http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c1 Rick Opper changed: What |Removed |Added ---------------------------------------------------------------------------- OS|Other |SUSE Other Severity|Normal |Major --- Comment #1 from Rick Opper --- Actually, it won't suspend at all... If I use the power button on the status menu it looks like it's going to suspend - screen shuts off, but then the caps lock light starts flashing and the system never actually stops. It crashes when I try to bring it back up. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c3 --- Comment #3 from Rick Opper --- ok... so 'systemctl suspend' failed with the same results, so it must be a kernel issue then, so now what? If it helps, the system seems to stop, but not really suspend the computer. It's a HP notebook, and the big HP logo on the lid stays lit up and so do the keys (volume mute, wifi, shift lock). The shift lock light flashes at different speeds. Before, the power status light on the side would blink while the computer was suspended. now it doesn't... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c5 --- Comment #5 from Rick Opper --- ok, well before I change my grub config and reboot, I checked uname and have 4.5.0-2-default but zypper se -v says I have the 4.5 default kernel installed and the 3.19 desktop kernel installed... shouldn't uname say what's being used regardless of what else is installed? would it be easier (less of a risk) to just upgrade the desktop kernel? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 Antoine Belvire changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antoine.belvire@laposte.net -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c8 --- Comment #8 from Rick Opper --- Created attachment 671654 --> http://bugzilla.opensuse.org/attachment.cgi?id=671654&action=edit hwinfo --all -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c10 --- Comment #10 from Takashi Iwai --- Try to boot with the previous 4.4.x kernel. Does the suspend work with it? Or if you don't have an old 4.4.x kernel (i.e. TW was freshly installed and containing already 4.5), install a kernel in OBS home:tiwai:kernel:4.4 repo. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c12 --- Comment #12 from Takashi Iwai --- Is this a laptop with hybrid GPUs? If so, there was a known regression in 4.5 kernel. It's been already addressed in 4.6-rc and backported. So, try OBS Kernel:stable repo at first. If this still doesn't work, try 4.4 kernel in my repo. In that case, just grab the rpm from the download directory, and install it locally via zypper in --oldpackage kernel-4.4*.rpm and just break the dependency. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c14 --- Comment #14 from Takashi Iwai --- (In reply to Rick Opper from comment #13)

