Framework 13 AI 300 Series won't resume most of the time

Which Linux distro are you using?
Fedora

Which release version?
(if rolling release without a release version, skip this question)
42

(If rolling release, last date updated?)

Which kernel are you using?
6.15.7-200.fc42.x86_64

Which BIOS version are you using?
3.04

Which Framework Laptop 13 model are you using? (AMD Ryzen™ AI 300 Series, AMD Ryzen™ 7040 Series, Intel® Core™ Ultra Series 1, 13th Gen Intel® Core™ , 12th Gen Intel® Core™, 11th Gen Intel® Core™)
AMD Ryzen™ AI 300 Series

Hello, I have a brand new Framework 13 with a Ryzen AI 9 HX 370, WD SN850X, 4 USB-C expansion cards and 96GB of the Mushkin MRA5S560LKKD48GX2 (the one recommended by Framework).

The issue I’m having is that sometimes when I suspend by pressing the button and almost always when I close the lid, the computer won’t wake up.

At first when I opened the lid, it would have a pulsating button like it was in sleep mode but would respond to nothing.

Now, it seems to have changed and it has a solid button but still I can’t do anything.

If I run journalctl -b -1 | grep -iE ‘resume|suspend’ I get:

Jul 25 15:17:45 fedora kernel: Low-power S0 idle used by default for system suspend
Jul 25 15:17:46 fedora kernel: nvme 0000:bf:00.0: platform quirk: setting simple suspend
Jul 25 15:26:30 fedora systemd-logind[1661]: The system will suspend now!
Jul 25 15:26:30 fedora ModemManager[1762]: <msg> [sleep-monitor-systemd] system is about to suspend
Jul 25 15:26:35 fedora systemd[1]: Starting systemd-suspend.service - System Suspend...
Jul 25 15:26:35 fedora systemd-sleep[5824]: Performing sleep operation 'suspend'...
Jul 25 15:26:35 fedora kernel: PM: suspend entry (s2idle)

I’ve tried amd-s2idle, and I get this:

|💻 |AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)|
|---|---|
|💻 |Framework Laptop 13 (AMD Ryzen AI 300 Series) (Laptop)|
|🐧 |Fedora Linux 42 (Workstation Edition)|
|🐧 |Kernel 6.15.7-200.fc42.x86_64|
|🔋 |Battery BAT1 (NVT FRANGWA) is operating at 101.53% of design|
|✅ |ASPM policy set to 'default'|
|✅ |GPIO driver `pinctrl_amd` available|
|✅ |PMC driver `amd_pmc` loaded (Program 11 Firmware 93.10.0)|
|✅ |USB3 driver `xhci_hcd` bound to 0000:c1:00.4, 0000:c3:00.0, 0000:c3:00.3, 0000:c3:00.4|
|✅ |USB4 driver `thunderbolt` bound to 0000:c3:00.5, 0000:c3:00.6|
|✅ |System is configured for s2idle|
|✅ |GPU driver `amdgpu` bound to 0000:c1:00.0|
|✅ |PC6 and CC6 enabled|
|✅ |SMT enabled|
|✅ |IOMMU properly configured|
|✅ |ACPI FADT supports Low-power S0 idle|
|✅ |LPS0 _DSM enabled|
|✅ |WLAN driver `mt7925e` bound to 0000:c0:00.0|

This is driving me crazy, I’ve spent so much time, and I feel like nothing works.

I’ve tried suspending with bluetooth and WiFi off, I’ve tried disabling the SSD sleep with nvme_core.default_ps_max_latency_us=0, I’ve tried disabling secure boot and the PCI power saving thing in the BIOS, nothing seems to work.

I also checked that my SSD has the latest firmware and it does.

I would really love to use Linux on this laptop but it’s looking more and more like I might have to switch to Windows for it to be usable.

I’m running Bluefin, which is mostly Fedora… Same kernel, 128 GB Crucial, WDSN850X.

My computer wakes up fine three times in four. That fourth time, the screen is frozen and nothing works. If I close the lid and re-open it, it fixes itself. It’s been months since my last GPU hang.

Reinstall? Try another distro? I think you have a combo that should work.

(edit: I don’t mean to say my setup works great, not yet. But it’s OK and I have hope)

Fedora 42, Ryzen AI 9 HX 370, 2.8K screen, 128 GB Crucial, Samsung 990 pro, AX210, 2x USB-C, 1x USB-A, 1x Ethernet. Sleep mode works reliably for me. I think I’ve only had a problem with it once, and I use it almost every day. If I were you, I would try removing the Wi-Fi card to see if that helps.

