Bug 190871

Summary:	Dell XPS13 9360: Power button not sending any events
Product:	Platform Specific/Hardware	Reporter:	Paul Menzel (pmenzel+bugzilla.kernel.org)
Component:	i386	Assignee:	Lv Zheng (lv.zheng)
Status:	CLOSED INVALID
Severity:	normal	CC:	carnil, lv.zheng, pmenzel+bugzilla.kernel.org
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.9-rc8	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	journalctl -k acpidump journalctl -k

Description Paul Menzel 2016-12-22 13:13:51 UTC

Similar to bug #84651 [1] the pressing the power button no event is send. (All other function keys work fine.)

The downstream report in the Debian BTS has the number 848967 [1].

```
$ sudo dmesg | grep -A1 BTN
Dec 22 12:02:33 xps13 kernel: ACPI: Power Button [PBTN]
Dec 22 12:02:33 xps13 kernel: input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input5
Dec 22 12:02:33 xps13 kernel: ACPI: Sleep Button [SBTN]
Dec 22 12:02:33 xps13 kernel: input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 
```


[1] https://bugzilla.kernel.org/show_bug.cgi?id=84651
[2] https://bugs.debian.org/848967


```
$ ls -l /sys/bus/platform/devices
total 0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 ACPI0003:00 -> ../../../devices/platform/ACPI0003:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 ACPI000C:00 -> ../../../devices/platform/ACPI000C:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 alarmtimer -> ../../../devices/platform/alarmtimer
lrwxrwxrwx 1 root root 0 Dec 22 12:02 coretemp.0 -> ../../../devices/platform/coretemp.0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 dcdbas -> ../../../devices/platform/dcdbas
lrwxrwxrwx 1 root root 0 Dec 22 12:02 i2c_designware.0 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 i2c_designware.1 -> ../../../devices/pci0000:00/0000:00:15.1/i2c_designware.1
lrwxrwxrwx 1 root root 0 Dec 22 12:02 i8042 -> ../../../devices/platform/i8042
lrwxrwxrwx 1 root root 0 Dec 22 12:02 idma64.0 -> ../../../devices/pci0000:00/0000:00:15.0/idma64.0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 idma64.1 -> ../../../devices/pci0000:00/0000:00:15.1/idma64.1
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT0800:00 -> ../../../devices/pci0000:00/0000:00:1f.0/INT0800:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT33A1:00 -> ../../../devices/platform/INT33A1:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT33D2:00 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D2:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT33D3:00 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D3:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT33D4:00 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D4:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT33D5:00 -> ../../../devices/platform/INT33D5:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT33D6:00 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT3400:00 -> ../../../devices/platform/INT3400:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT3403:00 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT3403:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT3403:01 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT3403:01
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT3403:02 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT3403:02
lrwxrwxrwx 1 root root 0 Dec 22 12:02 INT344B:00 -> ../../../devices/pci0000:00/INT344B:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 iTCO_wdt -> ../../../devices/pci0000:00/0000:00:1f.4/iTCO_wdt
lrwxrwxrwx 1 root root 0 Dec 22 12:02 microcode -> ../../../devices/platform/microcode
lrwxrwxrwx 1 root root 0 Dec 22 12:02 pcspkr -> ../../../devices/platform/pcspkr
lrwxrwxrwx 1 root root 0 Dec 22 12:02 platform-framebuffer.0 -> ../../../devices/platform/platform-framebuffer.0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0103:00 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0103:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0C09:00 -> ../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0C0A:00 -> ../../../devices/platform/PNP0C0A:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0C0C:00 -> ../../../devices/platform/PNP0C0C:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0C0D:00 -> ../../../devices/platform/PNP0C0D:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0C0E:00 -> ../../../devices/platform/PNP0C0E:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0C14:00 -> ../../../devices/platform/PNP0C14:00
lrwxrwxrwx 1 root root 0 Dec 22 12:02 PNP0C14:01 -> ../../../devices/platform/PNP0C14:01
lrwxrwxrwx 1 root root 0 Dec 22 12:02 regulatory.0 -> ../../../devices/platform/regulatory.0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 rtsx_pci_ms.0 -> ../../../devices/pci0000:00/0000:00:1c.5/0000:3b:00.0/rtsx_pci_ms.0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 rtsx_pci_sdmmc.0 -> ../../../devices/pci0000:00/0000:00:1c.5/0000:3b:00.0/rtsx_pci_sdmmc.0
lrwxrwxrwx 1 root root 0 Dec 22 12:02 serial8250 -> ../../../devices/platform/serial8250
lrwxrwxrwx 1 root root 0 Dec 22 12:02 snd-soc-dummy -> ../../../devices/platform/snd-soc-dummy

$ ls -l /sys/bus/platform/drivers/*/
/sys/bus/platform/drivers/alarmtimer/:
total 0
lrwxrwxrwx 1 root root    0 Dec 22 13:02 alarmtimer -> ../../../../devices/platform/alarmtimer
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/broxton-pinctrl/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/byt_gpio/:
total 0
--w------- 1 root root 4096 Dec 22 12:02 uevent

/sys/bus/platform/drivers/cherryview-pinctrl/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/clk-lpt/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/coretemp/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 coretemp.0 -> ../../../../devices/platform/coretemp.0
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/coretemp
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/dcdbas/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 dcdbas -> ../../../../devices/platform/dcdbas
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/dcdbas
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/dw-apb-uart/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/efi-framebuffer/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/fjes/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/fjes
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/gpio-clk/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/hci_bcm/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/hci_uart
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/hci_intel/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/hci_uart
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/i2c_designware/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 i2c_designware.0 -> ../../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0
lrwxrwxrwx 1 root root    0 Dec 22 13:02 i2c_designware.1 -> ../../../../devices/pci0000:00/0000:00:15.1/i2c_designware.1
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/i2c_designware_platform
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/i8042/:
total 0
lrwxrwxrwx 1 root root    0 Dec 22 13:02 i8042 -> ../../../../devices/platform/i8042
--w------- 1 root root 4096 Dec 22 12:02 uevent

/sys/bus/platform/drivers/idma64/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 idma64.0 -> ../../../../devices/pci0000:00/0000:00:15.0/idma64.0
lrwxrwxrwx 1 root root    0 Dec 22 13:02 idma64.1 -> ../../../../devices/pci0000:00/0000:00:15.1/idma64.1
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/idma64
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/int3400 thermal/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 INT3400:00 -> ../../../../devices/platform/INT3400:00
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/int3400_thermal
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/int3401 thermal/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/processor_thermal_device
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/int3403 thermal/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 INT3403:00 -> ../../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT3403:00
lrwxrwxrwx 1 root root    0 Dec 22 13:02 INT3403:01 -> ../../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT3403:01
lrwxrwxrwx 1 root root    0 Dec 22 13:02 INT3403:02 -> ../../../../devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT3403:02
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/int3403_thermal
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/intel-lpss/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/intel_lpss_acpi
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/iTCO_wdt/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 iTCO_wdt -> ../../../../devices/pci0000:00/0000:00:1f.4/iTCO_wdt
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/iTCO_wdt
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/pcspkr/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/pcspkr
lrwxrwxrwx 1 root root    0 Dec 22 13:02 pcspkr -> ../../../../devices/platform/pcspkr
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/rtsx_pci_ms/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/rtsx_pci_ms
lrwxrwxrwx 1 root root    0 Dec 22 13:02 rtsx_pci_ms.0 -> ../../../../devices/pci0000:00/0000:00:1c.5/0000:3b:00.0/rtsx_pci_ms.0
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/rtsx_pci_sdmmc/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/rtsx_pci_sdmmc
lrwxrwxrwx 1 root root    0 Dec 22 13:02 rtsx_pci_sdmmc.0 -> ../../../../devices/pci0000:00/0000:00:1c.5/0000:3b:00.0/rtsx_pci_sdmmc.0
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/serial8250/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 serial8250 -> ../../../../devices/platform/serial8250
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/snd-soc-dummy/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/snd_soc_core
lrwxrwxrwx 1 root root    0 Dec 22 13:02 snd-soc-dummy -> ../../../../devices/platform/snd-soc-dummy
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/soc-audio/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/snd_soc_core
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/soc_button_array/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/soc_button_array
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/sunrisepoint-pinctrl/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 INT344B:00 -> ../../../../devices/pci0000:00/INT344B:00
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/tpm_tis/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
lrwxrwxrwx 1 root root    0 Dec 22 13:02 module -> ../../../../module/tpm_tis
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind

/sys/bus/platform/drivers/vesa-framebuffer/:
total 0
--w------- 1 root root 4096 Dec 22 13:02 bind
--w------- 1 root root 4096 Dec 22 12:02 uevent
--w------- 1 root root 4096 Dec 22 13:02 unbind
```

