Database Users

Overclocking and black screens when attempting to unlock: Explanation & Solutions

I wanted to explain black screen issue many folks are encountering with overclocked kernels. The root cause is that voltages at higher clock speeds are not high enough to get the screen to turn on. In other words, if your screen is off and your phone scales beyond 800Mhz, the phone does not have enough power to turn the screen on. You'll almost always scale to the max the moment you hit that power button.
There are a few ways to prevent this from happening (from best to worst):
Create a "screen off" profile in SetCPU to restrict the clock to 800Mhz or below when the screen is off. I think it's obvious why this works. At the same time, a lot of people already do this, which explains why everyone hasn't been having the problem.
Use the conservative governor. Because it scales more gradually, it won't immediately jump past 800Mhz when you attempt to power the screen. There is still a chance of encountering the issue if you attempt to turn on the screen if the device has been busy for a while.
Increase voltages in the kernel. I started experimenting with this before I decided to come here and recommend the first two options. To get the screen to reliably turn on at higher clock speeds, we'd have to raise the voltages substantially. So we'd end up with more risk of damaging components, degraded battery performance and so on. Once the screen is on, the cpu does not actually need more power than it's being given in today's frequency tables. Thus, we'd effectively be increasing power consumption all the time to deal with a need for more power at screen on. Clearly a bad idea.
Unless you're using SetCPU profiles (or equivalent) or the conservative frequency governor, you're going to get black screens. Cyanogen, Pershoot, Evil's and my kernels all use roughly the same voltages, so you're going to need to apply this solution regardless.
There you have it.

*Applauds*
I bow down to your wisdom, sir!

Can you explain why this doesn't happen to me when I'm on CM 6.1.1 ROM?
With setcpu settings at 1209/368 (ondemand scaling, no profiles) I have black screens on Virtuous but neveron Cyanogen's mods.

rgl12miami said:
Can you explain why this doesn't happens to me when I'm on CM 6.1.1 ROM?
With setcpu settings at 1200/300 I have black screens on Virtuous but never
on Cyanogen's mods.
Click to expand...
Click to collapse
I'd have to do more testing to confirm but I would guess more load is generated (events triggered) with Sense ROMs at the time of wake, causing the ondemand governor to scale up to nearly max more rapidly than CM.
There's a simple way to see if it'll ever happen on CM. Set your governor to "performance", with clock speed above 1Ghz. Turn off the screen and see if it fails to turn after a few attempts at toggling it on and off.

I did what you suggested about 30 times and no one has failed. It's a shame,
because I do really love your ROM: speed is incredible. But what bothers me
the most is when the alarm sounds or I receive a call and the screen refuse to
lighten up. I will keep an eye on your rom and for sure I will be back on it soon.
Great job! The best sense rom i've ever seen.

Thanks for this. Works perfectly on my Stock SenseUI ROM with virtuous kernel

Thanks! That explains why the issue hasn't been happening since I set my profile to conservative. That was probably the most annoying issue since I got my G2.

I bet the fact that every cpu is different would also explain why it happens to some and not others.
Again every cpu is different, but here is my settings for screen off. Min 245 max 245. I started min 245 max 368, dropped max down and no adverse effects and great bat life. I have no blackscreen/wakeup issuses. I've been using setcpu to save battery since before the first oc module/kernel.
Would def test kernel that drops below 245 and/or uv it greatly.

fastludeh22 said:
I bet the fact that every cpu is different would also explain why it happens to some and not others.
Again every cpu is different, but here is my settings for screen off. Min 245 max 245. I started min 245 max 368, dropped max down and no adverse effects and great bat life. I have no blackscreen/wakeup issuses. I've been using setcpu to save battery since before the first oc module/kernel.
Would def test kernel that drops below 245 and/or uv it greatly.
Click to expand...
Click to collapse
What do you mean that every CPU is different? At the hardware, firmware, software level?

gee one said:
What do you mean that every CPU is different? At the hardware, firmware, software level?
Click to expand...
Click to collapse
I think he means every cpu handle overclocking differently, for example ive been very unlucky and my cpu cant handle anything above 1.1 Ghz and it crashes if i set it up any higher but lots of people running theirs at 1.8 and they are stable
its just like overclocking PCs every cpu handle overclocking differently even if they have the exact same spec.

I'm bumping this due to how useful this information is and how often the issue still comes up.
Sent from my HTC Vision using XDA App

