"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. 8-). 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 does. 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 workaround. 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
