DragonFlyBSD

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

-Matt

On 26/05/2010 02:42 πμ, Matthew Dillon wrote:

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

We could also use ktr to log sent/delivered netmsgs. That and a large
value for KTR_ENTRIES should give us enough info to debug the problem.
I've often thought of doing that while debugging netmp and libevtr will
make analyzing the data much easier.

Aggelos

I've decided to undertake some major reworking of our network
stack. Well, it is really more a continuation of the work that
was done last year.

I already have the protosw cleaned up and ip_off and ip_len fixed
    up so they are left in network byte order (instead of switching back
    and forth).  I have some more work to do with ip_len to get rid of
    the header length trimming code and a ton of other stuff.  This
    will remove all the packet back-and-forth munging that is being done
    now.

This all leads up to being able to remove all the special cpu selection
    cases in the individual protocol stacks and in particular cleaning up
    the tcp syncache, and doing unconditional cpu selection closer to the
    netif.

When I get IPV4 stable I'll put the git branch up on leaf for people to
    test.  IPV6, IPV4 & IPV6 fragmentation, ICMP, and IPSEC will need a lot
    of testing.  Also PF (particularly NAT) and IPFW.  There will be
    lots of things needing testing.

-Matt

grab