Bug 1134865 - Unable to suspend
Unable to suspend
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-05-13 12:47 UTC by Leonardo Teodoro
Modified: 2022-01-03 09:02 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
dmesg output file (50.24 KB, text/plain)
2019-05-13 12:47 UTC, Leonardo Teodoro
Details
journalctl output (826.18 KB, text/plain)
2019-05-28 10:19 UTC, Dennis Irrgang
Details
supportconfig logs (1.21 MB, application/x-xz-compressed-tar)
2019-08-12 15:04 UTC, Leonardo Teodoro
Details
dmesg output after the "echo" and "cat" commands (52.40 KB, text/plain)
2019-08-28 11:53 UTC, Leonardo Teodoro
Details
hwinfo output (42.84 KB, text/plain)
2020-06-14 00:30 UTC, Leonardo Teodoro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leonardo Teodoro 2019-05-13 12:47:03 UTC
Created attachment 804883 [details]
dmesg output file

When I click on suspend button or when I let the PC idle (I setted it up to suspend after 30 minutes idling)or using systemd systemctl suspend, It simply don't suspend. It simply turns the screen off and music stops, but the cooler still works and I can turn it on again by just pressing whatever button on my keyboard or using the mouse.
I attached the output of dmesg and, due to not be able to attach more files, the output of journalctl:
https://cdn.discordapp.com/attachments/475419108448403469/577476546705489951/journalctl.txt
I performed a suspend at May 13th 2019 at 09:43 AM (If this information helps anyway)
Comment 1 Dennis Irrgang 2019-05-28 10:19:05 UTC
Created attachment 806174 [details]
journalctl output

journalctl output of attempting to suspend the laptop several times.

Seems to fail with:

PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 [usbcore] returns -16
Comment 2 Dennis Irrgang 2019-05-28 10:21:07 UTC
I can confirm at least a strikingly similar issue, though Leonardo's output doesn't include the same error as mine. Still possibly related?
Comment 3 Dennis Irrgang 2019-05-28 10:30:20 UTC
Hibernate works however.
Comment 4 Leonardo Teodoro 2019-08-12 15:04:37 UTC
Created attachment 813717 [details]
supportconfig logs
Comment 5 Jiri Slaby 2019-08-27 11:48:33 UTC
(In reply to Leonardo Teodoro from comment #0)
> I performed a suspend at May 13th 2019 at 09:43 AM (If this information
> helps anyway)

somebody is setting your /sys/power/mem_sleep to "s2idle" -- do "cat" on that file and try changing it to "deep". Like what's the output of this sequence:
cat /sys/power/mem_sleep
echo deep > /sys/power/mem_sleep
systemctl suspend
cat /sys/power/mem_sleep
echo deep > /sys/power/mem_sleep
echo mem > /sys/power/state

(In reply to Dennis Irrgang from comment #1)
> PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 [usbcore] returns -16

Yeah, a different issue. Most likely some of your USB devices is early-waking you up. The tablet is there and your camera too. Try to tune your /proc/acpi/wakeup. What do you have in there?
Comment 6 Leonardo Teodoro 2019-08-27 13:50:54 UTC
> somebody is setting your /sys/power/mem_sleep to "s2idle" -- do "cat" on
> that file and try changing it to "deep". Like what's the output of this
> sequence:
> cat /sys/power/mem_sleep
> echo deep > /sys/power/mem_sleep
> systemctl suspend
> cat /sys/power/mem_sleep
> echo deep > /sys/power/mem_sleep
> echo mem > /sys/power/state
all the "cat /sys/power/mem_sleep" outputs "s2idle [deep]" even If I do "echo deep > /sys/power/mem_sleep" and "echo mem > /sys/power/state" outputs "device or resource is busy"
Comment 7 Jiri Slaby 2019-08-28 07:33:52 UTC
(In reply to Leonardo Teodoro from comment #6)
> all the "cat /sys/power/mem_sleep" outputs "s2idle [deep]" even If I do
> "echo deep > /sys/power/mem_sleep" and "echo mem > /sys/power/state" outputs
> "device or resource is busy"

That's weird as I didn't see anything like that in your dmesg. Could you dump dmesg after this echo and attach it here?
Comment 8 Leonardo Teodoro 2019-08-28 11:53:47 UTC
Created attachment 816022 [details]
dmesg output after the "echo" and "cat" commands
Comment 9 Miroslav Beneš 2020-03-20 09:15:40 UTC
Leonardo, does the issue still exist with the lastest TW kernel? Could you retest, please?
Comment 10 Leonardo Teodoro 2020-03-21 17:31:55 UTC
(In reply to Miroslav Beneš from comment #9)
> Leonardo, does the issue still exist with the lastest TW kernel? Could you
> retest, please?

yep
Comment 11 Miroslav Beneš 2020-03-23 07:48:48 UTC
Ok. If it does not work even with the current upstream (Kernel:HEAD project), then, I guess, it should be reported upstream.

Jiri, any other idea what to do about this?
Comment 12 Leonardo Teodoro 2020-03-23 21:24:51 UTC
(In reply to Miroslav Beneš from comment #11)
> Ok. If it does not work even with the current upstream (Kernel:HEAD
> project), then, I guess, it should be reported upstream.
> 
> Jiri, any other idea what to do about this?

I doubt. Other rolling release distros work normally. I tested arch and debian sid and they both suspend normally.
Comment 13 Leonardo Teodoro 2020-03-23 21:26:40 UTC
(In reply to Leonardo Teodoro from comment #12)
> (In reply to Miroslav Beneš from comment #11)
> > Ok. If it does not work even with the current upstream (Kernel:HEAD
> > project), then, I guess, it should be reported upstream.
> > 
> > Jiri, any other idea what to do about this?
> 
> I doubt. Other rolling release distros work normally. I tested arch and
> debian sid and they both suspend normally.

I doubt that it is a upstream bug, cuz (reason above)
Comment 14 Takashi Iwai 2020-03-24 07:05:01 UTC
(In reply to Leonardo Teodoro from comment #13)
> (In reply to Leonardo Teodoro from comment #12)
> > (In reply to Miroslav Beneš from comment #11)
> > > Ok. If it does not work even with the current upstream (Kernel:HEAD
> > > project), then, I guess, it should be reported upstream.
> > > 
> > > Jiri, any other idea what to do about this?
> > 
> > I doubt. Other rolling release distros work normally. I tested arch and
> > debian sid and they both suspend normally.
> 
> I doubt that it is a upstream bug, cuz (reason above)

The Tumbleweed kernel is almost a pure upstream.  Therefore it's usually an upstream bug if something doesn't work with TW kernel even if a similar kernel in other distros does work.

That said, it might be related with the different kernel configuration, dependent on the user-space, or dependent on compiler version, etc -- no matter what, worth to report to upstream.
Comment 15 Leonardo Teodoro 2020-06-14 00:26:47 UTC
ok, so...
I copied debian's kernel and booted it (instead of use opensuse's kernel).
It booted normaly but the suspend still doesn't work...
So by now I don't think this is a kernel issue.
I don't know how to debug it properly honestly, I know that systemd is the responsible for suspending the system (systemctl suspend) and that's it, I don't know how to use systemd nor I don't know other tools that would participate on a suspension
Comment 16 Leonardo Teodoro 2020-06-14 00:30:08 UTC
Created attachment 838764 [details]
hwinfo output
Comment 17 Miroslav Beneš 2020-09-16 10:16:52 UTC
Sorry for the late reply, it slipped through.

Ok, then it really looks like a problem in userspace. CCing Frank if he's aware of any similar issue on systemd side. A couple of months have passed so the situation might be different now.
Comment 18 Miroslav Beneš 2021-12-31 14:36:29 UTC
Walked through the bug again. There is nothing strange in dmesg output from comment 8. The machine just wakes up immediately. Could be explained by pci_pm_suspend() failure in the report, couldn't it?

Leonardo, is the issue still present with the latest TW kernel? If yes, do you have the latest BIOS installed and could you share /proc/acpi/wakeup, please?
Comment 19 Leonardo Teodoro 2021-12-31 23:37:00 UTC
Hello

there's some time since this bug has gone. Sorry for being too late into sending feedback.
Comment 20 Miroslav Beneš 2022-01-03 09:02:08 UTC
Let's close then. Thanks for the feedback.