Date: Mon, 17 Sep 2001 11:30:05 -0700 (PDT) From: Jeremy Chadwick <jdc@best.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/30559: Intense SCSI tape access results in controller errors Message-ID: <200109171830.f8HIU5T17404@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/30559; it has been noted by GNATS.
From: Jeremy Chadwick <jdc@best.net>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109171830.f8HIU5T17404>