[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] dhcp_create_msg failure

From: Behrooz Shafiee
Subject: Re: [lwip-users] dhcp_create_msg failure
Date: Fri, 28 Mar 2014 00:07:37 -0400

I found out what's going wrong. Actually I was calling ethernet_input directly from my main thread (where driver receives the frame) and that resulted in having two different threads being in the core functions of lwip. So I just simply changed that to "tcpip_input" which handles the input packet from tcpip_thread and the problem is solved now.


On Thu, Mar 27, 2014 at 10:14 PM, Behrooz Shafiee <address@hidden> wrote:
Yes, that's true.

The dhcp_discover function (which calls dhcp_create_msg) is being called from the tcp_ip main loop thread and the input processing function is on another thread which will call dhcp_select (that calls dhcp_create_msg as well). Therefore in summary, dhcp_create_msg is being called from 1) dhcp_discover (because of dhcp timers and from tcpip_thread) and 2) from dhcp_select due to an input packet with the following stack call: my_driver_input_packet_callback->ethernet_if_input->ip_input->udp_input->dhcp_recv->dhcp_handle_offer->dhcp_select->dhcp_create_msg. 

So this is the problem, but I don't know how to solve it, because tcp_init function create a new thread and my input buffer are coming from another thread. Could you please tell me how to handle this situation? I tried LWIP_TCPIP_CORE_LOCKING but did not help.


On Thu, Mar 27, 2014 at 2:20 PM, Simon Goldschmidt <address@hidden> wrote:
 Behrooz Shafiee wrote:

>   LWIP_ASSERT("dhcp_create_msg: dhcp->p_out == NULL", dhcp->p_out == NULL);
> using some outputs I realized this happens because dhcp_create_msg being called consecutively without a dhcp_delete_msg in between.
> [..]
> I don't know the lwip mechanics but I am guessing sometimes the dhcp_delete_message takes longer than usual I guess...
> I have attached a log file as well.

The way your log output is formatted suggests that you are violating lwIP's threading requirements and more than one thread is active in the core at the same time: trace output of ip_input is mixed with that of dhcp functions.
I guess this sometimes results in two threads running the deco code at the same time, which is not supported.

lwip-users mailing list



reply via email to

[Prev in Thread] Current Thread [Next in Thread]