diff options
author | Thorsten Leemhuis <linux@leemhuis.info> | 2024-03-18 11:38:37 +0300 |
---|---|---|
committer | Jonathan Corbet <corbet@lwn.net> | 2024-03-18 12:43:31 +0300 |
commit | a0a3222fa9a7856b9c66708abeffdce45b2c1eb8 (patch) | |
tree | cc583d62ab0990b6addb93a18c76bf5a86643301 /Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst | |
parent | b513d12ed162cb948706b93b828bc4eec2e68188 (diff) | |
download | linux-a0a3222fa9a7856b9c66708abeffdce45b2c1eb8.tar.xz |
docs: verify/bisect: check taint flag
Instruct readers to check the taint flag, as the reason why it's set
might directly or indirectly cause the bug or interfere with testing.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <8fcaffa8e85f36d51178d61061355c3c8bc85a0f.1710750972.git.linux@leemhuis.info>
Diffstat (limited to 'Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst')
-rw-r--r-- | Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst | 64 |
1 files changed, 49 insertions, 15 deletions
diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index fb82118bb011..632372e343d8 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -113,6 +113,7 @@ will be considered the 'good' release and used to prepare the .config file. # checking if the output of the next two commands matches: tail -n 1 ~/kernels-built uname -r + cat /proc/sys/kernel/tainted c) Check if the problem occurs with this kernel as well. @@ -572,21 +573,29 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] Remember the identifier momentarily, as it will help you pick the right kernel from the boot menu upon restarting. -.. _recheckbroken_bissbs: - -* Reboot into the kernel you just built and check if the feature that is - expected to be broken really is. - - Start by making sure the kernel you booted is the one you just built. When - unsure, check if the output of these commands show the exact same release - identifier:: +* Reboot into your newly built kernel. To ensure your actually started the one + you just built, you might want to verify if the output of these commands + matches:: tail -n 1 ~/kernels-built uname -r - Now verify if the feature that causes trouble works with your newly built - kernel. If things work while investigating a regression, check the reference - section for further details. +.. _tainted_bissbs: + +* Check if the kernel marked itself as 'tainted':: + + cat /proc/sys/kernel/tainted + + If that command does not return '0', check the reference section, as the cause + for this might interfere with your testing. + + [:ref:`details<tainted_bisref>`] + +.. _recheckbroken_bissbs: + +* Verify if your bug occurs with the newly built kernel. If it does not, check + out the instructions in the reference section to ensure nothing went sideways + during your tests. [:ref:`details<recheckbroken_bisref>`] @@ -616,11 +625,14 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] make -s kernelrelease | tee -a ~/kernels-built reboot - Now verify if you booted the kernel you intended to start, to then check if - everything works fine with this kernel:: + Confirm you booted the kernel you intended to start and check its tainted + status:: tail -n 1 ~/kernels-built uname -r + cat /proc/sys/kernel/tainted + + Now verify if this kernel is showing the problem. [:ref:`details<recheckstablebroken_bisref>`] @@ -1629,13 +1641,32 @@ need to look in different places. [:ref:`back to step-by-step guide <storagespace_bissbs>`] +.. _tainted_bisref: + +Check if your newly built kernel considers itself 'tainted' +----------------------------------------------------------- + + *Check if the kernel marked itself as 'tainted'.* + [:ref:`... <tainted_bissbs>`] + +Linux marks itself as tainted when something happens that potentially leads to +follow-up errors that look totally unrelated. That is why developers might +ignore or react scantly to reports from tainted kernels -- unless of course the +kernel set the flag right when the reported bug occurred. + +That's why you want check why a kernel is tainted as explained in +Documentation/admin-guide/tainted-kernels.rst; doing so is also in your own +interest, as your testing might be flawed otherwise. + +[:ref:`back to step-by-step guide <tainted_bissbs>`] + .. _recheckbroken_bisref: Check the kernel built from the latest codebase ----------------------------------------------- - *Reboot into the kernel you just built and check if the feature that regressed - is really broken there.* [:ref:`... <recheckbroken_bissbs>`] + *Verify if your bug occurs with the newly built kernel.* + [:ref:`... <recheckbroken_bissbs>`] There are a couple of reasons why the regression you face might not show up with your own kernel built from the latest codebase. These are the most frequent: @@ -1712,6 +1743,9 @@ In case the feature that broke with newer kernels does not work with your first self-built kernel, find and resolve the cause before moving on. There are a multitude of reasons why this might happen. Some ideas where to look: +* Check the taint status and the output of ``dmesg``, maybe something unrelated + went wrong. + * Maybe localmodconfig did something odd and disabled the module required to test the feature? Then you might want to recreate a .config file based on the one from the last working kernel and skip trimming it down; manually disabling |