I updated my Flame from master based on gecko c9f8cc9ce89c to master based on gecko 37ac55a26014, and my data/cellular connection became very flaky. In particular: * I'd sometimes (maybe 20% of boots) see "Emergency calls only" for an extended period of time after boot * when I didn't, I'd see cell service, but no indicator of data connection for a long time * once the data connection was established, it was often E rather than H * once the data connection was established, it would sometimes later drop I'm currently bisecting to find the problematic changeset.

From bisecting gecko, I'm reasonably confident that this was regressed by https://hg.mozilla.org/mozilla-central/rev/b24e74058201 . (I have a build of 1015c2a66c50 that is clearly the working state, and a build of e231bba271cf that I'm reasonably confident was the bad state.)

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #1) > (I have a build of 1015c2a66c50 that is clearly the working state, Or maybe not so clearly. The first time I booted that build it was the fastest I'd seen a build get a data connection all day, but the second time it didn't work. The third time it worked again, though. (Maybe it's actually more likely to work indoors and plugged in to USB? That's the opposite of my previous experience, though.)

I did a few more tests of https://hg.mozilla.org/mozilla-central/rev/1015c2a66c50 and I'm pretty sure it's good. I'm now doing additional tests of https://hg.mozilla.org/mozilla-central/rev/37449b85186f and I'm thinking it's actually good as well. (It's possible T-Mobile in San Francisco is flaky in a way that led to consistent bisection results.)

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) (away/busy Aug 27-Sep 11) from comment #3) > I'm now doing additional tests of > https://hg.mozilla.org/mozilla-central/rev/37449b85186f and I'm thinking > it's actually good as well. Actually, now it's gone flaky, so it may well be bad.

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) (away/busy Aug 27-Sep 11) from comment #4) > (In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) > (away/busy Aug 27-Sep 11) from comment #3) > > I'm now doing additional tests of > > https://hg.mozilla.org/mozilla-central/rev/37449b85186f and I'm thinking > > it's actually good as well. > > Actually, now it's gone flaky, so it may well be bad. So I've managed to see the flaky behavior twice on that revision, and also once (getting EDGE when I should get HSDPA) with that revision but the nsNfc.js changes reverted.

Yes, I'm definitely seeing the flaky behavior with https://hg.mozilla.org/mozilla-central/rev/37449b85186f but with the nsNfc.js changes in https://hg.mozilla.org/mozilla-central/rev/b24e74058201 reverted.

[Blocking Requested - why for this release]: Regression that leads to unreliable data connection.

And now I'm seeing the flaky behavior on https://hg.mozilla.org/mozilla-central/rev/1015c2a66c50 as well.

Also, there is a frequent error in the logcat that might be related -- or might not: E/GeckoConsole( 289): [JavaScript Error: "TypeError: data.type is null" {file: "app://system.gaiamobile.org/js/statusbar.js" line: 730}] that's on the line: } else if (data && data.connected && data.type.startsWith('evdo')) {

I've proven my original regression window is wrong, but I don't know what the real one is.

Hsin-Yi - Do the logs here help with diagnosing what caused this problem?

Hi David: Could you please check your setting first? and Did you ever see 3G or H before flashing to problematic version? // Setting location Settings -> Cellular & Data -> SIM 1 -> Network operator What value Network type shows? Per two logs you provide, device stay in GSM (16) mode, or no service. We did not see device get other RATs (radio access technology) except GSM. I/Gecko ( 288): RIL Worker: [0] voice registration state: 1,0102,00005354,16,,,,0,,,,,,0, I/Gecko ( 288): RIL Worker: [0] voice registration state: 1,0102,00005354,16,,,,0,,,,,,0, I/Gecko ( 288): RIL Worker: [0] voice registration state: 1,0102,00005354,16,,,,0,,,,,,0, I/Gecko ( 288): RIL Worker: [0] voice registration state: 1,0102,00005354,16,,,,0,,,,,,0, I/Gecko ( 288): RIL Worker: [0] voice registration state: 1,0102,00005354,16,,,,0,,,,,,0, I/Gecko ( 288): RIL Worker: [0] voice registration state: 1,0102,00005354,16,,,,0,,,1,,,0, I/Gecko ( 288): RIL Worker: [0] voice registration state: 1,0102,00005354,16,,,,0,,,1,,,0,

Thanks for Shawn's comment :) Seems more information required based on his investigation.

Holding off the nomination until we have concrete information to investigate this bug.

(In reply to shawn ku [:sku] from comment #14) > Hi David: > Could you please check your setting first? and Did you ever see 3G or H > before flashing to problematic version? Is see H most of the time before flashing the problematic version, and I even still see H most of the time with it. > > // Setting location > Settings -> Cellular & Data -> SIM 1 -> Network operator > What value Network type shows? 3G preferred That said, the problem seems a lot better today. It's possible this was a problem with T-Mobile's network near the SF office (although that still doesn't explain why other people weren't seeing problems).

Hi David, Thanks for your reply. IMO, it would be better to have modem log, and have partner to check if it is really a network issue. However, I am not sure if our QA team can help with this. ni?tony to see if he can give a hand here. Thanks!! Shawn

i've never seen a 3G enabled connection in the US on this device. only HSPA+ qawanted team, can you see if this can be reproduced with logs. lets focus on 2.0 and 2.1 of flame, base v123. Thanks, Tony

David, I've also seen this kind of odd behaviour this morning up here near seattle while working on my Flame device. I was working on a different bug and noticed my sim wasn't being recognized for up to a minute after a reset or flash (can't remember which). Emergency calls only was seen on the lock screen. I've also seen E and H for data swap in the recent week for no apparent reason. Again always during work on other bugs so i just made a mental note. Anyway I'm working hard on this bug now and hopefully be able to come up with something solid soon.

Just wanted to provide an update. Since Comment 20, I've not seen this behaviour again. I've tried to repro with no luck.

based on comment 21 - closing as WFM, please re-open if you disagree