From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020427 Description of problem: Under your 2.4.9-31 kernel and well as the main line 2.4.18 you can turn on dma on the Tyan 2720. You can't do this on 2.4.18-3. The result is that hard drive access is very slow. [root@localhost root]# hdparm -d /dev/hda /dev/hda: using_dma = 0 (off) [root@localhost root]# hdparm -d 1 /dev/hda /dev/hda: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.install tyan 2720 system 2.hdparm -d 1 /dev/(drive) Actual Results: /dev/hda: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) Expected Results: /dev/hda: setting using_dma to 1 (on) using_dma = 1 (on) Additional info: I suspect this issue is due the the ide code you guys imported from the ac kernel.
I have exactly the same problem. Can't get the Tyan S2720GN to turn on DMA on /dev/hda when I type: hdparm -d1 /dev/hda. System config is Dual 2.2G Xeons, 1GB Memory, RH 7.3 with latest updates (Kernel 2.4.18-4smp) Top disk I/O Speed is 6+ MB/sec to a 40 GB IBM 7200 RPM ATA-100 disk. This s/b closer to 20MB/sec or better. There is a patch: ide-2.4.19-p7.all.convert.10.patch.bz2 at http://www.linuxdiskcert.org/ but since this is not the same kernel I don't think its appropriate. Any help would be appreciated. seth Is there a patch on the way or an rpm update for 2.4.18-4smp???
Try Tyan's new beta BIOS: 2720529a. I've successfully been able to use DMA with this motherboard and 2.4.18-4smp. http://www.tyan.com/support/html/bios_support.html#beta
Check for: 1) If you have "USE_DMA = 1" set either in "/etc/sysconfig/harddisks" or in "/etc/sysconfig/harddisk[IDE_DEVICE_NODE]", where IDE_DEVICE_NODE is "hda, hdb, hdc .... etc" 2) If you have options line for "ide-cd" in "/etc/modules.conf" reading as: options ide-cd dma=1 above to changes worked for me.... good luck!
current erratum kernel ought to have this fixed