From owner-freebsd-x11@FreeBSD.ORG Wed Jun 13 18:48:53 2012 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E99311065677 for ; Wed, 13 Jun 2012 18:48:52 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 74A868FC12 for ; Wed, 13 Jun 2012 18:48:52 +0000 (UTC) Received: by werg1 with SMTP id g1so896883wer.13 for ; Wed, 13 Jun 2012 11:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a+ibh4tkcOtlsIetYIyZw4w/ujj2sMN2A+lz+iRI8Es=; b=hMAV+xL/pPCz5+wzQcYmIBeeb5VGMIZUXDipgPM5dqGVaQ2PudXvyh+TGpKzYvv8Rs cwXSrD39m1Rloh0WDK6qgVzg9fwXXahBBb+AQIIKLCZhcYuicNIthojsy7AQy2a6TQ39 wdQ8F5eU4UUDgJuFgmn41NYEvdsznpD/gDBEJRARICR7Kgw01dUlXNHnLPdkRtWkDQuu 2bQa0iL98Tthf5k9d3MRCX6qyCtqxkxpZflcT/mcmk2dt1MQFQYyqd026euZ4wsGGIxd B7gfaI7tj36MKD5Czq4wOl2WlP//3yzsPhpke1lIUuWG9yjxot/S9FgoRrePv4NSTvhp V5Pw== MIME-Version: 1.0 Received: by 10.180.109.197 with SMTP id hu5mr39960490wib.8.1339613331285; Wed, 13 Jun 2012 11:48:51 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Wed, 13 Jun 2012 11:48:51 -0700 (PDT) In-Reply-To: <20120613112601.GS2337@deviant.kiev.zoral.com.ua> References: <4FD86E13.6090202@bally-wulff.de> <20120613112601.GS2337@deviant.kiev.zoral.com.ua> Date: Wed, 13 Jun 2012 11:48:51 -0700 Message-ID: From: Kevin Oberman To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: x11@freebsd.org Subject: Re: Intel KMS: a memory problem X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:48:53 -0000 On Wed, Jun 13, 2012 at 4:26 AM, 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. ??? I have read in several places that, for cases where large amounts of memory are not required, that i386 would run faster (and use less memory) than amd64 on the same hardware. Wee those reports incorrect for FreeBSD? (All were for Windows, of course.) -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com