Compiling custom kernels for P1.1 (with fiasco-gen) - Page 17 - maemo.org

PhonoN900 | # 161 | 2010-04-07, 13:36 | Report

Titan,

I have two (noob) questions:

If I use this custom kernel, will it delete all of my existing apps/settings?

When PR 1.2 comes out, will I still be able to update OTA?

Thanks for compiling this for the community, regardless of the answers.

Cheers and please advise,
Phono

NokiaRocks | # 162 | 2010-04-07, 13:42 | Report

None of your apps or settings will be deleted.

The Following User Says Thank You to NokiaRocks For This Useful Post:
PhonoN900

titan | # 163 | 2010-04-07, 13:49 | Report

Installing the kernel should not affect your apps or settings.
A backup before installation (and in general) is always recommend.
I don't have PR1.2 but it don't see any reason why it could break OTA.
it should be safe. In the worst case you can revert to the stock kernel before upgrading.
The OTA upgrade will overwrite the custom kernel.
If you want keep the custom kernel, make sure you reflash it immediately after
the OTA upgrade using "apt-get install --reinstall kernel-maemo kernel-flasher-maemo"

Originally Posted by PhonoN900 View Post

If I use this custom kernel, will it delete all of my existing apps/settings?
When PR 1.2 comes out, will I still be able to update OTA?

The Following User Says Thank You to titan For This Useful Post:
PhonoN900

PhonoN900 | # 164 | 2010-04-07, 15:30 | Report

Titan,

I've installed your kernel and successfully ran the oc command clocked @800mhz. It works, as reported by Conky.

However, it seems to be reverting back to 600mhz max after some period of time, without rebooting. It's just changing back of its own volition. I realize in your OP that you state it is not permanent, and will revert to the default upon reboot... But mine is doing it while running.

Have you or any other users noticed the same thing, with this kernel? Or is this just user error?

Thanks

titan | # 165 | 2010-04-07, 15:46 | Report

Originally Posted by PhonoN900 View Post

However, it seems to be reverting back to 600mhz max after some period of time, without rebooting. It's just changing back of its own volition. I realize in your OP that you state it is not permanent, and will revert to the default upon reboot... But mine is doing it while running.

this probably the dsme daemon setting it to the values in /etc/pmconfig.
so the only way to fix it permanently is to change the file.

The Following 2 Users Say Thank You to titan For This Useful Post:
evilJazz, mikhmv

BlackDiamond | # 166 | 2010-04-07, 16:12 | Report

Originally Posted by titan View Post

after an uptime of 30mins (only idling, with Conky and Terminal open, Wifi on, ssh connection)

1200000 0
1100000 0
1000000 0
950000 0
900000 0
850000 0
800000 0
750000 0
700000 0
600000 109312
550000 62
500000 3236
250000 5452
125000 58039

i.e. 600 MHz:62,42%, 550 MHz:0,04%, 500 MHz:1,85%, 250 MHz:3,10%, 125 MHz:32,60% (1265)

I have the same issue and I suspect some daemon from some installed app to make the CPU jump from 125 to 600 because the frequency gouvernor decide 125 isn't enough for it while it runs ok at 250.
Note that this is pure speculation.

PhonoN900 | # 167 | 2010-04-07, 16:32 | Report

Originally Posted by titan View Post

this probably the dsme daemon setting it to the values in /etc/pmconfig.
so the only way to fix it permanently is to change the file.

Well, that's a bit of a bummer.

Thanks for the feedback though.

Cheers,
Phono

mikhmv | # 168 | 2010-04-07, 16:46 | Report

I run >24h at 1000Hz. It is great.

For safe testing with /etc/pmconfig
I did following:
1. cp /etc/pmconfig /etc/pmconfig.bak
2. echo "cp -r /etc/pmconfig.bak /etc/pmconfig" >> /bootmenu.sh
3. edit /etc/pmconfig
4. reboot with closed keyboard. If device will not boot reboot with open keyboard....

The Following User Says Thank You to mikhmv For This Useful Post:
craftyguy

nightfire | # 169 | 2010-04-07, 19:11 | Report

Originally Posted by titan View Post

thanks. I'm also running it permanently on my device and it works flawlessly
(expect for the bug in the touchscreen calibration program).

not necessary. If I had severe ego problems I would switch to MeEgo

I just wish more users would vote for it (after testing) so that it can finally go to extras
to be accessible to more people.
Hopefully that would convince Nokia to add some its features to the stock kernel.

Ah, it's not an ego thing... it's always good to know contributed to / maintains various projects, and lots of custom kernels have been tagged over the years.

Anyway.. I didn't know about this voting thing. I just registered a garage account and voted it up. Do I need to do that each update?

Last edited by nightfire; 2010-04-07 at 19:14.

nightfire | # 170 | 2010-04-07, 19:19 | Report

In case anyone isn't following the overclocking thread (pretty high traffic), if you're looking for even more performance (at the potential cost of some battery life, though I haven't observed any diference so far), try this (copied from my post there):

Code:

echo 75 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
echo 150000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

By default, the ondemand governor is very aggressive about when it cycles up (waits for 95% load), and can have a significant latency of up to 300ms. This means if you saturate your CPU, your average wait for frequency increase is 150ms (0-300ms).

This change cuts that time in half, and lowers the bar for how much load is needed before committing.

It may affect battery life slightly (more frequent sampling, more aggressive cycle-up), but gives a yet more snappy feel. It may have no effect (or even lower battery consumption) by minimizing unneeded time at high cycle rates (responding to drop in load more quickly). Try it out!

If you want to make it permanent, just do this:

Code:

cat > /etc/event.d/ondemand-config << EOF
start on started xsession

console output
script
        echo 75 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
        echo 150000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
end script
EOF

In case anyone is wondering "why on started xsession?" .. it's because at some point late in the bootup, the ondemand scheduler is selected by something and I'm not sure what. When it's set, it resets the values. So I just wait a bit.

Perfect complement to any overclocking kernel.

The Following 21 Users Say Thank You to nightfire For This Useful Post:
ahmadamaj, Blaizzen, corecode, craftyguy, debernardis, deprecated, gabby131, geneven, iKneaDough, jamesla, Kurele, mdengler, Mentalist Traceur, moepda, PhonoN900, Scottlfa, Skaven2k2, thebtman, tiivonen, titan, zillertal