Re: pccbb crashes when detaching (unsafe interrupt handler)

In message: <20040816153437.GJ980_at_green.homeunix.org>
            Brian Fundakowski Feldman <green_at_FreeBSD.org> writes:
: Can we start off again on a good foot so we can fix this before
: -STABLE?  I think, at a very very low cost (instruction cache
: bloat, but few extra instructions in the fast-path), we can implement
: suspension of ithread handlers.  This would completely solve the
: problem at hand, and all the "slowness" would be pushed onto
: the ithread munging calls.

I think the day of code freeze makes this too late.

: I get an immediate panic when running X and unloading a card on my
: notebook because they share interrupts. I get an immediate panic on
: eject and kldunload, the exact same case, on my desktop when I'm playing
: music and interrupts are shared between the cardbus and the sound card.
: I don't think there would be harm pausing the interrupt handler to
: create a critical section there.

I already fixed this.  At least on my machine.  The races that you
pointed out have been corrected.  Have you tested it recently?  It
works for me w/o any problems, but I'll spend some time today.

: That is, it_need would be cleared, ih_need would be cleared and
: unsuspended interrupt handlers run, suspended interrupt handlers
: acknowledged and then run once they become unsuspended. Where IH_DEAD is
: checked would be added the test for suspension and acknowledgement.
: We could use the mutex to synchronize the ithread suspension function by
: setting a flag IH_WANTSUSPEND, use a flag IH_SUSPENDED to mark it
: suspended, and only allow a single suspension at a time (the
: ithread suspender would have to sleep until it can grab IH_WANTSUSPEND).
: The cost would be nil (testing (IH_DEAD | IH_*SUSPEND*) instead of
: IH_DEAD) plus one store and load (stack variable initialized to 0
: for "need to run suspended handlers" after they have been iterated
: through the first time).

I don't think we need this.  The lists are already protected by
mutexes.  The problems you pointed out were in how the pccbb layer was
bogusly handling things.  Since I've merged the fixes into -current
already, I don't see a need for the above.

So I claim there's no problems with completely up to date sources.
I'll test this claim later today on my laptop (I'll try it after the
buildworld is done), but I'm pretty sure I tested it before putting it
in p4.

: Comments, please.

Too late.

Warner