rmk40 said:
I wanted to explain black screen issue many folks are encountering with overclocked kernels. The root cause is that voltages at higher clock speeds are not high enough to get the screen to turn on. In other words, if your screen is off and your phone scales beyond 800Mhz, the phone does not have enough power to turn the screen on. You'll almost always scale to the max the moment you hit that power button.
Click to expand...
Click to collapse
I don't understand why I don't encounter this issue at all with AOSP ROMs. Is there an obvious reason I'm missing?

poochie2 said:
I don't understand why I don't encounter this issue at all with AOSP ROMs. Is there an obvious reason I'm missing?
Click to expand...
Click to collapse
This was the first question asked (see the fourth post). Here's the OP's theory...
rmk40 said:
I'd have to do more testing to confirm but I would guess more load is generated (events triggered) with Sense ROMs at the time of wake, causing the ondemand governor to scale up to nearly max more rapidly than CM.
Click to expand...
Click to collapse
I haven't seen this issue before either.

ianmcquinn said:
This was the first question asked (see the fourth post).
Click to expand...
Click to collapse
My bad, I missed that.

[Kernel] - 3-23-11 - v.5b - Impressive Sounding Name Kernel

Most of what is below is still accurate, but see this post for links to the kernel download and important infoshttp://forum.xda-developers.com/showpost.php?p=12397646&postcount=580
1-18-11
v.4 - GB’s Impressive Sounding Name Kernel
* As always, many, many thanks to xcaliburinhand.
* Consolidating Steam and Voodoo/CWM kernels into one thread. The two kernels are the same except for recovery, and jfs support in the Steam kernel.
* Started using a proper changelog
* Implemented Impressive Sounding Name Technology AND Dynamic Naming Technology patches; next update to include Dramatic Use of Imagery, with possible Reference to Mythical Creatures patch.
* Cherry-picked some recent commits not included in JPX source. (Will post source this evening, I hadn’t planned on releasing this just yet, but it seems as though it’s already being packaged into a ROM so might as well, right?)
* CONFIG_ARM_THUMBEE=y, enables ThumbEE processor mode, should give some minor JIT performance improvement.
* config_hz=100. With this value, kernel hz = user hz which eliminates HZ <--> USER_HZ conversions. It should also slightly increase battery life without affecting performance.
* Increased default overclock to 1280 MHz. Your may want to revise your undervolt settings, 1280MHz runs at the same voltage as 1200MHz did/does, so you **may** not be able to undervolt as much at 1280. (Yes, I previously said I wouldn’t go past 1200MHz, but, I feel ok going to 1280 since the voltage hasn’t changed and it’s still well below the max vdd_arm.) Use voltage control or setCPU to limit clock speed if you don’t want to use this. Delete your Voltage Control boot settings before booting this kernel. I’m currently using Voltage Control 3.0a.
* Added Voodoo Sound. I hadn’t really planned on it but there were a lot of requests for it.
* Removed i9000 splash screen and replaced with an old familiar one.
* Want lower screen brightness? I know Hardcore did tinkering with the kernel source to do this, but I really like Screen Filter, it even has a Tasker plugin.
* From previous versions: Backlightnotification 2.3, Voodoo color/video fixes re-enabled against my better judgment and even though single-blind testers couldn't tell me which kernels had it and which did not. .
Downloads of v.4 - The file you want is something like rGB-v.4-011811-XXXXX.zip/tar
By clicking any of these links, you agree to flash delete your Dalvik cache and remove any oc/uv boot settings you have before booting. v.4 ClockworkMod zip at the bottom of this post, tar files of Voodoo5/CWM and Steam below for those of you who like to use Odin.
tar of v.4 with Voodoo5 & CWM recovery
tar of v.4 with Steam recovery
Credits
Xcaliburinhand, supercurio, raspdeep, SztupY, sorry if I forgot anyone else.
Stuff I wrote a while ago and may or may not be accurate any more.
1-6-11
This seems to be stable again. Started over from scratch and added in BLN 2.3. Everyone who was affected by charging problems with the previous kernels has not had a shutdown over the last two days of testing. Hopefully we're good again.
1-4-11
Closed testing on newer kernels until I'm fairly confident the issue is resolved again. I had still been getting intermittent reports of charger instability from the reoriented-balls-1-3-11-ocuv-bln23.zip (#47) kernel. Anyone affected by this please switch back to the 'f' builds below, which is the last known rock solid (I think) version.
-----------------------------------------------------------------------------------------------
This kernel is fast, and this kernel is stable. It's overclocked by default to 1.2GHz, but if you don't want to overclock at all, just install either setCPU or download xan's app which I have attached to this post and set the max clock speed to 1.0GHz. This kernel supports init.d scripts, so you have save your settings and have them load at boot.
1100-1200+ Quadrant score on RFS at 1GHz. 1500-1700+ on /data, /dbdata, and /cache on ext4. ~14.1 Linpack at 1GHz. Compare that to any other kernel available here at the same speed and I think you'll see this one comes out on top. I'm not doing this for donations, I just want to my experience with the phone as good as possible. Since this is a Voodoo 5 kernel, you can also make /system ext4 as well for an even smoother experience. This kernel has great battery life and is very stable as well. And when I say stable, I mean, you can use the phone however you want to, you don't have to do any workarounds to keep it from freezing. (edit - as long as you're using one of the build f kernels it seems...) Although, as always, if you aren't 100% satisfied with any of my products, I will give you a full refund.
What this kernel is -
Kernel for 2.2.1 ROMs, (may work on 2.2, but I haven't personally tested it), built from JPX source, with Supercurio's Voodoo 5, overclocked by default to 1.2GHz with raspdeep's code, and Neldar's backlight notification enabled, and re-oriented with xcaliburinhand's code. The undervolting code has been fixed to keep your phone from dying while charging. I'll not be supporting anything beyond 1.2GHz. I hardly use 1.2GHz myself, and from what I've read, many users (but obviously not all) have stability issues with anything much beyond that. This post from one of the senior Android engineers at Google also struck a nerve with me, and is also part of the reason I'll not support anything past 1.2GHz. Samsung actually wrote most of the code for 1.2GHz into the kernel source but had it commented out, so I don't have a problem providing software that will allow users to push it to that level.
Again, for voltage control, use xan's app. I've attached an older version of the app as I'm not sure if the newer one is backwards compatible with the 'older' methods of power management.
Also, standard disclaimers about how if this blows up your phone or tells your girlfriend she's getting fat, it's not my fault. I've had this kernel on my phone for a couple days, so none of that should happen.
How to install - Either flash in ClockworkMod, or use Neldar's really awesome kernel flashing app.
gb-reorient-12-23-build-f.zip is a zip tarred zImage. Unzip, then flash the tar with Odin, or extract the zImage and flash it with Heimdall or Neldar's kernel flashing app.
gb-reorient-fixed-ocuv-f-cwm.zip is a ClockworkMod flashable kernel.
Some thoughts on undervolting
The whole point of undervolting is to safely do the same amount of work with your CPU while using less energy (ie more battery life). Your phone is idle most of the time, so you can the most from undervolting lower frequencies more. Undervolting is safe WHEN you find the settings that work for your phone. Generally, -75mV seems to be stable for everyone. If you want to push it further, go ahead, but realize that if you push it too far, you phone will freeze, and you'll have to pull the battery. Relatively harmless, but, be aware it can happen. Personally, my phone is perfectly stable at the following settings (from 100MHz to 1000MHz) -125mV, -100mV, -100mV, -100mV, -75mV. These settings may not work for your phone. You might find that you can get by with undervolting a little more, but your system will freeze randomly, so if that happens, don't undervolt as aggresively. So, for example, I found that I can usually get by with -150, -125, -125, -125, -100, but every once in a while the phone will freeze up. And since I want a stable system, I've backed down from that. I can't tell you what to do though, but keep in mind that undervolting too much may lead to system instability.
- If you still want to try to find a oc/uv kernel which works for you, don't undervolt at all and tell me if it still happens with kernel #7 (12-23 build from my other thread). As far as I know, no one has had an issue with charger instability on that kernel. If it does still happen, I need to know the kernel version # and for good measure, the production code under your battery (can someone tell me what the name for this is again, I don't feel like shutting off my phone to check), it will be a number like 08.10, 10.10, etc.
- If even with the 12/23 build f kernels and not undervolting at all, you're still get shutdowns when charging, you probably want to get a different kernel. If you insist upon using that one anyway, try charging via USB instead of the wall outlet, it seemed to happen less frequently on older kernels, and I haven't had a charge death in weeks now, so, I'm good at least.
- See if your phone is one of the ones being recalled. If your phone is under recall and these don't work for you, I'm not sure what else I can do.
- These fixes work for me and a lot other people who had the same problem with other oc/uv kernels. Like I said, we're running these out of spec, so a few unlucky souls might not have phones that can handle this. Or maybe some of these kernels have been sprinkled with pixie dust and others haven't. If you find a different kernel that works for you by all means use it. It's all about choice people.

