Mako not always entering suspend (msm_hsic_host wakelock)

[Pat McGowan]

The msm_hsic_host wakelock is being held in which case the suspend is aborted draining the battery.
This does not happen all the time.

[Ricardo Salveti (rsalveti)]

In theory fixed by https://github.com/CyanogenMod/lge-kernel-mako/pull/1, needs to be investigated again once the 4.4 port is done.

[Pat McGowan (pat-mcgowan)]

Bumping importance so we don't forget to verify

[Pat McGowan (pat-mcgowan)]

After moving to 4.4.2 running build #210
Linux ubuntu-phablet 3.4.0-4-mako #25-Ubuntu SMP PREEMPT Tue Feb 18 19:27:57 UTC 2014 armv7l armv7l armv7l GNU/Linux

demsg reports

[ 209.334564] PM: suspend entry 2014-02-27 17:57:07.599820075 UTC
[ 209.334655] PM: Syncing filesystems...
[ 209.423958] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 209.431985] sync done.
[ 209.670440] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[ 209.673401] Suspending console(s) (use no_console_suspend to debug)
[ 209.685823] msm_fb_ext_suspend: Turning off HPD circuitry
[ 209.722356] PM: suspend of devices complete after 45.167 msecs
[ 209.724126] PM: late suspend of devices complete after 1.709 msecs
[ 209.727788] power_suspend_late return 0
[ 209.727819] PM: noirq suspend of devices complete after 3.631 msecs
[ 209.727849] Disabling non-boot CPUs ...
[ 209.728765] msm_pm_enter
[ 209.728765] msm_pm_enter: power collapse
[ 209.728765] msm_mpm_irqs_detectable: cannot monitor 000000,00000000,00000000,00000000,00000000,00000020,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000
[ 209.728765] msm_pm_enter: return
[ 209.728765] Suspended for 0.000 seconds
[ 209.732488] PM: noirq resume of devices complete after 3.143 msecs
[ 209.734747] wakeup wake lock: msm_hsic_host
[ 209.736609] PM: early resume of devices complete after 1.709 msecs
[ 209.743415] msm_fb_ext_resume: Turning on HPD circuitry
[ 209.749824] PM: resume of devices complete after 13.212 msecs
[ 209.750984] Restarting tasks ... done.
[ 209.808423] PM: suspend exit 2014-02-27 17:57:10.063774114 UTC
[ 209.808423] suspend: exit suspend, ret = 0 (2014-02-27 17:57:10.063774114 UTC)
[ 209.808454] active wake lock msm_hsic_host
[ 209.808454] suspend: abort suspend

[Ricardo Salveti (rsalveti)]

Two quite common wakelocks we have: msm_hsic_host and qcom_rx_wakelock.

First one is related with the modem itself, while the second one related with the wifi driver.

From what I could see, there's no easy way to fix the issue with msm_hsic_host, and this is a common issue with default android as well. Many people tried to fix this wakelock, but the issue keeps coming back, so I'd guess we don't have much to do here.

Also tried CM-11 kernel, and the behavior is similar.

One thing I know for sure is that we're currently not requesting the modem to enter in low-battery mode when turning the screen off, and that might be helping the wakelock to be around longer than needed.

As this device is not officially supported by our kernel team (besides critical security fixes), not going to spend much more time on it. Please raise this issue with the kernel team if you think this is a blocker for you.

[Colin Ian King (colin-king)]

With a clean install from yesterday's image I left the mako idle and then ran some analysis on the data from the kernel log to see how well it is now deep sleeping:

Suspends:
  1579 suspends aborted (57.21%).
  1181 suspends succeeded (42.79%).
  total time: 14175.313684 seconds (92.86%).
  minimum: 0.383868 seconds.
  maximum: 792.576755 seconds.
  mean: 12.002806 seconds.

Time between successful suspends:
     0.000 - 0.124 seconds 608 51.53%
     0.125 - 0.249 seconds 0 0.00%
     0.250 - 0.499 seconds 13 1.10%
     0.500 - 0.999 seconds 10 0.85%
     1.000 - 1.999 seconds 523 44.32%
     2.000 - 3.999 seconds 8 0.68%
     4.000 - 7.999 seconds 3 0.25%
     8.000 - 15.999 seconds 8 0.68%
    16.000 - 31.999 seconds 7 0.59%

Duration of successful suspends:
     0.250 - 0.499 seconds 40 3.39%
     0.500 - 0.999 seconds 77 6.52%
     1.000 - 1.999 seconds 225 19.05%
     2.000 - 3.999 seconds 127 10.75%
     4.000 - 7.999 seconds 201 17.02%
     8.000 - 15.999 seconds 176 14.90%
    16.000 - 31.999 seconds 316 26.76%
    32.000 - 63.999 seconds 14 1.19%
    64.000 - 127.999 seconds 2 0.17%
   128.000 - 255.999 seconds 1 0.08%
   256.000 - 511.999 seconds 1 0.08%
   512.000 - seconds 1 0.08%

Suspend blocking wakelocks:
  qcom_rx_wakelock 20 76.92%
  wlan 4 15.38%
  msm_hsic_host 2 7.69%

So for about 92% of the time it was in deep sleep with frequent wakeups that didn't seem to last that long. So all, in all, not too bad.

[Tim Gardner (timg-tpi)]

Pat - given Colin's comments in #5, and that Mako is no longer officially supported, plus this is more likely a user space issue (according to #4), I'm marking this as Won't Fix.

[Pat McGowan (pat-mcgowan)]

Mako is the only officially supported phone atm (in case that makes a difference)

[Tim Gardner (timg-tpi)]

Of course. I'm confusing Mako with Grouper.

[Tony Espy (awe)]

I've added a task for ofono and powerd, as one of the reasons the modem may be holding a wake-lock, is that we never tell it to go into low-power mode when the screen goes off. The RIL defines a request to notify the radio daemon of changes in screen state. The primary purpose of this request is to throttle events from the radio daemon, however there's conjecture ( per comment #4 ) that this state may also affect the modem wakelock.

[Tony Espy (awe)]

I've also added a network-manager task with an importance of Wishlist. We need to put some thought into our current WiFi behavior with regards to sleep. Android has a very rich power management capabilities with respect to WiFi ( eg. keep WiFi on during sleep ). It's possible our lack of such controls means we have little control over the wakelock behavior of the Android WiFi drivers we rely on for mako, and other Touch devices.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

The following PR

https://github.com/rilmodem/ofono/pull/89

enables an interface to set low power mode in the modem (see doc/power-api.txt in the PR). This interface should be used by powerd when the screen changes the state from off to on and vice versa.

Using suspend-blocker, I have seen that the time that msm_hsic_host is locked is reduced substantially when low power mode is enabled. This happens as no events from the modem are produced in this case (for instance, no signal strength change is notified).

[Tony Espy (awe)]

The fix mentioned in comment #11 was released as part of ofono version: 1.12.bzr6868+14.10.20140625-0ubuntu1.

The corresponding powerd fix was released as version: 0.16+14.10.20140707-0ubuntu1, and is contained in image #u118+.

Both tasks updated to FixReleased.