Lines Matching full:it
25 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
38 The issue was fixed there, but you would like to see it resolved in a still
40 If it shows the problem, search for the change that fixed it in mainline and
41 check if backporting is in the works or was discarded; if it's neither, ask
42 those who handled the change for it.
45 ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
46 sure it's built and running in a healthy environment and not already tainted
64 developers. It might be all that's needed for people already familiar with
66 everyone else there is this section. It is more detailed and uses a
67 step-by-step approach. It still tries to be brief for readability and leaves
92 * Make sure it's not the kernel's surroundings that are causing the issue
126 go and install it for the reporting process. Testing and reporting with
129 approach, but in that development phase it can be an even better idea to
137 * Reproduce the issue with the kernel you just installed. If it doesn't show
144 that hear about it for the first time. And if you learned something in this
158 link to it. Include or upload all other information that might be relevant,
160 you wrote this main part, insert a normal length paragraph on top of it
174 help yourself, if you don't get any help or if it's unsatisfying.
189 <https://kernel.org/>`_ and make sure it mentions
205 issue and ideally explain how to reproduce it. Mention the first version
233 all, join the newest discussion, asking if it's in the cards.
249 what this section is for, as it will provide a lot more details on each of the
250 above steps. Consider this as reference documentation: it's possible to read it
251 from top to bottom. But it's mainly meant to skim over and a place to look up
257 demands more than other FLOSS projects. We'd love to make it simpler. But
270 upstream Linux kernel; motivate them by saying it's the only way to ensure
294 with reports for issues that don't even happen with their current code. It's
296 easily happen when it comes to the kernel and often leads to frustration on both
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.
332 those often get rejected or ignored, so consider yourself warned. But it's still
346 time for everyone involved, especially you as the reporter. So it's in your own
348 step of the process it's okay to just perform a rough search: a later step will
351 process, it can save you time and trouble.
365 often is not much helpful, as it is too specific. Instead try search terms like
399 the Linux kernel does not work with a newer one or somehow works worse with it.
400 It thus is a regression when a WiFi driver that did a fine job with Linux 5.7
401 somehow misbehaves with 5.8 or doesn't work at all. It's also a regression if
413 'Documentation/admin-guide/security-bugs.rst' before proceeding, as it
417 happens. That's for example the case when a Linux kernel corrupts the data it's
418 handling or damages hardware it's running on. You're also dealing with a severe
428 *Make sure it's not the kernel's surroundings that are causing the issue
432 runtime environment. It's hard to rule out that problem completely, but you
433 should minimize it:
443 * Try to make sure it's not faulty hardware that is causing your issue. Bad
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
483 automatically, for example when you install a new Linux kernel or boot it for
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
512 why the kernel also mentions the taint status when it reports an internal
516 line starting with 'CPU:'. It should end with 'Not tainted' if the kernel was
517 not tainted when it noticed the problem; it was tainted if you see 'Tainted:'
521 to find out why. Try to eliminate the reason. Often it's caused by one these
525 itself, as the kernel knows it might misbehave in strange ways after that
543 taints itself when it loads such module from external sources (even if
551 3. The kernel also taints itself when it's loading a module that resides in
554 quality standards. When you report an issue with such a module it's
573 various issues in one report also makes it quite difficult for others to tear
574 it apart. Hence, only combine issues in one report if they are very strongly
578 happens with other kernel versions. Therefore, it will make your work easier if
581 Note: it's often fruitless to report issues that only happened once, as they
613 It's crucial to send your report to the right people, as the Linux kernel is a
615 it. Quite a few programmers for example only care for just one driver, for
621 file your issue and make it reach the developers that need to know about it.
623 You can do that with the help of a script (see below), but it mainly targets
631 case it's likely an issue in the WiFi driver. Obviously it could also be some
632 code it builds upon, but unless you suspect something like that stick to the
633 driver. If it's really something else, the driver's developers will get the
640 the output of ``lspci -k``, as it lists devices on the PCI/PCIe bus and the
641 kernel module driving it::
655 this to find the module driving it::
662 are unsure which it is: just try your best guess, somebody will help you if you
665 Once you know the driver or subsystem, you want to search for it in the
684 First look at the line 'Status'. Ideally it should be 'Supported' or
685 'Maintained'. If it states 'Obsolete' then you are using some outdated approach
689 That only leaves these options: arrange yourself to live with the issue, fix it
690 yourself, or find a programmer somewhere willing to fix it.
692 After checking the status, look for a line starting with 'bugs:': it will tell
715 to find all people to contact. It queries the MAINTAINERS file and needs to be
732 Don't sent your report to all of them. Send it to the maintainers, which the
741 question, as they might be able to help. But use these results with care, as it
758 that you know where they need to be reported to. If it's mailing list, you will
773 It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
776 have reported it only there.
789 go and install it for the reporting process. Testing and reporting with
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
802 before reporting it. You are free to ignore this advice, but as outlined
814 It also outlines that using a pre-compiled kernel are fine, but better are
815 vanilla, which means: it was built using Linux sources taken straight `from
835 all intrusive ones get merged for the next release during this time. It's a bit
837 quite busy then and might have no spare time to deal with issue reports. It's
843 That's why it might make sense to wait till the merge window is over. But don't
848 using it for reproducing the issue is also better than not reporting it issue
854 needs to be fixed in mainline first before it can get backported, which can
862 further: if the issue doesn't occur with mainline it will guide you how to get
863 it fixed in older version lines, if that's in the cards for the fix in question.
873 you face or influence it somehow.
877 latest mainline or stable Linux built as vanilla kernel. It's totally okay to
879 at least close to it. Additionally ensure the packages contain the latest
897 about it: they are as reliable as a proper pre-release, unless the kernel's
905 the necessary steps already. If you are new to it, consider following one of
907 pick up the configuration of your current kernel and then tries to adjust it
916 build a kernel by quite a bit. But that's worth it, as these options will allow
920 But keep in mind: Always keep a record of the issue encountered in case it is
934 not set this flag. And if it does, you in almost all the cases needs to
935 eliminate the reason for it before you reporting issues that occur with it. See
942 *Reproduce the issue with the kernel you just installed. If it doesn't show
947 installed. If it was fixed there already, consider sticking with this version
949 users might still be plagued by it, as long as it's not fixed in either stable
962 that hear about it for the first time. And if you learned something in this
965 An unnecessarily complex report will make it hard for others to understand your
968 the same time try to keep it as short as possible.
981 When the kernel detects an internal problem, it will log some information about
982 the executed code. This makes it possible to pinpoint the exact line in the
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
991 are running a kernel you compiled yourself earlier, call it like this::
997 might need to get from the Linux sources if your distro does not package it)
1022 reason for it in the report. If you're lucky, it might not be needed. And if it
1041 the regression needs to be known. Normally it's up to the reporter to track
1043 reproduce it themselves.
1049 some time, but don't worry, it works a lot quicker than most people assume.
1051 code management system that's causing the regression. Once you find it, search
1054 reports about it, if there are any.
1057 bit of effort, which not everyone is willing to invest. Nevertheless, it's
1062 5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
1067 process. But keep in mind: it depends on the issue at hand if the developers
1069 recognize from the report want went wrong and can fix it; other times they will
1079 olddefconfig`` to adjust it for the needs of the new version.
1090 link to it. Include or upload all other information that might be relevant,
1092 you wrote this main part, insert a normal length paragraph on top of it
1101 Now that you have prepared everything it's time to write your report. How to do
1111 will look into it and help you. And that is why you should ignore them for now
1121 trigger it.
1128 version number and the compiler it was built with.
1136 subject and the commit-id of the change that is causing it.
1138 In a lot of cases it's also wise to make two more things available to those
1144 sure that it starts with a line like 'Linux version 5.8-1
1146 3 14:54:37 UTC 2020' If it's missing, then important messages from the first
1151 These two files are big, that's why it's a bad idea to put them directly into
1175 include it. If you can't copy'n'paste it, try to capture a netconsole trace
1180 mention its manufacturer, the card's model, and what chip is uses. If it's a
1181 laptop mention its name, but try to make sure it's meaningful. 'Dell XPS 13'
1182 for example is not, because it might be the one from 2012; that one looks
1201 insights how the components were configured. For some issues it might be
1230 Now that you have written this part take some time to optimize it, as it is the
1235 you, unless it's one of those 'issues of high priority' outlined earlier: in
1259 question. Make sure to inline the forwarded report, hence do not attach it.
1277 offer a way to keep reports private, forget about it and send your report as
1282 them when sending the report by mail. If you filed it in a bug tracker, forward
1283 the report's text to these addresses; but on top of it put a small note where
1284 you mention that you filed it with a link to the ticket.
1297 help yourself, if you don't get any help or if it's unsatisfying.*
1301 to fix it, test it, and send it straight for integration in mainline while
1302 tagging it for later backport to stable and longterm kernels that need it. Then
1304 with the fix once it gets released.
1308 but often it will be the things listed below. But before digging into the
1317 reply there and do not contact any of the developers privately about it. For
1322 list(s) and everyone else that gets involved over time stays in the loop; it
1331 * You were told to send something, but noticed it contains sensitive
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
1340 Linux kernel sources to test if it helps. In some cases it will be fine sending
1344 about it to a chatroom or forum you normally hang out.
1347 within a few hours. But most of the time it will take longer, as maintainers
1352 reports. Sometimes it will take longer, as they might be busy with the merge
1358 should wait a week at maximum (or just two days if it's something urgent)
1364 ask others for public or private replies how to move on. If that fails, it
1367 maintainers or all else fails, it might be one of those rare situations where
1368 it's okay to get Linus Torvalds involved.
1373 mail you sent as reply to your report (make sure it has all those in the CC
1375 commitment and that you are willing to help. It also tells developers if the
1376 issue persists and makes sure they do not forget about it. A few other
1389 **Check who you deal with**: Most of the time it will be the maintainer or a
1391 issues are normally reported in public it could be anyone that's replying —
1393 track with their questions or requests. That rarely happens, but it's one of
1394 many reasons why it's wise to quickly run an internet search to see who you're
1402 the attention of someone that might help and risk losing it the longer you
1407 possible fix, try to test it in timely manner, too. But do it properly and make
1408 sure to not rush it: mixing things up can happen easily and can lead to a lot
1412 notice when the kernel with the fix behaves just as one without it.
1419 nothing of substance coming out of it.
1435 confusing that people decided to completely stay away from it? The best way to
1439 review it before you send it out. Such an approach is totally fine; just
1443 If the report was proper you can send a second reminder; in it ask for advice
1460 It's also possible that after some discussion in the bug tracker or on a list
1462 a fix. Such situations can be devastating, but is within the cards when it
1488 line you care about: go to the front page of kernel.org and make sure it
1500 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1547 issue and ideally explain how to reproduce it. Mention the first version
1554 stable and regressions mailing list is all it takes; but in case you suspect
1558 And note, it helps developers a great deal if you can specify the exact version
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
1570 Once your report is out your might get asked to do a proper one, as it allows to
1584 reproduce your issue with a mainline kernel, but want to see it fixed in older
1633 all, join the newest discussion, asking if it's in the cards.*
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
1638 discussions abound it.
1653 line 5.4 and later. Most of the time it's getting applied there within two
1654 weeks, but sometimes it takes a bit longer.
1664 * If you see a proposed fix, search for it in the version control system as
1674 you would like to see it fixed, if suitable.
1716 old that it's something you don't find much outside of computer museums
1751 Compared with other Free/Libre & Open Source Software it's hard to report
1754 it is for now. The main author of this text hopes documenting the state of the
1761 fix it. You are free to do the same in a mostly informal way if you want