[linux-dvb] Re: Network: a new hope

[Emard <emard@softhome.net>]

> Sorry, I haven't followed this issue right from the start: Does it occur
> _only_ on budget class cards with the SAA7146A on it? Because I recently

It occurs on my both cards based on 7146A. One is real budget card of
early type (technotrend, sold as "satelco"), another is dvb-s v1.3 
(technotrend) with some modifications of my own (fan on demodulator
and budget-patch).

> investigated budget DMA issues with the SAA7146A and found that it tends to
> not properly fulfill DMA requests - depending on configuration, it can
> randomly not transfer Dwords within the data stream (but will advance the
> pointer).
> 
> The resulting stream can actually look perfectly ok according to the MPEG-2
> headers (no continuity count errors), but the actual packet contents will
> be corrupted.

INTERESTING! I dindn't expect that the DMA corruption would exist and be so 
subtle and not visible by mplayer. But if it's only DMA issue and not
software demux, then it would be much easier to get working I think!

> If this is indeed an SAA7146A/budet issue and you're willing to invest some
> time into this, you should start by modifying the budget DMA code so that
> it pre-initializes each buffer before it is DMA'd to with a certain DWORD
> pattern, and after the DMA checks whether the pattern is still found
> anywhere in the buffer (of course, any pattern can always appear in the
> real data, but a wisely chosen pattern would only show up once in a blue
> moon, and you can tell by the frequency whether it is real data or DMA
> corruption)...

So if it's DMA issue again, I should see certain DWORDs (32-bits, 'even' address 
aligned 4-byte ?) inside of the DMA buffer not being properly overwritten by 
DMA pass?? hemm. Let's do this: after DMA, I can fill it with random data and 
check if random data remains after DMA pass. It will be very unlikely for that 
to happen if DMA is working properly and would directly indicate the DMA "bug" 
(actually temporarily overloaded PCI glitch, attempting to still do some synchronous 
transfer while the timing is running out and the 7146 given its small output
buffer has no better choice than to skip something, here the tuning of the pci 
latency and 7146 parameters like dma burst, TS Height/Width could well fix this).

I think that for my machine, I resolved this but it's always good to
make sure again.



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.