none
[WHCK] Question about ConfirmSetOfLargeVariable in "Secure Boot Logo Test" RRS feed

  • Question

  • Hi experts,

      When I test this case, I meet a error in "ConfirmSetOfLargeVariable" as below:

    Test creation of testLargeVariable Insufficient Variable Storage - SetVariable failed with status 0xC0000454 STATUS_INSUFFICIENT_NVRAM_RESOURCES (EFI_OUT_OF_RESOURCES) Try rebooting your system to allow the firmware to reclaim unused space. The test should pass on its first execution after a reboot. If this error appears on the first test execution after a reboot, your firmware has a bug. VariableName "testLargeVariable" VendorGuid 77fa9abd-0359-4d32-bd60-28f4e78f784b Attributes 0x00000007 DataSize 0x00008000

    It prompts as below:

    NOTE: if this testcase fails, try restarting the machine and then running this test case on its own, for example: "te.exe UefiSecureBootLogo.dll /name:Microsoft.UefiSecureBootLogo.Tests.ConfirmSetOfLargeVariable"

    I think the root cause is our bios need do a reset to reclaim to get enough NVRAM space for 32K large variable.

    But It seems I cannot only run that failed sub case after reset. If I restart this test case, it will run full test and it still failed as previous sub case will consume >= 47K space(Confirm64KilobytesOfUnauthenticatedVariableStorage).

    Could anyone give me some suggestion?

    Thanks.

    Monday, January 14, 2013 9:03 AM

Answers

  • Hi Winddy,

    We don't believe that runtime NVRAM reclaim will occur during any real world scenario - the system will reboot before hitting your runtime reclaim limit.  The only scenario where we anticipate runtime reclaim is during the Secure Boot Logo Test and NVRAM stress tests. 

    Consider increasing your NVRAM storage or enabling runtime reclaim.  No patch is currently scheduled.


    Best Regards, J Cox [Microsoft] “This posting is provided AS IS with no warranties, and confers no rights.”

    • Marked as answer by Winddy Tuesday, February 5, 2013 5:52 AM
    Tuesday, February 5, 2013 12:48 AM

All replies

  • Hi Winddv,

    Is it possible for you to enable runtime NV reclaim in your BIOS so that a reboot is not required?


    Best Regards, J Cox [Microsoft] “This posting is provided AS IS with no warranties, and confers no rights.”

    Wednesday, January 16, 2013 1:12 AM
  • No, but I can save more space to avoid this issue now.

    In the secure boot manual logo test, it can let you have a platform reset to reclaim space.

    So, is it a WHCK's bug?

    Thanks.

    Friday, January 18, 2013 8:41 AM
  • Hi Winddv,

    I'm happy to hear that you have an alternative design that will allow you to pass the test.  If you did not, then we would have gone through the manual Errata process.  I agree that the test could handle this situation better, and we will consider modifying it in a future release. 


    Best Regards, J Cox [Microsoft] “This posting is provided AS IS with no warranties, and confers no rights.”

    Friday, January 18, 2013 4:38 PM
  • Hi JJ,

         This test is failed  by our QA team.

         I think my solution may not cover all the situation as NVRAM may not have 96K(64K + 32K) valid space at that runtime.

        And I have inquired NVRAM RT reclaim issue to EDK2 forum. They said RT reclaim may strip OS control from platform for several seconds which maybe causes OS hang.

         So I need a patch for your side?

        Thanks.

    Tuesday, January 29, 2013 7:30 AM
  • Hi Winddy,

    We don't believe that runtime NVRAM reclaim will occur during any real world scenario - the system will reboot before hitting your runtime reclaim limit.  The only scenario where we anticipate runtime reclaim is during the Secure Boot Logo Test and NVRAM stress tests. 

    Consider increasing your NVRAM storage or enabling runtime reclaim.  No patch is currently scheduled.


    Best Regards, J Cox [Microsoft] “This posting is provided AS IS with no warranties, and confers no rights.”

    • Marked as answer by Winddy Tuesday, February 5, 2013 5:52 AM
    Tuesday, February 5, 2013 12:48 AM
  • Hi JJ,

    Thank you.

    Tuesday, February 5, 2013 5:51 AM