Date: Sun, 14 Jan 1996 22:34:22 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> Cc: Sean Reifschneider <jafo@tummy.com>, freebsd-scsi@freebsd.org Subject: Re: FreeBSD NCR driver timeout? Message-ID: <199601142134.AA17404@Sysiphos> In-Reply-To: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> "Re: FreeBSD NCR driver timeout?" (Jan 14, 13:07)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 14, 13:07, "Justin T. Gibbs" wrote: } Subject: Re: FreeBSD NCR driver timeout? } >Well, sorry, those 1.6 seconds are already } >the maximum supported by the NCR hardware ... } } You could easily count the number of handshake timeouts in the driver and } make the interval a multiple of what the NCR supports. I don't see the } value of a handshake timeout anyway since the SCSI spec doesn't place any } lower bounds on communication speed, and you should be using the timeout } value that was passed down to you in the scsi_xfer struct as an overall } timeout value. Well, most devices will not require 1.6s for a single bus transaction (locking out all other devices ...). I know about the command timeout, and I'm really not sure, whether the 1.6s timeout should be there too. But then, I'm seeng SCSI as a shared access bus, and I do expect a device to disconnect, if it won't have any data to send for more than a few milliseconds. The handshake timeout helps diagnose error situations, since I know, at which NCR instruction the lockup occured. I'm not sure whether it is possible to break a lock without loosing that information, if only a command timeout is used. I'll have to look into this. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601142134.AA17404>