• Yifei Liu's avatar
    selftests: breakpoints: use remaining time to check if suspend succeed · c66be905
    Yifei Liu authored
    step_after_suspend_test fails with device busy error while
    writing to /sys/power/state to start suspend. The test believes
    it failed to enter suspend state with
    
    $ sudo ./step_after_suspend_test
    TAP version 13
    Bail out! Failed to enter Suspend state
    
    However, in the kernel message, I indeed see the system get
    suspended and then wake up later.
    
    [611172.033108] PM: suspend entry (s2idle)
    [611172.044940] Filesystems sync: 0.006 seconds
    [611172.052254] Freezing user space processes
    [611172.059319] Freezing user space processes completed (elapsed 0.001 seconds)
    [611172.067920] OOM killer disabled.
    [611172.072465] Freezing remaining freezable tasks
    [611172.080332] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
    [611172.089724] printk: Suspending console(s) (use no_console_suspend to debug)
    [611172.117126] serial 00:03: disabled
    some other hardware get reconnected
    [611203.136277] OOM killer enabled.
    [611203.140637] Restarting tasks ...
    [611203.141135] usb 1-8.1: USB disconnect, device number 7
    [611203.141755] done.
    [611203.155268] random: crng reseeded on system resumption
    [611203.162059] PM: suspend exit
    
    After investigation, I noticed that for the code block
    if (write(power_state_fd, "mem", strlen("mem")) != strlen("mem"))
    	ksft_exit_fail_msg("Failed to enter Suspend state\n");
    
    The write will return -1 and errno is set to 16 (device busy).
    It should be caused by the write function is not successfully returned
    before the system suspend and the return value get messed when waking up.
    As a result, It may be better to check the time passed of those few
    instructions to determine whether the suspend is executed correctly for
    it is pretty hard to execute those few lines for 5 seconds.
    
    The timer to wake up the system is set to expire after 5 seconds and
    no re-arm. If the timer remaining time is 0 second and 0 nano secomd,
    it means the timer expired and wake the system up. Otherwise, the system
    could be considered to enter the suspend state failed if there is any
    remaining time.
    
    After appling this patch, the test would not fail for it believes the
    system does not go to suspend by mistake. It now could continue to the
    rest part of the test after suspend.
    
    Fixes: bfd092b8 ("selftests: breakpoint: add step_after_suspend_test")
    Reported-by: default avatarSinadin Shan <sinadin.shan@oracle.com>
    Signed-off-by: default avatarYifei Liu <yifei.l.liu@oracle.com>
    Signed-off-by: default avatarShuah Khan <skhan@linuxfoundation.org>
    c66be905
step_after_suspend_test.c 4.77 KB