Pi 4 hard hang/root SSD I/O failure with ASMedia 174c:1156 UAS bridge on 6.12.96+rpt-rpi-v8

Start with the preserved remote-syslog kernel sequence, the linked raspinfo output, and the USB/UAS configuration for bridge 174c:1156. Compare the evidence with related issues #5060 and #6755, then follow any diagnostics requested by maintainers; done would require a confirmed cause or a reproducible, validated mitigation.

Describe the bug

Raspberry Pi 4 experienced a hard hang associated with failure of its USB-attached root SSD storage path. The system had been operating normally when remote syslog captured SCSI/storage I/O errors, write failures and ext4 journal-abort behavior. Local logging then ceased and the Pi became completely inaccessible by network, HDMI console and locally attached keyboard. Power remained present, but recovery required a forced power cycle.

After the forced power cycle the Pi booted normally from the same SSD and returned to service.

The root SSD is a Western Digital WDC WDS500G2B0B-00YS70 500 GB M.2 SATA SSD connected through an ASMedia USB-to-SATA bridge, VID:PID 174c:1156. The bridge was operating using UAS over USB 3/SuperSpeed.

Pre-failure health telemetry showed approximately 7 GB memory available, no significant memory pressure, normal temperature and no throttling indication. Post-recovery SMART examination has not identified SSD media failure.

I am not asserting that UAS or kernel 6.12 is the root cause. The incident appears potentially related to #5060 and possibly #6755, but I am not claiming this report is a duplicate.

I have preserved detailed local and remote forensic logs and can provide additional diagnostics requested by maintainers. Before changing the current UAS configuration, I would also be happy to collect any specific diagnostics maintainers want from the affected configuration.

Steps to reproduce the behaviour

The failure is intermittent and I do not currently have a deterministic method to reproduce it on demand.

Raspberry Pi 4 Model B Rev 1.4 is booted normally from a 500 GB SATA SSD connected through an ASMedia USB-to-SATA bridge (USB ID 174c:1156).
The bridge enumerates over the Pi 4 USB 3.0 xHCI controller at SuperSpeed and uses the Linux uas driver. The SSD appears as /dev/sda; /dev/sda2 is the ext4 root filesystem.
System is running Raspberry Pi/Debian Bookworm with kernel 6.12.96+rpt-rpi-v8.
Leave the system operating normally under ordinary server workload. No deliberate storage stress test is required for the failures observed so far.
Intermittently, the root-storage path fails. Kernel evidence from the failure shows SCSI/write I/O errors against /dev/sda, followed by buffer I/O errors against /dev/sda2 and loss/abort of the ext4 journal.
During the most recent occurrence, the Pi became completely unresponsive: network connectivity and Pi-hole stopped, SSH/remote terminal access failed, HDMI produced no usable output, and a locally attached keyboard produced no response.
A forced power cycle was required. After the power cycle, the same SSD and USB bridge booted successfully again.

Reproducibility: Intermittent. I have not intentionally attempted to force another occurrence because /dev/sda2 is the production root filesystem and repeated failures may risk filesystem corruption.

As a diagnostic/workaround, I am prepared to test disabling UAS for USB ID 174c:1156 and forcing the bridge to use usb-storage instead, but I have not made that change yet so the affected configuration remains intact for any additional diagnostics requested by the maintainers.

Device (s)

Raspberry Pi 4 Mod. B

System

raspinfo:
https://pastebin.com/WGZJQUre

Hardware:
Raspberry Pi 4 Model B Rev 1.4

OS:
Debian GNU/Linux 12 (bookworm)
Raspberry Pi reference image 2024-07-04

Kernel:
Linux raspberrypi1 6.12.96+rpt-rpi-v8
#1 SMP PREEMPT Debian 1:6.12.96-1+rpt1 (2026-07-24)
aarch64

VideoCore firmware:
May 21 2026 11:20:25
version 288930ab4712b99596f32732664aaaeb881ef1e0

Root storage:
Western Digital WDC WDS500G2B0B-00YS70 500 GB SATA SSD
connected through an Argon/ASMedia USB-to-SATA bridge.

USB VID:PID: 174c:1156
USB connection: USB 3.0 SuperSpeed (5000M)
Storage driver: uas
Block device: /dev/sda
Root filesystem: /dev/sda2, ext4

