Whoops. Much 
Does the expansion card have a full size HDMI, or a mini one?
It’s a full-size HDMI 
@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.
nvme.noacpi=1
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.
1 Like
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).
1 Like
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.
2 Likes
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 
2 Likes
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 
.
Described here Reboots instead of waking from sleep -- when plugged in to AC power? - #3 by mpascale
Came here to find a solution, my suspend is not turning on but i have my HDMI in slot 4 so it seems to not be the case,
of course I am on the fedora 40, bios 3.05.
I also regularly have issues with waking from suspend, on Ubuntu 24.04, and I don’t have any HDMI expansion cards installed, only 3 USB C and one USB A in the correct spot to avoid excess power draw. What can I run to gather day about this happening? It happens probably at least once a week for me. I saw some stuff somewhere about it being related to suspending while plugged in and I try to unplug before suspending nowadays but I still have this problem. It’s quite annoying.
1 Like
I’ve encountered this with suspend or hibernate (unsure which state the machine was in when this was triggered, likely hibernate) on a framework 16 and opensuse tumbleweed this week.
Whilst the system did appear responsive and allow GUI login initially, the nvme drive (sk hynix p41 platinum) appeared to be readonly, and switching to a tty revealed the same output that was in post 39 - namely log rotate and btrfs errors. I could not log in or do anything other than hard power off.
The kernel arguments are
BOOT_IMAGE=/boot/vmlinuz-6.12.6-1-default root=/dev/mapper/system-root loglevel=6 resume=/dev/system/swap mitigations=auto security=apparmor
And the USB peripherals in use were usb c in slot 1, 4 & 5, HDMI in slot 2, audio out in slot 3 and usb a in slot 6.
I could not login to the tty and was unable to get any further logs or diagnostics, which were obviously gone after powering off. I had considered switching to fedora as it should be supported, however it looks like this may be a cross distribution firmware or kernel bug?
This hints at a ssd hardware fault.
Does a “btrfs scrub” show any errors.
Look in the man page to understand what scrub does.
Also “smartctl-a devicename” might show some useful output so please post it here.