On Sat, 8 Apr 2006, Andi Kleen wrote:
> On Saturday 08 April 2006 16:05, Robert Hancock wrote:
>> Andi Kleen wrote:
>>> James Courtier-Dutton <[email protected]> writes:
>>>> Now, the question I have is, if I write values to RAM, do any of those
>>>> values survive a reset?
>>>
>>> They don't generally.
>>>
>>> Some people used to write the oopses into video memory, but that
>>> is not portable.
>>
>> I wouldn't think most BIOSes these days would bother to clear system RAM
>> on a reboot. Certainly Microsoft was encouraging vendors not to do this
>> because it slowed down system boot time.to
>
> Reset button is like a cold boot and it generally ends up with cleared
> RAM.
>
> -Andi
Further, in a boot where the BIOS needs to initialize hardware,
It will write all RAM before enabling NMI. This makes sure that
the parity bit(s) are set properly. Most BIOS will attempt to
preserve RAM on a 'warm' boot as a throw-back to the '286 days
with their above-1MB-memory-manager paged RAM because the
only way to get back from protected mode to 16-bit real mode
was a hardware reset. When using a memory-manager like DOS's
HIMEM.SYS, you might actually be rebooting the machine hundreds
of times per second!
If you want to make a flight-data recorder, you need to use
FAA specs and, as such, you can't rely on second-order effects.
You will need write all the parameters to flash (or equivalent)
at least 10 times per second. I would advise against putting
a file-system on the flash because the file-system might get
corrupt because of a bad write during a crash. Instead, I would
write a large number of identical groups of parameters (a structure
image) at a large number of raw offsets, each with the required
time-stamp. This, done the required 10 times per second.
Note that the NTSB, in investigating some light airplane accidents,
has been successful extracting data from hand-held GPS receivers
and FADEC controllers, so using flash RAM for accident investigation
has some successful history (useful for obtaining certification).
I once proposed a FDR for light aircraft that would cost the end-user
under $2,000. This was to use a small embedded CPU, raw NAV inputs
from the panel, a cheap accelerometer, and some pressure sensors
for altimetry. This would be mounted in the tail, requiring no
user (pilot) input at all. In the event of a crash, the last
hour of flight could be retrieved.
Typical response; "There is no market for this...."
Good luck!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
