19.10 - Suspend is broken

Support & Help Requests Hardware
1

Suspend actually "works", but the machine then immediately wakes up on mouse movement. Since it's an HTPC controlled entirely WITH the mouse normally, that's kind of a big problem since just putting the mouse away after using it to initiate the suspend causes the machine to wake up again...

I've got dmesg / syslog output from it, but it doesn't show anything useful: just a successful suspend, followed by a wakeup 1/100th of a second later.

I doubt this is MATE-specific, but I'm surprised that this was broken by the beta: it's been working fine for 5 years now, across a LOT of updates! I have no idea if I actually had to do something to fix this 5 years ago and that configuration/etc just got trashed in the update, or if it had always worked properly and 19.10 simply broke it.

I'll hunt for a solution myself, but if anyone else has run into it and fixed it already, please post the fix. Thanks.

2

Based on my experience with Win7, Win8, Win8.1, Win10 on various PCs during the last more than 10 years: moving the mouse => the PC will wake up from "Suspend" or "Hibernate" (if enabled in BIOS).

May be not a "standard behaviour", but this is what I expect!

3

jep, Windows has the same problem - but it does also have a sane way to STOP it doing that, which Ubuntu is missing.

I think I did have to do "something" to fix this originally on my HTPC, but I don't remember the details. I have a feeling it involved a boot-time script though (rc.local or other init.d pieces) so it may well be that the newer systemd just decided to break it for no good reason. It's either that, or it was in a config file that survived updating to 18.04 last month but the 19.10 beta trampled on. Either way though I'll sort it out soon enough. :slight_smile:

4

For the PCs I've used, it was enough to enable / disable something in BIOS to enable / disable wake-up from "Suspend" via mouse move (not only Win XP->10, but also Ubuntu 16.04->19.10 Beta).

For some of the PCs "moving the mouse" (if enabled in BIOS) works only for wake-up from "Sleep" but not "Hibernate":

  • PCs with ASUS mainboard - it works for wake-up from "Suspend" and "Hibernate"
  • Acer PCs and notebooks - it works for "Suspend" only
  • HP PCs and notebooks - depending on PC / notebook and BIOS version, may work for "Suspend" and / or "Hibernate" (newer PCs, both work as expected - by me!)
5

What about

6

@radax05 - Hibernate is a very distinct state from Suspend, so I'm not surprised your experiences with the two are different. (I'm not interested in Hibernate for any of my machines, so I'm going to keep this simple).

@ugnvs - Thanks. I hunted through root's history on that machine, and /proc/acpi/wakeup is apparently what I used x years ago. I have no idea what the 19.10 update did to break it though, and in the end I decided to just start over rather than keep spending time trying to figure that out.

One of the askubuntu threads I came across had a different way of tackling the problem that I thought was quite interesting, and is much better than the approach I used before. The thread is here but I thought I'd summarise the highlights. The big difference is that /proc/acpi is imprecise (and, for at least the poster in the thread you linked, didn't even work properly for him until he disabled all USB wakeups, even for a different class of USB (3) than his mouse was actually using (2)).
This version lets you choose devices rather than hubs, and as result lets you get the ideal results for a desktop, i.e. wake on USB keyboard, but don't wake just because you breathed near the mouse. :slight_smile:

$ grep . /sys/bus/usb/devices/*/product

On my HTPC, that produces

/sys/bus/usb/devices/1-2/product:Bluetooth Radio
/sys/bus/usb/devices/1-3/product:USB Receiver
/sys/bus/usb/devices/1-4/product:USB Entry Keyboard
/sys/bus/usb/devices/usb1/product:xHCI Host Controller
/sys/bus/usb/devices/usb2/product:xHCI Host Controller

"USB Receiver" is the wireless mouse dongle, so after

(this must be as root, but putting a hash mark here causes crazy broken formatting in the forum)
$ echo disabled > /sys/bus/usb/devices/1-3/power/wakeup

and checking things with

grep . /sys/bus/usb/devices/*/power/wakeup

I (correctly) get

/sys/bus/usb/devices/1-2/power/wakeup:disabled
/sys/bus/usb/devices/1-3/power/wakeup:disabled
/sys/bus/usb/devices/1-4/power/wakeup:enabled
/sys/bus/usb/devices/usb1/power/wakeup:disabled
/sys/bus/usb/devices/usb2/power/wakeup:disabled

So the mouse behaves the way it should and doesn't interfere with suspend, but the keyboard can be used to wake the machine rather than needing to use the power button.

There are two likely problems with this, both related to rebooting. First is that this will almost certainly get wiped out on the next reboot. The more worrying one is that the USB hub and/or device ordering may change, apparently - in which case fixing this via rc.local becomes impractical, and the only "sensible" option is to just disable all USB wakeups via the /proc/acpi method instead.
I haven't actually rebooted that machine to check yet, because the session-restore bug in 19.10 makes that a headache I wasn't in the mood to deal with, but it'll probably happen sometime in the next week, so I'll find out then.

7

I finally rebooted that machine, and as expected the mouse wakeup had been re-enabled, so I added the fix to /etc/rc.local (which was missing entirely despite history showing that I'd edited it at some point in the past, which is a bit worrying).
I'd love to know why / how 19.10 broke my 5-year-stable wakeup rules in the first place, but doubtless never will. (18.04 and 19.04 didn't).

From what I can tell rc.local is still supported properly, but it'll need another reboot to check that and people have clearly had issues with it as far back as at least 18.04, so you may need to create a systemd entry to get it to work.
Seeing as how the systemd one is called "rc-local-somethingsomething-generator", it may be that it just runs when systemd is installed and creates the entry if it finds rc.local at the time. That way, clean installs won't work if users add rc.local later, but upgrades will, and would explain why systemd is so inconsistent about it.

The ordering hadn't changed, but it's only one reboot so it might later. Seems unlikely, but certainly not implausible.