From owner-freebsd-x11@FreeBSD.ORG Mon Jun 18 04:23:03 2012 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A24401065670 for ; Mon, 18 Jun 2012 04:23:03 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-04.shaw.ca (smtp-out-04.shaw.ca [64.59.134.12]) by mx1.freebsd.org (Postfix) with ESMTP id 53F788FC0C for ; Mon, 18 Jun 2012 04:23:03 +0000 (UTC) Received: from lb7f8hsrpno-svcs.dcs.int.inet (HELO pd7ml3no-ssvc.prod.shaw.ca) ([10.0.144.222]) by pd5mo1no-svcs.prod.shaw.ca with ESMTP; 17 Jun 2012 22:22:58 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=aDUJ/pRHNXkohnfhaDKKve0FfU8uPxX8npdo6G126bI= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=5nhAaST1bdhC7ZQVj88A:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=Cbw8TXLC14YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by pd7ml3no-dmz.prod.shaw.ca with ESMTP; 17 Jun 2012 22:22:57 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id E930480; Sun, 17 Jun 2012 21:22:56 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.5/8.14.5) with ESMTP id q5I4MwHW017942; Sun, 17 Jun 2012 21:22:58 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201206180422.q5I4MwHW017942@slippy.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Cy Schubert In-Reply-To: Message from Cy Schubert of "Sat, 16 Jun 2012 10:11:52 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jun 2012 21:22:58 -0700 Cc: Soeren Straarup , x11@freebsd.org Subject: Re: Intel KMS: a memory problem X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 04:23:03 -0000 No hang but artifacts. Not sure how to debug this or provide more info. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org Cy Schubert writes: > It appears to have fixed my hang as well. To test I'd run find / in a > gnome-terminal and wait for up to a minute. It used to hand hard. Playing a > video would result in the same. All that's working now. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > In message <4FDB114F.70606@bally-wulff.de>, Luca Pizzamiglio writes: > > 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 > > > > > > 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 SandyBridg > e > > >>>>> 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+0x3 > a > > >>>>> 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+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 = 0x293d5b93, esp = > > >>>>> 0xbfbf7f4c, ebp = 0xbfbf7f68 --- > > >>>>> > > >>>>> I tried to increase vm.kmem_size and vm.kmem_size_max to 512M, but th > e > > >>>>> 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 hav > e > > >>>> 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 > te > > ly > > >>>> 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 an > d > > >>> performance is an important topic. > > >>> It's quite strange what are you saying about KVA fragmentation, the loa > d > > >>> 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, i > nt > > mode) > > >> va = KERNBASE + pa; > > >> else > > >> va = kmem_alloc_nofault(kernel_map, size); > > >> - if (!va) > > >> - panic("pmap_mapdev: Couldn't alloc kernel virtual memor > y"); > > >> + if (va == 0) { > > >> + panic("pmap_mapdev: Couldn't alloc kernel virtual memor > y, " > > >> + "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 d > rm > > _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); > > > } > > > > > > > > > > > > _______________________________________________ > > freebsd-x11@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > > > > > >