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