1008557 - [Flame] Unable to send or receive SMS

Status: VERIFIED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[:gerard-majax]

Custom built system (available in https://mozilla.app.box.com/files/0/f/1932801249/FlameCustomBuilds).

Flame running master with MozRIL, two SIMs cards. From time to time, sending SMS fails, with either SIM card.

I turned on RILC debug as this:

> In your B2G build tree, edit hardware/ril/libril/ril.cpp and switch the RILC_LOG define to 1. Then rebuild and push libril.so:
> $ ./build.sh out/target/product/flame/system/lib/libril.so
> $ adb root && adb wait-for-device && adb remount
> $ adb push out/target/product/flame/system/lib/libril.so /system/lib/libril.so

And when the issue reproduces, all I see is:

> D/RILC    (  345): [0246]> SEND_SMS ((null),01000A816071894055000003477C1D)
> D/RILC    (  345): [0246]< SEND_SMS fails by E_GENERIC_FAILURE

Comment 1

[Jason Smith [:jsmith]]

Not a regression, so this is not a QA blocker.

Comment 2

[Edgar Chen [:edgar]]

(In reply to Alexandre LISSY :gerard-majax from comment #0)
> 
> > D/RILC    (  345): [0246]> SEND_SMS ((null),01000A816071894055000003477C1D)
> > D/RILC    (  345): [0246]< SEND_SMS fails by E_GENERIC_FAILURE
>

I found this issue was only happened right after device reboot.
Once you on/off fly mode, device can send/receive SMS normally.

Comment 3

[Edgar Chen [:edgar]]

Attachment: flame_sms.log

// Device bootup
// Fail to send SMS, modem replies error with 2 (means GENERIC_FAILURE).
05-15 11:10:48.851   289   743 I Gecko   : RIL Worker: [0] Solicited response for request type 25, token 172, error 2
05-15 11:10:48.851   289   743 I Gecko   : RIL Worker: [0] Handling parcel as REQUEST_SEND_SMS
05-15 11:10:48.851   289   743 I Gecko   : RIL Worker: [0] _processSmsSendResult: rilRequestError = 2

// On/off airplane mode.
05-15 11:11:03.081   289   289 I Gecko   : -*- RadioInterface[0]: setRadioEnabled: {"requestId":"id{3a0ee119-785c-4ae5-b69b-9bdac540f97d}","enabled":false}
05-15 11:11:03.101   289   289 I Gecko   : -*- RadioInterface[1]: setRadioEnabled: {"requestId":"id{52997cbd-73cc-48fb-9f52-9d0d50f462e6}","enabled":false}
05-15 11:11:12.171   289   289 I Gecko   : -*- RadioInterface[0]: setRadioEnabled: {"requestId":"id{93172dab-bef7-470d-9773-bd586f683f79}","enabled":true}
05-15 11:11:12.191   289   289 I Gecko   : -*- RadioInterface[1]: setRadioEnabled: {"requestId":"id{c3e308dd-9097-435e-bca2-3ab704bbbf09}","enabled":true}

// After that, device can send SMS normally.
05-15 11:11:28.989   289   743 I Gecko   : RIL Worker: [0] Solicited response for request type 25, token 335, error 0
05-15 11:11:28.989   289   743 I Gecko   : RIL Worker: [0] Handling parcel as REQUEST_SEND_SMS
05-15 11:11:28.989   289   743 I Gecko   : RIL Worker: Next parcel size unknown, going to sleep.
05-15 11:11:28.989   289   289 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"sendSMS","rilMessageToken":32,"rilMessageClientId":0}

Comment 4

[:gerard-majax]

(In reply to Edgar Chen [:edgar][:echen] from comment #2)
> (In reply to Alexandre LISSY :gerard-majax from comment #0)
> > 
> > > D/RILC    (  345): [0246]> SEND_SMS ((null),01000A816071894055000003477C1D)
> > > D/RILC    (  345): [0246]< SEND_SMS fails by E_GENERIC_FAILURE
> >
> 
> I found this issue was only happened right after device reboot.
> Once you on/off fly mode, device can send/receive SMS normally.

I'm reproducing even after enabling/disabling airplane mode.

Comment 5

[:gerard-majax]

I see REQUEST_GSM_SMS_BROADCAST_ACTIVATION failing:

> 05-19 11:45:49.115  1821  1908 D RILC    : [0004]< (51) BASEBAND_VERSION fails by E_GENERIC_FAILURE
> 05-19 11:45:49.125  1820  1912 D RILC    : [0004]< (51) BASEBAND_VERSION fails by E_GENERIC_FAILURE
> 05-19 11:45:49.225  1820  1926 D RILC    : [0014]< (19) SIGNAL_STRENGTH fails by E_GENERIC_FAILURE
> 05-19 11:45:54.515  1821  2012 D RILC    : [0080]< (51) BASEBAND_VERSION fails by E_GENERIC_FAILURE
> 05-19 11:45:54.525  1820  2010 D RILC    : [0045]< (51) BASEBAND_VERSION fails by E_GENERIC_FAILURE
> 05-19 11:47:10.988  1820  2171 D RILC    : [0076]< (51) BASEBAND_VERSION fails by E_GENERIC_FAILURE
> 05-19 11:47:10.988  1820  1829 D RILC    : [0077]< (91) <unknown request> fails by E_GENERIC_FAILURE
> 05-19 11:47:10.988  1821  1839 D RILC    : [0124]< (91) <unknown request> fails by E_GENERIC_FAILURE
> 05-19 11:47:10.998  1821  2173 D RILC    : [0123]< (51) BASEBAND_VERSION fails by E_GENERIC_FAILURE
> 05-19 11:47:14.126  1820  1829 D RILC    : [0123]< (91) <unknown request> fails by E_GENERIC_FAILURE
> 05-19 11:47:20.756  1820  1825 D RILC    : [0140]< (31) GET_CLIR fails by E_GENERIC_FAILURE

Comment 6

[:gerard-majax]

REQUEST_GSM_SMS_BROADCAST_ACTIVATION is identified as unknown request because hardware/ril/ril.cpp lacks RIL_REQUEST_GSM_SMS_BROADCAST_ACTIVATION mapping.

Comment 7

[Edgar Chen [:edgar]]

(In reply to Alexandre LISSY :gerard-majax from comment #4)
> (In reply to Edgar Chen [:edgar][:echen] from comment #2)
> > (In reply to Alexandre LISSY :gerard-majax from comment #0)
> > >  
> > > > D/RILC    (  345): [0246]> SEND_SMS ((null),01000A816071894055000003477C1D)
> > > > D/RILC    (  345): [0246]< SEND_SMS fails by E_GENERIC_FAILURE
> > >
> > 
> > I found this issue was only happened right after device reboot.
> > Once you on/off fly mode, device can send/receive SMS normally.
> 
> I'm reproducing even after enabling/disabling airplane mode.

Hi gerard-majax,

I was using the test image provided by t2m to reproduce this issue.
https://mozilla.app.box.com/files/0/f/1708478428/Foxfone-one-V10f-3_BlackforMozRIL.zip

This test image includes all configurations that moz-ril needs.
With this image, I can send/receive sms (but need to disable/enable airplane first, as I mention in comment #2).
For the failed case, I already reported to partner. We need their help to check.

Could you help to try this test image on your side?

Thank you.

Comment 8

[:gerard-majax]

(In reply to Edgar Chen [:edgar][:echen] from comment #7)
> (In reply to Alexandre LISSY :gerard-majax from comment #4)
> > (In reply to Edgar Chen [:edgar][:echen] from comment #2)
> > > (In reply to Alexandre LISSY :gerard-majax from comment #0)
> > > >  
> > > > > D/RILC    (  345): [0246]> SEND_SMS ((null),01000A816071894055000003477C1D)
> > > > > D/RILC    (  345): [0246]< SEND_SMS fails by E_GENERIC_FAILURE
> > > >
> > > 
> > > I found this issue was only happened right after device reboot.
> > > Once you on/off fly mode, device can send/receive SMS normally.
> > 
> > I'm reproducing even after enabling/disabling airplane mode.
> 
> Hi gerard-majax,
> 
> I was using the test image provided by t2m to reproduce this issue.
> https://mozilla.app.box.com/files/0/f/1708478428/Foxfone-one-V10f-
> 3_BlackforMozRIL.zip
> 
> This test image includes all configurations that moz-ril needs.
> With this image, I can send/receive sms (but need to disable/enable airplane
> first, as I mention in comment #2).
> For the failed case, I already reported to partner. We need their help to
> check.
> 
> Could you help to try this test image on your side?
> 
> Thank you.

No, your link is dead.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Alexandre LISSY :gerard-majax from comment #6)
> REQUEST_GSM_SMS_BROADCAST_ACTIVATION is identified as unknown request
> because hardware/ril/ril.cpp lacks RIL_REQUEST_GSM_SMS_BROADCAST_ACTIVATION
> mapping.

The request is for enabling cell broadcast. The lack in mapping is an issue but it doesn't look related to sms sending problem. Besides, I checked AOSP lineup/til.cop, in addition to GSM_SMS_BROADCAST_ACTIVATION, there are some requests missing in the mapping. I an not sure how much different the libril.so you build is from the proprietary one, and wondering if it's okay to push the built one into device.

Comment 10

[:gerard-majax]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #9)
> (In reply to Alexandre LISSY :gerard-majax from comment #6)
> > REQUEST_GSM_SMS_BROADCAST_ACTIVATION is identified as unknown request
> > because hardware/ril/ril.cpp lacks RIL_REQUEST_GSM_SMS_BROADCAST_ACTIVATION
> > mapping.
> 
> The request is for enabling cell broadcast. The lack in mapping is an issue
> but it doesn't look related to sms sending problem. Besides, I checked AOSP
> lineup/til.cop, in addition to GSM_SMS_BROADCAST_ACTIVATION, there are some
> requests missing in the mapping. I an not sure how much different the
> libril.so you build is from the proprietary one, and wondering if it's okay
> to push the built one into device.

Thanks, but look Edgar's answer over, he reproduces with builds from partner.

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Alexandre LISSY :gerard-majax from comment #10)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #9)
> > (In reply to Alexandre LISSY :gerard-majax from comment #6)
> > > REQUEST_GSM_SMS_BROADCAST_ACTIVATION is identified as unknown request
> > > because hardware/ril/ril.cpp lacks RIL_REQUEST_GSM_SMS_BROADCAST_ACTIVATION
> > > mapping.
> > 
> > The request is for enabling cell broadcast. The lack in mapping is an issue
> > but it doesn't look related to sms sending problem. Besides, I checked AOSP
> > lineup/til.cop, in addition to GSM_SMS_BROADCAST_ACTIVATION, there are some
> > requests missing in the mapping. I an not sure how much different the
> > libril.so you build is from the proprietary one, and wondering if it's okay
> > to push the built one into device.
> 
> Thanks, but look Edgar's answer over, he reproduces with builds from partner.

Yes, so we are still waiting for partners reply. I was just trying to explain that comment 6 seems another issue. :)

Comment 12

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Is it reproducible on 1.3 with commercial RIL?

Comment 13

[Eric Chang [:ericcc] [:echang]]

Attachment: 2014-05-20 15.45.39.jpg

Flame v1.3 V10E, SMS sending okay

Comment 14

[Edgar Chen [:edgar]]

(In reply to Alexandre LISSY :gerard-majax from comment #8)
> (In reply to Edgar Chen [:edgar][:echen] from comment #7)
> > (In reply to Alexandre LISSY :gerard-majax from comment #4)
> > > (In reply to Edgar Chen [:edgar][:echen] from comment #2)
> > > > (In reply to Alexandre LISSY :gerard-majax from comment #0)
> > > > >  
> > > > > > D/RILC    (  345): [0246]> SEND_SMS ((null),01000A816071894055000003477C1D)
> > > > > > D/RILC    (  345): [0246]< SEND_SMS fails by E_GENERIC_FAILURE
> > > > >
> > > > 
> > > > I found this issue was only happened right after device reboot.
> > > > Once you on/off fly mode, device can send/receive SMS normally.
> > > 
> > > I'm reproducing even after enabling/disabling airplane mode.
> > 
> > Hi gerard-majax,
> > 
> > I was using the test image provided by t2m to reproduce this issue.
> > https://mozilla.app.box.com/files/0/f/1708478428/Foxfone-one-V10f-
> > 3_BlackforMozRIL.zip
> > 
> > This test image includes all configurations that moz-ril needs.
> > With this image, I can send/receive sms (but need to disable/enable airplane
> > first, as I mention in comment #2).
> > For the failed case, I already reported to partner. We need their help to
> > check.
> > 
> > Could you help to try this test image on your side?
> > 
> > Thank you.
> 
> No, your link is dead.

https://mozilla.app.box.com/files/0/f/1708478428/Foxfone-One
Foxfone-one-V10f-3_BlackforMozRIL.zip

Thank you :)

Comment 15

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

ni?  Alexandre

Hi Alexandre, per Comment#14, could you try that image to see if there is still any problem in sending/receiving SMS? if that link still don't work for you, please try this one:

https://mozilla.app.box.com/s/v87dfnez9q4bh4g78pb5/1/1708478428/17066979972/1

Thanks

Vance

Comment 16

[:gerard-majax]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> ni?  Alexandre
> 
> Hi Alexandre, per Comment#14, could you try that image to see if there is
> still any problem in sending/receiving SMS? if that link still don't work
> for you, please try this one:
> 
> https://mozilla.app.box.com/s/v87dfnez9q4bh4g78pb5/1/1708478428/17066979972/1
> 
> Thanks
> 
> Vance

Yes, I can download this one. Do we know what are the changes ?

Comment 17

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #16)
> (In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> > ni?  Alexandre
> > 
> > Hi Alexandre, per Comment#14, could you try that image to see if there is
> > still any problem in sending/receiving SMS? if that link still don't work
> > for you, please try this one:
> > 
> > https://mozilla.app.box.com/s/v87dfnez9q4bh4g78pb5/1/1708478428/17066979972/1
> > 
> > Thanks
> > 
> > Vance
> 
> Yes, I can download this one. Do we know what are the changes ?

My question being, to be more clear: is the change on the modem side, or in qualcomm libril ? Or even in Gecko ?

Comment 18

[:gerard-majax]

(In reply to Eric Chang [:ericcc] [:echang] from comment #13)
> Created attachment 8425291 [details]
> 2014-05-20 15.45.39.jpg
> 
> Flame v1.3 V10E, SMS sending okay

Eric, I feel very very bad. There was quite a very good reason for SMS not to go through even after playing with airplane mode: my SIM card was out of credit.

So it looks like I'm reproducing exactly as you do.

Comment 19

[Chris Lord [:cwiiis]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> ni?  Alexandre
> 
> Hi Alexandre, per Comment#14, could you try that image to see if there is
> still any problem in sending/receiving SMS? if that link still don't work
> for you, please try this one:
> 
> https://mozilla.app.box.com/s/v87dfnez9q4bh4g78pb5/1/1708478428/17066979972/1
> 
> Thanks
> 
> Vance

I downloaded this image and flashed a local build of Gecko/Gaia on top of it and can send and receive texts ok, so far at least.

Comment 20

[:gerard-majax]

(In reply to Chris Lord [:cwiiis] from comment #19)
> (In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> > ni?  Alexandre
> > 
> > Hi Alexandre, per Comment#14, could you try that image to see if there is
> > still any problem in sending/receiving SMS? if that link still don't work
> > for you, please try this one:
> > 
> > https://mozilla.app.box.com/s/v87dfnez9q4bh4g78pb5/1/1708478428/17066979972/1
> > 
> > Thanks
> > 
> > Vance
> 
> I downloaded this image and flashed a local build of Gecko/Gaia on top of it
> and can send and receive texts ok, so far at least.

It does not work for me:
 - with the v10F-3 provided, it works
 - pulling new blobs from v10F-3, rebuilding a new system, I'm back with the airplane trick issue.

Comment 21

[Tony Chung [:tchung]]

I just got the V10G-2 image, and also confirm SMS is not working with both Master/mozril and 1.4/mozril.   logcat has no information except: 

05-22 10:41:24.058: E/QCALOG(439): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
05-22 10:41:24.068: E/QCALOG(439): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
05-22 10:41:24.128: E/QCALOG(439): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]

Screen error shows:   "Message not sent.  There was a problem sending the message.  Please try again"

Comment 22

[Tony Chung [:tchung]]

(In reply to Tony Chung [:tchung] from comment #21)
> I just got the V10G-2 image, and also confirm SMS is not working with both
> Master/mozril and 1.4/mozril.   logcat has no information except: 
> 
> 05-22 10:41:24.058: E/QCALOG(439): [MessageQ] ProcessNewMessage: [XT-CS]
> unknown deliver target [OS-Agent]
> 05-22 10:41:24.068: E/QCALOG(439): [MessageQ] ProcessNewMessage: [XTWiFi-PE]
> unknown deliver target [OS-Agent]
> 05-22 10:41:24.128: E/QCALOG(439): [MessageQ] ProcessNewMessage: [XTWWAN-PE]
> unknown deliver target [OS-Agent]
> 
> Screen error shows:   "Message not sent.  There was a problem sending the
> message.  Please try again"

i confirm the airplane mode trick (toggling on/off) fixes it.   we need this to block 2.0.

Comment 23

[Tony Chung [:tchung]]

Ni? Viral/ Thomas for assistance.   Do you guys know what's going on?

Comment 24

[Johan Lorenzo [:jlorenzo] - On PTO - Back on March 18th]

SMS can't also be received on V10G-2 + master.

Step to reproduce
Sent a text message to the Flame device freshly flashed.
Wait 5 minutes => No message shows up.
Activate Airplane mode.
Deactivate it => The text message comes in.

Build Information
Gaia      ef66efa34ed8a559c8998bde688fae88eb943a7a
Gecko     https://hg.mozilla.org/mozilla-central/rev/b40296602083
BuildID   20140522040230
Version   32.0a1
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014

Comment 25

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

ni Ken

Hi Ken, per discussion, since this problem only happened with MOZ RIL, please help to find someone to take a look at this one first.

Thanks!

Comment 26

[viral [:viralwang]]

We already have an offline discussion for the bug.
Ken will help on this bug.
Thanks Ken :)

Comment 27

[Ken Chang[:kenkai]]

Bevis, Please check what is the differences of the initial steps between MozRIL and Commercial RIL in flame.

Comment 28

[:gerard-majax]

v10G-2 does not help either.

Comment 29

[Natalya Kot [:nkot]]

We've started running our manual smoke tests using Flame, so adding 'smoketest' keyword here as the issue still exists. 
Having said that, the workaround (toggling on/off airplane mode) works for us too.

Base v10G-2
BuildID: 20140523040203
Gaia: b61129780e085636d09406f2a46e922d0f8b9757
Gecko: e9b2b72f4e6c
Version: 32.0a1

Comment 30

[Ken Chang[:kenkai]]

> And when the issue reproduces, all I see is:
> 
> > D/RILC    (  345): [0246]> SEND_SMS ((null),01000A816071894055000003477C1D)
> > D/RILC    (  345): [0246]< SEND_SMS fails by E_GENERIC_FAILURE
Hi Wayne, can you please ask partner to check what the specific problem is in RILC? We have tried many ways bug it doesn't help. If partner can give some hints of this failure, it may help.

Comment 31

[Bevis Tseng[:bevis][:btseng](Exited)]

After more comparison of the radio log between QC_RIL/MOZ_RIL,
We found the reason why SMS not able to be sent/received after bootup:
There seems some limitation when using REQUEST_SET_UICC_SUBSCRIPTION:
1. It can only be invoked after RADIO_POWER is set to ON.
2. There is no error reported from RILD when REQUEST_SET_UICC_SUBSCRIPTION during RADIO_POWER is off.

When device boot up, RILD always reports the following events no matter client is connected or not.
1. UNSOL_RESPONSE_RADIO_STATE_CHANGED {RADIO_OFF}
2. UNSOL_RESPONSE_SIM_STATUS_CHANGED (This will trigger the connected client to GET_SIM_STATUS)

When QC_RIL or MOZ_RIL connects to RILD, both will set the RADIO_POWER to OFF and 
wait for upper layer to enable Radio Power according to the settings.

The difference between QC_RIL/MOZ_RIL is that, QC_RIL is connected after SIM_STATUS_CHANGED reported
while MOZ RIL is connected before SIM_STATUS_CHANGED reported.

Then, in MOZ RIL, we will run into a scenario to execute SIM_IO and 
REQUEST_SET_UICC_SUBSCRIPTION while RADIO_POWER is requested to OFF during power on.

In this case, the device is not able to send/receive the SMS.
This problem can be fixed by toggling airplane mode because that
the REQUEST_SET_UICC_SUBSCRIPTION will be done again when RADIO_POWER is turned to ON.

Comment 32

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: WIP: getICCStatus only when radioState is ready.

This is a quick fix to prevent block anyone from testing.
We still need to consider more about 
1. What is the correct initialization sequence of our RadioInterfaceLayer?
2. Shall SIM access be forbidden when RADIO_POWER is off?
3. What mandatory info shall be fetched proactively after initialization is done instead of relying on the UNSOLICITED events from modem?

Comment 33

[Bevis Tseng[:bevis][:btseng](Exited)]

Instead of working around the fix of REQUEST_SET_UICC_SUBSCRIPTION,
I'd like to know in detail from partner if the following symptoms 
during device boot up is normal to come out a better solution:
1. RILD reports UNSOL_RESPONSE_RADIO_STATE_CHANGED {RADIO_UNAVAILABLE},
   UNSOL_RESPONSE_RADIO_STATE_CHANGED {RADIO_OFF}, 
  UNSOL_RESPONSE_SIM_STATUS_CHANGED sequentially.
2. RIL Client in gecko set RADIO_POWER to OFF and 
   wait for application layer to set the expected RadioState according to the user settings.
3. REQUEST_GET_SIM_STATUS triggered by UNSOL_RESPONSE_SIM_STATUS_CHANGED in step#1.
   - What we get is normal and informative response with CARD_PRESENT and CARD_APP available.
   - Hence, we assume that, in Flame, SIM status is independent from RADIO state according to this result.
4. REQUEST_SET_UICC_SUBSCRIPTION according to the response of GET_SIM_STATUS in step#3 without error.
5. The response of GET_SIM_STATUS tell us that the subscription index is set correctly.
6. However, after RADIO_POWER is set to ON by application in step#2, 
   we found voice/data are okay but MO/MT SMS is broken.
(Luckily, we don't see this problem in QC RIL because 
 QC RIL connects to RILD after UNSOL_RESPONSE_SIM_STATUS_CHANGED is reported which postpones the 
 SIM related queries until RADIO_POWER is set to ON).

From our viewpoint, it seems that SET_UICC_SUBSCRIPTION works incompletely when RadioState is OFF.
Hence, we need partner's help to clarify
1. Is it normal to get the positive SIM_STATUS response with CARD_PRESENT/CARD_APP when RADIO_STATE is OFF?
2. If yes, does that means SIM I/O, UICC_SUBSCRIPTION is independent from RADIO_STATE in Flame design?
3. Is there any limitation when using SET_UICC_SUBSCRIPTION during RADIO_STATE is OFF?
   If yes, we expect to see
   a. Some kind of Error was reported in the response of SET_UICC_SUBSCRIPTION.
   b. The subscription index in the response of GET_SIM_STATUS remained unchanged instead.
   If No, we expect that SMS shall be workable as well as voice/data services.

Comment 34

[Wayne Chang [:wchang]]

Anshul,

Can someone help answering Bevis' questions in (In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #33)

> 1. Is it normal to get the positive SIM_STATUS response with
> CARD_PRESENT/CARD_APP when RADIO_STATE is OFF?
> 2. If yes, does that means SIM I/O, UICC_SUBSCRIPTION is independent from
> RADIO_STATE in Flame design?
> 3. Is there any limitation when using SET_UICC_SUBSCRIPTION during
> RADIO_STATE is OFF?
>    If yes, we expect to see
>    a. Some kind of Error was reported in the response of
> SET_UICC_SUBSCRIPTION.
>    b. The subscription index in the response of GET_SIM_STATUS remained
> unchanged instead.
>    If No, we expect that SMS shall be workable as well as voice/data 
> services.

Comment 35

[Jason Smith [:jsmith]]

Blocking this to enable Flame on 1.4 & 2.0.

Comment 36

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Patch v1 - setUiccSubscription when the RadioState is ready. r=htsai, a=1.4+

According to the finding in comment 31, it seems that REQUEST_SET_UICC_SUBSCRIPTION works incompletely if we set it during RADIO_POWER is OFF.
There is no such problem in QC_RIL because this request is only executed after RADIO_POWER is ON.

Fix this bug by REQUEST_SET_UICC_SUBSCRIPTION when RADIO_POWER is ON.

Comment 37

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8429754 [details] [diff] [review]
Patch v1 - setUiccSubscription when the RadioState is ready. r=htsai, a=1.4+

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

Thanks for fixing this crafty issue! r=me with comment addressed.

::: dom/system/gonk/ril_worker.js
@@ +3380,5 @@
> +    if (RILQUIRKS_SUBSCRIPTION_CONTROL && index === -1 &&
> +        this.radioState === GECKO_RADIOSTATE_READY) {
> +      // Should enable uicc scription if index is not valid.
> +      // Note: REQUEST_SET_UICC_SUBSCRIPTION works abnormally when RADIO is OFF, which
> +      // causes SMS function broken in Flame. See bug 1008557 for detailed info.

No problem with the functionality. But please rewrite as 

if (RILQUIRKS_SUBSCRIPTION_CONTROL && index === -1) {
  if (this.radioState !== GECKO_RADIOSTATE_READY) {
    return;
  }
  ... ...
}

in this way, even radio state isn't met, we don't need to do more check (as follows). We know we can return directly.

Comment 38

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Hsin-Yi Tsai (OOO 5/30 ~ 6/8) [:hsinyi] from comment #37)
> Comment on attachment 8429754 [details] [diff] [review]
> Patch v1 - setUiccSubscription when the RadioState is ready. r=htsai, a=1.4+
> 
> Review of attachment 8429754 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks for fixing this crafty issue! r=me with comment addressed.
> 
> ::: dom/system/gonk/ril_worker.js
> @@ +3380,5 @@
> > +    if (RILQUIRKS_SUBSCRIPTION_CONTROL && index === -1 &&
> > +        this.radioState === GECKO_RADIOSTATE_READY) {
> > +      // Should enable uicc scription if index is not valid.
> > +      // Note: REQUEST_SET_UICC_SUBSCRIPTION works abnormally when RADIO is OFF, which
> > +      // causes SMS function broken in Flame. See bug 1008557 for detailed info.
> 
> No problem with the functionality. But please rewrite as 
> 
> if (RILQUIRKS_SUBSCRIPTION_CONTROL && index === -1) {
>   if (this.radioState !== GECKO_RADIOSTATE_READY) {
>     return;
>   }
>   ... ...
> }
> 
> in this way, even radio state isn't met, we don't need to do more check (as
> follows). We know we can return directly.

Thanks! I'll update the patch again to address this. :)

Comment 39

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Patch v2 - setUiccSubscription when the RadioState is ready. r=htsai, a=1.4+

Address the suggestion in comment 37.

Comment 40

[Kai-Chih Hu [:khu]]

My understanding is that this issue is happened in MozRIL only, is it?

Comment 41

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Kevin Hu [:khu] from comment #40)
> My understanding is that this issue is happened in MozRIL only, is it?
Yes, this is a MozRIL-only issue.

Comment 42

[Kai-Chih Hu [:khu]]

Thanks, in this case, I think this bug should block Dolphin. 
Put Ivan to cc list because he is the EPM for Dolphin project.

Comment 43

[Kai-Chih Hu [:khu]]

I suggest to test this on Dolphin to see if it's reproducible. If it's not, we may need to remove 1.4+ tag. Make sense?

Comment 44

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Kevin Hu [:khu] from comment #42)
> Thanks, in this case, I think this bug should block Dolphin. 
> Put Ivan to cc list because he is the EPM for Dolphin project.

I don't think so.
This is a hardware-dependent/modem-aware issue. Dolphin is adopting a different modem solution.

(In reply to Kevin Hu [:khu] from comment #43)
> I suggest to test this on Dolphin to see if it's reproducible. If it's not,
> we may need to remove 1.4+ tag. Make sense?

Not seem necessary for me but it's always safe to have more tests.

Comment 45

[Jason Smith [:jsmith]]

(In reply to Kevin Hu [:khu] from comment #43)
> I suggest to test this on Dolphin to see if it's reproducible. If it's not,
> we may need to remove 1.4+ tag. Make sense?

No. This is our reference solution for testing for 1.4 & 2.0 right now, so this stays as a blocker.

Comment 46

[Kai-Chih Hu [:khu]]

Flame is our reference device, yes, but for this issue, we may need to test it with the RIL we're going to ship, isn't it?

Comment 47

[Kai-Chih Hu [:khu]]

(In reply to Hsin-Yi Tsai (OOO 5/30 ~ 6/8) [:hsinyi] from comment #44)
> (In reply to Kevin Hu [:khu] from comment #42)
> > Thanks, in this case, I think this bug should block Dolphin. 
> > Put Ivan to cc list because he is the EPM for Dolphin project.
> 
> I don't think so.
> This is a hardware-dependent/modem-aware issue. Dolphin is adopting a
> different modem solution.
> 
Thanks for the information. I removed the dependency with the Dolphin meta bug.

Comment 48

[Jason Smith [:jsmith]]

(In reply to Kevin Hu [:khu] from comment #46)
> Flame is our reference device, yes, but for this issue, we may need to test
> it with the RIL we're going to ship, isn't it?

We test on the RIL we have available. Moz RIL is all we have for internal builds at the moment, so this is a test blocker to using Flame as a production testing solution.

Comment 49

[Jason Smith [:jsmith]]

Per a drivers' thread - we can't continue development of this work, so I'm going to unblock this. Probably need to WONTFIX this, but I'm going to wait for Ken to confirm that.

Comment 50

[Bevis Tseng[:bevis][:btseng](Exited)]

update try server result:
https://tbpl.mozilla.org/?tree=Try&rev=81c95186fdc2

Comment 51

[Hsin-Yi Tsai (she/her) [:hsinyi]]

https://hg.mozilla.org/integration/b2g-inbound/rev/61a3ae88f00d
Note: I removed "a=1.4+" from the commit message

Comment 52

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Hsin-Yi Tsai (OOO 5/30 ~ 6/8) [:hsinyi] from comment #51)
> https://hg.mozilla.org/integration/b2g-inbound/rev/61a3ae88f00d
> Note: I removed "a=1.4+" from the commit message

Thanks!

Comment 53

[Ken Chang[:kenkai]]

We seem not to have a conclusion now. Let's see what we need to do in the next 2 days.

Comment 54

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/61a3ae88f00d

Comment 55

[William Hsu [:whsu]]

Good Job! Mike and I have verified this patch.
We cannot reproduce this bug on latest PVT build.

* Build information:
 - Gaia      b669dd2cc321f37cebc7081a79b968cac36b4200
 - Gecko     https://hg.mozilla.org/mozilla-central/rev/b85b57f05fda
 - BuildID   20140529160204
 - Version   32.0a1

Comment 56

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #49)
> Per a drivers' thread - we can't continue development of this work, so I'm
> going to unblock this. Probably need to WONTFIX this, but I'm going to wait
> for Ken to confirm that.

This has been invalidated because this has landed, so I think this statement no longer applies. We've got no ETA for the RIL builds we need & this the only solution we've got, so we need to get unblocked here. As such, I'm putting blocking flag back on as this is a test blocker.

Comment 57

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/de7bd6d744b8

Comment 58

[Natalya Kot [:nkot]]

Verified on both, 2.0 and 1.4 - works as expected - able to send/receive SMS successfully 

Flame 1.4
BuildID: 20140602000203
Gaia: ba8d7ef46cadf5d66d189b0b036d0f2e936bece0
Gecko: 384d3410a854
Version: 30.0
v10G-2