[Avila] fatal ethernet error on gw2348-4

[David Acker]

The port is not part of a bridge.  It is in promiscuous mode and is 
receiving and sending a relatively large amount of traffic.  I have a 
userspace program that has a raw socket bound to each port.  I don't 
have any netfilter rules in place.

I have done some more debugging and found some information.  The failure 
  is due to 
ixp400_xscale_sw/src/ethAcc/IxEthAccDataPlane.c::ixEthAccPortRxFreeReplenish(...) 
thinking that the length is too small.  See the following test:
if (IX_OSAL_MBUF_MLEN(buffer) < IX_ETHNPE_ACC_RXFREE_BUFFER_LENGTH_MIN)

The length reported by IX_OSAL_MBUF_MLEN(buffer) is 0 and 
IX_ETHNPE_ACC_RXFREE_BUFFER_LENGTH_MIN = 64.

ixEthRxFrameProcess calls ixEthAccPortRxFreeReplenish and before the 
call it tries to reset the length with the following line of code:
IX_OSAL_MBUF_MLEN(mbufPtr) = IX_OSAL_MBUF_PKT_LEN(mbufPtr) = 
IX_OSAL_MBUF_ALLOCATED_BUFF_LEN(mbufPtr);

Before this call to adjust the lengths I have seen the lengths reported 
by IX_OSAL_MBUF_MLEN(mbufPtr) and IX_OSAL_MBUF_PKT_LEN(mbufPtr) be 
various sizes although sometimes they are below 64 (I have seen as low 
as 60).  IX_OSAL_MBUF_ALLOCATED_BUFF_LEN(mbufPtr) is reporting 0 which 
leads to IX_OSAL_MBUF_MLEN(mbufPtr) becoming 0 and the length test failing.

I am still looking into when the allocated buffer length got corrupted. 
  It could be a locking issue and/or a race condition that only happens 
at high speeds.  With any luck I will know more by the end of the day.
-Ack

Dave G wrote:
> Ack,
> 
> 
> Is the affected port part of a bridge group? Do you have any netfilter 
> rules in place either using bridge nf or not?
> 
> 
> -Dave
> 
> 
>> Hello folks,
>> We are running the .06 development kit on our gw2348-4 board.  If we 
>> run it long enough with even small amounts of ethernet traffic we 
>> eventually get the following error:
>>
>> [fatal] ixEthRxFrameProcess: Failed to replenish with filtered frame 
>> on port 0
>>
>> After this error the port usually does not receive at all but can 
>> send. For example, when I ping an ethernet client that has ethereal 
>> on, I can see the ARP requests, and I can see the client send the ARP 
>> response, but the board's arp tables do not show ever getting the 
>> response.  The port stays in this state through unplug/replug of the 
>> cable.  Sometimes it stays in this state through a reboot command.  It 
>> always clears up on a full power cycle.  The other ethernet port will 
>> work when one port is in this state.
>>
>> Does anyone know what causes this error and how to fix it?
>>
>>