From owner-freebsd-bugs Mon Sep 17 11:30:12 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8A0F737B40E for ; Mon, 17 Sep 2001 11:30:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f8HIU5T17404; Mon, 17 Sep 2001 11:30:05 -0700 (PDT) (envelope-from gnats) Date: Mon, 17 Sep 2001 11:30:05 -0700 (PDT) Message-Id: <200109171830.f8HIU5T17404@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jeremy Chadwick Subject: Re: kern/30559: Intense SCSI tape access results in controller errors Reply-To: Jeremy Chadwick Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/30559; it has been noted by GNATS. From: Jeremy Chadwick To: "Justin T. Gibbs" Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/30559: Intense SCSI tape access results in controller errors Date: Mon, 17 Sep 2001 11:29:03 -0700 On Mon, Sep 17, 2001 at 11:16:07AM -0600, gibbs@scsiguy.com wrote: > >>Description: > > Under heavy SCSI tape access, our system spits out the following on the cons > >ole. Please note this applies to the ahc1 controller. > > This essentially tells us that the controller is waiting for the target to > REQ the last bits of data on this transfer. Either the target failed to see > an ACK from the initiator, or the initiator failed to see a REQ from the target. > > > Our SCSI bus is terminated properly. The drives are not LVD. Cables do > > not "run too close to the power supply." Cable length does not exceed > > specification. Cable quality is high -- replacing cables made no difference. > > Decreasing speed from 40MB/sec to 20MB/sec made no difference. Disabling SMP > > (via sysc tl MIB) made no difference. > > > > The only thing I haven't tried is removing the drive from the library/changer > > system itself, and throwing it right off the main SCSI cable. > > Nonetheless, this is an "environmental" problem. Perhaps your changer has > a bad power supply. Perhaps the changer design does not allow you to run > with anything other than a very short cable (well below the maximum length > allowed by the SCSI spec), etc. > > If you bootverbose, does the controller report the termination values > you expect? Thanks for getting back to me. In a "last attempt" to figure out the problem, we flipped our 1st and 3rd SDX-500C drives (in the library system). Oddly enough, the problem went away. This leads me to believe the problem relates to either a flakey SCSI port on one of the SDX-500C drives (the one reporting errors in my bug report), or possibly bad cabling within the library system itself. Since swapping the drive order, we've seen fantastic results in speed and stability from the drives. Hence my prognosis. This bug report can be closed. -- | Jeremy Chadwick jdc@best.net | | Best Internet/Verio Pacific ext 8251 | | UNIX Systems Administrator Mountain View, CA, USA | | Verio - "the new world of business" | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message