Bug 14781 - 181a533 is causing severe screen flickering on 965GM
Summary: 181a533 is causing severe screen flickering on 965GM
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 14230 14840
  Show dependency tree
 
Reported: 2009-12-10 08:49 UTC by benisty.e
Modified: 2010-04-07 14:58 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.32
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Xorg log (12.33 KB, application/octet-stream)
2009-12-10 08:49 UTC, benisty.e
Details
dmesg (32.73 KB, text/plain)
2009-12-10 08:50 UTC, benisty.e
Details
kernel config (78.06 KB, application/octet-stream)
2009-12-10 08:51 UTC, benisty.e
Details
remove render reclock support (4.47 KB, patch)
2009-12-17 19:12 UTC, Jesse Barnes
Details | Diff

Description benisty.e 2009-12-10 08:49:59 UTC
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.
Comment 1 benisty.e 2009-12-10 08:50:34 UTC
Created attachment 24129 [details]
dmesg
Comment 2 benisty.e 2009-12-10 08:51:10 UTC
Created attachment 24130 [details]
kernel config
Comment 3 Lex Rivera 2009-12-14 19:14:47 UTC
i can confirm this bug.
Comment 4 Ryan Underwood 2009-12-16 17:13:55 UTC
Has this patch been applied yet?  Can it be found in any release?

http://lkml.org/lkml/2009/10/18/142
Comment 5 Jesse Barnes 2009-12-17 19:12:23 UTC
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?
Comment 6 benisty.e 2009-12-18 16:43:36 UTC
(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.
Comment 7 Michael Reinelt 2009-12-25 08:49:10 UTC
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
Comment 8 JohnMB 2009-12-25 18:46:38 UTC
(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.
Comment 9 Robert Hooker 2009-12-25 21:55:57 UTC
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/
Comment 10 Michael Reinelt 2009-12-26 04:19:48 UTC
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
Comment 11 Robert Hooker 2009-12-26 06:23:05 UTC
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
Comment 12 Michael Reinelt 2009-12-28 05:33:40 UTC
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
Comment 13 benisty.e 2009-12-28 07:00:17 UTC
(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;
 }
Comment 14 JohnMB 2009-12-28 18:34:05 UTC
Whether it is the right or wrong way, the patch in comment #13 fixes the problem when applied to the Mandriva development (cooker) kernel.
Comment 15 Michael Reinelt 2009-12-30 08:36:08 UTC
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
Comment 17 Rafael J. Wysocki 2010-01-10 22:37:14 UTC
Fixed by commit cda9d05c499093c67b4a376a15009923acc2127a .
Comment 18 Andrey Rahmatullin 2010-02-04 17:38:13 UTC
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.
Comment 19 Lex Rivera 2010-02-04 18:10:07 UTC
Same here, but .33-rc6. Flickering and blankings on 945 GME
Comment 20 arond 2010-02-10 19:52:48 UTC
I can confirm this bug is not dead on .33-rc6-13 with 945GME.

I think it should be reopened.
Comment 21 Rafael J. Wysocki 2010-02-10 20:23:07 UTC
This is a different problem, then.

Also, please try .33-rc7 or better the current Linus' tree to double check the problem is there.
Comment 22 Lex Rivera 2010-02-11 16:10:04 UTC
Well, with rc7. no blankings (tested only for ~30 mins, but flicks are here. After suspend2ram and resume.
Comment 23 arond 2010-02-12 03:28:33 UTC
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).
Comment 24 Andrey Rahmatullin 2010-02-12 05:41:35 UTC
(In reply to comment #23)
> but it seems both things don't happen as often as before
I agree.
Comment 26 arond 2010-03-07 21:41:54 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.