Re: SPL NOT ZERO ON SYSCALL ENTRY

[Andrew Doran <ad%NetBSD.org@localhost>]

On Wed, Mar 19, 2008 at 10:53:25AM +0100, Matthias Drochner wrote:

> ad%NetBSD.org@localhost said:
> > I also suspect it's some corner case or race condition with the soft
> > interrupt code. 
> 
> I've got a nice DDB stacktrace which also points into
> that direction.
> Another observation is that the CPU which does not
> lower the SPL on syscall exit is always CPU 1.
> (Softints run always on CPU 0, right?)

They can run on any CPU. A softint will only fire and run on the same CPU it
was triggered on: the processing is per-CPU as are the kernel threads.
 
> CPU0:
> mutex_spin_enter()
> sched_pstats()
> callout_softclock()
> softint_execute()
> softint_dispatch()
> 
> CPU1:
> (Breakpoint after the "spl not lowered" printf)
> Xsyscall

It's unlikely to be related for the reason given above, and because the
snapshot of activity you get from CPUs other than the CPU that originally
panic'ed is from some time after the panic happened. Hmm, it would be
worthwhile to add another KASSERT() in softint_execute() to make sure that
the scheduler doesn't do something stupid like putting a bound kernel thread
onto another CPU.

Andrew