[linux-dvb] [RFC] video-buf redesign
hermann-pitton at arcor.de
Wed Sep 26 22:58:02 CEST 2007
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.
> 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.
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.
More information about the linux-dvb