[TRACKING] Cannot resume from suspend on AMD

Ditto what @jwp suggested.

Thanks jwp, crazy busy and I appreciate the assist.

@jwp Thanks. I’ll consider it. Because of the nature of my work I have to have some guarantees around encryption at rest but could possibly switch things up so I’m not running an encrypted system drive.

That said, since running without the HDMI Expansion card I have seen no issues with resuming, whereas I was seeing multiple occurrences per day prior. Not sure if I got a janky card or what.

@Matt_Hartley Based on the HDMI observation made by @jonp I removed the HDMI expansion card, and left only one USB-C card installed in slot (1). All other slots were empty.

Did two long-duration suspends (over 6 hours). In both cases the laptop woke up without problems.

Not a definite smoking gun, but it’s anecdotal evidence suggesting that something may be wrong with the HDMI card, and/or the Linux kernel really doesn’t like it.

PS. Interestingly, without the HDMI card installed, the drop in battery percentage reduced to about 0.5-0.6 points per hour during the suspend. With the HDMI card it was about 0.7 to 0.8 points per hour.

Given this latest development, I’ve also removed the HDMI expansion card, and will report my anecdata.

@jwp As per your advice, upgraded to F39. This came along with the rather fresh update to kernel 6.6.2, which promptly caused problems.

Under kernel 6.6.2-201.fc39, waking up the machine from suspend resulted in a completely white screen. Switching to terminal view via the usual control-alt-F1/F2/F3 etc key combos didn’t help. Hard reboot was required.

Downgrading to kernel 6.5.12-200.fc38 (retained from the original F38 install) fixed the issue. Suspend with that kernel seems to be working okay.

In all cases the only installed expansion cards are USB-C in (1), and USB-A in (4). USB-C had a charger connected to it.

As per @jonp’s suspicion over the HDMI expansion card, I removed my HDMI expansion card (slot 4), booted my system (secure boot, luks, fedora 39), logged in, opened a couple of apps and then closed the lid for two hours, all on battery power, starting the test at ~60%

Left-hand side expansion cards Right-hand side expansion cards
1. USB-C 3. USB-C
2. USB-A 4. Empty (used to be HDMI)

Upon opening the lid, the screen was blank (backlight on) for ~70 seconds before I was presented with the login screen. I logged in and a couple of GUI applications had errors. Battery was far from empty (somewhere above 40%). I attempted to open a terminal twice to do a write test with $ touch as I didn’t already have a terminal open, but gnome-terminal failed to open both times.

I then pressed ctrl, alt, F3 to move from my graphical gnome session to tty3. About 4 error messages appeared (can’t remember exactly what they were about, I believe something about btrfs?) and was then on a blank screen with a single blinking underscore in the top left for a few seconds, before these errors began being printed to the screen:

TLDR: A 2 hour suspend with no HDMI expansion card still resulted in a read-only system after waking (which took 70 seconds).

Perhaps relevant, as my framework used to be Intel, I’m using 2022 expansion cards which came with my original Intel framework, now plugged into an AMD motherboard.

I’m going to try disabling secure boot next, whilst keeping the suspect HDMI expansion card disconnected.

EDIT: After removing the kernel arguments module_blacklist=hid_sensor_hub and nvme.noacpi=1, my system has been waking from suspend immediately with no read-only problems :tada:

Will post again after longer term testing where I plan to slowly re-enable secure boot and reinstall the HDMI expansion card if all goes well.

~24 hours so far with HDMI expansion card disconnected, no suspend/resume failures.

Edit: Went to a co-working space today, and this happened :face_exhaling:


@goldenspinach Just upgraded to 6.6.2-201.fc39 yesterday with no issues resuming here.

Also: as an update, since removing the HDMI card 3 days ago I’ve not had a single issue with resuming.

I’m not entirely sure about the graphical issue others are seeing, but I have the amdgpu.sg_display=0 kernel option set because I did experience that earlier and haven’t since.

1 Like

Whoops. Much :face_with_hand_over_mouth:
Does the expansion card have a full size HDMI, or a mini one?

It’s a full-size HDMI :+1:

@mailtodevnull Yeah, the lack of HDMI is a bummer. Currently experimenting with a small USB-C → HDMI dock. Will report observations.

HDMI Expansion only goes in the Front Port on the Right side. NOT the left per the SLOT compat matrix.


WILL break things DO NOT use on AMD.

Have you been using rtc_cmos.use_acpi_alarms=1 ? This fixup is incorporated in 6.6 fc39 kernel. If you haven’t been using it then that is likely the cause of suspend issues.

I haven’t been using scatter gather disabled for the last week with 6.6 and 6.7 kernels and haven’t hit issues . But DO make sure UMA_GAME_OPTIMIZED is turned on in bios.

You can’t use HDMI on the left side?

So looking at step 12 of the DIY guide, it doesn’t clearly specify HDMI, but it does say that “display” is only for slots (1), (3), (4).

The Adapter is a DP to HDMI converter - so needs DP Alt mode support on the port. Which the left front doesn’t have. So yes. It can’t go in the left front port.

If you use a USB to HDMI adapter that uses displaylink - which is a terrible way of using compression tricks and virtual framebuffer emulation over USB (which is a POS in my NSHO) - then you could probably use the front Left Port as it’s just tunneled over USB2 or 3 if you’re lucky. You generally find displaylink converter in cheap adapters (j5create) and some crappy hubs or conference room kits. It does mostly work in recent mainlines - but it for years was a gigantic nightmare and still has issues .

1 Like

… interesting… perhaps that’s what is causing this issue? I’ll try installing the HDMI expansion card in a different slot.

@jwp @goldenspinach
I think this business about the HDMI card not being able to go into slot 2 was the problem for me actually. I’ve been running with the card in slot 4 without issue for several days.

@Matt_Hartley I’d suggest updating the Quick Start Guide to make this restriction on the HDMI card placement and suspend bug painfully clear until this bug is squashed. Perhaps a warning, or update to the diagram to include a big X with HDMI in slot 2. I blew past that step without looking closely at the diagram, and certainly wouldn’t have expected suspend issues because I put the HDMI card in the wrong slot.

1 Like

That is my experience as well, now that I have moved the HDMI expansion card to slot 4, I have not had a single suspend issue.

A little embarrassing here, but I was so excited when I unboxed that I did not see the quick start guide at all :smile:

1 Like

Checking the HDMI slot seems, at least by my preliminary assessment, to have fixed issues with suspend for me too. Also missed that in the setup instructions and didn’t think to look there for troubleshooting a suspend issue :sweat_smile:.

Described here Reboots instead of waking from sleep -- when plugged in to AC power? - #3 by mpascale