Sleep vs suspend

Ask Fedora
,
1

Is there a difference between sleep and suspend?

When I sudo systemctl suspendmy system goes to sleep (all lights and screens are off) and pressing the power button it comes right up again. But when I

image

The system power lights stay, screen is off and no matter which button I press (_including_ the power button) the machine refuses to wake.

So suspend is awesome but sleep apparently not but I cannot select suspend from the list:

image
image199×193 8.66 KB

cat /proc/acpi/wakeup

Device S-state Status Sysfs node
PEG0 S4 *enabled pci:0000:00:01.0
PEGP S4 *disabled pci:0000:01:00.0
PEG1 S4 *enabled pci:0000:00:01.1
PEGP S4 *disabled pci:0000:02:00.0
PEG2 S4 *disabled
PEGP S4 *disabled
PS2K S3 *enabled pnp:00:00
*disabled serio:serio0
PS2M S3 *disabled pnp:00:01
RP09 S4 *enabled pci:0000:00:1d.0
PXSX S4 *disabled pci:0000:42:00.0
RP10 S4 *disabled
PXSX S4 *disabled
RP11 S4 *disabled
PXSX S4 *disabled
RP12 S4 *disabled
PXSX S4 *disabled
RP13 S4 *disabled
PXSX S4 *disabled
RP01 S4 *enabled pci:0000:00:1c.0
PXSX S4 *disabled
RP02 S4 *enabled pci:0000:00:1c.1
PXSX S4 *disabled
RP03 S4 *enabled pci:0000:00:1c.2
PXSX S4 *disabled
RP04 S4 *disabled
PXSX S4 *disabled
RP05 S4 *enabled pci:0000:00:1c.4
PXSX S4 *enabled pci:0000:09:00.0
RP06 S4 *disabled
PXSX S4 *disabled
RP07 S4 *disabled
PXSX S4 *disabled
RP08 S4 *disabled
PXSX S4 *disabled
RP17 S4 *enabled pci:0000:00:1b.0
PXSX S4 *disabled
RP18 S4 *disabled
PXSX S4 *disabled
RP19 S4 *enabled pci:0000:00:1b.2
PXSX S4 *enabled pci:0000:04:00.0
RP20 S4 *enabled pci:0000:00:1b.3
PXSX S4 *disabled pci:0000:05:00.0
RP21 S4 *disabled
PXSX S4 *disabled
RP22 S4 *disabled
PXSX S4 *disabled
RP23 S4 *disabled
PXSX S4 *disabled
RP24 S4 *disabled
PXSX S4 *disabled
RP14 S4 *disabled
PXSX S4 *disabled
RP15 S4 *disabled
PXSX S4 *disabled
RP16 S4 *disabled
PXSX S4 *disabled
GLAN S4 *enabled pci:0000:00:1f.6
XHC S4 *enabled pci:0000:00:14.0
XDCI S4 *disabled
HDAS S4 *disabled pci:0000:00:1f.3

inxi -Fzxx

