Re: [REGRESSION] Intel Wireless adapter is not detected until suspending to RAM and resuming

[Lukas Wunner <lukas@wunner.de>]

On Tue, Oct 21, 2025 at 03:35:42PM +0200, Adrià Vilanova Martínez wrote:
> [    0.220045] pcieport 0000:00:1c.0: pciehp: Slot Status            : 0x0048

In the working case (without 4d4c10f763d7), there's a stale
Presence Detect Changed event in the Slot Status register.
The event is cleared by pcie_init() prior to enabling interrupts.
However the event immediately re-appears:

> [    0.220308] pcieport 0000:00:1c.0: pciehp: pcie_enable_notification: SLOTCTRL 58 write cmd 1028
> [    0.220316] pcieport 0000:00:1c.0: pciehp: pending interrupts 0x0008 from Slot Status

I also note that in the working case there are a bunch of
Correctable Errors reported through AER several times in the log:

> [    1.949940] pcieport 0000:00:1c.0: AER: Multiple Correctable error message received from 0000:00:1c.0
> [    1.949950] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)
> [    1.949955] pcieport 0000:00:1c.0:   device [8086:9d10] error status/mask=00000001/00002000
> [    1.949960] pcieport 0000:00:1c.0:    [ 0] RxErr                  (First)

Now here's the kicker:

Looking at the ASPM configuration in the lspci output you've provided,
I note that after booting without 4d4c10f763d7, ASPM is disabled on
the Root Port but L1 is enabled on the Wifi card!

After resuming from system sleep, ASPM is disabled on both of them
(with and without 4d4c10f763d7).

I suspect the incongruence of ASPM settings between Root Port and
Wifi card is the root cause of the Presence Detect Changed flaps
as well as the Correctable Errors.  I guess the BIOS set these
incorrectly.  Looking at the code in:

pcie_aspm_init_link_state()
  pcie_aspm_cap_init()

... it first disables L0s and L1 to initialize L1 substates,
then restores the register values as they were set by BIOS.
This feels wrong.  The safest option is probably to instead
disable L0s and/or L1 if either of them was only enabled
on one of the two link partners.

pcie_aspm_init_link_state() later does call pcie_config_aspm_path(),
which should rectify incongruent settings.  But it's only called
if the aspm_policy is something else than POLICY_POWERSAVE and
POLICY_POWER_SUPERSAVE.

Which policy is set in your kernel configuration?
(Search for CONFIG_PCIEASPM_...)

Does setting it to CONFIG_PCIEASPM_PERFORMANCE change the behavior?

With 4d4c10f763d7, the Wifi card falls off the bus and the link never
comes back.  I don't know why the commit is causing that.  As Mario
suggested, it may be caused by the platform.  Could you provide an
acpidump for further analysis?  The usual way to share large blobs
like this (as well as dmesg and lspci output) is by opening a bug
on bugzilla.kernel.org and attaching it there.

Thanks,

Lukas