Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: I have a Western Digital Raptor (WD360) Serial ATA harddrive on Si3112 SATA controller. The drive performs very well with other operating systems, however, under RH Linux 9 the drive is painfully slow. In addition to being very slow, I experience long pauses during writes. I do not receive any error messages in syslog or any place else. Version-Release number of selected component (if applicable): kernel-2.4.20-8 How reproducible: Always Steps to Reproduce: 1. boot into RH Linux 9 2. 3. Actual Results: reads/writes are very slow. Often writes cause long (5-30 second) pauses. Expected Results: The drive should be very fast Additional info: Again, under other operating systems, the drive performs as expected. Other ATA100 drives on my system perform very well (not on SATA controller).
We have a known problem with some drive combinations that leaves the controller in PIO mode wrongly. Does "hdparm -d1 /dev/hda" make it a lot happier ?
when I enable dma by 'hdparm -d1 /dev/hde', the system crashes. I get a ton of read/write timeout erros such as: hde: dma_timer_expiry: dma status == 0x21 hde: timeout waiting for DMA ide2: reset phy, status = 0x00000113, siimage reset
You probably need -X66 -d1 so that you also tune the drive for DMA
when I do a 'hdparm -X66 -d1 /dev/hde', things blow up again with similar errors (HDE I/O errors, drive not ready, etc...)
I had excactly the same problem with a Intel SE7505VB2 dual XEON mainboard (SiI3112 SATA controller) with WD360GD SATA disk. Patch for SiI3112 exists in linux-2.4.21-rc3, see http://www.cs.helsinki.fi/linux/linux-kernel/2003-20/1012.html With this kernel I can run "hdparm -X udma5 -c1 -d1 -u1 /dev/hde" without errors. The performance in nice: # hdparm -tT /dev/hde /dev/hde: Timing buffer-cache reads: 128 MB in 0.23 seconds =556.52 MB/sec Timing buffered disk reads: 64 MB in 1.17 seconds = 54.70 MB/sec
I'm still working on this. I have to deal with one bit of fun with a certain vendors drives then it should be ready to test/roll into future base kernels/RH
thank you for the update!
I have an ASUS A7N8X Deluxe that contains an on board Si3112, also, I have an Si3112 based PCI card on this machine. I have 4 Seagate 120GB Baracuda SATA drives, and I have attempted to create a RAID5 array on RedHat 9.0 with no success. The drives are all detected properly during boot, and disk druid is able to determine their configuration and such, however, when anaconda attempts to format them, the mouse gets very jumpy, and eventually, it produces an error. Each time I have done this is produced a different error. I could not capture the exact text because this system has no floppy drive. I have also attempted to install RedHat 9.0 onto a single member of this group and I encounter similar difficulty. I went out and got a couple of parallel IDE drives, just to get started, and they have worked fine. I would, of course, still like to get the RAID5 array running though. I hope this info helps. -Jim Heintz
I also have a sluggish SATA problem. However, when I attempt to put the SATA drives into DMA mode (hdparm -d1 /dev/hdc), it will not enter DMA mode. I am running Severn. I have an Intel S875WP1-E motherboard. Because the motherboard's SATA controller is not supported by the Linux kernel, I have configured the BIOS to run in Legacy ATA mode. The sluggish problem was bad that I have put in a PATA drive and installed Severn on that. It is like night and day.
The Intel 875 is an ICH5 not SI3112 - it isnt currently supported but should be in beta 2 - different bug, but if it still fails after beta2 let me know.
I'm having similar problems with Sil3112 on Gigabyte 8KNXP with Maxtor SATA. Use W2K and RH9 dual boot. In W2K the SATA disk had error / crashed (with log event in 2K complaining about SI3112 not responding in timeout period - and then bad blocks on drive). W2K could not even format drive after that. So went to Linux - reformatted OK, then ran a: badblocks -svw -c 8192 -o bad.txt /dev/hde1. Drive is 160GB and it took 15 hours to fill the disk with the 0xaaaaaaaa test pattern - but got there in the end! Then it completely hung on block zero when it tried to read it back. Sounds like the slow write is linked to the problems described above - not sure why it hung on read though?
Regarding the SATA SiI 3112A drive compatability, is there any updates on this issue? Is there any OS versions that I can upgrade to that will fix this problem.
The 2.6 kernel tree knows a bit more about SI3112A and using it well, as it has a real SATA layer and stuff. For 2.4 the older 2.4 kernels use the device in pio mode (hdparm -d1 can be done), later ones apply the write size limit DMA rule to all disks, the 2.6 current stuff (I think it made 2.6 by now) applies the write size limit only to the problem drives
For SATA you really want to be running Fedora or RHEL, as libata isn't going to be backported to RHL9 before it reaches end of life next month.
The same problem occurs with RHEL 3.0. See bug# 119478. However, using the Fedora kernel, things seem to work correctly.