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):
Steps to Reproduce:
1. boot into RH Linux 9
Actual Results: reads/writes are very slow. Often writes cause long (5-30
Expected Results: The drive should be very fast
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
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.
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
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.