From owner-freebsd-ipfw@FreeBSD.ORG Sat Oct 11 14:42:38 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2E90221; Sat, 11 Oct 2014 14:42:38 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B561F16; Sat, 11 Oct 2014 14:42:38 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xctsp-0008IR-RQ; Sat, 11 Oct 2014 14:26:43 +0400 Message-ID: <5439418A.5050903@FreeBSD.org> Date: Sat, 11 Oct 2014 18:41:14 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: David Wolfskill , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD] References: <542FE9A7.9090208@FreeBSD.org> <20141011141505.GA46277@albert.catwhisker.org> In-Reply-To: <20141011141505.GA46277@albert.catwhisker.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 14:42:38 -0000 On 11.10.2014 18:15, David Wolfskill wrote: > On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote: >> Hi, >> >> I'm going to merge projects/ipfw branch to HEAD in the middle of next week. >> .... > OK; I was able to build & install head @r272938 this morning on my > laptop; on reboot, I was greeted by a panic. Ups. Not the best greeting, definitely. Can you send me ipfw ruleset? > > Now, this is a laptop, so I don't have a serial console -- but I was > able to "call doadump", then reboot with the wireless NIC disabled (to Do you have some hooks to run ipfw on iface-up? > avoid the panic) and get the dump & core.txt captured. > > Here's the first chunk of the core.txt file: > > localhost dumped core - see /var/crash/vmcore.0 > > Sat Oct 11 07:02:26 PDT 2014 > > FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392 r272938M/272938:1100037: Sat Oct 11 05:44:30 PDT 2014 root@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > panic: resize_storage() notify failure > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 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-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: resize_storage() notify failure > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c10ebfd8,d1070720,fc,10000000,1,...) at 0xc0528cdd = db_trace_self_wrapper+0x2d/frame 0xfa0cc508 > kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 = kdb_backtrace+0x30/frame 0xfa0cc570 > vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d = vpanic+0x11d/frame 0xfa0cc5ac > kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a = kassert_panic+0xea/frame 0xfa0cc5d0 > ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 0xc0d25cfd = ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0 > add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 = add_table_entry+0x348/frame 0xfa0cc7c8 > manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b9 = manage_table_ent_v1+0x1c9/frame 0xfa0cc828 > ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d = ipfw_ctl3+0xacd/frame 0xfa0ccb20 > rip_ctloutput(d2432dc0,fa0ccbe0,ffffffff,200007f,1fffff,...) at 0xc0c3cf49 = rip_ctloutput+0x299/frame 0xfa0ccb48 > sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 = sogetopt+0xb0/frame 0xfa0ccba8 > kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 = kern_getsockopt+0x116/frame 0xfa0ccc0c > sys_getsockopt(d03afc40,fa0cccc8,c12ab55e,d5,c1455210,...) at 0xc0b71417 = sys_getsockopt+0x67/frame 0xfa0ccc40 > syscall(fa0ccd08) at 0xc0f7c76b = syscall+0x31b/frame 0xfa0cccfc > Xint0x80_syscall() at 0xc0f665b1 = Xint0x80_syscall+0x21/frame 0xfa0cccfc > --- syscall (118, FreeBSD ELF32, sys_getsockopt), eip = 0x2815a3c7, esp = 0xbfbfd2e4, ebp = 0xbfbfd300 --- > KDB: enter: panic > > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. > Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. > Loaded symbols for /boot/kernel/tmpfs.ko.symbols > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > Loaded symbols for /boot/kernel/linprocfs.ko.symbols > #0 doadump (textdump=0) at pcpu.h:233 > 233 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=0) at pcpu.h:233 > #1 0xc0526acd in db_fncall (dummy1=-99826980, dummy2=0, dummy3=1573888, > dummy4=0xfa0cc2b4 "\036\211\220À¸\026MÁ") > at /usr/src/sys/ddb/db_command.c:578 > #2 0xc05267ab in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:449 > #3 0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 > #4 0xc0528e20 in db_trap (type=, > code=) at /usr/src/sys/ddb/db_main.c:251 > #5 0xc0b226f4 in kdb_trap (type=, > code=, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xc0f7ba87 in trap (frame=) > at /usr/src/sys/i386/i386/trap.c:693 > #7 0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > #8 0xc0b21f7d in kdb_enter (why=0xc10e77dd "panic", > msg=) at cpufunc.h:71 > #9 0xc0ae7bb1 in vpanic (fmt=, ap=) > at /usr/src/sys/kern/kern_shutdown.c:739 > #10 0xc0ae7a6a in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:634 > #11 0xc0d25cfd in ipfw_link_table_values (ch=0x0, ts=0xfa0cc6f8) > at /usr/src/sys/netpfil/ipfw/ip_fw_table_value.c:560 > #12 0xc0d1be78 in add_table_entry (ch=0xc1518498, tei=0xfa0cc800, > flags=0 '\0', count=1) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:620 > #13 0xc0d202b9 in manage_table_ent_v1 (op3=, > sd=) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:1038 > #14 0xc0d1834d in ipfw_ctl3 (sopt=0xfa0ccbe0) > at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2723 > #15 0xc0c3cf49 in rip_ctloutput (so=, sopt=0xfa0ccbe0) > at /usr/src/sys/netinet/raw_ip.c:583 > #16 0xc0b6c670 in sogetopt (so=0xd2432dc0, sopt=0xfa0ccbe0) > at /usr/src/sys/kern/uipc_socket.c:2721 > #17 0xc0b71556 in kern_getsockopt (s=, > level=, name=, > val=, valseg=, > valsize=) at /usr/src/sys/kern/uipc_syscalls.c:1589 > #18 0xc0b71417 in sys_getsockopt (uap=0xfa0cccc8) > at /usr/src/sys/kern/uipc_syscalls.c:1535 > #19 0xc0f7c76b in syscall (frame=) at subr_syscall.c:133 > #20 0xc0f665b1 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:269 > #21 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > I'll be happy to poke around more, test patches, .... The "poking" will > likely be a bit on the slow side, since I won't have connectivity while > the machine is running head (until the issue is circumvented, at least); > as I type, it's running stable/9 (also just built today). And yes, > since it's a laptop, and it's thus subject to being connected to > networks I don't control, I run IPFW on it -- same rulesets & tables > whether it's running stable/9, stable/10, or head. > > Peace, > david