On 3/29/20 10:21 PM, Miroslav Zubcic wrote: > Thank you for this docs pointer. I'm cloning linux.git now and reading > what is git-bisect option anyway. Looks like I will have to run perl > script which will find the maintainer of the minor peripheral driver > "kernel/cpu.c". :-)
Not really necessary. You just use bisect to find the commit which introduced the regression and then send an email to the sparc-linux Linux kernel mailing list and CC the author of said commit. Usually the author will figure out quickly what mistake they made. > I'm reading now how kernel things are functioning in this decade, > because apart from two kernels on this sparc in past 2-3 months, I have > actively compiled kernels 12-15 years ago last time! Yeah, you basically just have to compile your kernel for debugging these days. But it's very simple: $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ cd linux $ git bisect start $ git bisect good v4.19 $ git bisect bad v5.4 BUILD Then: $ cp -av /boot/config-$(uname -r) && yes | make oldconfig $ make && make modules_install && make install && update-grub # update-grub may not be necessary $ reboot If it crashes: $ git bisect bad If it works $ git bisect good Then jump back to BUILD and repeat until git tells you the bad commit. > P. S. > Are there any special options for compiling or pre-configuring kernel > for debugging in the cases like this? CFLAGS="-g" or something like that? No. Bisecting doesn't require any debugging. You just build and test kernels using a bisect algorithm until you found the bad commit. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913