IDE I/O disturbes other PCI busmasters on VIA platforms

Hello all,

I'm currently playing with on of those neat VIA Epia based x86 platforms.

One problem that annoyed my on other VIA based systems before is that IDE I/O disturbes other PCI busmasters.

I did my latest tests with 2.4.22-ac2 and ide dma enabled for both the hdd and the dvd drive.

The effect is visible when you use a TV card with busmastering capabilities (simple saa7146 based tv card) and use the overlay facility of "xawtv" for example. As you all know, the tv picture is written directly to the framebuffer with busmaster dma.

If you start "updatedb" now, for example, you'll notice heavy pixel dropouts in the frame. They're "best" visible if there's look of motion in the picture.

If you disable dma, you'll notice frozen pictures, which will last up to several seconds.

I tried the following
- use latest 2.4 kernel
- set latencies for the different PCI devices with "setpci"
- play with burst and threshold settings of the saa7146 busmaster

Unfortunately, non of these things really helped. I was able to make things worse (by setting latencies very low or by lowering the burst size of the transfers), but I did not get rid of the problem.

Does anyone know a solution for this problem? Any help is appreciated.

Below I attached the lspci output of the box.

CU
Michael.

lspciroot@micro:~# lspci -v
00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266]
        Subsystem: VIA Technologies, Inc.: Unknown device aa01
        Flags: bus master, 66Mhz, medium devsel, latency 8
        Memory at d0000000 (32-bit, prefetchable) [size=128M]
        Capabilities: [a0] AGP version 2.0
        Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d8000000-dbffffff
Capabilities: [80] Power Management version 2

00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI])
Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller
Flags: bus master, medium devsel, latency 32, IRQ 12
Memory at de000000 (32-bit, non-prefetchable) [size=2K]
I/O ports at d000 [size=128]
Capabilities: [50] Power Management version 2

00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. USB
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2

00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. USB
Flags: bus master, medium devsel, latency 32, IRQ 12
I/O ports at d800 [size=32]
Capabilities: [80] Power Management version 2

00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. USB
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at dc00 [size=32]
Capabilities: [80] Power Management version 2

00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI])
Subsystem: VIA Technologies, Inc. USB 2.0
Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at de001000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2

00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
Subsystem: VIA Technologies, Inc.: Unknown device aa01
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: [c0] Power Management vesion 2

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio Controller (rev 50)
Subsystem: VIA Technologies, Inc.: Unknown device aa01
Flags: medium devsel, IRQ 10
I/O ports at e400 [size=256]
Capabilities: [c0] Power Management version 2

00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
Subsystem: VIA Technologies, Inc. VT6102 [Rhine II] Embeded
Ethernet Controller on VT8235
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at ec00 [size=256]
Memory at de002000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2

00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH: Unknown device 0003
Flags: bus master, medium devsel, latency 32, IRQ 12 Memory at de003000 (32-bit, non-prefetchable) [size=512]

01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03) (prog-if 00 [VGA])
Subsystem: VIA Technologies, Inc. VT8623 [Apollo CLE266]
integrated CastleRock graphics
Flags: bus master, medium devsel, latency 32, IRQ 11
Memory at d8000000 (32-bit, prefetchable) [size=64M]
Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Capabilities: [70] AGP version 2.0

Do not perform busmaster transfers between busses with diffrerent speeds, or use only 20MBps bandwidth or do not use VIA. All chips I saw from them are not able to convert burst transfer on PCI to the burst transfer on AGP bus. Either go through main memory, or plug PCI videocard to your box.
Petr Vandrovec

I get none of these problems. That is with a bt878 tv card, G450 agp video card, 2.6.0-test5, udma4 enabled, and using xawtv with xv via the v4l module for X. If i disable dma, the tv is the only thing uneffected. This is on a Abit mobo with VIA vt82c686b ide chipset and VIA Twister-K/KT133x/KM133 agp chipset (using agpgart). DRI not loaded.

If disabling dma gives you picture distortion, then it seems to me to be obvious that Busmastering has nothing to do with the problem and rather it's a rendering issue. If you're using x11 to render the image than it will most certainly be effected by heavy io as the kernel will have issues scheduling under heavy io, especially in 2.4. I would check to make sure you're using xv to render the tv window if you have that option, if not then maybe that's as best as you can do with X.

Hello Ed,

Hm, I don't think so. I think that disabling dma and thus the polling of the CPU on the IDE->PCI bus simply hogs it completely.

I'm using the overlay facility, ie. the data is written directly to the framebuffer. There is no CPU, no scheduling and no memcpy() involved, just pure PCI-to-AGP busmaster transfer. If I see distortions there, then I guess it's a busmastering issue.

As I have already written, you can make things even worse, if you lower the latencies vie setpci or shrink the dma burst sizes. Then you'll get only pixel garbage... ;-)

CU
Michael.