[PCI/Thunderbolt] Intel Titan Ridge DD (8086:15ef): ACSViol on link-local LTR Msg (route 100b), possible ACS Source Validation false positive

[PCI/Thunderbolt] Intel Titan Ridge DD (8086:15ef): ACSViol on link-local LTR Msg (route 100b), possible ACS Source Validation false positive

[lionel margueritat]

Hello Linux PCI, USB xHCI and Thunderbolt maintainers,

I am requesting review of a reproducible Intel Titan Ridge DD PCIe ACS
Source Validation violation on a link-local LTR Message TLP. The goal
is to identify and correct the first rejection without disabling ACS,
AER or IOMMU.

Hardware: GEEKOM A7 Max AMD USB4, BIOS 1.26 (2025-09-15); ACASIS
TBU405Pro Intel JHL7540 Titan Ridge DD, NVM 69.84, 40 Gb/s. Ubuntu
24.04 HWE 7.0.0-43-generic.
Both reproduced boots use AMD PCIe tunnel root 0000:00:03.1 -> Intel
upstream bridge 0000:06:00.0 -> downstream 0000:07:01.0 -> NVMe
0000:08:00.0, plus downstream 0000:07:02.0 [8086:15ef] -> Intel xHCI
0000:09:00.0 [8086:15f0]. Earlier privileged data showed ACS Source
Validation enabled on the xHCI-side bridge; current non-privileged
lspci -vv does not expose PCIe extended capability registers.

Current boot (signed experimental Thunderbolt timeout module; kernel
timestamps in seconds since boot):
[1532.142389] AMD 00:03.1 pciehp Link Up
[1532.273384] Intel 06:00.0 bridge configuration invalid ([bus
00-00]), reconfiguring
[1532.280...] Bus and BAR assignment completed for endpoints
[1532.282964] xhci_hcd 09:00.0: xHCI Host Controller
[1532.824413] Intel 07:01.0: Correctable Data Link Layer BadTLP [6]
(NVMe-side bridge)
[1533.779213] Intel 07:02.0: Uncorrectable (Non-Fatal), Transaction Layer
[1533.779233] Intel 07:02.0: [21] ACSViol (First)
[1533.779243] Intel 07:02.0: TLP Header 0x34000000 0x00000010
0x00000000 0x00000000
[1533.790681] xhci_hcd 09:00.0: AER: can't recover (no error_detected callback)
[1533.790732] Intel 07:02.0: AER: device recovery failed

The Correctable BadTLP was observed approximately 0.955 sec before the
ACSViol, but on the separate NVMe downstream branch; causality is NOT
established and an analogous pre-ACS BadTLP has NOT been observed on
the previous stock-driver run.

On the previous boot with the STOCK Ubuntu Thunderbolt driver, the
same xHCI-side switch port reported first ACSViol at t=2459.768614 and
the identical LTR TLP header. Across different observation windows:
stock 75 identical ACSViol headers / 74 xHCI recovery failures,
experimental 39 headers / 38 failures. Counts cannot be compared as an
improvement.

The packet appears to be a link-local routing 100b Message TLP with
code 0x10 (LTR) and Requester ID 0000. PCI-SIG ECN of 15 April 2026,
'Access Control Services (ACS) - Source Validation Clarification',
discusses false Source Validation errors for locally routed Msg TLPs
(100b, 110b, 111b):
https://pcisig.com/PCIExpress/ECN/Base/AccessControlServicesACSSourceValidationClarification
This is a strong hypothesis, NOT a confirmed Intel silicon erratum.

Unbinding only Intel xHCI stopped new ACSViol while the NVMe continued
to enumerate; no new ACSViol since 12 Nov 19:30:05 CET. Sustained NVMe
I/O has not been validated. ACS/AER/IOMMU have NOT been disabled or
masked, and no firmware has been flashed. Both USB4 domains report
iommu_dma_protection=0. Please do not suggest wholesale ACS disabling
on this Thunderbolt topology.

