From owner-freebsd-scsi Tue Aug 19 20:23:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA23963 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 20:23:14 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA23958 for ; Tue, 19 Aug 1997 20:23:12 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id VAA08483; Tue, 19 Aug 1997 21:20:38 -0600 (MDT) Message-Id: <199708200320.VAA08483@pluto.plutotech.com> To: Greg Lehey cc: FreeBSD SCSI Mailing List Subject: Re: Bus resets. Grrrr. In-reply-to: Your message of "Wed, 20 Aug 1997 09:08:10 +0930." <19970820090810.54774@lemis.com> Date: Tue, 19 Aug 1997 21:19:59 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >On Tue, Aug 19, 1997 at 10:53:54AM -0600, Justin T. Gibbs wrote: >>>> What version of the kernel are you using >>> >>> Recent versions of -current. The ones I reported it against were some >>> time last week. I've just rebuilt with a version supped this morning. >> >> And it is still reproducible? > >I changed the configuration file and added (inter alia) >AHC_SCBPAGING_ENABLE. The resultant kernel hung solid three times in >the course of a couple of hours, once with a disk activity light on >solid, and the other two without. I removed AHC_SCBPAGING_ENABLE, and >last night the backup went through for the first time in a week. It >ran fine until last Wednesday, however, so this could be a >coincidence. The system hung solid with no kernel messages or were you in X so you couldn't see them? There is no guarantee that driver messages will make it into the log file if the SCSI bus is wedged. I wasn't aware of any problems with SCB paging, so I'd be very interrested in any information you can provide on this problem. In most cases, BTW, SCB paging isn't a win unless you are also using tagged queuing (option AHC_TAGENABLE). >No, at the moment the chain only has four devices connected, but I >notice it finds two LUNs for the tape changer: Ahh. I thought you said you had a 2940A, not a 2940. This pretty much rules out the QOUTFIFO overflow problem (assuming you are not using tagged queueing, which your dmesg output seems to confirm) since the aic7870 has 16 slots meaning 9 active devices would be necessary. >ahc0: rev 0x03 int a irq 12 on pci0.18.0 >ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs >ahc0: waiting for scsi devices to settle >scbus0 at ahc0 bus 0 >scbus0 target 0 lun 0: type 0 fixed SCSI 2 >sd0 at scbus0 target 0 lun 0 >sd0: Direct-Access 1001MB (2051615 512 byte sectors) >sd0: with 1760 cyls, 15 heads, and an average 77 sectors/track It looks like there is newer firmware available for this drive from Micropolis: ftp://techsupport.micropolis.com/pub/files/firmware/Aquaris/2105-2108-2112/4930010f.bin ftp://techsupport.micropolis.com/pub/files/Utils/ASPIUTIL.EXE >> Could it be that you don't have disconnections enabled for your tape drive? >> You should check both SCSI-Select for the 2940 and any relevant jumpers >> on the tape drive itself. If disconnections are disabled, a tape write that >> required multiple retries could easily tie up the SCSI bus for the 10s >> needed to make a disk command time out. > >You'd see that on the activity light, right? In any case, the host >adapter is set correctly, and the tape doesn't seem to have any such >config switch. Would there be another way to test that? Not really. Since the timeout was "while idle", chances are that disconnection is enabled and working. >> The first one probably fails because the device isn't ready. > >That's what I thought, too, so I put a sleep 30 into the script. It >still works the second time. Then it probably fails because there is a unit attention that needs to be cleared. The console error message would be enough to determine what is really happening. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================