My fedora 10 laptop routinely "freezes". That means the menu's and applications don't respond to mouse clicks. After a few seconds (or sometimes many seconds) it frees up and works normally again. If I look at the cpu consumption graph I can see that something had the processer pegged at 100% but what? during the episode there is no way to switch to top or the ksysguard process list because the system is unresponsive. So how do I find out what caused the lockup? wcn
On Wed, 2010-02-24 at 10:53 -0700, Wendell Nichols wrote:
My fedora 10 laptop routinely "freezes". That means the menu's and applications don't respond to mouse clicks. After a few seconds (or sometimes many seconds) it frees up and works normally again. If I look at the cpu consumption graph I can see that something had the processer pegged at 100% but what? during the episode there is no way to switch to top or the ksysguard process list because the system is unresponsive. So how do I find out what caused the lockup? wcn
Wendell,
There are a few options here but probably the easiest is to set top running with a long(ish) time between updates -- something like "top -d 30". When your laptop unfreezes, go to the top window and see what's been sucking CPU.
-Chris
Wendell Nichols wrote:
My fedora 10 laptop routinely "freezes". That means the menu's and applications don't respond to mouse clicks. After a few seconds (or sometimes many seconds) it frees up and works normally again. If I look at the cpu consumption graph I can see that something had the processer pegged at 100% but what? during the episode there is no way to switch to top or the ksysguard process list because the system is unresponsive. So how do I find out what caused the lockup? wcn
Here's a possibility.
$ while true; do date>>time.log; ps g -f --sort=utime,stime | head -n 3
time.log; sleep 1; done
As root, use renice to set the process to run at high priority; it might help. Perhaps you'll need to use nice in the loop to force things to run.
That file will grow fairly rapidly, so you might want to set up another one to delete the file once an hour or day or so. You may want or need to tweak the number of lines you capture, and how often it runs.
When an "event" occurs, you could kill the process, and
$ tail -n 24 time.log
to see the last 6 entries. To look at other entries, you could use something like
$ tail -n 40 time.log | head -n 24
if you've got a few at the end to omit. The example shows you what happened 10 seconds ago. This might save time loading it into a text editor or whatever.
$ tail -n 80 time.log | less
Might be good. Anyway, once you've got the data, you'll think of ways to proceed.
Crude, but it may get you what you want.
You got the suggestion to run top, but running top in batch mode results in a very rapidly growing log file, possibly too rapidly. I don't know of a way to limit the output top produces.
Mike
Mike McCarty wrote:
Wendell Nichols wrote:
My fedora 10 laptop routinely "freezes". That means the menu's and applications don't respond to mouse clicks. After a few seconds (or sometimes many seconds) it frees up and works normally again. If I look at the cpu consumption graph I can see that something had the processer pegged at 100% but what? during the episode there is no way to switch to top or the ksysguard process list because the system is unresponsive. So how do I find out what caused the lockup? wcn
Here's a possibility.
$ while true; do date>>time.log; ps g -f --sort=utime,stime | head -n 3
time.log; sleep 1; done
As root, use renice to set the process to run at high priority; it might help. Perhaps you'll need to use nice in the loop to force things to run.
That file will grow fairly rapidly, so you might want to set up another one to delete the file once an hour or day or so. You may want or need to tweak the number of lines you capture, and how often it runs.
When an "event" occurs, you could kill the process, and
$ tail -n 24 time.log
to see the last 6 entries. To look at other entries, you could use something like
$ tail -n 40 time.log | head -n 24
if you've got a few at the end to omit. The example shows you what happened 10 seconds ago. This might save time loading it into a text editor or whatever.
$ tail -n 80 time.log | less
Might be good. Anyway, once you've got the data, you'll think of ways to proceed.
Crude, but it may get you what you want.
You got the suggestion to run top, but running top in batch mode results in a very rapidly growing log file, possibly too rapidly. I don't know of a way to limit the output top produces.
Mike
Thanks everyone for your input. In the end I did a: while [ 1 ] do date ps -eo pcpu,pid,user,args | sort -k 1 -r | head -10 sleep 2 done
I ran that script with its output redirected to a log. My machine then acted up (badly) and I was able to see that udevd was using 50% (one whole core) and a bunch of kde apps were unusually elevated ... in the 12-20% area. The machine ran like that for half an hour and finally thermaled off. I had to cool it with a fan to get it restarted! To make a long story short it seems to happen when I plug my blackberry in to charge! I've seen some chat around the net and the fault is probably with the berry_charge module. I will find an electrical socket to plug that piece of junk into... (its only working function is to prematurely terminate conversations anyway). Thanks again... wcn
On Wed, 2010-02-24 at 13:42 -0700, Wendell Nichols wrote:
To make a long story short it seems to happen when I plug my blackberry in to charge!
It seems silly to use a $1000 computer to charge up something, instead of a $20 battery charger.
Considering that so many things use USB incorrectly (e.g. expect full power without negotiation, expect to be able to draw more current than the spec allows, etc.), I really dislike self-powered USB devices, and despise things that use USB merely as some sort of power supply.