All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Thorsten Leemhuis <linux@leemhuis.info>,
	Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 08/26] docs: reporting-bugs: make readers check the taint flag
Date: Fri, 2 Oct 2020 10:08:18 -0700	[thread overview]
Message-ID: <8129d3a7-3649-b9cc-1615-402f12ee370a@infradead.org> (raw)
In-Reply-To: <eed27c4faa31d98bd37db18ba2ae90f1767c7102.1601541165.git.linux@leemhuis.info>

On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Tell users early in the process to check the taint flag, as that will
> prevent them from investing time into a report that might be worthless.
> That way users for example will notice that the issue they face is in
> fact caused by an add-on kernel module or and Oops that happened
> earlier.
> 
> This approach has a downside: users will later have to check the flag
> again with the mainline kernel the guide tells them to install. But that
> is an acceptable trade-off here, as checking only takes a few seconds
> and can easily prevent wasting time in useless testing and debugging.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
> 
> = RFC =
> 
> Should "disable DKMS" come before this step? But then the backup step right
> before that one would need to be moved as well, as disabling DKMS can mix things
> up.
> ---
>  Documentation/admin-guide/reporting-bugs.rst  | 59 +++++++++++++++++++
>  Documentation/admin-guide/tainted-kernels.rst |  2 +
>  2 files changed, 61 insertions(+)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
> index 430a0c3ee0ad..61b6592ddf74 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -311,6 +311,65 @@ fatal error where the kernels stop itself) with a 'Oops' (a recoverable error),
>  as the kernel remains running after an 'Oops'.
>  
>  
> +Check 'taint' flag
> +------------------
> +
> +    *Check if your kernel was 'tainted' when the issue occurred, as the event
> +    that made the kernel set this flag might be causing the issue you face.*
> +
> +The kernel marks itself with a 'taint' flag when something happens that might
> +lead to follow-up errors that look totally unrelated. The issue you face might
> +be such an error if your kernel is tainted. That's why it's in your interest to
> +rule this out early before investing more time into this process. This is the
> +only reason why this step is here, as this process later will tell you to
> +install the latest mainline kernel and check its taint flag, as that's the
> +kernel the report will be mainly about.
> +
> +On a running system is easy to check if the kernel tainted itself: it's not
> +tainted if ``cat /proc/sys/kernel/tainted`` returns '0'. Checking that file is
> +impossible in some situations, that's why the kernel also mentions the taint

                      situations;

> +status when it reports an internal problem (a 'kernel bug'), a recoverable
> +error (a 'kernel Oops') or a non-recoverable error before halting operation (a
> +'kernel panic'). Look near the top of the error messages printed when one of
> +these occurs and search for a line starting with 'CPU:'. It should end with
> +'Not tainted' if the kernel was not tainted beforehand; it was tainted if you
> +see 'Tainted:' followed by a few spaces and some letters.
> +
> +If your kernel is tainted study

                     tainted, study

> +:ref:`Documentation/admin-guide/tainted-kernels.rst <taintedkernels>` to find
> +out why and try to eliminate the reason. Often it's because a recoverable error
> +(a 'kernel Oops') occurred and the kernel tainted itself, as the kernel knows
> +it might misbehave in strange ways after that point. In that case check your
> +kernel or system log and look for a section that starts with this::
> +
> +       Oops: 0000 [#1] SMP
> +
> +That's the first Oops since boot-up, as the '#1' between the brackets shows.
> +Every Oops and any other problem that happen after that point might be a
> +follow-up problem to that first Oops, even if they look totally unrelated. Try
> +to rule this out by getting rid of that Oops and reproducing the issue
> +afterwards. Sometimes simply restarting will be enough, sometimes a change to
> +the configuration followed by a reboot can eliminate the Oops. But don't invest
> +too much time into this at this point of the process, as the cause for the Oops
> +might already be fixed in the newer Linux kernel version you are going to
> +install later in this process.
> +
> +Quite a few kernels are also tainted because an unsuitable kernel modules was

                                                                     module

> +loaded. This for example is the case if you use Nvidias proprietary graphics

                                                   Nvidia's

> +driver, VirtualBox, or other software that installs its own kernel modules: you
> +will have to remove these modules and reboot the system, as they might in fact
> +be causing the issue you face.

You will need to reboot the system and try to reproduce the issue without loading
any of these proprietary modules.

> +
> +The kernel also taints itself when it's loading a module that resists in the

                                                                 resides

> +staging tree of the Linux kernel source. That's a special area for code (mostly
> +drivers) that does not yet fulfill the normal Linux kernel quality standards.
> +When you report an issue with such a module it's obviously okay if the kernel is
> +tainted, just make sure the module in question is the only reason for the taint.

   tainted;

> +If the issue happens in an unrelated area reboot and temporary block the module

                                                        temporarily

> +from being loaded by specifying ``foo.blacklist=1`` as kernel parameter (replace
> +'foo' with the name of the module in question).
> +
> +
>  .. ############################################################################
>  .. Temporary marker added while this document is rewritten. Sections above
>  .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
> diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
> index abf804719890..2900f477f42f 100644
> --- a/Documentation/admin-guide/tainted-kernels.rst
> +++ b/Documentation/admin-guide/tainted-kernels.rst
> @@ -1,3 +1,5 @@
> +.. _taintedkernels:
> +
>  Tainted kernels
>  ---------------
>  
> 


