Re: Black box flight recorder for Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 10 Apr 2006, Krzysztof Halasa wrote:

> "linux-os \(Dick Johnson\)" <[email protected]> writes:
>
>> 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.
>
> I think there is no distinction WRT RAM test between cold and warm
> boot anymore. If the BIOS clears the RAM is, I think, determined by
> the "fast POST" option in BIOS setup (it always checks the size
> so some bytes will be changed anyway).
>
>> When using a memory-manager like DOS's
>> HIMEM.SYS, you might actually be rebooting the machine hundreds
>> of times per second!
>
> Yes but it uses (or, rather, used) a CMOS flag to skip POST (not only
> the RAM test) and to go directly to the entry point in real mode.
>
> IIRC (I may be wrong, that was 15+ years ago) only 286 required
> KBC reset to return to real mode (did LOADALL matter?), 386s have
> no such problem.
>
>
> BTW I understand the idea have nothing to do with actual aircraft,
> so it would be the admin rather than NTSB looking at the data(?).
> --
> Krzysztof Halasa

Yes. After I responded and after reading other responses I noted that
the idea was to review the reason for a PC crash. There are no
good places to store things that can be counted upon to remain after
a crash. Even though CMOS RAM goes to 0x7f and not all of it is
needed for BIOS setup, many/(maybe all) BIOS checksum the whole
thing with some hair-brained checksum routines so it's not a good
place to store things. Many BIOS use 128k or more, which can
be re-written in 64k pages. Certainly there is space available
...but... the BIOS would be trashed if a power-failure occurred
during the write, so that's not a good place either. I did, at
one time, use a "spare" page of screen memory (one that wasn't
displayed) during the boot process (buffering for a bootable NVRAM
disk). This is "available" RAM, but it isn't going to survive
even as screen-card reset!


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]
  Powered by Linux