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 13/26] docs: reporting-bugs: point out the environment might be causing issue
Date: Fri, 2 Oct 2020 10:32:36 -0700 [thread overview]
Message-ID: <a226274e-7bda-bd27-a0a5-1f1bb165fcd1@infradead.org> (raw)
In-Reply-To: <6dab906efb915c6cd6733df525b1f3da3753c4b4.1601541165.git.linux@leemhuis.info>
On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Help users to avoid a few pitfalls, as they might be the real reason why
> the kernel is acting up somehow.
>
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
> Documentation/admin-guide/reporting-bugs.rst | 34 ++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
> index d96b21512c03..2292b79cf462 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -583,6 +583,40 @@ not part of the Linux kernel. Your package manager might thus force you to
> remove those, too.
>
>
> +Ensure a healthy environment
> +----------------------------
> +
> + *Make sure it's not the kernels surroundings that are causing the issue you
kernel's
> + face.*
> +
> +Problems that look a lot like a kernel issue are sometimes caused by build
> +or runtime environment. It's hard to rule out that problem completely, but you
> +should minimize it:
> +
> + * Use proven tools when building your kernel, as bugs in the compiler or the
> + binutils can cause the resulting kernel to misbehave.
> +
> + * Ensure your computer components runs within their design specifications;
run
> + that's especially important for the main processor, the main memory, and the
> + motherboard. Therefore, stop overclocking when facing a potential kernel
> + issue.
> +
> + * Try to make sure it's not faulty hardware that is causing your issue. Bad
> + main memory for example can result in a multitude of issues that will
> + manifest itself in problems looking like kernel issues.
> +
> + * If you're dealing with a filesystem issue, you might want to check the file
> + system in question with ``fsck`` before trying to reproduce it again.
> +
> + * When dealing with a regression, make sure it's not something else that
> + changed in parallel to updating the kernel. The problem for example might be
> + caused by another software that was updated at the same time. It can also
by other software
> + happen that a hardware component coincidentally just broke when you rebooted
> + into a new kernel for the first time. Updating the systems BIOS or changing
> + something in the BIOS Setup can also lead to problems that on the first sight
> + look like a regression.
> +
> +
> .. ############################################################################
> .. 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.
>
--
~Randy
next prev parent reply other threads:[~2020-10-02 17:32 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
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 [this message]
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=a226274e-7bda-bd27-a0a5-1f1bb165fcd1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).