I wanted to share my experience with a persistent USB storage disconnection issue on my EQi12, and see if anyone has found a solution.

Setup:

Beelink EQi12 i5-1235U, 32GB DDR4
BIOS: EQI12D405 (latest)
OS: Debian Linux, Kernel 6.12.74
External Storage: TerraMaster D6-360 6-bay DAS (brand new) with 5 x HDDs
Connected via USB-C using a Cable Matters 40Gbps USB4 cable

The Problem:
The D6-360 connects on Bus 004 (the Thunderbolt 4 controller) and spontaneously drops off the USB bus, taking all 5 drives offline simultaneously. This happens under both load and completely idle conditions. The hub reconnects within a few seconds but the filesystems don’t remount automatically.

Kernel log at time of disconnect:

usb 4-2: USB disconnect, device number 3
usb 4-2.1: USB disconnect, device number 4
sd [sda] FAILED Result: hostbyte=DID_ERROR
I/O error, dev sda, sector 64267232
EXT4-fs (sda1): shut down requested
Aborting journal on device sda1-8
usb 4-2: new SuperSpeed Plus Gen 2x1 USB device reconnected

Troubleshooting I’ve tried:

Three different cables (stock cable, Anker USB-C, Cable Matters 40Gbps USB4)
Disabled UAS, forced usb-storage mode: options usb-storage quirks=174c:235c:u
Disabled USB autosuspend via udev rules
Moved from USB-C to USB-A ports - same issue
Reduced I/O load significantly

Key finding:
The exact same D6-360 unit ran on a Beelink Mini S13 N150 via USB-C to USB-A adapter for over a week with zero disconnections. The problem is specific to the EQi12’s Thunderbolt 4 controller on Linux.

I also found a previous thread (d/71-eq12-powered-usb-disk-issues) where EQ12 and SEi12 users reported identical symptoms - USB-A ports causing I/O errors with powered USB enclosures on Linux - with no resolution provided.

Current workarounds:

Auto-remount via udev rules when drives reconnect
usb-storage mode instead of UAS
Throttled background jobs to reduce USB load

These help but don’t solve the root cause. Has anyone found a permanent fix? Is there a BIOS setting I’m missing, or is a fix planned?

Happy to share full kernel logs if useful.

Thanks,
IdahoX1