X server crashes when enter key is pressed

This happens to me intermittently. I noticed it some weeks ago, I didn't see it for a while, and it returned in the last several days. It may happen more often if I boot with the radeon.modeset=0 option and I also see it with a rather new 2.6.33 release candidate stock kernel I sometimes boot. It may happen 3 out of 10-20 times and seems to happen in runs.

At times, after a reboot, rather than the login screen, I see a mostly blank screen and when I type I see scan codes echoed as I type. If I switch to VT1 at this point and then back to VT7 I see the login screen. If I press Enter, X will crash with the same traceback listed above. If, when this has happened and I'm at VT7's framebuffer, I press ALT-Sysrq-R I can proceed correctly.

When in the above error mode I avoid pressing enter by using the touchpad or mouse I can proceed to logging in and start a terminal, type a few things, and then press Enter. At that point X will crash and the framebuffer image, when I see it, will contain scan codes for the ascii characters I typed into the terminal session, ending in ^\ .

Ascii ^\ is 0x1c and the scan code for enter is 0x1c as well. Of course the Ascii code ^\ is the standard thing to use to send SIGQUIT to a running process.

I've determined that the error case and good case can be determined when I get to the login screen by switching to VT1 and entering

<code>
sudo stty -F /dev/tty7
</code>

In good cases -isig is displayed. In bad cases isig is set. Thus, there are times when tty7 is left with processing of signal producing control characters on when set up to pass scan codes to the X server and the kernel reacts to processing the Enter scan code by sending the SIGQUIT signal to the X server, causing it to quit.

While in VT1 in the error case I can use
<code>sudo stty -F /dev/tty7 -isig</code>
and then on return to VT7 can proceed without a crash.

I don't see a pattern in my /var/log/syslog between working and error cases.

While one approach might be to try to figure out why isig sometimes is being left unset, I wonder why the tty driver is getting confused between scan codes and Ascii anyway.

When X crashes this way it is restarted on the next VT and another login screen is presented. I haven't seen this happen more than once in a boot session.

I can reproduce at times right after booting current Lucid kernel.

Plymouth is screwing with the VT and sets isig

Err, sorry, I didn't mean to put that comment with the package change there.

Thanks, Robert.

That makes a lot of sense for the case that I described above. I removed plymouth and plymouth-x11 and booted 30 times without it happening again. Booting with radeon.modeset=0 and my custom kernel, both very problematic in the past, worked fine as well.

Can plymouth cause this problem well after login after Enter has been pressed many times into the GUI session? I would think plymouthd would be gone by then. This just happened to me with plymouth reinstalled. For some reason the GUI was on VT1 rather than VT7. Immediately after it happened I checked for the plymouthd process and it wasn't running.

Perhaps this is what happened to OP Marc. He didn't say that the first "enter" press caused X to crash, I just assumed he was experiencing what I was sometimes able to reproduce, but perhaps not.

If this is all explained by the bug the plymouth devs are working on please excuse the noise.

I am certain that I pressed enter successfully many times in the session before it crashed.

Also, I am usually able to login, which requires pressing enter twice.

I can also reproduce the bug behavior and have some more information:

The return key (both in the main typing area and on the numpad) is not the only one to cause the crash. I tried all keys on my (german standard usb) keyboard and found the following:

