Related
Hey guys, searched for a quite a while and havnt been able to find a similiar problem. Heres what i did
Got the phone 3 days ago and proceeded to root it. It had the perfect SPL so i took the long route and made a goldcard and went to the 2005 SPL.
After phone was flashed i did the "daredevil" way of reverting back to 32b and flashed an appropriate rom to it (cynogens 4.1.8 is on there now)
It seems about %70 of the time when you hit the menu button to get the screen to turn on you can see it flash some lines on the screen like its "charging" the lcd than it just fizzes out, no picture what so ever is visible just weird fuzzy tv looking things than they go away. Trying again usually does the same thing. I have to try probably 5-6 times just to get the screen to turn on and work like normal.
So my question is, is this a PHONE issue, or is this something that could be rom / radio / spl related.
If this is a phone issue i need to take this to unroot and take to the tmobile store asap and get it replaced with another under warranty.
I got the same thing in my G1... send to HTC warranty, they changed the main board. Got it back and it happened again. Then I rooted and installed cyanogen mod, now I never see it again. So I thought it was a hardware issue, but after ROM upgrade I never see it again, so now I really don't know...
The issue is being worked on in this thread and it seems to be related to specific kernels: http://forum.xda-developers.com/showthread.php?t=554612
notxel21 said:
The issue is being worked on in this thread and it seems to be related to specific kernels: http://forum.xda-developers.com/showthread.php?t=554612
Click to expand...
Click to collapse
ok so this could possibly be both rooted / non rooted boards? Thanks for that link i appreciate it, i'll put my few good words in there. I dont think i can use this phone for business with it doing this.
This is mainly an issue with CPU clocking. Download the CPU clock widget for free and set it at no greater than 245mhz as a starting value. You can clock all the way up to 528 safely but if the phone tries to turn the screen on at 384mhz or greater you will get this fuzzy screen issue repeatedly! I was having this problem lots over the last few days and once I turned my cpu clock down to a range of 245mhz to 528mhz instead of what I was running of 384mhz to 528mhz the problem is gone. Some roms do this clocking automatically so even a fresh flash of a rom can cause this issue but if you download an app that allows you to change the cpu clock *you do have to be rooted* then you can solve this issue.
Give it a shot and post your results here so others may know this works too!
P.S.
The thread: http://forum.xda-developers.com/showthread.php?t=554612&page=25 refering to the "blurry screen issue" is not what this topic is about. The origonal post is refering to the screen fizzing with some distorted lines across it when you turn the screen on and then it looks blank or is backlit but has nothing on the screen. After about 5 tries though the screen will come back on as normal and operate as normal until the next time you turn your screen off and back on. The other thread mentioned is for problems with certain roms looking normal after first boot and then going blurry, like when you get a confirmation on the screen and the background blurs, except it happens to the entire screen and does not go away. If you are having this blurred screen problem, please go to the other thread. If you are having a fuzzy screen where sometimes it comes back on and sometimes just goes blank, then please clock your cpu down to 245mhz and let it clock up gradually to whatever higher cpu setting you want.
Apollo_316 said:
This is mainly an issue with CPU clocking. Download the CPU clock widget for free and set it at no greater than 245mhz as a starting value. You can clock all the way up to 528 safely but if the phone tries to turn the screen on at 384mhz or greater you will get this fuzzy screen issue repeatedly! I was having this problem lots over the last few days and once I turned my cpu clock down to a range of 245mhz to 528mhz instead of what I was running of 384mhz to 528mhz the problem is gone. Some roms do this clocking automatically so even a fresh flash of a rom can cause this issue but if you download an app that allows you to change the cpu clock *you do have to be rooted* then you can solve this issue.
Give it a shot and post your results here so others may know this works too!
P.S.
The thread: http://forum.xda-developers.com/showthread.php?t=554612&page=25 refering to the "blurry screen issue" is not what this topic is about. The origonal post is refering to the screen fizzing with some distorted lines across it when you turn the screen on and then it looks blank or is backlit but has nothing on the screen. After about 5 tries though the screen will come back on as normal and operate as normal until the next time you turn your screen off and back on. The other thread mentioned is for problems with certain roms looking normal after first boot and then going blurry, like when you get a confirmation on the screen and the background blurs, except it happens to the entire screen and does not go away. If you are having this blurred screen problem, please go to the other thread. If you are having a fuzzy screen where sometimes it comes back on and sometimes just goes blank, then please clock your cpu down to 245mhz and let it clock up gradually to whatever higher cpu setting you want.
Click to expand...
Click to collapse
That's what were refering to the screen wake issue. Same problem just called different things. I will try to set my phone at or below 245MHZ for my low and post results!!
Because I've came across both issues depending on the rom. Some give me blur, and some give me the screen wake issue, and some give me both, but I will try you're suggestion.
Thank you for this.
Yeah the JacX hero rom is the only hero rom I have found for the *well at least my* MyTouch3g that *does not* give me the blurry screen issue so that's what I'm running. Then last night I played with my clock settings and went to bed, only to find that my screen was now having this distorted/not waking up issue not like the blur issue of other roms and when I retraced my steps and clocked the processor back down the screen not waking up issue went the way of the dinosaur! I really wish the blurry screen issue could get solved already because I want to try some other hero roms and especially cyanogens experimental rom really bad but I need my phone to work too lol...well I have spare phones so that's not entirely true but I just love my android so much lol!
And you're welcome! I figure that I've learned so much from this forum over the years and had so many helpful and friendly people that it's the least I can do to provide help back!
I'd still love to know if this works for you *I'm confident it will* if you wouldn't mind posting your results as well!
I just updated to 4.1.8 and it hasnt did it in quite some time now. Didnt get the overclock widget yet but im going to wait till it does this again to see if thats the issue. Which more then likely it is.
Not as much of an issue with wake screen on 4.1.9.2 but its still there.
Guess i'll try the overclock widget also.
Yeah the devs (most anyway) are now incorporating built-in cpu clocking settings in the user.conf file for their roms and this allows the rom to do dynamic cpu clocking from the stock rom, which also allows them to push the speeds of the phones the roms are installed on without additional software. The downside to this is when the clock starts above what it's default is, or at least above 245mhz the screen has a tendacy to not wake up properly. If the clock is started at 245mhz and then gradually moved up to 528mhz based on demand on the cpu then the problem goes away. The cpu widget is free and works great to allow you to control the cpu clocks, not the rom. There's another one I'd recommend called SetCPU on the market but it costs like $2 or $3 which also works nicely but doesn't really add anything over the free widget available other than some profile options for low battery and such.
*I'm still learning alot every day about all this android modding stuff so if I've stated anything incorrectly please PM me or let me know here and I'll edit my posts acordingly*
~*Apollo*~
still no dice
im running 4.1.10.1 and it is still not waking up properly. Even with the overclock widget installed and working. Im not sure what else to do. Im updating to 4.1.11.1 right now but i have a feeling this isnt going to fix anything.
I haven't seen this.
This issue has been addressed more thoroughly in the Dream section. Follow up with stories and details there. Otherwise, I haven't seen this problem in any of the most recent ROM ports.
Everyone's device is different regardless of matching statistics. Lol.
Best of luck to you fellas.
So I was investigating loadable kernel modules on the Droid 2 this weekend. One of the modules I tried loading was the smartass governor module and to my surprise it worked. From what I can tell it appears to be working with no problems.
The module itself is from a Milestone Cyanogen ROM. Given how close the Milestone is to the Droid 1 and how close the Droid 1 is to the Droid 2 it seemed like a safe try to see if it would load.
Requirements:
You must be rooted. This really should go without saying but I'm trying to cover all the bases here.
You must have busybox installed.
You must be able to boot into clockwork recovery.
I've tried this on Fission ROM but since we can't change the kernel on the Droid 2 this will probably work on any other Droid 2 ROM. D2G users, YMMV.
NOTICE: By installing this you assume any and all risk for what might happen to your phone. I am not responsible if this mod causes your phone to stop working, catch fire, steal your significant other, and/or hijack a plane. Basically I haven't had any issues but that is not a guarantee that you won't have any issues.
Attached is the update.zip. Boot into clockwork recovery and choose this zip to install. Once you reboot you'll be using the smartass governor.
So what has this done for your battery life?
Anecdotally I believe my battery life has improved. With the ondemand governor and data and wifi off I've seen my battery drop 10% in a night. With the smartass governor under the same conditions my battery appears to be the same. Now given that Motorola phones report the battery in just 10% increments my totally non-scientific analysis might end up being nothing.
Really you'd have to try it yourself and determine if things are better. From what I've read online the smartass governor is better at conserving battery than ondemand but it really depends on how you use your phone.
Download circle battery widget from the market. Its free and somehow it reports 1% increments. I have been using it for a while now and it seems to be spot on.
Sent from my DROID2 using Tapatalk
It just guesses
Well, there is a way to get an accurate battery reading. Reading /sys/devices/platform/cpcap_battery/power_supply/battery/charge_counter will give you the battery level in 1% increments. However, the system reads from /sys/devices/platform/cpcap_battery/power_supply/battery/capacity which provides the bounded 10% increments. Some widgets, Minimalistic Text for example, will read from charge_counter on Moto devices.
Ideally a kernel module could be written that changes what is written out to capacity so the entire system could take advantage of 1% battery increments. If I had the time I would take a crack at it, but it's been awhile since I've done any C coding.
Looks interesting. I'll wait until a little more feedback is given before I try it. How is the performance after the install?
I'm guessing you have to sbf to go back?
tbaker077 said:
How is the performance after the install?
Click to expand...
Click to collapse
No different than using the ondemand governor. Smartass takes a clever approach to CPU scaling: instead of polling CPU usage like ondemand it detects when the phone comes out of sleep and sets a timer to go off in two ticks. Once that timer goes off it looks at CPU usage and scales if needed. What does all this mean? Well, if you turn on your phone to quickly check the time and then turn it back off the smartass governor will never ramp up the clockspeed. So far after a few days of light usage I've been quite pleased.
rtfield said:
I'm guessing you have to sbf to go back?
Click to expand...
Click to collapse
Nope. If you want to revert just chmod 644 /etc/startup/smartass.sh and reboot.
Sweet
Thanks
I wonder if they could modify this to work with the new gingerbread kernel.
I know when I had an HTC Eris, Conap used a smartass gov on his kernel and it was awesome.
So I took a shot and flashed the smartass governor a second ago on my GB d2, and seems to be working just fine. I'll report later with battery stats and anything else i notice.
Spitemare said:
Well, there is a way to get an accurate battery reading. Reading /sys/devices/platform/cpcap_battery/power_supply/battery/charge_counter will give you the battery level in 1% increments. However, the system reads from /sys/devices/platform/cpcap_battery/power_supply/battery/capacity which provides the bounded 10% increments. Some widgets, Minimalistic Text for example, will read from charge_counter on Moto devices.
Ideally a kernel module could be written that changes what is written out to capacity so the entire system could take advantage of 1% battery increments. If I had the time I would take a crack at it, but it's been awhile since I've done any C coding.
Click to expand...
Click to collapse
I took a look at this and found some stuff that might be encouraging.
Here is the source for the battery driver. Line 397 reads as such:
Code:
val->intval = sply->batt_state.capacity;
If line 397 is changed to this
Code:
val->intval = sply->batt_state.batt_capacity_one;
then battery level should be reported in 1% increments. I've posted the updated driver code here.
The problem is the gorram encrypted bootloader. It's not easily possible to swap a built-in hardware driver with a compiled module. If someone with more Linux kernel experience than I wants to take a crack at it then by all means...
Do we really need busybox to uses this?
tbaker077 said:
Do we really need busybox to uses this?
Click to expand...
Click to collapse
Busybox's insmod is a little more robust then the insmod that's on the Droid 2. You can try editing the file /etc/startup/smartass.sh to remove the references to busybox and see if it works; I just stuck with busybox since that was what worked for me when building this thing. I'd try it myself but I can't at the moment.
I'm running an experiment now to see how long this governor will take me. I charged my phone to 100% last night (really 100% and not just to when the charging light went off) and turned it off. I turned it on this morning and will let the phone run until 5% battery is left. At that time I'll take a screenshot showing how long the system has been up. A few guidelines:
ROM is Fission 2.6.1 which of course means Froyo. I've been thinking about switching to the leaked Gingerbread ROM but I've decided to wait a little longer
Data must remain on. I usually turn data off when I'm not using it but to get results closer to worst case I'll keep data on. The only time it will go off is when I turn on Wi-Fi at home.
No turning off the phone at any time nor plugging it in. I guess I'm going to be using Dropbox a lot during this to transfer files but I don't want to reset the time since plugged in at all.
No overclocking, underclocking, or undervolting. Clockspeed and voltage are stock.
Usage will be light to moderate. I tend to use my phones for calls, chats, and web browsing. I'll throw in some YouTube videos and maybe download Angry Birds.
No apps that try to maximize battery life. That means no SetCPU, Tasker, Superpower, etc. This is supposed to be about how well the smartass governor does for battery life.
Again, once I reach 5% I'll try to take a screenshot of how long the phone went without being recharged.
Spitemare said:
I took a look at this and found some stuff that might be encouraging.
The problem is the gorram encrypted bootloader. It's not easily possible to swap a built-in hardware driver with a compiled module. If someone with more Linux kernel experience than I wants to take a crack at it then by all means...
Click to expand...
Click to collapse
Is this difficult to swap in simply because of the nature of what we'd be switching out, or does the eFuse chip and whatever other protection play a role here? I would try compiling your modified code and putting it on my device, except I'm afraid there will be some protective measure or something like that would brick my phone if I try. That and the fact that I have no idea what libraries and stuff I would compile this against.
So unfortunately my phone rebooted halfway into the experiment so there is no screenshot for you all. I will say my phone made it just under 36 hours (6:30 Friday to 18:15 Saturday) on this governor. With some moderate internet browsing and way too many YouTube videos I'm quite happy with the outcome using this governor.
ZaneKaminski said:
Is this difficult to swap in simply because of the nature of what we'd be switching out, or does the eFuse chip and whatever other protection play a role here? I would try compiling your modified code and putting it on my device, except I'm afraid there will be some protective measure or something like that would brick my phone if I try. That and the fact that I have no idea what libraries and stuff I would compile this against.
Click to expand...
Click to collapse
I've already compiled the modified module and tried to load it. The phone just prevents it from loading since the hardware interrupts are already bound to the compiled in driver.
eFuse doesn't prevent new kernel modules from being loaded. Since a kernel module can alter almost anything not being able to change the kernel isn't too much of a problem. What a kernel module can't really do, however, is change device drivers. There's not a really clean way to unload a device driver module since it binds to hardware interrupts and you can't really unbind that once the phone is up and running. If you want to replace a device driver with an alternate module you have to load the module before the original module is loaded sometime during the boot process. With compiled in device drivers though that's not really possible.
Basically we're in a situation where we need to load an alternate version of the device driver in module form before the compiled in device driver binds to the hardware interrupts. That would take some sort of ramdisk containing the altered driver module and we can't do that with eFuse.
The other option would be to write a module that hijacks calls to the particular function in the device driver and replaces that call with an alternative. That's got loads of problems though and is potentially dangerous. It would take someone with a lot more kernel experience than I have to write such a thing.
I installed this and didn't see any improvement in battery life until I ran
Code:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
It said it was still ondemand. I checked scaling_available_governors and smartass was not in there, so I went ahead and installed the zip again... still doesn't work.
I went ahead and took a look at /etc/startup/smartass.sh. The permissions were right, so I ran /etc/startup/smartass.sh. I then checked /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and it was set to smartass.
Can anyone shed some light on why this script is not running on boot? I'm running the leaked Motorola Gingerbread ROM if that makes a difference.
Spitemare said:
The other option would be to write a module that hijacks calls to the particular function in the device driver and replaces that call with an alternative. That's got loads of problems though and is potentially dangerous. It would take someone with a lot more kernel experience than I have to write such a thing.
Click to expand...
Click to collapse
I see. I'm guessing the way to hijack said calls would be through directly modifying memory, right? That definitely is not something that sounds easy to do.
I tried running smartass.sh through an init.d script... still nothing. I actually had to make the /etc/init.d/ directory, so I figured that init.d scripts aren't supported on the Motorola Gingerbread rom... strange. I'll look for somewhere else where I can run stuff on startup.
Look for /etc/install_recovery.sh. That file is run by /init.rc if it exists. It's how the overclock stuff gets loaded on Fission. What the update.zip does is back up that file if it exists and then append /etc/startup/smartass.sh to the end. Just add the following to the end of /etc/install_recovery.sh if the update.zip doesn't add it:
Code:
/etc/startup/smartass.sh
guys...my phone sometimes freezes on the lockscreen....and I have to pull out the battery...the problem is that this happens with all roms, sense or not based....
what's going on?!
You may get more help if you provide a little more info, ie:
-Are you using a specific 3rd party launcher with roms?
-Are you using a custom kernel, and if so what are your settings?
-Have you tried running in safe mode to rule out 3rd party apps?
-Did this problem begin after anything in particular you can think of?
-etc....
Maybe too low CPU values?
Undervolt can cause this as well.
It happened to me while using APEX on ARHD.
But indeed more info is needed.
this started a week ago...with miui official/faux kernel and now with aokp b38/tamcore kernel....I know tamcore kernel is undervolted, and don't know nothing about faux's one...
I use nova launcher, setcpu is set at 384/1188 and I have a profile screen-off at 192/432...
uh, forgot, I use SIO scheduler...I set it with no frills and uninstalled it after, to have just one cpu control app (setcpu)...
this morning my alarm didn't ring! then I had to pull out the battery because it was freezed...luckily I woke up by myself this morning XD
I recommend to use a higher off-screen value (384 MHz) as a first try. See how it reacts and also use an app to check the current voltage (like system tuner / st pro).
If this does not helps then start isolating apps.
I have NOOP sched and 384-432 Off-screen and had no issues far, but I remember that with 192 Mhz a while ago the screen did not wake up a few times (on ARHD 6.3.x).
I updated to b39, nothing now....if it freezes i'll try setting a higher minfreq...
thank you all! thx+1
Hello. I have been a "lurker" on these boards for roughly 2 years. I have rooted, flashed and installed custom ROMs, bootloaders, recoveries and radios on the following devices:
Samsung Vibrant (original samsung galaxy S)
HTC Amaze (a.k.a Ruby.... wire trick and all)
ASUS Transformer 1 WiFi Only model ( a.k.a TF101)
Anyway, I am posting for the first time. Because of this, I cannot post directly to the development thread involved with my issue. Never the less, here it is:
I am running RaymanFX's JellyBean Cyanogen 10 V6 (STABLE) with Rayman's custom kernel on my TF101. I was running a Revolver ICS ROM prior to installing this JB ROM.... or Revolution HD, I can't remember... anyway
I am having an issue with the TF101 either 1) involuntary reboot or 2) freeze/lockup/crashing after wakeup from sleep mode and complete loss of WiFi radio.
Yes, I have extensively searched the development threads and I found posts related to this one, but none of them solve the issue and I also noticed a few people have this same problem but have no known solution.
I have wiped and done clean install of this ROM several times always with the same result. I also flashed LiquidSmooth (Rayman worked on this ROM and his kernel is cross compatible) to see if it was ROM-related and discovered it is not.... this is a kernel issue. My wipe procedure is:
Factory Reset (cache/data wipe)
Run Superwipe script for TF101 from Android Revolution HD thread (format cache, data, etc...)
Wipe Dalvik Cache
Flash ROM
Reboot
Flash GAPPS (latest version linked on Cyanogen thread from goo.im)
Reboot
Everything runs buttery smooth and flawlessly, HOWEVER.... "Wake on WiFi fix" solution on RaymanFX's post does not work for me.
The "fix" is to designate WiFi Always On during Sleep. Changing this setting doesn't stick... WiFi still sleeps even with this setting corrected. With one caveat... Changing the setting to "Never" and then modifying WiFi Idle Timeout to "3 hours" and then changing the Keep WiFi on During Sleep to "Always" will delay the WiFi from idling out temporarily unless the tablet is in Sleep longer than 3 hours.... at which it idles anyway and causes a crash or reboot.
Secondly, I have discovered that the CPU Frequency setting under Performance could be part of the reason it crashes. I have "Set on Boot" enabled. Setting a CPU Frequency, regardless of governor, above 1408 Mhz WILL cause tablet to lockup/crash upon wakeup from Sleep as the processor jumps to maximum set frequency. If maximum frequency is set to 1408, it will stutter and lag out the system forcing it to become unresponsive to touch commands but "stable" and useable.... albeit very laggy. If the Max Frequency is set to 1200, it will NOT reduce the maximum frequency set for the CPU unless tablet is put into Sleep mode and then woken again.... it will constantly cycle between the "old" maximum frequency setting and the "new" maximum frequency setting (observed by monitoring the frequency in the Performance setting screen after changing from a higher max frequency to a lower max frequency and staying on the menu screen and allowing the CPU to "settle" without any user input).
I really like this ROM and I hate to give up on it, so I'm hoping someone out there will have an idea about what I can do to make this work... or at least recommend a different kernel that will work with this ROM and also has a way to change CPU frequencies and governers.
Any ideas?
Problem Reproduction:
1. Boot the device.
2. No problems during normal usage or when charging.
3. Let the device go to sleep for a couple 2-4 hours
SOD:
When pressing the power button after opening the lid the screen turn on but instead is a black screen, device still seems operational, but screen does not come on, only happened two times since flashing and randomly with nothing I can pin-point it to have a theory from some research, but do not know if it is related.
RR:
Device not reboot unless reboot is initiated, TF101 is rebooting randomly during deep sleeps.
Neither RR or Deep Sleeps occur when the tablet is charging or in active use.
Specifics
Tablet: TF101 Tab and Dock, 16 GB WIFI
Recovery: TWRP 2.3.2.3
ROM: EOS 4 Nightlies Build 99
Kernel: KatKernel_96_JB4.2_Lidpatch
Specific Customization Apps:
K.A.T_V1.2.7 - using KAT Audio, KAT Media Service, GPS fix installed, and adblock hosts file in place.
SetCPU - Profile 1 (screen-on priority 50): Overclocked to 1504Mhz with Smartassv2 govenor, min setting 312 MHZ (read some people do this prevent SOD and RR for the min setting)I/0 Scheduler SIO (also read on XDA others have been very stable with this setup). Profile 2 (Battery less than 38%, priority 75): Stock Max to 312 Mhz Min with conservative governor and SIO scheduler.
**Note: All SOD and RR have occured while SetCPU is in profile 1.
Ram Manager Pro: Minfree setting set to More RAM for devices with over 512MB Memory. JV Heap set to 64MB
Lux Dash: Used to fix auto-brightness setting being too low on transformers. Have it set to dynamic update brightness.
Other settings
Disabled Hotword detection for Google Now fix.
Removed test keys from build.prop and renamed SuperSU to SU in system/apps to get around the Root checks of the TimeWarnerCable live streaming app.
Background: My transformer was in on stock ICS OTA update and was so slow it was barely usable and used battery like crazy. I followed all the procedures on XDA (http://forum.xda-developers.com/showthread.php?t=2063406) and http://public.timduru.org/Android/tf101/eos4/ for wiping, i wiped and formated everything (dalvick, cache, system, factory)besides the externalSD card. Flashed the 99 nightly build and was impressed with how smooth everything was, was like a brand new tab. Did some bench marking and saw the good reviews on KAT kernel, so I flashed KAT kernel and installed KAT app and was even more impressed with performance, benchmarks jumped significantly. Tested everything I could think possible and did not see any major bugs so I figured this would be a good settling point. I did not re-install any of my apps from the Titanium or My Backup Pro or system settings, i installed everything from the market and configured systems settings, after I stopped all the update activities that when I noticed the SOD and RR issues (due to android assistant showing startup times when I had not initiated a reboot). Two days or so ago I installed Reboot Logger to keep track of the RRs. I noticed one SOD on the 18th after 2 hours of inactivity and one on the 19th around the same amount of time of inactivity. There was four RRs on the 19th and two on the 20th. Last night I was doing some digging and saw a bunch of feedback for JB on disabling the location services in setting and app settings, so I implemented that last night as well as removed the dock SD card after before leaving the device in a state of inactivity. After those two changes there was only two RR vs the four the prior day (Although if this is a semi-fix it is a pain not being able to use auto-location for apps) and no SODs again YET.
Let me just say that I love the ROM and KAT Kernel and KAT app, I am extremely impressed with all of it with the way to performs and how buttery smooth it is compared to stock. Lots of Kudos to the developers. If possible I would like to leave KAT Kernel in place because of the performance benefits. If I could get eliminate or minimize the SOD and RRs to an extreme minimum this would be a perfect/Rock solid solution. Attached are the Kmsg and logcats before the last RR and a screenshot of the RR from the Reboot Logger (note the RR/soft boots do not have a restart timstamp next to them, the ones that do are initiated reboots. .
Do you think the latest preview (175) or nightly 100 help the SODs or RRs? Also since the previews are compiled in Linaro and this is the native format for the TF101 be slightly more stable (I did a lot of digging on XDA but could not find a lot one way or the other to justify one direction or another), any empirical data from testing? Just curious. Thanks
Turning on Fsync in KatKernel
pursleyt said:
Problem Reproduction:
1. Boot the device.
2. No problems during normal usage or when charging.
3. Let the device go to sleep for a couple 2-4 hours
SOD:
When pressing the power button after opening the lid the screen turn on but instead is a black screen, device still seems operational, but screen does not come on, only happened two times since flashing and randomly with nothing I can pin-point it to have a theory from some research, but do not know if it is related.
RR:
Device not reboot unless reboot is initiated, TF101 is rebooting randomly during deep sleeps.
Neither RR or Deep Sleeps occur when the tablet is charging or in active use.
Specifics
Tablet: TF101 Tab and Dock, 16 GB WIFI
Recovery: TWRP 2.3.2.3
ROM: EOS 4 Nightlies Build 99
Kernel: KatKernel_96_JB4.2_Lidpatch
Specific Customization Apps:
K.A.T_V1.2.7 - using KAT Audio, KAT Media Service, GPS fix installed, and adblock hosts file in place.
SetCPU - Profile 1 (screen-on priority 50): Overclocked to 1504Mhz with Smartassv2 govenor, min setting 312 MHZ (read some people do this prevent SOD and RR for the min setting)I/0 Scheduler SIO (also read on XDA others have been very stable with this setup). Profile 2 (Battery less than 38%, priority 75): Stock Max to 312 Mhz Min with conservative governor and SIO scheduler.
**Note: All SOD and RR have occured while SetCPU is in profile 1.
Ram Manager Pro: Minfree setting set to More RAM for devices with over 512MB Memory. JV Heap set to 64MB
Lux Dash: Used to fix auto-brightness setting being too low on transformers. Have it set to dynamic update brightness.
Other settings
Disabled Hotword detection for Google Now fix.
Removed test keys from build.prop and renamed SuperSU to SU in system/apps to get around the Root checks of the TimeWarnerCable live streaming app.
Background: My transformer was in on stock ICS OTA update and was so slow it was barely usable and used battery like crazy. I followed all the procedures on XDA (http://forum.xda-developers.com/showthread.php?t=2063406) and http://public.timduru.org/Android/tf101/eos4/ for wiping, i wiped and formated everything (dalvick, cache, system, factory)besides the externalSD card. Flashed the 99 nightly build and was impressed with how smooth everything was, was like a brand new tab. Did some bench marking and saw the good reviews on KAT kernel, so I flashed KAT kernel and installed KAT app and was even more impressed with performance, benchmarks jumped significantly. Tested everything I could think possible and did not see any major bugs so I figured this would be a good settling point. I did not re-install any of my apps from the Titanium or My Backup Pro or system settings, i installed everything from the market and configured systems settings, after I stopped all the update activities that when I noticed the SOD and RR issues (due to android assistant showing startup times when I had not initiated a reboot). Two days or so ago I installed Reboot Logger to keep track of the RRs. I noticed one SOD on the 18th after 2 hours of inactivity and one on the 19th around the same amount of time of inactivity. There was four RRs on the 19th and two on the 20th. Last night I was doing some digging and saw a bunch of feedback for JB on disabling the location services in setting and app settings, so I implemented that last night as well as removed the dock SD card after before leaving the device in a state of inactivity. After those two changes there was only two RR vs the four the prior day (Although if this is a semi-fix it is a pain not being able to use auto-location for apps) and no SODs again YET.
Let me just say that I love the ROM and KAT Kernel and KAT app, I am extremely impressed with all of it with the way to performs and how buttery smooth it is compared to stock. Lots of Kudos to the developers. If possible I would like to leave KAT Kernel in place because of the performance benefits. If I could get eliminate or minimize the SOD and RRs to an extreme minimum this would be a perfect/Rock solid solution. Attached are the Kmsg and logcats before the last RR and a screenshot of the RR from the Reboot Logger (note the RR/soft boots do not have a restart timstamp next to them, the ones that do are initiated reboots. .
Do you think the latest preview (175) or nightly 100 help the SODs or RRs? Also since the previews are compiled in Linaro and this is the native format for the TF101 be slightly more stable (I did a lot of digging on XDA but could not find a lot one way or the other to justify one direction or another), any empirical data from testing? Just curious. Thanks
Click to expand...
Click to collapse
Turned on Fsync in KatKernel for additional testing on SODs and RRs.
pursleyt said:
Turned on Fsync in KatKernel for additional testing on SODs and RRs.
Click to expand...
Click to collapse
1 RR while tablet was asleep, plugged in and charged to 100%.
Solved
pursleyt said:
1 RR while tablet was asleep, plugged in and charged to 100%.
Click to expand...
Click to collapse
After Upgrading to preview version 181 and turning Fsync on with K.A.T kernel the TF101 is 100% stable with no RR or SODs after 48 hours.
pursleyt said:
After Upgrading to preview version 181 and turning Fsync on with K.A.T kernel the TF101 is 100% stable with no RR or SODs after 48 hours.
Click to expand...
Click to collapse
1 RR with SD CARD in dock, know problem with EO4/Kat Kernel removed SD card from dock when not in use, stable again.
pursleyt said:
1 RR with SD CARD in dock, know problem with EO4/Kat Kernel removed SD card from dock when not in use, stable again.
Click to expand...
Click to collapse
using preview 181 kk96 dock sd removed getting RR during sleep, I tried with fsync=on, rr's stopped but that prevented tab from entering deep sleep. now trying with microsd removed. still docked