BugTriage
|
Size: 4569
Comment:
|
Size: 2647
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| * [[Kernel/Triage/BugStates]] -- how the Kernel team uses bug states * [[KernelTeam/TriageLevels]] -- how the various levels of triage are defined and how they are performed |
* [[Kernel/BugTriage/BugStates]] -- how the Kernel team uses bug states * [[Kernel/TriageLevels]] -- how the various levels of triage are defined and how they are performed |
| Line 9: | Line 7: |
| * [[KernelTeam/UsingArsenal]] -- utilising the kernel arsenal scripts for automated triage * [[Kernel/BugTriage/CollectingInformation]] -- what information to collect for specific bug types * [[Kernel/Debugging]] -- debugging hints for various common scenarios |
|
| Line 21: | Line 22: |
| == Kernel Sound Bugs == If this is a sound related Ubuntu kernel bug, run the following to gather and attach important sound debugging information to the bug: {{{ $ apport-collect -p alsa-base <bug#> }}} == Problems in capturing information == === Bootloader === If the bug occurs during bootup, you can disable the splash screen in one of the following ways: * Permanent: Edit /boot/grub/menu.lst and remove ''splash'' and ''quiet'' kernel parameters to bootloader from the entry for the buggy kernel * Temporary: Press 'Escape' key at the 3 second pause by Grub bootloader. Then press 'e' (edit) on the buggy kernel entry, followed by 'e' again on the ''kernel'' line. Then remove the ''splash'' and ''quiet'' keywords and press 'b' to boot. === Capturing OOPs === If the bug report involves a crash, it is hoped that a kernel backtrace (aka OOPS, kernel panic) is available. If the machine does not completely lockup from the crash, the backtrace should be available in the `dmesg` output. If the crash completely locks the system: * Take a look at https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe * If using linux-crashdump (above) is not successful try and see if any backtrace was logged to `/var/log/kern.log.0`. Please attach this file if anything was captured. * If unable to log the full backtrace, supply a digital photo of the screen to capture the crash. It most important to capture the beginning of the kernel oops or panic. * When all fails, try to see if [[KernelTeam/Netconsole]] can help out. === In X window mode === Sometimes crashes occur in X, and so terminal access is not available (to capture the kernel backtrace). When this occurs, the user should try to recreate the crash at the console (Ctrl+Alt+F1). If this is not possible, then annotate the bug as such. = DIY Debugging Hints = For a complete list of debugging procedures refer to https://wiki.ubuntu.com/DebuggingProcedures <<Include(Kernel/Debugging, , from="== Debugging Scenarios ==$", to="==")>> |
Kernel/BugTriage/BugStates -- how the Kernel team uses bug states
Kernel/TriageLevels -- how the various levels of triage are defined and how they are performed
Kernel/Tagging -- how tags are used within Kernel bugs
Kernel/Tagging -- Level-2 triage tags and searches
KernelTeam/UsingArsenal -- utilising the kernel arsenal scripts for automated triage
Kernel/BugTriage/CollectingInformation -- what information to collect for specific bug types
Kernel/Debugging -- debugging hints for various common scenarios
Triage Effort
Triaging kernel bugs is a day-to-day effort, and can be very time consuming. Luckily, we have a lot of community members willing and able to help with this effort. The kernel team will also begin using a set of Kernel Arsenal scripts to help with the day-to-day triaging efforts (see KernelTeam/UsingArsenal). In order to make sure everyone working on kernel bugs follows the same policy, this document will describe how to handle the kernel bug workflow. This will also provide bug reporters with an idea of the life cycle their bug will follow.
Note that beginning with the Karmic development cycle an emphasis is being made to ensure bugs are tested and reported upstream. In relation to this, the Ubuntu kernel team will be transitioning their focus to fixing bugs which have been confirmed to exist upstream or are fixed upstream but exist in the Ubuntu kernel.
Also note that, as of the Maverick cycle, we will be breaking out our bugs into specific subsystems based on tags. For a list of current tags, please see the Tagging page. For specific information concerning the Bug Review process as it currently stands, please visit the Bug Review page. We have also further defined the levels of triage within our team. For an overview of that, please visit the Levels of Triage page.
Caveats
Sometimes kernel bugs are opened to track security vulnerabilities. These bugs usually contain the word "CVE" either in the title or bug description and will most likely have the ubuntu-security team subscribed to the bug. We should try to avoid spamming these bugs with comments to test the latest kernel to verify if the issue still exists. Whether manually posting to a bug or using python-launchpad-bugs to script comments, please take extra care to not cause more unnecessary traffic for the security team to deal with. Thanks.
Kernel/BugTriage (last edited 2012-06-19 00:49:02 by 210-185-64-102)