Re: [REGRESSION 6.16] r8169 RTL8168h/8111h fails to probe — "Unable to change power state from D3cold to D0" — bisected to 4d4c10f763d7

[Bjorn Helgaas <helgaas@kernel.org>]

On Sun, Jun 21, 2026 at 12:24:42PM -0700, Mario Limonciello wrote:
> On 6/17/26 01:32, Thorsten Leemhuis wrote:
> > On 6/12/26 03:07, Josh Perry wrote:
> > > #regzbot introduced: 4d4c10f763d7
> > > 
> > > Since v6.16 one of two onboard RTL8168h/8111h NICs on this board fails
> > > to probe on boot; the device drops to D3cold and the driver can't bring
> > > it back:
> > 
> > FWIW, that commit is 4d4c10f763d780 ("PCI: Explicitly put devices into
> > D0 when initializing") [v6.16-rc1] from Mario, who is already CCed, but
> > looks like might be on holiday or something due to inactivity on the
> > lists in the recent days. So it might take a few days before this moves on.
> > 
> > Josh, this is not my area of expertise, but there are two things I guess
> > might be helpful:
> > 
> > * retry with 7.1
> > * upload "dmesg" and "sudo lspci -vvv" output from working and broken
> > kernels somewhere (like bugzilla.kernel.org).
> 
> Yes; please retry with mainline.  We already had multiple regressions from
> that commit fixed, so if you bisected down to this commit then it's
> plausible that there is already a fix.

Thanks a lot for your bisection and detailed report, Josh.  Can you
verify whether this is still a problem?

The only commit that claims to fix 4d4c10f763d7 ("PCI: Explicitly put
devices into D0 when initializing") is 907a7a2e5bf4 ("PCI/PM: Set up
runtime PM even for devices without PCI PM"), and you already verified
that it did not fix the problem (both appeared in v6.16).

c855c9921da7 ("PCI/ASPM: Don't reconfigure ASPM entering low-power
state"), which appeared in v7.2-rc1, mentions a similar symptom
("Unable to change power state from D3hot to D0, device inaccessible") 
so it's possible that it would fix the issue.

> > >    r8169 0000:02:00.0 eth0: RTL8168h/8111h, 00:2b:67:48:40:01, XID 541,
> > > IRQ 137
> > >    r8169 0000:04:00.0: Unable to change power state from D3cold to D0,
> > > device inaccessible
> > >    r8169 0000:04:00.0: Mem-Wr-Inval unavailable
> > >    r8169 0000:04:00.0: error -EIO: PCI read failed
> > >    r8169 0000:04:00.0: probe with driver r8169 failed with error -5
> > > 
> > > The board has two identical RTL8168h NICs (both XID 541): 0000:02:00.0
> > > and 0000:04:00.0. Only 04:00.0 fails — its sibling 02:00.0, on a
> > > different root port, probes and works normally on the very same kernel
> > > and boot. The failing NIC then does not appear (no enp4s0), taking the
> > > machine's WAN offline. This strongly suggests the problem is port/
> > > topology-specific rather than device- or driver-specific: the upstream
> > > port behind 04:00.0 is placed in D3cold and the endpoint cannot be
> > > resumed to D0.
> > > 
> > > Hardware: RTL8168h/8111h, XID 541, PCI 04:00.0 (onboard 1GbE).
> > > Platform: Lenovo ThinkCentre M90n-1 (11AHS0B200), BIOS M2AKT49A
> > > (2026-03-25, latest available). Firmware is current, so this is not a
> > > platform-firmware issue.
> > > 
> > > Bisection: v6.15 good, v6.16 bad (verified by booting both). I then
> > > reverted 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when
> > > initializing") together with its follow-up 907a7a2e5bf4 ("PCI/PM: Set up
> > > runtime PM even for devices without PCI PM") on top of 6.16.7: the NIC
> > > probes and links at 1Gbps/Full normally, with no workaround:
> > > 
> > >    r8169 0000:04:00.0 eth1: RTL8168h/8111h, 00:2b:67:48:40:02, XID 541,
> > > IRQ 138
> > >    r8169 0000:04:00.0 enp4s0: Link is Up - 1Gbps/Full - flow control rx/tx
> > > 
> > > Workaround: booting an unmodified v6.16+ kernel with pcie_port_pm=off
> > > also restores the NIC, which is consistent with the upstream port being
> > > placed in D3cold and the device failing to resume to D0 after the
> > > explicit-D0 init change.
> > > 
> > > The follow-up 907a7a2e5bf4 does not fix this resume case: v6.18.33 is
> > > still affected (retested today on current firmware).
> > > 
> > > Happy to test patches or provide full dmesg / lspci.
> > > 
> > 
>