You are not logged in.
Hello,
I've been experiencing an issue with my laptop touchpad. Im guessing this could be a race condition situation,im not an expert in this area so please let me know if more backtraces or additional logs would be useful :-)
The touchpad fails to initialize in approximately 12 out of 13 cold boots (rough estimate). Occasionally fails in Windows too after long suspend (>4h), suggesting a firmware/hardware-level issue (at least from my understanding).
AFAIK, similar symptoms have been reported elsewhere but with different root causes, hence this post.
Hardware:
Lenovo IdeaPad Slim 5 16IRL8
Intel Alder Lake-P (ADL-P)
Insyde firmware CB-01
Touchpad: ELAN06FA over I2C
Kernel: 6.18.9-arch1-2
The issue:
The I2C controller (i2c_designware) times out before i2c_hid_acpi can read the HID report descriptor.
ACPI tables are consistent between good and bad boots (verified by comparing `dmesg` AFAIK).
No relevant module parameters found for i2c_hid or i2c_hid_acpi.
No difference between cold boot or warm boot.
Logs:
[ 4.848721] i2c_designware i2c_designware.0: controller timed out
[ 4.848789] hid (null): reading report descriptor failed
[ 4.848794] i2c_hid_acpi i2c-ELAN06FA:00: can't add hid device: -110
[ 4.848121] i2c_hid_acpi i2c-ELAN06FA:00: probe with driver i2c_hid_acpi failed with error -110
I tried:
* i8042.reset, i8042.nomux, acpi_osi=, acpi=noirq, irqpoll as kernel parameters — no effect
* Manual rmmod/modprobe of i2c_hid_acpi and hid_multitouch — i2c_hid in use, cannot remove
* Manual unbind/rebind via sysfs — device ID not present in driver directory when probe fails (never bound)
Is there a known workaround for i2c_designware timeouts on ADL-P during early boot? Is there a way to delay or retry the probe for i2c_hid_acpi? Has anyone seen this with ELAN touchpads on Lenovo ADL-P hardware?
Any additional thoughts or pointers to an existing solution i might have missed are very welcome :)
Offline
https://gitlab.archlinux.org/archlinux/ … issues/295 has a potential workaround.
You might also want to read this kernel-regressions thread for previous debugging efforts: https://lore.kernel.org/regressions/513 … l.com/T/#u
The above thread did not result in a fix, so feel free to reply on that mailing list if you have additional info that could help resolve the issue.
Offline
https://gitlab.archlinux.org/archlinux/ … issues/295 has a potential workaround.
You might also want to read this kernel-regressions thread for previous debugging efforts: https://lore.kernel.org/regressions/513 … l.com/T/#u
The above thread did not result in a fix, so feel free to reply on that mailing list if you have additional info that could help resolve the issue.
Thanks for the quick response. I haven’t had time to read the full regression thread yet, but it was very helpful!. I had already come across some of the suggested workarounds, so this saved me some (actually a lot of) time.
Thanks as well for compiling similar cases — I wasn’t able to find threads with models this close to mine (my hardware is almost 1:1 with one of the systems mentioned in the regression thread).
I’m dual-booting (sadly), so the BIOS is already up to date with vendor releases. I now have a few ideas to try as workarounds; if I find anything useful, I’ll report back :-)
Offline