hmp@cive.ri.cmu.edu (Henning Pangels) (05/23/89)
I am using an MVME147A-1 (25MHz, 8MB version) board running vxWorks, and am experiencing a bizarre problem: Given enough time, the board will freeze up, requiring a reboot. The amount of time varies from seconds (sometimes it dies while loading the symbol table) to hours, but eventually (e.g. overnight) it will always hang up. The problem seems to be related to the ethernet interface, since it doesn't happen if I disconnect the ethernet cable after boot-up. Wind River has confirmed the existence of the problem, but nobody seems to know what to do about it. I would appreciate hearing from anyone out there who has the same problem -- better yet, someone who has a fix for it! If I find a solution, I'll post it here for everyone's benefit. Henning Pangels Field Robotics Center Robotics Institute Carnegie-Mellon University ARPAnet/Internet: hmp@cive.ri.cmu.edu (412) 268-6557 --
rdt@genrad.UUCP (Ron D. Thornton) (05/25/89)
In article <5040@pt.cs.cmu.edu> hmp@cive.ri.cmu.edu (Henning Pangels) writes: >I am using an MVME147A-1 (25MHz, 8MB version) board running vxWorks, >and am experiencing a bizarre problem: Given enough time, the board will >freeze up, requiring a reboot. ... > The problem seems to be related >to the ethernet interface, since it doesn't happen if I disconnect the I got involved with the MVME147A-1 and vxWorks here to do the evaluation of its network performance. After hanging up vxWorks several times with my test program I began to suspect the problem was not my code. We finally simplified the test case. Using a LAN analyzer we send 60 byte ethernet frames to the 147 card using the correct hardware ethernet address, a type code of 00-00 and data of all 0's. At 1% ethernet bandwidth load the 147 card continues to function. At 2% the 147 card quickly freeze up. It will continue to echo characters typed at the console port but executes no commands. The board will only recover by reboot. The board is only sensitive to traffic that it is forced to read off the net (broadcasts would probably cause the same problem). It is not affected by traffic that is ignored in hardware by the lance ethernet address filter logic. We can use the LAN analyzer to generate traffic at >40% network bandwith using the analyzer address for the destination, and the 147 continues to run. We are currently working with Wind River to find out what is happening and how to fix it. -Ron-