Lines Matching full:that
8 is available under CC-BY-4.0, as versions of this text that were processed
24 you don't find any, install `the latest release from that series
40 If it shows the problem, search for the change that fixed it in mainline and
56 Once the report is out, answer any questions that come up and help where you
57 can. That includes keeping the ball rolling by occasionally retesting with newer
64 developers. It might be all that's needed for people already familiar with
72 a slightly different order. That's in your interest, to make sure you notice
73 early if an issue that looks like a Linux kernel problem is actually caused by
89 issue, or a really severe problem: those are 'issues of high priority' that
90 need special handling in some steps that are about to follow.
92 * Make sure it's not the kernel's surroundings that are causing the issue
102 that made the kernel set this flag might be causing the issue you face.
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,
128 situations; during the merge window that actually might be even the best
129 approach, but in that development phase it can be an even better idea to
144 that hear about it for the first time. And if you learned something in this
148 decoding the kernel log to find the line of code that triggered the error.
158 link to it. Include or upload all other information that might be relevant,
162 that briefly describes the problem and gets people to read on. Now give the
163 thing a descriptive title or subject that yet again is shorter. Then you're
206 that shows the problem and the last version that's working fine. Then
218 kernels regularly rebased on those. If that the case, follow these steps:
220 * Prepare yourself for the possibility that going through the next few steps
227 * Search the Linux kernel version control system for the change that fixed
229 scheduled for backporting already. If you don't find anything that way,
230 search the appropriate mailing lists for posts that discuss such an issue
235 * One of the former steps should lead to a solution. If that doesn't work
236 out, ask the maintainers for the subsystem that seems to be causing the
248 experienced users might wonder how to actually do one of those steps. That's
258 that would require work in various places as well as some infrastructure,
259 which would need constant maintenance; nobody has stepped up to do that
260 work, so that's just how things are for now.
265 development community, and this document. That's why you can't demand
280 With that off the table, find below the details on how to properly report
294 with reports for issues that don't even happen with their current code. It's
297 sides. That's because almost all Linux-based kernels pre-installed on devices
307 face, even if they look small or totally unrelated. That's why you should report
310 upstream or forward the report there. In practice that often does not work out
312 vendor by installing the very latest Linux kernel core yourself. If that's an
314 explain how to do that once it rules out other potential causes for your issue.
320 small modifications to a kernel based on a recent Linux version; that for
324 its only slightly modified; that for example is often the case for Arch Linux,
345 Reporting an issue that someone else already brought forward is often a waste of
360 look at the issue from the perspective of someone else: that will help you to
370 you might be able to provide valuable additional information. That can be
372 developers might look for people that can provide additional information or
377 be a good idea, as that might provide valuable insights or turn up matching
380 need to report your issue". The developers that should take care of the issue
390 issue, or a really severe problem: those are 'issues of high priority' that
391 need special handling in some steps that are about to follow.*
394 fixed as soon as possible, hence there are 'issues of high priority' that get
398 You deal with a 'regression' if something that worked with an older version of
400 It thus is a regression when a WiFi driver that did a fine job with Linux 5.7
406 new kernel needs to be built with a configuration that is similar to the one
407 from the old kernel (see below how to achieve that). That's because the kernel
417 happens. That's for example the case when a Linux kernel corrupts the data it's
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
432 runtime environment. It's hard to rule out that problem completely, but you
439 that's especially important for the main processor, the main memory, and the
443 * Try to make sure it's not faulty hardware that is causing your issue. Bad
444 main memory for example can result in a multitude of issues that will
448 system in question with ``fsck``, as it might be damaged in a way that leads
451 * When dealing with a regression, make sure it's not something else that
453 caused by other software that was updated at the same time. It can also
454 happen that a hardware component coincidentally just broke when you rebooted
456 something in the BIOS Setup can also lead to problems that on look a lot
467 system. That's what you are about to do in this process. Thus, make sure to
481 your kernel gets enhanced in any way. That's why you should remove or disable
487 Note, you might not be aware that your system is using one of these solutions:
489 driver, VirtualBox, or other software that requires a some support from a
490 module not part of the Linux kernel. That why your might need to uninstall the
498 that made the kernel set this flag might be causing the issue you face.*
500 The kernel marks itself with a 'taint' flag when something happens that might
501 lead to follow-up errors that look totally unrelated. The issue you face might
502 be such an error if your kernel is tainted. That's why it's in your interest to
506 then, as that's when it matters because it's the kernel the report will focus
511 everything is fine. Checking that file is impossible in some situations; that's
525 itself, as the kernel knows it might misbehave in strange ways after that
526 point. In that case check your kernel or system log and look for a section
527 that starts with this::
531 That's the first Oops since boot-up, as the '#1' between the brackets shows.
532 Every Oops and any other problem that happens after that point might be a
533 follow-up problem to that first Oops, even if both look totally unrelated.
541 2. Your system uses a software that installs its own kernel modules, for
547 Linux kernel developers. Most of the time the easiest way to do that is:
551 3. The kernel also taints itself when it's loading a module that resides in
552 the staging tree of the Linux kernel source. That's a special area for
553 code (mostly drivers) that does not yet fulfill the normal Linux kernel
567 work independently on a freshly booted system. That's needed, as each issue
581 Note: it's often fruitless to report issues that only happened once, as they
582 might be caused by a bit flip due to cosmic radiation. That's why you should
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
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.
622 That's why you have to find the right place and way to report issues yourself.
623 You can do that with the help of a script (see below), but it mainly targets
630 the WiFi in your Laptop suddenly misbehaves after updating the kernel. In that
632 code it builds upon, but unless you suspect something like that stick to the
637 component that is both universal and easy.
686 that was replaced by a newer solution you need to switch to. Sometimes the code
689 That only leaves these options: arrange yourself to live with the issue, fix it
694 example above does not have such a line. That is the case for most sections, as
713 For people that have the Linux sources at hand there is a second option to find
742 can easily send you in a wrong direction. That for example happens quickly in
744 modified during tree-wide cleanups by developers that do not care about the
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
757 as the reporter. That's why you should search for existing report again, now
758 that you know where they need to be reported to. If it's mailing list, you will
761 But some list are hosted in different places. That for example is the case for
771 the results to the archives at that URL.
791 situations; during the merge window that actually might be even the best
792 approach, but in that development phase it can be an even better idea to
799 reports for issues that don't even happen with the current code. It's just a
800 waste everybody's time, especially yours. That's why it's in everybody's
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
814 It also outlines that using a pre-compiled kernel are fine, but better are
822 want to use for testing. Ignore the big yellow button that says 'Latest release'
825 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
826 kernel for testing, as that where all fixes have to be applied first. Do not let
827 that 'rc' scare you, these 'development kernels' are pretty reliable — and you
831 proper release with a version number like '5.7'. If that happens, consider
833 version (5.8-rc1) shows up on kernel.org. That's because the Linux development
838 also quite possible that one of the many changes applied during the merge
839 window fixes the issue you face; that's why you soon would have to retest with
843 That's why it might make sense to wait till the merge window is over. But don't
844 to that if you're dealing with something that shouldn't wait. In that case
846 latest stable version offered on kernel.org. Using that is also acceptable in
852 must be applied to mainline first. That's why checking the latest mainline
863 it fixed in older version lines, if that's in the cards for the fix in question.
876 few of them you'll find repositories on the net that contain packages with the
884 Please note that you might need to build your own kernel manually later: that's
886 document. Also be aware that pre-compiled kernels might lack debug symbols that
906 those how-to's that suggest to use ``make localmodconfig``, as that tries to
908 somewhat for your system. That does not make the resulting kernel any better,
916 build a kernel by quite a bit. But that's worth it, as these options will allow
917 you later to pinpoint the exact line of code that triggers your issue. The
932 something happens that can lead to follow-up errors that look totally
933 unrelated. That's why you need to check if the kernel you just installed does
935 eliminate the reason for it before you reporting issues that occur with it. See
936 the section above for details how to do that.
948 line and abandoning your plan to report the issue. But keep in mind that other
962 that hear about it for the first time. And if you learned something in this
966 report. Thus try to find a reproducer that's straight forward to describe and
979 decoding the kernel log to find the line of code that triggered the error.*
983 source code that triggered the issue and shows how it was called. But that only
986 kernel's log. That will make it a lot easier to understand what lead to the
987 'panic', 'Oops', 'warning', or 'BUG', which increases the chances that someone
1025 be required to retrieve the relevant details. Don't worry about that, if that's
1035 Linux lead developer Linus Torvalds insists that the Linux kernel never
1036 worsens, that's why he deems regressions as unacceptable and wants to see them
1037 fixed quickly. That's why changes that introduced a regression are often
1040 get something quickly fixed. But for that to happen the change that's causing
1046 'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process
1048 reproduce the issue with each of them before building the next. Yes, that takes
1051 code management system that's causing the regression. Once you find it, search
1059 don't want to go down that route at least find out which mainline kernel
1061 5.5.15 to 5.8.4, then try at least all the mainline releases in that area (5.6,
1064 has three sections (5.6.12, 5.7.8), as that makes the outcome hard to
1090 link to it. Include or upload all other information that might be relevant,
1094 that briefly describes the problem and gets people to read on. Now give the
1095 thing a descriptive title or subject that yet again is shorter. Then you're
1101 Now that you have prepared everything it's time to write your report. How to do
1102 that is partly explained by the three documents linked to in the preface above.
1103 That's why this text will only mention a few of the essentials as well as
1106 There is one thing that fits both categories: the most crucial parts of your
1110 better the top section of your report, the higher are the chances that someone
1111 will look into it and help you. And that is why you should ignore them for now
1119 earlier that outline how you and ideally others can reproduce the issue; in
1120 those rare cases where that's impossible try to describe what you did to
1136 subject and the commit-id of the change that is causing it.
1139 that read your report:
1143 * the kernel's messages that you get from ``dmesg`` written to a file. Make
1144 sure that it starts with a line like 'Linux version 5.8-1
1151 These two files are big, that's why it's a bad idea to put them directly into
1153 the ticket. If you report the issue by mail do not attach them, as that makes
1161 happen if five or ten years from now a developer works on some code that was
1165 replies to your own mail. Just remember to actually do that once the report
1168 Things that might be wise to provide
1182 for example is not, because it might be the one from 2012; that one looks
1183 not that different from the one sold today, but apart from that the two have
1197 * Gather additional information from the kernel that might be of interest. The
1200 make the output from ``sudo lspci -vvv`` available, as that provides
1218 Now that you have the detailed part of the report prepared let's get to the
1221 insert two newlines at the top. Now write one normal length paragraph that
1226 Once you did that insert two more lines at the top and write a one sentence
1227 summary that explains quickly what the report is about. After that you have to
1230 Now that you have written this part take some time to optimize it, as it is the
1236 that case please read the next subsection first before sending the report on
1249 In case you performed a successful bisection, use the title of the change that
1252 make your report mention the latest tested version that's working fine (say 5.7)
1268 If that's not the case simply proceed with reporting the issue as described.
1269 For issues that bear such a risk you will need to adjust the reporting process
1284 you mention that you filed it with a link to the ticket.
1302 tagging it for later backport to stable and longterm kernels that need it. Then
1306 But this ideal scenario rarely happens. That's why the job is only starting
1319 you receive. That includes mails with any additional data you might want to add
1322 list(s) and everyone else that gets involved over time stays in the loop; it
1332 information that needs to be kept private. In that case it's okay to send it
1333 in private to the developer that asked for it. But note in the ticket or a
1334 mail that you did that, so everyone else knows you honored the request.
1337 process someone might tell you to do something that requires a skill you might
1341 a reply asking for instructions how to do that. But before going that route try
1357 here: maintainers should address them as soon as possible; that's why you
1364 ask others for public or private replies how to move on. If that fails, it
1366 driver that would be the wireless maintainers; if there are no higher level
1374 that up to that point participated in the discussion). This will show your
1375 commitment and that you are willing to help. It also tells developers if the
1390 developer of the particular code area that will respond to your report. But as
1391 issues are normally reported in public it could be anyone that's replying —
1392 including people that want to help, but in the end might guide you totally off
1393 track with their questions or requests. That rarely happens, but it's one of
1402 the attention of someone that might help and risk losing it the longer you
1403 wait; that outcome is even likely if you do not provide the information within
1410 proposed patch with a fix was applied, but in fact wasn't. Things like that
1425 get the ball running somehow. If the report got out by mail, do that in the
1426 first lines of a mail that is a reply to your initial mail (see above) which
1427 includes a full quote of the original report below: that's on of those few
1435 confusing that people decided to completely stay away from it? The best way to
1438 to move forward. That might mean: prepare a better report and make those people
1440 mention that this is the second and improved report on the issue and include a
1446 version got published, as you should retest and provide a status update at that
1460 It's also possible that after some discussion in the bug tracker or on a list
1469 You for example could try to find others that are affected and team up with
1471 together that mentions how many you are and why this is something that in your
1473 or the change that introduced a regression, which often makes developing a fix
1474 easier. And with a bit of luck there might be someone in the team that knows a
1494 chosen and gets supported for at least two years (often six). That's why you
1501 (EOL) stamp. Version lines that reached that point still get mentioned on the
1532 vendor applied might be interfering. You need to rule that out by performing
1548 that shows the problem and the last version that's working fine. Then
1551 When reporting a regression that happens within a stable or longterm kernel
1556 as well, because that will speed things up.
1559 that introduced the problem. Hence if possible within a reasonable time frame,
1560 try to find that version using vanilla kernels. Lets assume something broke when
1562 instructed above go and check the latest kernel from that version line, say
1563 5.10.9. If it shows the problem, try a vanilla 5.10.5 to ensure that no patches
1566 first version where things broke. Mention it in the report and state that 5.10.9
1571 pinpoint the exact change that causes the issue (which then can easily get
1590 *Prepare yourself for the possibility that going through the next few steps
1596 are very aware of that and thus only apply changes to these kernels that are
1602 fix you are hoping for might be one of those that won't be backported to the
1603 version line your care about. In that case you'll have no other choice then to
1627 *Search the Linux kernel version control system for the change that fixed
1629 scheduled for backporting already. If you don't find anything that way,
1630 search the appropriate mailing lists for posts that discuss such an issue
1636 got fixed there. The commit that fixed it would need to get backported as well
1637 to get the issue solved. That's why you want to search for it or any
1640 * First try to find the fix in the Git repository that holds the Linux kernel
1648 'stable tag' that looks like this:
1652 If that's case the developer marked the fix safe for backporting to version
1660 section `Locate kernel area that causes the issue` above and follow the
1668 backported to the version line you care about. If that's the case you have
1673 join the discussion: mention the version where you face the issue and that
1680 *One of the former steps should lead to a solution. If that doesn't work
1681 out, ask the maintainers for the subsystem that seems to be causing the
1686 one option left: ask for advice. Do that in a mail you sent to the maintainers
1697 will make sure of that. They and the other kernel developers will fix a lot of
1698 other issues as well. But be aware that sometimes they can't or won't help; and
1701 This is best explained with kernel developers that contribute to the Linux
1716 old that it's something you don't find much outside of computer museums
1724 The situation is not that different with developers that are paid for their
1738 That's true for spare time or the time employers grant their developers to
1753 document and the implications between the lines illustrate that. But that's how