Ted Phelps writes:
> Daniel Vetter writes:
> > If it's short (order of a second or less) can you rehang your gpu with
> > kernel log timestamping switched on?
>
> I'm happy to re-hang the GPU with kernel log timestamping enabled, but I
> won't be able to do
Daniel Vetter writes:
> On Thu, Aug 4, 2011 at 16:05, Ted Phelps wrote:
> > I saw a bunch of stack traces like the one below, alternating between
> > ring_put and ring_get, before the GPU was declared wedged.
>
> How much time happens between the first wait_for_fifo backtrac
Keith Packard writes:
> Jesse Barnes and I found a couple of issues where incorrect mode
> setting would cause problems with RC6 enabled. We're hopeful that
> fixing those will resolve the outstanding issues with a few machines
> that had trouble before 3.0 with rc6.
Thanks for continuing to bash
Ben Widawsky writes:
> On Wed, Jul 06, 2011 at 04:03:14PM -0700, Keith Packard wrote:
> > On Wed, 6 Jul 2011 15:14:52 -0700, Ben Widawsky wrote:
> >
> > > -static int i915_modeset =3D -1;
> > > +static int i915_modeset __read_mostly =3D -1;
> >
> > What effect does this have? Performance? Code si
Jesse Barnes writes:
> > [Note to self: submit a bug report]
>
> Please do; and please try to confirm that your GPU hangs are really rc6
> related. RC6 provides a huge (multiple Watt) power savings, and we
> really want it to be robust.
Done: BZ#38567. I'd love to save those watts, so please le
Hi Nicolas,
Nicolas Kalkhof writes:
> SNB GPU still hangs frequently with kernel patches next-20110620
> raising "drm:i915_hangcheck_ring_idle *ERROR* Hangcheck timer
> elapsed... gen6 bsd ring idle". This happens when multiple
> applications (mplayer decoding vaapi stream and some openGL game)
>
Jesse Barnes writes:
> Please try this patch.
Works a treat, as does the one that Keith merged into drm-intel-next.
Thanks for the speedy patch!
-Ted
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listin
Jesse Barnes writes:
> Set the IRQ handling functions in driver load so they'll just be used
> directly, rather than branching over most of the code in the chipset
> functions.
I'm seeing a kernel panic on my SNB i7-2600K with keithp/drm-intel-next
(61e499b). I've bisected to 4697995 -- the comm
Ted Phelps writes:
> Chris Wilson writes:
> > Whenever we finish reading an object through a fence, for safety we
> > clear any GPU read domain and so invalidate any TLBs associated with
> > the fenced region upon its next use.
>
> This change is causing a regressio
Chris Wilson writes:
> Whenever we finish reading an object through a fence, for safety we
> clear any GPU read domain and so invalidate any TLBs associated with
> the fenced region upon its next use.
This change is causing a regression on my Sandybridge CPU (i7 2600K).
The colours all look right
Hi Andy,
Andi Kleen writes:
> Ted Phelps writes:
>
> > Apologies if this is a known issue, but I haven't been able to convince
> > myself that someone is looking after it. I've been seeing this issue
> > with Linux kernel 2.6.37, 2.6.38-rc4 and the most re
Apologies if this is a known issue, but I haven't been able to convince
myself that someone is looking after it. I've been seeing this issue
with Linux kernel 2.6.37, 2.6.38-rc4 and the most recent merge of Linus's
git tree and drm-intel-fixes. I'm happy to provide more information,
apply patche
12 matches
Mail list logo
