From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 17:44:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 312B0AE1; Wed, 6 Aug 2014 17:44:59 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94A8B2D3E; Wed, 6 Aug 2014 17:44:58 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id b13so3022982wgh.30 for ; Wed, 06 Aug 2014 10:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o35s5hPhAcygRdB2GSS6x2wYMQHE/PkoMNenkbA/9u8=; b=WT0AXk860L3jrpV0JZjbH7bo6Zw2aF9sQ6MgK7p55zxU2Cd2x0btafngQjPr2ru5Ws iom4pwPa7nWYmfVlosXbL4qma1N4Slywf8QHx41PF9J4mpgd3jDMT1AKF+iXDVymR5P7 GKvmZsUWAhrq9B+N9ae2Swt5+4JXXRuBRtHdbYWKyW7UF7ylLm0sNmOKIDhXC2QFl5MH wHkU/qGNaLkMeUTx9XCxurWqK1uOjrkTgTGwrTyOEfVC2K16Iw6GzO1Kd97P8z6z7lpr uPd5SzLSwE45X5S+uiTc4Vi+gTAIufh9TJLd8TZXeESfEnae2Wgvh649Oai8HqWYSFuL 3Fcg== X-Received: by 10.180.39.139 with SMTP id p11mr11883848wik.50.1407347096776; Wed, 06 Aug 2014 10:44:56 -0700 (PDT) Received: from [172.16.1.30] (39.Red-2-136-52.dynamicIP.rima-tde.net. [2.136.52.39]) by mx.google.com with ESMTPSA id f3sm8227434wiz.0.2014.08.06.10.44.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 10:44:55 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <53E26996.20503@FreeBSD.org> Date: Wed, 06 Aug 2014 19:44:54 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: r259580 breaks radeonkms References: <53E178BC.4040201@freebsd.org> <53E1F6E3.1040304@FreeBSD.org> <5850878054da9ac1898035b6c5d010e5@sonic.net> <53E25D3E.7000200@FreeBSD.org> <20140806173833.GJ93733@kib.kiev.ua> In-Reply-To: <20140806173833.GJ93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 17:44:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/14 19:38, Konstantin Belousov wrote: > On Wed, Aug 06, 2014 at 06:52:14PM +0200, Roger Pau Monn?? wrote: >> On 06/08/14 16:35, Nathan Whitehorn wrote: >>> >>> >>> On 2014-08-06 02:35, Roger Pau Monn?? wrote: >>>> On 06/08/14 02:37, Nathan Whitehorn wrote: >>>>> Kernels with r269580 will panic when loading the radeonkms >>>>> driver in pmap_page_set_memattr(). This probably indicates >>>>> a bug in radeonkms, but the system is unusable in the >>>>> meantime. -Nathan >>>> >>>> I seem to be able to load radeonkms just fine after r269580: >>> >>> It's possible that it is related to actually using it, rather >>> than loading the module. I was only testing them together. I'm >>> using vt and the panic (page fault in kernel mode) occurs when >>> TTM tries to set memory attributes on some page while starting >>> X. Before the panic, I see all the normal Radeon module >>> messages as you do, so the module seems to have actually loaded >>> correctly. The KMS console also seems to be functional enough >>> to display the panic message, so I suspect it's X that triggers >>> it. -Nathan >> >> Please try the attached patch, it seems to solve the panic for >> me. It also includes a fix for Intel i915 gem, which I'm not able >> to test because I don't have the hardware. >> >> Roger. >> > >> From 9dd3a21d99ff2fc7bf3299359751d2399eee912a Mon Sep 17 00:00:00 >> 2001 From: Roger Pau Monne Date: Wed, 6 >> Aug 2014 18:16:53 +0200 Subject: [PATCH] drm: fix usage of >> vm_phys_fictitious_to_vm_page >> >> vm_phys_fictitious_to_vm_page should not be called directly, even >> when operating on a range that has been registered using >> vm_phys_fictitious_reg_range. PHYS_TO_VM_PAGE should be used >> instead because on arches that use VM_PHYSSEG_DENSE the page >> might come directly from vm_page_array. >> >> Reported by: nwhitehorn Sponsored by: Citrix Systems R&D --- >> sys/dev/drm2/i915/i915_gem.c | 6 ++++-- >> sys/dev/drm2/ttm/ttm_bo_vm.c | 8 ++++++-- 2 files changed, 10 >> insertions(+), 4 deletions(-) >> >> diff --git a/sys/dev/drm2/i915/i915_gem.c >> b/sys/dev/drm2/i915/i915_gem.c index a3acb60..6d46207 100644 --- >> a/sys/dev/drm2/i915/i915_gem.c +++ >> b/sys/dev/drm2/i915/i915_gem.c @@ -1428,8 +1428,10 @@ retry: >> >> obj->fault_mappable = true; VM_OBJECT_WLOCK(vm_obj); - m = >> vm_phys_fictitious_to_vm_page(dev->agp->base + obj->gtt_offset + >> - offset); + m = PHYS_TO_VM_PAGE(dev->agp->base + >> obj->gtt_offset + offset); + KASSERT((m->flags & PG_FICTITIOUS) >> != 0, + ("physical address %#jx not fictitious", + >> (uintmax_t)(dev->agp->base + obj->gtt_offset + offset))); if (m >> == NULL) { VM_OBJECT_WUNLOCK(vm_obj); cause = 60; diff --git >> a/sys/dev/drm2/ttm/ttm_bo_vm.c b/sys/dev/drm2/ttm/ttm_bo_vm.c >> index 83ec76c..7aa1ac0 100644 --- a/sys/dev/drm2/ttm/ttm_bo_vm.c >> +++ b/sys/dev/drm2/ttm/ttm_bo_vm.c @@ -216,8 +216,12 @@ reserve: >> } >> >> if (bo->mem.bus.is_iomem) { - m = >> vm_phys_fictitious_to_vm_page(bo->mem.bus.base + - >> bo->mem.bus.offset + offset); + m = >> PHYS_TO_VM_PAGE(bo->mem.bus.base + bo->mem.bus.offset + + >> offset); + KASSERT((m->flags & PG_FICTITIOUS) != 0, + >> ("physical address %#jx not fictitious", + >> (uintmax_t)(bo->mem.bus.base + bo->mem.bus.offset + + >> offset))); pmap_page_set_memattr(m, >> ttm_io_prot(bo->mem.placement)); } else { ttm = bo->ttm; > > This should be fine. In fact I considered doing similar change > some time ago, but for some reasons decided not to. Still, it is > not clear why does it break with your changes, in particular, the > PCI hole where the aperture is mapped should be covered by > vm_page_array. This is because I've changed the logic in vm_phys_fictitious_reg_range, so that if a region is covered by vm_page_array it is no longer added to the red-black tree that tracks fictitious ranges, and thus vm_phys_fictitious_to_vm_page returns NULL in those cases. Roger. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAEBAgAGBQJT4mmWAAoJEKXZdqUyumTAEpIH/1c/BgcC0MvlTPTq4yamnGTD FdoaNABSfh6VRRfAlQjzyTKldVLpXfcZnTpVaHiTNZgT2TRDzFoI3Brawhr33grg 1MDpYS+EusxadkTBYrsV8rQ4+t1K6jCPxgOJPVnB+85ud2Uu6SWJgilfZTW2Raq4 AKlItP2BrKtH0+Fbrtg7rBsz/Knx7kExC7bPHyBBDDuakfZJFhfIn/To1iJgw5Ug Nmtje8IhEChtZFG9Q3S1IT8Azb8FlnImXaBdwk2bBhjMaeP0jKQFV7a6lpG+4Jjs 3/PeJtgsQpCry7oIZNZ8sCptQSRAx4lSKjgpqoTchowSv1Fj41a0s7IsJ4ALiQ8= =DbvG -----END PGP SIGNATURE-----