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
