907155 - [B2G][Helix][LCD][wufumin]wake up mobile, LCD backlight normal, but no screen image

Status: VERIFIED FIXED

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

Description

[lecky]

User Agent: Mozilla/4.0 (compatible; MSIE 8.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)

Steps to reproduce:

1.put the phone into sleep modem for time
2.wake up mobile



Actual results:

We can see the picture properly


Expected results:

LCD backlight normal, but no screen image

Comment 1

[lecky]

grab picture from  Framebuffer,we find that the  picture is black.
From this phenomenon, the upper layer is not normal drawing.

Comment 2

[lecky]

Attachment: log.txt

Comment 3

[Wayne Chang [:wchang]]

keven, can you find someone suitable to check this?

Thanks

Comment 4

[Keven Kuo [:kkuo]]

Hi! Viral, Marco

Is this the case you worked before?

--
Keven

Comment 5

[Marco Chen [:mchen]]

No, I didn't heard this kind of bug. 

1. Ask for qawanted:

   Hi QA friends,
   Could you help to verify and confirm this bug on our side?

2. Hi lecky,

   Could you give more detail info for STR?
   Ex: 
     a. how much time the device went to sleep will cause this issue or this is not a factor?
     b. What is the fail rate here? 100%~ 0%.
     c. Does any app need to run before suspend?
     d, Could you provide the kernel log & adb logcat for this bug?
        (And please help to figure out it happened on which resuming log.)

Thanks.

Comment 6

[viral [:viralwang]]

As Marco's comment, we need more information on this bug to dig out the root cause.

Comment 7

[lecky]

Hi,Macro Chen

Sorry,reply to you late.

a/b)From current test,we only find two phones.If  restart phone,we find that this problem disappears.so we do not statistical time.we only can  give you an inaccurate time . phone standby for half an hour ,we wake up phone and find no screen image .

d)I have provided some log in the file of log.txt,please check it. and I provide more log in the file of log_8_24.please check them .

thanks

Comment 8

[lecky]

Attachment: log_8_24.rar

Comment 9

[viral [:viralwang]]

Hi Lecky,

In log_8_24, I found the kernel log start at "2013-08-20 11:00:14" and end in "2013-08-20 11:25:35".
There're over 30 times suspend/resume process and wake up sequence looks fine.

I also can not find the symptom "standby for half an hour ,we wake up phone and find no screen image" or similar case in this log.
May I have any timestamp to find the symptom in this log? It will help a lot in this bug.
Thank you.

Comment 10

[lecky]

hi,viral

you can get some information  from log.txt.From log.txt you can find b2g can not running,when wake up mobile.

Comment 11

[lecky]

hi,viral

I add some information 

when wake up,we find tha  framebuffer is empty

Comment 12

[Marco Chen [:mchen]]

Hi Lecky,

Could you to add a log into position as below?
http://mxr.mozilla.org/mozilla-b2g18/source/widget/gonk/nsWindow.cpp#91
Please help to print the variable - mIsOn.
In normal case, we should see this log in every screen off/on. Then it will tell Gecko Window whether the window is nsSizeMode_Minimized or not.

-----------------------

By the way, may I know how the log.txt show b2g can not be running while wake up mobile? Thanks.

Comment 13

[lecky]

Hi Marco,

It's very hard to reproduce this issue. I added the log to print mIsOn. But I don't think the mIsOn has any problem, for the backlight can still off/on.

Can you provide some suggestion from the exist logs?

Comment 14

[Marco Chen [:mchen]]

