>Number:         12913
>Category:       kern
>Synopsis:       isa(4) doesn't explain "stray interrupts"
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 11 18:47:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     John Hawkinson
>Release:        -current of 22 Apr 2001
>Organization:
MIT
>Environment:
	
System: NetBSD zorkmid.mit.edu 1.5U NetBSD 1.5U (ZORKMID-$Revision: 1.10 $) #94: Sun Apr 22 16:38:31 EDT 2001 jhawk@zorkmid.mit.edu:/usr/local/netbsd-current/src/sys/arch/i386/compile/ZORKMID i386


>Description:
	isa(4) doesn't talk about what a stray interrupt means. It should.
>How-To-Repeat:
	
>Fix:
	
	Perhaps use this message from Charles as a starting point
Subject: Re: problems with pcmcia hard drive
Date: Sun, 29 Apr 2001 21:15:56 -0700
From: "Charles M. Hannum" <abuse@spamalicious.com>
To: Henry Nelson <henry@irm.nara.kindai.ac.jp>
Cc: netbsd-users@netbsd.org
Subject: Re: problems with pcmcia hard drive
Message-ID: <20010429211556.U25151@mail.netbsd.org>
References: <200104300339.MAA03980@ibr1.irm.nara.kindai.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200104300339.MAA03980@ibr1.irm.nara.kindai.ac.jp>; from henry@irm\
.nara.kindai.ac.jp on Mon, Apr 30, 2001 at 12:39:58PM +0900


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

>Release-Note:
>Audit-Trail:
>Unformatted: