[Intel-gfx] 2.6.31 -> 2.6.32 Sound and video regressions

Jesse Barnes jbarnes at virtuousgeek.org
Thu Dec 17 20:05:56 CET 2009


On Thu, 10 Dec 2009 09:54:22 -0800
Jesse Barnes <jbarnes at virtuousgeek.org> wrote:

> On Tue, 8 Dec 2009 20:20:07 +0700
> Emmanuel Benisty <benisty.e at gmail.com> wrote:
> 
> > On Mon, Dec 7, 2009 at 8:38 PM, Emmanuel Benisty
> > <benisty.e at gmail.com> wrote:
> > > On Mon, Dec 7, 2009 at 10:52 AM, Emmanuel Benisty
> > > <benisty.e at gmail.com> wrote:
> > >> On Mon, Dec 7, 2009 at 8:32 AM, Jesse Barnes
> > >> <jbarnes at virtuousgeek.org> wrote:
> > >>> On Sat, 05 Dec 2009 23:44:55 +0000
> > >>> Darren Salt <linux at youmustbejoking.demon.co.uk> wrote:
> > >>>
> > >>>> I demand that Andy Lutomirski may or may not have written...
> > >>>>
> > >>>> > Emmanuel Benisty wrote:
> > >>>> [snip]
> > >>>> >> I just wanted to report 2 regressions I am having now with
> > >>>> >> 2.6.32. Video
> > >>>> >> Screen is flickering/glitching like crazy in X. It happens
> > >>>> >> whether randomly or when conky is refreshed, when the mouse
> > >>>> >> cursor moves and like hell when a page is loading in the
> > >>>> >> browser. Not so easy to describe this issue.
> > >>>> [snip]
> > >>>>
> > >>>> > That sounds like FIFO underruns, which (I think) were
> > >>>> > introduced when self-refresh was enabled but should have been
> > >>>> > fixed. I personally have no clue how to fix them, but if you
> > >>>> > told the Intel people what kind of chip you have (lspci
> > >>>> > output), they can probably fix it.
> > >>>>
> > >>>> It also sounds like what I'm seeing on my EeePC 901. It only
> > >>>> happens after resume, which makes STR a little less than
> > >>>> useful; the display will, sooner or later, show a single
> > >>>> colour (which is, presumably, the result of a display engine
> > >>>> hang, as described in the comment immediately before
> > >>>> intel_calculate_wm) and, seemingly, be stuck like that until
> > >>>> power-off or reboot.
> > >>>>
> > >>>> Whether it *is* the same problem, I couldn't say.
> > >>>>
> > >>>> Needless to say, this problem goes away if I disable KMS.
> > >>>
> > >>> Arg, there are a few reports of this now, but I haven't been
> > >>> able to reproduce it.  I'll try harder...  (FYI the upstream
> > >>> bugs.freedesktop.org # for it is 24314).
> > >>
> > >> It *seems* that we are facing two different issues here (I don't
> > >> even use S2R and the problem is there since the very first second
> > >> I start X). Anyway, I have bisected the problem on my box, it
> > >> turns out to be this one:
> > >>
> > >> drm/i915: Fix render reclock availability detection
> > >>
> > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=181a5336d6cc836f05507410d66988c483ad0154
> > >>
> > > So, I have reverted this commit and rebuilt 2.6.32. It completely
> > > solved the issue described in my first post.
> > >
> > 
> > just FTR, it looks like I'm not alone:
> > http://forums.gentoo.org/viewtopic-p-6087556.html#6087556
> 
> Great, thanks for narrowing it down.  I'll see if I can come up with a
> fix.

Can you give this a try?

-- 
Jesse Barnes, Intel Open Source Technology Center

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 279dc96..5bde801 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3808,6 +3808,8 @@ void intel_decrease_renderclock(struct drm_device *dev)
 {
        drm_i915_private_t *dev_priv = dev->dev_private;
 
+       return;
+
        if (IS_IRONLAKE(dev))
                return;
 



More information about the Intel-gfx mailing list