Ok, I really don't want to add a quirk to handle this sort of thing.  I'll ping our chipset guys and see if I can figure out what's going on...  Maybe this board is just wired up strangely.

Brice, can you get a few things from this user?
  - no framebuffer drivers
  - register dump from startup, before X starts
  - register dump from after VT switch (from ssh or something, if possible)

Thanks,
Jesse

I have done the requested tests and will add a tarball will the regdumps.

I have done 4 sets of tests: with the old (2.2.0) and new (2.2.0.90) driver, and with and without framebuffer.
For the tests with frambuffer I've booted with 'vga=791'; for those without with 'video=vfb:off'.

Per test set I have made three regdumps:
- after booting the system, before starting X.Org
- after starting X.Org (using startx)
- after switching from X.Org to VT1

All tests were done while running the 2.6.24.2 kernel. See below for the relevant bit of the kernel config (unset options omitted).

The results for the console switches were interesting:
- old driver with framebuffer -> display is OK
- old driver without framebuffer -> no display, monitor switches off
- new driver with framebuffer -> display is blank, monotor remains on
- new driver without framebuffer -> display is OK

So, the issue is *reversed* for the two drivers.

The reason I include the config is that I wonder if this issue could be related to a kernel bug I filed for 2.6.23 (still unresolved!):
http://bugzilla.kernel.org/show_bug.cgi?id=9310
See also the message on LKML linked from that BR, which includes an analysis from Antonio Daplas of that issue.

Note that the issue there was similar and was traced to the newly added FRAMEBUFFER_CONSOLE_DETECT_PRIMARY option. Also note that I do have this option currently enabled in my kernel config.

I'm not sure whether this means that the new driver is really OK and the kernel is at fault, or that the change in the new driver is only a workaround for the kernel issue and thus will work for some, but not for others.

If you think the two issues are related, I suggest you contact Antonino Daplas, who was responsible for the commit that added the FRAMEBUFFER_CONSOLE_DETECT_PRIMARY option.

If needed I can also compile a kernel without that option enabled and provide regdumps for that.

Cheers,
FJP

CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=m
CONFIG_DRM=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_FB_INTEL=m
CONFIG_FB_INTEL_I2C=y
CONFIG_FB_VIRTUAL=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_PROGEAR=m

CONFIG_DISPLAY_SUPPORT=m

CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

Created attachment 14455 [details]
Requested register dumps

The file names match the testcases as described in my previous post.
For the VT switches, the result is also indicated in the name.

One additional comment.
In all test cases I could switch back to X.Org without problem, even if there was no display or the monitor turned itself off after switching to VT1. After switching back to VT7, X.Org/KDE would be displayed correctly again.

Frans, thanks a lot for your thorough testing!

So it sounds like as long as you don't use the framebuffer drivers, things are ok with the latest Intel driver.  We generally recommend that people not use the framebuffer drivers, since we've done no integration work between them and the X driver, so conflicts are common and you're likely to see hangs.

Given that when X is running, it owns the graphics device, I'm going to mark this one as notourbug, since the fb drivers are the ones that need to adapt to the presence of X...

(Entering through the website as a reply by mail resulted in:
   Unknown encoding '"utf-8"'
You may just want to fix that...)

> Given that when X is running, it owns the graphics device, I'm going to
> mark this one as notourbug, since the fb drivers are the ones that need
> to adapt to the presence of X...

I find that a very disappointing attitude, especially as I have been using 
framebuffer in combination with X for a _long_ time and have never before 
seen such issues. Since when are regressions caused by changes in _your_ 
software not at least partially _your_ problem?

I would have hoped for a somewhat more cooperative attitude from X.Org 
developers towards kernel (framebuffer) development.

I use framebuffer because I really like to be able to have the higher 
resolution for my text VTs. You are basically denying me that here.

I've just done one additional test.
When using a kernel with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY unset, the behavior when booted with framebuffer is the same as with that option set, so it is not relevant to the issue.

This means that I still consider this a regression caused by changes in the X.Org intel driver.

Cheers,
FJP

Cooperation would be fine, but the intelfb driver is basically unmaintained and doesn't support many configurations (or are you using vesafb?).

We also know that it actively conflicts with the X driver (even if you haven't
seen issues, many other have, frequently).  Also, we'd prefer to focus our
efforts on something that finally resolves the conflict between DRM and the
framebuffer drivers: the kernel modesetting branch.

That said, there haven't been many changes between 2.2.0 and 2.2.0.90, so maybe you could bisect the 2D driver and find where things broke with fb?  That might give us a chance of fixing it before release...

