On Mon, Sep 13, 2004 at 09:54:49AM +0200, Jonas Meurer wrote: > On 12/09/2004 Michel Dänzer wrote: > > On Sat, 2004-09-11 at 14:21 +0200, Jonas Meurer wrote: > > > at boot, when xdm is started, x freezes directly after the login screen > > > is displayed. sometimes it's possible to type in the login name, but at > > > the latest at typing the password, the complete screen freezes. > > > > FWIW, I used to see something similar with gdm and kdm a while back, and > > it was a VT allocation race between the X server and the gettys. IIRC > > the X server would attach to VT 2 but display on VT 7, so it would never > > get the input. AFAIR the mouse cursor worked though, is that the case > > for you? > > exactly, the mouse cursor still works, only keyboard seems to be broken. > after hitting <alt>+<sysrq>+<k>, the screen get's messed up, then i > change to tty1, this vc gets messed up completely, i type > '/etc/init.d/xdm stop', and the messed up screen becomes somehow reset. Does the Debian X FAQ[1] help? How do I tell xdm to start the X server on a different virtual console? People who have customized /etc/inittab to add virtual consoles beyond the six that is the default Debian configuration often find that the xdm and getty programs "collide" and often leave the console in an unusable state. Debian's xdm program ships with a configuration that tells it to start one local X server on virtual console 7. This works fine with the default Debian /etc/inittab, but not so well for people who have changed inittab to start a getty on VC 7. If you have increased your number of virtual consoles, or otherwise require VC 7 for some purpose, simply edit /etc/X11/xdm/Xservers and change the "vt7" argument on the ":0" server line to whatever VC is appropriate for your machine (vt8, vt12, etc.). Note that while the XFree86 manual page says that if the "vt" argument is not specified, the X server will use the first available virtual console, it is not a good idea to omit this parameter when starting local X servers with xdm. This is because even though xdm starts at the very end of the init sequence, well after the getty processes that manage the virtual consoles, some machines get through the init sequence so quickly that getty has not yet claimed its VC's before xdm starts. This leads to exactly the same kind of console lockup you get as if you deliberately tell getty (via /etc/inittab) and xdm (via /etc/X11/xdm/Xservers) to use the same virtual console for their respective tasks. [1] http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#xdmdiffconsole -- G. Branden Robinson | The more you do, the more people Debian GNU/Linux | will dislike what you do. branden@debian.org | -- Gerfried Fuchs http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature