From owner-freebsd-scsi Mon Jan 15 07:48:53 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA19341 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 07:48:53 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA19322 for ; Mon, 15 Jan 1996 07:48:41 -0800 (PST) Received: by Sysiphos id AA08578 (5.67b/IDA-1.5 for scsi@freebsd.org); Mon, 15 Jan 1996 16:47:09 +0100 Message-Id: <199601151547.AA08578@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 15 Jan 1996 16:47:08 +0100 In-Reply-To: "Justin T. Gibbs" "Re: FreeBSD NCR driver timeout?" (Jan 15, 6:09) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Justin T. Gibbs" Subject: Re: FreeBSD NCR driver timeout? Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 15, 6:09, "Justin T. Gibbs" wrote: } Subject: Re: FreeBSD NCR driver timeout? } >On Jan 14, 19:18, Peter Dufault wrote: } >} Unfortunately, Stefan, I think that if possible we ought to provide } >} the same host adapter behavior across all adapters and use the } >} timeout passed in (if we can), even if it is for an ungodly amount } >} of time. } >} } >} Keep in mind that someone might elect to dedicate an NCR controller } >} to talking to an anti-social scanner and will be disappointed if } >} they can't make it work with a timeout of, say, 10 seconds. After } >} all, those NCR controllers are among the cheapest we support and } >} therefore a good choice for a second dedicated bus. } > } >Well, guess I've got no choice :) } } Well you do have a choice. I think our shortest timeout is 10s right now } so this should work. I would suggest aborting the command if you see } enought HTH timeouts to be roughly equivilent to the timeout value in the } xfer or if your timeout handler is called. This would give you all the } information you have now, but a longer (tunable) timeout. I'm not sure whether the command that failed can be restarted ... A timeout is generally considered a fault, and I probably have to disable it, and to make a software timer issue a NCR halt in such a way, that the chips state is conserved for analysis by the error handler. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se