> Blacklisting the i2c-designware driver should do the trick. OK, thanks! On Tue, May 22, 2018 at 12:29 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > On 22-05-18 01:58, wereturtle wrote: >> >> By the way, >> >>> If this indeed is an Intel system one thing worth trying is >>> changing the clk_freq we use in the i2c-designware driver to >>> calculate clk high and low counts. There are some reports from >>> people attaching scopes to the i2c wires that on kabylake at >>> least the driver is driving the bus about 1.5 times the >>> expected rate (so 600KHz instead of 400KHz). >> >> >> 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. > > Regards, > > Hans > > > > >> >> I just want to make sure a kernel update in the future does not brick >> the laptop, as by the time the patch officially arrives in my distro I >> would be well outside my return window with Best Buy. (I'm not >> discounting Jarkko's ability to make a smooth patch, but this is for a >> doomsday scenario.) >> >> Thanks! >> >> On Mon, May 21, 2018 at 12:56 PM, wereturtle <wereturtledev@xxxxxxxxx> >> wrote: >>>> >>>> I would expect 4.18 given that 4.17 is more or less a done deal, but >>>> once the patch is out I expect it to also be cherry-picked as a bug-fix >>>> to the stable releases of older kernels. >>> >>> >>> Sounds great! Thanks, Hans! And thank you, to all of you! >>> >>> On Mon, May 21, 2018 at 11:12 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> On 21-05-18 19:02, wereturtle wrote: >>>>> >>>>> >>>>> Hi Hans, >>>>> >>>>>> Have you tried turning off the computer and removing the battery, >>>>>> then wait 5 minutes and put the battery back again? >>>>> >>>>> >>>>> >>>>> OK, I had to run to the store to get the right size Torx screwdriver, >>>>> but I removed the battery and waited 15 minutes before putting it back >>>>> in. Unfortunately, that didn't help. >>>>> >>>>>> Likely having the touchpad properly working results in either the >>>>>> touchpad >>>>>> or the i2c controller firing an interrupt at boot because of state >>>>>> left >>>>>> over from the previous boot with working touchpad. Since you now lack >>>>>> a working driver, nothing acks the interrupt and it keeps firing. >>>>> >>>>> >>>>> >>>>> Interesting! Thanks for teaching me! >>>>> >>>>>> The proper solution here would be to build 4.15 with the fix, or >>>>>> see if there are some patches to the nvidia driver to make it build >>>>>> with 4.17, which avoids the need for another kernel build. >>>>> >>>>> >>>>> >>>>> Alas, I've had too much difficulty with the latter solutions. 4.17 >>>>> vanilla (no patch) seems to ack it already. 4.15 would need something >>>>> else to ack it in the first place, and I'm not sure where to patch >>>>> that. I couldn't find any Nvidia patches for 4.17. >>>>> >>>>> Fortunately, Best Buy let me return the laptop without any fuss. They >>>>> were even offering to exchange it. I declined, but I might try again >>>>> and live without the touchpad for a time since the laptop just went on >>>>> sale this morning. >>>>> >>>>> As such, when, roughly, do you think the official patch will land? >>>>> Kernel 4.17 or 4.18? (Supposedly Ubuntu 18.10 will have 4.18, if the >>>>> stars align.) >>>> >>>> >>>> >>>> I would expect 4.18 given that 4.17 is more or less a done deal, but >>>> once the patch is out I expect it to also be cherry-picked as a bug-fix >>>> to the stable releases of older kernels. >>>> >>>> Jarkko, I did not see an official patch for this yet, I'm not on the >>>> list though, so I don't know if was not posted at all, or if you did >>>> not Cc me? (not Cc-ing me is fine I'm only sideways involved). >>>> >>>> Regards, >>>> >>>> Hans >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Thanks! >>>>> >>>>> On Sun, May 20, 2018 at 3:13 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> On 20-05-18 04:34, wereturtle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Some bad news to follow up the good news. >>>>>>> >>>>>>> Installing the patched Kernel for my touchpad had a negative side >>>>>>> effect. While running the patched Kernel, I didn't have any issues. >>>>>>> However, I couldn't get the Nvidia driver to install with this >>>>>>> Kernel. >>>>>>> As such, I tried rebooting into my old 4.15 Kernel. Even after >>>>>>> removing the patched Kernel and reinstalling the Nvidia driver >>>>>>> several >>>>>>> times for 4.15, my computer became sluggish during browsing, typing, >>>>>>> etc. Games were locking up or else having a huge framerate drop. My >>>>>>> CPU cores were spinning like crazy without even any processes taking >>>>>>> up CPU. >>>>>>> >>>>>>> Further investigation revealed a an "unexpected IRQ trap at vector >>>>>>> 9a" >>>>>>> error message at startup and shutdown in the console. The message >>>>>>> fires constantly. Under /proc/interrupts, it was listing intel-gpio >>>>>>> (i2c) for 9a. It was firing off like crazy. I think that's for my >>>>>>> touchpad? >>>>>>> >>>>>>> I tried reinstalling Kubuntu altogether, twice, and it wouldn't stop. >>>>>>> It's like that patch permanently wrote something to my hardware? I >>>>>>> tried installing 4.17 RC5 with Ukuu without the touchpad patch built >>>>>>> in. The intel-gpio interrupts went away, and the computer is snappy >>>>>>> and responsive again. However, rebooting back into 4.15 resulted in >>>>>>> the interrupts returning. >>>>>>> >>>>>>> How did this patch end up doing something permanently to my computer, >>>>>>> and what can I do to undo it for Kernel 4.15 so that I can use my >>>>>>> Nvidia drivers again? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Have you tried turning off the computer and removing the battery, >>>>>> then wait 5 minutes and put the battery back again? >>>>>> >>>>>> Likely having the touchpad properly working results in either the >>>>>> touchpad >>>>>> or the i2c controller firing an interrupt at boot because of state >>>>>> left >>>>>> over from the previous boot with working touchpad. Since you now lack >>>>>> a working driver, nothing acks the interrupt and it keeps firing. >>>>>> >>>>>> The proper solution here would be to build 4.15 with the fix, or >>>>>> see if there are some patches to the nvidia driver to make it build >>>>>> with 4.17, which avoids the need for another kernel build. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Hans >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Also, I don't notice this same sluggishness with Windows 10. Windows >>>>>>> is snappy regardless of the Kernel. >>>>>>> >>>>>>> On Sat, May 19, 2018 at 12:42 PM, wereturtle >>>>>>> <wereturtledev@xxxxxxxxx> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi everyone! >>>>>>>> >>>>>>>> I set the clk_rate to be 216000000 in my own patched Kernel 4.17. RC >>>>>>>> 5, and my touchpad now works! >>>>>>>> >>>>>>>> Thank you so much! >>>>>>>> >>>>>>>> On Fri, May 18, 2018 at 12:39 AM, Hans de Goede >>>>>>>> <hdegoede@xxxxxxxxxx> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 18-05-18 09:32, Hans de Goede wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 17-05-18 20:14, Dmitry Torokhov wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, May 17, 2018 at 2:36 AM, Benjamin Tissoires >>>>>>>>>>> <benjamin.tissoires@xxxxxxxxx> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Scope (_SB.PCI0.I2C1) >>>>>>>>>>>> { >>>>>>>>>>>> Device (ETPD) >>>>>>>>>>>> { >>>>>>>>>>>> Name (SBFB, ResourceTemplate () >>>>>>>>>>>> { >>>>>>>>>>>> I2cSerialBusV2 (0x004C, ControllerInitiated, >>>>>>>>>>>> 0x00061A80, >>>>>>>>>>>> AddressingMode7Bit, "\\_SB.PCI0.I2C1", >>>>>>>>>>>> 0x00, ResourceConsumer, _Y34, Exclusive, >>>>>>>>>>>> ) >>>>>>>>>>>> }) >>>>>>>>>>>> Name (SBFI, ResourceTemplate () >>>>>>>>>>>> { >>>>>>>>>>>> Interrupt (ResourceConsumer, Level, >>>>>>>>>>>> ActiveHigh, >>>>>>>>>>>> Exclusive, ,, ) >>>>>>>>>>>> { >>>>>>>>>>>> 0x0000005F, >>>>>>>>>>>> } >>>>>>>>>>>> }) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So nothing scary, the interrupt is a plain interrupt, not a >>>>>>>>>>>> GPIO. I >>>>>>>>>>>> guess the issue lies in i2c-designware and the AMD >>>>>>>>>>>> implementation... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also, in dmesg we have: >>>>>>>>>>> >>>>>>>>>>> [ 25.020612] cannonlake-pinctrl INT3450:00: pin 26 cannot be >>>>>>>>>>> used >>>>>>>>>>> as >>>>>>>>>>> IRQ >>>>>>>>>>> [ 25.020615] genirq: Setting trigger mode 3 for irq 137 failed >>>>>>>>>>> (intel_gpio_irq_type+0x0/0x140) >>>>>>>>>>> [ 25.023113] intel-lpss 0000:00:15.1: enabling device (0000 -> >>>>>>>>>>> 0002) >>>>>>>>>>> [ 25.023336] idma64 idma64.1: Found Intel integrated DMA 64-bit >>>>>>>>>>> [ 25.025326] i2c_hid i2c-ELAN1201:00: i2c-ELAN1201:00 supply >>>>>>>>>>> vdd >>>>>>>>>>> not >>>>>>>>>>> found, using dummy regulator >>>>>>>>>>> [ 25.025494] i2c_designware i2c_designware.1: >>>>>>>>>>> i2c_dw_handle_tx_abort: lost arbitration >>>>>>>>>>> [ 25.025652] i2c_designware i2c_designware.1: >>>>>>>>>>> i2c_dw_handle_tx_abort: lost arbitration >>>>>>>>>>> [ 25.025811] i2c_designware i2c_designware.1: >>>>>>>>>>> i2c_dw_handle_tx_abort: lost arbitration >>>>>>>>>>> [ 25.025970] i2c_designware i2c_designware.1: >>>>>>>>>>> i2c_dw_handle_tx_abort: lost arbitration >>>>>>>>>>> [ 25.025972] i2c_hid i2c-ELAN1201:00: hid_descr_cmd failed >>>>>>>>>>> >>>>>>>>>>> 0x5F is kind of high for a plain interrupt; I wonder if ACPI >>>>>>>>>>> table >>>>>>>>>>> relies on static gpio->virq mapping that could be different on >>>>>>>>>>> Linux... Also I am surprised the IRQ is active-HIGH, normally it >>>>>>>>>>> is >>>>>>>>>>> active low. Might want to try and hack the driver to force it to >>>>>>>>>>> low >>>>>>>>>>> and see what happens... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes the interrupt is definitely suspect. Actually using plain >>>>>>>>>> interrupts >>>>>>>>>> rather then a GpioInt is something which I would only expect to >>>>>>>>>> see >>>>>>>>>> in >>>>>>>>>> old DSDTs and not in recent ones, because for i2c devices there is >>>>>>>>>> no clear parent interrupt controller and as such no well defined >>>>>>>>>> way >>>>>>>>>> to >>>>>>>>>> properly interpret a raw Interrupt number. >>>>>>>>>> >>>>>>>>>> What is with the AMD reference btw, the above dmesg snippet looks >>>>>>>>>> to be about an Intel system? I would not expect cannonlake-pinctrl >>>>>>>>>> to be used on an AMD system... >>>>>>>>>> >>>>>>>>>> If this indeed is an Intel system one thing worth trying is >>>>>>>>>> changing the clk_freq we use in the i2c-designware driver to >>>>>>>>>> calculate clk high and low counts. There are some reports from >>>>>>>>>> people attaching scopes to the i2c wires that on kabylake at >>>>>>>>>> least the driver is driving the bus about 1.5 times the >>>>>>>>>> expected rate (so 600KHz instead of 400KHz). >>>>>>>>>> >>>>>>>>>> A workaround for now would be to edit: >>>>>>>>>> >>>>>>>>>> drivers/mfd/intel-lpss-pci.c >>>>>>>>>> >>>>>>>>>> And change clk_rate in: >>>>>>>>>> >>>>>>>>>> static const struct intel_lpss_platform_info spt_i2c_info = { >>>>>>>>>> .clk_rate = 120000000, >>>>>>>>>> .properties = spt_i2c_properties, >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> From 120000000 to 180000000, people are still working on >>>>>>>>>> getting >>>>>>>>>> to the bottom of this but it is worth a shot. The clk_rate >>>>>>>>>> value here is only used to calculate i2c timings and does >>>>>>>>>> not actually program a clock, it only specifies the frequency >>>>>>>>>> the clock is expected to be running at. So changing this should >>>>>>>>>> be safe. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ok, so I just read the new mails in the threads where this is being >>>>>>>>> discussed and it has been confirmed by Intel that for all Canon >>>>>>>>> Lake >>>>>>>>> devices the correct clk_rate is 216000000 . Which likely explains >>>>>>>>> the i2c errors here. Jarkko (added to the Cc) is working on a patch >>>>>>>>> for this. >>>>>>>>> >>>>>>>>> For now if you can build your own kernels you can make the change I >>>>>>>>> suggested above, but that will also change the clock-rate on other >>>>>>>>> machines, so that is just for testing on Canon Lake hardware! >>>>>>>>> >>>>>>>>> The way the Interrupt is specified is still suspicious btw, but >>>>>>>>> we'll cross that bridge when we get there. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Hans -- 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