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.
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.
Can someone please confirm that the touchpad is now indeed working consistently? I would love to jump back to Arch from Ubuntu (which I was using because I didn’t have time to fool with Arch b/c of school).
I have done thoughrough testing and this definitely resolved my issue. For anyone else, I would read those links to figure out the correct value for that kernal parameter.
Regarding trackpad issues: for me it’s working consistently, except when using ZFSBootMenu, in that case it neither works or gets detected at all, I suspect it’s due to the kernel not properly cleaning up the i2c bus state before kexecing the new kernel
Has anyone with the dGPU tried using visual studio code running in wayland?
On my system, running visual studio code in wayland keeps the dGPU active instead of suspended, increasing power consumption.
For me it just acts like any other electron and chrome app. Wakes dGPU up for a few seconds when I launch or close it. All other times the dGPU remains in sleep.
Is anyone else on KDE having a problem with their lock screen going to a black screen if you try moving the mouse (waking it up) right at the moment it tries to lock? When this happens to me the only way to get back to a usable desktop is to kill -9 the process kscreenlocker_greet.
I had a similar problem happen due to issues with the fingerprint unlock process. I ended up having to use loginctl on another terminal to unlock the system. The problem went away (I think/guess/hope) when I deleted my fingerprint login profile.
That’s what I see when I run it in XWayland. But for some reason, when running in Wayland (environment variable ELECTRON_OZONE_PLATFORM_HINT=wayland), it keeps the dGPU active.
It looks like electron apps using the dGPU instead of the iGPU is a common enough issue: Force integrated GPU · Issue #9842 · electron/electron · GitHub
I tried --force_low_power_gpu, but it doesn’t seem to work for VS code.
For now, I’ll have to use --disable-gpu to disable gpu accel. in VS code.
Hi all. Did the commonly advised thing and disabled secure boot in the BIOS to install Arch. It’s all working now, but doesn’t boot if I re-enable secure boot.
Do I have to leave this off permanently, or is there a way to get it to cooperate with what I’ve installed? Thanks.