From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754006AbZA3Ina (ORCPT ); Fri, 30 Jan 2009 03:43:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752464AbZA3InB (ORCPT ); Fri, 30 Jan 2009 03:43:01 -0500 Received: from mail-ew0-f21.google.com ([209.85.219.21]:46385 "EHLO mail-ew0-f21.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752182AbZA3Im7 (ORCPT ); Fri, 30 Jan 2009 03:42:59 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EhAFKPVcxLn35o81mWoSRHlhwwTTtIfhctaHEvZs8Jg4ZeHj8H4T+zyXTPjybGlCbK Sjb6Q3kmTF5uVxN0eInhqfpgoTHocQ3mK3uh4x/3p/oj93XRRlzW37c89XN8II7HBhO+ rc1OvEMz9hPldfGI6jqXDqpdbjqE/QTtK7GxE= MIME-Version: 1.0 Reply-To: kerolasa@gmail.com In-Reply-To: <20090129204403.5d9e4b38.akpm@linux-foundation.org> References: <20090129172010.f25fe0ad.akpm@linux-foundation.org> <21d7e9970901291743q4f0a9393yc5c24afb50013ff3@mail.gmail.com> <200901291950.18724.jbarnes@virtuousgeek.org> <20090129204403.5d9e4b38.akpm@linux-foundation.org> Date: Fri, 30 Jan 2009 09:42:57 +0100 X-Google-Sender-Auth: d9e8a293e6262b42 Message-ID: Subject: Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146! From: Sami Kerola To: Andrew Morton Cc: Jesse Barnes , Dave Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.sourceforge.net, Dave Airlie , Laurent Pinchart , Hugh Dickins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 30, 2009 at 05:44, Andrew Morton wrote: > On Thu, 29 Jan 2009 19:50:17 -0800 Jesse Barnes wrote: > >> On Thursday, January 29, 2009 5:43 pm Dave Airlie wrote: >> > On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton >> > > hm, I'm a bit surprised to see the drm code using `struct >> > > address_space' and read_mapping_page() and unmap_mapping_range() and >> > > such. I thought those only worked with regular files and pagecache :) >> > > >> > > Is it possible to briefly explain what's going on there? >> > > >> > > What instance of address_space_operations does ->dev_mapping actually >> > > point at? >> > >> > Okay a bit tired and headache coming on but I'll try, maybe jbarnes >> > can help out, >> > >> > We need to provide mappings to userspace that are backed by memory >> > that can move around behind the mappings. >> > >> > So userspace wants a mapping for a GEM object via the AGP/GTT aperture >> > instead of directly to the backing pages. >> > Now as the GEM object is backed by shmem we can't use the shmem file >> > descriptor we have to tie the mapping to without >> > hacking up the shmem mmap functionality which seemed like a bad plan. >> > >> > So GEM uses the device inode to setup the mappings on. We just use a >> > simple linear allocator to split up the device inodes address space >> > and assign chunks to handles for different objects. The userspace app >> > then uses the handle via mmap to get access to the VMAs. Now when GEM >> > wants to move that object out of the GTT or to another area of the GTT >> > we need some way to invalidate it, so we use unmap_mapping_range >> > which destroys all the mappings for the object in all the VMA for all >> > the processes mapping it currently >> > >> > GEM's read_mapping_page is distinct from this and is to do with the >> > shmem interfaceing. >> > >> > Not sure if this explains it or just make it worse. >> >> Sounds right to me. The offsets are just handles, not real file objects or >> backing store addresses. We use them to take advantage of all the inode >> address mapping helpers, since they track stuff for us. >> >> That said, unmap_mapping_range may not be the best way to do this; basically >> we need a way to invalidate a given processes' mapping of a GTT range (which >> in turn is backed by real RAM). If there's some other way we should be doing >> this I'm all ears. > > Well, we'd need to call in the big guns on this one - I've already > stirred Hugh ;) > > unmap_mapping_range() is basically a truncate thing - it shoots down > all mappings of a range of a *file*. Across all processes in the > machine which map that file. > > If that isn't what you want to do (and it sounds that way) then you'd > want to use something which is mm_struct (or vma) centric, rather than > file-centric. zap_page_range(), methinks. I have never seen this happen with 2.6.28. Last kernel that works without freeze is 2.6.29-rc1-00224. Next one which I compiled was 2.6.29-rc1-00534 and it did not work. I assumed PEBKAC. When the next one I tried 2.6.29-rc2-00013 did the same so I sent a bug report. I don't know does following have anything to do with issue but extra information has never hurt anyone. 1. Kernels which has the problem print 'acpiphp_ibm: ibm_acpiphp_init: acpi_walknamespace failed' before LUKS is started. 2. One out of three reboots fail because LUKS is unable to find partitions. -- Sami Kerola http://www.iki.fi/kerolasa/