On Iau, 2005-09-01 at 14:47 -0700, Tom Rini wrote:
> > > + * If there is some other CPU in KGDB then this is a
> > > + * spurious interrupt. so return without even checking a byte
> > > + */
> > > + if (atomic_read(&debugger_active))
> > > + return IRQ_NONE;
> > > +
> >
> > Shared IRQ -> hung box.
>
> Can you elaborate a bit more please? When we're actually in KGDB and
> working on stuff we're polling so it's really just the
> GDB-is-interrupting case.
If the IRQ source is level triggered and the device is the cause then as
soon as you exit the IRQ handler, you'll be called again and again and
again until the IRQ is cleared or 10,000 tries or so occur when the IRQ
is disabled
Does this only occur if there is a stray IRQ under delivery as kgdb is
entered ? (ie you do something like
write irq off to port
read back if mmio (to avoid posting)
atomic_inc(&debugger_active)
??
)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
