|
From: | Carr, Anthony |
Subject: | [lwip-users] Lock-up issue with tcp_receive() and tcp_output() |
Date: | Tue, 4 Jan 2011 11:18:37 +0000 |
Hi, I am having some problems with my application getting locked-up in a couple of the tcp routines. The first is in the tcp_receive() function in module tcp_in. In this module the firmware gets stuck in the following while loop: /* Remove segment from the unacknowledged list if the incoming ACK acknowlegdes them. */ while (pcb->unacked != NULL && TCP_SEQ_LEQ(ntohl(pcb->unacked->tcphdr->seqno) + TCP_TCPLEN(pcb->unacked), ackno)) { LWIP_DEBUGF(TCP_INPUT_DEBUG, ("tcp_receive: removing %"U32_F":%"U32_F" from pcb->unacked\n", ntohl(pcb->unacked->tcphdr->seqno), ntohl(pcb->unacked->tcphdr->seqno) + TCP_TCPLEN(pcb->unacked))); next = pcb->unacked; pcb->unacked = pcb->unacked->next; LWIP_DEBUGF(TCP_QLEN_DEBUG, ("tcp_receive: queuelen %"U16_F" ... ", (u16_t)pcb->snd_queuelen)); LWIP_ASSERT("pcb->snd_queuelen >= pbuf_clen(next->p)", (pcb->snd_queuelen >= pbuf_clen(next->p))); pcb->snd_queuelen -= pbuf_clen(next->p); tcp_seg_free(next); LWIP_DEBUGF(TCP_QLEN_DEBUG, ("%"U16_F" (after freeing unacked)\n", (u16_t)pcb->snd_queuelen)); if (pcb->snd_queuelen != 0) { LWIP_ASSERT("tcp_receive: valid queue length", pcb->unacked != NULL || pcb->unsent != NULL); } } The second is in the tcp_output() function in module tcp_out. In this module the firmware gets stuck in the following for loop: /* useg should point to last segment on unacked queue */ useg = pcb->unacked; if (useg != NULL) { for (; useg->next != NULL; useg = useg->next); } In normal operation the application works ok but the lock-up occurs under stress testing (i.e. increasing the amount of network traffic). The application is based upon lwip version 1.3.1. There is a later version of lwip available (1.3.2) and there are some changes in this area. I incorporated the changes from the later version for these modules but was still able to create the lock-up, so for the time being I have reverted to 1.3.1. I should also mention the Nagel algorithm has been disabled in order to speed up the transmission of the product protocol command responses. Also the application is not using an RTOS. I can trap the conditions in the offending loops but I am not certain what I should do after trapping the condition. It would be better to prevent the condition occurring in the first place. I would appreciate any suggestions or ideas as to what I can do to fix this issue. Thanks, Tony
Anthony Carr Principal Electronics Engineer Devlin Electronics Limited Unit D1, Grafton Way Basingstoke, Hampshire, RG22 6HZ, England Mobile: Tel: +44 (0)1256 467367 Fax: +44 (0)1256 840048 Email: address@hidden Website: www.devlin.co.uk & www.devlinmedical.co.uk Devlin Group Latest News:
Exhibitions: Healthcare Computing 2011 – Birmingham ICC – April 5th to 7th
Latest News: New Whitepaper on Achievable Healthcare Efficiency Savings Through the use of Computers on Wheels – Click Here
This email contains confidential and/or privileged information belonging to Devlin Electronics Ltd its affiliates and/or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and/or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error; please notify the sender by return Email and delete it from your system. If you require assistance, please contact our sales office on +44 (0)1256 467367 or visit our websites www.devlin.co.uk & www.devlinmedical.co.uk Devlin Electronics Limited is registered in England and Wales with company no 4067603. VAT no GB200 8583 88 Registered Address: Unit D1, Grafton Way, Basingstoke, Hampshire, RG22 6HZ, England.
[Prev in Thread] | Current Thread | [Next in Thread] |