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
I’ve had this happen before, although not on a framework, it was an old macbook. I was running Manjaro on btrfs with hibernate and full disk encryption. Randomly about ~1hr after waking the laptop from hibernation, I would have the exact same symptoms. Also, random files would get corrupted. I was running a special adapter to make the SSD fit into the macbook, though I don’t think that mattered. The SSD was a Samsung 970 EVO.
I didn’t have time to drill into why it was happening, but it was fixed after a reinstall (that didn’t have full disk encryption). The SSD wasn’t the problem, as I’m currently using that same SSD in my framework. I’m using the exact same settings now (Manjaro, Encryption, Hibernate, btrfs) on my framework and not having any issues.
Ran into the same issue with that same NVME drive. Seems to be a firmware bug where the drive does not properly handle going into it’s lowest powerstate. The fix is to add this kernel parameter to manually set a new (higher) minimum:
nvme_core.default_ps_max_latency_us=5500
To find the correct value for your nvme drive, run sudo smartctl -a /dev/nvme0 (adjust for the location of your nvme drive) and look for the values of Ex_Lat. Find the value for the 2nd to lowest power state and use that.
Sources:
Regardless of the root cause, we’ve release 39.1 to solve the issue.
1 Like
It’s unfortunate it’s just a work around, but I’m quite happy to be I’ll be able to reboot my device without using relying on the custom kernel builds I happened to have lying around on who knows what version of linux.