From patchwork Mon Dec 17 21:31:24 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Bolle X-Patchwork-Id: 1889041 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork2.kernel.org (Postfix) with ESMTP id 1D5A4DF266 for ; Mon, 17 Dec 2012 21:31:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9CDA2E61EE for ; Mon, 17 Dec 2012 13:31:40 -0800 (PST) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from cpsmtpb-ews03.kpnxchange.com (cpsmtpb-ews03.kpnxchange.com [213.75.39.6]) by gabe.freedesktop.org (Postfix) with ESMTP id 74DE4E5DE9 for ; Mon, 17 Dec 2012 13:31:26 -0800 (PST) Received: from cpsps-ews14.kpnxchange.com ([10.94.84.181]) by cpsmtpb-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 17 Dec 2012 22:30:28 +0100 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews14.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 17 Dec 2012 22:30:28 +0100 Received: from [192.168.1.103] ([212.123.139.93]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 17 Dec 2012 22:31:24 +0100 Message-ID: <1355779884.1414.14.camel@x61.thuisdomein> Subject: [PATCH] [RFC] drm/radeon: return 0 on successful gpu reset From: Paul Bolle To: David Airlie , Christian =?ISO-8859-1?Q?K=F6nig?= , Jerome Glisse Date: Mon, 17 Dec 2012 22:31:24 +0100 X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2012 21:31:24.0716 (UTC) FILETIME=[DD771EC0:01CDDC9D] X-RcptDomain: lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org Errors-To: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org On an (outdated) laptop the radeon driver (almost always) prints, during the first resume of each session: [drm] crtc 1 is connected to a TV This message is a bit puzzling as, as far as I know, no TV has ever been connected to this laptop. Anyhow, before v3.5, if that happened the radeon driver then printed an error during all following resumes: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35! (-35 is -EDEADLK.) But the resume would succeed and the driver seemed to run without too much trouble. From v3.5 onwards things changed. If the (puzzling) message about crtc 1 was printed on first resume the laptop would simply hang on second resume. Only a manual power off would then be possible. In that case nothing of interest would be found in the (truncated) logs. And, most annoyingly, the hang would never happen if the laptop was booted with, say, "console=ttyS0,115200n8" added to the kernel command line. I bisected the hang to commit 6c6f478370eccfbfafbdc6fc55c0def03e58f124 ("drm/radeon: rework recursive gpu reset handling"), which was added in the v3.5 release cycle. After discovering that and poking at the driver it turned out that this hang is triggered by radeon_cs_handle_lockup() returning -EAGAIN after successfully resetting the gpu. Simply returning 0 makes the hang disappear (and makes the drm error reappear). Nothing in the code or the commit explanation clarifies why -EAGAIN should be returned on successful gpu reset. So I suggest radeon_cs_handle_lockup() simply returns what radeon_gpu_reset() returns, eg 0 (on success) or a negative error code (on failure). Signed-off-by: Paul Bolle --- 0) This exact patch is untested (but I run something comparable). 1) Sent as an RFC because I do not understand why this laptop (almost always) prints the "crtc 1" message on first resume. Note that another workaround for this hang is simply booting with "radeon.tv=0". 2) Also sent as an RFC because I have no idea whatsoever why returning -EAGAIN will hang the machine. I guess it's returned to userland by radeon_cs_ioctl(). What code uses that ioctl? And what does that code do on -EAGAIN that hangs this laptop? 3) A third reason to send this as an RFC is that I also have no idea why this hang doesn't happen when booting with "console=ttyS0,115200n8" or even "console=tty0"! But I guess I'm now allowed to call this hang a Heisenbug. drivers/gpu/drm/radeon/radeon_cs.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index 41672cc..a302c00 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -486,11 +486,8 @@ out: static int radeon_cs_handle_lockup(struct radeon_device *rdev, int r) { - if (r == -EDEADLK) { + if (r == -EDEADLK) r = radeon_gpu_reset(rdev); - if (!r) - r = -EAGAIN; - } return r; }