System:
Kernel: 7.1.10-200.fc44.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 16.2.1
Desktop: KDE Plasma v: 6.7.4 tk: Qt v: N/A wm: kwin_wayland dm: N/A
Distro: Fedora Linux 44 (KDE Plasma Desktop Edition)
Machine:
Type: Desktop System: Gigabyte product: Z170X-Gaming 7 v: N/A
serial:
Mobo: Gigabyte model: Z170X-Gaming 7 v: x.x serial:
Firmware: UEFI vendor: American Megatrends v: F22m date: 03/09/2018
Battery:
Device-1: hid-dc:2c:26:3e:c2:2b-battery-3 model: KEMOVE K61 serial: N/A
charge: N/A status: discharging
Device-2: hidpp_battery_0 model: Logitech Anywhere MX serial:
charge: 45% status: discharging
CPU:
Info: quad core model: Intel Core i7-7700K bits: 64 type: MT MCP
arch: Kaby Lake rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 8 MiB
Speed (MHz): avg: 800 min/max: 800/4200 cores: 1: 800 2: 800 3: 800 4: 800
5: 800 6: 800 7: 800 8: 800 bogomips: 67200
Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: NVIDIA TU104GL [Quadro RTX 4000] driver: nouveau v: kernel
arch: Turing pcie: speed: 8 GT/s lanes: 8 ports: active: DP-1,DP-4
empty: DP-2,DP-3 bus-ID: 01:00.0 chip-ID: 10de:1eb1
Device-2: Logitech BRIO Ultra HD Webcam
driver: hid-generic,snd-usb-audio,usbhid,uvcvideo type: USB rev: 3.1
speed: 5 Gb/s lanes: 1 bus-ID: 6-2:2 chip-ID: 046d:085e
Display: wayland server: Xwayland v: 24.1.13 compositor: kwin_wayland
driver: gpu: nouveau d-rect: 5360x2520 display-ID: 0
Monitor-1: DP-1 pos: top-right model: Samsung CF791 res: 3440x1440 hz: 100
dpi: 110 diag: 864mm (34")
Monitor-2: DP-4 pos: bottom-l model: Lenovo M14 res: 1920x1080 hz: 60
dpi: 157 diag: 358mm (14.1")
API: EGL v: 1.5 platforms: device: 0 drv: zink device: 1 drv: swrast gbm:
drv: zink surfaceless: drv: zink wayland: drv: zink x11: drv: zink
API: OpenGL v: 4.6 vendor: mesa v: 26.1.8 glx-v: 1.4 direct-render: yes
renderer: zink Vulkan 1.4(Quadro RTX 4000 (NVK TU104) (MESA_NVK))
device-ID: 10de:1eb1 display-ID: :0.0
API: Vulkan v: 1.4.341 surfaces: N/A device: 0 type: discrete-gpu
driver: mesa nvk device-ID: 10de:1eb1 device: 1 type: cpu
driver: mesa llvmpipe device-ID: 10005:0000
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdriinfo,
xdpyinfo, xprop, xrandr
Audio:
Device-1: Intel 100/C230 Series Family HD Audio vendor: Gigabyte
driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a170
Device-2: NVIDIA TU104 HD Audio driver: snd_hda_intel v: kernel pcie:
speed: 8 GT/s lanes: 8 bus-ID: 01:00.1 chip-ID: 10de:10f8
Device-3: Logitech BRIO Ultra HD Webcam
driver: hid-generic,snd-usb-audio,usbhid,uvcvideo type: USB rev: 3.1
speed: 5 Gb/s lanes: 1 bus-ID: 6-2:2 chip-ID: 046d:085e
Device-4: RODE Microphones NT-USB driver: hid-generic,snd-usb-audio,usbhid
type: USB rev: 1.1 speed: 12 Mb/s lanes: 1 bus-ID: 7-4:5 chip-ID: 19f7:0003
API: ALSA v: k7.1.10-200.fc44.x86_64 status: kernel-api
Server-1: PipeWire v: 1.6.8 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin
Network:
Device-1: Intel Ethernet I219-V vendor: Gigabyte driver: e1000e v: kernel
port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15b8
IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac:
IF-ID-1: br-11d07a96bc87 state: down mac:
IF-ID-2: br-835f66dfd471 state: down mac:
IF-ID-3: br-b3704be1431b state: down mac:
IF-ID-4: br0 state: up speed: 1000 Mbps duplex: unknown mac:
IF-ID-5: docker0 state: down mac:
Bluetooth:
Device-1: Realtek Bluetooth Radio driver: btusb v: 0.8 type: USB rev: 1.1
speed: 12 Mb/s lanes: 1 bus-ID: 7-2.1:4 chip-ID: 0bda:a729
Report: btmgmt ID: hci0 rfk-id: 2 state: up address: bt-v: 5.1
lmp-v: 10
Drives:
Local Storage: total: 499.31 GiB used: 84.48 GiB (16.9%)
ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 960 EVO 500GB
size: 465.76 GiB speed: 31.6 Gb/s lanes: 4 serial: temp: 48.9 C
ID-2: /dev/sda vendor: Goldendisk model: GDSAL-32MS size: 29.82 GiB
speed: 3.0 Gb/s serial: temp: 37 C
ID-3: /dev/sdb model: USB DISK 2.0 size: 3.73 GiB type: USB rev: 2.0
spd: 480 Mb/s lanes: 1 serial:
Partition:
ID-1: / size: 335.17 GiB used: 83.6 GiB (24.9%) fs: btrfs
dev: /dev/nvme0n1p3
ID-2: /boot size: 1.9 GiB used: 814.3 MiB (41.8%) fs: ext4 dev: /dev/sda2
ID-3: /boot/efi size: 598.8 MiB used: 20 MiB (3.3%) fs: vfat
dev: /dev/sda1
ID-4: /home size: 335.17 GiB used: 83.6 GiB (24.9%) fs: btrfs
dev: /dev/nvme0n1p3
Swap:
ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 41.8 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Memory: total: 16 GiB available: 15.55 GiB used: 4.09 GiB (26.3%)
Processes: 416 Power: uptime: 14m wakeups: 2 Init: systemd v: 259
default: graphical
Packages: pm: rpm pkgs: N/A note: see --rpm pm: flatpak pkgs: 7
Compilers: N/A Shell: Bash v: 5.3.9 running-in: konsole inxi: 3.3.41

2

No.

Probably a bug.

3

think it is a confusion on the names and what they do

years ago there was no sleepp, there was suspend, but suspend to what?

there was suspend to ram and suspend to disk

sleep is the same as suspend to ram, where the system is almost turned off but ram is still powered on with the session you are running, awaiting to be woke up

what we dont see often and last time i heard it is broken is suspend to disk, also called hibernate, that copies all ram contents to the hard disk or ssd, than turns pc off, when you turn it on, it pulls what it had stored from previous session and copies it to ram, so you can keep working

i feel it is a change of names on the concepts we used in the past that makes us confused about what we are doing