Re: kernel panic with pccard insert on recent 7.0 CURRENT

In message: <[email protected]>
            "Hidetoshi Shimokawa" <[email protected]> writes:
: On 6/19/07, Paolo Pisati <[email protected]> wrote:
: > On Sun, Jun 17, 2007 at 10:58:12AM +0900, Hidetoshi Shimokawa wrote:
: > > And INTR_FILTER doesn't seem well-tested at least for
: > > handling of stray interrupts for filter only IRQs.
: > > I need the following patch to workaroung the problem.
: > >
: > > http://people.freebsd.org/~simokawa/tmp/kern_intr.c-20070617.patch
: > > on which platform?
: 
: amd64
: 
: > cause, right now, if there's a stray interrupt we disable the
: > irq line if the interrut disable function is hooked to
: > ie_disab:
: 
: My patch may be wrong. But it seems too restrictive to disable the
: interrupt forever
: only one stray interrupt. Drivers could return _STRAY even if it is the source.

I've seen hardware cause spurious interrupts all the time.  Part of
this experience dates back to the 4.x behavior of ISRs, but sometimes
hardware does just glitch.  You get a lot of glitching with CardBus/PC
Card insertion and removal events, even when one is very careful.  The
CardBus bridge is somewhat broken by design: if the card inserted
asserts the interrupt, then we'll get an interrupt.  During power up,
this can easily happen, and would result in 'STRAY' interrupts
happening.  These are not ill-behaved cards, but rather a squishy part
of the spec that some bridge makers have made good engineering
decisions, while others have made good business decisions about gate
counts..

While I can see the need to turn of an interrupt source that has
boatloads of stray interrupts, 'one' doesn't count as a boatload.

Warner

_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"