[pvrusb2] 29xxx pvrusb2 device initialization problems

Fri Feb 5 17:09:42 CST 2010

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