988979 - [B2G][General] After restarting or resetting device does not detect SIM card

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Brogan Zumwalt [Inactive]]

Description:
After user restarts, resets, or re-flashes device the SIM card is not detected by phone. Subsequent restarting, re-flashing, or resetting does not solve issue.

Repro Steps:
1) Updated Buri to BuildID: 20140327074806
2) After completing FTU launch settings app
3) Go to Device Information>More Information
4) Select "Reset Phone"

Actual:
After restarting, resetting, or reflashing to same build the phone does not detect SIM card.

Expected:
SIM card is always detected.

Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140327074806
Gaia: 7d716de0c186416b5b123baa1f3242e23d50529b
Gecko: 69e896713b11
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 3/3, 100%

Comment 1

[Gabriele Svelto [:gsvelto] (PTO)]

We encountered a similar issue on other phones with an older RIL, see bug 976497. Not sure if it's the same issue or not.

Comment 2

[Gabriele Svelto [:gsvelto] (PTO)]

I've just tested this on my buri with today's build and I can reproduce the issue. Enabling and disabling airplane mode makes the SIM card reappear so this looks a lot like bug 976497. I'll try to investigate this further tomorrow.

Comment 3

[Brogan Zumwalt [Inactive]]

Attachment: Logcat

Logcat from immediately after restart (SIM Works before restart > SIM not detected after restart)

Comment 4

[Natalya Kot [:nkot]]

We're working on getting regression-window here but there is a lot of confusion on how to reliably recover from the state when device doesn't detect SIM as it caries over to other builds

So far we were only able to identify last_working/first_broken builds and we're continue working on this issue

~Last Working~
BuildID: 20140326120354
Gaia: 29ed37f475ecfd292722f8d9c918c817c6e57e9b
Gecko: 2eb3d41f2673
Version: 30.0a2

~First Broken~
BuildID: 20140326135454
Gaia: 7d716de0c186416b5b123baa1f3242e23d50529b
Gecko: e4e9fa607b78
Version: 30.0a2

Comment 5

[Natalya Kot [:nkot]]

Rough pushlogs in case in can be helpful... and as i said, we're continue working on this issue

Gecko Pushlog: 
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=2eb3d41f2673&tochange=e4e9fa607b78

Gaia Pushlog: 
https://github.com/mozilla-b2g/gaia/compare/29ed37f475ecfd292722f8d9c918c817c6e57e9b...7d716de0c186416b5b123baa1f3242e23d50529b

Comment 6

[Noemí Freire (:noemi)]

This issue seems to be the same as bug 976497, dupe?

Comment 7

[Jason Smith [:jsmith]]

