933711 - [B2G][Helix][stability][fengximing]When the Firefox phone goes to sleep, wait for long time, if you wake up the phone, it took too much time to enter the lock screen.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P1)

Description

[lecky]

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; aff-kingsoft-ciba; .NET4.0E; .NET4.0C)

Steps to reproduce:

1, hit the power button on friefox phone to put it to sleep.
2, wait for 5 minutes.
3, wake up phone.
4, notice: the wake-up time.


Actual results:

1, From wake up phone to display the lock screen, it took more then 2 senconds(or 3 seconds), this has affected the user's experience. 
But its main problem is a black frame too long before the lock srceen displayed.


Expected results:

1, It should be less than 1 second.

Comment 1

[Wayne Chang [:wchang]]

CJ,
This is what we talked about last week, can you put someone to investigate this?

William, can you check if this occurs on Mozilla build v.s. Partner build?

Comment 2

[lecky]

Hi Wayne,

Sorry, I made a mistake on another bug.

This issue was also found on the Mozilla build, but the time less than our build versionm.

I want to say Yes, the Mozilla build wakes up after 1~1.5 seconds.

Thanks.

Comment 3

[u459114]

Morris, please help to check this issue

Comment 4

[William Hsu [:whsu]]

Hi, Wayne,

I don't know how to precisely measure the response time.
But, as I saw, the response time of commercial build is longer than Mozilla Build.
You can refer to my test video below.

* Test Build:
 + Mozilla Build:
  - Gaia:     366cb29c3ca9a25efcb95ed35d4395e613e099a5
  - Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/369468c97d16
  - BuildID   20131029042204
  - Version   18.0

 + Commercial Build:
  - Gaia:     1389e7b8f76c6b77b979799fafc3862f7c27028d
  - Gecko:   
  - BuildID   20131026030111
  - Version   18.0

Comment 5

[William Hsu [:whsu]]

* https://dc1.safesync.com/LMrHwTtl/WP_20131105_008.mp4?a=rfjlz1W2RXM

You can refer to the video above to know my test result.
The left hand is commercial build and right hand is the Mozilla Build.
Thanks!

Comment 6

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

In my Mozilla build, the response time is shorter than commercial build as well. I'll try to reproduce this issue in my Mozilla build.

Comment 7

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Hello lecky,
Can you give me gaia and gecko version info of your build? Thanks.

Comment 8

[lecky]

