Ok, we found the root cause. It is the MARVELL PHY 8e1111 which was to blame. The PHY needs an explicit RESET after any changes are done to the config. After doing this, the problem goes away.<br><br><div><span class="gmail_quote">
On 2/22/07, <b class="gmail_sendername">Gary Kenaley</b> <<a href="mailto:gkenaley@echelon.com">gkenaley@echelon.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div dir="ltr">
<div dir="ltr"><font color="#000000" face="Arial" size="2">I see a similar problem on
the MPC8349E MDS (V1.1 CPUs) in that the first ping or tftpboot
command often doesn't work in u-boot 1.1.3 or (much less often) Wind River Linux
kernel 2.6.14. The problem seems least severe on a node-to-node gigabit
connection and most severe on a public 100BT network. I haven't been able to
isolate the cause, but the severity seems dependent on the driver
characteristics of the equipment that the 8349 is communicating with. In my case
I also see very erratic ping times to the NFS server (dependent on how Kudzu
configured its e1000 driver). The 8349 sometimes slows to a crawl and fills
the logs with watchdog messages when it mounts NFS partitions and hits the
INIT phase of boot-up. This is all with out-of-the box software from Motorola
and Wind River. Maybe we will have better luck with the V3.0 CPUs? I wish I
could use 2.6.18, but I'm stuck at 2.6.14.</font></div>
<div dir="ltr"><font face="Arial" size="2"></font> </div>
<div dir="ltr"><font face="Arial" size="2">Regards, Gary</font></div></div>
<div dir="ltr"><br>
<hr>
<font face="Tahoma" size="2"><b>From:</b>
linuxppc-embedded-bounces+gkenaley=<a href="mailto:echelon.com@ozlabs.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">echelon.com@ozlabs.org</a> on behalf of SIP COP
009<br><b>Sent:</b> Thu 2/22/2007 9:14 PM<br><b>To:</b>
<a href="mailto:linuxppc-embedded@ozlabs.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">linuxppc-embedded@ozlabs.org</a><br><b>Cc:</b>
<a href="mailto:sipcop009@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">sipcop009@gmail.com</a><br><b>Subject:</b> Gianfar on 8347 sometimes get stuck at
startup<br></font><br></div><div><span class="e" id="q_110ed36a632b0359_1">
<div>
<div> </div>
<div>We have the our own MPC8349 based board which has 2 GigEs. It is
pretty much modelled similar to the 8349ADS EVAL boards, infact we have zero
changes.</div>
<div> </div>
<div>The issue that we are seeing - </div>
<div> </div>
<div>Sometimes at startup, we have send 2 TX packets to kind-of-kickstart the
TSEC Tranmission. If we send only packet it does not get to the other side. This
does not happen always.</div>
<div> </div>
<div>The TSEC Registers dont really show any errors nor does the Marvell PHY
show any errors.</div>
<div> </div>
<div>The kernel that we are using is 2.6.11.</div>
<div> </div>
<div>Anybody seen this before or something similar ? </div>
<div> </div>
<div>Any pointers will be appreciated. We cannot move to any other kernel
verision right now.</div>
<div> </div>
<div>Thanks!</div>
<div>ashutosh</div>
<div> </div></div></span></div></div>
</blockquote></div><br>