[Device] Flame --------------------------------------------- [Reproduction build] - v10F-3 + PVT mozilla-central Gaia 4f352142a54f7f7ae2c460aad9049eda4b0edb14 Gecko https://hg.mozilla.org/mozilla-central/rev/9ac3e2dd0898 BuildID 20140508160203 Version 32.0a1 --------------------------------------------- [Reproduce Steps] 1. "adb reboot bootloader" to fastboot 2. "fastboot oem mem 256" to set memory as 256MB 3. fastboot reboot --------------------------------------------- [Expected Result] Reboot normally --------------------------------------------- [Actual Result] Cannot boot to gecko Only use v10F-3 is fine --------------------------------------------- [Reproduce Rate] 100%

i can reproduce this on my flame, master/m-c build. when doing the above, gecko is stuck in the FF splash screen booting.

QA Wanted to check if this reproduces on the latest 1.3 base image.

(In reply to Jason Smith [:jsmith] from comment #2) > QA Wanted to check if this reproduces on the latest 1.3 base image. I am stuck on 'Firefox OS' static logo screen after executing step 1. Tested on Open C with FFOS_US_EBAY_P821A10V1.0.0B06 base image.

(In reply to Pi Wei Cheng from comment #3) > (In reply to Jason Smith [:jsmith] from comment #2) > > QA Wanted to check if this reproduces on the latest 1.3 base image. > > I am stuck on 'Firefox OS' static logo screen after executing step 1. > Tested on Open C with FFOS_US_EBAY_P821A10V1.0.0B06 base image. That isn't what was asked to be tested here. This needs to be tested on the latest 1.3 Flame base image.

(In reply to Jason Smith [:jsmith] from comment #4) > That isn't what was asked to be tested here. This needs to be tested on the > latest 1.3 Flame base image. My mistake. Re-tested on Flame base image v10f-3 and issue does NOT reproduce. Device correctly rebooted after executing all three repro steps.

Can we check 1.4 here as well>

(In reply to Jason Smith [:jsmith] from comment #6) > Can we check 1.4 here as well> Issue NOT reproducible on today's 1.4. Reboot was successful following repro steps. Tested on: Device: Flame MOZ BuildID: 20140509000203 Gaia: f19735d288d9bf1c6ee0c0ecc7941421365037c7 Gecko: 33aff135dc42 Version: 30.0 Firmware Version: v10F

This issue reproduces on the earliest central Flame build that we have available, therefore I'm unable to find a regression window for this bug. Tested on: Device: Flame MOZ BuildID: 20140417000006 Gaia: 7591e9dc782ac2e97d63a96f9deb71c7b3588328 Gecko: e71ed4135461 Version: 31.0a1 Firmware Version: v10F

Does this reproduce on 10E w/2.0 with 256 MB set?

(In reply to Jason Smith [:jsmith] from comment #9) > Does this reproduce on 10E w/2.0 with 256 MB set? With v10E base image on today's master flame build, this issue does NOT reproduce. Setting mem to 256MB and fastboot reboot correctly boots the device as expected. Tested on: Device: Flame MOZ BuildID: 20140514040204 Gaia: a13d42ab5240008e042d0c61bf9c9d05174e70e4 Gecko: 5c99d5136ad7 Version: 32.0a1 Firmware Version: v10E

Ok - that means this is a regression from 10E w/1.4 to 10F w/1.4, which indicates this is a vendor problem. Francis - Can you get a T2Mobile developer to weigh in here?

hi yanan, please check this issue. you can refer to comment 10

This is still busted on the v10G-2 image. Gecko won't start up and stuck on splash screen.

This issue is still occurring on v121-2 base image. Device is stuck on Firefox animation screen after setting oem mem 256 and fastboot reboot.

Same thing with v122 base image.

(In reply to Johan Lorenzo [:jlorenzo] from comment #15) > Same thing with v122 base image. Yep, just verified again. Still stuck (running latest base image and today's 2.0 nightly). Attaching a logcat from the startup sequence. It looks like we are having issues accesing files on the device with this change. Here is the first set of messages (followed by lots of messages about not able to open other files): E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:33:apps_std fopen failed: ./oemconfig.so No such file or directory E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:33:apps_std fopen failed: /system/lib/rfsa/adsp/./oemconfig.so No such file or directory E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:33:apps_std fopen failed: /system/vendor/lib/rfsa/adsp/./oemconfig.so No such file or directory E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/../inc/mod_table_imp.h:346::error: 2: 0 == (nErr = invoke_func_ptr(sc, pra)) E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:33:apps_std fopen failed: ./voiceproc_tx.so No such file or directory E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:33:apps_std fopen failed: /system/lib/rfsa/adsp/./voiceproc_tx.so No such file or directory E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:33:apps_std fopen failed: /system/vendor/lib/rfsa/adsp/./voiceproc_tx.so No such file or directory E/adsprpc ( 312): vendor/qcom/proprietary/adsprpc/src/../inc/mod_table_imp.h:346::error: 2: 0 == (nErr = invoke_func_ptr(sc, pra))

We boot fine with 512Mb of RAM - same phone, same builds as tested in comment 16

Dears, if you've try to replace gaia/gecko into base image version? we tested on v122. it's ok. can not reproduce this issue.

This is blocking 2.0, and should have been marked as such. QC is testing with 256mb phones, issues are blocking their FC, so our inability to test with such devices and reproduce issues means we can't produce a good 2.0.

:mwu given QA is hitting the issue and partner is not, may be if engg can help give a shot if this is working or not, it might help us.Can you please try if you are running into this issue as well ? This is currently a blocker for us to do any testing on 256MB on flame hence the priority.

(In reply to youlong.jiang from comment #18) > Dears, > > if you've try to replace gaia/gecko into base image version? we tested > on v122. it's ok. can not reproduce this issue. Hi Youlong, Just to be clear, can you write out the steps you did to make this work? On mozilla's side, we did the following: 1) install v122 base image 2) flash gecko and gaia only for 2.0 branch 3) boot into fastboot mode 4) $ fastboot oem mem 256 5) $ fastboot reboot 6) Verify the device starts and gets stuck on the Firefox OS splash screen. Would love urgent help from :mwu and t2m for more advice. Thanks, Tony

bhavana -- we are not seeing this issue on the flame we received. We are able to boot with mem 256. Although to compensate for the unoptimized modem image on these devices we should be specifying mem 273 to put us close to the configuration we have on our QRD devices. With mem 273 I am seeing following: $ adb shell cat /proc/meminfo MemTotal: 171852 kB MemFree: 3496 kB ... Can QA try with 273 and see if they can boot?

(In reply to Inder from comment #22) > Can QA try with 273 and see if they can boot? Trying this now.

Flame device correctly boots up with memory set to 273MB. Tested on a Flame 2.0 Aurora build ID 20140703085751. With mem 273 I see the following: $ adb shell cat /proc/meminfo MemTotal: 171852 kB MemFree: 3892 kB

\o/ thanks Inder!

Credit goes to :m1 for suggesting this could be the issue here.

Note: Comment 24 was tested on v122 base image.

Closing this out since we've worked around the issue. Thanks for the help btw.

Tried this and it booted fine for me. The only catch is I tried applying an OTA and after reboot, it hung apparently due to memory pressure. I'm attaching the logcat but it didn't catch the initial issue, just some of the symptoms.

(In reply to Tony Chung [:tchung] from comment #21) > (In reply to youlong.jiang from comment #18) > > Dears, > > > > if you've try to replace gaia/gecko into base image version? we tested > > on v122. it's ok. can not reproduce this issue. > > Hi Youlong, > Just to be clear, can you write out the steps you did to make this work? > On mozilla's side, we did the following: > > 1) install v122 base image > 2) flash gecko and gaia only for 2.0 branch > 3) boot into fastboot mode > 4) $ fastboot oem mem 256 > 5) $ fastboot reboot > 6) Verify the device starts and gets stuck on the Firefox OS splash screen. > > Would love urgent help from :mwu and t2m for more advice. > > Thanks, > Tony hi tony - No. I just flash v122 base image and not handle step#2.

I don't think the workaround means bug is fixed. Even we can use similar configuration, but boot fail problem still there. Besides, 256MB should be a compatible setting and the memory allocation must close to real 256MB device. You can refer bug995931 to aware the unreasonable memory allocation.

(In reply to Pi Wei Cheng (piwei) from comment #10) > (In reply to Jason Smith [:jsmith] from comment #9) > > Does this reproduce on 10E w/2.0 with 256 MB set? > > With v10E base image on today's master flame build, this issue does NOT > reproduce. Setting mem to 256MB and fastboot reboot correctly boots the > device as expected. > > Tested on: > Device: Flame MOZ > BuildID: 20140514040204 > Gaia: a13d42ab5240008e042d0c61bf9c9d05174e70e4 > Gecko: 5c99d5136ad7 > Version: 32.0a1 > Firmware Version: v10E Leaving qawanted as there was an indication offline that this might not be correct.

(In reply to Jason Smith [:jsmith] from comment #33) > Leaving qawanted as there was an indication offline that this might not be > correct. Would you like this tested on 2.0 Aurora or 2.1 master?

(In reply to Pi Wei Cheng (piwei) from comment #34) > (In reply to Jason Smith [:jsmith] from comment #33) > > Leaving qawanted as there was an indication offline that this might not be > > correct. > > Would you like this tested on 2.0 Aurora or 2.1 master? Both.

Copied & pasted my results responding to an email requesting further testing on this issue per Joshua's request. v10e base + 2.0 Aurora testing results will be posted in the next comment. ------------ > 1) only base image v122 (FxOS v1.3) can always boot successfully with 256MB setting This is true. Booted 3 successfully in 3 attempts. > 2) after flash gaia/gecko (v1.4/v2.0/v2.1), it has high probability (more than 90%) boot fail and stuck on splash screen v122+v1.4 - 3 out of 5 attempts cannot boot successfully v122+v2.0 - 3 out of 5 attempts cannot boot successfully v122+v2.1 - 1 out of 5 attempts cannot boot successfully (I used console command 'adb reboot' between each attempt, and for each branch I used today's tinderbox engineering build) > 3) even using old base image (v10E) + the latest gaia/gecko will happen cannot boot successfully problem v10e+v2.1 - 1 out of 10 attempts cannot boot successfully The only time the issue occurred is right after flashing gecko/gaia with 256MB mem already set. All subsequent attempts (adb reboot) booted correctly. In other words, if I set 256 mem AFTER I flash to a 2.1 build, this issue would NOT occur. To prove this theory, I set mem back to 512, re-flashed the 2.1 gecko+gaia, and set it back to 256 mem - issue does NOT occur which matches my theory. I suspect this finding also applies to v122 base image + 2.1 master above at 2). I recall not ever seeing the issue again after the first attempt.

v10e + v2.0 - 10 out of 10 attempts cannot boot successfully For v10e + v2.1 please see comment 36. Removed regression tag. Setting tracking flags based on v122 base image findings.

So the above testing concludes this isn't a vendor bug.

Changing v2.1 to affected because when flashing gecko&gaia with mem already set to 256 this issue still occurs (doing an adb reboot will then workaround the bug). This issue also occurs when factory resetting the phone via Settings. The same behavior is observed in 273 mem as well.

(In reply to Pi Wei Cheng (piwei) from comment #39) > Changing v2.1 to affected because when flashing gecko&gaia with mem already > set to 256 this issue still occurs (doing an adb reboot will then workaround > the bug). This issue also occurs when factory resetting the phone via > Settings. The same behavior is observed in 273 mem as well. There should be a separate bug open if this reproduces on 273 mem - that is a different problem than what this bug is tracking.

(In reply to Jason Smith [:jsmith] from comment #40) > There should be a separate bug open if this reproduces on 273 mem - that is > a different problem than what this bug is tracking. But if this 256 mem bug could be fixed, then the 273 mem bug wouldn't exist. I could file it if you still want it to be filed. I think the bug would look highly similar to comment 36 and 37.

(In reply to Pi Wei Cheng (piwei) from comment #41) > (In reply to Jason Smith [:jsmith] from comment #40) > > There should be a separate bug open if this reproduces on 273 mem - that is > > a different problem than what this bug is tracking. > > But if this 256 mem bug could be fixed, then the 273 mem bug wouldn't exist. > I could file it if you still want it to be filed. I think the bug would look > highly similar to comment 36 and 37. I'd prefer a separate bug mainly because we'll block on a 273 mem bug, but won't block on a 256 MB mem bug.

Bug 1036670 filed.

refer to comment37, change component

while boot fail problem happens, gonk will response memory pressure message I/GonkMemoryPressure( 946): Checking to see if memory pressure is over. I/GonkMemoryPressure( 290): Checking to see if memory pressure is over. I/GonkMemoryPressure( 290): Memory pressure is over. I/GonkMemoryPressure( 946): Memory pressure is over.

Be noted the duplicate bug 1036670 has been resolved.

Even bug 1036670 is fixed, 256MB still has this problem

Mike, could you please help to get a logcat log? Thanks.

verify again with base images v122 and v123 + latest v2.0 and v2.1 gaia/gecko it can boot successfully, just mark issue worksforme