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
