Hi,
Am Mittwoch, den 26.09.2007, 11:25 -0400 schrieb [EMAIL PROTECTED]:
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
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
