On 07/25/2009 12:12 PM, Marko Vojinovic wrote:
On Saturday 25 July 2009 08:52:43 Terry Barnaby wrote:
On 07/24/2009 10:40 PM, Bill Davidsen wrote:
Terry Barnaby wrote:
On 07/22/2009 02:07 PM, Paul W. Frields wrote:
On Wed, Jul 22, 2009 at 01:02:09PM +0100, Terry Barnaby wrote:
Hi,
I have noticed on several occasions, that running "kill -9<pid>" on
a GUI 3D process that is locked at 100% CPU usage (X-Server 100% also)
does not work. The 100% lockup I'm sure is due to the currently buggy
3D support (ATI in my case), but I am surprised that I cannot kill
either the GUI or X processes. Only a reboot appears to work.
Has something changed here ??
If you provide more details, such as the actual process you're
running, people might be able to try to duplicate the problem. I've
never seen an occasion where kill -9 didn't work, but that doesn't
mean it's not possible with some horribly written code.
The system in question is a dual Xeon system running Fedora-11 with
all updates
to 2009-07-22. Graphics board is an ATI RV280 [Radeon 9200 PRO].
I have some applications installed from rpmfusion including paraview.
Currently if I run paraview, X goes to 100% and I can no longer
operate the system via mouse/keyboard. Via a network login I
can "killall -9 X" but that does nothing to X. I have also
tried killing paraview in the same way with no effect (possibly
after trying to kill X).
I hope this is a typo, process "X" is long gone, the X process is called
"Xorg" now. I assume you had a finger check and actually killed the real
X process.
On F11 "Xorg" is hard linked to "X" and "X" is the program started.
So in "ps" listings the XServer process is named "X" and to kill it
with "killall" you need to do a "killall -9 X" ...
Or is it the other way around? :-)
I don't have F11 handy here, but on F10:
$ ll /usr/bin/X*
lrwxrwxrwx 1 root root 4 2009-06-20 04:04 X -> Xorg
-rws--x--x 1 root root 1844872 2009-05-25 00:45 Xorg
clearly says that X is the link to Xorg, which is the actual binary. Maybe
this is different in F11, but I don't see why would it be changed. However,
$ ps aux | grep X
root 3383 6.3 27.6 1097836 568064 tty1 Ss+ Jul24 132:32 /usr/bin/X -
br -nolisten tcp :0 vt1 -auth /var/run/xauth/A:0-4v23CU
means that ps lists out the name of the *link* rather than the name of the
actual binary. What I would do is prefer kill over killall, like
$ kill -9 3383
since PID is always unique.
All that said, forcibly killing a locked-up X usually *doesn't* give you back
control over the system, since main things that get locked up along with X are
graphics card, keyboard and mouse drivers. And those are typically part of the
kernel, and cannot be killed just so easy. Also, one cannot expect that -9
killing of X would gracefully reset all these drivers, and my experience is
that they remain hosed until a reboot.
What I believe the OP issue is about, it is not X that is locked up, it is the
radeon driver itself. I don't know if this is a kernel module and if it could
be reinitiated with modprobe or something similar, but my experience is that
if it locks up, nothing short of reboot can help.
HTH, :-)
Marko
Yes, Xorg is the original binary which ever way you name the links :)
I know in this case the lock up has probably has happened due to a bug in the
Radeon DRI graphics driver, but all kernel code should be written so that a
pending kill signal should terminate any loops and thence the process.
I don't don't consider it acceptable that you can't kill a process, even when in
the kernel and then have to reboot to recover. In my eyes as an old Unix
developer standards are slipping ...
Cheers
Terry
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
