DebuggingKernelProblems

Differences between revisions 6 and 22 (spanning 16 versions)
Revision 6 as of 2006-05-12 20:02:39
Size: 4237
Editor: 72
Comment: Update for kernel triaging
Revision 22 as of 2009-06-14 14:23:36
Size: 202
Editor: ip98-169-125-170
Comment: fix link
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Initial reports == #refresh 5 KernelTeamBugPolicies
Line 3: Line 3:
All initial bug reports should be left in the '''Unconfirmed''' and '''Normal''' states until the report is satisfactory for debugging.

All bug reports should contain atleast the output of these commands:

 * dmesg > dmesg.log
 * lspci -vv > lspvi-vv.log
 * lspvi -vvn > lspvi-vvn.log

These three files should be attached to the bug report (not pasted into comments, as it makes things harder to read, and formatting is completely broken).

Dmesg output may be annotated to show before and after problem occured (e.g. if a device is attached and does not work, annotate where in dmesg the device was attached so that messages related to the attachment can be isolated).

Also, dmesg output should be done as early as possible after bootup to avoid extraneous output.

The submitter should provide as much informatin as possible in regards to whether the bug exists in previous versions of Ubuntu. Where possible, test the latest development version as well. Whether or not the bug affects other Linux distributions, or stock kernels is also of importance.

If the bug report involves a crash, it is hoped that a kernel backtrace 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, then the user should be asked to supply a digital photo of the screen to capture the crash.

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 (Alt+F1). If this is not possible, then annotate the bug as such.


== Bug Classification ==

For the most part, kernel bugs should be assigned to the ubuntu-kernel-team. In many cases, however, a specific team is aimed at handling bugs in different sections of the kernel. These teams fall into two categories: Subsection specific teams, and Architecture specific teams.

When assigning to one of these teams, use the following guidelines. Remember that if a bug falls into more than one category (e.g. an IDE bug on powerpc), it should be assigned to the most relevant subsystem team (as opposed to the architecture team). Subsystem teams always take precedence on initial bug assignment.

Certain bug classifications below require additional info from the bug submitter. Be sure to obtain this information before moving the bug out of '''Needs Info''' status.

=== Subsystem specific ===

 * ubuntu-kernel-team: Drop through when bugs do not fall into a specific category.

 * ubuntu-server: Any bugs dealing with the -server kernels that are not reproducable on a standard kernel.

 * ubuntu-audio: Any bugs dealing with the ALSA sound system.

 * ubuntu-kernel-acpi: Any bugs dealing with ACPI, including hotkey features, cpu throttling, thermal detection, battery states, etc.

 * ubuntu-kernel-network: Any bugs dealing with network drivers (ethernet, wireless, etc) or the network stack (IP, ICMP, UDP, etc).

 * ubuntu-kernel-usb: All bugs related to USB and USB devices (except in cases such as storage, video, sound and networking, where the bug clearly has to do with that team as opposed to a general USB issue).

 * ubuntu-kernel-video: All bugs related to framebuffers, VGA, DRM, video acceleration, Video capture, etc.

 * ubuntu-kernel-storage: IDE, SATA, SCSI, RAID, etc.


=== Architecture specific ===

Architecure specific teams. Bugs should be assigned to these teams when it directly relates to the system in question. E.g. when the kernel wont boot on such a system.

 * ubuntu-amd64
 * sparc-port
 * ubuntu-hppa
 * ubuntu-ia64
 * ubuntu-x86
 * ubuntu-powerpc


== Final ==

Once a bug contains all the relevant information, it can be assigned to the appropriate team, and moved to the '''Confirmed''' state. If information is requested from the submitter, the bug should be left in '''Needs Info''' state.

Bugs that have been assigned are then handled by the appropriate team, or someone acting on behalf of that team. Once a member of the team begins work on a bug, it should be changed to the '''In Progress''' state.
This page is superseded by the KernelTeam/KernelTeamBugPolicies page. Please update any links to this page.
Line 70: Line 6:
["CategoryKernel"] Go back to '''[[DebuggingProcedures]]'''.<<BR>>

This page is superseded by the KernelTeam/KernelTeamBugPolicies page. Please update any links to this page.


Go back to DebuggingProcedures.

DebuggingKernelProblems (last edited 2009-06-14 14:23:36 by ip98-169-125-170)