> , 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.
I've seen this *exact* scenario -- and it's a direct conflict of lirc trying to communicate on the bus. Once a conflict occurs, all further transmissions cease. As to whether or not I've seen this with the older 2900, I'm not sure. Grepping the mailing list for lirc and my posts will show -- it was likely with the HVR-1950 I now use. So, I just uninstalled lirc completely due to "it's not worth the problem vs. amount of time I actually spend using IR" -- which is slim to none here as I don't lay in bed watching prerecorded stuff -- much at all! > 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: yup. lirc is finicky. One other note, when 2.30 first rolled-out, e100 (nic) driver got a complete face-lift (mainly focusing on firmware functions. Only problem, testing the new code was only a later consideration as the patches completely broke nic functions at first, then hibernate, etc... My concern is the quality of kernel code these days, so many untested patches breaking older stable code. <shrugs> (Whether or not it's their intent to force people into buying newer h/w once the code can't be maintained anymore, or gets so broken, dunno.) Mplayer XvMC feature was broken for awhile, but now recently fixed in cvs/svn ffmpeg code base. But I got so tired of Nvidia drivers requiring a broken nvidia-settings dependency here, I gave up and reverted to framebuffer and/or DWM. ;-) > 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. One possibility I have thought of, if you find it is being caused by lirc, lirc modules or lirc might be trying to communicate at the same time on the i2c bus, or *something*. You're the expert, and I can only guess at this point. > 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. You can be a little more blunt with us here and just say, "Some dummy broke the kernel code!" ;-) Remove lirc and all it's kernel modules... might have even better success. Took me several weeks to figure this out too. -- Roger http://rogerx.freeshell.org
signature.asc
Description: This is a digitally signed message part
_______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
