summaryrefslogtreecommitdiffstats
path: root/REPORTING-BUGS
diff options
context:
space:
mode:
Diffstat (limited to 'REPORTING-BUGS')
-rw-r--r--REPORTING-BUGS65
1 files changed, 46 insertions, 19 deletions
diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index ad709e4ccb7c..6ed518b6f715 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