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

[Linux regression tracking (Thorsten Leemhuis)]

On 21.05.24 15:31, Arazil Songweaver wrote:
> 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.

Okay, then I won't track this as a regression; might still be worth
trying a few older kernels in a spare minute to see if it was introduced
in the last 12 or 18 months and can be bisected.

CCed Jiri and Benjamin nevertheless in case they missed this report on
the lists.

Ciao, Thorsten

> 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
> 
>