[RESPONDED] AMD 7040 Setting Storage Password breaks resume from suspend

I have a Framework Laptop 13 with the Ryzen 5 7640U

When I set a storage password in the BIOS settings for the SSD (NOT master HDD password, and NOT supervisor password), resuming from suspend (s2idle) always results in an unreadable storage disk until I do a full power cycle. If I do not set a storage password, this problem never occurs. Can anyone else reproduce this issue?

Specs: I am running Linux (Debian 12 with recommendations from the community thread), and BIOS version 3.03. My SSD is the WD Blue SN580 1TB.

1 Like

Try disabling iommu (amd_iommu=off) or putting into passthrough (iommu=pt).

If either of those workarounds help it clarifies that the BIOS bug is specifically with iommu handling for that password.

Neither workaround helps (amd_iommu=off nor iommu=pt).

I forgot to mention that I also have Secure Boot enabled. Kernel version is 6.5.10 (deb version 6.5.10-1~bpo12+1)

In that case this is a BIOS bug I’ve never seen before. I suggest you file a ticket with framework to dig into it.

1 Like

I’m having this issue as well when resuming from s2idle on my AMD Framework 13.

The problem occurs with secure boot disabled, HDD storage password enabled. No issues with the storage password disabled. Workarounds from the “Suspend” section of the Framework Laptop 13 - ArchWiki page are ineffective.

OS: Linux (Arch)
CPU: Ryzen 7, 7840U
BIOS: 3.03
SSD: Samsung 990 Pro 2TB (MZ-V9P2T0B/AM)

Status update: I have been in contact with Framework support since 2023-12-26. After six correspondences, we are no closer to actually root-causing the problem.

I am disappointed by the quality of support from Framework Support.

  • They gave incorrect and unclear instructions to reset the mainboard (and later, a slight different set of instructions with fewer steps that actually works)
  • They gave me a set of terminal commands that fails to capture any system or kernel logs. I pointed out the mistakes, but they did not acknowledge it in their response. I just replied with a set of corrected commands.
  • Their responses lack of attention to previous correspondences. I have had to repeat several key details (e.g. the fact that I have reset my mainboard, my installed Linux distro). In their last response, they made the illogical request to capture logs after installing an officially supported distro to the SSD. Not only have they failed to acknowledge the invalid logging commands, but they also failed to understand that it’s impossible to capture any logs from a system running on the SSD (with storage password set) after resuming from s2idle.
  • They asked if I had a different SSD to test with. I didn’t have one, so I ordered a WD_BLACK SN770 just for this issue and told them to let me know (twice!) if they actually need the SSD. They have yet to acknowledge that I ordered the SSD.

The only reason I continue to work with Framework Support is it’s the only way I know of to actually reach the core Framework team. I firmly believe the core team is interested in diagnosing and fixing bugs like these. However, I hope my message encourages Framework to evaluate its Support team and improve, for the sake of its customers.

1 Like

I have the ticket now, I will be replying in the ticket from here on.

The initial contact team was running through our usual process, but yes, this is different.

I will be replying to your ticket directly from here on as I have it in my personal queue.

Some considerations going forward:

  • This was a very uncommon ticket inquiry. We recommend LUKS vs storage password in the BIOS.

  • Debian is not a tested distro. We test against and support Fedora 39 and Ubuntu LTS.

  • I am replicating this now using Fedora 39. I will update in the ticket, but suspect this will be a bug in how the BIOS interacts. Officially, we recommend LUKS. But if I can replicate this, I will escalate this to the engineering team.

  • And finally, I went through the ticket replies personally. Everything, everything they asked was correct and expected. The first contact team did everything to the letter as we would expect them to do.

If you feel this is not meeting your expectations, I would ask you to review the email thread again as I see absolutely nothing but correct procedure presented in what I read.

Matt

1 Like

@Matt_Hartley - Thanks for following up.

I can’t speak for others, but I use both LUKS and storage passwords (or, i used to, before i got a Framework laptop). Keep in mind, when using LUKS, the boot loader is not encrypted. This can be mitigated by going through the trouble of setting up secure boot, but it’s not ideal. This is part of why i use Samsung SSDs to begin with: they support transparent encryption, so locking the drive means that it’s also secured with another layer of encryption.

Update: I’ve wrapped up the conversation with Matt. The current recommendation is still LUKS (and Bitlocker on Windows), but he has put in a feature request to officially support SSD hardware encryption/storage passwords.

Matt also tried reproducing the issue with his own AMD Framework and a WD PC SN740 512 GB, but strangely he is unable to select the option in the BIOS to set the storage password, even though it is visible. We weren’t able to determine the cause.

Also regarding my last message, Matt and I have discussed them in more detail. For the record, I’d like to thank Matt for taking in the feedback and resolving all the remaining questions I had.

@Matt_Hartley Please feel free to correct me on any of the above.

1 Like

I have the same problem with a SK hynix Platinum P41/PC801 on a stock 6.7.3 kernel.
No secure boot, enabling hard drive password in the bios breaks s2idle resume.

I also completely agree with you regarding hard drive encryption in addition to LUKS.

To be clear, is the current state is that using the BIOS to set a hard drive password is supported but only when not using s2idle?

Yep, that looks good to me. Thank you for reaching out to me and working with us.

1 Like

Appreciate you sharing your experience as well. At this point, we are recommending LUKS as hardware encryption is not supported at this time.

1 Like

I have the same issue. It’s quite disappointing that it’s unsupported because when dual booting, hardware encryption is the most convenient option.

1 Like