877215 - [System] Device does not enter cpu idle state (AP's core 0 voltage)

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P1)

Description

[Julien Wajsberg [:julienw]]

+++ This bug was initially created as a clone of Bug #853698 +++

1. Title : Device does not enter cpu idle state (AP's core 0 voltage)
2. Precondition : Turn on deivce
3. Tester's Action : Check device state after turn on.
4. Detailed Symptom :  When device is turned on, the AP's core voltage never goes down.
5. Expected : Device should enter cpu idle state (AP's core 0 voltage), when there is no input for certain period of time.
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia revision : 

From Bug 853698 comment 4, it seems that the lockscreen animation prevents the cpu from entering the idle state.

We should stop/restart the animation using the page visibility API to make this possible.

Comment 1

[Leo]

Marking this for work week as per the discussion.

Comment 2

[Andreas Gal :gal]

Attachment: patch, untested

Julien, can you please test and grab/land if you like it?

Comment 3

[Andreas Gal :gal]

visibilityChange -> visibilityChanged typo, please fix

Comment 4

[Wayne Chang [:wchang]]

Alive, I think Julien is out for a week, perhaps you can help with this?

thanks,
Wayne

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

Taken.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Looks like :gal has a patch, so switch the assignee.
The patch looks all good to me.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/10098

See comment above, :gal made this patch and I am going to r+ it.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 755729 [details]
https://github.com/mozilla-b2g/gaia/pull/10098

r=alive

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

master
https://github.com/mozilla-b2g/gaia/commit/574b8e4f0050764ed47d49bc0032a0a8863ae868

v1-train
https://github.com/mozilla-b2g/gaia/commit/0bfcaf8546c6d365b0474d980a154d859d22c872

Comment 10

[Leo]

Tester checked this patch, but when applying this patch, device does not enter cpu idle state

So, I change status to ReOpen.

Comment 11

[Andreas Gal :gal]

leo team, there might be another reason why the sleep state is not reached, but we need some diagnosis here. Do you know why the idle state is not entered?

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

I think the patch is a reasonable fix though it doesn't fix leo's problem. I propose to open another follow(yeah I know this is already a followup) instead of reopening this one.
Does this make sense?

Comment 13

[Leo]

When I role back patch of Bug 838486(apply master git on 3/13), tester said device can enter CPU Idle state.

Patch of Bug 838486 relates lockscreen.js and this patch too.

So, I think system app engineer analyze Patch of Bug 838486, and keep state of this bug.

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Leo from comment #13)
> When I role back patch of Bug 838486(apply master git on 3/13), tester said
> device can enter CPU Idle state.
> 
> Patch of Bug 838486 relates lockscreen.js and this patch too.
> 
> So, I think system app engineer analyze Patch of Bug 838486, and keep state
> of this bug.

Nice, but the patch of 838486 looks pretty simple and irrelavant to CPU idle...
Me or yuren may investigate it.

Comment 15

[Jason Smith [:jsmith]]

Yes, let's open another followup. Generally, we should avoid reopening bugs and open followups, given how we track landings in bugzilla.

Comment 16

[Wayne Chang [:wchang]]

Leo has filed bug 878142 as a followup.

Comment 17

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

found this wakelock hold even screen off.
<6>[1980-01-07 05:45:59 KST][  214.146141] active wake lock unknown_suspend, time left 173

Comment 18

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

We can use this command to get who hold the wakelock
1. adb shell "echo 15 > /sys/module/wakelock/parameters/debug_mask"
and you can run 
2. adb shell cat proc/kmsg, found this suspect:

<6>[1980-01-07 07:21:46 KST][  736.872334] active wake lock unknown_suspend, time left 173

Comment 19

[leo.bugzilla.gecko]

"unknown suspend" is wakelock-timeout message for resolving the issue from deep-sleep to wake state.
We think it is not root cause.

Comment 20

[Andreas Gal :gal]

leo, do you still any other timers firing when the device is idle?

Comment 21

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

hi Leo, can you provide waht is the current power comsumation that you measure?

Comment 22

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

typo, consumption

Comment 23

[leo.bugzilla.fw]

(In reply to Randy Lin [:rlin] from comment #21)
> hi Leo, can you provide waht is the current power comsumation that you
> measure?

The current is about 178 mA.

Comment 24

[leo.bugzilla.fw]

(In reply to Andreas Gal :gal from comment #20)
> leo, do you still any other timers firing when the device is idle?

Yes, still firing in idle state.