Correction to the "Ethernet problem"

[Leon Pollak]

Thomas, hello.

Sorry to turn to you solely - I think that nobody understands this like you, 
if at all.

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? 

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.