AMD FW 13 - Sandisk WD Black SSD missing ACPI attributes

I’ve been diagnosing some issues with sleep, and I came across @Mario_Limonciello 's excellent script.

The report is showing:

:x: NVME Sandisk Corp WD Black SN850X NVMe SSD is not configured for s2idle in BIOS

With additional info:

🚦 Sandisk Corp WD Black SN850X NVMe SSD missing ACPI attributes
	An NVME device was found, but it doesn't specify the StorageD3Enable
	attribute in the device specific data (_DSD).
	This is a BIOS bug, but it may be possible to work around in the kernel.

Has anyone encountered and/or fixed this issue?

System: Framework Laptop 13 (AMD Ryzen 7040Series) (Laptop) running BIOS 3.5 (03.05) released 03/29/2024 and EC unknown
Kernel: 6.1.0-21-amd64

Can you post the full script log? Also if you haven’t installed it install the python3-systemd package and re-run it.

Sure thing, python3-systemd is installed. I’m having a hard time pasting the log to this post, but here’s a link:

https://pastebin.mozilla.org/Vy3LKRJD

Can you run the script as root?

I ran it as root and the SSD is showing as configured for s2idle and it’s asking me about suspend cycles.

I’m diagnosing an issue where it wakes from sleep on its own (which is how I found your script).

I tried running with a few sleep cycles of 5 minutes each, and when I returned the system had restarted itself. Looking at the logs, it only made it through the first cycle, and crashed/restarted sometime during the second.

The initial reported issue about the SSD seems to be from me not running as root, so I guess this particular thread can be closed. I’m probably going to switch to something supported, running on Debian 12 has been an absolute nightmare.

Attaching the log running as root – I tried 3 cycles of 5 min suspends, the second one killed it – in case it’s helpful.

Log: Mozilla Community Pastebin/rmxQc9aa (Plain Text)

(is there a better way to paste log files here? When I try to paste in a code block it gives me a 403 when I try to post)

So your kernel is very likely missing platform/x86/amd/pmc: Extend Framework 13 quirk to more BIOSes · torvalds/linux@f609e7b (github.com).

Can you move to a newer kernel?

That’s the approach I started with. I tried some 6.6 and 6.7 kernels from Debian backports, but for some reason both break my WiFi. Oddly, the card is able to see and even connect to other WiFi networks, like my mobile hotspot, but connecting to my home wifi hangs on device after authentication without any helpful error message other than a timeout. I’m sure that’s fixable.

I’ll keep at it for a bit more and see if I can’t get things rolling with distro hopping. I’ve followed most everything in the guides to no avail.

It looks like that particular quirk wouldn’t be in those kernels anyways – is there a version you’d recommend best for Framework 13 AMDs?

That commit did get backported to 6.6 stable and later:
[PATCH 6.6 089/158] platform/x86/amd/pmc: Extend Framework 13 quirk to more BIOSes - Greg Kroah-Hartman (kernel.org)

But it didn’t come to 6.1, contextually it’s missing too much code to work.

I personally use 6.9 on F13 AMD all the time. I run CachyOS on mine.

Great!

I’m going to see if I can solve the wifi issue and get 6.7 backports going. I really have no particular allegiance to Debian other than it was the best distro for me when running on Surface hardware, but there’s a bit of “I’ve come this far…” at play… :joy:

Thanks a ton for the help and the info!

1 Like

So my personal opinion is that Debian moves too slowly for modern hardware. You’ll end up with older mesa and linux-firmware for too long.

I think Fedora 40 and Ubuntu 24.04 are great balances between stability and quality. Arch/CachyOS are rolling distros so you’ve always got the latest and greatest, but you also get the regressions the quickest.

I also work on fwupd upstream, and I’ll tell you at least 90% of the release day bugs are Arch users. They’re usually real bugs, they just catch them first because they roll with the punches.

1 Like

I’m a huge fan of Arch, I eyed it first when sorting which distro to use. CachyOS looks interesting, I’d have to knock the rust off (or the rust accumulated!) from running Debian, but I’m sure it’s just like riding bike – boy do I miss PKGBUILDs!

Which kernel are you running out of the CachyOS offering?

I’m using the default (linux-cachyos) but mostly because I haven’t given the rest of them an honest shot yet!

1 Like

I ended up coming across this (!!):

I was able to get the 6.9 cachyos base kernel compiled and installed with the help of that nice script. Things are running great, although I do think I still need to work on some sleep stuff. The lid closed for roughly 7 hours drained about 60% of the battery. I haven’t started messing with anything there, yet.

Geekbench scores: Framework Laptop 13 (AMD Ryzen 7040Series) - Geekbench

Blazing!

Thanks for the tip on CachyOS!

Cool! I used the GUI installer.

Make sure you’ve got PPD (0.21 or later!) installed for managing runtime power consumption (I don’t recall if I had it by default in cachy or manually installed) and if you have power issues over suspend you should run scripts/amd_s2idle.py · master · drm / amd · GitLab

I’ll get PPD upgraded – for clarification I’m running Debian 12 but using the CachyOS 6.9 kernel. Not on Arch just yet :slight_smile:

Hey @Mario_Limonciello, do you know what to do for the FW 15 in this case?

Apparently, this workaround exists only for FW 13 according to this

To clarify, I have exactly the same output from the script:

:x: NVME Sandisk Corp WD Black SN850X NVMe SSD is not configured for s2idle in BIOS

And subsequently I am having issues with suspend

Huh? You’re conflating a bunch of stuff. The lid wakeup issue is only on Framework 13. There is no such thing as Framework 15, presumably you mean Framework 16.

What kernel?

If you’re having issues with suspend, share the full output from the script, it will help characterize the situation and most of the debug information needed. Do you have two SSDs? Maybe there is a problem with just one of them? We did make a kernel change that applies policy to more SSDs in the system on AMD side in recent kernels.

Yes its FW 16, that was a typo.

I do experience issues with suspend on a single SSD:

  • Hot lid
  • IO errors after suspend

I will provide the full results from the script once back to the laptop, but it shows green checkmarks for everything besides mentioned point.