Subject: Re: Various cats problems
To: Chris Gilbert <chris@dokein.co.uk>
From: Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk>
List: port-cats
Date: 05/05/2004 01:01:47
rearnsha@buzzard.freeserve.co.uk 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.