Closed Bug 988979 Opened 6 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

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

RESOLVED FIXED
1.4 S5 (11apr)
blocking-b2g 1.4+
Tracking Status
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: bzumwalt, Assigned: arthurcc)

References

Details

(Keywords: regression, smoketest, Whiteboard: [xfail])

Attachments

(2 files)

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%
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.
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.
Attached file Logcat
Logcat from immediately after restart (SIM Works before restart > SIM not detected after restart)
QA Contact: jharvey
blocking-b2g: --- → 1.4?
Component: General → RIL
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
This issue seems to be the same as bug 976497, dupe?
(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.
If it's gecko related, then this was caused by bug 984919.

If it's gaia related, then this was caused by bug 974253.
The swap is showing that this is a gecko regression, which points to bug 984919 as the cause.
Blocks: 984919
Bug 984919 has been backed out.
Keywords: qaurgent
Should be resolved per the backout in bug 984919.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
blocking-b2g: 1.4? → 1.4+
(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.
REOPENED per my comment 12.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(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.
I guess we meet the same problem as bug 969079.
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.
Depends on: 960906
Component: RIL → Vendcom
No longer blocks: 984919
(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?
Blocks: 974253
Component: Vendcom → Gaia::Settings
No longer depends on: 960906
Flags: needinfo?(arthur.chen)
(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.
(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.
(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?
(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?
(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.
(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.
Jason, I could still reproduce the issue on Inari with the patch on bug 974253 backed out.
Flags: needinfo?(arthur.chen)
I also still reproduce on a Peak.
(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?
Flags: needinfo?(arthur.chen)
Duplicate of this bug: 990025
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
Flags: needinfo?(arthur.chen)
(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.
Duplicate of this bug: 990609
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
Depends on: 990383
Is this bug a dup to bug 990383 instead of a dependent? What do Settings needs to do more here?
Flags: needinfo?(arthur.chen)
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.
Flags: needinfo?(arthur.chen)
OK, please do so after bug 990383 lands.
Assignee: nobody → arthur.chen
Whiteboard: [xfail]
Duplicate of this bug: 990669
Marking qawanted to retest this in the 4/3 build if this still reproduces with the dependency fixed.
Keywords: qawanted
(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.
(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
Keywords: qawanted
Okay - marking fixed by the dependency.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S5 (11apr)
No longer blocks: 987145
You need to log in before you can comment on or make changes to this bug.