DragonFly BSD
DragonFly bugs List (threaded) for 2010-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_active

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 May 2010 16:42:31 -0700 (PDT)

:panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_active
:mp_lock = 00000001; cpuid = 1
:Trace beginning at frame 0xd82db9b8
:panic(ffffffff) at panic+0x14f
:panic(c037a20a,c03a4300,c036edf8,e100,0) at panic+0x14f
:tcp_output(e3462208,e6b7e000) at tcp_output+0xe9a
:tcp_input(e6b7e000,14,6) at tcp_input+0x3d63

    This one is really difficult to track down even with the
    kernel core.  I think the only real way to do it is to add
    assertions near the top of tcp_input() and tcp_output() after
    the tp is looked up to assert that tt->tt_msg->tt_cpuid ==
    mycpu->gd_cpuid, to try to catch the problem earlier in the
    procedure chain.

    Even worse, we still have ipv6 hacks for the tcp stack that
    puts all ipv6 transport processing on cpu 0, and ipv6->ipv4
    conversion hacks for connections that screw up the model.
    It's a real mess, frankly.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]