Unfortunately things are getting more interesting: now ASUI now shows 5% drain per hour also on my new device. But this time I remember ...

...the last things I did:

Upgarde kernel: I could not mount samba drives, because I could not load the cifs.ko module. Apparently it was not compiled for the right version of the Diablo Turbo kernel. So I flashed the latest zImage. This fixed the problem.

Set clock with ntp: My clock was late by several hours. I changed the configuration of openntp so it adjusts the clock by any amount at startup and restarted ntp. That set the time right. Then I don't recall precisely what happened and what I did. At some point the clock was two hours in the future. I restarted ntp again and it set the time right again.

The time leap

The last incident made the device believe that time was jumping backwards. The next morning

• my originally full battery was at 40%.
• ASUI reported 5% drain/hour and
• the graph of ASUI showed the time leap by a horizontal line going from right to left followed by a steep decline

I appears that the drain started right after the time leap. I recall I had similar incidents on my old device (time off by several hours). I also recall that at some point all my alarms were gone and I had to recreate them.

So the problem is clearly a software problem and it seems to be related to Diablo Turbo and time. Does this ring any bells?

Try disabling Alarm Dispatcher (alarmd) in ASUI's service manager and see if that fixes it. There might be an issue between alarmd and the improved timing in DT kernel.

I disabled alarmd on my old device running the #3 Diablo Turbo kernel, since my new device runs the #2 kernel and behaves well. It did not make any difference, battery still drains at 5%/hr.

I could live happily with the #2 kernel, except I cannot find a suitable cifs.ko module and hence cannot mount samba drives.

The cifs.ko provided with the turbo kernel produces an "unknown symbol" (add_preemt_count, sub_preemet_count) when insmoded. I recall it works with the latest (#3) turbo zImage, but I hesitate to flash it.

I can insmod the cifs.ko which comes with wizard mounter, but when I actually try to mount something I get a segfault and I can no longer rmmod the module. It appears to be in use, but without listing a using module.

BTW: what is observability.ko? When I insmod it, I get stipes all over the screen and then the device reboots.

Did you disable metalayer-crawler?

Is connectivity search interval set to never?

Are the WIFI, GPS and Bluetooth radios turned off? I think you mentioned that it drains in flight mode so this might not be the problem.


If those don't help, you should reflash and use the device for a day after each package you install. Some apps should be okay to install all at once, but stuff like asui and DT should be tested. And don't load any kernel modules until you've tested the packages.

I am not aware of anything I could turn off. Once the device gets into the 5%/hr drain state, nothing I disabled made much difference. Strange enough it happens when I boot from flash too and there is no ASUI installed. Since it happens with two different devices and with different batteries, it must be something which lives in the initfs.

Is that reasoning correct?

Other than that, I had done pretty much what you suggested. I reflashed my new device, installed bootmenu, DT (latest zImage) and copied the root fs from the internall mmc of my old device to the new device. Result: 5%/hr drain.

Then I did the same thing again, except my root fs was still intact so I did not have to copy it again. Also I did not install the latest zImage, but the DT .deb. Result: 0.5%/hr drain, but no way to mount samba shares, because cifs.ko fails.

I guess I will reflash my old device and install DT latest zImage. So everything will be absolutely vanilla and then proceed as you suggested.

Maybe it is the latest kernel or cifs module causing the drain. I am only running the #2 kernel from 13mar and don't use cifs. Could you use ssh or ftp instead of samba?

It can sometimes help to open a terminal and use the "top" command.
I've seen daemon processes burning up the CPU after WiFi has
gone up/down several times and (apparently) confused their idea
of the connection state.

Just look at the top running processes, and if on a nominally idle system you're seeing something running and using more then 5-10% of the CPU, it'll be eating up the battery to keep the CPU that busy.