Bug 14781

Created attachment 24129 [details]
dmesg

Created attachment 24130 [details]
kernel config

i can confirm this bug.

Has this patch been applied yet?  Can it be found in any release?

http://lkml.org/lkml/2009/10/18/142

Created attachment 24215 [details]
remove render reclock support

Here's a more complete version of the patch I just posted to lkml.  Can you give it a try?

(In reply to comment #5)
> Created an attachment (id=24215) [details]
> remove render reclock support
> 
> Here's a more complete version of the patch I just posted to lkml.  Can you
> give it a try?

Thanks for the patch Jesse, I'd like to test it a bit more but here are the first impressions...

I'm not quite sure against which kernel version you made this patch but it fails on 2.6.32. Therefore, I tested it on 2.6.33-rc1. I also tried vanilla 2.6.33-rc1, so:

2.6.33-rc1 vanilla: severe flickering I was having with 2.6.32 has almost disappeared. I just noticed a few blinks sometimes.

2.6.33-rc1 with remove_render_reclock_support patch: until now, no flickering at all but I'd like to test it a few hours more.

I'm facing the same issue. Just tried 2.6.32.2, unfortunately the problem still exists.

Is there a patch/fix for 2.6.32 available?

TIA, Michael

(In reply to comment #7)
> I'm facing the same issue. Just tried 2.6.32.2, unfortunately the problem
> still
> exists.
> 
> Is there a patch/fix for 2.6.32 available?
> 
> TIA, Michael

+1 here as well.

Thanks.

With the patch applied (using the one in drm-intel-next), I seem to have been 100% stable over 3 days (and at least 15 suspend/resumes) while additionally using the powersave=0 module parameter from previous testing. Upon removing powersave=0 I was greeted with the same old flickering and eventual crash ~5 minutes after the first resume. 

Logs and dumps are here:
http://sarvatt.com/intel_crash/

booting with i915.powersave=0 (and no patch applied) doesn't help here.

@Robert: Where can I get "the patch from drm-intel-next" ?

TIA, Michael

powersave=0 only worked for me when I was also using a kernel with this commit (also attached earlier in comment #5), otherwise it was the same as not using it.

http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=cf74ecbbff3e3b45bae61d28d2220f74d853e2f0

As I read in comment #6, this patch does not apply to 2.6.32, but only to 2.6.33-rc*

I'm looking for a patch for 2.6.32

(In reply to comment #12)
> As I read in comment #6, this patch does not apply to 2.6.32, but only to
> 2.6.33-rc*
> 
> I'm looking for a patch for 2.6.32

not sure if it's the right way to solve that but reverting the guilty commit solved the issue for me on the 2.6.32 branch. revert patch:

--- a/drivers/gpu/drm/i915/intel_bios.c 2009-12-07 15:33:19.000000000 +0700
+++ b/drivers/gpu/drm/i915/intel_bios.c 2009-12-07 15:33:32.000000000 +0700
@@ -351,18 +351,20 @@
        struct drm_device *dev = dev_priv->dev;
        struct bdb_driver_features *driver;

+       /* set default for chips without eDP */
+       if (!SUPPORTS_EDP(dev)) {
+               dev_priv->edp_support = 0;
+               return;
+       }
+      
        driver = find_section(bdb, BDB_DRIVER_FEATURES);
        if (!driver)
                return;

-       if (driver && SUPPORTS_EDP(dev) &&
-           driver->lvds_config == BDB_DRIVER_FEATURE_EDP) {
+       if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
                dev_priv->edp_support = 1;
-       } else {
-               dev_priv->edp_support = 0;
-       }

-       if (driver && driver->dual_frequency)
+       if (driver->dual_frequency)
                dev_priv->render_reclock_avail = true;
 }

Whether it is the right or wrong way, the patch in comment #13 fixes the problem when applied to the Mandriva development (cooker) kernel.

Thanks to all you guys, it works here. I simplified the patch from comment #13, should apply to vanilla 2.6.32.2:

--- drivers/gpu/drm/i915/intel_bios.c.orig 2009-12-30 08:56:23.000000000 +0100
+++ drivers/gpu/drm/i915/intel_bios.c      2009-12-30 09:15:29.000000000 +0100
@@ -351,6 +351,12 @@
        struct drm_device *dev = dev_priv->dev;
        struct bdb_driver_features *driver;

+       /* set default for chips without eDP */
+       if (!SUPPORTS_EDP(dev)) {
+               dev_priv->edp_support = 0;
+               return;
+       }
+
        driver = find_section(bdb, BDB_DRIVER_FEATURES);
        if (!driver)
                return;


All the flickering is gone.

Important: works here *without* i915.powersave=0

Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=patch;h=cf74ecbbff3e3b45bae61d28d2220f74d853e2f0

Fixed by commit cda9d05c499093c67b4a376a15009923acc2127a .

I run .33-rc4 which, as I can see, includes cda9d05c499093c67b4a376a15009923acc2127a, but still experience flickers and occasional blankings (which are fixed only by suspend-to-RAM). It's 945GME on Eee PC 901.

Same here, but .33-rc6. Flickering and blankings on 945 GME

I can confirm this bug is not dead on .33-rc6-13 with 945GME.

I think it should be reopened.

This is a different problem, then.

Also, please try .33-rc7 or better the current Linus' tree to double check the problem is there.

Well, with rc7. no blankings (tested only for ~30 mins, but flicks are here. After suspend2ram and resume.

Im trying rc7-14-pae now. Flickering and blankings after resume are still here but it seems both things don't happen as often as before (blanking happend just couple of times in 2 hours).

(In reply to comment #23)
> but it seems both things don't happen as often as before
I agree.

It seems http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff;h=ee25df2bc379728c45d81e04cf87984db1425edf
 fixes this.

Has this been fixed for everyone? Im using 2.6.33-29 and I still get occasional blanks after suspend to ram. They happen like once in 2-3 hours and so far the screen goes only black (not pink etc... like before). As before, everything seems fine with i915.powersave=0 on boot.