DebuggingKernelProblems

Differences between revisions 4 and 6 (spanning 2 versions)
Revision 4 as of 2006-05-09 22:41:30
Size: 746
Editor: dsl-43
Comment: more stuff to capture
Revision 6 as of 2006-05-12 20:02:39
Size: 4237
Editor: 72
Comment: Update for kernel triaging
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
If you find a kernel bug or want to work on a kernel bug, please make sure you have the following information: == Initial reports ==
Line 3: Line 3:
ALL of the following (and the lspci entries are *not* the same, run both):
 * the output of `lspci -vv`
 * the output of `lspci -vvn`
 * the output of `dmesg`
 * `/var/log/kern.log`
 * If you have a fault that triggers after some action, such as inserting a device, run the above 4 things twice, once before and once after.
 * Make sure you read:
  * https://wiki.ubuntu.com/MemoryTest
  * https://wiki.ubuntu.com/DebuggingSystemCrash
  * https://wiki.ubuntu.com/DebuggingIRQProblems
  * https://wiki.ubuntu.com/DebuggingProcedures
All initial bug reports should be left in the '''Unconfirmed''' and '''Normal''' states until the report is satisfactory for debugging.
Line 15: Line 5:
== Sound problems == All bug reports should contain atleast the output of these commands:
Line 17: Line 7:
Please subscribe {{{alsa-team}}}.  * 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.

Initial reports

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.


["CategoryKernel"]

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