Bug 19578

Summary: [i915] VT->X get black screen if non-DRI or UXA
Product: xorg Reporter: zhao jian <jian.j.zhao>
Component: Driver/intelAssignee: Wang Zhenyu <zhenyu.z.wang>
Status: VERIFIED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: bjoern.martensen, bugs, bugzi11.fdo.tormod, dr-xorg, mike.lifeguard, waldauf, zorael
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 18858, 20276, 21255    
Attachments:
Description Flags
xorg.conf
none
xorg.0.log
none
xorg.0.log
none
i945 UMS vt switch fix none

Description zhao jian 2009-01-15 01:58:51 UTC
Created attachment 22002 [details]
xorg.conf

System Environment:
----------------------
Host:           915gm
Arch:           i386
OSD:            Fedora release 8 (Werewolf)
Kernel:         2.6.28 
Libdrm: (master)18d3cc076b53f2032eed1f9a4b21947f4cb9e4e7
Mesa: (intel-2008-q4)200fa9165d7078a6f36c5c9d3e0c997c2438bde3
Xserver: (server-1.6-branch)251d0d8090322b2c9dc0c8b7bef001f338d19433
Xf86_video_intel: (xf86-video-intel-2.6-branch) 
                   5cd65d965c8ed388275fe2084553302aad601d4a
kernel:  drm-intel-2.6.28 branch  e1a6fcee467556a7e955fe1f7ccc134dd2f974e7

Bug Description:
---------------------
Start X with xinit under UXA, then doing vt switch with 'chvt 1' and 'chvt 7'. When come back to the graphic mode(terminal 7 or 8), it is black screen. But if I first start gnome-session and compiz enabled, it can change VT successfully.(It will fail if I first run it without compiz) With EXA it works well except that I disable DRI. 

Reproduce Steps:
----------------
1. enable uxa in xorg.conf
2. xinit&
3. chvt 1 
4. chvt 7
Comment 1 zhao jian 2009-01-15 01:59:23 UTC
Created attachment 22003 [details]
xorg.0.log
Comment 2 Gordon Jin 2009-01-15 06:19:42 UTC
Zhenyu already reproduces this.
Comment 3 Martin 2009-01-16 04:41:29 UTC
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?
Comment 4 Martin 2009-01-16 04:42:18 UTC
(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
Comment 5 Gordon Jin 2009-01-18 01:31:20 UTC
(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"?
Comment 6 Martin 2009-01-18 01:44:46 UTC
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.
Comment 7 Wang Zhenyu 2009-01-19 18:36:08 UTC
Martin, this problem should be pre-965G chip specific, and if your 965GM has the same symptom, that might be another problem.  
Comment 8 Martin 2009-01-20 06:21:57 UTC
So, should I file another bug? I can't check the gnome-session stuff since I'm on KDE...
Comment 9 Martin 2009-01-23 12:46:01 UTC
It's fixed in 2.6.99.1+git20090102 (launchpad xorg-edgers ppa) for me.
Comment 10 Gordon Jin 2009-01-30 20:21:58 UTC
*** Bug 19837 has been marked as a duplicate of this bug. ***
Comment 11 Gordon Jin 2009-02-24 04:17:11 UTC
*** Bug 20264 has been marked as a duplicate of this bug. ***
Comment 12 Gordon Jin 2009-02-25 17:21:35 UTC
Does this still exist?
Comment 13 zhao jian 2009-03-03 17:33:02 UTC
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
Comment 14 Wang Zhenyu 2009-03-12 08:44:21 UTC
lower priority. KMS with recent driver doesn't have this problem.
Comment 15 Wang Zhenyu 2009-03-16 00:06:50 UTC
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.
Comment 16 Martin 2009-03-16 00:13:33 UTC
I can confirm the fix. Running 2.6.29-rc8, and intel driver 2:2.6.99.1+git20090312 + UMS.
Comment 17 zhao jian 2009-04-01 20:31:18 UTC
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
Comment 18 zhao jian 2009-04-01 21:32:19 UTC
It still existed with UMS 2.6.29-rc8 and the latest code. So I reopen it. 
Comment 19 Wang Zhenyu 2009-04-06 20:12:36 UTC
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?
Comment 20 zhao jian 2009-04-07 22:52:19 UTC
(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
Comment 21 zhao jian 2009-04-07 23:03:13 UTC
Created attachment 24658 [details]
xorg.0.log
Comment 22 Gordon Jin 2009-04-27 00:01:49 UTC
*** Bug 21352 has been marked as a duplicate of this bug. ***
Comment 23 Gordon Jin 2009-06-05 16:02:14 UTC
I'm very interested if this bug still exists? If so I'll mark it to block 2.8 release.
Comment 24 zhao jian 2009-06-08 00:21:12 UTC
(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 
Comment 25 Gordon Jin 2009-06-23 19:20:29 UTC
*** Bug 21647 has been marked as a duplicate of this bug. ***
Comment 26 JR 2009-06-25 01:53:18 UTC
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.
Comment 27 Jesse Barnes 2009-06-29 18:44:05 UTC
Do we fail to restore the swapped configuration possibly?
Comment 28 Wang Zhenyu 2009-06-30 00:09:35 UTC
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.
Comment 29 JR 2009-06-30 10:24:11 UTC
(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.
Comment 30 Wang Zhenyu 2009-06-30 19:23:18 UTC
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>

Comment 31 Yifei Chen 2009-06-30 20:47:54 UTC
We still get blank screen after vt switch with this commit on 945GM under UMS+UXA.
Comment 32 Gordon Jin 2009-06-30 23:04:03 UTC
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.
Comment 33 Wang Zhenyu 2009-06-30 23:16:14 UTC
I only have 945GM (IBM R60) which works with my patch. For new failure, please provide needed info at least..
Comment 34 Yifei Chen 2009-07-01 19:06:27 UTC
Wired but good, it works fine on and 915GM and 945GM now :)
Comment 35 Tormod Volden 2009-07-10 12:08:17 UTC
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).
Comment 36 Tormod Volden 2009-07-10 12:37:12 UTC
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

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.