Correction to the "Ethernet problem"

[Ian Caddy]

Hi Leon,

Look like we are getting closer now... ;-)


Leon Pollak wrote:
> On Monday, 4 בFebruary 2008, Thomas Doerfler wrote:
>> Leon,
>>
>> Leon Pollak schrieb:
>>>> Apart from this hint: maybe you can check/eliminate part of the
>>>> communication path, by directly connecting the PC and the RTEMS system
>>>> using a TP crossover cable.
>>> I think this was the most productive idea..:)
>>> To rework the cables was the problem, but I connected my PC and the box
>>> via the old 10BaseT HUB and, meanwhile, I am not able to reproduce the
>>> problem - nothing is lost!
>> When changing from 100Base-T Switch to a 10MBit Hub, you change several
>> things:
>> - The bit rate is slower
>> - All connections work in half-duplex instead of full duplex
>> - This also means you MIGHT get collisions (which is implossible, I
>> think, in full duplex)
>> - The Hub is a really dumb "repeater", which multiplies a bitstream
>> coming in to all ports in realtime
>> - A switch learns and forgets:
>>
>> It learns, which MAC addresses are available at which port (which source
>> MAC addresses come from a certain port), and directs any packet only to
>> the port which corresponds to the destination MAC address. So, before it
>> can route a packet to your system, your system must have sent a packet
>> with its own MAC address in the source MAC address field. Only then the
>> switch knows where it is connected.
>>
>> And the switch forgets: When it has not received a certain MAC address
>> for a while (about 15 minutes, I guess), then it erases the proper MAC
>> address from its routing table.
>>
>> Can you check, wheter the packet loss only occurs after about 15 minutes
>> of non-traffic with your system?
> No! It is always lost after I do HW reset (via BDM). And never - when I 
> restart the program jumping to boot vector (after it was loaded after reset 
> via BDM and run once). All these runs are done in 2-3 minutes, not more.
> 
> 
>> In that case it would be worth to put in a different (higher-quality)
>> switch, which does the learning faster. Actually I never herad about a
>> switch learning too slow, but ethernet and its protocols rely on the
>> fact, that packet may get lost, so the effect would not be obvious in
>> most cases.
> Well, the switch theory is clear.
> But isn't the first arp request enough for the switch to learn that RTEMS box 
> has that MAC address? Actually, even the first arp "box to itself" should 
> teach it were is it, no?
> Besides, IMHO, this can not explain the loss of INCOMING packet after two 
> outgoing were sent and I saw them in my PC via the same switch.

 From your debugging it looks like it is something to do with the PHY 
interaction with the particular switch.

Are you using an external PHY?  If so, do you have the part number?

Does you firmware initialise the PHY at all or do you expect it to come 
up in the correct state?

Is there an interrupt line from the PHY?  If so, do you service this 
interrupt line?

It is possible that something is happening with the PHY on the 
completion of the negotiation or reception of the first packet, and it 
may want to tell the MAC about it.  I am just clutching at straws here 
though... ;-)

regards,

Ian Caddy

-- 
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9444 2634