From owner-freebsd-hackers Fri Mar 12 23: 5:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 6059314DB0 for ; Fri, 12 Mar 1999 23:05:36 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id AAA01003; Sat, 13 Mar 1999 00:05:10 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903130705.AAA01003@panzer.plutotech.com> Subject: Re: Its BAAAAACK! :-) In-Reply-To: <19990312224455.D1582@Denninger.Net> from Karl Denninger at "Mar 12, 1999 10:44:55 pm" To: karl@Denninger.Net (Karl Denninger) Date: Sat, 13 Mar 1999 00:05:10 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Karl Denninger wrote... > > Hi folks, > > I thought this one was gone... but I guess not! You might get a better response by posting SCSI problems to the -scsi list, and by using a reasonable subject line. I only happened to look at this message by accident... > >From /var/log/messages: > > Mar 12 13:05:27 Genesis /kernel: (da0:ahc0:0:0:0): SCB 0xb - timed out while idl > e, LASTPHASE == 0x1, SEQADDR == 0xb > Mar 12 13:05:27 Genesis /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB > Mar 12 13:05:27 Genesis /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent > Mar 12 13:05:27 Genesis /kernel: (da0:ahc0:0:0:0): no longer in timeout, status > = 353 > Mar 12 13:05:27 Genesis /kernel: Unexpected busfree. LASTPHASE == 0xa0 > Mar 12 13:05:27 Genesis /kernel: SEQADDR == 0x154 > Mar 12 13:06:27 Genesis /kernel: (da0:ahc0:0:0:0): SCB 0x2 - timed out while idl > e, LASTPHASE == 0x1, SEQADDR == 0xc > Mar 12 13:06:27 Genesis /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB > Mar 12 13:06:27 Genesis /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent [ ... ] > And a bunch more. > > FreeBSD 4.0-CURRENT (KARL) #2: Fri Mar 12 11:38:33 CST 1999 > > That's the build date; it was updated last night via CVS (so the kernel is > current as of March 11th in the evening). Updating your source probably won't help a whole lot. I'm surprised you haven't seen this a whole lot more. My guess is that you just haven't been banging on the disk in question a whole lot. > Mar 12 11:44:30 Genesis /kernel: da1 at ahc0 bus 0 target 8 lun 0 > Mar 12 11:44:30 Genesis /kernel: da1: Fixed Direct Access SCSI-2 device > Mar 12 11:44:30 Genesis /kernel: da1: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled > Mar 12 11:44:30 Genesis /kernel: da1: 8682MB (17781520 512 byte sectors: 255H 63S/T 1106C) > Mar 12 11:44:30 Genesis /kernel: da0 at ahc0 bus 0 target 0 lun 0 > Mar 12 11:44:30 Genesis /kernel: da0: Fixed Direct Access SCSI-2 device > Mar 12 11:44:30 Genesis /kernel: da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled > Mar 12 11:44:30 Genesis /kernel: da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) The 'timed out while idle' messages are generally evidence of a disk problem. It means that a command timeout expired, and there was nothing going on when the timeout expired. The timeout for read/write commands from the da driver is 60 seconds. That means that the cause of the above error messages is most likely that your drive has gone "out to lunch". When a drive goes "dead" like that, we hit it with a BDR (Bus Device Reset) to wake it up. This will make more sense when you look at the model number for the Compaq drive in question. It looks very suspiciously like a rebadged Quantum Atlas I. (The 4 gig Atlas I's model number was XP34300) My guess is that you should look for updated firmware for the disk. IIRC, there was a problem with the Atlas I that got fixed with a firmware upgrade. I don't remember what the problem was, but I suspect it was a 'goes out to lunch' type problem. I'm surprised you haven't had trouble with your other disk as well. The LXY4 firmware of the Atlas II is known to have the 'goes out to lunch' problem as well. If you upgrade to the LYK8 firmware for your Atlas II, you at least won't have the drive hanging up on you. That firmware still has the famous Quantum queue full bug, but we work around it in CAM fairly well. (I've got 4 Atlas II's, with LYK8 firmware, and they're working fine.) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message