I faced exactly the same problem, did you manage to solve it somehow?
Quad SATA HAT Assembly and Troubleshooting
I did not. Had to ditch my SATA HAT again. I think it’s a deficiency of the controller.
I found the problem, but unfortunately without hardware intervention it cannot be solved. It was a mistake on the part of the developer to tie the operation of the disks to the signal from the GPIO. Raspberry is not such a powerful device to eliminate noise in the interface, as a result, the circuit incorrectly perceives the signal and momentarily turns off one of the SATA controllers, which leads to the destruction of the RAID array.
I’m trying to rewrite Python scripts to interact with GPIO as little as possible.
Have you tried turning off UAS (USB Attached Storage)? Some article indicate that it may have this transient disconnect and then reconnect of the controllers. As an example: https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS).
I have experienced similar kinds of things with my Quad SATA HAT when trying to rsync to an external USB 2.0 drive, but I have not yet done the UAS disablement, as I move my raid 5 drives over to a Penta SATA HAT and then experiment with the Quad hat.
Thanks a lot! The problem of sudden destruction of the RAID array can be solved. Adding the parameter usb-storage.quirks=152d:0561:u to the /boot/cmdline.txt file.
But a new problem arose. When trying to view SMART information about a disk, the disk will crash with an udisksd error
Error probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sda': Unexpected sense data returned:
0000: 70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 p...............
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
(g-io-error-quark, 0)Try the solution by adding usb-storage.quirks=152d:0561:u to /boot/cmdline.txt.
But first look at the identifier of your controller by entering the lsusb command
Were you able to read the SMART information before unloading the UAS functionality?
What drive(s) do you have attached?
Information is read in any modes, but the disk then falls off. When using UAS discs fall off spontaneously.
I am using 4x WD Blue WD10SPZX.
Unfortunately (or not) I have not had that problem. I am running with UAS disabled and have no problems running ‘smartctl -a /dev/sda’ or sdb.
It is just a play system at the moment, though I had used it as a (3-active, 1-spare) raid-5 NAS accessed through OMV 5 for over a year and had few problems, though I could occasionally get the controllers disappearing and re-appearing when I was doing an rsync to an external USB2.0 SSD drive, thus creating a high load. My drives were Seagate 2TB BarraCuda (ST2000LM015). During that time I had had UAS enabled.
I had no problems with OMV being able to read SMART, and had the SATA HAT software running that shows drive temps, so it was running smartctl too.
I had the older firmware in the controllers during its active service as a NAS, though I have upgraded.
I don’t know if this article has any applicability: https://bbs.archlinux.org/viewtopic.php?id=231161
I guess I should not have said that I had no problems because I immediately did where the jmicron controllers detached and re-attached. my sda drive (which was not mounted) came back as sda, my sdb drive, which was mounted and in use, came back as sdc, and appears to not have a directory block because the /dev/sdb1 partition (which is no longer there) is what is mounted in the file system.
Rebooted the raspberry and all was back again. I note that I had tried to look at the smart data through the OMV6, and that got an error, though I was able to get smart data on both sda and sdb through smartctl.
For me it was also the smartctl (as installed) which caused the disconnect. Reproduced it with the sdb drive (which was mounted, and remained mounted), which became sdc.
Used smartctl -a /dev/sdb and got:
Read SMART Self-test Log failed: scsi error aborted command
I had previously, on this hardware, but on an earlier Raspbian lite with an upgraded smartmontools (which support the JSON generation) been able to continuously do smartctl as part of getting disk temps (sudo smartctl -A /dev/sdb).
I tested smartctl with the -a and -A parameters. With the -A I appeared to get good stuff, and still had the disk. With smartctl -a I got the “Read SMART Self-test Log failed: scsi error aborted command” and the drive was gone. Retesting the new sdc drive (which was not mounted) did not abort the controller, though it still had the log read error.
I tried with my /dev/sda device. No problems doing smartctl _a or -a on the unmounted drive. When I mounted the sda1 partition I could do multiple smartctl -A commands on it, but the first smartctl -a command (which logged no SMART errors) blew it away. So it had to be smartctl -A and the drive needed a mounted partition.
See if it works for you not doing the -a.
I did a little experimentation, following the smartctl man page. I individually did a smartctl on a drive with a mounted partition using all the sub-arguments that -a provides:
-a, --all
Prints all SMART information about the disk, or TapeAlert information about the tape drive or changer. For ATA devices this is equivalent to
‘-H -i -c -A -l error -l selftest -l selective’
and for SCSI, this is equivalent to
‘-H -i -A -l error -l selftest’.
Each test was run with one of the arguments, tail dmesg, repeat both steps a second time.
The options -A, -H, -i produced no problems but ‘-l error’ blew the controller away, to be re-recognized and the sda drive became sdc.
So going for the error log is not a good thing and -a should be avoided. (I did not test with ‘-l selftest’.
Hello
I have a problem with my SATA HAT (for Raspberry Pi4).
I observed that my harddisks (4 SSDs) disappear after a few days of usage.
It seems that the USB 3.0 bridge (the PCB with 4 USB male connectors on it) is faulty.
I can sometimes get it to work by removing the bridge and reinserting it again.
I thought that I can replace it with 2 short USB 3.0 cables with male to male connectors (A-A).
So I bought 2 cables and connected them instead of the faulty bridge. Unfortunately the cables do not work (and I am sure they are correct, they are new from a shop and tested). Why I can’t use such cables? How can I replace the faulty USB bridge? Where I can buy new bridge replacement?
Best regards
Have you tried this method?
You can use just cables I think, but you can buy new bridge from here: https://shop.allnetchina.cn/collections/sata-hat/products/quad-sata-kit-usb-bridge-sparepart
Sadly, it’s sold out, so you have to wait 
But in my case, my bridge is also REALLY SENSITIVE, so if you touch it a little bit, it will definitely interrupt the connection between the RPi4 and HDDs.
You might be able to loosen the hat and the Pi screws, push both hard over towards the USB socket end, and retighten. I do not know how much slop is left over, but I found that the bridge plug lengths are somewhat shorter than the plug lengths on other USB cables I have, With the case being between the boards and the plug, anything you can do to shorten the gap might make a difference.
Is there a way to turn off all LED? Both on raspberry pi 4 and the quad sata hat?
My new quad hat is only partly working so far. The little screen on the fan is displaying CPU load, uptime, etc, and the little blue light is on next to the one 2.5 sata drive in socket 1. However, the drive itself is not showing up in lsblk nor can OpenMediaVault find it. It is the v1.3 quad hat on a Pi 4 4GB. I tried 3 different 2.5 drives, one at a time, that all work in another system. Any ideas how I might get it going?
Hi !
I have finally recieved my RPi4 and have been able plug in the quad sata hat I bought way back in 2020.
I’m experiencing a problem with port number 4, although I have a drive plugged-in it just doesn’t work, the corresponding LED never lights up, and only drives sda through sdc show in /dev/
I’ve tried to swap two drives together and the problems is still with port number 4. I’ve tried to unplug and clean the USB bridge to no avail. What can be done to solve this problem, could it be that I ended up with a faulty board or bridge or something of that nature ?
Help would be very much appreciated
Hi !
I have some news on my issue.
I’ve tried to plug less than four drives and no matter what I do, whether it’s a single HDD, two or three, any drive plugged into the fourth SATA port never shows up. The LED never lights up and it can’t be found in /dev/
I’ve also tried without the bridge and the LEDs do light up on SATA ports 1 through 3 but not on 4.
So in my mind, it rules out the eventuality of a faulty USB bridge and leaves me with either :
- A software issue (but it seems unlickely since ports 1 to 3 work out of the box)
- A faulty topboard
Does anyone have an idea on how to solve this ?
Hi @Bowbaq,
The SATA 2 and SATA 4 use the same USB. it looks like there may be a problem with the SATA 4 socket, can you take a clear photo of the back and send it to me via email at setq@radxa.com