From owner-freebsd-current Thu Oct 24 8:19:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AE1837B401 for ; Thu, 24 Oct 2002 08:19:18 -0700 (PDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7BA343E75 for ; Thu, 24 Oct 2002 08:19:11 -0700 (PDT) (envelope-from Alexander@Leidinger.net) Received: from fwd06.sul.t-online.de by mailout02.sul.t-online.com with smtp id 184jlK-0007XG-0C; Thu, 24 Oct 2002 17:19:06 +0200 Received: from Andro-Beta.Leidinger.net (520065502893-0001@[80.131.110.127]) by fmrl06.sul.t-online.com with esmtp id 184jlH-29nfRAC; Thu, 24 Oct 2002 17:19:03 +0200 Received: from Magelan.Leidinger.net (Magelan [192.168.1.1]) by Andro-Beta.Leidinger.net (8.12.6/8.12.6) with ESMTP id g9OFJ1L7014858; Thu, 24 Oct 2002 17:19:01 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.12.6/8.12.6) with SMTP id g9OFJ0kZ000990; Thu, 24 Oct 2002 17:19:00 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Thu, 24 Oct 2002 17:18:59 +0200 From: Alexander Leidinger To: Terry Lambert Cc: current@freebsd.org Subject: Re: page fault while in vm86 mode Message-Id: <20021024171859.3b05571b.Alexander@Leidinger.net> In-Reply-To: <3DB076F2.FB650CD7@mindspring.com> References: <20021018121229.1bff0d43.Alexander@Leidinger.net> <3DB076F2.FB650CD7@mindspring.com> X-Mailer: Sylpheed version 0.8.2claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Sender: 520065502893-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 18 Oct 2002 14:02:42 -0700 Terry Lambert wrote: > Alexander Leidinger wrote: > > Fatal trap 12: page fault while in vm86 mode > ^ > | > a page fault > > > #4 0xc0265055 in trap_pfault (frame=0xc0545fa8, usermode=0, eva=803202) > ^ ^ ^ > | | | > | | On a user address > | In kernel mode > A trap from kernel code Ok, now with a Aug 22 kernel instead of an Aug 8 kernel: ---snip-- Fatal trap 12: page fault while in vm86 mode fault virtual address = 0xc4182 fault code = user read, page not present instruction pointer = 0xc000:0x4182 stack pointer = 0x0:0xfc0 frame pointer = 0x0:0x0 code segment = base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags = interrupt enabled, resume, vm86, IOPL = 0 current process = 27349 (XFree86) trap number = 12 panic: page fault Uptime: 14h31m0s pfs_vncache_unload(): 1 entries remaining Dumping 639 MB (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:225 #1 0xc01a1712 in boot (howto=260) at ../../../kern/kern_shutdown.c:356 #2 0xc01a1b2d in panic (fmt=0xc02b8bc0 "%s") at ../../../kern/kern_shutdown.c:509 #3 0xc02704b7 in trap_fatal (frame=0xc0540fa8, eva=803202) at ../../../i386/i386/trap.c:847 #4 0xc027026d in trap_pfault (frame=0xc0540fa8, usermode=0, eva=803202) at ../../../i386/i386/trap.c:761 #5 0xc026fe9b in trap (frame= {tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 19158, tf_esi = 19182, tf_ebp = 0, tf_isp = -1068232748, tf_ebx = 13, tf_edx = 980, tf_ecx = 12, tf_eax = 13, tf_trapno = 12, tf_err = 4, tf_eip = 16770, tf_cs = 49152, tf_eflags = 721410, tf_esp = 4032, tf_ss = 0}) at ../../../i386/i386/trap.c:447 (kgdb) up 4 #4 0xc027026d in trap_pfault (frame=0xc0540fa8, usermode=0, eva=803202) at ../../../i386/i386/trap.c:761 761 trap_fatal(frame, eva); (kgdb) list 756 PCPU_GET(curpcb) != NULL && 757 PCPU_GET(curpcb)->pcb_onfault != NULL) { 758 frame->tf_eip = (int)PCPU_GET(curpcb)->pcb_onfault; 759 return (0); 760 } 761 trap_fatal(frame, eva); 762 return (-1); 763 } 764 765 /* kludge to pass faulting virtual address to sendsig */ (kgdb) ---snip--- > > This doesn't look much to me. I'm used to see more frames here. What can I do > > do debug this further? > > You can load up gdb, and decode all the variables in the trap_pfault() > function, so that we can tell which code path resulted in the problem. > > Specifically, we need to know whether: > > o Which map vm->vm_map refers to? (kgdb) print vm $1 = (struct vmspace *) 0x104 (kgdb) print vm->vm_map ---Can't read userspace from dump, or kernel process--- (kgdb) print *vm ---Can't read userspace from dump, or kernel process > o Whether vm_fault failed? (kgdb) print rv $4 = 1 > o The value of 'map' and the value of 'kmem_map' and 'kernel_map'? (kgdb) print map $5 = (struct vm_map *) 0x1 (kgdb) print kmem_map $6 = 0xc0834078 (kgdb) print kernel_map $7 = 0xc0834000 > o The value of p->p_lock (kgdb) print p $8 = (struct proc *) 0xc55ef8c0 (kgdb) print p->p_lock $9 = 0 '\0' > o The value of td->td_intr_nesting_level == 0 (kgdb) print td No symbol "td" in current context. > o If PCPU_GET(curpcb) is non-NULL How do I do this with gdb? > o If so, if PCPU_GET(curpcb)->pcb_onfault is non-NULL Bye, Alexander. -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message