https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082010-05-26T06:44:03ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #1769: panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_activehttps://bugs.dragonflybsd.org/issues/1769?journal_id=86062010-05-26T06:44:03Zdillon
<ul></ul><p>:panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_active<br />:mp_lock = 00000001; cpuid = 1<br />:Trace beginning at frame 0xd82db9b8<br />:panic(ffffffff) at panic+0x14f<br />:panic(c037a20a,c03a4300,c036edf8,e100,0) at panic+0x14f<br />:tcp_output(e3462208,e6b7e000) at tcp_output+0xe9a<br />:tcp_input(e6b7e000,14,6) at tcp_input+0x3d63</p>
<pre><code>This one is really difficult to track down even with the<br /> kernel core. I think the only real way to do it is to add<br /> assertions near the top of tcp_input() and tcp_output() after<br /> the tp is looked up to assert that tt->tt_msg->tt_cpuid ==<br /> mycpu->gd_cpuid, to try to catch the problem earlier in the<br /> procedure chain.</code></pre>
<pre><code>Even worse, we still have ipv6 hacks for the tcp stack that<br /> puts all ipv6 transport processing on cpu 0, and ipv6->ipv4<br /> conversion hacks for connections that screw up the model.<br /> It's a real mess, frankly.</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #1769: panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_activehttps://bugs.dragonflybsd.org/issues/1769?journal_id=86132010-05-26T17:10:13Zaoiko
<ul></ul><p>On 26/05/2010 02:42 πμ, Matthew Dillon wrote:</p>
<blockquote>
<p>:panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_active<br />:mp_lock = 00000001; cpuid = 1<br />:Trace beginning at frame 0xd82db9b8<br />:panic(ffffffff) at panic+0x14f<br />:panic(c037a20a,c03a4300,c036edf8,e100,0) at panic+0x14f<br />:tcp_output(e3462208,e6b7e000) at tcp_output+0xe9a<br />:tcp_input(e6b7e000,14,6) at tcp_input+0x3d63</p>
<p>This one is really difficult to track down even with the<br />kernel core. I think the only real way to do it is to add<br />assertions near the top of tcp_input() and tcp_output() after<br />the tp is looked up to assert that tt->tt_msg->tt_cpuid ==<br />mycpu->gd_cpuid, to try to catch the problem earlier in the<br />procedure chain.</p>
</blockquote>
<p>We could also use ktr to log sent/delivered netmsgs. That and a large <br />value for KTR_ENTRIES should give us enough info to debug the problem. <br />I've often thought of doing that while debugging netmp and libevtr will <br />make analyzing the data much easier.</p>
<p>Aggelos</p> DragonFlyBSD - Bug #1769: panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_activehttps://bugs.dragonflybsd.org/issues/1769?journal_id=86212010-05-26T23:52:15Zdillon
<ul></ul><p>I've decided to undertake some major reworking of our network<br /> stack. Well, it is really more a continuation of the work that<br /> was done last year.</p>
<pre><code>I already have the protosw cleaned up and ip_off and ip_len fixed<br /> up so they are left in network byte order (instead of switching back<br /> and forth). I have some more work to do with ip_len to get rid of<br /> the header length trimming code and a ton of other stuff. This<br /> will remove all the packet back-and-forth munging that is being done<br /> now.</code></pre>
<pre><code>This all leads up to being able to remove all the special cpu selection<br /> cases in the individual protocol stacks and in particular cleaning up<br /> the tcp syncache, and doing unconditional cpu selection closer to the<br /> netif.</code></pre>
<pre><code>When I get IPV4 stable I'll put the git branch up on leaf for people to<br /> test. IPV6, IPV4 & IPV6 fragmentation, ICMP, and IPSEC will need a lot<br /> of testing. Also PF (particularly NAT) and IPFW. There will be<br /> lots of things needing testing.</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #1769: panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_activehttps://bugs.dragonflybsd.org/issues/1769?journal_id=88792010-09-10T09:20:10Zsjg
<ul></ul><p>grab</p> DragonFlyBSD - Bug #1769: panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_activehttps://bugs.dragonflybsd.org/issues/1769?journal_id=142722022-05-15T18:07:41Ztuxillo
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/14272/diff?detail_id=3847">diff</a>)</li><li><strong>Target version</strong> changed from <i>6.4</i> to <i>Unverifiable</i></li></ul><p>Core dumps for i386, which is no longer supported. Also, note enough information on how to reproduce it, moving to unverifiable.</p>