For the record, I just built a couple of systems using FoxConn SIS-based
661FX7MI-S P4/775, PC3200 Motherboards with 2.6.11.12/IVTV-0.4.5, and the
PVR500 worked great. However, the SIS ethernet driver was faulty and limited
network access to < 100 Kbps (hideos!). So I swapped out the motherboards to
VIA chipset motherboards, and the ethernet worked but the REG_DMAXFER errors
prevented the PVR500 from working.
Hans Verkuil wrote ..
> Hi all,
>
> First of all I'd like to thank the people who tested these patches! It
> is clear that the patches improve matters for the DMA 0x0000000b error
> but that it is still not enough to get a fully stable system for some
> people.
>
> Based on these results I have committed the patch to the various ivtv
> branches and I will be making new releases next weekend (unless some
> serious errors crop up).
>
> The remaining DMA error ('ENC: REG_DMAXFER 2 wait failed') is much more
> difficult. Based on all the information I have the root cause is either
> buggy code in the firmware and/or buggy DMA hardware. But the current
> DMA handling in our driver makes it (much?) more likely that this bug
> is hit.
>
> Basically the DMA engine of the cx23415/6 seems to be not very good in
> detecting and handling DMA anomalies (DMA errors, drivers that do not
> read DMA fast enough, things like that). So when there is a large
> amount of DMA activity in the system, or if interrupts are blocked for
> a long time (I suspect CPU frequency changing here) then the driver
> can't handle the DMA fast enough and the firmware seems to get confused
> at some point (DMA queue overflowing? I've no idea). In the end the
> firmware seems to give up, stops DMA and simply hangs.
>
> Now, the current DMA code in the driver is not written to be as fast as
> possible as it is running in a user-space thread, contains sleeps and
> basically I don't trust it very much to behave correctly under high
> load conditions. Also I now know much better how it should work.
>
> Unfortunately, fixing this is not a matter of a quick hack, it means
> some serious reorganization. That's OK, I've wanted to do that for a
> long time and now seems to be a good time to do this. So I've started a
> serious clean up job in the current ivtv trunk. Hopefully at the end we
> will have a driver that is much more robust in high load situations.
>
> The older drivers (up to ivtv-0.8 for kernel 2.6.18) will be released
> with the fix for the DMA 0x0000000b error, which should be a big
> improvement for many people. For those where this is not sufficient you
> will have to wait until I'm done with the reorganization effort.
> Whether that will be backported to older versions I really cannot say
> at this moment.
>
> Regards,
>
> Hans
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
