[PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

By following works, my system very often fails set_variable() to set new
variable to efi variable storage and shows "efivars: set_variable() failed:
status=-28" message.

- commit 31ff2f20d9003e74991d135f56e503fe776c127c
    efi: Distinguish between "remaining space" and actually used space
- commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
    x86,efi: Implement efi_no_storage_paranoia parameter
- commit f8b8404337de4e2466e2e1139ea68b1f8295974f
    Modify UEFI anti-bricking code

When booting my system, remaining space of efi variable storage is about
5KB. So there is no room that sets a new variable to the storage.

According to above works, efi_no_storage_paranoia parameter was prepared
for sane UEFI which can do gc and fulfills spec. But why need a system
with a sane UEFI set the parameter? It is wrong. A system with a broken
UEFI should set the parameter.

This patch changes name of the parameter to efi_storage_paranoia and uses
all efi variable storage with no parameter.

Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
CC: Matthew Garrett <matthew.garrett@nebula.com>
CC: Richard Weinberger <richard@nod.at>
CC: Lee, Chun-Y <jlee@suse.com>
CC: Matt Fleming <matt.fleming@intel.com>
---
 Documentation/kernel-parameters.txt | 10 +++++-----
 arch/x86/platform/efi/efi.c         |  8 ++++----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index fcbb736..2157c8e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -888,11 +888,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 	edd=		[EDD]
 			Format: {"off" | "on" | "skip[mbr]"}

-	efi_no_storage_paranoia [EFI; X86]
-			Using this parameter you can use more than 50% of
-			your efi variable storage. Use this parameter only if
-			you are really sure that your UEFI does sane gc and
-			fulfills the spec otherwise your board may brick.
+	efi_storage_paranoia [EFI; X86]
+			Using this parameter you cannot use your efi variable
+			storage when the remaining space of the storage becomes
+			less than 5KB. Use this parameter if your UEFI does
+			not sane gc and fulfills the spec.

 	eisa_irq_edge=	[PARISC,HW]
 			See header of drivers/parisc/eisa.c.
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index c7e22ab..010a0eb 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -107,14 +107,14 @@ static int __init setup_add_efi_memmap(char *arg)
 }
 early_param("add_efi_memmap", setup_add_efi_memmap);

-static bool efi_no_storage_paranoia;
+static bool efi_storage_paranoia;

 static int __init setup_storage_paranoia(char *arg)
 {
-	efi_no_storage_paranoia = true;
+	efi_storage_paranoia = true;
 	return 0;
 }
-early_param("efi_no_storage_paranoia", setup_storage_paranoia);
+early_param("efi_storage_paranoia", setup_storage_paranoia);


 static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
