[pvrusb2] Ability to fully reset a PVRUSB2 Device

[Diego Rivera]

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 <isely at isely.net> 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
> > pvrusb2 at isely.net
> > 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
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-5.0.0-29-generic
Type: application/octet-stream
Size: 224406 bytes
Desc: not available
URL: <http://www.isely.net/pipermail/pvrusb2/attachments/20190922/691e8bff/attachment-0001.obj>