From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc MERLIN Subject: Re: More crashes with intel driver 1.10.4 and corrupted stack traces for GM45 Date: Tue, 13 Dec 2011 19:05:34 -0800 Message-ID: <20111214030534.GA411@merlins.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail1.merlins.org (magic.merlins.org [209.81.13.136]) by gabe.freedesktop.org (Postfix) with ESMTP id 079E39E9E3 for ; Tue, 13 Dec 2011 19:05:37 -0800 (PST) Content-Disposition: inline In-Reply-To: <20111213230402.GC18675@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter , Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, Dec 14, 2011 at 12:04:03AM +0100, Daniel Vetter wrote: > > > One of my X logs had some of these: > > > [1535818.200] (WW) intel(0): intel_uxa_prepare_access: bo map failed: No space left on device > > > [1535818.208] (WW) intel(0): intel_uxa_prepare_access: bo map failed: No space left on device > > > [1535818.208] (WW) intel(0): intel_uxa_prepare_access: bo map failed: No space left on device > > This one sounds like a vma exhausting issue Chris Wilson recently fixed. > Please retest with the latest versions of xf86-video-intel and libdrm from > git. On Tue, Dec 13, 2011 at 11:16:17PM +0000, Chris Wilson wrote: > On Tue, 13 Dec 2011 14:13:18 -0800, Marc MERLIN wrote: > > On Sun, Dec 11, 2011 at 12:32:00PM -0800, Marc MERLIN wrote: > > > Hi Eugeni and other folks on this list, > > > > Am I sending this to the wrong place or is GM45 unsupported? > > Apologies, it is a known issue. I was thrown by the bizarre stack trace, > but it seems like it just the mmap failure blowing up in spectacular > fashion. The ENOSPC issues arises from when we have either exhausted > or badly fragmented the (on your system presumably) 32-bits of address > space for GTT mappings such that we are no longer able to allocate new > ones. I have recently begun to take a similar issue whereby we exhausted > the per-process map limit with over 65,000 vma keep open. The solution > there of capping the number of cached vma is likely to resolve this > problem as well. Since I'm a newbie at thie, there isn't a 'head' per se, and I see that not all patches are production ready. Could you point me on what I could sync from and that would be reasonably likely to work? :) Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/