1: [Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ]
    2: 
    3:      What follows is a suggested procedure for reporting Linux bugs. You
    4: aren't obliged to use the bug reporting format, it is provided as a guide
    5: to the kind of information that can be useful to developers - no more.
    6: 
    7:      If the failure includes an "OOPS:" type message in your log or on
    8: screen please read "Documentation/oops-tracing.txt" before posting your
    9: bug report. This explains what you should do with the "Oops" information
   10: to make it useful to the recipient.
   11: 
   12:       Send the output to the maintainer of the kernel area that seems to
   13: be involved with the problem. Don't worry too much about getting the
   14: wrong person. If you are unsure send it to the person responsible for the
   15: code relevant to what you were doing. If it occurs repeatably try and
   16: describe how to recreate it. That is worth even more than the oops itself.
   17: The list of maintainers is in the MAINTAINERS file in this directory.
   18: 
   19:       If it is a security bug, please copy the Security Contact listed
   20: in the MAINTAINERS file.  They can help coordinate bugfix and disclosure.
   21: See Documentation/SecurityBugs for more information.
   22: 
   23:       If you are totally stumped as to whom to send the report, send it to
   24: linux-kernel@vger.kernel.org. (For more information on the linux-kernel
   25: mailing list see http://www.tux.org/lkml/).
   26: 
   27: This is a suggested format for a bug report sent to the Linux kernel mailing
   28: list. Having a standardized bug report form makes it easier for you not to
   29: overlook things, and easier for the developers to find the pieces of
   30: information they're really interested in. Don't feel you have to follow it.
   31: 
   32:       First run the ver_linux script included as scripts/ver_linux, which
   33: reports the version of some important subsystems.  Run this script with
   34: the command "sh scripts/ver_linux".
   35: 
   36: Use that information to fill in all fields of the bug report form, and
   37: post it to the mailing list with a subject of "PROBLEM: <one line
   38: summary from [1.]>" for easy identification by the developers.
   39: 
   40: [1.] One line summary of the problem:
   41: [2.] Full description of the problem/report:
   42: [3.] Keywords (i.e., modules, networking, kernel):
   43: [4.] Kernel information
   44: [4.1.] Kernel version (from /proc/version):
   45: [4.2.] Kernel .config file:
   46: [5.] Most recent kernel version which did not have the bug:
   47: [6.] Output of Oops.. message (if applicable) with symbolic information
   48:      resolved (see Documentation/oops-tracing.txt)
   49: [7.] A small shell script or example program which triggers the
   50:      problem (if possible)
   51: [8.] Environment
   52: [8.1.] Software (add the output of the ver_linux script here)
   53: [8.2.] Processor information (from /proc/cpuinfo):
   54: [8.3.] Module information (from /proc/modules):
   55: [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
   56: [8.5.] PCI information ('lspci -vvv' as root)
   57: [8.6.] SCSI information (from /proc/scsi/scsi)
   58: [8.7.] Other information that might be relevant to the problem
   59:        (please look in /proc and include all information that you
   60:        think to be relevant):
   61: [X.] Other notes, patches, fixes, workarounds:
   62: 
   63: 
   64: Thank you