[pvrusb2] 29xxx pvrusb2 device initialization problems

akp2akp2 akp2 at gmx.de
Sat Feb 6 05:54:59 CST 2010


Mike Isely schrieb:

> > 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
> >
> >   
>   
Hello Mike,

just a guess, but did you try to put a USB-Hub WITH own power supply
between laptop and the 29xxx device to rule out bad signal or power by
aging of the USB components of your laptop?

Grettings, Ansgar



More information about the pvrusb2 mailing list