Commit | Line | Data |
---|---|---|
c730904b MCC |
1 | Bisecting a bug |
2 | +++++++++++++++ | |
3 | ||
4 | Last updated: 28 October 2016 | |
5 | ||
6 | Introduction | |
7 | ============ | |
8 | ||
9 | Always try the latest kernel from kernel.org and build from source. If you are | |
10 | not confident in doing that please report the bug to your distribution vendor | |
11 | instead of to a kernel developer. | |
12 | ||
13 | Finding bugs is not always easy. Have a go though. If you can't find it don't | |
14 | give up. Report as much as you have found to the relevant maintainer. See | |
15 | MAINTAINERS for who that is for the subsystem you have worked on. | |
16 | ||
17 | Before you submit a bug report read | |
18 | :ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`. | |
19 | ||
20 | Devices not appearing | |
21 | ===================== | |
22 | ||
23 | Often this is caused by udev/systemd. Check that first before blaming it | |
24 | on the kernel. | |
25 | ||
26 | Finding patch that caused a bug | |
27 | =============================== | |
28 | ||
29 | Using the provided tools with ``git`` makes finding bugs easy provided the bug | |
30 | is reproducible. | |
31 | ||
32 | Steps 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 | |
ca435454 | 69 | start with ``git bisect start [BAD] [GOOD]`` |
c730904b MCC |
70 | |
71 | For 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>`_ |