Hi,
I found (using git bisect) that following commit:
commit 8b92e87d39bfd046e7581e1fe0f40eac40f88608
Author: Alan Cox <[email protected]>
Date: Sat Sep 19 13:13:24 2009 -0700
vt: add an event interface
This is needed and requested in various forms for ConsoleKit, screenblank
handling and the like so do the job with a single interface. Also build the
interface so that unlike VT_WAITACTIVE and friends it won't miss events.
FIXME: Should this be a waitactive ioctl or a new device file you can poll
and read events from. We need the code anyway to fix up the existing broken
wait for console switch logic but the ConsoleKit people would prefer the
new device to the ioctl we have here
Signed-off-by: Alan Cox <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
M drivers/char/vt.c
M drivers/char/vt_ioctl.c
M include/linux/vt.h
M include/linux/vt_kern.h
is the perpetrator of changing consolechars (and probably other
tty-related apps) behavior.
[ In Debian before the end of the S runlevel (boot) console-screen.sh
is executed (it is not the last script though), where consolechars is
used for loading console screen font for each tty. In my case it
evaluates to:
/usr/bin/consolechars --tty=/dev/ttyX -f lat0-sun16
Similarly consolechars is used in setupcon script invoked by
console-setup (processed after console-screen.sh) to set a font chosen
by user. ]
The problem is that since 8b92e87 running consolechars switches tty to
the one provided with --tty option. Last commit I have tested,
a9366e6, is still affected.
( Back then there was also another problem with "INIT:
open(/dev/console): Input/output error" introduced in b50989d and
fixed in f278a2f. )
Result? Messages starting from "INIT: Switching to runlevel: 2" don't
go to tty1 as they should and tty1 is not the tty I see when login
prompt shows up.
I tried to found out whether this issue was already brought to light,
but without success. Maybe this is an obvious and intentional
consequence of the patch for people familiar with tty/vt --
unfortunately I am not among them.
Thanks.
--
Przemysław Pawełczyk
> [ In Debian before the end of the S runlevel (boot) console-screen.sh
> is executed (it is not the last script though), where consolechars is
> used for loading console screen font for each tty. In my case it
> evaluates to:
>
> /usr/bin/consolechars --tty=/dev/ttyX -f lat0-sun16
>
> Similarly consolechars is used in setupcon script invoked by
> console-setup (processed after console-screen.sh) to set a font chosen
> by user. ]
>
> The problem is that since 8b92e87 running consolechars switches tty to
> the one provided with --tty option. Last commit I have tested,
> a9366e6, is still affected.
That is a suprise as the code shouldn't be changing the behaviour of any
application unless something happened to rely on the race it fixed. Even
then I wouldn't expect what you see.
What does an strace of that command look like so I can see what ioctls it
issues and in what order.
Alan
2009/11/15 Alan Cox <[email protected]>:
>> The problem is that since 8b92e87 running consolechars switches tty to
>> the one provided with --tty option. Last commit I have tested,
>> a9366e6, is still affected.
>
> That is a suprise as the code shouldn't be changing the behaviour of any
> application unless something happened to rely on the race it fixed. Even
> then I wouldn't expect what you see.
>
> What does an strace of that command look like so I can see what ioctls it
> issues and in what order.
# strace /usr/bin/consolechars --tty=/dev/tty2 -f lat0-sun16
[ snip ]
open("/dev/tty2", O_RDWR) = 3
ioctl(3, KDGKBTYPE, 0x7fff042a0177) = 0
[ snip ]
ioctl(3, KDFONTOP, 0x7fff042a0150) = 0
[ snip ]
fstat(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 2), ...}) = 0
ioctl(3, VT_GETSTATE, 0x7fff042a0130) = 0
ioctl(3, VIDIOC_G_COMP or VT_ACTIVATE, 0x2) = 0
ioctl(3, VIDIOC_S_COMP or VT_WAITACTIVE, 0x2) = 0
ioctl(3, PIO_UNIMAPCLR, 0x7fff042a0160) = 0
ioctl(3, PIO_UNIMAP, 0x7fff042a0730) = 0
ioctl(3, VIDIOC_G_COMP or VT_ACTIVATE, 0x1) = 0
ioctl(3, VIDIOC_S_COMP or VT_WAITACTIVE, 0x1) = 0
exit_group(0)
And by switching tty I mean what is meant by switching tty manually,
i.e. the result of pressing Alt+Fx under x86. Just to clarify.
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.
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.
> Alan
--
Przemysław Pawełczyk
> 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.