Bug 14481

Summary: [945G] regression: VT switch broken with vesafb
Product: xorg Reporter: Brice Goglin <brice.goglin>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: ben.pineau, bugs, elendil, marcus
Version: 7.3 (2007.09)Keywords: regression
Hardware: Other   
OS: All   
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465268
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 13493    
Description Flags
Requested register dumps none

Description Brice Goglin 2008-02-13 09:28:13 UTC
Bug reported by Franz Pop on the Debian BTS. He says:

"When I switch from my X session to other VTs, I get only a black screen. Downgrading to 2.2.0 solved the issue. I see in the BTS that other reports of VT switching issues were _solved_ in the newer versions, but for me the new version breaks things."

His graphics controller is:
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ
Integrated Graphics Controller [8086:2772] (rev 02)

He git-bisected and found the following commit breaking VT switch for him:

commit f69b48fe24ef94dac44b8123884ca71df675be4b
Author: Jesse Barnes <jbarnes@hobbes.virtuousgeek.org>
Date:   Tue Dec 18 18:10:33 2007 -0800

    Unconditionally restore pipe configuration

His config and log are available at:
Comment 1 Jesse Barnes 2008-02-19 14:39:12 UTC
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.
Comment 2 Jesse Barnes 2008-02-19 14:43:15 UTC
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)

Comment 3 Frans Pop 2008-02-20 05:40:19 UTC
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 ( 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 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!):
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.





Comment 4 Frans Pop 2008-02-20 05:42:49 UTC
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.
Comment 5 Frans Pop 2008-02-20 05:52:55 UTC
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.
Comment 6 Jesse Barnes 2008-02-20 08:40:07 UTC
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...
Comment 7 Frans Pop 2008-02-20 09:32:07 UTC
(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.
Comment 8 Frans Pop 2008-02-20 10:06:24 UTC
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.

Comment 9 Jesse Barnes 2008-02-20 10:08:43 UTC
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, 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...
Comment 10 Frans Pop 2008-02-20 10:33:08 UTC
I'm using vesafb:
$ cat /proc/fb
1 Virtual FB

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

Thanks for this last reply.
Comment 11 Jesse Barnes 2008-02-20 11:14:32 UTC
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) ==
        OUTREG(DSPACNTR, pI830->saveDSPACNTR);
-   if (pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_A) {
+   if ((pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_MASK) ==
        OUTREG(DSPBCNTR, pI830->saveDSPBCNTR);
@@ -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) ==
          OUTREG(DSPACNTR, pI830->saveDSPACNTR);
-      if (pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_B) {
+      if ((pI830->saveDSPBCNTR & DISPPLANE_SEL_PIPE_MASK) ==
          OUTREG(DSPBCNTR, pI830->saveDSPBCNTR);
Comment 12 Frans Pop 2008-02-20 13:03:58 UTC
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.
Comment 13 Jesse Barnes 2008-02-20 13:20:37 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.