Intel KMS: a memory problem

[Konstantin Belousov]

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.
-------------- 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/20120613/0fe96f8b/attachment.pgp