Bug 16638 - [965GM TV] switch from VT to X sometimes get blank screen
Summary: [965GM TV] switch from VT to X sometimes get blank screen
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Wang Zhenyu
QA Contact: Xorg Project Team
Depends on:
Reported: 2008-07-07 22:49 UTC by Richard Goedeken
Modified: 2009-03-01 22:00 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

gzipped log file (11.42 KB, application/octet-stream)
2008-07-08 09:01 UTC, Richard Goedeken
no flags Details
Log file showing underruns August 29, 2008 (242.58 KB, text/plain)
2008-08-29 09:50 UTC, Richard Goedeken
no flags Details
DVI/HDMI - Intrepid log file (129.76 KB, text/plain)
2008-09-18 11:09 UTC, elupus
no flags Details
xorg.log file extracted from the zipped one. (245.62 KB, text/plain)
2008-09-26 00:29 UTC, Michael Fu
no flags Details
TV svideo ok in X start (45.87 KB, text/plain)
2008-11-23 21:37 UTC, Wang Zhenyu
no flags Details
TV svideo no signal in X start (46.41 KB, text/plain)
2008-11-23 21:38 UTC, Wang Zhenyu
no flags Details
switch from VT to X ok (7.74 KB, text/plain)
2008-11-23 21:38 UTC, Wang Zhenyu
no flags Details
VT switch to X fail (7.64 KB, text/plain)
2008-11-23 21:39 UTC, Wang Zhenyu
no flags Details

Description Richard Goedeken 2008-07-07 22:49:00 UTC
- System: AOpen MiniPC MP965-DR
 - CPU/RAM: Core 2 duo T7500, 2GB ram
 - OS: Fedora 8
 - X server: xorg
 - intel_drv.so: git tip as of July 8, 2008, or intel-2.4 branch
 - system outputs: VGA, TMDS-1, LVDS, TV
 - TV: 32" Sony WEGA, NTSC 480i only

This bug causes a blank or solid color screen, but is different from the previous "blank-screen" bugs.  The previous blank-screen bug resulted from no signal output at all.  With this bug, there is a valid NTSC signal, but the screen is all black (or white, or some other color).

I did a bisect and found this bug was first present in commit c2e2fe48113667c683c6e1e9b1237635c41c61c3.  This bug is present in both the master and xf86-video-intel-2.4-branch.

This bug is intermittent.  Sometimes (but not always) it will appear when the X server starts.  Also, sometimes (but not always) it will appear when switching between text and graphical VTs.
Comment 1 Richard Goedeken 2008-07-07 22:51:09 UTC
One more piece of potentially useful information: When this bug occurs, it throws a Pipe A Underrun error in the xorg log file.
Comment 2 Gordon Jin 2008-07-08 02:28:00 UTC
Richard, thanks for the reporting and bisecting. Which kind of TV connector are you using, composite/svideo/component? Could you attach Xorg.0.log?

So it's caused by this commit:

commit c2e2fe48113667c683c6e1e9b1237635c41c61c3
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Jun 5 13:21:55 2008 -0700

    Move DSPARB setup into a separate function, and save/restore it at VT switch

Comment 3 Richard Goedeken 2008-07-08 09:01:14 UTC
Created attachment 17573 [details]
gzipped log file

Gordon, yes the bug is present in the commit that you referenced, but is not present in the commit just before it.  I am currently using the component output.  I have attached a gzipped xorg logfile.  For the session from which this log file was taken, the screen was blank at X startup.  I had to switch VTs 7 or 8 times to get a good screen, so there is a corresponding number of Pipe A underrun errors in the log.

Last night I tried starting from the tip of the 2.4 branch and reverting just this commit.  There were conflicts because the code has changed so much in the meantime.  I tried hacking the i830_driver.c file in some obvious ways to see if I could pin down the exact cause of the bug but was unable to correct the problem.
Comment 4 Joshua J. Berry 2008-08-08 02:32:51 UTC
I'm seeing something like this happen on my laptop's VGA port once every 24hrs or so.  (The internal display is fine -- it only seems to affect the external.)

The display goes either solid black or solid white (usually solid black), and nothing but a reboot fixes it.  Also, I see the following warnings show up in my Xorg.log when I try to switch VTs to/from the X server:

(WW) intel(0): ESR is 0x00000010, page table error
(WW) intel(0): PGTBL_ER is 0x00000010, display A pte
(WW) intel(0): Existing errors found in hardware state.

In my case, it's not connected to video-playing, however -- I'm using KDE trunk with OpenGL compositing enabled (in "Texture from Pixmap" mode).  This is on kernel 2.6.26 with driver version 2.3.2 and Xorg server 1.4.2.
Comment 5 Wang Zhenyu 2008-08-19 22:43:28 UTC
Could you try current 2.4-branch? I've an aopen here, which doesn't show this black issue.
Comment 6 Jesse Barnes 2008-08-20 15:24:32 UTC
There have also been a few fixes to the DSPARB code you pointed at since then, so please try git master or the 2.4 branch if possible.
Comment 7 Wang Zhenyu 2008-08-20 20:18:30 UTC
Works well here, so close.
Comment 8 Richard Goedeken 2008-08-29 09:50:17 UTC
Created attachment 18571 [details]
Log file showing underruns August 29, 2008
Comment 9 Richard Goedeken 2008-08-29 09:53:46 UTC
Today I tested with the tip of the 2.4-branch, which was just tagged as 2.4.2.  The blank screen problem and the buffer underruns remain.  It booted okay but when I switched VTs between text and graphics, it failed to come up in graphics mode 8 times out of 10.  When I rebuilt the driver from the previously stated version before the regression, it successfully switched back to the graphical VT 10 times out of 10.  I have attached the xorg.log file.
Comment 10 Gordon Jin 2008-09-12 00:08:34 UTC
A single line of "underrun" should not be a problem. So the remaining problem is VT switch.

