Framework 13 AMD (Ryzen 5 7640U) — s2idle Freeze on Fedora 44, Requires Cold Restart

Framework Laptop 13 Linux
1

Hardware

  • Laptop: Framework Laptop 13 (AMD)
  • CPU: AMD Ryzen 5 7640U w/ Radeon 760M Graphics
  • GPU: AMD Radeon 760M (integrated, amdgpu)
  • OS: Fedora 44 (Forty Four)
  • Kernel: 7.0.9-205.fc44.x86_64 (PREEMPT_DYNAMIC)
  • Suspend mode: s2idle only (no deep/S3 available)

Symptom

The laptop occasionally becomes completely unresponsive after closing the lid or after auto-suspend. No response to keyboard, trackpad, or power button short-press. The only recovery is a long power-button hold (cold restart). No kernel panic, oops, or crash dump is recorded — the journal simply ends at the last suspend entry.

Reproducibility

Intermittent. Over several weeks I recorded multiple sessions that ended with a crash flag in last -x rather than a clean shutdown, for example:

marcus   tty2         local            Mon May 25 09:25 - crash (9+08:47)

Each crash session corresponds to the journal ending abruptly after PM: suspend entry (s2idle) with no matching PM: suspend exit.

Kernel Messages

TSC Clocksource Instability

On every boot, the kernel marks the TSC unstable:

clocksource: timekeeping watchdog on CPU4: Marking clocksource 'tsc' as unstable because the skew is too large:
clocksource:                       'hpet' wd_nsec: 504572997 wd_now: 234aa383 wd_last: 22dc668c mask: ffffffff
clocksource:                       'tsc' cs_nsec: 504165189 cs_now: 23257d18e51e cs_last: 2325141e2a88 mask: ffffffffffffffff
clocksource:                       Clocksource 'tsc' skewed -407808 ns (0 ms) over watchdog 'hpet' interval of 504572997 ns (504 ms)
TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
clocksource: Switched to clocksource hpet

This triggers a sched_clock discontinuity which can cause timers to misfire during s2idle resume — a plausible mechanism for the freeze.

UCSI / USB-C Controller Errors

On every boot and after every resume, the ACPI UCSI driver reports errors:

ucsi_acpi USBC000:00: unknown error 0
ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
ucsi_acpi USBC000:00: unknown error 256

These are a known Framework firmware issue but can also delay or block the resume path if the EC is in an unexpected state.

hrtimer Latency Spike

One instance recorded during the previous boot:

hrtimer: interrupt took 4258883 ns

A 4.2 ms hrtimer delay is significant and consistent with the CPU being momentarily non-responsive — exactly what you would see during a partial resume failure.

GNOME Shell / Touchpad Errors

libinput error: event7 - PIXA3854:00 093A:0274 Touchpad: kernel bug: Touch jump detected and discarded.

meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed

These are secondary effects of the resume instability rather than the root cause.

Network Manager Warnings (secondary)

The p2p-dev-wlp1s0 IPv4 forwarding errors and imap.mailbox.org DNS resolution failures appear only during suspend/resume transitions — the WiFi disconnects and reconnects each cycle. These are symptoms, not cause.

Root Cause Analysis

The freeze is caused by a failure to resume from s2idle. The most likely sequence of events is:

  1. Lid closes or auto-suspend triggers PM: suspend entry (s2idle).
  2. The TSC is already marked unstable (known BIOS bug), forcing a fallback to HPET.
  3. During resume, a timing or ACPI event race occurs — possibly involving the UCSI controller, the amdgpu SMU resume, or the TSC/HPET handoff.
  4. The CPU or GPU never fully exits the low-power state. The system is unresponsive to all input.
  5. No kernel oops is generated because the CPU is halted — the journal has no opportunity to record anything.
2

Hi,
I have been having the same issue since the last update of PopOS 24.04. to Kernel 7.0.9-76070009-generic. Apart from the OS, my specs are also a bit different (AMD HX 370). Moreover, the issue in my case was not an occasional one. Any suspend-resume, either by closing and opening the lid or simply waiting for the suspend and wake-up, would lead to a system freeze requiring a cold reboot.

In my case, I identified the MediaTek MT7925 (AMD RZ717) wifi chip (or rather its driver) as the cause. Removing wifi using ‘sudo modprobe -r mt7925e’ mitigates the issue. I changed the wifi chip to an Intel AX210 today. The suspend now works properly. Below is a more detailed description of my issue.

Hardware

  • Framework Laptop 13 (AMD Ryzen AI 9 HX 370) with latest firmware/bios
  • Wi‑Fi: MediaTek MT7925 (AMD RZ717), driver mt7925e (mt76)

OS and Kernel

  • Distro: Pop!_OS 24.04 LTS x86_64
  • DE: COSMIC 1.0.0
  • WM: cosmic-comp (Wayland)
  • Kernel: 7.0.9-76070009-generic
  • Suspend mode: s2idle (no S3)
  • Boot cmdline (from /proc/cmdline): includes amdgpu.dcdebugmask=0x10; otherwise default Pop!_OS options

Symptoms

  • Closing lid, waiting for suspend or running: sudo rtcwake -m mem -s 5
  • System wakes and immediately freezes (no keyboard/mouse), requires long power button hold shutdown
  • No kernel panic; journal ends at PM: suspend entry (s2idle) with no “suspend exit”

Isolation and results

  • Clocksource: system uses TSC; switching to HPET at runtime does not help
    echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource → freeze still occurs
  • Staged suspend tests still freeze at the shallowest level:
    echo devices > /sys/power/pm_test; rtcwake -m mem -s 5 → wake then immediate freeze
  • Wi‑Fi driver is the trigger:
    Unloading mt7925e using ‘sudo modprobe -r mt7925e’ before suspend avoids the freeze
2 Likes
3

Hi,

The tsc on these recent amd cpu are stable, and the instability reported by the kernel is definitely wrong and due to the implementation of the tsc watchdog in the kernel.

You need to add

tsc=nowatchdog

to your kernel parameters.

The tsc kernel watchdog is being completely rewritten in the futur 7.1 kernel and this may not be needed in the near futur. clocksource: Rewrite watchdog code completely

4

Ryzen 7840hs here, fedora silverblue — I’ve set up hibernate, and the laptop is just incredibly inconsistent, half of the times it’d be fine, the other half the battery is completely dead. It’s been bad to the point that I avoid using my FW13 because whenever I want to use it there’s a good chance the battery is completely dead. Also a lot of the times when it did hibernate successfully, it simply will hang on boot and need a force shutdown/ restart anyway, negating the benefit of hibernate.

5

<tl;dr>Pop OS 24.04 with Kernel 7.x on AMD HX370: AX210 works fine; MT7925 gives freeze on resume.</t;dr>

Framework 13 with AMD Ryzen AI 9 HX370. Had issues with an AX210 card on kernel 6.x with suspend/resume (no freeze, but network would disappear and only come back after full reboot). Ordered a MT7925 card because the internet said it works better with AMD chips. While I was waiting for the MT7925 to arrive, kernel 7.x came out, and the AX210 started to work fine.

A few days later, the MT7925 arrived, and I figured I swap it in anyway, just to get freeze on resume. Put the AX210 back in and the freezes are gone.

1 Like