64-bit paddr_t and mmap()?

I'm trying to mmap a framebuffer device under evbmips,
using a 64-bit
paddr_t.   (Alchemy PCI space is located in the upper
portion of the
36-bit MIPS physical address space.)

Anyway, the mmap works fine.  I'm able to draw a picture on
screen.

But when the application exits (and hence does an implicit
munmap()), I
get a panic in pmap_remove_pv, called from pmap_remove,
where it looks
like a NULL "pg" pointer is being passed.

I'm curious if anyone else has used 64-bit paddr_t's and
mmap(), e.g. on
ARC.  I'm wondering if maybe I'm trying to do something
new, or if there
is some known fault, or if it is known to work on other
platforms.  Any
info that might help me restrict where I am looking would be
useful to
me.  

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecom
puter.com/
Phone: 951 325-2134  Fax: 951 325-2191

Garrett D'Amore wrote:
> I'm trying to mmap a framebuffer device under evbmips,
using a 64-bit
> paddr_t.   (Alchemy PCI space is located in the upper
portion of the
> 36-bit MIPS physical address space.)
> 
> Anyway, the mmap works fine.  I'm able to draw a
picture on screen.
> 
> But when the application exits (and hence does an
implicit munmap()), I
> get a panic in pmap_remove_pv, called from pmap_remove,
where it looks
> like a NULL "pg" pointer is being passed.

That sounds like a bug in the pmap.  Not all mapped pages
will have a
corresponding uvm_page (because of being able to map pages
outside of
uvm managed memory).  In that case, you just reap the PV
entry.

See line 1749 in powerpc/oea/pmap.c for instance.
-- 
Matt Thomas                     email: matt3am-software.com
3am Software Foundry              www: http://3am-software
.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge
of this message.

Matt Thomas wrote:
> Garrett D'Amore wrote:
>> I'm trying to mmap a framebuffer device under
evbmips, using a 64-bit
>> paddr_t.   (Alchemy PCI space is located in the
upper portion of the
>> 36-bit MIPS physical address space.)
>>
>> Anyway, the mmap works fine.  I'm able to draw a
picture on screen.
>>
>> But when the application exits (and hence does an
implicit munmap()), I
>> get a panic in pmap_remove_pv, called from
pmap_remove, where it looks
>> like a NULL "pg" pointer is being
passed.
>
> That sounds like a bug in the pmap.  Not all mapped
pages will have a
> corresponding uvm_page (because of being able to map
pages outside of
> uvm managed memory).  In that case, you just reap the
PV entry.
>
> See line 1749 in powerpc/oea/pmap.c for instance.

Yep.  I've posted a diff that I think fixes it and
send-pr'd it.  Still
waiting for the bug number to come back to me.  

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecom
puter.com/
Phone: 951 325-2134  Fax: 951 325-2191

FWIW, we use 64 bit paddr_t on sparc64, regardless of word
size.
(this might be true on sparc, too..?)