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+0x3d63This 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
