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: [email protected]
Website: www.devlin.co.uk<http://www.devlin.co.uk/> &
www.devlinmedical.co.uk<http://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<http://www.devlin.co.uk/users/cow_efficiency_white_paper.pdf>
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<http://www.devlin.co.uk/>
& www.devlinmedical.co.uk<http://www.devlinmedical.co.uk/> Devlin
<http://www.devlin.co.uk/> 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.
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
