Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!avdms8.msfc.nasa.gov!sol.ctr.columbia.edu!news.kei.com!world!ksr!jfw From: jfw@ksr.com (John F. Woods) Newsgroups: comp.os.386bsd.questions Subject: Re: The reason for stray interrupts Message-ID: <34175@ksr.com> Date: 27 Oct 93 12:33:49 EDT References: <2ais9gINN2t8@xs4all.hacktic.nl> <wilko.751660652@spoetnix.idca.tds.philips.nl> Sender: news@ksr.com Lines: 29 wilko@idca.tds.philips.nl (Wilko Bulte) writes: >ptuomola@hacktic.nl (Petri Tuomola) writes: >>Many people have been asking why their machines display "ISA strayintr 7" >>messages. This is an extract from /sys/arch/i386/isa/isa.c: >> /* for some reason, we get bursts of intr #7, even if not enabled! */ >> /* >> * Well the reason you got bursts of intr #7 is because someone >> * raised an interrupt line and dropped it before the 8259 could >> * prioritize it. This is documented in the intel data book. This >> * means you have BAD hardware! I have changed this so that only >> * the first 5 get logged, then it quits logging them, and puts >> * out a special message. rgrimes 3/25/1993 >I've read this piece of comment once in the source, and I don't think it is >very sensible. One could argue that the 8259 is braindead (which is possibly >true ;-) but this problem also occurs on machines with chipsets which >integrate the intr controller and so have no actual 8259 chip. This is, however, the PC world, where correcting the hardware mistakes of the past is viewed with grave suspicion; those integrated controllers may well deliberately duplicate this misbehavior... ;-) >I have run *BSD on various systems, and I have still to find a system that >does not complain about stray interrupts. And these systems were *not* >bad hardware, they have run both AT&T and SCO Unix without any problems. >(No comments on the virtues/vices of Sys V systems please). I think I've seen it only once or twice on my NetBSD system, when the system was having distinct hardware problems. (It's a 486/33, so it ought to be fast enough to uncover speed-related problems.)