Intel KMS: a memory problem

Cy Schubert Cy.Schubert at komquats.com
Mon Jun 18 04:23:03 UTC 2012 

No hang but artifacts. Not sure how to debug this or provide more info.


-- 
Cheers,
Cy Schubert <Cy.Schubert at komquats.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   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 <Cy.Schubert at komquats.com>
> FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org
> 
> 
> 
> In message <4FDB114F.70606 at 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 at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> > To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
> > 
> > 
> 
>

More information about the freebsd-x11 mailing list