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