(In reply to Noemí Freire (:noemi) from comment #6)
> This issue seems to be the same as bug 976497, dupe?

No. This problem only started happening yesterday. That issue has been present since 2/25 & likely has to do with the devices that don't have production device support.

Comment 8

[Jason Smith [:jsmith]]

If it's gecko related, then this was caused by bug 984919.

If it's gaia related, then this was caused by bug 974253.

Comment 9

[Jason Smith [:jsmith]]

The swap is showing that this is a gecko regression, which points to bug 984919 as the cause.

Comment 10

[Ed Morley [:emorley]]

Bug 984919 has been backed out.

Comment 11

[Jason Smith [:jsmith]]

Should be resolved per the backout in bug 984919.

Comment 12

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

(In reply to Jason Smith [:jsmith] from comment #11)
> Should be resolved per the backout in bug 984919.

Have this issue been verified after bug 984919 backed out? I tried mozilla-aurora 185204:3aaca223b673 (bug 984919 was backed out already) and the issue still exists, i.e. after rebooting, sim card isn't detected. 

I don't think bug 984919 causes this regression. Bug 984919 does not touch cardState related code at all. It touches only the path of "telphony.dial()." More investigation is required.

Comment 13

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

REOPENED per my comment 12.

Comment 14

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

Attachment: log - radio tech is 1xrtt

Weird ... radio tech is reported as 1xrtt (cdma tech) but it should be gsm tech. According to the radio tech, this._isCdma is set to true that leads to error while parsing card state information.

Comment 15

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

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #14)
> Created attachment 8399246 [details]
> log - radio tech is 1xrtt
> 
> Weird ... radio tech is reported as 1xrtt (cdma tech) but it should be gsm
> tech. According to the radio tech, this._isCdma is set to true that leads to
> error while parsing card state information.

Note: after turning on and off airplane mode, we query the right radio tech (gprs) from modem. I am wondering if this is a partner issue.

Comment 16

[Edgar Chen [:edgar]]

I guess we meet the same problem as bug 969079.

Comment 17

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

Thank to Edgar's information.

I followed his suggestion in bug 969079 comment 16 that works. 

So, the root cause of this issue is the lack of correct hardware configuration. We need vendor's help on bug 960906.

Comment 18

[Jason Smith [:jsmith]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #12)
> (In reply to Jason Smith [:jsmith] from comment #11)
> > Should be resolved per the backout in bug 984919.
> 
> Have this issue been verified after bug 984919 backed out? I tried
> mozilla-aurora 185204:3aaca223b673 (bug 984919 was backed out already) and
> the issue still exists, i.e. after rebooting, sim card isn't detected. 

We couldn't fully verify it. We just knew it was between two potential patches (one gaia, one gecko). I guess that makes bug 974253 the cause then.

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #17)
> Thank to Edgar's information.
> 
> I followed his suggestion in bug 969079 comment 16 that works. 
> 
> So, the root cause of this issue is the lack of correct hardware
> configuration. We need vendor's help on bug 960906.

Not happening - you can't blame every issue on a vendor, especially when we caused the regression itself. This is too critical of a regression to put a dependency on a partner to solve the issue, especially when the regression was caused by a change that we made. If this isn't caused by the other patch that was backed out, then this has to be caused by bug 974253.

Arthur - Can you test a backout of your patch on bug 974253 to see if this issue is fixed upon backout?

Comment 19

[Julien Wajsberg [:julienw]]

(In reply to Jason Smith [:jsmith] from comment #7)
> (In reply to Noemí Freire (:noemi) from comment #6)
> > This issue seems to be the same as bug 976497, dupe?
> 
> No. This problem only started happening yesterday. That issue has been
> present since 2/25 & likely has to do with the devices that don't have
> production device support.

What is this supposed to mean "production device support" ?

What I see is that our code seems to be very sensitive to timing issues.

Comment 20

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] (away until March 24) from comment #19)
> (In reply to Jason Smith [:jsmith] from comment #7)
> > (In reply to Noemí Freire (:noemi) from comment #6)
> > > This issue seems to be the same as bug 976497, dupe?
> > 
> > No. This problem only started happening yesterday. That issue has been
> > present since 2/25 & likely has to do with the devices that don't have
> > production device support.
> 
> What is this supposed to mean "production device support" ?

Devices that are phones shipped in our target markets - Buri, Ikura, Leo, etc.

Comment 21

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

(In reply to Jason Smith [:jsmith] from comment #18)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #12)
> > (In reply to Jason Smith [:jsmith] from comment #11)
> > > Should be resolved per the backout in bug 984919.
> > 
> > Have this issue been verified after bug 984919 backed out? I tried
> > mozilla-aurora 185204:3aaca223b673 (bug 984919 was backed out already) and
> > the issue still exists, i.e. after rebooting, sim card isn't detected. 
> 
> We couldn't fully verify it. We just knew it was between two potential
> patches (one gaia, one gecko). I guess that makes bug 974253 the cause then.
> 
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #17)
> > Thank to Edgar's information.
> > 
> > I followed his suggestion in bug 969079 comment 16 that works. 
> > 
> > So, the root cause of this issue is the lack of correct hardware
> > configuration. We need vendor's help on bug 960906.
> 
> Not happening - you can't blame every issue on a vendor, 

I don't blame them, but as mechanism of getting and setting 'preferred network type' changes one gecko and gaia, we need related changes on vendor side as well. Otherwise, how could we get the right configuration of our device? Without the device capability, we are unable to set the right network type for our device. Please note the original request from bug 960926. More, Bug 969079 comment 14 pointed out the same cause of this bug (attachment 8399246 [details]).

> especially when we
> caused the regression itself. This is too critical of a regression to put a
> dependency on a partner to solve the issue, especially when the regression
> was caused by a change that we made. If this isn't caused by the other patch
> that was backed out, then this has to be caused by bug 974253.
> 
> Arthur - Can you test a backout of your patch on bug 974253 to see if this
> issue is fixed upon backout?

Comment 22

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

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #21)
> (In reply to Jason Smith [:jsmith] from comment #18)
> > (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #12)
> > > (In reply to Jason Smith [:jsmith] from comment #11)
> > > > Should be resolved per the backout in bug 984919.
> > > 
> > > Have this issue been verified after bug 984919 backed out? I tried
> > > mozilla-aurora 185204:3aaca223b673 (bug 984919 was backed out already) and
> > > the issue still exists, i.e. after rebooting, sim card isn't detected. 
> > 
> > We couldn't fully verify it. We just knew it was between two potential
> > patches (one gaia, one gecko). I guess that makes bug 974253 the cause then.
> > 
> > (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #17)
> > > Thank to Edgar's information.
> > > 
> > > I followed his suggestion in bug 969079 comment 16 that works. 
> > > 
> > > So, the root cause of this issue is the lack of correct hardware
> > > configuration. We need vendor's help on bug 960906.
> > 
> > Not happening - you can't blame every issue on a vendor, 
> 
> I don't blame them, but as mechanism of getting and setting 'preferred
> network type' changes one gecko and gaia, we need related changes on vendor
> side as well. Otherwise, how could we get the right configuration of our
> device? Without the device capability, we are unable to set the right
> network type for our device. Please note the original request from bug
> 960926. 
 ^^^^^^^^ Sorry, should be bug 960906

> More, Bug 969079 comment 14 pointed out the same cause of this bug
> (attachment 8399246 [details]).
> 
> > especially when we
> > caused the regression itself. This is too critical of a regression to put a
> > dependency on a partner to solve the issue, especially when the regression
> > was caused by a change that we made. If this isn't caused by the other patch
> > that was backed out, then this has to be caused by bug 974253.
> > 
> > Arthur - Can you test a backout of your patch on bug 974253 to see if this
> > issue is fixed upon backout?

Comment 23

[Jason Smith [:jsmith]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #21)
> (In reply to Jason Smith [:jsmith] from comment #18)
> > (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #12)
> > > (In reply to Jason Smith [:jsmith] from comment #11)
> > > > Should be resolved per the backout in bug 984919.
> > > 
> > > Have this issue been verified after bug 984919 backed out? I tried
> > > mozilla-aurora 185204:3aaca223b673 (bug 984919 was backed out already) and
> > > the issue still exists, i.e. after rebooting, sim card isn't detected. 
> > 
> > We couldn't fully verify it. We just knew it was between two potential
> > patches (one gaia, one gecko). I guess that makes bug 974253 the cause then.
> > 
> > (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #17)
> > > Thank to Edgar's information.
> > > 
> > > I followed his suggestion in bug 969079 comment 16 that works. 
> > > 
> > > So, the root cause of this issue is the lack of correct hardware
> > > configuration. We need vendor's help on bug 960906.
> > 
> > Not happening - you can't blame every issue on a vendor, 
> 
> I don't blame them, but as mechanism of getting and setting 'preferred
> network type' changes one gecko and gaia, we need related changes on vendor
> side as well. Otherwise, how could we get the right configuration of our
> device? Without the device capability, we are unable to set the right
> network type for our device. Please note the original request from bug
> 960926. More, Bug 969079 comment 14 pointed out the same cause of this bug
> (attachment 8399246 [details]).

In these particular situations, you need to communicate to the vendor to make the change before you make the gaia/gecko change for devices actively in use in production testing. Otherwise, QA is going to get blocked. Right now, the entire QA team is blocked in daily testing due to this problem that apparently only appeared recently per the regression range.

I'm still not convinced that the problem is on the vendor side, as a regression range provides hard evidence that 1) this only recently started happening 2) was probably caused by the change in bug 974253 after finding out that the other patch was unrelated.

QA needs to get unblocked here, so we need a fix on gaia or gecko to unblock testing. That might mean we may need to implement a hack here to get this working again in daily builds.

Comment 24

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

(In reply to Jason Smith [:jsmith] from comment #23)
> (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #21)
> > (In reply to Jason Smith [:jsmith] from comment #18)
> > > (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #12)
> > > > (In reply to Jason Smith [:jsmith] from comment #11)
> > > > > Should be resolved per the backout in bug 984919.
> > > > 
> > > > Have this issue been verified after bug 984919 backed out? I tried
> > > > mozilla-aurora 185204:3aaca223b673 (bug 984919 was backed out already) and
> > > > the issue still exists, i.e. after rebooting, sim card isn't detected. 
> > > 
> > > We couldn't fully verify it. We just knew it was between two potential
> > > patches (one gaia, one gecko). I guess that makes bug 974253 the cause then.
> > > 
> > > (In reply to Hsin-Yi Tsai  [:hsinyi] from comment #17)
> > > > Thank to Edgar's information.
> > > > 
> > > > I followed his suggestion in bug 969079 comment 16 that works. 
> > > > 
> > > > So, the root cause of this issue is the lack of correct hardware
> > > > configuration. We need vendor's help on bug 960906.
> > > 
> > > Not happening - you can't blame every issue on a vendor, 
> > 
> > I don't blame them, but as mechanism of getting and setting 'preferred
> > network type' changes one gecko and gaia, we need related changes on vendor
> > side as well. Otherwise, how could we get the right configuration of our
> > device? Without the device capability, we are unable to set the right
> > network type for our device. Please note the original request from bug
> > 960926. More, Bug 969079 comment 14 pointed out the same cause of this bug
> > (attachment 8399246 [details]).
> 
> In these particular situations, you need to communicate to the vendor to
> make the change before you make the gaia/gecko change for devices actively
> in use in production testing. Otherwise, QA is going to get blocked. Right
> now, the entire QA team is blocked in daily testing due to this problem that
> apparently only appeared recently per the regression range.
> 
> I'm still not convinced that the problem is on the vendor side, as a
> regression range provides hard evidence that 1) this only recently started
> happening 2) was probably caused by the change in bug 974253 after finding
> out that the other patch was unrelated.
> 

I could see backing out bug 974253 is likely resolving this issue. Of course, let us wait for Arthur's confirmation.

So maybe I should say this way, to have bug 974253 work as expected, we will need vendor's support on bug 960906.

> QA needs to get unblocked here, so we need a fix on gaia or gecko to unblock
> testing. That might mean we may need to implement a hack here to get this
> working again in daily builds.

Okay, I got your concern. If Arthur confirms this is triggered by 974253, then agree backing out is a way. And having vendor's support on bug 960906 is another story.

Comment 25

[Arthur Chen [:arthurcc][inactive after 6/30]]

Jason, I could still reproduce the issue on Inari with the patch on bug 974253 backed out.

Comment 26

[William Dorffer [:Nildeala]]

I also still reproduce on a Peak.

Comment 27

[Jason Smith [:jsmith]]

(In reply to Arthur Chen [:arthurcc] from comment #25)
> Jason, I could still reproduce the issue on Inari with the patch on bug
> 974253 backed out.

You need to test the backout with a production device (preferably Buri) - there's already a known issue with devices that aren't production-based.

Can you please check this with a Buri specifically?

Comment 29

[Arthur Chen [:arthurcc][inactive after 6/30]]

I could still reproduce the issue with/without the patch on bug 974253 (Hamachi, production build). However, I could not reproduce it if I manually set the preferred network type as the comment[1] suggested before resetting the phone. That might suggest that there are issues related to modem.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=969079#c12

Comment 30

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

(In reply to Arthur Chen [:arthurcc] from comment #29)
> I could still reproduce the issue with/without the patch on bug 974253
> (Hamachi, production build). However, I could not reproduce it if I manually
> set the preferred network type as the comment[1] suggested before resetting
> the phone. That might suggest that there are issues related to modem.
> 
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=969079#c12

Agree with Arthur it looks like modem-dependent. However, we are working on bug 990383 which should be able to save us from this regression.

Comment 32

[Florin Strugariu [:Bebe]]

This issue is breaking out automation air plane mode test:

From the screen shot it looks like it's searching for the cell network while the air plane mode is on.
https://www.dropbox.com/s/igxt117klb7ukug/2014-04-01-18-28-02.png

Our automated test locks the air plane mode toggle and it can not be used

Manually this is fixing the issue after a air plane mode on/off and we can properly see the cell data

Gaia      874fe42b82e8d819d592690e74db91c07179e68c
Gecko     https://hg.mozilla.org/mozilla-central/rev/1417d180a1d8
BuildID   20140401040202
Version   31.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

Comment 33

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Is this bug a dup to bug 990383 instead of a dependent? What do Settings needs to do more here?

Comment 34

[Arthur Chen [:arthurcc][inactive after 6/30]]

No, we don't need to do anything to settings. But we still need to test if the issue gets resolved after bug 990383 lands.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

OK, please do so after bug 990383 lands.

Comment 37

[Jason Smith [:jsmith]]

Marking qawanted to retest this in the 4/3 build if this still reproduces with the dependency fixed.

Comment 38

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #37)
> Marking qawanted to retest this in the 4/3 build if this still reproduces
> with the dependency fixed.

Specifically trunk btw.

Comment 39

[Matthew Vaughan]

(In reply to Jason Smith [:jsmith] from comment #38)
> (In reply to Jason Smith [:jsmith] from comment #37)
> > Marking qawanted to retest this in the 4/3 build if this still reproduces
> > with the dependency fixed.
> 
> Specifically trunk btw.

This issue does *not* reproduce on the 04/04/14 Master branch. I reset and restarted the device multiple times and the SIM was detected each time and was usable.

Device: Buri Master MOZ RIL
BuildID: 20140404040204
Gaia: d9a574284d672f532f7c562a091bb01f531202b1
Gecko: 6c924a018540
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Comment 40

[Jason Smith [:jsmith]]

Okay - marking fixed by the dependency.