Re: writing OOPS/panic info to nvram?

From: Remco Post (r.post@sara.nl)
Date: Wed Sep 04 2002 - 09:23:04 EST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On woensdag, september 4, 2002, at 04:08 , J.A. Magallon wrote:

>
> On 2002.09.04 Remco Post wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On woensdag, september 4, 2002, at 02:54 , Morten Helgesen wrote:
>>
>>> On Wed, Sep 04, 2002 at 01:49:12PM +0100, Alan Cox wrote:
>>>> On Wed, 2002-09-04 at 13:31, Morten Helgesen wrote:
>>>>> True - the 'normal' size on a PC is apparently something like 114
>>>>> bytes ...
>>>>> I guess we could use it for something useful ... but maybe not for
>>>>> OOPSen/panics.
>>>>>
>>>>> I didn`t realize we only had 114 bytes to work with.
>>>>
>>>> We don't. They are all used by the BIOS
>>>
>>> That makes it even less useful. Oh well.
>>>
>>
>> For PC style hardware it does. For other platforms, it's stil nice to
>> be
>> able to see the oops info on an unattended crash (all crashes? ;) Dump
>> to nvram, dump to file after boot.... Other option is to crash-dump to
>> swap... Question is, do you really want to do that?
>>
>
> Instead of swap, let user specify a partition to raw dump there. If a
> user
> wants crash dumps, he has to leave some small disk space free and give
> an
> option like "dump=/dev/hda7".
>
>

Mjah,

swap can be destroyed during a crash dump, so why not use that?
Everybody else does it (AIX, Solaris, IRIX) so if none of the commercial
UNIX vendors see a problem in using swap for dump, why should we?

I like the nvram option best for hardware that allows a oops output to
be stored in nvram, since that is also usable on diskless systems when
the network is down (or the network driver oopses) or when the disk
driver oopses... Maybe do something like:

if there is enough space on disk && ..., use that else
if there is a swap over nfs && ..., use that else
if there is a tape drive attaced and a tape is present and it is
writeable... else
if there is nvram available use that

and print on the console....

maybe this is all a bit overkill for what we need to do, maybe not... I
guess it would make it possible to debug systems that are just sitting
there by themselves, and have some curious problem...

- ---
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl
High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
PGP keys at http://home.sara.nl/~remco/keys.asc

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE9dhdQBIoCv9yTlOwRAsm0AJ40VJx5QmhrI7ME4w02WyM3Vn9X6wCcDMyq
M8Dp4XhDjSkKtEO3rbLlwxo=
=YtBZ
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:21 EST