Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.29.0
Qt Version: 6.11.1
Kernel Version: 7.1.9-200.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 9 7940HS w/ Radeon 780M Graphics
Memory: 32 GiB of RAM (30.6 GiB usable)
Graphics Processor: AMD Radeon 780M Graphics
Manufacturer: Framework
Product Name: Laptop 16 (AMD Ryzen 7040 Series)
System Version: AJ
BIOS version: 04.05
I’ve installed Fedora 43 when got the laptop, and since then, I’ve upgraded it to 44.
I have the Dual M.2 adapter installed in my laptop, and every time I put it to sleep, the first, physically the furthest port always get lost. I have asked help from AI so I could gather a view on what is happening. Reading the journal, it seems that a data link layer reset timeout occurs, after which the system just disables the PCI port. What I have not yet tested, if only put one SSD does the same, but what I gathered from other post that something similar might occur, but they only used one SSD, so it may also fail too, maybe?
Based on the conversation with AI, I have made a list of command that ran to see what is going on, and share the output of these commands below.
Can you help make it functional? Do you know maybe a ticket tracking anything related to this?
The output is too long to share, so I’ve uploaded it to my Google Drive. Sorry about the inconvenience.
I can share atleast the diff that I’ve used to draw my final conclusion.
I haven’t read of this issue anywhere else, but I have observed it.
I sometimes lose an SSD after sleep on both Ubuntu and Windows 11. It’s always the nvme slot towards the rear of the module.
Only FreeBSD appears to be immune, but I think that is because it doesn’t support any sleep states for this CPU 
My hypothesis is that something in the firmware reduces the width of the expansion module PCIe when the system sleeps (from 8x to 4x for example) and then it’s not back to normal before the OS tries to wake the SSD (and fails). But that’s kind of just my gut feeling about it…
I spent a ton of time troubleshooting other possibilities, just in case, so I have very thoroughly ruled out the SSD failing, the dual M2 board failing, and the interposer.
I see, then I didn’t break anything. 
Is it possible, that the 100ms timeout is too short? If it is possible to increase up to something huge solely for testing purposes, like 1~2 minutes (which I don’t know how to do), it could show, if it is the device being too slow for the driver. Although this issue occurring under Windows too is foreboding. I have dual-boot with Windows, but I avoid booting in to it, if possible, and so I have not experienced it.
AI also suggested changing the PCI device not to turn to L1.3 power state (i.e. completely off), but I didn’t go in that direction (I don’t trust AI that much.) and I ran out the free tier before even could get there.
Yeah, I don’t think that it is a driver problem, especially since it is OS-agnostic…
The system firmware was developed with the dGPU modules in mind, so it probably just assumes that a single device is using all 8 lanes. In that case, it is perfectly safe to turn off all but 1, 2, or 4 lanes in a sleep state. You only need one line open to communicate over when the system wakes.
But when the lanes are split between 2 devices, turning off 4 or more lanes would completely disconnect a device, so no signal to wake it back up could reach it.
Chiming in to say I’ve noticed the same problem. I was using the furthest port as my Fedora OS drive, and every time after suspending, my entire OS didn’t work anymore. It seems it was just running on its RAM reserves, as nothing could be read from or written to the OS SSD. This seems like a pretty big issue for people that want to dual boot or triple boot, or just simply need the furthest slot to function after suspend.
This is on the latest BIOS (4.05) and a Ryzen 9 7940HS.
Yeah, the only reason it hasn’t been much of a problem for me is that I use both slots for a zfs mirror, so one drive going offline until I reboot is kind of okay (and I sort of fixed it by disabling suspend lol)
Not a problem at all that I have expirienced on my Ai9 HX 370.
I have Fedora KDE running as my main OS on the 2ns slot nvme1**** which is my main every day drive and due to Fedora KDE Desktop Edition is pretty much cutting edge, it sees at least 2 reboots a week if not more due to updates.
While nvme0******* runs a Windows 11 Pro OS. I have booted into it 3 to 4 times since receiving the new Laptop and zero issues.
I run the latest BIOS for Ai300 but didn’t have an issue even with the original BIOS.
I think you might have missed that this problem is only on the dual m.2 expansion board, not the dual m.2 slots on the mainboard.
Like, we have 4 nvme drives
1 Like
Yes, I did. Thanks for pointing that out.
FYI I’ve updated the title to make it more clear what is this topic about.
1 Like
