Skip site navigation (1)Skip section navigation (2)
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>