AMD Framework and NVMe SSD Enclosure Compatibility Investigation

Jason_Username_Taken · December 10, 2023, 2:29am

There seems to be compatibility issues between NVMe SSD enclosure and AMD Framework. I invite everyone who also have AMD Framework and NVMe enclosure to collectively experiment and report our findings. Hopefully by doing this, we can identify any patterns, root cause an issue if indeed present, and ultimately assist Framework engineers in addressing it.

Fault observed:
NVMe SSD in USB enclosure (not Thunderbolt) drops connection during sustained Read/Write activity. After the disk dropping, it could be hard to re-connect.
(SATA SSD enclosure doesn’t seem affected at all)

My setup:
AMD7840. BIOS 3.02. Windows 11. Launch-day Driver, OCT-24-2023 Driver, and no driver. Sabrent EC-SNVE Enclosure running factory v1.23.5 and latest v1.32.87 firmware. Silicon Power A60 2TB SSD. Multiple known-good Type-C to Type-C cable of unknown rating (one of them is the Sabrent cable).

Steps to Reproduce:
With said enclosure & SSD connected, initiate a sustained R/W activity to the disk. I have done this by running a CrystalDiskMark session, perform a slow formatting, or simply copy a larger file (~10GB). The disk will drop before any of these activities could finish. After a disconnect has occurred, I find it difficult to reconnect. A ‘cool down’ period ranging from a few minutes to hours may be required. Before a successful reconnect can be established, there’s some activity can be seen from the enclosure LED and SSD LED, maybe they are boot-looping. Unplug & replug couldn’t bypass this ‘cool down’ period.

Additional Details:
To further investigate, I tried both the full-feature (upper) port, and limited-feature (lower) port. Same fault behavior, and after a disk drop has occured, moving from an upper port to a lower port, and vice versa, cannot bypass the ‘cool down’ period.

I tested with launch day driver, OCT-23-2023 driver, and no windows driver. Same result

I also installed WinToGo (yes, I know that’s technically no longer supported, but I use it on a regular basis on multiple computers, it does work at least for now) on said external SSD, booted from it, and ran a disk benchmark. Before the benchmark could finish, OS will blue screen with INACCESSIBLE_BOOT_DEVICE. After rebooting into F12 boot selector, the disk continue to exhibit ‘cool down’ symptoms and cannot show up in boot selector. I take this as an indication that this is OS-agnostic.

Isolating Issue to AMD Framework:
I have conducted same test on an Intel 12th Gen Framework (3.05 BIOS), and an Intel non-T2 A1707 MacBook Pro running Windows 11. The enclosure/disk can undergo the same R/W workload and more without experiencing any issues. Further more, when the disk drops on the AMD Framework, immediately moving it to the 12th Gen FW or MBP and it will continue to work right away (and keeps taking a sustained load), indicating the SSD/Enclosure isn’t undergoing thermal or other similar faults.

Why Am I Still On 3.02 BIOS?
When community member patagona (their extremely detailed post) and a few others discovered 3.03 potentially introduced some PD-negotiation problem (although some of those issues are also reproduceable with 3.02) causing certain chargers unable to work, I decided to camp the 3.02 BIOS and just not use the AMD Framework until this charging bug is addressed. Especially as of now there’s no way to downgrade to 3.02, and Kieran has acknowledged under patagona’s post that a fix could come with the next BIOS release. Right now, in light of this NVMe Enclosure issue, I invite others on 3.03 to conduct the same test, while I continue to camp on 3.02, creating the ability to compare if 3.02 vs. 3.03 has any relevance.

Am I Crazy? Other Cases?
Community member Kelly_Wu also reported they are encountering issue with AMD FW & NVMe enclosures. However, it seems like in their case, they can’t function at all. They also reported some different Type-C related issues in their post.

To conclude, I invite everyone with AMD Framework and NVMe enclosure(s), 3.02 or 3.03, Windows or Linux to also test and share your result. I believe any further information we collectively discover can assist Framework engineers to iron out their AMD-based platform, or maybe, even preventing any of these issues from being present in the FW16.

When posting, I hope we all can present our information in a well-organized and clearly readable fashion. I understand issues can be frustrating, I feel the same too, I really want to promote the AMD Framework to daily driver but couldn’t. However, perhaps still present our empirical testing result first, and commentary after. We also should keep in mind that while bugs indeed still remain on AMD boards, engineers at Framework has done many more good things. We are all better off by encouraging them, provide any information to help them root-cause and fix any issues, than making commentaries that are not constructive and lowering spirit.

I’ll also update my post for anything new. Please feel free to point out if I have made any mistakes or omitted any information.

[Update 1]

DEC-10-2023. A night after the initial post, I am no longer able to get the enclosure/SSD detected by AMD Framework at all, in Windows and in BIOS. The enclosure LED and SSD onboard LED appears to show power cycling. I triggered ‘Battery Disconnect’ feature in BIOS with no RTC battery connected, then left laptop sitting for a few minutes. After powering back up, I confirmed the computer lost time (and perhaps some BIOS settings fell back to default), however, the enclosure/SSD still won’t work.

I’m still camping 3.02, I hope someone on 3.03 can help in performing the same sustained R/W test.

Adrian_Joachim · December 10, 2023, 5:58pm

Do you know what chipset your enclosure is based on?

I have tried 2 RTL9210 based nvme to usb enclosures in my amd framework and those worked just fine on all ports both with usb-a and c. How long are your sustained reads for the fault to occur, I only did a couple GBs. Gonna try a bit more just to make sure.

I am on bios 3.03 though. Personally don’t think the somewhat less bugged pd negotiation is worth the a lot more bugged igpu XD.

Edit: Yeah I just read (dd) 100GB from both (one in the back left usb-c port and one in the front left usb-a port) at the same time, each at a bit shy of 1GB/s.

RTL9210 and RTL9210B do seem to work fine with the amd framework at least in my case.

Jason_Username_Taken · December 10, 2023, 10:44pm

Thank you very much for your help testing this.
I dissected my Sabrent EC-SNVE, and confirmed it is RTL9210B. The firmware upgrade tool provided by Sabrent is also a Realtek tool.

