Correction to the "Ethernet problem"

[Ian Caddy]

Hi Leon,



Leon Pollak wrote:
> 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.

Yes, I agree with Thomas, that you look like you are loosing that first 
receive packet containing the ARP response sometimes.

> 
> 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!

Sorry, I didn't quite understand this bit.  Are you saying that at the 
start there are no tx packets as well?  What about the ARP request that 
was sent out?  We need to find out what happens to the ARP response.

Is your Ethernet MAC driver your own or are you using a standard one?

If your own are you sure you are initing the Rx portion at the same time 
as the Tx portion?

Is there a way to breakpoint your system on the first receive packet 
that you get and trace it up into the stack?  This would show whether 
the ARP response was at least getting into your firmware and not being 
lost somewhere else. (Due to hardware not inited or something similar).


> 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?
> 

I can't see it being the PHY.  They will not transmit or receive before 
they have finished the auto-negotiation process.  As far as I know they 
don't bring up the transmit and receive paths differently.  If you can 
transmit out of a PHY (your ARP request) then I am sure the PHY would 
also be able to receive.

regards,

Ian Caddy


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