All of a sudden (within a few days), it seems that the LED screen no longer works on the hat with a fresh install of Raspberry Pi OS Lite.
Any clues?
Quad SATA HAT Assembly and Troubleshooting
a try with a backup avail?
I got it! I went into interfaces and enabled SPI and I2C and it all started working great! I was trying to get it working with an OMV6 + Plex image.
I have just received my RPI4 NAS kit with Quad Sata. Everything installs fine. But I can only see 2 drives of the 4. I can move drives around the slots and all drives can be seen individually, but installing more than 2 means I can only see 2 of them.
They do not show up in the hardware lists. lsblk or blkid and I only see 2 devices in lsusb
Not sure how to proceed.
Help appreciated.
Cheers
Tony
- Power off your NAS.
- Try to pull out the USB-Bridge Sparepart, try to clean it, and plug in it back, it’s really sensitive as I experienced after more than 1 year of usage.
- Turn on your NAS and check the results.
Usually I repeat these steps while I can see all of 4 drivers.
1 Like
Hi there -
I just got my Quad SATA HAT and am having issues setting up the RAID. When I launch mdadm, it runs for a little bit and then comes to a screeching halt. Check out the syslog below.
Can anybody help me with that?
Jan 21 11:31:31 nastie kernel: [ 539.360782] sda: sda1
Jan 21 11:31:39 nastie kernel: [ 547.260707] sda: sda1
Jan 21 11:31:59 nastie kernel: [ 567.642104] sda: sda1
Jan 21 11:32:02 nastie kernel: [ 570.508842] sda: sda1
Jan 21 11:32:16 nastie kernel: [ 584.259362] sda:
Jan 21 11:32:16 nastie kernel: [ 584.267564] sda:
Jan 21 11:32:19 nastie kernel: [ 586.956767] sda:
Jan 21 11:33:34 nastie kernel: [ 662.251004] sda: sda1
Jan 21 11:33:37 nastie kernel: [ 665.057616] sda: sda1
Jan 21 11:34:09 nastie kernel: [ 697.210012] sda: sda1
Jan 21 11:34:09 nastie kernel: [ 697.217648] sda: sda1
Jan 21 11:34:11 nastie kernel: [ 698.882504] sda: sda1
Jan 21 11:34:14 nastie kernel: [ 702.195019] sda: sda1
Jan 21 11:34:32 nastie kernel: [ 720.134479] sdb: sdb1
Jan 21 11:34:34 nastie kernel: [ 722.517976] sdb: sdb1
Jan 21 11:34:41 nastie kernel: [ 728.927955] sdb: sdb1
Jan 21 11:35:18 nastie kernel: [ 766.360959] sdc: sdc1
Jan 21 11:35:33 nastie kernel: [ 781.518405] sdd: sdd1
Jan 21 11:35:35 nastie kernel: [ 783.299513] sda: sda1
Jan 21 11:35:40 nastie kernel: [ 787.808349] sda: sda1
Jan 21 11:35:42 nastie kernel: [ 790.342196] sdb: sdb1
Jan 21 11:35:44 nastie kernel: [ 792.482067] sdb: sdb1
Jan 21 11:35:45 nastie kernel: [ 793.475912] sdc: sdc1
Jan 21 11:35:48 nastie kernel: [ 796.115809] sdc: sdc1
Jan 21 11:35:49 nastie kernel: [ 797.612291] sdd: sdd1
Jan 21 11:36:14 nastie kernel: [ 821.992856] sdd: sdd1
Jan 21 11:37:21 nastie kernel: [ 889.124444] raid6: neonx8 gen() 4349 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.192440] raid6: neonx8 xor() 3845 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.260429] raid6: neonx4 gen() 5267 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.328443] raid6: neonx4 xor() 4030 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.396443] raid6: neonx2 gen() 4598 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.464421] raid6: neonx2 xor() 3617 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.532430] raid6: neonx1 gen() 3482 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.600426] raid6: neonx1 xor() 2803 MB/s
Jan 21 11:37:21 nastie kernel: [ 889.668429] raid6: int64x8 gen() 3087 MB/s
Jan 21 11:37:22 nastie kernel: [ 889.736430] raid6: int64x8 xor() 1772 MB/s
Jan 21 11:37:22 nastie kernel: [ 889.804448] raid6: int64x4 gen() 3028 MB/s
Jan 21 11:37:22 nastie kernel: [ 889.872431] raid6: int64x4 xor() 1783 MB/s
Jan 21 11:37:22 nastie kernel: [ 889.940452] raid6: int64x2 gen() 2778 MB/s
Jan 21 11:37:22 nastie kernel: [ 890.008429] raid6: int64x2 xor() 1578 MB/s
Jan 21 11:37:22 nastie kernel: [ 890.076435] raid6: int64x1 gen() 2167 MB/s
Jan 21 11:37:22 nastie kernel: [ 890.144433] raid6: int64x1 xor() 1177 MB/s
Jan 21 11:37:22 nastie kernel: [ 890.144440] raid6: using algorithm neonx4 gen() 5267 MB/s
Jan 21 11:37:22 nastie kernel: [ 890.144444] raid6: .... xor() 4030 MB/s, rmw enabled
Jan 21 11:37:22 nastie kernel: [ 890.144448] raid6: using neon recovery algorithm
Jan 21 11:37:22 nastie kernel: [ 890.147239] xor: measuring software checksum speed
Jan 21 11:37:22 nastie kernel: [ 890.148603] 8regs : 7588 MB/sec
Jan 21 11:37:22 nastie kernel: [ 890.149730] 32regs : 8774 MB/sec
Jan 21 11:37:22 nastie kernel: [ 890.151018] arm64_neon : 7669 MB/sec
Jan 21 11:37:22 nastie kernel: [ 890.151022] xor: using function: 32regs (8774 MB/sec)
Jan 21 11:37:22 nastie kernel: [ 890.152357] async_tx: api initialized (async)
Jan 21 11:37:22 nastie kernel: [ 890.169166] md/raid:md0: device sdc1 operational as raid disk 2
Jan 21 11:37:22 nastie kernel: [ 890.169177] md/raid:md0: device sdb1 operational as raid disk 1
Jan 21 11:37:22 nastie kernel: [ 890.169182] md/raid:md0: device sda1 operational as raid disk 0
Jan 21 11:37:22 nastie kernel: [ 890.170843] md/raid:md0: raid level 5 active with 3 out of 4 devices, algorithm 2
Jan 21 11:37:22 nastie kernel: [ 890.170874] md0: Warning: Device sdd1 is misaligned
Jan 21 11:37:22 nastie kernel: [ 890.193366] md0: detected capacity change from 0 to 6000690069504
Jan 21 11:37:22 nastie kernel: [ 890.197206] md: recovery of RAID array md0
Jan 21 11:37:34 nastie systemd[1]: Starting Cleanup of Temporary Directories...
Jan 21 11:37:34 nastie systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Jan 21 11:37:34 nastie systemd[1]: Finished Cleanup of Temporary Directories.
Jan 21 11:38:31 nastie kernel: [ 959.481481] sd 0:0:0:0: [sda] tag#12 uas_eh_abort_handler 0 uas-tag 4 inflight: IN
Jan 21 11:38:31 nastie kernel: [ 959.481495] sd 0:0:0:0: [sda] tag#12 CDB: opcode=0x28 28 00 00 7c fe 07 00 04 00 00
Jan 21 11:38:31 nastie kernel: [ 959.497486] scsi host0: uas_eh_device_reset_handler start
Jan 21 11:38:31 nastie kernel: [ 959.626199] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Jan 21 11:38:31 nastie kernel: [ 959.646495] usb 2-2: device firmware changed
Jan 21 11:38:31 nastie kernel: [ 959.654695] scsi host0: uas_eh_device_reset_handler FAILED err -19
Jan 21 11:38:31 nastie kernel: [ 959.654710] sd 0:0:0:0: Device offlined - not ready after error recovery
Jan 21 11:38:31 nastie kernel: [ 959.654765] sd 0:0:0:0: [sda] tag#12 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=31s
Jan 21 11:38:31 nastie kernel: [ 959.654773] sd 0:0:0:0: [sda] tag#12 CDB: opcode=0x28 28 00 00 7c fe 07 00 04 00 00
Jan 21 11:38:31 nastie kernel: [ 959.654781] blk_update_request: I/O error, dev sda, sector 8191495 op 0x0:(READ) flags 0x0 phys_seg 128 prio class 0
Jan 21 11:38:31 nastie kernel: [ 959.654791] md/raid:md0: read error not correctable (sector 8125960 on sda1).
...
Jan 21 11:38:31 nastie kernel: [ 959.654843] md/raid:md0: read error not correctable (sector 8126032 on sda1).
Jan 21 11:38:31 nastie kernel: [ 959.655016] sd 0:0:0:0: rejecting I/O to offline device
Jan 21 11:38:31 nastie kernel: [ 959.655019] blk_update_request: I/O error, dev sda, sector 8191503 op 0x0:(READ) flags 0x4000 phys_seg 1 prio class 0
...
Jan 21 11:38:31 nastie kernel: [ 959.655080] blk_update_request: I/O error, dev sda, sector 8191551 op 0x0:(READ) flags 0x4000 phys_seg 1 prio class 0
Jan 21 11:38:31 nastie kernel: [ 959.655209] usb 2-2: USB disconnect, device number 2
Jan 21 11:38:31 nastie kernel: [ 959.655423] md: super_written gets error=-5
Jan 21 11:38:31 nastie kernel: [ 959.661537] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Jan 21 11:38:32 nastie kernel: [ 959.733483] sd 0:0:0:1: [sdb] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s
Jan 21 11:38:32 nastie kernel: [ 959.733498] sd 0:0:0:1: [sdb] tag#6 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
Jan 21 11:38:32 nastie kernel: [ 959.733514] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.733683] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.733693] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.805481] sd 0:0:0:1: [sdb] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s
Jan 21 11:38:32 nastie kernel: [ 959.805493] sd 0:0:0:1: [sdb] tag#6 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
Jan 21 11:38:32 nastie kernel: [ 959.805506] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.805659] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.881480] sd 0:0:0:1: [sdb] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s
Jan 21 11:38:32 nastie kernel: [ 959.881492] sd 0:0:0:1: [sdb] tag#6 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
Jan 21 11:38:32 nastie kernel: [ 959.881504] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.881653] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.881662] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.913493] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00
Jan 21 11:38:32 nastie kernel: [ 959.953485] sd 0:0:0:1: [sdb] tag#5 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s
Jan 21 11:38:32 nastie kernel: [ 959.953496] sd 0:0:0:1: [sdb] tag#5 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
Jan 21 11:38:32 nastie kernel: [ 959.953510] md: super_written gets error=-5
...
Jan 21 11:38:32 nastie kernel: [ 959.954320] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 959.954563] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
Jan 21 11:38:32 nastie kernel: [ 959.955764] md: super_written gets error=-5
...
Jan 21 11:38:32 nastie kernel: [ 960.264179] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.265524] sd 0:0:0:1: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00
Jan 21 11:38:32 nastie kernel: [ 960.266206] md: super_written gets error=-5
...
Jan 21 11:38:32 nastie kernel: [ 960.526793] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.527369] usb 2-2: New USB device found, idVendor=152d, idProduct=0561, bcdDevice=81.36
Jan 21 11:38:32 nastie kernel: [ 960.527375] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Jan 21 11:38:32 nastie kernel: [ 960.527380] usb 2-2: Product: External Disk 3.0
Jan 21 11:38:32 nastie kernel: [ 960.527384] usb 2-2: Manufacturer: JMicron
Jan 21 11:38:32 nastie kernel: [ 960.527388] usb 2-2: SerialNumber: RANDOM__7CDEBB6A0840
Jan 21 11:38:32 nastie kernel: [ 960.528241] md: super_written gets error=-5
...
Jan 21 11:38:32 nastie kernel: [ 960.535054] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.535429] scsi host2: uas
Jan 21 11:38:32 nastie kernel: [ 960.536344] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.536377] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.536397] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.536406] scsi 2:0:0:0: Direct-Access JMicron Tech 8136 PQ: 0 ANSI: 6
Jan 21 11:38:32 nastie kernel: [ 960.537723] sd 2:0:0:0: Attached scsi generic sg0 type 0
Jan 21 11:38:32 nastie kernel: [ 960.538744] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.538773] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.538913] scsi 2:0:0:1: Direct-Access JMicron Tech 8136 PQ: 0 ANSI: 6
Jan 21 11:38:32 nastie kernel: [ 960.539029] sd 2:0:0:0: [sde] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
Jan 21 11:38:32 nastie kernel: [ 960.539294] sd 2:0:0:0: [sde] Write Protect is off
Jan 21 11:38:32 nastie kernel: [ 960.539300] sd 2:0:0:0: [sde] Mode Sense: 67 00 10 08
Jan 21 11:38:32 nastie kernel: [ 960.540103] sd 2:0:0:0: [sde] Write cache: enabled, read cache: enabled, supports DPO and FUA
Jan 21 11:38:32 nastie kernel: [ 960.540234] scsi 2:0:0:1: Attached scsi generic sg1 type 0
Jan 21 11:38:32 nastie kernel: [ 960.540907] sd 2:0:0:0: [sde] Optimal transfer size 33553920 bytes
Jan 21 11:38:32 nastie kernel: [ 960.542251] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.542289] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.543075] sd 2:0:0:1: [sdf] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
Jan 21 11:38:32 nastie kernel: [ 960.543345] sd 2:0:0:1: [sdf] Write Protect is off
Jan 21 11:38:32 nastie kernel: [ 960.543353] sd 2:0:0:1: [sdf] Mode Sense: 67 00 10 08
Jan 21 11:38:32 nastie kernel: [ 960.543852] sd 2:0:0:1: [sdf] Write cache: enabled, read cache: enabled, supports DPO and FUA
Jan 21 11:38:32 nastie kernel: [ 960.544235] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.544259] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.544660] sd 2:0:0:1: [sdf] Optimal transfer size 33553920 bytes
Jan 21 11:38:32 nastie kernel: [ 960.545619] md: super_written gets error=-5
...
Jan 21 11:38:32 nastie kernel: [ 960.561995] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.562089] sdf: sdf1
Jan 21 11:38:32 nastie kernel: [ 960.563064] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.563105] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.564218] sde: sde1
Jan 21 11:38:32 nastie kernel: [ 960.565133] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.565147] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.566239] sd 2:0:0:1: [sdf] Attached SCSI disk
Jan 21 11:38:32 nastie kernel: [ 960.566493] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.566530] md: super_written gets error=-5
Jan 21 11:38:32 nastie kernel: [ 960.567288] sd 2:0:0:0: [sde] Attached SCSI disk
Jan 21 11:38:32 nastie kernel: [ 960.568410] md: super_written gets error=-5
...
Jan 21 11:38:32 nastie kernel: [ 960.660238] md: super_written gets error=-5
Jan 21 11:38:33 nastie kernel: [ 960.699772] md0: detected capacity change from 6000690069504 to 0
Jan 21 11:38:33 nastie kernel: [ 960.699796] md: md0 stopped.
Jan 21 11:38:33 nastie systemd-udevd[4781]: sdb1: Process '/sbin/mdadm -If sdb1 --path platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:1' failed with exit code 1.
Jan 21 11:38:33 nastie mtp-probe: checking bus 2, device 4: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2"
Jan 21 11:38:33 nastie mtp-probe: bus: 2, device: 4 was not an MTP device
Jan 21 11:38:33 nastie mtp-probe: checking bus 2, device 4: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2"
Jan 21 11:38:33 nastie mtp-probe: bus: 2, device: 4 was not an MTP device
1 Like
I faced exactly the same problem, did you manage to solve it somehow?
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.