Abysmal harddrive performance and the uselessness of forums

While working with the "new" ASUS Pundit-R350 I found the IO performance of the system severely lacking.

When doing anything IO heavy on the box system load goes up and the system becomes basically unresponsive. I noticed that while preparing an image for an USB stick:

[root@workstation ~]# dd if=/dev/zero of=usbstick.img count=1024 bs=1M
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 300.266 s, 3.6 MB/s
[root@workstation ~]# uptime
 14:51:02 up 7 min,  2 users,  load average: 4.53, 3.63, 1.66
[root@workstation ~]#

3.6 MB/s transfer rate is completely unacceptable. I'm feeling as if 1994 called and asked for the Red Hat Linux 3.0.3 (Picasso) install CDs.
To solve this mystery, why a SATA disk is running that slow a bit of digging is needed.

Usually, such slow IO access means the drive in question is not using DMA transfer but one of the slower PIO modes.
This can be checked with the hdparm utility:

[root@workstation ~]# hdparm -I /dev/sda | grep '[DP][MI][AO]:'
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 ∗udma5 udma6 
	PIO: pio0 pio1 pio2 pio3 pio4 
[root@workstation ~]# 

As can be seen, the udma5 entry has an asterisk in front of it, identifying the currently used transfer mode is in fact UDMA/100.
Considering the claimed transfer mode and the actual speed I'd suspect a kernel problem. The tool for viewing the kernel log is dmesg. Using this command in combination with grep allows one to quickly find anything related to ata:

[root@workstation ~]# dmesg | grep ata
 BIOS-e820: 000000003bf40000 - 000000003bf50000 (ACPI data)
Memory: 965836k/982272k available (2233k kernel code, 15736k reserved, 1120k data, 284k init, 64768k highmem)
      .data : 0xc062e7b5 - 0xc0746800   (1120 kB)
Write protecting the kernel read-only data: 908k
libata version 3.00 loaded.
scsi0 : pata_atiixp
scsi1 : pata_atiixp
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
ata1.00: ATAPI: _NEC DVD_RW ND-4550A, 1.06, max UDMA/33
ata1.00: configured for UDMA/33
ata2.00: ATA-7: ST3250823AS, 3.03, max UDMA/133
ata2.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: simplex DMA is claimed by other device, disabling DMA
ata2.00: configured for PIO4
EXT3-fs: mounted filesystem with ordered data mode.
[root@workstation ~]#

The line ata2.00: simplex DMA is claimed by other device, disabling DMA and ata2.00: configured for PIO4 explain the problem. The disk was in fact only being accessed by one of the PIO modes. Googling for the first line, gives several results. Of interest are the different hits from the Arch-Linux, the Ubuntu and the Fedora forums. Seems other people have the same problems. The first hit however is from the Ubuntu Wiki suggesting that the problem is caused by the ata_generic module which prevents the pata_atiixp module from correctly driving the interface.

It quickly turns out however, that the wiki entry is incorrect and the forums are completely useless as nobody really looked into the issue at all. Koen, explains this nicely.

A bit of googling for Simplex DMA shows that the kernel driver is simply buggy/the way fedora loads sata drivers is buggy.
Happily, cebbert (one of our kernel wranglers) already applied a patch fixing this problem.

This nicely shows that even though fedora's way of trailing the bleeding edge quite closely may lead to strange hardware problems from time to time, the fix is usually pretty quickly applied.
Considering that the relatively large number of users allows for a larger testing base and therefore improving the software for every user in the long run I find this is an acceptable compromise.