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