[pvrusb2] Ability to fully reset a PVRUSB2 Device

[Mike Isely]

I did something really simple: I ran modprobe -r ir_kbd_i2c then renamed 
the .ko file so it would not get loaded anymore.  That appears to have 
put a stop to the infinite loop behavior.  It is not a solution but a 
large clue.  With that change I just hotplugged then hot-unplugged the 
hardware and THIS TIME it did not oops.  But I don't believe it.  I'm 
trying another build right now with my trace print removed - going back 
to the original scenario just to be sure that this is or is not related.

Along the way I ran into another bad scenario, "modprobe -r pvrusb2" 
after powering off the hardware seems to permanently jam.  That's not 
supposed to happen at all.

I'm keeping a list...

  -Mike


On Sat, 21 Sep 2019, Diego Rivera wrote:

> This is good news! Any progress is good progress! Perhaps disabling that
> bit somehow can provide a workaround? Maybe the whole I2C IR stack can be
> disabled system-wide? My box doesn't use that, so...?
> 
> Cheers!
> 
> --
> 
> Diego Rivera
> 
> On Sat, Sep 21, 2019, 19:30 Mike Isely <isely at isely.net> wrote:
> 
> > On Sat, 21 Sep 2019, Diego Rivera wrote:
> >
> > > Thanks for the update!
> > > It occurred to me: what if for #3, instead of the driver not handling
> > the error, it's simply
> > > expecting a different/new (type of) error to be raised in order to go
> > through a code path that leads
> > > to it not getting borked? Bah ... I'm sure you've thought of this ☺
> > > Cheers!
> >
> > Well anything is possible.  However EIO is generally understood to mean
> > "I/O error" which in fact this is.
> >
> > I just added a dump_stack() call after detecting the error, and the
> > guilty component is the I2C IR chip-level driver (the thing that watches
> > the IR port and figures out what buttons you press on the remote).
> > It's coming from a call to get_key_haup_common() which is in
> > ir-kbd-i2c.c. That code is not written with any loop, but it pretty
> > clearly itself returns -EIO to its caller if the I2C transfer attempt
> > fails (for any reason).  The caller can only be get_key_haup() but it
> > looks like the compiler optimized that away so it isn't showing up in
> > the stack trace.  Stack frames above that point "look" like it might be
> > coming from userspace, so - on the Ubuntu system where I'm playing with
> > this, a userspace IR daemon might be in play here.  It might be the
> > thing pounding on the pvrusb2 driver - in this scenario.
> >
> > I'm not familiar with that i2c kbd driver but there are a lot of avenues
> > to look at here.  For example, I can probably disable away that whole
> > thing so I can turn my attention to #1.  I also have several different
> > pvrusb2 devices here and they each have different IR designs which may
> > cause different upstream behavior.  Like I said, a number of avenues
> > here.
> >
> >   -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
> >
> _______________________________________________
> 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