[pvrusb2] 29xxx pvrusb2 device initialization problems

[Roger]

> , 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.isely.net/pipermail/pvrusb2/attachments/20100205/d1d3cf8a/attachment-0001.pgp>