This problem was discovered on an ASUS A7N8X-Deluxe Rev.2.00 motherboard with actual bios V1007 and two new ST3160023AS 160GB SATA drives connected to the onboard Silicon Image 3112A SATA controller. I tried several different 2.6 kernel versions with similiar configuration installed on an additional PATA drive to access the SATA drives, used siimage & libata + sata_sil, but everything I tried ended up with a transfer rate of only 15 MB/sec instead of the expected 55 MB/sec. The problem seems not be related to the siimage ot libata + sata_sil drivers, nor is it a hardware / IRQ / bios-setting or any other related problem. The only way of getting full 55 MB/sec transfer rate was booting from the 2004.1 livecd using smp kernel or booting from the LiveCD-Gentoo-Reiser4 RedeeLive. I have no explaination for that issue, but it is reproduceable and totally insane. Please have a look at my extensive forum topic, I have posted all necessary output and information about this issue: http://forums.gentoo.org/viewtopic.php?t=177788 Reproducible: Always Steps to Reproduce: 1.Setting up a complete new installation, choosing any 2.6 kernel with proper configuration, siimage & libata + sata_sil as modules. 2.Booting into the new installation, modprobing eihter siimage or sata_sil. 3.It does not matter what you try, you will not get more than 15 MB/sec transfer rate on a connected SATA drive (it has nothing to do with the siimage patch) Actual Results: Nothing else, I simply am unable to get more than 15 MB/sec transfer rate from the SATA drives, it does not matter if choosing siimage or sata_sil, if applying the known patch to the siimage driver, nothing seems to be able to influence this behavior. Expected Results: When booting from the mentioned livecds (it's on both a 2.6.5 kernel, but with different configuration and patches), the access to the SATA drives is exactly fine with about 55 MB/sec, but I am absolutely unable to reproduce this normal behavior on an actual performed installation on an additional PATA drive. This is my first bug report, I am sorry to be unable to write here in more details, but I already have posted every single details, every relevant output I got (dmesg, hdparm results, kernel config, test-methodes), and every single step I tried in my forum post. Please have a look at that.
After two more days of extensive trial & error testing on the config file from the working LiveCD-Gentoo-Reiser4 RedeeLive, I finally found the !!! SOLUTION !!!! to this hardcore-problem. You would never have imagined, what's causing this SATA-low-transfer-rate-problem: It's the obsolete DEVFS !!! What I didn't take a closer look at, was the following error messages, that came during each boot: ----- * Running hdparm on disc1... * Failed to start hdparm on disc1. * Running hdparm on disc2... * Failed to start hdparm on disc2. ----- I didn't care, because of course hdparm settings can not be applied to scsi-drives eg. SATA drives detected as scsi-drives (since the last two days, I only concentrated on the use of sata_sil + libata). Every time I saw that hdparm errors, I already knew, that hdparm -t would only bring up about 14 MB/sec transfer-rate. So this is what you have to enable in your kernel to get it working: ----- File Systems ---> Pseudo filesystems ---> [*] /dev file system support (OBSOLETE) [*] Automatically mount at boot (NEW) ----- After the recompile and reboot, the hdparm error message during boot changes into the following: ----- * Skipping disc1 hdparm does not support SCSI devices. * Skipping disc2 hdparm does not support SCSI devices. ----- and hdparm -t brings up the full transfer-rate of about 55 MB/sec !!! Bloody hell, what a fight, and what a waste of time. Of course I configured all my systems to abandon the obsolete DEVFS, using udev + hotplug, so how should someone guess that this can cause such a weird problem, if no error message comes up telling what's wrong. Of course I would have become suspicious, if /dev/sda and /dev/sdb wouldn't have shown up at all, that udev could be behind it, but they were always there, it was just that loss in transfer-rate. So how can this be explained? Is it a serious bug? Or can this be prevented by creating an udev rule ??? I don't see the point of having to stick with the obsolete DEVFS, if I have udev up and runnng without any other problem.
Probably related to: http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=108547985002942&w=2 http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=108548292915842&w=2 This is a situation where hdparm is giving useless values. I think you will find that the system runs at good speeds in general usage, just hdparm says you are running slow. I'd suggest trying kernel 2.6.7-rc1-mm1. This appears to have solved the problem for me, hdparm now operates at full speed.
Patch can be found on this thread: http://marc.theaimsgroup.com/?l=linux-kernel&m=108551093231241&w=2 This solves the issue, and has been merged into 2.6.7-rc1-mm1.
