AMD Framework and NVMe SSD Enclosure Compatibility Investigation

Community Support
,
8

@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.

9

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.

10

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 :slight_smile:

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.

3 Likes
11

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.

1 Like
12

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
1 Like
13

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.

@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:
  1. Writing 3 x 1MB did not result in a reset.
  2. Writing 4 x 1MB did not result in a reset.
  3. Writing 10 x 4MB resulted in a reset in 15 seconds. FAIL
  4. Then writing 3x1MB resulted in a reset. FAIL
  5. Writing 2x1MB did not result in a reset.
  6. Writing 3x1MB twice, no reset.
  7. Writing 4x1MB, no reset.
  8. Writing 5x1MB, no reset.
  9. Writing 6x1MB, reset. FAIL
  10. Writing 2x1MB, no reset.
  11. Writing 3x1MB, no reset.
  12. Writing 4x1MB, no reset.
  13. Writing 5x1MB, no reset.
  14. Writing 6x1MB, reset in >20 seconds. FAIL
  15. Writing 3x1MB, reset.

Power cable in right top port

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

Left top:
  1. 3 x 1MB, no reset.
  2. 4 x 1MB, no reset.
  3. 5 x 1MB, no reset.
  4. 6 x 1MB, reset. FAIL
  5. 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:
  1. 3 x 1MB, no reset.
  2. 3 x 1MB, no reset.
  3. 4 x 1MB, no reset.
  4. 5 x 1MB, no reset.
  5. 5 x 1MB, no reset.
  6. 6 x 1MB, no reset.
  7. 6 x 1MB, no reset.
  8. 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):
  1. 3 x 1MB, no reset.
  2. 3 x 1MB, no reset.
  3. 4 x 1MB, no reset.
  4. 5 x 1MB, no reset.
  5. 6 x 1MB, no reset.
  6. 7 x 1MB, no reset.
  7. 8 x 1MB, no reset
  8. 10 x 1MB, no reset
  9. 20 x 1MB, no reset
  10. 50 x 1MB, no reset
  11. 100 x 1MB, no reset
  12. 500 x 1MB, no reset
  13. 1000 x 1MB, no reset
  14. 5000 x 1MB, no reset
  15. 10000 x 1MB, no reset
  16. 20000 x 1MB, no reset (took 124.5 seconds at ~170MB/s, no reset) SUCCESS
  17. 1 x 100MB, no reset
  18. 1 x 500MB, no reset
  19. 1 x 1,000MB, no reset
  20. 1 x 5GB no reset
  21. 1 x 10GB no reset
  22. 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.
  23. I then disconnected the enclosure and reconnected it into the same port with the same cable, and it negotiated at 10Gbps (as it should):
  24. 3 x 1MB: no reset
  25. 3 x 1MB: no reset
  26. 4 x 1MB: no reset
  27. 5 x 1MB: no reset
  28. 6 x 1MB: no reset
  29. 7 x 1MB: no reset
  30. 8 x 1MB: no reset
  31. 10 x 1MB: no reset
  32. 20 x 1MB: no reset
  33. 50 x 1MB: no reset
  34. 100 x 1MB: no reset
  35. 500 x 1MB: no reset
  36. 1000 x 1MB: no reset
  37. 5000 x 1MB: reset. FAIL
  38. 1000 x 1MB: reset. FAIL
  39. 3 x 1MB: no reset
  40. 100 x 1MB: no reset
  41. 500 x 1MB: no reset
  42. 1000 x 1MB: no reset
  43. 5000 x 1MB: reset. FAIL
  44. 3 x 1MB: no reset
  45. 100 x 1MB: no reset
  46. 500 x 1MB: no reset
  47. 1000 x 1MB: reset. FAIL
  48. 3 x 1MB: no reset
  49. 100 x 1MB: no reset
  50. 500 x 1MB: no reset
  51. 1000 x 1MB: reset. FAIL
  52. Disconnected and reconnected enclosure cable physically and got it to negotiate at 5Gbps again to test:
  53. 3 x 1MB: no reset
  54. 3 x 1MB: no reset
  55. 4 x 1MB: no reset
  56. 5 x 1MB: no reset
  57. 6 x 1MB: no reset
  58. 7 x 1MB: no reset
  59. 8 x 1MB: no reset
  60. 10 x 1MB: no reset
  61. 20 x 1MB: no reset
  62. 50 x 1MB: no reset
  63. 100 x 1MB: no reset
  64. 500 x 1MB: no reset
  65. 1000 x 1MB: no reset
  66. 5000 x 5000MB: no reset
  67. 10000 x 1MB: no reset
  68. 1 x 100MB: no reset
  69. 1 x 500MB: no reset
  70. 1 x 1,000MB: no reset
  71. 1 x 5GB: no reset
  72. 1 x 10GB: no reset
  73. 1 x 107GB no reset. Took 10 minutes 10 seconds, ~168MB/S. SUCCESS
