I looked a bit more at this, and I may have found the problem.
If I understood things properly, pmap_zero_page() is not supposed to be called
with IRQs blocked, and it turns out that it's oftem called with cpl set to 0
(a simple printf/call to Debugger() confirmed this).
But pmap_zero_page() can also be called from the pool allocator: here's a stack
trace I've written by hand (cpl in pmap_zero_page() was set to splhigth, which
is the same as splclock).
pmap_zero_page()
pmap_growkernel()
uvm_map()
uvm_km_kmemalloc()
uvm_kmemalloc_poolpage1()
pool_page_alloc_nointr()
pool_get()

Now a quick look shows that uvm_kmemalloc_poolpage1() calls uvm_km_kmemalloc()
with the NOWAIT/WAITOK flag properly propagated. uvm_km_kmemalloc() will call
uvm_map() with the flags trimmed down to UVM_KMF_TRYLOCK (this means that
we have lost the WAITOK/NOWAIT info). uvm_map() can call pmap_growkernel()
which can calls pmap_zero_page().
pool_get() is called from interrupt context in the scsipi system (there may be
other places too, I didn't look closely at network boards drivers, but they
are suspect as well). This is probably the reason why not much persons have
been hit by this yet.

Comments ? Did I miss somthething ?

--
Manuel Bouyer <bouyer@antioche.eu.org>
--