xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call

[Keith Packard]

On Mon, 2007-10-08 at 13:12 -0700, Linus Torvalds wrote:

> I'd added a bugzilla entry.
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=323501
> 
> which hopefully causes somebody who understands the RH startup scripts to 
> tell us how it works.
> 
> But yes, I htink it's "rhgb-client --quit" that kills the first X thing, 
> and I suspect it's either not waiting for it, or the quit is simply done 
> *after* X has already been started.
> 
> > Unless we believe that a pending VT_ACTIVATE/VT_WAITACTIVE should
> > somehow magically keep a subsequent VT_ACTIVATE from switching to the
> > 'wrong' console. This doesn't seem practical though.
> 
> Yeah, not practical on a kernel level. But I do think that X is doing 
> setup wrong.
> 
> If X were to make itself be the owner of the console early, *it* could 
> keep the subsequent VT_ACTIVATE from happening, and saying "not during my 
> startup, you don't!".

The new X server, attempting to use vt6 cannot prevent the old X server
from switching from vt7 to vt0 -- it hasn't ever been active. And, it
cannot get vt7 active because the old X server has set the API to
request VT switch via signal, blocking the new X server's attempt to
activate vt6.

It cannot prevent the vt7->vt0 transition, all it can do is deal with it
when it happens.

The old X server would have to notice and switch to vt6 instead of vt7.
Can it tell that the new X server has called VT_ACTIVATE before it does
the vt7->vt0 transition?

> So I think the problem is that
>  - the old X server should probably do the "disconnect me as owner" 
>    _after_ it has cleaned up (and thus nicely react to, and serialize, 
>    others wanting to change consoles)

I think it does this correctly -- it switches back to vt0 and then
closes the connection to vt7.

>  - the new server should probably do the "set me as owner" _before_ it 
>    starts doing switching events (and tell others "hell no, I'm not going 
>    to allow you to switch VT's until I'm fully set up").

The delay here is caused by the old X server; it has the old VT set to
synchronous switching.

> As far as I can see, that sounds like the logical thing to do, but it also 
> sounds like either of the above would have fixed the race, much less both.

Nope; the old X server won't let the new X server have its VT, and
ignores the VT switch request as it exits.

> VT_WAITACTIVE isn't meant to be "useful" in the race avoidance. It has 
> nothing what-so-ever to do with that. It's simply a "I asked for a console 
> switch, now I'm going to wait for whoever was the old owner to give it to 
> me".

Not 'give it to me' as much as 'until I get my way'.

> But it doesn't have anything to do with ownership per se. That's the 
> VT_SETMODE(VT_PROCESS) thing.
> 
> But I do agree that the whole thing is just damn messy and horrid. And no, 
> I've never actually programmed to that interface, so there may be some 
> idiotic reason why you have to do things the wrong way around.

Suggestions on the proper way to use this interface would be gratefully
received...

-- 
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/20071008/0069a662/attachment.pgp>