"Søren Schmidt" wrote:
> > For a more "scientific test", downloading the firmware tool and
> > setting the DMA transfer rate down, and checking for problems,
> > would be pretty overwhelming evidence.  Personally, I don't have
> > any of the buggers lying around to test with any more.
> Why on earth would you do that ? (hint man atacontrol)
> Besides I dont see this as any evidence at all, but thats another matter...

If it fixes the problem, then the problem is most likely related
to what firmware setting the tool changes.


From my reading of the FreeBSD man pages, it can't blow the flash
byte that controls the DMA speed, like the IBM provided utility

Obviously, turning off tagged commands works, according to at least
one person who is reporting the problem.

I wonder if limiting outstanding tagged commands to less than the
number advertised by the drive would also work... can't be worse
than the initialization reordering patch that failed (e.g the
worst case is it still has the problems).  A lot safer than banging
bits in the firmware, I'm sure, though...

Limiting the outstanding tagged commands to less than the advertised
amount would actually be my first choice of a hack for a software

Can you do that with "sysctl hw.ata.tags=XXX"?  Or is that just a 1/0
thing?  A scan doesn't indicate documentation, but I'm probably just
not looking very hard...

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to