Framework 16 incompatible with JMS583 based NVMe SSD enclosures
Opened this issue · 12 comments
Device Information
System Model or SKU
Framework Laptop 16 (AMD Ryzen™ 7040 Series)
BIOS VERSION
C:\Windows\system32>wmic bios get SMBIOSBIOSVERSION
SMBIOSBIOSVersion
03.05
DIY Edition information
I ordered DIY but the laptop came mostly pre-assembled. (Not complaining, just noting down.)
Memory: I ordered "DDR5-5600 - 32GB (2 x 16GB)", it was already installed and I never replaced it.
Storage: WD Black SN770M 1TB (2230 slot)
Storage: When running Windows 10: Samsung 990 Pro 2TB (2280 slot)
Storage: When running Windows 11: Samsung 970 Evo Plus 2TB (2280 slot)
Port/Peripheral information
https://www.amazon.de/dp/B08C2G7CQF
AGPTEK m.2 NVMe SSD to USB 3.2 Gen 2 (10Gbit/s) enclosure. Uses the JMicron JMS583 chip internally.
- Port the Peripheral was connected to
- Device or expansion card attached to the Adjacent port to the port that is having the issue
See section "Details" below.
Standalone Operation
No
Describe the bug
When the SSD enclosure is connected directly to the laptop, such that it connects with USB 3.2 Gen 2 (10Gbit/s), and files are copied to/from the SSD, then:
- Most of the times, the copy speed quickly drops to zero, stays there for a few seconds, and then the operation fails with a 0x800701B1 error code.
- But sometimes the speed stays at zero for minutes without completely disconnecting. And sometimes the copy continues at wildly inconsistent (i.e. slow) speeds.
- Sometimes I don't even have to start the copy, and simply opening the drive in Explorer causes a disconnect.
- And very rarely it appears to be stable at consistent and plausible speeds.
It seems that different slots also have different behavior... sometimes? It's hard to tell.
Steps To Reproduce
- Put an m.2 NVMe SSD into the enclosure.
- Connect the enclosure directly to the laptop.
- Open the drive in Windows Explorer.
- Copy files off the drive.
Expected behavior
The copy should happen at consistent and high speeds and complete successfully.
Details
Tests
- The problematic m.2 NVMe to USB-C enclosure connects with USB 3.2 Gen 2 (10Gbit/s). I do not have any other devices that feature such a USB connection.
- The issue is not specific to the SSDs in the problematic enclosure. I tried different SSDs.
- The issue does not persist when using an m.2 SATA to USB-C enclosure that connects with USB 3.1 Gen 2 (10Gbit/s).
- The issue is not specific to whether I use a USB-C to USB-C cable connected to a USB-C expansion module, or USB-C to USB-A cable connected to a USB-A expansion module.
- With the USB-C to USB-A cable and a USB-A expansion module, I can do the "half insert trick" (insert the USB-A plug partially at first, wait for the device to show up, then insert it fully). This way, the problematic enclosure connects with USB 2.1 and the issue does not persist.
- The issue is not specific to the used cable. I tried different ones. I also tried skipping the expansion card and connecting directly to the recessed USB-C port, but the issue does persist.
- The issue is not specific to the presence and usage of other expansion modules. The issue persists with nothing else connected to the laptop, with regular use, and with intense use on all modules.
- The issue is not specific to whether I read from or write to the drive.
- The issue does not persist when using a USB stick that connects with USB 3.2 Gen 1 (5Gbit/s).
- The issue does not persist if I use a (passive) USB hub that connects with USB 3.0 (5Gbit/s) and connect the problematic enclosure to that. It does not matter whether I first connect the enclosure to the hub, or the hub to the expansion module.
- The issue does not persist if I use an (active) USB-C dock that connects with 5Gbit/s (I forgot to write down the USB version and I don't have that dock anymore, but it definitely was 5Gbit/s) and connecting the problematic enclosure to that.
- The issue does persist when using a USB-A interposer board with beefy capacitors on the power rails and additional externally supplied 5V.
At some point I got an overcurrent warning when testing on slot 3. I had to reboot to get the port working again.
More tests:
- A family member got a semi-modern laptop (Acer Aspire 5 A517-53-51QS) and I tried the USB enclosure there. It works fine on both USB-C and USB-A ports.
- Through work I got access to a Digitus DA-71546 m.2 docking station and I tried tha tin various combinations.
** Dock powered with the included power supply, data port connected to slot 2.
** Dock powered with Framework 180W charger (laptop on battery power), data port connected to slot 2.
** Dock powered by Framework Laptop slot 3, data port connected to slot 2.
** Dock powered by Framework Laptop slot 2, data port connected to slot 3.
** Multiple different SSDs (NVMe only, no SATA SSDs).
** Reading from and writing to the SSD.
** USB-interposer board on slot 2 with both power and data coming from that one slot (see below).
The issue does not persist at all with the Digitus dock.
About the USB-interposer board:
It's a USB 2 hub with USB 3 passthrough (https://www.amazon.de/dp/B09241T3CS):
(I bridged the 4.7Ω resistor.)
For the tests, I had the data port of the Digitus dock connected to the USB 3 port of the board and the power port of the dock to one of the USB 2 ports. And the entire board was plugged into slot 2 of the Framework Laptop. So the slot actually had to deliver all of the power. The dock connects with USB 3.2 Gen 2 and, as already mentioned, it works fine this way.
The main difference in the output of USB Device Tree Viewer V3.8.7 between the Digitus dock and the problematic JMicron enclosure seems to be that the Digitus dock reports to be self-powered with a "Demanded Current" of 0 mA, where the JMicron enclosure reports to use 896 mA. Maybe the JMicron enclosure draws more current than what's specified and the port shuts off because of that?
Even more tests
- USB-C expansion card and 180W Framework charger on slot 4, USB-A expansion card and SSD enclosure on slot 1: Transfer speed dropped to zero, got stuck there, no disconnect, cancelled after a while
- USB-C expansion card and 180W Framework charger on slot 1, USB-A expansion card and SSD enclosure on slot slots 2, 4 and 6: Transfer speed dropped to zero, got stuck there, no disconnect, cancelled after a while
- USB-C expansion card and 180W Framework charger on slot 1, USB-A expansion card and SSD enclosure on slot slot 3: Maximum transfer speed at ~830MB/s, did not get stuck but the transfer is somewhat unstable with intermittent dips to lower speeds.
- USB-C expansion card and 180W Framework charger on slot 1, USB-A expansion card and SSD enclosure on slot slot 5: The slot stopped working altogether at first (i.e. no USB devices were recognized). After a reboot, it started working again. Maximum transfer speed at ~850MB/s, did not get stuck but the transfer is somewhat unstable.
Note: With the unpowered hub inbetween, the transfer speed is overall lower but very stable (<±2MB/s):
So the fluctuations on slot 3 and 5 don't seem normal to me.
Screenshots
Two examples of copy operations with inconsistent speeds (but no disconnects):
Here's a video that demonstrates the issue:
https://github.com/user-attachments/assets/ba50bd61-6504-42fd-8e3f-e55aeae53fa3
- 00:00 At first, the enclosure is connected to an unpowered hub, which in turn is connected to slot 2.
- 00:03 The screen shows the SSD in the enclosure (P drive) in the top right, one of the internal SSD (C drive) in the bottom right, and USB Device Tree Viewer on the left.
- 00:12 I copy a virtual machine (21.5GiB in total) from P to C. Note how the transfer speed is perfectly stable at 370MiB/s (~3.1Gbit/s).
- 00:23 The transfer finishes successfully. I plug the enclosure directly into slot 2.
- 00:46 (After deleting the previously copied files) I copy the same virtual machine from P to C again.
- 00:51 The transfer speed reaches 0 Bytes/s.
- 01:03 The transfer speed momentarily goes up a few times while I wait, but always quickly goes back down to 0.
- 01:10 I cancel the transfer and wait for a while before giving up and ending the video.
Operating System:
Happens both on Windows 11 23H2 and Windows 10 22H2 with up-to-date drivers and after a mainboard reset.
Additional context
Add any other context about the problem here.
On 2024-11-24 I contacted Framework Support, asking whether there is any progress on this issue, as it was brought up to Framework support already, according to https://community.frame.work/t/amd-framework-and-nvme-ssd-enclosure-compatibility-investigation/41775/12.
On 2025-01-03, after a long and frustrating merry-go-round of ignoring my questions or giving non-sequitor answers, asking questions that I have already answered, giving me unclear and sometimes flat-out wrong instructions, I was instructed to file a new issue for this here.
Can confirm that it is also flaky on my Framework 16, but only on the DP/PD capable ports. Connected to the USB 3.2 ports there are less issues.
And mine are straight USB connections to the laptop (root hub), with nothing in between.
At some point I got an overcurrent warning when testing on slot 3. I had to reboot to get the port working again.
Can't say I ever bumped into that. Maybe it's going to be a problem if you use a particularly power hungry SSD. Framework's USB 5V limit is almost unconveniently low. But the 900mA (1A) ;s according to spec.
About the USB-interposer board: It's a USB 2 hub with USB 3 passthrough (https://www.amazon.de/dp/B09241T3CS):
This stuff is straight-up out-of-spec. Do not expect any connected 3.0 device to work.
00:51 The transfer speed reaches 0 Bytes/s.
It seems like sometimes, there is just a massive delay between the transaction packets. This can be seen when you plug in the drive in BIOS. Sometimes, it take maybe 1 second to scan that external SSD, sometimes it take forever. The theoretical maximum speed is quite rapid, but sometimes it's below USB 2 speeds. This happens outside of a OS environment, let alone a Ubuntu booted from said USB attached storage.
Have you seen this page:
https://knowledgebase.frame.work/en_us/expansion-card-slot-functionality-on-framework-laptop-16-rkUjGm7cn
Specifically read the paragraph about how much power each port can output.
Most nvme enclosures need 3A option, so best to use slot 1 or 4 for the nvme enclosure.
I use slot 1,4 for fast devices, 2 or 5 for PSU, and hardly use slot 3 or 6.
@jcdutton Thanks. I have seen the graphic, but not the information about the current limitation. That explains part of it.
Yesterday I have notived that the right side (port 5) doesn't work with my JMS583 enclosure, I get massive latency. Doesn't seem to work on USB2, either. The port just kept resetting.
Have tested with multiple enclosures from different brands. Orico's, and Aliexpress Specisal 1 and AliExpress Special 2. Aliexpress ones' dont have branding, but one of mine have "ITGZ", and the other "iRhasta",
However, port 4 is able to work with the JMS583 (with the USB-A card). Port 3 works immediately, and Port 2 worked after a brief "port reset". Seem to be switching modes between something. Port 5 seem to have the "port reset" issue. Would get stuck in a weird state that lags all transaction. Sometimes port 6 as well.
Port 5 and 6 resetting is a separate issue. I can replicate that with USB 2 .. USB sticks.
I got a mainboard replacement (slot 4 on mine had a physically damaged USB-C port, covered under warranty), and the new mainboard has the same problem.
You can probably only plug in one USB SSD at a time. Due to the power limits.
It assigned 15W to the first item plugged in, and then only 9W to other devices, Some SSDs need about 10W, so don't work if you plug 2 in at the same time.
@jcdutton I assume your intention is simply to add this as information, but just in case you are trying to point out a possible reason for why this might be happening for me: This issue also happens with just the charger connected, and even with nothing else connected to the laptop at all.
Due to the power limits.
This is true, but also un-true. If you don't run a hub (at least, un-powered hub), you should be able to plug a 1-SSD enclosure into any of the 6 ports.
Some SSDs need about 10W
Can't say I have tested those. But I imagine the enclosure run them at lower speeds (and power consumption) anyway.
@Niko-O Test all your SSD enclsoures by plugging them straight into the USB port on the laptop. I recall having mine work on some of the ports, definitely port 3, and probably port 2.
Updated for test results using the following:
UGREEN RTL9210 + SN740
UGREEN RTL9210B + Samsung 950 Pro.
Both will fail on the lower two ports. These ports are only rated for 900mA.
When running crystaldiskmark. I see periodic current draw from the SSD that goes over this power limit, and this looks like this is triggering OCP protection.
Also as a note, with the SN740, it seems the ssd write pattern is not 100% reproducible. after writing for some time, the SSD will start to generate these current spikes which causes the device to disconnect. However it can also run for 20-30 seconds without generating this waveform.
If I test the same combo of devices on the upper or middle ports (which are rated for 1.5A in a non PD contract). They do not disconnect when running crystaldiskmark.
@CDRXavier It seems I missed to state explicitly in the initial post that I have tried multiple ports already. Specifically, I have notes on failed tests on ports 1, 2, 3, 4 and 6. (And I have "Very inconsistent speed, but succeeded" noted for port 5, but that's just one test.)
It seems that the SSD enclosure initially connects and one can read and write data, but then later on, it disconnects and we think this disconnect is due to the device pulling too many watts.
The following commands are in the package "nvme-cli" on Ubuntu.
The the NVME SSD is connected over PCIe one can do the following commands:
nvme id-ctrl /dev/nvme1 <- Lists the available power profiles that the NVME can do. E.g.
For my SN850X NVME SSD:
ps 0 : mp:9.00W operational enlat:0 exlat:0 rrt:0 rrl:0
rwt:0 rwl:0 idle_power:0.6300W active_power:9.00W
active_power_workload:80K 128KiB SW
ps 1 : mp:6.00W operational enlat:0 exlat:0 rrt:0 rrl:0
rwt:0 rwl:0 idle_power:0.6300W active_power:6.00W
active_power_workload:80K 128KiB SW
ps 2 : mp:4.50W operational enlat:0 exlat:0 rrt:0 rrl:0
rwt:0 rwl:0 idle_power:0.6300W active_power:4.50W
active_power_workload:80K 128KiB SW
ps 3 : mp:0.0250W non-operational enlat:5000 exlat:10000 rrt:3 rrl:3
rwt:3 rwl:3 idle_power:0.0250W active_power:-
active_power_workload:-
ps 4 : mp:0.0050W non-operational enlat:3900 exlat:45700 rrt:4 rrl:4
rwt:4 rwl:4 idle_power:0.0050W active_power:-
active_power_workload:-
So, I can see from that, that limiting it to ps 2 would be a good idea, because the 9W profile is going to draw too much power and limiting to 0.9A/4.5W is probably a good place to start and then try at 1.5A/7.5W.
This command shows the current state the nvme is in:
nvme get-feature /dev/nvme1 -f 2 -H
E.g. for my SN850X:
get-feature:0x02 (Power Management), Current value:00000000
Workload Hint (WH): 0 - No Workload
Power State (PS): 0
The power state is not fixed, it varies continuously depending on what the NVME SSD is doing.
I can limit the max watts that the NVME SSD can use though with:
nvme set-feature /dev/nvme1 --feature-id=2 --value=2
e.g. that will limit it to only use power states 4,3,2 and never use 1 and 0.
I don't have a JMS583, but if it is a thunderbolt 3 / USB 4 device, it will be visible as a PCIe device, and so the above "nvme" commands will work on it.
Now, if the JMS583 is making the device look like a normal block device, e.g. /dev/sdb or /dev/sdc etc.
Then "nvme" commands will not work on it.
Only smartctl commands will work on it.
The problem then becomes how to modify smartctl so that it can send the equivalent of the above nvme commands, but to a /dev/sdb block device.
If smartctl can be modified to do that, then the user could force limit the power draw of the SSD, and thus never run into the problems of disconnects observed by some people here.
Has anyone managed to do that with smartctl ?
I finally decided to buy a new enclosure. I got an Icy Box IB-1808MCT-CU31, which, according to https://cdn-reichelt.de/documents/datenblatt/E900/ICY_1808MCT-CU31_DB-EN.pdf uses a Realtek 9210B chip.
It works fine when directly connected to slot 4, getting ~910MB/s read speeds.
So far it also works fine on slot 6, but getting only ~830MB/s read speeds.