df36ac1bc2a16 ("pstore: Don't allow high traffic options on fragile devices")

df36ac1bc2a16 ("pstore: Don't allow high traffic options on fragile devices")

[Borislav Petkov]

Hey Tony,

so I was wondering whether we could finally put that UEFI thing to use
and log dmesg into it but then Matt pointed me to df36ac1bc2a16.

Even though those nvram devices are fragile and can only stomach a
limited amount of writes, wouldn't it be a nifty feature to have a
kernel cmdline param of the sort "put_dmesg_in_nvram_this_one_time_only"
which logs to nvram only once for debugging purposes.

The usecase I have in mind is all those laptops which are sporting UEFI
now and where logging to serial or netconsole or something else is
simply not an option, for whatever reason (I'm sure anyone can think of
a number of those). If we had this, it would be one step closer to the
holy grail of being able to catch dmesg even on laptops.

We could also add checks like if efivarfs already has a dump-type* file
to not log, etc etc. Eventually, it would be a user decision whether to
still log to nvram or not, i.e. brick her laptop or not.

Thoughts?

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

RE: df36ac1bc2a16 ("pstore: Don't allow high traffic options on fragile devices")

[Luck, Tony]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 818 bytes --]

> Even though those nvram devices are fragile and can only stomach a
> limited amount of writes, wouldn't it be a nifty feature to have a
> kernel cmdline param of the sort "put_dmesg_in_nvram_this_one_time_only"
> which logs to nvram only once for debugging purposes.

Speed is also a factor ... waiting for flash to update for each printk()
would mess up timing so much that you might not see the problem
you are chasing.

A better EFI trick for this would be "capsules".  They live in regular RAM
and BIOS firmware does stuff with them at warm reset time.  Matt has
been looking at them - but BIOS support for them seems sketchy to none
right now.

-Tony
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: df36ac1bc2a16 ("pstore: Don't allow high traffic options on fragile devices")

[Borislav Petkov]

On Thu, Apr 10, 2014 at 06:34:34PM +0000, Luck, Tony wrote:
> Speed is also a factor ... waiting for flash to update for each
> printk() would mess up timing so much that you might not see the
> problem you are chasing.

Gaah, there's that too. I guess nvram access speeds slower than in the
msec range (I'm looking at my printk timestamps) are no good for us.

> A better EFI trick for this would be "capsules". They live in regular
> RAM and BIOS firmware does stuff with them at warm reset time. Matt
> has been looking at them - but BIOS support for them seems sketchy to
> none right now.

Hmm, I'm wondering whether we could put a bunch of sanity checks into
fwts to run on a box and check needed capsules functionality before
logging to one.

Matt, looks like we have ourselves a new project. :-)

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--