In this case, it seems like the issue could potentially be with my particular unit of AMD Framework, or 3.02 (or other variables that aren’t yet discovered). Now I’m tempted to update to 3.03. I think I’ll still hold off for a bit more in case something else pops up that could be tested on 3.02, especially considering pretty much everyone is on 3.03 now.

(In terms of PD, yeah, one of my favorite 30W PD charger doesn’t even work on 3.02, but considering other folks reported Steam Deck charger was working on 3.02 but not 3.03, I’m just waiting to see what is the next step. I couldn’t daily use it until the PD bug is patched anyway)

Adrian_Joachim · December 10, 2023, 10:50pm

Even with kickstarting (plugging in a higher wattage psu and the unplugging that)? Pretty much all chargers work on 3.03 with kickstarting but I hope this’ll get fixed in the next version.

That is a generous sacrifice XD

Jason_Username_Taken · December 10, 2023, 11:21pm

That’s a good point. I heard about the ‘kick-starting’ technique but haven’t got around to test it. As when I do need to use a small charger, that means I don’t have any means to ‘jump-start’ anyway, therefore, a patch would still be required.
(my 12th Gen Framework is quite reliable in this regard. It will charge with a potato if I want it to.)

Btw, forgot to answer one of your previous question. For load generated by file copying, it will not finish writing 10GB. When running CrystalDiskMark ‘all’ with default 5/1GiB, the run won’t finish. But like I said, I can’t get it to be detected at all now, don’t know why. (Just hammered it with 100GB of writing with 12th Gen Intel Framework, the SSD and enclosure definitely work)

Bruce_Wilbur · December 11, 2023, 12:57am

I’ve been having external NVMe issues as well. This on an FW13 (AMD) BIOS 3.03 running Linux (Ubuntu Studio 23.10). I’ve experienced the issues described below with both Samsung 970 EVO (2TB) and Crucial P3 Plus (4TB) units inside an Acasys TBU405ProM1 enclosure and another cheap one I’ve already returned as defective.

I haven’t complained since I’m running an unsupported Linux, I planned the external NVME for only backup purposes, and have a workaround with external hard-drives.

First, plugged into either USB-C (I have two, inserted into slots 1 and 3), the Acasys Thunderbolt external unit is identified as such and enabled in System Settings, but is invisible to Dolphin (KDE’s default File Manager) and grsync (used to backup the FW).

With another cable and plugged into a USB-A port (again two, slots 2 and 4) it is seen just fine by the file manager and backup. Of course as a 3.2 device.

Extended writes using grsync for backups starts encouragingly, but the transfer rate rapidly degrades to negligible (mere kbps). I give up after an hour or so.

Using an external hard drive (I have both Seagate and WD 4TB units) in the USB-A ports results in expected operation and write rates.

While I’ve repeatedly tried to get it working, I’ve been less than rigorous in recording results. This is all from memory. Disgusted, I’ve shoved it all in a drawer. Should someone feel fully documented tests will be useful, I can take a stab at it next weekend.

Jason_Username_Taken · December 11, 2023, 3:05am

Interesting! When I am booting WinToGo off NVMe enclosure on the AMD FW, I noticed quite a few instances of seconds-long lags, something won’t happen even when booting off a SATA-based WinToGo (I use it on a regular basis). I brushed it off as due to newly installed OS. Then, when I was running a system drive benchmark within the WinToGo environment, I did see the disk speed dropping significantly before the disk completely disconnecting and enters INACCESSIBLE_BOOT_DEVICE BSOD.

Thank you very much for your information. There seems to be some similar pattern.

Scott_H · December 11, 2023, 5:53pm

@Jason_Username_Taken

I had a similar issue with a sabrent EC-SNVE. If you call their support they have firmware updates for the realtek controller they can send to install on yours. In my case the firmware updates did not resolve the random disconnects I experienced, so sabrent replaced the unit. The replacement has been working well.

Jason_Username_Taken · December 12, 2023, 5:06pm

Yup, I did update the EC-SNVE’s firmware, and that fixed an unrelated issue with a Windows manual eject behavior.

However, the possibility of a defective enclosure couldn’t explain why this enclosure works smoothly on 12th Gen Intel Framework, and another non-Framework computer.

Michael_Wu · January 1, 2024, 11:22am

I can 100% confirm/reproduce the issue (with only a Samsung PM951), on all ports of my AMD 7840U mainboard, while it’s okay on my 11th gen Intel i7-1165G7 mainboard (and other devices).

TLDR

A Samsung 1TB P951 SSD in 3 different enclosures with 3 different chipsets work perfectly in my other devices including my previous Framework Intel i71165-G7 mainboard but do not in my Framework AMD 7840U mainboard. It exhibits the same issue @Jason_Username_Taken described, with USB3 5Gbps and 10Gbps where copying a large file (e.g. 10GB) will reset/disconnect the SSD/enclosure). It does work when connected to the (I think powerered) USB3.1 Gen 1 5Gbps hub of my monitor which is then connected to the USB-C port of the mainboard, as well as forcing USB2 with a cable/adapter. I think it might be a USB3 specific power overdraw issue that’s causing it since it works with the USB3 hub in the middle or forced into USB2. This same behavior happens on both Windows and Linux, on different kernel versions, so I’m fairly confident it’s not because of an operating system/driver/kernel error. I’ve also tested various enclosure chipset firmware including the respective latest versions — no dice.

System:

AMD 7840U mainboard swapped into 11th gen Intel body.
BIOS 3.03 since day one when I received in early November. I experienced the issue within the first week and did not test BIOS 3.02, but @Jason_Username_Taken has issues on 3.02 as well.

My AMD 7840U mainboard test results

The transfer tests were run by copying 10GB to the SSD (e.g. fallocate -l 10G / rsync -ah --progress [src] [dest]).

