Why doesn't pv_unlink4m() simply return when pv_pmap == NULL?
Nearly all its counterparts do.

Why isn't "pv_va" a "vm_offset_t" (unsigned long) instead of an "int"?
Most other ports appear to have it defined this way.


I've got more code reading to do, but my impression is as follows:

1. the pv_table stuff is a software-only table of pages that have mappings,
possibly multiple mappings, hence the singly linked list, and the pmap
structure pointers.

2. the kernel portion of the pv_table is probably not properly initialized
since the kernel page tables are hand-built in the first place in
pmap_bootstrap() and pmap_init() (when I dumped the entire 24,000 entry
table after a recent crash, fully 60% of the entries had virtual addresses,
but no pmap pointer).

3. when pmap_enk4m() goes down to rewire things for a new (or perhaps
reusing a freed allocation that was previously used) kernel malloc, panic
in pv_unlink4m() because the pv_table is not quite set up right for the
kernel (i.e. pv_pmap == NULL). Boom.

Thanks for any insight that can be provided,

	Erik