utmapp / utmapp/UTM

USB passthrough fails for OWC Mercury Elite Pro Quad (Invalid ep0 maxpacket: 9) on ARM Linux guest

Open
#7,774 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Swift
Stars
35.5k
Forks
1.8k
Avg merge
5d 5h
Merged PRs (30d)
7

Description

## Summary

USB passthrough fails for the OWC Mercury Elite Pro Quad in multiple guest operating systems (ARM Linux and Windows 11 ARM). The enclosure works correctly on the macOS host and on physical Linux hardware, Physical Windows hardware, suggesting the issue occurs during USB passthrough before the guest OS enumerates the device.

The Linux guest receives a USB hotplug event, but enumeration fails immediately with:

```text
Invalid ep0 maxpacket: 9
unable to enumerate USB device
```

## Environment

* Host: Apple Silicon Mac
* Host OS: macOS 15.7.7
* UTM versions tested:

* 4.7.4
* 4.7.5
* 5.0.3
* Guest OS: ARM-based Linux (Ubuntu)

* USB device:
* OWC Mercury Elite Pro Quad
* Vendor ID: 0x1e91
* Product ID: 0xa4a7
* Firmware / Version shown by macOS: 7.93

* USB controller modes tested in UTM:
* USB 3 / xHCI
* USB 2 / EHCI
* UHCI also appears in guest logs

## Host-side device information

macOS detects the enclosure correctly:

```text
Mercury Elite Pro Quad:

Product ID: 0xa4a7
Vendor ID: 0x1e91
Version: 7.93
Serial Number: 000000001
Speed: Up to 10 Gb/s
Manufacturer: OWC
```

macOS also sees the individual bays:

```text
Mercury Elite Pro Quad A
Mercury Elite Pro Quad B
Mercury Elite Pro Quad C
Mercury Elite Pro Quad D
```

Disks inside the enclosure are mounted and usable on the macOS host.

## Guest-side behavior

When connecting the OWC enclosure through UTM USB passthrough, the ARM Linux guest reports:

### xHCI / USB 3 mode

```text
usb 5-2: Invalid ep0 maxpacket: 9
usb 5-2: new high-speed USB device number 7 using xhci_hcd
usb 5-2: Invalid ep0 maxpacket: 9
usb usb5-port2: attempt power cycle
usb 5-2: new high-speed USB device number 8 using xhci_hcd
usb 5-2: Invalid ep0 maxpacket: 9
usb 5-2: new high-speed USB device number 9 using xhci_hcd
usb 5-2: Invalid ep0 maxpacket: 9
usb usb5-port2: unable to enumerate USB device
```

### USB 2 mode

```text
usb 3-2: new high-speed USB device number 2 using ehci-pci
usb 3-2: Invalid ep0 maxpacket: 9
usb 3-2: new high-speed USB device number 3 using ehci-pci
usb 3-2: Invalid ep0 maxpacket: 9
usb usb3-port2: attempt power cycle
usb 3-2: new high-speed USB device number 4 using ehci-pci
usb 3-2: Invalid ep0 maxpacket: 9
usb 3-2: new high-speed USB device number 5 using ehci-pci
usb 3-2: Invalid ep0 maxpacket: 9
usb usb3-port2: unable to enumerate USB device
usb 6-2: new full-speed USB device number 2 using uhci_hcd
usb 6-2: Invalid ep0 maxpacket: 9
usb 6-2: new full-speed USB device number 3 using uhci_hcd
usb 6-2: Invalid ep0 maxpacket: 9
usb usb6-port2: attempt power cycle
usb 6-2: new full-speed USB device number 4 using uhci_hcd
usb 6-2: Invalid ep0 maxpacket: 9
usb 6-2: new full-speed USB device number 5 using uhci_hcd
usb 6-2: Invalid ep0 maxpacket: 9
usb usb6-port2: unable to enumerate USB device
```

### Additional observations

The issue is not guest OS specific.

The same USB passthrough failure occurs with:

- ARM Linux guest
- Windows 11 ARM guest

Other USB storage enclosures work correctly in the same VMs.

This suggests the failure occurs during USB enumeration inside the virtualization layer, before the guest operating system can load any storage driver.

## Expected behavior

The OWC enclosure should enumerate successfully inside the Linux guest and expose the disks as block devices, similar to other USB storage enclosures.

## Actual behavior

The device fails during USB enumeration. No `/dev/sdX` block device appears in the Linux guest.

## Troubleshooting already performed

* Tested UTM 4.7.4 - 5.0.3: same result.
* Tested USB 3 / xHCI and USB 2 / EHCI modes: same result.
* Other USB HDD enclosures pass through successfully to the same Linux VM.
* USB keyboard passthrough also works.
* The same OWC enclosure works normally on the macOS host.
* The same OWC enclosure works on physical i686 Linux / antiX.
* Therefore this does not appear to be a general OWC hardware issue, Linux USB driver issue, or disk/filesystem issue.

## Suspected cause

This looks like a USB descriptor / enumeration issue in UTM/QEMU passthrough for this specific OWC device.

The repeated `Invalid ep0 maxpacket: 9` suggests that the guest receives a descriptor value it considers invalid during early USB enumeration.

## Request

Could you please advise whether this is a known limitation of UTM/QEMU USB passthrough, or whether there is a recommended workaround?

In particular, is there a way in UTM to attach the host block device directly, e.g. `/dev/diskX`, as a raw disk to the guest instead of using USB passthrough?

## Reference

[owc-usb-profile.txt](https://github.com/user-attachments/files/29795778/owc-usb-profile.txt)

Reference for OWC Disk array appearing on the USB Device menu

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the attached owc-usb-profile.txt and reproducing the failure with the listed xHCI, EHCI, and UHCI controller modes. Compare the passthrough descriptor and enumeration behavior across those modes; the work is done when the enclosure enumerates and exposes block devices, or when a confirmed limitation and workaround are documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux, macos
Domain
desktop-dev, operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.