Lines Matching full:issue
16 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
22 issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
27 <https://kernel.org/>`_. If the issue is present there, send a report.
29 The issue was fixed there, but you would like to see it resolved in a still
38 before the issue occurs.
42 issue, like the kernel and the distro used. In case of a regression, CC the
64 early if an issue that looks like a Linux kernel problem is actually caused by
68 * Are you facing an issue with a Linux kernel a hardware or software vendor
70 document and reporting the issue to your vendor instead, unless you are
79 * See if the issue you are dealing with qualifies as regression, security
80 issue, or a really severe problem: those are 'issues of high priority' that
83 * Make sure it's not the kernel's surroundings that are causing the issue
92 * Check if your kernel was 'tainted' when the issue occurred, as the event
93 that made the kernel set this flag might be causing the issue you face.
95 * Write down coarsely how to reproduce the issue. If you deal with multiple
97 work independently on a freshly booted system. That's needed, as each issue
105 * Locate the driver or kernel subsystem that seems to be causing the issue.
111 thoroughly for reports that might match your issue. If you find anything,
128 * Reproduce the issue with the kernel you just installed. If it doesn't show
133 reproduce your issue. Make sure the end result has all the important
136 process, consider searching again for existing reports about the issue.
141 * If your problem is a regression, try to narrow down when the issue was
145 issue. Always mention a few things: the latest kernel version you installed
147 reproduce the issue. Ideally, make the kernel's build configuration
152 outlining the issue and the impact quickly. On top of this add one sentence
188 the issue might have already been fixed there. If you first noticed the
196 issue and ideally explain how to reproduce it. Mention the first version
207 above, but failed to reproduce your issue there; at the same time you want to
208 see the issue fixed in a still supported stable or longterm series or vendor
212 might not get the issue solved in older releases: the fix might be too big
219 the issue in mainline, as its commit message might tell you if the fix is
221 search the appropriate mailing lists for posts that discuss such an issue
228 issue for advice; CC the mailing list for the particular subsystem as well
258 developer handling the issue works for the vendor in question. If you want
260 so, you might want to mention you'd like to see the issue fixed in the
264 * If you never reported an issue to a FLOSS project before you should consider
278 *Are you facing an issue with a Linux kernel a hardware or software vendor
280 document and reporting the issue to your vendor instead, unless you are
295 Linux kernel developers: an issue you face with one of them might have been
297 the modifications and enhancements by the vendor might be causing the issue you
300 report and, in case it turns out to be an upstream issue, fix it directly
305 explain how to do that once it rules out other potential causes for your issue.
310 issue in question. Your chances are quite good if the distributor applied only
324 better than not reporting the issue at all: sometimes such reports directly or
325 indirectly will help to get the issue fixed over time.
336 Reporting an issue that someone else already brought forward is often a waste of
338 interest to thoroughly check if somebody reported the issue already. At this
340 tell you to perform a more detailed search once you know where your issue needs
351 look at the issue from the perspective of someone else: that will help you to
360 In case you find an existing report about your issue, join the discussion, as
371 need to report your issue". The developers that should take care of the issue
373 the issue already got reported as outlined in this document and if not consider
377 Issue of high priority?
380 *See if the issue you are dealing with qualifies as regression, security
381 issue, or a really severe problem: those are 'issues of high priority' that
394 might want to be aware of; it for example explains how to add your issue to the
397 What qualifies as security issue is left to your judgment. Consider reading
401 An issue is a 'really severe problem' when something totally unacceptably bad
404 issue when the kernel suddenly stops working with an error message ('kernel
413 *Make sure it's not the kernel's surroundings that are causing the issue
416 Problems that look a lot like a kernel issue are sometimes caused by build or
426 potential kernel issue.
428 * Try to make sure it's not faulty hardware that is causing your issue. Bad
432 * If you're dealing with a filesystem issue, you might want to check the file
465 The risk your issue report gets ignored or rejected dramatically increases if
482 *Check if your kernel was 'tainted' when the issue occurred, as the event
483 that made the kernel set this flag might be causing the issue you face.*
486 lead to follow-up errors that look totally unrelated. The issue you face might
520 the issue afterwards. Sometimes simply restarting will be enough, sometimes
530 areas and thus might be causing the issue you face. You therefore have to
531 prevent those modules from loading when you want to report an issue to the
539 quality standards. When you report an issue with such a module it's
541 question is the only reason for the taint. If the issue happens in an
547 Document how to reproduce issue
550 *Write down coarsely how to reproduce the issue. If you deal with multiple
552 work independently on a freshly booted system. That's needed, as each issue
562 Additionally, during the reporting process you will have to test if the issue
564 you know exactly how to reproduce an issue quickly on a freshly booted system.
568 try to rule that out by reproducing the issue before going further. Feel free
570 due to faulty hardware apart from a kernel issue that rarely happens and thus
590 Check where you need to report your issue
593 *Locate the driver or kernel subsystem that seems to be causing the issue.
606 file your issue and make it reach the developers that need to know about it.
616 case it's likely an issue in the WiFi driver. Obviously it could also be some
674 That only leaves these options: arrange yourself to live with the issue, fix it
678 you where to find a subsystem specific bug tracker to file your issue. The
688 issue reports sent by email, make sure to add the Linux Kernel Mailing List
690 lists when sending your issue report by mail later! Maintainers are busy people
692 and LKML is important to have one place where all issue reports can be found.
737 thoroughly for reports that might match your issue. If you find anything,
740 As mentioned earlier already: reporting an issue that someone else already
786 interest that you confirm the issue still exists with the latest upstream code
788 earlier: doing so dramatically increases the risk that your issue report might
822 quite busy then and might have no spare time to deal with issue reports. It's
824 window fixes the issue you face; that's why you soon would have to retest with
833 using it for reproducing the issue is also better than not reporting it issue
838 kernel is so important: any issue you want to see fixed in older version lines
841 hard or risky for backporting; reporting the issue again hence is unlikely to
847 further: if the issue doesn't occur with mainline it will guide you how to get
857 unsuitable for testing and issue reporting: the changes might cause the issue
902 you later to pinpoint the exact line of code that triggers your issue. The
905 But keep in mind: Always keep a record of the issue encountered in case it is
907 the issue at all.
924 Reproduce issue with the fresh kernel
927 *Reproduce the issue with the kernel you just installed. If it doesn't show
931 Check if the issue occurs with the fresh Linux kernel version you just
933 line and abandoning your plan to report the issue. But keep in mind that other
941 Optimize description to reproduce issue
945 reproduce your issue. Make sure the end result has all the important
948 process, consider searching again for existing reports about the issue.*
956 issue you face. Use this knowledge and search again for existing reports
968 source code that triggered the issue and shows how it was called. But that only
1017 *If your problem is a regression, try to narrow down when the issue was
1023 promptly reverted if the issue they cause can't get solved quickly any other
1033 reproduce the issue with each of them before building the next. Yes, that takes
1052 process. But keep in mind: it depends on the issue at hand if the developers
1057 When dealing with regressions make sure the issue you face is really caused by
1060 In the whole process keep in mind: an issue only qualifies as regression if the
1072 issue. Always mention a few things: the latest kernel version you installed
1074 reproduce the issue. Ideally, make the kernel's build configuration
1079 outlining the issue and the impact quickly. On top of this add one sentence
1103 Describe in detail how your issue happens with the fresh vanilla kernel you
1105 earlier that outline how you and ideally others can reproduce the issue; in
1110 issue and its environment. What's actually needed depends a lot on the issue,
1135 issue and call ``dmesg`` right afterwards.
1138 your report. If you are filing the issue in a bug tracker then attach them to
1139 the ticket. If you report the issue by mail do not attach them, as that makes
1148 changed just to fix your issue.
1157 Depending on the issue you might need to add more background data. Here are a
1164 * If the issue might be related to your computer hardware, mention what kind
1180 its driver. If you have a filesystem issue, mention the version of
1208 describes the issue roughly. Leave out all boring details and focus on the
1239 and the oldest where the issue occurs (say 5.8-rc1).
1254 If that's not the case simply proceed with reporting the issue as described.
1258 * If the MAINTAINERS file instructed you to report the issue by mail, do not
1261 * If you were supposed to file the issue in a bug tracker make sure to mark
1262 the ticket as 'private' or 'security issue'. If the bug tracker does not
1286 might immediately spot what's causing the issue; they then might write a patch
1302 **Always reply in public**: When you filed the issue in a bug tracker, always
1348 times there might be disagreements, for example if an issue qualifies as
1357 mainline kernel version gets released, go and check if the issue is fixed there
1362 issue persists and makes sure they do not forget about it. A few other
1384 issue.
1404 developers; or a discussion around the issue evolved, but faded out with
1423 issue reporting and ask for their opinion. Also ask them for their advice how
1426 mention that this is the second and improved report on the issue and include a
1440 react somehow to every issue report, but they are only obliged to fix those
1453 Don't get devastated if you don't find any help or if the issue in the end does
1456 them to get the issue resolved. Such a team could prepare a fresh report
1496 Maybe the issue you face is already known and was fixed or is about to. Hence,
1498 <https://lore.kernel.org/stable/>`_ for reports about an issue like yours. If
1502 Reproduce issue with the newest release
1507 the issue might have already been fixed there. If you first noticed the
1511 Before investing any more time in this process you want to check if the issue
1513 This kernel needs to be vanilla and shouldn't be tainted before the issue
1522 well. If things are broken there, the issue does not qualify as upstream
1524 the issue.
1533 issue and ideally explain how to reproduce it. Mention the first version
1539 the start to get the issue reported quickly. Hence a rough description to the
1550 the distributor applied interfere. If the issue doesn't manifest itself there,
1557 pinpoint the exact change that causes the issue (which then can easily get
1558 reverted to fix the issue quickly). Hence consider to do a proper bisection
1570 reproduce your issue with a mainline kernel, but want to see it fixed in older
1577 might not get the issue solved in older releases: the fix might be too big
1590 live with the issue or switch to a newer Linux version, unless you want to
1614 the issue in mainline, as its commit message might tell you if the fix is
1616 search the appropriate mailing lists for posts that discuss such an issue
1621 In a lot of cases the issue you deal with will have happened with mainline, but
1623 to get the issue solved. That's why you want to search for it or any
1643 again for discussions about the issue. Search the net with your favorite
1646 section `Locate kernel area that causes the issue` above and follow the
1655 to live with the issue or switch to the kernel version line where the fix
1659 join the discussion: mention the version where you face the issue and that
1668 issue for advice; CC the mailing list for the particular subsystem as well
1673 for the subsystem where the issue seems to have its roots; CC the mailing list
1695 Then there are situations where such developers really want to fix an issue,
1728 to prioritize issue reports and reject some of them.