Description: Half of the screen becomes corrupted after flashing to the latest KK build. Note: I used Shallow Flash. Repro Steps: 1) Update a Flame device to BuildID: 20140919063003 2) Observe the display Actual: The screen is corrupted after flashing. Expected: The screen displays properly without corruption. Environmental Variables: Device: Flame 2.1 BuildID: 20140919063003 Gaia: f0f22bb46c881e02524b3991c2587ff8c0a9fc37 Gecko: ab2a88c05a4b Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Notes: Repro frequency: 10%, See attached: https://www.youtube.com/watch?v=Y-H9zAK7ZRg, and logcat

qawanted for reproducibility and branch checks.

Just a quick note, this bug has been seen by several people shallow flashing between 2.1 Flame and 2.2 Flame. Can happen going either way, TO or FROM 2.2. We are certain Shallow Flashing can cause this but unsure at this point if Full Flash can cause this problem. This bug is not 100% and just seems to randomly occur. This issue can be corrected by tapping the power button to turn the screen off and turn it back on. I'll get branch checks done in the next comment.

This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK Actual Results: Screen corruption seen occassionally when a Flame gets done flashing. Repro Rate: 2/10 Environmental Variables: Device: Flame Master KK BuildID: 20140923065343 Gaia: 37b8a812c642ca616bf9457cb9b71e45261cdfa8 Gecko: 9e193395b912 Version: 35.0a1 (Master) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 ----------------------------------------------------------------- Environmental Variables: Device: Flame 2.1 KK BuildID: 20140922185144 Gaia: 3742913e11f69e789dcb0aa0dedf2e5572da0129 Gecko: df42b05782aa Version: 34.0a2 Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ----------------------------------------------------------------- ----------------------------------------------------------------- This bug does NOT repro on Flame kk build: Flame 2.0 KK, Flame 2.0 KK Base Actual Result: No screen corruption seen when flashing. Repro Rate: 0/10 Environmental Variables: Device: Flame 2.0 KK BuildID: 20140923035745 Gaia: 6449cc35a8f0704d95acac374ba857bde4b86d6c Gecko: b930730dba81 Version: 32.0 (2.0) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ----------------------------------------------------------------- Environmental Variables: Device: Flame 2.0 KK Base BuildID: 20140904160718 Gaia: 506da297098326c671523707caae6eaba7e718da Gecko: Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

[Blocking Requested - why for this release]: Regression, very bad UX, obvious bug / corruption Not adding window-wanted tag - this repro late is too low to do a window against.

Ok so I just got this bug again this morning just by booting up my 2.1 Flame KK device. No flashing needed for this to occur.

I just saw this on the latest KK Flame 2.0 after resetting the device. After resetting it again the screen appeared normal. BuildID: 20140925082640 Gaia: 95a51689acd0488b3ba79abe2423cdcc132fff4a Gecko: bd67c37ece85 Platform Version: 32.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

This is bad so an easy 2.1+ decision. mwu, do you have any thoughts on this?

Very bizarre. Could be a vendor bug - the touch input is working correctly so gecko knows what the real resolution of the device is. I'll try to reproduce.

I cannot tell from the comments if this ever happened after a proper, full flash. I don't think we should block if this is shallow flash problem only. Can somebody verify they see this with full flash?

I just confirmed with a tester who strictly does full flash every day that yes he saw this a day or two ago when full flashing.

Thanks for confirming that. Is "missing /vendor/firmware/keymaster/keymaster.mdt" a relevant error message?

