Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Aug 2004 01:07:24 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Nate Lawson <nate@root.org>
Cc:        current@freebsd.org
Subject:   Re: panic on kldunload ipfw.ko
Message-ID:  <412532AC.2070302@freebsd.org>
In-Reply-To: <41252FD5.C67E25E0@freebsd.org>
References:  <41251502.2020607@root.org> <41252FD5.C67E25E0@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?412532AC.2070302>