[snip]Randy Kelsoe wrote:
[cut]
so, it looks like the big difference is the drive itself. Yours is a Seagate, and mine is a Western Digital.
looks like it is...
I'll probably see what that ata1(0): applying Seagate errata fix line does, and try to disable it. Or try to run in UDMA/133
I'm just reporting the solution for the Seagate SATA disk on a Sil3112 controller performance problems that I have had on kernels 2.6.7+
I looked into the LKML archives and found out that there has been an issue with older Seagate SATA drives and the Sil3112. Apparently the Sil3112 issues some exotic but legal commands that the drive cannot handle. Thus, there is a slow workaround in sata_sil.c, blacklisting certain Seagate drives to keep everyone safe. Now, from what I remember reading somewhere, getting the exact list of drives affected from Seagate would require signing an NDA, which noone wanted to do. Thus, it is possible, that some drive is blacklisted, whereas it need not be.
I've had no problems using the drive before the workaround, and I don't care all that much if I lose all the data on my hard drive, so I removed the drive from the blacklist in /usr/src/linux/drivers/scsi/sata_sil.c
Then I rebuild the module, made an initrd with it, fixed my grub.conf to use the new initrd, rebooted, and I got my good old performance back (4 times faster than with the workaround on).
My drive model is ST3160023AS. So far it's been running OK. If it goes FUBAR, I'll post a follow-up to this message.
HOWEVER, if you decide to be irresponsible (like me), and do what I did, and your data goes the way of the dodo, don't blame me. This "fix" is not a real fix at all for the moment, meaning that it is absolutely possible that it causes the complete destruction of your data. For all I know, it might be possible that it would physically damage your drive as well. So don't try it if you cannot live with the consequences!
Greets,
//Andro
-- Andrey Andreev University of Helsinki Dept. of Computer Science
