Hi, Am Mittwoch, den 26.09.2007, 11:25 -0400 schrieb mkrufky@xxxxxxxxxxx: > 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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