I'm using vesafb:
$ cat /proc/fb
0 VESA VGA
1 Virtual FB

I already did the bisection; see the bug history (first entry).

Thanks for this last reply.

Oops, yeah forgot that you already bisected it, sorry (and you're right, making things work with vesafb isn't unreasonable).  Looking at the register dumps, there are definitely some important differences:

--- regdump_2.2.0.90-3_fb_nox.txt       2008-02-20 04:28:12.000000000 -0800
+++ regdump_2.2.0.90-3_fb_vt-switch-blank.txt   2008-02-20 04:29:31.000000000 -0800
@@ -27,8 +27,8 @@
 (II):         PFIT_CONTROL: 0x00000000
 (II):      PFIT_PGM_RATIOS: 0x00000000
 (II):      PORT_HOTPLUG_EN: 0x00000020
-(II):    PORT_HOTPLUG_STAT: 0x00000000
-(II):             DSPACNTR: 0x94000000 (enabled, pipe A)
+(II):    PORT_HOTPLUG_STAT: 0x00000b00
+(II):             DSPACNTR: 0x58000000 (disabled, pipe A)
 (II):           DSPASTRIDE: 0x00000800 (2048 bytes)
 (II):              DSPAPOS: 0x00000000 (0, 0)
 (II):             DSPASIZE: 0x02ff03ff (1024, 768)
@@ -125,7 +125,7 @@
 (II):                 SR06: 0x00
 (II):                 SR07: 0x00
 (II):                  MSR: 0x67
-(II):                  ARX: 0x20
+(II):                  ARX: 0x30
 (II):                 AR00: 0x00
 (II):                 AR01: 0x01
 (II):                 AR02: 0x02
@@ -142,7 +142,7 @@
 (II):                 AR0d: 0x3d
 (II):                 AR0e: 0x3e
 (II):                 AR0f: 0x3f
-(II):                 AR10: 0x0c
+(II):                 AR10: 0x00
 (II):                 AR11: 0x00
 (II):                 AR12: 0x0f
 (II):                 AR13: 0x08

So for some reason, the new driver isn't properly restoring DSPACNTR even though it was enabled before X started.  Looking at the code, I can see why that might happen.  Can you give this patch a try?

diff --git a/src/i830_driver.c b/src/i830_driver.c
index 290236e..5cd0a34 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -2120,12 +2120,14 @@ RestoreHWState(ScrnInfoPtr pScrn)
     * enabled if pipe A is actually on (otherwise we have a bug in the initial
     * state).
     */
-   if (pI830->saveDSPACNTR & DISPPLANE_SEL_PIPE_A) {
+   if ((pI830->saveDSPACNTR & DISPPLANE_SEL_PIPE_MASK) ==
+       DISPPLANE_SEL_PIPE_A) {
        OUTREG(DSPACNTR, pI830->saveDSPACNTR);
        OUTREG(DSPABASE, INREG(DSPABASE));
        i830WaitForVblank(pScrn);
    }
-   if (pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_A) {
+   if ((pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_MASK) ==
+       DISPPLANE_SEL_PIPE_A) {
        OUTREG(DSPBCNTR, pI830->saveDSPBCNTR);
        OUTREG(DSPBBASE, INREG(DSPBBASE));
        i830WaitForVblank(pScrn);
@@ -2177,12 +2179,14 @@ RestoreHWState(ScrnInfoPtr pScrn)
        * Note that pipe B may be disabled, and in that case, the plane
        * should also be disabled or we must have had a bad initial state.
        */
-      if (pI830->saveDSPACNTR & DISPPLANE_SEL_PIPE_B) {
+      if ((pI830->saveDSPACNTR & DISPPLANE_SEL_PIPE_MASK) ==
+         DISPPLANE_SEL_PIPE_B) {
          OUTREG(DSPACNTR, pI830->saveDSPACNTR);
          OUTREG(DSPABASE, INREG(DSPABASE));
          i830WaitForVblank(pScrn);
       }
-      if (pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_B) {
+      if ((pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_MASK) ==
+         DISPPLANE_SEL_PIPE_B) {
          OUTREG(DSPBCNTR, pI830->saveDSPBCNTR);
          OUTREG(DSPBBASE, INREG(DSPBBASE));
          i830WaitForVblank(pScrn);

I'm glad I was able to convince you :-)

And good news, this patch _does_ fix the issue. Tested both with and without framebuffer.

Thanks Jesse.

Great, thanks for your persistence on this one, and sorry for being so thick about it. :)

I've pushed the fix as 28049540d8a9f79401fcfeb90784f5a528e7b34f.  I'll also pull it into the 2.2 branch.