於 四，2013-05-30 於 21:17 -0500，Russ Anderson 提到： > On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote: > > On Thu, 30 May 2013, Russ Anderson wrote: > > > > > > > That's a great idea. This patch moves the QueryVariableInfo() > > > > > call from bootime to runtime, in efi_late_init(). The attached > > > > > patch is consistent with the UEFI spec and avoids the problem. > > > > > > > > No, that defeats the entire point of the original patch. > > > > > > How so? It is still calling QueryVariableInfo() > > > before the data is used. > > > > You lose information provided by QueryVariableInfo() about boot-only > > variables once the transition boot -> runtime has happened. > > Is that information really more important than the ability > to boot? > > Correct me if I'm wrong, but linux was able to boot without > the boottime QueryVariableInfo() call up until 3.9-rc7, > and it still does on systems that do not use EFI stubs (ie > grub and elilo). It is only when linux uses EFI stubs (ie > grub2) that linux makes the boottime QueryVariableInfo() > call. So why is that call, or whatever is dependent on it, > more important than booting? > > > > Thanks, It related to BIOS's garbage collection behavior of UEFI variable storage. The used space of non volatile boottime variables is useful to us for calculate the active_size, please reference 31ff2f2 patch: https://lkml.org/lkml/2013/4/15/476 An earlier 68d9298 patch to avoid some machines bricked when more than 50% of the system flash is in use, because the garbage collection will not trigger on those machines. We need find out the size of system flash space indeed usage for avoid this problem. So, cc5a080c5 patch call QueryVariableInfo() to grab the usage information in boot time. Calling QueryVariableInfo() at boot time should not causes side effect until your issue show up. Before this issue happen, avoid bricking some machines is also important. Thanks a lot! Joey Lee -- 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