Enclosure	Chipset	Samsung PM951: 10GB File transfer	SK hynix Gold 2TB P31: 10GB File transfer	LITEON C A3-8D512512GB: 10GB File transfer	Notes
Plugable USB 3.1 Gen 2 (10Gbps) NVME Enclosure	JMicron JMS583	Fails	Succeeds	Succeeds	I’ve had this since 2019, and it’s worked in all my devices including my previous Intel i7-1165G7 mainboard. The internet says it’s not a stable chipset, but it runs perfectly fine (very well, high speeds) on that Framework Intel mainboard.
Plugable USB 3.1 Gen 2 (10Gbps) NVME Enclosure	Realtek RTL9120 (non B)	Fails	Succeeds	Succeeds	Plugable sent me the updated version (super appreciated). It’s slightly more “stable” on the AMD 7840 mainbord, as the JMicron JMS583 version can hang processes and it seems both the RTL9120B and non-B reset cleanly, although still unfortunately reset.
Sabrent USB 3.2 (also 10Gbps) NVME Enlosure (EC-SNVE)	Realtek RTL9120B	Fails	Succeeds	Succeeds	Same enclosure as @Jason_Username_Taken’s. Got this as I thought my old Plugable JMicron JMS583 enclosure was broken (it wasn’t).

Basically, after a few gigabytes are transferred, the SSD/enclosure will reset/disconnect. Here is a sample of journalctl logs when it resets/disconnects:

