public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@console-pimps.org>
To: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	matt.fleming@intel.com, matthew.garrett@nebula.com,
	jlee@suse.com
Subject: Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia
Date: Mon, 11 Nov 2013 10:54:24 +0000	[thread overview]
Message-ID: <20131111105424.GD22636@console-pimps.org> (raw)
In-Reply-To: <52809AEB.9080100@jp.fujitsu.com>

On Mon, 11 Nov, at 05:52:59PM, Yasuaki Ishimatsu wrote:
> Hi Matt,
> 
> I uses FUJITSU's x86 box.
> This does not become bricked even if I use all efi variable storage.
> Thus I want a way to not need to specify efi_no_storage_paranoia
> parameter.

The efi_no_storage_paranoia parameter was introduced because some
machines do not initiate garbage collection of the NVRAM until you
allocate all space - basically it's a switch to turn off the "save 5KB
of stoarge at all times" workaround that is needed to avoid bricking
some machines. 

The intention of the switch is not to allow you to fill your NVRAM just
because you can. If that is something you want to do then I think it's
fair to require you to explicitly turn on efi_no_storage_paranoia. But
I'm assuming here that you are doing something like writing lots and
lots of pstore entries and just want to write as many as your variable
storage will allow? Or are you doing something more fundamental like
creating BootXXXX entries?

What are you doing to run into the 5KB reserve? How much NVRAM does your
machine come with?

-- 
Matt Fleming, Intel Open Source Technology Center

  parent reply	other threads:[~2013-11-11 10:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-08  7:33 [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia Yasuaki Ishimatsu
2013-11-08  8:05 ` Richard Weinberger
2013-11-08  8:46   ` Madper Xie
2013-11-08  9:34   ` Yasuaki Ishimatsu
2013-11-08  9:37     ` Richard Weinberger
2013-11-08 10:25       ` Yasuaki Ishimatsu
2013-11-08 10:29         ` Richard Weinberger
2013-11-08 10:32           ` Yasuaki Ishimatsu
2013-11-08 14:34             ` Matt Fleming
2013-11-11  8:52               ` Yasuaki Ishimatsu
2013-11-11  9:47                 ` Madper Xie
2013-11-11 10:54                 ` Matt Fleming [this message]
2013-11-19  3:03                   ` Yasuaki Ishimatsu
2013-11-19  3:16                     ` Madper Xie
2013-11-20  6:26                       ` Yasuaki Ishimatsu
2013-11-20  8:08                         ` joeyli
2013-11-21  9:13                           ` Yasuaki Ishimatsu
2013-11-21  9:53                             ` joeyli
2013-11-21 10:27                               ` joeyli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131111105424.GD22636@console-pimps.org \
    --to=matt@console-pimps.org \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=jlee@suse.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matthew.garrett@nebula.com \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox