From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/0 Description of problem: Both the Tyan 2515, and 2518 don't enable dma by default.You can enable it via hdparm, but the kernel prints a lot of errors, and reverts to non dma access. Both systems can use dma under RH7.2, 2.4.18, and 2.4.19rc1. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.install limbo 2.hdparm -d 1 /dev/hda 3. Actual Results: From dmesg: hdc: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest } hdc: drive not ready for command hdc: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest } hdc: drive not ready for command hdc: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest } hdc: drive not ready for command hdc: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest } hdc: drive not ready for command hda: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } hda: drive not ready for command hda: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } hda: drive not ready for command hda: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } hda: drive not ready for command hda: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 hda: status error: status=0x58 { DriveReady SeekComplete DataRequest } hda: drive not ready for command Additional info:
any idea what kind of ide chipset this is?
SvrWks OSB4: IDE controller on PCI bus 00 dev 79 SvrWks OSB4: chipset revision 0 SvrWks OSB4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio Note I have not tested the current beta on this system yet.
OSB4.... yes DMA is disabled on purpose; there's a silicon bug that can lead to random memory corruption
We should only be cutting out UDMA. It also doesnt explain why using hdparm -d 1 failed. That should most definitely have worked. The rule is approximately CSB5/CSB6 -> UDMA OK OSB4 -> UDMA off for certain subsets of drives (safest to say for all), MWDMA works fine, as does PIO
This also occurs on a tyan 2510 /w the same OSB4 chipset. In addition the 2518, and 2510 seem to work fine on 7.2 (/w multiword dma), and under Alan's 2.4.20-pre2-ac3. (Fine = 24H of cerberus in pathological mode.)
Thats newer IDE code and being a little less conservative. Until we are sure we have the problem entirely under control its not reasonable to ship DMA enabled OSB4 to end users