On 4/3/22 13:42, Dennis Clarke wrote:
>> But since you seem to have a reliable reproducer, you can start trying to 
>> bisect
>> the kernel to find the commit that introduced this regression.
> That will be nearly impossible. I can not even recall when the bug first
> appeared or when was the last time that I could run update-grub without
> the machine locking up. At least two years now. Maybe three.

What do you mean is impossible? Bisecting the bug or the fact that it is
a kernel bug? I know very well it's a kernel bug because it does not occur
when using the 4.19 kernel on any of the affected SPARCs and it does not
occur on any of the newer SPARCs with a current kernel.

The SPARC T2 and T5 we are using don't have the problem at all, for example.

> Also this is an even older UltraSparc IIi type machine. Really I should
> have tossed it out long ago but the next machine I have handy is a
> Fujitsu M3000 unit and I thought I had heard it was impossible to get
> Linux on such a beast for unknown reasons. Could be myth or rumour but I
> thought the M3000 was somehow "special". The larger M4000 seems to be
> fine but those are just nasty large beasts to run in a home lab.
> Dragging the deep waters looking for that kernel bug will take a lot of
> time. Possibly even some luck.

Not really. You cross-build the kernel, transfer it to the machine and see if
update-grub works. If it doesn't, you mark the commit as bad. If it does, you
mark the commit as good. You start from a good known working kernel such as

But I can do it myself if I find the time, I have an Ultra 45 that can be used
for that. Thought it would just be nice if I can get a helping hand, especially
since cross-compiling and bisecting the kernel isn't really hard, it just takes


 .''`.  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

Reply via email to