We have a JMS583 (EVOLVEO Tiny N1) NVMe enclosure here, and I can confirm that there are definitely resets at 10Gbps.
It also only works in the top USB4 ports; it is not recognized at all in the bottom USB3.2 ports, or when it is, then it is extremely unstable and the connection does not last. The cable used does not seem to be the issue.
On a different AMD Ryzen machine (Thinkpad T14 Gen3 with Ryzen 5 PRO), I have observed no issues at all.
Dude, it’s the ssd. I did my testing with a 970 evo, tried a different ssd today and hotpluging just worked. Tried a bunch of others (Samsung PM9A1 and 960 evo, WD SN720, and micron 2450), they all worked. 970 evo again, didn’t work. Still got the 2GB/s limit though
Weirdly it works on windows, and without the 2GB/s limit.
Yeah, it seems like this issue isn’t within the scope of 3.03b EC firmware.
Thank you very much for sharing your controller and SSD models!
It does seem that some external SSD works better than other. However, given the totality of the circumstances, I would rather say it’s the AMD Framework, than it is the SSD. Especially when during my testing, the same SSD and enclosure works completely fine on every other computers I can get my hands on, including Intel Framework. (I don’t mean to be a jerk and picking on your words, I’m just sharing my opinion and conclusion on the topic under discussion)
Given that other Type-C related issues on AMD13, such as the single-cable Type-C monitor compatibility issues, are also well-discussed by other owners, including some opening their corresponding support ticket, I would appreciate if FW can comment on this issue. Such as if the cause is identified, and if the pending 3.04 BIOS includes improvement and fixes on Type-C related functionalities.
Probably a combination of both, the enclosure works fine with other ssds and with this one on windows.
I don’t really have access to any other usb4 capable devices and in tb fallback mode the 970 evo worked on linux too. It is a quite weird and speciffic issue for sure.
Just wanted to clarify here that the issue of a power reset/cycle during a large write, so far, has shown to be operating system and USB NVME chipset agnostic. It’s at least because of some FW AMD mainboard/SSD incompatibility. A possible reason is that the system is not giving enough power to certain SSDs during sustained high speed write. Perhaps some power hungrier SSD models ask for power but don’t receive it fast enough or at all, which causes them to reset. This happens negotiated at 10Gbps speeds. It doesn’t reset when forcing negotiation at USB2/480Mbps or when the system mistakenly negotiates a 5Gbps connection on one (perhaps some) of the ports.
@Adrian_Joachim are you testing a large sustained write when negotiated at 10Gbps? A full 10GB transfer should reliably reproduce the issue. Your/the ASMedia 246x has reports of being pretty stable AFAIK, so if you can repro it then it further excludes USB NVME chipsets from being the culprit. If, indeed, large writes work on Windows but not Linux, with your ASMedia 246x and Samsung 970 Evo, then that’s some potentially revealing info.
Edit: also to add, we still don’t know if this issue affects all mainboards or just a specific batch, if it’s fixable in software, etc.
Echoing @Jason_Username_Taken that it would be nice if FW was publicly tracking/commenting on this issue, but some good news is that I do have a support ticket open with them and they’ve acknowledged that “this issue is currently under active investigation”.
I can’t reproduce your drop out during write issue at all, I just tested 20GB writes on:
970 evo in RTL9210 enclosure 1 at 10Gbit (USB A)
970 evo in RTL9210 enclosure 2 at 10Gbit (USB-C)
970 evo in ASM2464 in usb3 mode at 10Gbit
PM9A1 in ASM2464 in usb4 mode at 40Gbit (capped to 2GB/s for some reason)
970 evo in ASM2464 in usb4 mode at 40Gbit (capped to 2GB/s for some reason, after reboot cause hotplug doesn’t work)
All on linux cause I did not have any dropouts. Not sure it’s a prower issue per se, the PM9A1 (oem 980 pro) is a much more power hungry ssd than the 970 and that one works too.
Ah okay, many thanks for testing. I think yours and @Terrance_Hendrik’s particular issue of “the 970 EVO not being hotpluggable in Linux but works in Windows” is different than the issue of “particular SSDs dropping out during a large write regardless of operating system” of mine and @Jason_Username_Taken’s, etc.
Curiously, @Bruce_Wilbur experienced the “transfer rate rapidly degrades to negligible” issue (which I’ve seen happen with a particular cheap flash drive, might have been just that drive and not a FW issue though) with the 970 EVO on a different enclosure, in Linux, but didn’t mention any hotplug issues:
So, if I’m understanding correctly, it seems like your hotplug issue is at least particular to the Linux + ASMedia ASM2464 + 970 EVO combo and may be caused by faulty driver/firmware somewhere in that chain.
Though maybe all of these (with the transfer/write issues) are symptoms of the same root cause from FW hardware/firmware.
Think so too, theough the 970 evo being a bit of a problem child is the common denominator
It’s even more speciffic, It’s particular to the framework laptop amd, linux and the asm2464 in usb4 mode and and the 970 evo, in tb3 mode though my egpu it works, in usb3 mode it works and on win11 it works.
Thank you all for the additional information, really appreciated.
According to Kieran, new AMD BIOS may drop within the next 7 days or so. Therefore, I’ll probably stay put for a few days, and try testing everything again with the new BIOS.
Until then, AMD will remain as an auxiliary and 12th Gen will continue to be my daily. I hope the new BIOS package will fix this issue, the AMD was meant to be my daily after all.
Power supply probably isn’t an issue per se. I’m now doing some sustained transfer test with external HDD, with this particular one being an HDD+Tiny SSD Hybrid drive. I assume this probably draws more power than my Gen3 NVMe in an enclosure. (although I do not have a device to measure)
