Lines Matching +full:straight +full:- +full:forward
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
3 If you want to distribute this text under CC-BY-4.0 only, please use 'The
5 …rg/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
8 is available under CC-BY-4.0, as versions of this text that were processed
45 ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
53 to pin-point the culprit with a bisection; if you succeed, include its
54 commit-id and CC everyone in the sign-off-by chain.
60 Step-by-step guide how to report issues to the kernel maintainers
67 step-by-step approach. It still tries to be brief for readability and leaves
68 out a lot of details; those are described below the step-by-step guide in a
98 kernel modules on-the-fly, which solutions like DKMS might be doing locally
178 --------------------------------------------------------------
213 -------------------------------------------------------------
231 or peer-review possible fixes; then check the discussions if the fix was
277 <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to ask good
278 questions <https://jvns.ca/blog/good-questions/>`_.
285 ------------------------------------------------
297 sides. That's because almost all Linux-based kernels pre-installed on devices
310 upstream or forward the report there. In practice that often does not work out
338 --------------------------------------
345 Reporting an issue that someone else already brought forward is often a waste of
387 -----------------------
413 'Documentation/admin-guide/security-bugs.rst' before proceeding, as it
426 ----------------------------
461 -----------------------
474 ------------------------------------------
477 kernel modules on-the-fly, which solutions like DKMS might be doing locally
482 mechanisms like akmods and DKMS: those build add-on kernel modules
495 ------------------
501 lead to follow-up errors that look totally unrelated. The issue you face might
514 non-recoverable error before halting operation (a 'kernel panic'). Look near
520 If your kernel is tainted, study 'Documentation/admin-guide/tainted-kernels.rst'
531 That's the first Oops since boot-up, as the '#1' between the brackets shows.
533 follow-up problem to that first Oops, even if both look totally unrelated.
563 -------------------------------
584 to ignore this advice if you are experienced enough to tell a one-time error
590 ----------------------------------------
606 -----------------------------------------
640 the output of ``lspci -k``, as it lists devices on the PCI/PCIe bus and the
643 [user@something ~]$ lspci -k
657 …[user@something ~]$ realpath --relative-to=/sys/module/ /sys/class/net/wlp58s0/device/driver/module
675 Web-page: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
704 (LKML) <linux-kernel@vger.kernel.org> to CC. Don't omit either of the mailing
724 $ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k*
728 linux-wireless@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS))
730 linux-kernel@vger.kernel.org (open list)
736 'ath10k@lists.infradead.org' and 'linux-kernel@vger.kernel.org' in CC.
739 ``get_maintainer.pl`` a second time with ``--git``. The script then will look
744 modified during tree-wide cleanups by developers that do not care about the
749 ---------------------------------------
756 brought forward is often a waste of time for everyone involved, especially you
786 ----------------------------------
814 It also outlines that using a pre-compiled kernel are fine, but better are
815 vanilla, which means: it was built using Linux sources taken straight `from
824 mainline, which most of the time will point to a pre-release with a version
825 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
832 suspending the reporting process until the first pre-release of the next
833 version (5.8-rc1) shows up on kernel.org. That's because the Linux development
834 cycle then is in its two-week long 'merge window'. The bulk of the changes and
868 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
870 problem: most of those shipped by distributors or add-on repositories are build
886 document. Also be aware that pre-compiled kernels might lack debug symbols that
893 often best served by obtaining the latest Linux kernel sources straight from the
896 Those are likely a bit ahead of the latest mainline pre-release. Don't worry
897 about it: they are as reliable as a proper pre-release, unless the kernel's
906 those how-to's that suggest to use ``make localmodconfig``, as that tries to
926 ------------------
932 something happens that can lead to follow-up errors that look totally
940 -------------------------------------
957 ---------------------------------------
966 report. Thus try to find a reproducer that's straight forward to describe and
976 -----------------------
993 …[user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux
1000 [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \
1001 /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/
1010 …[ 68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:1…
1013 '~/linux-5.10.5/test-module/test-module.c' and the error occurred by the
1030 ----------------------------
1046 'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process
1056 Note, a bisection needs a bit of know-how, which not everyone has, and quite a
1083 -------------------------
1112 and write the detailed report first. ;-)
1118 installed. Try to include the step-by-step instructions you wrote and optimized
1133 * the architecture of the CPU and the operating system (``uname -mi``)
1136 subject and the commit-id of the change that is causing it.
1144 sure that it starts with a line like 'Linux version 5.8-1
1148 ``journalctl -b 0 -k``; alternatively you can also reboot, reproduce the
1166 went out. ;-)
1193 libdrm and Mesa; also specify your Wayland compositor or the X-Server and
1195 corresponding filesystem utilities (e2fsprogs, btrfs-progs, xfsprogs, ...).
1198 output from ``lspci -nn`` will for example help others to identify what
1200 make the output from ``sudo lspci -vvv`` available, as that provides
1205 information. One such tool is ``alsa-info.sh`` `which the audio/sound
1206 subsystem developers provide <https://www.alsa-project.org/wiki/AlsaInfo>`_.
1253 and the oldest where the issue occurs (say 5.8-rc1).
1257 tracker, proceed to do so. Once filed, forward the report by mail to the
1263 author of the culprit to the recipients; also CC everyone in the signed-off-by
1267 short-term risk to other users would arise if details were publicly disclosed.
1282 them when sending the report by mail. If you filed it in a bug tracker, forward
1286 See 'Documentation/admin-guide/security-bugs.rst' for more information.
1290 --------------------------------
1301 to fix it, test it, and send it straight for integration in mainline while
1318 mailed reports always use the 'Reply-all' function when replying to any mails
1320 to your report: go to your mail applications 'Sent' folder and use 'reply-all'
1326 There are just two situations where a comment in a bug tracker or a 'Reply-all'
1370 **Proactive testing**: Every time the first pre-release (the 'rc1') of a new
1438 to move forward. That might mean: prepare a better report and make those people
1445 mail is shortly after the first pre-release (the 'rc1') of a new Linux kernel
1450 contact a higher-level maintainer asking for advice: even busy maintainers by
1479 ------------------------------------------------------------------------------
1500 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1533 a recheck. Say something broke when you updated from 5.10.4-vendor.42 to
1534 5.10.5-vendor.43. Then after testing the latest 5.10 release as outlined in
1537 regression and you need switch back to the main step-by-step guide to report
1574 the document 'Documentation/admin-guide/bug-bisect.rst' for details how to
1576 the recipients; also CC everyone in the signed-off-by chain, which you find at
1581 -----------------------------------------------------------------------------
1594 Even small and seemingly obvious code-changes sometimes introduce new and
1597 within rules outlined in 'Documentation/process/stable-kernel-rules.rst'.
1631 or peer-review possible fixes; then check the discussions if the fix was
1645 log --grep=<pattern>``.
1763 linux-doc@vger.kernel.org and "sign-off" your contribution as
1764 Documentation/process/submitting-patches.rst outlines in the section "Sign
1765 your work - the Developer's Certificate of Origin".