On Wed, 15 Nov 2006, Ian FREISLICH wrote: > Ian FREISLICH wrote: >> >> I have 2 servers each with 255 vlan interfaces and carp interfaces in each >> vlan.During the boot up while it's configuring the interfaces, it reliably >> panics. It boots fine if no network cables are plugged in (and in the test >> evironment on a quient lan). >> >> It's an SMP machine. My guess (from the panic message below) is that an >> arp query arives on an interface it's in the middle of creating or >> something like that (highly unsophisticated debugging conjecture). >> >> In the mean time I'm going to try a UP kernel and see if that masks the >> problem. > > FWIW, a UP kernel has the same problem. What happens if you disable PREEMPTION on UP and try the same thing again? Robert N M Watson Computer Laboratory University of Cambridge > >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x5f >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc058e18b >> stack pointer = 0x28:0xe34d9bb0 >> frame pointer = 0x28:0xe34d9c2c >> 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 = 14 (swi1: net) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(c06830f9,e34d9a74,c04eff40,c0695d9f,0,...) at db_trace_ > sel >> f_wrapper+0x27 >> kdb_backtrace(c0695d9f,0,c067664b,e34d9a80,80,...) at kdb_backtrace+0x2f >> panic(c067664b,c0696cfe,c49135fc,1,1,...) at panic+0x129 >> trap_fatal(e34d9b70,5f,1,0,e34d9ae4,...) at trap_fatal+0x332 >> trap_pfault(e34d9b70,0,5f,b,5f,...) at trap_pfault+0x232 >> trap(c06e0008,c4910028,e34d0028,0,c4e57800,...) at trap+0x3cb >> calltrap() at calltrap+0x5 >> --- trap 0xc, eip = 0xc058e18b, esp = 0xe34d9bb0, ebp = 0xe34d9c2c --- >> in_arpinput(c4fc3200,c04e3a0f,c06e5424,0,c4fc3200,...) at in_arpinput+0x123 >> arpintr(c4fc3200,c06e5424,0,c4914c40,e34d9c70,...) at arpintr+0xfb >> netisr_processqueue(c06ed4f8,c4914540,c4914c40,c4914c40,c4913460,...) at neti > sr_ >> processqueue+0xcc >> swi_net(0,c4914c40,246,0,c4914c40,...) at swi_net+0x125 >> ithread_execute_handlers(c4913460,c496e480,0,0,0,...) at ithread_execute_hand > ler >> s+0x165 >> ithread_loop(c48f6810,e34d9d38,7fdec364,3ae77ec0,3940eec5,...) at ithread_loo > p+0 >> x64 >> fork_exit(c04d405d,c48f6810,e34d9d38) at fork_exit+0x83 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0x1, eip = 0, esp = 0xe34d9d6c, ebp = 0 --- >> Uptime: 9m35s >> Physical memory: 2039 MB >> Dumping 64 MB: 49 33 17 1 >> (kgdb) bt >> #0 doadump () at pcpu.h:166 >> #1 0xc04efc20 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 >> #2 0xc04effff in panic (fmt=0xc067664b "%s") >> at /usr/src/sys/kern/kern_shutdown.c:567 >> #3 0xc06508e3 in trap_fatal (frame=0xe34d9b70, eva=95) >> at /usr/src/sys/i386/i386/trap.c:869 >> #4 0xc065058d in trap_pfault (frame=0xe34d9b70, usermode=0, eva=95) >> at /usr/src/sys/i386/i386/trap.c:778 >> #5 0xc06500ff in trap (frame= >> {tf_fs = -1066532856, tf_es = -997130200, tf_ds = -481492952, tf_edi = > 0, tf_esi = -991594496, tf_ebp = -481453012, tf_isp = -481453156, tf_ebx = 3, t > f_edx = 314, tf_ecx = -1, tf_eax = -996395008, tf_trapno = 12, tf_err = 0, tf_e > ip = -1067916917, tf_cs = 32, tf_eflags = 66118, tf_esp = -481453064, tf_ss = - > 989906900}) at /usr/src/sys/i386/i386/trap.c:463 >> #6 0xc063771a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 >> #7 0xc058e18b in in_arpinput (m=0xc4fc3200) >> at /usr/src/sys/netinet/if_ether.c:635 >> #8 0xc058e058 in arpintr (m=0xc4fc3200) >> at /usr/src/sys/netinet/if_ether.c:552 >> #9 0xc0586213 in netisr_processqueue (ni=0xc06ed4f8) >> at /usr/src/sys/net/netisr.c:236 >> #10 0xc0586464 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:349 >> #11 0xc04d3f7b in ithread_execute_handlers (p=0xc4913460, ie=0xc496e480) >> at /usr/src/sys/kern/kern_intr.c:666 >> ---Type <return> to continue, or q <return> to quit--- >> #12 0xc04d40c1 in ithread_loop (arg=0xc48f6810) >> at /usr/src/sys/kern/kern_intr.c:749 >> #13 0xc04d2914 in fork_exit (callout=0xc04d405d <ithread_loop>, >> arg=0xc49c3800, frame=0xc49c3800) at /usr/src/sys/kern/kern_fork.c:834 >> #14 0xc063777c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:19 > 9 >> (kgdb) frame 7 >> #7 0xc058e18b in in_arpinput (m=0xc4fc3200) >> at /usr/src/sys/netinet/if_ether.c:635 >> 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || >> (kgdb) l >> 630 * is part of carp, we call carp_iamatch to see if this is a >> 631 * request for the virtual host ip. >> 632 * XXX: This is really ugly! >> 633 */ >> 634 LIST_FOREACH(ia, INADDR_HASH(itaddr.s_addr), ia_hash) { >> 635 if (((bridged && ia->ia_ifp->if_bridge != NULL) || >> 636 (ia->ia_ifp == ifp)) && >> 637 itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) >> 638 goto match; >> 639 #ifdef DEV_CARP >> (kgdb) print bridged >> $1 = 0 >> (kgdb) print ia->ia_ifp >> There is no member named ia_ifp. >> (kgdb) print ia >> $2 = (struct in_ifaddr *) 0x3 > > Ian > > -- > Ian Freislich > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Wed Nov 15 2006 - 06:24:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:02 UTC