790906 - b2g RIL: The network keeps in "Emergency Calls Only" after reboot the device.

Status: RESOLVED INVALID

(Firefox OS Graveyard :: General, defect)

Description

[Vincent Liu[:vliu]]

Method to reproduce this issue.

1. Turn on the device and it can show network name in unlock screen.
2. Use "adb reboot" to reboot the device.
3. After reboot, the network keeps in "Emergency Calls Only" state in unlock screen.

This issue is found in otoro and not always happens for every reboot.

Comment 1

[Vincent Liu[:vliu]]

When I checked the log, I got some clues to know the reason why this issue happens. Maybe it may not exactly right and hope you can give me any me any suggestion. This issue also relative to bug 787172.
When we reboot the device, the system app send a mozContent event to indicate that it's loaded. shell.js can then convert this to an observer notification that RadioInterfaceLayer can observe and use to turn on the radio.
When error happens, I could see the system app send a mozContent event in gaia but I found shell.js didn't receive this event in custevt_handleEvent(evt). After that, RadioInterfaceLayer couldn't observe and then turned on the radio.
 
Does anyone can give me any suggestion what I should do to know why custevt_handleEvent(evt) didn't receive this event? Thanks

Comment 2

[Vincent Liu[:vliu]]

Thanks for shian-yow, vchang and Yoshi's help. From their help. I got more information.

When system app wanted to send system-message-listener-ready to shell.js, it should call window.dispatchEvent(event) when shell.js had finished to addEventListener for mozContentEvent. But when issue happens, it apparently not. In other words, system app dispatched system-message-listener-ready before shell.js finished to call addEventListener for mozContentEvent.

galaxy-nexus also can reproduce this issue. But I found when this issue happens on otoro, the network state showed "Emergency Call Only" while galaxy-nexus showed "Searching...". It might be another issue.

Comment 3

[Vincent Liu[:vliu]]

To run addEventListener for mozContentEvent, the shell.js must wait mozbrowserloadstart event in shell_handleEvent(evt). When issue happens, it run after the system app had sent system-message-listener-ready event to shell.js. It might be the new tracking direction.

Comment 4

[Vincent Liu[:vliu]]

Attachment: Simple patch to issue tracking.

To advance the timing to new chromeWindow and then send event for ContentStart , I put them into shell_start(). They originally run when shell.js received mozbrowserloadstart event. Please see the simple patch for detail. From log observation, I could see shell.js run addEventListener for mozContentEvent before system app sent system-message-listener-ready. But even the flow is correct, shell.js still not receiving system-message-listener-ready.

Comment 5

[Philipp von Weitershausen [:philikon]]

Comment on attachment 661672 [details] [diff] [review]
Simple patch to issue tracking.

