Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146!

[Sami Kerola <kerolasa@iki.fi>]

On Fri, Jan 30, 2009 at 05:44, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Jan 2009 19:50:17 -0800 Jesse Barnes <jbarnes@virtuousgeek.org> 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/