Re: Keyboard lockup after X startup; possible cause
On Sat, Jul 23, 2005 at 01:50:10AM +0400, Nikita V. Youshchenko wrote: I had the same bug. It used to happen when you changed inittab to use more than 6 VCs, I had no idea it could race even on lower VCs. I don't know which is the correct way to fix it. Possible ways: *) ensure that X is never started on vt on which getty is going to be started - in this case, having default Xservers files to set explicit vtN is enough, and kdm 3.4 should provide some way to ensure that it will not choose vt on which getty will be started later, Defining the vtN explicitly makes sense, especially as we seem to have standardised on having X running on vc7. People who change inittab to allocate vc7 for something else, should also change the display manager. A comment in the default inittab reminding of the issue could also help. *) debian should not treat *dm like other services, and start it after getty's, not before them I recommend against this one, as there's been quite some talking about invoking *dm earlier in the boot process, to speed up getting to the working environment. *) some other way? What would be required for getty and X to allocate the vc without messing each other up? The cleaner solution (to me) would be to have getty not run if X is using the vc, or X running on another vc if getty is using it; but I reckon it might not be technically possible, at least judging from the past discussions on bug#116747, bug#47451 and bug#165241, Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Keyboard lockup after X startup; possible cause
Hello. Several people probably faced the problem that after initial system bootup, and startup of *dm, keyboard does not work. Suggested workaround was to add implicit 'vtX' parameter to X server command line in Xservers file. I've never seen an explanation of what is actually hapenning, and why that workaround helps. Recently I've installed kde 3.4 packages from experimental on one of my systems, and faced that keyboard problem again. And the suggested workaround was not possible, because it seems that newer kdm does not use Xservers file. After logging into system remotely, I found that X was started with 'vt2' parameter. While trying to fix the situation, I probably guessed what is causing lockups. Unlike some other distributions, Debian treats *dm similar to other services, and starts it from /etc/init.d script while syste, startup. So *dm is started *before* getty's start for consoles. Then *dm starts X server which may scan for a free vt (or, in case of recent kdm, it scans for a free vt itself). At this point, there is a race. Either getty's fo vt2-vt6 are already started, and search result into really free vt, and everything goes ok. Or getty is not yet started, and X is started on vt on which later getty is started. In this case, getty initializes vt *after* X, and into some state incompatable with X, and keyboard no longer works. I don't know which is the correct way to fix it. Possible ways: *) ensure that X is never started on vt on which getty is going to be started - in this case, having default Xservers files to set explicit vtN is enough, and kdm 3.4 should provide some way to ensure that it will not choose vt on which getty will be started later, *) debian should not treat *dm like other services, and start it after getty's, not before them *) some other way? Nikita pgpuuKige4TW4.pgp Description: PGP signature
Re: Keyboard lockup after X startup; possible cause
Nikita V. Youshchenko wrote: Hello. Several people probably faced the problem that after initial system bootup, and startup of *dm, keyboard does not work. Suggested workaround was to add implicit 'vtX' parameter to X server command line in Xservers file. I had a similar problem, using lessdisks as a diskless workstation, where kdm left the keyboard unresponsive, but gdm worked. The fix was to tell kdm to use /dev/urandom as randomDevice. Dont remember the bug number, not sure if I filed it against Debian BTS, but at least I filed it against kdm in KDE BTS, and the problem should be gone in upstream KDE. -- Finn-Arne Johansen Debian-edu maintainer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
