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.
>
> 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.
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.
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.
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.
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.
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.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
