[pvrusb2] Ability to fully reset a PVRUSB2 Device

[Mike Isely]

On Sun, 14 Apr 2019, Diego Rivera wrote:

> Guinea pig #1 ready, sir! 😂
> 
> --
> 
> Diego Rivera
> 

Diego:

Going back over this thread and comparing my recent notes, there's a 
good experiment I'd like you to try:  Get the hardware into a state 
where you get the "Attempted to execute control transfer when device not 
ok" infinite log spew.  Once you've confirmed the scenario again, reboot 
the host and then rename the ir-kbd-i2c.ko module to something which 
disables it.  You can find this module in the following path:

/lib/modules/`uname -r`/krtnrl/drivers/media/i2c/

A good thing to do would be to just add "-disabled" to the end of the 
file name.  Then run "depmod -a" to rebuild the module dependencies 
(should take a few seconds) and now the ir-kbd-i2c module will be 
disabled.  On the off-chance that it has already been loaded, also run 
"modprobe -r ir_kbd_ic2" (or just reboot again).  NOW, run that same 
scenario where you get the log spew as mentioned above.  Is that still 
happening?  Also, if it isn't still happening, does "modprobe -r 
pvrusb2" still get stuck?

The reason I ask is because that's what I am seeing here.  That 
ir-kbd-i2c here is the source of the endless stream of failing I2C 
requests into the pvrusb2 driver.  I want to make sure we're looking at 
the same bug.  I've got roughly 3 misbehaviors on my plate right now.  
This is one of them.

There was an earlier mention of a kernel panic when trying to remove the 
pvrusb2 driver from the system.  While I am seeing kernel oopses from 
this - due to sysfs doing something unexpected - it is not panicing.  
So I have not yet seen that specific problem.  I'd like to know what 
exact kernel was being run (distro / uname -r output / .config would 
help too).

  -Mike

-- 

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