From owner-freebsd-x11@FreeBSD.ORG Wed Jun 13 11:26:24 2012 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8F3C106564A for ; Wed, 13 Jun 2012 11:26:23 +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 63EE68FC12 for ; Wed, 13 Jun 2012 11:26:22 +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 q5DBQ1lu024678; Wed, 13 Jun 2012 14:26:01 +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 q5DBQ1qe073872; Wed, 13 Jun 2012 14:26:01 +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 q5DBQ1ed073871; Wed, 13 Jun 2012 14:26:01 +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: Wed, 13 Jun 2012 14:26:01 +0300 From: Konstantin Belousov To: Luca Pizzamiglio Message-ID: <20120613112601.GS2337@deviant.kiev.zoral.com.ua> References: <4FD86E13.6090202@bally-wulff.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gh9b96O0vZdbsJLX" Content-Disposition: inline In-Reply-To: <4FD86E13.6090202@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: Wed, 13 Jun 2012 11:26:24 -0000 --gh9b96O0vZdbsJLX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2012 at 12:40:19PM +0200, Luca Pizzamiglio wrote: > Hi people, >=20 > I'm using 9-RELENG with KMS and the last port updated on a SandyBridge=20 > platform (Intel Graphics) > With a quite simple openGL application, a panic occurred: >=20 > 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+0x7e > i915_gem_obj_io(2d014008,0,4800,0,0,...) at i915_gem_obj_io+0x513 > i915_gem_pwrite_ioctl(c9925800,ca827120,ca871300,c0a78b5b,efa62bd4,...)= =20 > 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=20 > 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= =20 > 0xbfbf7f4c, ebp =3D 0xbfbf7f68 --- >=20 > I tried to increase vm.kmem_size and vm.kmem_size_max to 512M, but the=20 > problem persists. >=20 > 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. =46rom 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 definitely do not care about performance. --gh9b96O0vZdbsJLX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/YeMkACgkQC3+MBN1Mb4hITgCfdcYO6gHEM7FLZBLo2uAWmhn+ qEgAoL11dOqS9fZ1FZUzoxx6MVPxpwi2 =SNYC -----END PGP SIGNATURE----- --gh9b96O0vZdbsJLX--