Date: Fri, 15 Jun 2012 15:01:06 +0200 From: Soeren Straarup <xride@x12.dk> To: Konstantin Belousov <kostikbel@gmail.com> Cc: x11@freebsd.org Subject: Re: Intel KMS: a memory problem Message-ID: <20120615150106.7853bac1@x12.dk> In-Reply-To: <4FDB114F.70606@bally-wulff.de> 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> <4FDB114F.70606@bally-wulff.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Konstantin and rest,
On Fri, 15 Jun 2012 12:41:19 +0200
Luca Pizzamiglio <l.pizzamiglio@bally-wulff.de> wrote:
> 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
>
Same here, though i have not tried as i don't know what did trigger it.
But i have not experienced any panics since i added the two patches
this morning (~8h ago), yesterday they came quite earlier.
Thanks
>
> 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);
> > }
> >
> >
>
>
/Soeren
--
Soeren Straarup | aka OZ2DAK aka Xride
FreeBSD committer | FreeBSD since 2.2.6-R
If a program is not working right, then send a patch
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120615150106.7853bac1>