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.
1 Like
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
3 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

1 Like
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
6

Software workaround for mt7925e (RZ717) suspend/hibernate freeze — keep the card, no swap needed

Same hardware as this thread: Framework 13 AMD (Ryzen AI 9 HX 370), Pop!_OS 24.04, COSMIC on Wayland, System76 kernel 7.0.11. I hit the same resume freeze and isolated it to the same culprit — the MediaTek mt7925e driver hanging the resume path — but landed on a software fix that lets you keep the RZ717 instead of swapping to an Intel card. Posting it in case it’s useful to others here.

Symptom

After s2idle suspend, the display would return to the login screen but keyboard and touchpad were dead — hard reset the only way out. The same root cause also showed up two other ways that I’d previously logged as separate bugs: hibernate that entered but never resumed, and cosmic-comp “Unable to become drm master / DRM access error” after resume. All three turned out to be the one resume hang at different points in the resume path.

Isolating it

The decisive test was unloading the WiFi driver before suspend:

$ lspci -nnk | grep -iA3 -i net
c0:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:0717]
        Kernel driver in use: mt7925e

$ nmcli radio wifi off
$ sudo modprobe -r mt7925e
$ sudo rtcwake -m mem -s 20
# -> clean resume, keyboard and touchpad fully working

Note the device ID here is 14c3:0717 (the RZ717), where most of the existing reports cite 14c3:7925 — same driver, slightly different ID.

The workaround

A systemd-sleep hook that unloads mt7925e before any sleep and reloads it after resume. It keys on pre/post rather than the sleep type, so it covers suspend, hibernate, and suspend-then-hibernate identically.

/usr/lib/systemd/system-sleep/mt7925-suspend-fix.sh (chmod +x):

#!/bin/bash
LOG_TAG="mt7925-suspend-fix"
MODULE="mt7925e"

case "$1" in
    pre)
        logger -t "$LOG_TAG" "Unloading $MODULE before $2"
        nmcli radio wifi off 2>/dev/null
        sleep 1
        if modprobe -r "$MODULE" 2>/dev/null; then
            logger -t "$LOG_TAG" "$MODULE unloaded"
        else
            logger -t "$LOG_TAG" "WARNING: failed to unload $MODULE (resume may freeze)"
        fi
        ;;
    post)
        logger -t "$LOG_TAG" "Reloading $MODULE after $2"
        modprobe "$MODULE"
        nmcli radio wifi on 2>/dev/null
        logger -t "$LOG_TAG" "$MODULE reloaded"
        ;;
esac

Verify it fires with journalctl -t mt7925-suspend-fix -b.

Suspend-then-hibernate note (systemd 255)

This also works with suspend-then-hibernate, which is what I actually use (s2idle on battery, roll to hibernate after a delay). The thing I was unsure about was whether the driver would be unloaded at the moment the hibernate image is captured — if it’s loaded in the image, resume-from-hibernate restores the wedged state. The journal confirms systemd 255 brackets the s2idle phase and the hibernate phase separately, each with its own pre/post pair, so the driver is out across the image capture:

Unloading mt7925e before suspend-then-hibernate   # enter s2idle
Reloading mt7925e after suspend-then-hibernate     # RTC wake at delay
Unloading mt7925e before suspend-then-hibernate    # about to hibernate
mt7925e unloaded                                   # image written with WiFi OUT
Reloading mt7925e after suspend-then-hibernate     # full resume

For reference, the lid/sleep config that goes with this:

  • logind.conf: HandleLidSwitch=suspend-then-hibernate, HandleLidSwitchExternalPower=suspend
  • sleep.conf.d/hibernate-delay.conf: HibernateDelaySec=60min
  • (HibernateOnACPower= would be cleaner but it’s systemd 257+, not available on 255.)

Trade-offs vs. the card swap

Swapping the RZ717 for an Intel AX210/BE200 (as others in this thread did) is the clean permanent fix and needs no scripts. The hook is the option if you’d rather not open the machine or want to keep the MediaTek card. Cost of the hook: WiFi drops on every suspend and re-associates on resume (a few seconds), which can interrupt anything holding a live connection across sleep.

Caveat / what I haven’t done

I’m on the System76 7.0.x kernel and have not bisected this against a current mainline kernel, so I can’t say whether mainline already fixes it (some fixes reportedly landed around 6.15.3) or whether this is a missing backport in the System76 line. If anyone here is on mainline and can test s2idle with mt7925e loaded, that data point would help pin down which it is.

Related upstream/distro reports for anyone digging in:

  • Kernel Bugzilla #219825, #220395
  • Ubuntu Launchpad #2141198, #2115643
2 Likes
7

Bless you friend. I’d been dealing with this problem in some form or other for a few months and your fix finally did it, thank you. I have a framework 16 AMD AI 370—slightly different hardware but the exact same problem. The symptoms and fix match too consistently to be otherwise. Thanks to the others as well.

I did try switching off the tsc watchdog in the kernel first, but it didn’t fix this problem.

8

Chiming in to say that I’m getting the exact same freezes on Fedora 44, but I have the intel AX210.

9

@Mario_Limonciello Is there anything that can be done here?

10

Same, also having these freezes, and that’s separate from the suspend from resume from hibernate related freezes (see Framework 13 7840U freezes (maybe after hibernate) - #2 by Fn1), I notice that plugging the laptop to power when idling tends to also hard freeze the laptop (and it gets very hot). Power management on this laptop is just so unreliable :frowning:

1 Like
11

Also suffering from the same issue on my Linux Mint. I tried changing wifi module to the intel one from mtk. While that fixed my 5ghz wifi auto-connect not working after sleep, I still had random freeze and laptop will start heating up. Moved back to linux 6.x and seems fixed. Gonna keep it as default for now as it still seems to be getting updates but don’t know for how long.

12

I haven’t had these problems on Mediatek WiFi cards ever since a firmware update + kernel update on Arch Linux. I remember using this following script to fix bugs at /usr/lib/systemd/system-sleep/wifi

#!/bin/bash
case $1 in
    pre)
        nmcli r wifi off
        rmmod mt7925e mt7925_common mt792x_lib mt76_connac_lib mt76 btusb btmtk
    ;;
    post)
        modprobe mt7925 && modprobe btusb
        nmcli r wifi on
    ;;
esac

You can get away with just modprobing mt7925 & btusb, as they will auto-load and depedency they have.