Penta SATA HAT power input causing unstable Raspberry Pi 5 USB 3.0 ports? My testing and findings

Hardware and peripherals SATA HAT
1

Hi,

I would like to share an issue I discovered with my Raspberry Pi 5 + Radxa Penta SATA HAT setup, and ask whether anyone else has experienced similar behaviour.

My setup

  • Raspberry Pi 5, 12 GB RAM

  • Radxa Penta SATA HAT

  • 4 × Samsung 870 QVO 2 TB SATA SSDs

  • ZFS RAIDZ1 pool (tank)

  • OpenMediaVault

  • Docker/containers, including Immich

  • Kingston XS1000 2 TB external USB SSD

For normal operation, I powered the complete NAS through the DC power input on the Penta SATA HAT.

The power supply is:

Mean Well GST60A12-P1J

  • Output: 12 V DC

  • Maximum current: 5.0 A

  • Maximum power: 60 W

The Mean Well PSU is connected directly to the DC jack on the Penta SATA HAT, and the Raspberry Pi 5 is therefore also powered through the HAT.

I specifically selected a 12 V / 5 A, 60 W Mean Well PSU after reading the Penta SATA HAT power recommendations, because I wanted sufficient power headroom for the Raspberry Pi 5 and four SATA SSDs.

The four Samsung SATA SSDs and the ZFS pool have been operating normally in this configuration.

The problem appeared when I connected a Kingston XS1000 2 TB external SSD directly to one of the Raspberry Pi 5 USB 3 ports to use it as a backup drive.

Initial symptoms

The XS1000 would initially be detected correctly as a SuperSpeed USB device.

For example:

new SuperSpeed USB device
Product: XS1000
Manufacturer: Kingston
scsi host0: uas
[sda] 3907029168 512-byte logical blocks

However, after some I/O activity, the drive would disappear completely from the system.

lsblk would no longer show the XS1000.

The kernel log repeatedly showed errors such as:

Device not responding to setup address
device not accepting address, error -71
device descriptor read/64, error -110
reset high-speed USB device using xhci-hcd
attempt power cycle
USB disconnect
Buffer I/O error on dev sda1
unable to enumerate USB device

During an rsync backup, the failure looked like this:

rsync: [receiver] write failed ... Input/output error (5)

rsync error: error in file IO (code 11)

rsync: [sender] write error: Broken pipe (32)

The USB disconnect occurred while writing to the XS1000 and caused filesystem corruption on the EXT4 filesystem.

Things I tested

I tried to eliminate the obvious causes one by one.

Different USB ports

I tested both blue USB 3 ports on the Raspberry Pi 5.

The problem occurred on both.

Different USB cables

I tested more than one USB cable.

I even tested with a cable that connected the XS1000 at USB 2 speed.

The drive still eventually disappeared.

USB fan removed

I normally had a small USB fan connected to the Pi.

I removed the fan completely during troubleshooting so the XS1000 was essentially the only external USB load.

The problem remained.

Raspberry Pi bootloader updated

I updated the Raspberry Pi bootloader.

After the update:

BOOTLOADER: up to date
CURRENT: Tue May 26 15:01:25 UTC 2026
LATEST: Tue May 26 15:01:25 UTC 2026

Kernel:

Linux pi-nas 6.12.96+rpt-rpi-2712

The problem remained.

No reported undervoltage

Throughout the tests:

vcgencmd get_throttled

returned:

throttled=0x0

So the Raspberry Pi itself did not report an undervoltage or throttling event.

UAS test

The Kingston XS1000 identifies as:

idVendor=0951
idProduct=1780

Because UAS can sometimes cause compatibility issues with USB storage devices, I temporarily disabled UAS specifically for the XS1000 using:

usb-storage.quirks=0951:1780:u

After rebooting, lsusb -t correctly showed:

Class=Mass Storage, Driver=usb-storage, 5000M

instead of:

Driver=uas

However, the disconnect problem remained.

The XS1000 still disappeared and the kernel again reported:

Device not responding to setup address
device not accepting address, error -71
attempt power cycle

Therefore, UAS did not appear to be the root cause.

Filesystem check also triggered the problem

Even a read-only filesystem check:

sudo e2fsck -f -n /dev/sdX1

would fail on the NAS Pi with:

e2fsck: Input/output error while trying to open /dev/sdX1

