Lines Matching full:that
15 you don't find any, install `the latest release from that series
31 If it shows the problem, search for the change that fixed it in mainline and
47 Once the report is out, answer any questions that come up and help where you
48 can. That includes keeping the ball rolling by occasionally retesting with newer
55 developers. It might be all that's needed for people already familiar with
63 a slightly different order. That's in your interest, to make sure you notice
64 early if an issue that looks like a Linux kernel problem is actually caused by
80 issue, or a really severe problem: those are 'issues of high priority' that
81 need special handling in some steps that are about to follow.
83 * Make sure it's not the kernel's surroundings that are causing the issue
93 that made the kernel set this flag might be causing the issue you face.
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,
119 situations; during the merge window that actually might be even the best
120 approach, but in that development phase it can be an even better idea to
135 that hear about it for the first time. And if you learned something in this
139 decoding the kernel log to find the line of code that triggered the error.
149 link to it. Include or upload all other information that might be relevant,
153 that briefly describes the problem and gets people to read on. Now give the
154 thing a descriptive title or subject that yet again is shorter. Then you're
197 that shows the problem and the last version that's working fine. Then
209 kernels regularly rebased on those. If that the case, follow these steps:
211 * Prepare yourself for the possibility that going through the next few steps
218 * Search the Linux kernel version control system for the change that fixed
220 scheduled for backporting already. If you don't find anything that way,
221 search the appropriate mailing lists for posts that discuss such an issue
226 * One of the former steps should lead to a solution. If that doesn't work
227 out, ask the maintainers for the subsystem that seems to be causing the
239 experienced users might wonder how to actually do one of those steps. That's
249 that would require work in various places as well as some infrastructure,
250 which would need constant maintenance; nobody has stepped up to do that
251 work, so that's just how things are for now.
256 development community, and this document. That's why you can't demand
271 With that off the table, find below the details on how to properly report
285 with reports for issues that don't even happen with their current code. It's
288 sides. That's because almost all Linux-based kernels pre-installed on devices
298 face, even if they look small or totally unrelated. That's why you should report
301 upstream or forward the report there. In practice that often does not work out
303 vendor by installing the very latest Linux kernel core yourself. If that's an
305 explain how to do that once it rules out other potential causes for your issue.
311 small modifications to a kernel based on a recent Linux version; that for
315 its only slightly modified; that for example is often the case for Arch Linux,
336 Reporting an issue that someone else already brought forward is often a waste of
351 look at the issue from the perspective of someone else: that will help you to
361 you might be able to provide valuable additional information. That can be
363 developers might look for people that can provide additional information or
368 be a good idea, as that might provide valuable insights or turn up matching
371 need to report your issue". The developers that should take care of the issue
381 issue, or a really severe problem: those are 'issues of high priority' that
382 need special handling in some steps that are about to follow.*
385 fixed as soon as possible, hence there are 'issues of high priority' that get
402 happens. That's for example the case when a Linux kernel corrupts the data it's
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
417 runtime environment. It's hard to rule out that problem completely, but you
424 that's especially important for the main processor, the main memory, and the
428 * Try to make sure it's not faulty hardware that is causing your issue. Bad
429 main memory for example can result in a multitude of issues that will
433 system in question with ``fsck``, as it might be damaged in a way that leads
436 * When dealing with a regression, make sure it's not something else that
438 caused by other software that was updated at the same time. It can also
439 happen that a hardware component coincidentally just broke when you rebooted
441 something in the BIOS Setup can also lead to problems that on look a lot
452 system. That's what you are about to do in this process. Thus, make sure to
466 your kernel gets enhanced in any way. That's why you should remove or disable
472 Note, you might not be aware that your system is using one of these solutions:
474 driver, VirtualBox, or other software that requires a some support from a
475 module not part of the Linux kernel. That why your might need to uninstall the
483 that made the kernel set this flag might be causing the issue you face.*
485 The kernel marks itself with a 'taint' flag when something happens that might
486 lead to follow-up errors that look totally unrelated. The issue you face might
487 be such an error if your kernel is tainted. That's why it's in your interest to
491 then, as that's when it matters because it's the kernel the report will focus
496 everything is fine. Checking that file is impossible in some situations; that's
510 itself, as the kernel knows it might misbehave in strange ways after that
511 point. In that case check your kernel or system log and look for a section
512 that starts with this::
516 That's the first Oops since boot-up, as the '#1' between the brackets shows.
517 Every Oops and any other problem that happens after that point might be a
518 follow-up problem to that first Oops, even if both look totally unrelated.
526 2. Your system uses a software that installs its own kernel modules, for
532 Linux kernel developers. Most of the time the easiest way to do that is:
536 3. The kernel also taints itself when it's loading a module that resides in
537 the staging tree of the Linux kernel source. That's a special area for
538 code (mostly drivers) that does not yet fulfill the normal Linux kernel
552 work independently on a freshly booted system. That's needed, as each issue
566 Note: it's often fruitless to report issues that only happened once, as they
567 might be caused by a bit flip due to cosmic radiation. That's why you should
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
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.
607 That's why you have to find the right place and way to report issues yourself.
608 You can do that with the help of a script (see below), but it mainly targets
615 the WiFi in your Laptop suddenly misbehaves after updating the kernel. In that
617 code it builds upon, but unless you suspect something like that stick to the
622 component that is both universal and easy.
671 that was replaced by a newer solution you need to switch to. Sometimes the code
674 That only leaves these options: arrange yourself to live with the issue, fix it
679 example above does not have such a line. That is the case for most sections, as
698 For people that have the Linux sources at hand there is a second option to find
727 can easily send you in a wrong direction. That for example happens quickly in
729 modified during tree-wide cleanups by developers that do not care about the
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
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
746 But some list are hosted in different places. That for example is the case for
756 the results to the archives at that URL.
776 situations; during the merge window that actually might be even the best
777 approach, but in that development phase it can be an even better idea to
784 reports for issues that don't even happen with the current code. It's just a
785 waste everybody's time, especially yours. That's why it's in everybody's
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
799 It also outlines that using a pre-compiled kernel are fine, but better are
807 want to use for testing. Ignore the big yellow button that says 'Latest release'
810 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
811 kernel for testing, as that where all fixes have to be applied first. Do not let
812 that 'rc' scare you, these 'development kernels' are pretty reliable — and you
816 proper release with a version number like '5.7'. If that happens, consider
818 version (5.8-rc1) shows up on kernel.org. That's because the Linux development
823 also quite possible that one of the many changes applied during the merge
824 window fixes the issue you face; that's why you soon would have to retest with
828 That's why it might make sense to wait till the merge window is over. But don't
829 to that if you're dealing with something that shouldn't wait. In that case
831 latest stable version offered on kernel.org. Using that is also acceptable in
837 must be applied to mainline first. That's why checking the latest mainline
848 it fixed in older version lines, if that's in the cards for the fix in question.
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
871 document. Also be aware that pre-compiled kernels might lack debug symbols that
891 those how-to's that suggest to use ``make localmodconfig``, as that tries to
893 somewhat for your system. That does not make the resulting kernel any better,
901 build a kernel by quite a bit. But that's worth it, as these options will allow
902 you later to pinpoint the exact line of code that triggers your issue. The
917 something happens that can lead to follow-up errors that look totally
918 unrelated. That's why you need to check if the kernel you just installed does
920 eliminate the reason for it before you reporting issues that occur with it. See
921 the section above for details how to do that.
933 line and abandoning your plan to report the issue. But keep in mind that other
947 that hear about it for the first time. And if you learned something in this
951 report. Thus try to find a reproducer that's straight forward to describe and
964 decoding the kernel log to find the line of code that triggered the error.*
968 source code that triggered the issue and shows how it was called. But that only
971 kernel's log. That will make it a lot easier to understand what lead to the
972 'panic', 'Oops', 'warning', or 'BUG', which increases the chances that someone
1010 be required to retrieve the relevant details. Don't worry about that, if that's
1020 Linux lead developer Linus Torvalds insists that the Linux kernel never
1021 worsens, that's why he deems regressions as unacceptable and wants to see them
1022 fixed quickly. That's why changes that introduced a regression are often
1025 get something quickly fixed. But for that to happen the change that's causing
1031 Documentation/admin-guide/bug-bisect.rst describes in detail. That process
1033 reproduce the issue with each of them before building the next. Yes, that takes
1036 code management system that's causing the regression. Once you find it, search
1044 don't want to go down that route at least find out which mainline kernel
1046 5.5.15 to 5.8.4, then try at least all the mainline releases in that area (5.6,
1049 has three sections (5.6.12, 5.7.8), as that makes the outcome hard to
1063 Documentation/admin-guide/reporting-regressions.rst; that document also
1076 link to it. Include or upload all other information that might be relevant,
1080 that briefly describes the problem and gets people to read on. Now give the
1081 thing a descriptive title or subject that yet again is shorter. Then you're
1087 Now that you have prepared everything it's time to write your report. How to do
1088 that is partly explained by the three documents linked to in the preface above.
1089 That's why this text will only mention a few of the essentials as well as
1092 There is one thing that fits both categories: the most crucial parts of your
1096 better the top section of your report, the higher are the chances that someone
1097 will look into it and help you. And that is why you should ignore them for now
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
1122 subject and the commit-id of the change that is causing it.
1125 that read your report:
1129 * the kernel's messages that you get from ``dmesg`` written to a file. Make
1130 sure that it starts with a line like 'Linux version 5.8-1
1137 These two files are big, that's why it's a bad idea to put them directly into
1139 the ticket. If you report the issue by mail do not attach them, as that makes
1147 happen if five or ten years from now a developer works on some code that was
1151 replies to your own mail. Just remember to actually do that once the report
1154 Things that might be wise to provide
1168 for example is not, because it might be the one from 2012; that one looks
1169 not that different from the one sold today, but apart from that the two have
1183 * Gather additional information from the kernel that might be of interest. The
1186 make the output from ``sudo lspci -vvv`` available, as that provides
1204 Now that you have the detailed part of the report prepared let's get to the
1207 insert two newlines at the top. Now write one normal length paragraph that
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
1222 that case please read the next subsection first before sending the report on
1235 In case you performed a successful bisection, use the title of the change that
1238 make your report mention the latest tested version that's working fine (say 5.7)
1254 If that's not the case simply proceed with reporting the issue as described.
1255 For issues that bear such a risk you will need to adjust the reporting process
1270 you mention that you filed it with a link to the ticket.
1288 tagging it for later backport to stable and longterm kernels that need it. Then
1292 But this ideal scenario rarely happens. That's why the job is only starting
1305 you receive. That includes mails with any additional data you might want to add
1308 list(s) and everyone else that gets involved over time stays in the loop; it
1318 information that needs to be kept private. In that case it's okay to send it
1319 in private to the developer that asked for it. But note in the ticket or a
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
1327 a reply asking for instructions how to do that. But before going that route try
1343 here: maintainers should address them as soon as possible; that's why you
1350 ask others for public or private replies how to move on. If that fails, it
1352 driver that would be the wireless maintainers; if there are no higher level
1360 that up to that point participated in the discussion). This will show your
1361 commitment and that you are willing to help. It also tells developers if the
1376 developer of the particular code area that will respond to your report. But as
1377 issues are normally reported in public it could be anyone that's replying —
1378 including people that want to help, but in the end might guide you totally off
1379 track with their questions or requests. That rarely happens, but it's one of
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
1396 proposed patch with a fix was applied, but in fact wasn't. Things like that
1411 get the ball running somehow. If the report got out by mail, do that in the
1412 first lines of a mail that is a reply to your initial mail (see above) which
1413 includes a full quote of the original report below: that's on of those few
1421 confusing that people decided to completely stay away from it? The best way to
1424 to move forward. That might mean: prepare a better report and make those people
1426 mention that this is the second and improved report on the issue and include a
1432 version got published, as you should retest and provide a status update at that
1446 It's also possible that after some discussion in the bug tracker or on a list
1455 You for example could try to find others that are affected and team up with
1457 together that mentions how many you are and why this is something that in your
1459 or the change that introduced a regression, which often makes developing a fix
1460 easier. And with a bit of luck there might be someone in the team that knows a
1480 chosen and gets supported for at least two years (often six). That's why you
1487 (EOL) stamp. Version lines that reached that point still get mentioned on the
1518 vendor applied might be interfering. You need to rule that out by performing
1534 that shows the problem and the last version that's working fine. Then
1537 When reporting a regression that happens within a stable or longterm kernel
1542 as well, because that will speed things up.
1545 that introduced the problem. Hence if possible within a reasonable time frame,
1546 try to find that version using vanilla kernels. Lets assume something broke when
1548 instructed above go and check the latest kernel from that version line, say
1549 5.10.9. If it shows the problem, try a vanilla 5.10.5 to ensure that no patches
1552 first version where things broke. Mention it in the report and state that 5.10.9
1557 pinpoint the exact change that causes the issue (which then can easily get
1576 *Prepare yourself for the possibility that going through the next few steps
1582 are very aware of that and thus only apply changes to these kernels that are
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
1613 *Search the Linux kernel version control system for the change that fixed
1615 scheduled for backporting already. If you don't find anything that way,
1616 search the appropriate mailing lists for posts that discuss such an issue
1622 got fixed there. The commit that fixed it would need to get backported as well
1623 to get the issue solved. That's why you want to search for it or any
1626 * First try to find the fix in the Git repository that holds the Linux kernel
1634 'stable tag' that looks like this:
1638 If that's case the developer marked the fix safe for backporting to version
1646 section `Locate kernel area that causes the issue` above and follow the
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
1666 *One of the former steps should lead to a solution. If that doesn't work
1667 out, ask the maintainers for the subsystem that seems to be causing the
1672 one option left: ask for advice. Do that in a mail you sent to the maintainers
1683 will make sure of that. They and the other kernel developers will fix a lot of
1684 other issues as well. But be aware that sometimes they can't or won't help; and
1687 This is best explained with kernel developers that contribute to the Linux
1702 old that it's something you don't find much outside of computer museums
1710 The situation is not that different with developers that are paid for their
1724 That's true for spare time or the time employers grant their developers to
1739 document and the implications between the lines illustrate that. But that's how
1762 is available under CC-BY-4.0, as versions of this text that were processed