Bug 1134865

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

I can confirm at least a strikingly similar issue, though Leonardo's output doesn't include the same error as mine. Still possibly related?

Hibernate works however.

Created attachment 813717 [details]
supportconfig logs

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

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

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

Created attachment 816022 [details]
dmesg output after the "echo" and "cat" commands

Leonardo, does the issue still exist with the lastest TW kernel? Could you retest, please?

(In reply to Miroslav Beneš from comment #9)
> Leonardo, does the issue still exist with the lastest TW kernel? Could you
> retest, please?

yep

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?

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

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

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

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

Created attachment 838764 [details]
hwinfo output

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.

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?

Hello

there's some time since this bug has gone. Sorry for being too late into sending feedback.

Let's close then. Thanks for the feedback.