From stephen@cauchy.math.missouri.edu  Mon Apr  3 08:05:46 2000
Return-Path: <stephen@cauchy.math.missouri.edu>
Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.72.27])
	by hub.freebsd.org (Postfix) with ESMTP id 1F56337B68B
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  3 Apr 2000 08:05:40 -0700 (PDT)
	(envelope-from stephen@cauchy.math.missouri.edu)
Received: (from stephen@localhost)
	by cauchy.math.missouri.edu (8.9.3/8.9.1) id KAA01729;
	Mon, 3 Apr 2000 10:03:47 -0500 (CDT)
Message-Id: <200004031503.KAA01729@cauchy.math.missouri.edu>
Date: Mon, 3 Apr 2000 10:03:47 -0500 (CDT)
From: stephen@math.missouri.edu
Sender: stephen@cauchy.math.missouri.edu
Reply-To: stephen@math.missouri.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: stray irq7
X-Send-Pr-Version: 3.2

>Number:         17774
>Category:       kern
>Synopsis:       stray irq7
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr  3 08:10:01 PDT 2000
>Closed-Date:    Sun Sep 16 21:28:42 PDT 2001
>Last-Modified:  Sun Sep 16 21:29:14 PDT 2001
>Originator:     Stephen Montgomery-Smith
>Release:        FreeBSD 4.0-STABLE i386
>Organization:
University of Missouri
>Environment:


>Description:

       With FreeBSD 4.0, when I print, I get stray irq7 error messages.
       This does not effect actual printing, so it is harmless.

       Here are the settings in my kernel config file, and also 
       dmesg.

# Parallel port
device          ppc0    at isa? irq 7
device          ppbus           # Parallel port bus (required)
device          lpt             # Printer
#device         plip            # TCP/IP over parallel
#device         ppi             # Parallel port interface device
#device         vpo             # Requires scbus and da



Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California. All rights reserved.
FreeBSD 4.0-STABLE #2: Fri Mar 31 13:40:45 CST 2000
    root@xxxxxxxxxxxxxxxxxxxxxx:/usr/src/sys/compile/XXXX
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 232671179 Hz
CPU: Pentium/P55C (232.67-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x543  Stepping = 3
  Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
real memory  = 33554432 (32768K bytes)
avail memory = 29929472 (29228K bytes)
Preloaded elf kernel "kernel" at 0xc02d8000.
Intel Pentium detected, installing workaround for F00F bug
md0: Malloc disk
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
isab0: <Intel 82371SB PCI to ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX3 ATA controller> port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: <NVidia Riva TNT graphics accelerator> at 8.0 irq 11
pcm0: <AudioPCI ES1370> port 0x6000-0x603f irq 10 at device 10.0 on pci0
rl0: <RealTek 8139 10/100BaseTX> port 0x6100-0x61ff mem 0xe2000000-0xe20000ff
irq 9 at device 11.0 on pci0
rl0: Ethernet address: xxxxxxxxxxxxxxxxxxx
miibus0: <MII bus> on rl0
rlphy0: <RealTek internal media interface> on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: supplying EUI64: xxxxxxxxxxxxxxxxxxx
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <keyboard controller (i8042)> at port 0x60-0x6f on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: IEEE1284 device found /NIBBLE
Probing for PnP devices on ppbus0:
ppbus0: <Hewlett-Packard LaserJet 4L> HP ENHANCED PCL5,PJL
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
joy0 at port 0x201 on isa0
ad0: 1623MB <FUJITSU M1623TAU> [3298/16/63] at ata0-master using WDMA2
ad1: 8063MB <WDC AC28400R> [16383/16/63] at ata0-slave using WDMA2
afd0: 120MB <LS-120 COSM 05 UHD Floppy> [963/8/32] at ata1-master using PIO2
acd0: CDROM <GCD-R580B> at ata1-slave using PIO3
Mounting root from ufs:/dev/ad0s2a
rl0: starting DAD for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
rl0: DAD complete for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx - no duplicates found
stray irq 7
stray irq 7
stray irq 7
stray irq 7
stray irq 7
too many stray irq 7's; not logging any more



>How-To-Repeat:

	Just print something.

>Fix:
	


>Release-Note:
>Audit-Trail:

From: Johan Karlsson <k@numeri.campus.luth.se>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/17774: stray irq7
Date: Fri, 11 Aug 2000 21:10:44 +0200

 Hi
 
 Every now and then a mail or PR pops up with this question.
 
 I search the FreeBSD web pages for info about this but did not 
 find any, maybe I just missed it.
 
 I suggest the following is added to the faq
 =============
 Q: What does 'stray irq' mean?
 A: Stray irq are interupts from some hardware that do not have
 a driver assigned to it. J Wunsch writes in a response to a PR 
 "Stray IRQs are a known phenomenon.  Obviously (if you think 
 about it :), there's nothing the kernel could do about it. 
 Unless you have misconfigured your kernel so there's no driver 
 assigned to a device that actually issues IRQs, they are a sign 
 of flakey hardware, often caused by glitches on an IRQ line."
        
 You have three choices:
  1) Live with the warnings 
  2) Get a driver for the hardware into your kernel
  3) Remove the hardware that generates the interrupts
 ==============
 
 The PR refered to is 2017
 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=2017
 
 /Johan K
 
 
 
 
 
 
 
