| werber | http://www.ireland.spmgame.com/partner.php?ID=266012 | 10:21 |
|---|---|---|
| werber | http://www.ireland.spmgame.com/partner.php?ID=266012 | 10:21 |
| === nfeldman is now known as nathan | ||
| === nathan is now known as Guest80941 | ||
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Kernel Bug Triage Summit (Maverick) - Current Session: General Introduction - Instructor: JeremyFoshee | ||
| === JFo is now known as JeremyFoshee | ||
| === JeremyFoshee is now known as JFo | ||
| JFo | ah, that's better | 15:04 |
| JFo | Hello folks! o/ | 15:04 |
| JFo | apologies for the delay | 15:04 |
| JFo | and Welcome to the first (hopefully regularly occurring) kernel triage summit | 15:04 |
| JFo | I'd like to cover several items in todays General session | 15:05 |
| JFo | information concerning today's summit can be found here: https://wiki.ubuntu.com/Kernel/BugTriage/Summit/Maverick | 15:05 |
| JFo | This will also be the location to which I will post the links to the transcript of todays sessions | 15:06 |
| JFo | so, let's begin :) | 15:06 |
| JFo | 1) Locations for information | 15:07 |
| JFo | https://wiki.ubuntu.com/Kernel/ | 15:07 |
| JFo | https://wiki.ubuntu.com/Kernel/BugTriage | 15:07 |
| JFo | https://wiki.ubuntu.com/Kernel/BugTriage/Process | 15:07 |
| JFo | These are some of the more relevant locations for information we will be discussing today | 15:07 |
| JFo | As always, your feedback on how these can be improved is welcome. | 15:07 |
| JFo | you can send us your thoughts to kernel-team@lists.ubuntu.com | 15:08 |
| JFo | that way the whole team can see and respond to your feedback | 15:08 |
| JFo | That list is also the best location to submit any patches you have done for inclusion in the kernel... but that is a topic for another day :-) | 15:08 |
| JFo | any questions so far? | 15:09 |
| JFo | excellent! | 15:09 |
| JFo | let's continue :) | 15:09 |
| JFo | 2) Subsystem Breakdown of bugs | 15:09 |
| JFo | https://wiki.ubuntu.com/Kernel/Tagging | 15:09 |
| JFo | This, as some of you may already be aware, is a new initiative for the team this cycle. | 15:10 |
| JFo | we are working to break out all of the kernel bugs into their particular subsystems | 15:10 |
| JFo | so that the team can focus on their particular expertise | 15:10 |
| JFo | in a more efficient manner. | 15:10 |
| JFo | <shadeslayer> quick question, suppose i have a question about https://wiki.ubuntu.com/Bugs/Importance, regarding the network card being under medium importance, should i wait till after the session? | 15:11 |
| JFo | actually, I think our final session of the day will be a Q&A session due to the instructor not being available | 15:11 |
| JFo | but if you are interested in knowing now shadeslayer you can ask in #ubuntu-kernel | 15:12 |
| JFo | shadeslayer, my pleasure :) | 15:12 |
| JFo | I don't currently have much of a better breakdown for the subsytems for next cyclestem tagging other than the Tagging page mentioned above, but that improvement is slated to be included in the work i | 15:13 |
| JFo | this is an effort to continually improve our documentation | 15:13 |
| JFo | I hope that some of you can help us move that effort forward wherever you feel comfortable | 15:14 |
| JFo | While I am here, I should mention that we do have some of the team available today for any off Summit topic questions you may have. | 15:15 |
| JFo | They are available in the #ubuntu-kernel chanel | 15:15 |
| JFo | That was actually a nice segue into my next topic | 15:15 |
| JFo | 3) How to reach the Kernel Team | 15:15 |
| JFo | https://wiki.ubuntu.com/Kernel/FAQ#How%20do%20I%20find%20the%20kernel%20team? | 15:15 |
| JFo | We have created an item in our FAQ on how best to reach the team | 15:16 |
| JFo | as mentioned above, we have the channel we work in on Freenode | 15:16 |
| JFo | we have the mailing list I mentioned above for feedback | 15:16 |
| JFo | some of you may have seen our Ubuntu StackExchange site. | 15:17 |
| JFo | I don't have the link handy, but this is a new forum-type site that seems to be helping us ensure the best information gets to those of you that need it | 15:17 |
| JFo | we hope to continue to improve this site so that it, along with our Forums and the launchpad bugs will provide the best methods of community support to our users | 15:18 |
| JFo | I hope those of you interested will join in on the StackExchange community site so that it can be the best possible | 15:18 |
| JFo | <DrKenobi> QUESTION: do I need to know something in particular to triage kernel bugs? | 15:19 |
| JFo | DrKenobi, great question! | 15:19 |
| JFo | No, you don't need anything other than a working knowledge of the information on the BugTriage wiki page above | 15:19 |
| JFo | the biggest help to us is ensuring that these bugs have the right information in them and are ready for an Engineer to look into | 15:20 |
| JFo | that doesn't require very much knowledge on the kernel | 15:20 |
| JFo | I should also mention that we have a document outlining the levels of triage | 15:21 |
| JFo | that may help further define this | 15:21 |
| JFo | let me get that link | 15:21 |
| JFo | https://wiki.ubuntu.com/Kernel/TriageLevels | 15:22 |
| JFo | there we go | 15:22 |
| JFo | does that help DrKenobi? | 15:23 |
| JFo | Let me move on, we can get to that some more in a few moments | 15:23 |
| JFo | 4) Who are our upstreams and where are they? | 15:24 |
| JFo | As many of you may be aware, our upstream is really Linus himself | 15:24 |
| JFo | there are a number of folks that work with him on the Linux kernel | 15:24 |
| JFo | people who you may see occasionally commenting in bugs on Launchpad | 15:24 |
| JFo | Ted T'so | 15:25 |
| JFo | Greg Kroah-Hartman | 15:25 |
| JFo | among many others | 15:25 |
| JFo | we also have Audio upstreams and Graphics and Driver upstreams | 15:25 |
| JFo | we are one of the largest teams with the most upstream locations | 15:26 |
| JFo | The upstream bug tracker is located here: 4) Who are our upstreams and where are they? | 15:27 |
| JFo | sigh* | 15:27 |
| JFo | trying to go too fast :-) | 15:27 |
| JFo | https://bugzilla.kernel.org/ | 15:27 |
| JFo | here ^ :-) | 15:28 |
| JFo | when you see a Linux task on a bug with a bugzilla number, this is where that is going most of the time | 15:28 |
| JFo | We refer to those as upstream bug watches | 15:28 |
| JFo | My preference is that for most bugs (if possible) we should locate and note an upstream bug that seems to be at fault | 15:30 |
| JFo | this is a bit involved | 15:30 |
| JFo | and requires a bit of searching on the bugzilla which is a bit difficult | 15:30 |
| JFo | <apw> QUESTION: where do upstream bug watches come from? | 15:30 |
| JFo | Great Question apw :-) | 15:31 |
| JFo | The upstream Bug Watch would be added to the bug by the Triager who is working on the bug | 15:31 |
| JFo | it could also be added by the original reporter if they took the time to look upstream for their issue | 15:32 |
| JFo | however, it has been my experience that the vast majority of our bugs are difficult to track to an upstream bug | 15:33 |
| JFo | This is something that I am hoping to address more fully over the next few cycles. | 15:33 |
| JFo | * nathan_ has quit (Remote host closed the connection) | 15:34 |
| JFo | <DrKenobi> jfo, yes! Thank you! | 15:34 |
| JFo | <charlie-tca> These references are good! | 15:34 |
| JFo | <JFo> DrKenobi, :) | 15:34 |
| JFo | <JFo> charlie-tca, thank you :) | 15:34 |
| JFo | <czajkowski> would it not be wise to keep the conversations in here for the logs and get the kernel folks in here rather than another channel to join and watch ? | 15:34 |
| JFo | * apw is in both if that helps | 15:34 |
| JFo | * sconklin (~sconklin@ubuntu/member/sconklin) has joined #ubuntu-classroom-chat | 15:34 |
| JFo | <JFo> this channel doesn't get logged to my understanding czajkowski | 15:34 |
| JFo | <JFo> only the classroom one I think | 15:34 |
| JFo | <apw> QUESTION: where do upstream bug watches come from? | 15:34 |
| JFo | * sconklin75 (~sconklin7@ip-64-32-163-20.atl.megapath.net) has joined #ubuntu-classroom-chat | 15:34 |
| JFo | * sconklin75 has quit (Changing host) | 15:34 |
| === Ursinha is now known as Guest49260 | ||
| JFo | * sconklin75 (~sconklin7@ubuntu/member/sconklin) has joined #ubuntu-classroom-chat | 15:34 |
| JFo | <charlie-tca> QUESTION: as triagers, should we be searching for those upstream bugs, or are they like trying to find duplicates in launchpad? | 15:34 |
| JFo | * Ursinha-afk (~ursula@canonical/launchpad/ursinha) has joined #ubuntu-classroom-chat | 15:34 |
| JFo | whoops | 15:34 |
| JFo | copy/paste fail :) | 15:34 |
| JFo | <charlie-tca> QUESTION: as triagers, should we be searching for those upstream bugs, or are they like trying to find duplicates in launchpad? | 15:34 |
| JFo | charlie-tca, Great Question! | 15:34 |
| JFo | my preference is that you would look for the upstream bug watch | 15:35 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Kernel Bug Triage Summit (Maverick) - Current Session: General Introduction - Instructor: JFo | ||
| JFo | given the new policy for the kernel on duplicates located here: https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs | 15:35 |
| JFo | we prefer that bugs that appear to be duplicates not be marked as such to allow us to investigate hardware revisions | 15:36 |
| JFo | any questions on that bit? | 15:37 |
| JFo | ok, let's move on a bit | 15:37 |
| JFo | 5) Testing images and Firmware Test Suite(FWTS) | 15:37 |
| JFo | This is something that is dear to my heart and I hope it will be to yours as well | 15:38 |
| JFo | The testing images came about as a desire for us to be able to test the most machines in the wild as possible with the least difficulty | 15:38 |
| JFo | the images for these are located here: http://kernel.ubuntu.com/~kernel-ppa/testing/ | 15:39 |
| JFo | please have a look at these and see if you find them useful | 15:39 |
| JFo | please also let us know of any problems you encounter | 15:39 |
| JFo | I'd really love if these could be used during GlobalJam or your team meetings | 15:40 |
| JFo | I hope you find them as useful as I think you will | 15:41 |
| JFo | For those of you just joining us, please ask your questions in #ubuntu-classroom-chat and preface with 'QUESTION:" | 15:42 |
| JFo | <diwic> QUESTION: How does the kernel-ppa testing images differ from the other testing images (e g daily-live CD:s)? | 15:42 |
| JFo | Excellent question diwic! :) | 15:42 |
| JFo | They are built from the exact same source as the daily LiveISO | 15:42 |
| JFo | with several changes | 15:43 |
| JFo | the first is that these images won't bring you to a screen whereby you can either install or try out Ubuntu | 15:43 |
| JFo | it will instead, log in to the desktop from the Live Image | 15:43 |
| JFo | as the Ubuntu user | 15:43 |
| JFo | at that time a terminal window will open and begin the test suite | 15:44 |
| JFo | once you complete the test suite, the results will be gathered, or if you have an internet connection, they will be transmitted to our DB | 15:44 |
| JFo | <charlie-tca> QUESTION: what is fwts and ktts mean in the ppa ? | 15:45 |
| JFo | charlie-tca, Excellent Question | 15:45 |
| JFo | anda great segue to the next bit of this conversation | 15:45 |
| JFo | FWTS stands for Firmware Test Suite | 15:45 |
| JFo | extra special thanks go to cking on the kernel team for this little gem | 15:45 |
| JFo | it is a toolset that will completely test your BIOS along with any other firmware on your system | 15:46 |
| JFo | I'll stop there and let sconklin discuss it a bit more in his Graphics talk | 15:46 |
| JFo | kkts is another test suite, that if I am not mistaken is based on the fwts | 15:47 |
| JFo | actually, now that I look at it | 15:47 |
| JFo | I believe that is the test suite that we are using in the testing images | 15:47 |
| JFo | yep, that is exactly it | 15:48 |
| JFo | there are 2 unique sets of images there in the /testing directory | 15:48 |
| JFo | one is built with the fwts installed | 15:48 |
| JFo | and the other is our test suite built within terminal using bash | 15:48 |
| JFo | both are very useful | 15:49 |
| JFo | hope that helps clarify | 15:49 |
| JFo | Any more questions there? | 15:49 |
| JFo | <dgtombs> QUESTION: so both are automated tests? | 15:49 |
| JFo | dgtombs, to my understanding, yes. | 15:49 |
| JFo | I have not as yet used the fwts based image | 15:50 |
| JFo | my own fault for not taking the time :) | 15:50 |
| JFo | <DrKenobi> QUESTION: so, this two images do the same? | 15:50 |
| JFo | not exactly the same | 15:50 |
| JFo | but very similar, yes | 15:50 |
| ClassBot | There are are 10 minutes remaining in the current session. | 15:50 |
| JFo | we developed the ktts suite before the fwts was available | 15:51 |
| JFo | so that is the older of the two | 15:51 |
| JFo | If I had to pick one to use, it would be the fwts as it is much more comprehensive | 15:51 |
| JFo | the ktts, is a more general, quick test if you will | 15:51 |
| JFo | geared more toward use by LoCos at their events | 15:52 |
| JFo | the fwts is directed more at Firmware and BIOS | 15:52 |
| JFo | Does that clear things up or make them more murky DrKenobi? :-) | 15:53 |
| JFo | the last thing I will cover is the cool ability to create a USB key that will boot multiple ISO images | 15:54 |
| JFo | it is located here https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey | 15:54 |
| JFo | thanks apw | 15:54 |
| JFo | with this information it is possible to install and boot from a number of ISO images on a single USB key | 15:54 |
| JFo | I find that very exciting | 15:55 |
| JFo | as it enables the testing of numerous architectures and images without the need for numerous keys :-) | 15:55 |
| JFo | what could be better? | 15:55 |
| JFo | and with that I will accept questions for the remainder :-) | 15:55 |
| ClassBot | There are are 5 minutes remaining in the current session. | 15:55 |
| JFo | I hope all of you found this session useful | 15:56 |
| JFo | <apw> QUESTION: do the fwts etc images work on the multiple ISO keys? | 15:56 |
| JFo | apw, yes they do | 15:56 |
| JFo | also part of the reason for my excitement | 15:56 |
| JFo | :-) | 15:56 |
| JFo | ok, thanks everyone, we will stop a bit early for refreshment etc. | 15:57 |
| JFo | \o/ | 15:57 |
| JFo | <dgtombs> QUESTION: are the kernel wiki pages open for modification by non-team members? or do you prefer discussion first? | 15:57 |
| JFo | dgtombs, they are absolutely open to modification | 15:57 |
| JFo | however | 15:57 |
| JFo | I would ask that you verify things you aren't sure of before you modify steps :-) | 15:58 |
| JFo | other than that, HackAway! | 15:58 |
| === albert231 is now known as albert23 | ||
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Kernel Bug Triage Summit (Maverick) - Current Session: Graphics/KMS/DRM/X - Instructor: sconklin | ||
| sconklin | Alright, we'll kick off the session on graphics | 16:04 |
| sconklin | I'm Steve Conklin. I'm a kernel engineer employed by Canonical. In the past I've worked on graphics bugs, although now I do stable maintenance | 16:05 |
| sconklin | As has been already covered, please do not pile additional problems from different users into launchpad bugs. | 16:05 |
| sconklin | The reason is that the bugs are seldom duplicates, even when the same driver is loaded. For example, there are many dozens of Intel graphics card models, and they all have different code paths in the driver. | 16:05 |
| sconklin | This is important not only for the triaging steps, but later when we actually have fixes in kernels and need them tested | 16:05 |
| sconklin | When people pile onto graphics bugs with "me too" information, please ask them to open another bug. Also be very skeptical when people respond in a bug after having tested a kernel with a possible fix in it. There are often a lot of "It didn't fix it for me" responses from people who have different graphics hardware. | 16:05 |
| sconklin | One thing to be aware of is that recently something called KMS has been added to the kernel. | 16:07 |
| sconklin | This stands for "Kernel Mode Setting", and allows the card hardware to be set up in the kernel drivers instead of in userspace | 16:08 |
| sconklin | So a very common diagnostic test is to ask people to turn off KMS by using kernel switches, but this only makes sense for Karmic+ | 16:08 |
| sconklin | You will also see references to "UMS" which is User Mode Setting, and is the alternative to KMS, and the "old way" | 16:09 |
| sconklin | Any questions so far? | 16:09 |
| sconklin | Here's a diagram showing some X architecture | 16:10 |
| sconklin | https://wiki.ubuntu.com/X/Architecture | 16:10 |
| === lol is now known as Guest81324 | ||
| sconklin | This is a good reference | 16:10 |
| sconklin | DRM stands for Direct Rendering Manager | 16:11 |
| sconklin | It is often difficult to know whether a problem is in the X server or in the kernel. | 16:11 |
| sconklin | Generally, the X and kernel teams can sort this out if a bug is opened against either, but it's good if you learn how to tell the difference | 16:12 |
| sconklin | or open against both | 16:12 |
| === Ursinha-afk is now known as Ursinha | ||
| sconklin | QUESTION: do we follow the same procedures to triage X as the kernel? | 16:13 |
| sconklin | Initially the steps are the same, until it's determines which has the bug | 16:13 |
| sconklin | And ubuntu-bug gathers a lot of the same information, so if the bug was opened using ubuntu-bug, we'll have most of what we need | 16:14 |
| sconklin | Some bug types are almost always kernel driver bugs - | 16:14 |
| sconklin | suspend/resume bugs | 16:15 |
| sconklin | problems detecting plug events (like plugging in a HDMI plug) | 16:15 |
| sconklin | Hangs and freezes are more difficult | 16:15 |
| sconklin | It's sometimes difficult to tell the difference between a kernel hang (or crash) and a graphics hang. The best way to tell is to have openssh-server installed on the system, and have the IP address recorded. If the system hangs, see if you can log in via the network. If you can, then it is a graphics hang (freeze). Here is more information about diagnosing graphics freezes: https://wiki.ubuntu.com/X/Troubleshooting/Freeze | 16:16 |
| sconklin | and in fact, the whole X subsystem wiki pages are really helpful: | 16:16 |
| sconklin | https://wiki.ubuntu.com/X/ | 16:17 |
| sconklin | Worth taking some time to read them | 16:17 |
| sconklin | Even if you can't get in via ssh, you can try triggering disk activity by plugging in a USB device. If there is disk activity, the kernel is alive and the system is running | 16:18 |
| sconklin | QUESTION: Can magic keys (Alt-PrtScr-REISUB) also help to determine whether it's a kernel bug or not? | 16:18 |
| sconklin | good question, but I'm not sure, since you can't see what's happening. | 16:18 |
| sconklin | unless you can get something into the messages file and see if after reboot | 16:19 |
| sconklin | One thing to be aware of is the huge number of models of graphics hardware cards. | 16:20 |
| sconklin | There are many, many quirks coded into the various drivers for different cards and computer models, and even for almost identical models, the manufacturer of the computer may have connected or not connected optional hardware ports. It's impossible to be an expert in every model. | 16:20 |
| sconklin | There are a few things which are very important to know early in the triage process. One is which graphics card is in use. You can generally get this from the output of lspci, which is usually included in the bug report if ubuntu-bug was used to open it. You can also often get it from /var/log/messages. | 16:20 |
| sconklin | There is also good information in /var/log/Xorg.0.log, especially when dealing with resolution issues. | 16:21 |
| sconklin | We strongly recommend that the hardware model of the card be in the bug title, and encourage triagers to change this as needed. | 16:22 |
| sconklin | This also helps discourage "me too" entries in the bug. | 16:22 |
| sconklin | any questions? | 16:22 |
| sconklin | The fwts (firmware test suite) may be useful for helping diagnose issues like backlight brightness keys not working | 16:23 |
| sconklin | QUESTION: so what exactly is the rule on dupes with graphics-related bugs? Some are obviously software/userspace issues so I assume dupes are allowed there. Is the no-dupe rule only for bugs which might be driver issues? | 16:24 |
| sconklin | Good question. This may not exactly be the X team's process, but I would encourage separate bugs until they re proven dups | 16:25 |
| sconklin | always keep them separate, because it's very difficult to tease apart information from multiple reporters. | 16:26 |
| sconklin | It's very easy to set bugs as dups if they are discovered to be so, but impossible to separate a bug into multiple different ones | 16:26 |
| sconklin | Honestly, as a kernel developer, I typically stop reading a bug after a few "me toos" with different hardware, because it becomes impossible to manage it | 16:27 |
| sconklin | If you've opened a bug and it's become noisy, you can always open a new one, and put a note to that effect in the first bug | 16:28 |
| sconklin | Developers also pay much more attention to the original reporter, and will ignore others. So if you've piled onto a bug and the original reporter says it's fixed, then the bug is closed, and all other information in it is lost | 16:29 |
| sconklin | QUESTION: what do you recommend doing with a bug that has gotten spammed up with me-too's. ask everyone to re-file? try to clear it up? | 16:29 |
| sconklin | Ask everyone but the original reporter to. | 16:29 |
| sconklin | If it's hopeless, ask the original reporter to also | 16:29 |
| sconklin | Another important triage tip: | 16:30 |
| sconklin | Watch out for generic titles like "graphics broken" and change them as soon as you can | 16:30 |
| sconklin | Try to extract some information that is descriptive from the bug report, and include the hardware model number | 16:31 |
| sconklin | And also include the vendor in the hardware ID. | 16:31 |
| sconklin | Like "Intel 855 black screen after resume" | 16:32 |
| sconklin | One fairly common problem is that people report a problem against their graphics hardware, but the driver for that hardware never got loaded | 16:32 |
| sconklin | The system cal fail back to a VESA driver, giving unexpected results | 16:33 |
| sconklin | Here's a good wiki page about that: | 16:33 |
| sconklin | https://wiki.ubuntu.com/X/Troubleshooting/OnlyLoadsVesa | 16:33 |
| sconklin | So check for that fairly early in the triage process, ESPECIALLY for resolution problems like "My system only supports 1024x768" | 16:34 |
| === yofel_ is now known as yofel | ||
| sconklin | questions? | 16:34 |
| sconklin | For resolution issues, there is information under /sys/class/drm which shows all outputs available, and resolution information for each output | 16:36 |
| sconklin | This is only for systems using KMS (Kernel Mode Setting) | 16:37 |
| sconklin | One more thing: | 16:37 |
| sconklin | In general, if someone has solved their problem by changing their Xconfig, it's not a kernel issue, except in some cases of resolution problems. | 16:38 |
| sconklin | In systems with KMS, you can get additional debug information by using this in your kernel boot parameters: | 16:41 |
| sconklin | drm.debug=0x04 | 16:41 |
| sconklin | There are also kernel parameters to disable KMS, and sometimes these are a useful test, especially for Lucid drivers | 16:41 |
| sconklin | These vary a bit from driver to driver | 16:42 |
| sconklin | adding nomodeset should be the general case, specific ones are i915.modeset=0 and radeon.modeset=0 | 16:43 |
| sconklin | Again, this only works with KMS-enabled drivers | 16:43 |
| sconklin | Also, just because a machine has Radeon graphics, you can't tell which driver should be running. It could be fglrx or nv, or nouveau, and it's worth checking into which driver has loaded | 16:44 |
| sconklin | QUESTION: can you disable KMS in all drivers? i seem to remember reading that one only supported KMS | 16:44 |
| sconklin | No, you can't Recent drivers especially have begun to disable UMS | 16:45 |
| sconklin | Only Intel no longer has UMS support from Maverick onward at the moment, but there will be more | 16:46 |
| sconklin | If you disable it on intel, it will drop back to VESA, for example | 16:46 |
| sconklin | so again - check which driver got loaded | 16:46 |
| sconklin | Just a mention here that having triage help with graphics issues is very, very helpful, and your help is really appreciated | 16:47 |
| sconklin | It makes things a lot easier, especially when bugs are properly classified for hardware very early | 16:47 |
| sconklin | It really reduces the amount of time we spend applying fixes, and speeds up the process of getting fixes released. | 16:48 |
| sconklin | QUESTION: does this hinder debugging? how can a reporter gather more information if KMS isn't working but he/she can't disable it? | 16:48 |
| sconklin | good question. if it's failing in KMS, then what you gather in UMS isn't terribly useful | 16:49 |
| sconklin | So turning on drm.debug=0x04 is something to try, as well as looking at the kernel and Xorg logs | 16:50 |
| sconklin | And if it won't boot, then you'll have to drop to older kernels, or bisect that way. | 16:50 |
| sconklin | Or try the latest upstream builds, especially if the problem is with a development kernel. | 16:51 |
| ClassBot | There are are 10 minutes remaining in the current session. | 16:51 |
| sconklin | That's about all I wanted to cover, any last questions before we take a break going into the next hour? | 16:51 |
| sconklin | Is there a flag somewhere to get the kernel to kprint what it's setting when? | 16:52 |
| sconklin | That's what drm.debug=0x04 is for | 16:52 |
| sconklin | you can also set this on the fly somewhere in /proc but it escapes me at the moment how to do this | 16:53 |
| sconklin | Where is drm.debug documented? | 16:54 |
| sconklin | Bad answer, but in the code | 16:54 |
| sconklin | /sys/modules/drm/parameters/debug I believe is where you can set that | 16:55 |
| ClassBot | There are are 5 minutes remaining in the current session. | 16:55 |
| sconklin | Here's a page with some KMS debug info: https://wiki.ubuntu.com/X/KernelModeSetting | 16:57 |
| sconklin | Thanks everyone, we'll take a break now | 16:57 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Kernel Bug Triage Summit (Maverick) - Current Session: Audio/Pulse - Instructors: bjf, diwic | ||
| diwic | Hello everyone and welcome the triaging session on audio. If you have any questions, don't be afraid to ask them - please ask them in #ubuntu-classroom-chat and start your question with "QUESTION:". | 17:01 |
| diwic | I'm going to talk a little about the different audio symptoms and initial triaging of those | 17:02 |
| diwic | The symptoms I intend to cover are: | 17:02 |
| diwic | * Mixer slider problems | 17:02 |
| diwic | * No auto-mute, or some inputs/outputs work and other don't. E g speakers work but not headphones, or external mic works but not internal mics. | 17:02 |
| diwic | * Sound is of bad quality | 17:03 |
| diwic | * Underrun problems (related to the one above) | 17:03 |
| diwic | * No card detected | 17:03 |
| diwic | * And finally, No sound at all, which can be anything of the above :-) | 17:03 |
| diwic | But first have a look at the https://wiki.ubuntu.com/Audio page, there are some goodies for triagers. | 17:04 |
| diwic | I'm going to try to keep it updated with information relevant to the latest release. Note that there are some pages under https://help.ubuntu.com/community/Sound that are very outdated or even partially wrong. | 17:04 |
| diwic | Questions so far? | 17:04 |
| diwic | Okay, moving on to the first symptom: Mixer problems, e g "everything under 20% is muted, and 21% on the slider blows my speaker" | 17:05 |
| diwic | The most likely cause is bad dB data and/or control names in driver. | 17:06 |
| diwic | First ask the user to try the latest snapshot according to https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules | 17:06 |
| diwic | Oh a word about that, perhaps. While other kernel subsystems ask people to test mainline kernels, | 17:06 |
| diwic | we usually ask them to test the latest snapshot. We take it daily from ALSA upstream and backport them to work with Lucid and Maverick kernel. | 17:07 |
| diwic | For HDA: This can sometimes be fixed by trying different models, but upstream ALSA prefers fixing the generic parser. | 17:08 |
| diwic | HDA, btw, is short for "Intel HD Audio", and is a very common sound chip standard which almost every new laptop and desktop has | 17:09 |
| ClassBot | sconklin asked: What's the "generic parser" ad what does it do? | 17:09 |
| diwic | First, this is HDA specific. The generic parser tries to trust BIOS on what physical connections a specific hardware has, whereas other models tend to hardcode this information | 17:11 |
| diwic | So if no model has been coded for your driver, you are using the generic parser. | 17:11 |
| ClassBot | sconklin asked: and how do models fit in? | 17:11 |
| diwic | Well, for every codec vendor id, there is a list of models. Again, this is HDA specific. | 17:12 |
| diwic | The list can be found here: | 17:12 |
| diwic | http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio-Models.txt | 17:13 |
| diwic | I'll return to a little more of the HDA stuff if there is time at the end of the session. | 17:13 |
| diwic | Abote the generic parser, it can be forced by setting model=auto, and can be detected through a "BIOS autoprobing" line in dmesg. | 17:14 |
| diwic | and with "setting model=auto" I mean to add a line to /etc/modprobe.d/alsa-base.conf | 17:14 |
| diwic | saying "options snd-hda-intel model=auto". | 17:15 |
| diwic | You can also try "model=toshiba", "model=3stack" or whatever you find under your section in HD-audio-Models.txt | 17:15 |
| diwic | Any more questions? | 17:16 |
| diwic | Okay, next symptom | 17:16 |
| diwic | * No auto-mute, i e speakers continue to sound if you plug in headphones. | 17:17 |
| diwic | or | 17:17 |
| diwic | * some inputs/outputs work and other don't. E g speakers work but not headphones, or external mic works but not internal mics. | 17:17 |
| diwic | Both are related. | 17:18 |
| diwic | First a note: Headphones should only mute speakers. Line outs should never be auto-muted. | 17:18 |
| diwic | That's the rule set by upstream. | 17:18 |
| diwic | HDA specific: This is often caused by bad BIOS config of pin NIDs. Note that these pins often irrelevant if you're not using the generic parser. | 17:19 |
| diwic | Can sometimes be fixed by changing models, but upstream (i e Takashi) prefers fixing the generic parser or to override the pin configs. | 17:20 |
| diwic | Also try tweaking user_pin_configs. One day when I have lots of time and little to do I might write a small useful app that helps with this...for now I'll refer to http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_hd_audio_reconfiguration | 17:20 |
| diwic | Note: Known issue for VIA's: the HDA driver is fooling PA into believing that you manually muted things when you plug headphones in. | 17:21 |
| === emma_ is now known as emma | ||
| diwic | Any questions on that? | 17:21 |
| ClassBot | apw asked: by VIA do you mean the make ? | 17:22 |
| diwic | Okay, so VIA is a Codec vendor. HDA is made up of two parts, the controller and the codec. | 17:22 |
| diwic | The controller is often built into the southbridge of the motherboard. | 17:23 |
| diwic | For how to see your Codec vendor, please see https://wiki.ubuntu.com/Audio/SameHardware (scroll down a bit. You'll see an example where it says "Realtek") | 17:24 |
| diwic | Okay, moving on to the next symptom. | 17:25 |
| diwic | * Sound is of bad quality | 17:25 |
| diwic | Here it is important to distinguish between sounds that are either | 17:26 |
| diwic | A) Digital clipping/distortion, or "overdriven" sound, which usually indicate a mixer problem, or | 17:26 |
| diwic | B) Underrun / dropout / "crackling" sound, which indicates an underrun problem | 17:26 |
| diwic | So for mixer problems, I've already covered that. For underrun problems, that's harder. | 17:26 |
| diwic | Unfortunately, these can be quite difficult to track down, and to be honest, I have yet to learn how to that. | 17:27 |
| diwic | Anyway, underruns happen when we don't supply audio data in time. | 17:27 |
| diwic | With PulseAudio in the picture, this can happen either on PulseAudio's front-end or its back-end. | 17:28 |
| diwic | Check if the underrun is on PA's front-end or back-end. Request a verbose log: https://wiki.ubuntu.com/PulseAudio/Log | 17:28 |
| diwic | An underrun on the backend, that is, between PA and Alsa, looks like: "alsa-sink.c: Underrun!" in the log. | 17:29 |
| diwic | An underrun on the front-end, that is, between the application playing audio and PA, looks like: "Underrun on 'Rhythmbox', 0 bytes in queue", and it be worth checking the client application, especially if this only happens with some clients. | 17:30 |
| diwic | hmm..that's not the line exactly, it's something with "memblockq" as well | 17:30 |
| ClassBot | charlie-tca asked: do both PCI Vendor-ID and PCI SSID have to match for a bug to be a duplicate? | 17:31 |
| diwic | As a rule of thumb, yes. | 17:32 |
| diwic | It's very unlikely to find the same PCI SSID from two different vendors, but I assume it's theoretically possible. | 17:32 |
| diwic | So, in order to not show my lack of knowledge, I'm moving on to the next symptom without asking for questions. ;-) | 17:33 |
| diwic | * Card not detected | 17:34 |
| diwic | There are various levels of "detection" of a card. | 17:34 |
| diwic | 1) If card does not show up as in "AlsaDevices.txt" (on a bug report) or as a card under /proc/asound/cardX (on your computer), check dmesg for errors. | 17:35 |
| diwic | 2) If card does show up in step 1) but does not show up in "AplayDevices.txt" (on bug report) or "aplay -l" does not show the sound card (on your computer), it might be that we lost contact with the card, or have a permission problem when accessing it. | 17:36 |
| diwic | for losing contact, that shows up in dmesg, hopefully. For HDA, that shows as "switching to single_cmd mode" or something like that. | 17:37 |
| diwic | For both cases above, trying the latest snapshot according to https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules might help. | 17:37 |
| diwic | 3) If card shows up in step 1) and 2) , but is not listed in pulseaudio (use the "pacmd list-cards" command for that), it could be that the card either is busy, or was busy when PA started. | 17:38 |
| diwic | You can check if somebody is currently using the card with: "sudo fuser -v /dev/snd/*" | 17:39 |
| diwic | If card works for some users, but do not show up for other users when using "fast user switching", check if any user is part of the "audio" group. See https://wiki.ubuntu.com/Audio/TheAudioGroup for some background information on that. | 17:39 |
| ClassBot | johng asked: Do you ever need to collect a .wav file for diagnosis? | 17:39 |
| diwic | Well, that's really up to you and depend on the case. If the user is complaining about bad audio quality, and can provide a sample of that, you might be able to hear whether it is an underrun or digital clipping. | 17:40 |
| diwic | I seldom ask for that, but sometimes I guess it could make sense. | 17:41 |
| ClassBot | apw asked: are these various types of failure documented with these diasgnostic tips? | 17:41 |
| diwic | so what I write to you here, I should probably also write on a wiki page somewhere. I have not yet done that. Does that answer your question, apw? | 17:42 |
| ClassBot | charlie-tca asked: if a user is in the "audio" group, do they need to be removed from it? | 17:43 |
| diwic | Good question. I'm not really sure what to answer. | 17:43 |
| diwic | I've written an article on https://wiki.ubuntu.com/Audio/TheAudioGroup that lists the implications of doing so. If the user is aware of those and find it necessary for some other reason, I'm fine with that. | 17:45 |
| diwic | So if a user complains about his mixer slider, you shouldn't jump on him complaining about being in the audio group. | 17:46 |
| diwic | Okay, so the last symptom. | 17:46 |
| diwic | * No sound at all | 17:47 |
| diwic | This can be almost anything of the above. | 17:47 |
| diwic | First check the mixer levels: Given an apport-collect, go to the CardX.Amixer.values.txt, look for [off] and "2%" and the like. | 17:47 |
| diwic | That only applies to relevant mixer controls though, so if a user is complaining about playback not working, there is nothing wrong with e g "Mic" being [off]. | 17:48 |
| diwic | The "ubuntu-bug audio" command checks for this already btw. | 17:48 |
| diwic | Second, check if there is a card at all. | 17:49 |
| diwic | Tip: If you run "ubuntu-bug audio", you'll hear two sets of test tones. If the first set of test tones are heard, the problem is likely higher up in the stack. | 17:49 |
| diwic | The first set plays them directly to ALSA, whereas the second set plays them through PulseAudio. | 17:50 |
| diwic | Oh, and in Maverick, the most common reason is that sound is currently muted on boot and needs to be turned on the normal way. | 17:51 |
| ClassBot | There are are 10 minutes remaining in the current session. | 17:51 |
| diwic | We're working on that. | 17:51 |
| diwic | Questions? | 17:51 |
| diwic | If there are any questions I've missed, let me know. | 17:52 |
| diwic | Otherwise we'll having a five minute break now and then it's Q&A session. | 17:54 |
| apw | diwic, thanks that was a great session | 17:54 |
| * diwic bows | 17:54 | |
| apw | we'll pick up on the hour for a general triage Q&A | 17:55 |
| ClassBot | There are are 5 minutes remaining in the current session. | 17:55 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Kernel Bug Triage Summit (Maverick) - Current Session: General Kernel Q&A - Instructors: JFo, sconklin, diwic, apw | ||
| apw | Ok this next session is a general Triage Question and Answer session. If you have questions on triage or debugging the kernel, this is the place to ask. | 18:02 |
| apw | With us we have a number of kernel engineers from the Ubuntu kernel team | 18:02 |
| apw | so ... ask away. | 18:02 |
| ClassBot | the_hydra asked: personally i find it as a plus, so I just wonder.... | 18:03 |
| apw | QUESTION: what is the reason ubuntu ships -rt enabled kernel? | 18:03 |
| apw | actually the -rt kernel is an ubuntu community project. that means that members of the | 18:04 |
| apw | ubuntu community have deemed that kernel useful enough to warrent them spending their time on it. | 18:04 |
| apw | the kernel team is really only involved in sponsoring their uploads | 18:04 |
| apw | we do not prevent additional kernels being made available where they have a real use | 18:04 |
| ClassBot | the_hydra asked: what is the reason ubuntu ships -rt enabled kernel? | 18:06 |
| apw | yes indeed it is simply a packaging up of the -rt kernel from Ingo, with an ubuntu configuration and tooling | 18:06 |
| ClassBot | the_hydra asked: but -rt kernel is mostly based on ingo molnar's work, I assume? | 18:07 |
| apw | yes indeed it is simply a packaging up of the -rt kernel from Ingo, with an ubuntu configuration and tooling | 18:07 |
| apw | (getting in sync now) | 18:07 |
| ClassBot | sconklin asked: is there anything special that should be done is there's a patch attached to a bug? | 18:09 |
| apw | if the attached patch has the right mime type it will automatically mark itself as a patch. if you see a patch which is clearly a patch but not marked as such then do feel free to click the ticky | 18:10 |
| apw | this will allow us to better focus on fixes which have already found | 18:10 |
| apw | also if the fix is for an important bug, then it is worth making JFo aware of the patch so he can get it on the teams radar | 18:10 |
| apw | we have a bunch of bugs and stuff can easily get lost in the pile | 18:10 |
| ClassBot | the_hydra asked: in most shipped kernels, I find it to be configured with HZ=250 and preempt voluntary..for desktop, why not HZ=1000 and full preempt? | 18:11 |
| apw | the higher the rescheduling rate the higher the overheads, both in terms of CPU and in terms of power consumption | 18:12 |
| apw | most users simply do not require these settings so high. there is a place for them but not for the common case currently | 18:12 |
| ClassBot | the_hydra asked: isn't that tackled by NO_HZ? | 18:12 |
| apw | no although no_hz claims to prevent clocks it does not in practice complely do so, and overhead is measurable in the single digit percentage of performance | 18:13 |
| apw | and noticable reduction in battery life, hopefully HZ will become irelliveant over time | 18:13 |
| apw | in theory we should not nead one if NO_HZ worked as advertised. yet changing it makes a difference | 18:14 |
| ClassBot | the_hydra asked: i see now..how about preemp? | 18:14 |
| apw | that is more about following the upstream default, the most tested combination | 18:15 |
| apw | we try and stay as close to the most tested combinations in all choices at the confiiguration level | 18:15 |
| ClassBot | the_hydra asked: i see...well, IMO it's really all about compromise.... i, myself, prefer to use full preempt | 18:16 |
| apw | yes there is always compromise in any decision. you likely care to use the preempt kernel | 18:17 |
| ClassBot | dgtombs asked: what are the kernel team's on the massive backlog of kernel bugs? is there a plan of action to deal with it? | 18:17 |
| apw | yes we have some initiative in progress at the moment in fact | 18:18 |
| apw | we have been expiring older bugs which are not being responded to for example | 18:18 |
| apw | we have dropped out backlog from some 10k bugs to more like 5-6k | 18:18 |
| apw | and, this triage summit is another prong in that approach | 18:18 |
| apw | getting good quality bugs with good information helps find bugs which we can get progressed | 18:18 |
| apw | we are of course always interested in ideas from the community | 18:19 |
| apw | or ideas on how to help grow the triage and debug and development teams | 18:19 |
| apw | the more help we have, the better our product, the happier we are | 18:19 |
| apw | ... | 18:21 |
| apw | anyone have any further questions for us ? | 18:21 |
| ClassBot | johng asked: Should bug descriptions be oriented around what a user sees or what the underlying problem is? | 18:22 |
| apw | i think in the early days there is no doubt that the symptoms are the most useful | 18:22 |
| apw | as we want people to find the right bug. for myself when i knwo the real bug | 18:22 |
| apw | i tend to make a hybrid title which contains symptoms in the start and the real bug as the tail | 18:23 |
| apw | right if there are no further questions, i'm going to call it a day, and let my boys get some R&R for next week | 18:30 |
| apw | thanks all of those of you who attended and we hope you learned something new | 18:30 |
| apw | if you have feedback or suggestions please do feedback directly to the kernel-team, or if you want to do so in private direct to JFo | 18:31 |
| apw | thanks to everyone who contributed. till next time. goodbye | 18:31 |
| ClassBot | There are are 10 minutes remaining in the current session. | 18:50 |
| ClassBot | There are are 5 minutes remaining in the current session. | 18:55 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi | ||
| axisys | so when is the class starting? | 19:25 |
| * shoonya is away: Gone to bed... | 20:43 | |
| === SmartSsa_ is now known as SmartSsa | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!