Date: Thu, 21 Jun 2012 03:47:35 +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: <20120621034735.4d40caca@x12.dk> In-Reply-To: <20120614170623.GD2337@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Konstantin and list,
Sorry for the top post, but this is another thing i've watched both
before and after the patch below.
ctrl+alt+F1 -> odd colored screen, not a CLI.
then a few seconds later
alt+F9 back to working GUI.
This is the /var/log/messages from this activity:
Jun 21 03:41:36 raido kernel: [drm:KMS:pid0:intel_crt_detect] CRT not
detected via hotplug Jun 21 03:41:36 raido kernel:
[drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status updated
from 2 to 2 Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:drm_mode_setcrtc] [CRTC:4] Jun 21 03:41:43 raido
kernel: [drm:KMS:pid1647:drm_mode_setcrtc] [CONNECTOR:5:LVDS-1] Jun 21
03:41:43 raido kernel: [drm:KMS:pid1647:drm_crtc_helper_set_config] Jun
21 03:41:43 raido kernel: [drm:KMS:pid1647:drm_crtc_helper_set_config]
[CRTC:4] [FB:15] #connectors=1 (x y) (0 0) Jun 21 03:41:43 raido
kernel: [drm:KMS:pid1647:drm_crtc_helper_set_config]
[CONNECTOR:5:LVDS-1] to [CRTC:4] Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:drm_mode_getconnector] [CONNECTOR:5:?] Jun 21 03:41:43
raido kernel: [drm:KMS:pid1647:drm_helper_probe_single_connector_modes]
[CONNECTOR:5:LVDS-1] Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:drm_helper_probe_single_connector_modes]
[CONNECTOR:5:LVDS-1] probed modes : Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:drm_mode_debug_printmodeline] Modeline 13:"1024x600"
60 54200 1024 1133 1205 1386 600 607 620 652 0x48 0xa Jun 21 03:41:43
raido kernel: [drm:KMS:pid1647:drm_mode_getconnector] [CONNECTOR:5:?]
Jun 21 03:41:43 raido kernel: [drm:KMS:pid1647:drm_mode_getconnector]
[CONNECTOR:11:?] Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:drm_helper_probe_single_connector_modes]
[CONNECTOR:11:VGA-1] Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:intel_crt_detect] CRT not detected via hotplug Jun 21
03:41:43 raido kernel:
[drm:KMS:pid1647:drm_helper_probe_single_connector_modes]
[CONNECTOR:11:VGA-1] disconnected Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:drm_mode_getconnector] [CONNECTOR:11:?] Jun 21
03:41:43 raido kernel:
[drm:KMS:pid1647:drm_helper_probe_single_connector_modes]
[CONNECTOR:11:VGA-1] Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:intel_crt_detect] CRT not detected via hotplug Jun 21
03:41:43 raido kernel:
[drm:KMS:pid1647:drm_helper_probe_single_connector_modes]
[CONNECTOR:11:VGA-1] disconnected Jun 21 03:41:43 raido kernel:
[drm:KMS:pid1647:intel_crtc_cursor_set] Jun 21 03:41:53 raido kernel:
[drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug Jun 21
03:41:53 raido kernel: [drm:KMS:pid0:output_poll_execute]
[CONNECTOR:11:VGA-1] status updated from 2 to 2 Jun 21 03:41:57 raido
kernel: [drm:KMS:pid1647:intel_crtc_cursor_set] Jun 21 03:41:57 raido
kernel: [drm:KMS:pid1647:intel_crtc_cursor_set] cursor off
Looking forward for things to tryout.
/Soeren
On Thu, 14 Jun 2012 20:06:23 +0300
Konstantin Belousov <kostikbel@gmail.com> 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);
--
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?20120621034735.4d40caca>