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