via82cxxx don't use DMA on VT8237 chipset

Asked by Sannny

via82cxxx don't use DMA on VT8237 chipset (maybe others from via too).

Got the problem with a Via VB6002 mainboard running Ubuntu 8.04 Beta using a sata disk.

Hints:
http://www.viaarena.com/Guide/enable%20pide%20dma%20mode%20with%20via%20sb%20chips%20ver0%5B1%5D.82.gz
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/56823

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu linux Edit question
Assignee:
No assignee Edit question
Solved by:
Sannny
Solved:
Last query:
Last reply:

This question was originally filed as bug #208153.

Revision history for this message
Sannny (samuel-owee) said :
#1
Revision history for this message
Leann Ogasawara (leannogasawara) said :
#2

Hi Sannny,

Care to attach the output of "sudo lspci -vvnn" . Also, just for future reference if you could attach each log file individually rather than as a tarball it would be much appreciated. Thanks.

Revision history for this message
Sannny (samuel-owee) said :
#3
Revision history for this message
Sannny (samuel-owee) said :
#4

Oh, ehm, DMA seems to be enabled all the time. False alarm.

[ 22.057440] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 22.057569] USB Universal Host Controller Interface driver v3.0
[ 22.238635] ata1.00: ATA-8: WDC WD5000ABPS-01ZZB0, 02.01B01, max UDMA/133
[ 22.238646] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 22.253784] ata1.00: configured for UDMA/133
[ 22.457188] ata2: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
[ 22.469100] scsi 0:0:0:0: Direct-Access ATA WDC WD5000ABPS-0 02.0 PQ: 0 ANSI: 5

Now i'm wondering why the CPU iowait goes up to 80% when i copy some files around the disk... does anybody know why?

Thanks, Sannny

Revision history for this message
Sannny (samuel-owee) said :
#5

Hey, where are my attachments? grrr ...

mhh, i think the slow via C-7 is the problem.

Revision history for this message
JanCeuleers (jan-ceuleers) said :
#6

Can I just say that I've had a problem like this as well, with hdparm not being able to activate DMA:

root@fe2:~# hdparm -d1 -X68 /dev/hdb

/dev/hdb:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 setting xfermode to 68 (UltraDMA mode4)
 using_dma = 0 (off)

yet:

root@fe2:~# hdparm -i /dev/hdb

/dev/hdb:

 Model=MATSHITADVD-RAM UJ-85JS, FwRev=FWR7, SerialNo=
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 *udma4
 AdvancedPM=no
 Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6

 * signifies the current active mode

The standard anwer returned by your friendly corner search engine is that this can only be resolved by recompiling the kernel, either by compiling via82cxxx into the kernel (i.e. not as a module), or by disabling generic IDE support in the kernel config.

I have managed to resolve this problem without recompiling the kernel, but by excluding ide-generic from the initrd image. Specifically: I removed ide_generic from /etc/initramfs-tools/modules to which it had erroneously been added (this is Ubuntu 7.10).

Hope this helps someone...

Revision history for this message
Vesselin Kostadinov (vesok) said :
#7

Thanks JanCeuleers for your advice, it helped a lot.

On ubuntu 8.04 apparently via82cxxx chips are driven by the pata_via module and not via82cxxx. I had to edit /etc/initramfs-tools/modules and disable module ide_generic there. Then after `update-initramfs -u` and a reboot I found myself in an unusable system because the new pata_* modules name the drivers/partitions sda/sda1/sda2/etc instead of hda/hda1/hda2/etc. So I rebooted into old kernel, updated /etc/fstab and /boot/grub/menu.lst (replacing hda* with sda*) and finally I got DMA enabled and the system is >10* faster. Well worth the effort.