Closed Bug 981326 Opened 11 years ago Closed 11 years ago

[tarako] High CPU usage from wifi while screen is turn off

Categories

(Firefox OS Graveyard :: Vendcom, defect, P2)

All
Gonk (Firefox OS)
defect

Tracking

(tracking-b2g:backlog, b2g-v1.3T affected)

RESOLVED WORKSFORME
1.4 S6 (25apr)
tracking-b2g backlog
Tracking Status
b2g-v1.3T --- affected

People

(Reporter: fabrice, Assigned: xinhe.yan)

References

Details

(Keywords: perf, Whiteboard: [c=power p= s= u=] [POVB])

STR; - configure wifi - check that no network activity is happening - turn off screen Expected result: No cpu usage from the wifi subsystem Observed result: 3-4% cpu is used: Every 1.0s: adb shell top Sat Mar 8 11:37:58 2014 User 0%, System 6%, IOW 0%, IRQ 0% User 1 + Nice 0 + Sys 19 + Idle 284 + IOW 0 + IRQ 0 + SIRQ 0 = 304 PID PR CPU% S #THR VSS RSS PCY UID Name 4548 0 3% S 1 0K 0K unk root irq/181-wlan0 93 0 1% S 8 9668K 404K fg radio /system/bin/rild_sp 4853 0 1% R 1 992K 404K fg root top 452 0 0% S 1 0K 0K fg root kworker/u:3 63 0 0% S 1 0K 0K fg root mmcqd/0/ 57 0 0% S 1 0K 0K fg root kworker/u:1 9 0 0% S 1 0K 0K fg root bdi-default/ 10 0 0% S 1 0K 0K fg root kblockd/ 12 0 0% S 1 0K 0K fg root cfg80211 13 0 0% S 1 0K 0K fg root pm_print
Xinhe will take it.
Assignee: nobody → xinhe.yan
When screen is turnned off, wifi will be turnned off automatically. https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/system/js/wifi.js#L218 But it may depend on the value of screenOffTimeout. I saw the value is set to zero in Tarako. It means that wifi doesn't turnned off automatically. https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/system/js/wifi.js#L16 The other reason I may think of is that wifi driver may not be unloaded when wifi is disabled. It can be controlled by "ro.moz.wifi.unloaddriver" http://dxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js?from=wifiworker.js%20&case=true#110
ro.moz.wifi.unloaddriver is set to 1 in device/sprd/sp6821a_gonk/base.mk We will unload wifi driver when wifi is disable. After turn off screen, wheat I see is User 30%, System 25%, IOW 0%, IRQ 2% User 16 + Nice 16 + Sys 27 + Idle 44 + IOW 0 + IRQ 0 + SIRQ 3 = 106 PID PR CPU% S #THR VSS RSS PCY UID Name 5 0 17% R 1 0K 0K fg root kworker/u:0 438 0 13% S 12 69344K 23664K fg app_438 /system/b2g/plugin-container 81 0 12% S 39 132768K 39620K fg root /system/b2g/b2g 57 0 5% S 1 0K 0K fg root kworker/u:1 734 0 4% R 1 1000K 412K fg root top 512 0 1% S 1 0K 0K unk root irq/181-wlan0 60 0 1% S 1 0K 0K fg root kworker/u:2 511 0 1% S 1 2508K 1280K fg wifi /system/bin/wpa_supplicant 175 0 0% S 5 4460K 192K fg root /sbin/adbd 319 0 0% S 5 5300K 360K fg root /system/bin/slog 12 0 0% S 1 0K 0K fg root cfg80211 13 0 0% S 1 0K 0K fg root pm_print 14 0 0% S 1 0K 0K fg root kswapd0 15 0 0% S 1 0K 0K fg root fsnotify_mark 16 0 0% S 1 0K 0K fg root crypto But 2 seconds later, the cpu usage turn back to normal like this: User 0%, System 4%, IOW 0%, IRQ 0% User 0 + Nice 0 + Sys 5 + Idle 99 + IOW 0 + IRQ 0 + SIRQ 0 = 104 PID PR CPU% S #THR VSS RSS PCY UID Name 734 0 3% R 1 1000K 412K fg root top 319 0 0% S 5 5300K 360K fg root /system/bin/slog 3 0 0% S 1 0K 0K fg root ksoftirqd/0 4 0 0% S 1 0K 0K fg root kworker/0:0 5 0 0% S 1 0K 0K fg root kworker/u:0 6 0 0% S 1 0K 0K fg root khelper 7 0 0% S 1 0K 0K fg root suspend 8 0 0% S 1 0K 0K fg root sync_supers 9 0 0% S 1 0K 0K fg root bdi-default 10 0 0% S 1 0K 0K fg root kblockd 11 0 0% S 1 0K 0K fg root kworker/0:1 12 0 0% S 1 0K 0K fg root cfg80211 13 0 0% S 1 0K 0K fg root pm_print 14 0 0% S 1 0K 0K fg root kswapd0 15 0 0% S 1 0K 0K fg root fsnotify_mark Hi Fabrice, how log will cup usage turn back to zero at your tarako?
Xinhe, the top from comment 0 was after more than 2 seconds of the screen being turned off. Maybe we run different firwmare versions. How can I check if mine matches yours?
Fabrice, I can reproduce this bug on Tarako latest version. After connect an ap, close screen. wlan irq will consume 3% cpu. I found this symptom on our 8825 chip(android). But on tarako android, wifi did not consume CPU resource. I already contact our wifi engineer to check if this is normal.
Hi Fabrice, I got feedback from our WiFi engineer. After connect ap, WiFi chip need communicate with Tarako use irq. This symptom is same as our android(8825). I think we can close this bug.
Ok, thanks for the explanation!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Will this be a hardware fix or driver fix?
Flags: needinfo?(xinhe.yan)
(In reply to Michael Wu [:mwu] from comment #8) > Will this be a hardware fix or driver fix? I think this may not be a bug. WiFi chip need communicate with Tarako use irq which make irq/181-wlan0 consume CPU MIPS. Without connect ap, irq number is 100-150 every second. Connect ap, irq number is 350-500. Wifi driver need handle these irq. I found this log after turn off screen(not connect ap) sta_sleep_disconnected: going to sleep and this log (connect ap) 03-12 01:43:21.348 <4>0[ 353.796068] trout_cfg80211_get_station rate = 0x81 I guess after connect ap, wifi can not sleep. There will be more irq from wifi chip need be handle.
Flags: needinfo?(xinhe.yan)
That sounds like way too many interrupts, even if we're not using wifi power saving mode.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to Michael Wu [:mwu] from comment #10) > That sounds like way too many interrupts, even if we're not using wifi power > saving mode. Trout is our first wifi chipset, so I'll ask our wifi owner to check this issue.
Wifi will receive manager pacakge like beacon after connect ap. Trout is very specical, the mac protocal stack running on AP, not CP. This also consume some CPU MIPS. As james said, trout is our first wifi chip. The perfomance and power is not good. Trout chip already released in public market. So this may be not a serious problem. Wifi guy will check irq. I will leave for a couple of days. I will update next week.
Whiteboard: [POVB]
triage: 1.3T+ as we want to track this even if this is POVB
blocking-b2g: --- → 1.3T+
Component: General → Wifi
What does 'POVB' mean?
Let our PM Tyler know this issue on my side.
(In reply to James Zhang from comment #15) > What does 'POVB' mean? Part Of Vendor Build: these are issues that Mozilla can't fix itself.
OK, it's our first connectivity chipset known issue.
Component: Wifi → Vendcom
Flags: needinfo?(styang)
Flags: needinfo?(styang)
(In reply to Michael Wu [:mwu] from comment #10) > That sounds like way too many interrupts, even if we're not using wifi power > saving mode. Without coonnect ap, irq is 100-150. After connect ap, irq is 400. I made a statistics using /proc/interrupts. mmc1 interrupt 232 every second. wlan0 interrupt 13.6 every second. That is why we saw so many interrupts. Wifi use mmc(sdio) interface to commounicate with AP. At least 2 interrupts for one data transmission. Our mmc engineer said this is correct.
Hi Michael,Do you have any other questions? If you accept our explain in comment 20, we want close this bug.
Flags: needinfo?(mwu)
It's our first connectivity known issue, I think we can only WONTFIX.
I think we should unblock at least, but I want to investigate this more closely at a later point.
blocking-b2g: 1.3T+ → 1.3T?
Flags: needinfo?(mwu)
blocking-b2g: 1.3T? → backlog
Jon, This bug should be on your list of tarako power consumption issues to investigate. FYI for everyone: Power Harness and Power Tool details are here on MDN: http://mzl.la/1erl33E
Flags: needinfo?(jhylands)
Priority: -- → P2
See Also: → 989595
Whiteboard: [POVB] → [c=power p= s= u=] [POVB]
See Also: → 994566
So I flashed my Tarako on Thursday evening of last week (3.5 days ago) with the latest 3.5T, and fully charged the battery. Its been sitting on my desk, powered up, with the screen off, wifi on, no sim cards, since then. This morning, it still has 72% battery. I really don't think this is an issue worth investigating.
Flags: needinfo?(jhylands)
Okay, I'm going to rephrase that. Running the battery harness on it, for the first 10 minutes after power-on (or turning wifi on), it definitely shows more and higher power spikes. Once it gets past those initial 10 minutes, the power consumption goes way down.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → 1.4 S6 (25apr)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.