Right top:
  1. 3 x 1MB: no reset
  2. 10 x 1MB: reset. FAIL
  3. 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:
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: no reset
  8. 1000 x 1MB: no reset
  9. 5000 x 1MB: no reset
  10. 10000 x 1MB: reset 7.2GB in
  11. 3 x 1MB: no reset
  12. 10 x 1MB: no reset
  13. 50 x 1MB: no reset
  14. 100 x 1MB no reset
  15. 500 x 1MB: no reset
  16. 1000 x 1MB: no reset
  17. 5000 x 1MB: reset 3.3GB in
Left bottom port
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: no reset
  8. 1000 x 1MB: no reset
  9. 5000 x 1MB: reset in 3.3GB
  10. 3 x 1MB:
  11. 10 x 1MB: no reset
  12. 50 x 1MB: no reset
  13. 100 x 1MB no reset
  14. 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:
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: no reset
  8. 1000 x 1MB: no reset
  9. 5000 x 1MB: reset at 3.2GB
  10. 3 x 1MB: no reset
  11. 10 x 1MB: no reset
  12. 50 x 1MB: no reset
  13. 100 x 1MB no reset
  14. 500 x 1MB: reset
Right bottom port:
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: no reset
  8. 1000 x 1MB: no reset
  9. 5000 x 1MB: reset 2.6GB in
  10. 3 x 1MB: no reset
  11. 10 x 1MB: no reset
  12. 50 x 1MB: no reset
  13. 100 x 1MB: no reset
  14. 500 x 1MB: no reset
  15. 1000 x 1MB: no reset
  16. 5000 x 1MB: reset 2.8 GB in

No power cable, on battery

Plugable RTL9120 (10Gbps) enclosure in:
Left top port:
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: reset
  8. 3 x 1MB: reset
  9. 2 x 1MB: no reset
  10. 3 x 1MB: no reset
  11. 5 x 1MB: no reset
  12. 50 x 1MB: no reset
  13. 100 x 1MB: no reset
  14. 500 x 1MB: reset
Left bottom port (negotiated at 5Gbps):
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: reset
  8. 3 x 1MB: reset
  9. 5 x 1MB: reset
  10. 50 x 1MB: no reset
  11. 100 x 1MB: no reset
  12. 500 x 1MB: reset
Left bottom port (negotiated at 10Gbps):
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: no reset
  8. 1000 x 1MB: reset
  9. 3 x 1MB: reset
  10. 2 x 1MB: no reset
  11. 3 x 1MB: no reset
  12. 5 x 1MB: no reset
  13. 50 x 1MB: no reset
  14. 100 x 1MB: reset
Right top port:
  1. 2 x 1MB: no reset
  2. 3 x 1MB: no reset
  3. 5 x 1MB: no reset
  4. 10 x 1MB: no reset
  5. 20 x 1MB: no reset
  6. 100 x 1MB: no reset
  7. 500 x 1MB: reset
  8. 3 x 1MB: reset
  9. 2 x 1MB: no reset
  10. 3 x 1MB: no reset
  11. 5 x 1MB: no reset
  12. 10 x 1MB: no reset
  13. 50 x 1MB: no reset
  14. 100 x 1MB no reset
  15. 500 x 1MB: reset
Right bottom port:
  1. 2 x 1MB: reset
  2. 2 x 1MB: no reset
  3. 3 x 1MB: no reset
  4. 5 x 1MB: no reset
  5. 10 x 1MB: no reset
  6. 20 x 1MB: reset
  7. 2 x 1MB: reset
  8. 2 x 1MB: reset
  9. 2 x 1MB: no reset
  10. 3 x 1MB: reset
  11. Physically unplugged and replugged
  12. 2 x 1MB: no reset
  13. 3 x 1MB: no reset
  14. 10 x 1MB: no reset
  15. 50 x 1MB: reset
3 Likes
14

@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

