Date: Fri, 15 Jun 2012 12:41:19 +0200 From: Luca Pizzamiglio <l.pizzamiglio@bally-wulff.de> To: Konstantin Belousov <kostikbel@gmail.com> Cc: x11@freebsd.org, Soeren Straarup <xride@x12.dk> Subject: Re: Intel KMS: a memory problem Message-ID: <4FDB114F.70606@bally-wulff.de> In-Reply-To: <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> <20120614173404.GE2337@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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);
> }
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FDB114F.70606>