Bug 194623 - Touchpad stops working intermittently.
Summary: Touchpad stops working intermittently.
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-18 14:33 UTC by kernel
Modified: 2023-12-23 02:02 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.9.6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
System journal (249.14 KB, text/plain)
2017-02-18 14:33 UTC, kernel
Details

Description kernel 2017-02-18 14:33:28 UTC
Created attachment 254823 [details]
System journal

Acer C720 using Arch Linux. 

I started seeing this behavior after upgrading from linux 4.8.13 to 4.9.6 and am still seeing it on 4.9.8. A couple of times a week the touchpad will stop working; that is, the cursor can no longer be moved by the touchpad. After I reboot, or suspend and then resume, the touchpad works again.

The failure is always accompanied with a series of messages in the log with "i2c-designware-pci 0000:00:15.1: timeout waiting for bus ready." I've attached a log.
Comment 1 christopocalypse 2018-03-12 22:04:47 UTC
Same. Acer C720 using Debian, kernel 4.14.12. Occurs on both 32-bit and 64-bit.

My system journal is identical to the posted one with regards to the cyapa 0-0067 "runtime resume failed", "runtime suspend failed", and surrounding i2c-designware-pci timeouts that occur when the trackpad freezes. The freeze sometimes occurs after hours of use, sometimes a few seconds after login and doesn't seem to correlate with observable system load or a particular activity as far as I can tell.

I ran kernel 3.18 for years on this chromebook with no trackpad issues.
Comment 2 russell.parker7 2018-03-13 02:41:26 UTC
Experienced on the Samsung Chromebook 3 (CELES) running 4.14.14. Tends to occur under heavy load. I am able to recover by suspending and resuming the system and get the additional log messages: 
> i2c_designware 808622C1:05: timeout in disabling adapter

and
> i2c_designware 808622C1:05: transfer terminated early - interrupt latency too
> high?"

Also, from http://e2e.ti.com/support/embedded/linux/f/354/p/70448/309432: 
> I am not sure if you got an answer to this but I can't help but give you this
> hint:  In my experience with I2C, if the clk is interrupted some how the
> slave device will hold the line waiting instead of sending an ack until it
> gets the proper amount of clock cycles.  We had to have a special case in the
> code for the timeout - if it occured we sent clock cycles until the slave
> released the line.  It locked up more often the busier the communication line
> was.  It took me days to figure this out.
Comment 3 Nova 2023-12-23 02:02:50 UTC
Sorry for bumping an old thread, but it seems I'm having the same issues. I have an Acer Aspire 5 A515-56-53DS running 6.6.6. I have found that unloading and reloading the i2c_hid_acpi module seems to provide a temporary fix. It seems to be a bit glitchy after doing this when trying to use multitouch gestures, which seems to be resolved by reloading the hid_multitouch module. Hope this helps!

Note You need to log in before you can comment on or make changes to this bug.