Re: [Bug 219031] New: DPC Regression non-Root Port and non-RCEC devices

[Bjorn Helgaas <helgaas@kernel.org>]

On Fri, Jul 12, 2024 at 12:18:46AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=219031
> 
>             Bug ID: 219031
>            Summary: DPC Regression non-Root Port and non-RCEC devices
>            Product: Drivers
>            Version: 2.5
>           Hardware: All
>                 OS: Linux
>             Status: NEW
>           Severity: normal
>           Priority: P3
>          Component: PCI
>           Assignee: drivers_pci@kernel-bugs.osdl.org
>           Reporter: dukovac.stefanie@live.ca
>         Regression: No
> 
> Created attachment 306564
>   --> https://bugzilla.kernel.org/attachment.cgi?id=306564&action=edit
> Diff of lspci output of switch between 6.5 and 6.5 with native dpc
> 
> This commit
> https://lore.kernel.org/all/20221210002922.1749403-1-helgaas@kernel.org/
> assumes that "switch[es] supports AER but not MSI" so initializing the AER IQR
> fails. This commit prevents registering AER and consequently DPC services on
> non-Root Port, non-Root Complex Event Collector devices.
> 
> I have a switch that supports MSI (or so I think). I find that DPC is no longer
> enabled by default on the switch with this commit. To re-enable DPC I pass
> `pcie_ports=dpc-native` as a karg. This means pci_aer_available() in on L263 of
> portdrv.c must evaluate to true, which means pci_msi_enabled() must be true,
> hence my switch does not match the assumption of the commit.
> 
> The `pcie_ports=dpc-native` karg forces native DPC control, regardless of
> whether native AER is enabled or not. PCIe r4.0 sec 6.1.10 and PCIe r7.0 sec
> 6.2.11 both recommend the operating system always link DPC control to the
> control of AER. 
> 
> I am working on 6.5.13.

Thanks for the report.

The change you mention was merged as
https://git.kernel.org/linus/d8d2b65a940b ("PCI/portdrv: Allow AER
service only for Root Ports & RCECs"), which appeared in v6.2, so it
looks like this would be a regression between v6.1 and v6.2.

Can you verify that v6.9 is still broken this way?  It sounds like
you've checked that reverting d8d2b65a940b solves the problem?

Can you please attach the complete dmesg log from the newest kernel
you can test?