From owner-freebsd-scsi Thu Dec 3 12:30:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17672 for freebsd-scsi-outgoing; Thu, 3 Dec 1998 12:30:25 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA17667 for ; Thu, 3 Dec 1998 12:30:23 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id NAA03868; Thu, 3 Dec 1998 13:29:17 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199812032029.NAA03868@panzer.plutotech.com> Subject: Re: IBM DCHS woes In-Reply-To: <199812031409.IAA01462@bonkers.taronga.com> from Peter da Silva at "Dec 3, 98 08:09:58 am" To: nick@Taronga.COM Date: Thu, 3 Dec 1998 13:29:17 -0700 (MST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter da Silva wrote... > (forwarded from a bounce message for a local user) > > From: nick@Taronga.COM (Nick Danger) > Subject: IBM DCHS woes > Reply-To: nick@Taronga.COM > > > I've got this oemed IBM DCHS 34550 that is being naughty. It refuses > to operate reliably at synchronous transfers rates and does this > regardless of what HBA or OS I'm running it off of. If I instruct > the HBA to not negiotate for synchronous transfers it runs flawlessly > (albeit inefficiently). I'm under the impression it's a firmware > problem. That's probably a good guess. You may want to contact IBM and see if they have any newer firmware for the drive in question. If it won't work with any HBA or OS you've tried, I'm not surprised at all that it doesn't work with FreeBSD. > I'm only concerned with it being functional on a FreeBSD-current > machine (-current as of late last week). These logs are from earlier > but the error is the same. > > > Drive is reported as: > > Nov 19 21:00:56 engylion /kernel: da1 at ahc0 bus 0 target 2 lun 0 > Nov 19 21:00:56 engylion /kernel: da1: Fixed Direct Acce Hmm. An SGI version of the drive. It could be they've got some sort of funky firmware in the drive. > Errors begin about five minutes later as I start doing a bunch of simultaneous > copies to it: > > > /kernel: (da1:ahc0:0:2:0): SCB 0x5 - timed out while id > le, LASTPHASE == 0x1, SCSISIGI == 0x0 > /kernel: SEQADDR == 0x8 > /kernel: SSTAT1 == 0xa > /kernel: (da1:ahc0:0:2:0): Queuing a BDR SCB > /kernel: (da1:ahc0:0:2:0): Bus Device Reset Message Sent > /kernel: (da1:ahc0:0:2:0): no longer in timeout, status = 34b > /kernel: ahc0: Bus Device Reset on A:2. 16 SCBs aborted > /kernel: (da1:ahc0:0:2:0): SCB 0xc - timed out while id le, LASTPHASE > == 0x1, SCSISIGI == 0x0 > /kernel: SSTAT1 == 0xa > /kernel: (da1:ahc0:0:2:0): Queuing a BDR SCB > /kernel: (da1:ahc0:0:2:0): Bus Device Reset Message Sent > /kernel: (da1:ahc0:0:2:0): no longer in timeout, status = 34b > /kernel: ahc0: Bus Device Reset on A:2. 15 SCBs aborted What this means is that the drive went "out to lunch", and we had to whap it over the head with a BDR to get it to wake up. > /kernel: (da1:ahc0:0:2:0): SCB 0x6 - timed out while idle, LASTPHASE == 0x1, SCS > ISIGI == 0x0 > /kernel: SEQADDR == 0xb > /kernel: SSTAT1 == 0xa > /kernel: (da1:ahc0:0:2:0): Queuing a BDR SCB > /kernel: (da1:ahc0:0:2:0): Bus Device Reset Message Sent > /kernel: (da1:ahc0:0:2:0): no longer in timeout, status = 34b > /kernel: ahc0: Bus Device Reset on A:2. 14 SCBs aborted > /kernel: (da1:ahc0:0:2:0): READ(06). CDB: 8 d ca f0 80 0 > /kernel: (da1:ahc0:0:2:0): ABORTED COMMAND asc:1b,0 > /kernel: (da1:ahc0:0:2:0): Synchronous data transfer error > /kernel: (da1:ahc0:0:2:0): READ(06). CDB: 8 d ca f0 60 0 > /kernel: (da1:ahc0:0:2:0): ABORTED COMMAND asc:1b,0 > /kernel: (da1:ahc0:0:2:0): Synchronous data transfer error Hmm. The drive is reporting transfer errors. > Would someone more SCSI-clueful than I mind telling me if this is > something I can try to work around with a quirk entry or if I should > just write it off? I don't think you're going to work around it with a quirk entry. It could be that the drive is messed up and is negotiating at a faster rate than it can actually handle. The "Synchronous data transfer error" above, and the fact that it works fine in async mode indicate that it may be a negotiation problem. Go into the Adaptec bios and try setting the transfer rate to something low (like 5MHz). If the drive works at that speed, gradually increase the speed until it breaks. You may be able to find a synchronous speed lower than 20MHz that it will work at. You'll probably still want to ask IBM about new firmware, though. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message