Bug 19578

Created attachment 22003 [details]
xorg.0.log

Zhenyu already reproduces this.

I have the same problem except:
- I switch using alt-f1/alt-f7
- I use EXA *with* DRI (to work around)

Should I file a new bug, or is it a duplicate?

(In reply to comment #3)
> I have the same problem except:
> - I switch using alt-f1/alt-f7
> - I use EXA *with* DRI (to work around)
> 
> Should I file a new bug, or is it a duplicate?
> 

Forgot to mention hardware: GM965

(In reply to comment #3)
> I have the same problem except:
> - I switch using alt-f1/alt-f7
That's essentially the same.

> - I use EXA *with* DRI (to work around)
Do you mean EXA with DRI "still reproduces this bug" or "a workaround to avoid this bug"?

I meant that, using EXA with DRI is *also* a way to work around this bug, for me.
A minor difference, but maybe important. I never tested EXA without DRI.

Martin, this problem should be pre-965G chip specific, and if your 965GM has the same symptom, that might be another problem.  

So, should I file another bug? I can't check the gnome-session stuff since I'm on KDE...

It's fixed in 2.6.99.1+git20090102 (launchpad xorg-edgers ppa) for me.

*** Bug 19837 has been marked as a duplicate of this bug. ***

*** Bug 20264 has been marked as a duplicate of this bug. ***

Does this still exist?

Yes. It still exists on 915gm both in UXA and non-DRI with the following configuration: 

Platform:               915GM
Arch:           i386
OSD:            Fedora release 8 (Werewolf)
Kernel:         2.6.29-rc6
Libdrm:         (master)a6dd0afa87558a670f970e61b023f45a396539eb
Mesa:            (mesa_7_4_branch)b65bfde84d2f0d83a432602cda425a63560e4034
Xserver:         (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:  (master)14bb61e0c2e28725a2f6167d3263649bc845be18

lower priority. KMS with recent driver doesn't have this problem.

Just tried 2.6.29-rc8 with xf-i-i master in ums and kms, both doesn't have this problem now. 

Mark as fixed, please verify it. Reopen if you still see it.

I can confirm the fix. Running 2.6.29-rc8, and intel driver 2:2.6.99.1+git20090312 + UMS.

It still existed on 945gm with UMS 2.6.29-rc8 and the latest code: 
Libdrm:         (master)  51d6346f9f3c425f49e57d185530c6bcaeb94f5e
Mesa:           (mesa_7_4_branch)781fb79c596cb6b153645c86c89ba2930521aeef
Xserver:        (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:   (2.7)e2465249a90b9aefe6d7a96eb56a51fde54698a0

It still existed with UMS 2.6.29-rc8 and the latest code. So I reopen it. 

Please provide the step you can still produce this, and what machine? log?

As two people have confirmed this, possible to bisect if still see?

(In reply to comment #19)
> Please provide the step you can still produce this, and what machine? log?
> As two people have confirmed this, possible to bisect if still see?

Reproduce Steps:
----------------
1. enable uxa or exa with dri off in xorg.conf
2. xinit&
3. chvt 1 
4. chvt 7

Both on 915gm and 945gm have such issue. The log file is in attachment. With KMS, it is OK. With the following configuration:
Libdrm:             (master)1faab66cfd1a854925da6ff7109aa614292dea90
Mesa:               (mesa_7_4_branch)de197cf991416f0cd65ad2e2d2ca9aa599b52075
Xserver:            (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:   (2.7)3e5586cace98f73a9f8403a6446d380899ecbce9
Kernel:             (drm-intel-2.6.29)71d7aec4bbf923eaf43563c03459726a746cd332

Created attachment 24658 [details]
xorg.0.log

*** Bug 21352 has been marked as a duplicate of this bug. ***

I'm very interested if this bug still exists? If so I'll mark it to block 2.8 release.

(In reply to comment #23)
> I'm very interested if this bug still exists? If so I'll mark it to block 2.8
> release.

Yes, in UMS with UXA, it still exist on 945gm with below commits: 
Libdrm:         (master)3d4bfe8c893d016ef43d1ebf28e4607aa1f540a4
Mesa:           (mesa_7_5_branch)cfff2a6189b38f1ee8c8ca204e223574a5abf760
Xserver:         (server-1.6-branch)5cd5a01259ba349f1868ca4af04207cf120d69e4
Xf86_video_intel:   (master)66ceedc0cc123e5c9f85f708b2e56d943f00e4b9
Kernel:         (for-linus)0e7ddf7eeeef5aea85412120539ab5369577faeb 

*** Bug 21647 has been marked as a duplicate of this bug. ***

Assuming bug #21647 is a duplicate of this one, I'll place my responses here.

From comment #4 (of that bug):
> can you get a backtrace from X with an ssh session or something (just
> gdb -p `pidof X` and do a 'bt').

X hasn't crashed, but when I try to switch back to it the screen is dark. I can switch out and do something like "DISPLAY=:0 ppracer" and it will run. If I switch to the X display, I can hear the ppracer music playing in the background, but I obviously can't see anything. So the commands suggested just (rightly) say that there is no backtrace; X is running happily.

dmesg just says:
[drm:i95_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
and nothing else of interest. I've attached Xorg.0.log copies in that duplicate bug report.

Do we fail to restore the swapped configuration possibly?

Created attachment 27249 [details] [review]
i945 UMS vt switch fix

Please test with this one. It'll also be good to try on more platforms for regression testing.

thanks.

(In reply to comment #28)
> Created an attachment (id=27249) [details]
> i945 UMS vt switch fix
> 
> Please test with this one. It'll also be good to try on more platforms for
> regression testing.
> 

Yes, that patch fixes it for me. Many thanks.

Pushed patch. Thanks.

commit 7e79fc8aa93df4df37c25cf37ee0ec6c7caca1d9
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Tue Jun 30 15:40:34 2009 +0800

    Fix 945GM VT switch in UMS
    
    Bug #19578. We should set private intel_crtc state according
    to current, as fail to do so pipe A needs active won't be taken
    care of. Also make sure pipe swap operation always set during
    VT switch.
    
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

We still get blank screen after vt switch with this commit on 945GM under UMS+UXA.

reopening. We need to make sure both 915GM and 945GM working before closing this one.
Zhenyu, I'm wondering why you only mention 945 in your patch title.

I only have 945GM (IBM R60) which works with my patch. For new failure, please provide needed info at least..

Wired but good, it works fine on and 915GM and 945GM now :)

The commit 7e79fc8aa93df4df37c25cf37ee0ec6c7caca1d9 seems to have caused a regression with non-KMS. Please see https://bugs.launchpad.net/bugs/394490 (xrandr: Configure crtc 0 invalid time).

Sorry for the noise, this was probably wrong commit and bug report. Anyway, the issue in question has been reported in https://bugs.freedesktop.org/show_bug.cgi?id=21987#c9