> 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
