Closed Bug 766837 Opened 12 years ago Closed 12 years ago

[Otoro]: Wifi fails after toggling off->on

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
DeveloperPhone

People

(Reporter: vliu, Unassigned)

Details

Attachments

(1 file)

Tips to describe this issue. 1. Wifi can scan the device on the first run. 2. After toggle off -> on, the wifi fails to open RFKILL control device. I tried to enable DEBUG in /gecko/dom/wifi/WifiWorker.js. I found some logs when I toggle off in step 2. I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=-1 state=3 BSSID=00:00:00:00:00:00 I/Gecko ( 115): -*- WifiWorker component: State change: INACTIVE -> SCANNING I/wpa_supplicant( 227): wlan0: CTRL-EVENT-TERMINATING I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=-1 state=0 BSSID=00:00:00:00:00:00 I/Gecko ( 115): -*- WifiWorker component: State change: SCANNING -> DISCONNECTED I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 0 d8:c7:c8:eb:17:22 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 3 d8:c7:c8:eb:17:20 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 1 d8:c7:c8:eb:18:42 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 2 d8:c7:c8:eb:17:72 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 4 d8:c7:c8:eb:18:40 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 7 d8:c7:c8:eb:17:d2 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 5 d8:c7:c8:eb:16:c2 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 6 d8:c7:c8:eb:17:70 I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 8 d8:c7:c8:eb:15:f1 : I/Gecko ( 115): -*- WifiWorker component: Event coming in: CTRL-EVENT-TERMINATING I/Gecko ( 115): -*- WifiWorker component: State change: DISCONNECTED -> DISCONNECTED I/Gecko ( 115): -*- WifiWorker component: Supplicant died! Does it any wrong to off the wifi in the first run?
Target Milestone: --- → DeveloperPhone
Summary: Wifi fails to open RFKILL control device in the second run to enable. → [Otoro]: Wifi fails after toggling off->on
Attached patch Patch file to solve this issue. (deleted) — Splinter Review
I found two issues block wifi turning on. 1. When wifi kernel module prepared to load, DRIVER_PROP_NAME sets to "ok" before it physically load completed. The "ok" leads the wpa_supplicant start running. In this situation, wpa_supplicant can't find wlan0 to link the interface. Adding a delay to wait for driver completely to load. 2. In wifi_start_supplicant_common() function, the system returns fail because there is no wifi.wpa_supp_ready in property field. I modified the code as workaround to fix this issue. May I ask for mwu's suggestion?
Attachment #637799 - Flags: feedback?(mwu)
(In reply to vliu from comment #1) > Created attachment 637799 [details] [diff] [review] > Patch file to solve this issue. > > I found two issues block wifi turning on. > 1. When wifi kernel module prepared to load, DRIVER_PROP_NAME sets to "ok" > before it physically load completed. The "ok" leads the wpa_supplicant start > running. In this situation, wpa_supplicant can't find wlan0 to link the > interface. Adding a delay to wait for driver completely to load. > Blake, what do you think? > 2. In wifi_start_supplicant_common() function, the system returns fail > because there is no wifi.wpa_supp_ready in property field. > This is already fixed. Do a repo update and delete your out/target/product/otoro/obj/EXECUTABLES/wpa_* directories.
(In reply to Michael Wu [:mwu] from comment #2) > Blake, what do you think? This is basically what I found in bug 769227. I just pushed that to central. If people feel that it's a lot cleaner to do this in wifi.c, we can use this patch. I have a mild preference for doing it in gecko (if for no other reason than to avoid modifying wifi.c), though.
(In reply to Blake Kaplan (:mrbkap) from comment #3) > (In reply to Michael Wu [:mwu] from comment #2) > > Blake, what do you think? > > This is basically what I found in bug 769227. I just pushed that to central. > If people feel that it's a lot cleaner to do this in wifi.c, we can use this > patch. I have a mild preference for doing it in gecko (if for no other > reason than to avoid modifying wifi.c), though. I think putting modification in gecko is much better then in libhardwar_legacy because we won't extra fork for wifi.
Great, marking this as fixed then, as everything has landed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Attachment #637799 - Flags: feedback?(mwu)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: