Hi Tony, It turns I'm having the same problem and saw you've done some research.
# dmesg| grep DMA pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 wd1(pciide0:0:1): using PIO mode 4, DMA mode 2 wd2(pciide0:1:1): using PIO mode 4, DMA mode 2 What exact changes did you make to pciide.c in order to enable Ultra-DMA? I see the switch at around line 2610 in pciide.c, but cannot work out how to add PCI_PRODUCT_VIATECH_VT82C571. I'm running 3.8. thanks, Sebastian Tony Lambiris wrote: > Man I must need sleep or something... this doesn't fix my problem, I > forgot I had the extra case in the switch statement still in pciide.c. > That did work, however, adding PCI_PRODUCT_VIATECH_VT82C571 as a case. > Like I said before I don't know if this is the right way to do this, but > it's a temporary fix for me. > > Over and out, sorry again for the noise. > > Tony Lambiris wrote: >> Sorry for all the noise, this seems to have fixed it (from NetBSD): >> >> --- via82c586.c.orig Mon Sep 12 19:38:35 2005 >> +++ via82c586.c Mon Sep 12 20:27:28 2005 >> @@ -256,9 +256,10 @@ >> reg = pci_conf_read(ph->ph_pc, ph->ph_tag, >> VP3_CFG_PIRQ_REG); >> shift = vp3_cfg_trigger_shift[i]; >> - /* XXX we only upgrade the trigger here */ >> if (trigger == IST_LEVEL) >> reg &= ~(VP3_CFG_TRIGGER_MASK << shift); >> + else >> + reg |= (VP3_CFG_TRIGGER_EDGE << shift); >> pci_conf_write(ph->ph_pc, ph->ph_tag, >> VP3_CFG_PIRQ_REG, reg); >> break; >> >> Tony Lambiris wrote: >> >>> I forgot to ask, would it be bad practice to just add >>> PCI_PRODUCT_VIATECH_VT82C571 to one of the cases in the switch >>> statement? It seems like this might go a little deeper.... >>> >>> Tony Lambiris wrote: >>> >>>> Well I thought I knew what the problem was (nope).. I found something >>>> interesting though... >>>> >>>> The motherboards that don't setup UDMA properly uses a "VIA VT8237 >>>> ISA" for pcib; the one's that setup UDMA properly uses a "VIA VT8235 >>>> ISA". I added some debugging in pciide.c in function apollo_chip_map >>>> on the switch statement, and the pcib_id it's switching on is 0x0571, >>>> which in pcidevs is "VT82C571 IDE". Does that mean somewhere the >>>> VT8237 chipset isn't being setup correctly or something? >>>> >>>> I'm a little confused at this juncture, any light that can be shed >>>> would be greatly appriciated. >>>> >>>> Thanks. >>>> >>>> Tony Lambiris wrote: >>>> >>>>> I (think I) found the problem... I will be posting a patch shortly >>>>> if I confirm my suspicions. >>>>> >>>>> Thanks. >>>>> >>>>> Tony Lambiris wrote: >>>>> >>>>>> We have some motherboards with (what we think) are the same chips >>>>>> and revisions with the same hard drives, but some drives are being >>>>>> detected as DMA and others as ATA133. Here is an example: >>>>>> >>>>>> pciide0 at pci0 dev 17 function 1 "VIA VT82C571 IDE" rev 0x06: >>>>>> ATA133, channel 0 configured to compatibility, channel 1 configured >>>>>> to compatibility >>>>>> wd0 at pciide0 channel 0 drive 0: <WDC WD800BB-75JHC0> >>>>>> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 >>>>>> >>>>>> pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: DMA, >>>>>> channel 0 configured to compatibility, channel 1 configured to >>>>>> compatibility >>>>>> wd0 at pciide0 channel 0 drive 0: <WDC WD800BB-75JHC0> >>>>>> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 >>>>>> >>>>>> As you can see it's the same IDE chipset, same revision, same >>>>>> drives.. the only thing I can think of is it's an IDE ribbon issue, >>>>>> but the ribbons we used (which were mixed from the cases and the >>>>>> motherboard boxes), were brand new. >>>>>> >>>>>> Any suggestions? >>>>>> >>>>>> TIA.
