From owner-freebsd-scsi@FreeBSD.ORG Sun Jul 27 20:50:38 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3181B37B401; Sun, 27 Jul 2003 20:50:38 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EC4D43FB1; Sun, 27 Jul 2003 20:50:37 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <305LG6LD>; Sun, 27 Jul 2003 23:50:36 -0400 Message-ID: From: Don Bowman To: "'Justin T. Gibbs'" , Don Bowman , "'freebsd-scsi@freebsd.org'" , aic7xxx@freebsd.org Date: Sun, 27 Jul 2003 23:50:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AIC7902 w/ seagate U320 drive issue on releng-4 (and current) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2003 03:50:38 -0000 > From: Justin T. Gibbs [mailto:gibbs@scsiguy.com] > > > FYI, i've solved this problem for me by moving to > > firmware version 5 on the ST318453LW (U320 15KRPM 18GB) > > seagate drive. > > This is exactly what I was going to suggest. 0004 is known > bad in packetized operation. Your test to drop the speed to > 160MB/s was a good thought, but for the 790X controllers, we > will still attempt to run with packetized protocol, assuming > the device supports it, even when you reduce the negotiated > rate. You can disable packetized protocol in SCSI-Select which > would probably have allowed you to limp along until you got > updated firmware. > > Sadly, 0005 is not perfect. I have seen situations where under > hight tag load 0005 still drops trasactions. I believe that > Seagate has a fix for this, but it has yet to be put into > release level firmware. You might want to touch base with > them in another month to see if they have released a follow > on to 0005. I wonder if the driver could back-off or do some test first. I thought i was good when i upgraded all these systems from 3 to 4, and am now faced with the unpleasant prospect of upgrading many systems that are @ remote customer sites. interestingly, 004 was fine until a recent driver rev (or at least, the problem did not manifest). Why would the behaviour be such that the drive disappears from the SCSI chain and not even a system reset fixes it? I'm very surprised that resetting the motherboard doesn't reset the drive, only a powercycle does in this case. Why would the 160 version of the same drive not have the same bug? I guess that's a question for seagate :) So after updating 15 test systems and running 'dd' for some hours, 1 of them showed the same card-state dump 1 time. Should i just drop the number of tags down to 32 or 64 on spec, or is there another cause likely? --don