From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 13/13] drm/radeon: rework recursive gpu reset handling
Date: Fri, 20 Apr 2012 09:50:52 +0200
Message-ID: <20120420075052.GD4217@phenom.ffwll.local>
References: <1334875160-5454-1-git-send-email-deathsimple@vodafone.de>
	<1334875160-5454-14-git-send-email-deathsimple@vodafone.de>
	<CAPM=9txr5EMjY4T8CtEtphkzTcxK8vRerzurXSNnLfHXY7CTxw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com
	[74.125.82.177])
	by gabe.freedesktop.org (Postfix) with ESMTP id E9DBDA0E46
	for <dri-devel@lists.freedesktop.org>;
	Fri, 20 Apr 2012 00:49:52 -0700 (PDT)
Received: by werp11 with SMTP id p11so7211239wer.36
	for <dri-devel@lists.freedesktop.org>;
	Fri, 20 Apr 2012 00:49:52 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <CAPM=9txr5EMjY4T8CtEtphkzTcxK8vRerzurXSNnLfHXY7CTxw@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: Dave Airlie <airlied@gmail.com>
Cc: Christian =?iso-8859-1?Q?K=F6nig?= <deathsimple@vodafone.de>, dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

On Fri, Apr 20, 2012 at 07:57:09AM +0100, Dave Airlie wrote:
> 2012/4/19 Christian K=F6nig <deathsimple@vodafone.de>:
> > Instead of all this humpy pumpy with recursive
> > mutex (which also fixes only halve of the problem)
> > move the actual gpu reset out of the fence code,
> > return -EDEADLK and then reset the gpu in the
> > calling ioctl function.
> =

> I'm trying to figure out if this has any disadvantages over doing what
> I proposed before and just kicking a thread to reset the gpu.
> =

> It seems like this should also avoid the locking problems, I'd like to
> make sure we don't return -EDEADLK to userspace by accident anywhere,
> since I don't think it prepared for it and it would be an ABI change.

Fyi, the trick i915 uses to solve the reset problem is to bail out with
-EAGAIN and rely on drmIOCtl restarting the ioctl. This way we use the
same codepaths we use to bail out when getting a signal, and thanks to X
these are rather well-tested. The hangcheck code also fires of a work item =
to
do all the reset magic. In all the ioctls that might wait for the gpu we
have a fancy piece of code which checks whether a gpu reset is pending,
and if so waits for that to complete. It also checks whether the reset
succeeded and if not bails out with -EIO.
-Daniel
-- =

Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48