[linux-dvb] [RFC] video-buf redesign

[hermann pitton]

Hi,

Am Mittwoch, den 26.09.2007, 11:25 -0400 schrieb mkrufky at linuxtv.org: 
> Mauro Carvalho Chehab wrote:
> >> Unfortunately, I see the same broken behavior in the videobuf tree and
> >> the tm6000-new tree.  Only the master branch v4l-dvb tree is
> >> functioning properly.
> >>     
> >
> > Unfortunately, there's nothing I can do without the logs. So, _please_
> > send the logs also.
> >
> > Every test I did here (and also Hermann reports) didn't produce the
> > issues you're showing. 
> >
> > All I get here is clean mpeg streams, with videobuf-dvb and cx88-dvb.
> >
> > There is, however, a known issue with IRQ and SMP machines that might be
> > influencing. So, I need you to do also "cat /proc/cpuinfo". If the
> > machine you're using to test has more than one CPU core, you may also
> > need to run irqbalance. Another valuable test would be to disable the
> > second core, and see what's happening.

I also conducted the tests only on UP machines on the saa7134 driver.

> Mauro,
> 
> It is a dual-core CPU.  This should be irrelevant to the issue, since 
> multi-core CPU's have no problem when using the videobuf code in the 
> master branch -- why would your new videobuf code be dependent on a 
> single core when the original videobuf code was not?
> 
> I had previously sent you logs of this problem while using read() , but 
> you said this was not good enough -- You told me that the logs did not 
> indicate any errors.
> 
> The only way to test this without using read() would be to use xawtv4, 
> which I am not able to build on my Ubuntu Feisty system.  Otherwise, I 
> could try to test by installing mythtv-backend, but that will take a lot 
> of time to setup -- I'll be happy to do it after I've settled in the new 
> apartment, if need be.
> 
> I understand that neither you nor Hermann were able to reproduce this 
> problem, but I assure you, this is indeed a regression, and it's a 
> show-stopper for 2.6.24 -- it absolutely must be fixed prior to a merge.

Yes, I agree then. We should be careful with this small testing base we
have and Mike obviously noticed issues.

> I will not be able to conduct any more tests until after I unpack into 
> my new apartment (next week) -- I will take down this test machine 
> tonight and pack it up in boxes.
> 
> If you still would like to see logs while using read() , then I can do 
> this tonight before I pack up the test machine.  If you want these logs, 
> please let me know asap.

Unfortunately I have not even a DVB-T card currently ...
The Medion Quad I ordered isn't here yet, also unsure if I can get DVB-T
running on it, don't have the original green PCI Slot for it.
Else I considered to get the Asus P7131 Hybrid LNA, since Soeren still
reports issues on it, also memory corruption with the old stuff.
http://linuxtv.org/pipermail/linux-dvb/2007-September/020748.html

This is still the only such report within the last two years.

The only case I know from Hartmut that this could happen, also tested
myself, is if someone uses DVB-T and anlog video at once from external
inputs with planar formats, like mplayer/mencoder does by default and
not packed formats as advised in such case.

Why this happens on his machine with VDR and an additional saa7146
device, I still don't know. We have also no reports for the new
video_buf design from saa7146 users.

Just installed the tm6000-new tree on two machines again and xawtv4
seems to be fine on both, UP, no DVB-T currently, no HD streams.

Cheers,
Hermann