Messages in this thread Patch in this message | | | Date | Fri, 22 Apr 2022 17:24:33 -0500 | From | Bjorn Helgaas <> | Subject | Re: [PATCH v4 1/2] PCI/AER: Disable AER service when link is in L2/L3 ready, L2 and L3 state |
| |
[+cc Rajvi, David]
On Fri, Apr 08, 2022 at 11:31:58PM +0800, Kai-Heng Feng wrote: > On Intel Alder Lake platforms, Thunderbolt entering D3cold can cause > some errors reported by AER: > [ 30.100211] pcieport 0000:00:1d.0: AER: Uncorrected (Non-Fatal) error received: 0000:00:1d.0 > [ 30.100251] pcieport 0000:00:1d.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) > [ 30.100256] pcieport 0000:00:1d.0: device [8086:7ab0] error status/mask=00100000/00004000 > [ 30.100262] pcieport 0000:00:1d.0: [20] UnsupReq (First) > [ 30.100267] pcieport 0000:00:1d.0: AER: TLP Header: 34000000 08000052 00000000 00000000 > [ 30.100372] thunderbolt 0000:0a:00.0: AER: can't recover (no error_detected callback) > [ 30.100401] xhci_hcd 0000:3e:00.0: AER: can't recover (no error_detected callback) > [ 30.100427] pcieport 0000:00:1d.0: AER: device recovery failed > > So disable AER service to avoid the noises from turning power rails > on/off when the device is in low power states (D3hot and D3cold), as > PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states > that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready > (D3hot), L2 (D3cold with aux power) and L3 (D3cold).
Help me walk through what's happening here, because I'm never very confident about how error reporting works. I *think* the Unsupported Request error means some request was in progress and was not completed. I don't think a link going down should by itself cause an Unsupported Request error because there's no *request*.
I have a theory about what happened here. Decoding the TLP Header (from PCIe r6.0, sec 2.2.1.1, 2.2.8.10) gives:
34000000 (0011 0100 ...): Fmt 001 4 DW header, no data Type 1 0100 Msg, Local - Terminate at Receiver
08000052 (0800 ... 0101 0010) Requester ID 0800 00:08.0 Message Code 0101 0010 PTM Request
From your lspci in bugzilla, 08:00 has PTM enabled. So my theory is that:
- 08:00.0 sent a PTM Request Message (a Posted Request) - 00:1d.0 received the PTM Request Message - The link transitioned to DL_Down - Per sec 2.9.1, 00:1d.0 discarded the Request and reported an Unsupported Request - Or, per sec 6.21.3, if 00:1d.0 received a PTM Request when its own PTM Enable was clear, it would also be treated as an Unsupported Request
So I suspect we should disable PTM on 08:00.0 before putting it in a low-power state. If you manually disable PTM on 08:00.0, do these errors stop happening?
David did something like this [1], but just for Root Ports. That looks wrong to me because sec 6.21.3 says we should not have PTM enabled in an Upstream Port (i.e., in a downstream device like 08:00.0) unless it is already enabled in the Downstream Port (i.e., in the Root Port 00:1d.0).
Nit: can you remove the timestamps from the log? They add clutter but no useful information.
[1] https://git.kernel.org/linus/a697f072f5da
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215453 > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > --- > v4: > - Explicitly states the spec version. > - Wording change. > > v3: > - Remove reference to ACS. > - Wording change. > > v2: > - Wording change. > > drivers/pci/pcie/aer.c | 31 +++++++++++++++++++++++++------ > 1 file changed, 25 insertions(+), 6 deletions(-) > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > index 9fa1f97e5b270..e4e9d4a3098d7 100644 > --- a/drivers/pci/pcie/aer.c > +++ b/drivers/pci/pcie/aer.c > @@ -1367,6 +1367,22 @@ static int aer_probe(struct pcie_device *dev) > return 0; > } > > +static int aer_suspend(struct pcie_device *dev) > +{ > + struct aer_rpc *rpc = get_service_data(dev); > + > + aer_disable_rootport(rpc); > + return 0; > +} > + > +static int aer_resume(struct pcie_device *dev) > +{ > + struct aer_rpc *rpc = get_service_data(dev); > + > + aer_enable_rootport(rpc); > + return 0; > +} > + > /** > * aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP > * @dev: pointer to Root Port, RCEC, or RCiEP > @@ -1433,12 +1449,15 @@ static pci_ers_result_t aer_root_reset(struct pci_dev *dev) > } > > static struct pcie_port_service_driver aerdriver = { > - .name = "aer", > - .port_type = PCIE_ANY_PORT, > - .service = PCIE_PORT_SERVICE_AER, > - > - .probe = aer_probe, > - .remove = aer_remove, > + .name = "aer", > + .port_type = PCIE_ANY_PORT, > + .service = PCIE_PORT_SERVICE_AER, > + .probe = aer_probe, > + .suspend = aer_suspend, > + .resume = aer_resume, > + .runtime_suspend = aer_suspend, > + .runtime_resume = aer_resume, > + .remove = aer_remove, > }; > > /** > -- > 2.34.1 >
| |