Comment 1 Paul Menzel 2016-12-22 13:14:32 UTC

Created attachment 248331 [details]
journalctl -k

Comment 2 Paul Menzel 2016-12-22 13:18:21 UTC

Created attachment 248341 [details]
acpidump

Comment 3 Lv Zheng 2016-12-23 02:35:19 UTC

(In reply to Paul Menzel from comment #0)
> Similar to bug #84651 [1] the pressing the power button no event is send.
> (All other function keys work fine.)

Normally such issues are not ACPI issues, but platform specific.
Are you sure you are filing the button bugs to the correct category?

Thanks
Lv

Comment 4 Lv Zheng 2016-12-23 03:25:04 UTC

1. First I can see this in FADT:
            Control Method Power Button (V1) : 0
            Control Method Sleep Button (V1) : 1

2. Second I can find this in DSDT:
            Device (PBTN)
            {
                Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */)  // _HID: Hardware ID
                Name (PBST, One)
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (PBST == One)
                    {
                        Return (0x0F)
                    }

                    Return (Zero)
                }

                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return (PPRW ())
                }

                Method (_PSW, 1, NotSerialized)  // _PSW: Power State Wake
                {
                    EEAC (One, Arg0)
                }
            }

            Device (SBTN)
            {
                Name (_HID, EisaId ("PNP0C0E") /* Sleep Button Device */)  // _HID: Hardware ID
            }

