Slashdot Mirror
Spirit 'Will Be Perfect Again'
G. Holst writes "NASA technicians are preparing to wipe Spirit's flash memory clean of science and engineering files that have stymied its software. The fix, likely to be made Friday, could completely restore Spirit. "I think it will be perfect again," says the Mission Manager. Chalk this one up for earth!" There are numerous stories about Spirit and Mars: one describes being careful with rm -rf. Reader Tablizer sends in an interesting site: "I discovered Bill Momsen's website where he describes his experiences working on the first successful photographic mission to another planet: Mariner IV to Mars."
VxWorks in my experience is terrible at memory management, and when you get close to the "edge" it becomes almost useless. Not just with Flash memory either. Even when managing a very large disk system I always try to keep at least 20% free.
They're deleting all the telemetry and science data Spirit's taken since launch. The OS is in the EEPROMS. With one exception, they can repeat all of the measurements & photos that will be lost. The exception: As one of the orbiters happened to fly directly overhead it took some atmospheric measurements; and, simultaneously Spirit performed the same measurement from the ground -- This would have given them a full thickness measurement of what was going on in the atmosphere at that moment.
As I understand it, the first thing they did once they got Opportunity on the ground was to clear out all the spaceflight 'cruise' data.
I imagine that someone is keeping an eye on it.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Someone here with VXworks experience explained this a few days ago. To be safe, the system reboots when a memory allocation request fails. It sounds like Windows tech support, step 1: reboot computer. The workaround is to prevent those requests from failing.
-B
Ummmm, there is. The OS is in the EEPROM. That's how they recovered it: reboot from EEPROM with the Flash disk turned off.
It's not so much that VxWorks reboots when a memory allocation request fails. It that the memory allocation request will cause the kernel to crash & later a watchdog timer will interrupt the processor & force it to reset.
rm -- -rf
Or just use your favorite GUI file manager.
Released versions of VxWorks do not have protected memory. (The development version does.) So nothing is there to prevent overwrites by concurrent tasks, etc.
Those of you in the audience experienced in embedded systems know that this makes sense for embedded hardwar -- VxWorks or not -- for three main reasons:
Stuff running in such environments is damn near bug-free. It's not like, say, Mozilla, or even the Linux kernel, or even /bin/ls. These things get tested rigourously, not as an afterthought deligated to the junior programmer.
In systems which are allowed to fail once in a while, reboots are fast. There's no hard drive to spin up, no filesystem to fsck, etc. It can just go *click* and humans won't typically see an interruption in [whatever it was the doohickey was doing].
There's usually no point in memory protection. If the propulsion system walks off the end of a garbage pointer, mission's over. No real use in keeping the guidance system going; it's already on a ballistic uncontrollable arc. If some critical part of the super-smart pacemaker fails (see #1), there's no victory in digging the device out of the corpse and saying, see, this other critical part wasn't affected, thanks to the memory protection! In those cases, memory protection just increases the cost and size of a device, without helping anything.
Protected memory is good for systems which do more than one thing, and/or have parts which can die without killing the whole device (e.g., a desktop computer). And as I said above, some embedded OSes are added such protection for customers who want to adapt their technology to more general-purpose tasks.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)