Re: NetBSD-10.0/i386 spurious SIGSEGV

Emmanuel Dreyfus <[email protected]>
Newsgroups gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
On Sat, Jun 08, 2024 at 10:10:58PM -0400, Mouse wrote:
> First thing I'd look at is the userland instruction(s) around the crash
> point, maybe look at instructions starting at 0xbb610480 or something
> and then disassemble forwards looking for 0xbb610579.  In particular,
> I'd be interested in whether it's a store instruction that failed or
> whether this happened during a syscall trap.

   0xbb610570 <__gettimeofday50>:	mov    $0x1a2,%eax
   0xbb610575 <__gettimeofday50+5>:	int    $0x80
   0xbb610577 <__gettimeofday50+7>:	jb     0xbb61057a <__gettimeofday50+10>
=> 0xbb610579 <__gettimeofday50+9>:	ret  

> Are all the failures in __gettimeofday50?  All in trap-to-the-kernel
> calls?

I have seen many crashes on system call returns. Another one on
__gettimeofday50:

   0xbb610570 <__gettimeofday50>:	mov    $0x1a2,%eax
   0xbb610575 <__gettimeofday50+5>:	int    $0x80
   0xbb610577 <__gettimeofday50+7>:	jb     0xbb61057a <__gettimeofday50+10>
   0xbb610579 <__gettimeofday50+9>:	ret    
=> 0xbb61057a <__gettimeofday50+10>:	push   %ebx

Another one:
   0xbb610570 <__gettimeofday50>:	mov    $0x1a2,%eax
   0xbb610575 <__gettimeofday50+5>:	int    $0x80
=> 0xbb610577 <__gettimeofday50+7>:	jb     0xbb61057a <__gettimeofday50+10>
   0xbb610579 <__gettimeofday50+9>:	ret  

At once I thought about a stack problem, but I think the last one proves
this is not the case. This one involves no memory access.

> You say "multiple machines"; are those multiple domUs on a single dom0,
> or are they spread across multiple underlying hardware machines? 

It happens on multiple hardware machines and starts on upgrading the 
domU. I even tested moving a domU from one machine to another one 
and the bug folllowed. Other netbsd-9 domU on the same dom0 have
no problem, or at least it is rare enough that I did not notice
for years.

> If the latter, how similar are those underlying machines? 

Same model:
vcpu3: Intel(R) Xeon(R) CPU E3-1220 v6 @ 3.00GHz, id 0x906e9


-- 
Emmanuel Dreyfus
[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.