- both return keys cause the crash, as known
- key "2" causes the crash too
- key "r" switches the SCROLL LOCK LED on
- key "w" switches the SCROLL LOCK LED off
- SCROLL LOCK button does not switch any LEDs on or off. NUM LOCK or CAPS LOCK works though.
(- the "p" key caused the crash a week or two ago too. It doesn't anymore; I regularly install lucid updates)

This not only happens on the logon screen; if I turn on autologon if have the same behavior on the desktop.

Additionally, there is a strange video artifact showing. It start with just some blinking pixels in the top row to the right, every keypress adds a pixel. The last pixel in the right two rows keep on blinking though. I attached a (very real camera-taken) screenshot of the top of my screen to show the effect after some extensive typing.

Hope to help
Henning

Henning:

Thanks for the information. Does it crash the first time you type these keys or can you type them at first but later it crashes? If the second case could you post your Xorg.0.log from when it crashed (hopefully in Xorg.0.log.old)? In that case I'm wondering whether the crashing X session started on VT1 rather than VT7 as did Marc's and mine (noted in the beginning of the log).

If it happens the first time you press a certain key in a session I think you might want LP# 532047.

Marc: I see from your log file that your problem X session started on VT1 just like mine. Even if still related to plymouth I wonder if our difficulties are also related to the situation involved in closed karmic bug LP: #396226. I haven't seen a case of this when plymouth isn't installed, though it happens rarely so it is hard to tell.

The comments seem to be about right and describe the same phenomenon. However, the problem is new for me in lucid as of February.

Hi!

First of all, sorry for my bad english.

This happens only in computers in my laptops with NVidia GPU's...

Before some fixs, if i press Enter after inserting password, computer crash.
The solution was insert password click on log in button, and log out. After
i insert password again, i can log in pressing Enter with no crash.

With latest updates, when i press enter in first tentative, monitor turns
black, after that, monitor shows a bunch of rectangles in screen and back to
login screen.
I try login again and always work well after this.

I will pm you(with phone video), when beta release comes out and this last
problem still show up.

Good Job

2010/3/10 John S. Gruber <email address hidden>

> Henning:
>
> Thanks for the information. Does it crash the first time you type these
> keys or can you type them at first but later it crashes? If the second
> case could you post your Xorg.0.log from when it crashed (hopefully in
> Xorg.0.log.old)? In that case I'm wondering whether the crashing X
> session started on VT1 rather than VT7 as did Marc's and mine (noted in
> the beginning of the log).
>
> If it happens the first time you press a certain key in a session I
> think you might want LP# 532047.
>
> --
> X server crashes when enter key is pressed
> https://bugs.launchpad.net/bugs/529230
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “plymouth” package in Ubuntu: Confirmed
>
> Bug description:
> kosh@isis:~$ lsb_release -rd
> Description: Ubuntu lucid (development branch)
> Release: 10.04
> kosh@isis:~$ dpkg -l xserver-xorg-core | egrep -e ^i
> ii xserver-xorg-core 2:1.7.5-1ubuntu1
> Xorg X server - core server
>
> Sometimes the X server crashes when I press the enter key. It happens
> seldomly, so I can still work, but sometimes X will just die right when I
> press enter. This has happened in oocalc, mplayer and gnome-terminal, and
> the application does not receive the key press event (or has no time to act
> on it).
>
> I have attached my X server log which shows a backtrace:
>
> Backtrace:
> 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a2528]
> 1: /usr/bin/X (0x400000+0x6522d) [0x46522d]
> 2: /lib/libpthread.so.0 (0x7fe52032b000+0xf920) [0x7fe52033a920]
> 3: /lib/libc.so.6 (__select+0x13) [0x7fe51f0e4c53]
> 4: /usr/bin/X (WaitForSomething+0x1ba) [0x45f5fa]
> 5: /usr/bin/X (0x400000+0x308d2) [0x4308d2]
> 6: /usr/bin/X (0x400000+0x2614a) [0x42614a]
> 7: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fe51f024c4d]
> 8: /usr/bin/X (0x400000+0x25cf9) [0x425cf9]
>
> Caught signal 3 (Quit). Server aborting
>
> I first noticed this problem on February 21st, so after this upgrade:
>
> [UPGRADE] xserver-xorg-core 2:1.7.3.902-1ubuntu12 -> 2:1.7.5-1ubuntu1
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/529230/+subscribe
>

Marc: New for me, too. Plymouth is new as a standard feature, if I'm not mistaken, and many are working to minimize the number of times the screen flashes or clears and on getting boot processes to start as early as possible to minimize boot time.

If you don't mind me asking, what version of plymouth are you running? Can you look to see if /usr/share/initramfs-tools/conf-hooks.d/plymouth exists and if so what it contains. It should probably not exist. If it does exist it probably contains just two lines.

plymouth 0.8.0~-12 as of March 5th.

No, /usr/share/initramfs-tools/conf-hooks.d/plymouth does not exist.

