Description: With the phone freshly flashed to current build, user is unable to dial out or send an SMS. The pop-up "To make a call you need to disable airplane mode in settings". When user goes to settings airplane mode is off and cycling it has no affect. Restartikng the device will reset this situation. Repro Steps: 1) Flash to Unagi Build ID: 20130709030202 2) Select Dialer 3) Dial a number and press enter Actual: Pop-up message appears "To make a call you need to disable airplane mode in settings." User unable to make a call or send a SMS. Expected: The device completes the call and sends SMS. Environmental Variables Build Location: https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-central-unagi/2013/07/2013-07-09-03-02-02/unagi.zip Gecko: http://hg.mozilla.org/mozilla-central/rev/f2de2035f0af Gaia: 45cbc4652be9a05d5f981cfa9d69b954d2192efd Platform Version: 25.0a1 Notes: Repro frequency: 100% Q Analysts Team Priority: Pri 2 See attached: AirplaneModeLog.txt Screenshot-AirplaneModeMessage.png Work Around: Restart device will resolve this issue.

Etienne - Any ideas what caused this regression?

(In reply to Jason Smith [:jsmith] from comment #1) > Etienne - Any ideas what caused this regression? Not sure, this is weird one. Looks like the only code path displaying this message is when we get a RadioNotAvailable error back from gecko [1]. [1] https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/telephony_helper.js#L59

This issue is not affecting current Unagi v1.2 Build ID: 20130711070209 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/aaa74e5efaf1 Gaia: 7cdcc46179d198cab11970964b181ede32a5b683 Platform Version: 18.1 RIL Version: 01.01.00.019.158 Will regress this issue on 7/12 build before resolving as WFM

Issue has reoccurred on: Unagi v1.2.0 Mozilla RIL Build ID: 20130712070210 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/282b5c37cf8d Gaia: e2ef782119b7e79fc62c48d36f0c36909d982988 Platform Version: 18.1

(In reply to Allen Maxwell from comment #4) > Issue has reoccurred on: > > Unagi v1.2.0 Mozilla RIL > Build ID: 20130712070210 > Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/282b5c37cf8d > Gaia: e2ef782119b7e79fc62c48d36f0c36909d982988 > Platform Version: 18.1 Info in Comment 4 incorrect Corrected info: Unagi v1.2.0 Mozilla RIL Build ID: 20130712030200 Gecko: http://hg.mozilla.org/mozilla-central/rev/b44898282f21 Gaia: d94ed01a27125ea8dc91b9f16805411e2d2cc708 Platform Version: 25.0a1

Still repros on Unagi 1.2 mozilla RIL. Build ID: 20130726030202 Gecko: http://hg.mozilla.org/mozilla-central/rev/46d73e889cb4 Gaia: a3d7268219f6ff92d296a3305bdfef14209885dc Platform Version: 25.0a1

Interesting. I don't see this issue on the master/eng build. 2013-07-26-03-02-02 Looks like it's a non-eng mozril issue specifically. It doesn't seem to try to find the network operator when I messed with it down at the bottom. Oddly I got the network to detect after reboot after messing with the network operator prior to reboot.

Julien - Can you followup with the Comms team to find an assignee here? This is currently breaking daily smoke tests on 1.2.

If I understand correctly, after a boot after full flash, everything happens as if we're in airplane mode except we're not according to the settings app, but after a reboot it works ok. Is it correct ? Anyway, this looks like a work for our RIL engineers.

It sounds something wrong with the Settings initialization in the RIL. I just reflashed (using ./flash) everything but couldn't reproduce this issue. Trying to update the latest build and do it again. Btw, V1.2 still means central (Gecko) + master (Gaia). Right? Comment #3 and comment #4 confuse me...

(In reply to Gene Lian [:gene] from comment #10) > It sounds something wrong with the Settings initialization in the RIL. I > just reflashed (using ./flash) everything but couldn't reproduce this issue. > Trying to update the latest build and do it again. > > Btw, V1.2 still means central (Gecko) + master (Gaia). Right? Comment #3 and > comment #4 confuse me... Right. Central + Master = 1.2. Specific build we use to test daily comes from - https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-central-unagi/latest/.

I used the PVT build at [1] and completely flashed everything (using ./flash). After booting, I can successfully make phone call and send SMS. I also tried to manually fetch the latest Master and Central codes. Everything is still working well after reflashing. I cannot reproduce this bug. [1] https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-central-unagi/latest/

QA Wanted for a retest. Allen - Can you retest on today's build?

Issue Is still repro on Unagi v1.2 Build ID: 20130731030205 Gecko: http://hg.mozilla.org/mozilla-central/rev/c2b375f3a909 Gaia: 9bfceaa90e8b92a379432b67121afa3cd3f14c90 Platform Version: 25.0a1 User is unable to make a call or send a SMS

Looks like I can reproduce as well on a 7/31 b2g18 build. Upon dialing a valid phone number, I get an error saying: Airplane mode activated To make a call you need to disable airplane mode in settings Note that the testing I did here was on a T-Mobile SIM in the US.

OK. I can reproduce it now (weird! I didn't do anything). Trying to solve this ASAP. Please stay tuned.

This bug is not 100% reproducing. After flashing again, it is working. Flashing again, working. Flashing again, not working. Trying to find a way to permanently reproduce this... I'd appreciate if anyone can provide more stable steps. Thanks!

Hi Michael, We're doubting this is an issue of RIL daemon. We don't know how to further solve this issue if the RIL daemon doesn't react. Could your team please help us figure out the root cause? This issue only happens after flashing (i.e. using ./flash.sh). The radio power bars (on the status bar) is gray and we cannot make phone calls and send messages under this situation. Restarting the phone may solve the problem. We've already checked we do send REQUEST_RADIO_POWER parcel [1] to the RIL daemon, but neither the REQUEST_RADIO_POWER [2] nor UNSOLICITED_RESPONSE_RADIO_STATE_CHANGED [3] are returned from the RIL daemon. [1] https://hg.mozilla.org/mozilla-central/file/76a944fa6b25/dom/system/gonk/ril_worker.js#l1448 [2] https://hg.mozilla.org/mozilla-central/file/76a944fa6b25/dom/system/gonk/ril_worker.js#l5002 [3] https://hg.mozilla.org/mozilla-central/file/76a944fa6b25/dom/system/gonk/ril_worker.js#l5777

The attachment is the result of |adb locat -b radio|, which should be similar to the one Naoki uploaded. Just attach my log again.

I'm sorry that it looks like there's not much we can help with here at the moment, as this bug is on both a device and ril that we don't support. Does this reproduce on a commercial device w/ supported ril?

This issue no longer has a repro frequency of 100%, it's now at @25%. The following build had 1/4 devices with the airplane mode set to on by default. Unagi v1.1.0 Mozilla RIL Build ID: 20130802070203 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/c489af94ada5 Gaia: 4b347e4e39b1716b68463dccc63c1b3eb49158b3 Platform Version: 18.1

(In reply to Michael Vines [:m1] [:evilmachines] from comment #21) > I'm sorry that it looks like there's not much we can help with here at the > moment, as this bug is on both a device and ril that we don't support. Does > this reproduce on a commercial device w/ supported ril? we havent recieved a 1.2 supported device with commercial RIL yet; is why we're testing this environment here. If this proves to be an inefficient set of testing; i can ask my team to halt this environment. But i'd like to hear from mozilla Developers if this is worthwhile effort.

Of course it is Tony, we need a stable mozilla-central with moz RIL to develop. Thanks a lot to you and your team.

Hi Vicamo, I have no idea how to continue if the RIL daemon doesn't response any events to the ril_worker after calling setRadioPower(). Do you have any insight regarding this issue? You can see the log as below. The ril_worker in the failed case doesn't receive REQUEST_RADIO_POWER or UNSOLICITED_RESPONSE_RADIO_STATE_CHANGED for the last call. Succeed: ==================== I/Gecko ( 109): receive: UNSOLICITED_RESPONSE_RADIO_STATE_CHANGED I/Gecko ( 109): call: setRadioPower: {"on":false} I/Gecko ( 109): receive: REQUEST_RADIO_POWER I/Gecko ( 109): receive: UNSOLICITED_RESPONSE_RADIO_STATE_CHANGED I/Gecko ( 109): call: setRadioPower: {"on":false} I/Gecko ( 109): receive: REQUEST_RADIO_POWER I/Gecko ( 109): call: setRadioPower: {"rilMessageType":"setRadioPower","on":true} I/Gecko ( 109): receive: REQUEST_RADIO_POWER I/Gecko ( 109): receive: UNSOLICITED_RESPONSE_RADIO_STATE_CHANGED Fail: ==================== I/Gecko ( 109): receive: UNSOLICITED_RESPONSE_RADIO_STATE_CHANGED I/Gecko ( 109): call: setRadioPower: {"on":false} I/Gecko ( 109): receive: UNSOLICITED_RESPONSE_RADIO_STATE_CHANGED I/Gecko ( 109): call: setRadioPower: {"on":false} I/Gecko ( 109): receive: REQUEST_RADIO_POWER I/Gecko ( 109): call: setRadioPower: {"rilMessageType":"setRadioPower","on":true}

(In reply to Gene Lian [:gene] from comment #27) > Hi Vicamo, > > I have no idea how to continue if the RIL daemon doesn't response any events > to the ril_worker after calling setRadioPower(). Do you have any insight > regarding this issue? No, if rild doesn't reply us anything, I can't do much help either. But I'd like to take this bug and have some experiments myself, so that you may continue other important tasks in Paris. Thank you!

Really appreciate! Vicamo!

Airplane mode continues to be experienced at a freq of 1/4 on: Unagi v1.2.0 Build ID: 20130811040204 Gecko: http://hg.mozilla.org/mozilla-central/rev/3d20597e0a07 Gaia: 1b9019acdc1eea9cfe78edeb914eba6e8153fbbe

New error message "No Network Connection" appears instead of "Airplane Mode" results are the same as Comment 30; unable to dial or SMS. Build ID: 20130813040222 Gecko: http://hg.mozilla.org/mozilla-central/rev/8c240c67f76c Gaia: b527d7406b4eed3bacdee78597bb4ff21bf9f7d0 Platform Version: 26.0a1

This has been confirmed to be unagi-specific. Given that we're no longer supporting unagi under 1.2 daily smoketests, removing from tracking.

Jason, given your comment 33 about this being unagi specific, can we resolve this bug as won't fix?

Yes.