- System: AOpen MiniPC MP965-DR - CPU/RAM: Core 2 duo T7500, 2GB ram - OS: Fedora 8 - X server: xorg 1.4.99.1-0.10.fc9 - 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.
One more piece of potentially useful information: When this bug occurs, it throws a Pipe A Underrun error in the xorg log file.
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
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.
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.
Could you try current 2.4-branch? I've an aopen here, which doesn't show this black issue.
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.
Works well here, so close.
Created attachment 18571 [details] Log file showing underruns August 29, 2008
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.
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?
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
Just noted that while at black screen, it seem to be printing loads of (EE) intel(0): underrun on pipe A!
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.
(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...
Created attachment 19231 [details] xorg.log file extracted from the zipped one.
(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 ).
Michael: 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.
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.
we also get the similar issue on our gm965,but it happens very often (about 3/5).
Haien, did you see the issue also on TV? How about LVDS or VGA?
(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.
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.
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.
Created attachment 20531 [details] TV svideo ok in X start
Created attachment 20532 [details] TV svideo no signal in X start
Created attachment 20533 [details] switch from VT to X ok
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.
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.
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.
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.