(In reply to Milan Sreckovic [:milan] from comment #11) > Is "missing /vendor/firmware/keymaster/keymaster.mdt" a relevant error > message? No

Unless we get confirmation that this happens on some other device, it appears to be POVB. It also appears rare enough that I can't reproduce it.

Bhavana, see comment 13 - how do we tag POVB issues and who do we CC?

May be worth re-testing this with base image 184?

waiting for QA to retest this with latest base image. In parallel, NI frlee, wesly huang to keep an eye if we to bring this upto vendor.

As feedback of Taipei QA team, no more appearance with base image 184. Waiting NIs responses, if there is no more reported. I think we could remove blocking flag.

hi Mike, may i have your comment on this bug? have you try to report it? so that bobby got feedback from Taipei QA

Brian ask all Taipei QA members today's morning to ensure if anyone ever encounter this problem. I think Bobby may got the report from Brian.

Per comment 17

Not sure about STR, just flash the phone, and I got this(v184). Gaia-Rev 7e2ef41d3ac98757acaf490b5413fb42061ad3e6 Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/75ebb70f8b38 Build-ID 20141009000203 Version 34.0a2 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141009.040900 FW-Date Thu Oct 9 04:09:09 EDT 2014 Bootloader L1TC00011840 http://youtu.be/wMXsYezEFac

3 machines in MTBF lab have this problem. v180 + gecko, gaia, ni walter for more info.

This is reproduced in 180kk and 184kk base. PVT build of 2.1 & 2.2 (184kk) 20140919063003 20140923065343 20141009000203 Frame buffer is ok, and gecko know the correct size of flame. I asked gaia, gecko, and gonk team. The conclusion would be that we should contact the partner to help with this issue. CCing more people for more input and comments

From a quick glance, the screen/framebuffer size read by gecko at boot time is the correct size. Something might have corrupted the GL or hwcomposer or whatever internal state.

(In reply to Eric Chang [:ericcc] [:echang] from comment #22) > Created attachment 8503864 [details] > 2014-10-13 10.24.58.jpg > > 3 machines in MTBF lab have this problem. > v180 + gecko, gaia, ni walter for more info. Does the touch work if you touch the garbage area? Do we have the reproduced machine? I would suggest to enable the "draw tile border" from developer option to check it is related to tiling or not.

The screen shrink to around 60%. However, if you touch the original location that icon or button should be, it will still work fine. Even if you kill the b2g and restart it, it will be the same. However, after someone long press power button for a while, one device recovered. Another device trapped in another bug of high consuming power, and it shut down itself after I saw it. So, we don't have any device with the bug now.

Peter, any idea? Or should we ask vendor to check this problem?

(In reply to Walter Chen[:ypwalter][:wachen] from comment #26) > The screen shrink to around 60%. However, if you touch the original location > that icon or button should be, it will still work fine. > > Even if you kill the b2g and restart it, it will be the same. However, after > someone long press power button for a while, one device recovered. Another > device trapped in another bug of high consuming power, and it shut down > itself after I saw it. So, we don't have any device with the bug now. I just talked to Walter, the problem happened before Gecko was running and couldn't recover by killing b2g. Tapas, is the any HW registers(MDP) we could dump to check the display status?

(In reply to peter chang[:pchang][:peter] from comment #28) > (In reply to Walter Chen[:ypwalter][:wachen] from comment #26) > > The screen shrink to around 60%. However, if you touch the original location > > that icon or button should be, it will still work fine. > > > > Even if you kill the b2g and restart it, it will be the same. However, after > > someone long press power button for a while, one device recovered. Another > > device trapped in another bug of high consuming power, and it shut down > > itself after I saw it. So, we don't have any device with the bug now. > > I just talked to Walter, the problem happened before Gecko was running and > couldn't recover by killing b2g. Tapas, is the any HW registers(MDP) we > could dump to check the display status? What are you specifically interested to know about the state of HWC?

Hi Mike: Since we now have v188 which is also QCT-CS basedm plus an update to newer base AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.095. Would you help check if this issue is available in v188 "based" image? I would like to have vendor to look into after we confirm this can be seen in a pure vendor release. Thank you.

(In reply to Diego Wilson [:diego] from comment #29) > (In reply to peter chang[:pchang][:peter] from comment #28) > > (In reply to Walter Chen[:ypwalter][:wachen] from comment #26) > > > The screen shrink to around 60%. However, if you touch the original location > > > that icon or button should be, it will still work fine. > > > > > > Even if you kill the b2g and restart it, it will be the same. However, after > > > someone long press power button for a while, one device recovered. Another > > > device trapped in another bug of high consuming power, and it shut down > > > itself after I saw it. So, we don't have any device with the bug now. > > > > I just talked to Walter, the problem happened before Gecko was running and > > couldn't recover by killing b2g. Tapas, is the any HW registers(MDP) we > > could dump to check the display status? > > What are you specifically interested to know about the state of HWC? I just re-check the video, the corrupted area is changed if content is changed too. Some UI flows from that video look like no using HWC, therefore, the problem may come from the output of GPU composition. In my opinion, the state of HWC may not help under this condition. Diego, do you have any suggestion to narrow down this issue? One thing we could do is to dump the gl cmds when problem happens by using the following cmds. $ adb shell setprop debug.egl.trace 1

I cannot reproduce this issue with v188 base image only

Assigning to Diego since the next action is on him.

(In reply to Chris Kreinbring [:CKreinbring] from comment #6) > I just saw this on the latest KK Flame 2.0 after resetting the device. > After resetting it again the screen appeared normal. Eric, Does the problem go away for you if you reboot the device?

Nothing obvious from looking at logcat. Can someone share a kernel log too? |adb shell dmesg | tee kernel.txt|

In my case, it goes away by tapping the power button. 1. Flashing a build, issue appears. 2. FTU appears. 3. Screen dims after timeout. 4. Tapping power button, issue goes away. (In reply to Diego Wilson [:diego] from comment #34) > (In reply to Chris Kreinbring [:CKreinbring] from comment #6) > > I just saw this on the latest KK Flame 2.0 after resetting the device. > > After resetting it again the screen appeared normal. > > Eric, > > Does the problem go away for you if you reboot the device?

So this bug is only reproducible in v180 and v184?

Unassigning from me. I can certainly help when this issue has been triaged further.

Hi Eric, If this cannot be reproduced on v188, can we just set RESOLVED WORKSFORME?

We have bug bash in several cities in these 2 days, it would be great to have more devices flashed with v188, let's wait for 2 more days, is that okay? https://quality.mozilla.org/2014/10/bug-bash-on-firefox-os-v2-1/

(In reply to Wesley Huang [:wesley_huang] from comment #39) > Hi Eric, > If this cannot be reproduced on v188, can we just set RESOLVED WORKSFORME? FWIW - I usually see things 'fixed' by new base/firmware closed as fixed instead of WFM - not sure if there is a consensus on that though.

I saw this issue today on 2.2 Flame KK base v188. Environmental Variables: Device: Flame 2.2 Master BuildID: 20141023110739 Gaia: f46d56d812480bff7f3b35e8cacbedfa4d49edc5 Gecko: d8de0d7e52e0 Version: 36.0a1 (2.2 Master) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

It did reproduce with pure v188 base image by Mike. Wesly, Can you ask T2Mobile to have a look on their devie?

I just got the reproduced device from QA. Basically the touch still works as expected, only the display gets vertical shrink. Beside the shrink, there are some flicker lines show up in the left of screen. After checking the mdp and fb state, I think it could be the display driver issue. Diego, any comment to identify the problem? peter@peters-MacBook-Pro:~/flame_corrupt$ adb shell cat ./sys/devices/virtual/graphics/fb0/virtual_size 480,1708 peter@peters-MacBook-Pro:~/flame_corrupt$ adb shell cat ./sys/kernel/debug/mdp/reg 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00010000 0000c000 00000000 00000000 0x00000030: 00000000 00000000 00000840 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 0x00000060: 00040004 00000000 00000000 00000000 0x00000070: 03040310 00000000 00112924 00000000 0x00000080: 00000000 00000000 00000000 00000000 0x00000090: 00000000 00000000 00000000 00000000 0x000000a0: 00000000 00000000 00000000 00000000 0x000000b0: 00000000 00000000 00000000 00000000 0x000000c0: 00000000 00000000 00000000 00000000 0x000000d0: 00000000 00000000 00000000 00000000 0x000000e0: 00000000 00000000 00000000 00000000 0x000000f0: 00000000 00000000 00000000 00000000 peter@peters-MacBook-Pro:~/flame_corrupt$ adb shell cat ./sys/kernel/debug/mdp/stat mdp: underrun: 00000000

attached the kmsg

peter, please keep the power supply of the phone and don't tap on the power button. In that case, we can keep track of it. Thanks.

(In reply to Walter Chen[:ypwalter][:wachen] from comment #46) > peter, please keep the power supply of the phone and don't tap on the power > button. In that case, we can keep track of it. Thanks. sure. Wesly, I suspect this is related to the flame display driver. Please help to contact partner about this issue.

(Got it, Peter) Hi Youlong: pls look into this issue as well, to clarify if it's display driver related, or other root cause. I will add this into our tracking list as well, thanks.

Is there any new status on this one? ccing myself for better tracking of this bug

(In reply to Walter Chen[:ypwalter][:wachen] from comment #49) > Is there any new status on this one? > > ccing myself for better tracking of this bug Dear, sorry for late reply. we'll test on v188, analysis this issue and feedback asap. tks.

(In reply to Wesly Huang from comment #48) > (Got it, Peter) > > Hi Youlong: > > pls look into this issue as well, to clarify if it's display driver related, > or other root cause. > I will add this into our tracking list as well, thanks. hi wesly - about this issue, it can't be reproduced on our side, and we checked the flame_kmsg.txt without any obvious clues. I wanna to confirm first when did you catch this log, while just issue display or any other situation? tks.

(In reply to youlong.jiang from comment #51) > hi wesly - > > about this issue, it can't be reproduced on our side, and we checked the > flame_kmsg.txt without any obvious clues. I wanna to confirm first when did > you catch this log, while just issue display or any other situation? > > tks. Walter, you should have the clearer answer for this question.

Sorry, I don't really understand the question though. It's not like we can reproduce this every time. I'd say we have a probability less than 10% to reproduce this. We got the log when the issue just happened.

(In reply to Walter Chen[:ypwalter][:wachen] from comment #53) > Sorry, I don't really understand the question though. > > It's not like we can reproduce this every time. I'd say we have a > probability less than 10% to reproduce this. We got the log when the issue > just happened. ok. the trouble met is we can't reproduce with serious efforts, and also the log you catch seems not work. could you pls try to cat log one more time for us when issue display, logcat and kernel log. tks.

How many times have you tried? We had a set of PCs in lab trying to reproduce it for few days. Also, we had a person or 2 flashing phones for few days. We could only get few crashes. We have proved that this is something not related to software but hardware. It shouldn't be on our side for now. We could provide if we ever met that again. However, it is not everyday that we flash 188 base image again and again. Please continue the testing work on your side.

(In reply to youlong.jiang from comment #54) > (In reply to Walter Chen[:ypwalter][:wachen] from comment #53) > > Sorry, I don't really understand the question though. > > > > It's not like we can reproduce this every time. I'd say we have a > > probability less than 10% to reproduce this. We got the log when the issue > > just happened. > > ok. > > the trouble met is we can't reproduce with serious efforts, and also the log > you catch seems not work. > > could you pls try to cat log one more time for us when issue display, logcat > and kernel log. > > tks. youlong, If you are looking for kernel log, please check attachment 8510794 [details] which I got it from the reproduced device before. If you don't see any strange, you might need to figure how to debug the problem once we have the reproduce device. Could we dump any register to help the debugging?

Hi Wesly, could you help to follow up this with partner? thanks.

As discussion with Peter, this issue is driver issue. Need partner's help. Set component as vendcom.

(In reply to peter chang[:pchang][:peter] from comment #56) > (In reply to youlong.jiang from comment #54) > > (In reply to Walter Chen[:ypwalter][:wachen] from comment #53) > > > Sorry, I don't really understand the question though. > > > > > > It's not like we can reproduce this every time. I'd say we have a > > > probability less than 10% to reproduce this. We got the log when the issue > > > just happened. > > > > ok. > > > > the trouble met is we can't reproduce with serious efforts, and also the log > > you catch seems not work. > > > > could you pls try to cat log one more time for us when issue display, logcat > > and kernel log. > > > > tks. > > youlong, If you are looking for kernel log, please check attachment 8510794 [details] > [details] which I got it from the reproduced device before. If you don't see > any strange, you might need to figure how to debug the problem once we have > the reproduce device. Could we dump any register to help the debugging? hi peter - we need kernel log and frame buffer data if you reproduce this issue. from 8510794, we can't find any problem, also pls use dmesg to cat kernel when system boot up completely. tks.

(In reply to Bobby Chien [:bchien] from comment #58) > As discussion with Peter, this issue is driver issue. Need partner's help. > Set component as vendcom. Hi Peter: Could you give us a video which reproducing this issue. you have checked the framebuffer and mdp registers from above comments, it is ok, so i will check the LCD driver. I have a question,how to capture the framebuffer on the Firefox OS? so can locate the issue quickly. if it happened after flash all images,what's more , during the U-boot bring up, it maybe the driver timming issue. it maybe transfer error data due to the timming incorrectly. Thanks

I was able to repro this for first time. I loaded v188-1, and shallow flashed gaia and gecko. then I went to B2G/gaia directory, and ran the command BUILDAPP=device make test-integration to run on-device marionette js test. (This is currently under development) (More info here: https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Gaia_integration_tests#Running_tests_on_device) The device froze, then I had to pull out the battery and do a reboot, which caused the bug.

Hi Youlong: If the log in comment#61 is still not for your analysis, pls 1. arrange your QA team to have it repro. for log catching (make sure they understand the procedure) 2. attach the test report here, if they still can't repro. w/ enough effort. Thank you.

(In reply to Wesly Huang from comment #63) > Hi Youlong: > > If the log in comment#61 is still not for your analysis, pls > > 1. arrange your QA team to have it repro. for log catching (make sure they > understand the procedure) > 2. attach the test report here, if they still can't repro. w/ enough effort. > > Thank you. hi wesly - 1. I wanna to confirm that if just reboot system, we could repro this problem, or we must re-flash images. I'll arrange our QAs for more testing. 2. could you pls help to provide method to capture frame buffer, if we reproduce that need this info tks.

@Youlong: Need to re-flash then boot phone. @Peter: do you have any suggestion to T2M, about how to get frame buffer data for analysis?

(In reply to Wesly Huang from comment #65) > @Youlong: > > Need to re-flash then boot phone. > > @Peter: do you have any suggestion to T2M, about how to get frame buffer > data for analysis? youlong, you can try to capture the screenshot to confirm by pressing home+power key or Volume down+power key.

(In reply to peter chang[:pchang][:peter] from comment #66) > (In reply to Wesly Huang from comment #65) > > @Youlong: > > > > Need to re-flash then boot phone. > > > > @Peter: do you have any suggestion to T2M, about how to get frame buffer > > data for analysis? > > youlong, you can try to capture the screenshot to confirm by pressing > home+power key or Volume down+power key. hi wesly - I'll arrange val repro this issue, and if got it on site we'll analysis to step forward. tks.

Thanks Youlong, like mentioned in comment#63 pls also attach your QA's test report if can't repro. it in the end.

peter, screenshot doesn't work for this bug. you should use a camera for taking a picture of the crashed screen

(In reply to Wesly Huang from comment #68) > Thanks Youlong, like mentioned in comment#63 pls also attach your QA's test > report if can't repro. it in the end. Dears, about this issue, we've arranged 3 devices, re-flash 20 times by each one, and not reproduce. so, I think this is a very low rate problem, and how did you got it more than once by a randomly rate. auto test script or any other method? tks.

Hi Walter, would you have some suggestion for the way forward? Is there any method to enable T2M for easily repro. this issue for analysis?

1. It's hard to reproduce sometimes. It still happens every now and on 2. power key + home button for screenshot won't work for this bug. It will take a screenshot without issue. 3. don't use power key, it will recover the phone.

Does this issue have any progress?

Hi! Mike, Is this case still an issue with V18D image? -- Keven

Yes, MTBF machine with v18D-1 base image still encounter this problem occasionally. Hi Youlong, could you help to investigate it again? We still encounter this problem, do you ever reproduce this on you side?

Comment 76 fulfilled the qawanted request.

Wesly, Can you add this to your discussion with vendor here for an update? Thanks

I confirmed again that I met this issue yesterday. However, STR is unclear and conclusion is whatever I mentioned in comment 73. Also, the issue of power consumption is the same.

Hi Youlong, as discussed during today's issue review meeting, pls help arrange your validation team to re-test this one with v18D base image again and let us know if you can repro. it and proceed the investigation. Thank you.

(In reply to Wesly Huang from comment #80) > Hi Youlong, as discussed during today's issue review meeting, pls help > arrange your validation team to re-test this one with v18D base image again > and let us know if you can repro. it and proceed the investigation. Thank > you. hi wesly - I re-arrange our val guys to verify this issue on v18D, with the same test condition on v188, and not reproduced. In my opinion, t2m/moz don't have other effective actions to step forward about this issue. as consider this problem is low-repro., then suggest to waive it. so what you think? tks.

Mike, do we still encounter this issue on v18D?

Yes, but the reproduce rate it lower than 1/20 in QA side

Hi Steven, Per comment 81 and 83. Should we de-nominate this bug from 2.1?

i'm good not to block this on 2.1 as the impact is lowered down.

Closing all intermittent test failures for Firefox OS (since we're not focusing on it anymore). Please reopen if my search included your bug by mistake.

Firefox OS is not being worked on