Regression in 028abd92 for Sun UltraSPARC T1
Dear all,
Riccardo Mottola first recognized a problem with 5.10.x kernels on his
Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify
the problem also on my Sun T1000 and it looks like this specific issue
breaks the mounting of the root FS or maybe mounting file systems at
all. This affects both booting from disk and from network.
[this thread]: https://lists.debian.org/debian-sparc/2021/03/msg00004.html
I bisected the Linux kernel between:
bbf5c979011a099af5dc76498918ed7df445635b (good)
...and:
3650b228f83adda7e5ee532e2b90429c03f7b9ec (bad)
...and the process identified:
028abd9222df0cf5855dab5014a5ebaf06f90565 ([1])
...as first bad commit.
```
commit 028abd9222df0cf5855dab5014a5ebaf06f90565
Author: Christoph Hellwig <hch@lst.de>
Date: Thu Sep 17 10:22:34 2020 +0200
fs: remove compat_sys_mount
compat_sys_mount is identical to the regular sys_mount now, so
remove it
and use the native version everywhere.
```
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=028abd9222df0cf5855dab5014a5ebaf06f90565
Details about the bisecting on [2].
[2]: https://lists.debian.org/debian-sparc/2021/03/msg00042.html
So far this only affects UltraSPARC T1 processors. I didn't see that
problem on a T5220 with UltraSPARC T2 and I also didn't see that problem
on a Sun Ultra Enterprise 450 with UltraSPARC II when testing a recent
Debian installation media with 5.10.x kernel some weeks ago. Other
UltraSPARC processors weren't tested yet. I plant to check UltraSPARC
IIIi and maybe others if time allows.
****
Do you maybe have an idea, what could go wrong with 028abd92
specifically on an UltraSPARC T1 processor?
I can provide a full log of a broken (network) boot process if that's
useful, I just need to re-create it. IIRC the kernel oopses for each
hardware thread (similar to what Riccardo wrote on the debian-sparc
mailing list above) and then stops.
Cheers,
Frank
Reply to: