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.
still an issue in 2.6.13?
I will have to check. :) I haven't messed with doing it since I discovered I couldn't sleep while having the console locked.
Looking through the code, I see that suspend-resume use the normal interfaces to switch the console and if VT LOCK is active console switch fails and hence the suspend also fails. As Tim mentioned, this can be worked around by using a different code path to switch to suspend-resume kernel. But, as this is not a critical issue, and can easily be handled by having a userlevel script that checks whether VT LOCK is active before suspend, releases it and then does suspend (and also does the reverse on resume), I kind of feel that we don't need to fix it in the kernel. Tim: If you don't insist for the kernel fix strongly enough, I am going to close this bug :-).
Closing the bug.