Re: Various cats problems

[Richard Earnshaw <rearnsha%buzzard.freeserve.co.uk@localhost>]

rearnsha%buzzard.freeserve.co.uk@localhost said:
> Well, here's one run that failed:
> simple_lock: lock held
>  

> lock: 0xf02b536c, currently at: /work/rearnsha/netbsd/src-2.0/sys/kern/
> kern _time out.c:242
>             

> last locked: /work/rearnsha/netbsd/src-2.0/sys/kern/kern_timeout.c:283
>  

> last unlocked: /work/rearnsha/netbsd/src-2.0/sys/kern/kern_timeout.c:392
>  


This is easily understandable.  It happens because SPL_SERIAL is higher 
than SPL_SCHED, and because the serial line drivers schedule callouts (in 
this case it was the fcom driver, but a quick look at com.c suggests that 
that *might* be able to do the same thing).

What's really not clear is whether its right to be managing callouts from 
within the serial drivers, or whether the callout code should be raising 
the bar even higher than it already is, so that even serial interrupts are 
blocked.  Looking at the code ARM isn't the only port to have SPL_SERIAL 
set higher than SPL_SCHED: the x86 code seems to have this too.

R.