From owner-freebsd-x11@FreeBSD.ORG Thu Jun 14 17:34:12 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 566281065673 for ; Thu, 14 Jun 2012 17:34:12 +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 973B78FC0C for ; Thu, 14 Jun 2012 17:34:11 +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 q5EHY5JQ025433; Thu, 14 Jun 2012 20:34:05 +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 q5EHY4YV098293; Thu, 14 Jun 2012 20:34:04 +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 q5EHY4lW098292; Thu, 14 Jun 2012 20:34:04 +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:34:04 +0300 From: Konstantin Belousov To: Luca Pizzamiglio , Soeren Straarup Message-ID: <20120614173404.GE2337@deviant.kiev.zoral.com.ua> References: <4FD86E13.6090202@bally-wulff.de> <20120613112601.GS2337@deviant.kiev.zoral.com.ua> <4FD992E4.9080902@bally-wulff.de> <20120614170623.GD2337@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c2qmoHupxsh34lk8" Content-Disposition: inline In-Reply-To: <20120614170623.GD2337@deviant.kiev.zoral.com.ua> 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:34:12 -0000 --c2qmoHupxsh34lk8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2012 at 08:06:23PM +0300, Konstantin Belousov wrote: > 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+= 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,..= .) > > >>at i915_gem_pwrite_ioctl+0x4b > > >>drm_ioctl(c97e0400,8020645d,ca827120,3,ca85c8a0,...) at drm_ioctl+0x2= d8 > > >>devfs_ioctl_f(c91cb850,8020645d,ca827120,c91b5e80,ca85c8a0,...) at > > >>devfs_ioctl_f+0x10a > > >>kern_ioctl(ca85c8a0,4,8020645d,ca827120,a62ccc,...) at kern_ioctl+0x2= a0 > > >>sys_ioctl(ca85c8a0,efa62ccc,c67c4c80,293d3b4e,1,...) at sys_ioctl+0x1= 34 > > >>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 defini= tely > > >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 an= d=20 > > performance is an important topic. > > It's quite strange what are you saying about KVA fragmentation, the loa= d=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. >=20 > Please apply the debugging patch from the end of message, and show > me the panic message after. >=20 > >=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... >=20 > I am sure that i915 does not work with PAE, probably not even compiles. >=20 > 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, in= t 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); Hm, I think I see an issue that could be very well the cause of the trouble. Please also apply the patch below. diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c index ca531fb..73c0b53 100644 --- a/sys/dev/drm2/i915/i915_gem.c +++ b/sys/dev/drm2/i915/i915_gem.c @@ -1064,7 +1064,7 @@ i915_gem_gtt_write(struct drm_device *dev, struct drm= _i915_gem_object *obj, IDX_TO_OFF(obj_pi), size, PAT_WRITE_COMBINING); ret =3D -copyin_nofault((void *)(uintptr_t)data_ptr, (char *)mkva + obj_po, size); - pmap_unmapdev(mkva, PAGE_SIZE); + pmap_unmapdev(mkva, size); return (ret); } =20 --c2qmoHupxsh34lk8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/aIIwACgkQC3+MBN1Mb4inugCggMYsUst2EOSXwIgxCEyYUgVX 7fUAnRBbLknGA8HW52HEDXeCozq+ECE3 =TrPw -----END PGP SIGNATURE----- --c2qmoHupxsh34lk8--