Re: kill -9 <pid of X>

Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
Wed, 12 Aug 1998 21:47:12 +0200 (CEST)


On Wed, 12 Aug 1998, MOLNAR Ingo wrote:
> On Wed, 12 Aug 1998, Alan Cox wrote:
> > > Massive re-coding? Sounds like X just has to be protected from signal 9
> > > just like init. That means you just need something to make X unique
> > > to the kernel's signal "generator". Remember, you did not kill X, you
> > > told the kernel to do it --- and it did.
> >
> > Or the kernel decided to blow it away, or I fed it stuff that crashed it
> > solidly. There are many ways to upset the Xserver. (Thats not entirely
> > an argument against any specific setup btw - no doubt kernel code would
> > have some upset potential too)
>
> is this a problem with the FB based X server too? If not then i dont see
> the problem ... the FB console is always in a well-defined state. SAK
> should work there too, just like on any console.

Video board wise the console is indeed in a well-defined state, unless you use
a different X server than XF68_FBDev. But the keyboard is still in MEDIUM_RAW
mode if you kill X the hard way. Simply restarting XF68_FBDev solves the
problem though. I know, I did it many times when working on XF68_FBDev :-)

> X is 'fast and a bit unsafe sometimes'. ('very unsafe' with Alan's
> definition ;)
>
> XFB is 'quite fast too and safe'. And people can start adding acceleration
> (hard) to make it similarly fast, etc. But since we are not there yet, so
> i think the flamewar is a bit too early :)

We're there, if you have a Retina Z3 graphics board :-)

Greetings,

Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html