Re: NetBSD on Sun T5220

On Tue, 30 Sep 2025, Sad Clouds wrote:

>
> Hi, I'll see if I can help out with debugging these issues. Does this
> usually manifest itself as alignment errors?


This is an example from my local build with lots of debug code added:


[  65.7404377] Trapframe 0x178831ed0:   tstate: 4400000205      pc: 61502c 
npc: 615030
[  65.7404377] fault: 0x4400000205      y: fffffc26     pil: 0  oldpil: 0 
tt: 34
[  65.7404377] Globals:
[  65.7404377] 0000000000000000 0000000000000c06 0000000000000007 
0000000000000000
[  65.7404377] 0000000000000000 000000000061502c 0000000000000000 
0000000040952150
[  65.7404377] Outs:
[  65.7404377] 0000000000000000 0000000000000000 00000000ffffffff 
0000000000a23000
[  65.7404377] 0000000000a23000 0000000000000032 ffffffffffff9721 
0000000000615024
[  65.7404377] Locals:
[  65.7404377] 0000000040a50590 000000000badcafe 000000000badcafe 
000000000badcafe
[  65.7404377] 000000000badcafe 000000000badcafe 000000000badcafe 
000000000badcafe
[  65.7404377] Ins:
[  65.7404377] 0000000040a1ba10 ffffffffffffa190 00000000009e9000 
0000000040a0b000
[  65.7504412] 0000000000a23000 0000000000a23000 ffffffffffff98b1 
000000000012d84c
[  65.7504412] insn c205c000


The insn is a load instruction from register %l7 and the dump above has 
%l7 containing 0xbadecafe which will cause an unaligned access from 
address 0xbadcafe.

I have additional debugging output that shows that  the register window is 
probably restored with incorrect values probably originating from a spill 
trap at trap level 1 that stores the incorrect register window.


> I tried booting into single user mode, but init kept dying due
> to /bin/sh crashing with alignment errors. After trial and error, I
> realised if I copy /bin/sh from older NetBSD-9.4 system, the crash did
> not occurs and init started correctly.
>
> At this stage I'm not sure if this was the register corruption and
> older /bin/sh just happened to avoid it by executing slightly different
> code paths, or if there are some real alignment issues with /bin/sh in
> -current.
>

I don't think any of the userland code is the origin of the issue - the 
issue is within the kernel handling of spill traps - probably executed 
during trap level 1 scenarios.


More debugging to be done, but my understading of the issue has improved 
during the past weeks... :-)