-- 
~Randy


  reply	other threads:[~2020-10-02 17:08 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01  8:39 [RFC PATCH v1 00/26] Make reporting-bugs easier to grasp and yet more detailed Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 01/26] docs: reporting-bugs: temporary markers for licensing and diff reasons Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 02/26] docs: reporting-bugs: Create a TLDR how to report issues Thorsten Leemhuis
2020-10-02  2:32   ` Randy Dunlap
2020-10-03  7:27     ` Thorsten Leemhuis
2020-11-11 15:24       ` Thorsten Leemhuis
2020-11-12  3:33         ` Randy Dunlap
2020-11-12  4:56           ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 03/26] docs: reporting-bugs: step-by-step guide on " Thorsten Leemhuis
2020-10-02  3:02   ` Randy Dunlap
2020-10-03  8:05     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 04/26] docs: reporting-bugs: step-by-step guide for issues in stable & longterm Thorsten Leemhuis
2020-10-02  3:25   ` Randy Dunlap
2020-10-03  8:24     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 05/26] docs: reporting-bugs: begin reference section providing details Thorsten Leemhuis
2020-10-02 16:49   ` Randy Dunlap
2020-10-03  8:27     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 06/26] docs: reporting-bugs: point out we only care about fresh vanilla kernels Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 07/26] docs: reporting-bugs: let users classify their issue Thorsten Leemhuis
2020-10-02 16:59   ` Randy Dunlap
2020-10-03  9:42     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 08/26] docs: reporting-bugs: make readers check the taint flag Thorsten Leemhuis
2020-10-02 17:08   ` Randy Dunlap [this message]
2020-10-03  9:56     ` Thorsten Leemhuis
2020-10-03 17:47       ` Randy Dunlap
2020-10-01  8:39 ` [RFC PATCH v1 09/26] docs: reporting-bugs: help users find the proper place for their report Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-07 12:05     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 10/26] docs: reporting-bugs: remind people to look for existing reports Thorsten Leemhuis
2020-10-02 17:17   ` Randy Dunlap
2020-10-03  9:58     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 11/26] docs: reporting-bugs: remind people to back up their data Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 12/26] docs: reporting-bugs: tell users to disable DKMS et al Thorsten Leemhuis
2020-10-02 17:28   ` Randy Dunlap
2020-10-03  9:59     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 13/26] docs: reporting-bugs: point out the environment might be causing issue Thorsten Leemhuis
2020-10-02 17:32   ` Randy Dunlap
2020-10-03 10:00     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 14/26] docs: reporting-bugs: make users write notes, one for each issue Thorsten Leemhuis
2020-10-02 17:35   ` Randy Dunlap
2020-10-03 10:01     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 15/26] docs: reporting-bugs: make readers test mainline, but leave a loophole Thorsten Leemhuis
2020-10-02 17:51   ` Randy Dunlap
2020-10-03 10:11     ` Thorsten Leemhuis
2020-11-11 15:36       ` Thorsten Leemhuis
2020-11-12  3:42         ` Randy Dunlap
2020-11-12  5:22           ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 16/26] docs: reporting-bugs: let users check taint status again Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 17/26] docs: reporting-bugs: explain options if reproducing on mainline fails Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 18/26] docs: reporting-bugs: let users optimize their notes Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 19/26] docs: reporting-bugs: decode failure messages [need help] Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 20/26] docs: reporting-bugs: instructions for handling regressions Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-04  6:31     ` Thorsten Leemhuis
2020-10-01  8:39 ` [RFC PATCH v1 21/26] docs: reporting-bugs: details on writing and sending the report Thorsten Leemhuis
2020-10-09  2:45   ` Randy Dunlap
2020-10-09  7:38     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 22/26] docs: reporting-bugs: explain what users should do once the report got out Thorsten Leemhuis
2020-10-09 17:37   ` Randy Dunlap
2020-10-11 13:29     ` Thorsten Leemhuis
2020-10-11 15:06       ` Randy Dunlap
2020-10-01  8:50 ` [RFC PATCH v1 23/26] docs: reporting-bugs: details for issues specific to stable and longterm Thorsten Leemhuis
2020-10-09 18:42   ` Randy Dunlap
2020-10-11 13:29     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-04  6:35     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 25/26] docs: reporting-bugs: explain things could be easier Thorsten Leemhuis
2020-10-04  4:03   ` Randy Dunlap
2020-10-04  6:36     ` Thorsten Leemhuis
2020-10-01  8:50 ` [RFC PATCH v1 26/26] docs: reporting-bugs: add SPDX tag and license hint, remove markers Thorsten Leemhuis
2020-11-09 11:01 ` [RFC PATCH v1 00/26] Make reporting-bugs easier to grasp and yet more detailed Thorsten Leemhuis
2020-11-09 18:21   ` Jonathan Corbet
2020-11-10 12:01     ` Thorsten Leemhuis
2020-11-10  3:23   ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8129d3a7-3649-b9cc-1615-402f12ee370a@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.