Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755141Ab0KIKlN (ORCPT ); Tue, 9 Nov 2010 05:41:13 -0500 Received: from darkcity.gna.ch ([195.226.6.51]:40098 "EHLO mail.gna.ch" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754789Ab0KIKlK convert rfc822-to-8bit (ORCPT ); Tue, 9 Nov 2010 05:41:10 -0500 X-Greylist: delayed 467 seconds by postgrey-1.27 at vger.kernel.org; Tue, 09 Nov 2010 05:41:09 EST X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 09 hex): Face: ...MWASAkVVViQjzP\n jycPrvgA\n\t\n R1goSzOnkp14Y[...] Subject: Re: Radeon RS780 - BUG: unable to handle kernel NULL pointer dereference From: Michel =?ISO-8859-1?Q?D=E4nzer?= To: Thomas Hellstrom Cc: "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Markus Trippelsdorf In-Reply-To: <4CD91D58.7080508@vmware.com> References: <20101108170221.GA1602@arch.trippelsdorf.de> <20101108170737.GA1617@arch.trippelsdorf.de> <20101108184301.GA1614@arch.trippelsdorf.de> <20101108190258.GA1623@arch.trippelsdorf.de> <4CD879BC.5060008@vmware.com> <20101109092920.GA1542@arch.trippelsdorf.de> <4CD91A07.1060308@vmware.com> <4CD91D58.7080508@vmware.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAADBQTFRFDg4OHh4eLCwsOzs7S0tLWlpaa2treXl5hISEjY2NmJiYqKiotLS0xsbG1dXV/Pz81CO0SQAAArtJREFUOMtd1M9P01AcAHCI/4AtGq/QDfDHRfraEX8eaNeJFw1rO/DCYet7mxc1ZG0x3sStHQkmZpqtHDwAi+tMiFEzbZdwNWEJR48cjPG4g5HhELUbrHvjpYe2n7zvt++977cD/7rjsCry8uNG93Gge9OKUyAAgLB1AlpTZICmAzR15QTEiQAPAKADYLMPfhNnEJR4HvD0tT5YI2KGUcyqihQN7mDwZ3hMN4q2N4ol+gEGTSLWhorrjYXrGPwc0jTDOoKP4xi8G0W6adl2Gz6zGDwag5p5PMON7vZgJuSB976+3U6y2QdeKNet1+uum9/qwVQHvEjtKesY0EIb7CNYe+7DIRXCID/vQ4tksVAY7JFBD7yvqrWTL93xoUmOQsPIddbnuk8v+bBPsigB2KRlFxS4nL/owwEpKBSg2MU3UcDf+nATyyHEQwrHzJZFNpXeuOHDC0qW4sMhEHESFGOUrvgQpWUYFVNQdjQxca8abnSB55CmehdcLSxa1ifoQ4JBpmGYWbhsly3X0fxQ7xmkW3Y5CztLcXI+fAu2oWho3nbV6s5rH35xSC/aBR2tOpVa/Utv25tcTDPL6aT21kG17WrvaFtMBJmFhJCsVF4uu9VG76DWBaRnEiNs7pU659pYlfwtQSRy9GCYlwR7C6/dPQgBw3MsTPNWA4d9SeMDDC9JYdnqq/amdF+diGnVhXFztQ/2lJSWjulOxjRX+uC7EkOqhLRk2ejrqHVBEqCqJLO5cmEXgx8TrBiWVQh1u2DhzQlPsyIveU2YLGorGBxODoR5notlpcUieoLB1/NEmGc4AalGJpLe8WF/8txMWASAkVVViQjzP jycPrvgA R1goSzOnkp14YCYHsp7QJHAS5QcXDqG1jBxdSITVgBNkBTFloj88Q/gMkFcuItYiQPUCBGc2xh5drsD/wGZrgsgDOE4ZAAAAABJRU5ErkJggg== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Tue, 09 Nov 2010 11:32:57 +0100 Message-ID: <1289298777.10682.63.camel@thor.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4237 Lines: 109 On Die, 2010-11-09 at 11:07 +0100, Thomas Hellstrom wrote: > On 11/09/2010 10:53 AM, Thomas Hellstrom wrote: > > On 11/09/2010 10:29 AM, Markus Trippelsdorf wrote: > >> OK I've found the buggy commit by bisection: > >> > >> e376573f7267390f4e1bdc552564b6fb913bce76 is the first bad commit > >> commit e376573f7267390f4e1bdc552564b6fb913bce76 > >> Author: Michel Dänzer > >> Date: Thu Jul 8 12:43:28 2010 +1000 > >> > >> drm/radeon: fall back to GTT if bo creation/validation in VRAM > >> fails. > >> > >> This fixes a problem where on low VRAM cards we'd run out of > >> space for validation. > >> > >> [airlied: Tested on my M7, Thinkpad T42, compiz works with no > >> problems.] > >> > >> Signed-off-by: Michel Dänzer > >> Cc: stable@kernel.org > >> Signed-off-by: Dave Airlie > >> > >> Please note that this is an old commit from 2.6.36-rc. When I revert > >> it the > >> kernel no longer crashes. Instead I see the following in my dmesg: > >> > > > > Hmm, so this sounds like something in the Radeon eviction error path > > is causing corruption. > > I had a similar problem with vmwgfx, when I tried to unref a BO > > _after_ ttm_bo_init() failed. > > ttm_bo_init() is really supposed to call unref itself for various > > reasons, so calling unref() or kfree() after a failed ttm_bo_init() > > will cause corruption. > > > > In any case, the error below also suggests something is a bit fragile > > in the Radeon driver: > > > > First, an accelerated eviction may fail, like in the message below, > > but then there must always be a backup plan, like unaccelerated > > eviction to system. On BO creation, there are a number of placement > > strategies, but if all else fails, it should be possible to initially > > place the BO in system memory. > > > > Second, If bo validation fails during a command submission, due to > > insufficient VRAM / TT, then the driver should retry the complete > > validation cycle after first blocking all other validators and then > > evicting everything not pinned, to avoid failures due to fragmentation. > > > > /Thomas > > > > Indeed, it seems like the commit you mention just retries ttm_bo_init() > after it previously failed. At that point the bo has been destroyed, so > that is probably what's causing the BUG you are seeing. > > Admittedly, ttm_bo_init() calling unref on failure is not properly > documented in the function description. The reason for doing so is to > have a single path for freeing all BO resources already allocated on the > point of failure. Does the patch below fix the problem? commit e224472eedbda391ddb6d8b88f26e82e1c3b036b Author: Michel Dänzer Date: Tue Nov 9 11:30:41 2010 +0100 drm/radeon/kms: Fix retrying ttm_bo_init() after it failed once. If ttm_bo_init() returns failure, it already destroyed the BO, so we need to retry from scratch. Signed-off-by: Michel Dänzer Cc: stable@kernel.org diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 1b9004e..bbe92d5 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -102,6 +102,8 @@ int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj, type = ttm_bo_type_device; } *bo_ptr = NULL; + +retry: bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL); if (bo == NULL) return -ENOMEM; @@ -109,8 +111,6 @@ int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj, bo->gobj = gobj; bo->surface_reg = -1; INIT_LIST_HEAD(&bo->list); - -retry: radeon_ttm_placement_from_domain(bo, domain); /* Kernel allocation are uninterruptible */ mutex_lock(&rdev->vram_mutex); -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/