[Ubuntu Wiki] Update of "DebuggingKernelOops" by brian-murray

[Ubuntu Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.

The following page has been changed by brian-murray:
http://wiki.ubuntu.com/DebuggingKernelOops?action=diff&rev1=8&rev2=9

The comment on the change is:
Reworking Tainted section

------------------------------------------------------------------------------
  EIP:    0060:[<c022a7b5>]    Not tainted VLI
  }}}
  
+ ==== Tainted Kernels ====
+ 
- This is also a good time to mention Tainted Kernels.  Some Oops reports contain the string 'Tainted: ' after the EIP. This indicates that the kernel has been tainted by some mechanism.  The string is followed by a series of position-sensitive characters, each representing a particular tainted value.
+ This is also a good time to mention Tainted Kernels.  Some Oops reports contain the string 'Tainted: ' after the EIP. This indicates that the kernel has been tainted by some mechanism.  'Tainted: ' is followed by a series of position-sensitive characters, each representing a particular tainted value.  If the letter does not appear the kernel is not tainted in that fashion.
  
   1. 'G' if all modules loaded have a GPL or compatible license
  
   1. 'P' if any proprietary module has been loaded.  Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary.
  
-  1. 'F' if any module was force loaded by "insmod -f", ' ' if all modules were loaded normally.
+  1. 'F' if any module was force loaded by "insmod -f".
  
   1. 'S' if the Oops occurred on an SMP kernel running on hardware that hasn't been certified as safe to run multiprocessor.  Currently this occurs only on various Athlons that are not SMP capable.
  
-  1. 'R' if a module was force unloaded by "rmmod -f", ' ' if all modules were unloaded normally.
+  1. 'R' if a module was force unloaded by "rmmod -f".
  
-  1. 'M' if any processor has reported a Machine Check Exception, ' ' if no Machine Check Exceptions have occurred.
+  1. 'M' if any processor has reported a Machine Check Exception.
  
   1. 'B' if a page-release function has found a bad page reference or some unexpected page flags.
  
-  1. 'U' if a user or user application specifically requested that the Tainted flag be set, ' ' otherwise.
+  1. 'U' if a user or user application specifically requested that the Tainted flag be set.
  
   1. 'D' if the kernel has died recently, i.e. there was an OOPS or BUG.
  
+  1. 'W' if a warning has previously been issued by the kernel.
+ 
+  1. 'C' if a staging module / driver has been loaded.
+ 
+  1. 'I' if the kernel is working around a sever bug in the platform's firmware (BIOS or similar).
+ 
+ An example output of a tainted line:
+ 
+ {{{
+ [187487.973317] Pid: 810, comm: iwl3945 Tainted: P   M        2.6.35-22-generic #33-Ubuntu
+ }}}
+ 
  The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has occurred.  Tainting is permanent: even if an offending module is unloaded, the tainted value remains to indicate that the kernel is not
  trustworthy.
+ 
+ ==== Call Stack Details ====
  
  {{{
  Stack: 00000000 00000000 d0b97e60 00008080 c01c4390 d0b97e60 00000000 00000000 
@@ -112, +128 @@

  Sometimes you'll need to derive even more information from the Call Stack.  This trace shows you how you got to where the code broke.  You'll notice that '''[thinkpad_acpi]''' trails some of the Call Trace output.  This indicates the module for which the code of the calling routine resides in.  This is often helpful in narrowing down which module contains the issue.
  
  == Submitting a Kernel Oops Bug Report ==
- Learning to debug and fix a kernel Oops is not an easy task for the average user.  However, any user should be able to gather the appropriate information to help the kernel team debug and fix the issue.  If you ever witness a kernel Oops please file a launchpad bug report.  The following steps help guide you through this reporting process:
+ Learning to debug and fix a kernel Oops is not an easy task for the average user.  However, any user should be able to gather the appropriate information to help the kernel team debug and fix the issue.  If you ever witness a kernel Oops please file a linux bug report in Launchpad.  The following steps help guide you through this reporting process:
  
   1. Search to see if someone else has already reported this issue.  However, make sure you are experiencing the _same_ Oops (ie Call Trace looks the same, EIP is at the same location, you have similar hardware, you use the same steps to reproduce the Oops, etc.)
     * If you are convinced the report is the same, please add any further useful information to the existing bug report.  It will also help if you subscribe youself to that report so you are notified of any updates regarding the bug.
     * If the report is not the same Oops you are experiencing, please proceed to Step 2.
-  1. Make sure the report is filed against the proper package. For a kernel Oops this will typically be 'linux-source-2.6.xx' or just 'linux'.
+  1. Make sure the report is filed against the proper package. For a kernel Oops this will be 'linux'.
   1. Please be sure to tag your report as 'kernel-oops'.  This can be done be clicking on the "Edit description/tags" link and entering the tag 'kernel-oops' into the Tags field.
-  1. Please provide a descriptive Subject for your bug
+  1. Please provide a descriptive Subject / Title for your bug.
     * BAD example - "Kernel Oops"
     * GOOD example - "Kernel Oops - unable to handle kernel NULL pointer dereference; EIP is at acpi_ns_internalize_name+0xd/0x83"
   1. Please provide the kernel team as much information as possible:
    * If you are able to consistently trigger the kernel Oops, please document the exact steps to reproduce it.
    * Capture the full output of the kernel Oops as well as any output that leads up to the kernel Oops.  This can usually be found in the dmesg output.
     * {{{ dmesg > dmesg.log }}}
-    * attach this file to the bug report
+    * attach dmesg.log to the bug report
    * Also attach the following information:
     * {{{ uname -a > uname-a.log }}}
     * {{{ cat /proc/version_signature > version.log }}}