Re: BUG: Framework Laptop 16 i2c-hid Based Touchpad Sometimes Fails To Initialize Properly On Early Boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I was able to reproduce bug again with: Linux version 6.9.0-1-git-10323-g8f6a15f095a6 (linux-git@archlinux) (gcc (GCC) 14.1.1 20240507, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Tue, 21 May 2024 11:58:24 +0000 (not an official Arch Linux package)

The relevant I2C_HID module needs to be built in to the kernel for the bug to trigger on a consistent basis. Arch Linux and mkinitcpio is currently getting around this issue by building I2C_HID as a module and delaying the load of that module until the part when autoprobe starts loading relevant kernel modules. The bug became (more) visible on Arch Linux after an update to mkinitcpio moved the I2C_HID module up to the beginning of the boot process.

This is not a recent regression. In my testing, I was able to reproduce this issue as far back as version 6.8. I did not test 6.7 or earlier revisions yet.

Thanks for the follow up.

-Arazil

On 5/21/24 5:57 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
On 14.05.24 04:57, Arazil Songweaver wrote:
We are experiencing an issue where the touch pad on the Framework Laptop
16 fails to initialize properly when the "i2c-hid" is loaded early in
the boot process. This issue is especially prominent when "i2c-hid" is
built directly into the kernel. When the "i2c-hid" module is built in,
the issue occurs roughly 50% of the time.
(https://community.frame.work/t/touchpad-not-working-since-update-archlinux/50304) Moving the module load to later in the boot process appears to resolve this issue by making initialization more likely to succeed. (https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/releases/v39.1)

Kernel version: Linux artemis 6.9.0-1-git-01560-ga7c840ba5fa7 #1 SMP
PREEMPT_DYNAMIC Tue, 14 May 2024 01:49:25 +0000 x86_64 GNU/Linux

I'm using the standard Arch Linux AUR "linux-git" package with the
following kernel configuration changes:

CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_HID=y
CONFIG_I2C_HID_ACPI=y
CONFIG_I2C_HID_OF=y
CONFIG_I2C_HID_CORE=y

We tried reverting the following patches without any behavior impact
(good or bad):

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=fb49deec375aa5beca4a5d71d7a74ec951872f28

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.8.y&id=418c5575d56410c6e186ab727bf32ae32447d497

Impacted devices seem to include: "PIXA3854:00" and "i2c_designware
AMDI0010:03"
Any news on this? If this is still unresolved I'll bring this to the
attention of the right developer, if this is a recent regressions (it
sounds like it, but it's not exactly clear; and from the first link
above it sounds like it's partly due to a change in arch's approach to
the initramfs).

Ciao, Thorsten




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux