On Saturday 26 November 2005 07:30, Geoffrey Kruse wrote:
> > > Hallo Hans!
> > >
> > >> I've started work on this problem yesterday. I discovered that
> > >> the MPEG data is placed at the correct memory location so the
> > >> shift happens either in the DMA handling (most likely) or in the
> > >> internal buffer handling of the driver. I can easily reproduce
> > >> it, so that helps a lot. I hope I can find the cause quickly. I
> > >> have several ideas, but it needs more debugging and tracing.
> > >
> > > Did you find the cause for the bug mentioned above? I don't want
> > > to rush, I'm just a bit curious...
> >
> > I'm slowly closing in on it. It's not as easy to reproduce as I
> > thought so
> > it is slow going. The bug is probably in the dma_from_device()
> > function in
> > ivtv-irq.c and is probably related to somehow incorrect handling of
> > a DMA
> > error. I have to wait for it to happen again before I can be more
> > certain.
> >
> > Hans
>
> I see this problem on every single recording on my pvr 500. Please
> let me know if there is anything I can do to help debug this since it
> is so easy for me to reproduce.
Can you do the following for me: edit ivtv-irq.c, go to the function
dma_from_device(), go to the end of the function and add a IVTV_INFO
line just before the 'goto redo_dma;' line:
spin_unlock_irqrestore(&itv->DMA_slock, flags);
if (redo_dma < 3) {
redo_dma++;
IVTV_INFO("redma %lx\n", redo_dma);
goto redo_dma;
}
IVTV_DEBUG_WARN(
"ENC: REDO DMA took too many tries.\n");
ret = -ENOMEM;
}
return ret;
}
Whenever things go wrong I always see a 'redma' line in the log. So it
is clearly related to a DMA error that the firmware does not correctly
recover from. Do you see the same message?
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
