On Sat, Apr 05, 2014 at 09:34:12PM +0100, Chris Wilson wrote:
> On Sat, Apr 05, 2014 at 01:08:02PM -0700, Ben Widawsky wrote:
> > Our current code cannot handle a failure to evict well. You'll get at
> > the very least the following splat, but usually a lot worse fallout after:
> >
> > [ 134.8194
Hi Peter,
Thanks for the bug report. To avoid losing track of it (too much going
on here all the time) can you please file a bug report on
bugs.freedesktop.org against DRI -> DRM (Intel).
We need
- dmesg with drm.debug=0xe added to your kernel (just for the system
information the driver dumps, so
As we've learned over time, the HW context is just a series of GPU
commands that we're able to decode without intel_error_decode. Since
many bugs recently have been implicated in the HW context state, it
makes sense to dump the whole context object in a form which can be
parsed.
Sample:
render rin
On Sat, Apr 05, 2014 at 01:08:02PM -0700, Ben Widawsky wrote:
> Our current code cannot handle a failure to evict well. You'll get at
> the very least the following splat, but usually a lot worse fallout after:
>
> [ 134.819441] [ cut here ]
> [ 134.819467] WARNING: CPU:
On Sat, Apr 05, 2014 at 12:18:05PM -0700, Ben Widawsky wrote:
> On Fri, Apr 04, 2014 at 02:40:06PM +0100, Chris Wilson wrote:
> > @@ -559,14 +519,13 @@ void i915_gem_context_close(struct drm_device *dev,
> > struct drm_file *file)
> > {
> > struct drm_i915_file_private *file_priv = file->driv
Our current code cannot handle a failure to evict well. You'll get at
the very least the following splat, but usually a lot worse fallout after:
[ 134.819441] [ cut here ]
[ 134.819467] WARNING: CPU: 3 PID: 442 at
drivers/gpu/drm/i915/i915_gem_evict.c:230 i915_gem_evict_
On Fri, Apr 04, 2014 at 02:40:06PM +0100, Chris Wilson wrote:
> If we always initialize kref for the context, even if we are using fake
> contexts for hangstats when there is no hw support, we can forgo the
> dance to dereference the ctx->obj and inspect whether we are permitted
> to use kref insid
On Sat, 5 Apr 2014 17:22:40 +0200
Daniel Vetter wrote:
> On Sat, Apr 05, 2014 at 07:29:22AM +0100, Chris Wilson wrote:
> > On Fri, Apr 04, 2014 at 04:12:09PM -0700, Jesse Barnes wrote:
> > > This always indicates a bug somewhere.
> >
> > We keep turning this off because we hadn't fixed all the b
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo)
misc bikesheds (Paulo)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c | 18 --
1 file changed, 16 in
On Sat, 5 Apr 2014 17:21:04 +0200
Daniel Vetter wrote:
> On Fri, Apr 04, 2014 at 03:12:08PM -0700, Jesse Barnes wrote:
> > Needs to happen after clock is running or it doesn't behave correctly.
> >
> > v2: fix subject (Ville)
> > make it clearer that this occurs in pre_enable (Paulo)
> >
>
On Sat, Apr 05, 2014 at 07:24:01AM +0100, Chris Wilson wrote:
> On Fri, Apr 04, 2014 at 10:41:07PM -0700, Ben Widawsky wrote:
> > I opted to do this instead of grabbing the context reference after
> > eb_create since eb_create can potentially call the shrinker, and that
> > makes things very compli
On Sat, Apr 05, 2014 at 07:29:22AM +0100, Chris Wilson wrote:
> On Fri, Apr 04, 2014 at 04:12:09PM -0700, Jesse Barnes wrote:
> > This always indicates a bug somewhere.
>
> We keep turning this off because we hadn't fixed all the bugs - as we
> try to wait on a dead pipe. Maybe this time we won't
On Fri, Apr 04, 2014 at 03:12:08PM -0700, Jesse Barnes wrote:
> Needs to happen after clock is running or it doesn't behave correctly.
>
> v2: fix subject (Ville)
> make it clearer that this occurs in pre_enable (Paulo)
>
> Signed-off-by: Jesse Barnes
Resent the wrong version or failed to g
On Fri, Apr 04, 2014 at 06:35:49PM -0300, Paulo Zanoni wrote:
> 2014-03-07 13:32 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Sprite LP2+ registers don't exist on ILK/SNB so don't read them.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Paulo Zanoni
Queued for -next, thanks for the pat
On Fri, Apr 4, 2014 at 11:11 PM, Paulo Zanoni wrote:
> Due to my past, I am not a person who should be reviewing these
> patches because I have a tendency to fear that a single variable
> rename will break everybody's machines at this point of the code :)
That's kinda why I want your opinion ;-)
On Thu, 03 Apr 2014 12:28:27 -0600
Alex Williamson wrote:
> I just happened to write-up an explanation this morning:
>
> https://bbs.archlinux.org/viewtopic.php?pid=1400212#p1400212
>
> Last I heard DRI gets disabled whenever Xorg finds that the VGA
> arbiter is managing multiple devices. There
16 matches
Mail list logo
