| Mauro Carvalho Chehab | c730904 | 2016-11-07 17:03:17 -0200 | [diff] [blame] | 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 |
| Jonathan Corbet | ca43545 | 2016-11-07 18:03:13 -0700 | [diff] [blame] | 69 | start with ``git bisect start [BAD] [GOOD]`` |
| Mauro Carvalho Chehab | c730904 | 2016-11-07 17:03:17 -0200 | [diff] [blame] | 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>`_ |