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

_______________________________________________
pvrusb2 mailing list
[email protected]
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Reply via email to