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

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

[Josh Perry]

#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:

   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.

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

[Thorsten Leemhuis]

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).

Ciao, Thorsten

>   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.
> 

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

[Mario Limonciello]

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.

> 
> Ciao, Thorsten
> 
>>    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.
>>
> 

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

[Bjorn Helgaas]

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.
> > > 
> > 
>