[Help] D2-320 drops off the bus under heavy load (USB over-current) then ZFS pool suspends

[Pezmc]

Hoping someone here has hit this and figured it out, because I'm a bit stuck.

I've got a D2-320 (single 3TB Seagate in it for now) plugged into an Intel NUC running Proxmox/Debian. It's been rock solid for normal use - streaming, copying files around, all fine. But the other night a ZFS scrub kicked off (heavy sustained reads across the whole disk for hours) and partway through, the enclosure just dropped off the USB bus. The drive vanished, my pool went into a suspended/faulted state, and nothing could read it until I physically re-seated the enclosure and power-cycled it.

The kernel log is pretty clear that it's a power/over-current thing on the enclosure's internal hub, not the disk:

```
usb 2-2-port2: over-current condition
usb 2-2-port3: over-current condition
sd 2:0:0:0: [sdc] FAILED Result: hostbyte=DID_ERROR
usb 2-2-port4: over-current condition
usb 2-2.4: USB disconnect, device number 3
usb 2-2-port4: attempt power cycle
usb 2-2-port4: unable to enumerate USB device
```

Worth noting ports 2 and 3 trip a few seconds before the drive's port (4) even errors, so it looks like the whole internal hub rail browns out, not one drive pulling too much. The drive itself is fine (SMART is clean, basically new), and it's DID_ERROR/DID_NO_CONNECT, a connection loss, not a disk read error.

Things I've already done:
- Using the original power adapter, fully seated. No splitters, no third-party brick.
- The bridge (ASMedia ASM1352R, 174c:1356) is already running on usb-storage, not UAS, Linux blocklists UAS for this chip automatically, so the usual "switch off UAS" fix doesn't apply, it's already off.
- Disabled USB autosuspend on the hub + bridge, and disabled drive spindown/APM so it never sleeps.
- Tried a different USB port and cable.

So my questions:
1. Is this a known issue with the 320-series under sustained load? I've seen a few scattered "D2/D4-320 disconnecting on Linux" threads but no clear root cause.
2. Does the internal over-current protection trip too aggressively under heavy continuous I/O, or does this point to a weak/failing PSU or internal hub board?
3. Is there any firmware update for the bridge/hub that addresses stability under load?
4. If the PSU is the likely culprit, what's the exact spec (V/A) so I can source a spare and rule it out, or should I be looking at an RMA?

It only happens under prolonged full-throughput load, so it's intermittent and hard to "prove," but it took my pool offline so I'd really like to nail it down. Any pointers appreciated.

[Phil]

Hoping someone here has hit this and figured it out, because I'm a bit stuck.

I've got a D2-320 (single 3TB Seagate in it for now) plugged into an Intel NUC running Proxmox/Debian. It's been rock solid for normal use - streaming, copying files around, all fine. But the other night a ZFS scrub kicked off (heavy sustained reads across the whole disk for hours) and partway through, the enclosure just dropped off the USB bus. The drive vanished, my pool went into a suspended/faulted state, and nothing could read it until I physically re-seated the enclosure and power-cycled it.

The kernel log is pretty clear that it's a power/over-current thing on the enclosure's internal hub, not the disk:

```
usb 2-2-port2: over-current condition
usb 2-2-port3: over-current condition
sd 2:0:0:0: [sdc] FAILED Result: hostbyte=DID_ERROR
usb 2-2-port4: over-current condition
usb 2-2.4: USB disconnect, device number 3
usb 2-2-port4: attempt power cycle
usb 2-2-port4: unable to enumerate USB device
```

Worth noting ports 2 and 3 trip a few seconds before the drive's port (4) even errors, so it looks like the whole internal hub rail browns out, not one drive pulling too much. The drive itself is fine (SMART is clean, basically new), and it's DID_ERROR/DID_NO_CONNECT, a connection loss, not a disk read error.

Things I've already done:
- Using the original power adapter, fully seated. No splitters, no third-party brick.
- The bridge (ASMedia ASM1352R, 174c:1356) is already running on usb-storage, not UAS, Linux blocklists UAS for this chip automatically, so the usual "switch off UAS" fix doesn't apply, it's already off.
- Disabled USB autosuspend on the hub + bridge, and disabled drive spindown/APM so it never sleeps.
- Tried a different USB port and cable.

So my questions:
1. Is this a known issue with the 320-series under sustained load? I've seen a few scattered "D2/D4-320 disconnecting on Linux" threads but no clear root cause.
2. Does the internal over-current protection trip too aggressively under heavy continuous I/O, or does this point to a weak/failing PSU or internal hub board?
3. Is there any firmware update for the bridge/hub that addresses stability under load?
4. If the PSU is the likely culprit, what's the exact spec (V/A) so I can source a spare and rule it out, or should I be looking at an RMA?

It only happens under prolonged full-throughput load, so it's intermittent and hard to "prove," but it took my pool offline so I'd really like to nail it down. Any pointers appreciated.

Thank you for your detailed feedback. The D2-320 device does not support the ZFS file system in single-disk mode. This model has an integrated RAID controller, which cannot split the hard drives into independent logical drives, and the system cannot distinguish the device IDs of HDD1 and HDD2. If you need to use the ZFS file system, we recommend that you switch to RAID 0 or RAID 1 mode, where the RAID controller will combine the two hard drives into a single logical drive.