Re: consolechars switches tty since 8b92e87 vt: add an event interface

[Alan Cox]

> ioctl(3, VIDIOC_G_COMP or VT_ACTIVATE, 0x2) = 0

Switch to VT 2
> ioctl(3, VIDIOC_S_COMP or VT_WAITACTIVE, 0x2) = 0

Wait for VT 2 to activate

> ioctl(3, PIO_UNIMAPCLR, 0x7fff042a0160) = 0
> ioctl(3, PIO_UNIMAP, 0x7fff042a0730)    = 0

Set maps

> ioctl(3, VIDIOC_G_COMP or VT_ACTIVATE, 0x1) = 0

Switch back to VT 1

> ioctl(3, VIDIOC_S_COMP or VT_WAITACTIVE, 0x1) = 0

Wait for VT1 to activate.

Nothing odd there, definitely looks like a kernel problem.

> I have one thing to add. It looks like that is not fully deterministic
> behavior, at least not at f278a2f^ I'm using now. Occasionally tty
> isn't switched. I wasn't aware of this before.

The console switch is asynchronously handled so a race or a bug in the
handling of the event wait which is what I suspect would indeed show up
that behaviour. X and other apps don't do sudden fast switch and switch
backs which would hide such a bug.
 
> I just booted that f278a2f^ (i.e. 569ec4c) while consolechars were
> limited only to console-setup script, but this time tty1 remained on
> the screen and I didn't get "INIT: open(/dev/console): Input/output
> error" I was seeing before. I'm not sure whether it is relevant here.

The I/O error is a different bug (technically a user space one), but the
new behaviour was different, not at all expected and was fixed back to
the old sane behaviour.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/