Re: KMSGDUMP: dump kernel messages to a diskette

Riley Williams (rhw@MemAlpha.CX)
Wed, 7 Jul 1999 13:56:12 +0100 (GMT)


Hi Ralf.

>> One thought: The main objection to the idea of dumpiing to disk
>> has been in connection with the fact that at the time the dump
>> is needed, it might not be possible to get reliable details as
>> to where to put it on the disk.

> The classic answer is using the swapspace for the dump from
> where a savecore program will copy the coredump to
> /var/adm/crash/ and eventually do some analysis and further
> processing of the dump.

>> To me, the obvious answer to that is to have the dump driver
>> hold a local pointer to the relevant location, initialise it at
>> system boot, and have hooks in the mount and sync routines to
>> ensure it's still valid.

> A more interesting issue is how you'll handle the state of all
> the kernel locks.

There are two separate issues here, and it looks like I'm discussing
one and you're discussing the other, so let me clarify...

1. Dumping to floppy diskette. The routine to do this needs some
way of knowing what capacity diskette is available, and the
fact that the system has panicked indicates that the normal
kernel detection routines will not be reliable.

The obvious solution to this is to have the routine get these
details when the system starts up, and also for it to have hooks
into the mount/unmount routines so it can keep track of whether
the floppy drive is currently mounted, and into the sync routine
so it can sync any data to floppy before unmounting it.

2. Dumping to hard disc. There is a veritable minefield of issues
to deal with here, not least the fact that such assumes that the
relevant controller subsystems are still working. I do not even
intend to begin to wade into those murky waters, sorry.

Whilst I was discussing issue (1), your comments lead me to believe
you were discussing issue (2). Am I correct?

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html

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