Re: SPL NOT ZERO ON SYSCALL ENTRY

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

On Tue, Apr 29, 2008 at 05:47:36PM +0200, Matthias Drochner wrote:

> ad%NetBSD.org@localhost said:
> > > $2 = {ipending = 0x40000000, ilevel = 0x7} 
> 
> The level is an 8 now, as expected:
> (gdb) print cpu_info_primary.ci_next->ci_istate
> $9 = {ipending = 0x40000000, ilevel = 0x8}
> 
> > ci_mtx_oldspl, ci_mtx_count?
> 
> (gdb) print cpu_info_primary.ci_next->ci_mtx_oldspl
> $12 = 0x0
> (gdb) print cpu_info_primary.ci_next->ci_mtx_count
> $13 = 0xffffffff
> 
> > You could instrument
> > arch/x86 and arch/i386 to record the last place that the IPL was raised
> > to IPL_HIGH before the panic
> 
> So it looks like a leaked spinlock with IPL_HIGH, or something
> between softintr() and mi_switch(), right?
> None of the spinlocks I've found does fit to the workload
> I'm observing this at. So I more suspect the latter - unfortunately
> I have yet to understand the code.

Does this happen with LOCKDEBUG? If not, I suggest sprinkling assertions
where you see LOCKDEBUG_BARRIER to check ci->mtx_count is reasonable. Two
good places for an asssertion would be at the top/bottom of softint_execute.
At the start of mi_switch() it should be -1 because a spinlock is held.

Thanks,
Andrew