Bug 13326 - [i945] Jittering and blanking display with framebuffer compression
[i945] Jittering and blanking display with framebuffer compression
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
unspecified
x86 (IA32) Linux (All)
: high major
Assigned To: Jesse Barnes
Xorg Project Team
: NEEDINFO
: 13418 13446 (view as bug list)
Depends on:
Blocks: 13493 15000
  Show dependency treegraph
 
Reported: 2007-11-20 16:14 UTC by Ben Gamari
Modified: 2008-06-02 08:31 UTC (History)
16 users (show)

See Also:
i915 platform:
i915 features:


Attachments
My xorg.conf (4.27 KB, text/plain)
2007-11-22 10:20 UTC, Ben Gamari
no flags Details
A log from a jittering (not yet blanked) X session (30.57 KB, text/plain)
2007-11-22 10:20 UTC, Ben Gamari
no flags Details
Log file from crashed X (29.84 KB, text/plain)
2007-11-23 10:57 UTC, Ben Gamari
no flags Details
Log of server with ModeDebug enabled (57.35 KB, text/plain)
2007-11-29 14:06 UTC, Ben Gamari
no flags Details
blacklight fixes (1.35 KB, text/plain)
2007-12-03 18:51 UTC, Sérgio M. Basto
no flags Details
The output of intel_reg_dumper while the screen is working (7.93 KB, text/plain)
2007-12-04 10:36 UTC, Ben Gamari
no flags Details
Register dump during blank screen (7.93 KB, text/plain)
2007-12-06 14:37 UTC, Ben Gamari
no flags Details
enable ssc for lvds dual channel (1.03 KB, patch)
2008-01-15 00:29 UTC, Hong Liu
no flags Details | Splinter Review
Change FBC idle mode (574 bytes, patch)
2008-02-19 20:35 UTC, Jesse Barnes
no flags Details | Splinter Review
/var/log/Xorg.0.log (61.43 KB, text/plain)
2008-03-31 15:46 UTC, Matej Cepl
no flags Details
Add FIFO debug code & default values (1.02 KB, patch)
2008-05-06 16:02 UTC, Jesse Barnes
no flags Details | Splinter Review
Fixup DSPARB default value (2.29 KB, patch)
2008-05-21 12:09 UTC, Jesse Barnes
no flags Details | Splinter Review
Fixup FIFO underrun on modeset (3.38 KB, patch)
2008-05-21 12:19 UTC, Jesse Barnes
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Gamari 2007-11-20 16:14:13 UTC
Running drm, mesa, and xf86-video-intel from git master causes the entire screen image to periodically jump to the size for a fraction of a second and then return. This can happen several times a minute. Eventually, the screen itself will blank. This condition cannot be cleared by restarting X or running Xrandr and thus requires a full reboot.

The problem is discussed further on the list in http://lists.freedesktop.org/archives/xorg/2007-November/030147.html.
Comment 1 Ben Gamari 2007-11-20 16:16:38 UTC
Interestingly, the bug does not effect other pipes. I have had a CRT plugged into the VGA output and it has continued working fine while my laptop's LCD has gone blank.
Comment 2 Gordon Jin 2007-11-20 18:25:00 UTC
Please attach xorg.conf and full Xorg.0.log.
Comment 3 Ben Gamari 2007-11-22 10:19:22 UTC
Just to note, my machine is actually a Dell D820 although this problem was originally reported by a mac owner. Sorry, should have mentioned that earlier.
Comment 4 Ben Gamari 2007-11-22 10:20:01 UTC
Created attachment 12690 [details]
My xorg.conf
Comment 5 Ben Gamari 2007-11-22 10:20:59 UTC
Created attachment 12691 [details]
A log from a jittering (not yet blanked) X session
Comment 6 Ben Gamari 2007-11-23 10:57:32 UTC
Created attachment 12704 [details]
Log file from crashed X

Just now the machine froze again, this time with a blank orange screen. I was able to switch to a VT, but the machine apparently locked when I attempted to switch back to X. This might be another issue but then again it might be related.  Attached is the log file from the crashed X session
Comment 7 Ben Gamari 2007-11-25 15:49:39 UTC
Any input on this bug? Even advice as how to approach debugging the bug myself would be welcome. I'm fairly competent at debugging driver issues but without an error I don't even know where to start.
Comment 8 Tino Keitel 2007-11-25 15:55:44 UTC
Maybe a git bisect? The problem is that only a human can the problem, so no automatic bisect is possible.
Comment 9 Jesse Barnes 2007-11-27 17:18:18 UTC
Does this still happen if you disable framebuffer compression?  Does it still happen with more recent pulls from git?
Comment 10 Tino Keitel 2007-11-27 23:25:39 UTC
It happens without EXA, and EXA is required for framebuffer compression AFAIK.
Comment 11 Jesse Barnes 2007-11-28 08:17:43 UTC
Yes, but the driver defaults to EXA now, and your log indicates that it's in use.
Comment 12 Tino Keitel 2007-11-28 08:23:29 UTC
To quote my original mail on the xorg mailing list regarding this issue:

----------------------------------------------------------------------
I tried the git version ab2055ebb20aa6de121fa377e488ce91913035ae of             
intel_drv.so with an Xorg server version 1.4. The computer is a Mac             
mini Core Duo with i945 graphics. A 1680x1050 TFT is connected via              
DVI-D.                                                                          
                                                                                
Every few seconds, the whole screen jittered for some tenth of a                
second. After a few minutes of normal work, the whole picture suddenly          
became black. Restarting the Xorg server or rebooting via kexec didn't          
help. I had to do a hard reboot to get a working Xserver again.                 
                                                                                
Both of the above bugs already happened with a git version from a few           
months ago. I can't tell what exact version that was, but the date              
could be the 12th of September.                                                 
----------------------------------------------------------------------

This was with EXA disabled.
Comment 13 Jesse Barnes 2007-11-28 08:47:31 UTC
Ah ok, thanks for the clarification.  I was suspicious of FBC since it rescans the framebuffer every 15 seconds or so, but if you had EXA off, it should have been disabled (you would see messages in your log about it if it was still on for some reason).

Can you build the intel_reg_dumper tool (src/reg_dumper in the git tree) and try to get register dumps from while things are working and then after the screen blanks?  If we're lucky, something will have changed and that might give us a clue.  Otherwise it might just be a bad mode that the LCD rejects after awhile?

Adding Hong to the cc list since he's been looking at LCD mode programming lately.

