Some more new on this:
- Jason's patch doesn't cure completely the problem: I don't get the panic from
  pmap_zero_page, but I got a core-dump from make, and a panic from uvm,
  the stack trace started with a trap #6 and uvm_fault ... a NULL pointer.
  I guess the code had been interrupted and pmap_zero_page called.
- with a kernel compiled from yesterday's evening sources (CVS, about 18h GMT)
  panics where much much harder to get (ran several make clean before getting
  one). Then I noticed my buffer cache was not as big as it used to be
  (with 80Mb RAM, default is about 4Mb, and as I don't do memory-intensive
  tasks, I use a 20Mb cache). I fixed i386/machdep.c, rebuilt a kernel and
  then the panic was here again.

Can pmap_zero_page be called for buffer cache entries, or is it just that a
bigger cache  allows a different interrupt or memory pattern ?

Also, I tried to  reproduce the problem with a C program doing forks/exit.
No luck. It seems related to disk usage. Maybe it's a disk irq that
interrupt the current process and calls pmap_zero_page ?

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--