Pericom PI7C9X2G608 (12d8:2608) missing from ACS quirk — breaks Renesas uPD720202 USB3 cards when IOMMU is on

Pericom PI7C9X2G608 (12d8:2608) missing from ACS quirk — breaks Renesas uPD720202 USB3 cards when IOMMU is on

[Max Stevens]

Hello,

I'd like to report that the Pericom PI7C9X2G ACS erratum handled by
pci_fixup_pericom_acs_store_forward() also affects the 6-port variant
of the switch, PI7C9X2G608GP (12d8:2608), which is not covered by the
existing quirk (2404/2304/2303, and b404 recently proposed by Nicolas
Cavallari). On this switch the erratum is severe enough to make an
entire class of consumer USB 3.0 cards completely non-functional on
any system with the IOMMU enabled.

Hardware

StarTech PEXUSB3S44V-style 4-port USB 3.0 card ("one dedicated channel
per port", widely sold ~2016 for Oculus Rift sensors). Topology:

00:1d.0 Intel Z690 PCH root port 07:00.0 Pericom PI7C9X2G608GP switch
upstream [12d8:2608] (x4 gen2) 08:01.0 - 08:04.0 switch downstream
ports [12d8:2608] 09:00.0 - 0c:00.0 4x Renesas uPD720202 xHCI
[1912:0015] (rev 02)

System: Alder Lake / Z690, kernel 6.18.43 (Void Linux), VT-d enabled,
booted with iommu=pt (default domain: passthrough). Firmware for the
uPD720202s is the correct v2.0.2.6 image (sha256 177560c2...) and
uploads successfully on every probe.

Symptom

With the IOMMU on, the kernel enables ACS on the switch's downstream
ports (ACSCtl: SrcValid+ ReqRedir+ CmpltRedir+ UpstreamFwd+). The four
xHCI controllers then probe cleanly, register their buses, upload
firmware, and report port connect status normally — but any device
plugged into any port fails enumeration with:

xhci-pci-renesas 0000:09:00.0: Error while assigning device slot ID:
Command Aborted xhci-pci-renesas 0000:09:00.0: Max number of devices
this xHCI host supports is 32. usb usb3-port1: couldn't allocate
usb_device

All four controllers fail identically. xhci debugfs portsc shows the
port stuck at "Connected ... Link:Polling" while the Enable Slot
command times out. Posted writes from the endpoints still work (MSI-X
interrupts for port change events are delivered), but the controllers
appear unable to complete DMA reads (command ring fetch) — consistent
with the known PI7C9X2G packet-buffering erratum when P2P Request
Redirect is enabled. No AER/DMAR errors are logged for the failed
requests.

Confirmation

Clearing ACS control on the downstream ports at runtime and rebinding
the drivers immediately and fully fixes the card:

for p in 08:01.0 08:02.0 08:03.0 08:04.0; do setpci -s $p
ECAP_ACS+6.w=0x0000 done

+ unbind/rebind xhci-pci-renesas for each 0x:00.0

After this, all four controllers enumerate devices normally and the
card works (tested with HID devices, hubs, and mass storage).
"pci=disable_acs_redir=pci:12d8:2608" is my current persistent
workaround.

Given that the 2G404/2G304/2G303 (and b404) already have the
store-and-forward fixup, could 12d8:2608 be added as well? I'm happy
to test a patch, and can provide full lspci -vv dumps, dmesg, or
register reads from the switch on request. I can't say whether the
store-and-forward vendor register of the smaller switches exists at
the same offset on the 2G608, but I'm glad to poke it under
instruction.

These cards were sold in large numbers and every Linux report I can
find about them (Arch, FreeBSD, Proxmox, Unraid forums) describes
unexplained failures or dropped input events with no root cause
identified — this quirk gap likely explains most of them.

Thanks, Maximo Paulino

Re: Pericom PI7C9X2G608 (12d8:2608) missing from ACS quirk — breaks Renesas uPD720202 USB3 cards when IOMMU is on

[Bjorn Helgaas]

On Mon, Aug 10, 2026 at 08:00:59PM -0500, Max Stevens wrote:
> Hello,
> 
> I'd like to report that the Pericom PI7C9X2G ACS erratum handled by
> pci_fixup_pericom_acs_store_forward() also affects the 6-port variant
> of the switch, PI7C9X2G608GP (12d8:2608), which is not covered by the
> existing quirk (2404/2304/2303, and b404 recently proposed by Nicolas
> Cavallari). On this switch the erratum is severe enough to make an
> entire class of consumer USB 3.0 cards completely non-functional on
> any system with the IOMMU enabled.
> 
> Hardware
> 
> StarTech PEXUSB3S44V-style 4-port USB 3.0 card ("one dedicated channel
> per port", widely sold ~2016 for Oculus Rift sensors). Topology:
> 
> 00:1d.0 Intel Z690 PCH root port 07:00.0 Pericom PI7C9X2G608GP switch
> upstream [12d8:2608] (x4 gen2) 08:01.0 - 08:04.0 switch downstream
> ports [12d8:2608] 09:00.0 - 0c:00.0 4x Renesas uPD720202 xHCI
> [1912:0015] (rev 02)
> 
> System: Alder Lake / Z690, kernel 6.18.43 (Void Linux), VT-d enabled,
> booted with iommu=pt (default domain: passthrough). Firmware for the
> uPD720202s is the correct v2.0.2.6 image (sha256 177560c2...) and
> uploads successfully on every probe.
> 
> Symptom
> 
> With the IOMMU on, the kernel enables ACS on the switch's downstream
> ports (ACSCtl: SrcValid+ ReqRedir+ CmpltRedir+ UpstreamFwd+). The four
> xHCI controllers then probe cleanly, register their buses, upload
> firmware, and report port connect status normally — but any device
> plugged into any port fails enumeration with:
> 
> xhci-pci-renesas 0000:09:00.0: Error while assigning device slot ID:
> Command Aborted xhci-pci-renesas 0000:09:00.0: Max number of devices
> this xHCI host supports is 32. usb usb3-port1: couldn't allocate
> usb_device
> 
> All four controllers fail identically. xhci debugfs portsc shows the
> port stuck at "Connected ... Link:Polling" while the Enable Slot
> command times out. Posted writes from the endpoints still work (MSI-X
> interrupts for port change events are delivered), but the controllers
> appear unable to complete DMA reads (command ring fetch) — consistent
> with the known PI7C9X2G packet-buffering erratum when P2P Request
> Redirect is enabled. No AER/DMAR errors are logged for the failed
> requests.
> 
> Confirmation
> 
> Clearing ACS control on the downstream ports at runtime and rebinding
> the drivers immediately and fully fixes the card:
> 
> for p in 08:01.0 08:02.0 08:03.0 08:04.0; do setpci -s $p
> ECAP_ACS+6.w=0x0000 done
> 
> + unbind/rebind xhci-pci-renesas for each 0x:00.0
> 
> After this, all four controllers enumerate devices normally and the
> card works (tested with HID devices, hubs, and mass storage).
> "pci=disable_acs_redir=pci:12d8:2608" is my current persistent
> workaround.
> 
> Given that the 2G404/2G304/2G303 (and b404) already have the
> store-and-forward fixup, could 12d8:2608 be added as well? I'm happy
> to test a patch, and can provide full lspci -vv dumps, dmesg, or
> register reads from the switch on request. I can't say whether the
> store-and-forward vendor register of the smaller switches exists at
> the same offset on the 2G608, but I'm glad to poke it under
> instruction.
> 
> These cards were sold in large numbers and every Linux report I can
> find about them (Arch, FreeBSD, Proxmox, Unraid forums) describes
> unexplained failures or dropped input events with no root cause
> identified — this quirk gap likely explains most of them.

Can you test the patch below?


diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f7846f..27f7d56c9ac3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6263,6 +6263,10 @@ DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_PERICOM, 0xb404,
 			 pci_fixup_pericom_acs_store_forward);
 DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_PERICOM, 0xb404,
 			 pci_fixup_pericom_acs_store_forward);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_PERICOM, 0x2608,
+			 pci_fixup_pericom_acs_store_forward);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_PERICOM, 0x2608,
+			 pci_fixup_pericom_acs_store_forward);
 
 static void nvidia_ion_ahci_fixup(struct pci_dev *pdev)
 {