PDA

View Full Version : How to kill 99% CPU X process ?



sunset
1st June 2006, 05:38 AM
On a machine of mine, usually it runs in runlevel 3 as a smb file server. Today I tried to login at the console, as myself, then startx. The screen went black, but never got to the graphical prompt.

Other smb share users noticed that "it seems slow". I checked top and found similar to:

top - 14:13:24 up 8 days, 6:47, 1 user, load average: 1.00, 1.08, 1.14
Tasks: 103 total, 3 running, 100 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.3% us, 0.3% sy, 0.0% ni, 99.3% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 0.0% us, 100.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1034364k total, 1002116k used, 32248k free, 160700k buffers
Swap: 2048184k total, 120k used, 2048064k free, 476492k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26735 root 39 19 0 0 0 R 99.9 0.0 306:15.87 X
6750 root 16 0 2128 920 708 R 0.3 0.1 0:00.07 top
1 root 16 0 1696 564 476 S 0.0 0.1 0:01.02 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.61 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.51 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.65 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:01.35 ksoftirqd/1
6 root 10 -5 0 0 0 S 0.0 0.0 0:01.86 events/0
7 root 10 -5 0 0 0 S 0.0 0.0 0:00.37 events/1
8 root 11 -5 0 0 0 S 0.0 0.0 0:00.30 khelper
9 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
12 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
76 root 10 -5 0 0 0 S 0.0 0.0 0:00.06 kblockd/0
77 root 10 -5 0 0 0 S 0.0 0.0 0:00.03 kblockd/1
80 root 15 0 0 0 0 S 0.0 0.0 0:00.00 khubd
136 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush


Since the machine is dual CPU, the machine still operates OK, since it seems to consume all the resources of only one of the two CPUs. (kernel-smp-2.6.12-2.3.legacy_FC3).

To fix this I have tried (remotely):
- kill 26735
- kill 9 26735
- ps aux|grep dm (no window manager running)
- service xfs stop
- init 3
- init 5
- init 1; init 3
- ctrl-alt-backspace at the console.
- runlevel {gives 1 3 as if it did it}
The only thing that seemed to succeed is was:
renice 19 -p 26735
which reduced the priority from 0 to 19, making the shares faster.

Other than the obvious reboot, any suggestions ?

Omega Blue
1st June 2006, 07:29 AM
ssh in as root, then issue 'kill -9'.

sunset
1st June 2006, 09:03 AM
I am sshed in and su root, when I have tried the above listed commands.
Do you mean I should do the above without a specific process ID ?
I have already tried: kill -9 26735
kill -9 by itself is not legit.
The machines uptime is only 10 days, it is usually months before it needs a reboot. Is there anything else I should try to nuke this X process ?

Omega Blue
1st June 2006, 09:57 AM
Send a hangup signal?

sunset
1st June 2006, 10:05 AM
as in?
# ps aux|grep X
root 26735 99.6 0.0 0 0 ? RN 09:05 594:06 [X]
# kill -s SIGHUP 26735
# ps aux|grep X
root 26735 99.6 0.0 0 0 ? RN 09:05 594:33 [X]

Still there :-( Next thing to try ?

InKo
1st June 2006, 11:52 AM
what graphic card do you have? there is a bug on nVidia cards as I know...

InKo
1st June 2006, 12:04 PM
sorry, I take my words back, it is not the nVidia...
it seems a general bug on Dell servers using ATI chipset...
https://www.redhat.com/archives/nahant-list/2005-November/msg00011.html
:)

sunset
1st June 2006, 12:09 PM
This machine doesn't have Nvidia: it's some ATI integrated server graphics.
# lsmod
Module Size Used by
radeon 79297 1
# lspci
04:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
Are there known problems with the Radeons ? This is the standard driver, rather than the proprietary one.

sunset
1st June 2006, 12:21 PM
Thanks InKo, at least I'm not alone with this problem. It is a Dell, I forget if it is an PowerEdge 1850, but given lspci gives same vga info, I think it may be. Time to check bugzilla and linux.dell.com...

InKo
1st June 2006, 12:23 PM
right. it is a good feeling: I am not alone.
Sometimes it feels better than a quickly solved problem! :D