lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Assert after dropped TX packet


From: Dittrich, Matthew
Subject: Re: [lwip-users] Assert after dropped TX packet
Date: Thu, 27 Oct 2011 14:53:02 -0500

Thanks for the reply Kieran,

>It's not quite clear to me from this whether/how you are protecting against a 
>received packet being handled by the stack (i.e. netif->input) at the same 
>time as the application might be calling (e.g.) tcp_write().  

Here is my ethernet task loop that runs after some init code:

  while (1) {

    /* monitor the HW link */
    if (Check_Link()) {
      if (last_link_status == FALSE) {
        /* link just came up */
        last_link_status = TRUE;
        netif_set_link_up(netif_eth0);

        netif_set_down(netif_eth0);

        if (local_cfg.net_settings & LCL_CFG_NET_DHCP) {
          /* dhcp was just enabled */
          dhcp_start(netif_eth0);
          dhcp_running = TRUE;
          /* md 20111027 dhcp will netif_set_up() when it gets it... */
        } else {
          if(dhcp_running) {
            dhcp_running = FALSE;
            dhcp_release(netif_eth0);
            dhcp_stop(netif_eth0);
          }

          netif_set_addr(netif_eth0, &local_cfg.net_ip, &local_cfg.net_mask, 
&local_cfg.net_gateway);
          netif_set_up(netif_eth0);
          dhcp_inform(netif_eth0);
        }

      } else {
        /* link is still up */
        if((dhcp_running == TRUE) && ((local_cfg.net_settings & 
LCL_CFG_NET_DHCP) == 0)) {
          /* dhcp was just disabled by user */
          dhcp_running = FALSE;
          dhcp_release(netif_eth0);
          dhcp_stop(netif_eth0);

          netif_set_down(netif_eth0);

          netif_set_addr(netif_eth0, &local_cfg.net_ip, &local_cfg.net_mask, 
&local_cfg.net_gateway);
          netif_set_up(netif_eth0);
          dhcp_inform(netif_eth0);
        } else if ((dhcp_running == FALSE) && (local_cfg.net_settings & 
LCL_CFG_NET_DHCP)) {
          /* dhcp was just enabled by user */
          netif_set_down(netif_eth0);

          dhcp_start(netif_eth0);
          dhcp_running = TRUE;
          /* md 20111027 dhcp will netif_set_up() when it gets it... */
        }
      }

      /* process packets! */
      ethernetif_handlepackets(netif_eth0);

    } else {
      if (last_link_status == TRUE) {
        /* link just went down */
        last_link_status = FALSE;
        netif_set_link_down(netif_eth0);

        if(dhcp_running) {
          dhcp_running = FALSE;
          dhcp_stop(netif_eth0);
        }
      }
    }

    sys_check_timeouts();

    iqe_monitor_events(last_link_status);

    vTaskDelay(1);
  }

--------

No other tasks/threads are involved, iqe_monitor_events() and 
ethernetif_handlepackets() were discussed/posted previously.  The only place 
netif->input is called is in ethernetif_handlepackets(), any application 
tcp_write()'s that result from ethernet_input() running are safe right?  Any 
tcp_write()'s from sys_check_timeouts() or iqe_monitor_events() are certainly 
safe, because this is all happening in the same (the only) thread calling any 
lwIP routines. Right?

I changed some constants in my MAC tx driver (from 18 256byte DMA descriptors, 
to 3 1536 byte descriptors) and the machine ran all last night without a 
failure.  I didn't change any code logic, but it seems to be working fine 
now... so either a bug in my descriptor handling code is hiding very well, 
resulting in selective dropping of some "unique" packets, or the chip is screwy 
(it's always fun to blame the silicon! :).  Anyway, those (now questionable) 
code paths that spread the frame over multiple descriptors will never run 
because a full frame can fit in a single one.  For me, the issue is resolved.

If you wouldn't mind, please take a look at the last pcap that I sent 
yesterday, it was cleanest and easiest to follow. I'd like you to verify the 
failure mode: basically the PC giving up at the app level before the "dropped" 
packet is scheduled to be sent again.  I don't have faith that the "old" driver 
would actually send it at that time...

Thanks again,
MD

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Kieran Mansley
Sent: Thursday, October 27, 2011 2:04 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Assert after dropped TX packet


On 25 Oct 2011, at 19:42, Dittrich, Matthew wrote:

> I can assure you I am not in the stack from different threads.  I am using 
> the raw API in order to avoid creating a task per connection. My Ethernet 
> task loop consists of a "handle_packets()", see below, netif->input is 
> ethernet_input().  low_level_input() returns a PBUF_RAW from PBUF_POOL. Then 
> sys_check_timeouts() is run, then my app level "monitor_events()" is run, 
> this watches a FreeRTOS queue that the other app tasks put messages into for 
> the ethernet task. The monitor_events() only makes tcp_writes() (no eth input 
> handling here) and only when we are not currently sending something else.  
> Then a FreeRTOS vTaskDelay(1) will pause the task until the next tick. Then 
> repeat the loop. No interrupts are involved.

It's not quite clear to me from this whether/how you are protecting against a 
received packet being handled by the stack (i.e. netif->input) at the same time 
as the application might be calling (e.g.) tcp_write().  If you're sure that is 
protected then that's good enough for me - the above suggests you have thought 
about this sort of thing - but I wanted to check to be sure.

I haven't had a chance to digest the rest of your email yet, but will as soon 
as I get the time.

Kieran
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users



reply via email to

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