cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

bug-bisect.rst (2159B)


      1Bisecting a bug
      2+++++++++++++++
      3
      4Last updated: 28 October 2016
      5
      6Introduction
      7============
      8
      9Always try the latest kernel from kernel.org and build from source. If you are
     10not confident in doing that please report the bug to your distribution vendor
     11instead of to a kernel developer.
     12
     13Finding bugs is not always easy. Have a go though. If you can't find it don't
     14give up. Report as much as you have found to the relevant maintainer. See
     15MAINTAINERS for who that is for the subsystem you have worked on.
     16
     17Before you submit a bug report read
     18'Documentation/admin-guide/reporting-issues.rst'.
     19
     20Devices not appearing
     21=====================
     22
     23Often this is caused by udev/systemd. Check that first before blaming it
     24on the kernel.
     25
     26Finding patch that caused a bug
     27===============================
     28
     29Using the provided tools with ``git`` makes finding bugs easy provided the bug
     30is reproducible.
     31
     32Steps to do it:
     33
     34- build the Kernel from its git source
     35- start bisect with [#f1]_::
     36
     37	$ git bisect start
     38
     39- mark the broken changeset with::
     40
     41	$ git bisect bad [commit]
     42
     43- mark a changeset where the code is known to work with::
     44
     45	$ git bisect good [commit]
     46
     47- rebuild the Kernel and test
     48- interact with git bisect by using either::
     49
     50	$ git bisect good
     51
     52  or::
     53
     54	$ git bisect bad
     55
     56  depending if the bug happened on the changeset you're testing
     57- After some interactions, git bisect will give you the changeset that
     58  likely caused the bug.
     59
     60- For example, if you know that the current version is bad, and version
     61  4.8 is good, you could do::
     62
     63           $ git bisect start
     64           $ git bisect bad                 # Current version is bad
     65           $ git bisect good v4.8
     66
     67
     68.. [#f1] You can, optionally, provide both good and bad arguments at git
     69	 start with ``git bisect start [BAD] [GOOD]``
     70
     71For further references, please read:
     72
     73- The man page for ``git-bisect``
     74- `Fighting regressions with git bisect <https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html>`_
     75- `Fully automated bisecting with "git bisect run" <https://lwn.net/Articles/317154>`_
     76- `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_