From owner-freebsd-current Fri Aug 8 10:44:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA01347 for current-outgoing; Fri, 8 Aug 1997 10:44:56 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA01342 for ; Fri, 8 Aug 1997 10:44:53 -0700 (PDT) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.8.6/8.8.5) id KAA03954; Fri, 8 Aug 1997 10:47:05 GMT From: Steve Kargl Message-Id: <199708081047.KAA03954@troutmask.apl.washington.edu> Subject: Re: scsi time-out & lockup under smp In-Reply-To: <199708081720.LAA06615@pluto.plutotech.com> from "Justin T. Gibbs" at "Aug 8, 97 05:20:12 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Fri, 8 Aug 1997 10:47:05 +0000 (GMT) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Justin T. Gibbs: > >It occurs on uni-processor system, too. If I use dump(1) to backup > >my system, I eventually get the following: > > > >st0(ahc0:2:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > >SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa > > Do you know if this occurs during the rewind or during some other operation > during the backup. These types of problems, at least when a tape drive is > the culprit, are almost always caused by one of the timeouts in the driver > being too short. For instance, you may have hit a bad tape block and the > timeout for reading a tape block is simply too short to deal with the > drives attempts to retry the read. > It occurs during a write to the tape drive. It will also occur when I use restore(1). I should note that if I use tar, then the problem does not occur. The driver did report a MEDIUM ERROR with at least 1 tape. I tried 3 different tapes. Note 1: I have options DDB in my kernel, but the machine does not panic. It just hangs, and a hard reset is necessary. Note 2: In a older version of your driver, use of TAG queuing and SCB were kernel option. If I did not enable TAG and SCB, dump and restore worked. Is there some kernel option that can be set to disable TAG queuing and SCB for a specific device? -- Steve finger kargl@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~kargl/sgk.html