[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1385029633.6516.4097.camel@linux-s257.site>
Date: Thu, 21 Nov 2013 18:27:13 +0800
From: joeyli <jlee@...e.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
Cc: Madper Xie <cxie@...hat.com>,
Matt Fleming <matt@...sole-pimps.org>,
Richard Weinberger <richard@....at>, linux-efi@...r.kernel.org,
linux-kernel@...r.kernel.org, matt.fleming@...el.com,
matthew.garrett@...ula.com
Subject: Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia
parameter to efi_storage_paranoia
於 四,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@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists