Renews DHCP lease on suspend

[lool]

Hi and thanks for pm-graph!

NB: I'm just getting familiar with pm-graph tools, I might be using it wrong

I'm running pm-graph from a git checkout (I didn't make install) on an Intel NUC6i7KYB running Ubuntu Desktop 20.04 and connected to a wired network. I'm running this command over SSH:
sudo ./sleepgraph.py -verbose -m mem -rtcwake 15

I can see the system suspends, resumes and the desktop UI comes back on the graphics output, but shortly after that it renews its DHCP lease and I lose my SSH connection.

This is the console output:

lool@rat:~/dev/pm-graph$ sudo ./sleepgraph.py -verbose -m mem -rtcwake 15
Checking this system (rat)...
    have root access: YES
    is sysfs mounted: YES
    is "mem" a valid power mode: YES
    is ftrace supported: YES
    are kprobes supported: YES
    timeline data source: FTRACE (all trace events found)
    is rtcwake supported: YES
    optional commands this tool may use for info:
        turbostat: MISSING
        mcelog: MISSING
        lspci: FOUND
        lsusb: FOUND
        netfix: MISSING
os-version              : Ubuntu 20.04.6 LTS
baseboard-manufacturer  : Intel Corporation
baseboard-product-name  : NUC6i7KYB
baseboard-serial-number : BTKY635005R7
baseboard-version       : H90766-405
bios-release-date       : 03/25/2020
bios-vendor             : Intel Corp.
bios-version            : KYSKLi70.86A.0067.2020.0325.1553
chassis-manufacturer    : Intel Corporation
chassis-version         : 1.0
processor-manufacturer  : Intel(R) Corporation
processor-version       : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz
cpucount                : 8
memtotal                : 16270972 kB
memfree                 : 10837720 kB
INITIALIZING FTRACE
Setting trace buffers to 65536 kB (8192 kB per cpu)
INITIALIZING KPROBES
    kprobe functions in this kernel:
         CPU_OFF: YES
         CPU_ON: YES
         __pm_notifier_call_chain: NO
         acpi_hibernation_begin: YES
         acpi_hibernation_enter: YES
         acpi_hibernation_leave: YES
         acpi_pm_end: YES
         acpi_pm_finish: YES
         acpi_pm_freeze: YES
         acpi_pm_prepare: YES
         acpi_pm_thaw: YES
         acpi_s2idle_begin: YES
         acpi_s2idle_end: YES
         acpi_s2idle_prepare: YES
         acpi_s2idle_prepare_late: YES
         acpi_s2idle_restore: YES
         acpi_s2idle_restore_early: YES
         acpi_s2idle_sync: NO
         acpi_s2idle_wake: YES
         acpi_s2idle_wakeup: YES
         acpi_suspend_begin: YES
         arch_enable_nonboot_cpus_end: NO
         async_synchronize_full: YES
         create_basic_memory_bitmaps: YES
         freeze_kernel_threads: YES
         freeze_processes: YES
         hibernate_preallocate_memory: YES
         ksys_sync: YES
         pm_notifier_call_chain: YES
         pm_prepare_console: YES
         pm_restore_console: YES
         pm_restore_gfp_mask: YES
         pm_restrict_gfp_mask: YES
         resume_console: YES
         suspend_console: YES
         swsusp_write: YES
         sys_sync: NO
         syscore_resume: YES
         syscore_suspend: YES
         thaw_processes: YES
    kprobe functions enabled: 36/40
SUSPEND START
will issue an rtcwake in 15 seconds
client_loop: send disconnect: Broken pipe

I installed turbostat for completeness, but perhaps this is because I didn't make install and netfix is not in place? There is a brief description of netfix in the help output of sleepgraph that it's to fix the network if suspend fails, but suspend does not seem to fail in my case.

I tried doing a few suspend/resumes manually rather than through sleepgraph, and the system keeps its DHCP lease:

sudo rtcwake -s 15
sudo systemctl suspend

I'm attaching the results from the latest run:
suspend-230410-174933.zip

Best,
- LM

[tebrandt]

S3 can sometimes cause havoc on the network on many systems because it fully powers down the devices. It's usually middleware's fault like network manager because it fails to trigger the reconnect. The fact that your sleepgraph run differs from your systemctl run is what concerns me. I think it might be because systemctl is running freeze and not mem. systemctl suspend defaults to whichever mode is selected in /sys/power/mem_sleep. cat out /sys/power/mem_sleep and see which string is in brackets. If it's [deep] then it's running a "mem-deep" aka "mem" aka S3 (and that's bad if sleepgraph -m mem behaves differently). If it's [s2idle] it's running a "mem-s2idle" aka "freeze" aka S2idle (and that's normal that sleepgraph -m mem behaves differently). Freeze doesn't power down the devices so it causes far fewer problems. Try running "sudo ./sleepgraph.py -verbose -m freeze -rtcwake 15" and see if the network is ok after that.

Note that when you pipe "mem" to /sys/power/state it will actually run S3 or S2idle depending on what string is selected in /sys/power/mem_sleep. Sleepgraph specifically sets /sys/power/mem_sleep to "deep" to ensure that you're running S3 when you select "mem". You can also send the mode "mem-s2idle" which sets /sys/power/mem_sleep to "s2idle" and sends "mem" to /sys/power/state to produce a freeze. This produces the same behavior as simply piping "freeze" into /sys/power/state. It's confusing because Raphael tried to make things verbally simple by renaming things but also left the legacy freeze string in there.

[tebrandt]

I just tried this command: 'sudo sleepgraph -cmd "systemctl suspend && sleep 15" -rtcwake 15 -dev -proc' . And it works correctly, demonstrating that the sleepgraph timeline shows either a mem or freeze based on what's in /sys/power/mem_sleep. deep = mem, s2idle = freeze.