[lwip-users] Lock-up issue with tcp_receive() and tcp_output()
Carr, Anthony
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: Anthon...@devlin.co.uk 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.
Kieran Mansley
>
> I would appreciate any suggestions or ideas as to what I can do to fix
> this issue.
It looks like some of the internal lists of packets or pcbs have become
corrupted. This is a common problem and almost always due to the port
or application calling into lwIP incorrectly. I would guess that you
have at some point got more than one thread operating in the core of
lwIP at the same time, this corrupts the lists, and then you see the
problem.
Kieran
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Carr, Anthony
Thanks for the response.
I understand it is better to prevent the issue occurring but is there any way to recover from this condition.
I believe I can trap both occurrences of the lock-up, so if there is a way to recover from this I could use this as a short-term fix whilst investigating the underlying cause.
Tony
Kieran Mansley
> I understand it is better to prevent the issue occurring but is there
> any way to recover from this condition.
No, sorry - once corrupted it's impossible to recover.
Carr, Anthony
Not the answer I wanted but at least I know where I stand in this state.
Tony
-----Original Message-----
From: lwip-users-bounces+anthony.carr=devlin...@nongnu.org [mailto:lwip-users-bounces+anthony.carr=devlin...@nongnu.org] On Behalf Of Kieran Mansley
Sent: 13 January 2011 09:36
To: Mailing list for lwIP users
Carr, Anthony
I have been delving into this problem a bit more and have found an identical issue in the archive.
In the archive thread the user was having problems with ethernetif_input() being interrupted by a timer interrupt that called tcp_slowtmr() and resulted in the corruption of the internal packet lists.
In my application I have the reverse condition.
tcp_slowtmr() is called periodically from main() with ethernetif_input() called from the Ethernet interrupt.
I am assuming if the Ethernet interrupt occurs during tcp_slowtmr() this could possibly be the cause of the corrupted packet lists.
Am I correct in this assumption?
Thanks,
Tony
-----Original Message-----
From: lwip-users-bounces+anthony.carr=devlin...@nongnu.org [mailto:lwip-users-bounces+anthony.carr=devlin...@nongnu.org] On Behalf Of Kieran Mansley
Sent: 13 January 2011 09:36
To: Mailing list for lwIP users
Simon Goldschmidt
"Carr, Anthony" <Anthon...@devlin.co.uk> wrote:
> In my application I have the reverse condition.
> tcp_slowtmr() is called periodically from main() with ethernetif_input()
> called from the Ethernet interrupt.
> I am assuming if the Ethernet interrupt occurs during tcp_slowtmr() this
> could possibly be the cause of the corrupted packet lists.
That should normally not be a problem but it depends on 2 things:
a) The pbuf.c and mem.c code must be protected againts concurrent access by using the correct defines (see the lwIP wiki for an explanation), but this should be OK with the defaults in opt.h, I think.
b) ethernetif_input() must *not* call into the stack directly. When using tcpip.c (in a multithreading environment), pass packets to tcpip_input(). When running without an OS, you have to put new packets on a linked list that is processed periodically from main() (just like the timers).
Simon
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de