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