: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