Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit c730904b authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab Committed by Jonathan Corbet
Browse files

doc-rst: admin-guide: move bug bisect to a separate file 



Better organize the admin guide documentation by moving the
bug bisect to a separate file.

Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent ab0e44c1

Documentation/admin-guide/bug-bisect.rst

0 → 100644
+78 −0
Original line number Diff line number Diff line 
Bisecting a bug

+++++++++++++++



Last updated: 28 October 2016



Introduction

============



Always try the latest kernel from kernel.org and build from source. If you are

not confident in doing that please report the bug to your distribution vendor

instead of to a kernel developer.



Finding bugs is not always easy. Have a go though. If you can't find it don't

give up. Report as much as you have found to the relevant maintainer. See

MAINTAINERS for who that is for the subsystem you have worked on.



Before you submit a bug report read

:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`.



Devices not appearing

=====================



Often this is caused by udev/systemd. Check that first before blaming it

on the kernel.



Finding patch that caused a bug

===============================



Using the provided tools with ``git`` makes finding bugs easy provided the bug

is reproducible.



Steps to do it:



- build the Kernel from its git source

- start bisect with [#f1]_::



	$ git bisect start



- mark the broken changeset with::



	$ git bisect bad [commit]



- mark a changeset where the code is known to work with::



	$ git bisect good [commit]



- rebuild the Kernel and test

- interact with git bisect by using either::



	$ git bisect good



  or::



	$ git bisect bad



  depending if the bug happened on the changeset you're testing

- After some interactions, git bisect will give you the changeset that

  likely caused the bug.



- For example, if you know that the current version is bad, and version

  4.8 is good, you could do::



           $ git bisect start

           $ git bisect bad                 # Current version is bad

           $ git bisect good v4.8





.. [#f1] You can, optionally, provide both good and bad arguments at git

	 start::



		git bisect start [BAD] [GOOD]



For further references, please read:



- The man page for ``git-bisect``

- `Fighting regressions with git bisect <https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html>`_

- `Fully automated bisecting with "git bisect run" <https://lwn.net/Articles/317154>`_

- `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_

Documentation/admin-guide/bug-hunting.rst

+0 −74
Original line number Diff line number Diff line
@@ -3,80 +3,6 @@ Bug hunting 


Last updated: 28 October 2016



Introduction

============



Always try the latest kernel from kernel.org and build from source. If you are

not confident in doing that please report the bug to your distribution vendor

instead of to a kernel developer.



Finding bugs is not always easy. Have a go though. If you can't find it don't

give up. Report as much as you have found to the relevant maintainer. See

MAINTAINERS for who that is for the subsystem you have worked on.



Before you submit a bug report read

:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`.



Devices not appearing

=====================



Often this is caused by udev/systemd. Check that first before blaming it

on the kernel.



Finding patch that caused a bug

===============================



Using the provided tools with ``git`` makes finding bugs easy provided the bug

is reproducible.



Steps to do it:



- build the Kernel from its git source

- start bisect with [#f1]_::



	$ git bisect start



- mark the broken changeset with::



	$ git bisect bad [commit]



- mark a changeset where the code is known to work with::



	$ git bisect good [commit]



- rebuild the Kernel and test

- interact with git bisect by using either::



	$ git bisect good



  or::



	$ git bisect bad



  depending if the bug happened on the changeset you're testing

- After some interactions, git bisect will give you the changeset that

  likely caused the bug.



- For example, if you know that the current version is bad, and version

  4.8 is good, you could do::



           $ git bisect start

           $ git bisect bad                 # Current version is bad

           $ git bisect good v4.8





.. [#f1] You can, optionally, provide both good and bad arguments at git

	 start::



		git bisect start [BAD] [GOOD]



For further references, please read:



- The man page for ``git-bisect``

- `Fighting regressions with git bisect <https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html>`_

- `Fully automated bisecting with "git bisect run" <https://lwn.net/Articles/317154>`_

- `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_



Fixing the bug

==============

Documentation/admin-guide/index.rst

+1 −0
Original line number Diff line number Diff line
@@ -26,6 +26,7 @@ problems and bugs in particular. 
   reporting-bugs

   security-bugs

   bug-hunting

   bug-bisect

   oops-tracing

   ramoops

   dynamic-debug-howto