yashsingh1/xdaforums huggingface dataset:
[Galaxy S II General] BJNK:
Hey thanks for the post.. I was wondering if you could expand on the Exchange issue or point me in the right direction?

I use Touchdown Exchange and I receive about 150 emails a day to my phone, so I understand that it will be quite active, but occasionally (usually about 3 times a day) when looking at battery stats, something has kept the phone "awake" for extended periods.

I have had ~12 different Android phones, and this is the first one that seems to keep doing that. I am a little dissapointed with the battery life on the SGSII and maybe its something to do with what you mentioned?

Thanks
[Galaxy S II General] KennyLegend:
Check the betterbatterystats thread for ways to interpret Ur results better.

**Sent from my Galaxy SII using XDA app & Rom Kitchen Ki8 by Tricky103**
[Galaxy S II General] Entropy512:
Or pull the contents of /proc/wakelocks and post it here - If you have ADB working (Droid Explorer is apparently a good way for Windows users), the following should work:

adb shell cat /proc/wakelocks > wakelocks.txt

Then post wakelocks.txt here for analysis.

/proc/wakelocks is harder to interpret, but is more complete - BBS seems to miss some things

I wonder where in the path from .7 to .14 the AOS behavior changed... Knowing exactly when would help narrow it down. I should start doing a one-by-one revert of arighi's commits to find the answer. :)
[Galaxy S II General] Entropy512:
Aaaah. HERE we are. Good, actual, useful data to analyze of the issue caught in the act. Finally. I wonder if this is related to the bcm4330 "goes to sleep and never wakes up, needing a reset" issue.

More data: Router brand/model? Bands used? Security? Does this happen on any wifi APs or just yours?

It looks like your wifi chipset is firing off interrupts WAY more often than it should, and more often than it does in most circumstances. For a second I thought it was the rx_wake wakelock, but it's wifi_wake. Now to poke inside the bowels of the dhd driver.

I hate broadcom, by the way...

CONFIG_LOG_BUF_SHIFT

https://github.com/Entropy512/linux_kernel_sgh-i777/commit/524c86aeb3bd6528bce2c118a50b39b71b04e3c8

Oh, I forgot to mention - The kernel dmesg timestamp counter does not increment in deep sleep, so when you see a pattern like this:

[ 0.000000] WAKEUP_STAT: 0x80000001
[ 0.000000] WAKUP_INT0_PEND: 0x0
[ 0.000000] WAKUP_INT1_PEND: 0x0
[ 0.000000] WAKUP_INT2_PEND: 0x20
[ 0.000000] WAKUP_INT3_PEND: 0x0
[ 0.000000] s3c_pm_enter: post sleep, preparing to return
[ 0.000000] S3C PM Resume (post-restore)
[ 0.000000] Wakeup from sleep, 0x80000001
[ 0.000000] L310 cache controller enabled
[ 0.000000] l2x0: 16 ways, CACHE_ID 0x4100c4c5, AUX_CTRL 0x7e470001, Cache Size: 1048576 B

You don't know how much time actually passed in there.

As an example, after an overnight run, check your system uptime. Then compare it to the timestamps. If you reset your CPU timers right after boot, the timestamps should be pretty close to the amount of time you've been out of deep sleep.

Mildly annoying for the purposes of debugging...

Your device seems to resume a bit faster than mine - around 500 msec instead of 650.

For the first time, we actually have some data POINTING to the wifi drivers (or maybe the BCM4330 hates your router - it hates some routers). So at last now we know where to look!
[Galaxy S II General] AndreiLux:
D-Link DSL-G624T Firmware Version : V3.10B01T02.EU-A.20070924, simple WPA-PSK, G-band 2.4GHz.

If it's the router, which has been the only constant ever and remained unchanged in months, how am I able to make occational screenshots like this. It doesn't happen always, the drain varies. Just look at the screenshots on the first page. It's all the same circumstances.

I've had it happen on other routers, I've had it happen on the city-wide Wifi which uses heavy-duty Cisco hardware, I've had it happen on campus. The thing is, sometimes it doesn't even happen at home and also enjoying great deep sleep. Because I don't live on the streets or on campus I cannot guarantee it doesn't bug out there too.

I also just reminded myself that I've tested it by creating a hotspot on my laptop and tunneling the router internet connection through that. So it must be something packet-related and not transmission related, unless the Intel 5100 has the same problem as the router. But I'm more than convinced it's a driver issue on the phone because it's uncanny how similar the issue is to the Galaxy S.

