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?
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
