815368 - Wifi connection randomly drops in otoro while device is unlocked and not idle (Can't finish "MW0: Every app is successfully launched into the foreground")

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::System, defect, P2)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Follow the STR in https://wiki.mozilla.org/B2G/Memory_acceptance_criteria#W0:_Every_app_is_successfully_launched_into_the_foreground_.5BBLOCKED.5D .  Basically, load a bunch of apps after unlocking the device.

The wifi connection randomly drops out while the screen is on and the device is not idle.  Wifi comes back on if I lock the device, wait for it to suspend, and then unlock it again.

These regressions are really hurting :(.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This seems to correlate with the "4 updates are available" notification from the gaia system tray.  After the notification, the wifi "quick setting" in the system tray is disabled.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Possible logcat

I reproduced something very much like this bug, except that my wifi came back up after dying. Looking at the logcat, it looks like we jump straight to the CONNECTED state, but then replay the state changes that we went through to get there. That's really weird, and I don't understand how that's possible. Finally, as a result of all of the state changes, we disconnect and then the supplicant crashes (?) I don't see any reason why, though.

Comment 3

[Etienne Segonzac (:etienne)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #1)
> This seems to correlate with the "4 updates are available" notification from
> the gaia system tray.  After the notification, the wifi "quick setting" in
> the system tray is disabled.

Gaia's UpdateManager does request/release a wake lock on wifi but only during the actual download of updates [1] so shouldn't have any influence here.

That said the notification is shown 30 seconds after gecko is done checking for updates [2] which may correspond to a wifi-related delay and cause the correlation.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/update_manager.js#L294
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/update_manager.js#L244-255

Comment 4

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Is this still a problem?

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I don't know, because the tests are so broken for other reasons that I can't complete them.

Comment 7

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

I cannot complete the test either, but wifi works all the way ... should we close as WFM?

Comment 8

[Vincent Chang[:vchang][changyihsin]]

I am trying to verify if this might related to the bug where supplicant.conf was messed up somehow. So I fix the wifi code to disable a network on shutdown wifi and save the configuration to wpa_supplicant.conf. But I don't see supplicant crashes on start up next time. 

If I click the wifi settings button quickly, I found the button was grayed out and couldn't be clicked anymore. The quick solution is adding 
gWifiCheckBox.disabled = true in gWifiCheckBox.onchange() in gaia/apps/settings/wifi.js.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Given comment 8, I'm going to hand this off to vchang.

Comment 10

[Vincent Chang[:vchang][changyihsin]]

Is it still a problem since bug 820702 is landed ?

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I don't reproduce this anymore, but we've changed the timing of update polling so I can't be sure this bug is actually fixed.  But I can't reproduce anymore.