Re: Xintr_ioapic_level3 jumps to 0 during softint_disestablish

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

On Fri, Apr 17, 2009 at 12:26:44PM -0500, David Young wrote:

> On Fri, Apr 10, 2009 at 01:08:44PM -0500, David Young wrote:
> > Xintr_ioapic_level3 tries to jump to an interrupt handler at 0 while
> > audio0 detaches a software interrupt handler (audiodetach calls
> > softint_disestablish).  I can reproduce this 100% of the time at
> > shutdown, if I set kern.detachall to 1, but I cannot reproduce it
> > otherwise.
> > 
> > I have just tried with kern.detachall=0, but audio(4) patched to always
> > detach at shutdown, and the crash is the same, so adding the audio
> > detachment to shutdown seems to be the critical difference, even if the
> > bug does not reside in audio(4).  audio0 is attached at pad0, btw.
> > 
> > Kernel configuration (debug.ojctech.com) at
> > <ftp://elmendorf.ojctech.com/users/netbsd-758e1bfc/ojctech.com> and
> > <ftp://elmendorf.ojctech.com/users/netbsd-758e1bfc/debug.ojctech.com>.
> > 
> > Console typescript with dmesg, backtraces, registers, process listing at
> > <ftp://elmendorf.ojctech.com/users/netbsd-da5c9f4c/softint.crash>.
> 
> It was just a coincidence that audio(4) slept in softint_disestablish()
> every single time the crash occurred.  The real problem was that uhci(4)
> and ehci(4) disestablished their PCI interrupt hooks without disabling
> interrupts on the hardware, first.  I fixed that---see commit message,
> below.

That should not cause a crash. Further interrupts should cause the line
to be masked by the interrupt code. Sounds like a bug in intr.c to me.

I'm starting to sound like a broken record: interrupt disestablish can
race with interrupts on other CPUs and therefore is not yet safe...