page fault on 1.2.0-RELEASE
Matthew Dillon
dillon at apollo.backplane.com
Sun Jun 12 22:18:44 PDT 2005
:I'm trying to install 1.2.0-RELEASE on a new x86 system (4-way Xeon
:based machine) but am getting a page fault very early during the boot
:of the kernel. Below is the output via comconsole with
:boot_verbose=yes (also, any idea why trace is showing (null) instead
:of the stack entries?).
:
:I tried both disabling ACPI and 'safe mode' but neither worked.
:FreeBSD 4.11 installs and boots ok (as did DF 1.0a if I recall
:correctly). a dmesg from 4.11 is here
:http://www.tuffli.net/ripper.dmesg
Here is a translation of the backtrace using symbols from the
release kernel:
(null)(44,1,0,c04ed420,c04ed2a0) at 0xc0259a55 lockmgr
(null)(c0694c10,c081b000,2,c0694c14,c0694c08) at 0xc039b961 vm_map_lookup
(null)(0,c081b000,2,0,c) at 0xc03959d6 vm_fault
(null)(c0694cc4,0,c081b00c,ffffffff,0) at 0xc04103de trap_pfault
(null)(18,10,c0810010,c081aff0,0) at 0xc0410088 trap
(null)(3d000,0,c0512fc0,c04c5d48,69f000) at 0xc03ff67b calltrap
(null)(69f000,3fbf8000,c081a000,c0694d98,c0249b18) at 0xc039f967
vm_page_startup
(null)(0,691c00,69f000,0,c013c18c) at 0xc039750b vm_mem_init
(null)(691000,0,0,0,0) at 0xc0249b18 mi_sartup
(null)() at 0xc013c18c begin
It looks like it is dying in vm_page_startup(), just at the point
where it calls vm_add_new_page() (not sure why vm_add_new_page() isn't
in the stack backtrace, but that is where the PC address is).
The panic itself is occuring when the kernel traps due to a VM fault
too early and so the panic message itself has nothing to do with the
actual failure.
I don't see why it would be dying right off hand. The SMAP entries
look ok:
SMAP type=01 base=00000000 00000000 len=00000000 0009fc00
SMAP type=01 base=00000000 00100000 len=00000000 3f95f000
SMAP type=01 base=00000000 3fa86000 len=00000000 0003c000
SMAP type=01 base=00000000 3fb06000 len=00000000 0000e000
SMAP type=01 base=00000000 3fb26000 len=00000000 000da000
It looks like some sort of page fault, which would imply that it
is accessing memory that hasn't been mapped into the page tables yet.
Would you like to do some debugging with the 1.2.0-RELEASE kernel
sources? It should be possible to figure out what is going on by
adding printf()s in vm_page_startup() and vm_add_new_page(). I
would print out e.g. first_page, page_range, npages, end,
vm_page_array, new_end, and the 'mapped' variable. I would print
all those out after it calls pmap_map().
I would also print out the phys_avail[i] and phys_avail[i+1] inside
the for (...) loop under the 'Construct the free queues' comment,
and the 'ps' and 'last_pa' variables just before the inner while()
loop.
-Matt
More information about the Bugs
mailing list