From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Subject: Re: CIK hangs with kernel 3.15, bisected Date: Mon, 12 May 2014 14:50:51 +0200 Message-ID: <5370C3AB.1080903@vodafone.de> References: <536D4B08.8030000@chown.ath.cx> <536DE204.5060308@vodafone.de> <536E552F.6010401@vodafone.de> <536F3D93.6050604@vodafone.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------090300090703050803010508" Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 404756E500 for ; Mon, 12 May 2014 05:51:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix1 Daemon) with ESMTP id D1B332608D0 for ; Mon, 12 May 2014 14:51:04 +0200 (CEST) Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix1.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ91qLECmgNi for ; Mon, 12 May 2014 14:50:59 +0200 (CEST) In-Reply-To: <536F3D93.6050604@vodafone.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --------------090300090703050803010508 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I could reproduce the problem with xonotic and I think I've found the iss= ue. Please test the attached patch. Thanks, Christian. Am 11.05.2014 11:06, schrieb Christian K=C3=B6nig: >> I have tested it and it doesn't fix the hangs. > Yeah, thought so. Well it was just a guess. > >> (Also, I don't like the patch, because it reverts the behavior I added >> for userspace buffers.) > Actually it shouldn't affect that. The alternative domain always=20 > contains GART even when userspace only specified VRAM as placement (as=20 > long as it is technical possible to do so). > > So what should happen is that TTM sees the current placement, matches=20 > that with the desired placement and should find that it doesn't need=20 > to move the buffer (we should just test if this behavior really works=20 > as expected). > > Christian. > > Am 10.05.2014 23:38, schrieb Marek Ol=C5=A1=C3=A1k: >> Hi Christian, >> >> I have tested it and it doesn't fix the hangs. >> >> (Also, I don't like the patch, because it reverts the behavior I added >> for userspace buffers.) >> >> Marek >> >> >> >> On Sat, May 10, 2014 at 6:34 PM, Christian K=C3=B6nig >> wrote: >>> Couldn't reproduce the issue so far. So the attached patch is just a >>> complete shoot into the dark found by rereading the code, but it migh= t >>> actually be the problem. >>> >>> Please give it a try. >>> >>> Going to keep testing in the meantime, >>> Christian. >>> >>> Am 10.05.2014 10:23, schrieb Christian K=C3=B6nig: >>> >>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if=20 >>>>> I boot >>>>> with radeon.vramlimit=3D256 and then run Xonotic timedemo with high= =20 >>>>> settings. >>>>> I haven't had a chance to bisect it yet, but it might be a similar=20 >>>>> problem. >>>> Sounds like the same issue to me. Thx for the good test case. >>>> >>>>> Any idea what is wrong with it? >>>> Actually I already wondered that it went so smooth without any=20 >>>> regression >>>> so far, didn't noticed the bug in bugzilla.kernel.org yet. >>>> >>>>> Some of the tests allocate a lot of MSAA textures and the tests als= o >>>>> run in parallel, which creates a lot of memory pressure and probabl= y >>>>> causes buffer evictions. >>>> Sounds like the underlying problem to me. We probably evict some=20 >>>> part of a >>>> page table without updating the page directory. Going to dig into=20 >>>> it today, >>>> it's probably just a one liner missing somewhere in the VM code. >>>> >>>> Christian. >>>> >>>> Am 09.05.2014 23:39, schrieb Grigori Goronzy: >>>>> On 09.05.2014 20:03, Marek Ol=C5=A1=C3=A1k wrote: >>>>>> >>>>>> This commit which first appeared in 3.15-rc1 causes hangs on=20 >>>>>> Bonaire: >>>>>> [...] >>>>>> >>>>>> The simplest way to reproduce the hangs is to run piglit with thes= e >>>>>> parameters: >>>>>> -t texelFetch.fs >>>>>> >>>>>> Some of the tests allocate a lot of MSAA textures and the tests al= so >>>>>> run in parallel, which creates a lot of memory pressure and probab= ly >>>>>> causes buffer evictions. >>>>>> >>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if=20 >>>>> I boot >>>>> with radeon.vramlimit=3D256 and then run Xonotic timedemo with high= =20 >>>>> settings. >>>>> I haven't had a chance to bisect it yet, but it might be a similar=20 >>>>> problem. >>>>> >>>>> Grigori >>>> > --------------090300090703050803010508 Content-Type: text/x-diff; name="0001-drm-radeon-fix-page-directory-update-size-estimation.patch" Content-Disposition: attachment; filename*0="0001-drm-radeon-fix-page-directory-update-size-estimation.pa"; filename*1="tch" Content-Transfer-Encoding: quoted-printable >>From a81682b06f702ea35ccc7fdc176c3f8db6cff138 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Christian=3D20K=3DC3=3DB6nig?=3D Date: Mon, 12 May 2014 14:46:11 +0200 Subject: [PATCH] drm/radeon: fix page directory update size estimation MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Take padding into account as well. Signed-off-by: Christian K=C3=B6nig --- drivers/gpu/drm/radeon/radeon_vm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/= radeon_vm.c index 2aae6ce..d9ab99f 100644 --- a/drivers/gpu/drm/radeon/radeon_vm.c +++ b/drivers/gpu/drm/radeon/radeon_vm.c @@ -595,7 +595,7 @@ int radeon_vm_update_page_directory(struct radeon_dev= ice *rdev, ndw =3D 64; =20 /* assume the worst case */ - ndw +=3D vm->max_pde_used * 12; + ndw +=3D vm->max_pde_used * 16; =20 /* update too big for an IB */ if (ndw > 0xfffff) --=20 1.9.1 --------------090300090703050803010508 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --------------090300090703050803010508--