Responsible-Changed-From-To: freebsd-bugs->freebsd-doc 
Responsible-Changed-By: johan 
Responsible-Changed-When: Fri Aug 11 12:11:03 PDT 2000 
Responsible-Changed-Why:  
Let the -doc folks have a look the suggested FAQ entry. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=17774 

From: Bruce Evans <bde@zeta.org.au>
To: Johan Karlsson <k@numeri.campus.luth.se>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/17774: stray irq7
Date: Sun, 13 Aug 2000 08:55:04 +1000 (EST)

 On Fri, 11 Aug 2000, Johan Karlsson wrote:
 
 >  I suggest the following is added to the faq
 
 The fwa? :-).
 
 >  =============
 >  Q: What does 'stray irq' mean?
 >  A: Stray irq are interupts from some hardware that do not have
 >  a driver assigned to it. J Wunsch writes in a response to a PR 
 
 No, they are mostly from hardware that removes its interrupt request
 in the middle of the interrupt request acknowledge cycle.  FreeBSD's
 interrupt handling (toggling the PIC masks at a critical time)
 probably amplifies this problem.  Assigning a driver can "fix" the
 problem by breaking detection of it.  The correct fix is to detect
 the stray interrupts caused by interrupt timing glitches and decide
 what to do about them (whatever is done, it shouldn't involve
 printing a faq magnet).
 
 Bruce
 
 

From: Johan Karlsson <k@numeri.campus.luth.se>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/17774: stray irq7 
Date: Sun, 13 Aug 2000 11:11:55 +0200

 At Sun, 13 Aug 2000 08:55:04 +1000, Bruce Evans wrote:
 > On Fri, 11 Aug 2000, Johan Karlsson wrote:
 > 
 > >  I suggest the following is added to the faq
 > 
 > The fwa? :-).
 
 ???
 
 > 
 > >  =============
 > >  Q: What does 'stray irq' mean?
 > >  A: Stray irq are interupts from some hardware that do not have
 > >  a driver assigned to it. J Wunsch writes in a response to a PR 
 > 
 > No, they are mostly from hardware that removes its interrupt request
 > in the middle of the interrupt request acknowledge cycle.  FreeBSD's
 > interrupt handling (toggling the PIC masks at a critical time)
 > probably amplifies this problem.  Assigning a driver can "fix" the
 > problem by breaking detection of it.  The correct fix is to detect
 > the stray interrupts caused by interrupt timing glitches and decide
 > what to do about them (whatever is done, it shouldn't involve
 > printing a faq magnet).
 
 Ok
 
 Should the print of this text be removed from kernel then?
 
 Is the following suggestion for the FAQ better or should we not
 have an FAQ entry at all for this (which I think we should since 
 the question pops up)?
 
 ============
 Q: What does 'stray irq' mean?
 A: Stray IRQs are indications of hardware IRQ glitches, mostly 
 from hardware that removes its interrupt request in the middle 
 of the interrupt request acknowledge cycle.
 J Wunsch writes in a response to a PR 
 "Stray IRQs are a known phenomenon.  Obviously (if you think about it :), 
 there's nothing the kernel could do about it. Unless you have
 misconfigured your kernel so there's no driver assigned to a device
 that actually issues IRQs, they are a sign of flakey hardware, often
 caused by glitches on an IRQ line."
        
 You have three choices:
  1) Live with the warnings 
  2) Get a driver for the hardware into your kernel
  3) Remove the hardware that generates the interrupts
 =============
 

