Closed Bug 1008557 Opened 7 years ago Closed 6 years ago

[Flame] Unable to send or receive SMS

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.4+, firefox30 wontfix, firefox31 wontfix, firefox32 fixed, b2g-v1.4 verified, b2g-v2.0 verified)

VERIFIED FIXED
2.0 S3 (6june)
blocking-b2g 1.4+
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
b2g-v1.4 --- verified
b2g-v2.0 --- verified

People

(Reporter: gerard-majax, Assigned: bevis)

References

Details

(Keywords: smoketest, Whiteboard: [p=3])

Attachments

(3 files, 2 obsolete files)

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
Not a regression, so this is not a QA blocker.
Keywords: qablocker
(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.
Attached file 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}
(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.
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
REQUEST_GSM_SMS_BROADCAST_ACTIVATION is identified as unknown request because hardware/ril/ril.cpp lacks RIL_REQUEST_GSM_SMS_BROADCAST_ACTIVATION mapping.
(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.
(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.
Flags: needinfo?(echen)
(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.
(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.
Flags: needinfo?(htsai)
(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. :)
Flags: needinfo?(htsai)
Is it reproducible on 1.3 with commercial RIL?
Keywords: qawanted
Attached image 2014-05-20 15.45.39.jpg
Flame v1.3 V10E, SMS sending okay
(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 :)
Flags: needinfo?(echen)
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
Flags: needinfo?(lissyx+mozillians)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] 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 ?
Flags: needinfo?(lissyx+mozillians) → needinfo?(vchen)
(In reply to Alexandre LISSY :gerard-majax from comment #16)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] 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 ?
(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.
Flags: needinfo?(vchen)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] 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.
(In reply to Chris Lord [:cwiiis] from comment #19)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] 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.
Flags: needinfo?(vchen)
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"
(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.
Ni? Viral/ Thomas for assistance.   Do you guys know what's going on?
Flags: needinfo?(vwang)
Flags: needinfo?(ttsai)
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
Summary: [Flame] Unable to send SMS → [Flame] Unable to send or receive SMS
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!
Flags: needinfo?(vchen) → needinfo?(kchang)
We already have an offline discussion for the bug.
Ken will help on this bug.
Thanks Ken :)
Flags: needinfo?(vwang)
Flags: needinfo?(ttsai)
Bevis, Please check what is the differences of the initial steps between MozRIL and Commercial RIL in flame.
Assignee: nobody → btseng
Flags: needinfo?(kchang)
v10G-2 does not help either.
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
Keywords: smoketest
> 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.
Flags: needinfo?(wchang)
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.
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?
Flags: needinfo?(wchang)
blocking-b2g: 2.0? → 1.4?
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.
Flags: needinfo?(vchen)
Whiteboard: p=3
Target Milestone: --- → 2.0 S3 (6june)
Anshul,

Can someone help answering Bevis' questions in (In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) 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.
Flags: needinfo?(anshulj)
Blocking this to enable Flame on 1.4 & 2.0.
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(anshulj)
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.
Attachment #8428636 - Attachment is obsolete: true
Attachment #8429754 - Flags: review?(htsai)
Flags: needinfo?(vchen)
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.
Attachment #8429754 - Flags: review?(htsai) → review+
(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. :)
Whiteboard: p=3 → [p=3]
My understanding is that this issue is happened in MozRIL only, is it?
(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.
Thanks, in this case, I think this bug should block Dolphin. 
Put Ivan to cc list because he is the EPM for Dolphin project.
Blocks: dolphin
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?
blocking-b2g: 1.4+ → 1.4?
(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.
(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.
blocking-b2g: 1.4? → 1.4+
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?
(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.
No longer blocks: dolphin
(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.
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.
blocking-b2g: 1.4+ → ---
Flags: needinfo?(kchang)
Keywords: smoketest
(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!
We seem not to have a conclusion now. Let's see what we need to do in the next 2 days.
Flags: needinfo?(kchang)
https://hg.mozilla.org/mozilla-central/rev/61a3ae88f00d
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Keywords: smoketest
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
Status: RESOLVED → VERIFIED
(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.
blocking-b2g: --- → 1.4+
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
You need to log in before you can comment on or make changes to this bug.