@bron @Petr_Hlavac Thanks for letting me know your configs.

@Petr_Hlavac Why do you think wifi might be causing it?

I’ll try rfkill to see if it has any effect, not sure I want to rip open the computer but it might come to that.

The other difference could possibly be the RAM. You both are using Crucial and I’m using Mushkin.

I’m running Debian 13 on the AI 7 350 with 32 GB A-DATA (framework) and 2 TB WD Black SN850X.

Since the original AMD/MediaTek Wifi adapter was not working stable, I replaced it with the Intel AX210 and very frequently, the system would hang on resume caused by the iwlwifi driver.

After building a 6.16.0-rc4 Kernel (the latest some weeks ago), this was solved and now about 1 out of 30 resumes the screen comes up, power button LED solid on but system completely locked up.

Journal looks like this:

Jul 24 23:53:43 framework systemd-sleep[97449]: Successfully froze unit 'user.slice'.
Jul 24 23:53:43 framework systemd-sleep[97449]: Performing sleep operation 'suspend'...
Jul 24 23:53:43 framework kernel: PM: suspend entry (s2idle)
Jul 24 23:53:43 framework wpa_supplicant[1298]: wlp192s0: CTRL-EVENT-DSCP-POLICY clear_all
Jul 24 23:53:43 framework kernel: Filesystems sync: 0.012 seconds
-- Boot ea2affa249194a95b15980adf3ba52a0 --
Jul 25 07:22:38 framework kernel: Linux version 6.16.0-rc4 (dode@framework) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #3 SMP PREEMPT_DYNAMIC Wed Jul  2 22:04:25 CEST >
Jul 25 07:22:38 framework kernel: Command line: BOOT_IMAGE=/vmlinuz-6.16.0-rc4 root=/dev/mapper/framework--vg-root ro quiet
Jul 25 07:22:38 framework kernel: x86/split lock detection: #DB: warning on user-space bus_locks

So, nothing after “Filesystems sync”, and then a regular boot after force powering off.

I’d also try removing the Wifi module, or maybe it is sufficient to blacklist the Kernel driver module?
And maybe trying with just one of the two RAM modules?

I too hope this will improve within a few Kernel and BIOS releases.

It’s just a thought and I’m not entirely sure about it, but the main hardware differences between our configurations are the RAM, SSD, and WiFi card. Out of those three, I’d guess the WiFi card is the most likely culprit. Support for WiFi cards on Linux used to be problematic. I’ve seen a few cases where WiFi stopped working after waking the system from sleep and users were experimenting with scripts to restart the WiFi afterward.

WiFi cards from Realtek, which are used in the AMD branded modules, tend to be less well supported on Linux compared to those from Intel. And then there’s the thing with the newer Intel WiFi modules that can prevent an AMD laptop from powering on at all. So the WiFi card can have an impact on issues like this.

Also, WiFi cards rely on different drivers, while I would expect RAM and SSDs to behave similarly across different manufacturers. Generally, when a manufacturer releases a new SSD or RAM model, it will work right away, but with a new WiFi card model, you often have to wait until it is supported on Linux. Plus, the WiFi card is the easiest to test since the laptop will still work without it. In contrast, testing RAM is harder unless you have a spare kit to swap in.

But again, this is what I would test if I had this problem. I don’t know what exactly is causing your problem.

Since I don’t have a WiFi 6 or WiFi 7 router, I use the Intel AX210. Therefore, I don’t know how well the AMD branded WiFi cards perform. Maybe other users will tell you they work fine and I might be completely wrong.

Now I realize that the Framework allows you to disable Wi-Fi in BIOS, so you don’t have to take it apart to test it.

Great tip! I didn’t realize there was a whole other page in the BIOS if I scrolled down.

So I tried disabling WiFi/BT and still the same problem :persevering_face:

Just in case I tried disabling everything in the IO menu like fingerprint, camera, etc. but still the same issue.

I guess that would suggest either the RAM or some sort of hardware defect?

If you are willing to be a bit adventurous, there are a few things to try.

  1. Keep the console awake during suspend, so you get to see more potential error messages on the console.
    echo N | sudo tee /sys/module/printk/parameters/console_suspend

Then test suspend with “amd-s2idle”

The messages might disappear quickly, so probably best to video the screen with your phone, and then play it back slowly, and read what it said.

  1. If you are prepared to compile your own kernel, you can try the S5_RESET_STATUS.
    You might wish to read this:
    FW16 Freeze then Reboot (FTR) S5_RESET_STATUS = 0x08000800 <- Sync Flood. · Issue #41 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub
    Try the S5_RESET_STATUS patch.

