USB-SATA-connector not always visible: in certain situations found with "lsusb", but sata hdd is never shown in /dev/

Ask Fedora
, ,
1

I have a new SATA HDD and a SATA connector (incl. support UASP, TRIM [unrelated to HDD]), which the vendor says is Linux compatible with 2.6.3+. The chip is ASM1153, which is documented to be Linux compatible.

I use it with a 3,5" HDD, so it needs additional power. When everything is connected (power to HDD and subsequently HDD to USB), the HDD is shortly running but then goes to sleep: it is never shown in the system. The same for the USB connector, which is not in lsusb that way. I assumed the latter is the origin of the first. When I re-connect power, the disk comes back and goes sleep again. When I re-connect USB, nothing occurs at all. In all cases, nothing is shown.

However, when I removed the power cable of the connector, and plugged in solely the USB-SATA-connector to the USB/Laptop (no HDD nor power cable in USB-SATA-connector), it became visible:
lsusb | grep ASMedia Bus 004 Device 000: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge

However, the HDD does not work without external power, so I connected it again, first HDD, then Power cable:
Now the HDD starts again, and while the lsusb | grep ASMedia output disappears for a moment, it comes back after a few seconds: I get now the output in KDE that the device “ugreen … … USB storage” was connected (ugreen is the USB-SATA-connector vendor), but I cannot identify a device. After some time, also the lsusb | grep ASMedia output disappears again, KDE says its disconnected, and I am back to the origin.

If I want to reproduce this “best outcome”, I need to unplug everything at all, then plugin the USB-connector by USB, then attach the HDD, then attach power.

I have just started to search, but having not played with stuff like this for long, I thought someone maybe knows of the cuff to explain this behavior :classic_smiley: My expectation at this time is that the compatibility is limited and this will not work out reliably, but maybe I prove wrong :slight_smile:

Happy to offer more details if required.

I cannot exclude a relation about this:

  • just for the record (while I think it is not useful here): ls /dev/ -la | grep <minute of connecting> suggests that crw-rw-rw-. 1 root tty 5, 2 Feb 12 12:45 ptmx gets updated when doing the “best outcome” plugging in. The same for /dev/block, but the latter’s content does not change.

  • Just to have it tested: I tried to open updated entries in /dev/ with parted, but they are no storage devices :classic_smiley:

  • The journal does not contain useful information, except a correlating log in two cases, which would suggest the kernel tried to consider the USB device as smart card reader and then as printer (each time both first printer treatment and then smartcard reader treatment; though this correlated only twice in many more test cases) [1].

  • I cannot exclude the HDD to have experienced a transport damage due to unsafe shipment.

[1] one of the two cases, just in case someone finds it relevant:

Feb 12 12:02:38 fedora rtkit-daemon[1975]: Successfully made thread 22206 of process 21271 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.
Feb 12 12:02:35 fedora pcscd[5187]: 00000142 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client
Feb 12 12:02:35 fedora pcscd[5187]: 00023941 ../src/auth.c:166:IsClientAuthorized() Process 22140 (user: 1000) is NOT authorized for action: access_pcsc
Feb 12 12:02:35 fedora pcscd[5187]: 00000140 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client
Feb 12 12:02:35 fedora pcscd[5187]: 00024061 ../src/auth.c:166:IsClientAuthorized() Process 22140 (user: 1000) is NOT authorized for action: access_pcsc
Feb 12 12:02:35 fedora pcscd[5187]: 00000108 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client
Feb 12 12:02:35 fedora pcscd[5187]: 00023968 ../src/auth.c:166:IsClientAuthorized() Process 22140 (user: 1000) is NOT authorized for action: access_pcsc
Feb 12 12:02:35 fedora pcscd[5187]: 00000359 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client
Feb 12 12:02:35 fedora pcscd[5187]: 99999999 ../src/auth.c:166:IsClientAuthorized() Process 22140 (user: 1000) is NOT authorized for action: access_pcsc
Feb 12 12:02:30 fedora cupsd[2187]: REQUEST localhost - - "POST / HTTP/1.1" 200 564 Create-Printer-Subscriptions successful-ok
Feb 12 12:02:30 fedora cupsd[2187]: REQUEST localhost - - "POST / HTTP/1.1" 200 215 Create-Printer-Subscriptions client-error-bad-request
Feb 12 12:02:30 fedora cupsd[2187]: [Client 9] Returning IPP client-error-bad-request for Create-Printer-Subscriptions (/) from localhost.
Feb 12 12:02:30 fedora cupsd[2187]: REQUEST localhost - - "POST / HTTP/1.1" 200 185 Renew-Subscription client-error-not-found
Feb 12 12:02:28 fedora cupsd[2187]: REQUEST localhost - - "POST / HTTP/1.1" 200 303 Create-Printer-Subscriptions successful-ok
Feb 12 12:02:28 fedora cupsd[2187]: REQUEST localhost - - "POST / HTTP/1.1" 200 215 Create-Printer-Subscriptions client-error-bad-request
Feb 12 12:02:28 fedora cupsd[2187]: [Client 8] Returning IPP client-error-bad-request for Create-Printer-Subscriptions (/) from localhost.
Feb 12 12:02:28 fedora cupsd[2187]: REQUEST localhost - - "POST / HTTP/1.1" 200 185 Renew-Subscription client-error-not-found
Feb 12 12:02:23 fedora kdeconnectd[3629]: No uuids found for "DF:3E:F8:66:91:D1"
2

