From owner-freebsd-stable Sun Nov 28 14: 3:52 1999 Delivered-To: freebsd-stable@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 39B2C15381 for ; Sun, 28 Nov 1999 14:03:43 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA22418; Sun, 28 Nov 1999 15:02:24 -0700 (MST) (envelope-from ken) Message-Id: <199911282202.PAA22418@panzer.kdm.org> Subject: Re: ahc problems (with vinum?) In-Reply-To: <14401.38935.33670.167936@trooper.velocet.net> from David Gilbert at "Nov 28, 1999 04:01:11 pm" To: dgilbert@velocet.ca (David Gilbert) Date: Sun, 28 Nov 1999 15:02:23 -0700 (MST) Cc: jgreco@ns.sol.net (Joe Greco), stable@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote... > >>>>> "Joe" == Joe Greco writes: > > >> > Copyright (c) 1992-1999 FreeBSD Inc. > Copyright (c) 1982, 1986, > >> 1989, 1991, 1993 > The Regents of the University of California. All > >> rights reserved. > FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST > >> 1999 > root@host:/usr/src/sys/compile/DEMO > >> > >> The first problem is that you're running 3.3-R with two 7890s. > >> Justin worked around a bug in the 7890 in the Adaptec driver > >> shortly after 3.3 came out. I'd recommend at the very least > >> updating your Adaptec driver, although depending on your > >> circumstances, it might be easier to just update to the latest > >> -stable. > > Joe> Noted. One is an onboard controller, part of the ASUS P2B-DS. > Joe> This particular system was supposed to have a 3940, but I didn't > Joe> have one so I crammed in two 2940-type controllers. Would this > Joe> also be an issue for a system with the onboard controller and a > Joe> 3940-type controller? > > In my case... this happens with single or multiple controlers and I'm > not using the 3940's. I am already running 3.3-STABLE (as of > Thursday, I believe) because vinum improved quite a bit after > 3.3-RELEASE. So you shouldn't have a problem with the 7890 bug, since you have the newer driver. Joe's problem is actually with a bus on a non-Ultra2 2940. > Joe> I thought a bus reset was supposed to deal with bus phase > Joe> issues...? But I'm admittedly an armchair SCSI quarterback. I > Joe> used to see Suns that had a heterogeneous SCSI array of mildly > Joe> incompatible SCSI devices routinely go through the > Joe> jam-reset-restart sequence. > > One strange datapoint to add. I was looking at the system in > preparation for putting another SCSI controller into it so I could get > back the errors... and I removed the external terminator from the LVD > chain to read it's label. Immediately, the screen started scrolling > again with ahc messages --- This leads me to believe that everything > is stuck waiting for the card to un-wedge. Now... I'd already hit > CTRL-ALT-DEL to see if I could unwedge things... so the system didn't > come back at that point, but I thought it was interesting. I believe LVD busses need to be properly terminated with an LVD terminator in order to function. So yanking the terminator is a bad idea. :) > The following is my carefully typed sequence of messages from the > console: (does not include messages after the terminator was > removed). > > (da5:ahc0:0:9;0): SCB 0xd5 - time out in dataout phase, SEQADDR == 0x5e > (da5:ahc0:0:9;0): BDR message in message buffer > (da5:ahc0:0:9;0): SCB 0xd5 - time out in dataout phase, SEQADDR == 0x5d > (da5:ahc0:0:9;0): no longer in timeout, status 34b > ahc0: Issued Channel A Bus Reset. 4 SCBs aborted That generally means you have a cabling or termination problem. It could be a bent pin somewhere even. Justin has had trouble with pins on his LVD cables getting bent and causing weird problems. So if you've got a spare cable setup, it might be a good idea to just swap the cables out and see if the problem goes away. Before you put in the new cable set, make sure you check for any bent pins. Specifically, the error above means that the bus probably got stuck for 60 seconds while the controller was trying to write data out to the drive. So it is the fact that your bus is getting stuck in dataout phase that leads me to believe that you've got a cabling or termination problem. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message