On Mon, Apr 30, 2001 at 12:39:58PM +0900, Henry Nelson wrote:
> > >> "Stray interrupt on IRQ 7" (or words to that effect), followed by "wd2 
> > >> at pcmcia1 function 0".  It never comes back after that.  Hitting 
> > >> cntl+alt+esc makes it say "cardslot1 at cpu_Debugger+0x4 leave".
> > >
> > >Can you try it using pcic (i.e. plain PCMCIA), rather than pccbb (i.e.
> > >CardBus)?  I believe this is instantiation of an IRQ stalling behavior
> > >I reported AGES ago, which is tickled by pccbb because it uses
> 
> What is the meaning of "Stray interrupt on IRQ 7"?  I have gotten that
> message repeated over and over in two distinct situations:

It means the interrupt controller reported an unmasked interrupt on IRQ
7, but no driver attached to that IRQ `claimed' it.

There are two reasons this can happen:

1) In anything other than a PC, it would ~always mean that there is a
   driver attached to the IRQ (otherwise it would be masked), but it is
   the wrong driver.  (This is probably not what's happening to you.)

2) This being a PC, there is the more obscure issue of `default IR7's.
   That is, when a device asserts an IRQ, but the IRQ is deasserted
   after the PIC latches the interrupt and before the CPU acknowledges
   it, the PIC just flat out lies about which IRQ it was.  This is
   what's happening in both of the cases you cite -- in one case due
   to an implicit race condition between the hackish kernel output
   handling, and in the other case probably due to a suboptimally coded
   driver.

   There is a scheme for recognizing `default IR7's, but it turns out
   that it fails badly on some older systems, and in general it's
   better to fix drivers to not generate them in the first place.  In
   some cases it's difficult to completely prevent them when using
   edge-triggered interrupts, though.

Regardless, you should only see those messages with a DEBUG kernel,
IIRC.