On Wednesday 01 August 2007 18:27:09 Mark Bryars wrote:
> Hans Verkuil wrote:
> > For the ivtv-0.10.x series you can get the updated driver here:
> >
> > http://ivtvdriver.org/viewcvs/ivtv/branches/0.10.tar.gz?view=tar
>
> I've been testing this, it's been great the past few days, been doing
> a longer term test with 7 cards in a machine, its been 48 hours now,
> no lockups.
>
> I do see a few DMA ERRORS, not particularly showing any pattern
>
> ivtv2 warning: ENC DMA ERROR b (offset 00106ec0, xfer 1 of 2, retry
> 0) ivtv2 warning: ENC DMA ERROR b (offset 00154ec0, xfer 2 of 3,
> retry 0) ivtv1 warning: ENC DMA ERROR b (offset 0010fec0, xfer 2 of
> 3, retry 0) ivtv1 warning: encoder MPEG: offset 132 -> 128
> ivtv1 warning: ENC DMA ERROR b (offset 00131ec0, xfer 1 of 1, retry
> 0) ivtv1 warning: ENC DMA ERROR b (offset 001046c0, xfer 1 of 1,
> retry 0) ivtv0 warning: ENC DMA ERROR b (offset 000fa6c0, xfer 1 of
> 1, retry 0) ivtv2 warning: ENC DMA ERROR b (offset 0015e6c0, xfer 1
> of 1, retry 0)
>
> Previously from observation a DMA ERROR b meant there was corruption
> in the output stream, I haven't determined if it still does. I see
> the code retries the DMA transfer, but I'm not convinced this doesn't
> mean there isn't corruption in the stream. Does anyone know?
There should be no corruption if the DMA transfer is retried. At least,
not in any of my tests. The orignal retry code did give a corrupt video
stream, but after further tests I discovered that I had to retry the
full frame, not just the buffer that failed. I've no idea why, but it
clearly fixed all the video issues I saw.
> The sort of error counts i'm seeing over 48 hours streaming on 7
> cards is:
>
> dmesg -s 300000|grep 'DMA ERROR'|cut -d \( -f1|sort|uniq -c|sort -n
> 5 ivtv6 warning: ENC DMA ERROR b
> 7 ivtv4 warning: ENC DMA ERROR b
> 9 ivtv5 warning: ENC DMA ERROR b
> 20 ivtv2 warning: ENC DMA ERROR b
> 22 ivtv3 warning: ENC DMA ERROR b
> 23 ivtv1 warning: ENC DMA ERROR b
> 31 ivtv0 warning: ENC DMA ERROR b
>
> ivtv0123 are on one pci bus and 456 on another bus, which may explain
> the distribution of the errors.
Thank you very much for putting in the time and making the crucial
observation regarding DMA transfer size and DMA timeout. Although there
were hints that buffer size mattered, the link was never made this
directly.
I intend to do more testing in the next week, especially relating to the
INITIALIZE_INPUT firmware call: it looks like that code is not yet 100%
solid.
Something to watch out for: a DMA TIMEOUT right after the capture starts
is likely to be related to this call and not any of the DMA transfers.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