Hong, any ideas?
Comment 14 Tino Keitel 2007-11-28 08:53:19 UTC
I use a modeline in my xorg.conf to get a usable mode at all with version 2.1 (fixed meanwhile in version 2.2, which I would use this this bug would't be present). So I guess that 2.1 and 2.2 use the same mode.

Another detail: a reboot via kexec won't bring back a usable output, the screen stays black. I have do trigger a real reboot without kexec to get back working graphics.
Comment 15 Hong Liu 2007-11-28 18:19:25 UTC
(In reply to comment #14)
> I use a modeline in my xorg.conf to get a usable mode at all with version 2.1
> (fixed meanwhile in version 2.2, which I would use this this bug would't be
> present). So I guess that 2.1 and 2.2 use the same mode.
> 

So which modeline is working with your card?
And would you please attach your xorg log with "modedebug" turned on?
Comment 16 Hong Liu 2007-11-28 18:22:09 UTC
(In reply to comment #7)
> Any input on this bug? Even advice as how to approach debugging the bug myself
> would be welcome. I'm fairly competent at debugging driver issues but without
> an error I don't even know where to start.
> 
Hi, Ben
Would you please turn on the "modedebug" option and attach your xorg.log?
I am not sure whether your 1920x1200 (requires 162M pixel clock) is OK for our LVDS mode programming?

Thanks,
Hong
Comment 17 Johannes Engel 2007-11-29 12:51:54 UTC
Does it help to unload the drm module from git and reload the one from kernel tree? At least that avoids the bug for me even without a reboot (see #13446).
Comment 18 Tino Keitel 2007-11-29 12:54:00 UTC
I don't use drm from git. I always use the one from the kernel tree.
Comment 19 Ben Gamari 2007-11-29 14:06:11 UTC
Created attachment 12833 [details]
Log of server with ModeDebug enabled
Comment 20 Ben Gamari 2007-11-29 14:08:48 UTC
I just attached a log from Xorg starting with the ModeDebug option enabled. Note that I too run the kernel in-tree DRM modules (presently from 2.6.23). Additionally, it appears that framebuffer compression is enabled in my case.
Comment 21 Sérgio M. Basto 2007-12-03 18:51:46 UTC
Created attachment 12921 [details]
blacklight fixes

Hi, I send this weekend this patch to Jesse Barnes and Lukas Hejtmanek. They are the authors , I just compile what I think is the best .
The patch solve (almost) all my problem, could you give a try , and feed back please
Comment 22 Ben Gamari 2007-12-03 20:13:56 UTC
(In reply to comment #21)
> Created an attachment (id=12921) [details]
> blacklight fixes
> 
> Hi, I send this weekend this patch to Jesse Barnes and Lukas Hejtmanek. They
> are the authors , I just compile what I think is the best .
> The patch solve (almost) all my problem, could you give a try , and feed back
> please 
> 

I have yet to try the patch you provided but unfortunately I doubt this will fix my problem. I'm fairly certain that the backlight on my machine (a Dell Latitude D820) is not controlled by the graphics controller. I'll give it a try anyways though.
Comment 23 Johannes Engel 2007-12-04 03:37:06 UTC
I tested that patch and at least for me it changes nothing. Maybe because I also have a Dell Latitude D820. :)
Comment 24 Tino Keitel 2007-12-04 04:00:25 UTC
I have this problem with an external Eizo TFT, so it shouldn't have to do anything with ACPI backlight stuff.
Comment 25 Ben Gamari 2007-12-04 10:33:25 UTC
Yeah, sounds like the backlight code isn't the problem. Unfortunately, I've been having difficulty reproducing the problem lately. I don't believe it has happened in the last few days. Has anyone else found that the incidents have stopped wit recent git revisions or have I just had a lucky streak? I never was able to figure out a way to reliably produce the blanking, so maybe it's just been luck that it has stopped. Has anyone found a way to force the problem to occur?
Comment 26 Ben Gamari 2007-12-04 10:36:20 UTC
Created attachment 12933 [details]
The output of intel_reg_dumper while the screen is working

I should point out that while the blanking may have apparently stopped, the jittering continues.
Comment 27 Johannes Engel 2007-12-05 05:35:32 UTC
I just got the blanking error again. one additional remark: suspending to ram and resuming again restores the screen (VBE_POST??).
Also after that compiz had been killed.
Comment 28 Ben Gamari 2007-12-06 14:37:55 UTC
Created attachment 12983 [details]
Register dump during blank screen

I finally managed to get the bug to recur. This time the screen turned straight white. This time I managed to SSH in to the machine and grab a register dump as well. Moreover, I can confirm that suspending and resuming the machine fixes the issue. Additionally I know for a fact that  backlight control is not the issue:
  1) When I allowed the machine to sit idle, I could see gnome-power-manager eventually dim the display
  2) My machine does not rely on the GPU for backlight control.

I hope this helps. If there's anything else necessary for debugging, just ask.

- Ben
Comment 29 Tino Keitel 2007-12-10 12:49:12 UTC
I just tried the latest git (d9df93578b74785c08ba860b4c9aa23b0c89c91c). The jittering is still there. However, no black screen so far.
Comment 30 Hong Liu 2007-12-10 17:34:31 UTC
(In reply to comment #29)
> I just tried the latest git (d9df93578b74785c08ba860b4c9aa23b0c89c91c). The
> jittering is still there. However, no black screen so far.
> 

Would you please try to add some new modes toggling the polarity of HSYNC VSYNC to see if there is a mode working?

Thanks,
Hong
Comment 31 Ben Gamari 2007-12-10 18:03:53 UTC
(In reply to comment #30)
> (In reply to comment #29)
> > I just tried the latest git (d9df93578b74785c08ba860b4c9aa23b0c89c91c). The
> > jittering is still there. However, no black screen so far.
> > 
> 
> Would you please try to add some new modes toggling the polarity of HSYNC VSYNC
> to see if there is a mode working?
> 
> Thanks,
> Hong
> 


Have there been any changesets that might fix the issue? I didn't see anything too promising in gitweb. Unfortunately, I won't be able to do any testing for a few weeks. Yesterday I dropped my laptop, triggering all manner of hardware failures. I'll definitely report back when I have my machine back, though.

P.S. Be careful about marking this as fixed. My screen behaved fine for nearly 72 hours once before blacking out four times in a matter of 10 minutes. It's a tricky one...
Comment 32 Tino Keitel 2007-12-10 22:17:39 UTC
I already use a modeline (because I won't get a correct output without a modeline before 2.2.0).

Modeline "1680x1050_60.00"  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync

This modeline works fine with 2.1.1, so I think that it should be no problem with 2.2.0, too.
Comment 33 Hong Liu 2007-12-19 17:28:02 UTC
(In reply to comment #32)
> I already use a modeline (because I won't get a correct output without a
> modeline before 2.2.0).
> 
> Modeline "1680x1050_60.00"  146.25  1680 1784 1960 2240  1050 1053 1059 1089
> -hsync +vsync
> 
> This modeline works fine with 2.1.1, so I think that it should be no problem
> with 2.2.0, too.
> 
Hi, Tino
Since you can workaround your problem with your specific modeline, maybe there are something wrong with your monitor's EDID data. Would you please attach your xorg.log with modedebug turned on?

For Ben's problem, I don't have any clue now :(

Thanks,
Hong


Comment 34 Ben Gamari 2007-12-19 18:58:50 UTC
(In reply to comment #33)
Well, I should have a new computer by Friday (albeit with an i965) so hopefully I'll be able to reproduce it at that point.

- Ben


> (In reply to comment #32)
> > I already use a modeline (because I won't get a correct output without a
> > modeline before 2.2.0).
> > 
> > Modeline "1680x1050_60.00"  146.25  1680 1784 1960 2240  1050 1053 1059 1089
> > -hsync +vsync
> > 
> > This modeline works fine with 2.1.1, so I think that it should be no problem
> > with 2.2.0, too.
> > 
> Hi, Tino
> Since you can workaround your problem with your specific modeline, maybe there
> are something wrong with your monitor's EDID data. Would you please attach your
> xorg.log with modedebug turned on?
> 
> For Ben's problem, I don't have any clue now :(
> 
> Thanks,
> Hong
> 

Comment 35 Tino Keitel 2007-12-19 23:18:19 UTC
See Bug #10784. I attached logfiles with modedebug enabled to this bug.
Comment 36 Christian Weeks 2008-01-03 13:44:12 UTC
Hi, I've also been experiencing this problem (jittery external DVI display, occasional external display blanking). Note that the laptop (Dell D620) doesn't hang, and the Laptop display (which was still enabled through xrandr) is still working. DVI is the only pipe that causes the problem btw (DVI is exposed through a port replicator too- that could be important).

I would love to get this issue fixed. The 2.1 driver didn't suffer from this problem in my experience. 2.2 definitely does. I run the debian packaged from sid.

Christian
Comment 37 Hong Liu 2008-01-09 18:04:14 UTC
(In reply to comment #36)
> Hi, I've also been experiencing this problem (jittery external DVI display,
> occasional external display blanking). Note that the laptop (Dell D620) doesn't
> hang, and the Laptop display (which was still enabled through xrandr) is still
> working. DVI is the only pipe that causes the problem btw (DVI is exposed
> through a port replicator too- that could be important).
>
Hi, Christian

Your problem is not the same as Ben's. Would you please open a new bug and attach the Xorg.log with modedebug turned on?

Thanks,
Hong
Comment 38 Johannes Engel 2008-01-14 10:05:22 UTC
*** Bug 13446 has been marked as a duplicate of this bug. ***
Comment 39 Hong Liu 2008-01-15 00:29:10 UTC
Created attachment 13717 [details] [review]
enable ssc for lvds dual channel

Hi, Ben

Would you please try this patch? And please attach the xorg log with modedebug turned on (with this patched applied) if problem is still there.

Thanks,
Hong
Comment 40 Johannes Engel 2008-01-15 02:42:40 UTC
I used a slightly adapted version for the current git (origin/xvmc branch), that did not solve the problem, although the log says:
(WW) intel(0): enable SSC clock for LVDS
(WW) intel(0): enabling SSC clock for LVDS, setting dpll_b
Comment 41 Brice Goglin 2008-01-15 05:59:51 UTC
Tried on a Dell D420 (i945) with a DVI Dell 2007FP monitor (and LVDS closed), we still get the same blank screen and flickering from time to time.
Comment 42 Ross Burton 2008-01-17 03:44:03 UTC
I think I'm seeing this too, xserver-xorg 1.4.1, -intel 2.2.0, on a Thinkpad X60.

When I work on the LVDS, the display is fine.  When I switch to VGA and disable the LVDS, I get occasional jitters of the screen and sometimes (one every few days) the VGA output turns itself off.  If I remove the VGA cable and blindly xrandr --auto, the LVDS turns back on but I can't enable VGA again.

My monitor appears to emit broken EDID, or the intel driver doesn't read it properly, so I need a custom modeline:

Modeline "1680x1050" 149.00  1680 1760 1944 2280  1050 1050 1052 1089

Is this the same issue, or should I file another bug?  Can I contribute anything useful?
Comment 43 Gordon Jin 2008-01-17 18:57:26 UTC
Increasing priority, as it seems many people are impacted, though I'm not seeing it.
Comment 44 Tino Keitel 2008-01-17 23:45:44 UTC
I planned to try a git bisect to hunt this bug down. But this week I tested the 2.2 git branch and first thought that the bug is gone, because I didn't notice the jittering and got no blank screen after an hour or so. However, I left the computer running and when I came back from work I had a blank screen. Then I rebooted and after a while I got the jittering again.

So it looks to be hard to reproduce under certain conditions. I saw no procedure to trigger the bug or make it occur faster. Or did I miss something?
Comment 45 Jesse Barnes 2008-01-18 09:05:07 UTC
I wonder if disabling and re-enabling the display is the culprit?  If you leave it for awhile, the DPMS callbacks should disable both the outputs and the actual pipes.  If you do that a few times can you reproduce the problem?
Comment 46 Ross Burton 2008-01-18 09:15:57 UTC
I disabled Framebuffer compression and can confirm that this has stopped the jittering for me.
Comment 47 Tino Keitel 2008-01-21 13:36:16 UTC
I also disabled FramebufferCompression now, and so far got no jittering. However, I'll wait one or two days to be sure.
Comment 48 Michael Fu 2008-01-25 01:22:23 UTC
Tino, any more update after these days?

re-title this bug
Comment 49 Tino Keitel 2008-01-25 02:50:26 UTC
I got neither jittering nor blanking during the last days with framebuffer compression disabled, so it looks like this is the culprit.
Comment 50 Brice Goglin 2008-01-25 03:12:03 UTC
I think I can confirm what Tino says. I had blanking at least twice a day on my i945 earlier. With FramebufferCompression disabled, no problem so far.
Comment 51 Jesse Barnes 2008-02-05 14:11:06 UTC
Can you give the latest git bits a try?  I pushed a change that I hope will fix this...
Comment 52 Adam Williamson 2008-02-06 11:05:16 UTC
I am experiencing this bug (I believe) on my laptop (i945 chipset). With framebuffer compression enabled, on average every twelve hours (but with a wide variance - sometimes it happens within an hour of rebooting, sometimes over a day), one or both displays is 'blanked' (actually not blanked, but set to displaying all pixels of a single color, usually black but occasionally grey or white or even another color).

For a long time I was running release 2.2.0 in clone mode on the internal display (LVDS) and an external display (VGA). The external display would be blanked, but never the internal display. I recently switched to git as of Sunday, and a side-by-side configuration (VGA right of LVDS). The two times the issue happened in this configuration before I disabled framebuffer compression, *both* displays were blanked.

As others have stated, neither restarting X nor fiddling with xrandr, disconnected and reconnecting the affected head etc can fix it - only a system restart.

Of note is that I did not see any display 'jitters', that I recall.

I will update to today's git, re-enable framebuffer compression, and see if the problem continues to occur...unless this is fixed in the driver, I'm recommending our X maintainer to disable framebuffer compression by default for the next Mandriva release (2008 Spring, due in April).
Comment 53 Adam Williamson 2008-02-06 11:09:11 UTC
hmm, per comment 36 / 37, mine may not be the same bug. If not, can someone please direct me to the appropriate bug? I can't find it.
Comment 54 Michael Fu 2008-02-06 15:50:05 UTC
(In reply to comment #53)
> hmm, per comment 36 / 37, mine may not be the same bug. If not, can someone
> please direct me to the appropriate bug? I can't find it.
> 
Adam, if you can confirm disableing FBC will relieve your pain, it might be the same bug.. we will wait for your test result of the latest git tree. thanks.
Comment 55 Tino Keitel 2008-02-10 22:37:59 UTC
I tested the xf86-video-intel-2.2-branch branch as of commit 2c8f87be99957e0e18d8bcda46bd8706ab374253 on my Mac mini using LVDS connected via DVI. I still get the jitter sometimes, and yesterday I also got a blank screen. So the bug is still present for me.
Comment 56 Ross Burton 2008-02-11 01:35:50 UTC
I'm running the packaged intel driver in Debian Sid (2.2.0.90 with commit 2c8f87be99957e0e18d8bcda46bd8706ab374253 merged) on a ThinkPad X60 (945GM/GMS) and with frame buffer compression on I get screen jitter on the VGA output (not on LVDS).
Comment 57 Jesse Barnes 2008-02-19 20:35:04 UTC
Created attachment 14432 [details] [review]
Change FBC idle mode

Can you give this patch a try?  It should (hopefully) change the idle mode for FBC to be a little more bus friendly.  It may also be that FBC_CONTROL2 can't be written at all on pre-i965 chips.
Comment 58 Anton Khirnov 2008-02-25 07:25:58 UTC
This bug seems to be fixed in 2.2.1.
Comment 59 Michael Fu 2008-02-29 15:38:20 UTC
Tino or Ross, Can you confirm Anton's finding (gone in 2.2.1) ? thanks.
Comment 60 Ross Burton 2008-03-03 01:45:29 UTC
I turned FBC off with 2.2.1 and still get jittering on my VGA output.  I'll try that patch now.
Comment 61 Ross Burton 2008-03-03 03:09:02 UTC
It appears that Jesse's patch appears to be helping, I've had X running for 20 minutes and no jittering so far.
Comment 62 Ross Burton 2008-03-03 07:13:59 UTC
Four hours and still no jittering with the patch, which is great.
Comment 63 Jesse Barnes 2008-03-03 09:37:28 UTC
Ross, if you're seeing flicker w/FBC disabled, then you may be seeing another bug.  Earlier reporters only saw this problem when FBC was on, and my patch should only affect that case.  Can you clarify?
Comment 64 Ross Burton 2008-03-03 22:48:32 UTC
Sorry I meant I disabled the line turning FBC off... :)  FBC is enabled now, and I'm not seeing jittering but I used too before the patch was applied.
Comment 65 Jesse Barnes 2008-03-04 08:59:53 UTC
Ok, thanks for testing Ross.  Fix pushed as 4936e097028b91f4bdc2d9101dc49f6fe586e718.
Comment 66 Ross Burton 2008-03-05 02:04:56 UTC
I'm sorry to be the bearer of bad news, but despite a day of this patch working, I rebooted today and have jitter again.

Comment 67 Jesse Barnes 2008-03-18 18:27:46 UTC
Ok, back to the drawing board then...
Comment 68 Peter 2008-03-27 01:12:26 UTC
I'm seeing the jitter too. I've been seeing this on Fedora rawide (F9 beta). The jitter occurs every 5-10 mins on the internal lcd (1680x150) but during a normal 8-10 hour day I don't normally get a lockup although I have seen it when running for extended periods +24hrs. Interesting thing is I don't think this use to happen on Fedora 8 on the same machine. But I had seen it on F7 with the later releases of the driver on a Dell D620.

The fedora rpm is xorg-x11-drv-i810-2.2.1-15.fc9.x86_64

Device is a HP Compaq nx7400

lspci
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
Comment 69 Peter 2008-03-28 04:23:15 UTC
I spoke too soon. The latest version running on Fedora (same as one mentioned in comment #68) locks up every 3-4 hours with the screen suddenly going either black or white.
Comment 70 Jesse Barnes 2008-03-28 13:31:56 UTC
Peter, does the lockup go away if you disable framebuffer compression?
Comment 71 Peter 2008-03-28 14:21:16 UTC
No idea. How do I disable fb compression?
Comment 72 Jesse Barnes 2008-03-28 14:37:06 UTC
Option "framebuffercompression" "off" in the intel driver section of your xorg.conf.
Comment 73 Peter 2008-03-29 06:52:36 UTC
With that I get the following in Xorg.0.log so it looks to be disabled. I've been running it around 10 mins and looks quite good.

(II) intel(0): EDID vendor "QDS", prod id 63
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1680x1050"x0.0  119.00  1680 1728 1760 1840  1050 1053 1059 1080 -hsync -vsync (64.7 kHz)
(II) intel(0): EDID vendor "QDS", prod id 63
(II) intel(0): fbc disabled on plane a
(II) intel(0): fbc disabled on plane a
(II) intel(0): fbc disabled on plane a
(II) intel(0): fbc disabled on plane a
(II) intel(0): fbc disabled on plane a
Comment 74 Peter 2008-03-30 06:09:56 UTC
Just an update. Its looking a lot better with the fbc turned off. I don't think its perfect but the random flickers seem to have gone, and touch wood I'm yet to see a lock up after 3-4 hours like I was seeing previously.
Comment 75 Matej Cepl 2008-03-31 15:46:18 UTC
Created attachment 15590 [details]
/var/log/Xorg.0.log

I am not sure whether this is relevant, even though I have FramebufferCompression set to "no" there is periodicall blinking (I am not sure whether it is exactly regular, but it feels like every minute or so) when whole display blinks for a fraction of second like when visual-bell is set on (but there is no reason to beel set off).
Comment 76 Jesse Barnes 2008-04-08 17:51:21 UTC
*** Bug 13418 has been marked as a duplicate of this bug. ***
Comment 77 Dan McGuirk 2008-04-18 15:42:43 UTC
I seem to have this same problem, using Ubuntu hardy package xserver-xorg-video-intel 2:2.2.1-1ubuntu12.

I have not tried changing the FramebufferCompression option yet.

One thing I have noticed is that the problem does not start for me until *after* the first time the screen is blanked by the power management.  I don't know if that is useful information, but I haven't seen it mentioned before.  Once it starts, it happens pretty regularly every 2 minutes or so (but I don't believe it's a fixed pattern).

Actually, I only see lines referring to 'fbc enabled' after the first power management screen blanking, so maybe that's the connection.  Sorry, but I'm not really familiar with what the framebuffer compression is supposed to be doing.

I'm seeing this on an external Samsung SyncMaster 220WM 22" LCD at 1680x1050 connected to a Dell Inspiron e1405 with Intel 945GM graphics.

Thanks...
Comment 78 Dan McGuirk 2008-04-18 15:48:33 UTC
Also, for what it's worth, I have verified the problem at two separate resolutions, 1680x1050 and 1280x1024, in case that helps re: whether a specific modeline is the problem.
Comment 79 Peter 2008-04-19 03:21:23 UTC
I'm pretty sure others have seen the same thing after as suspend and turning off FBC fixed it for them.
Comment 80 Dan McGuirk 2008-04-19 03:57:46 UTC
Yes, thanks, it seems to work for me as well.

However, I am assuming that the developers will eventually want to fix the actual bug so that the FBC feature is usable.
Comment 81 Jesse Barnes 2008-05-06 15:11:02 UTC
Can I get the following questions answered by the people who have been seeing this problem?

Does it occur with FBC disabled?
Does it occur on the builtin LCD panel?
Does it occur when only one display is attached (builtin panel or otherwise)?

At this point, I suspect the memory arbitration or FIFO settings may be incorrect in some cases, and FBC exacerbates the problem (but it still might happen in other, non-FBC configs).

I updated the register dumper in git master so that it will dump the FIFO watermark regs, I'd appreciate register dumps from problem configurations.

In the meantime, I'm trying to reproduce locally by abusing my memory arbitration & FIFO watermark regs...
Comment 82 Dan McGuirk 2008-05-06 15:24:01 UTC
In my experience,

-- No, it does not occur with FBC disabled.
-- No, it does not occur on the built-in panel.
-- Not sure if the built-in panel is meant to be considered permanently "attached", but the problem does happen when I am using only the external monitor and have turned off the built-in panel with 'xrandr --output LVDS --off' (in fact this is the normal case where I see the problem).
Comment 83 Johannes Engel 2008-05-06 15:50:18 UTC
Three answers:
- No, it does not occur while FBC disabled
- If you mean LVDS: Yes, that is my only display
- The same as above: It occurs, if only LVDS is attached and active
Comment 84 Jesse Barnes 2008-05-06 16:02:06 UTC
Created attachment 16394 [details] [review]
Add FIFO debug code & default values

Success (maybe).  I was able to reproduce the flickering as described by allocating less FIFO RAM to plane A, and eventually the display blanked.  The debug code included in this patch caught the underrun status and printed an error in my log, and once the display blanked I needed to reboot for things to work again.

The patch also includes basic FIFO settings, which will override the BIOS values and may prevent the problem, but I'm still interested in getting answers to the questions I posed earlier.

Thanks,
Jesse
Comment 85 Bill Nottingham 2008-05-06 19:44:22 UTC
(In reply to comment #81)
> Does it occur with FBC disabled?

Have not seen it in the month+ since I disabled FBC.

> Does it occur on the builtin LCD panel?

That's the only place I saw it as...

> Does it occur when only one display is attached (builtin panel or otherwise)?

... I generally only run with the LVDS active.
Comment 86 Peter 2008-05-07 01:27:49 UTC
Does it occur with FBC disabled?

No

Does it occur on the builtin LCD panel?

Yes

Does it occur when only one display is attached (builtin panel or otherwise)?

I only use the builtin LCD panel.
Comment 87 Ross Burton 2008-05-07 02:55:10 UTC
- I don't get jittering with FBC disabled.  I do get occasional screen blanking still.
- I only see jittering on VGA output to a LCD panel, not LVDS
- When I see jittering the LVDS is disabled, so there is only one output

I just noticed that my previous xorg log after a screen black/reboot contains this:

(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): PRB0_HEAD (0xb0613474) and PRB0_TAIL (0x000135c8) indicate ring buffer not flushed
(WW) intel(0): Existing errors found in hardware state.

That said, I'll update to git drivers shortly.
Comment 88 Jesse Barnes 2008-05-10 18:29:44 UTC
So no one wants to test the last patch?  Another good default to try in case the stock patch doesn't work would be to set DSPARB to 48, that should split the FIFO RAM equally between planes A & B, which are the only ones the current driver uses.
Comment 89 Guillaume Melquiond 2008-05-15 02:36:45 UTC
To answer the questions:
- Jitter only happens with FBC.
- It happens only on the VGA display. (But that is because the LVDS is always on plane B, due to my DRM being the one from kernel 2.6.25 and not from git master.)

I have tried the patch. It did not fix the issue at all (though it may have reduced how often it occurs). Nevertheless, you seem to be on the right track: Whenever a flicker occurs, an "underrun on pipe A" line appears in my log.

I will now play with the DSPARB register. When you said 48, did you mean that the register should be set to 0x2FB0? (Just to be sure I understand the documentation correctly.) Should I care about display C / overlay?
Comment 90 Guillaume Melquiond 2008-05-15 04:16:48 UTC
With DSPARB set to 0x2FB0, it is still as bad as before. But with 0x2FC0, the VGA display is finally stable!

Once I have a fixed DRM, I will try again with 0x2FB0. (Since the DRM will set the LVDS on plane A hopefully, the clock rate will be lowered on the fifo of plane A.)
Comment 91 Eugene San 2008-05-15 05:13:52 UTC
(In reply to comment #88)
> So no one wants to test the last patch?  Another good default to try in case
> the stock patch doesn't work would be to set DSPARB to 48, that should split
> the FIFO RAM equally between planes A & B, which are the only ones the current
> driver uses.
> 

I am testing the patch...
I've tried it with 2.3.1 from debian/unstable and flickering and coloured
blanking gone. BUT, Totally black screen with huge amount of "(EE) intel(0):
underrun on pipe A!".
After that I've tried 2.2.1 from Ubuntu/Hardy and it's still flickering and probably will get blank very soon.

Do you want me to supply any additional info or perform test?

P.S.
I am using GM945 on Mac Mini with LCD connected to DVI-D.
Comment 92 Jesse Barnes 2008-05-15 16:49:07 UTC
Excellent, thanks a lot for testing.  One other thing I'm hoping you can try:  set DSPARB to (95 << 7) | (48)?  That should remove most of the FIFO entries for display plane C, and hopefully keep things stable...
Comment 93 Jesse Barnes 2008-05-15 16:57:01 UTC
Guillaume, yeah you shouldn't have to care about display plane C, you can allocate 1 or 0 FIFO entries for it since we don't use it.  Thanks a lot for trying this out, we really need to set DSPARB better.  An even split between pipe B and A might not be appropriate in some cases, e.g. running 1920x1200 on pipe a and 640x480 on pipe B, so we'll have to do some bandwidth calculations and set it...
Comment 94 Guillaume Melquiond 2008-05-15 22:54:11 UTC
Bandwidth calculations may not be needed. Since the underrun seems to happen only with FBC, and since FBC is only enabled when only plane A is on, a solution would be: when enabling FBC, set DSPARB to 95/95; when disabling FBC, set DSPARB back to the default value 28/59.

Moreover, the FBC could perhaps be disabled for very high resolutions. (But is the chip fast enough to drive them?) At least in my case, 64/95 is fine for 1600x1200x4 at 60Hz. So I guess 1920x1200 should be fine with 95/95.
Comment 95 Guillaume Melquiond 2008-05-16 02:26:53 UTC
I don't know why it worked yesterday. (I'm sure it worked, since I verified with reg_dumper that the FBC was on.) But today, it does not work anymore: The underruns are back while I'm still using the 64/95 split. There must be something missing.
Comment 96 Guillaume Melquiond 2008-05-16 08:47:38 UTC
The current situation is really surprising: Switching VTs was enough to stop the underrun flood (I didn't even have to restart it). I have now been running X for several hours without a single flicker, while the FBC is still enabled. So I'm not even sure my 64/95 split makes a difference, perhaps the 48/95 would have been sufficient. Could there be some kind of race condition when setting the fifo or FBC that would confuse the chipset?
Comment 97 Jesse Barnes 2008-05-16 09:17:22 UTC
Maybe you're running into the DSPARB programming limitations?  It's only supposed to be written when either all pipes are off or only one pipe is active with all planes directed at it...  I think you could move the write of DSPARB into EnterVT after the output & crtc "dpms off" calls.
Comment 98 Jesse Barnes 2008-05-21 12:09:44 UTC
Created attachment 16666 [details] [review]
Fixup DSPARB default value

Ok, here's the patch I'd like to push, can you give it a try and make sure it still fixes things for you?
Comment 99 Jesse Barnes 2008-05-21 12:19:06 UTC
Created attachment 16667 [details] [review]
Fixup FIFO underrun on modeset

Oops, please try this patch instead.  It fixes up the FIFO underrun status bit during mode setting as well, to avoid false positives (FIFO underrun is normal during mode setting, but in other cases indicates a bug).
Comment 100 Jesse Barnes 2008-05-26 09:43:10 UTC
Ok, I pushed the fix as 2e1425246ccc75216247b0c2fa6fce2635db472b.
Comment 101 Tino Keitel 2008-06-01 22:44:01 UTC
Hi,

I tried git bd137a19dc29dd466eac030e040f729ed0807e3f from the master branch and still get jittering and a blank display after some time. This build includes commit 2e1425246ccc75216247b0c2fa6fce2635db472b which should fix this issue, right? At least for me, it doesn't.

In the Xorg log file, I still see those "(EE) intel(0): underrun on pipe A!" messages.

This is a Mac mini Core Duo with Intel i945, DVI, frame buffer compression enabled. I'll now disable it again.
Comment 102 Jesse Barnes 2008-06-02 08:31:05 UTC
Ok, thanks for testing, Tino.  There's another bug open for this now, #16169, we'll track further improvements to the FIFO allocation there.