From owner-freebsd-scsi Mon Jan 15 15:46:25 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20592 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 15:46:25 -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 PAA20587 for ; Mon, 15 Jan 1996 15:46:20 -0800 (PST) Received: by Sysiphos id AA18145 (5.67b/IDA-1.5 for scsi@freebsd.org); Tue, 16 Jan 1996 00:46:03 +0100 Message-Id: <199601152346.AA18145@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 16 Jan 1996 00:46:02 +0100 In-Reply-To: Sean Reifschneider "NCR Handshake timeout" (Jan 15, 17:38) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Sean Reifschneider Subject: Re: NCR Handshake timeout Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 15, 17:38, Sean Reifschneider wrote: } Subject: NCR Handshake timeout } Wolfgang Stanglmeier suggested adding the following line to the kernel } config file: } } options "SCSI_NCR_NO_HTH_TIMEOUT" # Disable handshake timeout } } and applying the patch included below (I made this from the 2.1.0 } distribution ncr.c). This sets the handshake timeout to unlimited } insetad of 1.6 seconds. Each nibble is "2 ** n * 50us" with 0 } representing infinate timeout. Ok. I knew that 100us was the lowest value, and had expected '0' to disable the timeouts, but had not had time to verify this. I already commited a patch to FreeBSD-current, which unconditionally disables the handshake time out. There has always been a software timeout, and I'll see whether there are any reports of problems after this change ... } This did quite effectively remove the handshake timeout and allowed the } scanner to pound right along. Fine! } Apparently, just removing the HTH from the interrupt mask causes confusion. } The NCR chip generates an interrupt, and the driver just ignores it, so it } gets flaky. Yes. I did expect problems like this. The interrupt mask register may prevent that the interrupt pin get sactive, but the chip sees the handshake timeout situation anyway. That was the reason that I did not apply that change to -current ... 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