On Wed, Jun 27, 2012 at 12:08:33AM +0200, Łukasz Kuryło wrote:
> >
> > - if (!mutex_trylock(&dev->struct_mutex))
> > - return -EBUSY;
> > + mutex_lock(&dev->struct_mutex);
> >
> > i915_gem_reset(dev);
> >
>
> But ... the original code:
>
> Correct me if I'm wrong.
>
> - if (!mutex_trylock(&dev->struct_mutex))
> - return -EBUSY;
> + mutex_lock(&dev->struct_mutex);
>
> i915_gem_reset(dev);
>
But ... the original code:
Correct me if I'm wrong.
In every manual I've found mutex_trylock(...) returns 0 on success.
So
if(!mutex_tr
So don't return -EAGAIN, even in the case of a gpu hang. Remap it to -EIO
instead.
This is a bit ugly because intel_ring_begin is all non-interruptible
and hence only returns -EIO. But as the comment in there says,
auditing all the callsites would be a pain.
To avoid duplicating code, reuse i915_
With the gpu reset no longer using a trylock we've the chances of
userspace getting stuck quite a bit. To make that (hopefully) rare
case more paletable time out when waiting for the gpu reset code to
complete and signal this little issue to the caller by returning -EIO.
This should help userspace
Simply failing to reset the gpu because someone else might still hold
the mutex isn't a great idea - I see reliable silent reset failures.
And gpu reset simply needs to be reliable and Just Work.
"But ... the deadlocks!"
We already kick all processes waiting for the gpu before launching the
reset
Having this early check in intel_ring_begin doesn't buy us anything,
since we'll be calling into wait_request in the usual case already
anyway. In the corner case of not waiting for free space using the
last_retired_head we simply need to do the same check, too.
With these changes we'll only ever
PS: The debug output etc. is in the bug tracker (already).
I'll try to compile and run (reproduce the bug) on
drm-intel-next-queued as soon as possible Daniel.
On Tue, Jun 26, 2012 at 10:09 PM, Georg Grabler wrote:
> Hello,
>
> Sorry to "hijack" this thread, but I'd like to know if it is probabl
We shouldn't hit this path anyway, but make it use the IVB sprite format
definition to avoid confusion.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_sprite.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/dr
Or going from tiled to untiled may break.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_sprite.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 9db..64174c5 100644
--- a/drivers/gpu/drm/i915
Hello,
Sorry to "hijack" this thread, but I'd like to know if it is probably
the same problem I am experiencing on the same machine, see:
https://bugs.freedesktop.org/show_bug.cgi?id=35812
Just because I seem to be sooo alone out there with that problem :-(.
Thanks,
Georg
On Tue, Jun 26, 2012 a
On Tue, Jun 26, 2012 at 03:08:32PM -0400, Giacomo Comes wrote:
> I have a dell latitude E6420 with Sandybridge Mobile (GT2).
> Since I got it (about one year ago), it has been a nightmare to run linux on
> it.
> At the beginning I installed openSUSE 11.4 (kernel 2.6.37.6) and the laptop
> would fr
I have a dell latitude E6420 with Sandybridge Mobile (GT2).
Since I got it (about one year ago), it has been a nightmare to run linux on it.
At the beginning I installed openSUSE 11.4 (kernel 2.6.37.6) and the laptop
would freeze almost immediately. After that I waited for newer kernels in order
t
On Tue, 26 Jun 2012 01:05:24 +0200, Daniel Vetter wrote:
> it would
> inevitably die on the next gtt pagefault. But I guess we can etch out
> a bit more survivability in corner cases.
Yeah, we need to do something about that pagefault-of-doom after EIO,
regardless. :(
I believe to do so we need
13 matches
Mail list logo