Thanks for looking into this, vliu. It seems shell.js and the System app are racing each other for events / event listeners here. Asking Vivien for feedback on your patch. (Please don't just upload a patch without asking for review for feedback.)

Comment 6

[Gene Lian (I already quit Mozilla)]

Hi Vivien,

Please also see https://bugzilla.mozilla.org/show_bug.cgi?id=787172#c14 when you have a chance. I think Bug 783149 has already consider the delayed system message sending but the extra "system-message-listener-ready" mechanism would probably lead us to racing effect.

Please correct me if I'm wrong. :)

Comment 7

[Vincent Liu[:vliu]]

Attachment: Patch to avoid racing issue

(In reply to vliu from comment #4)
> Created attachment 661672 [details] [diff] [review]
> Simple patch to issue tracking.
> 
> To advance the timing to new chromeWindow and then send event for
> ContentStart , I put them into shell_start(). They originally run when
> shell.js received mozbrowserloadstart event. Please see the simple patch for
> detail. From log observation, I could see shell.js run addEventListener for
> mozContentEvent before system app sent system-message-listener-ready. But
> even the flow is correct, shell.js still not receiving
> system-message-listener-ready.

I tried to add delay in gaia for 5 seconds and it could avoid racing issue.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 662113 [details] [diff] [review]
Patch to avoid racing issue

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

That sounds really a workaround. You may want to fix the real cause of the issue and not add a delay.

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 661672 [details] [diff] [review]
Simple patch to issue tracking.

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

The problem by moving the code here is that the content could be not loaded at the time you're sending the ContentStart event.

Comment 10

[Vincent Liu[:vliu]]

Hi Vivien,
I got an idea and maybe you can give me any suggestion. When I discussed with Gene about Bug 783149, he mentioned about bufferedSysMsgs in shell.js. This bufferedSysMsgs buffered non-activity messages until content starts to load for 10 seconds. If I can make out a patch pushing system-message-listener-ready into this buffer, we can sent it to RadioInterfaceLayer after shell.js has sending Content event and plus a 10 second. Although this method also add a delay, we can make sure that system-message-listener-ready sent to RadioInterfaceLayer.js after ContentStart

Comment 11

[Gene Lian (I already quit Mozilla)]

That bufferedSysMsgs is aimed to buffer system messages from Gecko. It doesn't make sense to push the system-message-listener-ready event into it as well. :O

Comment 12

[Vincent Liu[:vliu]]

Hi Gene, Vivien,
When I came out this idea, I supposed system-message-listener-ready is one of system messages generated from gaia and when shell.js received this system message, it then call Services.obs.notifyObservers(null, 'system-message-listener-ready', null) to RadioInterfaceLayer. 

I might have a more simple way and maybe you can give me any suggestion. The below is code snippet 

      shell.timer.initWithCallback(function timerCallback() {
        shell.bufferedSyshttp://www.facebook.com/his Msgs.forEach(function sendSysMsg(msg) {
          shell.sendSystemMessage(msg);
        });
        shell.bufferedSysMsgs.length = 0;
        shell.needBufferSysMsgs = false;
        shell.timer = null;
+       Services.obs.notifyObservers(null, 'system-message-listener-ready', null);  
      }, 10000, Ci.nsITimer.TYPE_ONE_SHOT);

From code snippet, shell.js can send system-message-listener-ready to RadioInterfaceLayer after ContentStart.

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to vliu from comment #12)
> Hi Gene, Vivien,
> When I came out this idea, I supposed system-message-listener-ready is one
> of system messages generated from gaia and when shell.js received this
> system message, it then call Services.obs.notifyObservers(null,
> 'system-message-listener-ready', null) to RadioInterfaceLayer. 
> 
> I might have a more simple way and maybe you can give me any suggestion. The
> below is code snippet 
> 
>       shell.timer.initWithCallback(function timerCallback() {
>         shell.bufferedSyshttp://www.facebook.com/his Msgs.forEach(function
> sendSysMsg(msg) {
>           shell.sendSystemMessage(msg);
>         });
>         shell.bufferedSysMsgs.length = 0;
>         shell.needBufferSysMsgs = false;
>         shell.timer = null;
> +       Services.obs.notifyObservers(null, 'system-message-listener-ready',
> null);  
>       }, 10000, Ci.nsITimer.TYPE_ONE_SHOT);
> 
> From code snippet, shell.js can send system-message-listener-ready to
> RadioInterfaceLayer after ContentStart.

In general adding a timer is a bad idea, it just workaround the real issue.
You likely want to find the main reason of what you said in comment #3.

Comment 14

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

https://github.com/mozilla-b2g/gaia/pull/4901

After talking to vliu we concluded that we should fix this on Gaia side.

Comment 15

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

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #14)
> https://github.com/mozilla-b2g/gaia/pull/4901
> 
> After talking to vliu we concluded that we should fix this on Gaia side.

Merged and verified by vliu that this fixed the issue.

Comment 16

[Philipp von Weitershausen [:philikon]]

RESO/INVALID since it was decided to be a Gaia bug, not a Gecko bug.