Looks good to me in ubuntu gutsy (2.6.22). I'll boot into my opensuse (2.6.19) at some point and check it out there. That system is much better set up for monitoring the errors. I'll post my results in the mailing list.
On Fri, 2007-07-27 at 12:00 +0200, [EMAIL PROTECTED] wrote: > Send ivtv-devel mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ivtv-devel digest..." > > > Today's Topics: > > 1. Re: Trying to recover from DMA TIMEOUT lockup. - Large DMA > transfers to blame? - A Potential Fix! (Mark Bryars) > 2. Re: Trying to recover from DMA TIMEOUT lockup. (larry.bernstone) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 Jul 2007 14:31:51 +0100 > From: Mark Bryars <[EMAIL PROTECTED]> > Subject: Re: [ivtv-devel] Trying to recover from DMA TIMEOUT lockup. - > Large DMA transfers to blame? - A Potential Fix! > To: Discussion list for development of the IVTV driver > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > 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 > > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Jul 2007 18:23:23 -0600 > From: "larry.bernstone" <[EMAIL PROTECTED]> > Subject: Re: [ivtv-devel] Trying to recover from DMA TIMEOUT lockup. > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > Mark, > It is very cool that you are looking into this. If you need a guinea > pig for this stuff, I am willing to test any fixes you may come up with > on my machine. It is a nForce4 motherboard with an AMD Turion. I'm not > much of a coder, but I am a pretty decent sysadmin, and can give you > debug logs. > > > > > ------------------------------ > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > > End of ivtv-devel Digest, Vol 23, Issue 27 > ****************************************** _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
