Closed Bug 961934 Opened 6 years ago Closed 6 years ago

[DSDS][MMS] Unable to switch data call from primary SIM to 2nd if user tries to download MMS attachment of 2nd SIM.

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3+)

VERIFIED DUPLICATE of bug 961938
1.3 C3/1.4 S3(31jan)
blocking-b2g 1.3+

People

(Reporter: echu, Assigned: jessica)

References

Details

(Whiteboard: dsdsrun1.3-2)

Attachments

(3 files)

Unable to switch data call from primary SIM to 2nd if user tries to download MMS attachment of 2nd SIM.

* Build Number  
Fugu
Gaia      ee25b0e45649d2955f340ce4f71ad55712dd0fab
Gecko     913cf2b92845441c9578787362ddad6f2ac15df6
BuildID   20140121095108
Version   28.0a2

* Reproduce Steps
1. Send a MMS to non-primary data SIM.
2. Once receive the message, press download button within it.
3. When confirmation window pops up, select okay to download the attachment.

* Expected Result
Data call will be switched to non-primary data SIM and start downloading.

* Actual Result
Data call is not switched successfully, but the message still shows downloading and have no way to stop it.

* Occurrence rate
Only the first time works, after that, no matter SIM1 to SIM 2 or SIM 2 to SIM 1, unable to switch the data call.
I heard of this is by far a vendor's issue that we cannot switch Data connection among SIMs.
Hardware: x86_64 → ARM
Blocks: 918558
I found something weird in the logs (attachment 8362795 [details]).

There are always two 'ril.data.defaultServiceId' commands send to RIL in 2-3 seconds:
01-21 12:59:44.384 I/Gecko   (  107): -*- RadioInterfaceLayer: 'ril.data.defaultServiceId' is now 1
01-21 12:59:46.484 I/Gecko   (  107): -*- RadioInterfaceLayer: 'ril.data.defaultServiceId' is now 0
and:
01-21 13:04:12.774 I/Gecko   (  107): -*- RadioInterfaceLayer: 'ril.data.defaultServiceId' is now 1
01-21 13:04:14.484 I/Gecko   (  107): -*- RadioInterfaceLayer: 'ril.data.defaultServiceId' is now 0
So the default sim for data call was not switched.
And finally:
01-21 13:08:28.724 I/Gecko   (  107): -*- RadioInterfaceLayer: 'ril.data.defaultServiceId' is now 1
default sim for data call was switched to SIM2.

I wonder if this is related to bug 961938.

Enpei, could you help verify if this issue can be reproduced if you switch default sim for data call manually? Many thanks.
Hi Jessica,

