> What does "cat /proc/interrupts" show? I'm confused is the spamming instance I2C host controller, intel-gpio or what. > > My quick guess would be misconfigured GPIO interrupt from touchpad that goes active once touchpad is initialized over I2C and i2c_hid driver > initializes the irq. But what I failed to understand why it keeps coming after battery removal and reverting to old kernel where I2C communication with the touchpad wasn't working. I probably should have also mentioned that I tried disabling the trackpad in the BIOS, as there was an option to do so. In spite of that, the intel-gpio i2c interrupts continued to drive the CPU cores to 100%. Don't know if that information sheds light on anything, but I thought I'd throw it out there. On Tue, May 22, 2018 at 7:52 AM, wereturtle <wereturtledev@xxxxxxxxx> wrote: >> What does "cat /proc/interrupts" show? I'm confused is the spamming instance I2C host controller, intel-gpio or what. >> >> My quick guess would be misconfigured GPIO interrupt from touchpad that goes active once touchpad is initialized over I2C and i2c_hid driver > initializes the irq. But what I failed to understand why it keeps coming after battery removal and reverting to old kernel where I2C communication with the touchpad wasn't working. > > I don't have the laptop with me any more (I returned it to Best Buy > before it's return window ran out, since it seemed bricked). However, > /proc/interrupts was showing a disturbingly high number of interrupts > for the intel-gpio for i2c. I am actually wondering if the interrupts > were there all along, but at a lower rate before I applied the patch, > such that I did not notice any adverse effects to the CPU cores. > > On Tue, May 22, 2018 at 4:05 AM, Jarkko Nikula > <jarkko.nikula@xxxxxxxxxxxxxxx> wrote: >> On 05/22/2018 10:29 AM, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 22-05-18 01:58, wereturtle wrote: >>>> >>>> >>>> If I theoretically ran into the into the issue with the i2c interrupts >>>> driving my CPU cores up to 100% once again in the future, what could I >>>> do to work around it? Would blacklisting the i2c-designware driver >>>> fix that? Would that have negative side effects for other things? Is >>>> there a kernel parameter to make the gpio i2c not send so many >>>> interrupts? >>> >>> >>> Blacklisting the i2c-designware driver should do the trick. >>> >> What does "cat /proc/interrupts" show? I'm confused is the spamming instance >> I2C host controller, intel-gpio or what. >> >> My quick guess would be misconfigured GPIO interrupt from touchpad that goes >> active once touchpad is initialized over I2C and i2c_hid driver initializes >> the irq. But what I failed to understand why it keeps coming after battery >> removal and reverting to old kernel where I2C communication with the >> touchpad wasn't working. >> >> -- >> Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
