Re: KMSGDUMP: dump kernel messages to a diskette

Willy Tarreau (willy@novworld.Novecom.Fr)
Thu, 8 Jul 1999 21:43:27 +0200 (CEST)


> > at the moment, I use the 0x9 code which makes the bios do some very little
> > hardware initialization and does a RETF from a stack passed by my program.
>
> 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.

> Neither are safe, anyway,
> because they require RAM contents to be valid which might not be the case.
> And executing from clobbered RAM mau cause further destruction -- e.g.
> some unwanted hard disk writes.

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.

>
> > > Other options are either not defined precisely or need data from RAM,
> > > which might already be trashed. In the latter case it's better to halt or
> > > reboot than to try to recover.
> >
> > I've found only one case in which it would be interesting to try to recover,
> > it's when the user sees his host going down, and first wants to get the dump,
> > and after that, he'd like to try to unmount his filesystems, but... it's too
> > late. People must know well that by pressing Alt-SysRq-D, they won't be able
> > to get back.
>
> Writing "to recover" I meant to start the boot loader, which might in
> turn dump the memory to swap, for example, just as it's done by OSes for
> non-ia32 platforms.

OK, sorry. I thought you meant "trying to do the best to get back to a
more or less stable kernel".

>
> You still are not sure all components are back to whatever settings BIOS
> would like to use. Note that for the case of a floppy you might need to
> set up some values within BIOS data area, not only interrupt vectors.

yes, I know. But since there are lots of places to look at (0:78, 0:522, ...)
I prefered find what differed from 2.2.10 and 2.3.5 concerning this.

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.

Willy

-
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/