(In reply to lecky from comment #13)
> Hi Marco,
> 
> It's very hard to reproduce this issue. I added the log to print mIsOn. But
> I don't think the mIsOn has any problem, for the backlight can still off/on.
> 
> Can you provide some suggestion from the exist logs?

If it is really hard to reproduce it then I think it's priority can be put into low.

Why I added this log is that the "mIsOn" will effect the Gecko's display (may caused the issue like this bug if that value is abnormal) and it's value is got from kernel side. So I would need your help to gather the log.

As viral said, we can see anything wrong from the adb logcat.
By the way, please help to answer my question on Comment 12 too.

"may I know how the log.txt show b2g can not be running while wake up mobile?
"Thanks.

Comment 15

[lecky]

Hi Marco

I am sorry .I did not describe clearly.my means you can get more information form the log.txt.From the above description,we can know that the framebuffer is empty .I do not know why .

Comment 16

[Marco Chen [:mchen]]

(In reply to Marco Chen [:mchen] from comment #14)
s/we can see/we can't see/

Comment 17

[Marco Chen [:mchen]]

(In reply to Marco Chen [:mchen] from comment #12)
> Hi Lecky,
> 
> Could you to add a log into position as below?
> http://mxr.mozilla.org/mozilla-b2g18/source/widget/gonk/nsWindow.cpp#91
> Please help to print the variable - mIsOn.
> In normal case, we should see this log in every screen off/on. Then it will
> tell Gecko Window whether the window is nsSizeMode_Minimized or not.
> 
> -----------------------

What I suspect is on the comment 12, so we need your help to add the log and verify it.
Thanks.

Comment 18

[Marco Chen [:mchen]]

Hi Peter,

Please help to provide which position we need to add the logs for analyzing this issue.
According it is hard to reproduce, partner asked us to add any possible logs for analysis.

Thanks.

Comment 19

[Peter Chang[:pchang]]

(In reply to Marco Chen [:mchen] from comment #18)
> Hi Peter,
> 
> Please help to provide which position we need to add the logs for analyzing
> this issue.
> According it is hard to reproduce, partner asked us to add any possible logs
> for analysis.
> 
> Thanks.

Please refer below for more detail drawing/composition logs.

About composition, please add log in below code lines.
http://mxr.mozilla.org/mozilla-b2g18/source/gfx/layers/opengl/LayerManagerOGL.cpp#680

screen on events
http://mxr.mozilla.org/mozilla-b2g18/source/widget/gonk/nsWindow.cpp#130

screen off events
http://mxr.mozilla.org/mozilla-b2g18/source/widget/gonk/nsWindow.cpp#126

add logs for drawing
http://mxr.mozilla.org/mozilla-b2g18/source/layout/base/nsPresShell.cpp#5285

BTW, are you able to use adb when problem happened?
If so, please also use adb shell "echo w > /proc/sysrq-trigger" to dump kernel stack.

Comment 20

[bweng]

I have tried this issue for 5 times but could not reproduce it. 

The build I am using is 

Build Identifier: 20130904042205

Comment 21

[lecky]

(In reply to bweng from comment #20)
> I have tried this issue for 5 times but could not reproduce it. 

The build
> I am using is 

Build Identifier: 20130904042205

It is a low probability problem, about 1%, we find it appears on 3 devices from current test.
It is hard to reproduce but critical issue.

Comment 22

[lecky]

(In reply to peter chang[:pchang] from comment #19)
> (In reply to Marco Chen [:mchen] from comment #18)
> Hi Peter,
> 
> Please
> help to provide which position we need to add the logs for analyzing
> this
> issue.
> According it is hard to reproduce, partner asked us to add any
> possible logs
> for analysis.
> 
> Thanks.

Please refer below for more
> detail drawing/composition logs.

About composition, please add log in below
> code lines.
> http://mxr.mozilla.org/mozilla-b2g18/source/gfx/layers/opengl/
> LayerManagerOGL.cpp#680

screen on events
> http://mxr.mozilla.org/mozilla-b2g18/source/widget/gonk/nsWindow.cpp#130
> screen off events
> http://mxr.mozilla.org/mozilla-b2g18/source/widget/gonk/nsWindow.cpp#126
> add logs for drawing
> http://mxr.mozilla.org/mozilla-b2g18/source/layout/base/nsPresShell.cpp#5285
> BTW, are you able to use adb when problem happened?
If so, please also use
> adb shell "echo w > /proc/sysrq-trigger" to dump kernel stack.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

adb shell "echo w > /proc/sysrq-trigger" to dump kernel stack.
where is the kernel stack saved?

Comment 23

[viral [:viralwang]]

please make sure "/proc/sys/kernel/sysrq" is 1 to enable the function
"echo w > /proc/sysrq-trigger" will dump kernel stack in kernel log

Comment 24

[Wayne Chang [:wchang]]

Lecky please provide new logs when you have reproduced this with the additional debug messages.

Comment 25

[lecky]

Attachment: wakeup_no_display_2013_9_12+19.51.40.zip

Comment 26

[lecky]

(In reply to Wayne Chang [:wchang] from comment #24)
> Lecky please provide new logs when you have reproduced this with the
> additional debug messages.


//reply:
1.we reproduce the issue with the logs, please see the applogcat-log(pay attention to the "d00204688", which log is you suggested)
2.and also "echo w > /proc/sysrq-trigger" "echo t > /proc/sysrq-trigger" saved in sysrqlog.txt

Comment 27

[lecky]

Hi,

I found the following log:
09-23 17:49:57.556: D/HWComposer(158): Layer has planar semitransparency which is unsupported
09-23 17:49:57.556: D/HWComposer(158): Render aborted. Nothing was drawn to the screen

so this issue is because "Render aborted. Nothing was drawn to the screen",
how to know the reason?

Thanks.
027-59599479l.

Comment 28

[lecky]

Hi,

I would like to add some infomation.
When the Firefor phone is in the low power state(About 10% ), and make it in the standby state for more than 1 hours. 
it is very easy to appear the problem.


Thanks.
027-59599479l.

Comment 29

[Wayne Chang [:wchang]]

Marco/Peter/Viral,

Someone checking this here? :)

We need some analysis on this before deciding if we should block on this and for which release.

Lecky, How frequent does it happen with the conditions mentioned in comment 28?

Comment 30

[lecky]

Hi Wayne,

It's very high probability.

Thanks.

Comment 31

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

(In reply to lecky from comment #27)
> Hi,
> 
> I found the following log:
> 09-23 17:49:57.556: D/HWComposer(158): Layer has planar semitransparency
> which is unsupported
> 09-23 17:49:57.556: D/HWComposer(158): Render aborted. Nothing was drawn to
> the screen
> 
> so this issue is because "Render aborted. Nothing was drawn to the screen",
> how to know the reason?
> 
> Thanks.
> 027-59599479l.

Hi lecky,
Currently, hwc doesn't support semitransparency layer. When we have semitransparency layer, it will fall back to gl composer and show this message.
When we have semitransparency layer or have too many layers that hwc can't support, it will show "Render aborted. Nothing was drawn to the screen" message.
In this case, we need to check whether gl composer works correctly

Comment 32

[Wayne Chang [:wchang]]

ni?reporter for comment 31

please follow up with jerry on this case.

Comment 33

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

Hi lecky,
In attachment 803672 [details], could you tell me which log file presents the wakeup_no_display problem?
There are a lot of logs.

Comment 34

[viral [:viralwang]]

Hi Lecky,

I think the log is /kmsg_logcat/bugreport.log, is that right?

Here's another question about time stamp.
bugreport.log end at [09-12 19:45:25] but sysrqlog.txt only capture during [09-12 20:31:35] to [09-12 20:33:10]
Any more information about the time stamp for us to understand the when the issue happened?
Thank you.

Comment 35

[Wayne Chang [:wchang]]

If this is easily reproduced as comment 30 suggests, it needs to be resolved.
Setting hd+ here, if the root cause found also impacts other releases we should revisit the blocking flag.

Comment 36

[lecky]

Attachment: screen-off-on-no display log.rar

Comment 37

[lecky]

Hi all,

please see this problem log in screen-off-on-no display log.rar. or refer to the wakeup_no_display_2013_9_12+19.51.40.zip.

Thanks.

Comment 38

[viral [:viralwang]]

Hi Lecky,

in screen-off-on-no display log.rar, the time start [09-23 17:49:57.456] and end [09-23 17:49:59.156]
It means we met screen all black in this period? or any useful time stamp can provide?

The time stamp is most important part for us to identify the root cause of the issue, could you please also help to provide it when you upload log?

Also, please let me collect the information we have now:
1. when issue happened, it can not recovery, you can only have normal backlight behavior. So when you press home key, you can only see the backlight turn on. What if you press home key again, the backlight will be off or not?

2.Since the bug easily found when low power, is it possible that the power become even lower after 1hr standby? Shall all HW components like GPU/CPU can still work in such low voltage?

3. how often the reproduce rate is, you mention it's very high probability. That means >10%? >1%? or > 0.1%?
Shall this bug can found in all devices or in some specific devices?

Thank you.

Comment 39

[lecky]

Hi viral,

I have uploaded a new log in attachment, we reproduced this issue again.
please see screen on-off log in After_the_bug and logcat log in After_the_bug\bugreports\applogcat-log.

1, When issue happened, it only have backlight, and it can not recovery unless you reboot. When you press home key, only backlight turn on, no image, when you press power key again, the backlight turn off. But when you reboot phone, it's normal again.
So I think this is because the b2g process is restarted, so it becomes normal.  

2, We did a comparison test, the same HW component it can work on Android device, so how much voltage the Foirfox OS need to complete the drawing layer? I found a few of problem that drawing layer or loading layer. for example, when power on, the full screen display white.

3, This issue is very high probability, because we found this problem on many different devices. 
In these two days, we reproduced two times again.
So we need your help to analyze this issue.

I hope you to reproduce this issue, this is very important if you want to resolve this problem.


Thanks.

Comment 40

[lecky]

Attachment: After_the_bug.rar

Comment 41

[Wayne Chang [:wchang]]

Lecky,

We will need your help to reproduce this issue and provide valuable information, even better if you can do some debugging on your end too as we do not have as many devices as you have that can be used to test this.

Please also always make sure you can find this issue on Mozilla builds without your own modification too, as this is what we will be checking.

Comment 42

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

(In reply to lecky from comment #40)
> Created attachment 810904 [details]
> After_the_bug.rar

1.
There are some error message from qcom hwc library.

"09-26 21:07:47.359: ERROR/libQcomUI(161): sfdump: Layer[1] private-handle is invalid"

Is that normal? We can't find these error message in my device(not helix).

2.
In file applogcat-log.3 line:2621, this is the last print of "PresShell:Paint Draw" message.

09-26 14:41:07.439 I/Gecko   (  158): [Parent 158] WARNING: d00204688 PresShell::Paint drawing!

Is this the start point the no screen issue happened?

And In file kmsgcat-log, There are also some hwc error message.
09-26 14:41:04 <3>[280, Compositor] [   97.102926] mdp_ppp_verify_req(): Error in Line 1212
09-26 14:41:04 <3>[280, Compositor] [   97.102941] mdp_ppp: invalid image!
It might releate to the display problem.

3.
These log came from 09/03 to 09/26 21:00. Could you provide the only log containing the issue and the exact time stamp when this issue happened?

Comment 43

[lecky]

Hi Jerry,

1, Too many problems on this base-line, so we have updated the kerne, in order to analyze this isssue, I open the libQcomUI log switch, so you can see this log, but I also don't know whether this is normal.
How to confirm whether this is normal?

2, About hwc error log, it't normal, because it has happened on a normal phone. I can't understand you mean that "is that the start point the no screen issue happened", I suggest we talk about this issue with telephone. I think it happened before.

3, These log olny belong to this issue, no another, please see srceen-on-off log, they are printed when this issue occures, so it's valuable I think.

Thanks.
027-59599479.

Comment 44

[lecky]

Hi all,

We repeatedly verified, this issue is very easy to reproduce if it is in the low power condition.
So it's very serious, because it's very easy to enter low power when a user uses a phone.

Thanks.

Comment 45

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

(In reply to lecky from comment #44)
> We repeatedly verified, this issue is very easy to reproduce if it is in the
> low power condition.
> So it's very serious, because it's very easy to enter low power when a user
> uses a phone.

Hi viral,
Can we reproduce this issue on our helix device?
I think we need a real device for debugging.

Comment 47

[lecky]

Hi William,

Note: this issue is no screen image in the device, the full screen is black, don't display anything.
The bug 921829 describes that the full screen display a white image.

This is a very serious problem, I have already explained.

Hi Wayne,

can you tell me, whether someone is working on this issue?

Thanks.

Comment 48

[Marco Chen [:mchen]]

(In reply to lecky from comment #44)
> Hi all,
> 
> We repeatedly verified, this issue is very easy to reproduce if it is in the
> low power condition.
> So it's very serious, because it's very easy to enter low power when a user
> uses a phone.
> 
> Thanks.

If this issue is more easy to reproduce on low power mode, may I suspect that this is related to the sequence/level/timing issue of power on/off signals on panel?

Comment 49

[Wayne Chang [:wchang]]

Marco,

Please have an assignee on this so it gets ownership.

Thanks

Comment 50

[Marco Chen [:mchen]]

(In reply to lecky from comment #39)
Hi Lecky,

We are still on trying to reproduce it but we can't until now.
So please help us to do some experiment since it is easy to reproduce it now. Very Thanks.

> 1, When issue happened, it only have backlight, and it can not recovery
> unless you reboot. When you press home key, only backlight turn on, no
> image, when you press power key again, the backlight turn off. But when you
> reboot phone, it's normal again.
> So I think this is because the b2g process is restarted, so it becomes
> normal.  
> 

Experiment 1:
  You said that "reboot phone and it's normal because b2g process is restarted". This sentence is not precise,
  because the display driver is restarted too.
  So could you help to verify by this way?
    a. To reproduce this issue.
    b. After reproducing it, to restart the b2g only by "adb shell stop b2g" and "adb shell start b2g"

  This case will skip to restart the display driver (kernel) and only test whether restarting b2g can recover this or not.

Experiment 2:
  a. Please try to draw a display area to red color (or others) in display or fbmem driver before every action of pan display called by b2g.
  b. Please add a log before pan display to show whether b2g tried to call it.
  c. To reproduce this issue.

  After reproducing it, 
    - if the log of pan display didn't be shown then b2g need to be investigated.
    - if log is shown and there is still no any screen, display driver should be investigated.
    - if log is shown and there is a area with red color, b2g need to be investigated.

Thanks for your effort on testing them.

Comment 51

[lecky]

Hi  Marco,

> Experiment 2:
>   a. Please try to draw a display area to red color (or others) in display or fbmem driver before every action > of pan display called by b2g.
>   b. Please add a log before pan display to show whether b2g tried to call it.
>  c. To reproduce this issue.

For experiment 1, I will test on it.
For experiment 2, where I should need to add these, how to do, because I'm not familiar with the process.

Thanks.

Comment 52

[viral [:viralwang]]

flag is no need now, I can not reproduce it in my side

Comment 53

[Marco Chen [:mchen]]

(In reply to lecky from comment #51)
> For experiment 2, where I should need to add these, how to do, because I'm
> not familiar with the process.
> 
> Thanks.

Hi, please refer to https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/drivers/video/fbmem.c#n843

Please add a kernel log there to represent any one try to swap buffer for displaying next frame.
And try to modify a partial area of framebuffer there for ensuring frame is output and displayed by panel normally.

Comment 54

[lecky]

(In reply to Marco Chen [:mchen] from comment #50)
> (In reply to lecky from comment #39)

> Experiment 1:
>  You said that
> "reboot phone and it's normal because b2g process is restarted". This
> sentence is not precise,
>  because the display driver is restarted too.
>  So
> could you help to verify by this way?
>    a. To reproduce this issue.
>    b.
> After reproducing it, to restart the b2g only by "adb shell stop b2g" and
> "adb shell start b2g"

>  This case will skip to restart the display driver
> (kernel) and only test whether restarting b2g can recover this or not.

I have reproduced it, , the display normal after restarting b2g, it shows the homescreen image.
the problem occurs from gecko, right?

Thanks.

Comment 55

[lecky]

Hi Marco,

I got the framebuffer content, but it's atramentous, I compared the normal phone, it's displayed the locked-screen image in the framebuffer.

I have found the method which is very easy to reproduce this issue.
This issue occurs every time If you use this method, maybe I can't describe, I'm sorry, but we can telephone exchange.

Tel:[phone].
Thanks.

Comment 56

[Marco Chen [:mchen]]

(In reply to lecky from comment #55)
> I have found the method which is very easy to reproduce this issue.
> This issue occurs every time If you use this method, maybe I can't describe,
> I'm sorry, but we can telephone exchange.

Thanks for this information. If we can reproduce it on our local side then we have more chance to investigate it.

By the way, please give me the moz build version including gaia and gecko which can reproduce this issue with your steps.

Comment 57

[Marco Chen [:mchen]]

After I got the moz build version, I will check the steps with you.

Comment 58

[lecky]

Hi  Marco,

(In reply to Marco Chen [:mchen] (Business Trip 10/21 ~ 10/23) from comment #56)
> By the way, please give me the moz
> build version including gaia and gecko which can reproduce this issue with
> your steps.

Is that what you want?
gaia:
commit dc8f0a4528d93573d566b717d268ead5553959eb
Author: Anthony Ricaud <[e-mail]>
Date:   Tue Oct 22 14:14:02 2013 +0200

    Bug 911010 - [B2G][Helix][dialer][tongxiao]The emergency call Interface ... r=rik

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 59

[Marco Chen [:mchen]]

Hi Lecky,

Yes, then I will use this base to reproduce the issue.
Please provide me the steps. Thanks.

Comment 60

[lecky]

Hi Marco,


I'm sorry, maybe I can't clearly describe, do you have some time, please call me.

Thanks.
Tel:[phone].

Comment 61

[lecky]

Hi Marco,

How to disable compositor or don't use compositor?

Thanks.

Comment 62

[Marco Chen [:mchen]]

(In reply to lecky from comment #61)
> Hi Marco,
> 
> How to disable compositor or don't use compositor?
> 
> Thanks.

Hi Lecky,

Could you give more detail about this? We need compositor to combine each surface then output to FrameBuffer via GL or HWC.

Comment 63

[Marco Chen [:mchen]]

Hi Lecky,

I used power monitor to set voltage as 3.3V then test this case and I also disabled auto shutdown from Gaia.
The result is that I can't reproduce this issue even the device is in suspend more then 10 minutes.

Q1: If we need to reproduce this under such low voltage then it can't be reproduced from Mozilla build. Because auto shutdown will be triggered. So I don't think this issue can be reproduced on moz build.

Q2: I found that the combination key (power + home) can save one snapshot image of current framebuffer into /sdcard.
    Could you help to capture this snapshot by combination key for checking the framebuffer content at that time slot?

Thanks.

Comment 64

[lecky]

Attachment: 1024_dumplayer.zip

Comment 65

[lecky]

Attachment: 1024_framebuffer.zip

Comment 66

[lecky]

Attachment: analysis_log.zip

Comment 67

[lecky]

Hi Marco,

Please see the attatchment.
1024_dumplayer.zip : layers, it was captured after this issue occurred.
1024_framebuffer.zip: framebuffer content, it was captured after this issue occurred, the framebuffer is atramentous.
analysis_log.zip: I hope that is useful.

I use the following command to get layers, the layer is normal.
1/adb shell setprop debug.sf.dump.enable true 
2/adb shell setprop debug.sf.dump.png 50

I use the following script and tool to get framebuffer, the framebuffer is atramentous, I compared the normal phone, it's displayed the lock screen image in the framebuffer.
script: cat_fb0.bat
tool: ifanview

Thanks.

Comment 68

[lecky]

Hi Marco,

You can adjust voltage to 3.44V~3.56 or more than on moz build, and to do this as many as possible, I advise you to reproduce this on our device if you can.

I have a question, on our platform, 
mLayerManager->GetBackendType() is LAYERS_BASIC, not LAYERS_OPENGL.
What is the difference?

Thanks.

Comment 69

[lecky]

Hi Macro,

It will not be reproduced If you delete shutdown API in battery_manager.js, so please don't delete shutdown API and to reproduce this issue.

Thanks.

Comment 70

[Marco Chen [:mchen]]

Attachment: shutdownlog.patch

Hi Lecky,

Please help to apply shutdownlog.patch into your test then provide the log when you hit this issue.

By the way, I still can't reproduce it on 20131025 eng build. I tried 3.5V and if lower then it device will be auto shutdown.

Comment 71

[Marco Chen [:mchen]]

Hi Peter,

>> mLayerManager->GetBackendType() is LAYERS_BASIC, not LAYERS_OPENGL.
Could you help to answer the question on comment 68? Thanks.

Comment 72

[Peter Chang[:pchang]]

(In reply to lecky from comment #68)
> I have a question, on our platform, 
> mLayerManager->GetBackendType() is LAYERS_BASIC, not LAYERS_OPENGL.
> What is the difference?
> 
> Thanks.

Where do you dump this info? 
Because the content and b2g both of them have their own layermanager.
If you dump above info inside content app, it shows LAYERS_BASIC or LAYERS_CLIENT.
If you dump it inside b2g, it shows LAYERS_OPENGL.

Comment 73

[lecky]

(In reply to peter chang[:pchang] from comment #72)
> Where do you dump this info? 
> Because the content and b2g both of them have their own layermanager.
> If you dump above info inside content app, it shows LAYERS_BASIC or LAYERS_CLIENT.
> If you dump it inside b2g, it shows LAYERS_OPENGL.



Hi peter,

I dump it from gecko/widget/gonk/nsWindow.cpp.

Comment 74

[lecky]

Attachment: log_abnormal_10301725.zip

Comment 75

[Peter Chang[:pchang]]

(In reply to lecky from comment #73)
> (In reply to peter chang[:pchang] from comment #72)
> > Where do you dump this info? 
> > Because the content and b2g both of them have their own layermanager.
> > If you dump above info inside content app, it shows LAYERS_BASIC or LAYERS_CLIENT.
> > If you dump it inside b2g, it shows LAYERS_OPENGL.
> 
> 
> 
> Hi peter,
> 
> I dump it from gecko/widget/gonk/nsWindow.cpp.

You can dump layermanager backend at the following line which will dump it as LAYERS_OPENGL.

About b2g process, it has not only the composition ability but also the drawing ability, just like a content process. In other words, b2g has two layermanger, LAYES_BASIC/LAYERS_CLIENT and LAYERS_OPENGL.

http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/CompositorParent.cpp#644

Comment 76

[lecky]

Hi Macro,

please see the new log in the attachment 824543 [details].

Thanks.

Comment 77

[lecky]

Hi Macro,

Sorry, I replace my log with your shutdownpatch log, but your shutdownpatch log is not output. 
I use dump(""), but you use dump(''), I don't understand, why?

But, please look at "fengximing: sleep_menu.js startPowerOff if getElementById('poweroff-splash') true. return."

In startPowerOff function:
if (document.getElementById('poweroff-splash')) {
        dump("fengximing: sleep_menu.js startPowerOff if getElementById('poweroff-splash') true. return.");
        return;
    }

Thanks.

Comment 78

[lecky]

Attachment: log_abnormal_10301803.zip

from power wake up to screen turn off.

Comment 79

[Marco Chen [:mchen]]

Hi Lecky,

Thanks for your help. And please help again to ensure my logs can be output.
And collect the log to us.

It seems that this issue is related to shutdown animation so I need these log to prove this suspect.

Comment 80

[Marco Chen [:mchen]]

(In reply to lecky from comment #77)
> In startPowerOff function:
> if (document.getElementById('poweroff-splash')) {
>         dump("fengximing: sleep_menu.js startPowerOff if
> getElementById('poweroff-splash') true. return.");
>         return;
>     }

More info.

I saw dump msg above in partner's log and that means there is already a poweroff-splash there.
And due to it's z-index will be highest, I suspect this is the reason that why underlying layer including lock screen can't be display.

Wait for logs with mine from partner for evidence.

Comment 81

[lecky]

Attachment: applogcat-log-1031.zip

Hi Macro,

This includes shutdownpatch log.

Comment 82

[lecky]

Hi Marco,

Please see the applogcat-log at the end.

01-06 00:32:35.021 I/GeckoDump(  162): bug 907155 detect battery low then shutdown 0.02##0.02
01-06 00:32:35.021 I/GeckoDump(  162): bug 907155 sleep_menu.js in
01-06 00:32:35.021 I/GeckoDump(  162): bug 907155 sleep_menu.js dom power is exist
01-06 00:32:35.031 I/GeckoDump(  162): fengximing: sleep_menu.js startPowerOff if getElementById('poweroff-splash') true. return.
01-06 00:32:35.031 I/GeckoDump(  162): bug 907155 after calling SleepMenu.startPowerOff(false)

Comment 83

[lecky]

bug 907155 detect battery low then shutdown 0.02##0.02 
bug 907155 sleep_menu.js in                            
bug 907155 sleep_menu.js dom power is exist            
bug 907155 sleep_menu.js poweroff-splash is not exist  
bug 907155 sleep_menu.js try to load custom logo       
bug 907155 after calling SleepMenu.startPowerOff(false)
bug 907155 sleep_menu.js loaded custom logo            
bug 907155 sleep_menu.js custom is video               
bug 907155 sleep_menu.js video is ended                
bug 907155 sleep_menu.js video unload hw resource ok   
bug 907155 detect battery low then shutdown 0.01##0.02 
bug 907155 sleep_menu.js in                            
bug 907155 sleep_menu.js dom power is exist            
bug 907155 after calling SleepMenu.startPowerOff(false)
bug 907155 detect battery low then shutdown 0##0.02    
bug 907155 sleep_menu.js in                            
bug 907155 sleep_menu.js dom power is exist            
bug 907155 after calling SleepMenu.startPowerOff(false)
bug 907155 detect battery low then shutdown 0##0.02    
bug 907155 sleep_menu.js in                            
bug 907155 sleep_menu.js dom power is exist            
bug 907155 after calling SleepMenu.startPowerOff(false)
bug 907155 detect battery low then shutdown 0.01##0.02 
bug 907155 sleep_menu.js in                            
bug 907155 sleep_menu.js dom power is exist            
bug 907155 after calling SleepMenu.startPowerOff(false)
bug 907155 detect battery low then shutdown 0.02##0.02 
bug 907155 sleep_menu.js in                            
bug 907155 sleep_menu.js dom power is exist            
bug 907155 after calling SleepMenu.startPowerOff(false)

Comment 84

[Marco Chen [:mchen]]

Hi Lecky,

The reason caused to this issue is

  1. After resuming, battery_manager.js found battery is too low then trigger the shutdown flow.
  2. Near the end of playing power-off-video, link as below will add a hide into CSS class then wait for transitioned event.
     https://github.com/mozilla-b2g/gaia/blob/v1.1.0hd/apps/system/js/sleep_menu.js#L239
  3. But it seems to that sometimes transitioned event can't be received from web content.

Q1: Could you help to test the normal shutdown procedures by pressing shutdown from sleep menu?
    We want to see whether this is happened always or occasionally or under a specific condition.

Thanks for your support here.

Comment 85

[lecky]

Attachment: bugreports_normal_shutdown_10311155.zip

Hi Macro,

This is the normal shutdown procedures, please see the new log in bugreports_normal_shutdown_10311155.zip.

bug 907155 detect battery low then shutdown 0.02##0.02
bug 907155 sleep_menu.js in
bug 907155 sleep_menu.js dom power is exist
bug 907155 sleep_menu.js poweroff-splash is not exist
bug 907155 sleep_menu.js try to load custom logo
bug 907155 after calling SleepMenu.startPowerOff(false)
bug 907155 sleep_menu.js loaded custom logo
bug 907155 sleep_menu.js custom is video
bug 907155 sleep_menu.js video is ended
bug 907155 sleep_menu.js video unload hw resource ok
bug 907155 sleep_menu.js elem transitionend callback. calling _actualPowerOff()
bug 907155 sleep_menu.js _actualPowerOff call trunscreenoff
bug 907155 sleep_menu.js after _actualPowerOff call trunscreenoff

Thanks.

Comment 86

[Marco Chen [:mchen]]

Hi,

By the way,

From the log, I can see power-off-video is played to the end already. Could you confirm with you that after resuming you didn't see the power-off-video but only black screen there?

Thanks.

Comment 87

[lecky]

(In reply to Marco Chen [:mchen] from comment #86)
> Hi,

> By the way, 
> From the log, I can see power-off-video is played to the
> end already. Could you confirm with you that after resuming you didn't see
> the power-off-video but only black screen there?

Yes, and it also can press power key, wake up or enter sleep, but it only has backlight, no power-off-video. 
Where does it send transitioned event?

Thanks.

Comment 88

[lecky]

Hi Macro,

I look at source code:
      var video = document.createElement('video');
      video.src = this.videoPath;
      video.setAttribute('autoplay', null);

From the following log, the video has been loaded, but the browser doesn't play video, or it doesn't send transitioned event. How to debug this problem?

bug 907155 logo_loader.js initVideo                          
bug 907155 logo_loader.js initImage                          
bug 907155 logo_loader.js initImage onerror                  
bug 907155 logo_loader.js initVideo onerror                  
bug 907155 logo_loader.js initVideo onnotfound               
bug 907155 detect battery low then shutdown 0.02##0.02       
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 sleep_menu.js poweroff-splash is not exist        
bug 907155 logo_loader.js initVideo                          
bug 907155 logo_loader.js initImage                          
bug 907155 sleep_menu.js try to load custom logo             
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 logo_loader.js initImage onerror                  
bug 907155 logo_loader.js oncanplay                          
bug 907155 logo_loader.js _onLogoLoaded start.               
bug 907155 logo_loader.js _onLogoLoaded this.ready.          
bug 907155 logo_loader.js _onLogoLoaded this.onload.         
bug 907155 sleep_menu.js loaded custom logo                  
bug 907155 sleep_menu.js custom is video                     
bug 907155 logo_loader.js _onLogoLoaded this.onload ok.      
bug 907155 sleep_menu.js video is ended                      
bug 907155 sleep_menu.js video unload hw resource ok         
bug 907155 detect battery low then shutdown 0.01##0.02       
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0##0.02          
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0.01##0.02       
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0##0.02          
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0.01##0.02       
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0##0.02          
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0.01##0.02       
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0##0.02          
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0.01##0.02       
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)      
bug 907155 detect battery low then shutdown 0.01##0.02       
bug 907155 sleep_menu.js in                                  
bug 907155 sleep_menu.js dom power is exist                  
bug 907155 after calling SleepMenu.startPowerOff(false)

Comment 89

[KM Lee [:rexboy] (inactivate after Sep. 22)]

> bug 907155 sleep_menu.js video is ended 
This line indicates that movie has been played to the end. But I'm not very sure why transitionend is not raised.

There are some redundant code here caused by different commits. Actually we can remove codes of adding css transition and just call self._actualPowerOff(reboot) directly; or remove codes of releasing codecs so that fade-out animation can be seen again, instead. I'm not sure if the former can become a workaround for this bug.

diff --git a/apps/system/js/sleep_menu.js b/apps/system/js/sleep_menu.js
index 4da64e1..da4efab 100644
--- a/apps/system/js/sleep_menu.js
+++ b/apps/system/js/sleep_menu.js
@@ -237,7 +237,7 @@ var SleepMenu = {
 
       if (elem.tagName.toLowerCase() == 'video' && !elem.ended) {
         elem.onended = function() {
-          elem.classList.add('hide');
+          self._actualPowerOff(reboot);
           // XXX workaround of bug 831747
           // Unload the video. This releases the video decoding hardware
           // so other apps can use it.

Comment 90

[lecky]

Hi Macro,

I have a modification solution, please review.

diff --git a/apps/system/js/sleep_menu.js b/apps/system/js/sleep_menu.js
index 1ccc1ca..31a046c 100644
--- a/apps/system/js/sleep_menu.js
+++ b/apps/system/js/sleep_menu.js
@@ -10,6 +10,11 @@ var SleepMenu = {
   // Indicate setting status of volume
   isSilentModeEnabled: false,
 
+  /* fengximing/00202490 20131031 begin */
+  // Indicate transitionend event status
+  isRecevieTransitionendEvent: false,
+  /* fengximing/00202490 20131031 end */
+  
   elements: {},
 
   get visible() {
@@ -205,6 +210,16 @@ var SleepMenu = {
         break;
     }
   },
+  
+  /* fengximing/00202490 20131031 begin */
+  checkTransitionendEventStatus: function sm_checkTransitionendEventStatus() {
+      if (self.isRecevieTransitionendEvent) {
+          return true;
+      }
+      self.isRecevieTransitionendEvent = true;
+      return false;
+  },
+  /* fengximing/00202490 20131031 end */
 
   startPowerOff: function sm_startPowerOff(reboot) {
     var power = navigator.mozPower;
@@ -258,10 +273,20 @@ var SleepMenu = {
           }
         });
       }
-
+      
+      /* fengximing/00202490 20131031 begin */
+      setTimeout( function() {
+          if (!self.checkTransitionendEventStatus()) {
+              self._actualPowerOff(reboot);
+          }
+      }, 3*1000);
+      
       elem.addEventListener('transitionend', function() {
-        self._actualPowerOff(reboot);
+        if (!self.checkTransitionendEventStatus()) {
+            self._actualPowerOff(reboot);
+        }
       });
+      /* fengximing/00202490 20131031 end */

Comment 91

[Marco Chen [:mchen]]

Hi Lecky,

Very thanks for you to provide idea here.
And please refer to the link as below for how to summit a patch and ask for the review.
https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch

If you met any problem, please let me know.

-------------------------------

By the way,

The patch you provided is like a workaround on this issue. 
We would need to find out the root cause.
I have a light about this and will summit a patch for a try. Please help.

Comment 92

[lecky]

Okay,  I'd be more than happy to do this.

Thanks.

Comment 93

[Marco Chen [:mchen]]

Attachment: battery_manager_wake_when_low_level.patch

Hi,

Please help to apply this patch for battery_manager.js then to see whether the issue can still be reproduced.

What I suspect

  1. In our code now power state will not be set to 'on' when battery_manager found battery level is low and fire a power off animation.
  2. When device is in suspend and battery_manager fired a power off animation, the display driver/framebuffer is still off according to power state - 'mem'. Which will cause browser window in minimized state. 
  3. I suspect this state will cause another render or layout limitation which prevent transitioned state from firing.

----------------------

I think even this patch can not solve the entire issue, but we still need to wake up screen in order to show power off animation to end user.

Comment 94

[lecky]

Hi Marco,

I'm sorry for replying you so late.

I tested the patch, it looks like normal, Once the battery level less than AUTO_SHUTDOWN_LEVEL, the phone was awakened and displayed the power-off animation, then it has been shutdown.
From user view of point, I think it is great than before.
I don't know whether the patch can completely solve the problem(I worried about wake event), but it's very good I think.

Thank you very much.

Comment 95

[William Hsu [:whsu]]

Change the status. If the bug happens again, please reopen it.
Thanks!

Comment 96

[Marco Chen [:mchen]]

(In reply to William Hsu [:whsu] from comment #95)
> Change the status. If the bug happens again, please reopen it.
> Thanks!

Hi William,

The partner just reported this issue can't be reproduced after applying the attached patch.
So now we are going to review and landing process.

Comment 97

[KM Lee [:rexboy] (inactivate after Sep. 22)]

The patch in comment 93 looks good to me, we may just need some unit test for me.
I can try working on it.

Comment 98

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: patch

Patch with unit test.
I may need some device to confirm this patch works right before starting review.

Comment 99

[Wayne Chang [:wchang]]

(In reply to KM Lee [:rexboy] from comment #98)
> Created attachment 828587 [details]
> patch
> 
> Patch with unit test.
> I may need some device to confirm this patch works right before starting
> review.

William, can you work with Rex here and see what support he needs in terms of testing? Thanks.

Comment 100

[William Hsu [:whsu]]

Hi, Wayne,

Sure! I will contact Rex later to see if there is anything I can do.
Thanks!

Comment 101

[Wayne Chang [:wchang]]

Rex, William, how are we progressing here? :)

Thanks

Comment 102

[William Hsu [:whsu]]

Hi, Wayne,

Many special helix tests occupied my device.
I will handle it tomorrow.
Thanks!

Comment 103

[William Hsu [:whsu]]

--------- Needinfo myself ---------

Comment 104

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: test codes

From my side I tried to reproduce by hard-code some test codes addressed
in attachment.
(or it takes lots of time to drain the battery.)

What I do is mainly apply this test code to allow poweroff be triggered
on a high battery level like 97%. After plugging out USB, I turn off the
screen and wait a while to see if transitionend of shutdown animation is
correctly triggered before/after applying the proposed patch.

I do reproduced the issue before applying the proposed patch, but not
in 100% reproducibility. One of the case is:
plug out USB ->
wait a while -> battery goest down to 94% ->
transitionend not triggered (KO) ->
battery goes down to 93% -> 
transitionend triggered instead.

So the issue do reproduced but not very stable for me. 
Anyway after applying the proposed patch, the animationend
is always called correctly. 

I've heard from William that there are bugs of screen can't be turned
on when battery level is very low, so maybe William would like to
confirm on that?

Comment 105

[Wayne Chang [:wchang]]

Marco,

Suggestions to Rex here to verify his patch? I understand you were able to trigger this issue with particular methods?

Lecky,
I'd also suggest you to take Rex's patch here and test in parallel with your methods.

Thanks

Comment 106

[lecky]

Hi Wayne,

What's Rex's patch?
If it's attachment 828587 [details], I have added "window.dispatchEvent(new Event('wake'))" in the battery_manager.js, and tested it long time, it's normal.

But I haven't add context as attachment 828587 [details] in the battery_manager_test.js.

Thanks.

Comment 107

[Marco Chen [:mchen]]

(In reply to lecky from comment #106)
> Hi Wayne,
> 
> What's Rex's patch?
> If it's attachment 828587 [details], I have added "window.dispatchEvent(new
> Event('wake'))" in the battery_manager.js, and tested it long time, it's
> normal.

Lecky already did the testing on steps we used to reproduce this bug and the result is positive.

Comment 108

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Comment on attachment 828587 [details]
patch

Since this patch seems work for me and lecky, after discussing with William we think we can start reviewing it.

Alive may you help review for this patch? Thanks a lot!

Comment 109

[KM Lee [:rexboy] (inactivate after Sep. 22)]

(In reply to lecky from comment #106)
> Hi Wayne,
> 
> What's Rex's patch?
> If it's attachment 828587 [details], I have added "window.dispatchEvent(new
> Event('wake'))" in the battery_manager.js, and tested it long time, it's
> normal.
> 
> But I haven't add context as attachment 828587 [details] in the
> battery_manager_test.js.
> 
> Thanks.
That's unit test I added.
Unit test codes are not flashed into device thus doesn't affect functionality.

Comment 110

[William Hsu [:whsu]]

I will double check(Verify) the patch after landing on V1.1.0hd.
Thanks for your help!

Comment 111

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

Comment on attachment 828587 [details]
patch

It's fine to hd+ but please see my comment on github for master.

Comment 112

[KM Lee [:rexboy] (inactivate after Sep. 22)]

v1.1.0hd
https://github.com/mozilla-b2g/gaia/commit/85f9a33cc95e04f5fd962ec37fa39eb622136f45

Comment 113

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Comment on attachment 828587 [details]
patch

Thanks for the comments Alive. Since the revision is not quite suitable for v1.1.0hd (due to its division with master) I just committed it to v1.1.0hd above.
And for master, may you review this revised version again?

Comment 114

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Thanks for reviewing, Alive!

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

Comment 115

[William Hsu [:whsu]]

Hi, Rex and all,

Thanks for your help!
I cannot reproduce this bug on latest Mozilla build.
So, I would like to close it.

* The tested Build:
 - Gaia      2d79d8c461262b4d819fba17a0e8cbc03b36b6b1
 - Gecko     http://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/7245241c6c8f
 - BuildID   20131222042202
 - Version   18.0
  => Cannot reproduce