On Wed, 3 Feb 2010, Mike Isely wrote: > > I have just discovered a likely serious problem with 29xxx device > support. > > I would very much appreciate it if anyone on this list using a 29xxx > device (if there are any!) would please e-mail me. I am particularly > interesting in knowing which exact model you are running, what kernel > version you are using, and if you've installed any out-of-tree v4l > drivers and/or the standalone pvrusb2 driver. Knowing this information > will help me to zero in on the problem. Thanks! > > At the moment I am totally puzzled over this. >
Wow. This just gets stranger still. Here's what is happening: Normally when a new pvrusb2-driven device is powered up, the pvrusb2 driver probes it, detects that the FX2 firmware needs to be loaded, loads it, the device disconnects, reconnects, the pvrusb2 driver probes it again, passes the FX2 firmware check and then it initializes the rest of the way. I have 4 of the older PVR-USB2 devices here. Two are 24xxx type, and two are 29xxx type. With 24xxx devices, the above is working fine, as usual. On one test system here, the above is NOT working with either of my 29xxx devices. What happens instead is that the pvrusb2 driver probes it, detects that the FX2 firmware needs to be loaded, loads it, and then everything stops. The device fails to disconnect. Normally I'd chalk that up to being corrupted firmware, however the disconnect action happens _before_ the new firmware takes effect. See, the disconnect is a precursor to a device reset, after which point the new firmware starts running. This disconnect / reconnect action is part of the FX2 silicon, outside of the influence of whatever firmware might be loaded. So bad firmware shouldn't be able to do this - it should AT LEAST disconnect and then fail. Nevertheless I md5sum'ed the firmware on the test system and it's correct. Enabling debug printk's in the driver also shows that nothing went awry during the FX2 firmware download. So here's where it gets wierd: I just tried the same experiment on another machine here. That other machine is running the _exact_ same kernel binary image (built from vanilla 2.6.31.9) as the failing case. Yet the 29xxx device initializes correctly there! I've used both of these machines in the past to test the pvrusb2 driver, so there's nothing wrong with the hardware. The failing setup is a Core2 Duo laptop running at 2.0 GHz, and it's never had a problem before. The working setup is a Core2 Quad desktop system running at 2.66 GHz. Both are running in 32 bit mode. Software-wise they're both Debian systems, however the failing system is running Debian Testing while the working system is running Debian stable - but I'm completely perplexed by that since the symptoms I am seeing suggest a problem at the kernel level. If anyone here using a 29xxx device can add any datapoint(s), it would probably be helpful. This smells like it's going to be a very bizarre bug chase. I probably can't just ignore the failing setup since I'm _sure_ that somebody else is going to hit this... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
