On Thu, Mar 18, 2010 at 11:07 AM, Marco Lohse <mlohse@xxxxxxxxxx> wrote: > Devin Heitmueller wrote: >> On Thu, Mar 18, 2010 at 6:00 AM, Andreas Besse <besse@xxxxxxxxxx> wrote: >>> Hello, >>> >>> We are now able to reproduce the problem faster and easier (using the >>> patched version of szap-s2 and the scripts included in the tar.gz : >>> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17334 >>> and >>> http://cache.gmane.org//gmane/linux/drivers/video-input-infrastructure/17334-001.bin >>> ) >> >> This is pretty interesting. I'm doing some ngene work over the next >> few weeks, so I will see if I can reproduce the behavior you are >> seeing here. >> >> I noticed that you are manually setting the "one_adapter=0" modprobe >> setting. Does this have any bearing on the test results? >> > > I will try to answer this one: > > No, leaving out this parameter does not change the test results; you > will only need to use different and additional parameters for szap-s2 > for specifying the correct adapter and sub-devices. > > By now, we also found out that the problems can be reproduced much easier: > > 0) > > szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | > grep Delay > > Delay : 0.573021 > > 1) > > szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -x | > grep Delay > Delay : 0.564667 > > 2) > > szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | > grep Delay > Delay : 1.741931 > > Instead of 2) you can also run the included script > > 2') > > ./run_szap-s2_adapter0.sh > > which will result in the device timeout after 30-40 iterations > > To summarize > > => When opening and closing adapter0, then opening and closing devices > of adapter1, this will immediately result in problems. > > And there a lot more variations of this bug, for example: actually read > data from adapter0, tune adapter1 using szap-s2, which will result in > adapter0 to be 'blocked' and not produce any more data after around 60 secs. > > We are currently trying to dig into the source code of the driver to > solve the problems and would appreciate any help. Hi Marco, Ok, great. Like I said, I will see if I can reproduce it here, as that will help narrow down whether it's really an issue with the ngene bridge, or whether it's got something to do with that particular bridge/demod/tuner combination. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
