On Dell Wyse 5070, ethernet controller (r8169) is connected to a root port with D3cold support (i.e. _PR3 present). Plugging RJ45 cable can wake the device from D3cold, but just for once. The second time the device gets put to D3cold, plugging RJ45 can no longer wake the device up. The ethernet controller is using GPE 8, and the root port is using GPE 9. Here's the GPE status after boot: gpe07: 0 invalid unmasked gpe08: 0 EN enabled unmasked gpe09: 0 EN enabled unmasked Here's the GPE status after RJ45 cable is plugged to ethernet port, or we manually resume the device using `lspci`: gpe07: 0 STS invalid unmasked gpe08: 0 disabled unmasked gpe09: 0 disabled unmasked And after RJ45 cable is unplugged, device and root are suspended again: gpe07: 0 STS invalid unmasked gpe08: 0 disabled unmasked gpe09: 0 disabled unmasked And plugging RJ45 doesn't work anymore. I wonder if STS on GPE 7 causes this.
Blacklisting the ethernet driver (r8169) to make sure GPE 8 is not in use. Resume the root port, we can still observe the GPE 7 status bit is flagged.
Created attachment 293013 [details] ACPI GPEs at boot, can detect RJ45 plugging
Created attachment 293015 [details] ACPI GPEs when RJ45 is plugged
Created attachment 293017 [details] ACPI GPEs when RJ45 is unplugged. It can no longer detects RJ45 cable plugging
Created attachment 293019 [details] dmesg
Created attachment 293021 [details] lspci -tv
Created attachment 293023 [details] lspci -vv
Created attachment 293027 [details] acpidump
Speaking for r8169 and RTL8168h: Chip initialization includes the following: RTL_W8(tp, MISC_1, RTL_R8(tp, MISC_1) & ~PFM_D3COLD_EN); Due to missing chip documentation I can't say what this actually does, but it wouldn't be a surprise if D3cold doesn't work properly. How is it if add a call to pci_d3cold_disable() to rtl_init_one() in r8169? Is waking from D3hot working properly?
(In reply to Heiner Kallweit from comment #9) > Speaking for r8169 and RTL8168h: > Chip initialization includes the following: > RTL_W8(tp, MISC_1, RTL_R8(tp, MISC_1) & ~PFM_D3COLD_EN); > Due to missing chip documentation I can't say what this actually does, but > it wouldn't be a surprise if D3cold doesn't work properly. I've seen r8169 works with D3cold without any issue. So if we really need to disable D3cold, we should do it at pcieport driver. > > How is it if add a call to pci_d3cold_disable() to rtl_init_one() in r8169? > Is waking from D3hot working properly? PCI PME on D3hot works properly.
So the problem is caused by disabled GPE 08 and 09? does the problem still exist if you run "echo enable > gpe08" and "echo enable > gpe09" to enable them manually?
Sorry, it was a copy error. Here's the status when it's suspended again: gpe07: 0 STS invalid unmasked gpe08: 0 EN enabled unmasked gpe09: 0 EN enabled unmasked
And I cannot clear gpe07: # echo clear > gpe07 bash: echo: write error: Invalid argument [ 1870.556493] ACPI: Can not change Invalid GPE/Fixed Event status
(In reply to Kai-Heng Feng from comment #12) > Sorry, it was a copy error. > > Here's the status when it's suspended again: > gpe07: 0 STS invalid unmasked > gpe08: 0 EN enabled unmasked > gpe09: 0 EN enabled unmasked So, it works as following? The ethernet controller is using GPE 8, and the root port is using GPE 9. Here's the GPE status after boot: gpe07: 0 invalid unmasked gpe08: 0 EN enabled unmasked gpe09: 0 EN enabled unmasked Here's the GPE status after RJ45 cable is plugged to ethernet port, or we manually resume the device using `lspci`: gpe07: 0 STS invalid unmasked gpe08: 0 disabled unmasked gpe09: 0 disabled unmasked And after RJ45 cable is unplugged, device and root are suspended again: gpe07: 0 STS invalid unmasked gpe08: 0 enabled unmasked gpe09: 0 enabled unmasked
can you attach the output of lspci -v as well as "grep . /sys/bus/pci/devices/*/firmware_node/path"?
Created attachment 293427 [details] lspci -vv
Created attachment 293429 [details] firmware_nodes
Using this diff to do some test: diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index a5cc4f3bb..492259f2a 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -755,11 +755,13 @@ static ssize_t counter_set(struct kobject *kobj, if (result) goto end; + /* if (!(status & ACPI_EVENT_FLAG_HAS_HANDLER)) { printk(KERN_WARNING PREFIX "Can not change Invalid GPE/Fixed Event status\n"); return -EINVAL; } + */ if (index < num_gpes) { if (!strcmp(buf, "disable\n") && When the issue happened: gpe07: 0 STS invalid unmasked gpe08: 0 enabled unmasked gpe09: 0 enabled unmasked Clear gpe07: # echo clear > gpe07 gpe07: 0 invalid unmasked gpe08: 0 EN enabled unmasked gpe09: 0 EN enabled unmasked Plug RJ45: gpe07: 0 STS invalid unmasked gpe08: 0 EN enabled unmasked gpe09: 0 EN enabled unmasked Feels like the GPE shifted to GPE07?
does the problem still exist when GPE07 cleared manually?
Yes. Both gpe08 and gpe09 don't work even with gpe07 gets cleared prior.
Zhang Rui, Do you think it's a firmware/hardware bug? If so I'll write a quirk to disable D3cold for the root port.
Turns out the first wake is from native PME. ACPI GPE never works. I'll ask if ODM is willing to fix is in DSDT/SSDT. Otherwise I'll write a quirk instead.
Looks like vendor will fixed it in BIOS, by changing _S0W from 4 to 3.