Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!homer.alpha.net!news.jersey.net!ns2.mainstreet.net!bug.rahul.net!a2i!rahul.net!a2i!dandelion.com!not-for-mail From: "Leonard N. Zubkoff" <lnz@dandelion.com> Newsgroups: comp.unix.bsd.freebsd.misc,comp.periphs.scsi Subject: Re: SCSI-2 Bus Hangs Date: 27 Dec 1995 18:07:47 -0800 Organization: Dandelion Digital Lines: 48 Sender: lnz@dandelion.com Message-ID: <4bsu5j$eca@kelewan.dandelion.com> References: <4bju5p$ihj@wilma.widomaker.com> <4bp3bp$7cc@scratchy.mosquito.com> <1995Dec26.123518.1@spcvxb.spc.edu> <4brb07$b4q@uriah.heep.sax.de> NNTP-Posting-Host: dandelion.com NNTP-Posting-User: root In-reply-to: j@uriah.heep.sax.de's message of 27 Dec 1995 11:34:31 GMT Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:11592 comp.periphs.scsi:43958 In article <4brb07$b4q@uriah.heep.sax.de> j@uriah.heep.sax.de (J Wunsch) writes: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes: > Also, the driver should time out a SCSI command that's taking too long > and start recovery, first by retrying the command, then by doing a device > reset to the target, and then doing a complete SCSI bus reset as a last > resort. This is harder than it looks, though - for example, rewinding a > tape should have a much longer timeout than a disk read. The only driver > I know of that does this is the new BusLogic driver for Linux (from ftp. > dandelion.com if I recall correctly). FreeBSD drivers do this already since day 1. However, as you mention, there are some problems that aren't easy to solve. By now, the drivers could be ``tuned'' to assume a particular timeout for a specific command, so for example you could bump the timeout to format a hard disk to two hours (some disks do really take more than one hour for it). I still don't know what's the best method (or where to get reasonable figures for acceptable timeouts). A device or bus reset to a device that's operating normally is about as harmful as a jamming device. Would you kindly point me to the code where the Bus Device Reset or SCSI Bus Reset is initiated in FreeBSD? I've perused some of the SCSI code in FreeBSD-current and especially the BusLogic driver, but I've not been able to figure out where this happens. I must be missing something about how this code is structured. As far as I could tell, the drivers implement Bus Device Reset, but the higher level code never uses it; I couldn't find any code to do a full SCSI Bus Reset or to hard reset the host adapter if necessary. As for Linux, the higher level parts of the SCSI subsystem have had similar code for a long while also. Unfortunately, many/most/some of the low level SCSI drivers have either not implemented the code at all, or it has not worked properly. The higher level code also had some places that needed improvement. Actually, a Bus Device Reset or SCSI Bus Reset is recoverable for most kinds of devices if the higher level parts of the SCSI system retry commands appropriately, with tapes being the notable exception. One of my favorite torture tests is to run an MD5 checksum program across an entire file system and save the fingerprints, then do it again while causing all manner of SCSI bus lossage, and verify that despite reinitializing the host adapter numerous times, Bus Device Resets, and full SCSI Bus Resets, the second set of fingerprints match the first precisely. Leonard