• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [ROM] CM7 TG-Reloaded (Final: 03-25)

Checked the past posts, let me know if this is known.

Items in the drop-down notification window sometimes freeze if I intentionally (or unintentionally) swipe them to the side. It is a useful feature if you want to get rid of a single notification, but not if it freezes the whole notification window.

Only fix I found was a restart. Anyone seen this?
Yes, this is a known issue.
 
Upvote 0
WhyKernel-02-08.zip

Uploaded a new kernel (02-08). The occasional "event" wakelock should be fixed. I looked at some other 2.6.37 kernels and found out 2 input events running together caused it (likely accelerometer, magnetometer, compass, microphone or some combination), it was only showing up as 'event2' and 'event4'. Now /proc/wakelocks confirms they're not active anymore.

Also I experimented with removing some Big Kernel Locks (lock_kernel) calls, by modeling after 2.6.37 kernels which have this old method phased out (in favor of smaller scale mutex-locks). It seems to have improved touchscreen reliability. But I've said this before & have been wrong, maybe these are all small incremental improvements, only really noticeable when switching back to a stock kernel.

I'd like to hear if anyone still encounters any of these issues:

1) "event" kernel wakelocks
2) freezing capacitive buttons
3) any other odd behavior that did NOT occur before this kernel (assuming you've ruled out any setting changes or new app installs)


2) freezing capacitive buttons

Yes, I do. It seems less common, but I'm not really sure.

I seem to have more idle drain than you have. maybe 10-15% over 6 hours or so with nothing but radio on. For some reason 2 hours before my alarm goes off in the morning it shows constantly awake. Maybe it needs that?? I'll try uninstalling and reinstalling it.
 
Upvote 0
WhyKernel-02-08.zip

Uploaded a new kernel (02-08). The occasional "event" wakelock should be fixed. I looked at some other 2.6.37 kernels and found out 2 input events running together caused it (likely accelerometer, magnetometer, compass, microphone or some combination), it was only showing up as 'event2' and 'event4'. Now /proc/wakelocks confirms they're not active anymore.

Also I experimented with removing some Big Kernel Locks (lock_kernel) calls, by modeling after 2.6.37 kernels which have this old method phased out (in favor of smaller scale mutex-locks). It seems to have improved touchscreen reliability. But I've said this before & have been wrong, maybe these are all small incremental improvements, only really noticeable when switching back to a stock kernel.

I'd like to hear if anyone still encounters any of these issues:

