On Thu, 05 Jul 2018 18:02:11 +0200, Rafael J. Wysocki wrote: > > [The Lv's address is not valid any more, so drop it from the CC] > > On Thursday, July 5, 2018 5:10:20 PM CEST Rafael J. Wysocki wrote: > > On Thu, Jul 5, 2018 at 5:09 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > > On Thu, 05 Jul 2018 16:00:14 +0200, > > > Thomas H4nig wrote: > > >> > > >> Am 05.07.2018 um 14:12 schrieb Takashi Iwai: > > >> > On Thu, 05 Jul 2018 12:41:03 +0200, > > >> > Rafael J. Wysocki wrote: > > >> >> > > >> >> On Thursday, July 5, 2018 11:50:11 AM CEST Takashi Iwai wrote: > > >> >>> On Thu, 05 Jul 2018 11:34:59 +0200, > > >> >>> Rafael J. Wysocki wrote: > > >> >>>> > > >> >>>> Hi, > > >> >>>> > > >> >>>> On Thu, Jul 5, 2018 at 9:05 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > >> >>>>> Hi, > > >> >>>>> > > >> >>>>> we've got a regression report since 4.17 about the behavior of > > >> >>>>> power-off with the power button. When a machine is powered off with > > >> >>>>> the power button on desktop, it reboots after a few seconds instead of > > >> >>>>> power down. > > >> >>>>> > > >> >>>>> The manual power down via "systemctl poweroff" works fine, so it's > > >> >>>>> possibly some spurious wakeup by the power button action, and some > > >> >>>>> ACPI-related change is suspected. > > >> >>>>> The regression still remains in 4.18-rc3. > > >> >>>> > > >> >>>> There are only a few ACPI commits directly related to power management > > >> >>>> between 4.16 and 4.17 and none of them looks particularly suspicious. > > >> >>> > > >> >>> OK, interesting. > > >> >>> > > >> >>>> It looks like the power button state may not be cleared sufficiently > > >> >>>> after it's been pressed which is now visible for some reason. > > >> >>> > > >> >>> Hmm, where can such a state remain? Since it happens after the > > >> >>> machine turned off, some (ACPI) wakeup bits? > > >> >> > > >> >> Basically, yes. > > >> >> > > >> >> It looks like a GPE may remain active which then triggers wakeup after > > >> >> shutdown. > > >> >> > > >> >> On a hunch, I'm wondering if reverting commit > > >> >> > > >> >> 18996f2db918 ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume > > >> >> > > >> >> (may not revert clearly, though) makes any difference. > > >> > > > >> > OK, I'm building a 4.17.x test kernel with that revert, in OBS > > >> > home:tiwai:bsc1099930 repo. > > >> > > > >> > Thomas, could you try later the kernel in > > >> > http://download.opensuse.org/repositories/home:/tiwai:/bsc1099930/standard/ > > >> > ? It'll take an hour or so until the build finishes. > > >> > > >> With your new built kernel > > >> 4.17.4-1.g6f23755-default > > >> > > >> the power button works again, so the revert solved the problem > > > > > > Thanks, that clarifies the cause. > > > Adding Erik and Lv to Cc. > > > > > > I guess it's the side-effect by removing > > > acpi_ev_walk_gpe_list(acpi_hw_clear_gpe_block, NULL); > > > in acpi_hw_disable_all_gpes(). > > > > > > This function is called from acpi_power_off_prepare(), and the machine > > > goes to power off without clearing the GPEs, hence it's woken up later > > > unexpectedly. > > > > That's correct. > > > > We need to fix up that commit. I'll try to prepare something. > > > > Below is a patch to test that theory and maybe fix things if it is correct. > > What it does is to clear all GPEs after disabling them in > acpi_power_off_prepare() which should address the issue if our theory > about the underlying reason is correct. > > Please test. OK, building a new test kernel package in OBS home:tiwai:bsc1099930-2 repo. It'll appear at http://download.opensuse.org/repositories/home:/tiwai:/bsc1099930-2/standard/ Thomas, please give it a try later. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