Thanks. Going to try it now.

I flashed 'em at 94%, so we'll see.
But FWIW- I think I've had MAYBE 2 charge deaths when I was on perception. But I was using Setiron's kernels, so I dunno...
I'll report back in a bit.. gonna let it over-charge for a bit and see what happens.

Darky 7.0.1 with your kernel and 100% battery power for 2.5 hours plugged in to the wall and no power off yet. Hopefully this is the fix, I am tired of leaving my computer on all night to charge on usb

thank you so much for this...been looking for something exactly like this, and seems sleep death is gone

darky 7.0.1 here also.
I had it charge around an hr and a half past 100% and no death!
So we'll see how it does overnight

I'll try it out and let you know how it goes, i charge by ac overnight so I should have the results of it to you by morning I'm using it with Assonance 5.2 by the way.

Well no charge death for me last night...
Sent from my GT-I9000 using XDA App

Absolutely no problem, left on ac all night with an undervolt and everything. Great job with this, it made oc/uv usable for me.

Doc's 6.1.3 + your kernel = 100% joy
I found your thread last night after a long and happy Christmas day with the family. Followed your instructions to the letter. Charged overnight from 45% and woke up to find the phone operating fine. This might be the answer to all our prayers!! Thank you so much!

Runs great with eugenes ginger clone. Slightly better benchmarks than other rom/kernel combos. I peak out at 1.3ghz so 1.2 seems like a good medium. One request though is to look into changing the divider for the gpu. I know we don't need it but its good for bragging. Unhelpful had this and I could set the gpu down to 166.750 For lower clocks to save battery and up to 222.334 (stable) for benchmarks. I never tried other clocks so I don't know if it would work on other settings. It depends on how his code works. but it seems by my math the gpu is divided off a 2000 or 2001mhz frequency. There is a margin of error I guess. and stock is divided by 10. In unhelpfuls code it is divided by 9 (222.334) default but could be set to 10 or 12. If we bump that up to 15 or 20 we might reduce battery consumtion with a gpu clock at 133 or even 100mhz. Id also like to try the divider at 8 for 250mhz. Im curious as to how that would benchmark if its stable.
Sent from my SAMSUNG-SGH-I897 using Tapatalk

