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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