From https://linux-hardware.org/?id=usb:174c-1153 looks like your adapter doesn’t work for lots of other linux users. I do have a couple uGreen USB3 external cases with power dongles that are working well with macOS. There are also a lot of bugzilla entries for thus USB ID at kernel.org.

1 Like
3

Interesting, didn’t know that list. I found some other threads before I bought the controller that suggested it worked well on some Linux variants.

Ever tested a UASP-supporting one on Linux to verify if general capability is given?

4

I checked the list in more depth now, and if I go through it, there are also many that work fine: for the majority it works.
It is just the first 3.5 out of 46 pages that contain the fails. The way this list is ordered makes it look worse than it is. That said, many also just confirm “connected”. However, I found another report that suggests this might be a USB3 problem and the device works when used on USB2. I’ll check out if that proves true in my case as well.

Supplement: not identified on a USB2 laptop too when pluggin in the power-connected HDD-connected USB-SATA-connector through USB2.

5

A search for systems similar to the one with the issue that also report the same adapter would be more definitive, but the kernel.org bugzilla threads may explain why it happens. I will try one of my Ugreen cases with current linux when I have time in case recent kernels are causing the problem.

6

F42 has working cases, so I would not think that it is a general kernel issue. A lot can trigger bugs in one situation but not other though , but I could not find indicative counter/parallel cases. What I find is that some have issues with uas, but I tried without (both blacklisting and quirks for the hardware id), doesn’t make a difference. However, with the device I can provoke another error log that in one other case could be traced to the ugreen device using this chip, so it occurred only with the device, but not others. Might be indicative. A centOS broke the same way, but it was within a VM, and the one moment the device disappears temporarily broke the experiment obviously because this also breaks the forwarding to the VM. So I can only say that the initial symptom is the same on the CentOS 10 kernel. However, I also do not exclude that the hdd is the origin.

I do a few more tests, but tend already to check out other devices / chipsets. I’ll have a review later to the kernel reports, but if you review one in specific that looks indicative, feel free to share the BZ# :classic_smiley: It’s not critical though. This device was cheap and had UASP, and several reports indicated it to work with Linux. It was a risk worth taken :classic_smiley: Thanks anyway for your support!

7

If anyone knows a USB3 → SATA3 bridge with dedicated power connector (necessary for 3,5" HDD), preferably with UASP, that works reliable with an unpatched Fedora kernel, feel free to share the device’s name :classic_smiley:

8

Update: Issues are in some cases related to firmware issues. Further, it might be not sufficiently precise to consider the chip ( ASM1153) but it is necessary to evaluate the hardware ID, which differs among different ASM1153 devices. That seems to be more indicative not only for stability but also actual UASP-support on Linux. Some devices seem to be more arbitrary in different constellations than others, and some seem generally to work fine (all based on a subjective/non-representative selection of reports).

9

Connected one of my UGreen external SATA HDD drive cases with power dongle to F43. lsusb gives:

Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s

I’ve been using a couple of these with older Fedora versions for several years. They support S.M.A.R.T and have been problem free.

1 Like
10

I assume you don’t know the very product? An article number or so? Amazon and such only show the chip (at best), not the hardware ID, and as I can see it in my current case, it is the hardware ID that makes the difference, whereas my chip exists with different hardware IDs, some working fine, some not (the last 4 digits of the ID make the game of being useful or not, at least with the devices with my chip) :classic_smiley:

I just checked the very device I have, and I keep wondering that its reports at amazon are filled with people confirming it works out of the box with linux and UASP (one reason I bought it). I wonder it that is related to some patch of Ubuntu, as all reports that referene a linux do ubuntu or mint, both running the (heavily patched) ubuntu kernel. Alternatively remains the possibility of the HDD being broken (or the rare case of issues with backward compatibility), but the symptoms are strange for that though, even if it was the case. Ironically, I found reports of JMS578 that resembled my issue :joy:

11

UGREEN 3.5" Hard Drive Enclosure USB 3.0 to SATA III Adapter, but the “specs” don’t provide a USB ID, so they may have changed the chipset. I relied on online reviews that reported “works” with MacOS and Linux. There negative reviews complaining that drive doesn’t power up after a power failure. Mine are on UPS.

1 Like
12

Thanks. I still wonder that my exact device is filled on amazon with +1 Linux reviews, including many in 2025 (which is one reason why I bought it). I didn’t expect that the Ubuntu kernel (making up most reviews) is patched in this area, but who knows… I have the chip I expected but it is listed with the 3 Gbit driver, so it could be also one of the rare cases of lack of backward compatibility. This field seems indeed a mess and one can only buy and hope. I have to find out soon if I have to return the HDD so I will just buy something that has some +1 and hope ^^ Thanks again for your support :classic_smiley:

13

Have you checked for the firmware?

fwupdmgr get-devices

P.S.

Certain versions of Linux running kernel 2.6.3 and higher can take advantage of UASP, but it is limited to only a small number of supported hardware.

#source  https://www.minitool.com/lib/uasp.html