3. Third, I found notifications related to the buttons:
   Device Wake Notifications:
   _WAK (Invoking _SB.PCI0.LPCB.SWAK)
	Line 4438:                         Notify (PBTN, 0x02)
   _SB.PCI0.HECI._DSM
	Line 17958:                                     Notify (PBTN, 0x02)
   _SB.PBTN.BTNV (One, One)
 	Line 36983:                         Notify (PBTN, 0x02)

   Status Change Notifications:
   _SB.PCI0.HECI._DSM
	Line 17965:                                     Notify (PBTN, 0x80)
   _SB.PBTN.BTNV (One, Zero)
	Line 36978:                         Notify (PBTN, 0x80)

   (Ignore) Device Check Notifications:
	Line 37266:                         Notify (PBTN, One)
	Line 37721:                     Notify (PBTN, One)

Checking BTNV, it's invoked by EV6, and Arg0 should be 1, so we can see the following 2 invocations:
   EV6 (One, Zero/One)
   _SB.PCI0.LPCB.ECDV._Q66
	Line 36498:             EV6 (One, Zero)
	Line 36978:                         Notify (PBTN, 0x80)
   _GPE._L09
	Line 36817:                 EV6 (One, One)
 	Line 36983:                         Notify (PBTN, 0x02)
According to the spec:
0x80: Sleep notification
While the system is in the working state, a power button press is a user request to transition the system into either the sleeping (G1) or soft-off state (G2). In these cases, the power button event handler issues the Notify command with the device specific code of 0x80. This indicates to OSPM to pass control to the power button driver (PNP0C0C) with the knowledge that a transition out of the G0 state is being requested.
0x02: Wakeup notification
Upon waking from a G1 sleeping state, the AML event handler generates a notify command with the code of 0x2 to indicate it was responsible for waking the system.

So you need to check if _Q66 and _L09 have been invoked.
For _L09, you can monitor /sys/firmware/acpi/interrupts/gpe09 and upload your monitoring result here.
For _Q66, you can specify a boot parameter (dyndbg="file ec.c +p") to boot the system, and press button, dump the dmesg output and upload here.

However, I'm not able to obtain the _PRW result for PBTN.
I searched all _PWR, many of them are wrapped by AML control methods and cannot be obtained remotely.
GPRW (0x69, 0x04)
	Line 4691:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 4727:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 4946:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 4982:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 5201:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 5237:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 5456:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 5492:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 5711:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 5747:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 5966:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6002:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6221:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6257:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6476:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6512:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6731:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6767:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 6986:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 7022:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 7241:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 7277:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 7496:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 7532:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 7751:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 7787:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8006:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8042:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8261:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8297:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8516:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8552:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8771:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 8807:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9026:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9062:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9271:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9307:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9516:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9552:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9761:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 9797:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 10006:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 10042:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 10261:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 10297:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 10516:                     Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 10552:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
