This fixes an bug where the system is prevented from suspending by a
stuck "Waiting for cronjob" mutex.
The wakeup_active count doesn't provide information about system
wakeups, so track the amount of time spent in suspend instead. Also make
sxmo_hook_mnc.sh responsible for deciding if the system has time to
suspend before the next cron job. This makes the suspend code a bit
cleaner.
There are two bugs that can cause the mutex to get stuck:
Bug one: The kernel allows multiple applications to request multiple
wakeup times, if anything else does we will get stuck.
Bug two: /sys/class/wakeup/wakeupN/active_count does not count the
number of times the device woke the system from suspend. It counts the
number of times the device prevented the system from suspending.
Periodically the kernel syncs the system clock to the rtc. When doing
this the rtc subsystem takes a wakelock to prevent the system from
suspending until the time has been updated, which increments
active_count. If this happens while resuming we get stuck.
This is a kernel stack trace I captured of this happening while resuming:
wakeup_source_activate+0
pm_stay_awake+68
rtc_set_time+212
sync_hw_clock+436
process_one_work+520
worker_thread+120
kthread+276
ret_from_fork+16
Signed-off-by: Stacy Harper <contact@stacyharper.net>
329f3bfda9