Bug 17774
| Summary: | stray irq7 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Stephen Montgomery-Smith <stephen> |
| Component: | kern | Assignee: | freebsd-doc (Nobody) <doc> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
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 Let the -doc folks have a look the suggested FAQ entry. 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 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 ============= 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 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 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 ;) |
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.