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: lwip-users-bounces+mdittrich=dukane....@nongnu.org [mailto:lwip-users-bounces+mdittrich=dukane....@nongnu.org] 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 lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users