Hi,
I upgraded my 2.6.6 kernel to 2.6.8 (the fedora update). I run a SATA drive on a Sil 3112A controller. I quickly noticed that the SATA drive was no longer visible under /dev/hde, but under /dev/sda, fixed my fstab, etc.
However, as Sil 3112 has had very varied performance with different kernels, and there obviously was a change in the way it worked, I ran:
[andrei@brie andrei]$ sudo /sbin/hdparm -t -T /dev/sda /dev/sda: Timing buffer-cache reads: 1564 MB in 2.00 seconds = 780.95 MB/sec Timing buffered disk reads: 44 MB in 3.12 seconds = 14.11 MB/sec
Which is pretty awfuly slow, compared to 2.6.6 (over 50 MB/sec). Otherwise, I can spot no other errors or problems with it.
Any pointers as to what I should change? Is this a common result with that controller?
See the relevant dmesg part
8<--------------------------------------->8
SCSI subsystem initialized libata version 1.02 loaded. sata_sil version 0.54 ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 11 (level, low) -> IRQ 11 ata1: SATA max UDMA/100 cmd 0x2285D080 ctl 0x2285D08A bmdma 0x2285D000 irq 11 ata2: SATA max UDMA/100 cmd 0x2285D0C0 ctl 0x2285D0CA bmdma 0x2285D008 irq 11 ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f ata1: dev 0 ATA, max UDMA/133, 312581808 sectors: lba48 ata1(0): applying Seagate errata fix ata1: dev 0 configured for UDMA/100 scsi0 : sata_sil ata2: no device found (phy stat 00000000) scsi1 : sata_sil Vendor: ATA Model: ST3160023AS Rev: 3.18 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
8<--------------------------------------->8
TIA,
//Andro
Andrey Andreev wrote:
Hi,
I upgraded my 2.6.6 kernel to 2.6.8 (the fedora update). I run a SATA drive on a Sil 3112A controller. I quickly noticed that the SATA drive was no longer visible under /dev/hde, but under /dev/sda, fixed my fstab, etc.
However, as Sil 3112 has had very varied performance with different kernels, and there obviously was a change in the way it worked, I ran:
[andrei@brie andrei]$ sudo /sbin/hdparm -t -T /dev/sda /dev/sda: Timing buffer-cache reads: 1564 MB in 2.00 seconds = 780.95 MB/sec Timing buffered disk reads: 44 MB in 3.12 seconds = 14.11 MB/sec
I have not seen this slowdown:
[root@quicksilver home]# uname -r 2.6.8-1.521 [root@quicksilver home]# sbin/hdparm -t -T /dev/sda Timing buffer-cache reads: 1524 MB in 2.00 seconds = 761.73 MB/sec Timing buffered disk reads: 132 MB in 3.01 seconds = 43.85 MB/sec
Which is pretty awfuly slow, compared to 2.6.6 (over 50 MB/sec). Otherwise, I can spot no other errors or problems with it.
Any pointers as to what I should change? Is this a common result with that controller?
See the relevant dmesg part
8<--------------------------------------->8
SCSI subsystem initialized libata version 1.02 loaded. sata_sil version 0.54 ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 11 (level, low) -> IRQ 11 ata1: SATA max UDMA/100 cmd 0x2285D080 ctl 0x2285D08A bmdma 0x2285D000 irq 11 ata2: SATA max UDMA/100 cmd 0x2285D0C0 ctl 0x2285D0CA bmdma 0x2285D008 irq 11 ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f ata1: dev 0 ATA, max UDMA/133, 312581808 sectors: lba48 ata1(0): applying Seagate errata fix ata1: dev 0 configured for UDMA/100 scsi0 : sata_sil ata2: no device found (phy stat 00000000) scsi1 : sata_sil Vendor: ATA Model: ST3160023AS Rev: 3.18 Type: Direct-Access ANSI SCSI revision: 05
Mine looks like:
libata version 1.02 loaded. sata_sil version 0.54 ACPI: PCI interrupt 0000:01:0d.0[A] -> GSI 11 (level, low) -> IRQ 11 ata1: SATA max UDMA/100 cmd 0x4285D080 ctl 0x4285D08A bmdma 0x4285D000 irq 11 ata2: SATA max UDMA/100 cmd 0x4285D0C0 ctl 0x4285D0CA bmdma 0x4285D008 irq 11 ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003 88:203f ata1: dev 0 ATA, max UDMA/100, 234441648 sectors: lba48 ata1: dev 0 configured for UDMA/100 scsi0 : sata_sil ata2: no device found (phy stat 00000000) scsi1 : sata_sil Vendor: ATA Model: WDC WD1200JD-00G Rev: 02.0 Type: Direct-Access ANSI SCSI revision: 05
so, it looks like the big difference is the drive itself. Yours is a Seagate, and mine is a Western Digital.
Also, from the man pages of hdparm, for the -t and the -T options:
For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory.
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...
Also, from the man pages of hdparm, for the -t and the -T options:
For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (noother active processes) with at least a couple of megabytes of free memory.
I know, I know... It stays pretty much there... 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
Thanks!
//Andro
Andrey Andreev wrote:
I upgraded my 2.6.6 kernel to 2.6.8 (the fedora update). I run a SATA drive on a Sil 3112A controller. I quickly noticed that the SATA drive was no longer visible under /dev/hde, but under /dev/sda, fixed my fstab, etc.
However, as Sil 3112 has had very varied performance with different kernels, and there obviously was a change in the way it worked, I ran:
[andrei@brie andrei]$ sudo /sbin/hdparm -t -T /dev/sda /dev/sda: Timing buffer-cache reads: 1564 MB in 2.00 seconds = 780.95 MB/sec Timing buffered disk reads: 44 MB in 3.12 seconds = 14.11 MB/sec
Which is pretty awfuly slow, compared to 2.6.6 (over 50 MB/sec).
Slow enough for PIO: what does hdparm -d /dev/sda report?
James.
James Wilkinson wrote:
[andrei@brie andrei]$ sudo /sbin/hdparm -t -T /dev/sda /dev/sda: Timing buffer-cache reads: 1564 MB in 2.00 seconds = 780.95 MB/sec Timing buffered disk reads: 44 MB in 3.12 seconds = 14.11 MB/sec
Which is pretty awfuly slow, compared to 2.6.6 (over 50 MB/sec).
Slow enough for PIO: what does hdparm -d /dev/sda report?
/dev/sda: operation not supported on SCSI disks
I noticed that hdparm is not really very useful on SCSI disks. What'd be its equivalent for SCSI?
//Andro
On Mon, 2004-08-30 at 04:31, Andrey Andreev wrote:
James Wilkinson wrote:
[andrei@brie andrei]$ sudo /sbin/hdparm -t -T /dev/sda /dev/sda: Timing buffer-cache reads: 1564 MB in 2.00 seconds = 780.95 MB/sec Timing buffered disk reads: 44 MB in 3.12 seconds = 14.11 MB/sec
Which is pretty awfuly slow, compared to 2.6.6 (over 50 MB/sec).
Slow enough for PIO: what does hdparm -d /dev/sda report?
/dev/sda: operation not supported on SCSI disks
I noticed that hdparm is not really very useful on SCSI disks. What'd be its equivalent for SCSI?
//Andro
hdparm works for me on scsi. FC2 and fully updated.
I did the following: hdparm -d /dev/sda and got:
/dev/sda: operation not supported on SCSI disks
I noticed that hdparm is not really very useful on SCSI disks. What'd be its equivalent for SCSI?
//Andro
hdparm works for me on scsi. FC2 and fully updated.
Mine is fully updated too. Anyway:
[andrei@brie andrei]$ rpm -qi hdparm Name : hdparm Relocations: (not relocatable) Version : 5.5 Vendor: Red Hat, Inc. Release : 1 Build Date: Thu 19 Feb 2004 11:43:15 AM EET Install Date: Wed 19 May 2004 09:30:54 PM EEST Build Host: tweety.devel.redhat.com Group : Applications/System Source RPM: hdparm-5.5-1.src.rpm Size : 62903 License: BSD Signature : DSA/SHA1, Fri 07 May 2004 02:10:23 AM EEST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. http://bugzilla.redhat.com/bugzilla Summary : A utility for displaying and/or setting hard disk parameters. Description : Hdparm is a useful system utility for setting (E)IDE hard drive parameters. For example, hdparm can be used to tweak hard drive performance and to spin down hard drives for power conservation.
how about at your box? Probably it has to do a lot with the controller (sil 3112A) and the drive itself (seagate)
//Andro
Andrey Andreev wrote:
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...
[snip]
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 -
James Wilkinson -
Jeff Vian -
Randy Kelsoe