[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: F11: kill -9 doesn't work

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, :-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]