[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Correction to the "Ethernet problem"
- Date: Thu, 31 Jan 2008 20:54:21 +0200
- From: leonp at plris.com (Leon Pollak)
- Subject: Correction to the "Ethernet problem"
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...
> 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.