The complete raspinfo output is provided at the URL above.

Logs

The critical failure was preserved by remote syslog on a Synology NAS. This is important because the affected device, /dev/sda2, is the running root filesystem and local logging became unavailable during the failure.

Immediately before the failure the system was still operating normally:

08/22/2026 11:14:07 AM systemd:
Starting nut-status-data.service - Build NUT Shutdown Status Dashboard Data...

08/22/2026 11:14:09 AM systemd:
nut-status-data.service: Deactivated successfully.

08/22/2026 11:14:09 AM systemd:
Finished nut-status-data.service - Build NUT Shutdown Status Dashboard Data.

08/22/2026 11:14:09 AM systemd:
nut-status-data.service: Consumed 1.299s CPU time.

Two seconds later the remote syslog captured the following kernel sequence:

08/22/2026 11:14:11 AM kernel:
[1307946.766254] sd 0:0:0:0: [sda] tag#3 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=0s

08/22/2026 11:14:11 AM kernel:
[1307946.766273] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x2a 2a 00 1d 1c c7 70 00 01 78 00

08/22/2026 11:14:11 AM kernel:
[1307946.766278] I/O error, dev sda, sector 488425328 op 0x1:(WRITE) flags 0x9800 phys_seg 47 prio class 2

08/22/2026 11:14:11 AM kernel:
[1307946.766286] Buffer I/O error on dev sda2, logical block 60921070, lost sync page write

08/22/2026 11:14:11 AM kernel:
[1307946.766339] Aborting journal on device sda2-8.

08/22/2026 11:14:11 AM kernel:
[1307946.766364] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=0s

No subsequent RaspberryPi1 messages were received by the remote syslog following this sequence.

The Pi became completely unresponsive and required a forced power cycle.

After the forced power cycle, the same SSD and USB bridge successfully enumerated and the system booted again. The subsequent boot reported the previous persistent system journal as corrupted or uncleanly shut down.

Current root-storage configuration:

Raspberry Pi 4 Model B Rev 1.4
Kernel: 6.12.96+rpt-rpi-v8

USB bridge:
174c:1156 ASMedia Technology Inc. / Argon Forty
USB 3 SuperSpeed (5000M)
Driver: uas

SSD:
/dev/sda
Western Digital WDC WDS500G2B0B-00YS70
500 GB SATA SSD

Root filesystem:
/dev/sda2
ext4
mounted as /

Post-recovery SMART examination:
SMART Extended Comprehensive Error Log: No Errors Logged
UDMA_CRC_Error_Count: 0
SATA "Command failed due to ICRC error": 0

Full current raspinfo:
https://pastebin.com/WGZJQUre

The original Synology remote-syslog CSV containing these records has been preserved and can be supplied if needed.

Additional context

The affected SSD contains the Raspberry Pi root filesystem. Consequently, once the storage path failed, local persistent logging could no longer be assumed reliable. A Synology system on the LAN receives Pi1 syslog remotely and preserved kernel/storage messages surrounding the failure after local logging stopped.

The Pi remained powered but was completely unresponsive. Network services were unavailable, the UniFi network controller showed the Pi offline, HDMI produced no usable display output, and a locally attached keyboard produced no response. A forced power cycle restored normal operation.

The SSD currently reports SMART health as PASSED. Investigation after recovery found no reallocated sectors, no reported uncorrectable media errors and no UDMA CRC errors. Pre-failure telemetry did not indicate thermal throttling, undervoltage or memory exhaustion.

The ASMedia bridge is USB VID:PID 174c:1156 and is currently using the Linux uas driver at SuperSpeed.

Potentially related reports:

#5060 — similar Raspberry Pi 4 / USB SSD / ASMedia / UAS/xHCI storage-disconnect behavior.
#6755 — USB3 storage disappearance reported with a Raspberry Pi 6.12 kernel and ASMedia bridge; hardware/circumstances differ.

These are provided for comparison only; I am not asserting that this issue is a duplicate.

I have considered a controlled diagnostic test using usb-storage.quirks=174c:1156:u to force only this bridge from UAS to usb-storage. I have intentionally not performed that test yet, so the system remains in the affected UAS configuration in case maintainers want additional diagnostic information collected first.