[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091214102015.2f43f5b4@jbarnes-piketon>
Date: Mon, 14 Dec 2009 10:20:15 -0800
From: Jesse Barnes <jbarnes@...tuousgeek.org>
To: Dave Airlie <airlied@...hat.com>
Cc: Arnd Bergmann <arnd@...db.de>, Daniel Vetter <daniel@...ll.ch>,
Adam Jackson <ajax@...hat.com>, linux-kernel@...r.kernel.org,
dri-devel@...ts.sourceforge.net, keithp@...thp.com,
eric@...olt.net, Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [BISECTED] drm: random hang since 620f378 "drm: prune modes
when ..."
On Mon, 14 Dec 2009 07:54:05 +1000
Dave Airlie <airlied@...hat.com> wrote:
> On Sun, 2009-12-13 at 21:31 +0000, Arnd Bergmann wrote:
> > On Sunday 13 December 2009 20:00:18 Daniel Vetter wrote:
> > > On Sun, Dec 13, 2009 at 12:30:25PM +0000, Arnd Bergmann wrote:
> > > > And now it's obvious that my computer hates me. 12 hours of
> > > > uptime, one reboot to check the old other version is broken, it
> > > > crashes. I reboot into the good version, send out the above
> > > > email and the next minute it crashes again. c05422d52ee6b is
> > > > not the culprit. Sorry Daniel for blaming your patch.
> > >
> > > No problem. Looks like your hunting a pretty ugly Heisenbug.
> > > There's quite a interesting blog post by Paul McKenney, esp. the
> > > solution to "Quick Quiz 1" might be usefull in your case:
> > >
> > > http://paulmck.livejournal.com/14639.html
> >
> > Thanks! In fact I've actually read that post on the kernel planet
> > and decided to do basically a linear search through the i915
> > patches merged into 2.6.32.
> >
> > The current result is 67cf781bea5 "drm/i915: Make the downclocking
> > debug code be under DRM_DEBUG not DRM_ERROR." is known bad, while
> > 043029655 "drm/i915: Support IGD EOS" is probably good, pointing to
> > Jesses 652c393a33 "drm/i915: add dynamic clock frequency control"
> > as the next best guess. Unfortunately, that is a rather large
> > change that is not easy to revert on current kernels.
>
> That seems the most likely, perhaps jbarnes can comment.
You can disable most of that code by loading i915 with 'powersave=0'.
If that patch really is at fault the powersave=0 should work around the
issue as well.
It's been implicated in another issue (some display flicker and
underruns) so I'm pretty sure there's something wrong with it in some
configurations at least...
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists