Keyboard left in raw mode after failed X server start?

[Eugenia Loli-Queru]

Just finished downloading the latest -current Live CD, February 08.

My AMD Duron 1.2 GHz (Linare PC from wal-mart, Linux-compatible) loads fine, but
the whole machine freezes when Ubuntu can't manage to load X. It tells me that
there was a problem loading X and if I would want to view the X log, but the
keyboard has stopped working at that point (was working during boot up). The
monitor is an 19" Envision CRT which is VESA compliant and FEdora/MacOSX can
autodetect its resolutions just fine. It is capable of 1280x1024 at 85 Hz, or
1600x1200 at 75 Hz. The machine's onboard (and disabled) AGP graphics card is an
SiS one. The monitor is connected to an X-compatible PCI GeForce2-MX card, 64 MB
(that machine has no AGP slot, just 2 PCI ones). Please note that the
framebuffer works fine, and other OSes/distros can autodetect the gfx stuff
fine. It is only Novell Linux Desktop and your LiveCD that seem to have a
problem with it.

So, when I saw that my Duron doesn't work with the Live CD, I tried my AthlonXP
1600+ machine. That machine dies after it has scanned the USB stuff:
usb 5-0:1:0: 2 ports detected
uhci-hcd: loaded successfully
uhci-hcd: already loaded
pci [success]

and then nothing. It's freezed up right there. The machine includes 2 USB 1.1
ports from its VIA-based motherboard, and two more USB ports from my NEC USB 2.0
PCI card. This machine worked with Warty a few months back (I still have it
installed on a partition).

[Eugenia Loli-Queru (eloli)]

ok, more info:
on the *second* machine (the athlonxp), after inserting pci=noapic, the machine
boots. And then, it again fails to load X, exactly the same way it has happened
on the Duron. After X fails, the ncurses application that asks you "if you want
to see the log", is completely frozen, just like in the Duron. Only reset saves
the machine. The monitor I use on my AthlonXP is a 19" LG StudioWorks capable of
the same refresh rates as the Envision monitor I mentioned above.

So, the bug is two fold:
1. Even the new version of Ubuntu has the same problems on my athlonXP as the
previous version had and requires me to use noapic: see #1267

2. The current live CD has a bug when configuring X and freezes the machine, no
matter what monitor/gfx card/PC you use. It just fails, in general.

[Eugenia Loli-Queru (eloli)]

Tried a third PC (dual Celeron 533, Sony 21" monitor, Matrox 32 MB AGP). Same problem with X and
freezing.

[Matt Zimmerman (mdz)]

There are a couple of known bugs on the current daily live CD:

- The kernel modules in the live image do not match the kernel on the CD, so X
has no chance of starting (no mouse driver, e.g.)
- The xserver-xorg in the live image has some autodetection bugs (already filed
elsewhere, and with fixes pending)

You may use Array 4 as a known-good milestone until these bugs are fixed.

The problem with the dialog is also known, but I don't think it has been filed
yet, so we'll use this bug to represent it.

It looks like the keyboard is left in raw mode; if you press Alt+SysRq+R, it
will restore the keyboard to cooked mode and you will be able to switch to a
text console with alt+F1.

[Daniel Stone (daniels)]

Eugenia, does Alt+SysRq+R fix this?

[Eugenia Loli-Queru (eloli)]

Which is the SysRq key again? I did that once for Red Hat, but I can't remember
now which key it is. It's been a year since then.

[Daniel Stone (daniels)]

PrintScrn.

[Eugenia Loli-Queru (eloli)]

Yes, with Alt+SysRq+R I can change virtual consoles indeed. However, I don't
know the default login/password so I can't login. What is it again?

And after I got in, is there any way to fix manually the X problem?

[Matt Zimmerman (mdz)]

(In reply to comment #4)
> Eugenia, does Alt+SysRq+R fix this?

It "fixes" it for me, to the point of being able to switch consoles (though I
still can't talk to whiptail); this is how I've continued with live CD testing
while things have been broken in the daily live CDs.

You should be able to reproduce this easily with the (broken) live CD of
20050210, or by otherwise causing the X server to fail to start.

Interestingly, strace seems to show whiptail blocked writing to tty7.

[Daniel Stone (daniels)]

*** Bug 12437 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

I'm not able to reproduce this anymore (just tried). Downgrading until it
happens again.

[nanophase (nanophase)]

Hmm Bug 12437 has been marked as a duplicate of this one, and this is considered
now as not reproducable. However 6059 is still there, and I don't really see why
they should be the same. Just for info. Shouldn't be duplicate of this one imho.

[Matt Zimmerman (mdz)]

Are you able to reliably reproduce the symptoms described in bug #12437? What
about bug #12647?

[nanophase (nanophase)]

Well Matt,first of all mine is with Hoary install not with a live CD. I have to
run "kbdrate -r 30 -d 250" every time I boot the laptop), because the settings
that I console-tools sets will be flushed once X starts up through gdm, if gdm
doesn't start at boot, the beyboard rate is just fine (just as it's set up). I
can try disabling gdm and start X with like "X :0 | xterm -display :0" to test
if you like, or tell me what you need. So yes I can reproduce bug 12437, doesn't
bug me that much, can workaround it, but Hoary should have it fixed for the
coders sake imho :)

[Daniel Stone (daniels)]

So I assume the X server failed to start? If so, please attach a full
Xorg.0.log, so I can see where in the shutdown process we fail to restore the OS
keyboard settings.

[nanophase (nanophase)]

No, X _does_ start up, everything is fine, it's just that after X starts, and I
switch back to the with console ctrl-alt-F1, the keyboard rate is slow. So not
the thing I have in the config (rate 30, delay 250), but something else (rate
10.9, delay 250).

Hope this helps.

[Daniel Stone (daniels)]

OK, I know how to do this, but won't be doing it for Hoary (too invasive).

[Matt Zimmerman (mdz)]

(In reply to comment #16)
> OK, I know how to do this, but won't be doing it for Hoary (too invasive)

So you discovered the cause? What is it, and what is your proposed fix?

[Daniel Stone (daniels)]

it doesn't appear to save the state at all, so my plan was to save the state at
start and on vtenter, and restore on vtleave/exit.

[Matt Zimmerman (mdz)]

This bug still exists, but has been worked around for the common case in Ubuntu
as follows:

gdm (2.8.0.4-0ubuntu7) breezy; urgency=low

  * debian/patches/14_xkeepscrashing_kbdmode.patch
    - Call kbd_mode -a before trying to interact with the user, since X can
      leave the keyboard in raw mode (ubuntu #6286)

 -- Matt Zimmerman <email address hidden> Tue, 20 Sep 2005 17:14:47 -0700

Downgrading to normal.

[Henrik Nilsen Omma (henrik)]

Just a general ping to anyone who might still be subscribed to this bug :)

Last comment was on 2005-09-21. Are people still having these issues in recent dapper releases? Thanks.

- Henrik

[Fabio Massimo Di Nitto (fabbione)]

Nobody reported this problem anylonger. I think it has been fixed. If not, please feel free to reopen.

Fabio