Related
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Patches got merged to CM7
Will be included from nightly 27 onwards. Thread is about to be closed. Use nightly thread for further discussion if any.
Achievment earned: RIVER RUNS RED (write in red on first post of a thread with at least 50 pages)
Build #9 contains Kali's latest kernel plus the 2 patches from hrkfdn about the aic3254 dsp chip. no other tweaks involvled, since i like kali's fast and simple work.
get build #9 here - md5: cc9372655750994cddfd12460dcdcb8b
http://postkreative.eu/mad/mad-batfix-B9-signed.zip
http://uberfail.org/mad/mad-batfix-B9-signed.zip
mirrors by phunkycow - thanks a bunch!
just flash this .zip file from recovery. reflash it each time you installed a new nightly build. #6 and newer contains a cleanup-function to remove older deprecated files from system. reported to work with cm6
no workaround needed anymore with #9
Now that we seem to have reached the final version - thanks to you all and your feedback - without it, it would have been much harder to trace down all issues.
FAQ
Q: Where has the CHANGELOG gone?
A: Move to the top of 2nd post - just scroll down a bit.
Q: Do i need anthing else but the latest patch?
A: No. Except for a cm7 RC or nightly rom installed.
Q: Why do i need to reflash after a new nightly?
A: Because we cannot backup the boot image. So once you flash a nightly/RC, you also get its kernel.
Q: Whats this FM-Radio thing i read about?
A: One discussed way to solve the battery drain in cm7 nigthlies and future RC's would be to use hrkfdn's patches and disable all fm-radio support (not only the apk file, but also the libs and framework). This patch is bypassing disabling FM-Radio and still doing its job. Result of quiet some work.
Q: Will this patch work with other roms?
A: Sense based roms dont need it at all. Non sense roms could use the patch on their kernel, but its not sure if this kernel runs with other roms. You can either try it, or ask in your kernel thread to include the patches. But, this is not final/stable yet. Guranteed to work with CM7, reported to work with CM6.
Q: When will this be in CM7 nightlies?
A: When all issues are solved. It seems thats the case with #8 - so expect nightly integration soon.
Known Issues in #9
None yet.
Monitor Status of DSP Chip
get gscript light free from market
start it, menu -> add script
use "dmesg aic" as title
leave "Needs SU?" checked
write "dmesg | grep -i aic | grep -v suspend | grep -v resume | tail -n 25" into the lower command box and save
back in adw: menu -> add -> shortcuts -> GScript Lite -> dmesg aic
This results in one-click-to-check-homescreen-shortcut
Sample dmesg output
Code:
<6>[ 106.647766] aic3254_ioctl: index 13 for 40047313
<6>[ 106.647949] aic3254_set_config: table(0x40047313) index(13)
<6>[ 106.648071] aic3254_set_config: enable rx
<6>[ 106.648498] aic3254_config: size = 15
<6>[ 106.649475] aic3254_config: size = 11
<6>[ 122.602355] aic3254_ioctl: index 29 for 40047313
<6>[ 122.602508] aic3254_set_config: table(0x40047313) index(29)
<6>[ 122.602722] aic3254_config: size = 8
<6>[ 122.603973] aic3254_set_config: disable rx
<6>[ 122.604095] aic3254_powerdown: power off AIC3254
<6>[ 122.604217] aic3254_config: size = 32
at first, the dsp is enabled (enable rx) when i started a mp3 - then the dsp chip is powered off again when i stopped the playback. this power off should occur each time, you stop using sound playback or microphone.
requested feedback:
are there situations, when power off does not work? when you for example have to invoke the old "voice dial" workaround to make poweroff appear again?
Closing comments
build #9 should be the final version. if no more issues arise in the next 48 hours, i will integrate it into cm7 nightlies.
in case you wanna use #5 again, i made a copy of the old opening post below this post, including downloads and instructions.
happy battery life
mad
changelog
#9: remove AicBootFix.apk from app-drawer and list of applications. its secret now!
#8: added final(?) AicBootFix.apk, removed old bootfix, removed suspend/resume messages, added hopes this is the final version without issues
#7: reverted the latest patch of hrkfdn on behalf of himself. this kernel now only contains the first and second spi_aic3254.c patches.
#6: switched to hrkfdn's patches - added aicbootfix - looking forward to keep fm enabled.
#5: no need to use workaround anymore - modified power daemon and kernel driver take care of it. just flash .zip file once - will add itself to cm's auto backup facility.
#4: stoped logcat spam. opened an own thread, since cm7-ace-nightly started beeing the wrong place now.
#3: addind missing wifi module of #2
#2: added kernel and status - decreased ioctl time from 60s to 20s
#1: initial release
archive of old bat fix / method - build #5 - do not use unless you got good reason
This thread/patch aims to fix the battery drain all non-sense ace roms currently have. As soon as this is tested and working for everyone without issues, it will be merged into cm7 and probably also to other roms.
update 2011/03/11: sorry for being away two days. was unforseen. whats the status? hrkfdn started developing a own patch to the aic driver. by now, it seems much better than my solution. it still got an issue with fm radio on boot - but once that is figured out, that patch will be superior to my solution and probably make its way to nightly. until then, have fun with #5 - but dont expect further development here.
This patch contains a kernel, which is based on kali's cm7 kernel. in fact, its absolutly the same, just the driver for the AIC3254 dsp chip is changed.
get build #5 here - md5: f7c7b01a47266b26b8a01f2fc853cfbe
http://www.filesonic.com/file/178617251/mad-#5-aic3254pd_signed.zip
phunkycow's mirrors: http://postkreative.eu/mad/mad-5-aic3254pd_signed.zip / http://uberfail.org/mad/mad-5-aic3254pd_signed.zip - thanks phunky!
old work around after boot not needed anymore. just flash and smile.
to get the current power status:
Code:
[[email protected] xbin]$ adb shell aic3254pd status
Power status of aic3254 chip: OFF
same in terminal emulator on phone:
Code:
localhost / # aic3254pd status
Power status of aic3254 chip: OFF
this is a typical "adb logcat | grep -i aic":
Code:
[ 340.841369] aic3254_set_config: enable tx
[ 340.841766] aic3254_config: size = 12
[ 349.698486] aic3254_powerdown: power off AIC3254
[ 349.698638] aic3254_config: size = 32
[ 381.205322] aic3254_ioctl: Query for AIC3254_POWERSTATUS returned 0 (OFF)
[ 498.071563] aic3254_ioctl: Query for AIC3254_POWERSTATUS returned 0 (OFF)
this is the desired output - since OFF means less battery drain. if you only see ON but never OFF (even though no apps using speaker/microphone), leave feedback.
note: unmodified kernel cannot keep track of power status and init status. flash on non official cm7 roms on your own risk
measurements with battery monitor widget showed, for cm7 the battery drain drops from 11-15mA to 1-5mA to the level, sense roms in standby reach.
regards
mad
I don't have a mirror but I'll seed this until you update: torrent.
Thanks a lot, this made me try CM7
EDIT: I see you are updating but, anyway - the torrent is #4.
#5 might be the last - working on sending the stuff google voice search sends automatic on startup
need feedback: anyone notices, auto-power-down doesnt work anymore after it worked once?
do you need to start voice search again to get power down working?
I'm on cm7, latest nightly. flashed latest version battery fix however even after using voice search, terminal always shows the aic3254 chip as on?
Sent from my Desire HD using Tapatalk
Good on U!
Sent from my DHD Gingerbread
mad-murdock said:
#5 might be the last - working on sending the stuff google voice search sends automatic on startup
need feedback: anyone notices, auto-power-down doesnt work anymore after it worked once?
do you need to start voice search again to get power down working?
Click to expand...
Click to collapse
Noticed. Activated back on some time later.
Hey thanks so much for the patch !
However, when i try to enter command in terminal emulator, i have access denied ???
Do you know why ???
But when i tap dmesg | grep AIC3254, i have this after voice search activation :
Result:
<6>[ 366.089080] aic3254_powerdown: power off AIC3254
<6>[ 426.296417] aic3254_powerdown: power off AIC3254
<6>[ 486.500854] aic3254_powerdown: power off AIC3254
<6>[ 546.708404] aic3254_powerdown: power off AIC3254
<6>[ 606.913177] aic3254_powerdown: power off AIC3254
Cheers
Type in su, enter. Then type in the aic3254 status code.
Sent from my Desire HD using Tapatalk
alexmason14 said:
Type in su, enter. Then type in the aic3254 status code.
Sent from my Desire HD using Tapatalk
Click to expand...
Click to collapse
Oh thanks a lot
Sent from my Desire HD using XDA Premium App
I can replicate the autoswitching on of aic3254pd by playing music through headphones using the android music player..
I don t understand how to apply this patch sorry .... Just flash via CWM 3.0.0.6 and restart ?
sonydesouza said:
Hey thanks so much for the patch !
However, when i try to enter command in terminal emulator, i have access denied ???
Do you know why ???
But when i tap dmesg | grep AIC3254, i have this after voice search activation :
Result:
<6>[ 366.089080] aic3254_powerdown: power off AIC3254
<6>[ 426.296417] aic3254_powerdown: power off AIC3254
<6>[ 486.500854] aic3254_powerdown: power off AIC3254
<6>[ 546.708404] aic3254_powerdown: power off AIC3254
<6>[ 606.913177] aic3254_powerdown: power off AIC3254
Cheers
Click to expand...
Click to collapse
this is what you want to see! dsp chip powers itself down when unused. when you hear a sound, you should see another power off short after.
better do the aic3254pd status command described above
I don't have google voice installed, so I activate power off with built-in voice dialer. Works perfect for me.
Sent from my Desire HD using XDA Apppt
Great work, thanks! Here is some info from my testing, hope it's useful.
I installed mad-#4-aic3254pd_signed.zip from recovery, rebooted then waited
a while without doing anything with the phone (no power button, no touch).
Here is what I got:
/cygdrive/c/xxx: adb shell aic3254pd status
Power status of aic3254 chip: ON
/cygdrive/c/xxx: adb shell dmesg | grep aic3254_
<6>[ 5.092376] spi_aic3254_init
<6>[ 5.092590] spi_aic3254_probe
<6>[ 9.520355] aic3254_ioctl: parameters(64, 1024, 806041a0)
<6>[ 9.521087] aic3254_config: size = 23
<6>[ 9.524627] aic3254_config: size = 1
<6>[ 9.524963] aic3254_ioctl: update table(64,1024) successfully
<6>[ 9.526031] aic3254_ioctl: parameters(64, 1024, 806341a8)
<6>[ 9.526733] aic3254_ioctl: update table(64,1024) successfully
<6>[ 10.349945] aic3254_ioctl: parameters(24, 16384, 806641b4)
<6>[ 10.351898] aic3254_ioctl: update table(24,16384) successfully
<6>[ 10.370605] aic3254_ioctl: index 23 for 40047321
<6>[ 10.370697] aic3254_set_config: table(0x40047321) index(23)
<6>[ 10.370910] aic3254_set_config: miniDSP command len = 32
<6>[ 10.371002] aic3254_set_config: rx mode 29, tx mode 29
<6>[ 10.371124] aic3254_config: size = 32
<6>[ 10.372253] aic3254_set_config: configure minidsp done
<6>[ 10.372406] aic3254_ioctl: index 15 for 40047312
<6>[ 10.372619] aic3254_set_config: table(0x40047312) index(15)
<6>[ 10.372711] aic3254_set_config: enable tx
<6>[ 10.373138] aic3254_config: size = 23
<6>[ 10.373626] aic3254_config: size = 20
<6>[ 470.774963] aic3254_ioctl: Query for AIC3254_POWERSTATUS returned 1 (ON)
After this I used Google voice and then the power button to turn off the screen:
/cygdrive/c/xxxb: adb shell aic3254pd status
Power status of aic3254 chip: OFF
/cygdrive/c/xxx: adb shell dmesg | grep aic3254_
...
<6>[ 470.774963] aic3254_ioctl: Query for AIC3254_POWERSTATUS returned 1 (ON)
<6>[ 608.652496] aic3254_ioctl: index 1 for 40047321
<6>[ 608.652709] aic3254_set_config: table(0x40047321) index(1)
<6>[ 608.652801] aic3254_set_config: miniDSP command len = 32
<6>[ 608.653015] aic3254_set_config: rx mode 29, tx mode 15
<6>[ 608.653106] aic3254_config: size = 32
<6>[ 608.658111] aic3254_config: size = 23
<6>[ 608.659820] aic3254_config: size = 20
<6>[ 608.660278] aic3254_set_config: configure minidsp done
<6>[ 608.660614] aic3254_ioctl: index 29 for 40047312
<6>[ 608.660705] aic3254_set_config: table(0x40047312) index(29)
<6>[ 608.660919] aic3254_set_config: enable tx
<6>[ 608.661315] aic3254_config: size = 12
<6>[ 608.733917] aic3254_ioctl: index 23 for 40047321
<6>[ 608.734008] aic3254_set_config: table(0x40047321) index(23)
<6>[ 608.734222] aic3254_set_config: miniDSP command len = 32
<6>[ 608.734313] aic3254_set_config: rx mode 29, tx mode 29
<6>[ 608.734436] aic3254_config: size = 32
<6>[ 608.737457] aic3254_set_config: configure minidsp done
<6>[ 608.737670] aic3254_ioctl: index 15 for 40047312
<6>[ 608.737792] aic3254_set_config: table(0x40047312) index(15)
<6>[ 608.737976] aic3254_set_config: enable tx
<6>[ 608.738372] aic3254_config: size = 23
<6>[ 608.738922] aic3254_config: size = 20
<6>[ 614.000122] aic3254_ioctl: index 13 for 40047313
<6>[ 614.000396] aic3254_set_config: table(0x40047313) index(13)
<6>[ 614.000549] aic3254_set_config: enable rx
<6>[ 614.001068] aic3254_config: size = 15
<6>[ 614.001892] aic3254_config: size = 11
<6>[ 616.998382] aic3254_ioctl: index 1 for 40047321
<6>[ 616.998565] aic3254_set_config: table(0x40047321) index(1)
<6>[ 616.998687] aic3254_set_config: miniDSP command len = 32
<6>[ 616.998931] aic3254_set_config: rx mode 13, tx mode 15
<6>[ 616.999359] aic3254_config: size = 32
<6>[ 617.001770] aic3254_config: size = 15
<6>[ 617.006561] aic3254_config: size = 11
<6>[ 617.011535] aic3254_config: size = 23
<6>[ 617.013336] aic3254_config: size = 20
<6>[ 617.059783] aic3254_set_config: configure minidsp done
<6>[ 617.059906] aic3254_ioctl: index 29 for 40047312
<6>[ 617.059936] aic3254_set_config: table(0x40047312) index(29)
<6>[ 617.059936] aic3254_set_config: enable tx
<6>[ 617.059967] aic3254_config: size = 12
<6>[ 617.269744] aic3254_ioctl: index 29 for 40047313
<6>[ 617.269744] aic3254_set_config: table(0x40047313) index(29)
<6>[ 617.269744] aic3254_set_config: enable rx
<6>[ 617.269744] aic3254_config: size = 8
<6>[ 627.686737] aic3254_powerdown: power off AIC3254
<6>[ 627.686859] aic3254_config: size = 32
<3>[ 627.794860] aic3254_config: 3254 power down procedure ,flag 0x24=0x00(0x88)
<6>[ 1173.502197] aic3254_ioctl: Query for AIC3254_POWERSTATUS returned 0 (OFF)
After google voice search and chipset off:
# logcat | grep -i aic
I/AudioHardwareMSM7X30( 1206): aic3254_configure: sound effect (Original)
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 0, 1)
I/AudioHardwareMSM7X30( 1206): aic3254_configure: sound effect (Original)
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 0, 1)
I/AudioHardwareMSM7X30( 1206): aic3254_configure: sound effect (Recording)
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 1, 1)
I/AudioHardwareMSM7X30( 1206): aic3254: change tx mode to 15
I/AudioHardwareMSM7X30( 1206): aic3254_configure: sound effect (Recording)
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 1, 1)
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 1, 0)
I/AudioHardwareMSM7X30( 1206): aic3254: change rx mode to 13
E/HTC Acoustic( 1206): cannot open codec aic3254 device -1
I/AudioHardwareMSM7X30( 1206): aic3254_configure: sound effect (Recording)
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 0, 0)
E/AudioHardwareMSM7X30( 1206): cannot open codec aic3254 device -1
I/AudioHardwareMSM7X30( 1206): aic3254_configure: sound effect (Original)
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 0, 0)
I/AudioHardwareMSM7X30( 1206): aic3254: change tx mode to 29
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 0, 1)
I/AudioHardwareMSM7X30( 1206): aic3254: change rx mode to 29
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 0, 0)
I/AudioHardwareMSM7X30( 1206): aic3254: change rx mode to 13
I/AudioHardwareMSM7X30( 1206): do_aic3254_control (1, 0, 1)
I/AudioHardwareMSM7X30( 1206): aic3254: change rx mode to 29
Sent from my Desire HD using Tapatalk
No complaint here, just reporting so others know.
I flashed CM7 RC2, but it was still necessary to flash mad-#4-aic3254pd_signed.zip again after that and use Google voice to enable the power off of the aic3254.
Can someone explain in easy dummy guide style how to turn off voice after patching this fix. Thanks
Sent from my Desire HD using XDA App
Chezbel said:
No complaint here, just reporting so others know.
I flashed CM7 RC2, but it was still necessary to flash mad-#4-aic3254pd_signed.zip again after that and use Google voice to enable the power off of the aic3254.
Click to expand...
Click to collapse
FYI, things work the same as above for #14
shah_jee said:
Can someone explain in easy dummy guide style how to turn off voice after patching this fix. Thanks
Click to expand...
Click to collapse
I'm assuming that you used Google search and then clicked the microphone. When you are done speaking it should just turn off. If that doesn't help then can you provide more info about what you did and what problem you see.
I ended up in a discussion with someone about samsung's kernel code that dynamically offlines the secondary core in the exynos processor. To try and prove my point, I spent a couple hours with kmsg and used a bit of kernel magic to force cores on and off. I did prove a point, but it wasn't the one I expected.
Contrary to conventional wisdom, it appears that taking unused cores offline for the exynos processor doesn't save any power...
I'm really hoping someone can comment on this and show me where I've made a mistake in these tests. I really, really hate when I prove myself wrong.
Here's my test...
2 online exynos cores use the same power as 1 online and 1 offline!
The full test results are below, and there's a certain margin of error that has to be given. The device I tested on is an active android tablet with an exynos processor, so there are certain "background" things going on such as email checks, etc.
Regardless, with display brightness maxed out and numbers offset by ~500mA (see explanation below), here are some interesting power drain numbers:
2 cores locked online:
idle: 214mA
1 max thread: 392mA (2nd core is online but idle)
1 core locked online, 1 core locked OFFLINE (locked with samsung's own pm-hotplug)
idle: 208mA
1 max thread: 394mA (2nd core is locked offline)
So what is the difference between leaving both cores online and letting the kernel offline one of them when it's not needed? There isn't any difference at all from what I can see.
Detail...
The device is attached to a USB port and the kernel programmed to pull 500mA from that port (as long as the "soc" remains below 95%.) The "BAT" kernel messages contain a value, "curr" that reflect the current (in milliamps) going into or out of the battery. The 500mA from the USB cable is fed to the system; if more power is required, it is taken from the battery (and the 'curr' will be negative showing the power being pulled from the battery in excess of 500mA.) If the 500mA from the USB cable more than meets the demands of the system, then the excess power is pushed to the battery (and 'curr' will be positive showing the power being fed into the battery.)
As an example, in these tests, if the 'curr' is -200, then the overall system is using about 700mA of current. (500 from the USB cable and 200 from the battery.) If the 'curr' is a postive 100, then the overall system is using about 400mA (500 in, 400 to the system, 100 to the battery.)
One issue with this measuring: It is measuring the drain on the battery at a given instant (not averaged.)
This was done with a custom GT-P6210 kernel with a mostly stock (some apps frozen) KL1 firmware. The processor was locked at 1200MHz by using the performance governor. Voltages were left at stock. Screen brightness was set to max and the screen "touched" every 30-40 seconds to keep it fully bright (exception near the bottom of the tests when I was curious what the display pulled.) The battery of the device was kept between 80 and 90% charged to ensure consistant charging amperage.
The processor "lock" was performed using the /sys/module/pm_hotplug/parameters/lock file. Writing a '1' to the file while either both cores were active or a single core was active. Switching from 2 cores to 1 core was done by writing 0 to the lock file, letting the device go idle, and then writing 1 to the lock file to lock it into single core mode. A control test was also performed to ensure that multiple active threads did not activate a second core or increase the power consumed beyond that used by a single thread.
---- dual core tests ----
usb charging, locked to 1200MHZ, idle, screen on (full bright) 2 processor lock:
<6>[ 919.056730] BAT : soc(83), vcell(4000mV), curr(-216mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 959.336086] BAT : soc(83), vcell(4000mV), curr(-220mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 989.346786] BAT : soc(83), vcell(4001mV), curr(-205mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
Avg: -214mA drain with BOTH cores online and only minimal activity on either of them.
usb charging, locked to 1200MHZ, 1 maxed thread (cat /dev/urandom), screen on (full bright) 2 processor lock:
<6>[ 798.756718] BAT : soc(84), vcell(3978mV), curr(-392mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 828.776728] BAT : soc(84), vcell(3978mV), curr(-395mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
<6>[ 858.798651] BAT : soc(84), vcell(3979mV), curr(-389mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
Avg: -392mA drain with BOTH cores online and 1 of the cores maxed out. Only minimal activity on the second core.
usb charging, locked to 1200MHZ, 2 maxed thread (cat /dev/urandom), screen on (full bright) 2 processor lock:
<6>[ 678.636706] BAT : soc(84), vcell(3965mV), curr(-544mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 708.671712] BAT : soc(84), vcell(3962mV), curr(-543mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
<6>[ 738.711725] BAT : soc(84), vcell(3960mV), curr(-555mA), temp(32.5), chg(1), full(0), rechg(0), cable(1)
Avg: -547mA drain with BOTH cores online and BOTH cores maxed out.
---- single core tests ----
usb charging, locked to 1200MHZ, idle, screen on (full bright) 1 processor lock:
<6>[ 1208.160803] BAT : soc(83), vcell(4000mV), curr(-207mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 1238.193945] BAT : soc(83), vcell(3998mV), curr(-212mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
<6>[ 1268.231466] BAT : soc(83), vcell(3998mV), curr(-205mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
Avg: -208mA drain with only ONE core online and only minimal activity on it.
usb charging, locked to 1200MHZ, 1 maxed thread (cat /dev/urandom), screen on (full bright) 1 processor lock:
<6>[ 1598.818708] BAT : soc(82), vcell(3970mV), curr(-391mA), temp(32.7), chg(1), full(0), rechg(0), cable(1)
<6>[ 1628.862098] BAT : soc(82), vcell(3967mV), curr(-399mA), temp(32.7), chg(1), full(0), rechg(0), cable(1)
<6>[ 1658.901275] BAT : soc(82), vcell(3966mV), curr(-393mA), temp(32.8), chg(1), full(0), rechg(0), cable(1)
Avg: -394mA drain with only ONE core online and that core maxed out.
CONTROL and SANITY TESTS:
usb charging, locked to 1200MHz, 2 maxed thread (cat /dev/urandom), screen on (full bright) 1 processor lock:
(This was mostly a control test to ensure that only one processor was being
used.)
<6>[ 2144.689687] BAT : soc(82), vcell(3976mV), curr(-386mA), temp(31.8), chg(1), full(0), rechg(0), cable(1)
<6>[ 2174.751884] BAT : soc(82), vcell(3971mV), curr(-389mA), temp(31.9), chg(1), full(0), rechg(0), cable(1)
<6>[ 2205.090748] BAT : soc(82), vcell(3969mV), curr(-387mA), temp(31.9), chg(1), full(0), rechg(0), cable(1)
Avg: -387mA drain with only ONE core online and that core doing double duty. (this doesn't show us anything other than that only a single core was being used)
usb charging, locked to 1200MHz, 2maxed threads, screen OFF, 1 processor lock:
(note: display turned off!)
<6>[ 1993.881881] BAT : soc(82), vcell(4043mV), curr(182mA), temp(31.8), chg(1), full(0), rechg(0), cable(1)
<6>[ 2023.936881] BAT : soc(82), vcell(4045mV), curr(181mA), temp(31.7), chg(1), full(0), rechg(0), cable(1)
<6>[ 2053.986909] BAT : soc(82), vcell(4044mV), curr(181mA), temp(31.7), chg(1), full(0), rechg(0), cable(1)
usb charging, locked to 1200MHz, idle, screen OFF, 1 processor lock:
<6>[ 2910.782709] BAT : soc(83), vcell(4078mV), curr(370mA), temp(30.0), chg(1), full(0), rechg(0), cable(1)
<6>[ 2940.807429] BAT : soc(83), vcell(4080mV), curr(367mA), temp(29.9), chg(1), full(0), rechg(0), cable(1)
<6>[ 2970.841380] BAT : soc(83), vcell(4080mV), curr(369mA), temp(29.8), chg(1), full(0), rechg(0), cable(1)
(so, the display is pulling between 550mA and 590mA)
garyd9 said:
I ended up in a discussion with someone about samsung's kernel code that dynamically offlines the secondary core in the exynos processor. To try and prove my point, I spent a couple hours with kmsg and used a bit of kernel magic to force cores on and off. I did prove a point, but it wasn't the one I expected.
Contrary to conventional wisdom, it appears that taking unused cores offline for the exynos processor doesn't save any power...
I'm really hoping someone can comment on this and show me where I've made a mistake in these tests. I really, really hate when I prove myself wrong.
Here's my test...
2 online exynos cores use the same power as 1 online and 1 offline!
The full test results are below, and there's a certain margin of error that has to be given. The device I tested on is an active android tablet with an exynos processor, so there are certain "background" things going on such as email checks, etc.
Regardless, with display brightness maxed out and numbers offset by ~500mA (see explanation below), here are some interesting power drain numbers:
2 cores locked online:
idle: 214mA
1 max thread: 392mA (2nd core is online but idle)
1 core locked online, 1 core locked OFFLINE (locked with samsung's own pm-hotplug)
idle: 208mA
1 max thread: 394mA (2nd core is locked offline)
So what is the difference between leaving both cores online and letting the kernel offline one of them when it's not needed? There isn't any difference at all from what I can see.
Detail...
The device is attached to a USB port and the kernel programmed to pull 500mA from that port (as long as the "soc" remains below 95%.) The "BAT" kernel messages contain a value, "curr" that reflect the current (in milliamps) going into or out of the battery. The 500mA from the USB cable is fed to the system; if more power is required, it is taken from the battery (and the 'curr' will be negative showing the power being pulled from the battery in excess of 500mA.) If the 500mA from the USB cable more than meets the demands of the system, then the excess power is pushed to the battery (and 'curr' will be positive showing the power being fed into the battery.)
As an example, in these tests, if the 'curr' is -200, then the overall system is using about 700mA of current. (500 from the USB cable and 200 from the battery.) If the 'curr' is a postive 100, then the overall system is using about 400mA (500 in, 400 to the system, 100 to the battery.)
One issue with this measuring: It is measuring the drain on the battery at a given instant (not averaged.)
This was done with a custom GT-P6210 kernel with a mostly stock (some apps frozen) KL1 firmware. The processor was locked at 1200MHz by using the performance governor. Voltages were left at stock. Screen brightness was set to max and the screen "touched" every 30-40 seconds to keep it fully bright (exception near the bottom of the tests when I was curious what the display pulled.) The battery of the device was kept between 80 and 90% charged to ensure consistant charging amperage.
The processor "lock" was performed using the /sys/module/pm_hotplug/parameters/lock file. Writing a '1' to the file while either both cores were active or a single core was active. Switching from 2 cores to 1 core was done by writing 0 to the lock file, letting the device go idle, and then writing 1 to the lock file to lock it into single core mode. A control test was also performed to ensure that multiple active threads did not activate a second core or increase the power consumed beyond that used by a single thread.
---- dual core tests ----
usb charging, locked to 1200MHZ, idle, screen on (full bright) 2 processor lock:
<6>[ 919.056730] BAT : soc(83), vcell(4000mV), curr(-216mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 959.336086] BAT : soc(83), vcell(4000mV), curr(-220mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 989.346786] BAT : soc(83), vcell(4001mV), curr(-205mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
Avg: -214mA drain with BOTH cores online and only minimal activity on either of them.
usb charging, locked to 1200MHZ, 1 maxed thread (cat /dev/urandom), screen on (full bright) 2 processor lock:
<6>[ 798.756718] BAT : soc(84), vcell(3978mV), curr(-392mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 828.776728] BAT : soc(84), vcell(3978mV), curr(-395mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
<6>[ 858.798651] BAT : soc(84), vcell(3979mV), curr(-389mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
Avg: -392mA drain with BOTH cores online and 1 of the cores maxed out. Only minimal activity on the second core.
usb charging, locked to 1200MHZ, 2 maxed thread (cat /dev/urandom), screen on (full bright) 2 processor lock:
<6>[ 678.636706] BAT : soc(84), vcell(3965mV), curr(-544mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 708.671712] BAT : soc(84), vcell(3962mV), curr(-543mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
<6>[ 738.711725] BAT : soc(84), vcell(3960mV), curr(-555mA), temp(32.5), chg(1), full(0), rechg(0), cable(1)
Avg: -547mA drain with BOTH cores online and BOTH cores maxed out.
---- single core tests ----
usb charging, locked to 1200MHZ, idle, screen on (full bright) 1 processor lock:
<6>[ 1208.160803] BAT : soc(83), vcell(4000mV), curr(-207mA), temp(32.3), chg(1), full(0), rechg(0), cable(1)
<6>[ 1238.193945] BAT : soc(83), vcell(3998mV), curr(-212mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
<6>[ 1268.231466] BAT : soc(83), vcell(3998mV), curr(-205mA), temp(32.4), chg(1), full(0), rechg(0), cable(1)
Avg: -208mA drain with only ONE core online and only minimal activity on it.
usb charging, locked to 1200MHZ, 1 maxed thread (cat /dev/urandom), screen on (full bright) 1 processor lock:
<6>[ 1598.818708] BAT : soc(82), vcell(3970mV), curr(-391mA), temp(32.7), chg(1), full(0), rechg(0), cable(1)
<6>[ 1628.862098] BAT : soc(82), vcell(3967mV), curr(-399mA), temp(32.7), chg(1), full(0), rechg(0), cable(1)
<6>[ 1658.901275] BAT : soc(82), vcell(3966mV), curr(-393mA), temp(32.8), chg(1), full(0), rechg(0), cable(1)
Avg: -394mA drain with only ONE core online and that core maxed out.
CONTROL and SANITY TESTS:
usb charging, locked to 1200MHz, 2 maxed thread (cat /dev/urandom), screen on (full bright) 1 processor lock:
(This was mostly a control test to ensure that only one processor was being
used.)
<6>[ 2144.689687] BAT : soc(82), vcell(3976mV), curr(-386mA), temp(31.8), chg(1), full(0), rechg(0), cable(1)
<6>[ 2174.751884] BAT : soc(82), vcell(3971mV), curr(-389mA), temp(31.9), chg(1), full(0), rechg(0), cable(1)
<6>[ 2205.090748] BAT : soc(82), vcell(3969mV), curr(-387mA), temp(31.9), chg(1), full(0), rechg(0), cable(1)
Avg: -387mA drain with only ONE core online and that core doing double duty. (this doesn't show us anything other than that only a single core was being used)
usb charging, locked to 1200MHz, 2maxed threads, screen OFF, 1 processor lock:
(note: display turned off!)
<6>[ 1993.881881] BAT : soc(82), vcell(4043mV), curr(182mA), temp(31.8), chg(1), full(0), rechg(0), cable(1)
<6>[ 2023.936881] BAT : soc(82), vcell(4045mV), curr(181mA), temp(31.7), chg(1), full(0), rechg(0), cable(1)
<6>[ 2053.986909] BAT : soc(82), vcell(4044mV), curr(181mA), temp(31.7), chg(1), full(0), rechg(0), cable(1)
usb charging, locked to 1200MHz, idle, screen OFF, 1 processor lock:
<6>[ 2910.782709] BAT : soc(83), vcell(4078mV), curr(370mA), temp(30.0), chg(1), full(0), rechg(0), cable(1)
<6>[ 2940.807429] BAT : soc(83), vcell(4080mV), curr(367mA), temp(29.9), chg(1), full(0), rechg(0), cable(1)
<6>[ 2970.841380] BAT : soc(83), vcell(4080mV), curr(369mA), temp(29.8), chg(1), full(0), rechg(0), cable(1)
(so, the display is pulling between 550mA and 590mA)
Click to expand...
Click to collapse
Good to know our discussion have lead you do this tests. I hope it serves future developers and help them understand more about the ARM arch and it's power saving mechanics.
Thank you for your effort to make our devices better.
This is very interesting. I don't know if you follow the transformer prime but they also released some new firmware that keeps all 4 cores on all the time. There is a lot of confusion about this on the tfp boards but with this data it just makes sense from a battery/performance standpoint. Very interesting.
Thanks garyd9, I appreciate your efforts with this, may be things will be different shortly once we have quad core processors in place with one core completely dedicated to power management. Keep up good work!
Interesting... This says to me that there is something wrong with the chip's power management features, at least as implemented on the P6210.
One thing though - with the screen on, some of the lower CPU power consumption numbers are going to get "lost in the noise" - With your idle tests, you're trying to measure something on the order of tens of milliamps with the screen drawing on the order of 600 mA. As an example - when sitting idle and wakelocked at 200 MHz with screen off, my I777 consumes just over 1%/hour battery. As in, total system power represents only 20-30 mA of average consumption, including the cell radio and wifi.
The P6210 has, in theory, a superior cpuidle driver to the I9100, I777, and Note (with the exception of my kernel and SiyahKernel now that they have backports of the 6210's cpuidle driver) - However hotplugging in the second core makes this change irrelevant, as all idle states beyond basic clock gating (IDLE state) are locked out when the second core is online.
Your results are interesting in that they don't make sense - power gating an entire core when idle should save power by reducing static consumption (which is going to be maximized at 1.2 GHz), but that's not happening in this case. The question is why? I wonder if having USB plugged in is causing some of the cpuidle op checks to fail, or is causing enough interrupt or timer events that cpuidle isn't even selecting deeper states.
As an experiment - when you are idle on a single core with the screen full-on, check the cpuidle statistics after some time to see if it is attempting to enter deeper idle states. Note: Failing op-checks within the cpuidle driver itself won't get reflected as spending time in lower (worse) states, the statistics only report what the cpuidle governor selected, not what it actually got. An Exynos/Hummingbirdism is that one can select one idle state and get a worse one without knowing it.
It might be a couple days before I can do further testing... my paying job has certain expectations. My wife has even greater expectations.
I needed the screen at full brightness to keep a negative drain on the battery while testing (to prevent it from actually charging and then the charging circuit dropping to trickle mode.) I want to redo portions of the test when the battery is already at or below 50%, but with the screen off and the tablet in "airplane" mode. I don't think wifi pulls enough power to have an impact, but it doesn't hurt to disable it. I also want to add something to pull the battery current stats even when the tablet isn't connected to a cable... That will require a bit of a branch.
Where are the cpuidle stats you'd like pulled?
This was intented as a brute force question of: "Does having the second core offline save power given equal workloads?" One of the parameters of the test was to prevent overall system suspend. It's quite possible that allowing the second core to go offline does save power, but not within the limited parameters I tested for. The cpuidle code shouldn't really have played a part in this...
The ramifications that this might have on the cpuidle code are interesting, though.
It looks like I'm not done testing.
Take care
Gary
I won't be able to hunt down the locations for the idle states until tonight.
However as I mentioned in my kernel thread, there is evidence that having an active USB connection may fire enough interrupts or timer events to stop AFTR from being chosen, given AntwanL's experiences with the MFC/cpuidle interoperability issues - locking out AFTR manually eliminated the problems, but for him, just plugging USB into a computer also blocked the problems.
It's tests like this that make me really want to wire up a dummy battery with a current sensor... Such a pain in the ass but potentially so worth it!
my phone keeps on overheating as I am playing clash of clans for a prolonged period of time. is there any way to fix it? i am running purity rom with franco kernel.
onecrzyasian said:
my phone keeps on overheating as I am playing clash of clans for a prolonged period of time. is there any way to fix it? i am running purity rom with franco kernel.
Click to expand...
Click to collapse
describe "overheating". what cpu temp is it reaching?
Hi,
Another one...
You have a quadcore at 2,26 Ghz device, under certain conditions (heavy games, browsing in 4g, long run heavy tasks, etc...) it's absolutely normal that the phone runs hot... And you sais it by yourself "I am playing clash of clans for a prolonged period of time."...
In any case there is a thermal protection called thermal throttling that reduces the CPU freq, the number of cores online and the screen brightness when the CPU (and/or battery) reaches some different temperature ranges, so no worries...
And even if Franciscofranco modified the thermal management, the thermal throttle is always present (you can also adjust it to reduce the heat by decreasing the CPU temp limit before thermal throttling).
But guys... in all scenarios there is the thermal throttling, and it does its job when needed. In extreme conditions the phone shutdown itself to prevent any damage. This CPU can handle more than 100 °C. Use your phone as normal, as you need... Or don't use GPS, don't play games, don't run benchs...
As an example on how thermal throttling works:
Code:
sampling 5000
[battery_LCD_monitor]
algo_type monitor
sensor batt_therm
sampling 10000
thresholds 100000 340000 350000 360000 370000
thresholds_clr 50000 330000 340000 350000 350000
actions override override override override override
action_info 10000 7500 5000 2500 0
[SKIN_THERMAL_management_1]
algo_type monitor
sensor xo_therm_pu2
sampling 10000
thresholds 40000 42000 44000
thresholds_clr 38500 40500 42500
actions cpu+lcd cpu+lcd cpu+lcd
action_info 1958400+229 1574400+204 1190400+178
[battery_monitor]
algo_type monitor
sensor batt_therm
sampling 10000
thresholds 480000 550000
thresholds_clr 460000 500000
actions battery battery
action_info 2 3
[CPU0_MONITOR]
algo_type monitor
sensor cpu0
sampling 65
thresholds 115000
thresholds_clr 110000
actions shutdown
action_info 0
[CPU1_MONITOR]
algo_type monitor
sensor cpu1
sampling 65
thresholds 115000
thresholds_clr 110000
actions shutdown
action_info 0
[CPU2_MONITOR]
algo_type monitor
sensor cpu2
sampling 65
thresholds 115000
thresholds_clr 110000
actions shutdown
action_info 0
[CPU3_MONITOR]
algo_type monitor
sensor cpu3
sampling 65
thresholds 115000
thresholds_clr 110000
actions shutdown
action_info 0
[HOTPLUG-CPU1]
algo_type monitor
sensor cpu1
sampling 65
thresholds 105000
thresholds_clr 85000
actions hotplug_1
action_info 1
[HOTPLUG-CPU2]
algo_type monitor
sensor cpu2
sampling 65
thresholds 105000
thresholds_clr 85000
actions hotplug_2
action_info 1
[HOTPLUG-CPU3]
algo_type monitor
sensor cpu3
sampling 65
thresholds 105000
thresholds_clr 85000
actions hotplug_3
action_info 1
[PID-CPU0]
disable 1
[PID-CPU1]
disable 1
[PID-CPU2]
disable 1
[PID-CPU3]
disable 1
[PID-POPMEM]
disable 1
[SS-CPU0]
algo_type ss
sampling 65
sensor cpu0
device cpu
set_point 80000
set_point_clr 55000
[SS-CPU1]
algo_type ss
sampling 65
sensor cpu1
device cpu
set_point 80000
set_point_clr 55000
[SS-CPU2]
algo_type ss
sampling 65
sensor cpu2
device cpu
set_point 80000
set_point_clr 55000
[SS-CPU3]
algo_type ss
sampling 65
sensor cpu3
device cpu
set_point 80000
set_point_clr 55000
[SS-POPMEM]
algo_type ss
sampling 65
sensor pop_mem
device cpu
set_point 80000
set_point_clr 55000
time_constant 16
It's a quadcore at 2,26 Ghz completely enclosed without any additional cooling system, so...
It remembers me the Nexus 4 all these threads/questions about "pseudo" heating/overheating...
Like simms22 said check your temperatures and provide them to have an approach a bit more real, because "it feels hot", "it is overheating", etc... is very subjective (for example I go outdoor with a 2 °C room temperature, I take my phone stays indoor and I feel it "hot", I check the CPU temperature and it's at about 30 °C...if you know what I try to say even if it's not your case here but it's a general idea).
Also you provide more information like overclock? Undervolt? Governor (even if in Franciscofranco kernel there is only Interactive and Performance)?
I am not sure what the temp was before it shut down, but i shall try lowering the throttle temp
onecrzyasian said:
I am not sure what the temp was before it shut down, but i shall try lowering the throttle temp
Click to expand...
Click to collapse
Re,
Because your phone shutdown when you were playing? You did not mentioned it in the OP... (it could be caused by another things too, undervolt, kernel panic, etc...).
Before shutdown, it's the ultimate thermal protection, the CPU freq decreases according to different CPU/battery temperatures to cool down the CPU (thermal throttling)... Post a last_kmsg if you have a hard-reboot to see... Post it in the kernel thread, here, or in this thread: http://forum.xda-developers.com/showthread.php?t=2532422.
Ktoonsez presents:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
KT-NOTE4 kernel features
•Must have a Note 4 model N910T or N910P or N910W8
•Must have a Touchwiz Rooted ROM
•Must have CWM/TWRP based recovery installed
•Samsung open source
•Optimized kernel configuration
•unsecure root adb
•Voltage interface
•KTweaker app for kernel control
•KTweaker Widgets
•Schedulers (CFQ, BFQ, VR, SIO, NOOP, DEADLINE, ROW, FIFO, FIOPS)
•GOVERNORS (ktoonservativeq, intellidemand, msm-dcvs, wheatley, userspace, smartassh3, slp, powersave, pegasuq, nightmare, interactive, dancedance, conservative, badass, asswax, adaptive, abyssplug, performance, ondemand
•exFAT for Touchwiz
Click to expand...
Click to collapse
Touchwiz Kitkat 4.4 VERSION:
11.11.2014: http://goo.gl/IG2O5Q
Click to expand...
Click to collapse
Always do the following AFTER installing the kernel:
1. Clear cache
2. Clear dalvik
Post #2 will be reserved for change logs
Post #3 will be reserved for MY Settings, Extras and FAQ's
Sources can be found here:
https://github.com/ktoonsez/KTNOTE4
Change Log 12.08.2014
1. Added some Profiles to the KTweaker Shop, thanks to @zman2107 for helping out
2. Some tweaks to ktoonservativeq
3. Added Trinity Colors, thanks to @twistedumbrella for porting in the code
4. Added Bluetooth Min Mhz control
5. Added Music/Media Min Mhz control
6. Added bfq scheduler
Change Log 11.13.2014
1. Rebase kernel source on N910F
2. NOW Working on F and G models!!!!!!!!!!!!!!!
3. Make ramdisk universal so its working on all Qualcomm variants
4. Add Fast Charge from my S4/S5 code
5. Increase bandwidth fro OC steps from @twistedumbrella
6. Removed a butt load of dmesg spam
Change Log 11.11.2014
1. Initial release
2. Based on Samsung source from N910T model
3. Added multi compatibility for multiple models
4. Removed root restrictions from kernel
5. Made selinux permissive
6. Added voltage control
7. Added OC to 3072 Mhz
8. Added KThermal
9. Added KT Hotplug
10. Lots more stuff to come!!!!!!!!!!!!!!!!!!!!!!!!
11. Linaro -O3 compiled plus Make file opto's
12. Added bfq scheduler
13. There is lots of stuff in KTweaker not enabled yet so only use the stuff that is listed in this change log!!!
ktoonservativeq explained:
***** NOTES *****
Any item with the word cycle in it refers to how many sampling_rate's have occurred.
Examples:
A "boost_hold_cycles" of 22 and a sampling_rate of 45000 equates to 1 seconds of holding your Mhz at the boost level.
A block_cycles_offline_screen_on of 11 and a sampling_rate of 45000 equates to a half of a second block before it takes cores offline.
***** NOTES *****
block_cycles_offline_screen_off =1
How many sampling_rate cycles need to occur before a core is allowed to go OFFLINE while the screen is OFF.
block_cycles_offline_screen_on = 11
How many sampling_rate cycles need to occur before a core is allowed to go OFFLINE while the screen is ON.
block_cycles_online_screen_off = 11
How many sampling_rate cycles need to occur before a core is allowed to go ONLINE while the screen is OFF.
block_cycles_online_screen_on = 3
How many sampling_rate cycles need to occur before a core is allowed to go ONLINE while the screen is ON.
block_cycles_raise_screen_off = 11
How many sampling_rate cycles need to occur before the current Mhz is allowed to be raised while the screen is OFF.
block_cycles_raise_screen_on = 3
How many sampling_rate cycles need to occur before the current Mhz is allowed to be raised while the screen is ON.
boost_2nd_core_on_button_screen_off = 1
When this item is a 1, it will turn on the 2nd core when a button any hard button is pressed while the screen is OFF. 0 leaves the core in its current state.
boost_2nd_core_on_button_screen_on = 1
When this item is a 1, it will turn on the 2nd core when a button any hard button is pressed while the screen is ON. 0 leaves the core in its current state.
boost_3rd_core_on_button_screen_off = 0
When this item is a 1, it will turn on the 3nd core when a button any hard button is pressed while the screen is OFF. 0 leaves the core in its current state.
boost_3rd_core_on_button_screen_on = 0
When this item is a 1, it will turn on the 3nd core when a button any hard button is pressed while the screen is ON. 0 leaves the core in its current state.
boost_4th_core_on_button_screen_off = 0
When this item is a 1, it will turn on the 4nd core when a button any hard button is pressed while the screen is OFF. 0 leaves the core in its current state.
boost_4th_core_on_button_screen_on = 0
When this item is a 1, it will turn on the 4nd core when a button any hard button is pressed while the screen is ON. 0 leaves the core in its current state.
boost_hold_cycles = 22
How many sampling_rate cycles need to occur before going out of CPU/GPU boost mode
disable_hotplug = 0
When this item is a 1, it disables hotplugging so all cores stay on full time. 0 lets all cores turn on and off when needed.
disable_hotplug_bt = 0
When this item is a 1, it disables hotplugging so all cores stay on full time while paired to a bluetooth device and doing bluetooth activities like playing music, transfering files.... 0 doesn't do anything extra to the cores when doing bluetooth functions.
disable_hotplug_chrg = 0
When this item is a 1, it disables hotplugging so all cores stay on full time while charging the device. 0 doesn't do anything extra to the cores while charging.
disable_hotplug_media = 0
When this item is a 1, it disables hotplugging so all cores stay on full time while playing music or movies. 0 doesn't do anything extra to the cores while music or movies are playing.
down_threshold_screen_off = 52
A percentage of CPU utilization that needs to occur before the current Mhz begins to lower while screen is OFF.
down_threshold_screen_off_hotplug_1 = 35
A percentage of CPU utilization that needs to occur before the 2nd core is taken offline while screen is OFF.
down_threshold_screen_off_hotplug_2 = 45
A percentage of CPU utilization that needs to occur before the 3rd core is taken offline while screen is OFF.
down_threshold_screen_off_hotplug_3 = 55
A percentage of CPU utilization that needs to occur before the 4th core is taken offline while screen is OFF.
down_threshold_screen_on = 52
A percentage of CPU utilization that needs to occur before the current Mhz begins to lower while screen is ON.
down_threshold_screen_on_hotplug_1 = 35
A percentage of CPU utilization that needs to occur before the 2nd core is taken offline while screen is ON.
down_threshold_screen_on_hotplug_2 = 45
A percentage of CPU utilization that needs to occur before the 3rd core is taken offline while screen is ON.
down_threshold_screen_on_hotplug_3 = 55
A percentage of CPU utilization that needs to occur before the 4th core is taken offline while screen is ON.
freq_step_lower_screen_off = 8
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when lowering the current Mhz while the screen is OFF.
freq_step_lower_screen_on = 2
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when lowering the current Mhz while the screen is ON.
freq_step_raise_screen_off = 1
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when raising the current Mhz while the screen is OFF.
freq_step_raise_screen_on = 5
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when raising the current Mhz while the screen is ON.
ignore_nice_load = 0
If this value is "1," the system will ignore "Nice" processes when deciding to scale up or down. Nice processes are used by the IO scheduler to designate a low-priority process. Ignore nice load basically tells a governor to disregard processes with higher nice values.
lockout_2nd_core_hotplug_screen_off = 0
This is a 3 way option. While the screen is OFF, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_2nd_core_hotplug_screen_on = 0
This is a 3 way option. While the screen is ON, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_3rd_core_hotplug_screen_off = 0
This is a 3 way option. While the screen is OFF, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_3rd_core_hotplug_screen_on = 0
This is a 3 way option. While the screen is ON, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_4th_core_hotplug_screen_off = 0
This is a 3 way option. While the screen is OFF, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_4th_core_hotplug_screen_on = 0
This is a 3 way option. While the screen is ON, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
no_extra_cores_screen_off = 1
When set to a 1, this option keeps all extra CPU cores offline while the screen is OFF. 0 lets it hotplug them on and off as needed
sampling_down_factor = 1
NOT USED!
sampling_rate = 45000
The amount of milliseconds that the governor will analyze the CPU usage and adjust for changes in load while the screen is ON.
sampling_rate_min = 10000
READ-ONLY value that specifies the lower value that "sampling_rate" and "sampling_rate_screen_off" will accept.
sampling_rate_screen_off = 45000
The amount of milliseconds that the governor will analyze the CPU usage and adjust for changes in load while the screen is OFF.
super_conservative_screen_off = 0
With the screen OFF: When set to a 1, this option will explicitly obey your block cycles settings to be a super battery saver (Setting a 1 will slow down the UI a little bit). When set to a 0 it uses fuzzy logic on the "block cycle" items.
super_conservative_screen_on = 0
With the screen ON: When set to a 1, this option will explicitly obey your block cycles settings to be a super battery saver (Setting a 1 will slow down the UI a little bit). When set to a 0 it uses fuzzy logic on the "block cycle" items to create a smooooooth UI experience.
sync_extra_cores_screen_off = 0
With the screen OFF: When set to a 1, all online cores will be sync'd to the same speed as core 0. When set to a 0, all cores will operate at speeds independant of each other.
sync_extra_cores_screen_on = 0
With the screen ON: When set to a 1, all online cores will be sync'd to the same speed as core 0. When set to a 0, all cores will operate at speeds independant of each other.
touch_boost_2nd_core = 1
When set to a 1, this option turns on the 2nd core when the screen is touched. When set to a 0 it doesn't do anything extra to the cores.
touch_boost_3rd_core = 0
When set to a 1, this option turns on the 3rd core when the screen is touched. When set to a 0 it doesn't do anything extra to the cores.
touch_boost_4th_core = 0
When set to a 1, this option turns on the 4th core when the screen is touched. When set to a 0 it doesn't do anything extra to the cores.
touch_boost_cpu = 1804800
The Mhz that you want the online CPU's to jump to when the screen is touched.
touch_boost_cpu_all_cores = 0
When set to a 1, this option sets the current Mhz on all online cores to the selected touch_boost_cpu value.
touch_boost_gpu = 462400
This value specifies what Mhz the GPU should jump to when the screen is touched.
up_threshold_screen_off = 57
A percentage of CPU utilization that needs to occur before the current Mhz begins to raise while screen is OFF.
up_threshold_screen_off_hotplug_1 = 58
A percentage of CPU utilization that needs to occur before the 2nd core is put online while screen is OFF.
up_threshold_screen_off_hotplug_2 = 68
A percentage of CPU utilization that needs to occur before the 3rd core is put online while screen is OFF.
up_threshold_screen_off_hotplug_3 = 78
A percentage of CPU utilization that needs to occur before the 4th core is put online while screen is OFF.
up_threshold_screen_on = 57
A percentage of CPU utilization that needs to occur before the current Mhz begins to raise while screen is ON.
up_threshold_screen_on_hotplug_1 = 58
A percentage of CPU utilization that needs to occur before the 2nd core is put online while screen is ON.
up_threshold_screen_on_hotplug_2 = 68
A percentage of CPU utilization that needs to occur before the 3rd core is put online while screen is ON.
up_threshold_screen_on_hotplug_3 = 78
A percentage of CPU utilization that needs to occur before the 4th core is put online while screen is ON.
Other Governors and schedulers explained:
http://forum.xda-developers.com/showthread.php?t=1687578
http://forum.xda-developers.com/showthread.php?t=1369817
http://tinzdroid.blogspot.com/2012/07/android-kernel-governors-modules-io.html
http://forum.xda-developers.com/showpost.php?p=21638852&postcount=56
First
Everybody be sure to give @em0ney14 a big "THANKS" for the countless hours of testing the kernel while I spent countless hours doing the programming
@LuigiBull23
Man am I glad to see you here I was missing you over on the s4 forum! Love being able to rock your kernels from the s2 all the way here
Excellent! Flashing now, thanks for all your hard work throughout the years. I always rock KT whenever possible! :highfive:
Can you post stock kernel just in case .
BAD ASS NOTE 4
BACARDILIMON said:
Can you post stock kernel just in case .
BAD ASS NOTE 4
Click to expand...
Click to collapse
I cant but maybe someone else can, but if you are using somones ROM from the forum, all u have to do is flash the ROM again
re: official stock N910T Note 4 kernel
BACARDILIMON said:
Can you post stock kernel just in case .
BAD ASS NOTE 4
Click to expand...
Click to collapse
Here is a download link for the Tmobile N910T Note 4 stock kernel.
https://app.box.com/s/nj34un45zxdo01ygd1dk
Flash this kernel using Flashify.
Here is the Play Store link for Flashify in case you need it:
https://play.google.com/store/apps/details?id=com.cgollner.flashify
Good luck!
Misterjunky said:
Here is a download link for the Tmobile N910T Note 4 stock kernel.
https://app.box.com/s/nj34un45zxdo01ygd1dk
Flash this kernel using Flashify.
Here is the Play Store link for Flashify in case you need it:
https://play.google.com/store/apps/details?id=com.cgollner.flashify
Good luck!
Click to expand...
Click to collapse
Thanks fir that info mister junky, I also have a flashable for a near stock kernel kt and I was working on as a base if anyone has issues with this release let us know.
Cant seem to get cpu to go past 2649. I have it set with ktweak to 3000 but it stops at 2649
Sent from my SM-N910T using XDA Free mobile app
WOOT WOOT (I never understood why it is WOOT WOOT - versus WHOOO WHOOO - ? I never heard anyone ever go WOOT WOOT and prounce the T when they are really happy - more like WOO HOO - or something along those lines - well regardless The point is the same - and the sentiment is obvious - I am really glad to see you here - and just as glad to see you are brining us a new kernel -
Looking forward to flashing this and getting some ktnoonze kernel goodness on my NOTE 4 - thanks!
PS - who came up with the WOOT - versus the WOO ? Inquiring minds want to know.
Thanks Koontz. Downloading now. Be like the old a Asus tf101 days up in here.
chrisgto4 said:
Cant seem to get cpu to go past 2649. I have it set with ktweak to 3000 but it stops at 2649
Sent from my SM-N910T using XDA Free mobile app
Click to expand...
Click to collapse
What app r u using to see what spees its hitting? My KTMonitor app? Are you running a benchmark app to push the CPU?
ktoonsez said:
What app r u using to see what spees its hitting? My KTMonitor app? Are you running a benchmark app to push the CPU?
Click to expand...
Click to collapse
Im using ktmonitor. I tried the most cpu intensive apk i have. Video to gif.....it runs the cpu at avg 75-100% cpu usage. Then changed the governor to performance and set min/max to 3000. Still stayed at 2649. Other than that very impressed with kernel. Nice work
Sent from my SM-N910T using XDA Free mobile app
Man this is awesome.
Sent from my SM-N910T using Tapatalk
chrisgto4 said:
Cant seem to get cpu to go past 2649. I have it set with ktweak to 3000 but it stops at 2649
Sent from my SM-N910T using XDA Free mobile app
Click to expand...
Click to collapse
Click main settings - CPU Settings - then select - enable OC settings - then set your CPU to what you want to set it to - I did these steps and had no issues.
Some things are not working yet - but I know it is very early in this kernel's life - more good things are sure to be coming soon.
chrisgto4 said:
Im using ktmonitor. I tried the most cpu intensive apk i have. Video to gif.....it runs the cpu at avg 75-100% cpu usage. Then changed the governor to performance and set min/max to 3000. Still stayed at 2649. Other than that very impressed with kernel. Nice work
Sent from my SM-N910T using XDA Free mobile app
Click to expand...
Click to collapse
Here is a screen shot from em0ney, I know it works;
https://plus.google.com/u/0/photos/...6080647202194515042&oid=116366863869938231344
Hello everyone, most of you should know me by now.
I've been talking to @fatboyslimerr and it seems he and a lot of people are having random reboots.
I've created this thread as a discussion place to make it easy to coordinate the issues.
Known So Far about Random Reboots:
-Not Kernel Related apparently
-Issues appear when it goes into sleep mode
-Issues are appearing with wcnss_wlan.0, power.0, and alarm failing to suspend
-Issues are only (supposedly) appearing on CM-Based ROMS
Please post as many logs as possible and report the combinations where it's appearing
Thanks, javelinanddart
@Tamlins @waver1967 @letsurock @kudykam @amh.online @Auross are some of the people I believe that also had this reboot issue running various CM-based ROMs.
fatboyslimerr said:
@Tamlins @waver1967 @letsurock @kudykam @amh.online @Auross are some of the people I believe that also had this reboot issue running various CM-based ROMs.
Click to expand...
Click to collapse
Hi,
Yes I have it.
(sorry for my poor english)
I had it @ the begening of CM12 but the problems seemed to be corrected in some of last versions of CM12 (but I also changed 2-3 times Gapps)
The problem came back with 12.1. (with Gapps 5.1)
I'm not a dev, It's juste a feeling but are we sure that the problem not coming from Gapps ? Someone tryed to test with no Gapps installed at all ? (I can't do it for the moment)
Hboot 2.16
S-OFF
Cache/Dalvik cache wipe only
Regards,
Tamlin
Tamlins said:
Hi,
Yes I have it.
(sorry for my poor english)
I had it @ the begening of CM12 but the problems seemed to be corrected in some of last versions of CM12 (but I also changed 2-3 times Gapps)
The problem came back with 12.1. (with Gapps 5.1)
I'm not a dev, It's juste a feeling but are we sure that the problem not coming from Gapps ? Someone tryed to test with no Gapps installed at all ? (I can't do it for the moment)
Hboot 2.16
S-OFF
Cache/Dalvik cache wipe only
Regards,
Tamlin
Click to expand...
Click to collapse
It's a ROM issue, not gapps or kernel
For me, it used to reboot when charging the phone. Now I am on Euphoria 5.1.1 24-05-15 build. I didn't have any reboot in this build.
letsurock said:
For me, it used to reboot when charging the phone. Now I am on Euphoria 5.1.1 24-05-15 build. I didn't any reboot in this build.
Click to expand...
Click to collapse
Exactly the same problem : reboot when fully battery charged ! I'm on cyanid L 5.1.1 ROM.
I will do some tests with the setting tomorrow and i tell you if i find something interesting.
letsurock said:
For me, it used to reboot when charging the phone. Now I am on Euphoria 5.1.1 24-05-15 build. I didn't any reboot in this build.
Click to expand...
Click to collapse
Auross said:
Exactly the same problem : reboot when fully battery charged ! I'm on cyanid L 5.1.1 ROM.
I will do some tests with the setting tomorrow and i tell you if i find something interesting.
Click to expand...
Click to collapse
As far as I know Euphoria is not CM based, so maybe that's it. I know Cyanide for sure is.
Thanks for the feedback and please do run tests!
BTW, I have emailed @intervigil about this
I've been using CM from version 11 to 12.1.
I've alway seen random reboots and I still see some (1 to 3 times a day). Each time, it' GPS/gyro related. I use location services a lot: Ingress, Ware, Google Maps, Google location tracking, apps needing GPS for other usages. Each time I could diagnose it, the last lines of the last_kmg were about the Panasonic gyro kernel driver. It both happen while the screen is off and on, but it occurs more often while unlocking and turning on the phone/screen.
Since 12.1, I have random reboots while the phone is charging. This is new, and I did not take the time to diagnose this one, it always happened while I'm in bed trying to sleep, I don't want to get up I think it can be reproduced easily, just make it charge, in less than 2 hours it should occur.
I got a reboot whilst device was sleeping, not charging on Euphoria from 1st May.
The last_kmsg is here https://drive.google.com/open?id=0B7gvN7Z3xFy2V05zQ2VuYkwzMUU&authuser=0
Do you know if we can find any logs on the system which could explain some reboots or another troubles ?
Thanks
I just had a reboot while the phone was screen off in my pocket. I had been using Ingress so it might have tried to access GPS data. It was a full reboot with vibration and white HTC statup screen. That's why I guess it's a kernel bug.
Several info:
HBOOT 2.16
CM 12.1 2015-05-06 unofficial nightly built by F-L-Y-E-R
Radio 1.20
ext4 FS
Here are the last lines of /proc/kmesg:
Code:
[18001.475382] wakeup wake lock: bam_dmux_wakelock
[18001.480113] PM: early resume of devices complete after 4.120 msecs
[18001.482310] [BATT][BMS] cc_uah = 72241uAh, raw->cc = 102858d, cc = 16942477 after subtracting 0
[18001.482341] [BATT][BMS] pm8921_bms_resume: BMS_TOLERANCES=0x2f
[18001.484722] [USB] OTG PM resume
[18001.485179] [GSNR] Gsensor enable
[18001.485179] [GSNR][BMA250] BMA_set_mode: mode = 0x00
[18001.488659] [COMP][AKM8975] akm8975_resume: (m, a, t, mv) = (0x0, 0x0, 0x0, 0x0)
[18001.488689] [GYRO][PANASONIC] Gyro sys on on:g_status=0 off_status=0
[18001.488720] [GYRO][PANASONIC] GyroB sys off on:g_status=0 off_status=0
[18001.488750] [FLT]TPS tps61310_resume:
[18001.493054] msm_fb_ext_resume: Turning on HPD circuitry
[18001.493298] PM: resume of devices complete after 13.123 msecs
[18001.496106] [BATT] htc_battery_complete: sr_time_period=32959 ms; total passing time=168592 ms.htc_batt_info.state=0x2, batt_temp=374, sensor0_temp=0 at 18000998147051 (2015-05-11 12:06:23.003784523 UTC)
[18001.712709] Restarting tasks ... done.
[18001.742527] PM: suspend exit 2015-05-11 12:06:23.250197422 UTC
[18001.747746] suspend: exit suspend, ret = 0 (2015-05-11 12:06:23.255412362 UTC)
[18001.957024] [COMP][AKM8975] AKECS_GetOpenStatus:
[18002.228381] [GYRO][PANASONIC] EWTZMU2_GetOpenStatus:
[18003.479350] PM: suspend entry 2015-05-11 12:06:24.986408282 UTC
[18003.516188] Freezing user space processes ...
[18003.526138] [GYRO][PANASONIC] EWTZMU2_GetOpenStatus:wait OK
[18003.534165] (elapsed 0.009 seconds) done.
[18003.537278] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[18003.545823] Suspending console(s) (use no_console_suspend to debug)
[18003.553972] [BATT] htc_battery_prepare: passing time:170652 ms, alarm will be triggered after 3430 sec.(suspend_highfreq_check_reason=0x0, htc_batt_info.state=0x6), batt_temp=374, sensor0_temp=0 at 18003055387229 (2015-05-11 12:06:25.060994183 UTC)
[18003.555620] msm_fb_ext_suspend: Turning off HPD circuitry
[18003.559130] [FLT]TPS tps61310_suspend:
[18003.559130] [FLT]TPS flashlight_turn_off
[18003.559741] [GYRO][PANASONIC] Gyro sys off on:g_status=0 off_status=1
[18003.559771] [GYRO][PANASONIC] GyroB sys off on:g_status=0 off_status=1
[18003.559771] [GSNR] Gsensor disable
[18003.559771] [GSNR][BMA250] BMA_set_mode: mode = 0x01
[18003.576344] [USB] OTG PM suspend
[18003.609367] [BATT][BMS] cc_uah = 72410uAh, raw->cc = 1030269, cc = 16974441 after subtracting 0
[18003.609367] [BATT][BMS] pm8921_bms_suspend: BMS_TOLERANCES=0x2f
[18003.610740] PM: suspend of devices complete after 55.360 msecs
[18003.611564] PM: late suspend of devices complete after 0.823 msecs
[18003.612999] PM: noirq suspend of devices complete after 1.403 msecs
[18003.612999] Disabling non-boot CPUs ...
[18003.613457] msm_pm_enter
[18003.613457] msm_pm_enter: power collapse
[18003.613457] msm_mpm_irqs_detectable: cannot monitor 000000,00000000,00000000,00000000,00000000,00000000,00020000,00000000,00000000,00000000,00000000,00000000,00000000,00000000
[18003.613457] msm_pm_enter: return
[18003.614891] PM: noirq resume of devices complete after 1.312 msecs
[18003.615715] wakeup wake lock: bam_dmux_wakelock
[18003.616753] PM: early resume of devices complete after 0.762 msecs
[18003.618706] [BATT][BMS] cc_uah = 72855uAh, raw->cc = 10499d7, cc = 17078743 after subtracting 0
[18003.618706] [BATT][BMS] pm8921_bms_resume: BMS_TOLERANCES=0x2f
[18003.620079] [USB] OTG PM resume
[18003.620202] [GSNR] Gsensor enable
[18003.620202] [GSNR][BMA250] BMA_set_mode: mode = 0x00
[18003.623864] [COMP][AKM8975] akm8975_resume: (m, a, t, mv) = (0x0, 0x0, 0x0, 0x0)
[18003.623864] [GYRO][PANASONIC] Gyro sys on on:g_status=0 off_status=0
[18003.623864] [GYRO][PANASONIC] GyroB sys off on:g_status=0 off_status=0
[18003.623894] [FLT]TPS tps61310_resume:
[18003.625848] msm_fb_ext_resume: Turning on HPD circuitry
[18003.626092] PM: resume of devices complete after 9.308 msecs
[18003.628900] [BATT] htc_battery_complete: sr_time_period=121949 ms; total passing time=292601 ms.htc_batt_info.state=0x2, batt_temp=355, sensor0_temp=0 at 18003130309446 (2015-05-11 12:08:27.003479085 UTC)
[18003.845656] Restarting tasks ... done.
[18003.866684] PM: suspend exit 2015-05-11 12:08:27.241231020 UTC
[18003.880388] suspend: exit suspend, ret = 0 (2015-05-11 12:08:27.254953790 UTC)
[18004.062350] [COMP][AKM8975] AKECS_GetOpenStatus:
[18004.352935] [GYRO][PANASONIC] EWTZMU2_GetOpenStatus:
COMP is for compass and GYRO for the gyroscope.
Would it be possible for someone to build a kernel without the gyro driver so that I can use it during a few days for testing? And maybe also another one without the compass driver ?
kdd998 said:
I just had a reboot while the phone was screen off in my pocket. I had been using Ingress so it might have tried to access GPS data. It was a full reboot with vibration and white HTC statup screen. That's why I guess it's a kernel bug.
Several info:
HBOOT 2.16
CM 12.1 2015-05-06 unofficial nightly built by F-L-Y-E-R
Radio 1.20
ext4 FS
Here are the last lines of /proc/kmesg:
Code:
[18001.475382] wakeup wake lock: bam_dmux_wakelock
[18001.480113] PM: early resume of devices complete after 4.120 msecs
[18001.482310] [BATT][BMS] cc_uah = 72241uAh, raw->cc = 102858d, cc = 16942477 after subtracting 0
[18001.482341] [BATT][BMS] pm8921_bms_resume: BMS_TOLERANCES=0x2f
[18001.484722] [USB] OTG PM resume
[18001.485179] [GSNR] Gsensor enable
[18001.485179] [GSNR][BMA250] BMA_set_mode: mode = 0x00
[18001.488659] [COMP][AKM8975] akm8975_resume: (m, a, t, mv) = (0x0, 0x0, 0x0, 0x0)
[18001.488689] [GYRO][PANASONIC] Gyro sys on on:g_status=0 off_status=0
[18001.488720] [GYRO][PANASONIC] GyroB sys off on:g_status=0 off_status=0
[18001.488750] [FLT]TPS tps61310_resume:
[18001.493054] msm_fb_ext_resume: Turning on HPD circuitry
[18001.493298] PM: resume of devices complete after 13.123 msecs
[18001.496106] [BATT] htc_battery_complete: sr_time_period=32959 ms; total passing time=168592 ms.htc_batt_info.state=0x2, batt_temp=374, sensor0_temp=0 at 18000998147051 (2015-05-11 12:06:23.003784523 UTC)
[18001.712709] Restarting tasks ... done.
[18001.742527] PM: suspend exit 2015-05-11 12:06:23.250197422 UTC
[18001.747746] suspend: exit suspend, ret = 0 (2015-05-11 12:06:23.255412362 UTC)
[18001.957024] [COMP][AKM8975] AKECS_GetOpenStatus:
[18002.228381] [GYRO][PANASONIC] EWTZMU2_GetOpenStatus:
[18003.479350] PM: suspend entry 2015-05-11 12:06:24.986408282 UTC
[18003.516188] Freezing user space processes ...
[18003.526138] [GYRO][PANASONIC] EWTZMU2_GetOpenStatus:wait OK
[18003.534165] (elapsed 0.009 seconds) done.
[18003.537278] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[18003.545823] Suspending console(s) (use no_console_suspend to debug)
[18003.553972] [BATT] htc_battery_prepare: passing time:170652 ms, alarm will be triggered after 3430 sec.(suspend_highfreq_check_reason=0x0, htc_batt_info.state=0x6), batt_temp=374, sensor0_temp=0 at 18003055387229 (2015-05-11 12:06:25.060994183 UTC)
[18003.555620] msm_fb_ext_suspend: Turning off HPD circuitry
[18003.559130] [FLT]TPS tps61310_suspend:
[18003.559130] [FLT]TPS flashlight_turn_off
[18003.559741] [GYRO][PANASONIC] Gyro sys off on:g_status=0 off_status=1
[18003.559771] [GYRO][PANASONIC] GyroB sys off on:g_status=0 off_status=1
[18003.559771] [GSNR] Gsensor disable
[18003.559771] [GSNR][BMA250] BMA_set_mode: mode = 0x01
[18003.576344] [USB] OTG PM suspend
[18003.609367] [BATT][BMS] cc_uah = 72410uAh, raw->cc = 1030269, cc = 16974441 after subtracting 0
[18003.609367] [BATT][BMS] pm8921_bms_suspend: BMS_TOLERANCES=0x2f
[18003.610740] PM: suspend of devices complete after 55.360 msecs
[18003.611564] PM: late suspend of devices complete after 0.823 msecs
[18003.612999] PM: noirq suspend of devices complete after 1.403 msecs
[18003.612999] Disabling non-boot CPUs ...
[18003.613457] msm_pm_enter
[18003.613457] msm_pm_enter: power collapse
[18003.613457] msm_mpm_irqs_detectable: cannot monitor 000000,00000000,00000000,00000000,00000000,00000000,00020000,00000000,00000000,00000000,00000000,00000000,00000000,00000000
[18003.613457] msm_pm_enter: return
[18003.614891] PM: noirq resume of devices complete after 1.312 msecs
[18003.615715] wakeup wake lock: bam_dmux_wakelock
[18003.616753] PM: early resume of devices complete after 0.762 msecs
[18003.618706] [BATT][BMS] cc_uah = 72855uAh, raw->cc = 10499d7, cc = 17078743 after subtracting 0
[18003.618706] [BATT][BMS] pm8921_bms_resume: BMS_TOLERANCES=0x2f
[18003.620079] [USB] OTG PM resume
[18003.620202] [GSNR] Gsensor enable
[18003.620202] [GSNR][BMA250] BMA_set_mode: mode = 0x00
[18003.623864] [COMP][AKM8975] akm8975_resume: (m, a, t, mv) = (0x0, 0x0, 0x0, 0x0)
[18003.623864] [GYRO][PANASONIC] Gyro sys on on:g_status=0 off_status=0
[18003.623864] [GYRO][PANASONIC] GyroB sys off on:g_status=0 off_status=0
[18003.623894] [FLT]TPS tps61310_resume:
[18003.625848] msm_fb_ext_resume: Turning on HPD circuitry
[18003.626092] PM: resume of devices complete after 9.308 msecs
[18003.628900] [BATT] htc_battery_complete: sr_time_period=121949 ms; total passing time=292601 ms.htc_batt_info.state=0x2, batt_temp=355, sensor0_temp=0 at 18003130309446 (2015-05-11 12:08:27.003479085 UTC)
[18003.845656] Restarting tasks ... done.
[18003.866684] PM: suspend exit 2015-05-11 12:08:27.241231020 UTC
[18003.880388] suspend: exit suspend, ret = 0 (2015-05-11 12:08:27.254953790 UTC)
[18004.062350] [COMP][AKM8975] AKECS_GetOpenStatus:
[18004.352935] [GYRO][PANASONIC] EWTZMU2_GetOpenStatus:
COMP is for compass and GYRO for the gyroscope.
Would it be possible for someone to build a kernel without the gyro driver so that I can use it during a few days for testing? And maybe also another one without the compass driver ?
Click to expand...
Click to collapse
@intervigil confirmed this is a known CM bug that the Compass/Gyro causes reboots on Ville
This is a separate issue from the ROM side stuff @fatboyslimerr
I'll add this issue to the OP though thanks for reminding me
I'm waiting for @fatboyslimerr to confirm is a minor modification I made might've fixed Compass
javelinanddart said:
@intervigil confirmed this is a known CM bug that the Compass/Gyro causes reboots on Ville
This is a separate issue from the ROM side stuff @fatboyslimerr
I'll add this issue to the OP though thanks for reminding me
I'm waiting for @fatboyslimerr to confirm is a minor modification I made might've fixed Compass
Click to expand...
Click to collapse
Good news then
kdd998 said:
Good news then
Click to expand...
Click to collapse
Not fixed unfortunetely
javelinanddart said:
@intervigil confirmed this is a known CM bug that the Compass/Gyro causes reboots on Ville
This is a separate issue from the ROM side stuff @fatboyslimerr
I'll add this issue to the OP though thanks for reminding me
I'm waiting for @fatboyslimerr to confirm is a minor modification I made might've fixed Compass
Click to expand...
Click to collapse
That is a bug haunting Ville for ages...since long time ago users are reporting reboots while using maps or similar apps (I had it too several times in the past but now I'm not using maps/nav so often)
Sent from nowhere over the air...
Rapier said:
That is a bug haunting Ville for ages...since long time ago users are reporting reboots while using maps or similar apps (I had it too several times in the past but now I'm not using maps/nav so often)
Sent from nowhere over the air...
Click to expand...
Click to collapse
Yeah I heard from @intervigil
It's mostly compass apps
I've used Google Maps with no issues.
Unfortunately that's not the only issue
Phone seems to be rebooting when in deep sleep mode
Yep, still having reboots during sleep. Google maps does work fine, device gets seriously hot but it works fine. 3rd party compass apps cause reboots after awhile.
fatboyslimerr said:
Yep, still having reboots during sleep. Google maps does work fine, device gets seriously hot but it works fine. 3rd party compass apps cause reboots after awhile.
Click to expand...
Click to collapse
Device getting seriously hot is thermald issue
Why I used showp's thermal in a nutshell: Never had my ville not feel cold to the touch
Not that I have ville anymore ofc....
Since 2 days, I've been using cm12.1 nightly from the 15th. Now back on hboot 2.15 and last officially pushed (for international region) radio by HTC: 1.11.
I discovered the quick toggle for the compass and disabled its usage (it must be relatively recent). So far: not one reboot related to GPS
I had 2 reboots while setting up all my apps but didn't take the opportunity to get a logcat or kmesg. It did not occur since.
kdd998 said:
Since 2 days, I've been using cm12.1 nightly from the 15th. Now back on hboot 2.15 and last officially pushed (for international region) radio by HTC: 1.11.
I discovered the quick toggle for the compass and disabled its usage (it must be relatively recent). So far: not one reboot related to GPS
I had 2 reboots while setting up all my apps but didn't take the opportunity to get a logcat or kmesg. It did not occur since.
Click to expand...
Click to collapse
Sweet!
IDK about the apps thing