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.
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.
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)
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ā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)
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.
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.
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.
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.
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]).
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 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.
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:
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 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.
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.
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.
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.
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.
@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).
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.
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.
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
@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.
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).