Intel KMS: a memory problem

Konstantin Belousov kostikbel at gmail.com
Thu Jun 14 17:06:35 UTC 2012


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);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20120614/72645daf/attachment.pgp


More information about the freebsd-x11 mailing list