Ive been charging since 2pm yesterday and its still on. I think you got the fix

No problems here charging overnight. For those who care about quadrant scores, mine was about 250 points higher than the other 1.2ghz kernel I was using.

I get better quadrant scores too vs.my setiron 1.47 1200 kernel. I don't know if it's due to this kernel, but for some reason I'm getting much better battery life since flashing it.

opcow said:
I get better quadrant scores too vs.my setiron 1.47 1200 kernel. I don't know if it's due to this kernel, but for some reason I'm getting much better battery life since flashing it.
Click to expand...
Click to collapse
Same here, battery life seems better..I've noticed it not draining so quickly, im at 85% when usually id be at 50-60%
Sent from my Captivate

I've found Darky's 7.01 works best on my phone, could it be true this makes it run faster? Do I need to have full charge or can i flash this at any battery level?

I didn't look at the actual quadrant score. But my fps is on average about 2-3 greater. Similar to running at 1300 on other kernels. Battery life is much improved over the kernel in eugenes ginger clone rom.
Sent from my SAMSUNG-SGH-I897 using Tapatalk

I just flashed it over SetiroN 1.5.6 and can see a speed difference already. 1200 O/C is perfect, I really like the kernel. Working great on Darkys 7.0.1

I too just installed over Darky's 7.0.1, bit more speed is noticable but i mainly did it for the possibility of better battery because right now thats all i am after.

i just installed but i want some more about voltage control
how can i modified that option?
thx a lot!

Random lockups

As per the title, I have started experiencing random system lockups since yesterday. I have had to perform two battery pulls and I'm starting to worry that my ext partition won't be so lucky next time...
I have no idea what is causing the lockups, though both have occurred while using Swype. Coincidence?
For now I'm going to set my system clock back to 600Mhz and use the default input method for a while and see if I still get lockups, at which point I will probably flash another ROM unless I can find a solution, which is where you guys (hopefully) come in. Is there anything else I can do to diagnose and/or solve the problem?
- Typed from my rooted HTC Legend -

