After installing and booting kernel 5.2.0-2 everything seems to be running OK
until I try to shutdown or suspend the machine, either via the UI's shutdown
options or via command-line. What happens then is:

- Trying to shutdown or reboot: the system enters the normal shutdown sequence,
closes all running programs and services normally, completes the shutdown
sequence and shows the message "Reached power-off" or "Reached reboot" and
stops there, never actually powering off nor rebooting the machine. In order to
complete the action, I need to press the power button for about 10 seconds
until the BIOS cuts the power and then press again to restart.

- Trying to suspend: The suspend sequence normally shows no progress messages,
and even if it did what I normally do is close the lid and Gnome triggers a
suspend to RAM. This laptop has a LED (a Lenovo thinklight) that shows the
power state. On previous kernels, a couple of seconds after ordering the
suspend action, this LED changes from solid on (which indicates the system is
running) to a slow blink, which indicates the machine is a suspended state.
With kernel 5.2.0 it seems that the suspend sequence is initiated, but instead
of the slow blink the LED start to flash rapidly (which indicates that the
system is entering hibernation state),and stays in that state. The machine does
not respond to wakeup events, and I need to force a shutdown via long-pressing
the power button.


This started happening with the first installation of a 5.x kernel. If I reboot
the system with a current 4.x kernel (4.19.0-5 as of now), everything works OK.

My guess is that the kernel is not issuing the correct orders to the BIOS in
order to complete those actions. Either the new 5.x kernel series has changed
the power management strategy in some way breaking those calls to the BIOS,
which would be an upstream error, or is relying in a new software package which
is not normally installed in a 4.x-based system such as buster to complete
those calls, which will lead to this problem when the user wants to upgrade to
testing/unstable or when 5.x reaches stable.

Does this still happen if you remove the bbswitch module?

Ben.

Hi,

Yes, I removed bumblebee and all packages related, and the problem
persists. I also removed virtualbox and all vbox* modules so I got back to
an untainted kernel, and the problem persists.

Hi,

I am having this same problem with my Lenovo ThinkPad S5 Laptop.

Please let me know if there is anything I can share that may help.

Regards
Marc

I spent the day building kernels ...

Power off working with kernel v5.2-rc5 and not working with v5.2-rc4.

The power shutdown appears to work as normal after this commit.

f9482dabfd1686987cc6044e06ae0e4c05915518 is the first bad commit
commit f9482dabfd1686987cc6044e06ae0e4c05915518
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Jun 5 14:44:07 2019 +0200

    Revert "HID: core: Call request_module before doing device_add"

    This reverts commit a025a18fecd4429f4ca66b1746001263c052ecbb.

    This patch and 4ceabaf79 are giving extended timeouts
    on boot for at least Ubuntu and openSUSE.

    Revert them until we get a better fix.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=203741
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

 drivers/hid/hid-core.c | 8 --------
 1 file changed, 8 deletions(-)

close 939606 5.2.6-1
thanks