Lines Matching +full:keep +full:- +full:a +full:- +full:live
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
11 Are you facing a regression with vanilla kernels from the same stable or
23 expect to be told about problems, which most of the time will be by email with a
27 <https://kernel.org/>`_. If the issue is present there, send a report.
29 The issue was fixed there, but you would like to see it resolved in a still
35 **General remarks**: When installing and testing a kernel as outlined above,
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
42 issue, like the kernel and the distro used. In case of a regression, CC the
44 to pin-point the culprit with a bisection; if you succeed, include its
45 commit-id and CC everyone in the sign-off-by chain.
49 releases and sending a status update afterwards.
51 Step-by-step guide how to report issues to the kernel maintainers
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
59 out a lot of details; those are described below the step-by-step guide in a
62 Note: this section covers a few more aspects than the TL;DR and does things in
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
68 * Are you facing an issue with a Linux kernel a hardware or software vendor
74 * Perform a rough search for existing reports with your favorite internet
77 join the discussion instead of sending a new one.
80 issue, or a really severe problem: those are 'issues of high priority' that
86 * Create a fresh backup and put system repair and restore tools at hand.
89 kernel modules on-the-fly, which solutions like DKMS might be doing locally
97 work independently on a freshly booted system. That's needed, as each issue
101 * If you are facing a regression within a stable or longterm version line
103 'Dealing with regressions within a stable and longterm kernel line'.
108 by mail to a maintainer and a public mailing list.
112 join the discussion instead of sending a new report.
121 suspend your efforts for a few days anyway. Whatever version you choose,
122 ideally use a 'vanilla' build. Ignoring these advices will dramatically
138 * If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider
141 * If your problem is a regression, try to narrow down when the issue was
144 * Start to compile the report by writing a detailed description about the
145 issue. Always mention a few things: the latest kernel version you installed
151 you wrote this main part, insert a normal length paragraph on top of it
154 thing a descriptive title or subject that yet again is shorter. Then you're
160 * Wait for reactions and keep the thing rolling until you can accept the
161 outcome in one way or the other. Thus react publicly and in a timely manner
163 least every first release candidate (RC) of a new mainline version and
168 Reporting regressions within a stable and longterm kernel line
169 --------------------------------------------------------------
172 the point about regression within a stable or longterm kernel version line. You
173 face one of those if something breaks when updating from 5.10.4 to 5.10.5 (a
175 regressions as quickly as possible, hence there is a streamlined process to
186 * Install the latest release from the particular version line as a vanilla
189 problem with a vendor kernel, check a vanilla build of the last version
192 * Send a short problem report to the Linux stable mailing list
194 (regressions@lists.linux.dev); if you suspect the cause in a particular
204 -------------------------------------------------------------
208 see the issue fixed in a still supported stable or longterm series or vendor
216 within a stable and longterm kernel line" above.
222 or peer-review possible fixes; then check the discussions if the fix was
226 * One of the former steps should lead to a solution. If that doesn't work
240 what this section is for, as it will provide a lot more details on each of the
242 from top to bottom. But it's mainly meant to skim over and a place to look up
245 A few words of general advice before digging into the details:
253 * A warranty or support contract with some vendor doesn't entitle you to
257 anything such a contract guarantees in this context, not even if the
264 * If you never reported an issue to a FLOSS project before you should consider
268 <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to ask good
269 questions <https://jvns.ca/blog/good-questions/>`_.
276 ------------------------------------------------
278 *Are you facing an issue with a Linux kernel a hardware or software vendor
286 just a waste everybody's time, especially yours. Unfortunately such situations
288 sides. That's because almost all Linux-based kernels pre-installed on devices
304 option for you move ahead in this process, as a later step in this guide will
311 small modifications to a kernel based on a recent Linux version; that for
316 regular Fedora releases, and openSUSE Tumbleweed. But keep in mind, you better
317 want to use a mainline Linux and avoid using a stable kernel for this
318 process, as outlined in the section 'Install a fresh kernel for testing' in more
329 --------------------------------------
331 *Perform a rough search for existing reports with your favorite internet
334 sending a new one.*
336 Reporting an issue that someone else already brought forward is often a waste of
339 step of the process it's okay to just perform a rough search: a later step will
340 tell you to perform a more detailed search once you know where your issue needs
350 to use good search terms; vary them a few times, too. While doing so try to
362 important even when a fix is prepared or in its final stages already, as
364 test a proposed fix. Jump to the section 'Duties after the report went out' for
368 be a good idea, as that might provide valuable insights or turn up matching
369 reports. If you find the latter, just keep in mind: most subsystems expect
378 -----------------------
381 issue, or a really severe problem: those are 'issues of high priority' that
389 You deal with a regression if some application or practical use case running
390 fine with one Linux kernel works worse or not at all with a newer version
391 compiled using a similar configuration. The document
392 Documentation/admin-guide/reporting-regressions.rst explains this in more
393 detail. It also provides a good deal of other information about regressions you
398 Documentation/process/security-bugs.rst before proceeding, as it
401 An issue is a 'really severe problem' when something totally unacceptably bad
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
405 panic') or without any farewell note at all. Note: do not confuse a 'panic' (a
406 fatal error where the kernel stop itself) with a 'Oops' (a recoverable error),
410 Ensure a healthy environment
411 ----------------------------
416 Problems that look a lot like a kernel issue are sometimes caused by build or
425 motherboard. Therefore, stop undervolting or overclocking when facing a
429 main memory for example can result in a multitude of issues that will
432 * If you're dealing with a filesystem issue, you might want to check the file
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
439 happen that a hardware component coincidentally just broke when you rebooted
440 into a new kernel for the first time. Updating the systems BIOS or changing
441 something in the BIOS Setup can also lead to problems that on look a lot
442 like a kernel regression.
446 -----------------------
448 *Create a fresh backup and put system repair and restore tools at hand.*
453 create a fresh backup; also ensure you have all tools at hand to repair or
459 ------------------------------------------
462 kernel modules on-the-fly, which solutions like DKMS might be doing locally
467 mechanisms like akmods and DKMS: those build add-on kernel modules
468 automatically, for example when you install a new Linux kernel or boot it for
474 driver, VirtualBox, or other software that requires a some support from a
480 ------------------
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
494 On a running system is easy to check if the kernel tainted itself: if ``cat
498 problem (a 'kernel bug'), a recoverable error (a 'kernel Oops') or a
499 non-recoverable error before halting operation (a 'kernel panic'). Look near
500 the top of the error messages printed when one of these occurs and search for a
503 followed by a few spaces and some letters.
505 If your kernel is tainted, study Documentation/admin-guide/tainted-kernels.rst
509 1. A recoverable error (a 'kernel Oops') occurred and the kernel tainted
511 point. In that case check your kernel or system log and look for a section
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.
521 a change to the configuration followed by a reboot can eliminate the Oops.
526 2. Your system uses a software that installs its own kernel modules, for
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
539 quality standards. When you report an issue with such a module it's
548 -------------------------------
552 work independently on a freshly booted system. That's needed, as each issue
564 you know exactly how to reproduce an issue quickly on a freshly booted system.
567 might be caused by a bit flip due to cosmic radiation. That's why you should
569 to ignore this advice if you are experienced enough to tell a one-time error
570 due to faulty hardware apart from a kernel issue that rarely happens and thus
575 ----------------------------------------
577 *If you are facing a regression within a stable or longterm version line
579 'Dealing with regressions within a stable and longterm kernel line'.*
581 Regression within a stable and longterm kernel version line are something the
583 regression in the main development branch, as they can quickly affect a lot of
585 possible, hence there is a streamlined process to report them. Note,
591 -----------------------------------------
596 by mail to a maintainer and a public mailing list.*
598 It's crucial to send your report to the right people, as the Linux kernel is a
599 big project and most of its developers are only familiar with a small subset of
600 it. Quite a few programmers for example only care for just one driver, for
601 example one for a WiFi chip; its developer likely will only have small or no
605 Problem is: the Linux kernel lacks a central bug tracker where you can simply
608 You can do that with the help of a script (see below), but it mainly targets
621 Sadly, there is no way to check which code is driving a particular hardware
624 In case of a problem with the WiFi driver you for example might want to look at
625 the output of ``lspci -k``, as it lists devices on the PCI/PCIe bus and the
628 [user@something ~]$ lspci -k
630 … 3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
642 …[user@something ~]$ realpath --relative-to=/sys/module/ /sys/class/net/wlp58s0/device/driver/module
653 but before doing so, try a somewhat shorted or modified name when searching the
657 Mail: A. Some Human <shuman@example.com>
660 Web-page: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
667 A section near the top of the file explains these and other abbreviations.
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
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
678 you where to find a subsystem specific bug tracker to file your issue. The
679 example above does not have such a line. That is the case for most sections, as
681 a bug tracker, and only some of those rely on bugzilla.kernel.org.
685 maintainers of the particular code. Also look for a line starting with 'Mailing
689 (LKML) <linux-kernel@vger.kernel.org> to CC. Don't omit either of the mailing
695 Finding the maintainers with the help of a script
698 For people that have the Linux sources at hand there is a second option to find
701 called with a path to the source code in question. For drivers compiled as
702 module if often can be found with a command like this::
709 $ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k*
713 linux-wireless@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS))
715 linux-kernel@vger.kernel.org (open list)
721 'ath10k@lists.infradead.org' and 'linux-kernel@vger.kernel.org' in CC.
724 ``get_maintainer.pl`` a second time with ``--git``. The script then will look
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
734 ---------------------------------------
738 join the discussion instead of sending a new report.*
741 brought forward is often a waste of time for everyone involved, especially you
753 quite a few other lists miss a way to search the archives. In those cases use a
759 at this point. If your report needs to be filed in a bug tracker, you may want
767 or even more time can save you and others quite a lot of time and trouble.
770 Install a fresh kernel for testing
771 ----------------------------------
778 suspend your efforts for a few days anyway. Whatever version you choose,
779 ideally use a 'vanilla' built. Ignoring these advices will dramatically
784 reports for issues that don't even happen with the current code. It's just a
793 * Install a mainline kernel; the latest stable kernel can be an option, but
798 * The over next subsection describes way to obtain and install such a kernel.
799 It also outlines that using a pre-compiled kernel are fine, but better are
808 and look a little lower at the table. At its top you'll see a line starting with
809 mainline, which most of the time will point to a pre-release with a version
810 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
813 made a backup, as you were instructed above, didn't you?
815 In about two out of every nine to ten weeks, mainline might point you to a
816 proper release with a version number like '5.7'. If that happens, consider
817 suspending the reporting process until the first pre-release of the next
818 version (5.8-rc1) shows up on kernel.org. That's because the Linux development
819 cycle then is in its two-week long 'merge window'. The bulk of the changes and
820 all intrusive ones get merged for the next release during this time. It's a bit
825 a newer kernel version anyway, as outlined below in the section 'Duties after
840 take a few days or weeks. Another reason: the fix you hope for might be too
850 How to obtain a fresh Linux kernel
853 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
855 problem: most of those shipped by distributors or add-on repositories are build
860 But you are in luck if you are using a popular Linux distribution: for quite a
866 are older than a week, as new mainline and stable kernels typically get released
867 at least once a week.
871 document. Also be aware that pre-compiled kernels might lack debug symbols that
872 are needed to decode messages the kernel prints when a panic, Oops, warning, or
873 BUG occurs; if you plan to decode those, you might be better off compiling a
881 Those are likely a bit ahead of the latest mainline pre-release. Don't worry
882 about it: they are as reliable as a proper pre-release, unless the kernel's
883 development cycle is currently in the middle of a merge window. But even then
889 How to actually build a kernel is not described here, as many websites explain
891 those how-to's that suggest to use ``make localmodconfig``, as that tries to
896 Note: If you are dealing with a panic, Oops, warning, or BUG from the kernel,
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
911 ------------------
916 As outlined above in more detail already: the kernel sets a 'taint' flag when
917 something happens that can lead to follow-up errors that look totally
925 -------------------------------------
933 line and abandoning your plan to report the issue. But keep in mind that other
942 ---------------------------------------
951 report. Thus try to find a reproducer that's straight forward to describe and
953 the same time try to keep it as short as possible.
955 In this in the previous steps you likely have learned a thing or two about the
961 -----------------------
963 *If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider
971 kernel's log. That will make it a lot easier to understand what lead to the
973 can provide a fix.
975 Decoding can be done with a script you find in the Linux source tree. If you
976 are running a kernel you compiled yourself earlier, call it like this::
978 …[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux
980 If you are running a packaged vanilla kernel, you will likely have to install
985 [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \
986 /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/
995 …[ 68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:1…
998 '~/linux-5.10.5/test-module/test-module.c' and the error occurred by the
1015 ----------------------------
1017 *If your problem is a regression, try to narrow down when the issue was
1022 fixed quickly. That's why changes that introduced a regression are often
1024 way. Reporting a regression is thus a bit like playing a kind of trump card to
1030 To find the change there is a process called 'bisection' which the document
1031 Documentation/admin-guide/bug-bisect.rst describes in detail. That process
1034 some time, but don't worry, it works a lot quicker than most people assume.
1035 Thanks to a 'binary search' this will lead you to the one commit in the source
1041 Note, a bisection needs a bit of know-how, which not everyone has, and quite a
1043 highly recommended performing a bisection yourself. If you really can't or
1047 5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
1048 regression in a stable or longterm kernel, avoid testing versions which number
1052 process. But keep in mind: it depends on the issue at hand if the developers
1055 be unable to help unless you perform a bisection.
1060 In the whole process keep in mind: an issue only qualifies as regression if the
1061 older and the newer kernel got built with a similar configuration. This can be
1063 Documentation/admin-guide/reporting-regressions.rst; that document also
1064 provides a good deal of other information about regressions you might want to be
1069 -------------------------
1071 *Start to compile the report by writing a detailed description about the
1072 issue. Always mention a few things: the latest kernel version you installed
1078 you wrote this main part, insert a normal length paragraph on top of it
1081 thing a descriptive title or subject that yet again is shorter. Then you're
1089 That's why this text will only mention a few of the essentials as well as
1094 Developers often get quite a lot of mail. They thus often just take a few
1095 seconds to skim a mail before deciding to move on or look closer. Thus: the
1098 and write the detailed report first. ;-)
1104 installed. Try to include the step-by-step instructions you wrote and optimized
1110 issue and its environment. What's actually needed depends a lot on the issue,
1119 * the architecture of the CPU and the operating system (``uname -mi``)
1121 * if you are dealing with a regression and performed a bisection, mention the
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
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
1134 ``journalctl -b 0 -k``; alternatively you can also reboot, reproduce the
1137 These two files are big, that's why it's a bad idea to put them directly into
1138 your report. If you are filing the issue in a bug tracker then attach them to
1142 * Upload the files somewhere public (your website, a public file paste
1143 service, a ticket created just for this purpose on `bugzilla.kernel.org
1144 <https://bugzilla.kernel.org/>`_, ...) and include a link to them in your
1147 happen if five or ten years from now a developer works on some code that was
1152 went out. ;-)
1157 Depending on the issue you might need to add more background data. Here are a
1160 * If you are dealing with a 'warning', an 'OOPS' or a 'panic' from the kernel,
1161 include it. If you can't copy'n'paste it, try to capture a netconsole trace
1162 or at least take a picture of the screen.
1166 mention its manufacturer, the card's model, and what chip is uses. If it's a
1173 variants of this laptop with and without a dedicated graphics chip, so try
1179 libdrm and Mesa; also specify your Wayland compositor or the X-Server and
1180 its driver. If you have a filesystem issue, mention the version of
1181 corresponding filesystem utilities (e2fsprogs, btrfs-progs, xfsprogs, ...).
1184 output from ``lspci -nn`` will for example help others to identify what
1185 hardware you use. If you have a problem with hardware you even might want to
1186 make the output from ``sudo lspci -vvv`` available, as that provides
1191 information. One such tool is ``alsa-info.sh`` `which the audio/sound
1192 subsystem developers provide <https://www.alsa-project.org/wiki/AlsaInfo>`_.
1198 the start increases the chance someone will take a closer look.
1210 think this bug affects a lot of users, mention this to get people interested.
1212 Once you did that insert two more lines at the top and write a one sentence
1217 most important parts of your report: a lot of people will only read this before
1235 In case you performed a successful bisection, use the title of the change that
1239 and the oldest where the issue occurs (say 5.8-rc1).
1246 Also add a short note at the top where you mention the URL to the ticket.
1248 When mailing or forwarding the report, in case of a successful bisection add the
1249 author of the culprit to the recipients; also CC everyone in the signed-off-by
1252 **Security issues**: for these issues your will have to evaluate if a
1253 short-term risk to other users would arise if details were publicly disclosed.
1255 For issues that bear such a risk you will need to adjust the reporting process
1261 * If you were supposed to file the issue in a bug tracker make sure to mark
1263 offer a way to keep reports private, forget about it and send your report as
1264 a private mail to the maintainers instead.
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.
1272 See Documentation/process/security-bugs.rst for more information.
1276 --------------------------------
1278 *Wait for reactions and keep the thing rolling until you can accept the
1279 outcome in one way or the other. Thus react publicly and in a timely manner
1281 least every first release candidate (RC) of a new mainline version and
1286 might immediately spot what's causing the issue; they then might write a patch
1289 all you need to do is reply with a 'Thank you very much' and switch to a version
1295 details, here are a few important things you need to keep in mind for this part
1302 **Always reply in public**: When you filed the issue in a bug tracker, always
1304 mailed reports always use the 'Reply-all' function when replying to any mails
1306 to your report: go to your mail applications 'Sent' folder and use 'reply-all'
1312 There are just two situations where a comment in a bug tracker or a 'Reply-all'
1319 in private to the developer that asked for it. But note in the ticket or a
1323 process someone might tell you to do something that requires a skill you might
1325 you never have heard of yet; or you might be asked to apply a patch to the
1327 a reply asking for instructions how to do that. But before going that route try
1329 consider asking in other places for advice. For example ask a friend or post
1330 about it to a chatroom or forum you normally hang out.
1332 **Be patient**: If you are really lucky you might get a reply to your report
1333 within a few hours. But most of the time it will take longer, as maintainers
1334 are scattered around the globe and thus might be in a different time zone – one
1339 windows, other work, visiting developer conferences, or simply enjoying a long
1344 should wait a week at maximum (or just two days if it's something urgent)
1345 before sending a friendly reminder.
1347 Sometimes the maintainer might not be responding in a timely manner; other
1351 might be appropriate to get a higher authority involved. In case of a WiFi
1356 **Proactive testing**: Every time the first pre-release (the 'rc1') of a new
1358 or if anything of importance changed. Mention the outcome in the ticket or in a
1362 issue persists and makes sure they do not forget about it. A few other
1363 occasional retests (for example with rc3, rc5 and the final) are also a good
1375 **Check who you deal with**: Most of the time it will be the maintainer or a
1382 the right people, as a reminder to the maintainer (see below) might be in order
1383 later if discussion fades out without leading to a satisfying solution for the
1390 a few business days.
1392 **Requests for testing**: When you are asked to test a diagnostic patch or a
1394 sure to not rush it: mixing things up can happen easily and can lead to a lot
1395 of confusion for everyone involved. A common mistake for example is thinking a
1396 proposed patch with a fix was applied, but in fact wasn't. Things like that
1404 developers; or a discussion around the issue evolved, but faded out with
1407 In these cases wait two (better: three) weeks before sending a friendly
1408 reminder: maybe the maintainer was just away from keyboard for a while when
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
1414 situations where such a 'TOFU' (Text Over, Fullquote Under) is the right
1418 After the reminder wait three more weeks for replies. If you still don't get a
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
1429 If the report was proper you can send a second reminder; in it ask for advice
1430 why the report did not get any replies. A good moment for this second reminder
1431 mail is shortly after the first pre-release (the 'rc1') of a new Linux kernel
1432 version got published, as you should retest and provide a status update at that
1435 If the second reminder again results in no reaction within a week, try to
1436 contact a higher-level maintainer asking for advice: even busy maintainers by
1439 Remember to prepare yourself for a disappointment: maintainers ideally should
1442 get a reply along the lines of 'thanks for the report, I have more important
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
1456 them to get the issue resolved. Such a team could prepare a fresh report
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
1461 bit about programming and might be able to write a fix.
1464 Reference for "Reporting regressions within a stable and longterm kernel line"
1465 ------------------------------------------------------------------------------
1468 a regression within a stable and longterm kernel line.
1479 maintaining them longer is quite a lot of work. Hence, only one per year is
1486 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1488 kernel.org front page for a week or two, but are unsuitable for testing and
1505 *Install the latest release from the particular version line as a vanilla
1508 problem with a vendor kernel, check a vanilla build of the last version
1514 happens, as detailed outlined already above in the section "Install a fresh
1517 Did you first notice the regression with a vendor kernel? Then changes the
1519 a recheck. Say something broke when you updated from 5.10.4-vendor.42 to
1520 5.10.5-vendor.43. Then after testing the latest 5.10 release as outlined in
1521 the previous paragraph check if a vanilla build of Linux 5.10.4 works fine as
1523 regression and you need switch back to the main step-by-step guide to report
1529 *Send a short problem report to the Linux stable mailing list
1531 (regressions@lists.linux.dev); if you suspect the cause in a particular
1537 When reporting a regression that happens within a stable or longterm kernel
1538 line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
1539 the start to get the issue reported quickly. Hence a rough description to the
1541 the cause in a particular subsystem, CC its maintainers and its mailing list
1544 And note, it helps developers a great deal if you can specify the exact version
1545 that introduced the problem. Hence if possible within a reasonable time frame,
1547 your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
1549 5.10.9. If it shows the problem, try a vanilla 5.10.5 to ensure that no patches
1555 What the previous paragraph outlines is basically a rough manual 'bisection'.
1556 Once your report is out your might get asked to do a proper one, as it allows to
1558 reverted to fix the issue quickly). Hence consider to do a proper bisection
1560 the document Documentation/admin-guide/bug-bisect.rst for details how to
1561 perform one. In case of a successful bisection add the author of the culprit to
1562 the recipients; also CC everyone in the signed-off-by chain, which you find at
1567 -----------------------------------------------------------------------------
1570 reproduce your issue with a mainline kernel, but want to see it fixed in older
1580 Even small and seemingly obvious code-changes sometimes introduce new and
1583 within rules outlined in Documentation/process/stable-kernel-rules.rst.
1590 live with the issue or switch to a newer Linux version, unless you want to
1599 You need to carry out a few steps already described in another section of this
1617 or peer-review possible fixes; then check the discussions if the fix was
1621 In a lot of cases the issue you deal with will have happened with mainline, but
1630 a local clone you alternatively can search on the command line with ``git
1631 log --grep=<pattern>``.
1633 If you find the fix, look if the commit message near the end contains a
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
1651 outlined above, as the commit might tell you if a backport can be expected.
1655 to live with the issue or switch to the kernel version line where the fix
1658 * If the fix doesn't contain a stable tag and backporting was not discussed,
1666 *One of the former steps should lead to a solution. If that doesn't work
1671 If the previous three steps didn't get you closer to a solution there is only
1672 one option left: ask for advice. Do that in a mail you sent to the maintainers
1680 When reporting a problem to the Linux developers, be aware only 'issues of high
1683 will make sure of that. They and the other kernel developers will fix a lot of
1685 sometimes there isn't even anyone to send a report to.
1688 kernel in their spare time. Quite a few of the drivers in the kernel were
1706 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
1708 removing would be a regression.
1714 mainly by selling new hardware; quite a few of them hence are not investing
1715 much time and energy in maintaining a Linux kernel driver for something they
1716 stopped selling years ago. Enterprise Linux distributors often care for a
1719 a company orphans some code, but as mentioned above: sooner or later they will
1726 get overwhelmed with reports, even if a driver is working nearly perfectly. To
1730 But don't worry too much about all of this, a lot of drivers have active
1745 end-of-content
1748 you spot a typo or small mistake, feel free to let him know directly and
1749 he'll fix it. You are free to do the same in a mostly informal way if you
1751 linux-doc@vger.kernel.org and "sign-off" your contribution as
1752 Documentation/process/submitting-patches.rst outlines in the section "Sign
1753 your work - the Developer's Certificate of Origin".
1755 This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
1756 of the file. If you want to distribute this text under CC-BY-4.0 only,
1759 …rg/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
1762 is available under CC-BY-4.0, as versions of this text that were processed
1764 files which use a more restrictive license.