[Bugme-new] [Bug 4321] New: Sleeping if your console is locked via ioctl VT_LOCKSWITCH does not work.

[bugme-daemon at osdl.org]

http://bugme.osdl.org/show_bug.cgi?id=4321

           Summary: Sleeping if your console is locked via ioctl
                    VT_LOCKSWITCH does not work.
    Kernel Version: 2.6.11-rc5, with whitelist patch from bug #3022, and
                    gensplash
            Status: NEW
          Severity: low
             Owner: acpi_power-sleep-wake at kernel-bugs.osdl.org
         Submitter: tim+kernelbugzilla at nordell.us


Distribution: Gentoo
Hardware Environment: Thinkpad T41 2379-DJU (1.6ghz Pentium M)
Software Environment:
Problem Description: Computer will not suspend while a terminal is locked

Steps to reproduce: call the ioctl call VT_LOCKSWITCH on a virtual terminal (to
disable switching terminals via alt-f1, alt-f2, etc) before issuing the suspend
command.  Until terminal is unlocked, the computer will not suspend.  Easiest
way to show this is via the "vlock -a" command, and issuing an acpi event to
suspend (such as in my case I have closing my lid configured to suspend my
notebook).  The notebook will not suspend, until vlock exits (it might possibly
do without it exiting), but the script that tried to sleep the machine, will be
in the sleep state, and the suspending will not occur until you either kill the
script via kill -9, or trying to strace the script.

This is obviously very low priority, it's not producing any oops's or hindering
the usability of the machine.  The only reason I came across this was because I
was creating a program to switch to a virtual console, and lock it and wait
until a password is entered, and switch back to the virtual console it was on
previously.  Basically a way of "password" protecting my notebook.  I initially
tried having it run before the sleep event, but obviously I encountered this
weird...abnormality.  I might eventually figure out how to fix it myself, but I
am not familiar enough with the kernel for this, and it would probably end up
being a kludgey fix.

My gut feeling is that the problem lies in the fact that when you "sleep" it
outputs messages to a specific virtual console, and switches to that console. 
The problem lies in the fact that the console is locked at the time.  I would
guess that if the "sleep" call to the virtual console # call was done outside of
"locking" the console, that there wouldn't be an issue.  But that's just my gut
feeling.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.