Lines Matching full:to
14 <https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
16 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
23 expect to be told about problems, which most of the time will be by email with a
26 don't find any to join, install `the latest mainline kernel
29 The issue was fixed there, but you would like to see it resolved in a still
41 separately. While writing your report, include all information relevant to the
43 regressions mailing list (regressions@lists.linux.dev) to your report. Also try
44 to pinpoint the culprit with a bisection; if you succeed, include its
53 might want to switch to a rendered version: It makes it a lot easier to
54 read and navigate this document -- especially when you want to look something
55 up in the reference section, then jump back to where you left off.
61 Step-by-step guide how to report issues to the kernel maintainers
64 The above TL;DR outlines roughly how to report issues to the Linux kernel
66 reporting issues to Free/Libre & Open Source Software (FLOSS) projects. For
68 step-by-step approach. It still tries to be brief for readability and leaves
73 a slightly different order. That's in your interest, to make sure you notice
75 something else. These steps thus help to ensure the time you invest in this
79 provided? Then in almost all cases you are better off to stop reading this
80 document and reporting the issue to your vendor instead, unless you are
81 willing to install the latest Linux version yourself. Be aware the latter
82 will often be needed anyway to hunt down and fix issues.
91 need special handling in some steps that are about to follow.
105 * Write down coarsely how to reproduce the issue. If you deal with multiple
108 needs to get reported to the kernel developers separately, unless they are
112 (say something broke when updating from 5.10.4 to 5.10.5), scroll down to
115 * Locate the driver or kernel subsystem that seems to be causing the issue.
117 time this won't be bugzilla.kernel.org, as issues typically need to be sent
118 by mail to a maintainer and a public mailing list.
130 approach, but in that development phase it can be an even better idea to
139 up there, scroll down to the instructions for issues only happening with
142 * Optimize your notes: try to find and write the most straightforward way to
144 details, and at the same time is easy to read and understand for others
149 decoding the kernel log to find the line of code that triggered the error.
151 * If your problem is a regression, try to narrow down when the issue was
154 * Start to compile the report by writing a detailed description about the
156 for reproducing, the Linux Distribution used, and your notes on how to
159 link to it. Include or upload all other information that might be relevant,
163 that briefly describes the problem and gets people to read on. Now give the
165 ready to send or file the report like the MAINTAINERS file told you, unless
172 to any inquiries. Test proposed fixes. Do proactive testing: retest with at
174 report your results. Send friendly reminders if things stall. And try to
183 face one of those if something breaks when updating from 5.10.4 to 5.10.5 (a
184 switch from 5.9.15 to 5.10.5 does not qualify). The developers want to fix such
185 regressions as quickly as possible, hence there is a streamlined process to
189 line you care about: go to the `front page of kernel.org
200 known to work performs fine as well.
202 * Send a short problem report to the Linux stable mailing list
206 issue and ideally explain how to reproduce it. Mention the first version
217 above, but failed to reproduce your issue there; at the same time you want to
223 or risky to get backported there.
236 * One of the former steps should lead to a solution. If that doesn't work
237 out, ask the maintainers for the subsystem that seems to be causing the
248 reference section below? Did you spot errors? Or do you have ideas on how to
252 or a patch to Thorsten Leemhuis <linux@leemhuis.info> while ideally CCing the
254 vital to improve this text further, which is in everybody's interest, as it will
255 enable more people to master the task described here.
258 Reference section: Reporting issues to the kernel maintainers
263 sometimes wonder how to actually realize some of those steps or why they are
270 * The Linux developers are well aware that reporting bugs to them is more
272 the kernel is different, among others due to its mail-driven development
275 triaging bugs –– and nobody has stepped up to do or fund that work.
277 * A warranty or support contract with some vendor doesn't entitle you to
281 vendor who issued the contract. If you want to claim your rights, use the
284 * If you never reported an issue to a FLOSS project before, consider skimming
285 guides like `How to ask good questions
286 <https://jvns.ca/blog/good-questions/>`_, `How To Ask Questions The Smart Way
287 <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to Report
291 guide on reporting issues to the Linux kernel developers.
298 provided? Then in almost all cases you are better off to stop reading this
299 document and reporting the issue to your vendor instead, unless you are
300 willing to install the latest Linux version yourself. Be aware the latter
301 will often be needed anyway to hunt down and fix issues.*
303 Like most programmers, Linux kernel developers don't like to spend time dealing
306 easily happen when it comes to the kernel and often leads to frustration on both
313 Most of these vendor kernels are quite unsuitable for reporting issues to the
318 issues with these kernels to the vendor. Its developers should look into the
319 report and, in case it turns out to be an upstream issue, fix it directly
321 or might not what you want. You thus might want to consider circumventing the
324 explain how to do that once it rules out other potential causes for your issue.
327 developers in fact are willing to handle reports about issues occurring with
330 small modifications to a kernel based on a recent Linux version; that for
336 want to use a mainline Linux and avoid using a stable kernel for this
340 Obviously you are free to ignore all this advice and report problems with an old
341 or heavily modified vendor kernel to the upstream Linux developers. But note,
344 indirectly will help to get the issue fixed over time.
357 interest to thoroughly check if somebody reported the issue already. At this
358 step of the process it's okay to just perform a rough search: a later step will
359 tell you to perform a more detailed search once you know where your issue needs
360 to be reported to. Nevertheless, do not hurry with this step of the reporting
367 If you get flooded with results consider telling your search engine to limit
368 search timeframe to the past month or year. And wherever you search, make sure
369 to use good search terms; vary them a few times, too. While doing so try to
370 look at the issue from the perspective of someone else: that will help you to
371 come up with other words to use as search terms. Also make sure not to use too
372 many search terms at once. Remember to search with and without information like
380 you might be able to provide valuable additional information. That can be
383 test a proposed fix. Jump to the section 'Duties after the report went out' for
384 details on how to get properly involved.
390 need to report your issue". The developers that should take care of the issue
401 need special handling in some steps that are about to follow.*
403 Linus Torvalds and the leading Linux kernel developers want to see some issues
413 might want to be aware of; it for example explains how to add your issue to the
414 list of tracked regressions, to ensure it won't fall through the cracks.
416 What qualifies as security issue is left to your judgment. Consider reading
418 provides additional details how to best handle security issues.
436 runtime environment. It's hard to rule out that problem completely, but you
440 binutils can cause the resulting kernel to misbehave.
447 * Try to make sure it's not faulty hardware that is causing your issue. Bad
451 * If you're dealing with a filesystem issue, you might want to check the file
453 to unexpected kernel behavior.
456 changed in parallel to updating the kernel. The problem for example might be
460 something in the BIOS Setup can also lead to problems that on look a lot
471 system. That's what you are about to do in this process. Thus, make sure to
472 create a fresh backup; also ensure you have all tools at hand to repair or
473 reinstall the operating system as well as everything you need to restore the
494 module not part of the Linux kernel. That why your might need to uninstall the
495 packages with such software to get rid of any 3rd party kernel module.
505 lead to follow-up errors that look totally unrelated. The issue you face might
506 be such an error if your kernel is tainted. That's why it's in your interest to
508 only reason why this step is here, as this process later will tell you to
509 install the latest mainline kernel; you will need to check the taint flag again
513 On a running system is easy to check if the kernel tainted itself: if ``cat
525 to find out why. Try to eliminate the reason. Often it's caused by one these
537 follow-up problem to that first Oops, even if both look totally unrelated.
540 a change to the configuration followed by a reboot can eliminate the Oops.
543 version you are going to install later in this process.
549 areas and thus might be causing the issue you face. You therefore have to
550 prevent those modules from loading when you want to report an issue to the
551 Linux kernel developers. Most of the time the easiest way to do that is:
566 Document how to reproduce issue
569 *Write down coarsely how to reproduce the issue. If you deal with multiple
572 needs to get reported to the kernel developers separately, unless they are
575 If you deal with multiple issues at once, you'll have to report each of them
577 various issues in one report also makes it quite difficult for others to tear
581 Additionally, during the reporting process you will have to test if the issue
583 you know exactly how to reproduce an issue quickly on a freshly booted system.
585 Note: it's often fruitless to report issues that only happened once, as they
586 might be caused by a bit flip due to cosmic radiation. That's why you should
587 try to rule that out by reproducing the issue before going further. Feel free
588 to ignore this advice if you are experienced enough to tell a one-time error
589 due to faulty hardware apart from a kernel issue that rarely happens and thus
590 is hard to reproduce.
597 (say something broke when updating from 5.10.4 to 5.10.5), scroll down to
601 Linux developers want to fix badly, as such issues are even more unwanted than
603 people. The developers thus want to learn about such issues as quickly as
604 possible, hence there is a streamlined process to report them. Note,
606 from 5.9.15 to 5.10.5) do not qualify.
609 Check where you need to report your issue
612 *Locate the driver or kernel subsystem that seems to be causing the issue.
614 time this won't be bugzilla.kernel.org, as issues typically need to be sent
615 by mail to a maintainer and a public mailing list.*
617 It's crucial to send your report to the right people, as the Linux kernel is a
625 file your issue and make it reach the developers that need to know about it.
626 That's why you have to find the right place and way to report issues yourself.
631 How to read the MAINTAINERS file
633 To illustrate how to use the :ref:`MAINTAINERS <maintainers>` file, let's assume
636 code it builds upon, but unless you suspect something like that stick to the
640 Sadly, there is no way to check which code is driving a particular hardware
643 In case of a problem with the WiFi driver you for example might want to look at
656 other internal bus. In those cases you might want to check your WiFi manager or
659 this to find the module driving it::
661 [user@something ~]$ realpath --relative-to=/sys/module/ /sys/class/net/wlp58s0/device/driver/module
664 In case tricks like these don't bring you any further, try to search the
665 internet on how to narrow down the driver or subsystem in question. And if you
669 Once you know the driver or subsystem, you want to search for it in the
671 name is too specific. Sometimes you will need to search on the net for help;
690 that was replaced by a newer solution you need to switch to. Sometimes the code
693 That only leaves these options: arrange yourself to live with the issue, fix it
694 yourself, or find a programmer somewhere willing to fix it.
697 you where to find a subsystem specific bug tracker to file your issue. The
702 In this and many other cases you thus have to look for lines starting with
706 Your report later needs to go by mail to those addresses. Additionally, for all
707 issue reports sent by email, make sure to add the Linux Kernel Mailing List
708 (LKML) <linux-kernel@vger.kernel.org> to CC. Don't omit either of the mailing
711 and LKML is important to have one place where all issue reports can be found.
717 For people that have the Linux sources at hand there is a second option to find
718 the proper place to report: the script 'scripts/get_maintainer.pl' which tries
719 to find all people to contact. It queries the MAINTAINERS file and needs to be
720 called with a path to the source code in question. For drivers compiled as
726 Pass parts of this to the script::
736 Don't sent your report to all of them. Send it to the maintainers, which the
739 would need to send the report to 'Some Human <shuman@example.com>' with
742 Note: in case you cloned the Linux sources with git you might want to call
744 at the commit history to find which people recently worked on the code in
745 question, as they might be able to help. But use these results with care, as it
762 that you know where they need to be reported to. If it's mailing list, you will
768 ath10k@lists.infradead.org' for example will lead you to the `Info page for the
770 which at the top links to its
772 quite a few other lists miss a way to search the archives. In those cases use a
774 'site:lists.infradead.org/pipermail/ath10k/' to your search terms, which limits
775 the results to the archives at that URL.
777 It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
778 at this point. If your report needs to be filed in a bug tracker, you may want
779 to check the mailing list archives for the subsystem as well, as someone might
782 For details how to search and what to do if you find matching reports see
785 Do not hurry with this step of the reporting process: spending 30 to 60 minutes
796 approach, but in that development phase it can be an even better idea to
802 programmers, Linux kernel developers don't like to spend time dealing with
806 before reporting it. You are free to ignore this advice, but as outlined
817 * The over next subsection describes way to obtain and install such a kernel.
825 Head over to `kernel.org <https://kernel.org/>`_ to find out which version you
826 want to use for testing. Ignore the big yellow button that says 'Latest release'
828 mainline, which most of the time will point to a pre-release with a version
829 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
830 kernel for testing, as that where all fixes have to be applied first. Do not let
834 In about two out of every nine to ten weeks, mainline might point you to a
840 more risky to use mainline during this period. Kernel developers are also often
841 quite busy then and might have no spare time to deal with issue reports. It's
843 window fixes the issue you face; that's why you soon would have to retest with
847 That's why it might make sense to wait till the merge window is over. But don't
848 to that if you're dealing with something that shouldn't wait. In that case
856 must be applied to mainline first. That's why checking the latest mainline
857 kernel is so important: any issue you want to see fixed in older version lines
858 needs to be fixed in mainline first before it can get backported, which can
860 hard or risky for backporting; reporting the issue again hence is unlikely to
864 are unsuitable for this part of the reporting process: they are to distant from
866 further: if the issue doesn't occur with mainline it will guide you how to get
869 How to obtain a fresh Linux kernel
881 latest mainline or stable Linux built as vanilla kernel. It's totally okay to
883 at least close to it. Additionally ensure the packages contain the latest
888 Please note that you might need to build your own kernel manually later: that's
891 are needed to decode messages the kernel prints when a panic, Oops, warning, or
892 BUG occurs; if you plan to decode those, you might be better off compiling a
908 How to actually build a kernel is not described here, as many websites explain
909 the necessary steps already. If you are new to it, consider following one of
910 those how-to's that suggest to use ``make localmodconfig``, as that tries to
911 pick up the configuration of your current kernel and then tries to adjust it
913 but quicker to compile.
916 please try to enable CONFIG_KALLSYMS when configuring your kernel.
919 the former. Be aware CONFIG_DEBUG_INFO increases the storage space required to
921 you later to pinpoint the exact line of code that triggers your issue. The
925 hard to reproduce. Sending an undecoded report is better than not reporting
936 something happens that can lead to follow-up errors that look totally
937 unrelated. That's why you need to check if the kernel you just installed does
938 not set this flag. And if it does, you in almost all the cases needs to
940 the section above for details how to do that.
947 up there, scroll down to the instructions for issues only happening with
952 line and abandoning your plan to report the issue. But keep in mind that other
955 those). If you prefer to use one of those or just want to help their users,
956 head over to the section "Details about reporting issues only occurring in
960 Optimize description to reproduce issue
963 *Optimize your notes: try to find and write the most straightforward way to
965 details, and at the same time is easy to read and understand for others
969 An unnecessarily complex report will make it hard for others to understand your
970 report. Thus try to find a reproducer that's straight forward to describe and
971 thus easy to understand in written form. Include all important details, but at
972 the same time try to keep it as short as possible.
983 decoding the kernel log to find the line of code that triggered the error.*
986 the executed code. This makes it possible to pinpoint the exact line in the
989 your kernel. If you did so, consider to decode the information from the
990 kernel's log. That will make it a lot easier to understand what lead to the
999 If you are running a packaged vanilla kernel, you will likely have to install
1001 might need to get from the Linux sources if your distro does not package it)
1021 starting with 'Call trace', which show the path to the function where the
1025 Note, if you can't get this to work, simply skip this step and mention the
1027 is, someone might help you to get things going. Also be aware this is just one
1028 of several ways to decode kernel stack traces. Sometimes different steps will
1029 be required to retrieve the relevant details. Don't worry about that, if that's
1030 needed in your case, developers will tell you what to do.
1036 *If your problem is a regression, try to narrow down when the issue was
1040 worsens, that's why he deems regressions as unacceptable and wants to see them
1043 way. Reporting a regression is thus a bit like playing a kind of trump card to
1044 get something quickly fixed. But for that to happen the change that's causing
1045 the regression needs to be known. Normally it's up to the reporter to track
1046 down the culprit, as maintainers often won't have the time or setup at hand to
1049 To find the change there is a process called 'bisection' which the document
1051 will often require you to build about ten to twenty kernel images, trying to
1054 Thanks to a 'binary search' this will lead you to the one commit in the source
1057 (the first 12 characters of the commit id). This will lead you to existing
1061 bit of effort, which not everyone is willing to invest. Nevertheless, it's
1063 don't want to go down that route at least find out which mainline kernel
1065 5.5.15 to 5.8.4, then try at least all the mainline releases in that area (5.6,
1066 5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
1068 has three sections (5.6.12, 5.7.8), as that makes the outcome hard to
1070 version which introduced the regression, feel free to move on in the reporting
1072 will be able to help without knowing the culprit. Sometimes they might
1074 be unable to help unless you perform a bisection.
1083 provides a good deal of other information about regressions you might want to be
1090 *Start to compile the report by writing a detailed description about the
1092 for reproducing, the Linux Distribution used, and your notes on how to
1095 link to it. Include or upload all other information that might be relevant,
1099 that briefly describes the problem and gets people to read on. Now give the
1101 ready to send or file the report like the MAINTAINERS file told you, unless
1106 Now that you have prepared everything it's time to write your report. How to do
1107 that is partly explained by the three documents linked to in the preface above.
1109 things specific to the Linux kernel.
1114 seconds to skim a mail before deciding to move on or look closer. Thus: the
1123 installed. Try to include the step-by-step instructions you wrote and optimized
1125 those rare cases where that's impossible try to describe what you did to
1128 Also include all the relevant information others might need to understand the
1143 In a lot of cases it's also wise to make two more things available to those
1148 * the kernel's messages that you get from ``dmesg`` written to a file. Make
1156 These two files are big, that's why it's a bad idea to put them directly into
1157 your report. If you are filing the issue in a bug tracker then attach them to
1163 <https://bugzilla.kernel.org/>`_, ...) and include a link to them in your
1165 they could be useful to someone many years from now; this for example can
1167 changed just to fix your issue.
1170 replies to your own mail. Just remember to actually do that once the report
1173 Things that might be wise to provide
1176 Depending on the issue you might need to add more background data. Here are a
1177 few suggestions what often is good to provide:
1180 include it. If you can't copy'n'paste it, try to capture a netconsole trace
1183 * If the issue might be related to your computer hardware, mention what kind
1186 laptop mention its name, but try to make sure it's meaningful. 'Dell XPS 13'
1193 to find the exact model name or specify the main components.
1196 modules, you want to mention the versions of kmod, systemd, and udev in use.
1197 If one of the DRM drivers misbehaves, you want to state the versions of
1203 output from ``lspci -nn`` will for example help others to identify what
1204 hardware you use. If you have a problem with hardware you even might want to
1207 good to include the contents of files like ``/proc/cpuinfo``,
1209 ``/proc/scsi/scsi``. Some subsystem also offer tools to collect relevant
1213 Those examples should give your some ideas of what data might be wise to
1214 attach, but you have to think yourself what will be helpful for others to know.
1223 Now that you have the detailed part of the report prepared let's get to the
1224 most important section: the first few sentences. Thus go to the top, add
1228 crucial parts readers need to know to understand what this is all about; if you
1229 think this bug affects a lot of users, mention this to get people interested.
1232 summary that explains quickly what the report is about. After that you have to
1235 Now that you have written this part take some time to optimize it, as it is the
1261 (regressions@lists.linux.dev). In case the report needs to be filed to some web
1262 tracker, proceed to do so. Once filed, forward the report by mail to the
1264 question. Make sure to inline the forwarded report, hence do not attach it.
1265 Also add a short note at the top where you mention the URL to the ticket.
1268 author of the culprit to the recipients; also CC everyone in the signed-off-by
1271 **Security issues**: for these issues your will have to evaluate if a
1272 short-term risk to other users would arise if details were publicly disclosed.
1274 For issues that bear such a risk you will need to adjust the reporting process
1277 * If the MAINTAINERS file instructed you to report the issue by mail, do not
1280 * If you were supposed to file the issue in a bug tracker make sure to mark
1282 offer a way to keep reports private, forget about it and send your report as
1283 a private mail to the maintainers instead.
1285 In both cases make sure to also mail your report to the addresses the
1288 the report's text to these addresses; but on top of it put a small note where
1289 you mention that you filed it with a link to the ticket.
1299 to any inquiries. Test proposed fixes. Do proactive testing: retest with at
1301 report your results. Send friendly reminders if things stall. And try to
1306 to fix it, test it, and send it straight for integration in mainline while
1307 tagging it for later backport to stable and longterm kernels that need it. Then
1308 all you need to do is reply with a 'Thank you very much' and switch to a version
1312 once you got the report out. What you'll have to do depends on the situations,
1314 details, here are a few important things you need to keep in mind for this part
1323 mailed reports always use the 'Reply-all' function when replying to any mails
1324 you receive. That includes mails with any additional data you might want to add
1325 to your report: go to your mail applications 'Sent' folder and use 'reply-all'
1329 mailing lists to group all related mails together.
1334 * Someone tells you to send something privately.
1336 * You were told to send something, but noticed it contains sensitive
1337 information that needs to be kept private. In that case it's okay to send it
1338 in private to the developer that asked for it. But note in the ticket or a
1342 process someone might tell you to do something that requires a skill you might
1343 not have mastered yet. For example, you might be asked to use some test tools
1344 you never have heard of yet; or you might be asked to apply a patch to the
1345 Linux kernel sources to test if it helps. In some cases it will be fine sending
1346 a reply asking for instructions how to do that. But before going that route try
1347 to find the answer own your own by searching the internet; alternatively
1349 about it to a chatroom or forum you normally hang out.
1351 **Be patient**: If you are really lucky you might get a reply to your report
1356 In general, kernel developers will take one to five business days to respond to
1369 ask others for public or private replies how to move on. If that fails, it
1370 might be appropriate to get a higher authority involved. In case of a WiFi
1373 it's okay to get Linus Torvalds involved.
1378 mail you sent as reply to your report (make sure it has all those in the CC
1379 that up to that point participated in the discussion). This will show your
1380 commitment and that you are willing to help. It also tells developers if the
1387 to help to get issues resolved once they were reported.
1392 Here are your duties in case you got replies to your report:
1395 developer of the particular code area that will respond to your report. But as
1397 including people that want to help, but in the end might guide you totally off
1399 many reasons why it's wise to quickly run an internet search to see who you're
1401 the right people, as a reminder to the maintainer (see below) might be in order
1402 later if discussion fades out without leading to a satisfying solution for the
1405 **Inquiries for data**: Often you will be asked to test something or provide
1406 additional details. Try to provide the requested information soon, as you have
1411 **Requests for testing**: When you are asked to test a diagnostic patch or a
1412 possible fix, try to test it in timely manner, too. But do it properly and make
1413 sure to not rush it: mixing things up can happen easily and can lead to a lot
1416 happen even to experienced testers occasionally, but they most of the time will
1419 What to do when nothing of substance happens
1428 your report arrived or had something more important to take care of. When
1429 writing the reminder, kindly ask if anything else from your side is needed to
1431 first lines of a mail that is a reply to your initial mail (see above) which
1439 to reach out to the wrong people? Was the report maybe offensive or so
1440 confusing that people decided to completely stay away from it? The best way to
1441 rule out such factors: show the report to one or two people familiar with FLOSS
1443 to move forward. That might mean: prepare a better report and make those people
1446 link to the first report.
1454 If the second reminder again results in no reaction within a week, try to
1458 Remember to prepare yourself for a disappointment: maintainers ideally should
1459 react somehow to every issue report, but they are only obliged to fix those
1462 issues to deal with currently and won't have time to look into this for the
1466 nothing happens anymore and reminders don't help to motivate anyone to work out
1468 comes to Linux kernel development. This and several other reasons for not
1474 You for example could try to find others that are affected and team up with
1475 them to get the issue resolved. Such a team could prepare a fresh report
1480 bit about programming and might be able to write a fix.
1486 This subsection provides details for the steps you need to perform if you face
1493 line you care about: go to the front page of kernel.org and make sure it
1500 need to check if the kernel developers still support the version line you care
1504 should consider switching to the newer one and forget about the older one:
1505 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1515 Maybe the issue you face is already known and was fixed or is about to. Hence,
1519 already finished and scheduled to get applied soon.
1528 known to work performs fine as well.*
1530 Before investing any more time in this process you want to check if the issue
1532 This kernel needs to be vanilla and shouldn't be tainted before the issue
1537 vendor applied might be interfering. You need to rule that out by performing
1538 a recheck. Say something broke when you updated from 5.10.4-vendor.42 to
1542 regression and you need switch back to the main step-by-step guide to report
1548 *Send a short problem report to the Linux stable mailing list
1552 issue and ideally explain how to reproduce it. Mention the first version
1557 line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
1558 the start to get the issue reported quickly. Hence a rough description to the
1565 try to find that version using vanilla kernels. Let's assume something broke when
1566 your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
1568 5.10.9. If it shows the problem, try a vanilla 5.10.5 to ensure that no patches
1570 try 5.10.7 and then (depending on the outcome) 5.10.8 or 5.10.6 to find the
1575 Once your report is out your might get asked to do a proper one, as it allows to
1577 reverted to fix the issue quickly). Hence consider to do a proper bisection
1579 the document Documentation/admin-guide/bug-bisect.rst for details how to
1580 perform one. In case of a successful bisection add the author of the culprit to
1588 This section provides details for the steps you need to take if you could not
1589 reproduce your issue with a mainline kernel, but want to see it fixed in older
1597 or risky to get backported there.*
1601 are very aware of that and thus only apply changes to these kernels that are
1605 to mainline. Other fixes are easy to get backported to the newest stable and
1606 longterm kernels, but too risky to integrate into older ones. So be aware the
1607 fix you are hoping for might be one of those that won't be backported to the
1608 version line your care about. In that case you'll have no other choice then to
1609 live with the issue or switch to a newer Linux version, unless you want to
1618 You need to carry out a few steps already described in another section of this
1641 got fixed there. The commit that fixed it would need to get backported as well
1642 to get the issue solved. That's why you want to search for it or any
1645 * First try to find the fix in the Git repository that holds the Linux kernel
1657 If that's case the developer marked the fix safe for backporting to version
1666 instructions to find the subsystem in question: its bug tracker or mailing
1672 * Check the discussions for any indicators the fix might be too risky to get
1673 backported to the version line you care about. If that's the case you have
1674 to live with the issue or switch to the kernel version line where the fix
1679 you would like to see it fixed, if suitable.
1685 *One of the former steps should lead to a solution. If that doesn't work
1686 out, ask the maintainers for the subsystem that seems to be causing the
1690 If the previous three steps didn't get you closer to a solution there is only
1691 one option left: ask for advice. Do that in a mail you sent to the maintainers
1692 for the subsystem where the issue seems to have its roots; CC the mailing list
1696 Appendix: Why it is somewhat hard to report kernel bugs
1699 The Linux kernel developers are well aware that reporting bugs to them is harder
1705 outdated codebases as well as modifications and add-ons lead to kernel bugs
1708 but the situation is a lot worse when it comes to the kernel, as the changes
1718 again is and effect caused by the multitude of features and drivers, due to
1720 to their code and even less about other areas.
1722 * *It is hard finding where to report issues to, among others, due to the lack
1724 dislike, but that's the situation everyone has to deal with currently.
1731 interest shove it to the regular developers, as those know the code best.
1733 * *Linux developers are free to focus on latest mainline.* Some, thus, react
1734 coldly to reports about bugs in, say, Linux 6.0 when 6.1 is already out;
1736 be very welcoming to reports with 6.1.5 or 6.1.6, as the problem might be a
1739 * *Sometimes there is nobody to help.* Sometimes this is due to the lack of
1742 manufacturer left it behind. Other times there is nobody to even report bugs
1743 to: when maintainers move on without a replacement, their code often remains
1746 Some of these aspects could be improved to facilitate bug reporting -- many
1754 you spot a typo or small mistake, feel free to let him know directly and
1755 he'll fix it. You are free to do the same in a mostly informal way if you
1756 want to contribute changes to the text, but for copyright reasons please CC
1762 of the file. If you want to distribute this text under CC-BY-4.0 only,