1) "event" kernel wakelocks
2) freezing capacitive buttons
3) any other odd behavior that did NOT occur before this kernel (assuming you've ruled out any setting changes or new app installs)

This kernel does fix the capacative buttons and is a God send. I am having a new problem though. My music does skip a lot now like a scratched CD. I listen to music all the time as I'm walking to and from classes and this hasn't happened ever before. I've had no installs or added any new music or any other data to my phone since trying to use this kernel.

And I have confirmed that it's every song, not just a few. And the longer I am listening to my music the more it's occuring.
 
  • Like
Reactions: tastytoast
Upvote 0
I seem to have more idle drain than you have. maybe 10-15% over 6 hours or so with nothing but radio on. For some reason 2 hours before my alarm goes off in the morning it shows constantly awake. Maybe it needs that?? I'll try uninstalling and reinstalling it.

Probably a background app or service. I would start with Settings - Applications - Running Services to start the investigation. And the phone should not need to be awake for the alarm to go off. Rewipe alarm app cache, recovery mode cache & dalvik-cache, or a clean reinstall.

This kernel does fix the capacative buttons and is a God send. I am having a new problem though. My music does skip a lot now like a scratched CD. I listen to music all the time as I'm walking to and from classes and this hasn't happened ever before. I've had no installs or added any new music or any other data to my phone since trying to use this kernel.

And I have confirmed that it's every song, not just a few. And the longer I am listening to my music the more it's occuring.

I just tested playing about 5 MP3 songs with screen off without problems. Sounds like you're using a governor that locks to min frequency when screen is off. Change your CM Settings - Performance to 245-1024 Interactive governor to see if that fixes it. Or try wiping the music app's cache or wipe cache & dalvik-cache again in recovery mode. Also titanium restores can cause problems, so a clean install may be needed if all else fails.
 
  • Like
Reactions: tastytoast
Upvote 0
10%-15% over 6 hours? WHAT THE HELL I'd be lucky to have over 30% in that amount of time.... CM9 seems to do it better, or maybe the app that was causing it is gone.

I typicly come home with around 50% batt life after having my phone on, with some texting, some web brousing, maybe a game while I have my post-lunch time.

My wife has her emails pushed to her phone and it murders her battery, well before JD. If you have WiFi on all of the time, that'll do it too.

There's a post on batt saving tips <http://androidforums.com/motorola-triumph/461571-guide-triumphant-battery-tips.html>here
 
Upvote 0
Probably a background app or service. I would start with Settings - Applications - Running Services to start the investigation. And the phone should not need to be awake for the alarm to go off. Rewipe alarm app cache, recovery mode cache & dalvik-cache, or a clean reinstall.



I just tested playing about 5 MP3 songs with screen off without problems. Sounds like you're using a governor that locks to min frequency when screen is off. Change your CM Settings - Performance to 245-1024 Interactive governor to see if that fixes it. Or try wiping the music app's cache or wipe cache & dalvik-cache again in recovery mode. Also titanium restores can cause problems, so a clean install may be needed if all else fails.

Thanks Whyzor. Coincidentally I was just listening to music today (I still have the 2-02 TG-R installed) and noticed the scratching while listening to mp3s. Was running 61-1024 clock and pushed it up to 122-1024. Confirming the mp3's scratching is minimized. 245 eliminates the scratch.
 
Upvote 0
Thanks Whyzor. Coincidentally I was just listening to music today (I still have the 2-02 TG-R installed) and noticed the scratching while listening to mp3s. Was running 61-1024 clock and pushed it up to 122-1024. Confirming the mp3's scratching is minimized. 245 eliminates the scratch.
Mine's about the same. If i push it down to 61, music starts skipping.
 
Upvote 0
10%-15% over 6 hours? WHAT THE HELL I'd be lucky to have over 30% in that amount of time.... CM9 seems to do it better, or maybe the app that was causing it is gone.

In the process of upgrading to CM9, you factory reset, which cleared out any clutter from old apps. If you factory reset on CM7, you'd probably get just as good, if not better battery life.

Thanks Whyzor. Coincidentally I was just listening to music today (I still have the 2-02 TG-R installed) and noticed the scratching while listening to mp3s. Was running 61-1024 clock and pushed it up to 122-1024. Confirming the mp3's scratching is minimized. 245 eliminates the scratch.

Mine's about the same. If i push it down to 61, music starts skipping.

You two probably have a min freq locking governor, which I don't recommend. I use 61-1024 interactive and no need to mess with the lowest value, it AUTOMATICALLY scales up to enough speed for whatever load is required. For example if 61 is not enough with no background apps running, it'll automatically bump it up to 122 if I'm downloading something in the background. Locking min frequency sounds good and gives you control, but really unnecessary. Phones with screen off should be in deep sleep. Locking it to a low awake frequency just prevents any apps/service that needs to run from running properly. The correct solution is to disable that app/service from running if that's the intention.

whyzor, this kernal... too good. we dont deserve it.
its like cocain infused.

edit: holy moses typing accuracy has shot over 9000!

lol, yes that's an interesting analogy. I believe the BKLs (Big Kernel Locks) in some of the input processing held back the kernel from true multi-threaded processing. Which is why 2.6.37+ phased it out. I just implemented some of it in the input area for the 02-08 kernel, also have done more of it in the filesystem area, which shows even more improvement (next version). It requires extensive testing though because simultaneous locking problems are rare and appear "random" if/when they occur. Which is why I want to get extra testing done before releasing it in the main ROM.

For those curious, this article talks more about the demise of BKL:

https://www.linux.com/learn/tutoria...ux-2639-ding-dong-the-big-kernel-lock-is-dead
 
Upvote 0
You two probably have a min freq locking governor, which I don't recommend. I use 61-1024 interactive and no need to mess with the lowest value, it AUTOMATICALLY scales up to enough speed for whatever load is required. For example if 61 is not enough with no background apps running, it'll automatically bump it up to 122 if I'm downloading something in the background. Locking min frequency sounds good and gives you control, but really unnecessary. Phones with screen off should be in deep sleep. Locking it to a low awake frequency just prevents any apps/service that needs to run from running properly. The correct solution is to disable that app/service from running if that's the intention.
Hm, that's interesting, because I also use interactive (per your suggestion) and it still does it. Even if I'm just playing music and doing nothing else, it does it. I have to keep my min at 122 to prevent it.
 
Upvote 0
hey so i got a wake locj all night long after the kernal upgrade. how do i check current kernal installed? i can only see current version.

CPU Spy app will show the build date of the kernel. Or in terminal emulator 'uname -a'.

Hm, that's interesting, because I also use interactive (per your suggestion) and it still does it. Even if I'm just playing music and doing nothing else, it does it. I have to keep my min at 122 to prevent it.

Yeah that's a bit odd. What kinds of music files and which music player? I just use the old default music app (not the new Google Music) and regular constant bit-rate mp3s. Maybe other apps or codecs require higher CPU.
 
Upvote 0
I hate to say it but I seemed to have gotten a frozen capacitive button. I put the kernel on 2/8 and everything was fine. Just now I pulled down the notification page, right swiped one of the things (yes I know this can freeze the notification page) and then hit the Back capacitive button. Typical thing, nothing happened and had to wait 4-5 seconds. Then it all worked. Tried the same procedure again and this time no problem with the back capacitive button.

Sorry. Would love to have this fixed. Things do seem faster/smoother/better generally though. I'll try to help if there is any other info you require.

WhyKernel-02-08.zip

Uploaded a new kernel (02-08). The occasional "event" wakelock should be fixed. I looked at some other 2.6.37 kernels and found out 2 input events running together caused it (likely accelerometer, magnetometer, compass, microphone or some combination), it was only showing up as 'event2' and 'event4'. Now /proc/wakelocks confirms they're not active anymore.

Also I experimented with removing some Big Kernel Locks (lock_kernel) calls, by modeling after 2.6.37 kernels which have this old method phased out (in favor of smaller scale mutex-locks). It seems to have improved touchscreen reliability. But I've said this before & have been wrong, maybe these are all small incremental improvements, only really noticeable when switching back to a stock kernel.

I'd like to hear if anyone still encounters any of these issues:

1) "event" kernel wakelocks
2) freezing capacitive buttons
3) any other odd behavior that did NOT occur before this kernel (assuming you've ruled out any setting changes or new app installs)
 
  • Like
Reactions: dalem50 and Whyzor
Upvote 0
CPU Spy app will show the build date of the kernel. Or in terminal emulator 'uname -a'.



Yeah that's a bit odd. What kinds of music files and which music player? I just use the old default music app (not the new Google Music) and regular constant bit-rate mp3s. Maybe other apps or codecs require higher CPU.

Hello Whyzor! just wanted to register and let you know that I really like this ROM of yours.

I have been upgrading my phone with every build of yours and with each build I can see vast improvements so please keep up the good work.

I have a question for the WhyKernel-02-08.zip. I am trying to install this like I do with every build and that is by going to clock work mod recovery. I tried to install it twice and both times it stated that install was successful but when I go to terminal emulator and type 'uname -a' it states that the kernel is still 2.6. Am I missing something here? Sorry for the noob question. I guess i will download the zip again and try once more.

Again, thank you for all your hard work, Whyzor!
 
Upvote 0
I have a question for the WhyKernel-02-08.zip. I am trying to install this like I do with every build and that is by going to clock work mod recovery. I tried to install it twice and both times it stated that install was successful but when I go to terminal emulator and type 'uname -a' it states that the kernel is still 2.6. Am I missing something here? Sorry for the noob question. I guess i will download the zip again and try once more.

The 2.6.32.9 is the linux kernel that our kernel is based on. Motorola/Huawei made a lot of modifications to it too. What changes for this ROM is the build date, the kernel version won't get updated because it's not official linux versions.
 
  • Like
Reactions: Cyta
Upvote 0
I am extremely happy with this ROM and all the effort it took to get here. There are currently two issues I have experienced that are not as good as prior ROMs.

1. I have had phone calls that get interrupted by repeated vibration. My guess is that it is related to the proximity sensor, because I can usually stop the problem by holding the phone away from my face briefly.

I have tried changing settings related to calls, but have not found anything that effects this issue.

I use the phone in my left hand, and have that option set. I don't think my GO Launcher use would contributing anything here. I don't overclock, but do allow 61 Mhz, and use smartass2.

I can't think of anything else different about my setup. Am I alone with this issue?

2. The only other thing I notice that nobody else seems to mention is a slow to start wifi. I haven't timed it but I believe it takes about 20 seconds from request to start until ready. On the TG builds it seemed 2 or 3 times faster. At one time I had juice defender installed, perhaps it left me with this issue?

Once I get around to flashing the Cm9 alpha, I will test both issues out from a clean install.
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones