[pvrusb2] Ability to fully reset a PVRUSB2 Device

[Mike Isely]

Nope.  The problem still happens.  It has to be a race condition 
probably influenced by turning on all that trace print.

This is actually all good stuff.  There's a lot of good leads to chase 
down here.

  -Mike


On Sat, 21 Sep 2019, Mike Isely wrote:

> 
> 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
> _______________________________________________
> 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