Lines Matching full:it
16 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
29 The issue was fixed there, but you would like to see it resolved in a still
31 If it shows the problem, search for the change that fixed it in mainline and
32 check if backporting is in the works or was discarded; if it's neither, ask
33 those who handled the change for it.
36 ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
37 sure it's built and running in a healthy environment and not already tainted
55 developers. It might be all that's needed for people already familiar with
57 everyone else there is this section. It is more detailed and uses a
58 step-by-step approach. It still tries to be brief for readability and leaves
83 * Make sure it's not the kernel's surroundings that are causing the issue
117 go and install it for the reporting process. Testing and reporting with
120 approach, but in that development phase it can be an even better idea to
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
149 link to it. Include or upload all other information that might be relevant,
151 you wrote this main part, insert a normal length paragraph on top of it
165 help yourself, if you don't get any help or if it's unsatisfying.
180 <https://kernel.org/>`_ and make sure it mentions
196 issue and ideally explain how to reproduce it. Mention the first version
224 all, join the newest discussion, asking if it's in the cards.
240 what this section is for, as it will provide a lot more details on each of the
241 above steps. Consider this as reference documentation: it's possible to read it
242 from top to bottom. But it's mainly meant to skim over and a place to look up
248 demands more than other FLOSS projects. We'd love to make it simpler. But
261 upstream Linux kernel; motivate them by saying it's the only way to ensure
285 with reports for issues that don't even happen with their current code. It's
287 easily happen when it comes to the kernel and often leads to frustration on both
300 report and, in case it turns out to be an upstream issue, fix it directly
305 explain how to do that once it rules out other potential causes for your issue.
323 those often get rejected or ignored, so consider yourself warned. But it's still
337 time for everyone involved, especially you as the reporter. So it's in your own
339 step of the process it's okay to just perform a rough search: a later step will
342 process, it can save you time and trouble.
356 often is not much helpful, as it is too specific. Instead try search terms like
393 detail. It also provides a good deal of other information about regressions you
394 might want to be aware of; it for example explains how to add your issue to the
395 list of tracked regressions, to ensure it won't fall through the cracks.
398 Documentation/process/security-bugs.rst before proceeding, as it
402 happens. That's for example the case when a Linux kernel corrupts the data it's
403 handling or damages hardware it's running on. You're also dealing with a severe
413 *Make sure it's not the kernel's surroundings that are causing the issue
417 runtime environment. It's hard to rule out that problem completely, but you
418 should minimize it:
428 * Try to make sure it's not faulty hardware that is causing your issue. Bad
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
468 automatically, for example when you install a new Linux kernel or boot it for
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
497 why the kernel also mentions the taint status when it reports an internal
501 line starting with 'CPU:'. It should end with 'Not tainted' if the kernel was
502 not tainted when it noticed the problem; it was tainted if you see 'Tainted:'
506 to find out why. Try to eliminate the reason. Often it's caused by one these
510 itself, as the kernel knows it might misbehave in strange ways after that
528 taints itself when it loads such module from external sources (even if
536 3. The kernel also taints itself when it's loading a module that resides in
539 quality standards. When you report an issue with such a module it's
558 various issues in one report also makes it quite difficult for others to tear
559 it apart. Hence, only combine issues in one report if they are very strongly
563 happens with other kernel versions. Therefore, it will make your work easier if
566 Note: it's often fruitless to report issues that only happened once, as they
598 It's crucial to send your report to the right people, as the Linux kernel is a
600 it. Quite a few programmers for example only care for just one driver, for
606 file your issue and make it reach the developers that need to know about it.
608 You can do that with the help of a script (see below), but it mainly targets
616 case it's likely an issue in the WiFi driver. Obviously it could also be some
617 code it builds upon, but unless you suspect something like that stick to the
618 driver. If it's really something else, the driver's developers will get the
625 the output of ``lspci -k``, as it lists devices on the PCI/PCIe bus and the
626 kernel module driving it::
640 this to find the module driving it::
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
669 First look at the line 'Status'. Ideally it should be 'Supported' or
670 'Maintained'. If it states 'Obsolete' then you are using some outdated approach
674 That only leaves these options: arrange yourself to live with the issue, fix it
675 yourself, or find a programmer somewhere willing to fix it.
677 After checking the status, look for a line starting with 'bugs:': it will tell
700 to find all people to contact. It queries the MAINTAINERS file and needs to be
717 Don't sent your report to all of them. Send it to the maintainers, which the
726 question, as they might be able to help. But use these results with care, as it
743 that you know where they need to be reported to. If it's mailing list, you will
758 It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
761 have reported it only there.
774 go and install it for the reporting process. Testing and reporting with
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
787 before reporting it. You are free to ignore this advice, but as outlined
799 It also outlines that using a pre-compiled kernel are fine, but better are
800 vanilla, which means: it was built using Linux sources taken straight `from
820 all intrusive ones get merged for the next release during this time. It's a bit
822 quite busy then and might have no spare time to deal with issue reports. It's
828 That's why it might make sense to wait till the merge window is over. But don't
833 using it for reproducing the issue is also better than not reporting it issue
839 needs to be fixed in mainline first before it can get backported, which can
847 further: if the issue doesn't occur with mainline it will guide you how to get
848 it fixed in older version lines, if that's in the cards for the fix in question.
858 you face or influence it somehow.
862 latest mainline or stable Linux built as vanilla kernel. It's totally okay to
864 at least close to it. Additionally ensure the packages contain the latest
882 about it: they are as reliable as a proper pre-release, unless the kernel's
890 the necessary steps already. If you are new to it, consider following one of
892 pick up the configuration of your current kernel and then tries to adjust it
901 build a kernel by quite a bit. But that's worth it, as these options will allow
905 But keep in mind: Always keep a record of the issue encountered in case it is
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
932 installed. If it was fixed there already, consider sticking with this version
934 users might still be plagued by it, as long as it's not fixed in either stable
947 that hear about it for the first time. And if you learned something in this
950 An unnecessarily complex report will make it hard for others to understand your
953 the same time try to keep it as short as possible.
966 When the kernel detects an internal problem, it will log some information about
967 the executed code. This makes it possible to pinpoint the exact line in the
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
976 are running a kernel you compiled yourself earlier, call it like this::
982 might need to get from the Linux sources if your distro does not package it)
1007 reason for it in the report. If you're lucky, it might not be needed. And if it
1026 the regression needs to be known. Normally it's up to the reporter to track
1028 reproduce it themselves.
1034 some time, but don't worry, it works a lot quicker than most people assume.
1036 code management system that's causing the regression. Once you find it, search
1039 reports about it, if there are any.
1042 bit of effort, which not everyone is willing to invest. Nevertheless, it's
1047 5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
1052 process. But keep in mind: it depends on the issue at hand if the developers
1054 recognize from the report want went wrong and can fix it; other times they will
1076 link to it. Include or upload all other information that might be relevant,
1078 you wrote this main part, insert a normal length paragraph on top of it
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
1107 trigger it.
1114 version number and the compiler it was built with.
1122 subject and the commit-id of the change that is causing it.
1124 In a lot of cases it's also wise to make two more things available to those
1130 sure that it starts with a line like 'Linux version 5.8-1
1132 3 14:54:37 UTC 2020' If it's missing, then important messages from the first
1137 These two files are big, that's why it's a bad idea to put them directly into
1161 include it. If you can't copy'n'paste it, try to capture a netconsole trace
1166 mention its manufacturer, the card's model, and what chip is uses. If it's a
1167 laptop mention its name, but try to make sure it's meaningful. 'Dell XPS 13'
1168 for example is not, because it might be the one from 2012; that one looks
1187 insights how the components were configured. For some issues it might be
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
1245 question. Make sure to inline the forwarded report, hence do not attach it.
1263 offer a way to keep reports private, forget about it and send your report as
1268 them when sending the report by mail. If you filed it in a bug tracker, forward
1269 the report's text to these addresses; but on top of it put a small note where
1270 you mention that you filed it with a link to the ticket.
1283 help yourself, if you don't get any help or if it's unsatisfying.*
1287 to fix it, test it, and send it straight for integration in mainline while
1288 tagging it for later backport to stable and longterm kernels that need it. Then
1290 with the fix once it gets released.
1294 but often it will be the things listed below. But before digging into the
1303 reply there and do not contact any of the developers privately about it. For
1308 list(s) and everyone else that gets involved over time stays in the loop; it
1317 * You were told to send something, but noticed it contains sensitive
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
1326 Linux kernel sources to test if it helps. In some cases it will be fine sending
1330 about it to a chatroom or forum you normally hang out.
1333 within a few hours. But most of the time it will take longer, as maintainers
1338 reports. Sometimes it will take longer, as they might be busy with the merge
1344 should wait a week at maximum (or just two days if it's something urgent)
1350 ask others for public or private replies how to move on. If that fails, it
1353 maintainers or all else fails, it might be one of those rare situations where
1354 it's okay to get Linus Torvalds involved.
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
1362 issue persists and makes sure they do not forget about it. A few other
1375 **Check who you deal with**: Most of the time it will be the maintainer or a
1377 issues are normally reported in public it could be anyone that's replying —
1379 track with their questions or requests. That rarely happens, but it's one of
1380 many reasons why it's wise to quickly run an internet search to see who you're
1388 the attention of someone that might help and risk losing it the longer you
1393 possible fix, try to test it in timely manner, too. But do it properly and make
1394 sure to not rush it: mixing things up can happen easily and can lead to a lot
1398 notice when the kernel with the fix behaves just as one without it.
1405 nothing of substance coming out of it.
1421 confusing that people decided to completely stay away from it? The best way to
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
1446 It's also possible that after some discussion in the bug tracker or on a list
1448 a fix. Such situations can be devastating, but is within the cards when it
1474 line you care about: go to the front page of kernel.org and make sure it
1486 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1533 issue and ideally explain how to reproduce it. Mention the first version
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
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
1556 Once your report is out your might get asked to do a proper one, as it allows to
1570 reproduce your issue with a mainline kernel, but want to see it fixed in older
1619 all, join the newest discussion, asking if it's in the cards.*
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
1624 discussions abound it.
1639 line 5.4 and later. Most of the time it's getting applied there within two
1640 weeks, but sometimes it takes a bit longer.
1650 * If you see a proposed fix, search for it in the version control system as
1660 you would like to see it fixed, if suitable.
1702 old that it's something you don't find much outside of computer museums
1737 Compared with other Free/Libre & Open Source Software it's hard to report
1740 it is for now. The main author of this text hopes documenting the state of the
1749 he'll fix it. You are free to do the same in a mostly informal way if you