PureOS not entering standby


#1

Recently I’ve had a few occasions where the Librem 13v3 would not enter standby. The only way to resolve the issue was to restart.

Has anyone else experienced this and if so what was the remedy?

What system calls prevent the system from sleeping?


#2

check dmesg - should give some indication on why sleep fails. In general userland cannot prevent it, something in the kernel - kernel threads or device drivers (modules)


#3

This is what I got when checking the last 40 lines: (showing only what I think is the relevant info)

[ 219.230822] x86: Booting SMP configuration:
[ 219.230823] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 219.231344] cache: parent cpu1 should not be sleeping
[ 219.231615] CPU1 is up
[ 219.231636] smpboot: Booting Node 0 Processor 2 APIC 0x3
[ 219.232117] cache: parent cpu2 should not be sleeping
[ 219.232275] CPU2 is up
[ 219.232293] smpboot: Booting Node 0 Processor 3 APIC 0x2
[ 219.232765] cache: parent cpu3 should not be sleeping
[ 219.232925] CPU3 is up
[ 219.236694] ACPI: Waking up from system sleep state S3
[ 219.236900] ACPI: EC: interrupt unblocked
[ 219.280287] ACPI: EC: event unblocked
[ 219.280374] ath: phy0: ASPM enabled: 0x43
[ 219.281022] sd 0:0:0:0: [sda] Starting disk
[ 219.281030] sd 2:0:0:0: [sdb] Starting disk
[ 219.597649] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 219.597685] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 219.598405] ata3.00: supports DRM functions and may not be fully accessible
[ 219.603420] ata3.00: supports DRM functions and may not be fully accessible
[ 219.606803] ata3.00: configured for UDMA/133
[ 219.606815] ahci 0000:00:17.0: port does not support device sleep
[ 219.606967] ata3.00: Enabling discard_zeroes_data
[ 219.611442] ata1.00: configured for UDMA/133

Looks like it is a hard drive driver. Anyone else had this issue? Or maybe I’m interpreting this wrong.


#4

seems it’s content of boot time dmesg, not current. Try sudo dmesg -w, wait till listing stops and then push standby button - that should print out any new messages


#5

Well, I’ve already rebooted, so I’m not having the standby issue currently. However the next time I start having it, I’ll run that command, and post here again.


#6

Not sure this will help, but I’m having the failed to suspend issue again:

[79709.010428] sd 2:0:0:0: [sdb] Starting disk
[79709.069651] OOM killer enabled.
[79709.069651] Restarting tasks ... done.
[79709.275499] userif-3: sent link down event.
[79709.275505] userif-3: sent link up event.
[79709.280319] PM: suspend exit
[79709.280446] PM: suspend entry (s2idle)
[79709.280448] PM: Syncing filesystems ... 
[79709.324470] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[79709.338079] ata1.00: configured for UDMA/133
[79709.339903] done.
[79709.340203] Freezing user space processes ... (elapsed 0.004 seconds) done.
[79709.344845] OOM killer disabled.
[79709.344847] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[79709.346641] Suspending console(s) (use no_console_suspend to debug)
[79709.369899] sd 2:0:0:0: [sdb] Synchronizing SCSI cache
[79709.373025] sd 2:0:0:0: [sdb] Stopping disk
[79709.390060] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[79709.390162] sd 0:0:0:0: [sda] Stopping disk
[79709.620762] pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 [usbcore] returns -16
[79709.620772] dpm_run_callback(): pci_pm_suspend+0x0/0x120 returns -16
[79709.620776] PM: Device 0000:00:14.0 failed to suspend async: error -16
[79709.623893] PM: Some devices failed to suspend, or early wake event detected
[79709.624123] ath: phy0: ASPM enabled: 0x43

Don’t see anything task or program specific.


#7

no, not task or program but rather hardware. Do you have any usb device plugged which might prevent the sleep? or could be the usb3 hub itself which is getting stuck, so next time it fails to sleep try to modprobe -r xhci_pci and retry sleep


#8

Thank you for the suggestion. I’ve copied it down for when it happens again.

I believe it is most likely the USB3 hub itself. I plug in a external hdd to make a weekly backup, but I always ejected it before unplugging it. However, I am only waiting for the OS GUI to tell me it has been disconnected. I’m not waiting for the light or power to go off on the device. Maybe the controller is hanging as I’m not ejecting it correctly. Would be good, if a time out could have the controller reset this particular hang up, as preventing the standby could be a very severe thing.

Established behavior with the librem 13, is closing the lid sleeps the computer. If you were to pack your laptop in a bag, and walk away, overheating of the computer, and degradation of the hardware is a very real possibility.


#9

yea, i have it constantly in windows, on my dualboot laptops. They rather go sleeping ok, but always wake up while packed in the bag and then discharge the battery and overheat. While booted to linux though it’s always ok luckily :slight_smile:


#10

Yep, I’m a fan of windows from a technical stand point, but Windows deciding to wake on its own really pissed me off. I started just using windows on the laptop when I needed it, but then would reboot into Ubuntu, and sleep that.