Shortly afterwards, the XS1000 would disappear from lsblk.

This was important because it showed that the issue was not specific to rsync or heavy write operations.

Even ordinary read access could trigger the failure.

Control test on another Raspberry Pi

To determine whether the Kingston XS1000 or its cable was defective, I connected exactly the same XS1000 to another Raspberry Pi 5 that I use as a Pi-hole server.

That Raspberry Pi is powered using an official Raspberry Pi USB-C power supply.

The XS1000 was detected normally as:

/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M

The kernel detected it cleanly:

usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
usb 2-1: New USB device found, idVendor=0951, idProduct=1780
usb 2-1: Product: XS1000
usb 2-1: Manufacturer: Kingston
scsi host0: uas
sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk

There were no USB errors.

I then ran:

sudo e2fsck -f -n /dev/sda1

Unlike on the NAS Pi, the filesystem could be read successfully.

The previous USB disconnects on the NAS had caused filesystem errors, so I repaired them using:

sudo e2fsck -f -y /dev/sda1

The repair completed normally:

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 123514/122101760 files (1.2% non-contiguous),
97808364/488378384 blocks

I then ran another read-only filesystem check:

sudo e2fsck -f -n /dev/sda1

It completed all five passes successfully:

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

There were no filesystem errors and, importantly, no USB disconnects or USB errors in dmesg.

This made the XS1000 itself, its cable and UAS much less likely to be the cause.

Power supply test on the NAS Raspberry Pi

I then changed only the power arrangement of the NAS.

Instead of powering the complete system through:

Mean Well 12 V / 5 A PSU → Penta SATA HAT DC input → Raspberry Pi

I disconnected the HAT DC power input and connected an official Raspberry Pi USB-C power supply directly to the Raspberry Pi 5.

The Penta SATA HAT remained installed.

All four Samsung 870 QVO SSDs remained installed and visible.

The ZFS pool remained available.

Immediately after boot:

vcgencmd get_throttled

returned:

throttled=0x0

All four SATA SSDs were detected normally.

I then connected exactly the same Kingston XS1000 to the Raspberry Pi USB 3 port.

The result was completely different.

The drive remained stable.

e2fsck test with official Raspberry Pi PSU

On the NAS itself, now powered directly via USB-C, I ran:

sudo e2fsck -f -n /dev/sde1

The same command that previously caused the USB device to disappear now completed all five passes successfully:

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

No USB errors occurred.

Sustained raw read test

I then performed a sustained sequential read test:

sudo dd if=/dev/sde1 of=/dev/null bs=16M status=progress

The XS1000 sustained approximately:

370–371 MB/s

I stopped the test after more than 11 minutes:

253738614784 bytes (254 GB, 236 GiB) copied, 683 s, 371 MB/s

So approximately 254 GB was read continuously without a single USB disconnect.

After the test:

vcgencmd get_throttled

still reported:

throttled=0x0

and dmesg contained no USB resets, no error -71, no error -110, and no disconnects.

Final UAS test

I then removed the temporary UAS quirk and rebooted.

The XS1000 returned to normal UAS operation:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M

Again, the XS1000 remained stable.

This further confirmed that UAS itself was not the problem.

Real-world rsync stress test

Finally, I performed a real backup workload from the ZFS pool to the XS1000 using rsync.

The final result was:

