On Saturday 08 July 2006 00:05, Tim Dijkstra wrote: > On Fri, 7 Jul 2006 23:23:07 +0200 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > On Friday 07 July 2006 21:13, Rafael J. Wysocki wrote: > > > On Friday 07 July 2006 15:02, Tim Dijkstra wrote: > > > > On Fri, 7 Jul 2006 14:44:19 +0200 > > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Friday 07 July 2006 14:30, Tim Dijkstra wrote: > > > > > > On Fri, 7 Jul 2006 13:25:20 +0200 > > > > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Apparently we have used wrond console ioctls around > > > > > > > freeze() in suspend_system() and in a wrong order. The > > > > > > > appended patch fixes this. > > > > > > > > > > > > > > Comments welcome. > > > > > > > > > > > > Just some questions. You told me this was a hack to get the > > > > > > user not to switch VTs. > > > > > > > > > > > > I guess the VT_ACTIVATE before the freeze is need because we > > > > > > can't be sure the user didn't switch since the last time with > > > > > > switched. Is the second needed, because there is a (slim) > > > > > > chance they did just before the freeze after the first > > > > > > VT_ACTIVATE? > > > > > > > > > > It just returns to the previous state. > > > > > > > > Because freeze will mess with the VT state? > > > > > > It shouldn't, but generally we can't assume it never will. > > > > > > > > I think even if the user manages to > > > > > trigger the switch after the first VT_ACTIVATE, it won't hurt > > > > > us after the second VT_ACTIVATE, because X is now frozen and it > > > > > won't take over the hardware. > > > > > > > > > > Why do we switch to KD_GRAPHIC just before freeze and KD_TEXT > > > > > > just after? Shouldn't we KDGETMODE and restore that? > > > > > > > > > > prepare_console() is supposed to leave is in KD_TEXT. However > > > > > it's probably a good idea to use KDGETMODE anyway. > > > > > > > > I did a bit of reading on this, isn't using VT_SETMODE to set > > > > VT_PROCESS precisely what we want? If I read it correctly that > > > > will block all VT switching unless we issue the VT_RELDISP ioctl. > > > > > > Well, that should work, at least at first sight. > > > > At the second sight, however, it looks like after VT_PROCESS the > > kernel will block switching _to_ the VT in question and not _from_ > > it, and we're trying to prevent the latter from happening here. > > Hmm, maybe your right. I was reading this > > The "switch-from" process will need to perform any cleanup, and > issue the VT_RELDISP ioctl, telling the kernel that it is OK to > continue the switch. It is also possible for it to deny the > switch, in which case the kernel discontinues the switch. > > But maybe this is only true if the _to_ process set the VT_PROCESS, > seems odd though. There should also be a way to prevent switching > from. Maybe I'll try and test this tomorrow.
OK I think I'll apply my patch for now (later today) and we'll create a new patch on top of it once we are sure there's a better solution. Rafael Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
