Re: page fault in pmap_remove_all

Alan Cox wrote:
 > On Tue, Aug 10, 2010 at 9:43 AM, Oliver Fromme <olli_at_lurza.secnetix.de>wrote:
 > 
 > > Hi,
 > > 
 > > This is i386 -current as of 2010-08-04.
 > > It was building the toolchain for amd64 when it happened.
 > > I'll keep the vmcore around, so I can dig more into it
 > > if someone tells me what to do.
 > > 
 > > GNU gdb 6.1.1 [FreeBSD]
 > > Copyright 2004 Free Software Foundation, Inc.
 > > GDB is free software, covered by the GNU General Public License, and you
 > > are
 > > welcome to change it and/or distribute copies of it under certain
 > > conditions.
 > > Type "show copying" to see the conditions.
 > > There is absolutely no warranty for GDB.  Type "show warranty" for details.
 > > This GDB was configured as "i386-marcel-freebsd"...
 > > 
 > > Unread portion of the kernel message buffer:
 > > 
 > > 
 > > Fatal trap 12: page fault while in kernel mode
 > > fault virtual address   = 0x0
 > > fault code              = supervisor write, page not present
 > > instruction pointer     = 0x20:0xc083bc86
 > > stack pointer           = 0x28:0xe50a1a94
 > > frame pointer           = 0x28:0xe50a1ac4
 > > code segment            = base 0x0, limit 0xfffff, type 0x1b
 > >                        = DPL 0, pres 1, def32 1, gran 1
 > > processor eflags        = interrupt enabled, resume, IOPL = 0
 > > current process         = 5785 (install)
 > > trap number             = 12
 > > panic: page fault
 > > Uptime: 6h13m9s
 > > Physical memory: 951 MB
 > > Dumping 182 MB: 167 151 135 119 103 87 71 55 39 23 7
 > > 
 > > #0  doadump () at pcpu.h:231
 > > 231             __asm("movl %%fs:0,%0" : "=r" (td));
 > > (kgdb) list *0xc083bc86
 > > 0xc083bc86 is in pmap_remove_all (atomic.h:318).
 > > 313     atomic_readandclear_int(volatile u_int *addr)
 > > 314     {
 > > 315             u_int res;
 > > 316
 > > 317             res = 0;
 > > 318             __asm __volatile(
 > > 319             "       xchgl   %1,%0 ;         "
 > > 320             "# atomic_readandclear_int"
 > > 321             : "+r" (res),                   /* 0 */
 > > 322               "=m" (*addr)                  /* 1 */
 > > (kgdb) backtrace
 > > #0  doadump () at pcpu.h:231
 > > #1  0xc05daef0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
 > > #2  0xc05db11d in panic (fmt=Variable "fmt" is not available.
 > > ) at /usr/src/sys/kern/kern_shutdown.c:590
 > > #3  0xc0840583 in trap_fatal (frame=0xe50a1a54, eva=0)
 > >    at /usr/src/sys/i386/i386/trap.c:945
 > > #4  0xc08407d0 in trap_pfault (frame=0xe50a1a54, usermode=0, eva=0)
 > >    at /usr/src/sys/i386/i386/trap.c:858
 > > #5  0xc0840cf3 in trap (frame=0xe50a1a54) at
 > > /usr/src/sys/i386/i386/trap.c:533
 > > #6  0xc082ce2c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
 > > #7  0xc083bc86 in pmap_remove_all (m=0xc150e9e8) at atomic.h:318
 > > #8  0xc07e9544 in vm_fault (map=0xc38463c0, vaddr=684290048,
 > >    fault_type=1 '\001', fault_flags=Variable "fault_flags" is not
 > > available.
 > > ) at /usr/src/sys/vm/vm_fault.c:499
 > > #9  0xc08406c0 in trap_pfault (frame=0xe50a1d28, usermode=1, eva=684290048)
 > >    at /usr/src/sys/i386/i386/trap.c:837
 > > #10 0xc0840b5e in trap (frame=0xe50a1d28) at
 > > /usr/src/sys/i386/i386/trap.c:399
 > > #11 0xc082ce2c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
 > > #12 0x0804858c in ?? ()
 > > Previous frame inner to this frame (corrupt stack?)
 > > (kgdb)
 > > 
 > > 
 > If at all possible, I would like to know the value of "pv->pv_va" in
 > pmap_remove_all().

Sure.

(kgdb) print /x pv->pv_va
$1 = 0x28c89000


Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'