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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
