On 02/20/14 06:53, Sergey Isakov wrote: > Hi Laszlo, > I think there may be a bug: Variable.c > Look > ------------------- > NewLoadContext->ForceReconnect = (BOOLEAN) (NewLoadContext->Attributes & > LOAD_OPTION_FORCE_RECONNECT); > ------------------- > But LOAD_OPTION_FORCE_RECONNECT == 2 and BOOLEAN == UINT8 > so ForceReconnect will be 2. Then > -------------- > *((UINT32 *) Ptr) = LOAD_OPTION_ACTIVE | (ForceReconnect << 1); > -------------- > I am not sure it is a bug but I think it should be corrected as > ------------- > NewLoadContext->ForceReconnect = (BOOLEAN) ((NewLoadContext->Attributes > & LOAD_OPTION_FORCE_RECONNECT)?1:0); > ------------- > Wishes, > Sergey
Thanks for the tip! I'll look into this as soon as I can, because the bug is for real, wherever it is -- while working on my OVMF vidmode series, I rebooted one of my VMs so many times that it had *completely* run out flash storage, hit an ASSERT() *before* reaching the setup screens, and that was it. Of course I could find out about this only because my nvvarstore is split off into a separate file, and when I test a new OVMF build, the varstore remains intact (as it should do)... but with ever less room :) There were warning signs: after some point, the nvvar reclaim code ran at each boot, but in vain: the free workspace continued to decrease. The ASSERT() wasn't very hard to deal with, using a virtual machine (restore pristine nvvarstore file from fresh build), but I suspect the bug (wherever it is) might have bricked a real HW box :( So we need to exterminate this insect. Laszlo ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
