[SRU] [Unstable/OEM-B] [PATCH 0/2] r8169 doesn't get woken up by ethernet cable plugging, no PME generated
Kai-Heng Feng
kai.heng.feng at canonical.com
Wed Feb 27 14:55:27 UTC 2019
> On Feb 27, 2019, at 21:48, Seth Forshee <seth.forshee at canonical.com> wrote:
>
> On Tue, Feb 26, 2019 at 04:56:55PM +0800, Kai-Heng Feng wrote:
>> BugLink: https://bugs.launchpad.net/bugs/1817676
>>
>> [Impact]
>> Once r8169 (Realtek ethernet) and its root port enter to D3, plugging
>> network cable doesn't wake r8169 up.
>>
>> [Fix]
>> Revert "PCI/PME: Implement runtime PM callbacks".
>> Quote the original commit message:
>> "
>> The commit tried to prevent root port waking up from D3cold immediately but
>> looks like disabing root port PME interrupt is not the right way to fix
>> that issue so revert it now. The patch following proposes an alternative
>> solution to that issue.
>> "
>>
>> [Test]
>> After applying the fix, plugging the ethernet cable can generate PME IRQ
>> correctly, hence waking up r8169.
>>
>> [Regression Potential]
>> Medium. The commits are relative new, rely on some PCI detail that I am
>> not familiar with (PCI spec isn't publicly available).
>> Fortunately we only need this fix for Unstable/OEM-B, so it won't hit
>> most users if any regression happens.
>
> I think it would be safer to apply only the revert if the only problem
> we're trying to fix is the wakeup on cable plug, since that commit was
> new in 4.20 anyhow. If you think we also need the second commit, please
> explain why and let me know what kind of testing you've done with it.
Yes, the second commit is needed.
The reverted commit "PCI/PME: Implement runtime PM callbacks” is an
attempt to solve a TBT issue on X1 Carbon 6th Gen [1].
Patch [2/2] is a replacement for the reverted fix.
Without it, the native TBT device will be in a D0/D3cold loop [2]:
[ 263.418400] pcieport 0000:00:1d.0: power state changed by ACPI to D3cold
[ 264.919693] pcieport 0000:00:1d.0: power state changed by ACPI to D0
…
[ 285.114443] pcieport 0000:00:1d.0: power state changed by ACPI to D3cold
[ 286.614872] pcieport 0000:00:1d.0: power state changed by ACPI to D0
…
[ 306.682371] pcieport 0000:00:1d.0: power state changed by ACPI to D3cold
[ 308.183711] pcieport 0000:00:1d.0: power state changed by ACPI to D0
I think the dmesg itself is a good justification for picking patch [2/2].
Right now I can’t conduct any meaningful test because the one I have
(Dell TB16) has a device that prevents the full hierarchy to enter D3cold,
so the issue can't be reproduced here.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=202593
[2] https://bugzilla.kernel.org/attachment.cgi?id=281163
Kai-Heng
>
> Thanks,
> Seth
More information about the kernel-team
mailing list