@@ -1066,7 +1066,7 @@ efi_status_t efi_query_variable_store(u32 attributes, unsigned long size)
 	 * 5KB. This figure was provided by Samsung, so should be safe.
 	 */
 	if ((remaining_size - size < EFI_MIN_RESERVE) &&
-		!efi_no_storage_paranoia) {
+		efi_storage_paranoia) {

 		/*
 		 * Triggering garbage collection may require that the firmware

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Richard Weinberger]

Am 08.11.2013 08:33, schrieb Yasuaki Ishimatsu:
> By following works, my system very often fails set_variable() to set new
> variable to efi variable storage and shows "efivars: set_variable() failed:
> status=-28" message.
> 
> - commit 31ff2f20d9003e74991d135f56e503fe776c127c
>     efi: Distinguish between "remaining space" and actually used space
> - commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
>     x86,efi: Implement efi_no_storage_paranoia parameter
> - commit f8b8404337de4e2466e2e1139ea68b1f8295974f
>     Modify UEFI anti-bricking code
> 
> When booting my system, remaining space of efi variable storage is about
> 5KB. So there is no room that sets a new variable to the storage.
> 
> According to above works, efi_no_storage_paranoia parameter was prepared
> for sane UEFI which can do gc and fulfills spec. But why need a system
> with a sane UEFI set the parameter? It is wrong. A system with a broken
> UEFI should set the parameter.

And how does one know that his UEFI is broken?
"Oh my board is briked because I wrote too much into a variable, maybe setting
efi_storage_paranoia would have saved me. Let's try with the next board..." ;)

Thanks,
//richard

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Madper Xie]

richard@nod.at writes:

> Am 08.11.2013 08:33, schrieb Yasuaki Ishimatsu:
>> 
>> According to above works, efi_no_storage_paranoia parameter was prepared
>> for sane UEFI which can do gc and fulfills spec. But why need a system
>> with a sane UEFI set the parameter? It is wrong. A system with a broken
>> UEFI should set the parameter.
>
> And how does one know that his UEFI is broken?
> "Oh my board is briked because I wrote too much into a variable, maybe setting
> efi_storage_paranoia would have saved me. Let's try with the next board..." ;)
>
Agreed. It's hard for people to fix their briked motherboard. At least
it's hard for someone who is the first time meet this issue like me. :-(
and IMO, at least 51% of uefi firmwares on the world is buggy... ;)
However, if we simply make all buggy firmware become a brick, the
vendors will more careful in their next generation of products... But
it's painful for everyone, both customers and vendors.
> Thanks,
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Best,
Madper Xie.

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

(2013/11/08 17:05), Richard Weinberger wrote:
> Am 08.11.2013 08:33, schrieb Yasuaki Ishimatsu:
>> By following works, my system very often fails set_variable() to set new
>> variable to efi variable storage and shows "efivars: set_variable() failed:
>> status=-28" message.
>>
>> - commit 31ff2f20d9003e74991d135f56e503fe776c127c
>>      efi: Distinguish between "remaining space" and actually used space
>> - commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
>>      x86,efi: Implement efi_no_storage_paranoia parameter
>> - commit f8b8404337de4e2466e2e1139ea68b1f8295974f
>>      Modify UEFI anti-bricking code
>>
>> When booting my system, remaining space of efi variable storage is about
>> 5KB. So there is no room that sets a new variable to the storage.
>>
>> According to above works, efi_no_storage_paranoia parameter was prepared
>> for sane UEFI which can do gc and fulfills spec. But why need a system
>> with a sane UEFI set the parameter? It is wrong. A system with a broken
>> UEFI should set the parameter.
> 
> And how does one know that his UEFI is broken?

I have no idea. But at least, bricked board is broken UEFI.
Do you know the issue occurs on several boards or specific board?

Thanks,
Yasuaki Ishimatsu

> "Oh my board is briked because I wrote too much into a variable, maybe setting
> efi_storage_paranoia would have saved me. Let's try with the next board..." ;)
> 
> Thanks,
> //richard
> 

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Richard Weinberger]

Am 08.11.2013 10:34, schrieb Yasuaki Ishimatsu:
> (2013/11/08 17:05), Richard Weinberger wrote:
>> Am 08.11.2013 08:33, schrieb Yasuaki Ishimatsu:
>>> By following works, my system very often fails set_variable() to set new
>>> variable to efi variable storage and shows "efivars: set_variable() failed:
>>> status=-28" message.
>>>
>>> - commit 31ff2f20d9003e74991d135f56e503fe776c127c
>>>      efi: Distinguish between "remaining space" and actually used space
>>> - commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
>>>      x86,efi: Implement efi_no_storage_paranoia parameter
>>> - commit f8b8404337de4e2466e2e1139ea68b1f8295974f
>>>      Modify UEFI anti-bricking code
>>>
>>> When booting my system, remaining space of efi variable storage is about
>>> 5KB. So there is no room that sets a new variable to the storage.
>>>
>>> According to above works, efi_no_storage_paranoia parameter was prepared
>>> for sane UEFI which can do gc and fulfills spec. But why need a system
>>> with a sane UEFI set the parameter? It is wrong. A system with a broken
>>> UEFI should set the parameter.
>>
>> And how does one know that his UEFI is broken?
> 
> I have no idea. But at least, bricked board is broken UEFI.
> Do you know the issue occurs on several boards or specific board?

On *many* boards including laptops....
Please read the history of the whole issue.

Thanks,
//richard

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

(2013/11/08 18:37), Richard Weinberger wrote:
> Am 08.11.2013 10:34, schrieb Yasuaki Ishimatsu:
>> (2013/11/08 17:05), Richard Weinberger wrote:
>>> Am 08.11.2013 08:33, schrieb Yasuaki Ishimatsu:
>>>> By following works, my system very often fails set_variable() to set new
>>>> variable to efi variable storage and shows "efivars: set_variable() failed:
>>>> status=-28" message.
>>>>
>>>> - commit 31ff2f20d9003e74991d135f56e503fe776c127c
>>>>       efi: Distinguish between "remaining space" and actually used space
>>>> - commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
>>>>       x86,efi: Implement efi_no_storage_paranoia parameter
>>>> - commit f8b8404337de4e2466e2e1139ea68b1f8295974f
>>>>       Modify UEFI anti-bricking code
>>>>
>>>> When booting my system, remaining space of efi variable storage is about
>>>> 5KB. So there is no room that sets a new variable to the storage.
>>>>
>>>> According to above works, efi_no_storage_paranoia parameter was prepared
>>>> for sane UEFI which can do gc and fulfills spec. But why need a system
>>>> with a sane UEFI set the parameter? It is wrong. A system with a broken
>>>> UEFI should set the parameter.
>>>
>>> And how does one know that his UEFI is broken?
>>
>> I have no idea. But at least, bricked board is broken UEFI.
>> Do you know the issue occurs on several boards or specific board?
> 
> On *many* boards including laptops....
> Please read the history of the whole issue.

Thank you for your comment.
I has read git log. But there is no information like this.
So I will read them of related threads again. Do you know good threads
to know the history of the issue?

Thanks,
Yasuaki Ishimatsu

> 
> Thanks,
> //richard
> 

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Richard Weinberger]

Am 08.11.2013 11:25, schrieb Yasuaki Ishimatsu:
> (2013/11/08 18:37), Richard Weinberger wrote:
>> Am 08.11.2013 10:34, schrieb Yasuaki Ishimatsu:
>>> (2013/11/08 17:05), Richard Weinberger wrote:
>>>> Am 08.11.2013 08:33, schrieb Yasuaki Ishimatsu:
>>>>> By following works, my system very often fails set_variable() to set new
>>>>> variable to efi variable storage and shows "efivars: set_variable() failed:
>>>>> status=-28" message.
>>>>>
>>>>> - commit 31ff2f20d9003e74991d135f56e503fe776c127c
>>>>>       efi: Distinguish between "remaining space" and actually used space
>>>>> - commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
>>>>>       x86,efi: Implement efi_no_storage_paranoia parameter
>>>>> - commit f8b8404337de4e2466e2e1139ea68b1f8295974f
>>>>>       Modify UEFI anti-bricking code
>>>>>
>>>>> When booting my system, remaining space of efi variable storage is about
>>>>> 5KB. So there is no room that sets a new variable to the storage.
>>>>>
>>>>> According to above works, efi_no_storage_paranoia parameter was prepared
>>>>> for sane UEFI which can do gc and fulfills spec. But why need a system
>>>>> with a sane UEFI set the parameter? It is wrong. A system with a broken
>>>>> UEFI should set the parameter.
>>>>
>>>> And how does one know that his UEFI is broken?
>>>
>>> I have no idea. But at least, bricked board is broken UEFI.
>>> Do you know the issue occurs on several boards or specific board?
>>
>> On *many* boards including laptops....
>> Please read the history of the whole issue.
> 
> Thank you for your comment.
> I has read git log. But there is no information like this.
> So I will read them of related threads again. Do you know good threads
> to know the history of the issue?

Everything started with an issue that killed Samsung laptops:
http://mjg59.dreamwidth.org/22855.html

Later it was found that if you write too much into UEFI variables many
UEFI implementations will do bad things.

Thanks,
//richard

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

(2013/11/08 19:29), Richard Weinberger wrote:
> Am 08.11.2013 11:25, schrieb Yasuaki Ishimatsu:
>> (2013/11/08 18:37), Richard Weinberger wrote:
>>> Am 08.11.2013 10:34, schrieb Yasuaki Ishimatsu:
>>>> (2013/11/08 17:05), Richard Weinberger wrote:
>>>>> Am 08.11.2013 08:33, schrieb Yasuaki Ishimatsu:
>>>>>> By following works, my system very often fails set_variable() to set new
>>>>>> variable to efi variable storage and shows "efivars: set_variable() failed:
>>>>>> status=-28" message.
>>>>>>
>>>>>> - commit 31ff2f20d9003e74991d135f56e503fe776c127c
>>>>>>        efi: Distinguish between "remaining space" and actually used space
>>>>>> - commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
>>>>>>        x86,efi: Implement efi_no_storage_paranoia parameter
>>>>>> - commit f8b8404337de4e2466e2e1139ea68b1f8295974f
>>>>>>        Modify UEFI anti-bricking code
>>>>>>
>>>>>> When booting my system, remaining space of efi variable storage is about
>>>>>> 5KB. So there is no room that sets a new variable to the storage.
>>>>>>
>>>>>> According to above works, efi_no_storage_paranoia parameter was prepared
>>>>>> for sane UEFI which can do gc and fulfills spec. But why need a system
>>>>>> with a sane UEFI set the parameter? It is wrong. A system with a broken
>>>>>> UEFI should set the parameter.
>>>>>
>>>>> And how does one know that his UEFI is broken?
>>>>
>>>> I have no idea. But at least, bricked board is broken UEFI.
>>>> Do you know the issue occurs on several boards or specific board?
>>>
>>> On *many* boards including laptops....
>>> Please read the history of the whole issue.
>>
>> Thank you for your comment.
>> I has read git log. But there is no information like this.
>> So I will read them of related threads again. Do you know good threads
>> to know the history of the issue?
> 

> Everything started with an issue that killed Samsung laptops:
> http://mjg59.dreamwidth.org/22855.html
> 
> Later it was found that if you write too much into UEFI variables many
> UEFI implementations will do bad things.

Thanks for the information.
I will read it.

Thanks,
Yasuaki Ishimatsu

> 
> Thanks,
> //richard
> 

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Matt Fleming]

On Fri, 08 Nov, at 07:32:51PM, Yasuaki Ishimatsu wrote:
> > Everything started with an issue that killed Samsung laptops:
> > http://mjg59.dreamwidth.org/22855.html
> > 
> > Later it was found that if you write too much into UEFI variables many
> > UEFI implementations will do bad things.
> 
> Thanks for the information.
> I will read it.

Out of curiosity, what hardware are you using?

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

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.

Thanks,
Yasuaki Ishimatsu


(2013/11/08 23:34), Matt Fleming wrote:
> On Fri, 08 Nov, at 07:32:51PM, Yasuaki Ishimatsu wrote:
>>> Everything started with an issue that killed Samsung laptops:
>>> http://mjg59.dreamwidth.org/22855.html
>>>
>>> Later it was found that if you write too much into UEFI variables many
>>> UEFI implementations will do bad things.
>>
>> Thanks for the information.
>> I will read it.
>
> Out of curiosity, what hardware are you using?
>

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Madper Xie]

Howdy Yasuaki,
  I know some boxes with small NVRAM (less than 64kb?) will meet many
  issues if we always keep ~5kb free space.
  But if we really do not keep some free space as default, many box will
  become a brick. (In fact, I just fixed a bricked dell xps 8500 last
  week. 5kb is not enough for dell xps...)
  So maybe the better way is: we check the size of nvram and decide how
  many space we retain.
  
isimatu.yasuaki@jp.fujitsu.com writes:

> 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.
>
> Thanks,
> Yasuaki Ishimatsu
>
>
> (2013/11/08 23:34), Matt Fleming wrote:
>> On Fri, 08 Nov, at 07:32:51PM, Yasuaki Ishimatsu wrote:
>>>> Everything started with an issue that killed Samsung laptops:
>>>> http://mjg59.dreamwidth.org/22855.html
>>>>
>>>> Later it was found that if you write too much into UEFI variables many
>>>> UEFI implementations will do bad things.
>>>
>>> Thanks for the information.
>>> I will read it.
>>
>> Out of curiosity, what hardware are you using?
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Best,
Madper Xie.

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Matt Fleming]

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

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

Hi Matt,

Sorry for late the reply.


(2013/11/11 19:54), Matt Fleming wrote:
> 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?

I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up,
the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry.

Thanks,
Yasuaki Ishimatsu

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Madper Xie]

isimatu.yasuaki@jp.fujitsu.com writes:

> Hi Matt,
>
> Sorry for late the reply.
>
>
> (2013/11/11 19:54), Matt Fleming wrote:
>> 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?
>
> I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up,
> the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry.
>
Howdy Yasuaki,
  If the remaining NVRAM is less than 5Kb, your writing will trigger a
  NVRAM storage reclamation. However you still failed creating entry. So
  I'm just curious what itmes occupy lots of nvram storage space.

> Thanks,
> Yasuaki Ishimatsu

--
Best,
Madper

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

(2013/11/19 12:16), Madper Xie wrote:
> 
> isimatu.yasuaki@jp.fujitsu.com writes:
> 
>> Hi Matt,
>>
>> Sorry for late the reply.
>>
>>
>> (2013/11/11 19:54), Matt Fleming wrote:
>>> 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?
>>
>> I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up,
>> the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry.
>>
> Howdy Yasuaki,
>    If the remaining NVRAM is less than 5Kb, your writing will trigger a
>    NVRAM storage reclamation. However you still failed creating entry. So
>    I'm just curious what itmes occupy lots of nvram storage space.

Even if we got EFI_OUT_OF_RESOURCES while running Linux, gc does not run.
Trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS environment with
UEFI. So on my system, if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte threshold,
we cannot use nvram storage until EFI_OUT_OF_RESOURCES occurs on pre OS
environment with UEFI.

Thanks,
Yasuaki Ishimatsu

> 
>> Thanks,
>> Yasuaki Ishimatsu
> 
> --
> Best,
> Madper
> 

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[joeyli]

於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到：
> (2013/11/19 12:16), Madper Xie wrote:
> > 
> > isimatu.yasuaki@jp.fujitsu.com writes:
> > 
> >> Hi Matt,
> >>
> >> Sorry for late the reply.
> >>
> >>
> >> (2013/11/11 19:54), Matt Fleming wrote:
> >>> 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?
> >>
> >> I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up,
> >> the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry.
> >>
> > Howdy Yasuaki,
> >    If the remaining NVRAM is less than 5Kb, your writing will trigger a
> >    NVRAM storage reclamation. However you still failed creating entry. So
> >    I'm just curious what itmes occupy lots of nvram storage space.
> 
> Even if we got EFI_OUT_OF_RESOURCES while running Linux, gc does not run.
> Trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS environment with
> UEFI. So on my system, if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte threshold,
> we cannot use nvram storage until EFI_OUT_OF_RESOURCES occurs on pre OS
> environment with UEFI.
> 
> Thanks,
> Yasuaki Ishimatsu

Can we try to trigger gc by EFI_OUT_OF_RESOURCE in EFI stub kernel or
EFI boot loader to recover NVRAM space? Does work with the BIOS on this
machine?


Thanks a lot!
Joey Lee

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[Yasuaki Ishimatsu]

(2013/11/20 17:08), joeyli wrote:
> 於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到：
>> (2013/11/19 12:16), Madper Xie wrote:
>>>
>>> isimatu.yasuaki@jp.fujitsu.com writes:
>>>
>>>> Hi Matt,
>>>>
>>>> Sorry for late the reply.
>>>>
>>>>
>>>> (2013/11/11 19:54), Matt Fleming wrote:
>>>>> 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?
>>>>
>>>> I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up,
>>>> the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry.
>>>>
>>> Howdy Yasuaki,
>>>     If the remaining NVRAM is less than 5Kb, your writing will trigger a
>>>     NVRAM storage reclamation. However you still failed creating entry. So
>>>     I'm just curious what itmes occupy lots of nvram storage space.
>>
>> Even if we got EFI_OUT_OF_RESOURCES while running Linux, gc does not run.
>> Trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS environment with
>> UEFI. So on my system, if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte threshold,
>> we cannot use nvram storage until EFI_OUT_OF_RESOURCES occurs on pre OS
>> environment with UEFI.
>>
>> Thanks,
>> Yasuaki Ishimatsu
>
> Can we try to trigger gc by EFI_OUT_OF_RESOURCE in EFI stub kernel or
> EFI boot loader to recover NVRAM space? Does work with the BIOS on this
> machine?

Yes. I can trigger gc by EFI_OUT_OF_RESOUCE in EFI shell on my machine.

Thanks,
Yasuaki Ishimatu

>
>
> Thanks a lot!
> Joey Lee
>

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[joeyli]

於 四，2013-11-21 於 18:13 +0900，Yasuaki Ishimatsu 提到：
> (2013/11/20 17:08), joeyli wrote:
> > 於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到：
> >> (2013/11/19 12:16), Madper Xie wrote:
> >>>
> >>> isimatu.yasuaki@jp.fujitsu.com writes:
> >>>
> >>>> Hi Matt,
> >>>>
> >>>> Sorry for late the reply.
> >>>>
> >>>>
> >>>> (2013/11/11 19:54), Matt Fleming wrote:
> >>>>> 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?
> >>>>
> >>>> I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up,
> >>>> the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry.
> >>>>
> >>> Howdy Yasuaki,
> >>>     If the remaining NVRAM is less than 5Kb, your writing will trigger a
> >>>     NVRAM storage reclamation. However you still failed creating entry. So
> >>>     I'm just curious what itmes occupy lots of nvram storage space.
> >>
> >> Even if we got EFI_OUT_OF_RESOURCES while running Linux, gc does not run.
> >> Trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS environment with
> >> UEFI. So on my system, if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte threshold,
> >> we cannot use nvram storage until EFI_OUT_OF_RESOURCES occurs on pre OS
> >> environment with UEFI.
> >>
> >> Thanks,
> >> Yasuaki Ishimatsu
> >
> > Can we try to trigger gc by EFI_OUT_OF_RESOURCE in EFI stub kernel or
> > EFI boot loader to recover NVRAM space? Does work with the BIOS on this
> > machine?
> 
> Yes. I can trigger gc by EFI_OUT_OF_RESOUCE in EFI shell on my machine.
> 
> Thanks,
> Yasuaki Ishimatu
> 

OK, then maybe can try to trigger gc in EFI stub before
ExitBootService(). 

Another problem is what's the reasonable threshold. The threshold should
bigger then 5Kbyte, then we write a dummy BootTime NV variable to
trigger gc.


Thanks
Joey Lee

Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia

[joeyli]

於 四，2013-11-21 於 17:53 +0800，joeyli 提到：
> 於 四，2013-11-21 於 18:13 +0900，Yasuaki Ishimatsu 提到：
> > (2013/11/20 17:08), joeyli wrote:
> > > 於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到：
> > >> (2013/11/19 12:16), Madper Xie wrote:
> > >>>
> > >>> isimatu.yasuaki@jp.fujitsu.com writes:
> > >>>
> > >>>> Hi Matt,
> > >>>>
> > >>>> Sorry for late the reply.
> > >>>>
> > >>>>
> > >>>> (2013/11/11 19:54), Matt Fleming wrote:
> > >>>>> 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?
> > >>>>
> > >>>> I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up,
> > >>>> the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry.
> > >>>>
> > >>> Howdy Yasuaki,
> > >>>     If the remaining NVRAM is less than 5Kb, your writing will trigger a
> > >>>     NVRAM storage reclamation. However you still failed creating entry. So
> > >>>     I'm just curious what itmes occupy lots of nvram storage space.
> > >>
> > >> Even if we got EFI_OUT_OF_RESOURCES while running Linux, gc does not run.
> > >> Trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS environment with
> > >> UEFI. So on my system, if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte threshold,
> > >> we cannot use nvram storage until EFI_OUT_OF_RESOURCES occurs on pre OS
> > >> environment with UEFI.
> > >>
> > >> Thanks,
> > >> Yasuaki Ishimatsu
> > >
> > > Can we try to trigger gc by EFI_OUT_OF_RESOURCE in EFI stub kernel or
> > > EFI boot loader to recover NVRAM space? Does work with the BIOS on this
> > > machine?
> > 
> > Yes. I can trigger gc by EFI_OUT_OF_RESOUCE in EFI shell on my machine.
> > 
> > Thanks,
> > Yasuaki Ishimatu
> > 
> 
> OK, then maybe can try to trigger gc in EFI stub before
> ExitBootService(). 
> 
> Another problem is what's the reasonable threshold. The threshold should
> bigger then 5Kbyte, then we write a dummy BootTime NV variable to
> trigger gc.
> 
> 
> Thanks
> Joey Lee

hm... after review your mail, if the free NVRAM space of issue machine
is REALLY less then 5K even after gc. Then there have no way to write
any variable unless user remove some NV variable.


Thanks
Joey Lee