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
