Re: panic on kldunload ipfw.ko

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.
>