50% of time suspend fails to resume.
 

Hello there,

I have installed Mint 19.1 Beta on my desktop computer.

Mate terminal command ----> inxi -Fxz

System:
Host: deb-B667 Kernel: 4.15.0-42-generic x86_64 bits: 64 compiler: gcc
v: 7.3.0 Desktop: MATE 1.20.1 Distro: Linux Mint 19.1 Tessa
base: Ubuntu 18.04 bionic
Machine:
Type: Desktop System: powerspec product: B667 v: 10/21/09 serial: <filter>
Mobo: ECS model: G43T-AM v: 2.0 serial: <filter> BIOS: American Megatrends
v: 080015 date: 10/16/2009
CPU:
Topology: Quad Core model: Intel Core2 Quad Q8400 bits: 64 type: MCP
arch: Penryn rev: A L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx bogomips: 21334
Speed: 2000 MHz min/max: 2003/2670 MHz Core speeds (MHz): 1: 2000 2: 2000
3: 2000 4: 2000
Graphics:
Device-1: Intel 4 Series Integrated Graphics vendor: Elite Systems
driver: i915 v: kernel bus ID: 00:02.0
Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa
resolution: 1680x1050~60Hz
OpenGL: renderer: Mesa DRI Intel G45/G43 v: 2.1 Mesa 18.0.5
direct render: Yes
Audio:
Device-1: Intel 82801JI HD Audio vendor: Elite Systems
driver: snd_hda_intel v: kernel bus ID: 00:1b.0
Sound Server: ALSA v: k4.15.0-42-generic
Network:
Device-1: Intel 82567V-2 Gigabit Network vendor: Elite Systems
driver: e1000e v: 3.2.6-k port: d880 bus ID: 00:19.0
IF: enp0s25 state: down mac: <filter>
Device-2: Ralink RT2561/RT61 802.11g PCI driver: rt61pci v: 2.3.0
port: e800 bus ID: 03:01.0
IF: wlp3s1 state: up mac: <filter>
Drives:
Local Storage: total: 465.76 GiB used: 15.58 GiB (3.3%)
ID-1: /dev/sda vendor: Western Digital model: WD5000AAKS-22V1A0
size: 465.76 GiB
RAID:
Hardware-1: Intel SATA Controller [RAID mode] driver: ahci v: 3.0
bus ID: 00:1f.2
Partition:
ID-1: / size: 452.90 GiB used: 7.72 GiB (1.7%) fs: ext4 dev: /dev/dm-1
ID-2: /boot size: 703.5 MiB used: 149.5 MiB (21.3%) fs: ext4
dev: /dev/sda1
ID-3: swap-1 size: 3.87 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/dm-3
Sensors:
System Temperatures: cpu: 27.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 196 Uptime: 7m Memory: 3.73 GiB used: 1.10 GiB (29.5%)
Init: systemd runlevel: 5 Compilers: gcc: 7.3.0 Shell: bash v: 4.4.19
inxi: 3.0.27

Approximately 50%-60% of the time I am able to resume from suspend. Suspend seems to mainly fail most always on the second suspend attempt on any given uptime.

I have about the same problem with the same kernel on an older p4 with 19 Tara.

Is there an area I could/should be more focused on to try to resolve this issue?

Thank You,

Let's suspect the distro first. Try Does that work?

@business_kid

deb@deb-B667:~$ sudo echo mem > /sys/power/state
bash: /sys/power/state: Permission denied

Anymore ideas with this situation?

Thank you

I have an install of mint as a spare and a vm, and suspend/resume never was an issue. Mint uses systemd. There must be a way to do it with that.

I've updated the installation here of Mint 19.1 Beta to 19.1 Tessa and still having intermittent suspend/resume problems. I am a noob so I am not certain about just yet how to attempt to use systemd to suspend and resume. Thanks for the help though.

man systemctl?

Ok great.

Thank You

I believe with this particular terminal that BIOS ACPI settings have some play in the suspend issue I have been dealing with. Terminal seems to suspend and unsuspend in general without failure when BIOS ACPI settings is set to auto instead of ACPI S1 or ACPI S3.

Thanks

Bios ACPI settings are one issue, but if the terminal does it OK, that seems to clear the BIOS.

What you're left with is the power manager (or lack thereof) in whatever WM you happen to be using. Often it's simply badly configured. I once got this issue that if I went to hibernate, it would hibernate, reboot, and hibernate again immediately. It was in fact doing it twice - once via bios and once via power manager. It could even be loading the wrong drivers.

Another useful trick is to restart acpid with a -l option. You can then tail syslog and hit bios hot keys, and they will report them in syslog. They link to scripts (all under /etc/acpi). Of course, if systemd has stuck it's nose into that, you're up the creek without a paddle from this poster at any rate.