[Galaxy S II General] Entropy512:
Sounds like what I call "weak-signal gmail sync battery rape" - On the Infuse, in some cases, if gmail couldn't sync properly it would go NUTS on the battery. Using codeworkx's cpuidle fix backport from .14 would help that a lot, and it also seemed to be ROM-dependent. Stock ROMs on the Infuse were OK, some "hellraised" I9000 ROMs were really bad, Serendipity VII was in between.

Yup. Also, our power_profile.xml may be broken, causing some things to report disproportionately.

In our power_profile, our CPU is listed as consuming 577 (mA I assume) at full tilt.

The Tegra2 in the Tab 10.1 is listed as consuming 255 at full tilt (however, it's near constant across the board - only dropping to 230 or so at minimum clock?)

Is our device's drain at full tilt REALLY twice that of the Tegra2 in the Tab 10.1 (and also at least 50% higher when both are running at 1 GHz), or is there a mistake in power_profile.xml? There isn't clear documentation on whether Android considers full tilt on 2 cores to be 100% or 200% in the power estimation code. Linux boxes are pretty inconsistent here, so how top calculates percentage may not match how the power estimator does. If power_profile is supposed to be per-core and Samsung accidentally put in the full dual-core current consumption numbers, everything is going to report double.

power_profile is clearly not set up to handle core hotplugging either - In the case of the Tegra2 this doesn't really matter since it does not appear to shut off the second core when not needed, but in our case, our device does.

I'm curious to pull the power_profile from an Atrix or Xoom - same CPU as the 10.1, but profile generated by a different company.

One thing is - if you're running one of the SiyahKernel releases that supports a 100 MHz clock rate, it may be misreporting CPU power consumption significantly higher than reality (not counting any of the potential issues discussed previously even) because power_profile.xml isn't aware of the 100 MHz step and has no current statistics for it - so will assume consumption identical to that of the 200 MHz step, even, for example, if your CPU is sitting idle at 100 waiting for an svnet-dormancy wakelock to expire.

Well, the 48k wakelocks aren't really the big issue here... The total time is very low (they were likely very fine-grained wakelocks to avoid a race condition), and the total sleep time was even lower - basically insignificant.

However, that long 107 minute fuel_alerted wakelock IS a problem. Going to see if I can track that down tonight in the kernel sources...

One thing I have figured out so far (will post some data on this tonight):

I think our wifi chip's standby drain is VERY low. So leaving it set to "never sleep" will not likely hurt battery life much, and if your phone spends a lot of time in range of wifi, could help significantly.

For general reference, in terms of /proc/wakelocks:

svnet-dormancy appears to be cellular data. You pay a minimum 6 second penalty of sleep time for every time the device wakes for a packet. This timer can be changed in sysfs, but reducing it could severely break something

svnet appears to be normal radio management (handling signal strength updates, etc.)

wlan_rx is wifi data (I think, need to recheck tonight, might just be wlan_wake) - You pay a MUCH lower penalty for periodic small transfers than with svnet-dormancy

sec-battery-monitor is your battery polling. This one is strange, changing the polling interval in the kernel doesn't change this one's usage significantly, and I've seen my device sleep