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