I deducted that around 1 minute of CPU time in BBS is roughly 0.6-1% of battery, so even you in your testing out of 9 hours are losing a big chunk of power due to the processes, even if you're not reproducing what I'm and many many other people are experiencing. I don't know if other phones behave the same but from what I've researched, it's not the case!

Also, the problem is that suspend goes also high on 3G, but I'll have to retest that theory on Monday. I'm not very often on 3G since I've got Wifi coverage 90% of the time wherever I go. It's also hard to monitor because now I'm running .14 patched kernels on a daily basis...

Anyway, as you see, the drain is real and has a valid cause.
[Galaxy S II General] Entropy512:
You've finally found a contributor AND some useful test/debugging data at last which points somewhere to look, now it's time to figure out the variables. Good that you have a more reproducible test case...

hmm, would be interesting to see what happens if you run Wireshark on the same WLAN network on your laptop when it's "good" and when it's "bad"...

There's a limit to how many wakeups you can eliminate before you start sacrificing functionality (like Google Sync) - Who knows, I might be able to whittle some stuff down (seeing the sec_battery_monitor that high on the list is putting messing with the battery polling interval MUCH higher on the list - but merely changing it isn't safe because charge termination loops run at the polling interval.)

To nail this down, I think we're going to need one of the kernel devs for your devices - someone needs to crank up CONFIG_LOG_BUF_SHIFT for you and probably CONFIG_PM_DEBUG and CONFIG_PM_VERBOSE set. (Edit: Ok, probably not CONFIG_PM_VERBOSE - a little TOO chatty, and still no wallclock timestamps anywhere...)

In theory I might be able to build something, but I REALLY, REALLY hate building kernels for devices I don't own, even if they are ridiculously similar to mine.
[Galaxy S II General] AndreiLux:
I asked gokhanmoral in the Siyah thread to pump it up to 19. Also asked to make a custom build if possible. If not I can compile myself a modified kernel, but I prefer having the latest bells and whistles in the source, so maybe next week / I'll see later. Off to bed now. As far as I'm concerned whatever .14 did needs to be undone as it does absolutely nothing other than make monitoring of drain harder, so would be useful if you find that commit.
[Galaxy S II General] madmack:
just wanted to say that you both are giving us an awesome and very informative discussion.

thank you both. looks like we're onto something here :)
[Galaxy S II General] s2d4:
+1 to this, thank you guys both. Hope AndreiLux won't be so frustrated and I do genuinely think it's good that he has brought it up. However, it may be an impossible to tasks to educate people about it correctly considering the amount of "I have AOS bug" in the S2 forums..

I do prefer Entropy's methodology tho, it was just a pity that it took so long and so much profanity before he finally has some data to get his teeth into, and looking at the issue with expertise.
[Galaxy S II General] Entropy512:
God, getting proper real time printed in dmesg on ARM is proving to be a pain in the ass... But I think I've found a fugly hack that'll do the trick.
[Galaxy S II General] d3vilskid:
android os

just went on xda and saw this as one of the main topic. I remember this android os bug on the g1 and it was killing our batteries quick. the dev farmatito supposedly fixed t for the g1. here is a link to it maybe it can help.

http://xdaforums.com/showthread.php?t=1010932

PS:sorry didnt read through the post so not sure if its mentioned in here or not. well hope it helps.
[Galaxy S II General] Entropy512:
Ah, we've already got fixes for those USB battery drain bugs in at least some of our kernels (I know I do).

This is something else.

Time to run a test... Now I've got statistics for each time I enter deep sleep as to how long I was in it. :) Well, sort of - it's a ***** to read.
[Galaxy S II General] d3vilskid:
sry like i said i didnt read through it, but yea i guess it seems to be a different type of aos than.
[Galaxy S II General] m2smoe:
So in short, this appears to be a wifi problem?
[Galaxy S II General] Molitro:
It isn't exclusive to wifi, though it does get worse.
[Galaxy S II General] mariosraptor:
Min is sjowing 17% or less AOS. also wathdog is not seeing any apps missbehaving but in BBS suspend and events are full. What is going on? Even cpu spy shows deep sleep.
[Galaxy S II General] statusnone:
Either you do not have the AOS bug, and something else is causing the high AOS drain. Or (like many have stated in this thread) this particular charge around the bug wasn't as frequent or you has some other variable in there as well.

