Re: [PATCH] PCI: Disable NoSnoop and Relaxed ordering for Intel wireless BE200
Bjorn Helgaas <[email protected]>
| Newsgroups | dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <20260728180315.GA1380884@bhelgaas> |
On Thu, Jul 23, 2026 at 11:35:41AM +0000, Grumbach, Emmanuel wrote: > On Thu, 2026-07-23 at 15:19 +0530, Manikanta Maddireddy wrote: > > On 22/07/26 10:34 pm, Bjorn Helgaas wrote: > > > > The problem was that we didn't show up at all in the enumeration. > > > > We > > > > send a malformed TLP. I'm not quite an expert at this, but our > > > > PCIe > > > > experts run a PCI analyzer on the enumeration on that specific > > > > platform and they saw that platform's PCI controller sets the > > > > NoSnoop and Relaxed ordering bit in the TLP. According to the > > > > spec > > > > (which I ignore), the BE200 is supposed to return the TLP as > > > > received, but we reply with 0 Attributes and the enumeration > > > > doesn't > > > > complete successfully. > > > I'm curious about the details of this enumeration failure. Do you > > > know which TLPs had No Snoop and Relaxed Ordering set? Per the > > > PCIe > > > spec, they shouldn't be set for the config requests used for PCI > > > core > > > enumeration. > > > > > > At least*some* config reads to the BE200 must work; otherwise, we > > > wouldn't know the Vendor or Device ID, which we need to apply the > > > quirk. So I think you should see something like this in dmesg, and > > > BE200 would probably appear in lspci output: > > > > > > pci 0000:04:00.0: [8086:272b] type 00 class ... > > > > > > Is the failure that iwl_pci_probe() itself fails somehow? > > > > > > You mentioned that this happens on Jetson Thor, but I'm not sure > > > what PCIe controller that is. My guess is it might be Tegra264 > > > [1], which doesn't look like it's merged yet. > > > > > > Thierry, Manikanta, do you have any insight into this? Does > > > this PCIe controller set No Snoop and Relaxed Ordering for some > > > reason? I don't think endpoint drivers are expecting that. > > > > > > [1]https://lore.kernel.org/linux-pci/20260716-tegra264-pcie- > > > [email protected]/ > > > > Hi, > > > > Jetson Thor(Tegra264) is not setting NoSnoop and RlxdOrd bits in > > config > > read TLP. > > > > I made sure that both these bits are set in RP's DevCtl > > > > DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+ > > RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ > > > > and dumped TLP header for a config read towards BDF 0x100 with offset > > 0x24. > > 0x04000001 0x0000000f 0x01000024 0x00000000 > > > > I think dmesg and AER log with header information might help with > > this > > particular issue. > > Ok, so I checked again the logs and I was wrong. > We do see the device in the enumeration, it does show up in lspci. > Problems start when we want to access our registers. > I attached the full dmesg output. In that log we try to load iwlwifi > twice. > > I'm adding here the snippet of the first load: > > [ 15.275887] iwlwifi 0001:01:00.0: Adding to iommu group 53 > [ 15.279737] iwlwifi 0001:01:00.0: enabling device (0100 -> 0102) > [ 15.280047] iwlwifi 0001:01:00.0: HW_REV=0xFFFFFFFF, PCI issues? \\ ** The "enabling device" message is from pci_enable_resources(), called in the pci_enable_device() path. The 0100 is from a config read of PCI_COMMAND, and the 0102 is from adding PCI_COMMAND_MEMORY to enable memory BARs. The "HW_REV=" is from iwl_pci_probe(), which looks like the very first MMIO read to a BE200 BAR. So I guess the theory is that Tegra264 set NoSnoop and/or RlxdOrd in the MMIO read, BE200 didn't copy the attributes from the Request to the Completion as required by PCIe r7.0, sec 2.2.9.1, and Tegra264 logged a Malformed TLP? AFAICS we still don't know why Tegra264 would set NoSnoop and/or RlxdOrd in the MMIO read. Unless iwlwifi asked for NoSnoop and/or RlxdOrd to be set, I think it's a potential problem for drivers if Tegra264 sets them. > [ 15.280070] iwlwifi: probe of 0001:01:00.0 failed with error -5 \\ ** > [ 15.280087] pcieport 0001:00:00.0: AER: Correctable error message received from 0001:00:00.0 > [ 15.280104] pcieport 0001:00:00.0: DPC: containment event, status:0x3f01 source:0x0000 > [ 15.280110] pcieport 0001:00:00.0: DPC: unmasked uncorrectable error detected > [ 15.280127] pcieport 0001:00:00.0: AER: found no error details for 0001:00:00.0 > [ 15.280154] pcieport 0001:00:00.0: PCIe Bus Error: severity=Uncorrectable (Fatal), type=Transaction Layer, (Receiver ID) > [ 15.280157] pcieport 0001:00:00.0: device [10de:22d8] error status/mask=00040000/04400000 > [ 15.280160] pcieport 0001:00:00.0: [18] MalfTLP (First) > [ 15.280163] pcieport 0001:00:00.0: AER: TLP Header: 4a008001 01000004 00000028 72040000 > [ 15.280274] pci 0001:01:00.0: AER: can't recover (no error_detected callback) > > Does that help? > > > > > Thanks, > > Manikanta