On Wed, 13 Nov, at 08:57:49PM, Madper Xie wrote: > > matt@xxxxxxxxxxxxxxxxx writes: > > > On Mon, 11 Nov, at 08:38:31PM, Madper Xie wrote: > >> > >> matt@xxxxxxxxxxxxxxxxx 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. :-( OK, it looks like the firmware Boot Manager gets very confused when it tries to parse the Boot Load Option you created with efibootmgr. This looks like a general firmware bug and not something we need to worry about in the kernel. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
