Correction to the "Ethernet problem"

[Thomas Doerfler]

Leon,

Leon Pollak schrieb:
> Thomas, hello.
> 
> Sorry to turn to you solely - I think that nobody understands this like you, 
> if at all.

I am trying my best...
> 
> Your last letter gave me the hint and all the day i studied and maid 
> experiments. The results are:
> 
> 1. After passing the initial problem, the driver (and the rest) works fine - I 
> did very extensive and heavy tests both on speed and load. So, the problem is 
> only in the first step.
> 
> 2. The initial problem looks strange - neither driver nor controller do not 
> see a problem. I mean that when driver says that there were no interrupts, 
> controller does not say that the packets were. This is correct for both rx 
> and tx, as I discovered that also tx packets do not exit the unit!
> 
> 3. Now, all this leads me to the following: as I am totally zero in PHYs, I 
> should like to ask you - is it possible that after reset the PHY is not ready 
> and thus some i/o that is done helps it to come to the working state? 

Normally the PHY should take some seconds (2-3) to negotiate the 
transfer parameters (10/100MBit, Full/Halfduplex...) with the switch. 
Some questions:

When does the PHY come out of reset? Together with the processor reset? 
Or do you need to pull a separate line by software? (this means that the 
PHY comes out of reset later than the processor and auto.negotiation 
might not yet be finished when you start the networking stack).

I agree with Ian, that the auto-negotiation time is not a hot candidate 
for the problem, because I would expect that the TX side will work only, 
when the RX side is ready, and obviously you can transmit properly.

I have discussed things with my collegue Peter. He gave the hint, that 
maybe the receive interrupt is not handled properly.

Rx and Tx interupts are handled in the same interrupt handler. How did 
you organize it? Did you properly implement the case, that you enter 
ther interrupt handler (due to the packet transmitted) and you have a 
transmit event AND a receive event at the same time? You should check this.

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.

Well that's it, no more ideas from our side...

Good Luck!

Thomas.

> 
> I looked into our "National 8349" PHY's manual and saw that it comes up in the 
> default auto-negotiation state. And I can see on my switch that it detects it 
> as 100BaseT line (and when I connected to the 10BasteT hub, it also 
> auto-configured itself). But may be this is insufficient for it and some 
> actions must be done?
> 
> As it is my first time with 100BaseT and PHY, I am lost...
> 
> Thank you very much for your willing to help...
> 
> Best Regards
> 
> Leon
> 
>> Leon,
>>
>> Leon Pollak schrieb:
>>> Hello, Ian.
>>>
>>> Thank you for your detailed explanation - it is very useful to know the
>>> way the stack works. Just it seems rather strange that packets are not
>>> queued, but have only one depth back log...
>>>
>>> But, to my pity, this is not the problem in my case - I have 3s pause
>>> between sequential sends.
>> obviously we were looking in the wrong direction? Maybe you do not have
>> a transmit problem, but a receive problem. Your system sends an ARP
>> request, an ARP response is sent, but since your system repeats the ARP
>> request for the next packet, it did not receive the ARP response properly.
>>
>> look at the networking statistics once again, after a "good" and after a
>> bad case. Maybe in the bad case one ARP packet was lost? Now the
>> question would be whether it was lost already on driver level, or it is
>> somewhat altered so it is not recognized properly in the network stack
>> as an ARP packet.
>>
>> By the way (I like shooting arrows in the dark) how did you ensure, that
>> the cache and the networking SDMA work coherent (think about setting the
>>   "GBL" bit in the "FCRx" Function code registers of the parameter ram.
>>
>> wkr,
>> Thomas.
> 


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.