545,857,983,373 100% 145.87MB/s 0:59:28
(xfr#435477, to-chk=0/631394)

So the system processed approximately 546 GB during almost one hour of sustained real-world activity, involving more than 435,000 transferred files and more than 630,000 checked items.

During the entire operation there was no USB disconnect.

After the transfer:

vcgencmd get_throttled

still returned:

throttled=0x0

and dmesg contained no:

error -71
error -110
USB disconnect
reset SuperSpeed USB device
Buffer I/O error
attempt power cycle

What appears to make the difference

The same hardware behaves very differently depending on how the Raspberry Pi 5 is powered.

Penta SATA HAT DC input

Mean Well GST60A12-P1J
12 V / 5 A / 60 W
        |
        v
Penta SATA HAT DC input
        |
        v
Raspberry Pi 5
        |
        v
USB 3 port → Kingston XS1000

Result:

  • repeated USB disconnects

  • error -71

  • error -110

  • USB port power cycles

  • XS1000 disappears from lsblk

  • I/O errors

  • filesystem corruption after interrupted writes

Official Raspberry Pi USB-C PSU

Official Raspberry Pi USB-C PSU
        |
        v
Raspberry Pi 5
        |
        +--- Penta SATA HAT
        |      + 4 × Samsung 870 QVO 2 TB
        |
        +--- USB 3 → Kingston XS1000

Result:

  • stable USB 3 SuperSpeed operation

  • UAS works normally

  • successful filesystem checks

  • ~254 GB continuous raw read at ~371 MB/s

  • ~546 GB real-world rsync

  • almost one hour of sustained workload

  • no USB errors

  • throttled=0x0

My conclusion so far

In my particular configuration, the testing strongly suggests that the problem is related to the power-delivery path from the Penta SATA HAT to the Raspberry Pi 5 and/or its USB subsystem when the system is powered through the HAT DC input.

I do not think the issue is simply insufficient total PSU wattage.

The Mean Well GST60A12-P1J is rated at:

12 V / 5 A / 60 W

and I specifically selected it to provide significant power headroom.

Also, the Raspberry Pi never reports an undervoltage condition:

throttled=0x0

even when the USB failures occur.

Therefore, my suspicion is not necessarily that the external PSU itself is too weak, but that there may be a limitation or instability somewhere in the 12 V → 5 V conversion / power distribution path through the Penta SATA HAT to the Raspberry Pi and consequently to its USB ports.

I want to emphasize that I have not measured the 5 V USB rail directly with an oscilloscope or multimeter under transient load, so I cannot prove that the USB voltage itself is dropping.

However, the A/B testing appears quite consistent:

  • same Raspberry Pi

  • same Penta SATA HAT

  • same four SATA SSDs

  • same Kingston XS1000

  • same USB cable

  • same operating system

  • same USB port

  • UAS tested both enabled and disabled

The major variable that changes the behaviour is how the Raspberry Pi is powered.

Questions

Has anyone else experienced similar USB 3 instability when powering a Raspberry Pi 5 through the Penta SATA HAT DC input?

Is there a known limitation regarding how much current is available to the Raspberry Pi 5 USB ports when the Pi is powered through the Penta SATA HAT?

Could the Penta SATA HAT’s 12 V → 5 V power conversion or power distribution cause short voltage drops or transient instability on the Raspberry Pi USB power rail without triggering the normal Raspberry Pi undervoltage/throttling flags?

Is there any recommended way to measure or verify the 5 V rail supplied from the Penta SATA HAT to the Raspberry Pi under USB SSD load?

Finally, is powering the Raspberry Pi 5 directly through the official USB-C PSU while keeping the Penta SATA HAT and four SATA SSDs installed considered a supported long-term configuration?

I would be very interested to hear from Radxa or anyone running a similar Raspberry Pi 5 + Penta SATA HAT + multiple SSD setup.

Thanks.

2

Where did you buy this?

Also post config.txt contents and output of ‘rpi-eeprom-update‘; That should show whether 5A is used or not.

3

Its 16GB. My bad.

Here are the outputs.

/boot/firmware/config.txt:

# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Additional overlays and parameters are documented
# /boot/firmware/overlays/README

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

# Run as fast as firmware / board allows
arm_boost=1

[cm4]
otg_mode=1

[cm5]
dtoverlay=dwc2,dr_mode=host

[all]
dtparam=pciex1
dtparam=pciex1_gen=3
dtoverlay=disable-wifi

sudo rpi-eeprom-update:

BOOTLOADER: up to date
   CURRENT: Tue May 26 15:01:25 UTC 2026 (1779807685)
    LATEST: Tue May 26 15:01:25 UTC 2026 (1779807685)
   RELEASE: default (/usr/lib/firmware/raspberrypi/bootloader-2712/default)
            Use raspi-config to change the release.

I haven’t manually changed or added any 5A-related settings, so this is how it was configured during the tests.

4

OK, then do that as this seems the well known issue with RPI5 defaulting to only 3A. See RPi docs how to override so 5A@5V is used. Can be in config.txt (or EEPROM config with some edit command AFAIK).

5

For now, I solved the issue by mounting the XS1000 over NFS from another Raspberry Pi, which is running Pi-hole and is powered by the original Raspberry Pi power supply. I actually think this is a better setup for my use case anyway.

But if I need to use the USB ports on the PiNAS in the future, I’ll definitely keep this 5A setting in mind.

Thanks for the info!