Related
guys, I found out that the G-sensor daemon "akmd" alwasy takes up to 3% cpu on my N1 with CM-5.0.5/6.
I compared with stock ERE-27 rom, in which "akmd" in that takes less than 1%.
While during standby, it take no CPU usage.
Does it matter? I mean, would that kill our battery?
Actually I first found that out when I was using CM-5.0.5. One day I put my fully charged N1 beside my pillow and after 7-hr sleep, only 86% power left..
Maybe it has something to do with the 360 degree launcher2.
I personally don't use that feature. I'm gonna take a look at my usage.
I just noticed this as well while tinkering.
Gimpeh said:
I just noticed this as well while tinkering.
Click to expand...
Click to collapse
I realize I'm bumping an older thread now but I still feel this might be relevant.
Running top at any point will still show "/system/bin/akmd" which is the system daemon for the compass.
In my case, it almost always resides underneath "system_server". I've tweeted it at Cyanogen once but got no response to my question.
So, after doing some digging, I pulled down the SDK and fired up the "Dalvik Debug Monitor" here's what I saw (See attached: android-troubleshooting2.jpg)
Edit: i42.tinypic.com/m953rq.jpg
Not that it needed reiterating but the AK8973 is the 3-axis compass chip and something calling it or (the driver itself) is throwing an error almost precisely every 10 seconds. Now, I belive this has only been happening since the upgrade to CM5.0.6-N1 (Although I am now on CM5.0.7-Test1) either way whatever bug there is, still remains.
Edit: i40.tinypic.com/21liauh.jpg
Googling for that error: "Compass driver encountered fatal error2" pulls up a single page in the CyanogenMod Forums and two error logs on PasteBin.
Bump!!-Bumb!!
Thanks for the bump! Being a lurker has it's definite disadvantages.
prophetjinn said:
Maybe it has something to do with the 360 degree launcher2.
I personally don't use that feature. I'm gonna take a look at my usage.
Click to expand...
Click to collapse
In my testing, the use of 360ยบ rotation nor the setting of "Launcher Rotation" changed whether akmd was consuming resources.
Full size image link: i40.tinypic.com/dxh0yu.jpg
Just as GaryD had posted here:
forum.cyanogenmod.com/index.php?/topic/3129-ak8973-compass-driver-encountered-fatal-error2
after a reboot the errors disappear for a while. I don't know the pattern to which they reappear (e.g. due to a buffer overflow or some other reason.)
confirmed...
I think this issue is with newer kernels. I saw it on various versions of CM before switching to enom's TheOfficial rom. Doesn't exist on unmodified versions of enom's rom, but I just loaded several of the newer 2.6.33.x kernels and all show akmd using 1% cpu while the phone is sleeping.
Additionally, power drain while sleeping with these kernels is between 5 and 7 milliamps, while with the stock rom (and enom's stock kernel) it is between 3 and 5 milliamps.
If anyone wonders how I am getting these numbers, I am using OSMonitor (from the market). I sort the processes, reversed, by CPU%. To get the power drain, I look at the dmesg log and filter for the "batt" tag.
I may post this as a new topic for the kernel devs to review if it gets no attention here...
bubbahump said:
I think this issue is with newer kernels. I saw it on various versions of CM before switching to enom's TheOfficial rom. Doesn't exist on unmodified versions of enom's rom, but I just loaded several of the newer 2.5.33.x kernels and all show akmd using 1% cpu while the phone is sleeping.
Additionally, power drain while sleeping with these kernels is between 5 and 7 milliamps, while with the stock rom (and enom's stock kernel) it is between 3 and 5 milliamps.
If anyone wonders how I am getting these numbers, I am using OSMonitor (from the market). I sort the processes, reversed, by CPU%. To get the power drain, I look at the dmesg log and filter for the "batt" tag.
I may post this as a new topic for the kernel devs to review if it gets no attention here...
Click to expand...
Click to collapse
Since I haven't run any other roms I was hesitant to drag anyone else's ROMs into the discussion. I've seen it with InsectrRaven and the Pershoot but they're obviously all pulling from CM's commits on Github. I realize they're not large amounts of cycles but any usage that can be minimized is something. Right? Maybe I'm just a minimalist at heart.
Much appreciated on the bump and the bump towards the devs.
Another confirm here.
I'm on CM5.0.7-test2 with pershoot 2.6.33.4 kernel. Mine was steady at 6% CPU though.
Confirmed..
E/AK8973 ( 101): Compass driver encountered fatal error2 is thrown in every 10 seconds.
CM-5.0.7.1-N1
Kernel 2.6.33.4-cyanogenmod
this TOTALLY makes sense to me. used the stock ROM for last 3 months and had great battery life. after using cyanogen 5.0.7 the last 4 days, battery life is much worse than the stock ROM for me. also different is in cyanogen this "akmd" always shows up in my battery usage, but this never appears in the stock ROM. i'd make a solid bet that this is a cause of the poor battery life on current cyanogenmod, especially if this thing is hitting every 10 seconds with some fatal error. wonder if it can be easily fixed?
I have an EVO, unrooted, no OTA update, fully stock but used the 'top' app to notice the compass /system/bin/akmd consistently using resources.
Disabling auto orientation has fixed it, and done miraculous things for my battery life (battery graphs can have flat lines!), but I want my auto-rotate back. Is this a case of the accelerometer writing out a bad settings file, or it's a bug or what?
I'm still seeing this issue in the latest cyan r c 2 nightly. I'm confused why the compass would be used for the screen orientation. As far as I know, we are talking about 2 different sensors. The phone has a compass sensor, which is akmd, and also has an accelerometer sensor, which is used for auto screen rotation. The compass I thought is only used in things like maps street view and Google sky map.
Regardless, is there any solution to get akmd to stop running all the time? What process is calling this to even run all the time exactly?
I have the exact same problem (though akmd often takes up 80% here) on Hero with CM6 nightly build Aug 19th. I hope I can simply delete the file somehow.
dvfk said:
I have the exact same problem (though akmd often takes up 80% here) on Hero with CM6 nightly build Aug 19th. I hope I can simply delete the file somehow.
Click to expand...
Click to collapse
was same for me.. i had disabled auto-rotating in "settings->display" and in cyganamod settings.. AND in launcher pro.. (i always lay down on the side and the phone flips and i dont like it).. i did this 2 days ago.. and phone been laggy as **** since then. akmd have had 70-99% cpu all the time.. so i turned it all back on again. and now akmd takes 1% wake and 0% sleeping.. so wierdo.. shud be the other way around!
any updates on this?
having the issue as well, can't get rid of it.
please someone let me know.
Hi all
On my european Samsung Galaxy I9000 (Switzerland, unbranded) running PDA:XFJP7/PHONE:XXJPP/CSC:XXJP7 after a random length of usage the system suddenly is extremely slow (any kind of input takes ~5 seconds until response) or even becomes completely unresponsive.
It also happens with USB connected, so I could check via ADB shell with top who's fault it is. The kernel process "dhd_dpc" is blocking the CPU. It seems wifi related (which I have activated). Checking in with dmesg there's a nonstop spam of "dhdsdio_htclk: HT Avail request error: -35".
It happened on all kinds of Froyo releases. I tried pretty much all official and leaked firmwares, as well as various ROMs and other customizations. It doesn't require an actual usage of wifi. Often it happens when I try to get the phone out of standby and then I just can't unlock it anymore because it doesn't take inputs anymore.
I now downgraded to an Eclair version (PDA:XWJM8/PHONE:XXJM4/CSC:XXJM1) and with it the problem is kinda the same but not exactly. On Eclair the process ksoftirqd/0 jumps to insanely high CPU usage but the system is a bit more responsive than the Froyo issue. There are two messages that appear over and over in dmesg "BUG eth0 code -19 qlen 5" and "dhd_start_xmit: xmit rejected due to dhd bus down status". On Eclair I also am able to "fix" the issue by turning WiFi off and on a few times. I was unable to do that on Froyo.
So I guess my question is... Is my phone broken? There's times when it works for a few hours no problem... Sometimes it just takes 20 minutes.
Thanks for reading and for any input. I'm kinda lost...
Psyraven
Would any dev or anyone who knows a bit about compiling be able to do this? I've tried some other kernels, and generally love some of the features and performance they bring, but none of them has been 100% stable for me. Stock kernel is 100% stable, but lacks the 5 point multitouch which I do use for emulators, and GPU+ which makes a noticeable difference in 3D graphics smoothness.
The closest I found was HeyItsLou's #8 (I might have the number wrong) which runs great, has the multitouch, but no GPU+ Lou's has some other good features that seem to help smoothness and battery life too.
Maybe Lou or someone could throw GPU+ into that kernel? Or just take the stock kernel and add GPU+ and multitouch? Would anyone else be interested in this?
Um what about the. 32 incredikernel?
Sent from my ADR6300 using XDA Premium App
That's what I'm running now but it will randomly peg the CPU (system panel shows Android System as maxed out) and slow the phone to a crawl, requiring a reboot. And no, I'm not running SetCPU. That is the ONLY problem I have with that kernel, but I've never had that happen on the stock kernel. I don't want to deal with the random lockups anymore.
Ziggy's kernel doesn't have the lock ups, but doesn't run as smooth either, and I notice a lot of stutters while gaming.
I don't know why that would be. I compiled it for someone a few days ago and he loves how it runs.
Sent from my ADR6300 using XDA Premium App
what is 5pt multi touch?????
jdog94 said:
what is 5pt multi touch?????
Click to expand...
Click to collapse
Just that, you are able to use five fingers (or "points") simultaneously.
From my understanding, multitouch is affected by the touch panel you have, and also the way it is flashed. There was a compatible recovery floating around a while ago, but it's no longer maintained.
Yeah not all phones support 5pt
Sent from my ADR6300 using XDA Premium App
Phydo - I've actually been running your undervolted version of Chad's kernel for the last few days. I'm still having the same issue. In Chad's thread, there were actually a few people having the exact same issue. It was thought that SetCPU was somehow to blame, but again, I don't even have that installed.
From a performance standpoint, Chad's kernel is the one I've had the best results with and keep going back to, but this issue with the CPU getting stuck at 100% load happens regularly, every 24-48 hours.
bast525 said:
Phydo - I've actually been running your undervolted version of Chad's kernel for the last few days. I'm still having the same issue. In Chad's thread, there were actually a few people having the exact same issue. It was thought that SetCPU was somehow to blame, but again, I don't even have that installed.
From a performance standpoint, Chad's kernel is the one I've had the best results with and keep going back to, but this issue with the CPU getting stuck at 100% load happens regularly, every 24-48 hours.
Click to expand...
Click to collapse
I'd be willing to bet your problem is the ProcessStats.java bug documented in Issue 9733. It is exacerbated by kernels that add extra frequencies. Some ROMs work around the issue by making the time_in_state file unreadable, but SetCPU undoes this workaround every time you open it. 24-48 hours seems about right for the time it was taking for me to run into this problem. I'm now running with an init.d script that redoes the chmod 600 every 5 minutes just in case I open SetCPU and the problem has gone away.
Aweaver33 - would this be something I could easily incorporate into my own ROM? I'm running a mostly stock ROM that I customized by adding an earlier Evo framework and taking out some stuff I didnt want. Would I be able to flash your init.d script? Or since I don't run setcpu, could you explain or point me somewhere I could figure out how to make time_in_state unreadable?
EDIT: nevermind.... aweaver you are awesome for posting that link. I will try to chmod the time_in_state file as outline in that thread and see if I can make it 48 hours without it making the cpu.
Do you know how specifically this is kernel related? I've had this issue with Chad's kernel, and the old KingKlick kernels. I have NOT had the issue on the very old Hydra kernel or any of the stock kernels. I guess its just the number of frequencies they enable? Man if chmod'ing that file is all it took to fix that bug.... you are my friggin hero dude. I've been mostly using Chad's kernel since December and love it but MAN I hated the phone locking up every two days!
bast525 said:
Do you know how specifically this is kernel related? I've had this issue with Chad's kernel, and the old KingKlick kernels. I have NOT had the issue on the very old Hydra kernel or any of the stock kernels. I guess its just the number of frequencies they enable?
Click to expand...
Click to collapse
Yeah, it's mostly just the number of frequencies they enable. Also a potential, but smaller, contributor would be governor settings that result in a more even distribution of frequencies, which would result the overall file size getting larger more quickly. I first noticed this issue when I was doing stability testing that intentially created an even distribution of frequencies and made it less than a day before triggering the bug.
Well, I'm at 36 hours of running now, so far no issues. I did open the time in state file and noted it is still updating, though the permissions were correctly changed.
My only problem now is the leaked GB roms that popped up today... I want to flash one but I REALLY want to see if after six months of dealing with this very annoying bug, if it is finally fixed. I gonna TRY to resist flashing til tomorrow.
Any way to make the change in permissions to the time in state file stick? It undoes the changes on reboot
bast525 said:
Any way to make the change in permissions to the time in state file stick? It undoes the changes on reboot
Click to expand...
Click to collapse
That's where the init.d script comes in. Put the following in a file in /etc/init.d/ and set permissions to 755:
Code:
#!/system/bin/sh
while [ 1 ]; do
chmod 400 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
sleep 300
done
If there is no /etc/init.d folder, and I create and throw that file in there will it work?
EDIT: nevermind... tried it, didn't work. Created the folder, put the file I'm there, rebooted. Let phone sit five mins, looked at permissions for time in state file, they were still at default. Does it need to have an extension? I just named it "fix".
Sorry, it looks like the /etc/init.d/ directory is not standard Android. The following is the last line in my /bootcomplete.inc.rc file, which looks like what enables running the scripts in the /etc/init.d directory:
Code:
/system/xbin/busybox run-parts /system/etc/init.d
I'm not sure if that line was automatically added when I installed busybox, or if something else put it there.
It's cool, I found an alternate method. There's a very small app in the market simply called "Autostart", to use it you create a script, name it autostart.sh, drop it in a folder you create in /data/, and it runs at boot same as if it were in init.d. I took your script and modified it a bit to make it not repeat every 300 seconds. I don't run SetCPU so I only need it to run once at start up.
I still haven't let the phone run for 48 hours straight to verify this fixed it, but still man thank you for the info, it is greatly appreciated. After reading that Google bug thread you linked, I have very high hopes that this is the fix I've been looking for for six months now.
Thanks again man and I'll report in a day or two as I have no more reasons to reboot for a while.
48 hour mark just passed and still running like a champ
I saw a thread saying about DSI/MMC kernel fix, but i don't know what it means...
This may be a noob question, but i really dont know
The DSI fix adresses a bug in Motorola's 2.2 Kernel which can make the phone freeze and reboot spontaneously.
If the fix is applied, those problems are gone - but when you scroll through a list or something at fast speed some tearing might occur (similar to disabled v-sync in PC games)
So it's a tradeoff giving you a more stable system whilst sacrificing image quality.
At least that's how I understood it
The display hardware on the Milestone (OMAP really) sometimes hangs. After a short time a "watchdog" timer causes the phone to reset. For a while in CM7 (CM6?) there has been a "DSI kernel bug workaround". It causes a slight slow down and tearing, as Eiertshik mentioned, but at least your phone doesn't mysteriously hang and then reboot.
This DSI fix is a kernel module that has been available since CM7.1.0-RC10 (June 14). It notices when the display hardware has locked up and issues some sort of reset to it. So you can turn off the other workaround and get nice fast, smooth scrolling whilst also being stable.
And for some reason, kabaldan has recently combined a separate MMC fix into the same module. So it's now a DSI/MMC fix module.
Thanks for the answer, I understood now.
While being an experienced linux user, I still consider myself android noob, so I hope I can get some info about the problem here (yes, and you said to be nice while I was registering, so please let me solve it myself, it may be a new challenge )
System:SGS I9000 8GB, not overclocked (tried 1200 for some time)
OS: Gingerbread 2.3.5 XXJVT
Kernel: Semaphore 2.1.1 JVZ
Battery: huge fat 3000mah buddy, to be replaced by 3500 ones and a desk charger
System uses semaphore script manager to manager init.d directory
System is rooted(3.0.3) and uses voodoo control(2.1.1) to manage sound possibilities
Problem:
After applying a list of mods I found here (originally, I used froyo ...), I thought everything was fine, but I noticed 2 problems:
1. the system is unstable: when I do not use the phone, it often completely turns off, without me noticing it. This weekend however, I noticed this does not happen when connected to USB. I consider the voltage description for my cpu a bit too low at the lowest frequencies, or the battery has had its time and needs replacement (when performing on USB power, the SGS always is at highest frequencies, and on battery, the ondemand governor does its work and slows down the CPU).
2.When dialing a number from the dialer, or getting dialed, everything works fine. However, when I take a number from my message history and try to dial it, the microphone does not work. it does not matter if the phone is in my contact list or not. The person at the other side only hears some cracking noise and that's it.
So, my question is about part 2: where can I find any information about the android audio subsystem? by using my linux experience, I can already make the following statements:
- The audio system works with the dialer (phone and microphone work)
- The audio system works partly while the message program passes its information to the dialer (phone works), but the system fails to pass the microphone information to the dialer.
- The message program may have some kind of 'lock' on the subsystem (it must be able to send MMS messages with voice), but 'forgets' to release it when starting the dialer.
but this is just guessing info, I'd like to have a more clear vision on the situation.
So, where can I find documentation related to the problem?
all ideas are welcome, this is not urgent