1136585 - Cannot camp on network after rild disconnection and re-connection (i.e. adb shell kill)

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Vendcom, defect)

Description

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

This is a clone of https://bugzilla.mozilla.org/show_bug.cgi?id=1067629#c68

We noticed that after killing rild, even rild re-connects successfully and radio is enabled as expected, the device is not able to camp on the network.

This issue is independent of the recovery mechanism we use. I.e., we see this issue no matter bug 1067629 is landed or not.

Comment 1

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

Note that after second review of log, I saw "setDataRegistration" had been sent after rild re-connection. I don't see something obviously suspicious at the moment. Further investigation required.

Comment 2

[Ben Hsu [:HoPang]]

Attachment: Request network information despite current ICC state

After applying this patch to gecko, we can restore the voice registration state after |rild| restarts, and further make the device "looks" camped on the network. However, there are two things weird occur. First, the voice registration state of sim[0] will become "disconnected" after we kill the |rild| of sim[1]. Second, after |rild| restarts and voice registration state becomes "connected", we won't get any |UNSOLICITED_RESPONSE_CALL_STATE_CHANGED| when either making a phone call or being called.

Comment 3

[Ben Hsu [:HoPang]]

Attachment: Part 1: Enable and extend the debug messages

Comment 4

[Ben Hsu [:HoPang]]

Attachment: Part 2: Query network information on signal strength changes

Comment 5

[Ben Hsu [:HoPang]]

With the two patches, we now can restore the voice registration states of both modems no matter which |rild| is killed, though the patch fixes this issue filthily. However, we still no longer can receive any |UNSOLICITED_RESPONSE_CALL_STATE_CHANGED| after any |rild| is killed.

Comment 6

[Ben Hsu [:HoPang]]

Attachment: log

[Device]
Flame equipped with two SIM cards

[Steps]
1. Turn on the phone
2. Kill rild[0], and wait for the voice registration states recover
3. Kill rild[1], and wait for the voice registration states recover

Hi Anshul,

After rild[1] connected again, I found out there is no |UNSOLICITED_RESPONSE_VOICE_NETWORK_STATE_CHANGED| between the time voice registration state of SIM[0] becomes disconnected (line 25203) and the time voice registration state of SIM[0] becomes connected (line 26891). I think there should be one |UNSOLICITED_RESPONSE_VOICE_NETWORK_STATE_CHANGED| within the interval to indicate the state has changed, otherwise we have to poll the voice registration state as the patch does. Is there should be a |UNSOLICITED_RESPONSE_VOICE_NETWORK_STATE_CHANGED|?

Besides, do you know why we can no longer receive any |UNSOLICITED_RESPONSE_CALL_STATE_CHANGED| after one of the rilds being killed?

Comment 7

[Anshul]

Ben, please have your OEM file an SR in the QC case system for me to find the right team to look at the issue.

Comment 8

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

Hi Wesly,
You may want to take a look at this.

Comment 9

[Wesly Huang (EPM)]

Hi Youlong, would you have a SR for this issue as mentioned in comment#7, so we can officially have a support from QCT to look into it?

Thank you!

Comment 10

[youlong.jiang]

(In reply to Wesly Huang from comment #9)
> Hi Youlong, would you have a SR for this issue as mentioned in comment#7, so
> we can officially have a support from QCT to look into it?
> 
> Thank you!

Dears -

pls follow case '01963087' to check this problem.

tks.

Comment 11

[Wesly Huang (EPM)]

Thanks Youlong!

Hi Anshul, please see 01963087 and help direct this issue to right team, thanks!

Comment 12

[Anshul]

Wesley, our CE team is working with the customer to investigate this issue.

Comment 13

[youlong.jiang]

Dears -

qcom request to collect proper QXDM logs, log mask attached.

tks.

Comment 14

[youlong.jiang]

Attachment: logMask.dmc

Comment 15

[Anshul]

youlong.jiang, please work with QC through the case system and not through bugzilla.

Comment 16

[BMO Automation]

Firefox OS is not being worked on