Re: Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
Update:
Sorry it's taken me a while to start looking at this issue; my Ultra-30
was unavailable for about 5 days while it was updating Gentoo (I need to
configure a QEMU host for Sparc 64 to build and update my Debian and
Gentoo root filesystems).
Anyway, this morning I upgraded Debian SID again ("apt-get upgrade") and
noticed that it had updated the kernel and initrd. I made a mistake with
my symbolic link for the initrd, so it ended up booting without an
initrd, and the kernel boots fine (as expected, it fails to see the SCSI
disks). So the "Fast Data Access MMU Miss" error seems to be related
only to the initrd, which is consistent with my original message.
I don't think a kernel bisect will identify the issue, since the kernel
boots ok. This has something to do with the initrd, and I don't know how
to troubleshoot that. Any recommendations?
# ls -l vmlinuz initrd.img
lrwxrwxrwx 1 root root 26 Jul 31 08:07 initrd.img ->
initrd.img-6.4.0-1-sparc64
lrwxrwxrwx 1 root root 23 Jul 31 07:51 vmlinuz -> vmlinux-6.4.0-1-sparc64
# ls -l *6.4.0-1*
-rw-r--r-- 1 root root 83 Jul 29 22:50 System.map-6.4.0-1-sparc64
-rw-r--r-- 1 root root 186222 Jul 29 22:50 config-6.4.0-1-sparc64
-rw-r--r-- 1 root root 23023550 Jul 31 07:05 initrd.img-6.4.0-1-sparc64
-rwxr-xr-x 1 root root 19082504 Jul 29 22:50 vmlinux-6.4.0-1-sparc64
thanks
-Stan
-----
On 7/24/23 11:28 PM, John Paul Adrian Glaubitz wrote:
> Hi Stan!
>
> On Mon, 2023-07-24 at 15:46 -0600, Stan Johnson wrote:
>> The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
>> Ultra 30 with the following error at the PROM:
>>
>> -----
>> ...
>> Loaded kernel version 6.4.4
>> Loading initial ramdisk (23022746 bytes at 0x64000000 phys, 0x40C00000
>> virt)...
>> Fast Data Access MMU Miss
>> ok
>> -----
>>
>> I have been running a custom 6.2.10 kernel, and that continues to work.
>> I'm not sure whether this is related to Joacim Nilsson's cgroup fail
>> error on his Sun Ultra 5, but the failure message is different. I'll
>> have to investigate whether this could be a kernel regression.
>
> Thanks for the report.
>
> If you could bisect this issue and report the commit to the original author
> who introduced it while CC'ing the SPARC LKML, that would be extremely helpful.
>
> I have some older SPARCs myself, but currently no space to set them up for testing.
>
> Adrian
>
Reply to: