Hi,
I have a dual boot with Archlinux and MS Windows for institutional tools. Yesterday I updated my system (yay) and my touchpad does not work anymore. It does not seem to be recognized with xinput list, lsplug (lsusb) and lspci -k. So I booted on Windows… and it is not a hardware issue.
Can you help me, please?
Can you try booting into your backup kernel? If Arch isnt detecting the hardware itself it sounds like a kernel issue!
There are two commits in 6.8.9 that are suspect to me looking at the change list.
Can you try to revert those one by one and see which (if either) caused it?
Just hopping in here to say I got the same issues when doing pacman -Syu. Libinput not seeing the trackpad at all
Indeed I have the kernel 6.8.9 (from 6.8.4) and I can try but I do not know how.
I know I can downgrade the linux package with
sudo pacman -U file:///var/cache/pacman/pkg/
but how to revert a commit in a pacman package?
PS: sometimes the touchpad works but I did not identified what is the cause. An external mouse is always ok.
https://www.reddit.com/r/archlinux/comments/rn25qo/how_do_you_apply_kernel_patches/ will help you. You basically take the broken kernel and create a ‘revert patch’ and apply that and see what happens.
Make sure you keep the “broken” mkinicpio tho!
I tested a kernel with both of these commits reverted, and managed to reproduce the issue after ~5 boots.
In that case you might need to bisect it.
That is going to take a while…
Well, I might as well get started!
Progress update:
6.8 is bad
cae0de45c8fd62612e1ee429134fd82c2c0e335e is bad
7d461b291e65938f15f56fe58da2303b07578a76 is bad
5a6a09e97199d6600d31383055f9d43fbbcbe86f is bad
17047fbced563cf5abe5aa546f6a92af48900b69 is weird (When it detects, the cursor is very laggy). Counting as “bad”
5b593ee172bd536a2c9fd717de7e4a16d682ef23 is bad
6.6 is good
Estimated ~9 builds left
Currently building: 2925fc49b3303ee7733cf9f6cba6a59a5b8a5e4b
I’ve been running various versions of 6.8 for a while without issue. I just updated to 6.8.9-zen1-1-zen and am now seeing the issue myself as well. Typing this up using tab for site navigation.
Update: I tested the arch default kernel (6.8.9) and that worked, then booted back into zen and found the issue was gone. Strange, it sounds like mine may be inconsistent like yours.
I upgraded to default 6.8.9.arch-1 on May 2nd while using it with a mouse, so I didn’t notice the issue immediately. When I saw this thread, I noticed that my touchpad was not working.
However, I just rebooted and it works now.
I compared journalctl -b vs journalctl -b -1 and found:
touchpad not working
framework kernel: i2c_hid_acpi i2c-FRMW0003:00: failed to reset device: -121
framework kernel: tsc: Refined TSC clocksource calibration: 3792.871 MHz
framework kernel: clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6d5812d0b0b, max_idle_ns: 881590872300 ns
framework kernel: clocksource: Switched to clocksource tsc
framework kernel: hid-generic 0018:32AC:001B.0001: hidraw0: I2C HID v1.00 Device [FRMW0003:00 32AC:001B] on i2c-FRMW0003:00
framework kernel: xhci_hcd 0000:c4:00.3: xHCI Host Controller
framework kernel: xhci_hcd 0000:c4:00.3: new USB bus registered, assigned bus number 1
framework kernel: xhci_hcd 0000:c4:00.3: hcc params 0x0128ffc5 hci version 0x120 quirks 0x0000000200000410
framework kernel: hid-sensor-hub 0018:32AC:001B.0001: hidraw0: I2C HID v1.00 Device [FRMW0003:00 32AC:001B] on i2c-FRMW0003:00
touchpad working:
hid-generic 0018:32AC:001B.0001: hidraw0: I2C HID v1.00 Device [FRMW0003:00 32AC:001B] on i2c-FRMW0003:00
framework kernel: input: PIXA3854:00 093A:0274 Mouse as /devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/0018:093A:0274.0002/input/input2
framework kernel: input: PIXA3854:00 093A:0274 Touchpad as /devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/0018:093A:0274.0002/input/input3
framework kernel: hid-generic 0018:093A:0274.0002: input,hidraw1: I2C HID v1.00 Mouse [PIXA3854:00 093A:0274] on i2c-PIXA3854:00
framework kernel: xhci_hcd 0000:c4:00.3: xHCI Host Controller
framework kernel: xhci_hcd 0000:c4:00.3: new USB bus registered, assigned bus number 1
framework kernel: xhci_hcd 0000:c4:00.3: hcc params 0x0128ffc5 hci version 0x120 quirks 0x0000000200000410
framework kernel: xhci_hcd 0000:c4:00.3: xHCI Host Controller
framework kernel: xhci_hcd 0000:c4:00.3: new USB bus registered, assigned bus number 2
framework kernel: xhci_hcd 0000:c4:00.3: Host supports USB 3.1 Enhanced SuperSpeed
framework kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.08
framework kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
framework kernel: usb usb1: Product: xHCI Host Controller
framework kernel: usb usb1: Manufacturer: Linux 6.8.9-arch1-1 xhci-hcd
framework kernel: usb usb1: SerialNumber: 0000:c4:00.3
framework kernel: hub 1-0:1.0: USB hub found
framework kernel: hub 1-0:1.0: 5 ports detected
framework kernel: hid-sensor-hub 0018:32AC:001B.0001: hidraw0: I2C HID v1.00 Device [FRMW0003:00 32AC:001B] on i2c-FRMW0003:00
It is inconsistent, and it only happens with mkinitcpio 39.0, which only came out very recently.
mkinitcpio v39 is necessary to reproduce this issue since it’s the first version that includes the i2c-hid* kernel modules, which appear to be the source of this bug.
While bisecting, I already found that kernel commit cae0de45c8fd62612e1ee429134fd82c2c0e335e (which was part of a 6.7 RC) already had the bug when combined with a “broken” (as in, generated by mkinitcpio v39) initramfs.
I am going to continue the bisect once I get back home in ~5 hours.
I am back! Continuing from where I left off
I think it’s worth dropping both of those fixups as well as the original commit they were trying to “fix” and see if that helps the issue.
The further back I go with my bisect, the weirder the situation becomes.
I am currently somewhere in RC1, and I hit a few commits that don’t build.
If you prefer, I can put the bisect aside for a moment and try to test reverting suspicious commits: i just need to know the hashes so that i can make a patch
The two I mentioned above as well as HID: i2c-hid: Move i2c_hid_finish_hwreset() to after reading the repo… · torvalds/linux@af93a16 (github.com)
Well, I tried for a bit, but I could not get a kernel with those three patches to build.
I am going to continue tomorrow, when I have a clearer mind (hopefully).
I hope y’all find the issue before it gets to Fedora, lol. One of the reasons I don’t use Arch and dirivatives as my daily these days. Fedora is currently on 6.8.8 so crossing my fingers we won’t see this issue.
Again: the bug has been in the kernel for a while. It got triggered just now because Arch started including the i2c-hid* modules in their initramfs.
Sorry, a lot of the info on this thread goes over my head.
Found the problem! (I did not notice that GCC just had an update!) Now everything is back in order.