On Jan 15, 2008 8:43 AM, Jonathan Larmour <[EMAIL PROTECTED]> wrote: > > > > Thomas Taranowski wrote: > > 95% of the time my ftp/telnet apps work fine. However, once in awhile I > > get into a cycle where the tcp connections totally hose up. The cause > > appears to be related to the fact that in sys_mbox_fetch(), the > > again:/goto again loop is spinning with wild abandon. I put a counter > > inside sys_mbox_fetch, which easily upticks into the several hundreds > > within seconds of stack startup. I've verified that the > > sys_arch_mbox_fetch is returning sane values. The odd thing is that > > this only crops up once in awhile, and will stay around. Last time I > > thought I had a bad ethernet card, and switched test targets, and > > everything started working. However, now that I'm seeing it again on > > different hardware/ethernet card combo, I'm concerned that I've got a > > critical bug floating around somewhere. > > > > I've attached a wireshark capture of the link output. It's a portion of > > the ftp session. You'll see that it basically works, but will spew out > > loads of TCP Dup ACK, TCP Retransmits, and finally drops the connection > > at the end with a series of 7 RSTs in a row. Presumably I'm seeing > > these cause the timers are firing way to fast. > > > > Note: This is a custom port of lwIP to an OS I'm working on. > > > > Any ideas on how to debug this, or what the issue is? When this occurs, > > I do have an inetd server start listening on several tcp ports at system > > startup. > > Given sys_mbox_fetch is spinning, I would initially suspect your port's > sys_arch_timeouts() call. It should return a list of timeouts only for the > current thread. > > Jifl > --
I do return a list of timeouts for only the current thread, but I'm returning a pointer to the list of timeouts. More timeouts *could* be added while I'm in the midst of processing the list, potentially creating a situation where I never return, which seems to be what is happening. Hmm, It's almost like it keeps rerunning stale timeout handlers. Anyway, thanks for the pointer. I will check out that area. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
