[ivtv-devel] Still need help on DMA issues causing MPEG Corruption

Steven Ellis mail_lists at stevencherie.net
Wed Aug 9 05:18:22 CEST 2006

Hi Hans

Hans Verkuil wrote:
> On Tuesday 08 August 2006 23:37, Steven Ellis wrote:
>> First off can someone setup an account on trac for me so I can update
>> tickets 48 and 49.
> Axel, can you do this?
>> Now I have been trying ivtv version 0.4.2-0.4.6, plus I've seen
>> recent reports of the problem still being present with the 0.6.x
>> tree.
>> Hardware - Asus A8N-VM CSM motherboard, Athlon 64 3000+, Knoppmyth
>> R5B7 with 2.6.15 kernel, IDE HD and either PVR150 or PVR500 capture
>> (tried both). I also have a FreeCom USB DVB-T card, and I run a lot
>> of media over the 100Mb network.
>> Reproducing the problem
>> --------------------------------
>> Can almost do this at will now. If I have a capture running whilst I
>> delete a large previously captured file (about 2G) off an ext3 local
>> volume the slight system pause during the deletion is enough to force
>> the problem.
>> It also seems to happen quite quickly if I'm playing a video file
>> across the network via NFS and jump around the video stream very
>> rapidly. Its like the ethernet i/o is preventing the DMA from the
>> ivtv card
>> Attempts to fix the problem
>> ----------------------------------
>> 1. Turned off Cool and Quiet
>> This was mentioned in trac ticket 48 as a possible fix. Initially
>> appeared to reduce occurrences, but I was mistaken. No change
>> 2. Try to change the PCI latency of the IDE devices with setpci.
>> Doesn't work with the IDE devices on my motherboard. It uses and
>> nforce chipset and the driver won't let you change latency values.
>> The MythTV Wiki recommends bumping the IDE latency to avoid issues.
>> 3. Check BIOS level timings etc
>> Doesn't appear to be anything I can tweak in this bios.
>> 4. Use PIO mode.
>> Well I just tried this and my machine isn't fast enough to capture
>> full D1 PAL in PIO mode. CPU is running 60%+ in ivtv_enc, but I still
>> get capture issues.
>> Possible Next Steps
>> ------------------------
>> 1. Changing the size of the DMA ENC buffers
>> Any chance increasing the buffer sizes might help matters.
> Won't help.
Ok. Nice to know.
>> 2. Enable additional debug information
>> This is where I need some feedback. What debug options should I look
>> at enabling.
>> I'd really appreciate any help here. The oddest part is I never had
>> this problem with the older 0.3.x driver versions. There are quite a
>> few people on this list and the users list with the problem. I'm sure
>> with a bit of guidance from Hans we can track it down.
> First of all, this problem can only occur after a DMA error. Some 
> chipsets are more prone to DMA errors than others, so this introduces a 
> hardware component into the problem. Many people don't see this (or 
> only very rarely) because their hardware is better in dealing with DMA.
> At some point in time Chris Kennedy switched from using the firmware DMA 
> mailbox commands to directly programming DMA registers in the card's 
> memory. The reason is that the card's firmware is simply buggy when 
> dealing with DMA (and from all accounts so is the hardware). This is 
> (if I understand correctly) especially the case when multiple streams 
> (e.g. MPEG encoding and MPEG decoding, or MPEG encoding and VBI) are 
> running simultaneously.
Ok what version do I need to look at for the old DMA code. I'm more than 
happy to try an retrofit that code into the current 0.4.x tree and work 
through my steps that reproduce the problem. Don't a bit of Linux device 
driver work in the past so i'm not totally poking around in the dark 
(see tw98.sf.net).
> Now it seems that when a DMA error occurs the dma_from_device() function 
> doesn't seem to be able to restore the card to the correct 
> configuration before retrying the DMA. The result is that MPEG data is 
> shifted and the stream becomes corrupt.
Makes a lot of sense based on the nature of the visible artifacts
> Several people have looked at it without finding anything special. It is 
> really hard for me to investigate since it so rarely happens on my 
> hardware.
> An alternative approach (although that would be a temporary solution 
> only) might be to reinstate the original DMA handling and make it 
> possible to select one or the other. It may well be that the original 
> DMA handling is actually better at correcting DMA errors in the case of 
> having just a single stream.
Yes I agree it would be good to make the two DMA modes selectable.
> What makes this an interesting approach is that it may be possible to 
> compare the DMA registers after a DMA error occurred and see if that 
> suggests a solution for our dma_from_device() function.
How can you do this?
> Unfortunately, I myself don't have the time for that, and the great 
> difficulty I have to even reproduce it doesn't make it easier for me.
Understood. Just need some pointers and a little bit of hand holding.
> There are no debugging options that are useful here. It is really a case 
> of very low level printk debugging and hoping you can find out what's 
> wrong. If it was easy this would have been fixed ages ago.
> I would really appreciate it if you would manage to solve this, but be 
> aware that it is probably a major effort.
This is really important. My company (www.openmedia.co.nz) has been 
shipping MythTV based PVR units using the Hauppauge cards, and thus far 
most of my customers aren't having the problems. I can reproduce this 
quite easily in my lab thanks to the stress tests I perform. Quite happy 
to apply some engineering time onto this issue so that all of the ivtv 
users can benefit.


More information about the ivtv-devel mailing list