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.)
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
