Comment 129 for bug 625239

Here is my complete kernel.log since last reboot, just after downgrading to the regular gdm package for lucid (no workarounds).
You can do your own greps if you wish :)

-------------------------------------------------------------------------------
Now if someone is ever interested in more details, what follows is a prosaic account of my last session 'with the issue'. This is hardly new information just more detail. It also serves as evidence that the attached log file is relevant as the symptoms are seen.
-------------------------------------------------------------------------------

The boot went fairly quickly, and thus, expectedly, X and gdm landed on stty2. I then went for coffee - nothing happens. I subsequently read my mail, nothing happened, I harvested this log and started typing. That's when the signs start to appear!

I had the following watch running:

Every 2.0s: date; date -r /var/run/gdm/firstserver.stamp; stty -F /dev/tty2 Tue Sep 14 16:36:25 2010

   Tue Sep 14 16:36:25 CEST 2010
   Tue Sep 14 15:55:16 CEST 2010
   speed 38400 baud; line = 0;
   -brkint ixoff -imaxbel
   -isig -iexten -echo

After about 50 keystrokes in succession (approx!) the scroll lock light came on. I froze, because I knew this was the signal that the vt is about to crash X on reception of certain scan-codes. I was sly enough quietly slip into vt1 and do:

root@lucid:~# date; while true; do sleep .5; stty -F /dev/tty2 -isig; done
Tue Sep 14 16:28:05 CEST 2010

You can see how that would provide me with (racy) immunization against terminating the X session.
I'm still on the same terminal/X session now at 16:53. Every so often, the scrolllock light will toggle on or off (keys must be pressed for it to happen but there doesn't seem to be a pattern in timing, sometimes quite rapidly in succession).

The terminal 'flags' do change every now and then, but not in synch with the scrolllock light. Note again how I do not normally have a functioning scrolllock key/light (not even when X is on a separate vt7 without any other confusion).

Approx. halft the time the output of 'stty -F /dev/tty2 'is

    speed 38400 baud; line = 0;
    -brkint ixoff -imaxbel
    -isig -iexten -echo

Once in a while the output changes to the following for some time:

    speed 38400 baud; line = 0;
    min = 1; time = 0;
    -brkint -icrnl -imaxbel
    -opost -onlcr
    -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Note that this is when I'm keeping -isig artificially 'low' by using the background loop running on vt1. I wouldn't be typing this otherwise :)
The symptoms went away when I issued 'stop tty2'
The time is 16:59 now