DragonFly BSD
DragonFly bugs List (threaded) for 2005-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: page fault on 1.2.0-RELEASE


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 12 Jun 2005 22:17:01 -0700 (PDT)

: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




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]