Created attachment 24128 [details] Xorg log Hi, Commit 181a5336d6cc836f05507410d66988c483ad0154 drm/i915: Fix render reclock availability detection. is causing screen flickering on some intel chipsets in X. Reverting this commit solves the issue.
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.