Please don't use my image in a wrong context.
We I took that pic, I was using the original kernel from nokia.
I think the problem came from a defective or not well fixed cable between the screen and the motherboard.

The problem stopped 3 days after that photo and, one year later, I'm still using that phone, now with kp v50, sometimes with dsp profile to watch h264 vids. It works like a charm.

So yes, stop spreading FUD

powertop doesn't have anything to do with kernel-power. But, whatever...

// Edit

Thanks for straightening it, darodi.

Yeah the context is ambignous, but I believe the person quoted the picture had almost same effects onscreen. It seems like hardware bug which is not permanent (because it can be recovered later). Hardware bug nicholes had merged with some internals of KP50 or another root-app (it's mostly software which changes on the device - hardware rarely changes outside disk - and RAM state etc.rather belongs to software state) may triggered bug darodi had happened earlier/more_frequent.

Most people know that nokia devices are really hard to kill (although smartphones/tablets are somewhat more vulnerable than feature_phones/dumbphones), so it's possible that many N900 has nasty hardware bug which is not enough to kill/harm_seriously the device until some software bug happen (and the hardware bug doesn't have to be in all hardware revisions). However something as trivial as loose conections is also possible like darodi said. The problem may for example be also result of some power problems on some graphics-related chip which could be connected with KP50 as it were going to fix power-managment mechanism of N900. Still KP50 is not enough to kill the device - it needs some rare software/hardware state (but some hardware state needed to trigger may be common to some rare hardware revision of N900).

It's better to state "evrything is possible" than "KP is guilty" or "KP is completely unrelated to a problem". I advice people having problem check if another part of their N900 isn't faulty and know there may be something they overlooked. I also advice developers to not rapidly shoot doors if somebody suggest KP50 may be (one of) reasons hovewer the suggestion would sound dumb, because there things about N900 even pali and freemangordon doesn't know (eg. only nokians know such or even them not). On the other side I understand that freaky guy who killed his N900 by overclocking to 1500 and blame the KP50 is reaaally annoying.

If the device in question looks like the one posted above, it's almost definitely a hardware problem. And yes, heat could easily cause a connector to shift or come loose and allow for poor contact. Heat should never be ignored when it comes to computers. If you have a device that's overly warm or hot, find out why and fix it.

To the poster of the problem N900: Would you ignore your leg if it went numb if some random person on the street told you it was fine? Why not take a picture of what your device is actually doing. That may actually help you out instead of making you look like a douche for posting other peoples pictures, implying they're your own.

hey I discovered nasty bug in KP50 overclocking feature.
I used modified DSP profile with limits 500-900, and it seems it stick to 900 where there are absolutely no need (procesor usage were much under 30% all the time). I tried to fix it just by making profile more switchy (changed up threshold a bit, added substantial but not huge powersave bias, increased sampling rate a half). It was a bit successful - it switched between 720 and 900 most of the time and very rarely got 500/600. For me it's not a big problem since device now doesn't emit any heat which could be felt (name it device is cool), and it before apeared to emit a bit of heat which is enough to feel on stock clock (perhaps undervolting of KP50 helped me). But anybody getting limits upto 1150 would have serious problem - it would be 1150 most of the time, including not used, enabled device - which would substantialy reduce device life, and having it almost permanently on 1150 from full charge until full discharge is I believe enough to have overheat problems and even dmaging the chips (even if it could work well on 1150 for a half an hour without break).

So yes KP50 can break the device on dangerous but not stupidly dangerous overclock settings, because frequency switching don't work as it is said to be. On my side fine since I stopped at adviced limit of 900, even if I can go further. I would not mind the bug for now since the device works more nice, however I would wait for KP51 fixing the bug. I don't believe I have any apps/scripts/modules which would affect frequency switching aside of KP50. Since my device work suprisingly well It's possible that kernel-power-settings report bad values instead of values really beeing too heavy. I did a bit checking under powertop and checked that most offensive application were proximityd, which have to be installed for shortcutd but is useless for me so I disabled it under shortcutd's menu. I have a bit experience with overclocking since my PC has core duo overclocked from 1866 to 2520, including memory pushed up to the limit (since I have poor MB limit were much lower than one guaranted by producer of those kingston hyper-x) - note that core duo is one of best capable of overclock CPUs so I perhaps could go around 3200 but I not needed it so stayed safe (there's substantial gain and have no single instability because prime95 didn't show any errors after 8 hour test).

Back to topic: is there any logs or logmaking tools you want to me make it acquire logs to send you? Do you have any stresstesting application which would not only stress the machine but also well measure stability? I see no prime95 for ARM machines (maybe because it's FPU heavy) and the program is beloved because show substantial instability after seconds medium after minutes and after 12 hour test passed you may be sure there wouldn't be a single wrong calculated innstruction once a month (the algorithm for searching mersenne primes would always give known values - the first thousands of the primes - and it constantly uses values calculated before so it's much better for checking stability than those programs which loop calculation over reseted data again and again). I don't hope getting something same fabulous as prime95 but any good stability checking tools you know is welcome to be linked here - since I'd like to not have application crashed once a month due to small/medium instability due to overclocking. If I could check my phone @900 is fully stable (which is much more than "stable enough") and the KP50 bug would be fixed I may try higher limits (I prefer stable 900 than just working 1350, for sure, and very little noticeable unstability @1100 is enough for me to get upper limit under the frequency).

Anybody would comment or help? Any questions?

EDIT: Also memtest is only for x86, so any memory testing tool for N900 is also appreciated (the faulty memory or memory operation could be very annoying even while not overclocking and should be at least a bit checked before making decision if your device is for service/memory_replace) although I believe I have no problems with RAM. Hovewer it would help many other persons.
PS: do you intend memory overclocking or any overclocking features for another chips than cpu and mpu/dsp in future KP versions?

your current freq does not matter, if the cpu load is not high there cant be any overheating or damage
mine is also mostly "stuck" on 900MHz when looking on conky but since it is idle most of the time(2-3% load) there is no danger...

Can't confirm - I also use 500-900 limits (all the time) and it changes frequency as it should. BTW, I don't know what You guys got in your device, if looking @ conky gives You constant 900 - Mine is 4-6% @ 500 mhz, when only Conky opened. I occasionally jumps higher, during swap flushes etc, but only for a moment.

/Estel

To observe your CPU speed without the overhead of conky. Remember to ctrl+c quit before you close or it will run in the background keeping your CPU out of C4.

Okay sorry, the watch shows proper enough values. Seems the problem is with kernel-config showing wrong value as current or some copies of value aren' synchronised (eg. watch showing fine while some internal value beeing not fine).

Thanks for better measure then. My profile is so cruel so it rarely go to 900 even on tesplaying Another World on Dosbox (EGA, low sound quality settings) if watch results are correct. I'll try to change profile to less strict one and watch the results. Sorry for false allarm it seems - if watch value is valid test - it is a bug with another metters (I'll perhaps should use ssh login for the watch to get better results than switching back).

PS: the watch gives sometime not round value about 550Mhz, I wonder why it happen? It suggest precision of 1Khz (last digit was not 0) which normally won't be wanted result (we stick to round frequencies doesn't we?). I'll try to make some more tests while watch is enabled - I hope the problem is only "kernel-settings show" and/or another measures and I have OC working well while still having KP50.
EDIT: noticed it also around 805 and 850... hmmm

You can see how long your device has spent in each cycle since the last reboot by simply typing:
I run 500-900 and my results show:
900000 1280109
500000 16595596

So, I'm showing 16x more usage at 500 than 900.

If you want to see what it's really be up too (including idle time) then use this script, which shows how much it's spent at each level.