Hi,<br><br> Do your boards use the MPC5200B or MPC5200? Also, do you ever see any corrupted data? (I'm guessing you would have mentioned it if you did see corrupted data)<br><br>Regards,<br><br>Dave<br><br><div><span class="gmail_quote">
On 4/27/07, <b class="gmail_sendername">Eberhard Stoll</b> <<a href="mailto:eberhard.stoll@berghof.com">eberhard.stoll@berghof.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;">
Hi,<br>> I've the same problem by running MPC5200B, but under MQX ...<br>><br>Did you check/compare already some registers with mine?<br>Maybe it could be a hint for a hardware problem in the (RevB) processor<br>
- or a hint for two different drivers which have the same problem :-)<br>>> This situation is very rare - only a constellation with 6 Controllers<br>>> and a special ethernet communication load leads to this fault - in about
<br>>> one day!<br>>><br>No more! Now i can reproduce the fault in between 10 to 30 minutes in my<br>office!<br><br>Try this:<br>1) Use two mpc5200 boards and a pc which can telnet into the<br>controllers. I use 100M
<br> FullDuplex settings for the link.<br>2) Now telnet into the controllers and start on all controllers a flood<br>ping. E.g:<br> # ping -f <a href="http://10.255.226.70">10.255.226.70</a><br> on <a href="http://10.255.226.71">
10.255.226.71</a> and a<br> # ping -f <a href="http://10.255.226.71">10.255.226.71</a><br> on <a href="http://10.255.226.70">10.255.226.70</a>. So both controllers ping each others. You can<br>watch the<br> dots in your telnet session.
<br>3) After some minutes (about 10 to 30 minutes) one of the two<br>controllers doesn't<br> respond any more. It shows a slow blinking rx led, the link is<br>still ok, but the<br> controller doesn't respond any more. In the telnet session you can see
<br> running points on the other controller mixed with some 'E's. In the<br>telnet<br> session on the other controller you see Ethernet is dead.<br> =====================================================<br>
Congretulations, now you have reproduced the fault!<br> =====================================================<br><br>It seems that this fault only occurs if the ping is done thru a telnet<br>session. Logging into the controller on the serial console and doing the
<br>pings won't trigger the fault (at least not so fast). This might be a<br>timing issue or has to do with Ethernet utilisation. ping -f prints some<br>points for transmitted ethernet frames. In case of a telnet session ping
<br>produces 2 packets at the same time. One for the ping and another for<br>the dot in telnet!<br>If i do a 'ping -f <a href="http://10.255.226.71">10.255.226.71</a> > /dev/null', which suppresses the<br>output now run for hours ...
<br><br>Eberhard<br><br>______________________________________________________________________<br>This email has been scanned by the MessageLabs Email Security System.<br>For more information please visit <a href="http://www.messagelabs.com/email">
http://www.messagelabs.com/email</a><br>______________________________________________________________________<br>_______________________________________________<br>Linuxppc-embedded mailing list<br><a href="mailto:Linuxppc-embedded@ozlabs.org">
Linuxppc-embedded@ozlabs.org</a><br><a href="https://ozlabs.org/mailman/listinfo/linuxppc-embedded">https://ozlabs.org/mailman/listinfo/linuxppc-embedded</a><br></blockquote></div><br><br clear="all"><br>-- <br>David Kanceruk
<br><br>"The generation of random numbers is far too important to be left to chance."