Ethernet MAC component 2.3.3 - Configuration Issue or Bug?

[Jack]

Hi there,

we have seen a weird behaviour when using the ethernet_server_full (2.3.3) of the XMOS SoftIP.

We used a simply modification of the ARP demo attached.

- when sending simple frames via mac_tx() continusly (e.g. every 1s) all works fine
- when sending one frame, waiting for less then 21.47s and sending the next frame, both frames are forwarded as expected (with an intermission of the wait time)
- when sending one frame, waiting for more then 21.47s and sending the next frame, the 2nd frame is not send out
- waiting again 21.47s and sending a frame, the frame is forwarded again
- this behavior (working/blocking/working) alternates every 21.47s

Has anyone experienced this kind of behaviour so far? Is this an configuration issue? The value of 21.47s suspects that there might be an overflow of an integer value, but we where not able to figure out at what point of the source code this might happen.

Thanks for the support!

[Redeye]

I have a suspicion I'm experiencing the same bug at the moment. I have an application using sc_ethernet v2.3.2 which is working fine apart from that it sometimes becomes unresponsive on the ethernet when trying to connect to it. I've tracked this down to something related to ARP - when it gets a multicast message it needs to reply to it sends (or tries to send) an ARP request, but it takes about 20 seconds to get a reply.

I've been trying to figure this out for quite a while - it's not a catastrophic bug, but it's very annoying. The curious thing is that it never used to have this problem when building with sc_xtcp v3.1.2rc0 and sc_ethernet v2.2.5rc0. However, there was another more serious bug in sc_ethernet v2.2.5rc0 which caused the ethernet stack to crash if you went online to lots of devices at the same time.

Right at the end of the day yesterday I was getting some success building with sc_ethernet v2.2.7rc1 which seemed to resolve the ARP bug but I ran out of time to test more fully. I've got to do other things today but I'm hoping to have a day getting to the bottom of this next week.

Looking at the git history :

https://github.com/xcore/sc_ethernet/commits/master

There appear to be only two significant changes between v2.2.7 and v2.3.2 - a fix for an IFG bug and an alteration to the timing on the LAN8710A. So, if further testing shows that v2.2.7 does indeed fix the problem, the next step is to figure out which of these two changes breaks it again.

[Folknology]

Definitely sounds like a 32 Bit timer overflow issue to me with that number (2^32 * 10e-09)/2 seconds

[Jack]

It seems that this happens only in the Full Implementation, Lite Implementaion seems to be ok.

We were also suspecting that this could be an 32bit overflow of a timer but we were not able to locate this in the source code. We assume that this happens somewhere in the MII code. Is there any timer getting reset by a frame sent out?

[Redeye]

Is the problem still there if you go back to v2.2.5 or v2.2.7? I'd be interested to know if it is the same problem that I'm seeing or if I'm just talking rubbish!

[Folknology]

BTW you (Jack) should use 'unsigned' rather than 'int' for your time...
(I'm hoping you didn't try > 24.47 secs with an Int originally)

[Jack]

@redeye: Thanks for the input testing this with different versions.

We just modified the test sequence a little bit (we are sending a sequence of 5 frames in 5 seconds and then wait 25s). See attached the source code.

-> We run this with Ethernet MAC Component 2.2.7 and do not see this issue
-> We run this with 2.3.3 and we do not lose the packets, but each 2nd sequence are delayed by about 2 x 21s while in 2.2.7 we get the packets instantly. Attached are the pcaps for 2.2.7 (How it should look like) and for 2.3.3 with the delayed forwarding.

@Folknology: Thanks for the advice, of course you are right. However this seems to be an issue in the Ethernet MAC 2.3.3 code

[Redeye]

Thanks for going back to check v2.2.7 - that's helpful to me too and it sounds like we're both probably seeing the same bug in slightly different ways.

The good news is that not a lot has changed between those two versions - only two significant changes that I can see in the git history. So it should be straightforward to figure out which one causes it, then the question is why. Both of the changes are timing related, so it's very possible that Folknology is right and one of them inadvertently causes a timer overflow.

[Jack]

Just an update: 2.3.0rc0 works fine - 2.3.1rc0 shows the misbehaviour
We think the issue is in mii_master.xc because we replaced the file of the 2.3.1 with the one from 2.3.0 and it works.
-> therefor the "Re-work the inter-frame gap enforcement code to prevent invalid IFG" should have an impact on that.

[Redeye]

An update on my testing - I've programmed 10 devices with a build using v2.2.7 ethernet and haven't seen the slow response problem at all in the last two days.

The only differences between v2.2.7 and 2.3.0rc0 seem to be AVB specific so in this application they should be equivalent.