I can't check right now with this laptop w/out nvidia.

But with this Intel GPU, don't exist. :S

2010/3/10 John S. Gruber <email address hidden>

> Marc: New for me, too. Plymouth is new as a standard feature, if I'm not
> mistaken, and many are working to minimize the number of times the
> screen flashes or clears and on getting boot processes to start as early
> as possible to minimize boot time.
>
> If you don't mind me asking, what version of plymouth are you running?
> Can you look to see if /usr/share/initramfs-tools/conf-hooks.d/plymouth
> exists and if so what it contains. It should probably not exist. If it
> does exist it probably contains just two lines.
>
> --
> X server crashes when enter key is pressed
> https://bugs.launchpad.net/bugs/529230
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “plymouth” package in Ubuntu: Confirmed
>
> Bug description:
> kosh@isis:~$ lsb_release -rd
> Description: Ubuntu lucid (development branch)
> Release: 10.04
> kosh@isis:~$ dpkg -l xserver-xorg-core | egrep -e ^i
> ii xserver-xorg-core 2:1.7.5-1ubuntu1
> Xorg X server - core server
>
> Sometimes the X server crashes when I press the enter key. It happens
> seldomly, so I can still work, but sometimes X will just die right when I
> press enter. This has happened in oocalc, mplayer and gnome-terminal, and
> the application does not receive the key press event (or has no time to act
> on it).
>
> I have attached my X server log which shows a backtrace:
>
> Backtrace:
> 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a2528]
> 1: /usr/bin/X (0x400000+0x6522d) [0x46522d]
> 2: /lib/libpthread.so.0 (0x7fe52032b000+0xf920) [0x7fe52033a920]
> 3: /lib/libc.so.6 (__select+0x13) [0x7fe51f0e4c53]
> 4: /usr/bin/X (WaitForSomething+0x1ba) [0x45f5fa]
> 5: /usr/bin/X (0x400000+0x308d2) [0x4308d2]
> 6: /usr/bin/X (0x400000+0x2614a) [0x42614a]
> 7: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fe51f024c4d]
> 8: /usr/bin/X (0x400000+0x25cf9) [0x425cf9]
>
> Caught signal 3 (Quit). Server aborting
>
> I first noticed this problem on February 21st, so after this upgrade:
>
> [UPGRADE] xserver-xorg-core 2:1.7.3.902-1ubuntu12 -> 2:1.7.5-1ubuntu1
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/529230/+subscribe
>

I've determined some of the things involved on my system when this happens but I don't know if others' situations are the same.

Marc and I have our troublesome X sessions starting on VT1 (tty1). Is that true for other reporters? You can tell right after you see the inital graphic login screen after booting if you hold CTL-ALT and press F1 and the login screen doesn't change. If it does change you can press CTL-ALT and F7 or other Fn keys to go back--in that case your situation is different from Marc's and mine.

The Xorg.0.log.old file after the crash also lists the VT Xon which X started before the crash. I noticed in the file he posted that Marc's session started on VT1.
==
Marc and other reporters seeing their graphic login on VT1:
What is the last thing you are seeing on your screen before gdm starts up X and displays the graphic login? (Are you seeing a splash screen, or messages, or a blank screen)? If a blank screen, what was the last thing you saw on the screen before it is cleared?
==
Looking at another aspect of this bug:

Do each of you see messages in /var/log/auth.log including text similar to "FAILED LOGIN (3) on '/dev/tty1'" before one of these crashes?

Marc: It crashes only the first time I press enter after reboot, so 532047 matches much better, thanks. Though the workaround with /etc/init/plymouth-splash.conf.disabled doesn't work for me.

John: Yes, I see those messages in auth.log, but the last one is from March 8th, and I have experienced crashes after that date.

Henning, #532047 has been fixed, as they say;
/usr/share/initramfs-tools/conf-hooks.d/plymouth does not exist in my system with plymouth 0.8.0~-14

