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.

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

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

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

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.

Bug 984919 has been backed out.

Should be resolved per the backout in bug 984919.

(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.

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.

(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?

(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.

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?

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

(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.

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

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

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.

OK, please do so after bug 990383 lands.

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

(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

Okay - marking fixed by the dependency.