Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!news.dell.com!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail From: burgess@hrd769.brooks.af.mil (Dave Burgess) Newsgroups: comp.os.386bsd.misc Subject: Re: Three ESDI drives possible? Date: 26 Aug 1993 09:51:26 -0500 Organization: Armstrong Laboratory, Brooks AFB, TX Lines: 52 Message-ID: <25iils$9g1@hrd769.brooks.af.mil> References: <1993Aug20.023013.19454@sserve.cc.adfa.oz.au> <1993Aug20.155651.18766@leland.Stanford.EDU> <2574j5$65u@olivaw.apanix.apana.org.au> <25eo46INNrbi@kralizec.zeta.org.au> NNTP-Posting-Host: hrd769.brooks.af.mil In article <25eo46INNrbi@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes: } }The "extra interrupts" are caused by the driver sending some }initialization commands to the controller for and then waiting for the }controller to finish, all with wd interrupts disabled. The controller }turns off its interrupt line when a the driver tests the controller }status after a command finishes, so the driver expects not to get any }interrupts. However, bde's rewrite of the interrupt handling for the }0.2.4 patchkit results in stale interrupts being delivered. These are }usually harmless. They are always harmless when the controller }complains about them :-). But sometimes a stale interrupt acts as an }early completion for the next command. This shouldn't be a problem - Do you mean like the problem that several wd user are reporting; wherein during periods of intense disk activity, the drive and controller and system somehow get out of sync and the system locks up? This could explain how this is happening to many folks. I have noticed that I often have 6150 uSec timeouts... Since this exceeds the threshold for reporting, I get the report. This whole discussion has suddenly tied all of these factors together and helped me understand a little better where MY particular problem with the wd controller code may be. If I increase the time-out period, does anyone think that the occurences of the problem will get reduced? BTW, I am running netBSD-0.9, and can rebuild a kernel at will (of course, Will likes me to ask first... :-) }the driver just has to wait a little longer until the controller is }really ready. More seriously, the driver is sloppy about waiting for }commands to finish, so the "extra" interrupt is one that it didn't }wait for. The extra interrupt is no problem unless the command failed. } Which may well be a cause of the problem that I have noticed. In fact, the default time-out may be too short for my particular example. I will try increasing the time-out period until I no longer get 'extra interrupt' errors on boot-up and see if it helps. }My fixes for this and many other bugs in the wd driver are not finished }yet. } -- ------ TSgt Dave Burgess NCOIC AL/Management Information Systems Office Brooks AFB, TX