[pvrusb2] pvrusb2 device hardware appears to be jammed and I can't clear it.

[Mike Isely]

On Mon, 29 Jun 2009, Kondratev A.S. wrote:

> When I connect tv tuner dmesg writes.
> pvrusb2: Failed to submit write-control URB status=-22
> pvrusb2: Device being rendered inoperable
> pvrusb2: ***WARNING*** pvrusb2 device hardware appears to be jammed and I
> can't clear it.
> pvrusb2: You might need to power cycle the pvrusb2 device in order to
> recover.
> usbcore: registered new interface driver pvrusb2
> pvrusb2: 20090616 (from www.isely.net):Hauppauge WinTV-PVR-USB2 MPEG2
> Encoder/Tuner
> pvrusb2: Debug mask is 31 (0x1f)
> 
> Tv Tuner - GoTView USB2 DVD
> 
> What should I do?


The failure code (-22) is EINVAL, which usually indicates passing of a 
bad parameter into the function which failed.  However the code where 
you got the error has been essentially unchanged for at least 2 years 
and it is common to all uses of the pvrusb2 driver (i.e. not specific to 
Gotview).  This is leaving me quite puzzled - I would have expected an 
EIO (-5) or EPROTO (-71) error if there was a true hardware failure.  
But it is probably still too early to rule out squirrely hardware.

I saw your other reply to Roger's suggestion, and the 2.6.27 kernel 
should work just fine with the latest standalone driver.  This is in 
fact one of the combinations that I currently routinely test.

The text above suggests you were running a standalone pvrusb2 driver.  
Can you instead try the one that is already a part of the kernel you are 
using?  Gotview support was added quite a while ago and what is in 
2.6.27 should still be good enough for that hardware.  (Even if running 
the in-kernel driver solves this, that isn't a real fix since we really 
therefore need to figure out what might have changed in the standalone 
driver - especially since "today's" standalone driver will be 
"tomorrow's" in-kernel driver...)

You only pasted a portion of the total output - did this failure occur 
as part of when the driver tried to initialize the hardware for the 
first time or after you tried to use it?  (I'm guessing this is at 
initialization but it is important to be sure.)

IIRC, that device does not require externally loaded FX2 firmware, so 
firmware foul-ups should not be able to do this.

Other suggestions here:

1. Power cycle the device - though I'm sure you've already done that 
numerous times.

2. Try a different USB cable and/or different USB ports or (if possible) 
a different USB controller.  This is all under the assumption that there 
might be a problem communicating with the device, due to marginal USB 
hardware...  Do you have another USB 2.0 high speed device that works on 
that same port + cable?

3. Can you run the device successfully on a different computer?

4. Can you run the device successfully under (ugh..) Windows?

5. There are additional driver debug flags we can turn on which will 
probably help.  But it will help first to understand the circumstances 
of the failure first (e.g. initialization time or when running) before 
we can know which are the best flags to enable.

  -Mike



-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8