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