kernel: usb 6-1: USB disconnect, device number 3
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: usb 6-1: cmd cmplt err -108
kernel: sd 0:0:0:0: [sda] tag#14 uas_zap_pending 0 uas-tag 1 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#14 CDB: Write(10) 2a 00 28 67 3d 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#15 uas_zap_pending 0 uas-tag 2 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#15 CDB: Write(10) 2a 00 28 67 41 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#9 uas_zap_pending 0 uas-tag 3 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#9 CDB: Write(10) 2a 00 28 67 45 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#18 uas_zap_pending 0 uas-tag 4 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#18 CDB: Write(10) 2a 00 28 67 49 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#19 uas_zap_pending 0 uas-tag 5 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#19 CDB: Write(10) 2a 00 28 67 4d 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#16 uas_zap_pending 0 uas-tag 6 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#16 CDB: Write(10) 2a 00 28 67 51 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#10 uas_zap_pending 0 uas-tag 7 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#10 CDB: Write(10) 2a 00 28 67 55 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#17 uas_zap_pending 0 uas-tag 8 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 28 67 59 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#11 uas_zap_pending 0 uas-tag 9 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#11 CDB: Write(10) 2a 00 28 67 65 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#8 uas_zap_pending 0 uas-tag 10 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#8 CDB: Write(10) 2a 00 28 67 75 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#12 uas_zap_pending 0 uas-tag 11 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#12 CDB: Write(10) 2a 00 28 67 35 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#13 uas_zap_pending 0 uas-tag 12 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#13 CDB: Write(10) 2a 00 28 67 39 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#23 uas_zap_pending 0 uas-tag 13 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#23 CDB: Write(10) 2a 00 28 67 5d 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#20 uas_zap_pending 0 uas-tag 14 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#20 CDB: Write(10) 2a 00 28 67 61 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#21 uas_zap_pending 0 uas-tag 15 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#21 CDB: Write(10) 2a 00 28 67 69 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#22 uas_zap_pending 0 uas-tag 16 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#22 CDB: Write(10) 2a 00 28 67 6d 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#24 uas_zap_pending 0 uas-tag 17 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#24 CDB: Write(10) 2a 00 28 67 71 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#25 uas_zap_pending 0 uas-tag 18 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#25 CDB: Write(10) 2a 00 28 67 79 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#26 uas_zap_pending 0 uas-tag 19 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#26 CDB: Write(10) 2a 00 28 67 7d 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#27 uas_zap_pending 0 uas-tag 20 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#27 CDB: Write(10) 2a 00 28 67 81 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#29 uas_zap_pending 0 uas-tag 21 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#29 CDB: Write(10) 2a 00 28 67 85 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#28 uas_zap_pending 0 uas-tag 22 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#28 CDB: Write(10) 2a 00 28 67 89 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#0 uas_zap_pending 0 uas-tag 23 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 28 67 8d 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#1 uas_zap_pending 0 uas-tag 24 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#1 CDB: Write(10) 2a 00 28 67 91 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#2 uas_zap_pending 0 uas-tag 25 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#2 CDB: Write(10) 2a 00 28 67 95 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#3 uas_zap_pending 0 uas-tag 26 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#3 CDB: Write(10) 2a 00 28 67 99 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#4 uas_zap_pending 0 uas-tag 27 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#4 CDB: Write(10) 2a 00 28 67 9d 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#5 uas_zap_pending 0 uas-tag 28 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#5 CDB: Write(10) 2a 00 28 67 a1 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#6 uas_zap_pending 0 uas-tag 29 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#6 CDB: Write(10) 2a 00 28 67 a5 00 00 04 00 00
kernel: sd 0:0:0:0: [sda] tag#7 uas_zap_pending 0 uas-tag 30 inflight: CMD 
kernel: sd 0:0:0:0: [sda] tag#7 CDB: Write(10) 2a 00 28 67 a9 00 00 04 00 00
kernel: scsi_io_completion_action: 24 callbacks suppressed
kernel: sd 0:0:0:0: [sda] tag#14 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#14 CDB: Write(10) 2a 00 28 67 3d 00 00 04 00 00
kernel: blk_print_req_error: 19398 callbacks suppressed
kernel: I/O error, dev sda, sector 677854464 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: buffer_io_error: 964878 callbacks suppressed
kernel: Buffer I/O error on dev sda1, logical block 84731552, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731553, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731554, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731555, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731556, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731557, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731558, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731559, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731560, lost async page write
kernel: Buffer I/O error on dev sda1, logical block 84731561, lost async page write
kernel: sd 0:0:0:0: [sda] tag#15 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#15 CDB: Write(10) 2a 00 28 67 41 00 00 04 00 00
kernel: I/O error, dev sda, sector 677855488 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#9 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#9 CDB: Write(10) 2a 00 28 67 45 00 00 04 00 00
kernel: I/O error, dev sda, sector 677856512 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#18 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#18 CDB: Write(10) 2a 00 28 67 49 00 00 04 00 00
kernel: I/O error, dev sda, sector 677857536 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#19 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#19 CDB: Write(10) 2a 00 28 67 4d 00 00 04 00 00
kernel: I/O error, dev sda, sector 677858560 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#16 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#16 CDB: Write(10) 2a 00 28 67 51 00 00 04 00 00
kernel: I/O error, dev sda, sector 677859584 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#10 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#10 CDB: Write(10) 2a 00 28 67 55 00 00 04 00 00
kernel: I/O error, dev sda, sector 677860608 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#17 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 28 67 59 00 00 04 00 00
kernel: I/O error, dev sda, sector 677861632 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#11 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#11 CDB: Write(10) 2a 00 28 67 65 00 00 04 00 00
kernel: I/O error, dev sda, sector 677864704 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
kernel: sd 0:0:0:0: [sda] tag#8 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK cmd_age=0s
kernel: sd 0:0:0:0: [sda] tag#8 CDB: Write(10) 2a 00 28 67 75 00 00 04 00 00
kernel: I/O error, dev sda, sector 677868800 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 2
systemd-homed[1418]: block device /sys/devices/pci0000:00/0000:00:08.3/0000:c3:00.3/usb6/6-1/6-1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 has been removed.
systemd-homed[1418]: block device /sys/devices/pci0000:00/0000:00:08.3/0000:c3:00.3/usb6/6-1/6-1:1.0/host0/target0:0:0/0:0:0:0/block/sda has been removed.
udisksd[1425]: Cleaning up mount point /run/media/mwu/PM951 (device 8:1 no longer exists)
systemd[1]: run-media-mwu-PM951.mount: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit run-media-mwu-PM951.mount has successfully entered the 'dead' state.
kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
nautilus[6427]: (../src/nautilus-list-base.c:1252):real_set_selection: runtime check failed: (files_to_find == NULL)
kernel: sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
ntfs-3g[8142]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
ntfs-3g[8142]: Reading $BITMAP failed: Input/output error
ntfs-3g[8142]: Failed to allocate clusters: Input/output error
ntfs-3g[8142]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
ntfs-3g[8142]: Reading $BITMAP failed: Input/output error
ntfs-3g[8142]: Failed to allocate clusters: Input/output error
ntfs-3g[8142]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
ntfs-3g[8142]: Reading $BITMAP failed: Input/output error
ntfs-3g[8142]: Failed to allocate clusters: Input/output error
ntfs-3g[8142]: Failed to write buffer to bitmap (-1 != 8192). Leaving inconsistent metadata: Input/output error
ntfs-3g[8142]: Cluster deallocation failed (84730400, 407834): Input/output error
ntfs-3g[8142]: Failed to free clusters.  Leaving inconsistent metadata.
ntfs-3g[8142]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
ntfs-3g[8142]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
ntfs-3g[8142]: Failed to free base MFT record.  Leaving inconsistent metadata.
ntfs-3g[8142]: ntfs_attr_mst_pwrite: written=-1: Input/output error
ntfs-3g[8142]: Error writing $Mft record(s): Input/output error
ntfs-3g[8142]: MFT record sync failed, inode 5: Input/output error
ntfs-3g[8142]: ntfs_attr_mst_pwrite: written=-1: Input/output error
ntfs-3g[8142]: Error writing $Mft record(s): Input/output error
ntfs-3g[8142]: MFT record sync failed, inode 5: Input/output error
ntfs-3g[8142]: Unmounting /dev/sda1 (PM951)
ntfs-3g[8142]: Failed to sync device /dev/sda1: Input/output error
ntfs-3g[8142]: Failed to fsync device /dev/sda1: Input/output error
ntfs-3g[8142]: Failed to close volume /dev/sda1: Device or resource busy
kernel: usb 6-1: new SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd
kernel: usb 6-1: New USB device found, idVendor=0bda, idProduct=9210, bcdDevice=20.01
kernel: usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 6-1: Product: RTL9210
kernel: usb 6-1: Manufacturer: Realtek
kernel: usb 6-1: SerialNumber: 012345678924
kernel: probe of 6-1:1.0 returned 6 after 33 usecs
kernel: scsi host0: uas
kernel: probe of 6-1:1.0 returned 0 after 44402 usecs
kernel: probe of 6-1 returned 0 after 73125 usecs
kernel: scsi 0:0:0:0: Direct-Access     PM951 NV Me SAMSUNG 1024G 1.00 PQ: 0 ANSI: 6
mtp-probe[9185]: checking bus 6, device 4: "/sys/devices/pci0000:00/0000:00:08.3/0000:c3:00.3/usb6/6-1"
mtp-probe[9185]: bus: 6, device: 4 was not an MTP device
kernel: probe of 0:0:0:0 returned 19 after 5 usecs
kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
kernel: sd 0:0:0:0: [sda] 2000409264 512-byte logical blocks: (1.02 TB/954 GiB)
kernel: sd 0:0:0:0: [sda] Write Protect is off
kernel: sd 0:0:0:0: [sda] Mode Sense: 37 00 00 08
kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
kernel: sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
kernel: sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes
kernel:  sda: sda1
kernel: sd 0:0:0:0: [sda] Attached SCSI disk
kernel: probe of 0:0:0:0 returned 0 after 19476 usecs
boltd[1532]: probing: started [1000]
mtp-probe[9211]: checking bus 6, device 4: "/sys/devices/pci0000:00/0000:00:08.3/0000:c3:00.3/usb6/6-1"
mtp-probe[9211]: bus: 6, device: 4 was not an MTP device
udisksd[1425]: Error probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sda': Unexpected sense data returned:
                                         0000: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
                                         0010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
                                          (g-io-error-quark, 0)

The issue remains when forcing the direct USB connection from USB3 10Gbps to USB3 5Gbps with a cable.
When the enclosures are connected to the USB-C port (pretty sure it’s a powered USB3 hub) of my Dell U3421WE monitor (at USB 3.1 Gen 1 5Gbps speeds) which is then connected to the mainboard via USB-C, they succeed and do not reset/disconnect.
When the enclosures are forced into USB2 (480Mbps) with a cable or Pixel USB-A to USB-C adapter, they succeed and do not reset/disconnect.
Reading from the enclosure/SSD works fine.

