> You might extend your debugging to log entry and exit from the system
> call routine, which will help you determine whether the hang is in the
> kernel or in userspace. 

I did dig a bit more, here is what happens:
- the IRIX process gets a SIGSEGV and it catches it
- it runs the system call handler...
- while it runs the system call handler, a _native_ process runs too
- The native process calls sigreturn, and we hang here, in kernel mode
(the native process never returns from sigreturn).

I dumped SR values during the scene. Some processes have 2000ff13, and
others 0000ff13. The 20000000 flag is SR_COP_1_BIT.

This flag is involved in FPU handing, I can see in the native sendsig
and sigreturn (sys/mips/mips/mips_machdep.c) that it is touched. I was
not paying attention to it in irix_sendsig and irix_sigreturn (neither I
did in linux_sendsig and linux_sigreturn).

Is someone able to explain me why and how it crashed? I understand the
IRIX signal delivery did not handle properly FP issues, but I don't
really understand how this causes a machine hang. I need to know because
now I added the code to handle FP save/restore, I still get a crash.

[I suggest follow-up to port-mips@]

-- 
Emmanuel Dreyfus.  
JavaScript est encapsule dans HTML, qui encapsulait
deja pas mal d'autres conneries comme ca.
manu@netbsd.org