Hi,
i may have found a problem reviewing the EMAC code. The function
ulEMACInputLength is called before the EMAC buffers are copied into the
pbufs. It sets ulNextRxBuffer to the buffer with a Start Of Frame set
and gives back the total length which is written in the last buffer of
the frame.
I just assume that some big frames arrive in a very short time. The
first frame fits in the EMAC buffers, let's say it needs 10 buffers
(each buffer has 128 byte in my EMAC) starting at buffer 0. The second
frame is written in the buffers before the first packet is copied away
by the EMAC task - after 6 received buffers the EMAC got an overrun as
it has no free blocks. We have a fragment of a frame in the buffers
10-15. Now the EMAC task copies away the 10 buffer packet and frees the
EMAC buffers 0-9. A next packet of 11 frames is received by EMAC and
written in the (now free) buffers 0-9, causing another overrun due to
missing space for the 11th frame.
What we will find now are 16 EMAC buffers with the set ownership bit,
two of them has a "Start Of Frame" set, but no one has the end frame
included with the total frame length, as both end frames were skipped
due to the overrun.
If however this situation occurs, the first while loop in the function
will happily find a buffer with SOF at its position, so freeing no
buffers. The second loop will be infinite as there is no block with a
cleared ownership bit and no "last block" with the length in it.
Just theory at the moment, but a possible scenario which may happen
sometimes. I will change the second loop in that function, so that after
NB_RX_BUFFERS cycle the loop will exit and free all Rx buffers. I will
report if i see any crashed in promiscuous mode after this.
Marco