Hi,

One of our developers is working on a new omap dev board and running
into problems with pmap issues.  He asked the following questions, and
I'm afraid I don't know the answers. Any help is most welcome.

He is seeing a pmap panic periodically:

pmap_zero_page: page xxxx has mappings.

Preliminary investigation involved utilizing uvm_hist and indicated a
physical page first has a managed mappping.  It then got an anonymous
mapping.  The anonymous mapping was later removed, and the physical
page was placed on the free queue.  Later, the page is selected from
uvm_pagealloc_strat, and pmap_zero_page is called, resulting in the
panic.

Secondary investigation involved trying to add a panic where the
page is actually placed on the free queue.  The comments for the
function uvm_pagefree states that it assumes all valid mappings of pg
are gone.  I created a pmap_has_mappings() function which basically
returns nonzero if (vm_page*)pg->mdpage.pvh_list != NULL.  This causes
a panic just starting up /etc/init   

I found that uvm_km_free() for instance, orders the function calls as
such:

                uvm_km_pgremove(addr, addr + size);
                pmap_remove(pmap_kernel(), addr, addr + size);


Therefore, my testing in uvm_pagefree is done prior to pmap removing
the managed mapping.  Is there a reason for the above ordering?

For testing purposes, I've reversed the order, and I get further
along, but eventually hit a similar problem in uvm_page_unbusy().  I'm
working around this, now.  

I'm not sure if any locks are acquired by uvm_km_free() and I'm
wondering if there may be a locking hole somewhere where a physical
page may be placed on the free list before its pmap layer mapping is
removed.  Has anyone encountered such problems before?