From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 23:07:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66F3216A4CE for ; Thu, 19 Aug 2004 23:07:25 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9636543D39 for ; Thu, 19 Aug 2004 23:07:24 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 1684 invoked from network); 19 Aug 2004 23:07:25 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Aug 2004 23:07:25 -0000 Message-ID: <412532AC.2070302@freebsd.org> Date: Fri, 20 Aug 2004 01:07:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <41251502.2020607@root.org> <41252FD5.C67E25E0@freebsd.org> In-Reply-To: <41252FD5.C67E25E0@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: panic on kldunload ipfw.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 19 Aug 2004 23:07:25 -0000 Ok, the patch doesn't fix it. I've just tried it. However I'm getting my panic in atkbd_timeout(), so I suspect some general callout memory corruption going on. I'm not sure whether a ipfw unload is just bringing problems from somewhere else to light. -- Andre Andre Oppermann wrote: > Nate Lawson wrote: > >>Easy to reproduce -- boot single user. kldload ipfw.ko; kldunload >>ipfw.ko. Next timeout, you get the following panic: >> >>panic: write, page not present >>callout_reset() + 0x12c >>tcp_isn_tick() + 0x3f >>softclock >>ithread_loop >> >>(gdb) l *callout_reset+0x12c >>0xc05011e8 is in callout_reset (../../../kern/kern_timeout.c:437). >>432 >>433 c->c_arg = arg; >>434 c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING); >>435 c->c_func = ftn; >>436 c->c_time = ticks + to_ticks; >>437 TAILQ_INSERT_TAIL(&callwheel[c->c_time & callwheelmask], >>438 c, c_links.tqe); >>439 mtx_unlock_spin(&callout_lock); >>440 } >>441 >> >>(gdb) l *tcp_isn_tick+0x3f >>0xc0588c4f is in tcp_isn_tick (../../../netinet/tcp_subr.c:1368). >>1363 if (projected_offset > isn_offset) >>1364 isn_offset = projected_offset; >>1365 >>1366 isn_offset_old = isn_offset; >>1367 callout_reset(&isn_callout, 1, tcp_isn_tick, NULL); >>1368 } >>1369 >>1370 /* >>1371 * When a source quench is received, close congestion window >>1372 * to one segment. We will gradually open it again as we proceed. > > > This doesn't really make sense. Nowhere in ip_fw2.c any tcp_* function > is touched. However there might be a (long-standing) problem in ipfw2 > which the patch below should fix. >