F11: kill -9 doesn't work

[Terry Barnaby]

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