(In reply to Takashi Iwai from comment #12)

...

Is this a laptop with hybrid GPUs?

Yes... ATI/Intel

If so, there was a known regression in

...

4.5 kernel. It's been already addressed in 4.6-rc and backported. So, try OBS Kernel:stable repo at first.

Done. systemctl suspend works fine with the backported kernel. But still noting when I close the lid.

Is it just nothing, or is the suspend failing? i.e. do you see any suspend-related messages at lid close? In doubt, you can create a file /usr/lib/systemd/system-sleep/log.sleep containing: #!/bin/sh echo $* >> /tmp/suspend.log date >> /tmp/suspend.log ... and run "chmod +x /usr/lib/systemd/system-sleep/log.sleep" Then this will log /tmp/suspend.log at each sleep action via systemd. Check whether it's logged at lid close.

...

If this still doesn't work, try 4.4 kernel in my repo. In that case, just grab the rpm from the download directory, and install it locally via zypper in --oldpackage kernel-4.4*.rpm and just break the dependency.

I ended up breaking the dependency anyway...

So, 4.4 kernel works as is? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c16 --- Comment #16 from Takashi Iwai --- (In reply to Rick Opper from comment #15)

...

Is it just nothing, or is the suspend failing? i.e. do you see any suspend-related messages at lid close?

In doubt, you can create a file /usr/lib/systemd/system-sleep/log.sleep containing:

#!/bin/sh echo $* >> /tmp/suspend.log date >> /tmp/suspend.log

... and run "chmod +x /usr/lib/systemd/system-sleep/log.sleep" Then this will log /tmp/suspend.log at each sleep action via systemd. Check whether it's logged at lid close.

I created the script. When I use systemctl suspend I get: pre suspend Thu Apr 7 10:20:22 CEST 2016 post suspend Thu Apr 7 10:21:03 CEST 2016

but nothing when I close the laptop lid.

OK, that answers my suspect. The suspend isn't triggered in this case. But I don't know whether it's a regression in kernel or any other place. So...

...

So, 4.4 kernel works as is? No, I didn't try the 4.4 kernel. I had to break the same dependency for the new 4.5 kernel. Something about DJlib of some sort related to IPtables. But there was a replacement for it in the official repo, so I don't know where I picked up the old module... anyway, the new kernel seems to work fine otherwise...

... could you try 4.4 kernel? We don't need the full functionality. We just need to check whether the lid close triggers the suspend with this kernel. If 4.4 kernel doesn't work, too, it's more likely a breakage in the user-space side. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c18 --- Comment #18 from Takashi Iwai --- (In reply to Rick Opper from comment #17)

(In reply to Takashi Iwai from comment #16)

...

... could you try 4.4 kernel? We don't need the full functionality. We just need to check whether the lid close triggers the suspend with this kernel.

Nope... nothing when I close the lid with the 4.4 kernel either...

...

If 4.4 kernel doesn't work, too, it's more likely a breakage in the user-space side.

So, what could be broken in the user-space side?

Supposing it's a regression, yes. The suspend at lid close ever worked before with Tumbleweed, right? Or has it never worked? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c20 --- Comment #20 from Takashi Iwai --- Aha, so the "update" was rather a big "upgrade" from Leap (or equivalent). In that case, you should check at least 4.1 kernel again before jumping to the conclusion. Try to install 4.1 kernel from OBS Kernel:openSUSE-42.1 repo, and confirm whether the lid close triggers the suspend or not. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c22 --- Comment #22 from Takashi Iwai --- (In reply to Rick Opper from comment #21)

(In reply to Takashi Iwai from comment #20)

...

Aha, so the "update" was rather a big "upgrade" from Leap (or equivalent).

In that case, you should check at least 4.1 kernel again before jumping to the conclusion. Try to install 4.1 kernel from OBS Kernel:openSUSE-42.1 repo, and confirm whether the lid close triggers the suspend or not.

Unless there's a big difference between the 42.1 version and the Tumbleweed version of the 4.1 kernel, the lid close won't do it. I already booted back into my old 4.1 kernel and suspend (sytemctl suspend) worked but not lid close. I think it's more something related to the new Gnome stack than just the kernel... Is there a big difference between the two kenels? (big enough that I need to install another kernel and reboot again)?

Yes, there are tons of changes between 4.1 and later kernels, as always :) Could you give the output of dmesg after a fresh boot of 4.4 and 4.5 kernels? We need to check whether the lid switch is detected as the input driver. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c24 --- Comment #24 from Rick Opper --- (In reply to Takashi Iwai from comment #22)

Yes, there are tons of changes between 4.1 and later kernels, as always :)

I meant between two 4.1 kernels... would the 4.1 kernel installed with Leap be different from the 4.1 kernel installed with Tumbleweed...

Could you give the output of dmesg after a fresh boot of 4.4 and 4.5 kernels? We need to check whether the lid switch is detected as the input driver.

ok... I attached the dmesg output for the 4.5 kernel and checked it... the lid switch IS in it: [ 4.865871] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0D:00/input/input3 [ 4.866974] ACPI: Lid Switch [LID] -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c26 --- Comment #26 from Rick Opper --- Created attachment 672009 --> http://bugzilla.opensuse.org/attachment.cgi?id=672009&action=edit dmesg 4.4 kernel -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c28 --- Comment #28 from Takashi Iwai --- Try to install evetest package. Then go to VT1 (ctrl-alt-F1), login as root. Try like: evtest /dev/input/event3 for various /dev/input/event* files to figure out which device corresponds to the lid switch. (You may figure it out from sysfs, too). Press Ctrl-C to break the command. Then, while running evtest with the input event device for the lid switch, close the lid. If you get the EV_SW SW_LID events, then it works in the kernel level. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c30 --- Comment #30 from Takashi Iwai --- Right, then this is no kernel issue. Just to be sure: you don't connect to an external monitor, right? When an external monitor or dock is connected, systemd and others won't handle the lid close. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c32 --- Comment #32 from Takashi Iwai --- OK. And, the suspend isn't triggered even at lid close on VT1 without GUI? The suspend at lid-close on VT is basically managed by systemd itself, and its configuration is found in /etc/systemd/logind.conf (and other files mentioned in logind.conf(5) man page). Check the configuration whether you have any special setup. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=973754 http://bugzilla.opensuse.org/show_bug.cgi?id=973754#c34 Takashi Iwai changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Basesystem Assignee|kernel-maintainers@forge.pr |bnc-team-screening@forge.pr |ovo.novell.com |ovo.novell.com Flags|needinfo?(brainstormtrooper | |@free.fr) | --- Comment #34 from Takashi Iwai --- Thanks, then let's assign it to systemd guys at first. The kernel seems passing the lid-close input event, but the rest user-space stuff doesn't seem to handle it. -- You are receiving this mail because: You are on the CC list for the bug.