Date: Sun, 27 Jul 2003 23:50:36 -0400 From: Don Bowman <don@sandvine.com> To: "'Justin T. Gibbs'" <gibbs@scsiguy.com>, Don Bowman <don@sandvine.com>, "'freebsd-scsi@freebsd.org'" <freebsd-scsi@freebsd.org>, aic7xxx@freebsd.org Subject: RE: AIC7902 w/ seagate U320 drive issue on releng-4 (and current) Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533702742000@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C8533702742000>