Switch data sim from SIM manager has no such problem, thanks.
(In reply to Jessica Jong [:jjong] [:jessica] from comment #3)
> I found something weird in the logs (attachment 8362795 [details]).
> 
> There are always two 'ril.data.defaultServiceId' commands send to RIL in 2-3
> seconds:
> 01-21 12:59:44.384 I/Gecko   (  107): -*- RadioInterfaceLayer:
> 'ril.data.defaultServiceId' is now 1
> 01-21 12:59:46.484 I/Gecko   (  107): -*- RadioInterfaceLayer:
> 'ril.data.defaultServiceId' is now 0
> and:
> 01-21 13:04:12.774 I/Gecko   (  107): -*- RadioInterfaceLayer:
> 'ril.data.defaultServiceId' is now 1
> 01-21 13:04:14.484 I/Gecko   (  107): -*- RadioInterfaceLayer:
> 'ril.data.defaultServiceId' is now 0
> So the default sim for data call was not switched.
> And finally:
> 01-21 13:08:28.724 I/Gecko   (  107): -*- RadioInterfaceLayer:
> 'ril.data.defaultServiceId' is now 1
> default sim for data call was switched to SIM2.
> 
> I wonder if this is related to bug 961938.

Yes, that's it. Because data connection cannot switch to the other SIM, so the confirmation prompt would keep popping up until the data connection is switched.
Blocks: 961938
No longer blocks: 961938
ken

Please look at it from RIL perspective.
Flags: needinfo?(kchang)
Component: Gaia::SMS → RIL
blocking-b2g: 1.3? → 1.3+
Jessica, I wonder if it is possible to fix 922584 before this week. If not, we should discuss with Steve to see if we can have a alternative solution.
Assignee: nobody → jjong
Flags: needinfo?(kchang) → needinfo?(jjong)
Whiteboard: dsdsrun1.3-2 → dsdsrun1.3-2 [FT:RIL]
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
(In reply to Ken Chang[:ken] from comment #7)
> Jessica, I wonder if it is possible to fix 922584 before this week. If not,
> we should discuss with Steve to see if we can have a alternative solution.

I talked with Steve yesterday. The root cause seems bug 961938 which is kinda blocked by bug 922584.
We agreed that if this bug is urgent (1.3+), then gaia could provide a workaround at this moment. However, I strongly suggest that we move bug 922584 much more faster.
Flags: needinfo?(jjong)
(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #8)
> (In reply to Ken Chang[:ken] from comment #7)
> > Jessica, I wonder if it is possible to fix 922584 before this week. If not,
> > we should discuss with Steve to see if we can have a alternative solution.
> 
> I talked with Steve yesterday. The root cause seems bug 961938 which is
> kinda blocked by bug 922584.
> We agreed that if this bug is urgent (1.3+), then gaia could provide a
> workaround at this moment. However, I strongly suggest that we move bug
> 922584 much more faster.

Cool, Jessica provided a very good solution (I won't say it's a workaround ;) ) for gaia. And we could move those bugs on based on her suggestion! Thanks, Jessica :D
(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #9)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #8)
> > (In reply to Ken Chang[:ken] from comment #7)
> > > Jessica, I wonder if it is possible to fix 922584 before this week. If not,
> > > we should discuss with Steve to see if we can have a alternative solution.
> > 
> > I talked with Steve yesterday. The root cause seems bug 961938 which is
> > kinda blocked by bug 922584.
> > We agreed that if this bug is urgent (1.3+), then gaia could provide a
> > workaround at this moment. However, I strongly suggest that we move bug
> > 922584 much more faster.
> 
> Cool, Jessica provided a very good solution (I won't say it's a workaround
> ;) ) for gaia. And we could move those bugs on based on her suggestion!
> Thanks, Jessica :D
Thanks, Jessica and Hsinyi, by the way, who will provide a patch for this bug for Gaia?
Flags: needinfo?(jjong)
(In reply to Ken Chang[:ken] from comment #10)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #9)
> > (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #8)
> > > (In reply to Ken Chang[:ken] from comment #7)
> > > > Jessica, I wonder if it is possible to fix 922584 before this week. If not,
> > > > we should discuss with Steve to see if we can have a alternative solution.
> > > 
> > > I talked with Steve yesterday. The root cause seems bug 961938 which is
> > > kinda blocked by bug 922584.
> > > We agreed that if this bug is urgent (1.3+), then gaia could provide a
> > > workaround at this moment. However, I strongly suggest that we move bug
> > > 922584 much more faster.
> > 
> > Cool, Jessica provided a very good solution (I won't say it's a workaround
> > ;) ) for gaia. And we could move those bugs on based on her suggestion!
> > Thanks, Jessica :D
> Thanks, Jessica and Hsinyi, by the way, who will provide a patch for this
> bug for Gaia?

I think Steve is working on this, see bug 961938, which seems to be the root cause of this bug.
Flags: needinfo?(jjong)
Steve, this bug seems not a blocker for bug 961938. should we set this bug as a duplicate of bug 961938?
Flags: needinfo?(schung)
Attached patch dsds.patchSplinter Review
Hi Jessica, here is the WIP patch which should trigger the mms retrieval at the correct timing. Please verify the issue again after patch applied, thanks.
Attachment #8365826 - Flags: feedback?(jjong)
Flags: needinfo?(schung)
I updated the patch in attachment 8365825 [details] [review] and Enpei is testing for it. We can verify it when patch landed, but I think we can duplicate this one with her positive feedback first.
(In reply to Steve Chung [:steveck] from comment #13)
> Created attachment 8365826 [details] [diff] [review]
> dsds.patch
> 
> Hi Jessica, here is the WIP patch which should trigger the mms retrieval at
> the correct timing. Please verify the issue again after patch applied,
> thanks.

Jessica, can you help to provide feedback?
Flags: needinfo?(jjong)
Sorry for not giving feedback yet. Enpei is helping us testing the patch provided by Steve, we found some issues while doing the tests and wanted to make sure it is not related to the original issue. Will sync with her today.
Flags: needinfo?(jjong)
During the test I met bug 965107 but the occurrence rate is not 100%. I assume that it's not related to this bug but need to be tracked after this bug is landed on 1.3. So I open that bug first for tracking. 

But if anyone has concern, feel free to comment it.
Comment on attachment 8365826 [details] [diff] [review]
dsds.patch

From Enpei's comment 17, the original issue can be solved with this patch (or the latest patch in bug 961938). So I think we can mark this as duplicated. Thank you.
Attachment #8365826 - Flags: feedback?(jjong) → feedback+
Set as duplicate per comment 14, comment 17, and comment 18
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 961938
Verified.

Fugu - 
Gaia      bb36b4164d3e51ca04b612e507e1178f80bf240d
Gecko     4227240a4d3e1e418ced160c2a48cb454d7b5645
BuildID   20140204104742
Version   28.0
Status: RESOLVED → VERIFIED
Whiteboard: dsdsrun1.3-2 [FT:RIL] → dsdsrun1.3-2
You need to log in before you can comment on or make changes to this bug.