From owner-freebsd-scsi Mon Jan 15 04:42:38 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA11240 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 04:42:38 -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 EAA11235 for ; Mon, 15 Jan 1996 04:42:31 -0800 (PST) Received: by Sysiphos id AA00997 (5.67b/IDA-1.5 for scsi@freebsd.org); Mon, 15 Jan 1996 13:41:09 +0100 Message-Id: <199601151241.AA00997@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 15 Jan 1996 13:41:09 +0100 In-Reply-To: Peter Dufault "Re: FreeBSD NCR driver timeout?" (Jan 14, 19:18) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Peter Dufault Subject: Re: FreeBSD NCR driver timeout? Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 14, 19:18, Peter Dufault wrote: } Subject: Re: FreeBSD NCR driver timeout? } > >Well, most devices will not require 1.6s for a single } > >bus transaction (locking out all other devices ...). } > } > I completely agree here... It *SHOUDN'T*, but it does. :-) } } This is what I mentioned the Microtek scanner does. It locks up } the SCSI bus while it positions the scan head. This is the problem } with these "PC" scanners that ship with their own SCSI controllers } - they can be completely anti-social about what they do on the bus. } } 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 :) I'm not sure whether masking HTH interrupts does not have bad effects, and I guess the command timeout handler has to be extended to give the same information as is currently available to the handshake timeout handler ... Ok. If there is a success report, I'll at least make disabling HTH a kernel config option. It is not required in the GENERIC kernel, since nobody will boot from a SCSI scanner anytime soon :) If this doesn't break anything else, it may become a standard feature, later ... 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