Closed Bug 1008050 Opened 7 years ago Closed 6 years ago

[Flame][Memory]Customize memory to 256MB will cause cannot boot to gecko

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.3 unaffected, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)

RESOLVED WORKSFORME
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: mlien, Unassigned)

Details

Attachments

(2 files)

[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.
Keywords: qawanted
(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.
Keywords: qawanted
(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.
Keywords: qawanted
(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.
Keywords: qawanted
Can we check 1.4 here as well>
Keywords: qawanted, regression
blocking-b2g: --- → 2.0?
(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
Keywords: qawanted
Component: GonkIntegration → Runtime
QA Contact: pcheng
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?
Keywords: qawanted
(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
Keywords: qawanted
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?
blocking-b2g: 2.0? → ---
Component: Runtime → Vendcom
Flags: needinfo?(frlee)
Whiteboard: [POVB]
hi yanan,

please check this issue. you can refer to comment 10
Flags: needinfo?(frlee) → needinfo?(yanan.zhao)
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.
No longer blocks: 1031503
Attached file startup.log
(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
Flags: needinfo?(yanan.zhao)
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.
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → 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.
Flags: needinfo?(mwu)
(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?
Flags: needinfo?(bbajaj)
(In reply to Inder from comment #22)
> Can QA try with 273 and see if they can boot?

Trying this now.
Keywords: qawanted
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Credit goes to :m1 for suggesting this could be the issue here.
Flags: needinfo?(bbajaj)
Note:
Comment 24 was tested on v122 base image.
Closing this out since we've worked around the issue. Thanks for the help btw.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
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.
blocking-b2g: 2.0+ → ---
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
(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?
Flags: needinfo?(jsmith)
(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.
Flags: needinfo?(jsmith)
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted, regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
So the above testing concludes this isn't a vendor bug.
Whiteboard: [POVB]
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.
Flags: needinfo?(pcheng)
(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.
Flags: needinfo?(jsmith)
(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.
Flags: needinfo?(jsmith)
Bug 1036670 filed.
Flags: needinfo?(pcheng)
refer to comment37, change component
Component: Vendcom → GonkIntegration
Flags: needinfo?(mwu)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
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
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.