http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c2 --- Comment #2 from Hubert Mantel --- Created attachment 807207 --> http://bugzilla.suse.com/attachment.cgi?id=807207&action=edit hwinfo -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c4 Alynx Zhou changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alynx.zhou@suse.com Assignee|bnc-team-screening@forge.pr |hmacht@suse.com |ovo.novell.com | --- Comment #4 from Alynx Zhou --- Looks like an acpi issue...if not right please tell me, thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c6 --- Comment #6 from Hubert Mantel --- (In reply to Alynx Zhou from comment #4)

Looks like an acpi issue...if not right please tell me, thanks.

I'm not really sure what I should do or provide here!? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c9 --- Comment #9 from Hubert Mantel --- I now re-partitioned an additional hard disk in order to have a swap distribution of appropriate size so I can at least try hibernate instead of suspend: This works! In this case the power-off will be as fast as it was with 42.3. But I noticed that a reboot now also takes some minutes. I still can press ESC and see as last message "target shutdown reached". Then nothing happens. After approximately two minutes the system will finally reboot. And also hibernate does not work 100% correctly: After resuming, the network does no longer work. A simple "systemctl restart network" will solve this and it is less work than to re-setup the complete workspace due to the broken suspend, but this is yet another regression from 42.3. But at least I now have a workaround that mitigates those problems. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 Alynx Zhou changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|hmacht@suse.com |systemd-maintainers@suse.de -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c12 --- Comment #12 from Hubert Mantel --- (In reply to Franck Bui from comment #11)

So if you think that systemd is the culprit what about providing the journal logs (hint: journalctl -b -o short-monotonic) instead of the content of the kernel log buffer ?

I think we might see multiple issues here. Shutting down taking several minutes sounds like a systemd issue to me. I know that several other people also observed this. Not powering off the system via suspend to RAM might be a kernel issue. The network being non-functional after suspend from hibernate I do not know. And even after restarting the network manually after resume leads to virtual machines no longer being reachable. So to me it boils down to not being able to use suspend at all. This is a clear regression as it has been working for years on Leap 42.3.

Also how do you suspend your system exactly ? (I prefer asking because you seem to be reluctant to use systemd).

I do not like systemd because the developers seem to have the wrong focus. More and more functionality is being put into systemd, but the basic functionality (RELIABLY! booting the system and shutting it down) always has issues since the very beginning. I'm suspending the system by simply clicking on the mini applet in the lower right corner of the task bar in KDE. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c14 --- Comment #14 from Hubert Mantel --- (In reply to Franck Bui from comment #13)

(In reply to Hubert Mantel from comment #12)

...

I think we might see multiple issues here. Shutting down taking several minutes sounds like a systemd issue to me. I know that several other people also observed this.

Again I don't see how you came to this conclusion. In fact systemd is not involved at all when the actual suspend process starts, only the kernel is.

I still can press ESC and see messages "Target shutdown reached". Michael Calmer did some debugging on this and found some KDE process that would not exit. So finally after some minutes it seems this process gets killed and power-off finally works. But I admit that I'm somewhat biased when it comes to systemd :)

...

Not powering off the system via suspend to RAM might be a kernel issue.

The network being non-functional after suspend from hibernate I do not know. And even after restarting the network manually after resume leads to virtual machines no longer being reachable.

Unless you're using systemd-networkd, which I doubt, your network is most likely managed by either wicked or NM.

Please note that I do not know whether this is a regression! I never used hibernate before. Only after suspend-to-RAM got broken with the upgrade to 15.1 I tried it as a workaround. I added another disk (did not have a swap partition of sufficient size) and was quite happy to see that the system immediately powered off successfully! Also resume is of acceptable size, but the shutdown network makes this feature almost unusable for me :(

...

I'm suspending the system by simply clicking on the mini applet in the lower right corner of the task bar in KDE.

Can you try to suspend your system with ?

# echo -n mem >/sys/power/state

Ok, will give this a try in the evening. Do not want to do that remote as I could not judge whether it's successful :) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c16 --- Comment #16 from Franck Bui --- (In reply to Hubert Mantel from comment #14)

I still can press ESC and see messages "Target shutdown reached". Michael Calmer did some debugging on this and found some KDE process that would not exit. So finally after some minutes it seems this process gets killed and power-off finally works. But I admit that I'm somewhat biased when it comes to systemd :)

Well you know that some KDE process is preventing your system to suspend but you blame systemd for that... indeed, you're definitively biased. If you can provide the journal content as requested earlier that might be helpful. Also try to boot with the "multi-user.target" as the default one [1] (ie KDE and X is not started at all) and see if the suspend to RAM works better so we can figure out if the problem is really due to KDE or not. [1] Booting with runlevel 3 should do that as it did in the old good days. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c18 --- Comment #18 from Hubert Mantel --- (In reply to Franck Bui from comment #16)

(In reply to Hubert Mantel from comment #14)

...

I still can press ESC and see messages "Target shutdown reached". Michael Calmer did some debugging on this and found some KDE process that would not exit. So finally after some minutes it seems this process gets killed and power-off finally works. But I admit that I'm somewhat biased when it comes to systemd :)

Well you know that some KDE process is preventing your system to suspend but you blame systemd for that... indeed, you're definitively biased.

No, I know that this was the case for somebody else. Might be the same for me. But even if there still is some process, I expect such a process to get KILLED in a timely manner. Similar issues also were present at sysvinit times. But the reliable sysvinit would send a signal to every process. If some process refused to terminate, it would simply get killed. Maybe systemd also is doing this, but only after very, very long timeouts. And I have the impression that such timeouts even seem to accumulate, as I have seen reboots taking many minutes.

If you can provide the journal content as requested earlier that might be helpful.

Will do in the evening. I'm in the office right now.

Also try to boot with the "multi-user.target" as the default one [1] (ie KDE and X is not started at all) and see if the suspend to RAM works better so we can figure out if the problem is really due to KDE or not.

In the weekend I initiated a suspend to RAM and let it sit in this stage for the whole night just to check if there are many timeouts that just delay the power-off. Unfortunately the next day the power LED was still on and the fans still running.

[1] Booting with runlevel 3 should do that as it did in the old good days.

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c20 --- Comment #20 from Hubert Mantel --- Created attachment 809894 --> http://bugzilla.suse.com/attachment.cgi?id=809894&action=edit journalctl -b -o short-monotonic -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c22 --- Comment #22 from Franck Bui --- Also the content of /sys/kernel/debug/suspend_stats might be interesting. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c24 --- Comment #24 from Hubert Mantel --- (In reply to Franck Bui from comment #22)

Also the content of /sys/kernel/debug/suspend_stats might be interesting.

This is on my system at home that is failing: Terra:~ # cat /sys/kernel/debug/suspend_stats success: 0 fail: 3 failed_freeze: 0 failed_prepare: 0 failed_suspend: 0 failed_suspend_late: 0 failed_suspend_noirq: 0 failed_resume: 0 failed_resume_early: 0 failed_resume_noirq: 0 failures: last_failed_dev: last_failed_errno: -16 -16 last_failed_step: For comparison my workstation in the office: Mandelbrot:~ # cat /sys/kernel/debug/suspend_stats success: 2 fail: 0 failed_freeze: 0 failed_prepare: 0 failed_suspend: 0 failed_suspend_late: 0 failed_suspend_noirq: 0 failed_resume: 0 failed_resume_early: 0 failed_resume_noirq: 0 failures: last_failed_dev: last_failed_errno: 0 0 last_failed_step: So many new, interesting stuff in the kernel nowadays :) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c26 --- Comment #26 from Franck Bui --- First thing I would check would be the version of the firmware currently installed and make sure I run the latest one. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c28 --- Comment #28 from Hubert Mantel --- (In reply to Franck Bui from comment #26)

First thing I would check would be the version of the firmware currently installed and make sure I run the latest one.

Ok, just checked and I'm already running the latest one. I have installed version F22 which is the most recent one according to: https://www.gigabyte.com/de/Motherboard/GA-Z77-D3H-rev-10/support#support-dl... There is only one more recent (released only two months later) but F23b is still tagged as beta version. I'm usually always installing updates as soon as they are released, so this system has run more or less every kernel that ever was released for 42.3 and all of them have been working fine. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c30 --- Comment #30 from Hubert Mantel --- (In reply to Takashi Iwai from comment #29)

The original issue seems to be some spurious wakeup immediately after the suspend. e.g. the dmesg in comment 1 shows:

[ 813.684339] ACPI: Preparing to enter system sleep state S3 [ 813.684637] PM: Saving platform NVS memory [ 813.684645] Disabling non-boot CPUs ... ..... [ 813.718652] ACPI: Waking up from system sleep state S3 .....

But in this case the system should come up completely again, no? If I try to suspend to RAM, the system *seems* to shut down correctly. Display goes off and I can even hear the hard disk spin down. It is just that power is not switched off (board fans continue to run and power LED stays lid). Only after pressing some key the system will come up again in full. Btw, this works perfectly fine, network still is up correctly.

It's possibly a BIOS bug that surfaced on the recent system by some reason (likely ACPI code changes that take effect).

Well, unfortunately there is no newer BIOS version available.

Check /proc/acpi/wakeup contents and try to disable the unnecessary wakeup sources.

How do I identify an "unnecessary wakeup source" and how do I remove it? Sorry, I'm a mere mortal user in this respect :) mantel@Terra:~ [0]> cat /proc/acpi/wakeup Device S-state Status Sysfs node PS2K S3 *enabled pnp:00:05 PS2M S3 *disabled P0P1 S4 *disabled USB1 S3 *disabled USB2 S3 *disabled USB3 S3 *disabled USB4 S3 *disabled USB5 S3 *disabled USB6 S3 *disabled USB7 S3 *disabled RP01 S4 *disabled pci:0000:00:1c.0 PXSX S4 *disabled RP02 S4 *disabled PXSX S4 *disabled RP03 S4 *disabled PXSX S4 *disabled RP04 S4 *disabled PXSX S4 *disabled RP05 S4 *disabled PXSX S4 *disabled RP06 S4 *disabled pci:0000:00:1c.5 PXSX S4 *disabled pci:0000:02:00.0 RP07 S4 *disabled pci:0000:00:1c.6 PXSX S4 *disabled pci:0000:04:00.0 RP08 S4 *disabled pci:0000:00:1c.7 PXSX S4 *enabled pci:0000:05:00.0 PEG0 S4 *disabled PEGP S4 *disabled PEG1 S4 *disabled PEG2 S4 *disabled PEG3 S4 *disabled GLAN S4 *disabled EHC1 S4 *enabled pci:0000:00:1d.0 EHC2 S4 *enabled pci:0000:00:1a.0 XHC S4 *enabled pci:0000:00:14.0 HDEF S4 *disabled pci:0000:00:1b.0 PWRB S3 *enabled platform:PNP0C0C:00 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c32 --- Comment #32 from Hubert Mantel --- (In reply to Takashi Iwai from comment #31)

You can simply write the ACPI PNP ID to disable. For example, echo -n 'PS2K' > /proc/acpi/wakeup will disable the first entry, supposedly the wakeup by PS2 keyboard.

Unfortunately this does not help. I disabled everything I could, but behaviour is unchanged. For some reason I cannot disable it for "PXSX": Terra:~ # echo -n 'PXSX' > /proc/acpi/wakeup Terra:~ # cat /proc/acpi/wakeup Device S-state Status Sysfs node PS2K S3 *disabled pnp:00:05 PS2M S3 *disabled P0P1 S4 *disabled USB1 S3 *disabled USB2 S3 *disabled USB3 S3 *disabled USB4 S3 *disabled USB5 S3 *disabled USB6 S3 *disabled USB7 S3 *disabled RP01 S4 *disabled pci:0000:00:1c.0 PXSX S4 *disabled RP02 S4 *disabled PXSX S4 *disabled RP03 S4 *disabled PXSX S4 *disabled RP04 S4 *disabled PXSX S4 *disabled RP05 S4 *disabled PXSX S4 *disabled RP06 S4 *disabled pci:0000:00:1c.5 PXSX S4 *disabled pci:0000:02:00.0 RP07 S4 *disabled pci:0000:00:1c.6 PXSX S4 *disabled pci:0000:04:00.0 RP08 S4 *disabled pci:0000:00:1c.7 PXSX S4 *enabled pci:0000:05:00.0 PEG0 S4 *disabled PEGP S4 *disabled PEG1 S4 *disabled PEG2 S4 *disabled PEG3 S4 *disabled GLAN S4 *disabled EHC1 S4 *disabled pci:0000:00:1d.0 EHC2 S4 *disabled pci:0000:00:1a.0 XHC S4 *disabled pci:0000:00:14.0 HDEF S4 *disabled pci:0000:00:1b.0 PWRB S3 *disabled platform:PNP0C0C:00 Terra:~ # -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c34 --- Comment #34 from Hubert Mantel --- (In reply to Takashi Iwai from comment #33)

Then could you give kernel messages with suspend/resume with ACPI waekup disablement? At best, boot with no_console_suspend option so that we see more details what's going on.

Ok, finally found the time to test this. There is no difference in behavior; even the monitor still goes off despite parameter "no_console_suspend". -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c36 --- Comment #36 from Hubert Mantel --- Just tested with the latest tumbleweed kernel, but with this one things are even worse: Suspend to RAM still does not work (exactly same behavior), but with the newer kernel, even rebooting the system does no longer work. It will print something like "Reached target shutdown" and that's all. Need to power cycle. Went back to the latest kernel from Leap 15.1. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c58 --- Comment #58 from Hubert Mantel --- Created attachment 817859 --> http://bugzilla.suse.com/attachment.cgi?id=817859&action=edit Kernel config of working Ecosia kernel -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c61 --- Comment #61 from Hubert Mantel --- (In reply to Theo Luning from comment #59)

Suspend-to-RAM works perfectly on Mageia, but hibernate does not resume the session :-(

Did this work for you on leap 42.3? I have to admit that I never tested this. Since suspend to RAM was working perfectly for years, I never felt the need to hibernate. So would be interesting to know whether this is also a regression. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c68 --- Comment #68 from Hubert Mantel --- (In reply to Hubert Mantel from comment #67)

Seems we are seeing a bug in the 4.x series of the kernel that is no longer present with 5.x. So there is some hope :)

Unfortunately there still seems to be an issue with the SUSE Kernel. For testing purposes I had a newer SUSE Kernel kernel-default-5.3.8-6.1.g98ead79.x86_64.rpm running on my VDR system where it was needed because of newer drivers. This seems to have worked fine for several days, so I finally tried it on my problematic workstation. But it is even worse: When I try to suspend to RAM, the screen will turn black and the kernel seems to panic: The keyboard LEDs are just blinking and I cannot resume the system. Needed to press the power button. I think I will try to get the Mageia kernel sources and compile them for my system as this one works perfectly for me. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c72 --- Comment #72 from Takashi Iwai --- Oh, please don't be confused about "support". Distros would take care of a fix for a known regression IFF it's addressed in the upstream (or in the subsystem) in general. But, the other way round -- if the distro kernel happens to work while the same latest upstream (equivalent with TW or Fedora kernel) is broken -- it means something casually working without knowing what, and it's not because it's well "supported". IOW, if TW kernel doesn't work, you shall hit the same problem sooner or later in every distro unless it's fixed in the upstream at first. So driving the problem resolution for the upstream forward is the recommended way. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c74 --- Comment #74 from Takashi Iwai --- Then please try TW kernel on your current Leap 15.1 system. If this doesn't work, it's an upstream problem, per definition, since TW kernel is merely the latest stable kernel plus just a few known fixes (and kernel packaging adaption). (BTW, testing TW kernel is often the very first thing to try; it confirms whether it's an upstream problem or not. So, if you encounter such a kernel problem at the next time, please remember to try this option.) Also, if the direct S2RAM invocation via sysfs (echo mem > /sys/power/state) doesn't work, it's basically an issue only about the kernel. Reducing the test scenario like this is often helpful, too. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c76 --- Comment #76 from Takashi Iwai --- Again, there is no such "SUSE-specific" if it happens with TW kernel. (I guess you tested by echoing to sysfs, right?) It can be a bug triggered by some kernel configuration combo SUSE is currently using, but it's not SUSE-specific, per se. No matter what it's called, if the problem is seen with 5.5 kernel, it's better to be handled in the upstream, instead of sticking here. BTW, if this used to work with the old SUSE kernels, you can try my kernel archive, OBS home:tiwai:kernel:* repos. For example, OBS home:tiwai:kernel:4.9 repo contains the last 4.9.y kernel TW used: http://download.opensuse.org/repositories/home:/tiwai:/kernel:/4.9/standard/ This might help narrowing down a regression range. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c78 --- Comment #78 from Hubert Mantel --- (In reply to Takashi Iwai from comment #77)

BTW, one more thing that came to my mind. There is a known issue in XHCI that can trigger spurious wakeups at suspend or shutdown, and the workaround is applied only to limited platforms. For testing that, - Disable ACPI wakeups in /proc/acpi/wakeup, and

How to do that? Or is this a typo and you mean this: XHC S0 *enabled pci:0000:00:14.0

- Boot with xhci_hcd.quirks=0x42000 option.

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c80 --- Comment #80 from Theo Luning --- @Takashi Iwai: Thank you. Maybe there is a better word for "Suse-specific", I am not an expert. As a user, I can only say that all distributions I have tested lately turn off my fan when I suspend the machine. There are different Kernels involved: Fedora 31: Kernel 5.3 Mageia 7: Kernel 5.1. Debian 10: Kernel 4.19 While Tumbleweeed and Leap 15.1 do not turn off the fan, whether the Kernel is 4.9 (tiwai), 4.12 or 5.5 echo mem > /sys/power/state says: Translated from german: Write error: device or resource is busy (occupied?) Testing xhci_hcd.quirks later. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c82 --- Comment #82 from Theo Luning --- xhci_hcd.quirks does not change anything here. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c84 --- Comment #84 from Theo Luning ---

Is this after once you tested S2RAM and failed?

No, it was directly after startup.

BTW, did Leap 42.3 work on your system in the past?

Yes, and it still does on the same machine (dual boot).

If yes, you can install the old Leap 42.3 kernel on the new system, just for testing the suspend, too.

Hmm, can i add the old 42.3 repository to 15.1 and install via Yast? Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c86 --- Comment #86 from Theo Luning --- I have now 4.4.76-1-default on Leap 15.1, but it's still the same. I don't think it's a problem of the kernel. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c90 --- Comment #90 from Takashi Iwai --- (In reply to Theo Luning from comment #89)

@Takashi Iwai

On 42.3 echo mem > /sys/power/state works perfectly.

OK, but still 42.3 kernel wakes up after S3 spuriously, right? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c96 --- Comment #96 from Takashi Iwai --- (In reply to Theo Luning from comment #95)

...

.. it means either the boot option or the setup afterward influences on the suspend behavior. A possible cause is e.g. power-save setup or module configuration, too. It's still a kernel bug, though -- the system should have worked no matter which setup is done.

Well, It was a standard installation via Yast. I didn't do anyhing special.

What can I change about power-save setup or module configuration and how?

It's my question -- what's the difference since Leap 42.3 in the user-space side. For the power-saving, you may install powertop package, and run "powertop --auto" as root once after boot. This will automatically turn on the power-saving features in many areas. This would be the easiest test. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1137748 http://bugzilla.suse.com/show_bug.cgi?id=1137748#c98 --- Comment #98 from Theo Luning --- @Takashi Iwai I've tried powertop auto-tune. It did not improve the suspend-situation, but disabled my USB-Mouse. I've installed the kernel from home:tiwai:bsc1137748-ecosia-config but it still does not fully suspend. CPU Fan keeps running. No improvement. I'm curious if it helps Hubert. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1137748 https://bugzilla.suse.com/show_bug.cgi?id=1137748#c125 --- Comment #125 from Hubert Mantel --- Already tried this, but does not help. It is definitely a regression created by SUSE. It has been working fine up to Leap42.3. Problem started with 15.1 and still exists as of 15.2. Every other distribution is working correctly. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1137748 https://bugzilla.suse.com/show_bug.cgi?id=1137748#c127 --- Comment #127 from Frank Krüger --- (In reply to Hubert Mantel from comment #125)

Already tried this, but does not help.

It is definitely a regression created by SUSE. It has been working fine up to Leap42.3. Problem started with 15.1 and still exists as of 15.2. Every other distribution is working correctly.

I presume that your using KDE. For the sake of curiosity, could you please try to suspend before you login to the KDE session (e.g. via the desktop display manager or some shortcut)? I have one machine with Leap 15.2 where this works, but after login it does not (while 'systemctl suspend' etc. works fine). -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1137748 https://bugzilla.suse.com/show_bug.cgi?id=1137748#c129 --- Comment #129 from Hubert Mantel --- (In reply to Frank Krüger from comment #127)

I presume that your using KDE. For the sake of curiosity, could you please try to suspend before you login to the KDE session (e.g. via the desktop display manager or some shortcut)? I have one machine with Leap 15.2 where this works, but after login it does not (while 'systemctl suspend' etc. works fine).

I already tried and just confirmed it: Even when trying to suspend before logging in I still see the same behaviour: Machine seems to suspend, monitor turns black, but fans and disks keep running. Exactly the same when trying to suspend from command line via "systemctl suspend". Btw, this still is with 15.1 I also installed 15.2 into a virtual machine and it seems something is fishy here as well, because I cannot shut down the system from the respective KDE menu either. Again I could not find anything in the logs that would help... -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1137748 https://bugzilla.suse.com/show_bug.cgi?id=1137748#c130 --- Comment #130 from Hubert Mantel ---

From my point of view, this bug can be closed as WONTFIX or WORKSFORME.

So sad... -- You are receiving this mail because: You are on the CC list for the bug.