Re: Back from the Brink -

Post #137,612 by deSitter 1/25/04 12:19:27 AM Reply	Re: Back from the Brink - Still, this was a basic design screwup in the software - a computer should never continuously reboot like that. Why am I in doubt about the skills of younger programmers? And why do I suspect C++ as the culprit? -drl
Post #137,663 by jake123 1/25/04 12:17:22 PM Reply	Continuous rebooting If there was hardware damage, then the software is outside it's spec range, and anything can happen, including continuous rebooting. If the flash is damaged (say some bits were flipped by a stray cosmic ray), it might very well be that the third instruction on boot is a branch to the first instruction... which is a go gently into that good night scenario. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #137,666 by deSitter 1/25/04 12:58:02 PM Reply	Re: Continuous rebooting C'mon Jake, even an IBM PS/2 would run a POST and halt if hardware problems were found. This sounds like it was loading something from corrupted flash RAM - it should have never got that far. Did an impatient engineer insist on a quick POST without full checks of the hardware? :) Anecdote: The first lunar landing was nearly aborted because debugging code was not properly backed out of the production software (actually firmware, magnetic core ROM :) This piece of code was meant to simulate a broken rendezvous radar on an IBM 360 LM hardware simulator - the break was to get the computer to try to calculate an angle with both a sine and a cosine of 0 - impossible. The code would not execute on landing because the rendezvous radar was supposed to be turned off - however an error in procedures caused the radar to be left on during the landing, and the bad code started stealing cycles and eventually overloaded the computer several times during the actual landing! The computer was designed to restart with the last "state vector" of the LM's position and velocity, so the landing went on as planned. -drl

Welcome to IWETHEY!