Lines Matching full:issue
25 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
31 issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
36 <https://kernel.org/>`_. If the issue is present there, send a report.
38 The issue was fixed there, but you would like to see it resolved in a still
47 before the issue occurs.
51 issue, like the kernel and the distro used. In case of a regression, CC the
73 early if an issue that looks like a Linux kernel problem is actually caused by
77 * Are you facing an issue with a Linux kernel a hardware or software vendor
79 document and reporting the issue to your vendor instead, unless you are
88 * See if the issue you are dealing with qualifies as regression, security
89 issue, or a really severe problem: those are 'issues of high priority' that
92 * Make sure it's not the kernel's surroundings that are causing the issue
101 * Check if your kernel was 'tainted' when the issue occurred, as the event
102 that made the kernel set this flag might be causing the issue you face.
104 * Write down coarsely how to reproduce the issue. If you deal with multiple
106 work independently on a freshly booted system. That's needed, as each issue
114 * Locate the driver or kernel subsystem that seems to be causing the issue.
120 thoroughly for reports that might match your issue. If you find anything,
137 * Reproduce the issue with the kernel you just installed. If it doesn't show
142 reproduce your issue. Make sure the end result has all the important
145 process, consider searching again for existing reports about the issue.
150 * If your problem is a regression, try to narrow down when the issue was
154 issue. Always mention a few things: the latest kernel version you installed
156 reproduce the issue. Ideally, make the kernel's build configuration
161 outlining the issue and the impact quickly. On top of this add one sentence
197 the issue might have already been fixed there. If you first noticed the
205 issue and ideally explain how to reproduce it. Mention the first version
216 above, but failed to reproduce your issue there; at the same time you want to
217 see the issue fixed in a still supported stable or longterm series or vendor
221 might not get the issue solved in older releases: the fix might be too big
228 the issue in mainline, as its commit message might tell you if the fix is
230 search the appropriate mailing lists for posts that discuss such an issue
237 issue for advice; CC the mailing list for the particular subsystem as well
267 developer handling the issue works for the vendor in question. If you want
269 so, you might want to mention you'd like to see the issue fixed in the
273 * If you never reported an issue to a FLOSS project before you should consider
287 *Are you facing an issue with a Linux kernel a hardware or software vendor
289 document and reporting the issue to your vendor instead, unless you are
304 Linux kernel developers: an issue you face with one of them might have been
306 the modifications and enhancements by the vendor might be causing the issue you
309 report and, in case it turns out to be an upstream issue, fix it directly
314 explain how to do that once it rules out other potential causes for your issue.
319 issue in question. Your chances are quite good if the distributor applied only
333 better than not reporting the issue at all: sometimes such reports directly or
334 indirectly will help to get the issue fixed over time.
345 Reporting an issue that someone else already brought forward is often a waste of
347 interest to thoroughly check if somebody reported the issue already. At this
349 tell you to perform a more detailed search once you know where your issue needs
360 look at the issue from the perspective of someone else: that will help you to
369 In case you find an existing report about your issue, join the discussion, as
380 need to report your issue". The developers that should take care of the issue
382 the issue already got reported as outlined in this document and if not consider
386 Issue of high priority?
389 *See if the issue you are dealing with qualifies as regression, security
390 issue, or a really severe problem: those are 'issues of high priority' that
412 What qualifies as security issue is left to your judgment. Consider reading
416 An issue is a 'really severe problem' when something totally unacceptably bad
419 issue when the kernel suddenly stops working with an error message ('kernel
428 *Make sure it's not the kernel's surroundings that are causing the issue
431 Problems that look a lot like a kernel issue are sometimes caused by build or
441 potential kernel issue.
443 * Try to make sure it's not faulty hardware that is causing your issue. Bad
447 * If you're dealing with a filesystem issue, you might want to check the file
480 The risk your issue report gets ignored or rejected dramatically increases if
497 *Check if your kernel was 'tainted' when the issue occurred, as the event
498 that made the kernel set this flag might be causing the issue you face.*
501 lead to follow-up errors that look totally unrelated. The issue you face might
535 the issue afterwards. Sometimes simply restarting will be enough, sometimes
545 areas and thus might be causing the issue you face. You therefore have to
546 prevent those modules from loading when you want to report an issue to the
554 quality standards. When you report an issue with such a module it's
556 question is the only reason for the taint. If the issue happens in an
562 Document how to reproduce issue
565 *Write down coarsely how to reproduce the issue. If you deal with multiple
567 work independently on a freshly booted system. That's needed, as each issue
577 Additionally, during the reporting process you will have to test if the issue
579 you know exactly how to reproduce an issue quickly on a freshly booted system.
583 try to rule that out by reproducing the issue before going further. Feel free
585 due to faulty hardware apart from a kernel issue that rarely happens and thus
605 Check where you need to report your issue
608 *Locate the driver or kernel subsystem that seems to be causing the issue.
621 file your issue and make it reach the developers that need to know about it.
631 case it's likely an issue in the WiFi driver. Obviously it could also be some
689 That only leaves these options: arrange yourself to live with the issue, fix it
693 you where to find a subsystem specific bug tracker to file your issue. The
703 issue reports sent by email, make sure to add the Linux Kernel Mailing List
705 lists when sending your issue report by mail later! Maintainers are busy people
707 and LKML is important to have one place where all issue reports can be found.
752 thoroughly for reports that might match your issue. If you find anything,
755 As mentioned earlier already: reporting an issue that someone else already
801 interest that you confirm the issue still exists with the latest upstream code
803 earlier: doing so dramatically increases the risk that your issue report might
837 quite busy then and might have no spare time to deal with issue reports. It's
839 window fixes the issue you face; that's why you soon would have to retest with
848 using it for reproducing the issue is also better than not reporting it issue
853 kernel is so important: any issue you want to see fixed in older version lines
856 hard or risky for backporting; reporting the issue again hence is unlikely to
862 further: if the issue doesn't occur with mainline it will guide you how to get
872 unsuitable for testing and issue reporting: the changes might cause the issue
917 you later to pinpoint the exact line of code that triggers your issue. The
920 But keep in mind: Always keep a record of the issue encountered in case it is
922 the issue at all.
939 Reproduce issue with the fresh kernel
942 *Reproduce the issue with the kernel you just installed. If it doesn't show
946 Check if the issue occurs with the fresh Linux kernel version you just
948 line and abandoning your plan to report the issue. But keep in mind that other
956 Optimize description to reproduce issue
960 reproduce your issue. Make sure the end result has all the important
963 process, consider searching again for existing reports about the issue.*
971 issue you face. Use this knowledge and search again for existing reports
983 source code that triggered the issue and shows how it was called. But that only
1032 *If your problem is a regression, try to narrow down when the issue was
1038 promptly reverted if the issue they cause can't get solved quickly any other
1048 reproduce the issue with each of them before building the next. Yes, that takes
1067 process. But keep in mind: it depends on the issue at hand if the developers
1072 When dealing with regressions make sure the issue you face is really caused by
1075 In the whole process keep in mind: an issue only qualifies as regression if the
1086 issue. Always mention a few things: the latest kernel version you installed
1088 reproduce the issue. Ideally, make the kernel's build configuration
1093 outlining the issue and the impact quickly. On top of this add one sentence
1117 Describe in detail how your issue happens with the fresh vanilla kernel you
1119 earlier that outline how you and ideally others can reproduce the issue; in
1124 issue and its environment. What's actually needed depends a lot on the issue,
1149 issue and call ``dmesg`` right afterwards.
1152 your report. If you are filing the issue in a bug tracker then attach them to
1153 the ticket. If you report the issue by mail do not attach them, as that makes
1162 changed just to fix your issue.
1171 Depending on the issue you might need to add more background data. Here are a
1178 * If the issue might be related to your computer hardware, mention what kind
1194 its driver. If you have a filesystem issue, mention the version of
1222 describes the issue roughly. Leave out all boring details and focus on the
1253 and the oldest where the issue occurs (say 5.8-rc1).
1268 If that's not the case simply proceed with reporting the issue as described.
1272 * If the MAINTAINERS file instructed you to report the issue by mail, do not
1275 * If you were supposed to file the issue in a bug tracker make sure to mark
1276 the ticket as 'private' or 'security issue'. If the bug tracker does not
1300 might immediately spot what's causing the issue; they then might write a patch
1316 **Always reply in public**: When you filed the issue in a bug tracker, always
1362 times there might be disagreements, for example if an issue qualifies as
1371 mainline kernel version gets released, go and check if the issue is fixed there
1376 issue persists and makes sure they do not forget about it. A few other
1398 issue.
1418 developers; or a discussion around the issue evolved, but faded out with
1437 issue reporting and ask for their opinion. Also ask them for their advice how
1440 mention that this is the second and improved report on the issue and include a
1454 react somehow to every issue report, but they are only obliged to fix those
1467 Don't get devastated if you don't find any help or if the issue in the end does
1470 them to get the issue resolved. Such a team could prepare a fresh report
1510 Maybe the issue you face is already known and was fixed or is about to. Hence,
1512 <https://lore.kernel.org/stable/>`_ for reports about an issue like yours. If
1516 Reproduce issue with the newest release
1521 the issue might have already been fixed there. If you first noticed the
1525 Before investing any more time in this process you want to check if the issue
1527 This kernel needs to be vanilla and shouldn't be tainted before the issue
1536 well. If things are broken there, the issue does not qualify as upstream
1538 the issue.
1547 issue and ideally explain how to reproduce it. Mention the first version
1553 the start to get the issue reported quickly. Hence a rough description to the
1564 the distributor applied interfere. If the issue doesn't manifest itself there,
1571 pinpoint the exact change that causes the issue (which then can easily get
1572 reverted to fix the issue quickly). Hence consider to do a proper bisection
1584 reproduce your issue with a mainline kernel, but want to see it fixed in older
1591 might not get the issue solved in older releases: the fix might be too big
1604 live with the issue or switch to a newer Linux version, unless you want to
1628 the issue in mainline, as its commit message might tell you if the fix is
1630 search the appropriate mailing lists for posts that discuss such an issue
1635 In a lot of cases the issue you deal with will have happened with mainline, but
1637 to get the issue solved. That's why you want to search for it or any
1657 again for discussions about the issue. Search the net with your favorite
1660 section `Locate kernel area that causes the issue` above and follow the
1669 to live with the issue or switch to the kernel version line where the fix
1673 join the discussion: mention the version where you face the issue and that
1682 issue for advice; CC the mailing list for the particular subsystem as well
1687 for the subsystem where the issue seems to have its roots; CC the mailing list
1709 Then there are situations where such developers really want to fix an issue,
1742 to prioritize issue reports and reject some of them.