Orange Pi5 kernel

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