[ECOS] RE: Trouble using lwIP (driver crash...)

Andrew Lunn andrew@lunn.ch
Wed Apr 5 14:49:00 GMT 2006


On Wed, Apr 05, 2006 at 10:34:19AM -0400, Michael Grimard wrote:
> This is the call stack of the recursion:
> 
> input_thread()
> i82559_deliver()
> PacketRxReady()
> eth_drv_recv()
> ecosif_input()
> etharp_arp_input()
> low_level_output()
> eth_drv_send()
> i82559_can_send()
> -->PacketRxReady
> eth_drv_recv()
> ecosif_input()
> ...
> 
> 
> So the recursion happens in i82559_can_send() when it calls PacketRxReady().
> 
> This time, it was for the reply of an ARP request.

O.K.

Things are becoming clearer.

With FreeBsd and NetBSD, the stack will not generate a packet as soon
as it recevies a packet. It queues the received packet and another
thread deals with it. lwip does this differently, as you have just
shown, when it receives an arp request it will imeadiately generate an
arp reply. 

As a quick, but potentially broken fix try changing

#ifndef CYGPKG_IO_ETH_DRIVERS_STAND_ALONE
    // We are not prepared to receive a packet now if we are in a polled
    // standalone configuration.
    PacketRxReady(p_i82559);
#endif

to

#if !defined(CYGPKG_IO_ETH_DRIVERS_STAND_ALONE) && !defined(CYGPKG_NET_LWIP)
    // We are not prepared to receive a packet now if we are in a polled
    // standalone configuration.
    PacketRxReady(p_i82559);
#endif

but you might find your receiver stops working because of lost
interrupts, or at least you might see big delays in receving packets.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list