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. Have fun, Marco -- 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