Back from the Brink -

Post #137,566 by Ashton 1/24/04 8:44:30 PM Reply	Back from the Brink - Seems they latched onto a diagnosis of 'bad flash memory'; were able to restore basic functioning with orders to eschew flash -for now-. Then - it was time to go beddy-bye. So it seems that communications are restored.. also it appears: their Fire-Ax fallback, "break glass and use This" planning wasn't too shabby. Guess: once control is orderly - bet they can test, reformat flash, possibly mapping around heavy-ion blasted? bad elements. If not successful, then - RAM will be limited to perhaps less sophisticated command storage for next events. I kinda doubt there's a HD within 50M miles. Rates a Whew!
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!