After further testing, I've gotten more clues. This is a very bizarre problem, limited to only 29xxx devices.
I'm convinced now that there is nothing wrong with the pvrusb2 driver. As for the root cause, I'm still not entirely sure. This is going to be hard to explain, but I'm going to lay out as much detail as I can here in the hopes that in the future when someone google-searches for this, the information might be helpful. So this message is going to be rather lengthy.... First, the background info: I have two systems where I test the pvrusb2 driver. One is a 2.66GHz Core2 Quad desktop system (scratch-built system, Asus LGA775-class motherboard), the other is a 1.73GHz (I might have mistakenly said 2.0GHz previously) Core2 Duo laptop (Dell Inspiron E1705). Both have been successfully used in the past for pvrusb2 testing. Both are running *exactly* the same kernel: a Core2-customized build of 2.6.31.9 downloaded from kernel.org (as I always do). The desktop system is running a Debian Stable (Lenny) installation; the laptop system is currently running a Debian Testing (Squeeze) installation. I believe that the last time I tested with the laptop, it was still using Debian Stable at the time (I had recently upgraded it). That fact might be playing a part in this, but I can't prove it. For the pvrusb2 devices, I have 4 samples of the older Hauppauge PVR-USB2. Two are 29xxx series - one is a 29022 device (early model) the other is a 29032 device. The other two are 24xxx series - one is a 24012 and the other is a 24022. (I also have a couple of the newer HVR-1950s, but I haven't tested those yet and expect they will continue to be fine since their design is closer to the 24xxx series than the 29xxx series.) So, attached to the desktop system, each of the 4 test devices initialized perfectly. But on the laptop system, only the 24xxx devices initialize correctly. Both of the older 29xxx series are having problems, getting into trouble after the FX2 firmware has been downloaded. So, now focusing on the problem case(s)... Initializing most pvrusb2-driven devices is a two stage process. For a device which has just been powered up, firmware must first be loaded to its Cypress FX2 microcontroller. Once that firmware has been loaded, the device is supposed to logically disconnect itself from the host, reset, and then reconnect to the host, with the device now running the new firmware. (Then the pvrusb2 driver sees it again and the remaining initialization is carried out.) For the problematic 29xxx cases, what happens is that the firmware gets downloaded just fine, but then there is no further progress. The last useful message in the kernel log (i.e. dmesg output) will be: pvrusb2: Device microcontroller firmware (re)loaded; it should now reset and reconnect. One interesting fact about the these devices is that once the firmware has been loaded correctly and so long as you keep power applied to the device, then it's possible to disconnect the USB cable, connect it back up and the pvrusb2 driver will correctly recognize that the firmware is already present and will therefore skip the 1st stage. So I did that: I yanked the USB cable, then plugged it back in. Effectively I forced a manual disconnect to try to get past the jam. Result? I got this after the reconnect: Feb 5 16:11:41 sheridan kernel: [ 3081.381195] usb 1-7: new high speed USB device using ehci_hcd and address 32 Feb 5 16:11:56 sheridan kernel: [ 3096.483130] usb 1-7: device descriptor read/64, error -110 Feb 5 16:12:11 sheridan kernel: [ 3111.686196] usb 1-7: device descriptor read/64, error -110 Feb 5 16:12:11 sheridan kernel: [ 3111.889195] usb 1-7: new high speed USB device using ehci_hcd and address 33 Feb 5 16:12:26 sheridan kernel: [ 3126.991201] usb 1-7: device descriptor read/64, error -110 Feb 5 16:12:41 sheridan kernel: [ 3142.194224] usb 1-7: device descriptor read/64, error -110 Feb 5 16:12:42 sheridan kernel: [ 3142.397219] usb 1-7: new high speed USB device using ehci_hcd and address 34 Feb 5 16:12:47 sheridan kernel: [ 3147.409276] usb 1-7: device descriptor read/8, error -110 Feb 5 16:12:52 sheridan kernel: [ 3152.521294] usb 1-7: device descriptor read/8, error -110 Feb 5 16:12:52 sheridan kernel: [ 3152.724139] usb 1-7: new high speed USB device using ehci_hcd and address 35 Feb 5 16:12:57 sheridan kernel: [ 3157.736356] usb 1-7: device descriptor read/8, error -110 Feb 5 16:13:02 sheridan kernel: [ 3162.848394] usb 1-7: device descriptor read/8, error -110 Feb 5 16:13:02 sheridan kernel: [ 3162.949213] hub 1-0:1.0: unable to enumerate USB device on port 7 Feb 5 16:13:02 sheridan kernel: [ 3163.190216] usb 5-1: new full speed USB device using uhci_hcd and address 2 Feb 5 16:13:02 sheridan kernel: [ 3163.319286] usb 5-1: not running at top speed; connect to a high speed hub Feb 5 16:13:02 sheridan kernel: [ 3163.335292] usb 5-1: New USB device found, idVendor=2040, idProduct=2900 Feb 5 16:13:02 sheridan kernel: [ 3163.335303] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Feb 5 16:13:02 sheridan kernel: [ 3163.335312] usb 5-1: Product: USB Device Feb 5 16:13:02 sheridan kernel: [ 3163.335317] usb 5-1: Manufacturer: Hauppauge Feb 5 16:13:02 sheridan kernel: [ 3163.335662] usb 5-1: configuration #1 chosen from 1 choice Feb 5 16:13:02 sheridan kernel: [ 3163.338416] pvrusb2: pvr2_hdw_create: hdw=f5498000, type "WinTV PVR USB2 Model 29xxx" Feb 5 16:13:02 sheridan kernel: [ 3163.338424] pvrusb2: Hardware description: WinTV PVR USB2 Model 29xxx (and then normal device initialization completes) So it worked - however the laptop had to downshift the connection to full speed in order for it to work! I have no idea why. But it proves one thing: the FX2 firmware that was loaded in the 1st stage is working. This also does not explain why the device failed to disconnect on its own. And note also that the firmware download in the 1st stage still happened with the connection running in hi-speed mode. So I tried another trick: I cold-powered the device once again using the laptop, waited for it to get stuck again waiting for it to disconnect itself, then I disconnected it and connected it instead to the desktop system. Result? The desktop system saw the device, skipped the 1st stage (i.e. it found the FX2 firmware had been loaded), and then successfully completed device initialization, all in hi-speed mode. That proves that the firmware was loaded correctly and successfully by the laptop. Then I tried the opposite sequence: I cold-powered the device using the desktop system. It initialized all the way, no problem. But then I disconnected it, and while leaving the device powered up, I connected it to the laptop. In other words, I used the desktop to perform the 1st stage of the initialization, leaving the laptop to do the rest of it. Result? It still got stuck there logging USB device descriptor errors, finally downshifted to full speed mode, then initialized successfully - same as the case above where I manually disconnected / reconnected the device on the laptop. For some idiot reason, the 29xxx devices can't seem to operate correctly in hi-speed mode with the laptop test system, once the firmware has been loaded. And it should be pretty clear now that the firmware is in fact being loaded correctly. So I tried one more experiment - something that simply should not have worked. I took a 24xxx firmware image (md5sum: 34d213394328adf78e2fc9f1411691b0) and renamed it as a 29xxx firmware image. This of course will screw things up and last time I tried that (years ago) the 29xxx device never came up properly (i.e. no sign of life). However this time it worked "better": After stage 1, the device successfully disconnected on its own, reconnected (in hi-speed mode) and then the pvrusb2 driver proceeded to initialize it. The initialization ultimately bombed out due to the mismatched hardware, but the fact that communications worked at all (in hi-speed mode!) really has me scratching my head. It's almost as if the older 29xxx firmware is configuring its USB interface in a manner that is somehow incompatible with the laptop. I *suppose* there could be some kind of basic incompatibility with the laptop's USB hardware - however this *did* work in the past. The only change since then is that I'm running Debian Testing (Squeeze) on it now. But it's the identical kernel binary as what is running successfully on the desktop system, and a problem as basic as this really should be a kernel-level not userspace issue. So I am having a hard time theorizing that the userspace update to Debian Testing could somehow be doing this. The obvious next step I guess would be to downgrade the laptop back to Debian Stable. That's also obviously a big destructive step. I think I'll just swap out its hard drive and scratch-install Debian Stable on the new device. I'll follow up with another message once I've done this experiment but it may be a little while before I'll be able to try it. So that's where things stand. Hopefully if you have a 29xxx device that won't survive the stage 1 initialization - and you've confirmed that the firmware image is correctly set up (and the dmesg output isn't complaining that it can't find the FX2 firmware), then maybe you might be getting had by this same problem. Best I can tell right now, whatever the cause is, it has nothing to do with the pvrusb2 driver. Suggestions are welcome. -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
