[pvrusb2] 29xxx pvrusb2 device initialization problems
isely at isely.net
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
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 126.96.36.199
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
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
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
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.
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2