Bug 21596

Created attachment 25553 [details]
Server configuration file

Created attachment 25554 [details]
dmesg output

Created attachment 25579 [details]
Xorg.0.log (correct version)

Noticed belatedly that the initial log was using the wrong configuration file (one that didn't have ModeDebug active); apologies for the mixup.

I've done a little additional testing and found:

- The Xorg process terminates normally on exit.  (There were a couple of threads that got SIGPIPE on writev() when the server exited, but I saw the same behavior on kernel 2.6.28, so I assume that's normal.)

- Even after the console lockup, X can be started from an SSH login, but it often (not always) takes ~20 seconds longer to complete the startup sequence, 28-32 seconds as opposed to 10-12.  After startup, applications seem to behave normally with no slowdown.  There are no additional dmesg messages except for repeats of the EDID messages at the bottom of the dmesg log already attached.  The only difference in Xorg.0.log (aside from the timestamp at the top) is:

@@ -253,8 +253,8 @@
 (II) intel(0): 0x00000000:            end of aperture
 (II) intel(0): BO memory allocation layout:
 (II) intel(0): 0x00000000:            start of memory manager
-(II) intel(0): 0x09891000-0x09c78fff: front buffer (4000 kB) X tiled
-(II) intel(0): 0x09881000-0x0988afff: HW cursors (40 kB)
+(II) intel(0): 0x09ca2000-0x0a089fff: front buffer (4000 kB) X tiled
+(II) intel(0): 0x09c92000-0x09c9bfff: HW cursors (40 kB)
 (II) intel(0): 0x00000000:            end of memory manager
 (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
 (II) intel(0): DPMS enabled

where the base address seems to increase with each execution; for the cursors line, I saw the following sequence: 0x09881000, 0x09c92000, 0x0a0a2000, 0x0a4b2000, 0x0b4dd000, 0x0b8ed000, 0x0c518000, 0x0c928000.

Adjusting severity: crashes & hangs should be marked critical.

It looks like you don't have the framebuffer console driver loaded/builtin?  If you want to see something when X isn't up you'll need that, it's CONFIG_FRAMEBUFFER_CONSOLE in the kernel config iirc.

That's correct, I don't have framebuffer support compiled in.  Through 2.6.28 I've used the standard 80x25 text mode with no problems; is this a change in behavior?

Yes. :)  KMS takes over the graphics hardware, so you don't get the legacy vgacon driver anymore, you have to use a framebuffer console (if you want a console at all that is).

Thanks for the information -- I've confirmed that either setting CONFIG_FRAMEBUFFER_CONSOLE or unsetting CONFIG_DRM_I915_KMS allows X to restore the console normally.  (I'm not sure why I had KMS set; the only warning in the help was about "old userspaces", so I may have figured it was safe to enable.)

In any case, I'd suggest that locking up the console if fbcon isn't available is not an ideal behavior (: so reopening to ask:  Is it not possible for the driver to at least detect this situation and abort?  If not, I'd suggest that DRM_I915_KMS should autoselect FRAMEBUFFER_CONSOLE in the kernel config.

(In reply to comment #8)
> If not, I'd suggest that
> DRM_I915_KMS should autoselect FRAMEBUFFER_CONSOLE in the kernel config.

... or at least specifically warn that fbcon is required if one wants a console (since I suppose there may be some people who don't need one).

Yeah, people have been getting bitten by this lately.  Pushed to the drm repo:

commit f29ce72795bf335553ab972606bc576b5473995e
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue May 12 09:08:31 2009 -0700

    drm/i915: automatically select FRAMEBUFFER_CONSOLE if !EMBEDDED

I'll send Linus a pull request shortly.