xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call

[Keith Packard]

On Sun, 2007-10-07 at 20:02 -0700, Linus Torvalds wrote:

> I agree. Looping on EINTR may end up being a worse fix than the current 
> problem.
> 
> What I'm starting to think is actually going on is:
> 
>  - the new X server asked for a VT switch.

This would presumably send a signal to the old X server, which may be
busy exiting and hence ignore it.

>  - in the meantime the *old* X server completed its VT switch back, or 
>    maybe it exited without having released it, so the kernel eventually 
>    noticed that the owner was no longer valid (or one of the other cases)

The old X server should always switch back to the initial VT on exit;
let's work on the assumption that it at least tries to do so. There
aren't many code paths out of the server that don't go right through the
VT switch code; it should happen even if the server crashes.

>      - that in turn *reset* the "switch to VT x" back to never switch at all
> 
>  - so the new X server will wait forever, since the kernel will never 
>    switch to the VT it was hoping to switch to!

Sounds like the symptom we're seeing at least.

> Now, if that is true, then that implies that X is probably mis-using the 
> ioctl's, and setting itself to be a VT master (with VT_SETMODE) while 
> another process is still thinking it is the owner of the console.

where by 'misusing', we mean 'using these weird interfaces in some way
that breaks things in this case'

The X server does (with all errors causing the server to exit):

	console_fd = open ("/dev/tty7", O_RDWR|O_NDELAY);
	chown ("/dev/tty7", 0, 0);
	chown ("/dev/tty0", 0, 0);
	ioctl (console_fd, VT_GETSTATE, &vts);
	ioctl (console_fd, VT_ACTIVATE, 7);
	ioctl (console_fd, VT_WAITACTIVE, 7);
	ioctl (console_fd, VT_GETMODE, &VT);
	VT.mode = VT_PROCESS;
	VT.relsig = SIGUSR1;
	VT.acqsig = SIGUSR1;
	ioctl (console_fd, VT_SETMODE, &VT);
	ioctl (console_fd, KDSETMODE, KD_GRAPHICS);

As you can see, it's not calling VT_SETMODE until it has called
VT_ACTIVATE (I don't see how to completely close the race between
WAITACTIVE and SETMODE, but we'll skip that for now).

However, VT_WAITACTIVE seems like a terrible interface here -- we can't
tell if our ACTIVATE is still pending, or if it has been cancelled by
some other VT switch in the meantime. Perhaps we should just poll, and
if the VT switches to something else, re-request the console by calling
VT_ACTIVATE again.

>  Or 
> something like that. This is all a huge mess, partly (largely) because we 
> inherited that whole VT switching interface from older Intel UNIXes, so 
> none of this is "designed".

It seems to have been 'designed' with built-in races.

> Which also means that I doubt anybody really knows all the rules. Damn.

I suggest that we just make it work in some straightforward fashion
(which might be as simple as 'don't use VT_WAITACTIVE, poll instead').

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20071007/eedb22cd/attachment.pgp>