Date: Wed, 24 Mar 2004 16:16:17 -0500 From: John Baldwin <jhb@FreeBSD.org> To: noackjr@alumni.rice.edu Cc: sam@FreeBSD.org Subject: Re: Fatal trap 12 Message-ID: <200403241616.17879.jhb@FreeBSD.org> In-Reply-To: <4061F615.4030300@alumni.rice.edu> References: <405F192E.8050305@supsi.ch> <200403241409.52320.jhb@FreeBSD.org> <4061F615.4030300@alumni.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 24 March 2004 03:56 pm, Jon Noack wrote:
> On 3/24/2004 1:09 PM, John Baldwin wrote:
> > On Tuesday 23 March 2004 06:01 pm, Roberto Nunnari wrote:
> >>Now I'm going to get some sleep.. as here is midnight..
> >>
> >>Hope this short session from gdb will give you some more
> >>information for solving this problem.. please ask me any
> >>relevant information you may need to look into this problem.
> >>
> >>Thank you.
> >>
> >>
> >>***********************************************************
> >>web.dti.supsi.ch# gdb -k kernel.debug /usr/crash/vmcore.1
> >>GNU gdb 5.2.1 (FreeBSD)
> >>Copyright 2002 Free Software Foundation, Inc.
> >>GDB is free software, covered by the GNU General Public License, and you
> >>are welcome to change it and/or distribute copies of it under certain
> >>conditions.
> >>Type "show copying" to see the conditions.
> >>There is absolutely no warranty for GDB. Type "show warranty" for
> >> details. This GDB was configured as "i386-unknown-freebsd"...
> >>panic: page fault
> >>panic messages:
> >>---
> >>Fatal trap 12: page fault while in kernel mode
> >>cpuid = 0; apic id = 00
> >>fault virtual address = 0xff70ff70
> >>fault code = supervisor read, page not present
> >>instruction pointer = 0x8:0xc0568949
> >>stack pointer = 0x10:0xe40a1b04
> >>frame pointer = 0x10:0xe40a1b28
> >>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 = 303 (ifconfig)
> >>trap number = 12
> >>panic: page fault
> >>cpuid = 0;
> >>boot() called on cpu#0
> >>
> >>syncing disks, buffers remaining... 218 218 216 216 215 215 215 215 215
> >>215 215 215 215 215 215 215 215 215 215 215 215 215 215 215
> >>giving up on 200 buffers
> >>Uptime: 46s
> >>Dumping 1023 MB
> >> 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
> >>320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
> >>608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
> >>896 912 928 944 960 976 992 1008
> >>---
> >>Reading symbols from
> >>/usr/obj/usr/src/sys/WEB/modules/usr/src/sys/modules/acpi/acpi.ko.debug..
> >>.d one. Loaded symbols for
> >>/usr/obj/usr/src/sys/WEB/modules/usr/src/sys/modules/acpi/acpi.ko.debug
> >>#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> >>240 dumping++;
> >>(kgdb) list *0xc0568949
> >>0xc0568949 is in rt_msg2 (/usr/src/sys/net/rtsock.c:708).
> >>703 register struct sockaddr *sa;
> >>704
> >>705 if ((sa = rtinfo->rti_info[i]) == 0)
> >>706 continue;
> >>707 rtinfo->rti_addrs |= (1 << i);
> >>708 dlen = ROUNDUP(sa->sa_len);
> >>709 if (cp) {
> >>710 bcopy((caddr_t)sa, cp, (unsigned)dlen);
> >>711 cp += dlen;
> >>712 }
> >
> > Ok, your panic is because the sa pointer is bogus. I think sa_len is the
> > first item in sockaddr, so that means sa = 0xff07ff07, which is a weird
> > value, certainly not a valid kernel pointer. This code is in the routing
> > table, so the best place to ask about this is on the net@ list probably.
> > I've also cc'd a couple of folks who might be able to help. Andre has
> > done a lot of work recently on the routing table I believe.
>
> How recently? This was after a 5.2-p1 -> RELENG_5_2 upgrade (for you
> late comers).
I think it was prior to 5.2.
--
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?200403241616.17879.jhb>