Lines Matching +full:get +full:- +full:only
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
36 ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
45 commit-id and CC everyone in the sign-off-by chain.
51 Step-by-step guide how to report issues to the kernel maintainers
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
89 kernel modules on-the-fly, which solutions like DKMS might be doing locally
98 needs to get reported to the kernel developers separately, unless they are
129 up there, scroll down to the instructions for issues only happening with
165 help yourself, if you don't get any help or if it's unsatisfying.
169 --------------------------------------------------------------
203 Reporting issues only occurring in older kernel version lines
204 -------------------------------------------------------------
212 might not get the issue solved in older releases: the fix might be too big
213 or risky to get backported there.
222 or peer-review possible fixes; then check the discussions if the fix was
261 upstream Linux kernel; motivate them by saying it's the only way to ensure
262 the fix in the end will get incorporated in all Linux distributions.
268 <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to ask good
269 questions <https://jvns.ca/blog/good-questions/>`_.
276 ------------------------------------------------
288 sides. That's because almost all Linux-based kernels pre-installed on devices
310 issue in question. Your chances are quite good if the distributor applied only
315 it's only slightly modified; that for example is often the case for Arch Linux,
323 those often get rejected or ignored, so consider yourself warned. But it's still
325 indirectly will help to get the issue fixed over time.
329 --------------------------------------
348 If you get flooded with results consider telling your search engine to limit
365 details on how to get properly involved.
378 -----------------------
385 fixed as soon as possible, hence there are 'issues of high priority' that get
392 Documentation/admin-guide/reporting-regressions.rst explains this in more
398 Documentation/process/security-bugs.rst before proceeding, as it
411 ----------------------------
446 -----------------------
458 Make sure your kernel doesn't get enhanced
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
473 they often get set up silently when you install Nvidia's proprietary graphics
476 packages with such software to get rid of any 3rd party kernel module.
480 ------------------
486 lead to follow-up errors that look totally unrelated. The issue you face might
489 only reason why this step is here, as this process later will tell you to
499 non-recoverable error before halting operation (a 'kernel panic'). Look near
505 If your kernel is tainted, study Documentation/admin-guide/tainted-kernels.rst
516 That's the first Oops since boot-up, as the '#1' between the brackets shows.
518 follow-up problem to that first Oops, even if both look totally unrelated.
541 question is the only reason for the taint. If the issue happens in an
548 -------------------------------
553 needs to get reported to the kernel developers separately, unless they are
559 it apart. Hence, only combine issues in one report if they are very strongly
566 Note: it's often fruitless to report issues that only happened once, as they
569 to ignore this advice if you are experienced enough to tell a one-time error
575 ----------------------------------------
591 -----------------------------------------
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
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
628 [user@something ~]$ lspci -k
642 …[user@something ~]$ realpath --relative-to=/sys/module/ /sys/class/net/wlp58s0/device/driver/module
660 Web-page: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
672 only has someone who provides 'Odd Fixes' when feeling motivated. And with
674 That only leaves these options: arrange yourself to live with the issue, fix it
681 a bug tracker, and only some of those rely on bugzilla.kernel.org.
689 (LKML) <linux-kernel@vger.kernel.org> to CC. Don't omit either of the mailing
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
729 modified during tree-wide cleanups by developers that do not care about the
734 ---------------------------------------
761 have reported it only there.
771 ----------------------------------
789 get rejected or simply ignored.
799 It also outlines that using a pre-compiled kernel are fine, but better are
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
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
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
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
866 are older than a week, as new mainline and stable kernels typically get released
871 document. Also be aware that pre-compiled kernels might lack debug symbols that
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
891 those how-to's that suggest to use ``make localmodconfig``, as that tries to
899 latter is the relevant one of those two, but can only be reached if you enable
911 ------------------
917 something happens that can lead to follow-up errors that look totally
925 -------------------------------------
928 up there, scroll down to the instructions for issues only happening with
937 head over to the section "Details about reporting issues only occurring in
942 ---------------------------------------
961 -----------------------
968 source code that triggered the issue and shows how it was called. But that only
978 …[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux
982 might need to get from the Linux sources if your distro does not package it)
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
1006 Note, if you can't get this to work, simply skip this step and mention the
1008 is, someone might help you to get things going. Also be aware this is just one
1015 ----------------------------
1023 promptly reverted if the issue they cause can't get solved quickly any other
1025 get something quickly fixed. But for that to happen the change that's causing
1031 Documentation/admin-guide/bug-bisect.rst describes in detail. That process
1041 Note, a bisection needs a bit of know-how, which not everyone has, and quite a
1060 In the whole process keep in mind: an issue only qualifies as regression if the
1063 Documentation/admin-guide/reporting-regressions.rst; that document also
1069 -------------------------
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
1098 and write the detailed report first. ;-)
1104 installed. Try to include the step-by-step instructions you wrote and optimized
1119 * the architecture of the CPU and the operating system (``uname -mi``)
1122 subject and the commit-id of the change that is causing it.
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
1152 went out. ;-)
1179 libdrm and Mesa; also specify your Wayland compositor or the X-Server and
1181 corresponding filesystem utilities (e2fsprogs, btrfs-progs, xfsprogs, ...).
1184 output from ``lspci -nn`` will for example help others to identify what
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>`_.
1204 Now that you have the detailed part of the report prepared let's get to the
1210 think this bug affects a lot of users, mention this to get people interested.
1214 get even more abstract and write an even shorter subject/title for the report.
1217 most important parts of your report: a lot of people will only read this before
1239 and the oldest where the issue occurs (say 5.8-rc1).
1249 author of the culprit to the recipients; also CC everyone in the signed-off-by
1253 short-term risk to other users would arise if details were publicly disclosed.
1272 See Documentation/process/security-bugs.rst for more information.
1276 --------------------------------
1283 help yourself, if you don't get any help or if it's unsatisfying.*
1292 But this ideal scenario rarely happens. That's why the job is only starting
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'
1332 **Be patient**: If you are really lucky you might get a reply to your report
1351 might be appropriate to get a higher authority involved. In case of a WiFi
1354 it's okay to get Linus Torvalds involved.
1356 **Proactive testing**: Every time the first pre-release (the 'rc1') of a new
1364 idea, but only report your results if something relevant changed or if you are
1367 With all these general things off the table let's get into the details of how
1368 to help to get issues resolved once they were reported.
1381 interacting with. By doing this you also get aware if your report was heard by
1403 Some reports will not get any reaction from the responsible Linux kernel
1411 get the ball running somehow. If the report got out by mail, do that in the
1418 After the reminder wait three more weeks for replies. If you still don't get a
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
1436 contact a higher-level maintainer asking for advice: even busy maintainers by
1440 react somehow to every issue report, but they are only obliged to fix those
1442 get a reply along the lines of 'thanks for the report, I have more important
1450 getting help are explained in 'Why some issues won't get any reaction or remain
1453 Don't get devastated if you don't find any help or if the issue in the end does
1454 not get solved: the Linux kernel is FLOSS and thus you can still help yourself.
1456 them to get the issue resolved. Such a team could prepare a fresh report
1458 option should get fixed. Maybe together you can also narrow down the root cause
1465 ------------------------------------------------------------------------------
1478 Most kernel version lines only get supported for about three months, as
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"
1487 (EOL) stamp. Version lines that reached that point still get mentioned on the
1500 already finished and scheduled to get applied soon.
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
1523 regression and you need switch back to the main step-by-step guide to report
1539 the start to get the issue reported quickly. Hence a rough description to the
1556 Once your report is out your might get asked to do a proper one, as it allows to
1557 pinpoint the exact change that causes the issue (which then can easily get
1560 the document Documentation/admin-guide/bug-bisect.rst for details how to
1562 the recipients; also CC everyone in the signed-off-by chain, which you find at
1566 Reference for "Reporting issues only occurring in older kernel version lines"
1567 -----------------------------------------------------------------------------
1577 might not get the issue solved in older releases: the fix might be too big
1578 or risky to get backported there.*
1580 Even small and seemingly obvious code-changes sometimes introduce new and
1582 are very aware of that and thus only apply changes to these kernels that are
1583 within rules outlined in Documentation/process/stable-kernel-rules.rst.
1585 Complex or risky changes for example do not qualify and thus only get applied
1586 to mainline. Other fixes are easy to get backported to the newest stable and
1596 *Perform the first three steps in the section "Reporting issues only
1617 or peer-review possible fixes; then check the discussions if the fix was
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
1631 log --grep=<pattern>``.
1653 * Check the discussions for any indicators the fix might be too risky to get
1671 If the previous three steps didn't get you closer to a solution there is only
1677 Why some issues won't get any reaction or remain unfixed after being reported
1680 When reporting a problem to the Linux developers, be aware only 'issues of high
1682 to get resolved. The maintainers or if all else fails Linus Torvalds himself
1726 get overwhelmed with reports, even if a driver is working nearly perfectly. To
1727 not get completely stuck, the programmer thus might have no other choice than
1745 end-of-content
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
1761 Note: Only the content of this RST file as found in the Linux kernel sources
1762 is available under CC-BY-4.0, as versions of this text that were processed