Date: Wed, 11 Dec 1996 04:49:01 +0100 From: Tor Egge <Tor.Egge@idt.ntnu.no> To: peter@spinner.dialix.com Cc: smp@bluenose.na.tuns.ca, smp@freebsd.org Subject: Re: More info about fatal trap 12 Message-ID: <199612110349.EAA00310@pat.idt.unit.no> In-Reply-To: Your message of "Sat, 07 Dec 1996 02:15:12 %2B0800" References: <199612061815.CAA19205@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> Tor Egge wrote:
> > A closer examination of the kernel dump shows that the first page fault
> > is from the user process /bin/sh. The call stack is
> [..]
> > The first access to the stack by the child process failed when trying
> > to save the return value from fork.
> >
> > The parent process was running on CPU #1, and the child process
> > was running on CPU #0.
> >
> > - Tor Egge
>
> Hmm!! The plot thickens! I noticed the failing pmap_enter was at
> 0xefbfd000 which is the first stack page already, but I wasn't sure
> if it was the initial creation, or if the stack had been paged out
> and was failing on pagein.
I applied the following diff to pmap.c
Index: pmap.c
===================================================================
RCS file: /export/akg1/smp-cvs/sys/i386/i386/pmap.c,v
retrieving revision 1.31
diff -c -r1.31 pmap.c
*** pmap.c 1996/12/03 05:51:12 1.31
--- pmap.c 1996/12/11 00:48:46
***************
*** 1982,1987 ****
--- 1982,1991 ----
vm_offset_t opa;
vm_offset_t origpte, newpte;
vm_page_t mpte;
+ volatile u_long old_cr3;
+ volatile u_long old_frame;
+ volatile u_long old_PTDpde;
+ volatile int old_cpunum;
if (pmap == NULL)
return;
***************
*** 2011,2016 ****
--- 2015,2024 ----
pmap->pm_pdir[PTDPTDI], va);
}
+ old_cr3 = rcr3();
+ old_frame = pmap->pm_pdir[PTDPTDI];
+ old_PTDpde = PTDpde;
+ old_cpunum = cpunumber();
origpte = *(vm_offset_t *)pte;
pa &= PG_FRAME;
opa = origpte & PG_FRAME;
------------
Afterwards, when looking at the kernel stack trace:
----
#0 boot (howto=256) at ../../kern/kern_shutdown.c:264
#1 0xe0112d69 in panic (fmt=0xe01bcd7f "page fault")
at ../../kern/kern_shutdown.c:392
#2 0xe01bda65 in trap_fatal (frame=0xdfbffe4c) at ../../i386/i386/trap.c:747
#3 0xe01bd498 in trap_pfault (frame=0xdfbffe4c, usermode=0)
at ../../i386/i386/trap.c:654
#4 0xe01bd0cb in trap (frame={tf_es = -453967856, tf_ds = 16,
tf_edi = -533289196, tf_esi = -541077504, tf_ebp = -541065552,
tf_isp = -541065612, tf_ebx = 86614016, tf_edx = -4194304,
tf_ecx = -528396, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -535058445, tf_cs = 8, tf_eflags = 66050, tf_esp = -533683197,
tf_ss = -453959040}) at ../../i386/i386/trap.c:313
#5 0xe01ba7f3 in pmap_enter (pmap=0xe4ee0f64, va=3753889792, pa=86614016,
prot=7 '\a', wired=0) at ../../i386/i386/pmap.c:2022
#6 0xe01a41b3 in vm_fault (map=0xe4ee0f00, vaddr=3753889792,
fault_type=3 '\003', change_wiring=0) at ../../vm/vm_fault.c:773
#7 0xe01bd3f0 in trap_pfault (frame=0xdfbfffbc, usermode=1)
at ../../i386/i386/trap.c:634
#8 0xe01bcf73 in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = 352256,
tf_esi = 331156, tf_ebp = -541075036, tf_isp = -541065244, tf_ebx = 2,
tf_edx = 1, tf_ecx = -541075000, tf_eax = 0, tf_trapno = 12, tf_err = 7,
tf_eip = 45296, tf_cs = 31, tf_eflags = 66050, tf_esp = -541075060,
tf_ss = 39}) at ../../i386/i386/trap.c:241
#9 0xb0f0 in ?? ()
#10 0x63ab in ?? ()
#11 0x5ef0 in ?? ()
#12 0x7d01 in ?? ()
#13 0x7984 in ?? ()
#14 0x7754 in ?? ()
#15 0x60eb in ?? ()
#16 0x58e1 in ?? ()
#17 0xc11f in ?? ()
#18 0xc02e in ?? ()
#19 0x107e in ?? ()
(kgdb) up 5
#5 0xe01ba7f3 in pmap_enter (pmap=0xe4ee0f64, va=3753889792, pa=86614016,
prot=7 '\a', wired=0) at ../../i386/i386/pmap.c:2022
(kgdb) info locals
va = 3753889792
pa = 86614016
prot = 7 '\a'
pte = (unsigned int *) 0xfff7eff4
opa = 0
origpte = 3761678100
newpte = 0
mpte = (struct vm_page *) 0xe035f7c8
old_cr3 = 85966848
old_frame = 0
old_PTDpde = 85966883
old_cpunum = 0
(kgdb) print/x pmap->pm_pdir[0x37f]
$20 = 0x51fc023
----
This indicates that cr3 was correct, PTDpde was correct, but
pmap->pm_pdir[PTDPTDI] evaluated to 0. This triggered the use of the
alternate page table memory area.
Later on, during the post mortem investigation, pmap->pm_pdir[PTDPTDI]
evaluates to the correct value.
- Tor Egge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612110349.EAA00310>