diff options
Diffstat (limited to 'REPORTING-BUGS')
| -rw-r--r-- | REPORTING-BUGS | 65 |
1 files changed, 46 insertions, 19 deletions
diff --git a/REPORTING-BUGS b/REPORTING-BUGS index ad709e4ccb7..6ed518b6f71 100644 --- a/REPORTING-BUGS +++ b/REPORTING-BUGS @@ -1,3 +1,47 @@ +Identify the problematic subsystem +---------------------------------- + +Identifying which part of the Linux kernel might be causing your issue +increases your chances of getting your bug fixed. Simply posting to the +generic linux-kernel mailing list (LKML) may cause your bug report to be +lost in the noise of a mailing list that gets 1000+ emails a day. + +Instead, try to figure out which kernel subsystem is causing the issue, +and email that subsystem's maintainer and mailing list. If the subsystem +maintainer doesn't answer, then expand your scope to mailing lists like +LKML. + + +Identify who to notify +---------------------- + +Once you know the subsystem that is causing the issue, you should send a +bug report. Some maintainers prefer bugs to be reported via bugzilla +(https://bugzilla.kernel.org), while others prefer that bugs be reported +via the subsystem mailing list. + +To find out where to send an emailed bug report, find your subsystem or +device driver in the MAINTAINERS file. Search in the file for relevant +entries, and send your bug report to the person(s) listed in the "M:" +lines, making sure to Cc the mailing list(s) in the "L:" lines. When the +maintainer replies to you, make sure to 'Reply-all' in order to keep the +public mailing list(s) in the email thread. + +If you know which driver is causing issues, you can pass one of the driver +files to the get_maintainer.pl script: + perl scripts/get_maintainer.pl -f <filename> + +If it is a security bug, please copy the Security Contact listed in the +MAINTAINERS file. They can help coordinate bugfix and disclosure. See +Documentation/SecurityBugs for more information. + +If you can't figure out which subsystem caused the issue, you should file +a bug in kernel.org bugzilla and send email to +linux-kernel@vger.kernel.org, referencing the bugzilla URL. (For more +information on the linux-kernel mailing list see +http://www.tux.org/lkml/). + + [Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ] What follows is a suggested procedure for reporting Linux bugs. You aren't @@ -9,25 +53,8 @@ please read "Documentation/oops-tracing.txt" before posting your bug report. This explains what you should do with the "Oops" information to make it useful to the recipient. -Send the output to the maintainer of the kernel area that seems to be -involved with the problem, and cc the relevant mailing list. Don't worry -too much about getting the wrong person. If you are unsure send it to the -person responsible for the code relevant to what you were doing. If it -occurs repeatably try and describe how to recreate it. That is worth even -more than the oops itself. The list of maintainers and mailing lists is -in the MAINTAINERS file in this directory. If you know the file name that -causes the problem you can use the following command in this directory to -find some of the maintainers of that file: - - perl scripts/get_maintainer.pl -f <filename> - -If it is a security bug, please copy the Security Contact listed in the -MAINTAINERS file. They can help coordinate bugfix and disclosure. See -Documentation/SecurityBugs for more information. - -If you are totally stumped as to whom to send the report, send it to -linux-kernel@vger.kernel.org. (For more information on the linux-kernel -mailing list see http://www.tux.org/lkml/). +If it occurs repeatably try and describe how to recreate it. That is worth +even more than the oops itself. This is a suggested format for a bug report sent to the Linux kernel mailing list. Having a standardized bug report form makes it easier for you not to |