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
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
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.