So I have a Vega 64 card where I use a reset process to be able to pass through to my VMs. When upgrading from 5.16 to 5.17.4 this no longer works and the kernel crashes with an oops. I was able to switch to the LTS branch (5.15) and that has solved my issue in the meantime. I’d like to see if I can’t find the root cause of the issue though and to do that I think I need to bisect the kernel and determine when the breaking change occurred. Reading through a few articles though I’m not sure how I can do this with Arch. There are instructions on the wiki, but after compiling the kernel I assume I’d then have to install it, perform a reboot and test. The directions don’t really have those steps – does anyone know of a better guide or have done this before?
When you run “git bisect start”, you provide and starting and ending point with “git bisect bad [commit]” and “git bisect good [commit]”. Here the bad commit would be the tag for 5.17.4, the good commit would be the tag for 5.16.
Once git bisect has a starting and ending point, it will jump to the commit in the middle. You have then recompile the kernel, reboot and test, then tell git whether the commit was “git bisect good” or “git bisect bad”. If your commit was good, then the problem must lie between mid point and ending point; if your commit is bad, then the problem must lie between starting point and mid point.
By operating on the middle commit in a range, the git bisect algorithm will find the bad commit in approxmiately Log2(n) steps. So if you’re testing 1000 commits, you’d expect to find the bad commit in 5-10 tests.
As for the building process, maybe you’ll want to look at this AUR script - AUR (en) - linux-git. IIRC you can change the source in that script to " ```
git+https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux#commit-id
The method @cowphrase mentions - letting git keep track of where you are in commit chain is good.
Just beware - there’s technically a small chance some kernels can break your hardware, and/or eat your data, maybe it doesn’t even build in some cases,… basically make sure you have a backup, and do restore from backup once you’re done playing with random kernels.
Also if you have dkms packages or other sources of drivers, you should probably take a note of them and uninstall them before starting.
The official Arch way to do kernel stuff is to use their build system (abs) → Kernel/Arch Build System - ArchWiki
You can go about building and installing the kernel the traditional way (via make), but I find using abs a bit easier as it already includes their configuration and you can just install the result with pacman. I haven’t played around with the AUR package that @cowphrase linked to, I’d be curious how different that PKGBUILD is to the official one you pull down and modify with abs.