From owner-freebsd-x11@FreeBSD.ORG Fri Jun 15 10:41:45 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 2B57F106566B for ; Fri, 15 Jun 2012 10:41:45 +0000 (UTC) (envelope-from l.pizzamiglio@bally-wulff.de) Received: from mail.bally-wulff.de (mail.bally-wulff.de [212.144.118.8]) by mx1.freebsd.org (Postfix) with ESMTP id AFAC28FC12 for ; Fri, 15 Jun 2012 10:41:44 +0000 (UTC) Received: from bwex.bally-wulff.de (unknown [192.168.204.106]) by mail.bally-wulff.de (Postfix) with ESMTP id 65FB64096; Fri, 15 Jun 2012 12:41:37 +0200 (CEST) Received: from pizzamig.bally.de ([192.9.205.30]) by bwex.bally-wulff.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jun 2012 12:41:19 +0200 Message-ID: <4FDB114F.70606@bally-wulff.de> Date: Fri, 15 Jun 2012 12:41:19 +0200 From: Luca Pizzamiglio User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: Konstantin Belousov 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> In-Reply-To: <20120614173404.GE2337@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2012 10:41:19.0011 (UTC) FILETIME=[65D51F30:01CD4AE3] Cc: x11@freebsd.org, Soeren Straarup 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 10:41:45 -0000 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 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); > } > >