Thanks for the enclosure teardown, Iāll compare more carefully later, to check for any difference. Update: Compared side by side. Seems like we both have R1.2, all surface mount components appears to have identical placements.
I havenāt had the chance to check the replacement yet! But I do intend to make time for it soon.
Did you hear back after your ticket was escalated? I did receive a reply after post #28, I was thanked but didnāt get a definitive yes or no, regarding if I should leave a special note in the box, ship it to a different address, or anything else.
(Iām happy to help if I need to do anything, or if Framework says āno worries, we will figure outā I also wonāt protest. I simply want to avoid the situation that if I literally just sent it out, then I receive additional instruction such as leave a note inside with case number).
I privately messaged someone who likely can look into this for us, but this is Friday and I donāt blame them if they wonāt check message again until Monday. Now Iām just a bit unsure if I should hold the package for now, or send it right now.
Nope no updates from today unfortunately.
Edit: though I donāt think this is an easy issue to resolve, so it might take a while.
My 2 cents: if there was no deadline or rush from their end, Iād say it wouldnāt hurt to wait until you get a definitive answer. I donāt think them not having your issue unit for an extra few days would hurt them, but it might be inconvenient for them if your package ends up going to the wrong place in the beginning. Though whatever the case, they can probably figure it out and track it down anyways from their records.
If you canāt decide, maybe flip a coin or something
Yeah. Currently no rush from FW. Iāll perhaps hang tight just for a tiny bit more.
Iām certain everyone at Framework are helpful, and will assist their members from different functional departments when necessary. I just wish to prevent situations like if I send it out right now with the label I have currently, it goes right into a whole RMA pile at the destination, then the engineers decides it is indeed, but at that point it will take some work to process & dig out any specific unit. (I have no evidence to confirm or deny this will be the case, just a plausible theory.)
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.