These work without issue:

Sandisk 2TB Portable USB 3.2 Gen 2 10Gbps SSD (USB-C)
Toshiba Portable 2TB USB 3.0 2.5 SATA HDD (USB-A)
SanDisk Extreme Pro 512GB SSD connected via Sabrent USB 3.0 SATA to USB-A adapter

So in summary, my 1TB Samsung PM951 SSD in all those enclosures reset/disconnect when transferring a 10GB file to it over directly connected USB3+ but are fine over USB2. It was never and is still not an issue on my 11th gen Intel i7-1165G7 mainboard. For some reason, other SSDs in those enclosures do work in the AMD 7840U mainboard. I can get the PM951 to work by connecting it to the USB3.1 Gen 1 5Gbps hub on my monitor, and from what I’ve seen/researched, my intuition is that at USB3 speeds, for some reason the SSD pulls too much power and causes the mainboard’s USB3 port to reset and/or reset the enclosure/SSD. Connecting to my monitor’s USB3 hub might be routing around that issue since I’m pretty sure it’s powered. Again, it was totally fine on my previous 11th gen Intel mainboard, (like how it was fine on @Jason_Username_Taken’s 12th gen mainboard), and I’ve been using it in an enclosure successfully since 2019. So there’s likely something broken with the AMD mainboard implementation (or our’s).

I also came across this AMD USB issue in 500 series motherboards from 2021, but it’s a completely different, older series.

I found these that detail Samsung PM951 instability: 1, 2, 3, 4, 5. However, they’re for direct M.2 motherboard connections for that specific SSD and not USB-NVME enclosures, so they might some mixture of misleading and enlightening. I have not read through the lengthy 5. yet, but leaving these here in case they help.