I know this is suggested as a duplicate of bug #532047, but this one seems more closely aligned with the behavior I'm experiencing. I'm running Ubuntu 10.04 64-bit on a new System76 Serval Pro (serp6) laptop. When I boot up, I can login and have anywhere between 5 minutes and an hour of normal activity before I see a blank screen, and then the login screen again. If I login again, I never see another X reset until I boot. BTW, I'm fairly certain that this reset has almost always occurred when I press Enter, but I can often press Enter hundreds of time without a reset, but then it will happen eventually (if it's my first login after a boot).

After an initial boot up and first login, I'm always on VT1 or VT2, and I'll always get the X reset eventually. After logging in a second time (or if I just logout and login again after a boot), I'm always on VT8 and I never have an X reset.

On VT7 (Ctrl-Alt-F7), for both first and second logins, I always see an error like this:

(process:516) GLib-WARNING **: getpwuid_r(): failed due to unknown user id (0)

I've tried adding APT source ppa:ubuntu-x-swat/x-updates and reinstalling my nVidia (current) driver, as suggested in this thread on the issue:
http://ubuntuforums.org/showthread.php?t=1545846

No change. I also tried the "temporary workaround" in bug #532047 -- sudo mv /etc/init/plymouth-splash.conf /etc/init/plymouth-splash.conf.disabled -- no change.

I've spent many hours on this and would love to see it go away. BTW, I have nVidia current drivers with Ubuntu 10.04 64bit on my Dell Vostro 1510, which never has this issue--always login to VT7. I would be super appreciative if anyone has any ideas or if I can provide any further information. Am I commenting on the right bug (I read through a bunch, but this one seems to match the symptoms)? Is this bug still going to be looked at, or should I also comment on another bug? Thanks in advance for any help!

@John: Interesting... I meant to also comment on your question about stuff like this showing up in /var/log/auth.log:

$ cat /var/log/auth.log | grep FAILED
Sep 1 21:38:16 jkrug-serval login[6215]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', Authentication failure
Sep 1 21:38:19 jkrug-serval login[6215]: FAILED LOGIN (2) on '/dev/tty1' FOR 'UNKNOWN', Error in service module
Sep 1 21:38:22 jkrug-serval login[6215]: FAILED LOGIN (3) on '/dev/tty1' FOR 'UNKNOWN', Error in service module
Sep 1 21:38:25 jkrug-serval login[6215]: FAILED LOGIN (4) on '/dev/tty1' FOR 'UNKNOWN', Error in service module
Sep 1 21:38:27 jkrug-serval login[6215]: FAILED LOGIN (5) on '/dev/tty1' FOR 'UNKNOWN', Error in service module

What's strange is that, when I went to grab this to paste here, I noticed that the most recent date is Sep 1, but I'm positive I had one or two X resets yesterday, Sep 2. The difference was that yesterday I was trying out this suggested workaround:
sudo mv /etc/init/plymouth-splash.conf /etc/init/plymouth-splash.conf.disabled

So, apparently those "FAILED LOGIN" messages didn't appear in /var/log/auth.log, but X still reset on me :(

@Jamie:

So on 9/2, when the "FAILED LOGIN" messages didn't appear, was the session that eventually crashed on tty1 or on another tty?

With regard to where to report--I'd suggest you might want to report against bug #625239, but I'd be sure to mention both the delay before crashing, and the fact that X starts on tty1 rather than tty7. I imagine your /var/log/auth.log file showing errors might also be helpful.

As far as I could tell, the delay and the tty1 vs tty7 facts were the hallmarks of this report as opposed to bug #532047.

Bug #625239 is currently open and confirmed but not marked as triaged as there aren't many people who have confirmed the problem under maverick.

When the developers closed 532047 with a fix for Lucid they seemed to me to have fixed this report as well as #532047.

I'm afraid I haven't tested maverick much so I don't know if I'll see this bug or not. It was often intermittent for me.

@John:

Thanks for the response. I'm pretty sure I was on tty1 on 9/2 when X crashed, but it was either tty1 or tty2--that I'm certain of. It's always either tty1 or tty2 (I believe it's VT2 most often) upon first login after a boot, and always tty8 after logging out and logging in again.

I'll review bug #625239 next and post a summary of my results there.

BTW, I'm on Lucid too, so I haven't tested with Maverick at all.

Thanks again for the feedback.