All of lore.kernel.org
 help / color / mirror / Atom feed
From: Madper Xie <cxie@redhat.com>
To: Matt Fleming <matt@console-pimps.org>
Cc: Madper Xie <cxie@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Matt Fleming <matt.fleming@intel.com>
Subject: Re: [BUG]: DELL XPS 8500 become a brick after fill too many entries to nvram.
Date: Wed, 13 Nov 2013 20:57:49 +0800	[thread overview]
Message-ID: <878uws1msy.fsf@redhat.com> (raw)
In-Reply-To: <20131113112052.GJ22636@console-pimps.org>


matt@console-pimps.org writes:

> On Mon, 11 Nov, at 08:38:31PM, Madper Xie wrote:
>> 
>> matt@console-pimps.org writes:
>> 
>> > On Mon, 11 Nov, at 02:15:22PM, Madper Xie wrote:
>> >> Howdy all,
>> >>   For now we ensure at least ~5kb free space. But my dell xps still
>> >>   become a brick after I add too many entries to my nvram. So maybe 5kb
>> >>   is not safe enough. and 5kb is just aginst Samsung's laptop.
>> >>   So should we enlarge EFI_MIN_RESERVE?
>> >
>
> OK, that's pretty conclusive. Thanks.
>
Ouch, Sorry. My mistake. Seems filling too much entries to nvram is not
the murderer...
For testing, I using following command to fill my nvram:
head -c20480 /dev/urandom | efibootmgr --quiet --create --append-binary-args - 

For occupy lots of nvram space, I run it many times. But when I try to
find the threshold, I find the real murderer is that command. I mean my
dell xps will bricked even if I just run the command once and have more
than 100kb free space...

So the murderer is the new added boot entry. I don't really know if it's
still a bug. And I apologize for my mistake. :-(
>  
> Have you been able to calculate the safe limit of NVRAM we need to
> reserve to avoid bricking your machine?
>
> I was interested in the DMI and other firmware strings from dmesg.


-- 
Best,
Madper Xie.

WARNING: multiple messages have this Message-ID (diff)
From: Madper Xie <cxie@redhat.com>
To: Matt Fleming <matt@console-pimps.org>
Cc: Madper Xie <cxie@redhat.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-efi\@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Matt Fleming <matt.fleming@intel.com>
Subject: Re: [BUG]: DELL XPS 8500 become a brick after fill too many entries to nvram.
Date: Wed, 13 Nov 2013 20:57:49 +0800	[thread overview]
Message-ID: <878uws1msy.fsf@redhat.com> (raw)
In-Reply-To: <20131113112052.GJ22636@console-pimps.org>


matt@console-pimps.org writes:

> On Mon, 11 Nov, at 08:38:31PM, Madper Xie wrote:
>> 
>> matt@console-pimps.org writes:
>> 
>> > On Mon, 11 Nov, at 02:15:22PM, Madper Xie wrote:
>> >> Howdy all,
>> >>   For now we ensure at least ~5kb free space. But my dell xps still
>> >>   become a brick after I add too many entries to my nvram. So maybe 5kb
>> >>   is not safe enough. and 5kb is just aginst Samsung's laptop.
>> >>   So should we enlarge EFI_MIN_RESERVE?
>> >
>
> OK, that's pretty conclusive. Thanks.
>
Ouch, Sorry. My mistake. Seems filling too much entries to nvram is not
the murderer...
For testing, I using following command to fill my nvram:
head -c20480 /dev/urandom | efibootmgr --quiet --create --append-binary-args - 

For occupy lots of nvram space, I run it many times. But when I try to
find the threshold, I find the real murderer is that command. I mean my
dell xps will bricked even if I just run the command once and have more
than 100kb free space...

So the murderer is the new added boot entry. I don't really know if it's
still a bug. And I apologize for my mistake. :-(
>  
> Have you been able to calculate the safe limit of NVRAM we need to
> reserve to avoid bricking your machine?
>
> I was interested in the DMI and other firmware strings from dmesg.


-- 
Best,
Madper Xie.

  reply	other threads:[~2013-11-13 12:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11  6:15 [BUG]: DELL XPS 8500 become a brick after fill too many entries to nvram Madper Xie
2013-11-11  6:15 ` Madper Xie
     [not found] ` <87fvr3h3b9.fsf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-11 11:07   ` Matt Fleming
2013-11-11 11:07     ` Matt Fleming
2013-11-11 12:38     ` Madper Xie
2013-11-11 12:38       ` Madper Xie
     [not found]       ` <87eh6nt8oo.fsf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-13 11:21         ` Matt Fleming
2013-11-13 11:21           ` Matt Fleming
2013-11-13 12:57           ` Madper Xie [this message]
2013-11-13 12:57             ` Madper Xie
     [not found]             ` <878uws1msy.fsf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-13 14:08               ` Matt Fleming
2013-11-13 14:08                 ` Matt Fleming
2013-11-18 19:07                 ` Matthew Garrett

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=878uws1msy.fsf@redhat.com \
    --to=cxie@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@console-pimps.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.