Sidenote, this thread was incredibly hard to find (I searched for “AMD USB” which for some reason didn’t pop up many results, which I’ve been keeping an eye on since I first encountered this issue in early November when I received my board. It wasn’t until I searched just for “USB” and went through each thread title that I found this…I’m glad I found this though, as it confirms that I’m not alone in this. I didn’t see this thread until I performed my own troubleshooting that went quite deep, so this is reassurance that this is a real issue affecting more than 1 person, with different devices. Maybe if I add “AMD 7840U USB-C USB NVME SSD copy transfer disconnect/reconnect failure issue” it’ll pop up in search for others:
Ahem, AMD 7840U USB-C USB NVME SSD copy transfer disconnect/reconnect failure issue

Happy new year! Please let me know if I should send a ticket to support as well. Let’s try to get to the bottom of this and I’d of course be happy to test.

Jason_Username_Taken · January 1, 2024, 10:09pm

Hello @Michael_Wu , thank you for the very detailed report!

Considering Framework’s support system has caught up with all the backlogs per Twist before new year, it could be helpful if you can put your testing data into a formal support ticket, and link them to this thread. Hopefully a fix can make its way into 3.04 for AMD.

@Kieran_Levin @Matt_Hartley Any thoughts on this? I don’t mean to be pushy at all, I’m just wondering if you folks have became aware of this behavior, and if data we gathered here are of any help?

I’m can provide Framework my exact SSD/Enclosure/Cable/Laptop used to replicate this issue, if necessary. They can either just be returned to me afterward, or replaced with any off-the-shelf equivalent.

Michael_Wu · January 1, 2024, 10:30pm

Likewise @Jason_Username_Taken!

Glad to hear and I will do that now.
Edit: email sent to support

+1 from me and I’d be incredibly happy to provide mine as well:

AMD 7840U mainboard
The 1TB Samsung PM951 that has issues
A 512GB LITEON C A3-8D512512GB that is okay
Enclosures:
- Plugable JMicron JMS583
- Plugable Realtek RTL9120
- Sabrent Realtek RTL9120B

Michael_Wu · January 3, 2024, 5:03pm

I have some perhaps enlightening info. Basically, sometimes the enclosure with the Samsung PM951 will reset when writing a very small amount (3 x 1MB). Almost always, (2 x 1MB) will not cause a reset, though I’ve seen it happen on the right bottom port. Usually, it can get up to around 100-1000 x 1MB without resetting.

Usually when a reset it happens, it’s like clockwork. For example, writing 1 x 3MB succeeds; let it idle; and then 15 seconds later, it resets. It’s almost always 15 seconds, but I’ve seen it +/- 5 from 15 seconds (might be just a recording error from me, though).

When copying larger amounts, like 1000x1MB, it may copy 275MB and then reset. This will happen only a few seconds in, and not the usual 15 seconds after. It seems like a small write that takes 1 second, and then idles, will reset in 15 seconds. But a large write may reset just a few seconds in.

After spending all day testing because there’s so many combinations and needing to wait 15 seconds between each ._. I happened to find a working combination. I think this is the biggest clue, by far: in the left bottom port, sometimes it negotiates at 5Gbps with the Sabrent EC-SNVE Realtek RTL9120B/Samsung PM951 instead of the 10Gbps it’s supposed to. For testing, I would unplug and replug from the mainboard, not the enclosure, since it seemed like it would only renegotiate speeds this way; but I’m not sure. lsusb -tv will show the devices negotiated speed on Linux. At 5Gbps, I can write a 107GB file @ ~170MB/s over 10 minutes without issue. Which means that, for some reason, it can work successfully on this mainboard. However, when it negotiates at 10Gbps (as it should), it will reset as described above.

The Plugable Realtek RTL9120/Samsung PM951 sometimes also negotiates at 5Gbps, but for some reason it still resets as described above. Maybe a firmware update could get it to work like the Sabrent Realtek RTL9120B, but it works on my other devices negotiating at the correct 10Gbps, and I don’t believe this is an enclosure issue.

The Plugable JMicron JMS583/Samsung PM951 I can’t seem to ever get to negotiate at 5Gbps on that port.

Notably, that left bottom port is one of the USB3.2 and not USB4 ports. However, I can’t seem to get any enclosure to negotiate at 5Gbps on the other ports, including the right bottom USB3.2 port.

So, so far this is what works with the Samsung PM951:

That singular port/enclosure/5Gbps combination: Sabrent EC-SNVE Realtek RTL9120B (v1.32.87) in the left bottom port when it happens to mistakenly negotiate at 5Gbps.
All 3 enclosures through my monitor’s 5Gbps USB hub.
Forcing a USB2/480Mbps negotiation. Either with a USB-C USB2 cable, or by doing the “halfway-insert trick” where the USB3 USB-C cable is inserted into the mainboard where the enclosure is recognized, then insert all the way in. It will writes at those low speeds, but does not reset. Works on all ports. @brianshmrian tagging you here, hey again! You may find this interesting/helpful as it may be related.

Thanks @Michael_Schmid for the commands below as I was able to thoroughly test each power cable/enclosure port combination, using that and changing the size/count as needed and greatly simplified the process. Though, on my system, testing a singular amount with /dev/random was limited to 2GB, so I just used sample large files created with fallocate -l.

Ryzen 7040 External Monitor and NVMe Enclosures

Drive: Crucial P3 Plus 2TB NVME CT2000P3PSSD8

dd-transfer with /dev/random

sudo dd if=/dev/random bs=1G count=10 of=transfer_test status=progress  
10737418240 bytes (11 GB, 10 GiB) copied, 30 s, 354 MB/s 
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 30.3159 s, 354 MB/s

@Jason_Username_Taken can you try and see if your same model Sabrent enclosure (possibly on the same firmware) can also mistakenly negotiate at 5Gbps on the left bottom port and work without issue. If both of our mainboards do with our different SSDs, that may be a strong indicator. I’m not sure how to check for 5Gbps or 10Gbps in Windows, but ping me if needed and I’m sure I can figure out, if it’s possible.

I have also been chatting with Plugable support (super helpful and with them I’ve been able to further pinpoint). Here’s a statement from them that may help:

Plugable support has seen many power related issues from both host computers and from externally powered USB hubs with NVMe SSDs. They are very power demanding compared to for example SATA SSDs, or flash drives.

Again, I do strongly believe the root cause can possibly be fixed from Framework’s or AMD’s side? since:

the Samsung PM951 works with all enclosures my 11th gen Intel mainboard (and other devices)
the Samsung PM951 works with all enclosures through a monitor USB hub to my AMD mainboard
the Samsung PM951 works with 1 enclosures on the left bottom port mistakenly negotiated at 5Gbps on my AMD mainboard
the Samsung PM951 works with all enclosures forced at USB2 480Mbps speeds

I have an open support ticket already with Framework and will forward them this post and information.

My test results are below

I first began by transferring and noticing:

2 x 1MB files: okay
1 x 2MB: okay
3 x 1MB files: writes successfully, but then like clockwork will disconnect after 15 seconds, and then reconnect
1 x 3MB: writes successfully, but then like clockwork will disconnect after 15 seconds, and then reconnect
Sometimes copying 1 file up to maybe 1GB is okay. But then copying 3 x 1MB files works but causes it to disconnect/reconnect in 15 seconds.

This is a sample journalctl log:

kernel: usb 6-1: USB disconnect, device number 50
systemd-homed[1410]: block device /sys/devices/pci0000:00/0000:00:08.3/0000:c3:00.3/usb6/6-1/6-1:1.0/host1/target1:0:0/1:0:0:0/block/sdb/sdb1 has been removed.
systemd-homed[1410]: block device /sys/devices/pci0000:00/0000:00:08.3/0000:c3:00.3/usb6/6-1/6-1:1.0/host1/target1:0:0/1:0:0:0/block/sdb has been removed.
udisksd[1419]: Cleaning up mount point /run/media/mwu/PM951 (device 8:17 no longer exists)
systemd[1]: run-media-mwu-PM951.mount: Deactivated successfully.
kernel: sd 1:0:0:0: [sdb] Synchronizing SCSI cache
nautilus[471183]: (../src/nautilus-list-base.c:1252):real_set_selection: runtime check failed: (files_to_find == NULL)
kernel: sd 1:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

So I then tried every combination of power cable in one port and enclosure in another (nothing else plugged in). All tests run with all expansion bays empty and directly plugged in to the mainboard’s USB-C port or power cable plugged into a USB-C expansion card, except where noted. All ports also negotiated at 10Gbps, except where noted.

Also, for some reason, in the initial tests, it would reset usually at low amounts like 1x3MB / 1x6MB. It was different than the behavior I was seeing towards the end of my tests (but I had rebooted my system multiple times by then). Some of those combinations I retested, and writes would sometimes successfully go up to 1000x1MB. So assume this data may be off, as I was also developing my a testing methodology on the fly (noticeable in the data). I’ve concluded that with all combinations except the singular odd mistaken left bottom port negotiated at 5Gbps with the RTL9120B behave similarly: sometimes reset with low amounts like 3x1MB, and usually at around 1000x1MB. Let me know if I should rerun/test anything specific.

Data

Power cable in left top

Sabrent EC-SNVE Realtek RTL9120B (10Gbps) enclosure in:

Right top: 3 x 1MB transfers but causes it to reset after 15 seconds.
Right bottom: Writing 3 x 1MB was okay. Tried writing 3 x 100MB which caused it to reset. Then I tried writing 3 x 1MB which reset it in 15 seconds.
Left bottom: same 15 second reset
- I tested it the day after (10Gbps) and it would go up to 1000 x 1MB.

Power cable in left bottom

Sabrent EC-SNVE Realtek RTL9120B (10Gbps) enclosure in:

Left top

Same (not sure why I wrote this, I think I meant similar results to the Right bottom results below).

Right top:

Same (not sure why I wrote this, I think I meant similar results to the Right bottom results below).

Right bottom:

Writing 3 x 1MB did not result in a reset.
Writing 4 x 1MB did not result in a reset.
Writing 10 x 4MB resulted in a reset in 15 seconds. FAIL
Then writing 3x1MB resulted in a reset. FAIL
Writing 2x1MB did not result in a reset.
Writing 3x1MB twice, no reset.
Writing 4x1MB, no reset.
Writing 5x1MB, no reset.
Writing 6x1MB, reset. FAIL
Writing 2x1MB, no reset.
Writing 3x1MB, no reset.
Writing 4x1MB, no reset.
Writing 5x1MB, no reset.
Writing 6x1MB, reset in >20 seconds. FAIL
Writing 3x1MB, reset.

Power cable in right top port

Sabrent EC-SNVE Realtek RTL9120B (10Gbps) enclosure in:

Left top:

3 x 1MB, no reset.
4 x 1MB, no reset.
5 x 1MB, no reset.
6 x 1MB, reset. FAIL
3 x 1MB, reset. FAIL
I tested this particular combination the day after and it would go up to 500 x 1MB without resetting

Left bottom:

3 x 1MB, reset. FAIL

Right bottom:

3 x 1MB, reset. FAIL

Power cable in right bottom port

Sabrent EC-SNVE Realtek RTL9120B (10Gbps) enclosure in:

Left top:

3 x 1MB, no reset.
3 x 1MB, no reset.
4 x 1MB, no reset.
5 x 1MB, no reset.
5 x 1MB, no reset.
6 x 1MB, no reset.
6 x 1MB, no reset.
7 x 1MB, reset in 17 seconds.

Left bottom (I noticed it negotiated/connected at 5Gbps instead of the usual 10Gbps so I tested with that):

3 x 1MB, no reset.
3 x 1MB, no reset.
4 x 1MB, no reset.
5 x 1MB, no reset.
6 x 1MB, no reset.
7 x 1MB, no reset.
8 x 1MB, no reset
10 x 1MB, no reset
20 x 1MB, no reset
50 x 1MB, no reset
100 x 1MB, no reset
500 x 1MB, no reset
1000 x 1MB, no reset
5000 x 1MB, no reset
10000 x 1MB, no reset
20000 x 1MB, no reset (took 124.5 seconds at ~170MB/s, no reset) SUCCESS
1 x 100MB, no reset
1 x 500MB, no reset
1 x 1,000MB, no reset
1 x 5GB no reset
1 x 10GB no reset
1 x 107GB surprisingly no reset, it took 10 minutes 2 seconds. The entire file wrote successfully at ~190MB/s. SUCCESS. I also tested if this worked on battery power, not charging, with PCIe ASPM set to powersupersave, and a power savings profile to see if it made a difference. In theory, that should be the least reliable. Note I did not have such power savings settings in use for other tests. Writes were slower at ~60MB/s for the first 10% for a minute or two (where it usually resets a few seconds in) and it didn’t reset, so I assumed it worked as well. I changed back to power profile/settings I have while running on AC, but without the charger. Speed went up to ~150MB/s and finished successfully.
I then disconnected the enclosure and reconnected it into the same port with the same cable, and it negotiated at 10Gbps (as it should):
3 x 1MB: no reset
3 x 1MB: no reset
4 x 1MB: no reset
5 x 1MB: no reset
6 x 1MB: no reset
7 x 1MB: no reset
8 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: reset. FAIL
1000 x 1MB: reset. FAIL
3 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: reset. FAIL
3 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: reset. FAIL
3 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: reset. FAIL
Disconnected and reconnected enclosure cable physically and got it to negotiate at 5Gbps again to test:
3 x 1MB: no reset
3 x 1MB: no reset
4 x 1MB: no reset
5 x 1MB: no reset
6 x 1MB: no reset
7 x 1MB: no reset
8 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 5000MB: no reset
10000 x 1MB: no reset
1 x 100MB: no reset
1 x 500MB: no reset
1 x 1,000MB: no reset
1 x 5GB: no reset
1 x 10GB: no reset
1 x 107GB no reset. Took 10 minutes 10 seconds, ~168MB/S. SUCCESS

Right top:

3 x 1MB: no reset
10 x 1MB: reset. FAIL
3 x 1MB: reset. FAIL

No power cable, on battery

I accidentally left a USB-C expansion card in the right top slot but I don’t think it affected anything.

Sabrent EC-SNVE Realtek RTL9120B (10Gbps) enclosure in:

Left top port:

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: no reset
10000 x 1MB: reset 7.2GB in
3 x 1MB: no reset
10 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: reset 3.3GB in

Left bottom port

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: reset in 3.3GB
3 x 1MB:
10 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB no reset
500 x 1MB: reset

This port does work with Sabrent RTL9120B/Samsung PM951 combination mistakenly negotiated at 5Gbps on battery power, as described in the batch of tests above this.

Right top port:

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: reset at 3.2GB
3 x 1MB: no reset
10 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB no reset
500 x 1MB: reset

Right bottom port:

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: reset 2.6GB in
3 x 1MB: no reset
10 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: no reset
5000 x 1MB: reset 2.8 GB in

No power cable, on battery

Plugable RTL9120 (10Gbps) enclosure in:

Left top port:

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: reset
3 x 1MB: reset
2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: reset

Left bottom port (negotiated at 5Gbps):

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: reset
3 x 1MB: reset
5 x 1MB: reset
50 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: reset

Left bottom port (negotiated at 10Gbps):

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: no reset
1000 x 1MB: reset
3 x 1MB: reset
2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB: reset

Right top port:

2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: no reset
100 x 1MB: no reset
500 x 1MB: reset
3 x 1MB: reset
2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
50 x 1MB: no reset
100 x 1MB no reset
500 x 1MB: reset

Right bottom port:

2 x 1MB: reset
2 x 1MB: no reset
3 x 1MB: no reset
5 x 1MB: no reset
10 x 1MB: no reset
20 x 1MB: reset
2 x 1MB: reset
2 x 1MB: reset
2 x 1MB: no reset
3 x 1MB: reset
Physically unplugged and replugged
2 x 1MB: no reset
3 x 1MB: no reset
10 x 1MB: no reset
50 x 1MB: reset

Jason_Username_Taken · January 4, 2024, 3:56am

@Michael_Wu
Tested the Sabrent enclosure on the lower-left port, the port with the least features.
It was surprisingly difficult to find any clue that explicitly indicates the USB connection speed. However, I ran CrystalDiskMark, and the 935.55MB/s read and 914.26MB/s write likely indicates 10Gbps.

Disk dropped before benchmark could complete, not possible to reconnect as expected (on the lower-left and other ports), even after switching to a USB2 Type-C to Type-C cable. Confirmed with 12th Gen Framework that the enclosure and disk remains functional.

Interestingly, now you mentioned connection speed, I do remember seeing this enclosure and drive gets a noticeably higher R/W speed when being CrystalDiskMarked on other computers. IIRC, it will get a bit over 1GB/s, verses the slightly under 1GB/s I get when running the same synthetic test with AMD (until the connection drops, of course).

I’ll double check this on the 12th Gen. Brb

Michael_Wu · January 4, 2024, 5:07am

For Windows, USB Tree View reports SuperSpeed or SuperSpeed+, which is 5Gbps or 10Gbps.

I think it’s this: USB Device Tree Viewer, because that’s the first link that pops up on Google and it looks legit, but uh, I can’t vouch that it’s not malware haha (99% confident it’s not and I’ve used it before…maybe).

I got this info from @brianshmrian so if you could confirm, thanks in advance!

Yeah, unless the CrystalDiskMark readings are wrong since 5Gbps = 625MB/s.

Does it ever work when forcing USB2 (480Mbps) max speeds?

I was searching the Framework discord if others had reports and actually found yours I’ll open up a thread there too just in case.

brianshmrian · January 4, 2024, 5:28am

Yes, that’s the USB Tree View that I used. Bing chat recommended it for figuring out USB max connection speeds on Windows

I ran it through virustotal.com, which was fine with it.

Jason_Username_Taken · January 4, 2024, 5:31am

Just tested on 12th Gen FW. Same enclosure and drive gets 1064.97MB/s Read, and 939MB/s Write while Windows To Go was also booted from that same drive.

Also tested with an MacBook Pro with 7th Gen Intel processor and running Windows, with the drive attached as a typical storage device. Similar R/W as tested on 12th Gen FW.

Therefore, it does appear that the same enclosure is indeed yielding slightly lower speed when connected to the AMD FW. Not that it causes much practical difference, but I’m just wondering why.

Btw, stumbled upon your reply in the charger compatibility post. I use the 87W A1719 Apple adapter to charge both AMD and Intel Framework (and bunch of other things). Charger didn’t break, works fine.

Michael_Wu · January 4, 2024, 5:54am

I’ve noticed that too vs. my 11th gen Intel, and I think it might just be immature AMD drivers since the platform is pretty new. Or the USB controller is actually just slower

Good to know, mine’s also the A1719 though I’m on BIOS 3.03, not sure if that made a difference.

So the key, at least with my Sabrent EC-SNVE/Samsung PM951 is to get it to mistakenly negotiate at 5Gbps which only happens about 25% of the time on that one port. It may be another port for you, if we have the same issue. I’m also on the latest Sabrent firmware (the last post in this thread).

For some reason, that will allow it to not reset during a large transfer, even 100GB continuously.

Forcing USB2 on any port also works, albeit at slower speeds.

I’m actually testing out if the issue persists on Live Ubuntu for Framework support right now

Jason_Username_Taken · January 4, 2024, 6:10am

@Michael_Wu
Sorry, missed this part, I’m a bit tired and wasn’t reading the most carefully.

Please see my original post regarding the ‘cool down’ behavior I observed. After the connection dropped while I was performing the 10/5Gbps speed check a few hours ago, the same ‘cool down’ need occurred and the drive just wouldn’t connect with USB3 nor USB2 cable.

After waiting until about 30 minutes ago, the AMD FW recognizes the drive again. It is now connected via a Samsung Type-C to Type-C charging cable, capable of USB2 speed. At the speed of 30MB/s, it has been copying files for the past 30ish minutes. It hasn’t failed.

I wonder if you encounter the ‘cool down’ behavior I described in my original post, when each time your drive drops?

Update1: I got 5Gbps to happen on the lower-left port.

After the previous USB2 files copying completed, I ejected the drive and tried to reconnect it via the previous USB3 Type-C to Type-C cable. At first, drive couldn’t be recognized. On second attempt, it connected successfully and I started copying a 50GB folder. I observed the write speed being ~550MB/s, good indicator it’s functioning at 5Gbps. The 50GB folder successfully finished copying, which never happened before.

Update2: Connection dropped again after it self-promoted to 10Gbps.

After performing the test describe in Update1 and finished writing Update1, I never unplugged the drive during this period, but I did notice it entered power-saving mode. This is indicated by the soft-on/off LED on the enclosure (an external HDD would have stopped spinning in this case). I began a CrystalDiskMark and noticed the drive exiting low-power mode as it should, while the drive was never disconnected or ejected in Windows throughout this period, the CrystalDiskMark began running at 10Gbps speed for unknown reason. As expected, the drive crapped out before the benchmark could complete (also lasted a bit longer than usual), and now unable to reconnect once again. It seems like after the drive in 5Gbps state entered power-saving mode due to inactivity, it was able to wake up into 10Gbps, while technically always connected as far as Windows is concerned.

Michael_Wu · January 4, 2024, 6:33am

No worries, I’m tired too haha – also saw that you’re on the latest Sabrent firmware.

Nope, I don’t experience any “cooldown period”, although that might be a Linux (Fedora) thing. It will reconnect within a few seconds after disconnecting, always. But sometimes the filesystem gets corrupted from a failed transfer, and then I need to reboot into Windows to run chkdsk (the SSD in question is NTFS).

I’ve noticed that with the Plugable JMicron JMS583 drive (which is supposed to be the less stable version), on Windows, when it disconnects, freezes Windows Explorer and the entire system, and then I need to force a reboot. But still, I don’t believe I’ve seen such a cooldown period. I will test and report back (probably tomorrow).

Thanks, that confirms the same behavior and workaround I’ve seen. The next step I’ll be taking is to see if it works through a powered 10gbps hub, which may point to if it’s a power issue or a USB controller performance issue (and if I can successfully continually write negotiated at 10Gpbs). And getting back to Framework support will update

Edit: just saw your 5Gbps edit after posting. Haha nice, thanks for testing, we have movement! We have 2 different SSDs but the same enclosure that works oddly with the same “hacks” (I don’t believe it’s an enclosure issue though from the above thorough testing).