Re: What is wrong with kernels 5.X on sparc64 ?
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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: