Lines Matching +full:power +full:- +full:stable +full:- +full:time
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
20 Are you facing a regression with vanilla kernels from the same stable or
22 <https://lore.kernel.org/lkml/>`_ and the `Linux stable mailing list
23 <https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
25 <https://kernel.org/>`_. If it still shows the issue, report it to the stable
26 mailing list (stable@vger.kernel.org) and CC the regressions list
32 expect to be told about problems, which most of the time will be by email with a
39 supported stable or longterm series as well? Then install its latest release.
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
74 something else. These steps thus help to ensure the time you invest in this
98 kernel modules on-the-fly, which solutions like DKMS might be doing locally
110 * If you are facing a regression within a stable or longterm version line
112 'Dealing with regressions within a stable and longterm kernel line'.
116 time this won't be bugzilla.kernel.org, as issues typically need to be sent
127 the latest 'stable' Linux can be an acceptable alternative in some
139 stable and longterm kernels.
143 details, and at the same time is easy to read and understand for others
144 that hear about it for the first time. And if you learned something in this
177 Reporting regressions within a stable and longterm kernel line
178 --------------------------------------------------------------
181 the point about regression within a stable or longterm kernel version line. You
192 * Check the archives of the `Linux stable mailing list
193 <https://lore.kernel.org/stable/>`_ for existing reports.
201 * Send a short problem report to the Linux stable mailing list
202 (stable@vger.kernel.org) and CC the Linux regressions mailing list
213 -------------------------------------------------------------
216 above, but failed to reproduce your issue there; at the same time you want to
217 see the issue fixed in a still supported stable or longterm series or vendor
225 within a stable and longterm kernel line" above.
231 or peer-review possible fixes; then check the discussions if the fix was
238 as the stable mailing list.
277 <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to ask good
278 questions <https://jvns.ca/blog/good-questions/>`_.
285 ------------------------------------------------
293 Like most programmers, Linux kernel developers don't like to spend time dealing
295 just a waste everybody's time, especially yours. Unfortunately such situations
297 sides. That's because almost all Linux-based kernels pre-installed on devices
323 with kernels from distributions shipping the latest stable kernel, as long as
326 want to use a mainline Linux and avoid using a stable kernel for this
334 indirectly will help to get the issue fixed over time.
338 --------------------------------------
346 time for everyone involved, especially you as the reporter. So it's in your own
351 process, it can save you time and trouble.
387 -----------------------
405 increased power consumption also qualify as regression. But keep in mind: the
410 during build time configuration.
413 'Documentation/admin-guide/security-bugs.rst' before proceeding, as it
426 ----------------------------
453 caused by other software that was updated at the same time. It can also
455 into a new kernel for the first time. Updating the systems BIOS or changing
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
484 the first time. Also remove any modules they might have installed. Then reboot
495 ------------------
501 lead to follow-up errors that look totally unrelated. The issue you face might
503 rule this out early before investing more time into this process. This is the
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.
537 But don't invest too much time into this at this point of the process, as
547 Linux kernel developers. Most of the time the easiest way to do that is:
563 -------------------------------
584 to ignore this advice if you are experienced enough to tell a one-time error
589 Regression in stable or longterm kernel?
590 ----------------------------------------
592 *If you are facing a regression within a stable or longterm version line
594 'Dealing with regressions within a stable and longterm kernel line'.*
596 Regression within a stable and longterm kernel version line are something the
606 -----------------------------------------
610 time this won't be bugzilla.kernel.org, as issues typically need to be sent
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
782 or even more time can save you and others quite a lot of time and trouble.
786 ----------------------------------
790 the latest 'stable' Linux can be an acceptable alternative in some
798 programmers, Linux kernel developers don't like to spend time dealing with
800 waste everybody's time, especially yours. That's why it's in everybody's
808 * Install a mainline kernel; the latest stable kernel can be an option, but
809 most of the time is better avoided. Longterm kernels (sometimes called 'LTS
814 It also outlines that using a pre-compiled kernel are fine, but better are
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
835 all intrusive ones get merged for the next release during this time. It's a bit
837 quite busy then and might have no spare time to deal with issue reports. It's
846 latest stable version offered on kernel.org. Using that is also acceptable in
851 Better avoid using the latest stable kernel outside merge windows, as all fixes
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
877 latest mainline or stable Linux built as vanilla kernel. It's totally okay to
881 are older than a week, as new mainline and stable kernels typically get released
886 document. Also be aware that pre-compiled kernels might lack debug symbols that
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 -------------------------------------
944 stable and longterm kernels.*
949 users might still be plagued by it, as long as it's not fixed in either stable
957 ---------------------------------------
961 details, and at the same time is easy to read and understand for others
962 that hear about it for the first time. And if you learned something in this
968 the same time try to keep it as short as possible.
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 ----------------------------
1042 down the culprit, as maintainers often won't have the time or setup at hand to
1046 'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process
1049 some time, but don't worry, it works a lot quicker than most people assume.
1056 Note, a bisection needs a bit of know-how, which not everyone has, and quite a
1063 regression in a stable or longterm kernel, avoid testing versions which number
1083 -------------------------
1101 Now that you have prepared everything it's time to write your report. How to do
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>`_.
1230 Now that you have written this part take some time to optimize it, as it is the
1232 they decide if reading the rest is time well spent.
1253 and the oldest where the issue occurs (say 5.8-rc1).
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.
1286 See 'Documentation/admin-guide/security-bugs.rst' for more information.
1290 --------------------------------
1302 tagging it for later backport to stable and longterm kernels that need it. Then
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'
1322 list(s) and everyone else that gets involved over time stays in the loop; it
1326 There are just two situations where a comment in a bug tracker or a 'Reply-all'
1347 within a few hours. But most of the time it will take longer, as maintainers
1348 are scattered around the globe and thus might be in a different time zone – one
1370 **Proactive testing**: Every time the first pre-release (the 'rc1') of a new
1389 **Check who you deal with**: Most of the time it will be the maintainer or a
1411 happen even to experienced testers occasionally, but they most of the time will
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
1457 issues to deal with currently and won't have time to look into this for the
1478 Reference for "Reporting regressions within a stable and longterm kernel line"
1479 ------------------------------------------------------------------------------
1482 a regression within a stable and longterm kernel line.
1498 Note, if kernel.org lists two stable version lines on the front page, you
1500 support for it is likely to be abandoned soon. Then it will get a "end-of-life"
1505 Search stable mailing list
1508 *Check the archives of the Linux stable mailing list for existing reports.*
1511 `search the archives of the Linux stable mailing list
1512 <https://lore.kernel.org/stable/>`_ for reports about an issue like yours. If
1525 Before investing any more time in this process you want to check if the issue
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
1543 *Send a short problem report to the Linux stable mailing list
1544 (stable@vger.kernel.org) and CC the Linux regressions mailing list
1551 When reporting a regression that happens within a stable or longterm kernel
1554 stable and regressions mailing list is all it takes; but in case you suspect
1559 that introduced the problem. Hence if possible within a reasonable time frame,
1573 right away if time permits. See the section 'Special care for regressions' and
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 -----------------------------------------------------------------------------
1585 version lines (aka stable and longterm kernels).
1594 Even small and seemingly obvious code-changes sometimes introduce new and
1595 totally unexpected problems. The maintainers of the stable and longterm kernels
1597 within rules outlined in 'Documentation/process/stable-kernel-rules.rst'.
1600 to mainline. Other fixes are easy to get backported to the newest stable and
1619 * Search the Linux stable mailing list for exiting reports.
1631 or peer-review possible fixes; then check the discussions if the fix was
1645 log --grep=<pattern>``.
1648 'stable tag' that looks like this:
1650 Cc: <stable@vger.kernel.org> # 5.4+
1653 line 5.4 and later. Most of the time it's getting applied there within two
1672 * If the fix doesn't contain a stable tag and backporting was not discussed,
1683 as the stable mailing list.*
1688 for the subsystem as well as the stable mailing list (stable@vger.kernel.org).
1702 kernel in their spare time. Quite a few of the drivers in the kernel were
1706 These programmers most of the time will happily fix problems other people
1714 Sooner or later spare time developers will also stop caring for the driver.
1729 much time and energy in maintaining a Linux kernel driver for something they
1731 longer time period, but in new versions often leave support for old and rare
1732 hardware aside to limit the scope. Often spare time contributors take over once
1737 quite often are forced to set those, as time to work on Linux is limited.
1738 That's true for spare time or the time employers grant their developers to
1755 art will lay some groundwork to improve the situation over time.
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".