Lines Matching refs:you
11 Are you facing a regression with vanilla kernels from the same stable or
15 you don't find any, install `the latest release from that series
25 search the `LKML <https://lore.kernel.org/lkml/>`_ and the web, too. If you
29 The issue was fixed there, but you would like to see it resolved in a still
40 If you are facing multiple issues with the Linux kernel at once, report each
44 to pin-point the culprit with a bisection; if you succeed, include its
47 Once the report is out, answer any questions that come up and help where you
63 a slightly different order. That's in your interest, to make sure you notice
65 something else. These steps thus help to ensure the time you invest in this
68 * Are you facing an issue with a Linux kernel a hardware or software vendor
69 provided? Then in almost all cases you are better off to stop reading this
70 document and reporting the issue to your vendor instead, unless you are
76 List (LKML) <https://lore.kernel.org/lkml/>`_. If you find matching reports,
79 * See if the issue you are dealing with qualifies as regression, security
84 you face.
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
101 * If you are facing a regression within a stable or longterm version line
111 thoroughly for reports that might match your issue. If you find anything,
114 After these preparations you'll now enter the main part:
116 * Unless you are already running the latest 'mainline' Linux kernel, better
121 suspend your efforts for a few days anyway. Whatever version you choose,
125 * Ensure the kernel you just installed does not 'taint' itself when
128 * Reproduce the issue with the kernel you just installed. If it doesn't show
135 that hear about it for the first time. And if you learned something in this
145 issue. Always mention a few things: the latest kernel version you installed
151 you wrote this main part, insert a normal length paragraph on top of it
154 thing a descriptive title or subject that yet again is shorter. Then you're
155 ready to send or file the report like the MAINTAINERS file told you, unless
156 you are dealing with one of those 'issues of high priority': they need
160 * Wait for reactions and keep the thing rolling until you can accept the
165 help yourself, if you don't get any help or if it's unsatisfying.
171 This subsection is for you, if you followed above process and got sent here at
179 line you care about: go to the `front page of kernel.org
188 the issue might have already been fixed there. If you first noticed the
194 (regressions@lists.linux.dev); if you suspect the cause in a particular
206 This subsection is for you, if you tried the latest mainline kernel as outlined
207 above, but failed to reproduce your issue there; at the same time you want to
219 the issue in mainline, as its commit message might tell you if the fix is
220 scheduled for backporting already. If you don't find anything that way,
253 * A warranty or support contract with some vendor doesn't entitle you to
256 development community, and this document. That's why you can't demand
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
275 Make sure you're using the upstream Linux kernel
278 *Are you facing an issue with a Linux kernel a hardware or software vendor
279 provided? Then in almost all cases you are better off to stop reading this
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
298 face, even if they look small or totally unrelated. That's why you should report
302 or might not what you want. You thus might want to consider circumventing the
304 option for you move ahead in this process, as a later step in this guide will
316 regular Fedora releases, and openSUSE Tumbleweed. But keep in mind, you better
321 Obviously you are free to ignore all this advice and report problems with an old
333 List (LKML). If you find matching reports, join the discussion instead of
337 time for everyone involved, especially you as the reporter. So it's in your own
340 tell you to perform a more detailed search once you know where your issue needs
342 process, it can save you time and trouble.
348 If you get flooded with results consider telling your search engine to limit
349 search timeframe to the past month or year. And wherever you search, make sure
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
361 you might be able to provide valuable additional information. That can be
369 reports. If you find the latter, just keep in mind: most subsystems expect
370 reports in different places, as described below in the section "Check where you
380 *See if the issue you are dealing with qualifies as regression, security
393 detail. It also provides a good deal of other information about regressions you
414 you face.*
417 runtime environment. It's hard to rule out that problem completely, but you
432 * If you're dealing with a filesystem issue, you might want to check the file
439 happen that a hardware component coincidentally just broke when you rebooted
450 Reminder, you are dealing with computers, which sometimes do unexpected things,
451 especially if you fiddle with crucial parts like the kernel of its operating
452 system. That's what you are about to do in this process. Thus, make sure to
453 create a fresh backup; also ensure you have all tools at hand to repair or
454 reinstall the operating system as well as everything you need to restore the
466 your kernel gets enhanced in any way. That's why you should remove or disable
468 automatically, for example when you install a new Linux kernel or boot it for
472 Note, you might not be aware that your system is using one of these solutions:
473 they often get set up silently when you install Nvidia's proprietary graphics
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
489 only reason why this step is here, as this process later will tell you to
490 install the latest mainline kernel; you will need to check the taint flag again
502 not tainted when it noticed the problem; it was tainted if you see 'Tainted:'
524 version you are going to install later in this process.
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
550 *Write down coarsely how to reproduce the issue. If you deal with multiple
556 If you deal with multiple issues at once, you'll have to report each of them
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.
567 might be caused by a bit flip due to cosmic radiation. That's why you should
569 to ignore this advice if you are experienced enough to tell a one-time error
577 *If you are facing a regression within a stable or longterm version line
590 Check where you need to report your issue
605 Problem is: the Linux kernel lacks a central bug tracker where you can simply
607 That's why you have to find the right place and way to report issues yourself.
617 code it builds upon, but unless you suspect something like that stick to the
624 In case of a problem with the WiFi driver you for example might want to look at
637 other internal bus. In those cases you might want to check your WiFi manager or
645 In case tricks like these don't bring you any further, try to search the
646 internet on how to narrow down the driver or subsystem in question. And if you
647 are unsure which it is: just try your best guess, somebody will help you if you
650 Once you know the driver or subsystem, you want to search for it in the
651 MAINTAINERS file. In the case of 'ath10k_pci' you won't find anything, as the
652 name is too specific. Sometimes you will need to search on the net for help;
654 MAINTAINERS file, as then you might find something like this::
664 Note: the line description will be abbreviations, if you read the plain
670 'Maintained'. If it states 'Obsolete' then you are using some outdated approach
671 that was replaced by a newer solution you need to switch to. Sometimes the code
673 'Orphan' you are totally out of luck, as nobody takes care of the code anymore.
678 you where to find a subsystem specific bug tracker to file your issue. The
683 In this and many other cases you thus have to look for lines starting with
686 list:', which tells you the public mailing list where the code is developed.
719 the code as well as the Linux Kernel Mailing List (LKML). In this case you thus
723 Note: in case you cloned the Linux sources with git you might want to call
727 can easily send you in a wrong direction. That for example happens quickly in
737 thoroughly for reports that might match your issue. If you find anything,
741 brought forward is often a waste of time for everyone involved, especially you
742 as the reporter. That's why you should search for existing report again, now
743 that you know where they need to be reported to. If it's mailing list, you will
747 the ath10k WiFi driver used as example in the previous step. But you'll often
749 ath10k@lists.infradead.org' for example will lead you to the `Info page for the
759 at this point. If your report needs to be filed in a bug tracker, you may want
763 For details how to search and what to do if you find matching reports see
767 or even more time can save you and others quite a lot of time and trouble.
773 *Unless you are already running the latest 'mainline' Linux kernel, better
778 suspend your efforts for a few days anyway. Whatever version you choose,
786 interest that you confirm the issue still exists with the latest upstream code
806 Head over to `kernel.org <https://kernel.org/>`_ to find out which version you
808 and look a little lower at the table. At its top you'll see a line starting with
810 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
812 that 'rc' scare you, these 'development kernels' are pretty reliable — and you
813 made a backup, as you were instructed above, didn't you?
815 In about two out of every nine to ten weeks, mainline might point you to a
824 window fixes the issue you face; that's why you soon would have to retest with
829 to that if you're dealing with something that shouldn't wait. In that case
832 case mainline for some reason does currently not work for you. An in general:
838 kernel is so important: any issue you want to see fixed in older version lines
840 take a few days or weeks. Another reason: the fix you hope for might be too
847 further: if the issue doesn't occur with mainline it will guide you how to get
854 way for testing — especially is you are unfamiliar with the Linux kernel. The
858 you face or influence it somehow.
860 But you are in luck if you are using a popular Linux distribution: for quite a
861 few of them you'll find repositories on the net that contain packages with the
869 Please note that you might need to build your own kernel manually later: that's
873 BUG occurs; if you plan to decode those, you might be better off compiling a
890 the necessary steps already. If you are new to it, consider following one of
896 Note: If you are dealing with a panic, Oops, warning, or BUG from the kernel,
899 latter is the relevant one of those two, but can only be reached if you enable
902 you later to pinpoint the exact line of code that triggers your issue. The
913 *Ensure the kernel you just installed does not 'taint' itself when
918 unrelated. That's why you need to check if the kernel you just installed does
919 not set this flag. And if it does, you in almost all the cases needs to
920 eliminate the reason for it before you reporting issues that occur with it. See
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
936 those). If you prefer to use one of those or just want to help their users,
947 that hear about it for the first time. And if you learned something in this
955 In this in the previous steps you likely have learned a thing or two about the
956 issue you face. Use this knowledge and search again for existing reports
957 instead you can join.
969 works if you enabled CONFIG_DEBUG_INFO and CONFIG_KALLSYMS when configuring
970 your kernel. If you did so, consider to decode the information from the
975 Decoding can be done with a script you find in the Linux source tree. If you
976 are running a kernel you compiled yourself earlier, call it like this::
980 If you are running a packaged vanilla kernel, you will likely have to install
981 the corresponding packages with debug symbols. Then call the script (which you
1006 Note, if you can't get this to work, simply skip this step and mention the
1007 reason for it in the report. If you're lucky, it might not be needed. And if it
1008 is, someone might help you to get things going. Also be aware this is just one
1011 needed in your case, developers will tell you what to do.
1032 will often require you to build about ten to twenty kernel images, trying to
1035 Thanks to a 'binary search' this will lead you to the one commit in the source
1036 code management system that's causing the regression. Once you find it, search
1038 (the first 12 characters of the commit id). This will lead you to existing
1043 highly recommended performing a bisection yourself. If you really can't or
1047 5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
1050 interpret, which might render your testing useless. Once you found the major
1055 be unable to help unless you perform a bisection.
1057 When dealing with regressions make sure the issue you face is really caused by
1064 provides a good deal of other information about regressions you might want to be
1072 issue. Always mention a few things: the latest kernel version you installed
1078 you wrote this main part, insert a normal length paragraph on top of it
1081 thing a descriptive title or subject that yet again is shorter. Then you're
1082 ready to send or file the report like the MAINTAINERS file told you, unless
1083 you are dealing with one of those 'issues of high priority': they need
1087 Now that you have prepared everything it's time to write your report. How to do
1097 will look into it and help you. And that is why you should ignore them for now
1103 Describe in detail how your issue happens with the fresh vanilla kernel you
1104 installed. Try to include the step-by-step instructions you wrote and optimized
1105 earlier that outline how you and ideally others can reproduce the issue; in
1106 those rare cases where that's impossible try to describe what you did to
1111 but there are some things you should include always:
1121 * if you are dealing with a regression and performed a bisection, mention the
1129 * the kernel's messages that you get from ``dmesg`` written to a file. Make
1134 ``journalctl -b 0 -k``; alternatively you can also reboot, reproduce the
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
1150 * Put the files aside and mention you will send them later in individual
1157 Depending on the issue you might need to add more background data. Here are a
1160 * If you are dealing with a 'warning', an 'OOPS' or a 'panic' from the kernel,
1161 include it. If you can't copy'n'paste it, try to capture a netconsole trace
1165 of system you use. If you for example have problems with your graphics card,
1176 * Mention the relevant software in use. If you have problems with loading
1177 modules, you want to mention the versions of kmod, systemd, and udev in use.
1178 If one of the DRM drivers misbehaves, you want to state the versions of
1180 its driver. If you have a filesystem issue, mention the version of
1185 hardware you use. If you have a problem with hardware you even might want to
1195 attach, but you have to think yourself what will be helpful for others to know.
1204 Now that you have the detailed part of the report prepared let's get to the
1206 something like 'The detailed description:' before the part you just wrote and
1209 crucial parts readers need to know to understand what this is all about; if you
1212 Once you did that insert two more lines at the top and write a one sentence
1213 summary that explains quickly what the report is about. After that you have to
1216 Now that you have written this part take some time to optimize it, as it is the
1221 you, unless it's one of those 'issues of high priority' outlined earlier: in
1235 In case you performed a successful bisection, use the title of the change that
1246 Also add a short note at the top where you mention the URL to the ticket.
1250 chain, which you find at the end of its commit message.
1255 For issues that bear such a risk you will need to adjust the reporting process
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
1268 them when sending the report by mail. If you filed it in a bug tracker, forward
1270 you mention that you filed it with a link to the ticket.
1278 *Wait for reactions and keep the thing rolling until you can accept the
1283 help yourself, if you don't get any help or if it's unsatisfying.*
1285 If your report was good and you are really lucky then one of the developers
1289 all you need to do is reply with a 'Thank you very much' and switch to a version
1293 once you got the report out. What you'll have to do depends on the situations,
1295 details, here are a few important things you need to keep in mind for this part
1302 **Always reply in public**: When you filed the issue in a bug tracker, always
1305 you receive. That includes mails with any additional data you might want to add
1315 * Someone tells you to send something privately.
1320 mail that you did that, so everyone else knows you honored the request.
1323 process someone might tell you to do something that requires a skill you might
1324 not have mastered yet. For example, you might be asked to use some test tools
1325 you never have heard of yet; or you might be asked to apply a patch to the
1330 about it to a chatroom or forum you normally hang out.
1332 **Be patient**: If you are really lucky you might get a reply to your report
1343 here: maintainers should address them as soon as possible; that's why you
1359 mail you sent as reply to your report (make sure it has all those in the CC
1361 commitment and that you are willing to help. It also tells developers if the
1364 idea, but only report your results if something relevant changed or if you are
1373 Here are your duties in case you got replies to your report:
1375 **Check who you deal with**: Most of the time it will be the maintainer or a
1378 including people that want to help, but in the end might guide you totally off
1380 many reasons why it's wise to quickly run an internet search to see who you're
1381 interacting with. By doing this you also get aware if your report was heard by
1386 **Inquiries for data**: Often you will be asked to test something or provide
1387 additional details. Try to provide the requested information soon, as you have
1388 the attention of someone that might help and risk losing it the longer you
1389 wait; that outcome is even likely if you do not provide the information within
1392 **Requests for testing**: When you are asked to test a diagnostic patch or a
1418 After the reminder wait three more weeks for replies. If you still don't get a
1419 proper reaction, you first should reconsider your approach. Did you maybe try
1425 review it before you send it out. Such an approach is totally fine; just
1429 If the report was proper you can send a second reminder; in it ask for advice
1432 version got published, as you should retest and provide a status update at that
1441 'issues of high priority' outlined earlier. So don't be too devastating if you
1453 Don't get devastated if you don't find any help or if the issue in the end does
1454 not get solved: the Linux kernel is FLOSS and thus you can still help yourself.
1457 together that mentions how many you are and why this is something that in your
1458 option should get fixed. Maybe together you can also narrow down the root cause
1467 This subsection provides details for the steps you need to perform if you face
1474 line you care about: go to the front page of kernel.org and make sure it
1480 chosen and gets supported for at least two years (often six). That's why you
1481 need to check if the kernel developers still support the version line you care
1484 Note, if kernel.org lists two stable version lines on the front page, you
1496 Maybe the issue you face is already known and was fixed or is about to. Hence,
1499 you find any matches, consider joining the discussion, unless the fix is
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
1512 was already fixed in the latest release of version line you're interested in.
1517 Did you first notice the regression with a vendor kernel? Then changes the
1519 a recheck. Say something broke when you updated from 5.10.4-vendor.42 to
1523 regression and you need switch back to the main step-by-step guide to report
1531 (regressions@lists.linux.dev); if you suspect the cause in a particular
1540 stable and regressions mailing list is all it takes; but in case you suspect
1544 And note, it helps developers a great deal if you can specify the exact version
1562 the recipients; also CC everyone in the signed-off-by chain, which you find at
1569 This section provides details for the steps you need to take if you could not
1588 fix you are hoping for might be one of those that won't be backported to the
1589 version line your care about. In that case you'll have no other choice then to
1590 live with the issue or switch to a newer Linux version, unless you want to
1600 guide. Those steps will let you:
1603 you care about.
1614 the issue in mainline, as its commit message might tell you if the fix is
1615 scheduled for backporting already. If you don't find anything that way,
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
1629 or its mirror `on GitHub <https://github.com/torvalds/linux>`_; if you have
1630 a local clone you alternatively can search on the command line with ``git
1633 If you find the fix, look if the commit message near the end contains a
1642 * If the commit doesn't tell you anything or if you can't find the fix, look
1648 list archive might have the answer you are looking for.
1650 * If you see a proposed fix, search for it in the version control system as
1651 outlined above, as the commit might tell you if a backport can be expected.
1654 backported to the version line you care about. If that's the case you have
1659 join the discussion: mention the version where you face the issue and that
1660 you would like to see it fixed, if suitable.
1671 If the previous three steps didn't get you closer to a solution there is only
1672 one option left: ask for advice. Do that in a mail you sent to the maintainers
1702 old that it's something you don't find much outside of computer museums
1748 you spot a typo or small mistake, feel free to let him know directly and
1749 he'll fix it. You are free to do the same in a mostly informal way if you
1756 of the file. If you want to distribute this text under CC-BY-4.0 only,