Comment 2 for bug 529230

Revision history for this message
John S. Gruber (jsjgruber) wrote :

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.