It's most likely the OC that's causing the problem, Swpye shouldn't affect the stability. Unless it's a cracked version

Try interactive governor or flash latest kernel from the other thread.

TheGrammarFreak said:
It's most likely the OC that's causing the problem, Swpye shouldn't affect the stability. Unless it's a cracked version
Click to expand...
Click to collapse
That's peculiar, as I've had the processor on 768Mhz for a while now and I've had no problems at all before now.
As for Swype... it could be. ;P
BlaY0 said:
Try interactive governor or flash latest kernel from the other thread.
Click to expand...
Click to collapse
I'll try that, but what exactly does each governor do?

segphault said:
I'll try that, but what exactly does each governor do?
Click to expand...
Click to collapse
It manages when the processor speeds up. It doesn;t run at 768MHz all the time, that's just the highest you allow. Ondemand scales the frequency up when it's needed, and lowers it again afterward. It seems to be a little bugged in our kernels though, and causes crashes.
Interactive does a similar thing, but without polling the CPU. It also ramps the frequency up a little more quickly. I use it, it makes the phone more responsive (IMO), and also eliminates the need for profiles in setCPU (to a degree)

Just checked my kernel version - I already have the latest version (2.6.32.17). I've also set the governor to interactive as suggested, but I have pushed the max clock back to 768Mhz and the min clock to 122Mhz.
While we're here, is there any way to push the min clock down even lower, or would that require fiddling with the kernel? In which case, I have two questions:
1. blay0, I've heard people who can push their min clock down to something ridiculous like 19Mhz if I recall correctly, which makes battery life last a crazy amount of time. Could you include that as the minimum clock in the next kernel for b 0.8?
2. If not, how do I go about changing it myself?
I want to learn.

segphault said:
Just checked my kernel version - I already have the latest version (2.6.32.17). I've also set the governor to interactive as suggested, but I have pushed the max clock back to 768Mhz and the min clock to 122Mhz.
While we're here, is there any way to push the min clock down even lower, or would that require fiddling with the kernel? In which case, I have two questions:
1. blay0, I've heard people who can push their min clock down to something ridiculous like 19Mhz if I recall correctly, which makes battery life last a crazy amount of time. Could you include that as the minimum clock in the next kernel for b 0.8?
2. If not, how do I go about changing it myself?
I want to learn.
Click to expand...
Click to collapse
You'd have to mess around with kernel source code. I wouldn't know where to begin, sorry

Wouldn't 19 MHz min also make the phone painfully slow to wake up? Just curious.
Sent from my Legend using XDA App

MaBlo said:
Wouldn't 19 MHz min also make the phone painfully slow to wake up? Just curious.
Sent from my Legend using XDA App
Click to expand...
Click to collapse
That did cross my mind but other users have reported success with it, so I figured I might as well give it some investigation.

I had mine go to 19 min with screen off once, it did my head in. Maybe interactive with a reasonable upper limit with screen off (like 400) would work, who knows

TheGrammarFreak said:
I had mine go to 19 min with screen off once, it did my head in. Maybe interactive with a reasonable upper limit with screen off (like 400) would work, who knows
Click to expand...
Click to collapse
Maybe not quite 19Mhz, then.
Perhaps we should do some testing to see how much processing power is needed to wake the phone quickly? Is there any way to test that?

Back on topic, I just had another lockup while using the interactive governor. This time I froze up while loading Fruit Ninja.
Now I'm at a total loss for what could be causing the lockups.
- Swyped from my rooted HTC Legend -

Seeing as nobody can seem to pin-point the problem, I'm moving to CM7 permanently as soon as it's released as stable.

[INFO] Custom Kernels & Overclocking - FuguMod Ultra Pre Release

