Thanks. What you are illustrating is at least two problems. The log spew is definitely not the same issue as the hang-on-remove.
I'm also looking at what is going on in sysfs when the device is hot-unplugged. In that case I'm getting a kernel oops for each sysfs control (/sys/class/pvrusb2/sn-xxxxx/ctl_*) being removed. Looks like something else is removing these controls in a race with the driver. This might be a kobject reference count issue. -Mike On Sun, 22 Sep 2019, Diego Rivera wrote: > Test carried out. If I disable the ir-kbd-i2c module, everything appears to > boot up well enough, and the " Attempted to execute control transfer when > device not ok" spam is no more!! So that's the good news. > > The bad news is that modprobe -r pvrusb2 doesn't succeed either - it just > hangs there. > > This is my Kernel version (on Ubuntu 19.04): 5.0.0-29-generic. It's the > default OOTB (latest update) kernel. I've attached the configuration as > requested. > > The scenario isn't 100% reproducible, but the way I usually do it is either > by rmmod/modprobe -r, hot-unplug/replug, or power off one of the devices > while connected, and powering it back on (this seems to be the most > frequent scenario, due to power spikes/fluctiations, etc). > > For this test, I just did the modprobe -r. I'll test the other two > scenarios and report back shortly. > > Cheers! > > -- > *Diego Rivera* > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Sun, Sep 22, 2019 at 12:42 PM Mike Isely <[email protected]> wrote: > > > On Sun, 22 Sep 2019, Mike Isely wrote: > > > > > > > > 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/ > > > > Typo correction: > > > > /lib/modules/`uname -r`/kernel/drivers/media/i2c/ > > > > (fingers in wrong position on keyboard, apparently) > > > > > > > > > > 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 > > > > > > > -- > > > > 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 > > > -- 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
