64-bit paddr_t and mmap()?

[Garrett D'Amore]

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.tadpolecomputer.com/
Phone: [phone]  Fax: [phone]

[Matt Thomas]

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: matt@...
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.

[Garrett D'Amore]

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.tadpolecomputer.com/
Phone: [phone]  Fax: [phone]

[matthew green]

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