15

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 :laughing: I’ll open up a thread there too just in case.

1 Like
16

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

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

1 Like
17

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.

18

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 :person_shrugging:

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

19

@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.

1 Like
20

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 :sweat_smile: 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).

21

I just had an update 2 after the update 1, have a look!

Btw, what phone do you have, if you don’t mind me asking?

I found my Note 20 Ultra unable to recognize the Sabrent EC-SNVE on both the original firmware and latest firmware. I don’t know if the protocol used by this enclosure simply isn’t supported on Android 13 (or the Note 20 Ultra hardware).

22

Very interesting and very strange, so it renegotiated to 10Gbps, and there was no indication that it disconnected and reconnected, like the classic Windows device disconnect/reconnect sound, or any notifications?

Edit: I will also see if I can if I can reproduce that behavior

Sure thing, ask away :slight_smile:

I have a Google Pixel 5 (Android 14), and I just tried the Sabrent with the Samsung PM951. It’s recognized with ZUGate, which I use to mount external drives. It properly recognizes the drive and the NTFS partition, but it seems I can’t mount it and it just says “wrong format”. It seems the same with my Liteon drive’s NTFS partition, but I can mount the FAT and EXTx partitions and browse the files. ZUGate says it supports NTFS so I’m not sure what’s going on, but it has been on my list to investigate.

23

Correct, as far as Windows is concerned, it remained connected.

Interesting. I honestly didn’t even care about NTFS compatibility. I’ve shoved plenty drives with unsupported file systems, or straight up nuked partition map into my phone, and Android will offer an option to format it as long as the drive itself is functioning correctly. The Type-C port’s capability of this phone should also be reasonably adequate. I wonder why this drive doesn’t show up at all.

Edit: Grammar

Edit2:

Let me know if there’s anything else you want me to cross check. I’m about to not have this particular unit of AMD Framework very soon. Unrelated to the Type-C behavior we are looking into, I noticed a different issue on this specific laptop (physical issue, perhaps not even Framework’s fault, but something weird happened during transportation). Framework was very responsible, and quickly took care of me with a replacement. Considering my personal matters could be busy in the next few days and I have a perfectly fine 12th Gen currently using, I’m unsure when I’ll assemble the new replacement. I still ought to send the current AMD unit to Framework very very soon. Let me know if there’s any new discovery that could benefit from me trying to replicate on my side.

1 Like
24

Ah yeah, and I just tried without ZUGate and my phone’s recognizing it with “Tap to fix Sabrent” and offering to format. Have you tried another SSD in the enclosure and seeing if it works? Or does does that SSD work with another enclosure?
Edit: to pinpoint where the incompatibility lies. I’d be kinda shocked if you forced USB2 and your phone recognizes it, but doesn’t at USB3. That can shift the root cause back onto the enclosure/SSD along with the host. Though the incompatibilities on your phone and AMD could be discrete cases.

Also, reminder to self to check if a different filesystem makes a difference, though I don’t think it will.

Noted, thanks. It may be a good idea to let Framework know about your experience with this current issue so that they can hang on to the board and tag it so they have something to reproduce the issue reliably with. If they have it and can, it’ll be much easier to root cause.

25

'pologies for the double post, got some more insight. Per Framework support’s request, I tested with Live Ubuntu (22.04.3 LTS).

  • Charger in left top port.
  • USB-A expansion card with the 64gb USB flash/boot drive negotiated at USB2/480Mbps in the right top port.

I noticed the same behavior, with copying a 10GB file at around 220MB/s from the internal SSD to the enclosure/SSD failing in both the the left bottom and right bottom ports.

However, interestingly if I run dd which copies files from the USB2 speed flash drive (where Live Ubuntu is) to the enclosure/SSD, it will write at the limited USB2 speeds around ~60MB/s and not reset, even if the enclosure is connected at 10Gbps.

So from that, it looks like it doesn’t matter what speed the enclosure is negotiated at, but rather what speed the writes are. When mistakenly negotiated at 5Gbps, it has transferred successfully at 190MB/s, but I don’t think ever at 220MB/s, which is at 10Gbps negotiation (unsure why they’re so low but I think in this case, unrelated). This tracks from what I’ve seen…and now rules out negotiation speed being the cause. I suspect that writes at higher speeds may cause SSDs that are more power hungry to draw more power than the port can provide/handle, causing it to reset. TBD what Framework support says, but I think a few ways to validate this theory are:
1. Limiting write speeds in software to find the threshold when negotiated at 10Gbps
2. Using a powered hub at 10Gbps
3. Using a USB power meter

