dave@graftel.UUCP (dave) (05/27/88)
The "version" control message printed below is strongly suspected of breaking our Silicon Graphics 3130 for almost a week. Our site "graftel" responded to this message but was unable to later forward a response from a downstream site. The response from "graftel" has since been to "oddjob" and returned. Path: graftel!uunet!lll-winken!lll-lcc!ames!ncar!oddjob!nosuch!sitesas!these!madeup!namesin!hereexist!ijust!addedthem!tomakethe!pathline!aslongas!theonein!theother!testmessage!thatisent!atthesame!timeas!thisone!iamsure!youseewhy!oddjob.uchicago.edu!bbtest1 From: bbtest1@oddjob.uchicago.edu (Matt Crawford) Newsgroups: news.admin.ctl Subject: version Message-ID: <test-2@oddjob.uchicago.edu> Date: 12 May 88 18:22:47 GMT Control: version Reply-To: bbtest2@oddjob.uchicago.edu (Matt Crawford) Distribution: usa Organization: University of Chicago Lines: 0 Approved: Matt The word "breaking" needs some elaboration. The machine would appear to operate normally for periods varying from a few seconds to 15 min and then freeze. Symptoms included frozen graphics and no response to any key or set of keys at the console, over a serial line or ethernet. The system never crashed and the processor was not halted. The status lights continued to cycle between 2 and 3. The system would just become totally unresponsive. Sounds like a hardware problem? The SGI field engineer thought so and spent the better part of a week testing every hardware subsystem. Removing the data and execute files for the control message from /usr/spool/uucp fixed the problem. I think it's pretty strange that a program running in user space should be able to break a machine in this way. I reported this to Silicon Graphics but as of yet have received no feedback. Did anyone else have problems dealing with this message? iamsure!idonot!seewhy!thiswas!done