Can confirm need to reinstall arch with latest kernel due an faulty update (dont ask me how that happended, was suprised too…)
after that touchpad works on every second boot. but i can not figure out why.
Yep, just rebooted and touchpad stopped working. Rebooted a couple more times but it won’t come back 
.
Edit: spoke too soon. It seems to randomly decide whether to work whenever I reboot. I will try tomorrow to see if there is some any pattern. Could there be some drivers or firmware I forgot to install?
As far as i can tell, its a problem of latest kernel 6.8.9-arch1-1
If I switch to LTS kernel, in 8/8 tests the mouse always works.
I looked into the boot-log and tried to compare them with my limited knowledge
As far as i can tell, with LTS these two lines initialize the touchpad:
Mai 05 09:35:57 host kernel: hid-generic 0018:093A:0274.0001: input,hidraw0: I2C HID v1.00 Mouse [PIXA3854:00 093A:0274] on i2c-PIXA3854:00
Mai 05 09:35:57 host kernel: hid-generic 0018:32AC:001B.0002: hidraw1: I2C HID v1.00 Device [FRMW0003:00 32AC:001B] on i2c-FRMW0003:00
but around that timeframe with the latest kernel, there are no error messages indicating that it coult not initialize the touchpad…
EDIT: if someone want to take a look at the boot log i can provide that. maybe u guys can figure out more with it
Switching to the LTS kernel did not fix it for me; but downgrading to mkinitcpio 38.1 makes it work 100% of the time (at least for now).
Please tell me if it also fixes it for you.
2 Likes
Indeed i tried it 4 times and it worked everytime!
Yes, just downgraded to mkinitcpio38.1 and this has fixed the issue.
I just reported the issue upstream at Regression in 39.0 - Flaky touchpad detection on the Framework 16 laptop (#265) · Issues · Arch Linux / Mkinitcpio / mkinitcpio · GitLab
Please chime in if you have anything else that might be helpful; the dev has requested that someone else test the fix as well
1 Like
@Joe_M1 @Alex-X Can you please look at the bug report and check if the proposed solution works for you as well?
Update: Here’s the merge request that fixes the issue: Revert "install/keyboard: add more HID modules" (!376) · Merge requests · Arch Linux / Mkinitcpio / mkinitcpio · GitLab
The devs are looking for people to test it.
I’m not sure I agree with an initramfs root cause.
I think the commits I identified in Touchpad not working since update (Archlinux) - #2 by Shiroudan are more likely.
2 Likes
The mkinitcpio dev agreed that it was probably a kernel/firmware issue triggered by the inclusion of the i2c-hid* modules.
Quote:
This is without doubt either a firmware issue or a kernel bug, but since
no one actually asked for the change to include these modules to be made,
it should be fine to simply revert it.
I can’t sign in to Gitlab right now as it’s blocked due to spam, however I tried testing the fix by updating back to mkinitcpio39 and saving the keyboard file, but after rebooting the touchpad is still not working, rebooted at least 10 times before it worked. Have I applied the fix incorrectly?
You just need to shoot them an email as instructed in the login page, the process is really quick, I just signed up today.
You also need to rebuild the initramfs after saving the script; it works 100% consistently in my case.
I also made it executable, but I don’t know if it was actually needed.
Ah ok, reran mkinitcpio and it worked 4/4 times. I’ve emailed gitlab so can sign in soon. I didn’t need to make it executable btw.
Edit: Next day, the touchpad is no longer working consistently on boot. I’m still on mkinitcpio39, with the added keyboard file and I’ve tried re-running mkinitcpio but it’s still not working. Perhaps I got lucky yesterday when it worked 4 times in a row?
Not sure if this is relevant, but there is another issue with mkinitcpio39-1: Failed to start Generate shutdown-ramfs in the latest release (version 39) (#264) · Issues · Arch Linux / Mkinitcpio / mkinitcpio · GitLab, could this have anything to do with it?
Next day, the touchpad is no longer working consistently on boot. I’m still on mkinitcpio39, with the added keyboard file and I’ve tried re-running
mkinitcpiobut it’s still not working. Perhaps I got lucky yesterday when it worked 4 times in a row?
Weird, that didn’t happen to me; it’s still rock solid.
Not sure if this is relevant, but there is another issue with mkinitcpio39-1: Failed to start Generate shutdown-ramfs in the latest release (version 39) (#264) · Issues · Arch Linux / Mkinitcpio / mkinitcpio · GitLab, could this have anything to do with it?
I don’t think so, but I have 0 qualifications in the matter (It sounds like it’s a plymouth issue). You should talk with mkinitcpio devs once you get the account sorted
Ah, I think I did it wrong, simply running mkinitcpio in the command line will not actually do anything 
. After mkinitcpio -g /boot/initramfs-linux.img -k /boot/vmlinuz-linux the issue is fixed 7/7 boots.
I will confirm in Gitlab now, sorry for my naievety 
.
Pro tip: you can do mkinitcpio -P to automatically rebuild ALL the initramfs-es for every kernel you have installed :^P
2 Likes
Hello Everyone,
I’m reaching out for the first time with a technical issue that has me completely stumped, and I’d like to see if anyone else is experiencing something similar.
System Specs:
- Batch: 5
- RAM: 64 GB
- Processor: Ryzen 9
- GPU: Installed
- Storage: WD_BLACK SN850X 1000GB
- OS: Arch Linux with KDE Plasma
The Problem: During regular use, the system becomes unresponsive except for Chrome, and some applications crash while others continue running, likely because they’re still in RAM. However, any new commands or actions fail. For instance, all active terminal sessions stop working, and any command executed (e.g., ls) returns an error:
zsh: input/output error: wc
After this, the only solution is a full system reboot (by pressing the power button) because nothing else functions.
Initial Suspicions: I suspect the issue might be related to the SSD. However, I haven’t conducted thorough testing yet since the SSD is brand new, which makes it particularly odd.
Logs: Getting useful logs has proven challenging, but the best information I’ve found in journalctl is:
May 10 10:58:12 floreggianframework pipewire[1235]: mod.client-node: 0x634677aaa070: unknown peer 0x63467754a790 fd:75
May 10 10:58:13 floreggianframework wireplumber[1236]: <WpAsyncEventHook:0x5cf93ba899c0> failed: failed to activate item: Object activation aborted: proxy destroyed
May 10 10:58:13 floreggianframework wireplumber[1236]: <WpAsyncEventHook:0x5cf93ba899c0> failed: failed to activate item: Object activation aborted: proxy destroyed
May 10 10:59:18 floreggianframework pipewire[1235]: mod.client-node: 0x634677aaa070: unknown peer 0x634677a987b0 fd:71
May 10 11:19:40 floreggianframework wireplumber[1236]: <WpAsyncEventHook:0x5cf93ba899c0> failed: failed to activate item: Object activation aborted: proxy destroyed
May 10 11:20:16 floreggianframework wireplumber[1236]: <WpAsyncEventHook:0x5cf93ba899c0> failed: failed to activate item: Object activation aborted: proxy destroyed
May 10 11:20:16 floreggianframework pipewire[1235]: mod.client-node: 0x634677847680: unknown peer 0x63467754a790 fd:75
May 10 11:24:53 floreggianframework pipewire[1235]: mod.client-node: 0x6346775cf1a0: unknown peer 0x63467754a790 fd:71
May 10 11:24:55 floreggianframework pipewire[1235]: mod.client-node: 0x634677aaa070: unknown peer 0x63467787afa0 fd:77
-- Boot 53de65c6e8ed47d6bc15f215d22bd5d9 --
May 10 11:26:53 floreggianframework kernel: Linux version 6.8.9-arch1-2 (linux@archlinux) (gcc (GCC) 14.1.1 20240507, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Tue, 07 May 2024 21:35:54 +0000
May 10 11:26:53 floreggianframework kernel: Command line: root=UUID=821ef1e5-a791-4ffd-a27d-e1bb6ff38579 rw quiet splash add_efi_memmap initrd=amd-ucode.img initrd=initramfs-linux.img
May 10 11:26:53 floreggianframework kernel: BIOS-provided physical RAM map:
May 10 11:26:53 floreggianframework kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
May 10 11:26:53 floreggianframework kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000bffff] reserved
May 10 11:26:53 floreggianframework kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000009afffff] usable
May 10 11:26:53 floreggianframework kernel: BIOS-e820: [mem 0x0000000009b00000-0x0000000009dfffff] reserved
May 10 11:26:53 floreggianframework kernel: BIOS-e820: [mem 0x0000000009e00000-0x0000000009efffff] usable
May 10 11:26:53 floreggianframework kernel: BIOS-e820: [mem 0x0000000009f00000-0x0000000009f3bfff] ACPI NVS
Has anyone encountered something similar?
My next steps include doing a full test on the sdd or copying over my install to a external ssd and run that for a while to see if the issue persists.
I also cannot reproduce the issue on demand, so it is a waiting game before it fails
Even with it being a new SSD, I would suggest checking that the SSD has the latest firmware from the SSD manufacturer.
1 Like
I will update the firmware now and see if it yeilds any improvements