Red Hat Bugzilla – Bug 47597
UDMA not available with IBM Deskstar disks and K7T266 PRO motherboard
Last modified: 2007-04-18 12:34:30 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-12 i686; en-US; rv:0.9.1) Gecko/20010610 Description of problem: kernel-2.4.2-2 provided UDMA(33) support with IBM Deskstar 60GXP disks and Microstar K7T266 PRO motherboard based on VIA KT266 chipset. After kernel upgrade to kernel-2.4.3-12, only PIO modes were available. How reproducible: Always Steps to Reproduce: 1.install kernel-2.4.3-12 on specified hardware. 2.run hdparm -d1 /dev/hda Actual Results: hdparm says: operation not permitted. Expected Results: hdparm should report mode changed to DMA. Additional info: I tested the specified harware with DMA enabled under heavy momory and IO load (quantum chemistry chalculations: single test duration > 24h; several tests have been performed) and the box survived. Box has two disks and runs software RAID0 (striping) on them. BIOS is original 1.0 version (BIOS upgrades require Win32 and I had to refrain). I am aware that some/many VIA chipsets are buggy but this setup seems to be an exception. The relevant dmesg output for 2.4.2-2 is: VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1 ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:pio, hdd:pio hda: IC35L040AVER07-0, ATA DISK drive hdb: IC35L040AVER07-0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=5005/255/63, UDMA(33) hdb: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=5005/255/63, UDMA(33) I have actually tried forcing UDMA(100) with 2.4.2-2 (append="ide0=ata66" in /etc/lilo.conf) but have not had yet time to test it as thoroughly as udma33. If you need more information, just ask.
Could you check if the drive isn't already in DMA mode? cat /proc/ide/hda/settings should give that info.
I do not have 2.4.3-12 running right now but I am positive hdparm /dev/hda reported that DMA was off. I hope this is equivalent. If not, I can reboot the box and check it.
hdparm should give you the same indeed (it uses the same interface). The only change between 2.4.2-2 and 2.4.3-12 in this area is that 2.4.2-2 would disable DMA on ABIT KT7 boards due to a > 95% "corrupts data" rate, while 2.4.3-12 has the official VIA workaround for the bug and doesn't have this restriction anymore. This seems to be the opposite of what you're seeing..... /me wonders.
For the record: I tried kernel-2.4.5-10.src.rpm from rawhide and it could not enable DMA, neither.
I have recalled one more thing: hdparm crashed with certain option combination (I think it was -X66) and kernel-2.4.3-12, generating an oops: Jul 5 17:29:05 xi kernel: ide0: Speed warnings UDMA 3/4/5 is not functional. Jul 5 17:29:27 xi kernel: divide error: 0000 xi kernel: CPU: 0 xi kernel: EIP: 0010:[via_set_drive+142/352] xi kernel: EIP: 0010:[<c01983ce>] xi kernel: EFLAGS: 00010246 xi kernel: eax: 000003e8 ebx: c02d2960 ecx: 00000040 edx: 00000000 xi kernel: esi: c02d2960 edi: ee885ef8 ebp: c02d2960 esp: ee885e78 xi kernel: ds: 0018 es: 0018 ss: 0018 xi kernel: Process hdparm (pid: 943, stackpage=ee885000) xi kernel: Stack: c02d2a94 40000000 00000000 00000000 00000000 00000000 00000000 00000000 xi kernel: ee885ef4 ee885e08 00000000 00000000 00000000 00000001 c02d2960 c02d2960 xi kernel: ee885ef8 bffff7cc c02d2960 c02d2960 ee885ef8 bffff7cc c018bd91 c02d2960 xi kernel: Call Trace: [ide_ioctl+2289/3376] [write_chan+492/528] [blkdev_ioctl+38/64] [sys_ioctl+375/400] [system_call+51/56] xi kernel: Call Trace: [<c018bd91>] [<c0170dec>] [<c0139656>] [<c013fbe7>] [<c0106d2b>] xi kernel: xi kernel: Code: f7 35 34 49 2d c0 89 c7 a1 28 49 2d c0 0f b7 40 08 83 e0 07
For the record, kernel-2.4.6-3.1 of Roswell does not fix this problem. I wonder if it matters: this is straight KT7 motherboard, it is K7T266 based on different chipset, as far as I can tell. Also, I have been using it under heavy load for a month with ide0=ata66 enabled and experienced no problems at all (well, no problems that seemed to be related).
2.4.9-13 kernels appear to work just fine. This report can be closed as far I am concerned with resolution as ERRATA.