I might not fix your problem, but it will at least tell us more about what the problem is.

1 Like

@James3 For the console_suspend one, I need to set that value and then exit GNOME and run systemctl suspend?

I installed Windows 11 to see if I would have better luck there and got the exact same suspend issue (pulsing power button but nothing brings it out of sleep).

This is leading me to believe that it might really be the RAM as it’s the only piece of hardware on my Framework 13 that isn’t from Framework.

I think tomorrow I’ll try taking out one of the sticks and see if it has any effect.

Interestingly, this guy has a similar setup (although 7040 instead of AI 300) with the Mushkin RAM and had almost the same problem: [RESPONDED] Framework 13 DIY AMD won't wake from sleep on battery

Although he seemed to have resolved it with kernel upgrades.

@merxutio
No need to Exit gnome.
Just test suspend with “amd-s2idle” after setting the console suspend to N

Just a correction: AMD branded wifi is mediatek (ex Ralink).
Opensource support is OK, driver & firmware quality isn’t.
If you want to use Linux, no stick is long enough to avoid Realtek enough.

A few ideas:
Log kernel log to pstore. UEFI can store some data between reboots, so the kernel log can be saved there, and retrieved at the next boot. This works even when storage isn’t up and running. Unfortunately I don’t have anything better than the official kernel docs:

Assuming your kernel actually crashes, retrieving and looking at the backtrace might be helpful. Instructions: Kdump - ArchWiki

If it doesn’t crash, but only hangs, configure it to panic on hung tasks. This will get you the dump and you can start investigating.

Thanks for the correction. I should have checked before posting. Apologies if I caused any inconvenience.

I have no issue resuming, and it seems we are running the same OS:
Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.15.7-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen AI 7 350 w/ Radeon 860M
Memory: 64 GiB of RAM (62.1 GiB usable)
Graphics Processor: AMD Radeon 860M Graphics
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen AI 300 Series)
System Version: A7

Maybe a different DM?

What’s the brand of the RAM?

dmidecode 3.6

Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0012, DMI type 17, 92 bytes
Memory Device
Array Handle: 0x0011
Error Information Handle: 0x0015
Total Width: 64 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: SODIMM
Set: None
Locator: DIMM 0
Bank Locator: P0 CHANNEL A
Type: DDR5
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 5600 MT/s
Manufacturer: A-DATA Technology
Serial Number: 00355766
Asset Tag: Not Specified
Part Number: AD5S560032G-SFW
Rank: 2
Configured Memory Speed: 5600 MT/s
Minimum Voltage: 1.1 V
Maximum Voltage: 1.1 V
Configured Voltage: 1.1 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Unknown
Module Manufacturer ID: Bank 5, Hex 0xCB
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 32 GB
Cache Size: None
Logical Size: None

Handle 0x0013, DMI type 17, 92 bytes
Memory Device
Array Handle: 0x0011
Error Information Handle: 0x0016
Total Width: 64 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: SODIMM
Set: None
Locator: DIMM 0
Bank Locator: P0 CHANNEL B
Type: DDR5
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 5600 MT/s
Manufacturer: A-DATA Technology
Serial Number: 00357898
Asset Tag: Not Specified
Part Number: AD5S560032G-SFW
Rank: 2
Configured Memory Speed: 5600 MT/s
Minimum Voltage: 1.1 V
Maximum Voltage: 1.1 V
Configured Voltage: 1.1 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Unknown
Module Manufacturer ID: Bank 5, Hex 0xCB
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 32 GB
Cache Size: None
Logical Size: None

I ordered the ram at framework too and the box said framework.

I think I resolved it!

It was the RAM.

I swapped out the Mushkin sticks for a 48GB Crucial stick (CT48G56C46S5) and all my problems went away. It wakes up from suspend no problem in Windows 11 and Fedora 42. I also did amd-s2idle for 5 cycles (this always failed before) and it had no problems.

Just to be sure it wasn’t an issue with the amount of RAM (96GB), I put in a single 48GB Mushkin stick and the wake up issue returned.

Thanks everyone for your help!

Also, Framework, you should put a note on your RAM page (What DRAM/memory is supported by Framework Laptop 13 (AMD Ryzen™ AI 300 Series)?) that the Mushkin RAM is not compatible with the AI 300 Series, at least the sticks that I got.

3 Likes

Is the Mushkin RAM CL40 timing speed? There has been at least two reports in these threads of AI300 series processors having problems with CL40 RAM, but operating fine with CL46 RAM.