LWN: Comments on "Persistent storage for a kernel's "dying breath""

ACPI links

naesten — Wed, 10 Jul 2024 20:31:51 +0000

The PDF link has gone stale. Either see the Wayback Machine for the ACPI 4.0a PDF or the HTML version of ACPI 6.5 (the latest at this time).

Persistent storage for a kernel's "dying breath"

TIRTH007 — Sat, 09 Jan 2021 15:38:19 +0000

Can we use this pstore utility for our normal system (embedded device) ? Which is not server.

Persistent storage for a kernel's "dying breath"

mjg59 — Thu, 19 May 2011 14:46:58 +0000

Modern macs implement it as an EFI variable. Unsurprisingly, their implementation is incompatible with the EFI spec's implementation of the concept.

Persistent storage for a kernel's "dying breath"

kayabek — Thu, 19 May 2011 14:37:26 +0000

This idea is not new. Macs have had such a device for ages.

Persistent storage for a kernel's "dying breath"

cbf123 — Fri, 01 Apr 2011 19:20:24 +0000

If the vendor provided storage for ERST, then pstore would work on a normal PC.

If no hardware storage is available, the next best option is to use "kexec -p" to set up a recovery kernel that uses kexec to take over on a panic. The init scripts can then be modified to detect when they're running under the recovery kernel, and they can just dumps the original kernel memory to disk and then reboot.

crashdump to write logs

Tobu — Sat, 26 Mar 2011 11:28:32 +0000

A while ago LWN explained a proposal of using kexec to debug crashes. One prepares a crashdump kernel in some reserved memory area, and when the system crashes, it kexecs into the new kernel which can then write back a big core dump of the crashed kernel. Here are the kdump docs.

It seems like both kernels could be extended to dump and read logs in some ram area, which doesn't require hardware support and could be a fallback when there is no persistent area for pstore. Those logs can then be read without requiring kernel debug symbols or a kernel hacker to make sense of the kdump image.

Persistent storage for a kernel's "dying breath"

mjg59 — Thu, 24 Mar 2011 13:57:35 +0000

Not reliably, no. The only persistent storage that's guaranteed on a BIOS-based PC is the real time clock, and there's not really enough space there. EFI actually helps here(!), although right now we don't implement the bits of the spec that cover this.

Persistent storage for a kernel's "dying breath"

ebirdie — Thu, 24 Mar 2011 13:52:29 +0000

The article reminded me about some very old article of writing oopses to a block device, like swap. At then the conclusion was that it isn't wise since a block device might be at stage of mayhem and there is data at stake. Still I find it appealing, that there could be a block driver for pstore and it is at sysadmin's choice to use it or not. The block driver could be configured to use a USB-storage or whatever storage auxiliary to data storage. I guess the main point is that the sysadmin is very very aware to place the pstore behind some other subsystem than the system's main storage.

Persistent storage for a kernel's "dying breath"

rwmj — Thu, 24 Mar 2011 13:39:11 +0000

On ordinary PCs, can RAM be reserved that is preserved across a reboot?

I'd love this feature, if it was able to tell me why some box silently rebooted overnight.

Rich.