Questions:
1. Is the LTR TLP with route 100b and Requester ID 0000 valid on this
downstream switch port, and should ACS Source Validation exempt it?
2. Is there a known Intel Titan Ridge DD JHL7540 NVM/silicon
limitation, or a device-specific signed firmware correction? ACASIS
support has been contacted.
3. Could an init-time software quirk or firmware correction handle
this without weakening device isolation?
4. What passive pre-reject tracing/register evidence would you want
gathered during a future supervised maintenance window?

I can provide sanitized full dmesg/lspci/topology evidence. This is
not a claimed mainline regression; no clean upstream reproduction has
been done, and the experimental build is tainted.

Regards

Re: [PCI/Thunderbolt] Intel Titan Ridge DD (8086:15ef): ACSViol on link-local LTR Msg (route 100b), possible ACS Source Validation false positive

[Lukas Wunner]

On Fri, Nov 13, 2026 at 03:18:46AM -0500, lionel margueritat wrote:
> [1532.142389] AMD 00:03.1 pciehp Link Up
> [1532.273384] Intel 06:00.0 bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [1532.280...] Bus and BAR assignment completed for endpoints
> [1532.282964] xhci_hcd 09:00.0: xHCI Host Controller
> [1532.824413] Intel 07:01.0: Correctable Data Link Layer BadTLP [6]
> (NVMe-side bridge)
> [1533.779213] Intel 07:02.0: Uncorrectable (Non-Fatal), Transaction Layer
> [1533.779233] Intel 07:02.0: [21] ACSViol (First)
> [1533.779243] Intel 07:02.0: TLP Header 0x34000000 0x00000010
> 0x00000000 0x00000000
> [1533.790681] xhci_hcd 09:00.0: AER: can't recover (no error_detected callback)
> [1533.790732] Intel 07:02.0: AER: device recovery failed
[...]
> The packet appears to be a link-local routing 100b Message TLP with
> code 0x10 (LTR) and Requester ID 0000. PCI-SIG ECN of 15 April 2026,
> 'Access Control Services (ACS) - Source Validation Clarification',
> discusses false Source Validation errors for locally routed Msg TLPs
> (100b, 110b, 111b):
> https://pcisig.com/PCIExpress/ECN/Base/AccessControlServicesACSSourceValidationClarification
[...]
> 1. Is the LTR TLP with route 100b and Requester ID 0000 valid on this
> downstream switch port, and should ACS Source Validation exempt it?

It's a valid TLP.  The ECN talks about *optionally* ignoring TLPs
like this one when performing ACS Source Validation ("designers may
disable Source Validation").

> 2. Is there a known Intel Titan Ridge DD JHL7540 NVM/silicon
> limitation, or a device-specific signed firmware correction? ACASIS
> support has been contacted.

I'm not aware of one, maybe Mika has more info.

> 3. Could an init-time software quirk or firmware correction handle
> this without weakening device isolation?

CXL has a similar issue when performing a Secondary Bus Reset:
The Endpoint sends a PM Init message upstream with a zero Requester ID
and that triggers an ACS Source Validation.

Fabio used to work on this, he's no longer at Intel and the project
is thus paused:

https://lore.kernel.org/all/20260825022628.3651434-1-fabio.m.de.francesco@linux.intel.com/

According to PCIe r7.1 sec 2.2.9.1:

   "Functions must capture the Bus and Device Numbers supplied with all
    Type 0 Configuration Write Requests completed by the Function,
    and supply these numbers in the Bus and Device Number fields of the
    Completer ID for all Completions generated by the Device/Function.
    If a Function must generate a Completion prior to the initial device
    Configuration Write Request, 0's must be entered into the Bus Number
    and Device Number fields."

So we need to perform one Config Space Write before the device sends any
LTR message upstream.  The kernel sets PCI_EXP_DEVCTL2_LTR_EN in
drivers/pci/pcie/aspm.c, but I would think that we perform a lot of
Config Space Writes before that, so the device should know its bus and
device/function number by the time PCI_EXP_DEVCTL2_LTR_EN is set.

Is PCI_EXP_DEVCTL2_LTR_EN set by default on this device?  That would indeed
be a silicon bug because the default value is 0 for the bit per PCIe r7.1
sec 7.5.3.16.  Or maybe the platform firmware sets the bit?

Thanks,

Lukas