GPRW (0x6D, 0x04)
	Line 13000:             Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 13741:             Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 13794:             Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
PPRW ()
	Line 36931:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
	Line 36956:                 Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
0x6D, 0x00/0x01/0x03
	Line 37510:         Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake

The PPRW returns a GPE shared between Lid and PowerButton.

Could you use acpidbg to obtain that for me?
The command is:
# acpidbg -b "ex _SB.PBTN._PWR"
You need to enable CONFIG_ACPI_DEBUGGER_USER=m and rebuild kernel.
Please check see Documentation/acpi/aml-debugger.txt for more information.

Thanks
Lv

Comment 5 Paul Menzel 2016-12-23 10:29:36 UTC

(In reply to Lv Zheng from comment #3)
> (In reply to Paul Menzel from comment #0)
> > Similar to bug #84651 [1] the pressing the power button no event is send.
> > (All other function keys work fine.)
> 
> Normally such issues are not ACPI issues, but platform specific.
> Are you sure you are filing the button bugs to the correct category?

Sorry, I am not sure at all, if I assigned it to the correct to the correct category. Thank you for taking a look nevertheless. I’ll try get back with the information you requested as soon as possible.

Comment 6 Paul Menzel 2016-12-23 12:14:39 UTC

(In reply to Lv Zheng from comment #4)

[…]

> 3. Third, I found notifications related to the buttons:
>    Device Wake Notifications:
>    _WAK (Invoking _SB.PCI0.LPCB.SWAK)
>       Line 4438:                         Notify (PBTN, 0x02)
>    _SB.PCI0.HECI._DSM
>       Line 17958:                                     Notify (PBTN, 0x02)
>    _SB.PBTN.BTNV (One, One)
>       Line 36983:                         Notify (PBTN, 0x02)
> 
>    Status Change Notifications:
>    _SB.PCI0.HECI._DSM
>       Line 17965:                                     Notify (PBTN, 0x80)
>    _SB.PBTN.BTNV (One, Zero)
>       Line 36978:                         Notify (PBTN, 0x80)
> 
>    (Ignore) Device Check Notifications:
>       Line 37266:                         Notify (PBTN, One)
>       Line 37721:                     Notify (PBTN, One)
> 
> Checking BTNV, it's invoked by EV6, and Arg0 should be 1, so we can see the
> following 2 invocations:
>    EV6 (One, Zero/One)
>    _SB.PCI0.LPCB.ECDV._Q66
>       Line 36498:             EV6 (One, Zero)
>       Line 36978:                         Notify (PBTN, 0x80)
>    _GPE._L09
>       Line 36817:                 EV6 (One, One)
>       Line 36983:                         Notify (PBTN, 0x02)
> According to the spec:
> 0x80: Sleep notification
> While the system is in the working state, a power button press is a user
> request to transition the system into either the sleeping (G1) or soft-off
> state (G2). In these cases, the power button event handler issues the Notify
> command with the device specific code of 0x80. This indicates to OSPM to
> pass control to the power button driver (PNP0C0C) with the knowledge that a
> transition out of the G0 state is being requested.
> 0x02: Wakeup notification
> Upon waking from a G1 sleeping state, the AML event handler generates a
> notify command with the code of 0x2 to indicate it was responsible for
> waking the system.
> 
> So you need to check if _Q66 and _L09 have been invoked.
> For _L09, you can monitor /sys/firmware/acpi/interrupts/gpe09 and upload
> your monitoring result here.


```
$ more /sys/firmware/acpi/interrupts/gpe09
       0     EN enabled      unmasked
```

Pressing the power button nothing changes here.

> For _Q66, you can specify a boot parameter (dyndbg="file ec.c +p") to boot
> the system, and press button, dump the dmesg output and upload here.

```
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) submitted/blocked
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Event started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(W) = 0x84
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x09 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=1
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x66
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) unblocked
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) completed by hardware
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Query(0x66) scheduled
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Event stopped
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Query(0x66) started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x07
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x00
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x08
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (3)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x00
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x0b
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x08
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x0c
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x00
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:46 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x01
Dec 23 13:05:46 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x04
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:46 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:46 xps13 kernel: ACPI : EC: Query(0x66) stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) submitted/blocked
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Event started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(W) = 0x84
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x09 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=1
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x66
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) unblocked
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) completed by hardware
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) scheduled
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Event stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x07
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x00
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x08
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x00
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x0b
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x08
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (3)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x0c
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x00
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 2: Increase command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) started
Dec 23 13:05:47 xps13 kernel: ACPI : EC: TASK (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(W) = 0x80
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (3)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(W) = 0x01
Dec 23 13:05:47 xps13 kernel: ACPI : EC: IRQ (2)
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
Dec 23 13:05:47 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x00
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Command(UNDEF) stopped
Dec 23 13:05:47 xps13 kernel: ACPI : EC: 1: Decrease command
Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) stopped
```

[…]

Building the Linux kernel will take some more time. Hopefully the above will help already finding out about the problem.

Please note, that Ben Hutchings, the (one of) the maintainer(s) of the Linux kernel in Debian replied too [1].


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848967#26

Comment 7 Paul Menzel 2016-12-23 13:23:48 UTC

I don’t know if the button worked with the shipped “Dell Ubuntu”. I couldn’t find any patches in the Ubuntu Linux package for this issue [1].

Building the Linux kernel takes too long, so I’ll report the rest next year.

[1] http://packages.ubuntu.com/xenial/linux-image-4.4.0-57-generic

Comment 8 Lv Zheng 2016-12-26 02:14:39 UTC

(In reply to Paul Menzel from comment #5)
> > Normally such issues are not ACPI issues, but platform specific.
> > Are you sure you are filing the button bugs to the correct category?
> 
> Sorry, I am not sure at all, if I assigned it to the correct to the correct
> category. Thank you for taking a look nevertheless. I’ll try get back with
> the information you requested as soon as possible.

Just a casual talk.
I've re-assigned several such kind of bugs to platform-specific category.
Some are caused by wrong OSPM GPIO usages, some are caused by WMI gaps, and some are caused by lacking of platform specific device drivers.

However, this seems to be different.
According to your latest test result, we need to check _Q66 .

(In reply to Paul Menzel from comment #6)
> $ more /sys/firmware/acpi/interrupts/gpe09
>        0     EN enabled      unmasked
> Pressing the power button nothing changes here.

The GPE _L09 is responsible for wakeup, and Linux kernel doesn't route the GPE interupts to the ACPI drivers after being woken up.
So I should ask the following question instead:
 Can pressing power button wake the system up?

> Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x66
> Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) scheduled
> Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) started
> Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) stopped

We can see _Q66 invoked.
So we need to check with AML executed inside of _Q66.
            Method (_Q66, 0, NotSerialized)  // _Qxx: EC Query
            {
                If (ECRD != One)
                {
                    Return (Zero)
                }

                NEVT ()
                Return (Zero)
            }
Our expectation is:
NEVT is executed, inside of NEVT, EV6 is executed with (Arg0=One, Arg1=Zero), so ECG1 should return a value with last bit set.
Please:
1. build the kernel with CONFIG_ACPI_DEBUG=y;
2. boot the kernel with "acpi.trace_state=opcode acpi.trace_method_name=_SB.PCI0.LPCB.ECDV._Q66";
3. press power button and upload the dmesg output here.

If this gives too much information that can be hold by the kernel log buffer.
You can
1. Use "acpi.trace_state=opcode-once acpi.trace_method_name=_SB.PCI0.LPCB.ECDV._Q66" instead, of
2. Add "log_buf_len=16M" or bigger.

Hope this test could shed new light on the root cause.

> Please note, that Ben Hutchings, the (one of) the maintainer(s) of the Linux
> kernel in Debian replied too [1].
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848967#26

Thanks for the information, it's good to have this referenced here!

Best regards
Lv

Comment 9 Paul Menzel 2017-01-04 15:00:19 UTC

Created attachment 250231 [details]
journalctl -k

(In reply to Lv Zheng from comment #8)
> (In reply to Paul Menzel from comment #5)
> > > Normally such issues are not ACPI issues, but platform specific.
> > > Are you sure you are filing the button bugs to the correct category?
> > 
> > Sorry, I am not sure at all, if I assigned it to the correct to the correct
> > category. Thank you for taking a look nevertheless. I’ll try get back with
> > the information you requested as soon as possible.
> 
> Just a casual talk.
> I've re-assigned several such kind of bugs to platform-specific category.

I didn’t file it in the category *x86-64* as the description talks about “AMD Hammer”.

> x86-64: platform_x86_64@kernel-bugs.osdl.org
> Bugs specific to the AMD Hammer architecture.

> Some are caused by wrong OSPM GPIO usages, some are caused by WMI gaps, and
> some are caused by lacking of platform specific device drivers.
> 
> However, this seems to be different.
> According to your latest test result, we need to check _Q66 .
> 
> (In reply to Paul Menzel from comment #6)
> > $ more /sys/firmware/acpi/interrupts/gpe09
> >        0     EN enabled      unmasked
> > Pressing the power button nothing changes here.
> 
> The GPE _L09 is responsible for wakeup, and Linux kernel doesn't route the
> GPE interupts to the ACPI drivers after being woken up.
> So I should ask the following question instead:
>  Can pressing power button wake the system up?
> 
> > Dec 23 13:05:46 xps13 kernel: ACPI : EC: EC_DATA(R) = 0x66
> > Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) scheduled
> > Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) started
> > Dec 23 13:05:47 xps13 kernel: ACPI : EC: Query(0x66) stopped
> 
> We can see _Q66 invoked.
> So we need to check with AML executed inside of _Q66.
>             Method (_Q66, 0, NotSerialized)  // _Qxx: EC Query
>             {
>                 If (ECRD != One)
>                 {
>                     Return (Zero)
>                 }
> 
>                 NEVT ()
>                 Return (Zero)
>             }
> Our expectation is:
> NEVT is executed, inside of NEVT, EV6 is executed with (Arg0=One,
> Arg1=Zero), so ECG1 should return a value with last bit set.
> Please:
> 1. build the kernel with CONFIG_ACPI_DEBUG=y;
> 2. boot the kernel with "acpi.trace_state=opcode
> acpi.trace_method_name=_SB.PCI0.LPCB.ECDV._Q66";
> 3. press power button and upload the dmesg output here.

Thanks to Thorsten’s suggestion, I selected INTEL_VBTN, and the system suspends now, when pressing the power button. Hopefully, that doesn’t interfere.

Please find the output of `journalctl -k` from Linux master branch (4.10-rc2+) attached. Pressing the Unfortunately there are some graphical issues.

[…]
> If this gives too much information that can be hold by the kernel log buffer.
> You can
> 1. Use "acpi.trace_state=opcode-once
> acpi.trace_method_name=_SB.PCI0.LPCB.ECDV._Q66" instead, of
> 2. Add "log_buf_len=16M" or bigger.

Thanks to the systemd journal that isn’t necessary.

[…]


[2] https://bugzilla.kernel.org/describecomponents.cgi?product=Platform%20Specific%2FHardware
[3] https://lkml.org/lkml/2016/12/27/25
    "Question regarding power button of Dell XPS13"

Comment 10 Lv Zheng 2017-01-05 05:42:42 UTC

(In reply to Paul Menzel from comment #9)
> Created attachment 250231 [details]
> journalctl -k
> 
> > Just a casual talk.
> > I've re-assigned several such kind of bugs to platform-specific category.
> 
> I didn’t file it in the category *x86-64* as the description talks about
> “AMD Hammer”.
> 
> > x86-64: platform_x86_64@kernel-bugs.osdl.org
> > Bugs specific to the AMD Hammer architecture.
> 
> > Some are caused by wrong OSPM GPIO usages, some are caused by WMI gaps, and
> > some are caused by lacking of platform specific device drivers.

No, it's not about AMD hammer.
I don't know what the AMD hammer is.

The ACPI category only tracks linux ACPI support code.
So if the issue is because of some required platform stuffs, they are not related to ACPI, they are underlying support for ACPI.
ACPI developers have no idea and no knowledge to handle them.
For such kind of issues, you should ask BSP developers.
As only platform developers know there is such an hardware.

So normally we reassign such bugs to platform specific hardware category.
And INTEL_VBTN, which really is such kind of problem.
ACPI developers can only help to detect the existence of such hardware via debugging AMLs.

Don't you think it's unfair to complain to the developers of something that something is not working just because other thing to run something is not working.

> Thanks to Thorsten’s suggestion, I selected INTEL_VBTN, and the system
> suspends now, when pressing the power button. Hopefully, that doesn’t
> interfere.

So no problmes, right?

> 
> Please find the output of `journalctl -k` from Linux master branch
> (4.10-rc2+) attached. Pressing the Unfortunately there are some graphical
> issues.
> 
> […]
> > If this gives too much information that can be hold by the kernel log
> buffer.
> > You can
> > 1. Use "acpi.trace_state=opcode-once
> > acpi.trace_method_name=_SB.PCI0.LPCB.ECDV._Q66" instead, of
> > 2. Add "log_buf_len=16M" or bigger.
> 
> Thanks to the systemd journal that isn’t necessary.

OK, let me close the bug.
If anything still wrong in ACPI category, feel free to re-open it.

Thanks
Lv

Comment 11 Lv Zheng 2017-01-05 06:35:28 UTC

And re-categorized this bug to platform specific hardware/i386 where INTEL_VBTN issues should be filed against.

Thanks
Lv

Comment 12 Lv Zheng 2017-01-05 07:41:58 UTC

For the log of AML debugging - "acpi.trace_state=opcode acpi.trace_method_name=_SB.PCI0.LPCB.ECDV._Q66".

I meant to use it to capture why Notify is not invoked.
That could help me to detect the existence of the platform specific hardware.

Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Method Begin [0xffff9ffa80062c63:\_SB.PCI0.LPCB.ECDV._Q66] execution.
...
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Method Begin [0xffff9ffa800635e4:\NEVT] execution.
...

NEVT is exectued here.

Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa800635fa:If] execution.
...
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa800635fa:If] execution.

The 1st If block in NEVT, it looks the result is FALSE.

Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa8006363d:If] execution.
...
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa8006363d:If] execution.

The 2nd If block in NEVT, it looks the result is FALSE.
        If (Local1 & One)
        {
            EV10 (Zero, Zero)
        }

Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80063649:If] execution.
...
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80063649:If] execution.

The 3rd If block in NEVT, it looks the result is FALSE, and EV6 is not executed.
        If (Local0 & One)
        {
            EV6 (One, Zero)
        }
This is the only possibility that can trigger KEY_POWER via the ACPI power button hardware.
So it looks your system suspending is done via INTEL_VBTN which also reports KEY_POWER to the userspace.

Local0 is read by the following code:
        Local0 = ECG1 ()
So I traced into ECG1. It passes 0x07 as Arg0 to ECR1:
            Method (ECR2, 1, NotSerialized)
            {
                Local0 = ECR1 (Arg0)
                Arg0++
                Local1 = (ECR1 (Arg0) << 0x08)
                Local0 += Local1
                Return (Local0)
            }
        Method (ECRW, 1, NotSerialized)
        {
            Return (\_SB.PCI0.LPCB.ECDV.ECR2 (Arg0))
        }
        Method (ECG1, 0, NotSerialized)
        {
            Return (ECRW (0x07))
        }
And the last bit is only related to the first ECR1, that means ECR1(0x07).

So looking into ECR1 to find result related to ECR1(0x07), it's related to EC7 EC opregion accesses:
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80062ced:If] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80062cef:LEqual] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80062cf0:Arg0] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80062cf0:Arg0] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80062cf1:ByteConst] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80062cf1:ByteConst] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80062cef:LEqual] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80062cf3:Store] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80062cf4:-NamePath-] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80062cf4:-NamePath-] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode Begin [0xffff9ffa80062cf8:Local0] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80062cf8:Local0] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80062cf3:Store] execution.
Jan 04 15:26:09 xps13 kernel:   extrace-0175 ex_trace_point        : Opcode End [0xffff9ffa80062ced:If] execution.
                If (Arg0 == 0x07)
                {
                    Local0 = EC07 /* \_SB_.PCI0.LPCB.ECDV.EC07 */
                }
We can see EC07 is read in the above log. And we couldn't see any failure from EC driver, so the result must be obtained, and it's last bit must be cleared.

However, if you still want to see more detailed execution information, you can add "dyndbg="file ec.c +p" to the boot command, to see what's returned by the EC firmware via EC driver debugging log.
IMO, there won't be problems.

In order to let the EC07 opregion returns correct value, I think there must be some platform specific configuration related.

Cheers
Lv

Comment 13 Lv Zheng 2017-07-04 01:04:36 UTC

Closing...