Lines Matching refs:issues
5 …rg/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
13 Reporting issues
49 If you are facing multiple issues with the Linux kernel at once, report each
60 Step-by-step guide how to report issues to the kernel maintainers
63 The above TL;DR outlines roughly how to report issues to the Linux kernel
65 reporting issues to Free/Libre & Open Source Software (FLOSS) projects. For
81 will often be needed anyway to hunt down and fix issues.
89 issue, or a really severe problem: those are 'issues of high priority' that
105 issues at once, create separate notes for each of them and make sure they
116 time this won't be bugzilla.kernel.org, as issues typically need to be sent
138 up there, scroll down to the instructions for issues only happening with
165 you are dealing with one of those 'issues of high priority': they need
167 issues' below.
212 Reporting issues only occurring in older kernel version lines
243 Reference section: Reporting issues to the kernel maintainers
281 issues to the Linux kernel developers.
291 will often be needed anyway to hunt down and fix issues.*
294 with reports for issues that don't even happen with their current code. It's
303 Most of these vendor kernels are quite unsuitable for reporting issues to the
308 issues with these kernels to the vendor. Its developers should look into the
317 developers in fact are willing to handle reports about issues occurring with
322 Sid or Fedora Rawhide. Some developers will also accept reports about issues
390 issue, or a really severe problem: those are 'issues of high priority' that
393 Linus Torvalds and the leading Linux kernel developers want to see some issues
394 fixed as soon as possible, hence there are 'issues of high priority' that get
396 qualify: regressions, security issues, and really severe problems.
414 provides additional details how to best handle security issues.
444 main memory for example can result in a multitude of issues that will
445 manifest itself in problems looking like kernel issues.
566 issues at once, create separate notes for each of them and make sure they
571 If you deal with multiple issues at once, you'll have to report each of them
573 various issues in one report also makes it quite difficult for others to tear
574 it apart. Hence, only combine issues in one report if they are very strongly
581 Note: it's often fruitless to report issues that only happened once, as they
597 Linux developers want to fix badly, as such issues are even more unwanted than
599 people. The developers thus want to learn about such issues as quickly as
610 time this won't be bugzilla.kernel.org, as issues typically need to be sent
622 That's why you have to find the right place and way to report issues yourself.
799 reports for issues that don't even happen with the current code. It's just a
935 eliminate the reason for it before you reporting issues that occur with it. See
943 up there, scroll down to the instructions for issues only happening with
952 head over to the section "Details about reporting issues only occurring in
1097 you are dealing with one of those 'issues of high priority': they need
1099 issues' below.*
1201 insights how the components were configured. For some issues it might be
1235 you, unless it's one of those 'issues of high priority' outlined earlier: in
1239 Special handling for high priority issues
1242 Reports for high priority issues need special handling.
1244 **Severe issues**: make sure the subject or ticket title as well as the first
1266 **Security issues**: for these issues your will have to evaluate if a
1269 For issues that bear such a risk you will need to adjust the reporting process
1356 The 'issues of high priority' (see above for an explanation) are an exception
1382 to help to get issues resolved once they were reported.
1391 issues are normally reported in public it could be anyone that's replying —
1455 'issues of high priority' outlined earlier. So don't be too devastating if you
1457 issues to deal with currently and won't have time to look into this for the
1464 getting help are explained in 'Why some issues won't get any reaction or remain
1580 Reference for "Reporting issues only occurring in older kernel version lines"
1610 *Perform the first three steps in the section "Reporting issues only
1691 Why some issues won't get any reaction or remain unfixed after being reported
1694 When reporting a problem to the Linux developers, be aware only 'issues of high
1695 priority' (regressions, security issues, severe problems) are definitely going
1698 other issues as well. But be aware that sometimes they can't or won't help; and
1736 Priorities are another reason why some issues are not fixed, as maintainers
1745 maintainers who are quite interested in fixing as many issues as possible.
1752 issues to the Linux kernel developers: the length and complexity of this