Closed
Bug 774876
Opened 12 years ago
Closed 12 years ago
Toggling off and on the Wifi Checkbox will not scan wifi networks anymore
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-kilimanjaro:+, blocking-basecamp:+)
RESOLVED
FIXED
People
(Reporter: tchung, Assigned: mrbkap)
References
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
When disabling wifi checkbox from the settings page, and then re-enabling it again, it will stop scanning and retrieving networks. Cross filed from bug 772801, which is not a dupe.
Tested against the 7-17-2012 otoro daily build.
Commit #'s:
<project name="gaia" path="gaia" remote="b2g" revision="f671a9eec542a460a700a841d1cee72c053d9225"/>
<project name="mozilla-central" path="gecko" remote="b2g" revision="042312e73785327eb81b7d54346d98b018377060"/>
<project name="gonk-misc" path="gonk-misc" remote="b2g" revision="cc4675bcaf2ea282c8997785ab7ed006dff927d3"/>
<project name="rilproxy" path="rilproxy" remote="b2g" revision="32106d4ea635ebe17a1610b643b398db639b8b97"/>
REpro:
1) load settings > wifi
2) uncheck the wifi checkbox (assuming you had networks found before)
3) recheck the wifi checkbox
4) Verify no networks are ever scanned or found again.
Expected:
- toggling wifi off and on should re-scan wifi networks
Actual:
- toggling wifi off and on does not re-scan wifi networks
Comment 1•12 years ago
|
||
This is same as bug 774583. Per talk with Blake on IRC yesterday, he will look at this bug.
Updated•12 years ago
|
Assignee: nobody → mrbkap
Comment 2•12 years ago
|
||
Blake, I heard that you're working on this case. In order to prevent duplicated work, I just assigned this case to you. If you're not working on it right now, I am sorry and please remove your name on it. Thanks!
Assignee | ||
Comment 4•12 years ago
|
||
This is a little bizarre. The problem here appears to be a race condition in loading the wifi driver the second time we load it. I can't reproduce the race on the commandline (doing "insmod a; insmod b") but inserting a sleep statement into wifi_load_driver fixes this bug. The result of the race is that both drivers load successfully, however, loading ath6kl_sdio.ko doesn't bring up wlan0 like it does normally.
That being said, Android ICS on the Otoro works because turning off wifi doesn't remove wlan0 at all, so presumably the same race doesn't happen. I haven't been able to figure out why wlan0 doesn't disappear on Android, though. It looks like we call all of the same functions with different results.
Assignee | ||
Comment 5•12 years ago
|
||
I'll keep poking around for another solution, but this patch works.
Attachment #644122 -
Flags: review?(mwu)
Comment 6•12 years ago
|
||
There was a similar otorol-gb issue (bug 766837), which also related timing issue of wifi driver.
For platform dependent issue, IMHO, if there isn't a general way to fix it in gecko, it is cleaner to fixing it in gonk, even local fork needed.
Comment 7•12 years ago
|
||
Can we simply stop unloading the driver?
Comment 8•12 years ago
|
||
(In reply to Andreas Gal :gal from comment #7)
> Can we simply stop unloading the driver?
I had a hack which did exactly that and worked for me.
Assignee | ||
Comment 9•12 years ago
|
||
Yeah, I have a patch that mostly does that. I'll clean it up and attach it tomorrow.
Comment 10•12 years ago
|
||
FYI, I'm discussing this issue with our partner. This seems like a better option than a fork of something in gonk.
Comment 11•12 years ago
|
||
Yeah, no gonk forking please.
Updated•12 years ago
|
blocking-basecamp: ? → +
blocking-kilimanjaro: --- → +
Assignee | ||
Comment 12•12 years ago
|
||
Attachment #644122 -
Attachment is obsolete: true
Attachment #644122 -
Flags: review?(mwu)
Attachment #644564 -
Flags: review?(mwu)
Comment 13•12 years ago
|
||
Can we just stop unloading on all devices?
Comment 14•12 years ago
|
||
I am afraid we still have to unload it when the device enter suspend.
Comment 15•12 years ago
|
||
(In reply to vliu from comment #14)
> I am afraid we still have to unload it when the device enter suspend.
Why? This is a bug that needs to be fixed on the kernel side if that's the case.
Comment 16•12 years ago
|
||
Does android ever unload? If not neither should we.
Comment 17•12 years ago
|
||
(In reply to Michael Wu [:mwu] from comment #15)
> (In reply to vliu from comment #14)
> > I am afraid we still have to unload it when the device enter suspend.
>
> Why? This is a bug that needs to be fixed on the kernel side if that's the
> case.
Yes, you are right. Thanks for your correction.
(In reply to Andreas Gal :gal from comment #16)
> Does android ever unload? If not neither should we.
I downloaded Android-ICS on otoro to try. When I tried to toggling on/off wifi, I found wifi kernel module never been unloaded by lsmod checking.
Assignee | ||
Comment 18•12 years ago
|
||
(In reply to vliu from comment #17)
> I downloaded Android-ICS on otoro to try. When I tried to toggling on/off
> wifi, I found wifi kernel module never been unloaded by lsmod checking.
I also found the same thing, but I don't understand it. The code in WifiStateMachine.java tries to unload the driver (see WifiStateMachine.setWifiEnabled) immediately after it shuts down the supplicant. If I remember correctly, the logs also show us entering wifi_unload_driver. What gives?
Comment 19•12 years ago
|
||
Lets land the patch for now as we figure this out. Its an improvement for sure. Should we file a follow-up for the rest?
Updated•12 years ago
|
Attachment #644564 -
Flags: review?(mwu) → review+
Comment 20•12 years ago
|
||
(In reply to Blake Kaplan (:mrbkap) from comment #18)
> I also found the same thing, but I don't understand it. The code in
> WifiStateMachine.java tries to unload the driver (see
> WifiStateMachine.setWifiEnabled) immediately after it shuts down the
> supplicant. If I remember correctly, the logs also show us entering
> wifi_unload_driver. What gives?
Could be Android-ICS of otoro doesn't really unload driver in wifi_unload_driver()?
Comment 21•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 22•12 years ago
|
||
Comment on attachment 644564 [details] [diff] [review]
Ick
Review of attachment 644564 [details] [diff] [review]:
-----------------------------------------------------------------
::: dom/wifi/WifiWorker.js
@@ +140,5 @@
> }
>
> function unloadDriver(callback) {
> + // Otoro ICS can't unload and then load the driver, so never unload it.
> + if (device === "otoro") {
This expression gets a raspberry from me. I've captured the need to undo this in https://bugzilla.mozilla.org/show_bug.cgi?id=776311
Comment 23•12 years ago
|
||
Yeah, we should definitely not have this in final. I just need wifi fixed right now. We can iterate.
Assignee | ||
Comment 24•12 years ago
|
||
(In reply to Shian-Yow Wu from comment #20)
> Could be Android-ICS of otoro doesn't really unload driver in
> wifi_unload_driver()?
That's possible.
I just noticed that on Android, the driver is unloaded, but wlan0 sticks around in 'netcfg'. I wonder if that might just be a bug in the kernel, though.
You need to log in
before you can comment on or make changes to this bug.
Description
•