From owner-freebsd-x11@FreeBSD.ORG Fri Jun 15 13:01:14 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 109CD1065676 for ; Fri, 15 Jun 2012 13:01:14 +0000 (UTC) (envelope-from xride@x12.dk) Received: from gebo.x12.dk (gebo.x12.dk [204.109.63.178]) by mx1.freebsd.org (Postfix) with ESMTP id DA50C8FC0A for ; Fri, 15 Jun 2012 13:01:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gebo.x12.dk (8.14.3/8.14.3) with ESMTP id q5FD1G1U007893; Fri, 15 Jun 2012 13:01:17 GMT (envelope-from xride@x12.dk) Date: Fri, 15 Jun 2012 15:01:06 +0200 From: Soeren Straarup To: Konstantin Belousov Message-ID: <20120615150106.7853bac1@x12.dk> In-Reply-To: <4FDB114F.70606@bally-wulff.de> 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> <20120614173404.GE2337@deviant.kiev.zoral.com.ua> <4FDB114F.70606@bally-wulff.de> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd9.0) X-Face: 7Y!o?/XT:H%BE>uVwW9m14t\pR.ZF]T!3s$d_`Gv6TVIknyh$"aMW=:t(r}QL:3W, Ico:Gec Ksmq@nVq-$Ks_33F0L>R[^qp'3-g4eV#nKv/8rl",TY4NTKO&DRL)e(x^6Tn^9".i; oJf-l69YL+>hY- }/$J[OE(pIER<2n`8E_}HLv`tXVvUr^O%#4 Mobil: +4520276244 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Fri, 15 Jun 2012 13:01:14 -0000 Hi Konstantin and rest, On Fri, 15 Jun 2012 12:41:19 +0200 Luca Pizzamiglio wrote: > Hi Konstantin, > > I'm not able to repeat the panic. It seems that you've found the > issue! Thanks a lot, it works great! > > Best regards, > Luca > Same here, though i have not tried as i don't know what did trigger it. But i have not experienced any panics since i added the two patches this morning (~8h ago), yesterday they came quite earlier. Thanks > > On 06/14/12 19:34, Konstantin Belousov wrote: > > 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+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 = 0x293d5b93, esp = 0xbfbf7f4c, > >>>>> ebp = 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 definitely do not > >>>> care about performance. > >>>> > >>> > >>> Hi Konstantin, > >>> Thanks for the quick reply! > >>> yes, maybe I'm the first using 32bit architecture on SandyBridge, > >>> but for some internal conflicts (human ones) I should use 32 bit > >>> version and performance is an important topic. > >>> It's quite strange what are you saying about KVA fragmentation, > >>> the load of the machine is really low < 0.3; test scenario is: > >>> boot, starting X with twm and launching our openGL application.. > >>> after a couple of minutes, it panics. The openGL application draw > >>> a black screen and some lines to show performance indexes, like > >>> CPU percentage usage, time per 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. > >> > >>> > >>> I would like to try PAE extension to address more memory or use > >>> 64 bit world with the 32 bit compatibility layer. PAE extension > >>> is easy to 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 = KERNBASE + pa; > >> else > >> va = kmem_alloc_nofault(kernel_map, size); > >> - if (!va) > >> - panic("pmap_mapdev: Couldn't alloc kernel virtual > >> memory"); > >> + if (va == 0) { > >> + panic("pmap_mapdev: Couldn't alloc kernel virtual > >> memory, " > >> + "size %d", size); > >> + } > >> > >> for (tmpsize = 0; tmpsize < size; tmpsize += 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 = -copyin_nofault((void > > *)(uintptr_t)data_ptr, (char *)mkva + obj_po, size); > > - pmap_unmapdev(mkva, PAGE_SIZE); > > + pmap_unmapdev(mkva, size); > > return (ret); > > } > > > > > > /Soeren -- Soeren Straarup | aka OZ2DAK aka Xride FreeBSD committer | FreeBSD since 2.2.6-R If a program is not working right, then send a patch