From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: Using the RHEL kernel, I get really poor drive performance with my WD SATA drive. I installed the fedora-1 kernel, 2.4.22-1.2174.nptl, and the drive works correctly under this kernel. I assume this is the same problem as bug# 90988, which was fixed in fedora-1. This is a hdparm -T /dev/hde under the RHEL kernel: /dev/hde: Timing buffered disk reads: 6 MB in 4.35 seconds = 1.38 MB/sec Under the fedora kernel, I get: /dev/hde: Timing buffered disk reads: 158 MB in 3.03 seconds = 52.15 MB/sec Version-Release number of selected component (if applicable): kernel-2.4.21-9.0.1EL How reproducible: Always Steps to Reproduce: 1.use kernel 2.4.21-9.0.1EL 2. 3. Actual Results: looks like DMA mode does not set correctly Additional info: a hdparm -I under RHEL kernel: ATA device, with non-removable media Model Number: WDC WD360GD-00FNA0 Serial Number: WD-WMAH91001133 Firmware Revision: 34.06J34 Standards: Supported: 6 5 4 3 Likely used: 6 Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors: 4128705 LBA user addressable sectors: 72303840 LBA48 user addressable sectors: 72303840 device size with M = 1024*1024: 35304 MBytes device size with M = 1000*1000: 37019 MBytes (37 GB) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 74 Queue depth: 1 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * READ BUFFER cmd * WRITE BUFFER cmd * Host Protected Area feature set * Look-ahead * Write cache * Power Management feature set Security Mode feature set * SMART feature set * FLUSH CACHE EXT command * Mandatory FLUSH CACHE command * Device Configuration Overlay feature set * 48-bit Address feature set Automatic Acoustic Management feature set SET MAX security extension Power-Up In Standby feature set * DOWNLOAD MICROCODE cmd * SMART self-test * SMART error logging Security: supported not enabled not locked not frozen not expired: security count not supported: enhanced erase HW reset results: CBLID- above Vih Device num = 0 determined by the jumper Checksum: correct ----- hdparm -I under fedora kernel: /dev/hde: ATA device, with non-removable media Model Number: WDC WD360GD-00FNA0 Serial Number: WD-WMAH91001133 Firmware Revision: 34.06J34 Standards: Supported: 6 5 4 3 Likely used: 6 Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors: 4128705 LBA user addressable sectors: 72303840 LBA48 user addressable sectors: 72303840 device size with M = 1024*1024: 35304 MBytes device size with M = 1000*1000: 37019 MBytes (37 GB) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 74 Queue depth: 1 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * READ BUFFER cmd * WRITE BUFFER cmd * Host Protected Area feature set * Look-ahead * Write cache * Power Management feature set Security Mode feature set * SMART feature set * FLUSH CACHE EXT command * Mandatory FLUSH CACHE command * Device Configuration Overlay feature set * 48-bit Address feature set Automatic Acoustic Management feature set SET MAX security extension Power-Up In Standby feature set * DOWNLOAD MICROCODE cmd * SMART self-test * SMART error logging Security: supported not enabled not locked not frozen not expired: security count not supported: enhanced erase HW reset results: CBLID- above Vih Device num = 0 determined by the jumper Checksum: correct
Are there any plans to address this bug? Can I provide any additional details? Thanks!
can someone please please provide an update as to whats happening on this bug I have the same issue sii 3112 (a7n8x) and sata drive. Perfect performance in suse 9.1 and fedora but i need RHEL 3.0 as i run Oracle 11.5.9 please help. I even paid to get my RHCE surely that counts for something ;) please x
*** Bug 118095 has been marked as a duplicate of this bug. ***
I changed the SATA disc and now I have better performace with WDC WD1600SD-01K and the same SATA SiI 3112. There is no performance change when trying current RHEL3 or RHEL4 and both use /dev/sda (sata_sil module). With ST3160023AS about 15MB/s and with WD1600SD-01K about 35MB/sec (hdparm -t). Because Windows XP has no performace degradation on the same HW I think that there is something broken in Silicon Image support. The second reason for this is much better performance under XP (about 50-60MB/sec) I'll try to use Fedora to compare the results.
Support requests should go via RH support, so we can prioritize customer bugs. The SI v WD performance is expected, there are errata when combining some combinations of SI controllersand ST drives.
We have only education license so Bugzilla is the only way for bugreport.
Reassigning to Jeff Garzik.
i downloaded fc4_64 and installed in on msi k8neo platinum m.b. w. 2x sata samsung drives. install does not recognize raid stripe. is there a way to configure the striped array prior to linux installation ? same problem with suse 10.0_64 [btw, fc4 has five installation cd's, but the install only asked for 3. is this normal?]
You are using SW RAID card. This is better to use kernel level RAID (you may define RAID during the installation).
At MIT we have a customer Lab with computing facility that is using RAID, and seems to be having the same trouble reported in this bug: Poor performance with SATA and RAID. Their summary: We are running a server with RHEL v4 U2. We have 4 300GB SATA disks mapped as a single 900GB RAID5 volume through software. If we use the stock kernel, any copy operation of significant magnitude results in a ata timeout and in some cases severe enough to hang the system. The only solution we have had thus far is to compile a custom kernel more recent than 2.6.13.2. Further Details: Motherboard: Tyan Thunder S2895 (K8WE) CPU x2 : vendor_id : AuthenticAMD cpu family : 15 model : 37 model name : AMD Opteron(tm) Processor 250 stepping : 1 RAM : 16GB DDR-2700 (DDR-3200 was not stable) Linux version 2.6.14.2-sg (root.edu) (gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)) #1 SMP Sat Nov 19 02:45:52 EST 2005 they appended -sg to the kernel version to indicate that it was compiled by them and is not a standard RedHat kernel. SATA controller - we're looking for version info. in case that is relevant to the situation. -- 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) -- 3. any information that you can provide about the SATA drives (e.g. Sunfish 3200 Caviar, rev. 3). -- Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3300831AS Rev: 3.03 Type: Direct-Access ANSI SCSI revision: 05 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3300831AS Rev: 3.03 Type: Direct-Access ANSI SCSI revision: 05 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3300831AS Rev: 3.03 Type: Direct-Access ANSI SCSI revision: 05 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3300831AS Rev: 3.03 Type: Direct-Access ANSI SCSI revision: 05 These are Seagate 300GB SATA drives. When they run with stock RHEL 4 kernel, they have the problem. When they custom-compile a kernel more recent than 2.6.13.2, the problem goes away. QUESTIONS: 1. Is this bug fixed in RHEL 4 U3 which came out today? 2. If the answer to #1 is "no", is this a known bug, and explicitly fixed in 2.6.13.2 and later, or are we just getting lucky? -William Cattey Linux Platform Coordinator, Massachusetts Institute of Technology (Note, that like Milan Kerslanger above, we do not have a TAM, and pretty much our only recourse for bug fixing is through Bugzilla as well.)
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.
Gee I'd completely forgotten about this bug. I guess my customer, noticing that nobody responded after a year, probably wiped Red Hat Enterprise, and installed something like Ubuntu where there are people who actually read and respond to opened bugs.