Messages in this thread | | | From | BROWN Nick <> | Subject | RE: Oops assist... | Date | Thu, 6 May 1999 14:09:43 +0200 |
| |
>at least on cold power-on you first have to write something to RAM >to initialize the parity bit(s). if you try to read RAM first, >odds are 50% that the parity bit is wrong and you'll get an NMI...
Clearly across a cold boot nothing can be saved (until SRAM becomes available in 128 MB strips for $150), not least because the BIOS will have zeroed memory for us, but an awful lot is possible across the _right kind_ of warm boot.
Consider how DOS extenders get back from 286 extended mode to real mode. (Intel's designers provided no mechanism to do this, and literature circa 1990 tended to suggest that this was a huge design oversight. But of course, their model was a _proper_ OS which just uses real mode during boot. This was before compatibility with Microsoft bugs was the main factor driving chip design.) The processor is reset (yes, the keyboard controller gets told to pull down the CPU reset line, and the CPU jumps to FFFF:0000). But first (busking here - no BIOS manual to hand), the DOS extender writes a magic value (4321h ?) to a magic BIOS data area word, which tells the BIOS that it shouldn't trash the state of memory, execute part of the POST, etc, but should instead transfer to <EOF on my knowledge of this, but you get the idea>.
If current BIOSes support DOS extender functionality in this way, it might be possible to harness this to do a controlled panic/crash/reboot. Any [former] employees of Phar Lap, Rational, etc who can maybe supply more info ?
Nick Brown, Strasbourg, France (Nick(dot)Brown(at)coe(dot)int)
__________________________________________________________
email address updates : @coe.int replaces @coe.fr for more information, http://dct.coe.int/info/emfci001.htm __________________________________________________________
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |