BTW won't this be a battery whore? Well the script gets stuck into an infinite loop...

All I can say is, I wish my device acted that way. I can tell you, I've literally gone from replacing a battery, doing a power-up, and seeing this happen within 45 minutes. There are several others reporting similar experiences.

The funny part is that until PR1.3 I only had this happen once or twice at most, and wasn't sure what was causing it. After the PR1.3 update it started happening several times a week, though my usage patterns did change around the same time, so it may be I just wasn't tasking it enough to cause the issue.

No, it won't.. There's a sleep command in there to sleep for a specified time. The script has been running for a day on my device, it's used 1106 units (or jiffies). The CPU has produced 12007528 jiffies. That's less than 1/1000% of the CPU use.

Will this be in extras-devel repository?

No, it's a shell script. Basically a text file. Not really worth building a whole package for and setting up a developer account.

Once I get my dev environment setup, if I make this into a real program, I'll make one though. I didn't want that delay holding up releasing something quick though for people to use until a real solution is out. Hopefully Nokia will fix this and there will be no reason to make such a package. (And pigs may fly, and glittery rainbows may shoot from my bum... just as likely.)

For now you can download it from the first post and just run it (as root).

How can I run this script as root?

I can type in X Terminal "sudo gainroot" and then "./script" to start it, but then this script will be stopped as soon as this X Terminal window is closed, will not it?

I would like to run it at startup, if possible. Can it be done?

I just have hit the bug, at least the third or maybe fourth time.

When you are looping and there is nothing suspicious, can you store in memory last 30/60 seconds of dmesg output so that when there is something suspicious you dump logs from recent past into the file, and the human can later read dmesg logs of what happened before the problem and could be its cause?

http://ibot.rikers.org/%23maemo/20100128.html.gz

What's the way to resolve the problem, besides taking out the battery?

EDIT: I'm trying to reproduce the bug (with help of Modrana, USB internet, cellular connectivity, FIlebox, Leafpad and Fennec), but get [sgx_misr] CPU usage only around 0.2-0.4-0.5-0.6-0.7.

You almost have it right. What you need to do is start and Xterm and do:
That way it runs in the background, even after xterm closes.

The simplest way to do it is to use QueenBee to run it at startup via one of the widgets. I tried putting it into the startup area, but kept having issues of it either not finding the graphics driver process ID, or not liking the fact that it was a shell script.

The QueenBee wiki has examples of how to make a widget start something at system boot, and it's totally happy with running scripts, including running them as root.

That's the problem with this bug. It's not simple to reproduce, though it happens more often it seems when the system is burdened and/or navigating. I found that most of mine are triggered when all of the following is happening:

A high cpu app (modRana/microb/flash) is running
The network active (gprs or wifi)
An SMS arrives while all of the above is going on.

Oddly, I've not been able to get it to do it recently, but have had other issues. I've also had my SMS log corrupted by this, and now have some other odd side-effect issues affecting glogarchive and my SMS service. So I'm near the verge of re-flashing to fix that...

dmesg actually keeps a pretty good log of things in memory already. You could easily add that to the script to dump the current dmesg info into the log (just dmsg >> output.log). That's one of the nice parts of it being a script, it's easy to update and add new things.

A reboot is enough to do it for me... and the script is nice in that it at least reboots the system so it doesn't drain the battery as much. Sucks that rebooting seems to be the only way to fix it right now, but better a warning/reboot than a dead battery.

I just read from the modRana-thread that the next version will have an improvement (a bug fix really) that modRana will not update graphics when the application is minimized or the screen is blanked.
This drawing to the screen when not necessary is one of the reasons Nokia people have given why this graphics driver spinning may happen.

It's one they've been giving, but I've had it happen when the phone was completely idle. It may happen more often when that's going on, but it's not the only factor. The main factor in my case seems to be that every time it happens, it's as a new SMS comes in (but the SMS is not displayed or signaled until after the reboot). This doesn't happen with every SMS, but it does happen as a result of it.

Any improvement to modRana is a good thing though, as I do love that program and use it regularly.

Quick reply...
dmesg doesn't have long enough logs. After reboot I cannot see the SGX errors in the log. The oldest lines are about the last reboot. Booting process writes so much lines in dmesg.

I'm going to put dmesg logging into the script.

Does dmesg >> output.txt overwrite output.txt or add new lines to it?

And how can I filter out lines containing "slide" or "kb_lock"?