Re: pccbb crashes when detaching (unsafe interrupt handler)

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 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.

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).

Comments, please.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green_at_FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\