From owner-freebsd-x11@FreeBSD.ORG Thu Jun 14 17:06:35 2012 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF82C106564A for ; Thu, 14 Jun 2012 17:06:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 568028FC14 for ; Thu, 14 Jun 2012 17:06:35 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5EH6NiT020569; Thu, 14 Jun 2012 20:06:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5EH6NAb098133; Thu, 14 Jun 2012 20:06:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5EH6NI9098132; Thu, 14 Jun 2012 20:06:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Jun 2012 20:06:23 +0300 From: Konstantin Belousov To: Luca Pizzamiglio , Soeren Straarup Message-ID: <20120614170623.GD2337@deviant.kiev.zoral.com.ua> References: <4FD86E13.6090202@bally-wulff.de> <20120613112601.GS2337@deviant.kiev.zoral.com.ua> <4FD992E4.9080902@bally-wulff.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DvpQYQy10PodzGf7" Content-Disposition: inline In-Reply-To: <4FD992E4.9080902@bally-wulff.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: x11@freebsd.org Subject: Re: Intel KMS: a memory problem X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 17:06:35 -0000 --DvpQYQy10PodzGf7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2012 at 09:29:40AM +0200, Luca Pizzamiglio wrote: > On 06/13/12 13:26, Konstantin Belousov wrote: > >On Wed, Jun 13, 2012 at 12:40:19PM +0200, Luca Pizzamiglio wrote: > >>Hi people, > >> > >>I'm using 9-RELENG with KMS and the last port updated on a SandyBridge > >>platform (Intel Graphics) > >>With a quite simple openGL application, a panic occurred: > >> > >>panic: pmap_mapdev: Couldn't alloc kernel virtual memory > >>Tracing pid 944 tid 100105 td 0xca85c8a0 > >>kdb_enter(c0ffe535,c0ffe535,c103dcff,efa62ac0,1,...) at kdb_enter+0x3a > >>panic(c103dcff,5000,c9879151,0,c1a02000,...) at panic+0x18c > >>pmap_mapdev_attr(c1a02000,4800,1,1,c911d980,...) at pmap_mapdev_attr+0x= 7e > >>i915_gem_obj_io(2d014008,0,4800,0,0,...) at i915_gem_obj_io+0x513 > >>i915_gem_pwrite_ioctl(c9925800,ca827120,ca871300,c0a78b5b,efa62bd4,...) > >>at i915_gem_pwrite_ioctl+0x4b > >>drm_ioctl(c97e0400,8020645d,ca827120,3,ca85c8a0,...) at drm_ioctl+0x2d8 > >>devfs_ioctl_f(c91cb850,8020645d,ca827120,c91b5e80,ca85c8a0,...) at > >>devfs_ioctl_f+0x10a > >>kern_ioctl(ca85c8a0,4,8020645d,ca827120,a62ccc,...) at kern_ioctl+0x2a0 > >>sys_ioctl(ca85c8a0,efa62ccc,c67c4c80,293d3b4e,1,...) at sys_ioctl+0x134 > >>syscall(efa62d08) at syscall+0x34a > >>Xint0x80_syscall() at Xint0x80_syscall+0x21 > >>--- syscall (54, FreeBSD ELF32, sys_ioctl), eip =3D 0x293d5b93, esp =3D > >>0xbfbf7f4c, ebp =3D 0xbfbf7f68 --- > >> > >>I tried to increase vm.kmem_size and vm.kmem_size_max to 512M, but the > >>problem persists. > >> > >>Any easy idea or workaround? > >>In the meanwhile, I'll try to investigate this problem deeper. > > > >You are probably first who run 32bit kernel on SandyBridge + GEMified > >i915 driver. > > > > From the trace you provided it seems that kernel was unable to find > >a free area in KVA for 5 consequtive pages. I would think that you have > >relatively high fragmentation of KVA. What load on machine is ? > > > >Actually, quite some time ago, i915_gem_gtt_write() did mapped gtt > >page by page, instead of mapping the whole range of pages undergoing i/o. > >I was pointed out that this was major performance bootleneck for GTT > >mapped objects. It might be reasonable to restore the slow mode for > >32bit kernels, since people running such kernels on SandyBridge definite= ly > >do not care about performance. > > >=20 > Hi Konstantin, > Thanks for the quick reply! > yes, maybe I'm the first using 32bit architecture on SandyBridge, but=20 > for some internal conflicts (human ones) I should use 32 bit version and= =20 > performance is an important topic. > It's quite strange what are you saying about KVA fragmentation, the load= =20 > of the machine is really low < 0.3; test scenario is: boot, starting X=20 > with twm and launching our openGL application.. after a couple of=20 > minutes, it panics. The openGL application draw a black screen and some= =20 > lines to show performance indexes, like CPU percentage usage, time per=20 > frame, and so on. CPU percentage is about 7-9%. > The system has 4 GB of memory, but only 3GB are addressable. > Any idea how could I monitor memory fragmentation? Ok, there was second report of the same panic. Please apply the debugging patch from the end of message, and show me the panic message after. >=20 > I would like to try PAE extension to address more memory or use 64 bit=20 > world with the 32 bit compatibility layer. PAE extension is easy to=20 > test, but for 64bit I need to delete&reinstall&recompile everything... I am sure that i915 does not work with PAE, probably not even compiles. diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c index d02f00e..e15d24f 100644 --- a/sys/i386/i386/pmap.c +++ b/sys/i386/i386/pmap.c @@ -4983,8 +4983,10 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int = mode) va =3D KERNBASE + pa; else va =3D kmem_alloc_nofault(kernel_map, size); - if (!va) - panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); + if (va =3D=3D 0) { + panic("pmap_mapdev: Couldn't alloc kernel virtual memory, " + "size %d", size); + } =20 for (tmpsize =3D 0; tmpsize < size; tmpsize +=3D PAGE_SIZE) pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); --DvpQYQy10PodzGf7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/aGg8ACgkQC3+MBN1Mb4hFmwCg0GJTLTGeIXG/6lPN6oIkaObU lRMAn31j74RfqwO7cbKSSpNTVQlYVVvt =Cb9x -----END PGP SIGNATURE----- --DvpQYQy10PodzGf7--