Re: Fatal trap 12

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_at_ 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.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org