Lines Matching +full:look +full:- +full:up
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.
47 Once the report is out, answer any questions that come up and help where you
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
129 up there, scroll down to the instructions for issues only happening with
169 --------------------------------------------------------------
204 -------------------------------------------------------------
222 or peer-review possible fixes; then check the discussions if the fix was
242 from top to bottom. But it's mainly meant to skim over and a place to look up
250 which would need constant maintenance; nobody has stepped up to do that
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
298 face, even if they look small or totally unrelated. That's why you should report
299 issues with these kernels to the vendor. Its developers should look into the
329 --------------------------------------
351 look at the issue from the perspective of someone else: that will help you to
352 come up with other words to use as search terms. Also make sure not to use too
363 developers might look for people that can provide additional information or
368 be a good idea, as that might provide valuable insights or turn up matching
378 -----------------------
392 Documentation/admin-guide/reporting-regressions.rst explains this in more
398 Documentation/process/security-bugs.rst before proceeding, as it
411 ----------------------------
416 Problems that look a lot like a kernel issue are sometimes caused by build or
441 something in the BIOS Setup can also lead to problems that on look a lot
446 -----------------------
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
480 ------------------
486 lead to follow-up errors that look totally unrelated. The issue you face might
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
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.
518 follow-up problem to that first Oops, even if both look totally unrelated.
548 -------------------------------
569 to ignore this advice if you are experienced enough to tell a one-time error
575 ----------------------------------------
591 -----------------------------------------
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
638 the output of ``ip link``. Look for the name of the problematic network
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
669 First look at the line 'Status'. Ideally it should be 'Supported' or
677 After checking the status, look for a line starting with 'bugs:': it will tell
683 In this and many other cases you thus have to look for lines starting with
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
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 ---------------------------------------
771 ----------------------------------
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
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
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
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
892 pick up the configuration of your current kernel and then tries to adjust it
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
942 ---------------------------------------
961 -----------------------
978 …[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux
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/
993 Once decoded, these lines will look like this::
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 ----------------------------
1026 the regression needs to be known. Normally it's up to the reporter to track
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
1047 5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
1063 Documentation/admin-guide/reporting-regressions.rst; that document also
1069 -------------------------
1095 seconds to skim a mail before deciding to move on or look closer. Thus: the
1097 will look into it and help you. And that is why you should ignore them for now
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.
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>`_.
1198 the start increases the chance someone will take a closer look.
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 --------------------------------
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'
1356 **Proactive testing**: Every time the first pre-release (the 'rc1') of a new
1360 that up to that point participated in the discussion). This will show your
1394 sure to not rush it: mixing things up can happen easily and can lead to a lot
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
1443 issues to deal with currently and won't have time to look into this for the
1455 You for example could try to find others that are affected and team up with
1465 ------------------------------------------------------------------------------
1486 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
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
1542 as well, because that will speed things up.
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
1567 -----------------------------------------------------------------------------
1580 Even small and seemingly obvious code-changes sometimes introduce new and
1583 within rules outlined in Documentation/process/stable-kernel-rules.rst.
1617 or peer-review possible fixes; then check the discussions if the fix was
1631 log --grep=<pattern>``.
1633 If you find the fix, look if the commit message near the end contains a
1642 * If the commit doesn't tell you anything or if you can't find the fix, look
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
1762 is available under CC-BY-4.0, as versions of this text that were processed