> > Well, in that case you could use 0xa, which is handled by all i386 and
> > newer BIOSes, AFAIK, and requires less messing.
>
> 0xa does immediately branch to the address given at 40:67, whereas 0x9 does
> a little more before. On my computer, (asus P5A, K6/2), it seems to
> reinitialize something in the PCI chipsets, so it may be better than 0xA.
This indicates it's even less standard than I suspected -- in the 286 and
386 days 0x9 used only to pop registers off the stack in a predefined way
and then execute retf. If you want to perform some initialization then
0x5 performs exactly what 0xa does but additionally it resets the 8259s to
PC defaults.
> it must be the case because these functions were designed exactly for that use,
> ie. jumping from protected to real mode and execute a given code to eventually
> switch back to protected mode. Normaly, only the CPU reset line is activated
> by an out 0x64,0xfe, so nothing else should be lost on the motherboard.
I meant the memory got clobbered before -- as the reason or the result of
kernel crash.
> OK, sorry. I thought you meant "trying to do the best to get back to a
> more or less stable kernel".
One might try to recover the running kernel from a triple-fault but I
wouldn't dare performing any execution but creating a crash log
afterwards.
> One other problem I didn't speak about concerns people using loadlin. Their
> interrupts might redirect to DOS drivers such as smartdrive, in which case
> no dump would not work.
There might be a "well-known" BIOS entry point which could help here. I
don't have the list of BIOS entry points handy but BIOS developers still
seem to keep compatible with the IBM's original.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
- 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/