From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 11:14:46 2004 Return-Path: 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 BCD5316A4CE for ; Tue, 6 Jan 2004 11:14:46 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B799B43D2D for ; Tue, 6 Jan 2004 11:14:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 6075 invoked from network); 6 Jan 2004 19:14:42 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 6 Jan 2004 19:14:42 -0000 Received: from atl544379.corp.weather.com (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i06JEVM4026746; Tue, 6 Jan 2004 14:14:38 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Michael McGoldrick Date: Tue, 6 Jan 2004 14:15:08 -0500 User-Agent: KMail/1.5.4 References: <20040104013336.GA863@uriel.mcgoldrick.org> <20040106190630.GA1160@uriel.mcgoldrick.org> In-Reply-To: <20040106190630.GA1160@uriel.mcgoldrick.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401061415.09163.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: current@freebsd.org Subject: Re: Fatal trap 12 panic in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 19:14:46 -0000 On Tuesday 06 January 2004 02:06 pm, Michael McGoldrick wrote: > On Tue, Jan 06, 2004 at 10:21:09AM -0500, John Baldwin wrote: > > Wrong frame, gdb loses a frame during a page fault trap. Try doing > > 'l *0xc054-- > > Ah, I didn't realise. That certainly explains why it didn't seem to make > any sense. Here is the actual panic: (Probably, I might have updated in the > meantime...) I'd be happy to do more investigating if anyone is interested. > > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x10 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0543343 > stack pointer = 0x10:0xc9f89c80 > frame pointer = 0x10:0xc9f89cac > 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 = 27 (swi8: tty:sio clock) > trap number = 12 > panic: page fault > > syncing disks, buffers remaining... 1295 1295 1295 1295 1295 1295 1295 1295 > 1295 > 1295 1295 1295 1295 1295 1295 1295 1295 1295 1295 1295 > giving up on 816 buffers > Uptime: 12h47m56s > Dumping 127 MB > 16 32 48 64 80 96 112 > --- > Reading symbols from > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/linu > x/linux.ko.debug...done. > Loaded symbols for > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/linux/ > linux.ko.debug > Reading symbols from /boot/kernel/nvidia.ko...done. > Loaded symbols for /boot/kernel/nvidia.ko > Reading symbols from /boot/kernel/ng_ubt.ko...done. > Loaded symbols for /boot/kernel/ng_ubt.ko > Reading symbols from /boot/kernel/netgraph.ko...done. > Loaded symbols for /boot/kernel/netgraph.ko > Reading symbols from > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/ntfs > /ntfs.ko.debug...done. > Loaded symbols for > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/ntfs/n > tfs.ko.debug > Reading symbols from > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/linp > rocfs/linprocfs.ko.debug...done. > Loaded symbols for > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/linpro > cfs/linprocfs.ko.debug > Reading symbols from > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/ipfw > /ipfw.ko.debug...done. > Loaded symbols for > /usr/obj/usr/src/sys/URIEL/modules/usr/src/sys/modules/ipfw/i > pfw.ko.debug > Reading symbols from /boot/kernel/logo_saver.ko...done. > Loaded symbols for /boot/kernel/logo_saver.ko > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 > 240 dumping++; > (kgdb) bt > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 > #1 0xc05a1909 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 > #2 0xc05a1ce8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 > #3 0xc072efb6 in trap_fatal (frame=0xc9f89c40, eva=0) > at /usr/src/sys/i386/i386/trap.c:821 > #4 0xc072ec52 in trap_pfault (frame=0xc9f89c40, usermode=0, eva=16) > at /usr/src/sys/i386/i386/trap.c:735 > #5 0xc072e7ad in trap (frame= > {tf_fs = -1067778024, tf_es = -1065615344, tf_ds = 16, tf_edi = > -101627187 > 2, tf_esi = -1015529472, tf_ebp = -906453844, tf_isp = -906453908, tf_ebx = > 7, t > f_edx = 4, tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = > -1068223 > 677, tf_cs = 8, tf_eflags = 66118, tf_esp = -1015529472, tf_ss = 608}) > at /usr/src/sys/i386/i386/trap.c:420 > #6 0xc071fb48 in calltrap () at {standard input}:94 > #7 0xc05b3d5e in softclock (dummy=0x0) at > /usr/src/sys/kern/kern_timeout.c:226 > #8 0xc058b938 in ithread_loop (arg=0xc12c9580) > at /usr/src/sys/kern/kern_intr.c:544 > #9 0xc058a5b0 in fork_exit (callout=0xc058b760 , arg=0x0, > frame=0x0) at /usr/src/sys/kern/kern_fork.c:793 > (kgdb) l *0xc0543343 > 0xc0543343 is in umass_cam_rescan (/usr/src/sys/cam/cam_sim.h:107). > 102 }; > 103 > 104 static __inline u_int32_t > 105 cam_sim_path(struct cam_sim *sim) > 106 { > 107 return (sim->path_id); > 108 } > 109 > 110 static __inline const char * > 111 cam_sim_name(struct cam_sim *sim) > (kgdb) > Michael McGoldrick: michael@mcgoldrick.org Ok, definitely looks like a umass(4) bug. A good person to poke would probably be joe@ as he has been maintaining the usb(4) stack recently. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org