Side note: I'm sure there are many other people who are reading this thread who are FAR from as knowledgeable as the core contributors to helping this problem but aren't brain dead and can see the difference (from reading this thread, obviously) between the AOS bug and some other cause of drain.

Being one of these people myself, if there's any way, shape, or form that we can contribute to helping you guys then PLEASE let us know. More than happy to help solve this problem.
[Galaxy S II General] mariosraptor:
Ic i can help also just let me know.
[Galaxy S II General] Entropy512:
In Andrei's case, it's either a wifi problem with his device, or a device on his network is misbehaving.

For example, if something on his network is sending out broadcast packets at 1 Hz, this would wake up the device every second. Unfortunately, there's no way for the wifi chip itself to determine whether it needs to handle a broadcast packet or not - it has to pass it up to the host OS. A 1 Hz interrupt from the network card will be basically unnoticeable to a PC, but to a phone that is trying to stay in deep sleep, it'll kill the battery. Andrei, how familiar are you with Wireshark? It would be useful to know what traffic is going over your wifi network when the issue is happening. Unfortunately, I've never sniffed a WLAN before, so I don't know what "gotchas" there might be here, but I'll look into it. If you do know Wireshark, a capture would be useful - to filter out potentially personal info and reduce the capture file size, I suggest enabling the "Limit each packet to" option in Wireshark's capture options, and setting it to 68 bytes. For something like this only packet headers are needed.

Need more data to be sure whether it's the device or the network, but in Andrei's case it's clear that wifi is waking the device too much. The reasonably high "count" field in /proc/wakelocks doesn't worry me too much, but the "wake_count" of 56 after only 8 minutes is problematic. Also, in the dmesg it appears that the wifi chip is waking the host CPU with a GPIO interrupt (WAKEUP_INT2_PEND flags = 0x20) frequently.

Define "full"? What was the amount of time, and how long was the device on? Suspend and events/0 being at 1 minute after 10 hours isn't a problem - but if it's 20 minutes out of an hour or two, something is bad.

Power is dominated by display in your screenshots... No problems there.

All of your shots in your second post are tiny and unreadable. Plus if you're experiencing severe unexplainable drain, /proc/wakelocks and a dmesg are the most useful items.
[Galaxy S II General] AndreiLux:
Sure I know Wireshark. But then again I'm actually still using my PC and network :p I'll do a capture at night. But that might be all irrelevant after I show you the following;

I tried to search what svnet was but couldn't find something concrete, only thing consistent over the 3 modes. These are until now average-case scenarios, especially the Wifi where it gets much worse at times draining up to 3%/h. Skype and Trillian running in the background as only "connected" services, else the ROM is pretty much clean of anything requiring data, at least I think. I've done enough clean wipes to be sure of it though, and still reproduce it.

gokhanmoral also increased the dmesg log size to match yours and I flashed that somewhere inbetween testing.
[Galaxy S II General] statusnone:
For someone that's rarely on wifi the problem still exists but more so at home on my router.

For some reason xda won't let me post my watchdog usage. Suspend is at 85% and events at 75% in this photo set.
[Galaxy S II General] Entropy512:
It could easily be that there are multiple issues at play here - now that we're grabbing dmesgs and /proc/wakelocks, it's a LOT easier to tell what's what.

I did a run last night with a kernel that has a fugly hack to display suspend enter/exit times - see https://github.com/Entropy512/linux_kernel_sgh-i777/commits/wifi_test_hacks for more details

This was "normal operation" for me - my usual night drain test case of phone on the shelf, with Wifi Sleep Policy set to "never when plugged in".

Drain was unusually high last night, at a bit over 1%/hour. AOS was actually quite low at "only" 30% - as I've said before, so far in every test I've run with a .7 kernel, AOS has actually been an inverse indicator of battery life - when it's 60% it's great, when it's 30% like this, not so hot. Last night svnet-related wakelocks were the primary wakelock holders. Specifically svnet-dormancy - I'll have to look at that, see my previous posts regarding AT&T and Fast Dormancy, it may be that this is just drain from enabling FD on a network that doesn't support it. You'll notice that events/0 and suspend are only 1 minute each - MUCH lower than many of the wakelocks. Also the wakelock sleep_times add up to way more than the total time awake - wakelocks can overlap. It's interesting that svnet-dormancy has an "expire" for every single wakelocks - according to http://lwn.net/Articles/400771/ , this indicates some sort of bug. I need to read that article more though.

