Bug 24314 - [945GME FBC] underruns followed by freeze after resume with FBC enabled
[945GME FBC] underruns followed by freeze after resume with FBC enabled
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
Other All
: high critical
Assigned To: Jesse Barnes
Xorg Project Team
: NEEDINFO, regression
: 24928 25371 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-04 23:09 UTC by Oleksij Rempel
Modified: 2010-02-16 00:58 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments
fbc suspend/resume fix (2.07 KB, patch)
2009-10-13 10:38 UTC, Jesse Barnes
no flags Details | Splinter Review
dmesg with drm.debug=0x06 (60.26 KB, text/plain)
2009-11-20 23:12 UTC, Oleksij Rempel
no flags Details
drm-intel-next with debug=6 after resume (119.90 KB, text/plain)
2009-12-03 16:45 UTC, Tom Gundersen
no flags Details
dmesg with drm.debug=6 video briocken on start (121.69 KB, text/plain)
2009-12-03 23:30 UTC, Oleksij Rempel
no flags Details
dmesg drm.debug=6 with external display (122.65 KB, text/plain)
2009-12-04 01:15 UTC, Oleksij Rempel
no flags Details
drm-intel-next with debug=4 after resume (77.84 KB, text/plain)
2009-12-04 10:38 UTC, Tom Gundersen
no flags Details
dmesg; debug=4; external display (84.71 KB, text/plain)
2009-12-04 11:02 UTC, Oleksij Rempel
no flags Details
dmesg; debug=4; local display after resume (70.06 KB, text/plain)
2009-12-04 11:04 UTC, Oleksij Rempel
no flags Details
Unlock self-refresh bits on 945 (1.30 KB, patch)
2009-12-04 12:37 UTC, Jesse Barnes
no flags Details | Splinter Review
intel_reg_dumper output before suspend (EeePC 901) (10.40 KB, text/plain)
2009-12-06 18:03 UTC, Darren Salt
no flags Details
intel_reg_dumper output after resume (EeePC 901) (10.37 KB, text/plain)
2009-12-06 18:04 UTC, Darren Salt
no flags Details
intel_reg_dumper output before suspend (EeePC 901, running X) (10.41 KB, text/plain)
2009-12-06 18:19 UTC, Darren Salt
no flags Details
intel_reg_dumper output after resume (EeePC 901, running X) (10.37 KB, text/plain)
2009-12-06 18:19 UTC, Darren Salt
no flags Details
reg dump, eeepc 1005ha, clean start (9.19 KB, text/plain)
2009-12-06 23:23 UTC, Oleksij Rempel
no flags Details
reg dump, eeepc 1005ha, after resume (9.16 KB, text/plain)
2009-12-06 23:24 UTC, Oleksij Rempel
no flags Details
reg dump, eeepc 1005ha, start with external display (9.21 KB, application/octet-stream)
2009-12-06 23:25 UTC, Oleksij Rempel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oleksij Rempel 2009-10-04 23:09:42 UTC
This bug caused by "framebuffer compression for pre-GM45" 
patch. The symptom is: it seems to be ok after resume but the image
will get rare random interference (i don't know better wort) and with
playing video after ~3 minuts GPU will freeze. There is not trace in dmesg or xorg_log.

i use 2:2.9.0~git20090930.2841a4cd-0ubuntu0tormod driver and 2.6.32-rc2-00309-g8a0382f kernel

At the momment i disabled FBC with this patch, so every thing working fine now:
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1131,6 +1131,9 @@ static void intel_update_fbc(struct drm_crtc *crtc,
 	if (!crtc->fb)
 		return;
 
+
+	return;
+
 	intel_fb = to_intel_framebuffer(fb);
 	obj_priv = intel_fb->obj->driver_private;


My hardware, netbook eeepc p1005ha-h:
lex@mini:~$ lspci 
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
01:00.0 Ethernet controller: Attansic Technology Corp. Atheros AR8132 / L1c Gigabit Ethernet Adapter (rev c0)
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
Comment 1 Santi 2009-10-13 01:01:39 UTC
Hi *,

  I also reported the same issue in:

http://bugzilla.kernel.org/show_bug.cgi?id=14312

but Gordon Jin said to track it here.

  Basically it is the same but with:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller [8086:2a42] (rev 07)

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller [8086:2a43] (rev 07)

  and that I bisected down to v2.6.31-rc9-145-g74dff28.

Thanks,
Santi
Comment 2 Jesse Barnes 2009-10-13 10:38:05 UTC
Created attachment 30351 [details] [review]
fbc suspend/resume fix

Does this patch help?  I'm afraid FBC might have been enabled across suspend/resume but without a valid base register, which may have clobbered memory.
Comment 3 Oleksij Rempel 2009-10-13 13:21:06 UTC
No, this patch do not solve this problem.
I also noticed, after resume intel_gpu_top show "Framebuffer Compression 100%", before suspend you don't see "Framebuffer Compression" with gpu_top at all.
Comment 4 Santi 2009-10-13 13:50:48 UTC
(In reply to comment #2)
> Created an attachment (id=30351) [details]
> fbc suspend/resume fix
> 
> Does this patch help?  I'm afraid FBC might have been enabled across
> suspend/resume but without a valid base register, which may have clobbered
> memory.
> 

No, there is no difference with this patch in my case.

Thanks,
Santi
Comment 5 Jesse Barnes 2009-11-20 12:45:51 UTC
How about this one?  It's upstream now I think, so maybe your problem has gone away?

commit 629598da932cfa5ff398fe10bc123282a6f3049e
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Oct 20 07:37:32 2009 +0900

    drm/i915: update watermarks before enabling PLLs
Comment 6 Oleksij Rempel 2009-11-20 14:04:33 UTC
no, this patch do not fix it for me.
Comment 7 Jesse Barnes 2009-11-20 14:17:06 UTC
Can you load the drm module with debugging enabled?  I think you can load it with debug=0x06 to get the messages I want, just attach the output of dmesg after doing that and suspending & resuming here.
Comment 8 Oleksij Rempel 2009-11-20 23:12:01 UTC
Created attachment 31362 [details]
dmesg with drm.debug=0x06
Comment 9 Santi 2009-11-27 04:44:02 UTC
(In reply to comment #5)
> How about this one?  It's upstream now I think, so maybe your problem has gone
> away?
> 
> commit 629598da932cfa5ff398fe10bc123282a6f3049e
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Tue Oct 20 07:37:32 2009 +0900
> 
>     drm/i915: update watermarks before enabling PLLs
> 

I don't know for the submiter but for me (see Comment #1) it is already fixed. I don't know exactly the commit but for sure it works with the -rc after the commits:

http://bugzilla.kernel.org/show_bug.cgi?id=14312#c3

Thanks,
Santi
Comment 10 Oleksij Rempel 2009-11-27 05:05:51 UTC
@Santi,
this is different bug. FBC is brocken after resume and use 100% GPU. After some time GPU freeze.

My question is, are all 945GME affected? 
Comment 11 Jesse Barnes 2009-12-02 10:56:13 UTC
I don't think so, but I'm building the latest bits on my 945GME test machine to verify.
Comment 12 Tom Gundersen 2009-12-02 12:17:36 UTC
FWIW: I also get 100% FBC in intel_gpu_top after resume, followed by the a freeze.

Please let me know if I can help debugging this any further. In the meantime: is there an easy way of disabling FBC (sorry if this is a stupid question).

Some possibly relevant output. Let me know if I should post anything else.

> uname -a
Linux x60 2.6.32-rc8 #17 SMP PREEMPT Sat Nov 21 18:18:43 CET 2009 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux

> lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4)
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09)
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18)
Comment 13 Jesse Barnes 2009-12-02 12:24:20 UTC
My machine suspends & resumes just fine with FBC enabled.  I'm able to play
video after resume and I haven't seen any flicker yet.

Your logs don't have the info I needed, can you build a kernel from Eric's
drm-intel-next branch (at
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git)?  That
should give me the messages I'm looking for with debug=6.  I'm particularly
interested in seeing your dmesg after resume, it should have FBC and FIFO info.
Comment 14 Tom Gundersen 2009-12-03 16:45:29 UTC
Created attachment 31717 [details]
drm-intel-next with debug=6 after resume

I hope this dmesg will tell you something.

I might have messed up a bit as I merged drm-intel-next into v2.6.32 from linus, which I later realised was not the correct thing to do. If you want, I might have time to do it properly tomorrow.

I notice that my dmesg is truncated, is there a way to avoid this (in case you need all of it)?

Let me know if there is something else I could do to provide you with more info,

-t
Comment 15 Oleksij Rempel 2009-12-03 23:30:53 UTC
Created attachment 31727 [details]
dmesg with drm.debug=6 video briocken on start

@Jesse,
latest drm-next do not working for me at all.
but here is some news, i was able to reproduce this issue without suspend. After i started my netbook with attached video projector, it got same symptoms - random flickering and intel-gpu-top show FBC use 100%.

With latest drm-next kernel, with normal start i can see console cursor blinking, probably Xserver can't start. With attached external monitor, i can't see anything...
Comment 16 Oleksij Rempel 2009-12-04 01:15:38 UTC
Created attachment 31729 [details]
dmesg drm.debug=6 with external display

ok, latest working drm-next is 2.6.32-rc6-00278-gf40d681. I can reproduce this issue on suspend or without suspend, just start with external display.
Comment 17 Jesse Barnes 2009-12-04 10:25:14 UTC
Arg, sorry to ask for another dmesg. :)  But drm debug=6 is way too verbose, I'm losing the messages I want.  Can you try debug=4 instead of 6?  That should get me just the KMS related msgs and not all the "add request" ones.
Comment 18 Tom Gundersen 2009-12-04 10:38:03 UTC
Created attachment 31749 [details]
drm-intel-next with debug=4 after resume