After reading through the Thread for the Pre Release of FuguMod Ultra in the development section of this forum I thought I would post some info up for people who are wondering why it doesn't work with their phone, and just some general info on overclocking.
- First off, not all phones will be able to run at 1366MHz. Every CPU made has a range of freuqencies it will work at, and it is different for every single one. So some may be able to handle 1366MHz and above, others may max out at 900MHz. If you are getting black screens, freezes, or random behaviour, then your CPU doesn't like the frequency you have it at, try a lower frequency.
- Always keep an eye on the temp of the CPU when testing overclocking, if the CPU gets too hot, and fail safes don't work, there is a chance you could fry your CPU.
- With the FuguMod Ultra kernel, you must also be aware that gpu bus frequencies have been changed, so if your phone is not happy with that it will black screen. (as bus speeds are like cpu speeds, every different device can handle different clock speeds)
- plls values have been changed, and these may cause problems on your phone.
So if you want to have a go at overclocking your phone, back it up, and then give it a go. Select a frequency, and test with something pretty cpu intensive (3d game, multiple quadrant passes) and see if there are any bugs/overheating during a 15min time period. If you notice any problems/too much heat, try a lower frequency, and try again. And if for some reason your phone doesn't like the kernel, you can reflash with your previous kernel or a new ROM as you have already backed up your data.
If you have any other questions about overclocking, feel free to post here and I will try my best to answer them.
--- Samsung G3, InDroid 4.3, FuguMod 2.4 B3 800MHz ---

How can you check the CPU temperature? I thought it was only battery temperature.
Sent from my GT-I5800 using XDA App

dilzo said:
How can you check the CPU temperature? I thought it was only battery temperature.
Sent from my GT-I5800 using XDA App
Click to expand...
Click to collapse
The battery temp is a good representation of how hot the processor is getting as it is right next to the battery (only a thin sheet of metal seperating it) If the battery rises in temperature by a few degrees, then you can summize that the cpu is probably getting a few degrees hotter than that. I really wouldn't recommend letting the battery get above 55degrees (celcius) as this means the CPU may be getting up close to 65degrees (celcius) which is a very bad thing.

Good post.
Note that if you want to make some stress-tests, you have to put "PERFORMANCE" governor and set the max freq you want to test.

marcellusbe said:
Good post.
Note that if you want to make some stress-tests, you have to put "PERFORMANCE" governor and set the max freq you want to test.
Click to expand...
Click to collapse
Yes, Very true!!
Must also say, Your kernels are pretty legendary! Waiting patiently for the offical release of your FuguMod Ultra

m not able to see time in state with both setcpu and cpuspy and it seems deep sleep is also not working.

Piyush Rawal said:
m not able to see time in state with both setcpu and cpuspy and it seems deep sleep is also not working.
Click to expand...
Click to collapse
How have you got your phone set up? i.e. what ROM are you using etc.

I am using stock jpq with app2sd, swap, zipalign, ramhack and stuff. Setcpu is installed with default min/max freakquency, No profiles in use and undervolt a bit.

Ok,
This may be an issue caused by XXJPQ, as it is a new release there may be some sort of conflict. Have you tried asking if anyone else has this issue in this thread? http://forum.xda-developers.com/showthread.php?t=1132697
I haven't played around with JPQ yet so don't know what the bugs are yet.
Also, are you running a stock kernel? Have you confirmed that the phone has been rooted properly as well?

It's definitely a bug in Kernel. I tried three different roms and i wasn't able to check time in state in any of them (I am talking about fugumod ultra prerelease kernel here).
With previous versions of fugumad kernel everything is fine. So definatly a bug in kernel.

Piyush Rawal said:
It's definitely a bug in Kernel. I tried three different roms and i wasn't able to check time in state in any of them (I am talking about fugumod ultra prerelease kernel here).
With previous versions of fugumad kernel everything is fine. So definatly a bug in kernel.
Click to expand...
Click to collapse
Ok cool, I'll report the bug to the developer so that he can have a look into it. Thanks for testing and proving to the kernel.

Little bit of info some might find helpful. After some recent testing, I have found that some people might experience a black screen freeze when phone is in standby for a while with 83MHz min setting and on demand governor. I am not sure of the exact reason for this, whether it is a bug, or that the processor just doesn't like going that low for extended periods of time. If you experience this type of error, just hard reset the phone then open setcpu after phone has loaded and change the "standby" profile minimum to at least the next step up on the slider. Personally I use 223 setting as it provides a smoother lock screen animation, and no significant difference in battery drain.
Sent from my super smooth GT-I5800 using XDA App

Phone randomly will turn off? CM7.1

Lately I've been noticing when I go to grab my phone, it will be magically turned off. I know it wasn't turned off because it will just sit on my desk, full battery, no loose battery connection (NEVER has the phone turned off while use or moving around, but still an assumption), no crazy setcpu scaling (min: 245MHz max: 806MHz), and no water damage. I haven't had this problem in the past with CM7 nightlies, or CM7 final release. I also know that its not just that problem I have every once in a while where the screen won't turn on but the 4 touch buttons will. But I'm 99% sure that's just a result of my min: 245MHz max: 245MHz screen off setcpu profile. Anyone have this issue or have any ideas why its doing this?
Sent from my HTC Vision using XDA Premium App

