Doug / smarc-fsl-linux-kernel

Download as
Browse Code ยป

Commit 7883a250fed9562e6eae8a093e5e2d173ef16662

Authored by Sarah Sharp
1 parent d60418bce5
Exists in smarc-l5.0.0_1.0.0-ga and in 5 other branches imx_3.10.17_1.0.1_ga, imx_3.10.53_1.1.0_ga, imx_3.14.28_1.0.0_ga, smarc-imx_3.10.53_1.1.0_ga, smarc-imx_3.14.28_1.0.0_ga

Docs: Add "Gather info" section to REPORTING-BUGS. 

Add a sub-heading, and emphasize reproducibility.

Suggest taking a picture of the oops message.  (Did no one have cameras
in 2006?)

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Showing 1 changed file with 14 additions and 12 deletions Side-by-side Diff

... ... @@ -44,22 +44,24 @@
44 44  
45 45 [Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ]
46 46  
47   -What follows is a suggested procedure for reporting Linux bugs. You aren't
48   -obliged to use the bug reporting format, it is provided as a guide to the
49   -kind of information that can be useful to developers - no more.
  47 +Gather information
  48 +------------------
50 49  
51   -If the failure includes an "OOPS:" type message in your log or on screen
52   -please read "Documentation/oops-tracing.txt" before posting your bug
53   -report. This explains what you should do with the "Oops" information to
54   -make it useful to the recipient.
  50 +The most important information in a bug report is how to reproduce the
  51 +bug. This includes system information, and (most importantly)
  52 +step-by-step instructions for how a user can trigger the bug.
55 53  
56   -If it occurs repeatably try and describe how to recreate it. That is worth
57   -even more than the oops itself.
  54 +If the failure includes an "OOPS:", take a picture of the screen, capture
  55 +a netconsole trace, or type the message from your screen into the bug
  56 +report. Please read "Documentation/oops-tracing.txt" before posting your
  57 +bug report. This explains what you should do with the "Oops" information
  58 +to make it useful to the recipient.
58 59  
59   -This is a suggested format for a bug report sent to the Linux kernel mailing
60   -list. Having a standardized bug report form makes it easier for you not to
  60 +This is a suggested format for a bug report sent via email or bugzilla.
  61 +Having a standardized bug report form makes it easier for you not to
61 62 overlook things, and easier for the developers to find the pieces of
62   -information they're really interested in. Don't feel you have to follow it.
  63 +information they're really interested in. If some information is not
  64 +relevant to your bug, feel free to exclude it.
63 65  
64 66 First run the ver_linux script included as scripts/ver_linux, which
65 67 reports the version of some important subsystems. Run this script with