Re: Tracing NetBSD sun4v issues

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Fri, 9 Oct 2026 14:59:45 +0100
Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:

> I'm trying to trace the root cause of NetBSD issues on sun4v. I have a
> small user space test program that reliably dies with SIGSEGV. The test
> involves calling setpassent() which in turn calls nsdispatch() where it
> dies.
> 
> I added printf() statements to those functions to see where it dies in
> nsdispatch():
> 
> int
> /*ARGSUSED*/
> nsdispatch(
> 	void *retval, const ns_dtab disp_tab[], const char *database,
> 	const char *method, const ns_src defaults[], ...)
> {
> 	....
> 
> 	return (result ? result : NS_NOTFOUND);
> }
> 
> And it dies when executing the last return statement. The nsdispatch()
> function does not appear to return to its caller because the process
> dies and the next printf() debug statement after this function is not
> executed.

I reverted back to locore.s rev 1.435 as this version causes SEGV with
my test program and I'm thinking the same issue is still present in
-current. So I've done some more debugging as I wanted to see what
happens when the return statement is executed

src/lib/libc/net/nsdispatch.c
int
/*ARGSUSED*/
nsdispatch(void *retval, const ns_dtab disp_tab[], const char *database,
	const char *method, const ns_src defaults[], ...)
{
	...

	write(STDOUT_FILENO, "***nsdispatch 06\n", 17);
	return (result ? result : NS_NOTFOUND);
}

Let's enable trap debug, see src/sys/arch/sparc64/sparc64/trap.c

# sysctl -w hw.cnmagic=12345
# 12345
db{0}> write/l trapdebug 0x8b

Execute my test program and see what traps occur after the
"***nsdispatch 06" debug statement:

# /test
... trap debug output
[  65.2731497] 110: data_access_fault(0x154697ed0, 31, 0x405688cc, 0x402a0011, 402a0000, 1) nsaved=0
[  65.2731497] cpu0: data_access_fault: user uvm_fault(0x100a047c0, 402a0000, 1) sez 0 -- success
[  65.2731497] data_access_fault: done
[  65.2731497] 110: data_access_fault(0x154697ed0, 31, 0x4056c210, 0x406da011, 406da000, 1) nsaved=0
[  65.2835171] cpu0: data_access_fault: user uvm_fault(0x100a047c0, 406da000, 1) sez 0 -- success
[  65.2835171] data_access_fault: done
***nsdispatch 06
[  65.2835171] 110 text_access_fault(9, 40690011, 0x154697ed0)
[  65.2835171] text_access_fault: uvm_fault(0x100a047c0, 40690000, 4) sez 0
[  65.2835171] text_access_fault: done
[  65.2835171] 110: data_access_fault(0x154697ed0, 31, 0x40568850, 0x402a2011, 402a2000, 1) nsaved=0
[  65.2929154] cpu0: data_access_fault: user uvm_fault(0x100a047c0, 402a2000, 1) sez 0 -- success
[  65.2929154] data_access_fault: done
[  65.2929154] 110: data_access_fault(0x154697ed0, 31, 0x40589b50, 0xffffc011, ffffc000, 1) nsaved=0
[  65.2929154] cpu0: data_access_fault: user uvm_fault(0x100a047c0, ffffc000, 1) sez e -- failure
[  65.2929154] cpu0: data_access_fault at addr 0xffffc011: sending SIGSEGV
[  65.3018675] 110: data_access_fault(0x154697ed0, 31, 0xffffc011, 0x40589b50, ffffc000, 1) nsaved=0
Stopped in pid 110.110 (test) at        netbsd:cpu_Debugger+0x4:        nop
db{0}>

So it is possible that the above text and data access fault handlers
are causing corruption somewhere. I also find it suspicious that when
SEGV occurs there is a data access fault:

[  65.2929154] 110: data_access_fault(0x154697ed0, 31, 0x40589b50, 0xffffc011, ffffc000, 1) nsaved=0

where:
0x154697ed0  trap frame address
31           trap type
0x40589b50   program counter
0xffffc011   faulting virtual address
ffffc000     synchronous fault virtual address
1            synchronous fault status register

And it looks like the faulting virtual address could be wrong. It would
appear the upper bits have been set to zero causing it to be
0xffffc011. As far as I know sparc64 stack addresses start at the upper
end of the memory e.g. 0xffffffffffffc011.

Any ideas?