Could you try 2.5-branch or master?

Do you have chance to try other monitors besides TV?
Comment 11 elupus 2008-09-18 11:03:26 UTC
I have the same hardware, and I can confirm the bug to exist on dvi output too. 

- OS: Ubuntu Intrepid
- X sever: 1.5.0
- Intel drv: 2.4.1

Comment 12 elupus 2008-09-18 11:04:56 UTC
Just noted that while at black screen, it seem to be printing loads of 
(EE) intel(0): underrun on pipe A!

Comment 13 elupus 2008-09-18 11:09:06 UTC
Created attachment 18987 [details]
DVI/HDMI - Intrepid log file

Working on startup, but went black after a few VT switches, then back to proper display at the end after VT switch.
Comment 14 Michael Fu 2008-09-25 01:08:12 UTC
(In reply to comment #11)
> I have the same hardware, and I can confirm the bug to exist on dvi output too. 
> - OS: Ubuntu Intrepid
> - X sever: 1.5.0
> - Intel drv: 2.4.1

elupus, if your issue is about DVI, that's probably a different issue. Maybe you can try the patch in bug# 16515 comment# 33 to see if it fix your problem...
Comment 15 Michael Fu 2008-09-26 00:29:35 UTC
Created attachment 19231 [details]
xorg.log file extracted from the zipped one.
Comment 16 Michael Fu 2008-09-26 00:46:25 UTC
(In reply to comment #7)
> Works well here, so close.

zhenyu, the one we have is MP965-D. The diff with MP965-DR has HDMI ( and IR remote control ).
Comment 17 elupus 2008-09-27 05:03:42 UTC
Just for reference. I'm currently not able to use intrepid and are back on hardy (intel_drv 2.2.1) and don't want to replumb the entire xorg. However I backported the fix you referenced and it made no difference. 

Since the older driver experiences the issue as well, it's probably not the same bug anyway, so my log should probably be obsoleted here. Will comment in the other report when i get a chance to test it on later code again.
Comment 18 elupus 2008-10-06 05:34:16 UTC
I've now rechecked the solution reference on intrepid too, and no luck. I still get a bunch of underrun detected. The intrepid server has in the meantime been updated to 1.5.1. I will see if i can compile tip instead and see if that helps.
Comment 19 liuhaien 2008-10-09 02:15:57 UTC
we also get the similar issue on our gm965,but it happens very often (about 3/5).
Comment 20 Gordon Jin 2008-11-16 21:57:56 UTC
Haien, did you see the issue also on TV? How about LVDS or VGA?
Comment 21 liuhaien 2008-11-16 23:29:45 UTC
(In reply to comment #20)
> Haien, did you see the issue also on TV? How about LVDS or VGA?

yes,this issue happens on TV ,VGA and LVDS ,but it can hardly be reproduced.we only see once or twice in about ten tries.
Comment 22 elupus 2008-11-17 05:38:47 UTC
I don't know if this has any relevance. But the issue for me has changed abit on ubuntu intrepid compared to gutsy (that is 2.4.1 vs 2.2.1). On gutsy the screen always turns black, but on intrepid I've seen other colors too. Then again, that might be a different issue when those show up.
Comment 23 Wang Zhenyu 2008-11-23 21:32:37 UTC
I've tested this on Aopen 965GM here. I met occasional TV startup fail and vt switch fail when switch from console back to X. I'll attach log and dumps below.
Comment 24 Wang Zhenyu 2008-11-23 21:37:30 UTC
Created attachment 20531 [details]
TV svideo ok in X start
Comment 25 Wang Zhenyu 2008-11-23 21:38:05 UTC
Created attachment 20532 [details]
TV svideo no signal in X start
Comment 26 Wang Zhenyu 2008-11-23 21:38:45 UTC
Created attachment 20533 [details]
switch from VT to X ok
Comment 27 Wang Zhenyu 2008-11-23 21:39:43 UTC
Created attachment 20534 [details]
VT switch to X fail

I only saw failure when switch from VT to X sometime, switch from X back to console looks solid.
Comment 28 Richard Goedeken 2008-11-24 04:57:29 UTC
Somebody should take a real hard look at what changed in commit c2e2fe48113667c683c6e1e9b1237635c41c61c3.  Something changed in this commit which causes this bug.  I've been using the driver built from the commit just before this one for the last 5-6 months because I can't stand to have this bug present on my HTPC.
Comment 29 Wang Zhenyu 2009-03-01 21:59:31 UTC
I can't produce VT switch failure on my aopen with svideo TV now. kernel 2.6.29-rc6, 2D driver master (2.6.2 should work too), user modesetting. Please test and reopen if current upstream still now work for you. 
Comment 30 Wang Zhenyu 2009-03-01 22:00:11 UTC
sorry, if not work for you, reopen.

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.