ifconfig <interface> <number> and a soon following panic

From: Thomas Backman <serenity_at_exscape.org>
Date: Sun, 28 Jun 2009 16:31:11 +0200
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 <interface> <number>", 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 <Address 0xa out of bounds>) 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
Received on Sun Jun 28 2009 - 12:31:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:50 UTC