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_at_mcgoldrick.org Ok, definitely looks like a umass(4) bug. A good person to poke would probably be joe_at_ as he has been maintaining the usb(4) stack recently. -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Tue Jan 06 2004 - 10:14:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:36 UTC