From: Bruce Evans <bde@zeta.org.au>
To: Johan Karlsson <k@numeri.campus.luth.se>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/17774: stray irq7 
Date: Sun, 13 Aug 2000 22:52:53 +1000 (EST)

 On Sun, 13 Aug 2000, Johan Karlsson wrote:
 
 > At Sun, 13 Aug 2000 08:55:04 +1000, Bruce Evans wrote:
 > > On Fri, 11 Aug 2000, Johan Karlsson wrote:
 > > 
 > > >  I suggest the following is added to the faq
 > > 
 > > The fwa? :-).
 > 
 > ???
 
 Frequently Wrong Answers.
 
 > > problem by breaking detection of it.  The correct fix is to detect
 > > the stray interrupts caused by interrupt timing glitches and decide
 > > what to do about them (whatever is done, it shouldn't involve
 > > printing a faq magnet).
 > 
 > Ok
 > 
 > Should the print of this text be removed from kernel then?
 
 Either that or turned into a KASSERT panic or something that annoys
 developers enough to fix the problem.  (The irq7 and irq15 handlers
 need extra code which is hard to fit into the macros used to generate
 the code.  This may be easier when the code is rewritten for SMPng.)
 
 > Is the following suggestion for the FAQ better or should we not
 > have an FAQ entry at all for this (which I think we should since 
 > the question pops up)?
 > 
 > ============
 > Q: What does 'stray irq' mean?
 > A: Stray IRQs are indications of hardware IRQ glitches, mostly 
 > from hardware that removes its interrupt request in the middle 
 > of the interrupt request acknowledge cycle.
 > J Wunsch writes in a response to a PR 
 > "Stray IRQs are a known phenomenon.  Obviously (if you think about it :), 
 > there's nothing the kernel could do about it. Unless you have
 > misconfigured your kernel so there's no driver assigned to a device
 > that actually issues IRQs, they are a sign of flakey hardware, often
 > caused by glitches on an IRQ line."
 >        
 > You have three choices:
 >  1) Live with the warnings 
 >  2) Get a driver for the hardware into your kernel
 >  3) Remove the hardware that generates the interrupts
 > =============
 
 This is very confusing, since it gives conflicting answers.
 
 The only reasonable choices are:
 
 1) Live with the warnings.  All except the first 5 per irq are suppressed
    anyway.
 2) Break the warnings by changing 5 to 0 in isa_strayintr() so that all the
    warnings are suppressed.
 3) Break the warnings by installing parallel port hardware that uses irq 7
    and the ppp driver for it (this happens on most systems), and install
    an ide drive or other hardware that uses irq 15 and a suitable driver for
    it.
 
 Stray irqs on irqs other than irq7 and irq15 cause very frequently asked
 questions since they "can't happen".
 
 Bruce
 
 

From: Johan Karlsson <k@numeri.campus.luth.se>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/17774: stray irq7 
Date: Mon, 14 Aug 2000 09:58:19 +0200

 At Sun, 13 Aug 2000 22:52:53 +1000, Bruce Evans wrote:
 > Frequently Wrong Answers.
 
 That is why I thought it was the correct answer :-)
 
 > > Should the print of this text be removed from kernel then?
 > =
 
 > Either that or turned into a KASSERT panic or something that annoys
 > developers enough to fix the problem.  (The irq7 and irq15 handlers
 > need extra code which is hard to fit into the macros used to generate
 > the code.  This may be easier when the code is rewritten for SMPng.)
 
 If you think this should be done please go ahead and change it.
 
 In the mean time I think a FAQ entry should exists.
 
 -doc people, please check grammar and such since I'm not nativ :-)
 I have tried to merge Bruce's answer and any error is =
 
 probably mine.
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Q: What does 'stray irq' mean?
 A: Stray IRQs are indications of hardware IRQ glitches, mostly =
 
    from hardware that removes its interrupt request in the middle =
 
    of the interrupt request acknowledge cycle.
    One has three alternatives how to deal with this:
 	1) Live with the warnings.  All except the first 5 per irq =
 
 	   are suppressed anyway.
 	2) Break the warnings by changing 5 to 0 in isa_strayintr() =
 
 	   so that all the warnings are suppressed.
 	3) Break the warnings by installing parallel port hardware =
 
 	   that uses irq 7 and the ppp driver for it (this happens =
 
 	   on most systems), and install an ide drive or other =
 
 	   hardware that uses irq 15 and a suitable driver for it.
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 
 Thanks
 Johan K
 
State-Changed-From-To: open->closed 
State-Changed-By: murray 
State-Changed-When: Sun Sep 16 21:28:42 PDT 2001 
State-Changed-Why:  
An entry has been added to the FAQ.  This may take up to 24 hours to 
reach the website.  Thanks for your submission!  Sorry this took so long ;) 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17774 
>Unformatted:
 Stephen Montgomery-Smith