(In reply to Morris Tseng [:mtseng] from comment #7)
> Hello lecky, Can you give me gaia and gecko version info of your build?
> Thanks.

gaia:
commit dc8f0a4528d93573d566b717d268ead5553959eb
Author: Anthony Ricaud <[e-mail]>
Date:   Tue Oct 22 14:14:02 2013 +0200


gecko: 
commit 29edf4a3223675bb2518ed60b1760eed058398e1
Merge: 6aa9479 2603cdd
Author: Ryan VanderMeulen <[e-mail]>
Date:   Fri Oct 18 15:47:26 2013 -0400

    Merge b2g18 to 1.1hd. a=merge

Comment 9

[u459114]

Hi Morris, since you are currently working on this issue, assign to you

Comment 10

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

I'm making some experiment

1.I found when device connected to USB cable, the issue may not happened. 
2.I modified gaia's status bar app, remove all icons information update and the issue may not happened too.

Can somebody check above experiments as well and see if the issue happened?

Comment 11

[Jerry Shih[:jerry] (UTC+8) (inactive)]

We can always see the status bar soon when we press the power button.
Then it might take 2s to see the lock screen page.
Should we check the time of getting battery status or the 3g status?

Comment 12

[Wayne Chang [:wchang]]

HD+'ing this, we should have this resolved on v1.1hd before shipping.

Comment 13

[Wayne Chang [:wchang]]

Morris, do you need any help from Gaia on this investigation?

Comment 14

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

I double checked the experiments mentioned at comment 10 and both cases didn't solve issue. Right now I found this issue happens because re-paint event is not triggered when waking the device. I'll try to find root cause for this. Before finding root cause, I think I don't need help from Gaia. Thanks.

Comment 15

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

In the commercial build, I found issue didn't happen when switch to flight mode. Wayne, I need someone from Gaia to check this issue.

Comment 16

[Wayne Chang [:wchang]]

Tim, can anyone work with Morris on this?

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I don't see how flight mode is related ... did you try not entering the flight mode but turn wifi off?

Ian, could you contact Morris and see if he need any Gaia help?

Comment 18

[[e-mail], [e-mail]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #17)
> I don't see how flight mode is related ... did you try not entering the
> flight mode but turn wifi off?
> 
Morris is not able to reproduce the issue while he flashed the specific Gecko/Gaia by himself. He can reproduce it on partner's build from Wayne. In this device, the wifi is not able to turn on. Other trail, if we turn off "Adjust automatically", the issue is reproduced with high rate. Sometimes, it might be reproduced easily while open/close settings app.

William, could you please help Morris to flash correct build version? I see you're able to reproduce it in comment 4. That could be very helpful for debugging.

The follow up action, we could try to find out which module trigger Gecko to repaint first while waking up phone.

Comment 19

[William Hsu [:whsu]]

Hi, Ian,

Thanks for your reminder!
No problem. I will contact Morris later.
:)

Comment 20

[Wayne Chang [:wchang]]

Just to note, the wifi not being able to turn in mentioned in comment 18 is likely due to bug 929423

Comment 21

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Attachment: force-reflow.patch

This patch force apply re-flow when screen is on and looks like issue never happened.

lecky, Can you apply this patch and check if issue still happens?

Comment 22

[William Hsu [:whsu]]

Hi, Wayne,

Sorry for the late information.
Per I discussed this bug with Morris last weekend, we only can reproduce this bug on commercial build.
So, I suggest that we could assign this bug to our partner.

If I was wrong, please correct me.
Thanks!

Comment 23

[lecky]

(In reply to Morris Tseng [:mtseng] from comment #21)
> Created attachment 8333648 [details] [diff] [review] force-reflow.patch
> This patch force apply re-flow when screen is on and looks like issue never
> happened.

> lecky, Can you apply this patch and check if issue still happens?

Hi Morris Tseng ,
force-reflow.patch happened a compile error: 
"gecko/content/base/src/nsFrameLoader.cpp:2600: error: 'rootScrollFrame' was not declared in this scope".

I search 'rootScrollFrame', it's not a global variable.
How to do this?

Thanks.

Comment 24

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Attachment: force-reflow.patch

fix compile error

Comment 25

[lecky]

 Hi Morris,

I modified the patch as follows(add "nsIFrame* rootScrollFrame = presShell->GetRootScrollFrame();"):

  nsCOMPtr<nsIPresShell> presShell;
  if (mDocShell) {
    mDocShell->GetPresShell(getter_AddRefs(presShell));
    if (presShell) {
      nsIFrame* rootScrollFrame = presShell->GetRootScrollFrame();
      presShell->FrameNeedsReflow(rootScrollFrame, nsIPresShell::eResize,
                                  NS_FRAME_IS_DIRTY);
    }
  }

this issue seems to have not been sloved, it still exists.

Thanks.

Comment 26

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Attachment: statusbar_anim.patch

Hi, lecky. Can you please try this patch? This patch add an animation to statusbar and it should trigger re-paint when turning on the screen. I want to make sure if this problem causing by re-paint issue. So, please apply this patch and check if issue still happens.

Comment 27

[lecky]

Hi Morris,

I have tried it, but how to confirm whether this problem causing by re-paint issue?
can you give me a call.
Tel:[phone].

Thanks.

Comment 28

[Nicholas Nethercote [inactive]]

I have a GeeksPhone Keon.  I got an update to 1.1.1.0-GP yesterday and am having similar symptoms.  When I hit the wake-up button, the home button lights up immediately but the display doesn't wake up for at least 0.3--0.5s.  (Previously -- version 1.0.1.0-pre -- both were immediate.)

If I haven't used the phone for a while, the wake-ups are even worse.  Sometimes hitting the wake-up button doesn't even cause the home button to light up and I have to press the wake-up button multiple times and it might take 5 or 10 or 15 seconds to get the screen to wake up.  It's quite annoying.  Occasionally I see the icons in the top bar show up before anything else, but that's not reliable.

Some device info:
- OS version: 1.1.1.0-GP
- Platform version: 18.1
- Build ID: 20131118140310
- Git commit info: 2013-11-17 13:58:06  b585b3241fafa...

I'm happy to do experiments including doing developer debug stuff, though I use this as my day-to-day phone so I don't want to try patches or flash the phone or anything like that.

Comment 29

[Nicholas Nethercote [inactive]]

More data:  this morning when I first touched my phone....

1. I hit the wake-up button
2. About 10 seconds passed with no response
3. Then the home button lit up
4. Then about 0.3--0.5 seconds later the screen woke up

Since then, that's been the general pattern, though the "10 seconds" value is sometimes 0s, sometimes 2s, sometimes 5s...

And again, during step 4 above, occasionally the icon strip at the top of the screen shows up a second or two before the rest of the screen wakes up.

Comment 30

[Josh Matthews [:jdm]]

Out of curiosity, does the lockscreen still show an animation these days? How soon after the screen wakes up does this animation run?

Comment 31

[Nicholas Nethercote [inactive]]

> Out of curiosity, does the lockscreen still show an animation these days?
> How soon after the screen wakes up does this animation run?

Do you mean the bouncing thing that indicates how to unlock the phone?  It runs about 5 seconds after the screen wakes up.

Comment 32

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Attachment: elapsed_time.patch

Hi lecky,
I found there are some events take too long time may cause this issue. Can you apply this patch and when issue happens, save and update log to this bug. Thanks

Comment 33

[lecky]

Hi Morris,

I will test it as soon as possible.

Thanks a lot.

Comment 34

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

I found when wake up phone, the cpu freq may stay in low freq which causes this issue.

lecky, can you set scaling_max_freq to 1008000(i.e. set /sys/devices/system/cpu/cpu0/cpufreq to 1008000) and check if this issue still happen? thanks

Comment 35

[lecky]

Hi Morris,
1,
The scaling_max_freq is 1008000 on our device.
root@android:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq
cat scaling_max_freq
1008000
root@android:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq
cat scaling_min_freq
196608

2,
The patch is invalid, the issue still happen.
If you see "nsWindow.cpp ScreenOnOffEvent Run mIsOn=1", the lock-screen will display quickly.
So I think this happen in the backlight on to display lock-screen image.

the patch log(if you need more, you can tell me.):
01-05 19:17:47.301: I/IdleService(178): ReconfigureTimer: no idle or waiting observers
01-05 19:17:47.301: I/GeckoDump(178): fengximing: shell.js shell_handleEvent start.
01-05 19:17:47.301: I/GeckoDump(178): fengximing: shell.js shell_sendChromeEvent start.sleep-button-press
01-05 19:17:47.311: I/GeckoDump(178): fengximing: shell.js shell_sendEvent start. type:mozChromeEvent
01-05 19:17:47.311: I/Gecko(178): Morris DispatchEvent mozChromeEvent
01-05 19:17:47.311: I/Gecko(178): Morris DispatchEvent wake
01-05 19:17:47.311: I/GeckoDump(178): fengximing: screen_manager.js scm_handleEvent. evt.type:wake
01-05 19:17:47.311: I/GeckoDump(178): fengximing: screen_manager.js scm_turnScreenOn start.
01-05 19:17:47.311: I/GeckoDump(178): fengximing: screen_manager.js scm_setScreenBrightness start.
01-05 19:17:47.311: I/GeckoDump(178): fengximing: screen_manager.js mozPower != null.
01-05 19:17:47.311: I/GeckoDump(178): fengximing: screen_manager.js Actually turn the screen on.
01-05 19:17:47.311: I/GeckoDump(178): fengximing: screen_manager.js scm_turnScreenOn cannot get mozPower.
01-05 19:17:47.311: E/fengximing(178): fengximing: gecko PowerManager::SetScreenEnabled aEnabled:1.
01-05 19:17:47.311: I/Gecko(178): Morris AddEventListener devicelight
01-05 19:17:47.321: I/GeckoDump(178): fengximing: scrren_manager.js scm_reconfigScreenTimeout start.
01-05 19:17:47.321: I/GeckoDump(178): fengximing: windos_manager.js getDisplayedApp start.
01-05 19:17:47.321: I/GeckoDump(178): fengximing: scrren_manager.js scm_reconfigScreenTimeout LockScreen.locked.
01-05 19:17:47.321: I/Gecko(178): Morris AddEventListener moztimechange
01-05 19:17:47.321: I/IdleService(178): Register idle observer 49492f40 for 1 seconds
01-05 19:17:47.321: I/IdleService(178): Register: adjusting next switch from -1 to 1 seconds
01-05 19:17:47.321: I/IdleService(178): next timeout 983 msec from now
01-05 19:17:47.321: I/IdleService(178): SetTimerExpiryIfBefore: next timeout 983 msec from now
01-05 19:17:47.321: I/IdleService(178): reset timer expiry to 991 msec from now
01-05 19:17:47.321: I/IdleService(178): Get idle time: time since reset 19 msec
01-05 19:17:47.321: I/Gecko(178): Morris AddEventListener will-unlock
01-05 19:17:47.321: I/Gecko(178): Morris AddEventListener lockpanelchange
01-05 19:17:47.321: I/GeckoDump(178): fengximing: screen_manager.js scm_fireScreenChangeEvent start.
01-05 19:17:47.321: I/Gecko(178): Morris DispatchEvent screenchange
01-05 19:17:47.331: I/GeckoDump(178): fengximing: bm_handleEvent. evt.typscreenchange
01-05 19:17:47.451: I/Gecko(178): Morris AddEventListener deviceorientation
01-05 19:17:47.451: I/Gecko(178): Morris AddEventListener wifi-statuschange
01-05 19:17:47.451: I/Gecko(178): Morris AddEventListener moznetworkupload
01-05 19:17:47.451: I/Gecko(178): Morris AddEventListener moznetworkdownload
01-05 19:17:47.461: I/GeckoDump(178): fengximing: window_manager.js Event type is mozChromeEvent; Locked state is true; DisplayedApp is app://settings.gaiamobile.org; Inline length is 0
01-05 19:17:47.461: I/GeckoDump(178): fengximing: shell.js shell_handleEvent start.
01-05 19:17:47.461: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:47.461: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:47.461: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:47.461: I/Gecko(178): Morris DispatchEvent devicelight
01-05 19:17:47.461: I/GeckoDump(178): fengximing: screen_manager.js scm_handleEvent. evt.type:devicelight
01-05 19:17:47.461: I/GeckoDump(178): fengximing: screen_manager.js scm_adjustBrightness start.
01-05 19:17:47.461: I/GeckoDump(178): fengximing: screen_manager.js scm_setScreenBrightness start.
01-05 19:17:47.461: I/GeckoDump(178): fengximing: screen_manager.js mozPower != null.
01-05 19:17:47.471: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:47.471: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:47.471: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:47.551: I/GeckoDump(178): fengximing: shell.js shell_handleEvent start.
01-05 19:17:47.551: I/GeckoDump(178): fengximing: shell.js shell_sendChromeEvent start.sleep-button-release
01-05 19:17:47.551: I/GeckoDump(178): fengximing: shell.js shell_sendEvent start. type:mozChromeEvent
01-05 19:17:47.551: I/Gecko(178): Morris DispatchEvent mozChromeEvent
01-05 19:17:47.551: I/GeckoDump(178): fengximing: window_manager.js Event type is mozChromeEvent; Locked state is true; DisplayedApp is app://settings.gaiamobile.org; Inline length is 0
01-05 19:17:47.641: I/Gecko(178): Morris Screen On Watcher
01-05 19:17:47.641: E/fengximing(178): fengximing nsWindow.cpp frameBufferWatcher dispatch Screen On Event
01-05 19:17:47.641: I/Gecko(178): Morris Screen On
01-05 19:17:47.641: E/fengximing(178): fengximing nsWindow.cpp ScreenOnOffEvent Run mIsOn=1
01-05 19:17:47.641: E/fengximing(178): fengximing nsWindow.cpp ScreenOnOffEvent Run sTopWindows=0 sTopWindows.Length=1
01-05 19:17:47.641: E/fengximing(178): fengximing nsWindow.cpp ScreenOnOffEvent Run listener = win->GetWidgetListener
01-05 19:17:47.641: I/Gecko(178): Morris DispatchEvent sizemodechange
01-05 19:17:47.641: I/Gecko(178): Morris DispatchEvent sizemodechange
01-05 19:17:47.641: I/GeckoDump(178): fengximing: shell.js shell_handleEvent start.
01-05 19:17:47.641: I/GeckoDump(178): fengximing: shell.js shell_handleEvent evt.type==sizemodechange.
01-05 19:17:47.961: I/Gecko(178): Morris greater than 100ms, 127056ms, 42e3e670
01-05 19:17:48.051: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.051: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.051: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.071: I/Gecko(178): Morris:	avg:4901.899902 us, max:130864 us, min:6 us, std:18572.427734
01-05 19:17:48.081: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.081: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.081: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.101: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.101: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.101: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.131: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.131: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.131: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.151: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.151: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.151: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.181: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.181: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.181: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.211: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.211: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.211: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.241: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.241: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.241: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.271: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.271: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.271: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.291: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.291: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.291: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.301: I/IdleService(178): Get idle time: time since reset 747 msec
01-05 19:17:48.301: I/IdleService(178): Idle timer callback: current idle time 747 msec
01-05 19:17:48.301: I/IdleService(178): next timeout 252 msec from now
01-05 19:17:48.301: I/IdleService(178): SetTimerExpiryIfBefore: next timeout 252 msec from now
01-05 19:17:48.301: I/IdleService(178): reset timer expiry to 261 msec from now
01-05 19:17:48.321: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.321: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.321: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.351: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.351: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.361: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.391: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.391: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.391: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.421: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.421: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.421: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.461: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.461: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.461: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.491: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.491: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.491: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.521: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.521: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.521: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.551: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.551: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.551: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.561: I/IdleService(178): Get idle time: time since reset 1007 msec
01-05 19:17:48.561: I/IdleService(178): Idle timer callback: current idle time 1007 msec
01-05 19:17:48.561: I/IdleService(178): next timeout 4294967293992 msec from now
01-05 19:17:48.561: I/IdleService(178): SetTimerExpiryIfBefore: next timeout 4294967293992 msec from now
01-05 19:17:48.561: I/IdleService(178): reset timer expiry to 4294967294002 msec from now
01-05 19:17:48.561: I/IdleService(178): Idle timer callback: tell observer 49492f40 user is idle
01-05 19:17:48.561: I/IdleService(178): Get idle time: time since reset 1008 msec
01-05 19:17:48.591: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.591: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.591: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.621: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.621: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.621: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.651: I/Gecko(178): Morris:	avg:5467.770020 us, max:30476 us, min:10 us, std:5989.665527
01-05 19:17:48.651: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager WillPaintWindow.
01-05 19:17:48.651: E/fengximing(178): fengximing: nsWindow::DoDraw GetLayerManager GetBackendType == LAYERS_BASIC.
01-05 19:17:48.651: E/fengximing(178): fengximing: nsWindow::DoDraw sUsingOMTC:1.
01-05 19:17:48.661: I/Gecko(178): Morris DispatchEvent devicemotion


Thanks a lot.

Comment 36

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

(In reply to lecky from comment #35)
> Hi Morris,
> 1,
> The scaling_max_freq is 1008000 on our device.
> root@android:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq
> cat scaling_max_freq
> 1008000
> root@android:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq
> cat scaling_min_freq
> 196608
> 
My fault, actually I want to ask you set "scale_min_freq" to 1008000, not "scale_max_freq". Can you set scale_min_freq to 1008000 and try again? thanks

Comment 37

[lecky]

Hi Morris, 

I modified it, the issue still happen.
root@android:/ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
1008000

I suggest we talk about this with telephone.
For some phenomenon, maybe you need to know. 
Tel: [phone].

Thanks.

Comment 38

[Ben Kelly [:bkelly, not reviewing]]

This sounds similar to the symptoms described in bug 900221 comment 22.  I believe the fix for bug 900221 that landed in b2g18 was flawed in that it did not make DOMRequestHelper observer reference weak.

To test if this is related you could try backporting the fix in bug 924565 to see if that helps here.

Comment 40

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Ben Kelly [:bkelly] from comment #38)
> This sounds similar to the symptoms described in bug 900221 comment 22.  I
> believe the fix for bug 900221 that landed in b2g18 was flawed in that it
> did not make DOMRequestHelper observer reference weak.
> 
> To test if this is related you could try backporting the fix in bug 924565
> to see if that helps here.

Actually, it might be easier to try backing out:

  https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/bcd70a871ade
  https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/e85db8ff0a7c

As I said in comment 38 I don't think this patch solved bug 900221 anyway since the observer reference is still strong.  So if its causing this wake problem then backing it out may just be the best way to go.

Comment 41

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Attachment: backout.patch

this patch backout the change of bug 900221 as comment 40 mentioned.

Comment 42

[u459114]

Morris, please log CPU usage of all threads while screen on.
I don't think nsFrameMessageManager::ReceiveMessage take so much time even if we have more then 600 listeners in queue. It's may because of nsFrameMessageManager thread be suppressed by another thread while screen on.

Comment 43

[an]

I can confirm that the patch in comment 41 does it for my phone (Huawei G300)! Thanks.

Comment 44

[lecky]

Hi Morris,

My build environment has bad, sorry, but I will try the patch and update the result as soon as possible.

Thanks.

Comment 45

[lecky]

Hi Morris,

I have verified the patch, it looks different with before, this patch has a obvious delay when wake up the phone.

Can you contact my colleagues? maybe we can talk about it.

Thanks.

Comment 46

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Hi, Lecky,
I want to align our test environment. What patches I applied are elapsed_time.patch and backout.patch. So you have to apply those two patches and rebuild gecko. After rebuild, flash gecko to device and reboot. After reboot, tweak scaling_min_freq and scaling_max_freq to 1008000 and then our environments are aligned. If this environment still causes issue, please update log to here, thanks.

Comment 47

[lecky]

Hi Morris,

I add elapsed_time.patch and backout.patch to our code, then I change scaling_min_freq and scaling_max_freq to 1008000, about result please see the video in the attachment.

Thanks.

Comment 48

[lecky]

Attachment: bug_ 933711_11281158_VID_0025.3gp

Comment 49

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

At about 11 seconds, I saw you press power button twice very quickly. Bug 919903 mentioned this phenomenon. In other cases, I think the wake up time is less than 1 second?

Comment 50

[lecky]

Hi Morris,

Yes, you are right, at present, each it was less than 1 second, unless the action such as Bug 919903, I will test one time again after the device enter into standby for long time.

What about Bug 919903 now?

Thanks.

Comment 51

[lecky]

Hi Morris,

We can't modify min cpufreq, I think we need to talk about backout.patch, can you contact my colleagues?

Thanks a lot.

Comment 52

[Wayne Chang [:wchang]]

We will not be address bug 919903 (multiple clicks) on v1.1hd. Let's keep this bug's focus on the long wake up time from a single power button press.

(In reply to lecky from comment #50)
> Hi Morris,
> 
> Yes, you are right, at present, each it was less than 1 second, unless the
> action such as Bug 919903, I will test one time again after the device enter
> into standby for long time.
> 
> What about Bug 919903 now?
> 
> Thanks.

Comment 53

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Attachment: merge_920804_and_933070.patch

I think bug 920804 and bug 933070 optimize nsFrameMessageManager which resolved this issue. So I merge those changes to b2g18. Lecky, can you check this patch works or not? thanks.

Comment 54

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Morris Tseng [:mtseng] from comment #53)
> I think bug 920804 and bug 933070 optimize nsFrameMessageManager which
> resolved this issue. So I merge those changes to b2g18. Lecky, can you check
> this patch works or not? thanks.

Morris, it sounds like this patch is a replacement for the backout, correct?  Just want to make sure I understand.  Thanks!

Comment 55

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

Hi Ben,
Yes, I think backout bug 900221 isn't a good idea because backout doesn't resolve both issues. So this patch actually resolve both issues is better solution. Thanks.

Comment 56

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Morris Tseng [:mtseng] from comment #55)
> Yes, I think backout bug 900221 isn't a good idea because backout doesn't
> resolve both issues. So this patch actually resolve both issues is better
> solution. Thanks.

Sounds good to me.  Thanks for tracking down the underlying issues!

Comment 57

[[:fabrice] Fabrice Desré]

Comment on attachment 8341582 [details] [diff] [review]
merge_920804_and_933070.patch

Review of attachment 8341582 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the backport.

Not to sheriffs: That only needs to land on 1.1hd

Comment 58

[Nicholas Nethercote [inactive]]

Once this lands on 1.1hd, any idea how long it will take to make it into a Geeksphone update?  I'd love to have the fix on my phone, but I want to stick with the standard Geeksphone updates, rather than flashing my phone and all that...

Comment 59

[lecky]

Hi Morris,

I will test merge_920804_and_933070.patch and reply you as soon as possible, but about elapsed_time.patch and backout.patch, will it need to be removed?

Thanks.

Comment 60

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

(In reply to lecky from comment #59)
> Hi Morris,
> 
> I will test merge_920804_and_933070.patch and reply you as soon as possible,
> but about elapsed_time.patch and backout.patch, will it need to be removed?
> 
> Thanks.
Yes, you need remove both patches.

Comment 61

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/59d274520709

Comment 62

[lecky]

Hi Morris,

I have merged merge_920804_and_933070.patch, but the screen is black and, and the deive can't boot after the third Logo displayed.


Thanks.

Comment 63

[Morris Tseng [:mtseng] [:Morris] (Inactive)]

I didn't have any problem with this patch. Would you please rebuild you code entirely and try again? Thanks

Comment 64

[lecky]

Hi morris,

I tried it agian, and I compared the code agian, the code is the same with your patch, but the system still does't boot.

Can you contact my colleagues?


Thanks.

Comment 65

[lecky]

Hi Morris,

This patch is effective, Thank you very much.
With our concerted efforts, we saw the FFOS performance gradually improved,

maybe I can't say that, but I still want to say: you are very good!!!
Thank you very much for your support and hard work on this.