So I managed to get my Nexus working by enabling only the little cores, however, I would like to try to get the big cores working.
Here's the console-ramoops I pulled from my device: https://pastebin.com/ddinyPzz
The first major error relating to the BIG cpu (that I noticed), was at lines 317 and 318 "_cpu_up: attempt to bring up CPU 4 failed"
However, the fatal error seems to occur at lines 439-451. Multiple errors about pll_clk_enable occur, here's some lines that I noticed.
Line 440: "variable_rate_pll_clk_enable: PLL a57_pll1 didn't lock after enabling for L value 0x50!"
And then at line 451: "Kernel panic - not syncing: failed to lock a57_pll1 PLL" From that point on, the kernel appears to go through the shutdown process.
For those who don't know, the cortex-a57 cores are the ones that make up the BIG cpu.
I tried to do some research on what PLL was (disclaimer, I am no expert whatsoever, so what I say may be wrong)
From what I could find, the PLL stands for phase-locked loop, and it's purpose is to control the frequencies of a CPU.
Intel has a post on possible causes for PLL losing lock: https://www.altera.com/support/support-resources/operation-and-testing/pll-and-clock-management/pll-loss-lock.html
I did some digging around in the kernel source code, and there are entries for "pll_clk_disable" in the PLL driver https://android.googlesource.com/kernel/msm/+/android-msm-angler-3.10-o-preview-3/drivers/clk/qcom/clock-pll.c
So maybe this means there's a way to somehow disable PLL?
So if any Devs, or anyone with experience on this, have an idea on how to possibly fix this, please give your thoughts. This problem is a relatively prominent one in this device, and it would be awesome if we could fix it.
Here's my questions to anyone who knows more about this,
Would it be possible to disable PLL?
Is PLL hardware based, or software?
And would it be possible to somehow build a kernel to fix this problem?
Caveat: I'm a mechanical, not electrical engineer. Take this with a huge grain of salt.
Phase locked loops can't be "disabled". They are a very important, low-level aspect of modern electronics. As you point out it is useful for signal synchronization such as a CPU bus. They also have many important electronic components, the failure of any single one will result a cascade of failures. So basically, I think your logs just further suggest it is a fundamental hardware issue.
As a theoretical example (this is completely made up by the way, my own hypothetical amateur understanding): let's say a solder pad is broken on the CPU or tin whiskers formed on one of the two signals for which the PLL comparator is operating. One signal will be a nice sine wave, the other will be random noise. The comparator output will be random noise. So in this case, the "PLL lock failure" will indicate a broken solder joint.
As another theoretical example (this is completely made up, etc.): let's say the Voltage Controlled Oscillator circuit develops a non-monotinic output, which is described in the video as sometimes occurring. (I'll just say "silicon wear".) This would result in system instability at certain frequencies. Ergo, another hardware problem. (In this case, maybe downclocking the CPU would be a test? Do the Big cores operate at different frequencies at boot?)
All in all I think it's great you got it this far, and is brilliant work. Way to go. I hope (*cough*) Google considers signing a "hotfix" firmware image that implements your workaround, so that people with locked/stock bootloaders may possibly have the opportunity to fix their phones. I'll pass this on to Techno Bill, our firmware volunteer guy. He's the one who successfully argued for publishing signed Full OTA "Rescue images" way back when. I'll ping whomever I can, and keep my fingers crossed.
Here's some helpful references:
https://www.electronics-notes.com/articles/radio/pll-phase-locked-loop/tutorial-primer-basics.php
https://www.youtube.com/watch?v=A9qt0JYdvFU
TL;DR: Likely still a hardware problem. I am out of the loop (pardon the pun) on this topic, and am only a volunteer so my views are my own, etc. However I suspect Google was being honest about it from the get go.
If you have a bootlooping phone, the official line from volunteers like me is to call in and ask about Warranty Service.
XCnathan32 said:
So I managed to get my Nexus working by enabling only the little cores, however, I would like to try to get the big cores working.
Here's the console-ramoops I pulled from my device: https://pastebin.com/ddinyPzz
The first major error relating to the BIG cpu (that I noticed), was at lines 317 and 318 "_cpu_up: attempt to bring up CPU 4 failed"
However, the fatal error seems to occur at lines 439-451. Multiple errors about pll_clk_enable occur, here's some lines that I noticed.
Line 440: "variable_rate_pll_clk_enable: PLL a57_pll1 didn't lock after enabling for L value 0x50!"
And then at line 451: "Kernel panic - not syncing: failed to lock a57_pll1 PLL" From that point on, the kernel appears to go through the shutdown process.
For those who don't know, the cortex-a57 cores are the ones that make up the BIG cpu.
I tried to do some research on what PLL was (disclaimer, I am no expert whatsoever, so what I say may be wrong)
From what I could find, the PLL stands for phase-locked loop, and it's purpose is to control the frequencies of a CPU.
Intel has a post on possible causes for PLL losing lock: https://www.altera.com/support/supp...g/pll-and-clock-management/pll-loss-lock.html
I did some digging around in the kernel source code, and there are entries for "pll_clk_disable" in the PLL driver https://android.googlesource.com/ke...3.10-o-preview-3/drivers/clk/qcom/clock-pll.c
So maybe this means there's a way to somehow disable PLL?
So if any Devs, or anyone with experience on this, have an idea on how to possibly fix this, please give your thoughts. This problem is a relatively prominent one in this device, and it would be awesome if we could fix it.
Here's my questions to anyone who knows more about this,
Would it be possible to disable PLL?
Is PLL hardware based, or software?
And would it be possible to somehow build a kernel to fix this problem?
Click to expand...
Click to collapse
Hey man, do you have your current kernel tree online? I a) don't own the device and b) am no expert. However, I am a very resourceful kernel hacker, and working around the impossible is my specialty. Just looking at the clk driver from the same source you shared, I can see some glaring issues in online cpu refcounting. Also the logs lean closer to device tree/platform data errors than anything else. Though the following init sequences should definitely be checking for the population instead of just progressing based on trust. I would be happy to submit some patches if you have a build up
Sent from my Note 3 using XDA Labs
robcore said:
Hey man, do you have your current kernel tree online? I a) don't own the device and b) am no expert. However, I am a very resourceful kernel hacker, and working around the impossible is my specialty. Just looking at the clk driver from the same source you shared, I can see some glaring issues in online cpu refcounting. Also the logs lean closer to device tree/platform data errors than anything else. Though the following init sequences should definitely be checking for the population instead of just progressing based on trust. I would be happy to submit some patches if you have a build up
Sent from my Note 3 using XDA Labs
Click to expand...
Click to collapse
The nougat kernel source for the 6P is here, not sure if that's the same thing as a kernel tree, correct me if i'm wrong. Thanks for working on this!
Nathan-K said:
Caveat: I'm a mechanical, not electrical engineer. Take this with a huge grain of salt.
Phase locked loops can't be "disabled". They are a very important, low-level aspect of modern electronics. As you point out it is useful for signal synchronization such as a CPU bus. They also have many important electronic components, the failure of any single one will result a cascade of failures. So basically, I think your logs just further suggest it is a fundamental hardware issue.
As a theoretical example (this is completely made up by the way, my own hypothetical amateur understanding): let's say a solder pad is broken on the CPU or tin whiskers formed on one of the two signals for which the PLL comparator is operating. One signal will be a nice sine wave, the other will be random noise. The comparator output will be random noise. So in this case, the "PLL lock failure" will indicate a broken solder joint.
As another theoretical example (this is completely made up, etc.): let's say the Voltage Controlled Oscillator circuit develops a non-monotinic output, which is described in the video as sometimes occurring. (I'll just say "silicon wear".) This would result in system instability at certain frequencies. Ergo, another hardware problem. (In this case, maybe downclocking the CPU would be a test? Do the Big cores operate at different frequencies at boot?)
All in all I think it's great you got it this far, and is brilliant work. Way to go. I hope (*cough*) Google considers signing a "hotfix" firmware image that implements your workaround, so that people with locked/stock bootloaders may possibly have the opportunity to fix their phones. I'll pass this on to Techno Bill, our firmware volunteer guy. He's the one who successfully argued for publishing signed Full OTA "Rescue images" way back when. I'll ping whomever I can, and keep my fingers crossed.
Here's some helpful references:
https://www.electronics-notes.com/articles/radio/pll-phase-locked-loop/tutorial-primer-basics.php
https://www.youtube.com/watch?v=A9qt0JYdvFU
TL;DR: Likely still a hardware problem. I am out of the loop (pardon the pun) on this topic, and am only a volunteer so my views are my own, etc. However I suspect Google was being honest about it from the get go.
If you have a bootlooping phone, the official line from volunteers like me is to call in and ask about Warranty Service.
Click to expand...
Click to collapse
Ok that makes more sense, thanks for clearing that up. I do know that some people have said simply underclocking their big cores have worked, personally it didn't work for me, but maybe I just need to clock it lower, I'm not sure. Regardless, it shocks me how blatantly erroneous the Nexus 5X/6P devices are, and somehow, Google/Huawei/Qualcomm/LG haven't done anything to address or fix the problem, other than Google and Huawei getting into a pissing contest over who's fault it is.
XCnathan32 said:
The nougat kernel source for the 6P is here, not sure if that's the same thing as a kernel tree, correct me if i'm wrong. Thanks for working on this!
Click to expand...
Click to collapse
For sure, I meant moreso if you were working on a kernel personally for it
Sent from my Note 3 using XDA Labs
robcore said:
For sure, I meant moreso if you were working on a kernel personally for it
Click to expand...
Click to collapse
I'm thinking of working on a kernel to optimize it for using only the little cores, for now though, I'm just trying to get this fix out to as many devices as I can. Apparently Qualcomm 808/810 SOCs have tons of problems.
XCnathan32 said:
I'm thinking of working on a kernel to optimize it for using only the little cores, for now though, I'm just trying to get this fix out to as many devices as I can. Apparently Qualcomm 808/810 SOCs have tons of problems.
Click to expand...
Click to collapse
If you do, please reach out to me. Judging from your logs, the big cores aren't being found during initialization, and the other errors (pll, clocks) are from assuming that the cores are already registered with the driver. Now, given that the big cores have been identified as the culprit for the loops, maybe we could work on a custom solution to delay their initialization to a later initialization stage.
While upstreaming a legacy device of mine, I had to rewrite the Qualcomm cpufreq driver in order to make it register with the cpufreq core, and it was a learning experience that would be a pity to keep to myself!
robcore said:
If you do, please reach out to me. Judging from your logs, the big cores aren't being found during initialization, and the other errors (pll, clocks) are from assuming that the cores are already registered with the driver. Now, given that the big cores have been identified as the culprit for the loops, maybe we could work on a custom solution to delay their initialization to a later initialization stage.
While upstreaming a legacy device of mine, I had to rewrite the Qualcomm cpufreq driver in order to make it register with the cpufreq core, and it was a learning experience that would be a pity to keep to myself!
Click to expand...
Click to collapse
This sounds promising, it's weird though how devices would randomly bootloop, not even right after an update.
My thought would be that, being that this is clearly a hardware issue, would there be a way to track it to a specific core? Then simply disable -that- core, rather than disabling all "big cores" as they're being referred to.
I have minimal experience related to this, but that's just what's on my mind at the moment.
kronflux said:
My thought would be that, being that this is clearly a hardware issue, would there be a way to track it to a specific core? Then simply disable -that- core, rather than disabling all "big cores" as they're being referred to.
I have minimal experience related to this, but that's just what's on my mind at the moment.
Click to expand...
Click to collapse
The issue is hardly any specific core but rather kernel/driver related to the whole BIG cluster as specified above. I think that if there were any real production defects they would have noticed them by now.
I have a Sony Z5C, which uses the same SoC and has a similar issue but is nowhere near as severe. Our hotplugging is inefficient and the CPU readings and IRQs were botched. Until recently the only viable/stable CPU governor was interactive (even on custom kernels)... Anything else gave erroneous data, locked frequencies, deteriorated performance and didn't survive a reboot (or 10 minutes of use) without defaulting back to interactive. We don't have reboots or lockups or anything but the issue's still quite similar once you think about it.
Is there anyway to enable one core in big cluster? If only part of the big cluster is bad, we can isolate it and use the other cores.
Booting with one core at a time we can test which one is the problem.
Maybe we could disable the core or set freq to 0? Or voltage to 0.
Sent from my Nexus 6P using XDA-Developers Legacy app
Pineapplelaw said:
Is there anyway to enable one core in big cluster? If only part of the big cluster is bad, we can isolate it and use the other cores.
Booting with one core at a time we can test which one is the problem.
Maybe we could disable the core or set freq to 0? Or voltage to 0.
Click to expand...
Click to collapse
Look at my last post.
XCnathan32 said:
This sounds promising, it's weird though how devices would randomly bootloop, not even right after an update.
Click to expand...
Click to collapse
Strange? Yes. Workable? Perhaps!
Something tells me the hmp scheduling has been a largely failed experiment as well. As well, the Google/oem sources are far from perfect, and every device needs its own specific workarounds for these types of issues.
robcore said:
Strange? Yes. Workable? Perhaps!
Something tells me the hmp scheduling has been a largely failed experiment as well. As well, the Google/oem sources are far from perfect, and every device needs its own specific workarounds for these types of issues.
Click to expand...
Click to collapse
I'm seeing this error "msm_thermal:Failed reading node=/soc/qcom,msm-thermal" and CPU-z doesn't report any temps for my device whatsoever, is this universal for 6p's? Or is it another problem with the SoC?
Edit: Also seeing this error? (not sure if it is an error) come up a lot "(name of module/driver)0 <--> 0 mV" Do you think it's possible that the BIG CPUs are somehow not getting power?
@XCnathan32 see . / drivers / clk / qcom / clock-cpu-8994.c
The pll lock bit is defined as BIT(31), which is the MSB of register pll->status_reg.
On the log you posted, pll->status_reg is 0xca000100 with MSB set, this suggests the pll has locked by the time that debug message has set.
Conclusion: the cpu is not giving the pll enough time to lock.
Suggested possible solution: change line 53 in clock-pll.c from #define ENABLE_WAIT_MAX_LOOPS 200 to #define ENABLE_WAIT_MAX_LOOPS 100000 to give the pll 100ms to attempt a lock.
programmargorp said:
@XCnathan32 see . / drivers / clk / qcom / clock-cpu-8994.c
The pll lock bit is defined as BIT(31), which is the MSB of register pll->status_reg.
On the log you posted, pll->status_reg is 0xca000100 with MSB set, this suggests the pll has locked by the time that debug message has set.
Conclusion: the cpu is not giving the pll enough time to lock.
Suggested possible solution: change line 53 in clock-pll.c from #define ENABLE_WAIT_MAX_LOOPS 200 to #define ENABLE_WAIT_MAX_LOOPS 100000 to give the pll 100ms to attempt a lock.
Click to expand...
Click to collapse
Will try it.
programmargorp said:
@XCnathan32 see . / drivers / clk / qcom / clock-cpu-8994.c
The pll lock bit is defined as BIT(31), which is the MSB of register pll->status_reg.
On the log you posted, pll->status_reg is 0xca000100 with MSB set, this suggests the pll has locked by the time that debug message has set.
Conclusion: the cpu is not giving the pll enough time to lock.
Suggested possible solution: change line 53 in clock-pll.c from #define ENABLE_WAIT_MAX_LOOPS 200 to #define ENABLE_WAIT_MAX_LOOPS 100000 to give the pll 100ms to attempt a lock.
Click to expand...
Click to collapse
Just realized this, would I need to uncomment "#define"? Because I would think that line would be ignored when commented.
XCnathan32 said:
Just realized this, would I need to uncomment "#define"? Because I would think that line would be ignored when commented.
Click to expand...
Click to collapse
No no this is the proper way to define things for the c preprocessor!
Damn, I hope I'm not offending anyone but, I feel very sad that I don't have a broken 5x/6p (and my nexus 5 does not want to die) to work on this fix.
Will follow this thread and help with whatever I can (which is limited to some C programming and a few linux kernel builds...).
Good luck and congrats for this progress.
Related
Hi Guys,
I saw this on a foreign website. Not sure if this has been posted already.
[HKEY_LOCAL_MACHINE\Comm\AsyncMac1\Parms]
"DisablePowerManagement"=dword:1
Change to
"DisablePowerManagement"=dword:0
[HKEY_LOCAL_MACHINE\Comm\Irsir1\Parms]
"DisablePowerManagement"=dword:1
Change to
"DisablePowerManagement"=dword:0
[HKEY_LOCAL_MACHINE\Comm\PPTP1\Parms]
"DisablePowerManagement"=dword:1
Change to
"DisablePowerManagement"=dword:0
[HKEY_LOCAL_MACHINE\Comm\L2TP1\Parms]
"DisablePowerManagement"=dword:1
Change to
"DisablePowerManagement"=dword:0
This will turn on power management for the above protocols. Logically, it should save us some power. The orginal poster claims that there is a significant increment in his battery life .
I've applied this tweak to my SPV M3100, Hopefully this will save me more battery life.
N.B. please do a backup before applying this reg tweak just to be on the safe side.
Update: been using it for the few days and I must say I've noticed some improvement in Battery life. no other issues at the moment so far so good
What exactly are the above protocols? L2tp1, pptp1... what are those for? its not like that nokia tweak where it gives less power to the antenna?
Basicly is this tweak gonna cripple my device in any way?
fone_fanatic said:
What exactly are the above protocols? L2tp1, pptp1... what are those for? its not like that nokia tweak where it gives less power to the antenna?
Basicly is this tweak gonna cripple my device in any way?
Click to expand...
Click to collapse
The above mentioned protocols are used for VPN (Virtual Prvate Network).
fone_fanatic said:
Basicly is this tweak gonna cripple my device in any way?
Click to expand...
Click to collapse
I've made those registry changes to my TyTn. So far, I can find no bad side-effects.
software_samurai said:
I've made those registry changes to my TyTn. So far, I can find no bad side-effects.
Click to expand...
Click to collapse
no bad side-effects... but what about good?
shogunmark said:
no bad side-effects... but what about good?
Click to expand...
Click to collapse
Hmmm... Well, so far I think the battery life is a little better. But I need more time to really test it.
(Now that I've installed the Battery Status plugin, I can see the power usage, so I'll fiddle with these settings and see what happens to the numbers.)
gfreek said:
This will turn on power management for the above protocols. Logically, it should save us some power. The orginal poster claims that there is a significant increment in his battery life .
Click to expand...
Click to collapse
Thanks for posting.. but Like most random registry tweaks, I'd suggest not touching them for the following reasons:
They are not in the associated MSDN documentation for the reg keys. This is usually MS's way of saying 'this doesn't work right so we don't talk about it so no one thinks we support it'.
Second, the protocols it refers to are all network protocols that aren't generally in use by most people anyway and those that do wouldn't have vpn's running 24/7 therefore any power savings would be minimal.
Thirdly, they were purposely disabled for some reason. I assume because there is a problem with them. And my device is unstable enough
Just my 0.02c
FYI: My test results
In my admittedly objected tests (I changed those settings, soft-rebooted, and then watched the batter drain number for a few minutes), it looked as though enabling the power management for those 4 settings brought the batter drain down a little faster then with them disabled. When they were disabled, it took several minutes for the battery drain to drop down to about 90mA. When they were enabled, the batter drain dropped down to 90mA within about 2 minutes. However, in both cases, the battery drain seemed to bottom out at about 88mA after a while (actually, right after the backlight went into power-saving mode). So I can't say these settings would save a "significant" about of power. YMMV.
icemantwilight said:
Thanks for posting.. but Like most random registry tweaks, I'd suggest not touching them for the following reasons:
They are not in the associated MSDN documentation for the reg keys. This is usually MS's way of saying 'this doesn't work right so we don't talk about it so no one thinks we support it'.
Second, the protocols it refers to are all network protocols that aren't generally in use by most people anyway and those that do wouldn't have vpn's running 24/7 therefore any power savings would be minimal.
Thirdly, they were purposely disabled for some reason. I assume because there is a problem with them. And my device is unstable enough
Just my 0.02c
Click to expand...
Click to collapse
If it's not supported, I can understand it. But, I've found with my Wizard, and now my Hermes, that just because it's disabled, doesn't mean it isn't useable. I've found a variety of registry keys that I love tinkering with. That isn't one of them thankfully, but some of the things that they disable there aren't any problems that I've seen, so therefore I add them back in.
A good example is that "Wireless" today plug in. Sure, it really doesn't server a whole lot of purpose, but I like it, so I put it back in.
Much of it is in the eye of the beholder. N00bs probably shouldn't do some of this stuff. Then again, if it weren't for our curiousity, we'd never make any progress hacking these devices...
icemantwilight said:
Thanks for posting.. but Like most random registry tweaks, I'd suggest not touching them for the following reasons:
They are not in the associated MSDN documentation for the reg keys. This is usually MS's way of saying 'this doesn't work right so we don't talk about it so no one thinks we support it'.
Second, the protocols it refers to are all network protocols that aren't generally in use by most people anyway and those that do wouldn't have vpn's running 24/7 therefore any power savings would be minimal.
Thirdly, they were purposely disabled for some reason. I assume because there is a problem with them. And my device is unstable enough
Just my 0.02c
Click to expand...
Click to collapse
This wouldnt be the right forum if noone would investigate any kind of improvement (or at least finding out if it does anything, positive or negative)
I we would go for what MS suggests or covers in their docs, we wouldnt flash roms, apply MUIs or anything in that regard.
After all this site is called XDA-Developers and playing around with tools, tweaks and sharing knowledge is what this is about.
So far i cannot see any change in battery life. I will give it a few more test.
if there is a way that we could scale the processor based on the processing requirements, then we will always consume optimal power... something similar to speed-step intel has on PC's.
from what I know for this to be possible, the CPU has to have dynamic voltage scaling, meaning that when the processing load is reduced, the core voltage of the cpu reduces yielding reduced clock frequency. when more isntructions need be executed, the voltage supply to the CPU core will increase, hence increasing clock frequency.
has anyone read the documentation in regards to the architecture of the samsung CPU? if it supports dynamic voltages scaling, and if it is wired up to a dynamic voltage source, then there could be some tweak to enable such a feature.
I've had the pleasure of reading the Samsung CPU manual. You should too!
It doesn't support much clock speed scaling - ie you can't easily overclock (and even then, not by anything of signficance). Voltage scaling is possible. Look into Pocket Hack Master.
V
vijay555 said:
I've had the pleasure of reading the Samsung CPU manual. You should too!
It doesn't support much clock speed scaling - ie you can't easily overclock (and even then, not by anything of signficance). Voltage scaling is possible. Look into Pocket Hack Master.
V
Click to expand...
Click to collapse
if the core CPU voltage can be scaled, then we instantly have a scaled clock frequency. there is a direct relationship between power dissipation in CMOS semiconductors, clock frequency, supply voltage, capacitance and probability if switching (ie dynamic clocking).
Here is an interesting read for you softeare hackers out there. it is a project ot implement dynamic voltage scaling on pda's for those that have CPU with fine grian dynamic voltage scaling. the work is on linux os on a pda, but the methodology should be the same.
http://www.eecg.toronto.edu/~tamda/csc2228/
Dynamic voltage scaling doesnt imply that we can overclock the device, but instead keep the CPU running at a speed that is ample for the processing that it is doing, ie, dynamic. so if there are no apps runing besides an idle today screen, why keep the CPU at 400MHZ running at its full voltage supply. lets reduce it to an amount that it enought to handle the performance requirements of having an idle today screen BY reducing the supply voltage.
Dynamic voltage scaling is basically an algorith (if the hardwre is there) that can be implemented at the CPU level or OS level to monitor instructions required per second etc, then adjusts the CPU core suply voltage accordingly. So in effect, we can get our devices running from 10MHz (doing nothing and consuming little power - I am sure this is the case 70% of the time) to 400MHZ (running apps, GPS, video streaming etc - and consume more power)
I have a PhD student doing his thesis on dynamic voltage scaling for mobile medical devices and the philosophy is "do (process) only what you have to do (process)"
EDIT: Just looked into pocket hack master, it does some kind of clock scaling, well, I learn new things everyday, this is my first PPC and its overwhelming.
vijay,
what is the model number of the samsung CPU in the hermes? i cant seem ti find it?
EDIT: I found it, Samsung K5D5657ACA-D090, it seems voltage scaling is not supported by pocket hack master, that app supports the samsung ric micr S3C24XX series in which the S3C24A0 has a max clock of 200MHz running of a 1.2V supply
also you may want to be careful with Pocket Hack Master.. some people have reported it completely bricking their device. I had it installed it hours before my phone died, but i dont know if it was the cause due to a high amount of irregular bad blocks that werent there when i got the phone.
shogunmark said:
also you may want to be careful with Pocket Hack Master.. some people have reported it completely bricking their device. I had it installed it hours before my phone died, but i dont know if it was the cause due to a high amount of irregular bad blocks that werent there when i got the phone.
Click to expand...
Click to collapse
I dont trust it, it doesnt support our samsung CPU in terms of voltage scaling and by simply scaling the processor frequency isnt really going to accomplish much of an energy saving in terms of the big picture. by big picture i mean with respect to LCD screen energy consumption, GSM radio and UMTS radios (all of which use separate LNA's for each of the Centre Frequency bands) BT etc....
This trick, run on wm 6.5 ?
The main thing I'm concerned about here is the time it takes to charge the phone.
What it seems like is happening is that the phone won't underclock like it did before froyo and it stays up above 500-600 mhz instead of much, much lower in the 200-300 range.
Can anyone tell me if I'm way off on this?
If I'm not, is there a way to test and see at which speed the processor is running, especially in standby?
Then, is there anything that can be done about this, or do we have to wait for the source code to be released and then for custom kernels to be developed that can help the phone be more energy efficient when charging.
Thanks
You could use Set CPU to limit the processor speed while the screen is off or charging.
My only concern with doing that is that when a task needs to be performed it would take alot longer to do it, and erase any positive effect of underclocking that way.
Does anyone know if this is a valid or known issue? Is anyone else seeing the same issue or know why its happening? Just looking for more info on this.
Kind of off topic, but does setCPU work with the latest leak of Froyo?
Sent from my ADR6300 using XDA App
I just have a setCPU profile set to 245/245 while screen off. Doesn't seem to affect anything in a negative way. SetCPU should work as long as your phone is rooted. Select "Autodetect" in device selection. Moving this to General with a redirect expiring in one month.
Keep in mind that underclocking will not work unless you disable the perflock. In setcpu, hit menu to do so. Its only per boot.
adrynalyne said:
Keep in mind that underclocking will not work unless you disable the perflock. In setcpu, hit menu to do so. Its only per boot.
Click to expand...
Click to collapse
thanks for the tip.. so I guess I'll have to disable perflock every time I reboot.. sigh..
Also, what does the "set to boot" check/uncheck option do?
You can set your default speeds with that option on boot. However, it will only work on perflock disabled kernels, and I haven't found a way to disable it in the stock kernel. Easy enough from source, but once its compiled, its a lot tougher, if not impossible.
I guess I don't want to deprive the device of it's full potential by underclocking it especially when I am using it... the processor speed being one of the main reasons why this phone stood out for me back then..
However, I do have the processor speed dip down to 245max/min when screen is off.. I think that should help with battery quite a bit yea? Also with the 245 max/min profile when screen is off.. I guess there is no need for an app killer anymore.
Thats what I am doing as well and the results have been promising. Just wish the perflock disable was permanent
I requested it as a feature in the dev thread, but I don't know if he will add it.
Seems to me he just needs to insmod the module that disables the perflock at the same time speeds are set with the at boot time option.
Not that I know anything about programming.
Ahh yes...forgot about the perflock on your Sense devices.
My understanding was having to do the perflock each time was intentional. Since it has a chance of crashing your phone, if it was permanent it would cause a permanent unrecoverable loop or something to that effect.
But I know nothing about programming either (WAY less than adrynalyne that's for sure), just remember reading that somewhere on the forums.
Didn't really intend for this thread to become a setCPU discussion, but got some good info out of it.
Was mainly trying to figure out WHY group doesn't seem to undertook natively and id there is a possible fix out there or at least looming.
That said. I'll be getting to a charger in a few minutes and anxious to see if this helps me with the charging issue as is seems to have with others.
s197 said:
My understanding was having to do the perflock each time was intentional. Since it has a chance of crashing your phone, if it was permanent it would cause a permanent unrecoverable loop or something to that effect.
But I know nothing about programming either (WAY less than adrynalyne that's for sure), just remember reading that somewhere on the forums.
Click to expand...
Click to collapse
Its true thats why it has been set up that way, and Im sure the dev did that for support reasons too.
Anything is recoverable though
Maybe the dev could add a secret geek code to unlock it for those of us who are stupid and wreckless
[Complete rewrite 26/10]
I'm writing this since the abundant misinformation about it coming across many many threads, and all other Android OS threads are too big and real information is easy to overlook.
After several weeks of analyzing and monitoring of the behavior of the device, things are starting to clear up and we can come to a conclusion.
What's the Android OS usage?
Many have noticed that on our Galaxy S2's and various other variations (Epic 4G Touch, etc) that in the Android battery stats the Android OS entry is supposedly eating away a large percentage of the battery used.
{
"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"
}
There's been many threads old and new discussing it and theorizing and many users magically fixing it by doing god knows what changes.
The Android OS package is a bundle of processes, in this case, all root processes used by the system kernel. Please remember this when continuing to read on, as there is much more to it than meets the eye and only once specific aspect of the whole story will be treated.
A diagnosis of the main problem:
Download [APP] BetterBatteryStats adds battery history back to Gingerbread. It is your #1 friend on finding out what uses up CPU power and causes problems.
Note: The CPU time in BetterBatteryStats is normalized, meaning 100% load during full frequency for a minute will show up as 1 minute CPU time, 100% load at half-frequency for a minute will show 30 seconds CPU time. Keep this in mind when monitoring processes. The CPU time shown in the Android battery stats is useless.
As you can see in the screenshot, "suspend" and "events/0" pop up as the big consumers of CPU power. Red means it's a system/kernel process and blue means it's a user process.
The suspend process is the program that's in charge of telling the hardware to go into deep sleep mode and reawaken from it.
The events/0 is just the general events manager for the system kernel.
You can monitor this with Watchdog Task Manager. Set it up so that it monitors system processes and raises notifications. Depending on the severity of the bug at the time and some black magic, you'll see the 99% load on the system.
Due to how the hardware of the phone is designed, the default kernel settings of the phone lock its frequency to 800MHz before falling into deep sleep. This is believed to be one of the main problems as to why so much battery is drained. Compared to other the devices the Exynos 4210 in our Galaxy S2's takes a much longer time to enter deep sleep (suspend) and wake up again from sleep (resume). This can be seen in the device message logs:
<6>[ 749.242666] PM: suspend of devices complete after 171.413 msecs
<6>[ 749.250855] PM: late suspend of devices complete after 0.396 msecs
<4>[ 749.250864] Disabling non-boot CPUs ...
<7>[ 749.250909] s3c_pm_enter(3)
<7>[ 749.250916] s3c_sleep_save_phys=0x40d9fe80
<7>[ 749.250959] sleep: irq wakeup masks: 000fffdd,cb37b97f
<6>[ 0.000000] WAKEUP_STAT: 0x80000001
<6>[ 0.000000] WAKUP_INT0_PEND: 0x80
<6>[ 0.000000] WAKUP_INT1_PEND: 0x0
<6>[ 0.000000] WAKUP_INT2_PEND: 0x0
<6>[ 0.000000] WAKUP_INT3_PEND: 0x0
<7>[ 0.000000] s3c_pm_enter: post sleep, preparing to return
<7>[ 0.000000] S3C PM Resume (post-restore)
<7>[ 0.000000] Wakeup from sleep, 0x80000001
<6>[ 0.000000] L310 cache controller enabled
<6>[ 0.000000] l2x0: 16 ways, CACHE_ID 0x4100c4c5, AUX_CTRL 0x7e470001, Cache Size: 1048576 B
<6>[ 749.251252] PM: early resume of devices complete after 0.255 msecs
..
..
<6>[ 749.748189] PM: resume of devices complete after 496.599 msecsThe fact that these operations are done at a higher frequency, together with the fact that a suspend-wake cycle takes around anything from 0.6 to 0.8 seconds, while doing nothing else, will drain more power than actually needed.
The screenshot on the right is a period of 15 minutes where the processes were bugged, the timers in CPU Spy were reset, and the screen immediately turned off to collect the statistics. A screen-off profile was used to limit the maximum frequency to 200MHz, so theoretically any standard process is not allowed to use any of the frequency-states above that. Nevertheless, There you can see the device being in the 800MHz state for roughly half the time. This means that half the time the device is spending on being awake is being wasted on just entering and leaving the deep sleep state.
Note: The deep sleep state is a state in which the CPU isn't clocked anymore and caches are no longer kept coherent, basically it's turning off most of the CPU, and thus conserving a lot of power.
What's the cause of high Android OS usage?
This is where things get interesting.
Network usage
The most common cause of the device waking up often enough to cause a problem and raise the suspend process up, and thus also the AOS usage, are incoming and outgoing network traffic. These will be attributed to the operating system rather than the service or application at cause of the problem.
Wild wakelocks
Second most common cause are high-frequency wakelocks caused by some application or service. Refer to the next section for this topic.
Incorrect statistical interpretation
One has to keep in mind that when generating the percentages shown under the battery stats in Android, that those values are just an estimate. The ROM has a file called power_profile.xml in which power drain values for different uses are listed. These values are coming from Samsung. For example, the CPU running at 1200MHz is listed as using 577mAh of power, so when a task is running for 10 seconds at 1200MHz, then it means that that process will be getting attributed a power consumption of 1602µAh (577mAh/3600s *10s). ASOP ROMs like MIUI will actually list these values in the battery stats. Each entry in the battery usage as such has an estimated power consumption value, and out of which the percentages are calculated from.
The problem is, that these are all just estimates and wether they are calculated correctly is up to debate. There are issues if either dual core use is taken into account in these estimates, or not, and even if the values provided by power_profile.xml are representative of real use or not. One issue for certain is that power consumption will be wrong for people who underclock/overclock, and undervolting. There are no entries for states above 1200MHz or below 200MHz, and the ones already present are meant to be representative of default/stock voltages. If you're running 100MHz in idle, the system will use the 200MHz estimates and thus overestimate your power consumption, if you're overclocking and using 1400MHz for example, the system will underestimate your power consumption.
This part is also what causes kernels which claim to fix the problem to be nothing but red herrings: somewhere in the patching of the kernels to 2.6.35.12 there is a change which makes the whole suspend and wakeup process no longer visible to the system and thus is no longer registered. Because of that, there are no statistics of these and the drain can not be calculated. Tests have shown that this is nothing other than just hiding of the problem rather than a tangible fix.
What you can do:
First of all you need to find the cause of the problem; study your wakelocks. You can do this by using BBS as mentioned above but this will only show part of the story as it will not tell you about system wakelocks, but only user wakelocks. If there is no obvious villain listed there, then you must do some more advanced troubleshooting:
Dump your wakelocks file using a terminal or over ADB if you are familiar with it, as follows:
cat /proc/wakelocks > /sdcard/wakelocks.csvTo read this data you need to import it into a spreadsheet application like Excel or OpenOffice and you'll end up getting something like this: (Read the thread around here on how to format your spreadsheet)
You need to mainly look for high-duration wakelocks, and the wake_count frequency, meaning how often your device has woken up.
While this is all a bit advanced and all, you can do it simpler:
Avoid using application and services that use a permanent internet connections. Avoid using applications which use polling for their connectivity and instead use those who support C2DM push-notifications. This will vastly increase your battery life by vastly decreasing network traffic. If this all doesn't help, try doing a network analysis (packet capture) to inspect the source of it, please refer to discussions later in the thread for this.
What your device can be capable of:
In the first screenshot you can see two periods of around 18 hours where the battery drain is relatively flat. In this period the suspend process gained merely a few seconds of CPU time. Then I use the phone for a bit, it goes haywire, and then calms down again and then starts draining again. You can see this in the step-wise drain in the curve. It should be smooth and not like that.
In the second screenshot it's after a full charge where it didn't trigger for 8 hours. My battery is perfectly calibrated so those are real 4% of battery. So if things were to go smoothly on the software part then the phone is idling at around 0.4% of battery per hour on Wifi, and other people have been reporting down to 0.8% or even less with a good 3G signal.
Left side: low network usage, how it should be; Right side: high network usage, how it behaves sometimes in severe cases.
Same network, same location, same signal strength, same ROM (Changing my font maybe fixed it....) , same wakelocks between them, same background apps running. Not even 5 minutes screen time on the two. The only difference with .14 patched kernels I'm experiencing is that it's not showing up anymore in the stats, but it drains just as much as in the right screen, showing the same CPU state behavior. It's also happening less often, and many say it's not happening at all anymore, but how would they know it it's hidden now?
"tvout resume wo"
One might have noticed the high usage of the "tvout resume wo" (wo = work, btw) in BetterBatteryStats. This is part of the TVOut functionality/driver, and it seems that every time the CPU resumes it goes through this work wether you use TVOut or not. Due it being a kernel process it's also part of adding up to the Android OS package usage. If you are suffering from high frequency wakeups, then this will also go up as system routines for this functionality are called every time the device wakes up.
<6>[ 749.251252] PM: early resume of devices complete after 0.255 msecs
<3>[ 749.251350] [MHL]mhl_int_irq_handler() is called
Last words
The device is still superb. Even with this bug the battery is equivalent to many other high-end devices out there. The thing is, it could be much better. If you want to squeeze out most of your device read on the discussions in this thread to try to find out what's keeping the phone from wasting power. Forward this to people so they're informed and aware of it.
I really appreciate all the effort you've put into researching this!
AndreiLux said:
Summarized quick-facts:
It's caused by a bug in the drivers.
Click to expand...
Click to collapse
While I certainly do believe this, what leads you to believe it is a driver issue? And what particular driver have you found is the culprit?
AndreiLux said:
We can just hope that Samsung will fix this issue soon. For all we know they're aware of it and are working on it. The original Galaxy S had this very same issue and it has been supposedly fixed in a firmware update earlier this year. The Galaxy S2 is not the only phone having this issue, but it's the one that has it guaranteed most of the time.
Click to expand...
Click to collapse
I know that the 2.3.4 update for the original GX2 was supposed to have fixed this exact bug. You're saying that it is not in fact fixed? Shouldn't Samsung be alerted to this blunder?
AndreiLux said:
What your device would be capable of.
In the first screenshot you can see two periods of around 18 hours where the battery drain is relatively flat. In this period the suspend process gained merely a few seconds of CPU time. Then I use the phone for a bit, it goes haywire, and then calms down again and then starts draining again. You can see this in the step-wise drain in the curve. It should be smooth and not like that.
In the second screenshot it's after a full charge where it didn't trigger for 8 hours. My battery is perfectly calibrated so those are real 4% of battery. So if things were to go smoothly on the software part then the phone is idling at around 0.4% of battery per hour on Wifi, and other people have been reporting down to 0.8% or even less with a good 3G signal.
Basically Android OS should not be even showing up in the battery stats, like on many other devices. Lowest people are getting on the Galaxy S2 is about 5-10%. There's also some other issues like high usage of "tvout resume wo", but that's something irrelevant compared to the elephant in the room that is "suspend" & "events/0".
Click to expand...
Click to collapse
So you're saying it was just dumb luck and you happened to not trigger the bug? So this could account for people finding "solutions," but they were only coincidental of the bug randomly not manifesting itself?
Very weell explained.
As far as the first SGS, I can confirm that the bug was solved from the first 2.3.4.
I was experiencing a fantastic battery life with my SGS, and I was quite shocked when I had to watch helpless as Android OS went up on the S2.
That was a fantastic explanation. It does explain the vast difference in AOS between my Nexus S and SGSII. Hope this thread gets pinned to help put away the vast number of AOS threads present. And hopefully it'll help get more people to star the issue and get it the attention it badly needs!
xak944 said:
While I certainly do believe this, what leads you to believe it is a driver issue? And what particular driver have you found is the culprit?
Click to expand...
Click to collapse
It's been confirmed by a Samsung person on the original Galaxy S where it had the very same issue. Which driver exactly it is, I don't know. Supposedly it was the Wifi-driver but the bug also happens to some extent without Wifi, so I don't know. If you want you're welcome to go through 120MB of kernel source code to find the issue and change it.
xak944 said:
I know that the 2.3.4 update for the original GX2 was supposed to have fixed this exact bug. You're saying that it is not in fact fixed? Shouldn't Samsung be alerted to this blunder?
Click to expand...
Click to collapse
Look. There's Android, and then there's a complete phone firmware. People tend to call firmware versions by the Android version they're on. Android version itself is completely meaningless and it's not Google's job to fix this, the manufacturers are the ones who deliver the drivers and everything that makes Android run on the phone. There's been for example about 8 leaked firmware versions for 2.3.4 on the Galaxy S2.
xak944 said:
So you're saying it was just dumb luck and you happened to not trigger the bug? So this could account for people finding "solutions," but they were only coincidental of the bug randomly not manifesting itself?
Click to expand...
Click to collapse
Yes. Go wave a dead chicken over the phone and practice voodoo magic on it and you'll be just as successful at changing the behavior. The issue goes way too deep for the user to have any reproducible impact on it.
Thanks for great explanation and having a bit more light on the issue. I'm going to star those as soon as it goes off maintenance.
Good post thanks for your research.
AndreiLux said:
It's been confirmed by a Samsung person on the original Galaxy S where it had the very same issue.
Click to expand...
Click to collapse
Was this in a support case you opened with Samsung? A forum? Where and how?
AndreiLux said:
Look. There's Android, and then there's a complete phone firmware. People tend to call firmware versions by the Android version they're on. Android version itself is completely meaningless and it's not Google's job to fix this, the manufacturers are the ones who deliver the drivers and everything that makes Android run on the phone. There's been for example about 8 leaked firmware versions for 2.3.4 on the Galaxy S2.
Click to expand...
Click to collapse
Then why are we flagging the issues on the Android project? Shouldn't we be hammering on Samsung support channels for a fix if the problem is located in their proprietary drivers?
xak944 said:
Was this in a support case you opened with Samsung? A forum? Where and how?
Click to expand...
Click to collapse
Galaxy S XDA thread ; post in question ; response by Todd who is a Google employee.
xak944 said:
Then why are we flagging the issues on the Android project? Shouldn't we be hammering on Samsung support channels for a fix if the problem is located in their proprietary drivers?
Click to expand...
Click to collapse
You're more than welcome to show me the proper non-Korean Samsung channels. You're the one who said in big bold red letters to flag it to Google. In any way, Google forwards big issues directly to the manufacturers themselves.
AndreiLux said:
Galaxy S XDA thread ; post in question ; response by Todd who is a Google employee.
Click to expand...
Click to collapse
Oh good grief. We've really gone full circle now. That entire thread claims it was fixed in 2.3.4!
AndreiLux said:
You're the one who said in big bold red letters to flag it to Google.
Click to expand...
Click to collapse
Yeah, you're right. I should've done my own research and not assumed you knew what you were talking about.
AndreiLux said:
You're more than welcome to show me the proper non-Korean Samsung channels
Click to expand...
Click to collapse
http://www.samsung.com/us/SUPPORT/
http://twitter.com/SamsungSupport
http://facebook.com/SamsungSupport
Very good post probably the best on the subject to date.
Personally running 2.3.5 i don't find it as bad but there can be no denying the problem is still there and until Samsung sort it out it will continue to be there.
xak944 said:
Oh good grief. We've really gone full circle now. That entire thread claims it was fixed in 2.3.4!
Click to expand...
Click to collapse
It was... for the Galaxy S, we're on another phone. XXJVP fixed it, not 2.3.4. I said it earlier, firmware version != Android version.
xak944 said:
http://www.samsung.com/us/SUPPORT/
http://twitter.com/SamsungSupport
http://facebook.com/SamsungSupport
Click to expand...
Click to collapse
Well I'm not that stupid and have been that far myself. The US site doesn't even let me select my model because it doesn't officially exist there, and the international site where I'm rerouted to doesn't even have a report feature and the only contact is a phone number. And I'm not going to start FB'ing or Twittering about driver issues to a mega-conglomerate coorporation, I'll leave others to do that. Hardly a "proper" tech support channel as Google Code. Only the Korean site has that, but sadly, I can't speak Korean.
Thanks for the research.
Lets all star this so we cant get it to Samsung and they can fix this ASAP.
Great post. Lots of people are talking about battery life but without understanding how the stats work and how to interpret them.
The battery usage screenshot is funny though. Yeah, I understand it shouldn't have those steep fall-offs. But still, must be pretty nice to have 40% battery left after 2.5 days!
Thanks for your explanation, I often wondered what the android os bug was and now I know. I'm quite fortunate by the sound of things my android os is usually around 15%. Is this issue likely to be resolved with ICS?
Sent from my GT-I9100 using Tapatalk
Here's what I don't get. I've had the phone since week one back in may and from may to September - no os bug. So why now? Have I done something to trigger it? Can we isolate the cause to prevent others getting it? I can list what I've done different recently to previous months if it helps?
And if it's drivers then why doesn't it access the CPU when the charger is plugged in?
I share everyone's frustration over all this.
Sent from my GT-I9100 using XDA App
We have the same problem on the US Galaxy S II/Sprint Epic 4G Touch :\
This thread should be stickied!
Shafty said:
Here's what I don't get. I've had the phone since week one back in may and from may to September - no os bug. So why now? Have I done something to trigger it? Can we isolate the cause to prevent others getting it? I can list what I've done different recently to previous months if it helps?
Sent from my GT-I9100 using XDA App
Click to expand...
Click to collapse
I have no idea.
I've tried it on half a dozen ROMs, wiped everything clear, removed every app to the point of the ROM being pretty naked, and still didn't get to change it. There's a lot of people like you who say they don't have the bug and suddenly have it. It may be a hardware fault that doesn't trigger until some certain circumstances are fulfilled. Maybe it's just some stupid bug in the drivers and it's some synchronization problem between registers. It may be cosmic rays who change a bit in the memory. Who the **** knows.
All I know is that nobody has been able to isolate it to any common cause, and I sure haven't managed in the last 3 months, and I've had it since July myself. At the same time you ask yourself why there's such a wide variety of devices having the same issue, but different hardware. If I would be paid full time to look through the source code and find the bug then I'd do it. But until then, I just wanted to share it with everybody and just tell them to stop wasting their time.
Shafty said:
And if it's drivers then why doesn't it access the CPU when the charger is plugged in?
Click to expand...
Click to collapse
Because when the device is plugged in then a wakelock is active and the device doesn't go to deep sleep at all. Since the going to deep sleep process is what is bugging, then wakelocking it prevents it from bugging out. I mentioned this already in the post. Since you have MIUI, you can for example tell it in the battery setting to not go to deep sleep at all (there's a checkbox), and see the results for yourself.
I'll just say i got my SGS2 recently and it came with 2.3.4 - there was no AOS bug at first then oneday started noticing it. I upgraded to 2.3.5 via XXKI3 and it's better as it's "only" 11% now rather than 29-40%.
Guess i should check with CPUspy to see if the phone is actually deep sleeping - I would however assume so as it's been getting better battery life since i upgrading to 2.3.5.
Hi everyone,
Thanks for reading this . As specified above, my phone has a rather serious problem of overheating. To try and reslove the issue I tried modifying the CPU frequency, to set it low enough. And a very bizarre thing just happend.
Opening Kernel Adiutor, I saw that 4 out of my 8 cores (the 2.5 ones) were running normally. No overclock, stock settings, stock governor and so on. The issue seems to be in the other 4 (the 2.3 ones). Both the minimum and highest frequency allowed is set up to the same parameter (1556 mHz), forcing it to stay at maximum clock all the time. I tried modyfing via Kernel Adiutor the settings, lowering the minimum frequency allowed to stock one (which should be around 300 or something), but it had no effects: it immediatly comes back to 1556 and just won't come down.
All of this started happening after i removed Franco Kernel from my system, flashing another ROM (Chroma) with a different kernel altogether. I'm currently on Cataclysm ROM and after doing a clean install, formatting internal storage as well as every other partition, i couldn't resolve the issue. Moreover, Kernel Adiutor sometimes won't even show my CPU settings, stuck on an infinite loading. If anyone could help me, it would be much appreciated. It's really important. I'm by no means Android expert but i do have a rather basic understanding of ADB and so on.
Thanks a lot for your time.
-LVBNR5
I used to own a n7 and that allowed me to set min and max freq. with apps fine but i am also seeing this on my 6p, i don't notice any "overheating" although it may be due to me being used to it always running hot since i run a lot of heavier programs and also you know... SD810 but i guess it does the frequency thing as a way that frequency is actually controlled on this platform or something, because it sticks fine to the limits you set while flashing a kernel but no app can get it to stick. Then again this is just me sharing my experience with it as it is my first phone with this platform, so maybe someone who knows more about this could offer some help.
ml11ML said:
I used to own a n7 and that allowed me to set min and max freq. with apps fine but i am also seeing this on my 6p, i don't notice any "overheating" although it may be due to me being used to it always running hot since i run a lot of heavier programs and also you know... SD810 but i guess it does the frequency thing as a way that frequency is actually controlled on this platform or something, because it sticks fine to the limits you set while flashing a kernel but no app can get it to stick. Then again this is just me sharing my experience with it as it is my first phone with this platform, so maybe someone who knows more about this could offer some help.
Click to expand...
Click to collapse
Thanks anyway, i really appreciate it!
(FIXED)
Assalam o alaikum
Hi
I've an lg v20 Us996
Unlocked bootloader amd rooted
When i first bought this phone it was liquid and buttery but after few days device starts lagging and stucking,i farctory restored it but no fruit then plan to root it and j rooted it but still the device keep lagging.
I've strictly monitored the activities of my cpu and the thing which i captured is that My cpu min and max frequencies keep changjng by it self which makes it laggy.
Like the max frequency is 2.15, but i automatically scales down to 400mhz,900mhz,1036 and some others frequencies which slow down the device.
Even if i use kernal auditor and set the max frequency to sclae up still it automatically changes.
I've used 3different kernals and on stock based rom(weta rom)
Still the same issue.
Is it a hardware issue or software issue?
Thanks in advance
First off, this shouldn't be posted in the development section as it's unrelated to development.
Second, the CPU is supposed to scale, change frequencies depending what the phones doing, 307 MHz-2.15 GHz. If the CPU stayed at 2.15GHz, you would face dramatically shortened battery life and eventual overheating. Thermal throttling is a necessity. LG is a bit more conservative compared with some other vendors I have noticed but if the issue has just started I would look more towards a particular app running afoul.
+1 for app craziness... If you utilize any 3rd party stores, ie Aptoide,Blackmart,ect... Then I HIGHLY suggest getting some sort of active antivirus on your device at this point. Malware is getting good enough to bypass Google Play filters, what do you think is going on on the less-than-monitored stores? Mayhem... Silent, costly mayhem. Chances are, if your CPU is doing all of that randomly, and especially if it is getting warm for no reason/battery drain from sitting and doing nothing, chances are your device is part of an Ethereum/Bitcoin MineNet, making someone money... I suggest getting a Norton AntiMalware scanner.. I KNOW.. Norton blows on windows.. But it cleared my device of the exact same plagues... Just watch out for that FinSpy... That bites.... I just had a bit of that as part of an entire multi-zero-day attack on my networks I am in the process of writing up reports for CVE's.... It made a mesh network between anything with Wifi, Bluetooth, or IR... Kernel level on windows 10... and with the climate of today, and how you started the thread, if I were you, and if you connect your phone to your computer, and if you run Windows 10, then I would check your MBR, and your bootsec as well for possible buffer overflows that lead to code injection that might send your device booting elsewhere while images are being made of your system... This is a long shot... But these are the symptoms I experienced, which led me to literally watch my logcat with aLogCatView live for about 2 hours, watching my mic go on and off, and then once, in light blue letters, I caught FinSpy, with nothing after those letters... just a notation that scrolled on...
Now more than ever, exercize proper security. Especially on a device who's sec has been bypassed by the same exploits that the malware will use to gain access to do damage. We praise DirtyCow for giving us our phones, truly. But the nefarious praise it for giving THEM OUR devices... Just my .2
Ducter said:
First off, this shouldn't be posted in the development section as it's unrelated to development.
Second, the CPU is supposed to scale, change frequencies depending what the phones doing, 307 MHz-2.15 GHz. If the CPU stayed at 2.15GHz, you would face dramatically shortened battery life and eventual overheating. Thermal throttling is a necessity. LG is a bit more conservative compared with some other vendors I have noticed but if the issue has just started I would look more towards a particular app running afoul.
Click to expand...
Click to collapse
The problem was with thermal engine which I've fixed
maxi65 said:
The problem was with thermal engine which I've fixed
Click to expand...
Click to collapse
How did you fix it?
Sent from my LG-H918 using XDA-Developers Legacy app
Assalam o alaikum
You just simply have to replace thermal engine configuration file form your system/etc folder using root explorer and everything will be fine and smooth (in sha Allah)
Use root explorer
Go to system and find for 'etc' Folder
Then in etc folder find ' thermal engine 8996' and create a backup of that file by simply copy that file to your internal storage or wherever you want
Then replace this file with that file which I've provided you in attachment
Note: the attached file is in 'txt' format
Change the extension from 'txt' to 'conf' by simply renaming the file then replace it.
Thanks man You saved