TBD, and I’ve already ruled out thermal throttling previously.

Edit: tested software write speed limit with rsync --bwlimit, nevermind, still resets even limiting to 50MB/s when negotiated at 10Gbps. Perhaps the USB2 flash drive to USB3 enclosure transfer was limited to the USB2 controller so it worked?

26

I wanted to replicate this. Filled up a 64GB microSD with large files. I wanted to plug the microSD card and Sabrent enclosure both into the AMD Framework, and copy large files from the microSD card to the external NVMe SSD via AMD Framework. Unfortunately, for some reason the Sabrent enclosure isn’t being recognized at all now. (microSD in card reader popped up immediately)

Section Update 1: Got it to work. USB3 card reader, but the card isn’t capable of exceeding ~90MB/s read, therefore the external SSD isn’t getting more than ~90MB/s write, obviously. Copy lasted under a minutes until the external SSD dropped again. Seems like a low write speed in this scenario doesn’t mitigate the disk drop. (Interesting how when the drive is erroneously slated as 5Gbps upon connection, it was able to finish copying a bunch of large files at a much faster 500MB/s)

When the AMD FW enteres the state of ‘cool down’ right after a disk drop, the external drive won’t even show in the BIOS boot selector. (the disk is bootable, and will otherwise show)

I’ve also worked to rule out the possibility of defective Type-C pass-through Expansion Cards. Plugging the external drive directly into the board with no Expansion Card doesn’t eliminate this issue. I’ve also pulled Expansion Cards off the AMD Framework, linked them back-to-back, plug them into my 12th Gen, connected the Sabrent Enclosure and smashed it with both large file transfer and synthetic benchmark. Works fine.

Picture (fix)
Picture (fix)3296×1792 1.1 MB

Yup. It’s about time I really ought to pack up this specific unit of AMD FW and ship it to them. When I email Framework to inform them the tracking number once I have it, I’ll also mention this behavior we are investigating, so if they wish, they can grab this unit for their own testing. Again, if anyone from Framework is reading, I can also provide my enclosure/SSD/cable.

(For anyone just began reading from here. This specific unit is being sent to Framework as I discovered an unrelated physical issue on this unit, perhaps something happened during storage or transportation and irrelevant to the Framework AMD mainboard’s design. It is also unlikely a cause or contributing factor to the Type-C behavior we are investigating. Framework was very responsive when contacted regarding this phsyical issue, and already took care of me with a fresh replacement.)

Edit 1: Fix attachment.

27

So I just tested in Windows to see if I could reproduce your stated “cooldown period” and I could not, with CrystalDiskMark or transferring a large file. After it disconnects it then reconnects immediately (the same behavior I’ve been seeing on Fedora and Ubuntu).

Also I can confirm, that for Windows USB Device Tree Viewer confirms 5Gbps (SuperSpeed) or 10Gbps (SuperSpeedPlus) under Device Connection Speed. When it negotiated at 5Gbps, CrystalDiskMark was showing around half the throughput vs. what it was at 10Gbps, and Device Connection Speed said SuperSpeed instead of SuperSpeedPlus.

When it was connected at 5Gbps and working with CrystalDiskMark, I let it idle and it went into the breathing blue LED/power-saving mode. When I ran CrystalDiskMark again and it came out of that mode, it stayed connected at 5Gbps, worked as it usually does when it’s connected at 5Gbps in my left bottom port, and did not renegotiate to 10Gbps.

So I couldn’t reproduce that either.

The “cooldown period” and not getting your drive to be recognized at all might be because I’m on BIOS 3.03 while you’re on 3.02, and if so that could mean there were changes that improved stability with our hardware. Which could be promising for the next update. Though it’s odd your S20 phone doesn’t recognize it either.

What in the ever living :laughing: lmao good to know. Time to construct a bridge around the world made solely out of Framework USB-C expansion cards

Before doing so, you could update to BIOS 3.03 just to verify if that does indeed allow the enclosure/SSD to always be recognized and with no “cooldown period” like it does on my mainboard. Though keeping your BIOS on 3.02 might benefit Framework support’s troubleshooting process. Do please mention this and thank you!

An update from my end: Framework support has escalated my ticket and their engineering team is taking a look. wubba lubba dub-dub!