From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 14:31:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9BF1065676 for ; Sun, 28 Jun 2009 14:31:26 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5ED538FC19 for ; Sun, 28 Jun 2009 14:31:26 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:41245 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MKvPW-0006NL-6I for freebsd-current@freebsd.org; Sun, 28 Jun 2009 16:31:17 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 27D1E5F982 for ; Sun, 28 Jun 2009 16:31:14 +0200 (CEST) Message-Id: <0A918DF9-F417-4AD5-935B-1F2E397DBB80@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 28 Jun 2009 16:31:11 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MKvPW-0006NL-6I. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MKvPW-0006NL-6I 23455b768d01c1a742c454d17dc1b7c3 Subject: ifconfig and a soon following panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 28 Jun 2009 14:31:27 -0000 OK, so I was (not knowing what I was/am doing, I might add) trying to get jumbo frames running on my LAN. After all, all my NICs should support it, as should my switch. Warning: You could say that this post is a bit incoherent, and you'd be right. Sorry about that. Anyway... Step 1: ifconfig nfe0 mtu 7000 (as that was the maximum I managed to get out my Linux box), and then check if it worked. It had, according to ifconfig. Step 2: Try it out. Average frame size: ~1400 bytes (during some heavy file transfer). I guess it didn't work. Ah well, I guess I'll try again later, not really feeling like it right now. Step 3: ifconfig nfe0 1500. OOPS. Note that I did NOT say "mtu 1500". Network access lost! Step 4: Physically access the computer; notice nfe0 has an incorrect IP address (see above) and run /etc/rc.d/netif restart (again, could be the wrong way). Step 5 (I think there were no step 4.5): double fault panic. So, two problems (I *guess* the first one is a... feature..., that is, setting the IP based on a decimal(?) number?) i.e. losing net access on "ifconfig ", and the kernel panic following a netif restart. The interface has a static IP: # grep 192 /etc/rc.conf defaultrouter="192.168.1.1" ifconfig_nfe0="inet 192.168.1.10 netmask 255.255.255.0" The panic: Unread portion of the kernel message buffer: Fatal double fault rip = 0xffffffff8065eb19 rsp = 0xffffff8000021fc0 rbp = 0xffffff8000022050 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 2d0h59m13s Physical memory: 2027 MB #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff805a5249 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff805a569c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff801f1ee7 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801f22f1 in db_command (last_cmdp=0xffffffff80c35820, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801f2540 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801f44d9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff805d7465 in kdb_trap (type=3, code=0, tf=0xffffffff80ceb490) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff80893538 in trap (frame=0xffffffff80ceb490) at /usr/src/sys/amd64/amd64/trap.c:613 #9 0xffffffff80879647 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #10 0xffffffff805d763d in kdb_enter (why=0xffffffff80982c1c "panic", msg=0xa
) at cpufunc.h:63 #11 0xffffffff805a56ab in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #12 0xffffffff80892534 in dblfault_handler (frame=Variable "frame" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:879 #13 0xffffffff8087972c in Xdblfault () at /usr/src/sys/amd64/amd64/exception.S:274 #14 0xffffffff8065eb19 in rtalloc1_fib (dst=0xffffff80000220b0, report=1, ignflags=0, fibnum=0) at /usr/src/sys/net/route.c:395 Previous frame inner to this frame (corrupt stack?) The bt I got in ddb looked way different, of course, and looked like a "loop" of some sort (it was at least 30 functions deep, and it looked like two of them were repeating again and again). I was expecting it to be saved with the dump, so I didn't bother to write anything down... I tried to reproduce twice but it worked as it should (except that /etc/rc.d/defaultroute restart doesn't actually set the default route set in rc.conf - intentional?) the next two times. Regards, Thomas