I've found a regression somewhere between 6.7.4 and 6.8.0-rc0 that causes my Framework 7840 AMD laptop to freeze after waking it from a suspend. I can reliably trigger the issue, but unfortunately cannot provide useful logs for now and hope to get some help with doing so. How to reproduce ---------------- The last working kernel release was 6.7.4, the issue appeared in all 6.8 release candidates from 1-4. 1. normally boot the system with a 6.8 kernel 2. suspend and resume the system 2 to 4 times. Usually, the freeze already occurs at the 2nd resume. 2.1 graphical approach: I've reproduced this directly from the "Suspend" button in my SDDM display manager (X11) 2.2 TTY approach: You can also directly swith to a tty after boot, log in, and then issue `systemctl suspend` 2 to 4 times 3. After resume number 2 or later, the system freezes while resuming and cannot be used anymore. The screen is switched on and displays something, but no inputs are processed and the image is static. 3.1 graphical approach: When suspending and resuming by closing and opening the laptop lid, the screen is black with the cursor displayed. When doing so while keeping the lid open, the display manager's background image and a cursor are displayed, but only statically frozen. No keyboard or touchpad input is processed. 3.2 on a TTY: When suspending and resuming from a tty, a few kernel messages still manage to be printed, but after that no new information is displayed. E.g. when keeping a `journalctl -f` session open in another tmux pane, that journal output does not update anymore. Keyboard inputs are not processed anymore. Nonetheless, the cursor continues to blink regulary. I've attached two screenshots showing the situation with kernels 6.7.4 (working) and 6.8 (broken). Detailed Description -------------------- In most cases, the freeze already occurs after the 2nd suspend-resume-cycle. Unfortunately, this freeze also appears to block IO, as after a forced hard reboot I cannot retrieve relevant information from `journalctl -b "-1"`. The last retrievable log messages are from the successful suspend action. I welcome any recommendation on how to retrieve valuable information. I have not yet played around with cmdline parameters relevant for debug. System Details -------------- Distro: NixOS 23.11, kernel 6.8 rc1-4 compiled manually kernel: Linux version 6.8.0-rc4 (nixbld@localhost) (gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40) #1-NixOS SMP PREEMPT_DYNAMIC Sun Feb 11 20:18:13 UTC 2024 hardware: Framework 13 laptop, 7840 AMD series, CPU AMD Ryzen 7 7840U x86_64 In the attachments you find: - the used kernel config - my cmdline params - 2 screenshots from the bug occuring when triggered from a tty Next Steps ---------- I intend to bisect the issue, but this can take a while due to the need for manual testing and a kernel compile cycle requiring >30min for now. I am mostly reporting this now already to still raise awareness in the RC phase and to have something where I can point other Framework laptop users towards for reproduction of the bug. All the best schmittlauch Disclaimer: I read the kernel docs on reporting issues, IMHO these were a bit unclear on whether RC kernels are in the scope of the stable and regressions lists. If they aren't please point me to where to do this. So far I had only reported bugs via the bugzilla.
Attachment:
20240215_014050.jpg
Description: JPEG image
Attachment:
20240215_014247.jpg
Description: JPEG image
initrd=\efi\nixos\192wlpsshd9mb14qkmigj0h1z7lc4483-initrd-linux-6.8-rc4-initrd.efi init=/nix/store/rqjg8g51p7v4ria0hjjl4jl41s0nx8x9-nixos-system-framenix-23.11.20240211.809cca7/init amd_pstate=active amdgpu.sg_display=0 amd_pstate=active amdgpu.abmlevel=1 splash loglevel=4
Attachment:
config.gz
Description: application/gzip
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