My initial interpretation was that svnet was radio-related - but looking through the kernel code more indicates this might actually be related to USB tethering. I'm going to try disabling those functions and testing tonight.

Unfortunately I need to do a kernel release that I promised some users would happen last night, and also run errands and do a motherboard swap, so I probably won't get too much on this done today.
[Galaxy S II General] AndreiLux:
What is beyond any logic for me is why there aren't any user processes being shown in /proc/wakelocks for me; I can see them in BBS (nothing too special in there btw) but they're not listed as they are for you in the dump.
[Galaxy S II General] Entropy512:
Hmm odd... I wonder if that's part of the .7 vs .14 difference (I've been running .7 for data collection purposes lately...)

Trying to yank out the USB SVNET driver is easier said than done - the main Samsung modem driver has dependencies on it. These dependencies should be represented in the Kconfig files but it's not in this case. Not sure if I can easily remove the dependencies.
[Galaxy S II General] AndreiLux:
They're not, I have the same thing on a stock kernel, as attached above in the Airplane-Wifi test1. Can't figure out why.
[Galaxy S II General] Entropy512:
Hmm... Odd... Could you attach the contents of /proc/config.gz (if gokhan included /proc/config.gz support, I hope he did) - I wonder if maybe you're missing some defconfig option.

Edit: Not possible to disable USB_CDC_SVNET without killing the whole radio interface. Dammit. :(
[Galaxy S II General] AndreiLux:
Here you go. Where does BBS get those stats from if not from /proc/wakelocks ?
[Galaxy S II General] Entropy512:
Good question... Kind of annoying, sometimes it shows stuff not in /proc/wakelocks, all the time it fails to show some of the stuff in /proc/wakelocks

Nothing obvious in your .config so far that I can find that would affect this that I can find yet... It's not something with the AT&T sources since Siyah is supposedly using those. gokhan might have broken something - megapatches like his are difficult to review.
[Galaxy S II General] emilcioran99:
Intratech's XXKI3 stock + CF-Root-SGS2_XX_OXA_KI3-v4.1-CWM4 + JKay's Blue circle.

In 3 hours, 40m and 57 s with wifi on and phone in sleep, looses only 1% of battery BUT still remaning the android os percentage (compsumption ?!) bigger then phone idlle or than cell standby.

What's happened here?
[Galaxy S II General] AndreiLux:
I'm still perplexed. Maybe you're the one different here :p I tried it on multiple kernels and even switched to MIUI for a bit. Pulling it from adb also doesn't do anything.
[Galaxy S II General] Molitro:
I seriously doubt that 1% is accurate. I mean... You don't even get that by wiping the phone and leaving it just with the gmail account and everything else off and clean. I actually tried it.
[Galaxy S II General] Entropy512:
Low drain combined with high Android OS is the nonsensical case that I have frequently. Grab a /proc/wakelocks please.

I did some more digging - it seems almost like our ratio network interface is a USB peripheral as far as the CPU goes. svnet is the interface to the radio.
[Galaxy S II General] aceofclubs:
All depends on battery size.

Im using OEM 2000mah extended battery and lost 3% overnight.
[Galaxy S II General] Entropy512:
Funny thing here:

/sys/devices/virtual/net/svnet0/statistics # cat rx_bytes
89379
/sys/devices/virtual/net/svnet0/statistics # cat rx_packets
917
/sys/devices/virtual/net/svnet0/statistics # cat tx_packets
1383
/sys/devices/virtual/net/svnet0/statistics # cat tx_bytes
12686587

12 megabytes in only 3 hours or so - but that sure didn't go out over the air. Either that or AT&T doesn't count outgoing data...

Edit: It's over 12MB even immediately after a reboot. I think that number includes bootloading the modem.

Ran a few interesting tests:

When in sleep, the Infuse does not respond to broadcast traffic. Neither does the GS2. Broadcast traffic does not appear to cause WLAN wakes on the Infuse, still need to test in GS2. (Edit, just tested - while the GS2 does not respond to broadcast pings when asleep, the wifi chip is reacting to it sufficiently to keep the device out of deep sleep with a 1 Hz ping.) Even after stopping the test deep sleep is still inhibited - maybe I screwed something up and caused another wakelock somewhere...

When in sleep, with Wifi Sleep Policy set to Never, the Infuse and GS2 respond to unicast pings. If these pings are at 2 Hz, deep sleep is less than 10% on the Infuse. On the GS2, it appears to fully inhibit deep sleep, and wlan_wake counts VERY fast.

Edit 2: OK, somehow I've managed to make StartingAlertService unhappy. It's now holding a permanent wakelock.

Edit 3: Gotta go to bed now, will take a look at your data tomorrow.
[Galaxy S II General] AndreiLux:
I have a few more tests but my brain is too tired to sort them out right now. I couldn't get to stop those **** UPnP packets, at least they didn't seem to affect it at all. Ah yea forgot to mention; this is on the laptop acting as a hotspot tunneling the actual router connection, so those are all the patckets on the network for that period.

192.168.253.101 is the phone.
[Galaxy S II General] emilcioran99:
That's what I think too.

It's imposible in this momment to have 1% / 3 hours drayn, even if the phone sleeps.

What means this? What's wrong in Android os to do this?

Don't know how to do this...

I'm a noob at this thing. :D

My battery is standard 1650Mah.
[Galaxy S II General] statusnone:
Most of today was off WiFi and very strong H+ signal. Checked for significant wakelocks and nothing out if the ordinary. Also a very low usage day and that's what disappoints me more than anything. And with samsung working with google for the new nexus and ICS I doubt a fix is coming until ICS.
[Galaxy S II General] Entropy512:
Sure it is, but your cell radio has to be off right now for that to happen. I've never seen a device with drain that low with the radio on. It also probably depends on how many apps you have with active data connections - the more data transferred in the background, the more that the svnet and svnet-dormancy wakelocks are going to fire.

The WiFi "bug" may be more of a network problem with some wifi networks. As demonstrated above, a unicast ping can completely inhibit deep sleep on this device, and there's no way to stop the wifi chip from firing an interrupt on a unicast packet without COMPLETELY breaking a lot of data connections. It doesn't respond to IPv4 broadcast when I'm in sleep, I'm not sure about multicast yet - I need to look in more detail at AndreiLux's Wireshark captures, but there's a broken machine on that network firing off WAY too many SSDP packets, one every few seconds. If the device reacts to those, it's not going to sleep.

What I mean is that it makes no sense that for some people (like myself), battery life IMPROVES as Android OS climbs upwards in 2.6.35.7 kernels.

Using ADB (Google it, and if you're a Windows user, Droid Explorer may help you), and run:

adb shell dmesg > dmesg.txt
adb shell cat /proc/wakelocks > wakelocks.txt

Or, with Android Terminal Emulator:
[code]
dmesg > /sdcard/dmesg.txt
cat /proc/wakelocks > /sdcard/wakelocks.txt

See the previous posts in this thread - BBS seems to miss a lot of wakelocks, grab a /proc/wakelocks. events/0 and suspend were a little higher than what I'm used to, but not THAT high for a 17 hour run. I usually see 1 minute per 10 hours.

Attached is more data, although not particularly interesting. One is from a grocery run yesterday, the other is of last night's idle drain. Went from 97% to 90% in a bit over 7 hours, AOS was at 30%. When AOS hits 60% on kernels like this my drain drops to less than 10% in 12.5 hours.
[Galaxy S II General] AndreiLux:
I found that the SSDP discovery service was running on both my laptop and on my desktop, even though it's marked as manual start, so some app must be starting it. I disabled the service and the packets are gone now. Need to kill of the LLMNR's now and I'll do several testings on a "virgin" network.

Edit; also found that one: http://ttcshelbyville.wordpress.com/2010/05/26/improve-vista-and-windows-7-networking/

Have you ever thought that *that* is something radio related where under good conditions your cell uses less power, but AOS is a constant but also therefor goes up in percentages. We're acting bit stupid with the percentages right now as we're a bit more scientific to the other regards of testing, so I suggest to you that you reproduce that case with a MIUI ROM as that shows the estimated mAh draw for every item in the Android Battery stats (And in my theory where those %'s are derived from in the first place, I sure hope it's not the other way around, but that's not logical), and see if it really is something as I say.
[Galaxy S II General] Entropy512:
Good point there, although I've never been able to figure out why the percentage is SO damn high. Drain should be MUCH more than it is if the percentages are even remotely correct.

I do get the impression that the percentages get scaled depending on whether an overclock kernel is installed, even if overclock is never used, simply having that max CPU freq at 1.6 throws things off. It would be interesting to dig through the source code of a CM7 battery stats app, partly to figure out WHAT items the Batt Stats app lumps into "Android OS".

I still want to try the Wilson amp trick at some point... Maybe later this week. :)