Bug 1137748 - suspend to RAM no longer working after upgrade to Leap 15.1
suspend to RAM no longer working after upgrade to Leap 15.1
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Basesystem
Leap 15.1
x86-64 Linux
: P3 - Medium : Major with 2 votes (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-06-10 12:19 UTC by Hubert Mantel
Modified: 2022-11-24 07:12 UTC (History)
11 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
nestolea: needinfo? (biswarupr)


Attachments
kernel messages of affected system (79.99 KB, text/plain)
2019-06-10 12:20 UTC, Hubert Mantel
Details
hwinfo (686.28 KB, text/plain)
2019-06-10 12:20 UTC, Hubert Mantel
Details
kernel messages from suspend/resume cycle (21.97 KB, text/plain)
2019-06-22 17:12 UTC, Hubert Mantel
Details
journalctl -b -o short-monotonic (25.08 KB, text/plain)
2019-07-09 18:29 UTC, Hubert Mantel
Details
Kernel messages; boot, suspend to RAM, resume (239.18 KB, text/plain)
2019-07-21 12:39 UTC, Hubert Mantel
Details
ASUS_S2-P8H61E dmesg starting at "PM: Syncing filesystems" OpenSUSE 42.3 vs 15.1 (15.97 KB, text/plain)
2019-09-07 17:23 UTC, Theo Luning
Details
Kernel config of working Ecosia kernel (52.58 KB, application/octet-stream)
2019-09-11 16:16 UTC, Hubert Mantel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hubert Mantel 2019-06-10 12:19:53 UTC
Three days ago I updated my main workstation from 42.3 to 15.1. Went surprisingly well and after using it for some time, almost everything is working nicely.

Only annoyance: Suspend to RAM no longer works. I can hear the hard disk spin down, monitor goes off, but the power LED always stays lit and I still can hear the fans running. Waking up from this state is working just fine. But as I'm lazy I do not want to shut down the machine completely every day :) And it is a regression since it has been working like a charm with 42.3.

I also updated a laptop from 42.3 to 15.1 and on this one suspend is working just fine. So it clearly is hardware dependent. I will attach dmesg and hwinfo of the affected system and can provide additional information on request.
Comment 1 Hubert Mantel 2019-06-10 12:20:31 UTC
Created attachment 807206 [details]
kernel messages of affected system
Comment 2 Hubert Mantel 2019-06-10 12:20:53 UTC
Created attachment 807207 [details]
hwinfo
Comment 3 Hubert Mantel 2019-06-18 07:02:26 UTC
Some additional information: I also noticed that shutting down the system takes several minutes(!) meanwhile, while it was only seconds with 42.3. So I thought I might see something similar with suspend and just waited for some time after trying to suspend the system. But it did not succeed. After half an hour I finally shut down the system as it would not really power off after suspend.

Michael Andres is observing similar issues on his system, so I'm ccing him for additional information.

I'm using the updated system since more than a week now, and apart from this (major) annoyance, everything is working perfectly. But needing to shut down the system every day now is quite a regression for me. Any hint on how to debug this would be appreciated.
Comment 4 Alynx Zhou 2019-06-20 08:00:14 UTC
Looks like an acpi issue...if not right please tell me, thanks.
Comment 5 Hubert Mantel 2019-06-22 17:12:31 UTC
Created attachment 808180 [details]
kernel messages from suspend/resume cycle

These are the kernel messages for a suspend/resume cycle. System was suspended around 11:37, then I waited about two minutes, so around 11:39 the resume started. But the kernel messages are confusing:

Jun 21 11:39:21 Terra kernel: PM: Preparing system for sleep (freeze)
Jun 21 11:39:21 Terra kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Jun 21 11:39:21 Terra kernel: OOM killer disabled.
Jun 21 11:39:21 Terra kernel: Freezing remaining freezable tasks ... (elapsed 0.012 seconds) done.
Jun 21 11:39:21 Terra kernel: PM: Suspending system (freeze)

Those messages get printed during the resume, two minutes after it actually was suspended. So either the messages are bogus or something weird is going on.
Comment 6 Hubert Mantel 2019-06-22 17:13:31 UTC
(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!?
Comment 7 Alynx Zhou 2019-06-23 02:15:22 UTC
(In reply to Hubert Mantel from comment #6)
> (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!?

Thank you, but I mean that I guess this is an acpi related issue from attachments you provided, and I assign this to acpi's bugowner. The last words I say is to bugowners that if this is not a acpi issue please tell me because I have little experience to this.
Comment 9 Hubert Mantel 2019-06-25 17:34:47 UTC
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.
Comment 10 Hubert Mantel 2019-06-26 07:24:14 UTC
(In reply to Alynx Zhou from comment #4)
> Looks like an acpi issue...if not right please tell me, thanks.

I do no longer think this is an ACPI issue. The kernel apparently can power down the system just fine because it works for hibernation. But those extreme delays when powering down or rebooting the system to me sound like an indication that we are still seeing systemd issues. This toy never worked reliably for me when it comes to exotic tasks such as powering down or rebooting the system.
Comment 11 Franck Bui 2019-07-09 08:40:49 UTC
(In reply to Hubert Mantel from comment #10)
> But those
> extreme delays when powering down or rebooting the system to me sound like
> an indication that we are still seeing systemd issues. This toy never worked
> reliably for me when it comes to exotic tasks such as powering down or
> rebooting the system.

sigh...

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 ?

Also how do you suspend your system exactly ? (I prefer asking because you seem to be reluctant to use systemd).
Comment 12 Hubert Mantel 2019-07-09 08:52:00 UTC
(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.
Comment 13 Franck Bui 2019-07-09 09:09:00 UTC
(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.

> 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.

> 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.

Sure and I don't dispute that.

> 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
Comment 14 Hubert Mantel 2019-07-09 09:27:06 UTC
(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 :)
Comment 15 Franck Bui 2019-07-09 10:44:09 UTC
(In reply to Hubert Mantel from comment #14)
> 
> Please note that I do not know whether this is a regression! I never used
> hibernate before.

I think we should focus on your suspend to RAM issue in this bug. This one is likely to be another one which deserves another report.
Comment 16 Franck Bui 2019-07-09 10:52:06 UTC
(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.
Comment 17 Hubert Mantel 2019-07-09 11:36:40 UTC
(In reply to Franck Bui from comment #15)
> (In reply to Hubert Mantel from comment #14)
> > 
> > Please note that I do not know whether this is a regression! I never used
> > hibernate before.
> 
> I think we should focus on your suspend to RAM issue in this bug. This one
> is likely to be another one which deserves another report.

Agreed. This is the most important one for me anyway.
Comment 18 Hubert Mantel 2019-07-09 11:41:17 UTC
(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.
Comment 19 Hubert Mantel 2019-07-09 18:28:10 UTC
(In reply to Franck Bui from comment #13)

> Can you try to suspend your system with ?
> 
>   # echo -n mem >/sys/power/state

Terra:~ # id
uid=0(root) gid=0(root) groups=0(root)
Terra:~ # echo -n mem >/sys/power/state
-bash: echo: write error: Device or resource busy
Terra:~ #
Comment 20 Hubert Mantel 2019-07-09 18:29:01 UTC
Created attachment 809894 [details]
journalctl -b -o short-monotonic
Comment 21 Franck Bui 2019-07-10 04:50:19 UTC
(In reply to Hubert Mantel from comment #19)
> Terra:~ # echo -n mem >/sys/power/state
> -bash: echo: write error: Device or resource busy

Ok then it's definitively not due to systemd but something in the lower layer (kernel, ACPI, BIOS...).

Kernel team, could you have look ?
Comment 22 Franck Bui 2019-07-10 04:52:41 UTC
Also the content of /sys/kernel/debug/suspend_stats might be interesting.
Comment 23 Hubert Mantel 2019-07-10 06:35:00 UTC
(In reply to Franck Bui from comment #21)
> (In reply to Hubert Mantel from comment #19)
> > Terra:~ # echo -n mem >/sys/power/state
> > -bash: echo: write error: Device or resource busy
> 
> Ok then it's definitively not due to systemd but something in the lower
> layer (kernel, ACPI, BIOS...).

Ahh, great!

Btw, just tested this on my workstation in the office and there it works like a charm.
Comment 24 Hubert Mantel 2019-07-10 06:37:09 UTC
(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 :)
Comment 25 Hubert Mantel 2019-07-10 06:57:57 UTC
Maybe this is related?

Jul 10 07:01:37 Terra kernel: ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
Jul 10 07:01:37 Terra kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT4._GTF, AE_NOT_FOUND (20170303/psparse-516)
Jul 10 07:01:37 Terra kernel: ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
Jul 10 07:01:37 Terra kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT4._GTF, AE_NOT_FOUND (20170303/psparse-516)
Jul 10 07:01:37 Terra kernel: ata5.00: configured for UDMA/100
Jul 10 07:01:37 Terra kernel: ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
Jul 10 07:01:37 Terra kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT2._GTF, AE_NOT_FOUND (20170303/psparse-516)
Jul 10 07:01:37 Terra kernel: ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
Jul 10 07:01:37 Terra kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT0._GTF, AE_NOT_FOUND (20170303/psparse-516)
Jul 10 07:01:37 Terra kernel: ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
Jul 10 07:01:37 Terra kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT2._GTF, AE_NOT_FOUND (20170303/psparse-516)
Jul 10 07:01:37 Terra kernel: ata3.00: configured for UDMA/133
Jul 10 07:01:37 Terra kernel: ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
Jul 10 07:01:37 Terra kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT0._GTF, AE_NOT_FOUND (20170303/psparse-516)
Jul 10 07:01:37 Terra kernel: ata1.00: configured for UDMA/133

The system is almost 6 years old, so maybe something in the kernel has changed so this old system is no longer fully supported?
Comment 26 Franck Bui 2019-07-11 10:21:46 UTC
First thing I would check would be the version of the firmware currently installed and make sure I run the latest one.
Comment 27 Hubert Mantel 2019-07-11 11:29:42 UTC
(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.

Which firmware do you mean? The board "BIOS"?

I'm reluctant to update it. I did this back in 2013 and after that the system would no longer boot because the EFI entries had been cleared.

And with the currently running version, there were no problems at all running Leap 42.3. So the problems got introduced by some later kernel.
Comment 28 Hubert Mantel 2019-07-11 16:22:37 UTC
(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-bios

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.
Comment 29 Takashi Iwai 2019-07-15 12:10:16 UTC
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
.....

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

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

The problem in comment 19 is different, though.  Judging from the error number, it's possibly some stale state after the failed suspend or such, which blocks the further processing.
Comment 30 Hubert Mantel 2019-07-15 12:46:42 UTC
(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
Comment 31 Takashi Iwai 2019-07-15 13:01:38 UTC
(In reply to Hubert Mantel from comment #30)
> (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?

I guess systemd tries to freeze the system after that point.  The behavior your described seems matching with that, too.  But it's just a wild guess and might be wrong, though.

> > 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 :)

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.
Comment 32 Hubert Mantel 2019-07-15 15:51:54 UTC
(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:~ #
Comment 33 Takashi Iwai 2019-07-15 16:49:52 UTC
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.
Comment 34 Hubert Mantel 2019-07-21 12:38:03 UTC
(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".
Comment 35 Hubert Mantel 2019-07-21 12:39:06 UTC
Created attachment 811098 [details]
Kernel messages; boot, suspend to RAM, resume
Comment 36 Hubert Mantel 2019-08-09 10:41:47 UTC
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.
Comment 37 Theo Luning 2019-08-20 12:30:10 UTC
I have exactly the same problem here.
A dual boot installation of 42.3 and 15.1, where 42.3 suspends without problems and 15.1 does not turn off the computer and fans.
My BIOS is 7 years old, this is the latest BIOS.
Some more info here: https://forums.opensuse.org/showthread.php/537158-Incomplete-standby

System:    Host: linux-x6pk Kernel: 4.12.14-lp151.28.13-default x86_64 bits: 64 gcc: 7.4.0
           Desktop: KDE Plasma 5.12.8 (Qt 5.9.7) Distro: openSUSE Leap 15.1
Machine:   Device: desktop Mobo: ASUSTeK model: S2-P8H61E v: Rev x.0x serial: N/A
           BIOS: American Megatrends v: 3509 date: 05/03/2012
CPU:       Dual core Intel Core i3-3240 (-HT-MCP-) arch: Ivy Bridge rev.9 cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 13601
           clock speeds: max: 3400 MHz 1: 3400 MHz 2: 3400 MHz 3: 3400 MHz 4: 3400 MHz
Graphics:  Card: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller bus-ID: 00:02.0
           Display Server: x11 (X.Org 1.20.3 ) drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@60.00hz
           OpenGL: renderer: Mesa DRI Intel Ivybridge Desktop version: 4.2 Mesa 18.3.2 Direct Render: Yes
Audio:     Card Intel 6 Series/C200 Series Family High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: Advanced Linux Sound Architecture v: k4.12.14-lp151.28.13-default
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169 v: 2.3LK-NAPI port: e000 bus-ID: 03:00.0
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 750.2GB (17.2% used)
           ID-1: /dev/sda model: Samsung_SSD_850 size: 250.1GB
           ID-2: /dev/sdb model: TOSHIBA_MQ01ABF0 size: 500.1GB
Partition: ID-1: / size: 69G used: 11G (17%) fs: ext4 dev: /dev/sda4
           ID-2: swap-1 size: 8.06GB used: 0.00GB (0%) fs: swap dev: /dev/sda1
Comment 38 Hubert Mantel 2019-08-26 07:10:00 UTC
(In reply to Theo Luning from comment #37)
> I have exactly the same problem here.
> A dual boot installation of 42.3 and 15.1, where 42.3 suspends without
> problems and 15.1 does not turn off the computer and fans.
> My BIOS is 7 years old, this is the latest BIOS.

Seems Linux has adopted the habit of fully supporting only new hardware :/

> Some more info here:
> https://forums.opensuse.org/showthread.php/537158-Incomplete-standby

Thanks! Good to know I'm not the only one. Exactly the same behavior I'm seeing. And I agree: Fiddling with BIOS settings does not sound right to me, as it worked perfectly with exactly those settings with older kernels.

But thanks for the hint regarding removal of LVM to at least speed up this stuff. Probably yet another systemd "feature".
Comment 39 Frank Morawietz 2019-08-28 19:40:42 UTC
May I join here?

Updated from openSUSE Leap 42.3 via openSUSE 15.0 to 15.1 .

I have been frequently using suspend to disk and suspend to RAM with 42.3 .

Suspend to disk still works fine (even with network after wake up).
Boot and shutdown time don't show noticeable differences than before.

Suspend to RAM no longer works with openSUSE Leap 15.1 .
Screen goes to power save mode, but fans and LEDs keep running.
Can't get the system back to work with keyboard or mouse. Screen stays black.

Only by pressing the power switch I can get the system running again.

Computer is a BTO system from 2012, with an Ivy Bridge processor, too (Intel Ivy Bridge Core-i5-3570K).

I am willing to provide more details and diagnostics, but I may need some guidance.
Comment 40 Frank Morawietz 2019-08-30 18:47:22 UTC
# echo -n mem >> /sys/power/state
-bash: echo: write error: Device or resource busy

Also does not work for me. Screen goes dark for a second, then it's turned on again with full brightness, then returns to normal.
Comment 41 Frank Morawietz 2019-08-30 18:49:02 UTC
(In reply to Frank Morawietz from comment #40)
> # echo -n mem >> /sys/power/state
> -bash: echo: write error: Device or resource busy
> 
> Also does not work for me. Screen goes dark for a second, then it's turned
> on again with full brightness, then returns to normal.

# cat /sys/kernel/debug/suspend_stats
success: 0
fail: 1
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
                        0
  last_failed_step:
Comment 42 Frank Morawietz 2019-08-30 18:59:20 UTC
I also have plenty of strange ACPI messages during boot:

2019-08-30T18:57:39.554000+02:00 Saphira kernel: [    4.174213] ACPI BIOS Error (bug): 
2019-08-30T18:57:39.554001+02:00 Saphira kernel: [    4.209274] ACPI Error: 
2019-08-30T18:57:39.554004+02:00 Saphira kernel: [    4.434921] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
2019-08-30T18:57:39.554004+02:00 Saphira kernel: [    4.460315] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT2._GTF, AE_NOT_FOUND (20170303/psparse-516)
2019-08-30T18:57:39.554009+02:00 Saphira kernel: [    4.461050] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
2019-08-30T18:57:39.554009+02:00 Saphira kernel: [    4.461061] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT2._GTF, AE_NOT_FOUND (20170303/psparse-516)
2019-08-30T18:57:39.554013+02:00 Saphira kernel: [    4.467538] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
2019-08-30T18:57:39.554064+02:00 Saphira kernel: [    4.467546] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT0._GTF, AE_NOT_FOUND (20170303/psparse-516)
2019-08-30T18:57:39.554077+02:00 Saphira kernel: [    4.624977] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
2019-08-30T18:57:39.554119+02:00 Saphira kernel: [   15.488741] ACPI: Power Button [PWRB]
2019-08-30T18:57:39.554121+02:00 Saphira kernel: [   15.490595] ACPI: Power Button [PWRF]
2019-08-30T18:57:39.554122+02:00 Saphira kernel: [   15.495116] ACPI: Thermal Zone [TZ00] (28 C)
2019-08-30T18:57:39.554123+02:00 Saphira kernel: [   15.497190] ACPI: Thermal Zone [TZ01] (30 C)
2019-08-30T18:57:39.554125+02:00 Saphira kernel: [   15.760617] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20170303/utaddress-213)
2019-08-30T18:57:39.554126+02:00 Saphira kernel: [   15.761592] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
2019-08-30T18:57:39.554127+02:00 Saphira kernel: [   15.762567] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20170303/utaddress-213)
2019-08-30T18:57:39.554127+02:00 Saphira kernel: [   15.763577] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
2019-08-30T18:57:39.554157+02:00 Saphira kernel: [   15.764609] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20170303/utaddress-213)
2019-08-30T18:57:39.554160+02:00 Saphira kernel: [   15.765676] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
2019-08-30T18:57:39.554160+02:00 Saphira kernel: [   15.766750] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000051F (\LED) (20170303/utaddress-213)
2019-08-30T18:57:39.554161+02:00 Saphira kernel: [   15.767856] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20170303/utaddress-213)
2019-08-30T18:57:39.554161+02:00 Saphira kernel: [   15.768977] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

...and from the "echo -n mem >> /sys/power/state" experiment above:

2019-08-30T22:43:56.419167+02:00 Saphira kernel: [ 6403.711075] ACPI: Preparing to enter system sleep state S3
2019-08-30T22:43:56.419179+02:00 Saphira kernel: [ 6403.725424] ACPI: Waking up from system sleep state S3
2019-08-30T22:43:56.419192+02:00 Saphira kernel: [ 6404.078000] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
2019-08-30T22:43:56.419193+02:00 Saphira kernel: [ 6404.078006] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT2._GTF, AE_NOT_FOUND (20170303/psparse-516)
2019-08-30T22:43:56.419193+02:00 Saphira kernel: [ 6404.078739] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
2019-08-30T22:43:56.419194+02:00 Saphira kernel: [ 6404.078745] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT2._GTF, AE_NOT_FOUND (20170303/psparse-516)
2019-08-30T22:43:56.419195+02:00 Saphira kernel: [ 6404.083549] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
2019-08-30T22:43:56.419195+02:00 Saphira kernel: [ 6404.083555] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT0._GTF, AE_NOT_FOUND (20170303/psparse-516)
2019-08-30T22:43:56.419196+02:00 Saphira kernel: [ 6405.151873] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20170303/psargs-330)
2019-08-30T22:43:56.419196+02:00 Saphira kernel: [ 6405.151878] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT0._GTF, AE_NOT_FOUND (20170303/psparse-516)
Comment 43 Frank Morawietz 2019-08-30 19:14:53 UTC
> Check /proc/acpi/wakeup contents and try to disable the unnecessary wakeup
> sources.

I can disable everything...

# grep -v disabled /proc/acpi/wakeup
Device  S-state   Status   Sysfs node

...but it does not change the reaction. Everything exactly as in my comment #40 above.
Comment 44 Frank Morawietz 2019-08-30 19:21:53 UTC
And some more information about my system:

System:    Host: saphira Kernel: 4.12.14-lp151.28.13-default x86_64 bits: 64 gcc: 7.4.0
           Console: tty 4 Distro: openSUSE Leap 15.1
Machine:   Device: desktop System: Gigabyte product: N/A serial: N/A
           Mobo: Gigabyte model: Z77-DS3H v: x.x serial: N/A
           BIOS: American Megatrends v: F9 date: 09/19/2012
CPU:       Quad core Intel Core i5-3570K (-MCP-) arch: Ivy Bridge rev.9 cache: 6144 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 27228
           clock speeds: max: 3800 MHz 1: 3403 MHz 2: 3403 MHz 3: 3403 MHz 4: 3403 MHz
Graphics:  Card: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller
           bus-ID: 00:02.0
           Display Server: X.Org 1.20.3 drivers: intel (unloaded: modesetting,fbdev,vesa)
           Resolution: 1920x1080@60.00hz
           OpenGL: renderer: Mesa DRI Intel Ivybridge Desktop
           version: 4.2 Mesa 18.3.2 Direct Render: Yes
Network:   Card: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet
           driver: atl1c v: 1.0.1.1-NAPI port: e000 bus-ID: 02:00.0
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 2000.4GB (11.8% used)
           ID-1: model: WDC_WD20EARX
Comment 45 Theo Luning 2019-09-07 16:55:14 UTC
> Suspend to RAM no longer works with openSUSE Leap 15.1 .
> Screen goes to power save mode, but fans and LEDs keep running.
> Can't get the system back to work with keyboard or mouse. Screen stays black.

Do you have an USB keyboard?
I've found out that only a PS/2 keyboard can get the system to resume.
A USB keyboard does not work here.
So this makes probably no difference between our systems.
Comment 46 Theo Luning 2019-09-07 17:23:54 UTC
Created attachment 817302 [details]
ASUS_S2-P8H61E dmesg starting at "PM: Syncing filesystems" OpenSUSE 42.3 vs 15.1

This file shows the differences in "dmesg" from the perfectly working (suspend to RAM) OpenSUSE 42.3 to the not completely "suspending" OpenSUSE 15.1 on the same machine (dual boot).
Comment 47 Hubert Mantel 2019-09-09 09:21:58 UTC
(In reply to Theo Luning from comment #45)
> > Suspend to RAM no longer works with openSUSE Leap 15.1 .
> > Screen goes to power save mode, but fans and LEDs keep running.
> > Can't get the system back to work with keyboard or mouse. Screen stays black.
> 
> Do you have an USB keyboard?
> I've found out that only a PS/2 keyboard can get the system to resume.
> A USB keyboard does not work here.
> So this makes probably no difference between our systems.

FWIW, I do have an USB keyboard and it is working fine. Both in 42.3 and also in 15.1 I can successfully resume the system both after suspend to RAM and after suspend to disk. However with 15.1 this is not yet definitive as the system does not really suspend to RAM.
Comment 48 Theo Luning 2019-09-09 12:29:05 UTC
I've upgraded the kernel to kernel-default-5.3 from here:
http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/

But I have the same problem as with Kernel 4.12.

Then I've tried Mageia-7.1-Live-Plasma-x86_64 (Kernel 5.1) to see if it's a general Problem with the newer Kernels.
But Mageia 7.1 works like a charm (Suspend to RAM and resume).

Still hoping for a fix. I am using openSUSE/SUSE Linux since Version 5. :-)
OTOH I really would like to able to "suspend-to-RAM".
Comment 49 Hubert Mantel 2019-09-09 12:46:00 UTC
(In reply to Theo Luning from comment #48)
> I've upgraded the kernel to kernel-default-5.3 from here:
> http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/
> 
> But I have the same problem as with Kernel 4.12.
> 
> Then I've tried Mageia-7.1-Live-Plasma-x86_64 (Kernel 5.1) to see if it's a
> general Problem with the newer Kernels.
> But Mageia 7.1 works like a charm (Suspend to RAM and resume).

Thanks for the hint! I will give it a try.

> Still hoping for a fix. I am using openSUSE/SUSE Linux since Version 5. :-)
> OTOH I really would like to able to "suspend-to-RAM".

Same here. I already had to destroy virtual machines several times because I forgot to shut them down before hibernate and cannot access them after resume.
Comment 50 Frank Morawietz 2019-09-10 19:19:27 UTC
(In reply to Theo Luning from comment #45)
> > Suspend to RAM no longer works with openSUSE Leap 15.1 .
> > Screen goes to power save mode, but fans and LEDs keep running.
> > Can't get the system back to work with keyboard or mouse. Screen stays black.
> 
> Do you have an USB keyboard?
> I've found out that only a PS/2 keyboard can get the system to resume.
> A USB keyboard does not work here.
> So this makes probably no difference between our systems.

You are right, I do have an USB keyboard.
But with Leap 42.3 it brought the suspended to RAM system back to life immediately with the first key pressed. Now it only returns to action with the power button.
That's no big issue for me. But what bothers me is that it does not really suspend to RAM. I can hear fans and disk still running. LEDs keep lit. Only the screen goes dark.

Regarding wake up by keyboard in general, some power management settings in BIOS might also play a role here.
Comment 51 Frank Morawietz 2019-09-10 19:38:15 UTC
I checked for BIOS updates for my mainboard.
(In reply to Hubert Mantel from comment #28)
> (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-
> bios
> 
> There is only one more recent (released only two months later) but F23b is
> still tagged as beta version.

Interesting: It seems that we are running similar mainboards. I have a Gigabyte Z77-DS3H (additional S between D and 3).

I checked for BIOS updates for my mainboard, too.
According to
https://www.gigabyte.com/de/Motherboard/GA-Z77-DS3H-rev-10/support#support-dl-bios
I am running the latest supported version. But there are two newer versions available marked as beta.

I gave the latest version a try and updated my BIOS with the F11a beta.

Did not change anything for Leap 15.1 . But my dual boot Windows installation then was no longer able to suspend to disk.
So with the newer beta BIOS I now have Windows with suspend to disk not working and Linux with suspend to RAM not working.   :-(

I think I will downgrade my BIOS again to the last supported version.
Comment 52 Frank Morawietz 2019-09-10 19:42:57 UTC
I noticed that there is an acpid (Advanced Configuration and Power Interface event daemon) available.

Can this daemon possibly help us here?
Comment 53 Hubert Mantel 2019-09-11 08:42:00 UTC
(In reply to Frank Morawietz from comment #51)

> Interesting: It seems that we are running similar mainboards. I have a
> Gigabyte Z77-DS3H (additional S between D and 3).
> 
> I checked for BIOS updates for my mainboard, too.
> According to
> https://www.gigabyte.com/de/Motherboard/GA-Z77-DS3H-rev-10/support#support-
> dl-bios
> I am running the latest supported version. But there are two newer versions
> available marked as beta.
> 
> I gave the latest version a try and updated my BIOS with the F11a beta.
> 
> Did not change anything for Leap 15.1 . But my dual boot Windows
> installation then was no longer able to suspend to disk.
> So with the newer beta BIOS I now have Windows with suspend to disk not
> working and Linux with suspend to RAM not working.   :-(
> 
> I think I will downgrade my BIOS again to the last supported version.

Yep :)

I think fiddling with the BIOS is not the correct approach anyway. I mean, it was working perfectly with an older version and it seems to be working with other distros with a newer kernel (will verify on my system this weekend with ecosia).
Comment 54 Hubert Mantel 2019-09-11 08:43:35 UTC
(In reply to Frank Morawietz from comment #52)
> I noticed that there is an acpid (Advanced Configuration and Power Interface
> event daemon) available.
> 
> Can this daemon possibly help us here?

Just for fun I installed this package already weeks ago. Did not change anything.
Comment 55 Takashi Iwai 2019-09-11 08:44:38 UTC
If other distro's kernel works (even though it's new enough), could you get the kernel config of such kernel?  Then we can try to build a kernel with the similar configuration, too.
Comment 56 Hubert Mantel 2019-09-11 09:10:47 UTC
(In reply to Takashi Iwai from comment #55)
> If other distro's kernel works (even though it's new enough), could you get
> the kernel config of such kernel?  Then we can try to build a kernel with
> the similar configuration, too.

Will do so on the weekend. I hope it provides /proc/config.gz ...

Did the kernel configuration regarding ACPI change between leap 42.3 and 15.1 ? Or are there SUSE-specific patches?
Comment 57 Takashi Iwai 2019-09-11 09:16:54 UTC
Yes, we've got a lot of ACPI backports from upstream on Leap 15.1.  But this kind of bug might be related with something else, too.

In anyway, if we have a working reference of the recent upstream with the configuration, it'd be a good hint.
Comment 58 Hubert Mantel 2019-09-11 16:16:02 UTC
Created attachment 817859 [details]
Kernel config of working Ecosia kernel
Comment 59 Theo Luning 2019-09-11 16:17:14 UTC
(In reply to Takashi Iwai from comment #55)
> If other distro's kernel works (even though it's new enough), could you get
> the kernel config of such kernel?  Then we can try to build a kernel with
> the similar configuration, too.

Here is a diff of /proc/config.gz from Mageia 7.1 (vs. OpenSUSE Leap 15.1 Linux 4.12.14-lp151.28.13-default (x86_64)).
http://theowp.bplaced.net/upload/config_mageia7_1.zip

Suspend-to-RAM works perfectly on Mageia, but hibernate does not resume the session :-(
Comment 60 Hubert Mantel 2019-09-11 16:18:13 UTC
Just gave the Ecosia live system a try and it works like a charm. I click on "suspend" and two seconds later the system is suspended. Resume also works fine. I should note that this kernel also prints the same error messages during boot as described in comment#25. Of course I did not check if they are 100% identical, but it looks very similar. I uploaded the kernel config of the ecosia kernel.
Comment 61 Hubert Mantel 2019-09-11 16:20:04 UTC
(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.
Comment 62 Theo Luning 2019-09-11 16:44:07 UTC
(In reply to Hubert Mantel from comment #61)
> (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.

Hibernate and "hybrid sleep" work perfectly here also on OpenSUSE 15.1.
My problem is only with Suspend-to-RAM.
I know it is strange...
Comment 63 Frank Morawietz 2019-09-11 19:40:17 UTC
(In reply to Hubert Mantel from comment #54)
> (In reply to Frank Morawietz from comment #52)
> > I noticed that there is an acpid (Advanced Configuration and Power Interface
> > event daemon) available.
> > 
> > Can this daemon possibly help us here?
> 
> Just for fun I installed this package already weeks ago. Did not change
> anything.

Same with me. But the default configuration is nearly empty. I assume one has to create some configuration entries to make anything happen. Unfortunately I have no idea currently..
Comment 64 Theo Luning 2019-09-11 20:26:29 UTC
> .. on Mageia, but hibernate does not resume the
> session :-(

That was my fault. I mistakenly configured a resume partition on device sdb.
Hibernate and Suspend-to-RAM work perfectly on Mageia 7.1 when resume is the swap partition of sda.
Comment 65 Hubert Mantel 2019-10-11 17:21:14 UTC
Just gave the latest kernel-vanilla a try and it is also broken. There is one tiny difference, though: At least rebooting the system works much better than with the default kernel. No waiting for several minutes after "target shutdown reached", but this is probably unrelated.
Comment 66 Theo Luning 2019-10-18 16:18:15 UTC
@Hubert Mantel: I don't think it has to do with the kernel (vanilla) directly.

I'm running Kernel 5.3.6 on Mageia now, and it still works like a charm.
Comment 67 Hubert Mantel 2019-10-21 09:42:41 UTC
(In reply to Theo Luning from comment #66)
> @Hubert Mantel: I don't think it has to do with the kernel (vanilla)
> directly.
> 
> I'm running Kernel 5.3.6 on Mageia now, and it still works like a charm.

Oh sorry, seems I was unclear: Leap 15.1 is using kernel 4.12.x and I tested vanilla kernel 4.12.x so we only know the breakage was not introduced by some SUSE patch.

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 :)

So probably it is not worthwhile hoping to get this fixed for an outdated kernel. Especially when it is not fatal (while still very annoying) and only affects a very limited number of systems. I have five systems running leap 15.1 and only a single one (unfortunately the most important one - Murphy was an optimist) is affected :/

So FPOV this bug can be closed as "LATER" or "WORKSFORME".
Comment 68 Hubert Mantel 2019-11-09 10:17:13 UTC
(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.
Comment 69 Ian Jones 2019-12-23 10:31:28 UTC
I am experiencing something similar. I experienced it also on 15.0. I upgraded to 15.1 to try to solve it. Suspend often fails but not always. These errors are in the journal:

Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: Suspending system (mem)
Suspending console(s) (use no_console_suspend to debug)
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
xhci_hcd 0000:06:00.0: WARN: xHC CMD_RUN timeout
suspend_common(): xhci_pci_suspend+0x0/0xd0 [xhci_pci] returns -110
pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 [usbcore] returns -110
dpm_run_callback(): pci_pm_suspend+0x0/0x130 returns -110
PM: Device 0000:06:00.0 failed to suspend async: error -110
PM: Some devices failed to suspend, or early wake event detected
sd 0:0:0:0: [sda] Starting disk
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata5: SATA link down (SStatus 0 SControl 300)
ata2.00: configured for UDMA/100

The screen is blank but the power hasn't gone off. When I press power and login I have no networking with Wicked, so had to switch to network manager, which recovers networking automatically.

Is this connected?
4.12.14-lp151.28.36-default #1 SMP Fri Dec 6 13:50:27 UTC 2019 (8f4a495) x86_64 x86_64 x86_64 GNU/Linux
Comment 70 Theo Luning 2020-01-22 16:11:31 UTC
I've tested Fedora 31 Live today:
https://spins.fedoraproject.org/kde/download/index.html

Everything regarding Suspend-Resume seems to work on my machine with Fedora 31 (Better than Mageia, which did not reconnect WiFi after resume and other USB and audio-device related problems).

I really prefer OpenSUSE with Yast2, but I need suspend-resume.
Comment 71 Hubert Mantel 2020-01-23 08:29:41 UTC
(In reply to Theo Luning from comment #70)
> I've tested Fedora 31 Live today:
> https://spins.fedoraproject.org/kde/download/index.html
> 
> Everything regarding Suspend-Resume seems to work on my machine with Fedora
> 31 (Better than Mageia, which did not reconnect WiFi after resume and other
> USB and audio-device related problems).
> 
> I really prefer OpenSUSE with Yast2, but I need suspend-resume.

Thanks for this information! It comes perfectly in time for me as I just ordered a new SSD so I can evaluate which distribution to use in future. Mageia (I confused it with "Ecosia" in previous comments :-) probably is too small, so I plan to evaluate Ubuntu and Fedora.

First test will be with Tumbleweed as I would prefer to stay with SuSE. But if the Tumbleweed kernel also does no longer fully support my system, I will switch. It is just too annoying meanwhile.
Comment 72 Takashi Iwai 2020-01-23 08:46:07 UTC
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.
Comment 73 Hubert Mantel 2020-01-23 09:42:43 UTC
I do not understand. The problem is specific to SuSE, as several other distributions seem to work fine and also openSuSE was working perfectly until Leap 42.3.

Maybe it's not only the kernel that is responsible for the issue but also some other component is involved.

Also I'm not sure if using a tumbleweed kernel on Leap 15.1 is supposed to work. It is quite some time that I tried different kernels, but things got even worse.
Comment 74 Takashi Iwai 2020-01-23 09:58:36 UTC
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.
Comment 75 Theo Luning 2020-01-23 10:51:50 UTC
Last week I've tried the Kernel 5.5 + Firmware from:
http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/

No improvement.

Fedora 31 (Live) has Kernel 5.3 and it works.
Debian 10 (Live) works as well (tested today).

To me this looks like a SUSE specific problem.

Thank you.
Comment 76 Takashi Iwai 2020-01-23 11:00:48 UTC
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.
Comment 77 Takashi Iwai 2020-01-23 13:49:19 UTC
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
- Boot with xhci_hcd.quirks=0x42000 option.
Comment 78 Hubert Mantel 2020-01-23 14:09:04 UTC
(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.
Comment 79 Takashi Iwai 2020-01-23 14:16:36 UTC
No, XHCI is the corret name.  The ACPI shows XHC just as its own naming, but essentially both point to the same thing.

What I meant is to boot with xhci_hcd.quirks=0x42000 option, in addition to disabling the wake up sources as much as possible in /proc/acpi/wakeup, as you already tried in the past.
Comment 80 Theo Luning 2020-01-23 14:35:16 UTC
@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.
Comment 81 Ian Jones 2020-01-23 14:48:30 UTC
(In reply to Takashi Iwai from comment #74)
> Then please try TW kernel on your current Leap 15.1 system.  If this doesn't

I think this would cause problems with my nvidia graphics drivers.
Comment 82 Theo Luning 2020-01-23 14:56:04 UTC
xhci_hcd.quirks does not change anything here.

Thank you.
Comment 83 Takashi Iwai 2020-01-23 15:06:23 UTC
(In reply to Theo Luning from comment #80)
> echo mem > /sys/power/state says: Translated from german:
> Write error: device or resource is busy (occupied?)

Is this after once you tested S2RAM and failed?  That's possible if the system went into some incomplete state after the failing suspend and its recovery.

BTW, did Leap 42.3 work on your system in the past?  If yes, you can install the old Leap 42.3 kernel on the new system, just for testing the suspend, too.

(In reply to Theo Luning from comment #82)
> xhci_hcd.quirks does not change anything here.

OK, that's not always a wonder spell :)
It's known to have some effect on old Haswell or Broadwell machines for the spurious wakeups after the shutdown.

BTW, now I see a spurious wakeup after S3 on an old HP laptop with Haswell, too.  But this is a known BIOS issue and the ACPI wakeup disablement via /proc/acpi/wakeup helped in this case; at least it's no regression for this machine.
Comment 84 Theo Luning 2020-01-23 15:46:57 UTC
> 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.
Comment 85 Takashi Iwai 2020-01-23 15:52:00 UTC
No need to add a repo in zypper.  Just download the latest kernel-default.rpm from Leap 42.3 download URL, e.g. 
  http://download.opensuse.org/update/leap/42.3/oss/x86_64/

And install it directly:
  zypper in --old-package kernel-default-4.4.*.rpm

Then boot with it.
Comment 86 Theo Luning 2020-01-23 16:21:05 UTC
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.
Comment 87 Takashi Iwai 2020-01-23 17:16:15 UTC
Yeah, then your problem is likely a different one although the end effect is same.  Some boot option difference or whatever.

Do you get the same error when you do echoing to /sys/power/state even on 42.3 kernel?  If yes, what shows "cat /sys/power/state"?
Comment 88 Ian Jones 2020-01-23 17:27:23 UTC
I installed the kernel 5.4.10-1-default #1 SMP Thu Jan 9 15:45:45 UTC 2020 (556a6fe) x86_64 x86_64 x86_64 GNU/Linux and installed the kernel-devel files, so nvidia is not broken. Now I am monitoring to see if suspend works. It failed intermittently before.
Comment 89 Theo Luning 2020-01-23 17:37:11 UTC
@Takashi Iwai

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

cat /sys/power/state says
freeze standby mem disk
same as on Leap

Thank you.
Comment 90 Takashi Iwai 2020-01-23 17:38:53 UTC
(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?
Comment 91 Theo Luning 2020-01-23 17:46:41 UTC
> OK, but still 42.3 kernel wakes up after S3 spuriously, right?

I don't know what you mean. On 42.3, everything works perfectly.
S3 sleeps all night long ;-) and resume turns on everything again.

The same as all OpenSUSE versions before (since 2013 on this hardware).

Problems arised only with Leap 15.1 (I skipped 15.0, can't tell).
Comment 92 Takashi Iwai 2020-01-23 17:55:54 UTC
(In reply to Theo Luning from comment #91)
> > OK, but still 42.3 kernel wakes up after S3 spuriously, right?
> 
> I don't know what you mean. On 42.3, everything works perfectly.

You wrote in comment 86 that Leap 42.3 kernel installed on the current system showed the same error.  Or did I misunderstand?
Comment 93 Theo Luning 2020-01-23 18:03:26 UTC
> You wrote in comment 86 that Leap 42.3 kernel installed on the current system showed the same error.  Or did I misunderstand?

That was 4.4.76-1-default installed on Leap 15.1.
Now I am talking of 42.3 (standard kernel).

And it is not waking up, it _does_ turns off e.g. the monitor, but it does not turn off the CPU fan (and maybe other things). 

But it does not "wake up" in that sense. 
It does not turn on the display or so, it just doesn't really "sleep".
Comment 94 Takashi Iwai 2020-01-23 18:54:38 UTC
(In reply to Theo Luning from comment #93)
> > You wrote in comment 86 that Leap 42.3 kernel installed on the current system showed the same error.  Or did I misunderstand?
> 
> That was 4.4.76-1-default installed on Leap 15.1.

Erm, 4.4.76-1-default *is* the Leap 42.3 standard kernel.  So you tested Leap 42.3 kernel on Leap 15.1 system.  What exactly was the test, then?

> Now I am talking of 42.3 (standard kernel).
> 
> And it is not waking up, it _does_ turns off e.g. the monitor, but it does
> not turn off the CPU fan (and maybe other things). 
> 
> But it does not "wake up" in that sense. 
> It does not turn on the display or so, it just doesn't really "sleep".

Which situation does this "it" point to...?  4.4.y kernel running on Leap 15.0 system, or what?  I don't want a text like what lawyers write, but let's make a bit clearer :)

If Leap 42.3 system worked but 42.3 kernel + 15.1 system doesn't, 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.
Comment 95 Theo Luning 2020-01-23 19:13:32 UTC
Confusion? Sorry!

> If Leap 42.3 system worked but 42.3 kernel + 15.1 system doesn't...
Yes, this is exactly the case.

>.. 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?

Thank you.
Comment 96 Takashi Iwai 2020-01-23 20:20:28 UTC
(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.
Comment 97 Takashi Iwai 2020-01-23 22:11:41 UTC
BTW, I'm building a 5.1.y kernel based on Ecosia kernel config Hubert gave in comment 58.  It's being built in OBS home:tiwai:bsc1137748-ecosia-config repo.
Meanwhile, the corresponding TW kernel (with the same kernel version) is found in OBS home:tiwai:kernel:5.1 repo.

Hubert, please try both kernels later and see whether you see the difference in the suspend-to-RAM behavior.  If yes, get dmesg outputs on both, and attach them.
Comment 98 Theo Luning 2020-01-24 14:35:59 UTC
@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.
Comment 99 Frank Morawietz 2020-03-03 21:29:47 UTC
(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
> - Boot with xhci_hcd.quirks=0x42000 option.

Tried this - did not change the problem. Did not fully suspend, like before.

What I noticed during my test (don't know if it is of relevance here):
During the failed attempt to suspend my system time got changed one hour ahead, matching hw clock with UTC.
Comment 100 Theo Luning 2020-03-03 21:42:17 UTC
@Frank Morawietz
Same problem with time leap here (2hrs, probably summer time).
I have already mentioned this in the forum:

https://forums.opensuse.org/showthread.php/537158-Incomplete-standby?p=2911852#post2911852
Comment 101 Frank Morawietz 2020-04-09 19:52:05 UTC
(In reply to Theo Luning from comment #98)
> 
> I've tried powertop auto-tune. It did not improve the suspend-situation, but
> disabled my USB-Mouse. 

Exactly the same powertop auto-tune result for me: Nothing improved for suspend, but USB mouse got disabled.
Comment 102 Frank Morawietz 2020-04-09 20:35:37 UTC
(In reply to Theo Luning from comment #98)
> I've installed the kernel from home:tiwai:bsc1137748-ecosia-config but it
> still does not fully suspend. CPU Fan keeps running. No improvement.

Tried this kernel as well. Minor improvement: The system can be waked up by pressing a key on the keyboard. (Before only possible with the power button.)

Nevertheless, it still does not go to sleep completely: Fans keep running, LEDs are still lit. So no help for the main problem.
Comment 103 Biswarup Ray 2020-06-13 12:39:56 UTC
I have switched to Tumbleweed recently and I am facing the same problem with a gigabyte Mobo from 2012. These are the relevant points:

1. Suspend to Ram works in the latest Ubuntu 20.04, Fedora and MX Linux releases but not on Tumbleweed or Leap 15.2 RC.

2. Suspend to Ram works with the kernel parameter <maxcpus=0> or 'nosmp'.

3. Noticing that suspend to ram works if booted with one cpu core enabled, I tried to disable the non boot cpu of my dual core pentium G640 on the fly (using the hot plug feature), but that did not work!

4.Since the <maxcpus=0> kernel parameter disables apic, this is most probably related to APIC. This is stated in kernel documentation:
"maxcpus=    [SMP] Maximum number of processors that an SMP kernel should make use of.  maxcpus=n : n >= 0 limits the kernel to using 'n' processors.
   n=0 is a special case, it is equivalent to "nosmp", which also disables the IO APIC."
Comment 104 Hubert Mantel 2020-06-14 09:13:17 UTC
(In reply to Biswarup Ray from comment #103)
> I have switched to Tumbleweed recently and I am facing the same problem with
> a gigabyte Mobo from 2012. These are the relevant points:
> 
> 1. Suspend to Ram works in the latest Ubuntu 20.04, Fedora and MX Linux
> releases but not on Tumbleweed or Leap 15.2 RC.
> 
> 2. Suspend to Ram works with the kernel parameter <maxcpus=0> or 'nosmp'.
> 
> 3. Noticing that suspend to ram works if booted with one cpu core enabled, I
> tried to disable the non boot cpu of my dual core pentium G640 on the fly
> (using the hot plug feature), but that did not work!
> 
> 4.Since the <maxcpus=0> kernel parameter disables apic, this is most
> probably related to APIC. This is stated in kernel documentation:
> "maxcpus=    [SMP] Maximum number of processors that an SMP kernel should
> make use of.  maxcpus=n : n >= 0 limits the kernel to using 'n' processors.
>    n=0 is a special case, it is equivalent to "nosmp", which also disables
> the IO APIC."

Well, using only one single CPU is even less acceptable than switching distros.

Also it seems it is not just the kernel itself, because using an older kernel from a working SUSE distribution still fails.
Comment 105 Biswarup Ray 2020-06-14 09:37:14 UTC
What is interesting is that I disabled the non boot cpu on the running system on the fly, so that only one cpu is running, and then invoked suspend, but it did not work.
Also I copied the mem_sleep file that 'systemctl suspend' invokes, from fedora to tumbleweed, there was no difference. 
I am now thinking about 'chroot'ing from another distro(running on pendrive) and then invoking suspend.
Comment 106 Frank Morawietz 2020-06-23 19:40:23 UTC
Hmmm, interesting findings.

As it is possibly related to the Advanced Programmable Interrupt Controller, might it help to dig into  /proc/interrupts  or  /proc/irq/ ?
Latter even contains a file named  default_smp_affinity , amongst others.

Does anybody know enough internals to judge on this?
Comment 107 Biswarup Ray 2020-06-24 06:43:28 UTC
STR is working even with both CPUs enabled if kernel parameter 'noapic' is used during boot.
So the issue definitely is with APIC.
Comment 108 Takashi Iwai 2020-06-24 08:07:44 UTC
Could you guys check whether the workaround with noapic is valid with Leap 15.2 kernel, too?  If yes, it's more interesting and we have a better chance to fix.
Comment 109 Hubert Mantel 2020-06-24 08:32:16 UTC
I currently cannot test because I need the machine for work, but I wonder about this workaround as this would indicate it is purely a kernel issue, correct?
Comment 110 Biswarup Ray 2020-06-24 08:51:13 UTC
I want to clarify that, in all my above comments, I have posted my results after testing on the latest snapshot of Tumbleweed. I had checked once with the Leap 15.2RC live usb about 15days ago and found that STR was not working on it, but I have not tested the workaround on it.
  If it was a kernel issue then the issue would have manifest itself on all distros at some point of time. Why is only OpenSuse affected?
Comment 111 Takashi Iwai 2020-06-24 10:03:39 UTC
(In reply to Hubert Mantel from comment #109)
> I currently cannot test because I need the machine for work, but I wonder
> about this workaround as this would indicate it is purely a kernel issue,
> correct?

Yes, it's a kernel problem.  But it might have been addressed in the recent kernel already, or the workaround doesn't work there.  The more tests are needed in anyway for further debugging and fixing.
Comment 112 Takashi Iwai 2020-06-24 10:06:48 UTC
(In reply to Biswarup Ray from comment #110)
> I want to clarify that, in all my above comments, I have posted my results
> after testing on the latest snapshot of Tumbleweed. I had checked once with
> the Leap 15.2RC live usb about 15days ago and found that STR was not working
> on it, but I have not tested the workaround on it.
>   If it was a kernel issue then the issue would have manifest itself on all
> distros at some point of time. Why is only OpenSuse affected?

There are always difference in kconfigs and different way of suspend/resume iamong distros.  About the latter, in general, the test should be minimum: better to test with "echo mem > /sys/power/state" for the direct kernel suspend-to-RAM.
Comment 113 Biswarup Ray 2020-06-24 10:45:15 UTC
There is another agent that can potentially introduce some distro specific quirks regarding how interrupts are handled - irqbalance, but I have checked its configuration files and the systemd startup file associated with it and I have found nothing unusual.
Comment 114 Frank Krüger 2020-06-27 06:57:48 UTC
Given current Leap 15.2 [Build 692.2] with KDE Plasma 5.18.5 suspend-to-ram does not work anymore, while hibernation works fine (using KDE menu). Please note that 'systemctl suspend' and 'echo mem > /sys/power/state' work as expected. Any idea? New bug report?
Comment 115 Frank Krüger 2020-06-27 07:50:43 UTC
(In reply to Frank Krüger from comment #114)
> Given current Leap 15.2 [Build 692.2] with KDE Plasma 5.18.5 suspend-to-ram
> does not work anymore, while hibernation works fine (using KDE menu). Please
> note that 'systemctl suspend' and 'echo mem > /sys/power/state' work as
> expected. Any idea? New bug report?

FYI: After reinstalling KDE the issue is solved for me.
Comment 116 Hubert Mantel 2020-06-29 09:11:14 UTC
(In reply to Frank Krüger from comment #115)
> (In reply to Frank Krüger from comment #114)
> > Given current Leap 15.2 [Build 692.2] with KDE Plasma 5.18.5 suspend-to-ram
> > does not work anymore, while hibernation works fine (using KDE menu). Please
> > note that 'systemctl suspend' and 'echo mem > /sys/power/state' work as
> > expected. Any idea? New bug report?
> 
> FYI: After reinstalling KDE the issue is solved for me.

Not sure I understand correctly: So are you saying that with 15.2 suspend to RAM is working again for you? Why did you have to reinstall KDE? Was this an upgrade from 15.1 without KDE?

As 15.2 is currently being released, I would want to give it a try next weekend. And working around any KDE issue by using the "echo mem" approach would be perfectly fine for me.
Comment 117 Frank Krüger 2020-06-29 10:35:54 UTC
(In reply to Hubert Mantel from comment #116)
> (In reply to Frank Krüger from comment #115)
> > (In reply to Frank Krüger from comment #114)
> > > Given current Leap 15.2 [Build 692.2] with KDE Plasma 5.18.5 suspend-to-ram
> > > does not work anymore, while hibernation works fine (using KDE menu). Please
> > > note that 'systemctl suspend' and 'echo mem > /sys/power/state' work as
> > > expected. Any idea? New bug report?
> > 
> > FYI: After reinstalling KDE the issue is solved for me.
> 
> Not sure I understand correctly: So are you saying that with 15.2 suspend to
> RAM is working again for you? Why did you have to reinstall KDE? Was this an
> upgrade from 15.1 without KDE?
> 
> As 15.2 is currently being released, I would want to give it a try next
> weekend. And working around any KDE issue by using the "echo mem" approach
> would be perfectly fine for me.

I upgraded Leap 15.1 with KDE by using 'zypper dup' a long time ago when a beta version of 15.2 was available. I never had any problems with suspend to ram until very recently. Since the issue is probably not due to systemd and the kernel,I tried reinstalling KDEand it worked. Unfortunately, after today's reboot the issue is back again. Strange!
Comment 118 Hubert Mantel 2020-06-29 12:04:12 UTC
Ah, so this is a totally different issue then :(
Comment 119 Frank Morawietz 2020-06-29 18:47:30 UTC
Back to 'our' issue I can confirm that after booting with the kernel parameter 'noapic' Suspend-to-RAM works without problems either with "echo mem >> /sys/power/state" and also via the KDE menu on openSUSE Leap 15.1 .

(I might try it with a 15.2 live system on my machine some days later.)
Comment 120 Frank Krüger 2020-06-29 19:28:04 UTC
(In reply to Frank Morawietz from comment #119)
> Back to 'our' issue I can confirm that after booting with the kernel
> parameter 'noapic' Suspend-to-RAM works without problems either with "echo
> mem >> /sys/power/state" and also via the KDE menu on openSUSE Leap 15.1 .
> 
> (I might try it with a 15.2 live system on my machine some days later.)

Sorry, I did not want to hijack this bug report. Anyway, as far as current Leap 15.2 is concerned, let me just mention that the corresponding KOTD kernel-default-5.3.18-lp152.80.1.g2a0430f.x86_64 solves my issue. Maybe this helps.
Comment 121 Hubert Mantel 2020-06-30 07:31:13 UTC
(In reply to Frank Morawietz from comment #119)
> Back to 'our' issue I can confirm that after booting with the kernel
> parameter 'noapic' Suspend-to-RAM works without problems either with "echo
> mem >> /sys/power/state" and also via the KDE menu on openSUSE Leap 15.1 .
> 
> (I might try it with a 15.2 live system on my machine some days later.)

Unfortunately this does not work for me. If I use the kernel parameter "noapic" my keyboard does not work and I cannot even log in. Strangely enough the mouse is working fine, which is also connected via USB.

Maybe I would need to fiddle with BIOS settings now. I will try things with 15.2 and see how things go.
Comment 122 Frank Morawietz 2020-06-30 19:51:57 UTC
> Sorry, I did not want to hijack this bug report. Anyway, as far as current
> Leap 15.2 is concerned, let me just mention that the corresponding KOTD
> kernel-default-5.3.18-lp152.80.1.g2a0430f.x86_64 solves my issue. Maybe this
> helps.

No problem at all. Every input is valued as it can provide new insights or provoke new ideas. For example the new kernel version you just mentioned sounds interesting.
Comment 123 Frank Morawietz 2020-06-30 19:55:38 UTC
(In reply to Hubert Mantel from comment #121)
> Unfortunately this does not work for me. If I use the kernel parameter
> "noapic" my keyboard does not work and I cannot even log in. Strangely
> enough the mouse is working fine, which is also connected via USB.
> 
> Maybe I would need to fiddle with BIOS settings now. I will try things with
> 15.2 and see how things go.

I would check BIOS settings first. Perhaps trying another keyboard.
Comment 124 Vadim Krevs 2020-07-13 19:59:28 UTC
Not sure if my issue is related to this but perhaps it is. A couple of days ago I had downgraded my Dell Inspiron 5770 laptop from Tumbleweed to openSUSE 15.2. 

Everything went smoothly except suspend to RAM stopped working. Worked fine under Tumbleweed. Closing the lid, choosing Leave->Sleep or "# echo -n mem >/sys/power/state" suspends the laptop for a second and then it wakes up again on 15.2.

openSuSE bugzilla led me to this issue, comment #37 led me to a forum.opensuse.org thread, and there comment #8 lead me to https://blog.mdda.net/oss/2017/08/12/prevent-spurious-wakeups, which helped me  discover that it was my USB3 hub with 3 external HDDs and webcam attached to it that was the reason for the wakeups.

Adding "echo XHC > /proc/acpi/wakeup" to /etc/init.d/boot.local resolved the issue for me on 15.2 and suspend to RAM is working again. 

Perhaps this might be useful to someone.
Comment 125 Hubert Mantel 2020-07-16 11:34:15 UTC
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.
Comment 126 Takashi Iwai 2020-07-16 12:02:13 UTC
(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.

Hubert, we've been never so innovative, neither "created" such a regression at all.  It must be some upstream change that has effect only with a certain combo of kernel config or other setup where other distros don't hit by some reason.
Comment 127 Frank Krüger 2020-07-16 18:34:42 UTC
(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).
Comment 128 Hubert Mantel 2020-07-21 12:15:05 UTC
(In reply to Takashi Iwai from comment #126)
> (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.
> 
> Hubert, we've been never so innovative, neither "created" such a regression
> at all.  It must be some upstream change that has effect only with a certain
> combo of kernel config or other setup where other distros don't hit by some
> reason.

Sorry, maybe I used the wrong wording (I'm not native English speaker). I just wanted to say that it must be something introduced by SUSE only lately because in the past it has been working fine and every other distribution so far also does not show this issue.

Unfortunately I'm completely out of ideas where to look further. Also currently I need this machine for work; maybe I can do more testing after the end of July when I do not need the machine for work any longer. But so far I could only confirm the findings of others anyway.
Comment 129 Hubert Mantel 2020-07-21 12:18:29 UTC
(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...
Comment 130 Hubert Mantel 2020-08-07 09:34:57 UTC
From my point of view, this bug can be closed as WONTFIX or WORKSFORME.

So sad...
Comment 131 Frank Morawietz 2020-10-08 18:30:48 UTC
Just in case somebody is still interested and reading this...

I verified with a Tumbleweed live system that the problem is there in Tumbleweed, too.
(Kernel 5.7.5-1-default)

Choosing "Suspend to RAM" in KDE menu results in
- screen goes dark and confirms no more signal incoming
- LEDs at desktop front stay lit
- fans still running
- system can be woke up again by keyboard
Comment 132 Frank Morawietz 2020-10-08 19:24:18 UTC
FWIW: exactly the same symptoms with the KOTD from 2020-10-07:
kernel-default-5.9.rc8-2.1.ge450c4d.x86_64
Comment 133 Biswarup Ray 2021-06-29 08:38:55 UTC
Today I booted the GeckoLinux_ROLLING_Cinnamon.x86_64-999.210526.0.iso which is based on Tumbleweed, using a pen drive and was surprised to find that suspend to ram is working fine.
Comment 134 Frank Morawietz 2021-06-30 17:55:00 UTC
(In reply to Biswarup Ray from comment #133)
> Today I booted the GeckoLinux_ROLLING_Cinnamon.x86_64-999.210526.0.iso which
> is based on Tumbleweed, using a pen drive and was surprised to find that
> suspend to ram is working fine.

Which Kernel version was this?
Comment 135 Biswarup Ray 2021-07-01 07:34:19 UTC
(In reply to Frank Morawietz from comment #134)

> Which Kernel version was this?
5.12.4-1.1

This version of Geckolinux was released about a couple of months ago.
Comment 136 Frank Morawietz 2021-07-01 20:53:22 UTC
(In reply to Biswarup Ray from comment #135)
> > Which Kernel version was this?
> 5.12.4-1.1

Thanks for providing the detail.

I tested 5.13.0-1 from <http://download.opensuse.org/repositories/Kernel:/stable/standard/> under openSUSE Leap 15.2 . (Couldn't find your exact version.)

Did not work for me. Display still active, everything keeps running, only keyboard and mouse are disabled. After pressing the power button, keyboard and mouse are working again.

So the new kernel version does not seem to be the crucial difference. There must be more.
Comment 137 christian mathieu 2022-07-25 14:22:20 UTC
Hello.

I still have this bug.

My hardware configuration:
    - motherboard: ASUS M5A99X EVO (rev 1.0)
    - processor: AMD FX(tm)-8350 Eight-Core Processor
    - graphics card: AMD Radeon HD 7750 Series (verde)

------------------------------------------------------------------    
suspend does not work with:
    - GeckoLinux_ROLLING_Plasma.x86_64-999.220115.0
    - openSUSE-Leap-15.4-KDE-Live-x86_64-Build6.199-Media
    - openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20220719-Media
    - openSUSE-Tumbleweed-NET-x86_64-Snapshot20220719-Media
        -in dmesg, I find:
            [  396.799647] r8169 0000:05:00.0 enp5s0: Link is Down
            [  399.759312] PM: suspend entry (deep)
            [  400.231992] Filesystems sync: 0.472 seconds
            [  400.438798] Freezing user space processes ... (elapsed 0.001 seconds) done.
            [  400.440570] OOM killer disabled.
            [  400.440572] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
            [  400.441815] printk: Suspending console(s) (use no_console_suspend to debug)
            [  400.444988] serial 00:04: disabled
            [  400.465868] sd 0:0:0:0: [sda] Synchronizing SCSI cache
            [  400.469243] sd 0:0:0:0: [sda] Stopping disk
            [  401.122141] ACPI: PM: Preparing to enter system sleep state S3
            [  401.122285] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
            [  401.123314] ACPI: PM: Saving platform NVS memory
--------->  [  401.123425] Disabling non-boot CPUs ...
--------->  [  401.123427] Wakeup pending. Abort CPU freeze
--------->  [  401.123428] Non-boot CPUs are not disabled
            [  401.123448] ACPI: PM: Waking up from system sleep state S3
            [  401.162846] usb usb6: root hub lost power or was reset
            [  401.162853] usb usb7: root hub lost power or was reset
            [  401.163050] sd 0:0:0:0: [sda] Starting disk
            [  401.164391] serial 00:04: activated
            [  401.170936] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
            [  401.179688] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
            [  401.179781] radeon 0000:01:00.0: WB enabled
            [  401.179785] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00
            [  401.179789] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c
            [  401.180558] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118
            [  401.180759] debugfs: File 'radeon_ring_gfx' in directory '0' already present!
            [  401.180762] debugfs: File 'radeon_ring_dma1' in directory '0' already present!

------------------------------------------------------------------    
suspend work with:
    - Fedora-KDE-Live-x86_64-36-1.5
    - manjaro-kde-21.3.5-220721-linux515
    - kubuntu-22.04-desktop-amd64
    - debian-live-11.4.0-amd64-kde+nonfree
    - MX-21.1_KDE_x64
    - . . . 
        -in dmesg, I find:
            [12192.721273] PM: suspend entry (deep)
            [12192.728251] Filesystems sync: 0.006 seconds
            [12192.728387] Freezing user space processes ... (elapsed 0.002 seconds) done.
            [12192.730601] OOM killer disabled.
            [12192.730602] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
            [12192.732056] printk: Suspending console(s) (use no_console_suspend to debug)
            [12192.740729] serial 00:07: disabled
            [12192.779526] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
            [12192.779547] sd 0:0:0:0: [sda] Synchronizing SCSI cache
            [12192.779552] sd 3:0:0:0: [sdd] Synchronizing SCSI cache
            [12192.779555] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
            [12192.779604] sd 2:0:0:0: [sdc] Stopping disk
            [12192.779893] sd 0:0:0:0: [sda] Stopping disk
            [12192.780127] sd 1:0:0:0: [sdb] Stopping disk
            [12192.780175] sd 3:0:0:0: [sdd] Stopping disk
            [12193.660839] ACPI: EC: interrupt blocked
            [12193.676148] amdgpu 0000:01:00.0: amdgpu: PCI CONFIG reset
            [12193.692822] ACPI: PM: Preparing to enter system sleep state S3
            [12193.693272] ACPI: EC: event blocked
            [12193.693273] ACPI: EC: EC stopped
            [12193.693274] ACPI: PM: Saving platform NVS memory
            [12193.693329] Disabling non-boot CPUs ...
            [12193.695725] smpboot: CPU 1 is now offline
            [12193.698364] smpboot: CPU 2 is now offline
            [12193.700216] smpboot: CPU 3 is now offline
            [12193.702065] smpboot: CPU 4 is now offline
            [12193.704183] smpboot: CPU 5 is now offline
            [12193.705949] smpboot: CPU 6 is now offline
            [12193.707957] smpboot: CPU 7 is now offline
------------------------------------------------------------------
Comment 138 christian mathieu 2022-08-16 16:50:30 UTC
Hello  !

exactly same problem with another mobo : Giga-Byte GA-990FXA-UD3  ! ! !

Thank you.
Comment 139 christian mathieu 2022-11-23 23:01:14 UTC
Hello.

Why is this old bug not fixed ?
OpenSUSE is the only distribution affected !
I prefer OpenSUSE, but I can't install it! 

Kind regards
Comment 140 Takashi Iwai 2022-11-24 07:12:59 UTC
Mainly because the problem happens only on certain (likely old) machines under some situations.  And partly because debugging the suspend/resume problem is *VERY* difficult to do remotely; the suspend/resume can't leave much logs unless you set up specially.

At least you can try the latest upstream kernel from OBS Kernel:stable:Backport, and check whether the problem persists.  If yes, the issue should be reported rather to the upstream and handled there.