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

Root [KERNEL] TheOC v1.7.20 kernel for MT Isaac & TG based CM7

New-Year.png
 
I want to write some scripts to run on my phone so I can test my settings while I'm sleeping. I use my phone for an alarm, witch was nasty the other morning. It went off while my phone was locked to 64MHz. Try it! Not a healthy noise. I couldn't unlock the phone, so I ran out to the living room and eventualy had to pull the battery. Well, I had the idea if I could run a script, I could set it to end the test, change the processor speed, what ever. I've written some scripts before, but I don't know where to look to change the processor speed, or if I could end stability test by command. google that in a moment

I know you guys know your way around theese kernels, I thought I would ask. May even be of some use:rolleyes:
 
I emailed the developer of stability test, he said the app can't respond to commands from the terminal. He did say it's due for an update though. I have him the suggestion of a scedual and maybe a limiter with the Battery.:D
 
I want to write some scripts to run on my phone so I can test my settings while I'm sleeping. I use my phone for an alarm, witch was nasty the other morning. It went off while my phone was locked to 64MHz. Try it! Not a healthy noise. I couldn't unlock the phone, so I ran out to the living room and eventualy had to pull the battery. Well, I had the idea if I could run a script, I could set it to end the test, change the processor speed, what ever. I've written some scripts before, but I don't know where to look to change the processor speed, or if I could end stability test by command. google that in a moment

I know you guys know your way around theese kernels, I thought I would ask. May even be of some use:rolleyes:

I think running stability test at a frequency for more than 30 minutes is really not necessary. If it hasn't crashed or detected errors in 30 minutes, it probably won't at longer times.
 
I think running stability test at a frequency for more than 30 minutes is really not necessary. If it hasn't crashed or detected errors in 30 minutes, it probably won't at longer times.

Eh, the app it self said that it may take hours. And with the scaling test and the large number of steps from 64MHz to 1.4GHz it doesnt hurt to run while I get my beauty sleep:cool:
 
Mantera, have you seen this:

https://github.com/tjstyle/FIH-Kernel-MSM7x30/blob/android-fih-2.6.32.9/History_LINUX.txt

It seems to have a lot more recent updates than the one used by our kernel. There may even be an updated 2.6.35 kernel out there too that works on the MT. This dev is the guy that made the Android-ID ROM that works on the MT except for radio is for GSM.

I was thinking of digging in some time & merging all the updates to our kernel, but since I'm still new to github it may take me a while.

UPDATE: Turns out most of the changes may not affect the MT, but a few are worth looking into.
 
No, I haven't really had much of a chance lately to look into it. What kind of stuff do you see that is interesting?
 
HAVS hasn't been mentioned in a while, is there still a possibility of it being included?

remote possibility for now. Basically, there's a really bad bug in the current iteration of the havs code (at least as it works on the MT) which was causing the phone to reboot every time that it tries to go into deep sleep. So until I can figure that out (or somebody else does) then it won't happen.
 
No, I haven't really had much of a chance lately to look into it. What kind of stuff do you see that is interesting?

When I first looked through it, I noted these changes as of interest:

0.100.0532
0.100.0494
0.100.0475
0.100.0443
0.100.0435
 
With the fixes, have you tried leaving WIFI ON and set to disconnect when the phone goes to sleep? And does the phone wake up ok again after about half an hour of sleep?

And also when WIFI is set to Never sleep. Does it get the sleep of death and needing a batter pull? Used to take > 30 min of sleep before that happened.

Thanks.
 
With the fixes, have you tried leaving WIFI ON and set to disconnect when the phone goes to sleep? And does the phone wake up ok again after about half an hour of sleep?

And also when WIFI is set to Never sleep. Does it get the sleep of death and needing a batter pull? Used to take > 30 min of sleep before that happened.

Thanks.

I'll test that some time when I can leave my phone's wifi on for 30 min sleeping. This update doesn't change TG's intentional wifi wakelock which is still implemented (verified debug msgs). All I did was give it one set of Wifi and BT wake_lock structs to use consistently. Before it used host(mmc), which can be 0,1,or 2. So if mmc0 locked it, mmc2 later tries to unlock and it can't so left it around. The hard part about finding this was the wakelock was reported as MMC, not a more meaningful string like "wlan_lock" (which it is now).
 
changelog:
TheOCv1.7.19.zip
Just a small update
-kernel patched to version 2.6.32.21
-includes most of Whyzor's kernel updates
-uses Whyzor's latest touchscreen driver
-changed default io scheduler to sio
-changed default goveror to interactive
-using same gpu drivers as in cm9
 
sorry for the stupid question but id like to flash this to my MT running cm7 3/4 build and i was wondering how can i properly flash it? last time i tried it wouldnt boot past the boot logo.
 
sorry for the stupid question but id like to flash this to my MT running cm7 3/4 build and i was wondering how can i properly flash it? last time i tried it wouldnt boot past the boot logo.

There's no special procedure needed. Just flash it in Clockworkmod recovery the same as you would flash any other mod.

If you want, you can wipe the cache and Dalvik cache before flashing this kernel. Although, I've never done that and have not had any issues.
 
Mantera, I used to use this kernel.
What are the current differences between this and Whyzors current kernel, and what results would you expect when swapping with this one.
 
Mantera, I used to use this kernel.
What are the current differences between this and Whyzors current kernel, and what results would you expect when swapping with this one.

The main difference between this and Whyzor's current kernel is that this is patched up to 2.6.32.21 whereas his is at 32.9 still. If you are really curious to know what is actually in those patches, you can take a look on kernel.org at the patch logs for the 2.6.32.x kernel. Of course, you can also just take a look at my github to see what was actually changed, if you're so inclined.

Basically, the patches generally involve fixing a bug, adding a new feature, or improving an existing feature.
 
I added a test 1.7.20.zip file to the OP. This reverts the commit that tries to prevent 2 sensors from grabbing wakelocks. It looks like it's possible that when only one sensor is active, it may not be able to grab a wakelock.

Let me know if that helps.
 
I added a test 1.7.20.zip file to the OP. This reverts the commit that tries to prevent 2 sensors from grabbing wakelocks. It looks like it's possible that when only one sensor is active, it may not be able to grab a wakelock.

Let me know if that helps.

Yes! the screen comes back on when I pull it away from my ugly mug!

You're the man!
 
Back
Top Bottom