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 ```
Created attachment 248331 [details] journalctl -k
Created attachment 248341 [details] acpidump
(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
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
(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.
(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
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
(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
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"
(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
And re-categorized this bug to platform specific hardware/i386 where INTEL_VBTN issues should be filed against. Thanks Lv
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
Closing...