From owner-aic7xxx@FreeBSD.ORG Sun Jul 27 21:05:42 2003 Return-Path: Delivered-To: aic7xxx@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 400D437B401; Sun, 27 Jul 2003 21:05:40 -0700 (PDT) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F66843F75; Sun, 27 Jul 2003 21:05:39 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h6S45cEU022444; Sun, 27 Jul 2003 22:05:38 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Sun, 27 Jul 2003 22:05:38 -0600 From: "Justin T. Gibbs" To: Don Bowman , "'freebsd-scsi@freebsd.org'" , aic7xxx@freebsd.org Message-ID: <2870085408.1059365138@aslan.scsiguy.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: AIC7902 w/ seagate U320 drive issue on releng-4 (and current) X-BeenThere: aic7xxx@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Adaptec Device Drivers in FreeBSD and Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2003 04:05:42 -0000 > I wonder if the driver could back-off or do some test first. This would be something for the CAM transport layer to do. Right now, it only throttles based on the drive reporting queue full status. It would be possible to also have the transport layer track errors and throttle based on that, but classifying errors that should result in a "speed throttle" versus a "tag throttle" would be tricky. > interestingly, 004 was fine until a recent driver rev (or at > least, the problem did not manifest). The driver has been getting faster due to some recent optimizations. Sorry. 8-) > Why would the behaviour be such that the drive disappears from > the SCSI chain and not even a system reset fixes it? Some versions of the firmware were shipped with a diagnostic feature enabled that causes the equivalent of an assert. This is great for firmware engineers since the drive stops dead at the location of the error. It's not so good for end users. > I'm very > surprised that resetting the motherboard doesn't reset the drive, > only a powercycle does in this case. Why is this surprising? What does reseting the motherboard do to the drive? A SCSI bus reset may occur, but that should occur during the drivers error recover anyway. Out to lunch drives typically only come back with a power cycle. > Why would the 160 version of the same drive not have the same > bug? I guess that's a question for seagate :) The 160 version does not support packetized protocol. This is a U320 feature. Seagate introduced some bugs in support this new protocol mode. > Should i just drop the number of tags down to 32 or 64 on spec, > or is there another cause likely? I have yet to see the failure running these drives at 32 tags. -- Justin