From owner-freebsd-current@FreeBSD.ORG Wed Mar 24 13:14:48 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 6103416A4CF for ; Wed, 24 Mar 2004 13:14:48 -0800 (PST) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3006143D45 for ; Wed, 24 Mar 2004 13:14:48 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 12779 invoked from network); 24 Mar 2004 21:14:47 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 24 Mar 2004 21:14:47 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i2OLEWDF006812; Wed, 24 Mar 2004 16:14:33 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: noackjr@alumni.rice.edu Date: Wed, 24 Mar 2004 16:16:17 -0500 User-Agent: KMail/1.6 References: <405F192E.8050305@supsi.ch> <200403241409.52320.jhb@FreeBSD.org> <4061F615.4030300@alumni.rice.edu> In-Reply-To: <4061F615.4030300@alumni.rice.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403241616.17879.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: andre@FreeBSD.org cc: freebsd-current@freebsd.org cc: rwatson@FreeBSD.org cc: Roberto Nunnari cc: sam@FreeBSD.org Subject: Re: Fatal trap 12 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: Wed, 24 Mar 2004 21:14:48 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org