Is this better?
Comment 19 Oleksij Rempel 2009-12-04 11:02:45 UTC
Created attachment 31750 [details]
dmesg; debug=4; external display
Comment 20 Oleksij Rempel 2009-12-04 11:04:05 UTC
Created attachment 31751 [details]
dmesg; debug=4; local display after resume
Comment 21 Jesse Barnes 2009-12-04 12:37:47 UTC
Created attachment 31753 [details] [review]
Unlock self-refresh bits on 945

The FIFO settings look identical between suspend and resume, so I guess that's not the issue if things were working fine before suspending.

But on 945 there are some unlock bits Li Peng recently posted a fix for.  Can you try this patch to see if it helps?
Comment 22 Oleksij Rempel 2009-12-04 13:54:32 UTC
No, still the same :(
Comment 23 Jesse Barnes 2009-12-06 17:43:00 UTC
Ah, just thought of something... maybe at resume time we set FBC to use the wrong fence reg?  We should reset it as part of the resume mode set, but it's possible things get out of sync.  That might explain the bad behavior...  I'll check on that, it should be easy to verify if you can capture a post-resume register dump along with the dmesg.
Comment 24 Darren Salt 2009-12-06 18:03:26 UTC
Created attachment 31787 [details]
intel_reg_dumper output before suspend (EeePC 901)
Comment 25 Darren Salt 2009-12-06 18:04:15 UTC
Created attachment 31788 [details]
intel_reg_dumper output after resume (EeePC 901)
Comment 26 Darren Salt 2009-12-06 18:19:15 UTC
Created attachment 31789 [details]
intel_reg_dumper output before suspend (EeePC 901, running X)
Comment 27 Darren Salt 2009-12-06 18:19:33 UTC
Created attachment 31790 [details]
intel_reg_dumper output after resume (EeePC 901, running X)
Comment 28 Oleksij Rempel 2009-12-06 23:23:53 UTC
Created attachment 31803 [details]
reg dump, eeepc 1005ha, clean start

To make your live more complicated i add my dumps too :)
1. dump is after clean start.
2. dump after resume
3. dump on start with external display
Comment 29 Oleksij Rempel 2009-12-06 23:24:35 UTC
Created attachment 31804 [details]
reg dump, eeepc 1005ha, after resume
Comment 30 Oleksij Rempel 2009-12-06 23:25:27 UTC
Created attachment 31805 [details]
reg dump, eeepc 1005ha, start with external display
Comment 31 Jesse Barnes 2010-01-04 18:16:33 UTC
Does the current drm-intel-next branch still have this issue?
Comment 32 Thomas Wendt 2010-01-05 06:34:21 UTC
(In reply to comment #31)
> Does the current drm-intel-next branch still have this issue?
> 
At least for me and my Samsung NC10 I still have this problem.
Comment 33 Alberto González 2010-02-04 09:11:31 UTC
My HP mini netbook also seemed to be affected by this bug while testing .32 kernel (so I'm still on .31). The bug is IMHO correctly marked as critical, and since .33 final is approaching and there seems to be no fix for this yet, I wanted to ask if it wouldn't be better to revert this feature on 945G chips before .33 final comes out and then try again for .34? (I don't know Intel's exact policy in these cases, so I'm just asking).
Comment 34 Alexander Lam 2010-02-04 15:58:17 UTC
This appears to be the same bug as Bug #15043 on bugzilla.kernel.org: Display goes off with i915.powersave=1 after suspend-resume
http://bugzilla.kernel.org/show_bug.cgi?id=15043

BTW, I have an Acer Aspire One (ZG5) with 945GSE graphics and I get this problem too. The latest intel-drm-next kernel I have tried was from January 31st.
Comment 35 Priit Laes (irc: plaes) 2010-02-05 01:42:06 UTC
*** Bug 24928 has been marked as a duplicate of this bug. ***
Comment 36 Jesse Barnes 2010-02-05 11:28:50 UTC
Can you try this patch? http://patchwork.kernel.org/patch/75423/

There's another patch in the current drm-intel-next tree that might help as well:
commit 72ddbd39f39b3cc5f1f661f97e67f2a497c4d57a
Author: Li Peng <peng.li@linux.intel.com>
Date:   Tue Jan 19 21:32:57 2010 +0800

    drm/i915: enable memory self refresh on 9xx

Can you test?
Comment 37 Alexander Lam 2010-02-05 13:14:43 UTC
(In reply to comment #36)
> Can you try this patch? http://patchwork.kernel.org/patch/75423/
> 
> There's another patch in the current drm-intel-next tree that might help as
> well:
> commit 72ddbd39f39b3cc5f1f661f97e67f2a497c4d57a
> Author: Li Peng <peng.li@linux.intel.com>
> Date:   Tue Jan 19 21:32:57 2010 +0800
> 
>     drm/i915: enable memory self refresh on 9xx
> 
> Can you test?
> 

When attempting to patch drm-intel-next with "Disable SR when more than one pipe is enabled" (http://patchwork.kernel.org/patch/75423/)

The following hunk is rejected:
--- drivers/gpu/drm/i915/intel_display.c
+++ drivers/gpu/drm/i915/intel_display.c
@@ -2638,6 +2646,10 @@
                if (srwm < 0)
                        srwm = 1;
                I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN | (srwm & 0x3f));
+       } else {
+               /* Turn off self refresh if both pipes are enabled */
+               I915_WRITE(FW_BLC_SELF, I915_READ(FW_BLC_SELF)
+                                       & ~FW_BLC_SELF_EN);
        }

        DRM_DEBUG_KMS("Setting FIFO watermarks - A: %d, B: %d, C: %d, SR %d\n",

This is due to:
> commit 72ddbd39f39b3cc5f1f661f97e67f2a497c4d57a
> Author: Li Peng <peng.li@linux.intel.com>
> Date:   Tue Jan 19 21:32:57 2010 +0800
> 
>     drm/i915: enable memory self refresh on 9xx
Comment 38 Jesse Barnes 2010-02-05 13:26:44 UTC
Ah that patch needs to be fixed up a little.  For 945 you can just add the hunk to the end (as an else for the if (HAS_FW_BLC...) conditional).

If you have an I915, you'll have to add a path to disable SR in INSTPM just like the enable path has.
Comment 39 Alexander Lam 2010-02-05 13:29:17 UTC
Don't know if this will help, but FBC in UMS worked fine (xf86-video-intel
2.9.1, kernel 2.6.32.7 vanilla)
Comment 40 Jesse Barnes 2010-02-05 13:37:57 UTC
That's a good data point, it means we should be able to get it working here.  Though there were some cases in the UMS driver where it would get silently disabled...
Comment 41 Alexander Lam 2010-02-05 15:29:05 UTC
Nope patches do not fix. Same symptoms:

A) During "intense" graphics operations, such as window resize, playing videos, or scrolling stuff, there will be the occasional screen "jump" occurring every few minutes. Examples of screen jump include the screen getting offset to the left by several pixels for a fraction of a second, the same but offset vertically, etc.

B) Finally, after several tens of minutes (in this case, 20), the screen goes black (but backlight still on). VT switch doesn't do anything. Had to ssh in to get logs & reboot.

Hardware is a Acer Aspire One (ZG5 Model) with 945GSE
Comment 42 Jesse Barnes 2010-02-05 15:37:25 UTC
But this only happens after a suspend/resume cycle?  After a fresh boot things are fine?
Comment 43 Alexander Lam 2010-02-05 15:39:17 UTC
When I first encountered this bug during normal use, this didn't happen from a fresh boot. I didn't check this time though, I just suspended right after I finished booting.
Comment 44 Jesse Barnes 2010-02-05 15:49:10 UTC
Another couple of hunks to try.  On the off chance this works, it would be good
to know whether it's the FBC change or the SR change that fixes it.

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3dd8018..01c2b95 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -341,6 +341,7 @@
 #define   FBC_CTL_EN           (1<<31)
 #define   FBC_CTL_PERIODIC     (1<<30)
 #define   FBC_CTL_INTERVAL_SHIFT (16)
+#define   FBC_C3_IDLE          (1<<13)
 #define   FBC_CTL_UNCOMPRESSIBLE (1<<14)
 #define   FBC_CTL_STRIDE_SHIFT (5)
 #define   FBC_CTL_FENCENO      (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_d
index 06761e4..c0861e0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned 
        I915_WRITE(FBC_FENCE_OFF, crtc->y);

        /* enable it... */
-       fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC;
+       fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC;
        fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
        fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT;
        if (obj_priv->tiling_mode != I915_TILING_NONE)
@@ -2631,7 +2631,9 @@ static void i9xx_update_wm(struct drm_device *dev, int
pla
                if (srwm < 0)
                        srwm = 1;
                if (IS_I945G(dev) || IS_I945GM(dev))
-                       I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm & 
+                       I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK |
+                                  FW_BLC_SELF_FIFO_MASK | FW_BLC_SELF_EN |
+                                  (srwm & 0xff));
                else if (IS_I915GM(dev)) {
                        /* 915M has a smaller SRWM field */
                        I915_WRITE(FW_BLC_SELF, srwm & 0x3f);

  
Comment 45 Thomas Wendt 2010-02-06 04:09:19 UTC
(In reply to comment #43)
> When I first encountered this bug during normal use, this didn't happen from a
> fresh boot. I didn't check this time though, I just suspended right after I
> finished booting.
> 
Can you test if you can trigger it by enabling/disabling an external display? Or by just playing around with xrandr? I can't test it at the moment but I think I could trigger it that way.
Comment 46 Alexander Lam 2010-02-06 07:39:36 UTC
(In reply to comment #44)
> Another couple of hunks to try.  On the off chance this works, it would be good
> to know whether it's the FBC change or the SR change that fixes it.
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3dd8018..01c2b95 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -341,6 +341,7 @@
>  #define   FBC_CTL_EN           (1<<31)
>  #define   FBC_CTL_PERIODIC     (1<<30)
>  #define   FBC_CTL_INTERVAL_SHIFT (16)
> +#define   FBC_C3_IDLE          (1<<13)
>  #define   FBC_CTL_UNCOMPRESSIBLE (1<<14)
>  #define   FBC_CTL_STRIDE_SHIFT (5)
>  #define   FBC_CTL_FENCENO      (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_d
> index 06761e4..c0861e0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned 
>         I915_WRITE(FBC_FENCE_OFF, crtc->y);
> 
>         /* enable it... */
> -       fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC;
> +       fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC;
>         fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
>         fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT;
>         if (obj_priv->tiling_mode != I915_TILING_NONE)
> @@ -2631,7 +2631,9 @@ static void i9xx_update_wm(struct drm_device *dev, int
> pla
>                 if (srwm < 0)
>                         srwm = 1;
>                 if (IS_I945G(dev) || IS_I945GM(dev))
> -                       I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm & 
> +                       I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK |
> +                                  FW_BLC_SELF_FIFO_MASK | FW_BLC_SELF_EN |
> +                                  (srwm & 0xff));
>                 else if (IS_I915GM(dev)) {
>                         /* 915M has a smaller SRWM field */
>                         I915_WRITE(FW_BLC_SELF, srwm & 0x3f);
> 
> 
> 

This works! (I suspended-resumed it, then left it on overnight while looping a movie trailer). I am in the process of testing which part of the patch fixed it.
Comment 47 Alexander Lam 2010-02-06 09:07:29 UTC
(In reply to comment #44)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3dd8018..01c2b95 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -341,6 +341,7 @@
>  #define   FBC_CTL_EN           (1<<31)
>  #define   FBC_CTL_PERIODIC     (1<<30)
>  #define   FBC_CTL_INTERVAL_SHIFT (16)
> +#define   FBC_C3_IDLE          (1<<13)
>  #define   FBC_CTL_UNCOMPRESSIBLE (1<<14)
>  #define   FBC_CTL_STRIDE_SHIFT (5)
>  #define   FBC_CTL_FENCENO      (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_d
> index 06761e4..c0861e0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned 
>         I915_WRITE(FBC_FENCE_OFF, crtc->y);
> 
>         /* enable it... */
> -       fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC;
> +       fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC;
>         fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
>         fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT;
>         if (obj_priv->tiling_mode != I915_TILING_NONE)

This fixes it. :D
Comment 48 Jesse Barnes 2010-02-06 10:28:48 UTC
Yay, I was starting to get worried.  I'll send that patch upstream now.
Comment 49 Jesse Barnes 2010-02-08 17:21:23 UTC
*** Bug 25371 has been marked as a duplicate of this bug. ***
Comment 50 Jesse Barnes 2010-02-11 09:33:48 UTC
Fix pushed to drm-intel-next:

commit	ee25df2bc379728c45d81e04cf87984db1425edf
drm/i915: handle FBC and self-refresh better

On 945, we need to avoid entering self-refresh if the compressor is
busy, or we may cause display FIFO underruns leading to ugly flicker.

Fixes fdo bug #24314, kernel bug #15043.
Comment 51 Jesse Barnes 2010-02-11 09:36:04 UTC
Err I mean for-linus.
Comment 52 Scott Warner 2010-02-12 13:33:07 UTC
(In reply to comment #44)
> Another couple of hunks to try.  On the off chance this works, it would be good
> to know whether it's the FBC change or the SR change that fixes it.
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3dd8018..01c2b95 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -341,6 +341,7 @@
>  #define   FBC_CTL_EN           (1<<31)
>  #define   FBC_CTL_PERIODIC     (1<<30)
>  #define   FBC_CTL_INTERVAL_SHIFT (16)
> +#define   FBC_C3_IDLE          (1<<13)
>  #define   FBC_CTL_UNCOMPRESSIBLE (1<<14)
>  #define   FBC_CTL_STRIDE_SHIFT (5)
>  #define   FBC_CTL_FENCENO      (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_d
> index 06761e4..c0861e0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -913,7 +913,7 @@ static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned 
>         I915_WRITE(FBC_FENCE_OFF, crtc->y);
> 
>         /* enable it... */
> -       fbc_ctl = FBC_CTL_EN | FBC_CTL_PERIODIC;
> +       fbc_ctl = FBC_CTL_EN | FBC_C3_IDLE | FBC_CTL_PERIODIC;
>         fbc_ctl |= (dev_priv->cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
>         fbc_ctl |= (interval & 0x2fff) << FBC_CTL_INTERVAL_SHIFT;
>         if (obj_priv->tiling_mode != I915_TILING_NONE)
> @@ -2631,7 +2631,9 @@ static void i9xx_update_wm(struct drm_device *dev, int
> pla
>                 if (srwm < 0)
>                         srwm = 1;
>                 if (IS_I945G(dev) || IS_I945GM(dev))
> -                       I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm & 
> +                       I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK |
> +                                  FW_BLC_SELF_FIFO_MASK | FW_BLC_SELF_EN |
> +                                  (srwm & 0xff));
>                 else if (IS_I915GM(dev)) {
>                         /* 915M has a smaller SRWM field */
>                         I915_WRITE(FW_BLC_SELF, srwm & 0x3f);
> 
> 
> 

After building a 2.6.33-r5 kernel from here (Snapshot):
http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=0f318cd689ef0758e7ebf0f92d3a21e711e18950
And changing the i915_debugfs.c to this:
http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=blob_plain;f=drivers/gpu/drm/i915/i915_debugfs.c;hb=0f318cd689ef0758e7ebf0f92d3a21e711e18950
I still have this issue, although the flickering is improved.
If I did this wrong, please tell me.
Running Debian sid on an eeepc 1005ha
Comment 53 Jesse Barnes 2010-02-12 13:39:10 UTC
Yeah, that's the wrong commit.  You want this one:

http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;
h=ee25df2bc379728c45d81e04cf87984db1425edf
Comment 54 Priit Laes (irc: plaes) 2010-02-16 00:58:18 UTC
I'm still experiencing same issues (although, less frequently) under 2.6.33-rc8.

Should I reopen this bug or start a new one on either kernel bugzilla or here?

Card info:
(--) PCI:*(0:0:2:0) 8086:27a2:17aa:201a Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xee100000/524288, 0xd0000000/268435456, 0xee200000/262144, I/O @ 0x00001800/8
(--) PCI: (0:0:2:1) 8086:27a6:17aa:201a Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xee180000/524288