Receive task crash on Etherlink driver (elnk.c)
salpha.2004 at gmail.com
Sun Jul 14 12:41:50 UTC 2013
Finally, after much investigations I found out something.
First, there is a bug in elnk driver as reported by Greg Menke at
2003-07-18 (described in c/src/ChangeLog)
Second, there are some differences between elnk.c and if_xl.c (in
FreeBSD). The major difference I noticed, was that if_xl.c locks a
mutex before each driver action (ISR, Network Tasks, start function,
etc.) and unlocks it at the end.
I didn't modify elnk.c according to this observation to see the impact
but I guess it may make things better in elnk driver.
I hope this helps or at least prevents future usage of elnk.c!!
On 6/4/13, Chris Johns <chrisj at rtems.org> wrote:
> SAeeD wrote:
>> 2. What happens when the received packet rates exceeds so very much
>> that rxDaemon can not update curr_rx_md before arrival of a new
> You need to size the receive queue at the hardware layer (DMA chains) so
> you can meet the burst rate verses the rx task latency you might see.
> Then you need to size the network stack pool sizes, and there are a few
> configurations here, to meet the sustained data rate of the network.
> Finally you need enough processing power to be able to process the data
> or you will at some point in time run out of buffers and start to see
> data dropped.
> You need to set the priorities to give the networking tasks enough of
> the processing time to process the incoming load. The hardware needs to
> have enough packets available to allow the rx task to wake and start
> processing the receive queue. It is assumed the rx processing loop is
> fast enough to get the packets from the hardware and to refresh with new
> packets. If your rx task uses all the processing time to handle the
> incoming packets you will soon run out of network stack buffers. If your
> rx task can process the packets much faster than they arrive it will
> sleep and the network task will wake. This will take the input queue
> processing the data finally delivering to the user's socket. If the user
> is not blocked in the socket the data is queued else it is copied to the
> user's buffer and the network buffer released back to the pool available
> for the receive task to queue at the hardware.
>> 3. As I know, elnk uses DMA to place the received packet in the
>> memory. It places the packet in the mbuf, but what happens when a
>> packet is larger than a single mbuf? How does the DMA breaks the
>> packet to fit in a mbuf chain, rather than a single mbuf? How does
>> next mbuf address pointer set?
> I have not looked at the specifics of the elink driver. Typically the
> hardware supports DMA scatter/gather functionality. The hardware is
> either set up to scatter the packet's data across a number of mbuf parts
> or it fills a single mbuf cluster buffer. In transmit the hardware can
> gather the data in the packet in realtime from a number of buffer
>> Even few rays of light would enlighten me very much! :)
> I hope this helps a little.
More information about the users