Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Oct 1998 13:44:35 -0600 (MDT)
From:      "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
To:        "Stephen D. Spencer" <scsi@artorius.sunflower.com>
Cc:        scsi@FreeBSD.ORG
Subject:   Re: CAM error report
Message-ID:  <199810121944.NAA07293@narnia.plutotech.com>
In-Reply-To: <Pine.BSF.4.01.9810121145310.3502-100000@artorius.sunflower.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.BSF.4.01.9810121145310.3502-100000@artorius.sunflower.com> you wrote:
> 
> The server didn't die.  There was a grand enough pause that caused
> some connections to drop, but it recovered quite nicely and continued
> plugging along.  Any comments or observations concerning these messages
> would be appreciated.

The timeout in CAM is now 60 seconds.  Timeouts in general are always
a tradeoff.  If we lower the timeout, it may catch situations that
are not really a problem.  The longer the timeout the longer the system
waits before attempting recovery.  You can reduce the timeout to something
smaller if it suits your needs through the DA_DEFAULT_TIMEOUT kernel
config option.

> QADDR == 0x10d
> SSTAT1 == 0x2
> (da1:ahc0:0:1:0): SCB 0x7e - timed out in datain phase, SCSISIGI == 0x44

This looks like a termination or cable issue.  The controller is waiting
for a Req from the drive or the drive is waiting for an Ack from the
controller, but one of these signals was lost on the wire.

--
Justin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810121944.NAA07293>