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@xxxxxx> 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
