Hans Verkuil wrote:
> > On Wednesday 25 July 2007 17:43:01 Mark Bryars wrote:
> >
>
>> >> Mark Bryars wrote:
>> >>
>>
>>> >>> Doing a bit of research into this, the last lockup I had was after
>>> >>> a 0x1C000 byte size DMA transfer, thats pretty big compared to the
>>> >>> usual ones
>>> >>>
>>> >>> After a bit of sampling I see DMA size distribution to be mainly in
>>> >>> the 0x2800 to 0x8000 region, a few crashes i provoked by setting
>>> >>> the latency down to 1, had transfers set up just beforehand that
>>> >>> were bigger than this: 0x8800, 0x12000, 0xE000, 0xA000
>>> >>>
>>> >>> I was looking at the code to see if it would be possible to
>>> >>> fallback to a PIO mode transfer for larger than 0x8000 sized
>>> >>> transfers. Would this be possible to do easily? Or how about
>>> >>> multiple smaller DMA transfers?
>>> >>>
>>>
>> >> Further to this, I added a very simple size cap on dma transfers, to
>> >> only get the first 32k of data, and although, of course, the stream
>> >> was corrupted (not as much as you might expect), even setting the pci
>> >> latency to 1, I did not provoke any DMA TIMEOUT crashes (although its
>> >> a currently brief test). I upped the limit to 128k as this would get
>> >> apparently everything, and 5 cards locked up in about a minute. I
>> >> really feel the dropping to PIO(or multiple smaller DMA) for >32k
>> >> transfers could be the solution we are waiting for.
>> >>
>>
> >
> > Have you tried changing this:
> >
> > itv->stream_buf_size[IVTV_ENC_STREAM_TYPE_MPG] = 0x08000;
> >
> > to this:
> >
> > itv->stream_buf_size[IVTV_ENC_STREAM_TYPE_MPG] = 0x10000;
> >
> > in ivtv-driver.c? Does this also trigger lockups?
> >
> > This change prevents scatter-gather DMA, just in case that is the cause.
> >
>
I don't really understand how this would change the DMA operation, but I
did see that this is a funny coincidence that sizes > 0x08000 are
locking up. My debug traces showed the card would under normal
conditions request transfers up to 0x20000, so I upped this figure to
0x20000 so the buffer matches the size of the request... Seems to make
sense to me. And I added the conditional cap to stop transfers bigger
than this, like i did before with the 0x8000 limit... and Hey Presto NO
lockups (so far this morning)! I set the pci latency down to 1, to
provoke them, and get this, although I did get DMA TIMEOUT 's, they were
genuine timeouts from the increased load, and the cards didn't lock up
after the timeout, they kept operating!
However, I am seeing an increase in the number of 'ENC DMA ERROR b'
messages.... Not so fatal tho, but not ideal.
>> >> I have also seen some really large dma transfers try to take place,
>> >> (>1Meg) the logging is lost so I do not know if they were successful.
>> >> If this is important I can reproduce.
>> >>
>>
> >
> > 1 MB? That's dubious. The largest transfer should be of an I-Frame,
> > which you can compare to a jpeg of a single PAL frame. Should
> > definitely be less than 1 MB. Could be a knock-on effect of a DMA
> > engine breakdown.
> >
>
It appears that my parsing dmesg meant that once the buffer scrolled, i
would be parsing half lines, so that wasnt the size, but the address, so
that was a red herring.
Regards,
Mark Bryars
Sorry its not a proper patch, but i've got looads of other debugging
stuff added that i've hand hacked out, so it might not apply.
--- linux-2.6.22.1/drivers/media/video/ivtv/ivtv-driver.c
2007-07-10 19:56:30.000000000 +0100
+++ linux-2.6.22.1.dmapatch/drivers/media/video/ivtv/ivtv-driver.c
2007-07-26 13:16:54.246894256 +0100
@@ -1108,7 +1116,7 @@
}
itv->params.video_gop_size = itv->is_60hz ? 15 : 12;
- itv->stream_buf_size[IVTV_ENC_STREAM_TYPE_MPG] = 0x08000;
+ itv->stream_buf_size[IVTV_ENC_STREAM_TYPE_MPG] = 0x20000;
itv->stream_buf_size[IVTV_ENC_STREAM_TYPE_PCM] = 0x01200;
itv->stream_buf_size[IVTV_DEC_STREAM_TYPE_MPG] = 0x10000;
diff -urN linux-2.6.22.1/drivers/media/video/ivtv/ivtv-irq.c
linux-2.6.22.1.dmapatch/drivers/media/video/ivtv/ivtv-irq.c
--- linux-2.6.22.1/drivers/media/video/ivtv/ivtv-irq.c 2007-07-10
19:56:30.000000000 +0100
+++ linux-2.6.22.1.dmapatch/drivers/media/video/ivtv/ivtv-irq.c
2007-07-26 13:27:56.282249584 +0100
@@ -124,6 +124,11 @@
offset = data[1];
size = data[2];
s->dma_pts = 0;
+
+ if (size>0x20000) {
+ IVTV_WARN("Warning: Large transfer
requested 0x%08x (truncating)\n",size);
+ size=0x20000;
+ }
-- Mark Bryars Product Development Engineer ETV Interactive Ltd Logie
Court Stirling University Innovation Park Stirling Scotland, UK FK9 4NF
T: +44 (0) 1786 455150 F: +44 (0) 1786 455179 W: www.etvinteractive.com
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
