Date: Tue, 6 Jan 2004 14:15:08 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Michael McGoldrick <michael@mcgoldrick.org> Cc: current@freebsd.org Subject: Re: Fatal trap 12 panic in recent -current Message-ID: <200401061415.09163.jhb@FreeBSD.org> In-Reply-To: <20040106190630.GA1160@uriel.mcgoldrick.org> References: <20040104013336.GA863@uriel.mcgoldrick.org> <XFMail.20040106102109.jhb@FreeBSD.org> <20040106190630.GA1160@uriel.mcgoldrick.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ithread_loop>, 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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401061415.09163.jhb>