Summary: | SATA Silicon Image 3112A sticks with 15 MB/sec (siimage & libata + sata_sil is not the problem) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Master One <MasterOne> |
Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | RESOLVED WORKSFORME | ||
Severity: | critical | CC: | dsd, livewire |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?t=177788 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Master One
2004-05-26 12:17:15 UTC
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. |