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)
 {

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

[Max Stevens]

Hi Bjorn,

Thanks for the quick patch. I tested its effect on my PI7C9X2G608GP
(12d8:2608) by replicating what pci_fixup_pericom_acs_store_forward()
does, using setpci at runtime (I have not built a patched kernel —
happy to do that too if you want a test of the actual binary).

Findings on the 2G608:

The mode register exists at the same offset as on the smaller
switches: upstream port config 0x74. Value on my system before any
test: 0x0102 (store-forward bit clear).
With ACS on all four downstream ports set to what the kernel normally
enables here (ACSCtl = SrcValid+ ReqRedir+ CmpltRedir+ UpstreamFwd+),
and 0x74 bit 0 CLEAR, device enumeration on the downstream xHCI
controllers fails: [43069.603242] xhci-pci-renesas 0000:0c:00.0: Error
while assigning device slot ID: Command Aborted [43069.603270] usb
usb9-port1: couldn't allocate usb_device
Setting 0x74 to 0x0103 (bit 0, store-forward) with ACS unchanged, then
rebinding the xHCI drivers: the same device on the same port
enumerates immediately and works fully: [43071.971147] usb 9-1: new
full-speed USB device number 2 using xhci-pci-renesas [43072.132176]
usb 9-1: Product: Azeron Keypad [43072.218656] hid-generic
0003:16D0:113C.0017: input,hidraw12: USB HID v1.11 Keyboard [Azeron
LTD Azeron Keypad] on usb-0000:0c:00.0-1/input1
I toggled the bit back and forth across several driver rebinds. Every
"Command Aborted" failure I have logged (both today and across earlier
debugging) occurred with the bit clear; none with it set.

One honest nuance: with the bit clear the failure is not 100% — I saw
one enumeration attempt start successfully during a bit-clear window.
That intermittency is consistent with the load-dependent packet
buffering behaviour described in Nathan's original erratum writeup,
and with this card family's long history of "sometimes almost works"
reports on various forums.

So on this hardware the store-forward workaround behaves exactly as it
does on the already-quirked siblings, and the patch looks correct to
me.

Tested-by: Maximo Paulino Thinker.Healer@gmail.com

Thanks, Max

On Mon, Aug 10, 2026 at 8:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> 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)
>  {

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

[Bjorn Helgaas]

On Tue, Aug 11, 2026 at 05:57:33AM -0500, Max Stevens wrote:
> Hi Bjorn,
> 
> Thanks for the quick patch. I tested its effect on my PI7C9X2G608GP
> (12d8:2608) by replicating what pci_fixup_pericom_acs_store_forward()
> does, using setpci at runtime (I have not built a patched kernel —
> happy to do that too if you want a test of the actual binary).
> 
> Findings on the 2G608:
> 
> The mode register exists at the same offset as on the smaller
> switches: upstream port config 0x74. Value on my system before any
> test: 0x0102 (store-forward bit clear).
> With ACS on all four downstream ports set to what the kernel normally
> enables here (ACSCtl = SrcValid+ ReqRedir+ CmpltRedir+ UpstreamFwd+),
> and 0x74 bit 0 CLEAR, device enumeration on the downstream xHCI
> controllers fails: [43069.603242] xhci-pci-renesas 0000:0c:00.0: Error
> while assigning device slot ID: Command Aborted [43069.603270] usb
> usb9-port1: couldn't allocate usb_device
> Setting 0x74 to 0x0103 (bit 0, store-forward) with ACS unchanged, then
> rebinding the xHCI drivers: the same device on the same port
> enumerates immediately and works fully: [43071.971147] usb 9-1: new
> full-speed USB device number 2 using xhci-pci-renesas [43072.132176]
> usb 9-1: Product: Azeron Keypad [43072.218656] hid-generic
> 0003:16D0:113C.0017: input,hidraw12: USB HID v1.11 Keyboard [Azeron
> LTD Azeron Keypad] on usb-0000:0c:00.0-1/input1
> I toggled the bit back and forth across several driver rebinds. Every
> "Command Aborted" failure I have logged (both today and across earlier
> debugging) occurred with the bit clear; none with it set.
> 
> One honest nuance: with the bit clear the failure is not 100% — I saw
> one enumeration attempt start successfully during a bit-clear window.
> That intermittency is consistent with the load-dependent packet
> buffering behaviour described in Nathan's original erratum writeup,
> and with this card family's long history of "sometimes almost works"
> reports on various forums.

If it's an improvement, I think it's worth applying even if it's not a
100% fix.

> So on this hardware the store-forward workaround behaves exactly as it
> does on the already-quirked siblings, and the patch looks correct to
> me.
> 
> Tested-by: Maximo Paulino Thinker.Healer@gmail.com

Thanks for doing this.  I'll queue up the patch below for v7.3 without
your explicit tested-by because quirks run at different times than
setpci, and the timing/ordering is often important.


commit c56a7c02e664 ("PCI: Add ACS quirk for Pericom PI7C9X2G404 switches [12d8:2608]")
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Aug 10 20:20:26 2026 -0500

    PCI: Add ACS quirk for Pericom PI7C9X2G404 switches [12d8:2608]
    
    Max reported that PI7C9X2G608GP (12d8:2608), the 6-port variant, has the
    same erratum and makes an entire class of consumer USB 3.0 cards completely
    non-functional on any system with the IOMMU enabled.
    
    On a system with a StarTech PEXUSB3S44V-style 4-port USB 3.0 card With
    IOMMU on, ACS on the switch's downstream ports is enabled (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
    
    Apply the same workaround used for other related Pericom switches.
    
    Reported-by: Max Stevens <thinker.healer@gmail.com>
    Closes: https://lore.kernel.org/all/CADoo8uyrmw_GkNgNf+bV_pieYN_gn5i49rOF8jUvSsfPOcqCJA@mail.gmail.com
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>


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)
 {

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

[Bjorn Helgaas]

[+cc Tim]

On Tue, Aug 11, 2026 at 04:28:37PM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 11, 2026 at 05:57:33AM -0500, Max Stevens wrote:
> > Hi Bjorn,
> > 
> > Thanks for the quick patch. I tested its effect on my PI7C9X2G608GP
> > (12d8:2608) by replicating what pci_fixup_pericom_acs_store_forward()
> > does, using setpci at runtime (I have not built a patched kernel —
> > happy to do that too if you want a test of the actual binary).
> > 
> > Findings on the 2G608:
> > 
> > The mode register exists at the same offset as on the smaller
> > switches: upstream port config 0x74. Value on my system before any
> > test: 0x0102 (store-forward bit clear).
> > With ACS on all four downstream ports set to what the kernel normally
> > enables here (ACSCtl = SrcValid+ ReqRedir+ CmpltRedir+ UpstreamFwd+),
> > and 0x74 bit 0 CLEAR, device enumeration on the downstream xHCI
> > controllers fails: [43069.603242] xhci-pci-renesas 0000:0c:00.0: Error
> > while assigning device slot ID: Command Aborted [43069.603270] usb
> > usb9-port1: couldn't allocate usb_device
> > Setting 0x74 to 0x0103 (bit 0, store-forward) with ACS unchanged, then
> > rebinding the xHCI drivers: the same device on the same port
> > enumerates immediately and works fully: [43071.971147] usb 9-1: new
> > full-speed USB device number 2 using xhci-pci-renesas [43072.132176]
> > usb 9-1: Product: Azeron Keypad [43072.218656] hid-generic
> > 0003:16D0:113C.0017: input,hidraw12: USB HID v1.11 Keyboard [Azeron
> > LTD Azeron Keypad] on usb-0000:0c:00.0-1/input1
> > I toggled the bit back and forth across several driver rebinds. Every
> > "Command Aborted" failure I have logged (both today and across earlier
> > debugging) occurred with the bit clear; none with it set.
> > 
> > One honest nuance: with the bit clear the failure is not 100% — I saw
> > one enumeration attempt start successfully during a bit-clear window.
> > That intermittency is consistent with the load-dependent packet
> > buffering behaviour described in Nathan's original erratum writeup,
> > and with this card family's long history of "sometimes almost works"
> > reports on various forums.
> 
> If it's an improvement, I think it's worth applying even if it's not a
> 100% fix.
> 
> > So on this hardware the store-forward workaround behaves exactly as it
> > does on the already-quirked siblings, and the patch looks correct to
> > me.
> > 
> > Tested-by: Maximo Paulino Thinker.Healer@gmail.com
> 
> Thanks for doing this.  I'll queue up the patch below for v7.3 without
> your explicit tested-by because quirks run at different times than
> setpci, and the timing/ordering is often important.

Actually, I take that back because the same patch is already queued up
from Tim Harvey:

  https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=virtualization&id=062fb7f816439da6bf3860386889343482a66bd4