On Thu, Sep 01, 2005 at 11:44:44PM +0100, Alan Cox wrote: > 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
But in the shared IRQ and other source is the other uart still registered to the real 8250 driver, we'd luck out. I know this has been tested on a shared serial irq box, so it's not immediate and always death at least... > Does this only occur if there is a stray IRQ under delivery as kgdb is > entered ? (ie you do something like So digging back in CVS it seems this was added to fix a spurious interrupt that occured on an (probably) an x86_64 box when NMI support didn't work correctly. I think it's safe enough to just drop this. -- Tom Rini http://gate.crashing.org/~trini/ - 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/