Correction to the "Ethernet problem"

[Leon Pollak]

Thanks, Ian and Thomas.
Below are my thought and test results.

On Friday, 1 February 2008, Ian Caddy wrote:
> > 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.
I noticed that very rarely, but tx packet is not shown by tcpdump too.


> Is your Ethernet MAC driver your own or are you using a standard one?
I can say that it is my own. But it strictly tries to follow the mbx860 
driver.


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


> 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).
Yes, there is. And I did this and saw that the first in-packet is passed and 
processed as required. BUT THE FIRST RECEIVED IS NOT THE FIRST SENT!
The sniffer shows that there was a packet sent to the box, but there are no 
traces of this event in the box - neither HW nor SW say they saw it.


> > 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.
I am not specialist in this.
But what I see is that without any indications and observable causes the first 
rx frame ALWAYS does not arrive after HW reset. And PHY's are connected to 
the reset.

Contrary, if I simply rerun the code from the boot point by setting program 
counter to the reset value, I NEVER loose a package!

--

On Friday, 1 February 2008, Thomas Doerfler wrote:
> 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?
Yes, they both are connected to the same reset line.


> 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.
Almost. Again, I observed the case when I did not see TX packet exiting, 
although I can not reproduce this often.


> 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.
The schema follows exactly the driver for mbx8260. 
The ISR checks both interrupts independently and sequentially, starting from 
RX interrupt.
I also checked that there are no pending/lost interrupts - this may be traced 
in buffer descriptors too.


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



So, aren't these the PHYs?
---------------------------

Many thanks to both of you for your help.
-- 
Leon