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!cs.utexas.edu!hermes.chpc.utexas.edu!xenon.brooks.af.mil!bsdns.brooks.af.mil!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail From: burgess@hrd769.brooks.af.mil (Dave Burgess) Newsgroups: comp.os.386bsd.questions Subject: Re: The Stray Interrupt Problem (7) under NetBSD ? Date: 1 Feb 1994 09:04:04 -0600 Organization: Armstrong Laboratory, Brooks AFB, TX Lines: 52 Message-ID: <2ilr1i$6fl@hrd769.brooks.af.mil> References: <1994Jan28.222149.12886@sifon.cc.mcgill.ca> <MYCROFT.94Jan30231828@duality.gnu.ai.mit.edu> NNTP-Posting-Host: hrd769.brooks.af.mil In article <MYCROFT.94Jan30231828@duality.gnu.ai.mit.edu>, Charles Hannum <mycroft@duality.gnu.ai.mit.edu> wrote: } }In article <1994Jan28.222149.12886@sifon.cc.mcgill.ca> }fox@cs.mcgill.ca (Colin BRADLEY) writes: } } I have just installed an UltraStor 34f on my NetBSD box - } [...] } Problem is, when I actually plug the SCSI drive (a Seagate } 3600N 525 meg affair) in, with the 50 pin cable, and boot } up the machine, it finds everything, the 34f, the Seagate, } and then finds 'ISA strayintr 7' and stops dead. } }This should be fixed in NetBSD-current. } for people of gender. Since the stray int-7 question comes up at least every day, I thought I would add a note to the FAQ about it. It seems to me that it is a complete red herring. It is, from everything I have ever seen here, a completely bogus warning and should be set by a define in the kernel source (IMHO). It this example, I would think that a much more likely culprit than random lpt interrupts would be that the cable in this case was bad/marginal. Another possibility is that the termination of the devices is not correct or some other similar SCSI problem. The stray interrupt 7 appears to be significant, but only in its sudden appearance. Now, as you all know by now, I may be completely off base here, but this is the impression that I have gotten over the past year or two. If someone would like to start a definitive discussion (or post a reasonable explanation) about why we need to know about the spurious signals when we AREN'T using the interrupt driven LPT driver and we don't need to know about them when we ARE, I would like to hear it. For the uninitiated, the only reason that you don't see the stray interrupt 7 warnings when you are using the lpt (versus lpa) driver is because the lpt driver eats them. We could add exactly the same code to the lpa driver and lose the warnings. This would eliminate a lot of these "My system is broke because of Stray Interrupts" messages. I have just read back over this message, and I realize that it sounds a little bit harsh. Unfortunately, it also expresses my opinion as well as I could. If anyone is offended, I apologize. That is not my intent. In fact, I don't even intend to beat up on the original poster. -- TSgt Dave Burgess NCOIC Applications Programming Branch US Strategic Command, Offutt AFB, NE burgessd@j64.stratcom.af.mil