Lines Matching +full:step +full:- +full:up
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
9 currently supported by developers -- to then explain how to locate the change
22 read and navigate this document -- especially when you want to look something
23 up in the reference section, then jump back to where you left off.
26 https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
32 over to the* ':ref:`step-by-step guide <introguide_bissbs>`' *below. It utilizes
45 *segment 2*. Then you can submit a preliminary report -- or continue with
47 full-fledged regression report. In the following example 6.0.13 is assumed to be
51 * **Preparations**: set up everything to build your own kernels::
55 # * Ensure Secure Boot permits booting self-compiled Linux kernels.
59 git clone -o mainline --no-checkout \
62 git remote add -t master stable \
64 git switch --detach v6.0
68 # * Connect external hardware (USB keys, tokens, ...), start a VM, bring up
71 ./scripts/config --set-str CONFIG_LOCALVERSION '-local'
72 ./scripts/config -e CONFIG_LOCALVERSION_AUTO
74 ./scripts/config -d DEBUG_INFO_NONE -e KALLSYMS_ALL -e DEBUG_KERNEL \
75 -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS
79 cp .config ~/kernel-config-working
90 git switch --discard-changes --detach mainline/master
94 cp ~/kernel-config-working .config
96 make -j $(nproc --all)
98 df -h /boot/ /lib/modules/
101 # job. See the step-by-step guide for further details.
103 command -v installkernel && sudo make install
104 # * Check how much space your self-built kernel actually needs, which
106 du -ch /boot/*$(make -s kernelrelease)* | tail -n 1
107 du -sh /lib/modules/$(make -s kernelrelease)/
110 make -s kernelrelease | tee -a ~/kernels-built
114 tail -n 1 ~/kernels-built
115 uname -r
128 git switch --discard-changes --detach v6.0
131 section b* -- just feel free to skip the 'du' commands, as you have a rough
141 git remote set-branches --add stable linux-6.1.y
159 All three commands will make Git check out another commit; then re-execute
160 this step (e.g. build, install, boot, and test a kernel to then tell Git
169 git bisect log > ~/bisect-log
170 cp .config ~/bisection-config-culprit
175 git switch --discard-changes --detach mainline/master
176 git revert --no-edit cafec0cacaca0
177 cp ~/kernel-config-working .config
178 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
193 ls -ltr /lib/modules/*-local*
196 '6.0-rc1-local-gcafec0cacaca0', use this::
198 sudo rm -rf /lib/modules/6.0-rc1-local-gcafec0cacaca0
199 sudo kernel-install -v remove 6.0-rc1-local-gcafec0cacaca0
200 # * Note, on some distributions kernel-install is missing
211 git switch --discard-changes --detach mainline/master
212 git apply /tmp/foobars-proposed-fix-v1.patch
213 cp ~/kernel-config-working .config
214 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1'
216 Build, install, and boot a kernel as described in *segment 1, section b* --
222 Step-by-step guide on how to verify bugs and bisect regressions
225 This guide describes how to set up your own Linux kernels for investigating bugs
231 set to report the bug -- unless it did not happen with earlier kernel versions,
236 *segment 3* to **perform a bisection** for a full-fledged regression report
239 :ref:`Preparations: set up everything to build your own kernels <introprep_bissbs>`.
254 pitfalls, as well as problems that might occur at the particular step -- and how
258 out Documentation/admin-guide/reporting-issues.rst, which works in conjunction
260 the latest 'mainline' kernel (e.g. versions like 6.0, 6.1-rc1, or 6.1-rc6),
267 as a regression check out Documentation/admin-guide/reporting-regressions.rst.
274 Preparations: set up everything to build your own kernels
275 ---------------------------------------------------------
301 ensure the system will permit your self-compiled kernel to boot. The
305 ``mokutil --disable-validation``.
316 you regularly use currently as 'good' (e.g. 6.0, 6.0.13, or 6.1-rc2).
323 (say 6.0.13) to a newer mainline series (like 6.1-rc7 or 6.1) or a
327 (e.g. 6.1-rc7, 6.1, or 6.1.5). Note, at this point it is merely assumed
331 a later one (like 6.1-rc1) or a stable/longterm release based on it
333 the first broken (e.g. 6.1-rc1 or 6.1.5) as 'bad'.
386 git clone -o mainline --no-checkout \
389 git remote add -t master stable \
398 to ('linux-6.1.y' in this example)::
400 git remote set-branches --add stable linux-6.1.y
408 step told you to boot; if you are unsure, check the current kernelrelease
409 identifier using ``uname -r``.
416 git switch --discard-changes --detach v6.0
430 the .config file for your running kernel -- in which case you have to put one
436 'make olddefconfig' again and check if it now picked up the right config file
444 optional, but especially wise for bisections, as it speeds up the build
445 process enormously -- at least unless the .config file picked up in the
446 previous step was already tailored to your and your hardware needs, in which
447 case you should skip this step.
450 keys, tokens, ...), quickly start a VM, and bring up VPNs. And if you rebooted
456 There is a catch to this, as the 'apparently' in initial sentence of this step
460 used occasionally -- like modules for external peripherals not yet connected
480 ./scripts/config --set-str CONFIG_LOCALVERSION '-local'
481 ./scripts/config -e CONFIG_LOCALVERSION_AUTO
493 ./scripts/config -d DEBUG_INFO_NONE -e KALLSYMS_ALL -e DEBUG_KERNEL \
494 -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS
499 ./scripts/config -d DEBUG_INFO -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
500 -d DEBUG_INFO_DWARF4 -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE
527 cp .config ~/kernel-config-working
534 ----------------------------------------------------------------
548 latest version ('linux-6.1.y' in the following example)::
551 git switch --discard-changes --detach stable/linux-6.1.y
555 linux-6.2.y) or mainline (see next point) fix the bug.
560 git switch --discard-changes --detach mainline/master
569 cp ~/kernel-config-working .config
571 make -j $(nproc --all)
573 If you want your kernel packaged up as deb, rpm, or tar file, see the
585 df -h /boot/ /lib/modules/
594 command -v installkernel && sudo make install
608 have to perform those again after executing ``command -v installkernel [...]``.
617 du -ch /boot/*$(make -s kernelrelease)* | tail -n 1
618 du -sh /lib/modules/$(make -s kernelrelease)/
629 make -s kernelrelease | tee -a ~/kernels-built
638 tail -n 1 ~/kernels-built
639 uname -r
670 git switch --discard-changes --detach mainline/master
675 cp ~/kernel-config-working .config
677 make -j $(nproc --all)
679 df -h /boot/ /lib/modules/
681 command -v installkernel && sudo make install
682 make -s kernelrelease | tee -a ~/kernels-built
688 tail -n 1 ~/kernels-built
689 uname -r
694 stable team. See Documentation/admin-guide/reporting-issues.rst for details.
709 ---------------------------------------------------
724 git switch --discard-changes --detach v6.0
729 cp ~/kernel-config-working .config
731 make -j $(nproc --all)
733 df -h /boot/ /lib/modules/
735 command -v installkernel && sudo make install
736 make -s kernelrelease | tee -a ~/kernels-built
742 tail -n 1 ~/kernels-built
743 uname -r
753 --------------------------------------------------------
756 to begin the bisection. This will make you build quite a few kernels -- usually
780 cp ~/kernel-config-working .config
782 make -j $(nproc --all)
784 df -h /boot/ /lib/modules/
786 command -v installkernel && sudo make install
787 make -s kernelrelease | tee -a ~/kernels-built
793 In case you skipped the 'test latest codebase' step in the guide, check its
794 description as for why the 'df [...]' and 'make -s kernelrelease [...]'
798 identifiers that might look odd or wrong to you -- which they are not, as it's
799 totally normal to see release identifiers like '6.0-rc1-local-gcafec0cacaca0'
812 tail -n 1 ~/kernels-built
813 uname -r
832 previous step; afterwards follow the instructions in this step again.
834 Repeat this again and again until you finish the bisection -- that's the case
839 might need to scroll up to see the message mentioning the culprit;
840 alternatively, run ``git bisect log > ~/bisection-log``.
850 git bisect log > ~/bisection-log
851 cp .config ~/bisection-config-culprit
875 git switch --discard-changes --detach linux-6.0.y
880 git switch --discard-changes --detach mainline/master
883 happens in mainline, there is one more thing to do: look up the mainline
884 commit-id. To do so, use a command like ``git show abcdcafecabcd`` to
887 'Upstream commit cafec0cacaca0'; use that commit-id in the next command
892 git revert --no-edit cafec0cacaca0
894 If that fails, give up trying and move on to the next step; if it works,
898 cp ~/kernel-config-working .config
899 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
905 make -j $(nproc --all)
907 df -h /boot/ /lib/modules/
909 command -v installkernel && sudo make install
910 make -s kernelrelease | tee -a ~/kernels-built
921 -----------------------------------------------------------
929 * To remove one of the kernels you installed, look up its 'kernelrelease'
930 identifier. This guide stores them in '~/kernels-built', but the following
933 ls -ltr /lib/modules/*-local*
938 'good') might become handy to verify something later -- thus better keep them
942 '*6.0-rc1-local-gcafec0cacaca0*', start by removing the directory holding its
945 sudo rm -rf /lib/modules/6.0-rc1-local-gcafec0cacaca0
949 sudo kernel-install -v remove 6.0-rc1-local-gcafec0cacaca0
953 distributions kernel-install does not exist or leaves boot-loader entries or
962 set up, as you might need a few things again. What is safe to remove depends
968 for a while, but safely remove all others with a '-local' in the release
971 * Did the bisection end on a merge-commit or seems questionable for other
985 --------------------------------------------------
997 git switch --discard-changes --detach mainline/master
1003 git remote set-branches --add stable linux-6.2.y
1009 git switch --discard-changes --detach stable/linux-6.2.y
1013 cp ~/kernel-config-working .config
1015 * Your next step depends on what you want to do:
1017 * In case you just want to test the latest codebase, head to the next step,
1023 git revert --no-edit cafec0cacaca0
1028 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
1031 '/tmp/foobars-proposed-fix-v1.patch' and apply it like this::
1033 git apply /tmp/foobars-proposed-fix-v1.patch
1035 In case of multiple patches, repeat this step with the others.
1040 ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1'
1046 make -j $(nproc --all)
1048 df -h /boot/ /lib/modules/
1050 command -v installkernel && sudo make install
1051 make -s kernelrelease | tee -a ~/kernels-built
1061 ----------
1063 You have reached the end of the step-by-step guide.
1065 Did you run into trouble following any of the above steps not cleared up by the
1071 CCing the Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is
1073 will enable more people to master the task described here -- and hopefully also
1077 Reference section for the step-by-step guide
1081 step-by-step guide.
1084 ------------------------------------------
1091 [:ref:`back to step-by-step guide <introprep_bissbs>`].
1102 -- especially if you fiddle with crucial parts like the kernel of an operating
1106 [:ref:`back to step-by-step guide <backup_bissbs>`]
1118 But there is a more important reason why this guide contains this step: most
1121 considered 'vanilla' anymore, as Documentation/admin-guide/reporting-issues.rst
1124 [:ref:`back to step-by-step guide <vanilla_bissbs>`]
1132 ensure the system will permit your self-compiled kernel to boot later.*
1136 they reject booting self-compiled kernels by default.
1138 You ideally deal with this by making your platform trust your self-built kernels
1141 its purpose; 'Documentation/admin-guide/module-signing.rst' and various web
1151 initiate this process by running ``mokutil --disable-validation``; this will
1152 tell you to create a one-time password, which is safe to write down. Now
1153 restart; right after your BIOS performed all self-tests the bootloader Shim will
1157 randomly chosen characters from the one-time password specified earlier. Once
1161 [:ref:`back to step-by-step guide <secureboot_bissbs>`]
1174 [:ref:`back to step-by-step guide <bootworking_bissbs>`]
1187 If you have space constraints, be sure to hay attention to the :ref:`step about
1192 [:ref:`back to step-by-step guide <diskspace_bissbs>`]
1217 [:ref:`back to step-by-step guide <rangecheck_bissbs>`]
1227 The kernel is pretty stand-alone, but besides tools like the compiler you will
1237 sudo pacman --needed -S bc binutils bison flex gcc git kmod libelf openssl \
1238 pahole perl zlib ncurses qt6-base
1242 sudo apt install bc binutils bison dwarves flex gcc git kmod libelf-dev \
1243 libssl-dev make openssl pahole perl-base pkg-config zlib1g-dev \
1244 libncurses-dev qt6-base-dev g++
1255 kernel-install-tools libelf-devel make modutils openssl openssl-devel \
1256 perl-base zlib-devel rpm-build ncurses-devel qt6-base-devel
1265 for tasks not covered in this guide -- for example when building utilities from
1268 [:ref:`back to step-by-step guide <buildrequires_bissbs>`]
1278 The step-by-step guide outlines how to download the Linux sources using a full
1280 that -- but there are two alternatives ways to retrieve the sources that might
1298 wget -c \
1300 git clone --no-checkout clone.bundle ~/linux/
1306 git remote add -t master stable \
1309 In case the 'wget' command fails, just re-execute it, it will pick up where
1312 [:ref:`back to step-by-step guide <sources_bissbs>`]
1322 git clone -o mainline --no-checkout --depth 1 -b master \
1325 git remote add -t master stable \
1330 be the first predecessor and 5.18 the second -- hence deepen the history up to
1333 git fetch --shallow-exclude=v5.18 mainline
1336 branches as explained in the step-by-step guide.
1344 releases (like 6.0-rc2 or 5.19-rc3).
1346 * This document in most places uses ``git fetch`` with ``--shallow-exclude=``
1348 tag). You alternatively can use the parameter ``--shallow-since=`` to specify
1349 an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
1356 In that case run ``git repack -d`` and try again.
1358 [:ref:`back to step-by-step guide <sources_bissbs>`]
1372 separately, create a directory like '~/linux-builddir/' and add the parameter
1373 ``O=~/linux-builddir/`` to all make calls used throughout this guide. You will
1374 have to point other commands there as well -- among them the ``./scripts/config
1375 [...]`` commands, which will require ``--file ~/linux-builddir/.config`` to
1382 that's what you intend (see next step), but in all other cases you want to
1408 kernel (say 6.1) on an older mainline release -- especially if it is much older
1409 (say 5.15). That's one of the reasons why the previous step in the guide told
1415 configuration; usually ``ls /boot/config-$(uname -r)`` will print its name. Copy
1419 [:ref:`back to step-by-step guide <oldconfig_bissbs>`]
1429 As explained briefly in the step-by-step guide already: with localmodconfig it
1430 can easily happen that your self-built kernels will lack modules for tasks you
1434 kernel the modules will not have been loaded -- and from localmodonfig's point
1439 additional kernel modules: start a VM, establish VPN connections, loop-mount a
1443 is hard to think of everything that might be needed -- even kernel developers
1452 But if you plan to build and use self-built kernels regularly, you might want to
1454 a few weeks. You can automate this with `modprobed-db
1455 <https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to
1456 point localmodconfig to the list of modules modprobed-db noticed being used::
1461 case you copied a suitable .config over to use as base (see previous step). Just
1462 run ``lsmod > lsmod_foo-machine`` on that system and copy the generated file to
1464 step-by-step guide mentions::
1466 yes '' | make LSMOD=~/lsmod_foo-machine localmodconfig
1468 [:ref:`back to step-by-step guide <localmodconfig_bissbs>`]
1480 '-local' in the name; it also helps picking the right entry in the boot menu and
1484 [:ref:`back to step-by-step guide <tagging_bissbs>`]
1510 'Decode failure messages' in Documentation/admin-guide/reporting-issues.rst
1513 [:ref:`back to step-by-step guide <debugsymbols_bissbs>`]
1541 ./scripts/config --set-str SYSTEM_TRUSTED_KEYS ''
1545 <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
1546 -- or generate your own, as explained in
1547 Documentation/admin-guide/module-signing.rst.
1549 [:ref:`back to step-by-step guide <configmods_bissbs>`]
1560 to enable or disable certain features using a text-based user interface; to use
1566 [:ref:`back to step-by-step guide <configmods_bissbs>`]
1583 [:ref:`back to step-by-step guide <saveconfig_bissbs>`]
1588 -----------------------------------------------------
1609 do -- in which case your problem from the perspective of the Linux kernel
1611 Documentation/admin-guide/reporting-regressions.rst explains in more detail.
1617 often caused by problems in mainline changes that were backported -- in which
1633 Your report might be ignored if you send it to the wrong party -- and even
1637 [:ref:`back to step-by-step guide <introlatestcheck_bissbs>`]
1648 problem, remember to run that ``git fetch --shallow-exclude [...]`` command
1651 [:ref:`back to step-by-step guide <checkoutmaster_bissbs>`]
1662 yourself. Another subsection explains how to directly package your kernel up as
1678 error. To make it easier to spot, this command also omits the ``-j $(nproc
1679 --all)`` used earlier to utilize every CPU core in the system for the job -- but
1684 for the most important and non-generic section of that line (say 4 to 8 words);
1685 avoid or remove anything that looks remotely system-specific, like your username
1700 Package your kernel up
1703 The step-by-step guide uses the default make targets (e.g. 'bzImage' and
1706 and directly package it up by using one of the following targets:
1708 * ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
1710 * ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
1712 * ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
1716 ``make -j $(nproc --all)``, as they will pick up everything already built.
1719 step-by-step guide's instructions on installing and removing your kernel;
1727 [:ref:`back to step-by-step guide <build_bissbs>`]
1736 What you need to do after executing the command in the step-by-step guide
1745 image in /boot/, usually as '/boot/vmlinuz-<kernelrelease_id>'; often it will
1746 put a 'System.map-<kernelrelease_id>' alongside it.
1750 '/boot/initramfs-<kernelrelease_id>.img' or
1751 '/boot/initrd-<kernelrelease_id>'. Commodity distributions rely on this file
1764 sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
1765 sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)
1770 [:ref:`back to step-by-step guide <install_bissbs>`]
1782 fill up volumes during a bisection -- and due to that even kernels which used to
1786 Note, most of the time the pattern '/boot/*$(make -s kernelrelease)*' used in
1787 the guide will match all files needed to boot your kernel -- but neither the
1791 [:ref:`back to step-by-step guide <storagespace_bissbs>`]
1802 follow-up errors that look totally unrelated. That is why developers might
1803 ignore or react scantly to reports from tainted kernels -- unless of course the
1807 Documentation/admin-guide/tainted-kernels.rst; doing so is also in your own
1810 [:ref:`back to step-by-step guide <tainted_bissbs>`]
1820 There are a couple of reasons why your bug or regression might not show up with
1828 * Your problem might be a race condition that does not show up with your kernel;
1833 be a problem that is specific to that series; the next step in this guide will
1836 [:ref:`back to step-by-step guide <recheckbroken_bissbs>`]
1851 [:ref:`back to step-by-step guide <recheckstablebroken_bissbs>`]
1856 ------------------------------------------------
1865 That is in your own interest, as trimming the configuration is not foolproof --
1871 Many readers of this guide normally run kernels that are patched, use add-on
1872 modules, or both. Those kernels thus are not considered 'vanilla' -- therefore
1881 [:ref:`back to step-by-step guide <introworkingcheck_bissbs>`]
1892 self-built kernel, find and resolve the cause before moving on. There are a
1915 [:ref:`back to step-by-step guide <recheckworking_bissbs>`]
1918 -------------------------------------------
1925 [:ref:`back to step-by-step guide <introbisect_bissbs>`].
1936 check out a commit round about half-way between the 'good' and the 'bad' changes
1939 [:ref:`back to step-by-step guide <bisectstart_bissbs>`]
1957 work better. Afterwards restart executing this step.
1962 base them on a somewhat earlier point like 6.1-rc1 or even 6.0 -- and then
1964 leads to those slightly odd looking version identifiers coming up during
1967 [:ref:`back to step-by-step guide <bisectbuild_bissbs>`]
1981 [:ref:`back to step-by-step guide <bisecttest_bissbs>`]
1994 allow someone to point out where a bisection likely went sideways -- and then
2001 [:ref:`back to step-by-step guide <bisectlog_bissbs>`]
2011 This is an optional step, but whenever possible one you should try: there is a
2012 decent chance that developers will ask you to perform this step when you bring
2013 the bisection result up. So give it a try, you are in the flow already, building
2016 The step-by-step guide covers everything relevant already except one slightly
2019 try to revert the culprit in the affected stable/longterm series -- and if that
2022 [:ref:`back to step-by-step guide <revert_bissbs>`]
2025 ---------------------------------------------------
2030 The steps in this section describe clean-up procedures.
2032 [:ref:`back to step-by-step guide <introclosure_bissbs>`].
2036 Cleaning up during the bisection
2039 *To remove one of the kernels you installed, look up its 'kernelrelease'
2044 need to worry to mess up your machine when you install a kernel manually (and
2053 The other place is /boot/, where typically two up to five files will be placed
2057 some distributions the ``kernel-install remove...`` command mentioned in the
2058 step-by-step guide will delete all of these files for you while also removing
2062 '6.0-rc1-local-gcafec0cacaca0'::
2064 rm -i /boot/{System.map,vmlinuz,initr}-6.0-rc1-local-gcafec0cacaca0
2067 '6.0-rc1-local-gcafec0cacaca0' in their name and consider deleting them as well.
2075 [:ref:`back to step-by-step guide <makeroom_bissbs>`]
2077 Cleaning up after the bisection
2083 you set up, as you might need a few things again.*
2087 the step-by-step guide might not free as much space as you would like. In that
2088 case consider running ``rm -rf ~/linux/*`` as well now. This will remove the
2090 (~/linux/.git/) behind -- a simple ``git reset --hard`` thus will bring the
2095 perform additional tests -- like testing a debug patch or a proposed fix.
2100 ~/kernel-config-working file around for a few weeks.
2102 [:ref:`back to step-by-step guide <finishingtouch_bissbs>`]
2107 ----------------------------------------
2118 [:ref:`back to step-by-step guide <introoptional_bissbs>`].
2127 ------------------------------------
2129 To compile kernels on another system, slightly alter the step-by-step guide's
2137 modules to a file using ``lsmod > ~/test-machine-lsmod``. Then locate the
2140 to find it) and store it as '~/test-machine-config-working'. Transfer both
2151 cp ~/test-machine-config-working ~/linux/.config
2153 * During the next step to ':ref:`disable any apparently superfluous kernel
2156 yes '' | make localmodconfig LSMOD=~/lsmod_foo-machine localmodconfig
2159 install, and reboot into a kernel every time they come up. Instead build
2162 cp ~/kernel-config-working .config
2164 make -j $(nproc --all) targz-pkg
2168 '6.0.0-rc1-local-g928a87efa423' built for x86 machines usually will
2169 be stored as '~/linux/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz'.
2176 sudo tar -xvzf ~/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz -C /
2182 … sudo /sbin/installkernel 6.0.0-rc1-local-g928a87efa423 /boot/vmlinuz-6.0.0-rc1-local-g928a87efa423
2187 cross-compilers and add the appropriate parameters to every invocation of make
2188 (e.g. ``make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [...]``).
2191 ---------------------------
2193 * The `man page for 'git bisect' <https://git-scm.com/docs/git-bisect>`_ and
2194 `fighting regressions with 'git bisect' <https://git-scm.com/docs/git-bisect-lk2009.html>`_
2196 * `Working with git bisect <https://nathanchance.dev/posts/working-with-git-bisect/>`_
2202 end-of-content
2207 want to contribute changes to the text -- but for copyright reasons please CC
2208 linux-doc@vger.kernel.org and 'sign-off' your contribution as
2209 Documentation/process/submitting-patches.rst explains in the section 'Sign
2210 your work - the Developer's Certificate of Origin'.
2212 This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
2213 of the file. If you want to distribute this text under CC-BY-4.0 only,
2216 …linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/verify-bugs-and-bisect-regress…
2220 is available under CC-BY-4.0, as versions of this text that were processed