[Help] Terrmaster D4-320 crashing under heavy usage (Ubuntu)

[HollowProphet]

Info: Ubuntu 26.04 LTS, Terramaster D4-320 connected via the supplied USB C cable, Beelink EQi12, 20 TB HDDs formatted ext4

I've just started running into an issue where my DAS crashes under heavy usage. Suddenly all of my services go offline so I know something happened. It's happened twice in the past two days. I reboot the computer and re-plug the DAS back in, and all is good.

I've been using Claude Code to narrow this down and here is a summary of what it thinks it is:
The DAS enclosure's USB bridge chip is intermittently starved for power on its host port during sustained heavy read/write across the 4 drives, causing brief transfer errors that almost always self-recover — but on rare occasions cascade into a full crash, and the actual root cause matches a documented issue on a sibling TerraMaster product line (D5-300C).

I'm not sold on that logic as this has never been a problem previously. Nothing in my setup has changed. At this point I have done extensive testing and am coming up empty.

Any advice?

Edit: some more info

Symptom:
Under sustained heavy write (~30GB+ continuous, ~150-200MB/s) to any single drive, dmesg/journalctl -k reliably shows repeated:

Code: Select all

xhci_hcd 0000:00:14.0: Transfer error for slot X ep 3 on endpoint
xhci_hcd 0000:00:14.0: Soft-reset ep 3, slot X
xhci_hcd 0000:00:14.0: // Ding dong!
xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1

Occurring multiple times per minute per drive under load, on every one of the 4 bays, not isolated to one bay/cable/drive. Almost always self-recovers via soft-reset with no data loss. On rare occasions (twice in ~4 months of real use) a reset failed to recover, escalating to EPROTO, DID_RESET, EXT4-fs ... shut down requested, and the drive dropping off the USB bus entirely, requiring a full power cycle of the enclosure to recover.

What's been tested/ruled out:

• Confirmed via controlled single-drive sustained-write tests: baseline error rate ~9-27 soft-resets per ~3-minute/30GB write, consistent across all 4 bays (not one bad drive/cable).
• Disabled USB3 Link Power Management (usbcore.quirks=174ck,0bdak, USB_QUIRK_NO_LPM) — reduced error rate by ~76%.
• Disabled PCIe runtime power management on the host's xHCI controller (/sys/bus/pci/devices/0000:00:14.0/power/control=on) — reduced further to ~86% total reduction from baseline.
• Confirmed via hdparm -I that "Device-initiated interface power management" is active at the SATA level between the bridge and each drive, but APM_level reports "not supported" through the bridge — no host-side ATA passthrough available to control it.
• Zero errors reproduced under concurrent multi-drive load (2-drive, 4-drive, and mixed read+write) — the fault appears specifically tied to a single sustained stream, not concurrency.
• USB autosuspend already correctly disabled (power/control=on) via existing udev rule for the hub and all 4 bays.

Suspected root cause: insufficient/marginal power delivery on the host USB-C port under sustained max-throughput load — even with the enclosure's own PSU powering the drives, the bridge chip's own logic still draws from USB VBUS, and a voltage sag under sustained load could explain intermittent transfer errors that clear once the reset briefly reduces load. This matches reports from other TerraMaster D5-300C owners with an identical symptom, whose fix was routing through a powered USB hub or a higher-power USB-A 3.1 port.

[TMroy]

TL;DR: not a power problem — it's a USB 3.2 Gen2 LPM (U1/U2) transition issue between the Intel xHCI controller and the enclosure's bridge chips, aggravated by a specific kernel version.

Your own tests already rule out "insufficient host port power":

Concurrent 4-drive full load (the highest current draw) = zero errors; single-drive sustained stream = reliably errors. If the port were undersupplied, it'd be the other way around.
Disabling USB3 LPM cut errors ~76%, plus PCIe runtime PM → ~86% total. That's a hit on link power-state transitions, not power capacity.
The "single stream fails, concurrent is clean" pattern is the classic LPM fingerprint: one stream leaves periodic micro-idle gaps → repeated U1/U2 entry/exit attempts → failed transition = Transfer error + Soft-reset. Concurrent load keeps the link busy, no idle windows, no transitions, no errors.

This also matches a documented case on Ubuntu Launchpad (Bug #2153431): same Beelink EQi12 mini PC + same D4-320 (ASMedia 174c:235c behind a Realtek hub), where a kernel update (6.8.0-111 → 6.8.0-117) caused continuous xHCI reset loops, and reverting the kernel gave zero errors even under sustained heavy write. So "nothing changed" is misleading — the kernel updates silently in the background on Linux.

Do this, in order:

uname -r + correlate your crash timestamps with kernel updates (/var/log/apt). Kernel is the prime suspect.
Pin the previously-working kernel (apt-mark hold) and test. If stable, that confirms it.
Keep LPM off + xHCI PCIe runtime PM off (your best measured fix, ~86%). Double-check the quirk is actually applied via lsusb -v — 174ck,0bdak isn't a valid usbcore.quirks string, so it may have been silently ignored.
As a control, test over a Gen1 link (USB-A cable/port). Errors gone = Gen2+LPM root cause confirmed. Skip the powered-hub advice from D5-300C threads — that's Gen1 and mixed evidence; treat it as a diagnostic, not a fix.