You're not the only one who has experienced this problem. Check out this thread from the T-mobile forums where users have discusses the problem and a possible fix. Take a look at the pictures on the 4th post on page 4 by user vlado4 and see if your battery is the same. Apparently there is an issue with the battery shorting out or something of that nature. http://forums.t-mobile.com/t5/T-Mobile-G2/G2-Turning-off-by-itself/td-p/513575/page/4 Hope this helps!

carquote said:
You're not the only one who has experienced this problem. Check out this thread from the T-mobile forums where users have discusses the problem and a possible fix. Take a look at the pictures on the 4th post on page 4 by user vlado4 and see if your battery is the same. Apparently there is an issue with the battery shorting out or something of that nature. http://forums.t-mobile.com/t5/T-Mobile-G2/G2-Turning-off-by-itself/td-p/513575/page/4 Hope this helps!
Click to expand...
Click to collapse
I checked my battery and my battery does not have the metal strips, should i still attempt his fix even though i dont have that metal on metal contact? My battery looks like the guys GF's battery a little bit down on the 4th page, 4th post.

I would ditch setCPU to be honest. since CM settings now has overclocking built in, it just seems loony to call on another app to manage cpu frequencies.
there is a lot of misunderstanding regarding profiles with setCPU as well...
unless you are running the performance governor (which pegs the CPU frequency at its highest selection), "profiles" are already built in to your kernel.
it is the kernel's job to manage frequencies according to load... which is exactly what you are attempting to do with your screen off profile. if you're on ondemand, interactive, scary, smartass, or any other governor aside from performance, the governor will do the "screen off" profile for you automatically by scaling down frequency based on load.
setCPU is a good tool for roms without built-in CPU management, but for CM7, it's officially obsolete (unless you're overclocking heavily and need a temperature profile... your governor won't do that for you )

Thanks for all the info, i knew CM7 had the built in one but didnt know the kernel handled as much as it did... thanks! (and i pressed "thanks" by the way to everyone who replied ) Since you seem to have some kernel knowledge, whats the smartass and userspace governor?

Kevin001111 said:
Thanks for all the info, i knew CM7 had the built in one but didnt know the kernel handled as much as it did... thanks! (and i pressed "thanks" by the way to everyone who replied ) Since you seem to have some kernel knowledge, whats the smartass and userspace governor?
Click to expand...
Click to collapse
here's a quote from erasmux on smartass (the sleeping frequencies may differ depending on whose smartass you're using):
smartass governor – is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!
Of course, the frequencies are different than what he used, since we have better processors than the Hero.
Z
Click to expand...
Click to collapse
userspace is problematic in my experience. would not recommend using it. here is a good article explaining what it does (and why it's not the best idea for most of us): http://publib.boulder.ibm.com/infoc...topic=/liaai/cpufreq/TheUserspaceGovernor.htm

G2 randomly turns off
I have been having a similar issue with the phone just randomly turning off, I am not sure if this has to do with the handoff between wifi and network calling but this is a hunch. I do have a logcat with a few shutdowns.

carquote said:
You're not the only one who has experienced this problem. Check out this thread from the T-mobile forums where users have discusses the problem and a possible fix. Take a look at the pictures on the 4th post on page 4 by user vlado4 and see if your battery is the same. Apparently there is an issue with the battery shorting out or something of that nature. [cant post outside links] Hope this helps!
Click to expand...
Click to collapse
You think you could summarize what the fix is? The link doesn't work anymore. Thanks

j0lte0n said:
You think you could summarize what the fix is? The link doesn't work anymore. Thanks
Click to expand...
Click to collapse
Try this link instead: http://208.74.204.85/t5/T-Mobile-G2/G2-Turning-off-by-itself/td-p/513575/page/4
T-Mobile, in their infinite wisdom, completely trashed the old forums in favor of some new community/social neworking-esque BS. Everything that people had worked on, figured out, and shared was lost for good. After an uproar from the community they temporarily restored a read-only version.
That link should work for now, but T-Mobile stated that the archives would only be brought back for about a week. Tools.

I had this issue. Only with the leaked 2.3.3. I haven't had the issue with the new official 2.3.4. I had to remove the battery and reinsert it. rather annoying especially if I was driving.