AIC7902 w/ seagate U320 drive issue on releng-4 (and current)
Don Bowman
don at sandvine.com
Sun Jul 27 20:50:38 PDT 2003
> From: Justin T. Gibbs [mailto:gibbs at 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
More information about the freebsd-scsi
mailing list