From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by mx.groups.io with SMTP id smtpd.web10.83.1570798196681679184 for ; Fri, 11 Oct 2019 05:49:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=SOR7H2TN; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x9BCkZNr041679; Fri, 11 Oct 2019 05:49:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=YLpSGBZmCsZ1PTZ2LNODL9kw6OWAU2WgiIufrmxswNE=; b=SOR7H2TNjPE96Y0lJ9Rs5FBSdNzgE0P/xM5podciOhiH99La7BlzDV7IZ3/wepZYyyvI WEUUcZil4J7kb7CzuCkdecgrTI8vDOqbLbZ+q9P8IMq2fAcYzw868R96o3gXq9UM/Owt o4yEbC78FOWAiyBXGF4U4tOMkB7Djs5a47YpgfUDlNV4ZHnOX4USHOIrupJza2gSmTx0 VK25Ro8uTsERrpU0UfhIdL3Am5kZ0skCi/Yz1099bxBV/L5Vk3639y7uKvHP1P/0fD1u 7vzNXhInGZ3MXqaZ22zX0xXa30zXQMYT8NaajWoDc/Kwl7HjDeMhQ0mRgyqQmnVEh88L xg== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2veqrmptm2-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 11 Oct 2019 05:49:54 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PZ7009I2NN4DW10@ma1-mtap-s02.corp.apple.com>; Fri, 11 Oct 2019 05:49:53 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PZ700200NF4VF00@nwk-mmpp-sz10.apple.com>; Fri, 11 Oct 2019 05:49:52 -0700 (PDT) X-Va-A: X-Va-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-Va-E-CD: c4384febc0b38a4c3ffc24bb55458dfb X-Va-R-CD: 39d1446bb985fb6c3d28e9c8d969a470 X-Va-CD: 0 X-Va-ID: 1b1689bd-c848-49bb-9eb2-980d125ea235 X-V-A: X-V-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-V-E-CD: c4384febc0b38a4c3ffc24bb55458dfb X-V-R-CD: 39d1446bb985fb6c3d28e9c8d969a470 X-V-CD: 0 X-V-ID: 2e881578-960e-4618-bd30-bb25274ba53c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-11_08:,, signatures=0 Received: from [17.235.46.243] (unknown [17.235.46.243]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PZ700K7WNN1RU80@nwk-mmpp-sz10.apple.com>; Fri, 11 Oct 2019 05:49:51 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] OVMF is crashing for me in master Date: Fri, 11 Oct 2019 05:49:48 -0700 In-reply-to: <51a06bcf-c22f-464c-bbe4-4006b7e8b4c5@redhat.com> Cc: devel@edk2.groups.io, "Gao, Liming" , Pete Batard To: Laszlo Ersek References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E515A05@SHSMSX104.ccr.corp.intel.com> <51a06bcf-c22f-464c-bbe4-4006b7e8b4c5@redhat.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-11_08:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_E374CF02-5BB3-455F-984D-B23E411A1F5C" --Apple-Mail=_E374CF02-5BB3-455F-984D-B23E411A1F5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 11, 2019, at 4:53 AM, Laszlo Ersek wrote: >=20 > On 10/11/19 06:59, Andrew Fish via Groups.Io wrote: >> Liming, >>=20 >> Thanks for looking into this! >>=20 >> Can someone also answer my question about the expected behavior of taki= ng an exception in OVMF? Is the CpuDeadloop() expected?=20 >=20 > Yes, it is. >=20 > The exception handler dumps the register file and the stack to the > emulated serial port, not to the QEMU debug port. >=20 > When looking for OVMF debug messages, people usually (and rightly) check > wherever the QEMU debug port has been redirected. (Unless they built > OVMF with -D DEBUG_ON_SERIAL_PORT.) However, the exception handler > always dumps the state to the serial port, regardless of > DEBUG_ON_SERIAL_PORT. This can be confusing, as the normally consulted > debug log has no indication of the issue. >=20 Laszlo, Thanks if I add -serial file:serial.log to the QEMU command line I see the= exception in serial.log.=20 Thanks, Andrew Fish > Thanks > Laszlo >=20 >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> On Oct 10, 2019, at 6:19 PM, Gao, Liming wrote: >>>=20 >>> Andrew: >>> I verify the change (2de1f611be06ded3a59726a4052a9039be7d459b MdeModu= lePkg/BdsDxe: Also call PlatformBootManagerWaitCallback on 0) in Emulator. >>> It works, because PCD value is set to 10 in Emulator. >>>=20 >>> Before this change, if TimeOut PCD is zero, BdsEntry doesn=E2=80=99t = call PlatformBootManagerWaitCallback(). >>> After this change, if TimeOut PCD is zero, BdsEntry still call Platf= ormBootManagerWaitCallback(). So, it trigs this issue. I agree your fix. >>>=20 >>> Pete: >>> Will you contribute the patch to fix this hang issue in OVMF? >>>=20 >>> Thanks >>> Liming >>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of = Andrew Fish via Groups.Io >>> Sent: Friday, October 11, 2019 5:12 AM >>> To: devel@edk2.groups.io; Pete Batard >>> Subject: [edk2-devel] OVMF is crashing for me in master >>>=20 >>> This is my flavor of OVMF: build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t = XCODE5 >>>=20 >>> It looks like I took an exception? Is it expected that an unhandled ex= ception just hang in a dead loop? I would have expected some serial output= about the failure?=20 >>>=20 >>> Looks like a divide by zero exception. The exception context has PC an= d FP so I can manually walk the stack. Yikes I see PlatformBootManagerWaitC= allback() will fault if PcdPlatformBootTimeOut is zero?=20 >>> /Volumes/Case/UDK2018(master)>git grep PcdPlatformBootTimeOut -- *.dsc >>> ArmVirtPkg/ArmVirtQemu.dsc:194: gEfiMdePkgTokenSpaceGuid.PcdPlatformB= ootTimeOut|3 >>> ArmVirtPkg/ArmVirtQemuKernel.dsc:191: gEfiMdePkgTokenSpaceGuid.PcdPla= tformBootTimeOut|3 >>> ArmVirtPkg/ArmVirtXen.dsc:122: gEfiMdePkgTokenSpaceGuid.PcdPlatformBo= otTimeOut|3 >>> EmulatorPkg/EmulatorPkg.dsc:236: gEfiMdePkgTokenSpaceGuid.PcdPlatform= BootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10 >>> OvmfPkg/OvmfPkgIa32.dsc:541: gEfiMdePkgTokenSpaceGuid.PcdPlatformBoot= TimeOut|0 >>> OvmfPkg/OvmfPkgIa32X64.dsc:553: gEfiMdePkgTokenSpaceGuid.PcdPlatformB= ootTimeOut|0 >>> OvmfPkg/OvmfPkgX64.dsc:552: gEfiMdePkgTokenSpaceGuid.PcdPlatformBootT= imeOut|0 >>> OvmfPkg/OvmfXen.dsc:470: gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTime= Out|0 >>> UefiPayloadPkg/UefiPayloadPkgIa32.dsc:344: gEfiMdePkgTokenSpaceGuid.P= cdPlatformBootTimeOut|3 >>> UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc:345: gEfiMdePkgTokenSpaceGui= d.PcdPlatformBootTimeOut|3 >>>=20 >>>=20 >>> OK PcdPlatformBootTimeOut is zero on Ovmf, so how did this ever work? >>>=20 >>>=20 >>> Ahhh gotom....=20 >>> /Volumes/Case/UDK2018(master)>git blame -L344,344 /Volumes/Case/UDK20= 18/MdeModulePkg/Universal/BdsDxe/BdsEntry.c=20 >>> 2de1f611be0 (Pete Batard 2019-09-25 23:50:05 +0800 344) PlatformBoot= ManagerWaitCallback (0); >>>=20 >>>=20 >>> This call causes a divide by zero if PcdPlatformBootTimeOut =3D=3D 0.= =20 >>>=20 >>> This fixes my crash: >>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/Ov= mfPkg/Library/PlatformBootManagerLib/BdsPlatform.c >>> index 70df6b841a..d6ae43e900 100644 >>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c >>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c >>> @@ -1634,6 +1634,11 @@ PlatformBootManagerWaitCallback ( >>> UINT16 Timeout; >>>=20 >>> Timeout =3D PcdGet16 (PcdPlatformBootTimeOut); >>> + if (Timeout =3D=3D 0) { >>> + Timeout =3D 100; >>> + } else { >>> + Timeout =3D (Timeout - TimeoutRemain) * 100 / Timeout; >>> + } >>>=20 >>> Black.Raw =3D 0x00000000; >>> White.Raw =3D 0x00FFFFFF; >>> @@ -1643,7 +1648,7 @@ PlatformBootManagerWaitCallback ( >>> Black.Pixel, >>> L"Start boot option", >>> White.Pixel, >>> - (Timeout - TimeoutRemain) * 100 / Timeout, >>> + Timeout, >>> 0 >>> ); >>> } >>>=20 >>>=20 >>>=20 >>> lldb debugger output: >>>=20 >>> (lldb) bt >>> * thread #1, stop reason =3D signal SIGTRAP >>> * frame #0: 0x0000000007b58a70 CpuDxe.dll:CpuDeadLoop() + 13 at /Volu= mes/Case/UDK2018/MdePkg/Library/BaseLib/CpuDeadLoop.c:31 >>> frame #1: 0x0000000007b61222 CpuDxe.dll:CommonExceptionHandlerWorke= r() + 674 at /Volumes/Case/UDK2018/UefiCpuPkg/Library/CpuExceptionHandlerLi= b/PeiDxeSmmCpuException.c:115 >>> frame #2: 0x0000000007b61624 CpuDxe.dll:CommonExceptionHandler() + = 36 at /Volumes/Case/UDK2018/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeEx= ception.c:40 >>> frame #3: 0x0000000007b5ff26 CpuDxe.dll:HasErrorCode() + 230 >>> (lldb) fr sel 1 >>> frame #1: 0x0000000007b61222 CpuDxe.dll:CommonExceptionHandlerWorker()= + 674 at /Volumes/Case/UDK2018/UefiCpuPkg/Library/CpuExceptionHandlerLib/P= eiDxeSmmCpuException.c:115 >>> 91 (ExternalInterruptHandler[ExceptionType]) (ExceptionT= ype, SystemContext); >>> 92 } else if (ExceptionType < CPU_EXCEPTION_NUM) { >>> 93 // >>> 94 // Get Spinlock to display CPU information >>> 95 // >>> 96 while (!AcquireSpinLockOrFail (&ExceptionHandlerData-= >DisplayMessageSpinLock)) { >>> 97 CpuPause (); >>> 98 } >>> 99 // >>> 100 // Initialize the serial port before dumping. >>> 101 // >>> 102 SerialPortInitialize (); >>> 103 // >>> 104 // Display ExceptionType, CPU information and Image in= formation >>> 105 // >>> 106 DumpImageAndCpuContent (ExceptionType, SystemContext); >>> 107 // >>> 108 // Release Spinlock of output message >>> 109 // >>> 110 ReleaseSpinLock (&ExceptionHandlerData->DisplayMessage= SpinLock); >>> 111 // >>> 112 // Enter a dead loop if needn't to execute old IDT han= dler further >>> 113 // >>> 114 if (ReservedVectors[ExceptionType].Attribute !=3D EFI_= VECTOR_HANDOFF_HOOK_BEFORE) { >>> -> 115 CpuDeadLoop (); >>> 116 } >>> 117 } >>> 118 } >>> 119 >>> (lldb) p ExceptionType >>> (EFI_EXCEPTION_TYPE) $0 =3D 0 >>> (lldb) p SystemContext.SystemContextX64->Rip >>> (UINT64) $1 =3D 0x0000000007a9cc38 >>> (lldb) p SystemContext.SystemContextX64->Rbp >>> (UINT64) $2 =3D 0x0000000007e8fc20 >>> (lldb) efi_backtrace --pc 0x0000000007a9cc38 --frame 0x0000000007e8fc2= 0 --symbols >>> frame 0: 0x07a9cc38 BdsDxe:PlatformBootManagerWaitCallback + 35 at /= Volumes/Case/UDK2018/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c:1= 646:37 >>> frame 1: 0x07a9e744 BdsDxe:BdsWait + 269 at /Volumes/Case/UDK2018/Md= eModulePkg/Universal/BdsDxe/BdsEntry.c:344:3 >>> frame 2: 0x07a9dff9 BdsDxe:BdsEntry + 2620 at /Volumes/Case/UDK2018/= MdeModulePkg/Universal/BdsDxe/BdsEntry.c:1002:5 >>> frame 3: 0x07eb367d DxeCore:DxeMain + 2680 at /Volumes/Case/UDK2018/= MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:544:3 >>> frame 4: 0x07e943cb DxeCore:_ModuleEntryPoint + 20 at /Volumes/Case/= UDK2018/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:48:3 >>> frame 5: 0x07edc947 DxeIpl.dll`AsmEnableCache >>> frame 6: 0x07ee1e4e DxeIpl:HandOffToDxeCore + 509 at /Volumes/Case/U= DK2018/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c:113:3 >>> frame 7: 0x07ee0604 DxeIpl:DxeLoadCore + 1354 at /Volumes/Case/UDK20= 18/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:449:3 >>> frame 8: 0x07eeff2f PeiCore.dll`PeiCore.cold.3 + 847 >>> frame 9: 0x07ee9d04 PeiCore:PeiCore + 163 at /Volumes/Case/UDK2018/M= deModulePkg/Core/Pei/PeiMain/PeiMain.c:502:3 >>> frame 10: 0x0082c387 0x0082c387 >>> frame 11: 0x00825dd7 0x00825dd7 >>> frame 12: 0x0082ad27 0x0082ad27 >>> frame 13: 0x0082b3a8 0x0082b3a8 >>> frame 14: 0x0082bf23 0x0082bf23 >>> frame 15: 0x00825e24 0x00825e24 >>> frame 16: 0x00823af2 0x00823af2 >>> frame 17: 0xfffd1db8 SecMain:SecStartupPhase2 + 67 at /Volumes/Case/U= DK2018/OvmfPkg/Sec/SecMain.c:858:3 >>> frame 18: 0xfffd1d67 SecMain:SecCoreStartupWithStack + 420 at /Volume= s/Case/UDK2018/OvmfPkg/Sec/SecMain.c:821:3 >>> frame 19: 0xfffd1e14 SecMain:ProcessLibraryConstructorList + 0 at /Vo= lumes/Case/UDK2018/Build/OvmfX64/DEBUG_XCODE5/X64/OvmfPkg/Sec/SecMain/DEBUG= /AutoGen.c:201 >>>=20 >>> (lldb) l /Volumes/Case/UDK2018/OvmfPkg/Library/PlatformBootManagerLib/= BdsPlatform.c:1646 >>> 1646 (Timeout - TimeoutRemain) * 100 / Timeout, >>> 1647 0 >>> 1648 ); >>> 1649 } >>> 1650 >>> 1651 /** >>> 1652 The function is called when no boot option could be launc= hed, >>> 1653 including platform recovery options and options pointing = to applications >>> 1654 built into firmware volumes. >>> 1655 >>> (lldb) l /Volumes/Case/UDK2018/MdeModulePkg/Universal/BdsDxe/BdsEntry.= c:344 >>> 344 PlatformBootManagerWaitCallback (0); >>> 345 DEBUG ((EFI_D_INFO, "[Bds]Exit the waiting!\n")); >>> 346 } >>> 347 >>> 348 /** >>> 349 Attempt to boot each boot option in the BootOptions arra= y. >>> 350 >>> 351 @param BootOptions Input boot option array. >>> 352 @param BootOptionCount Input boot option count. >>> 353 @param BootManagerMenu Input boot manager menu. >>> 354 >>>=20 >>>=20 >>> Thanks, >>>=20 >>> Andrew Fish >>>=20 >>>=20 >>=20 >>=20 >>=20 --Apple-Mail=_E374CF02-5BB3-455F-984D-B23E411A1F5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 11, 2= 019, at 4:53 AM, Laszlo Ersek <lersek@redhat.com> wrote:

On 10/11/19 06:59, Andrew Fish via Groups.= Io wrote:
= Liming,

Thanks for looking into this!

Can someone also answer my question about the expecte= d behavior of taking an exception in OVMF?  Is the CpuDeadloop() expec= ted? 

Yes, it is.
= The exception handler dumps the register file and the stack to the
emulated serial port, no= t to the QEMU debug port.

When looking for OVMF debug messa= ges, people usually (and rightly) check
wherever the QEMU debug port has been redirected. (Unless = they built
OVMF with -D= DEBUG_ON_SERIAL_PORT.) However, the exception handler
always dumps the state to the serial port, = regardless of
DEBUG_ON_= SERIAL_PORT. This can be confusing, as the normally consulted
debug log has no indication of the i= ssue.


Laszlo,

Thanks if I add -serial file:serial.= log to the QEMU command line I see the exception in serial.log. 
=

Thanks,

= Andrew Fish

Thanks
Laszlo


Thanks,
<= br class=3D"">Andrew Fish

On Oct 10, 2019, at 6:19 PM, Gao, Liming <liming.gao@intel.com> wrote:
Andrew:
 I verify the change= (2de1f611be06ded3a59726a4052a9039be7d459b MdeModulePkg/BdsDxe: Also call P= latformBootManagerWaitCallback on 0) in Emulator.
 It wo= rks, because PCD value is set to 10 in Emulator.

 Before this change, if TimeOut PCD is zero, BdsEntry doesn=E2=80= =99t call PlatformBootManagerWaitCallback().
 After thi= s change,  if TimeOut PCD is zero, BdsEntry still call PlatformBootMan= agerWaitCallback(). So, it trigs this issue. I agree your fix.

Pete:
 Will you contribute the patch to= fix this hang issue in OVMF?

Thanks
Liming
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via G= roups.Io
Sent: Friday, October 11, 2019 5:12 AM
To: devel@edk2.groups.i= o; Pete Batard <pete@akeo= .ie>
Subject: [edk2-devel] OVMF is crashing for me in = master

This is my flavor of OVMF:  build = -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t XCODE5

It = looks like I took an exception? Is it expected that an unhandled exception = just hang in a dead loop? I would have expected some serial  output ab= out the failure? 

Looks like a divide by zero exception. The exception = context has PC and FP so I can manually walk the stack. Yikes I see Platfor= mBootManagerWaitCallback() will fault if PcdPlatformBootTimeOut is zero? 
/Volumes/Cas= e/UDK2018(master)>git grep PcdPlatformBootTimeOut -- *.dsc
ArmVirtPkg/ArmVirtQemu.dsc:194:  gEfiMdePkgTokenSpaceGuid.PcdPlatform= BootTimeOut|3
ArmVirtPkg/ArmVirtQemuKernel.dsc:191:  gEf= iMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
ArmVirtPkg/Arm= VirtXen.dsc:122:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3EmulatorPkg/EmulatorPkg.dsc:236:  gEfiMdePkgTokenSpaceGuid= .PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10
OvmfPkg/OvmfPkgIa32.dsc:541:  gEfiMdePkgTokenSpaceGuid.PcdPlatf= ormBootTimeOut|0
OvmfPkg/OvmfPkgIa32X64.dsc:553:  gEfiMd= ePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
OvmfPkg/OvmfPkgX6= 4.dsc:552:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
OvmfPkg/OvmfXen.dsc:470:  gEfiMdePkgTokenSpaceGuid.PcdPlatformB= ootTimeOut|0
UefiPayloadPkg/UefiPayloadPkgIa32.dsc:344:  = ;gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
UefiPayloa= dPkg/UefiPayloadPkgIa32X64.dsc:345:  gEfiMdePkgTokenSpaceGuid.PcdPlatf= ormBootTimeOut|3


OK PcdPlatform= BootTimeOut is zero on Ovmf, so how did this ever work?


Ahhh gotom.... 
/Volumes/Case/UDK2018(master)>git blame -L= 344,344  /Volumes/Case/UDK2018/MdeModulePkg/Universal/BdsDxe/BdsEntry.= c 
2de1f611= be0 (Pete Batard 2019-09-25 23:50:05 +0800 344)   PlatformBootMan= agerWaitCallback (0);


This call= causes a divide by zero if PcdPlatformBootTimeOut =3D=3D 0. 

This fixe= s my crash:
diff --git a/OvmfPkg/Library/PlatformBootManagerL= ib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 70df6b841a..d6ae43e900 100644
--- a/OvmfPkg/= Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Li= brary/PlatformBootManagerLib/BdsPlatform.c
@@ -1634,6 +1634,1= 1 @@ PlatformBootManagerWaitCallback (
  UINT16 &nb= sp;            =             &nb= sp;   Timeout;

  Time= out =3D PcdGet16 (PcdPlatformBootTimeOut);
+  if (Timeou= t =3D=3D  0) {
+    Timeout =3D 100;
+  } else {
+    Timeout =3D (T= imeout - TimeoutRemain) * 100 / Timeout;
+  }

  Black.Raw =3D 0x00000000;
&= nbsp; White.Raw =3D 0x00FFFFFF;
@@ -1643,7 +1648,7 @@ Pl= atformBootManagerWaitCallback (
    Black= .Pixel,
    L"Start boot option",
    White.Pixel,
-   &nb= sp;(Timeout - TimeoutRemain) * 100 / Timeout,
+   &= nbsp;Timeout,
    0
 &= nbsp;  );
}



lldb debugger output:

(l= ldb) bt
* thread #1, stop reason =3D signal SIGTRAP
 * frame #0: 0x0000000007b58a70 CpuDxe.dll:CpuDeadLoop() + 13 a= t /Volumes/Case/UDK2018/MdePkg/Library/BaseLib/CpuDeadLoop.c:31
   frame #1: 0x0000000007b61222 CpuDxe.dll:CommonExceptio= nHandlerWorker() + 674 at /Volumes/Case/UDK2018/UefiCpuPkg/Library/CpuExcep= tionHandlerLib/PeiDxeSmmCpuException.c:115
   = frame #2: 0x0000000007b61624 CpuDxe.dll:CommonExceptionHandler() + 36 at /V= olumes/Case/UDK2018/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.= c:40
   frame #3: 0x0000000007b5ff26 CpuDxe.dl= l:HasErrorCode() + 230
(lldb) fr sel 1
frame #1= : 0x0000000007b61222 CpuDxe.dll:CommonExceptionHandlerWorker() + 674 at /Vo= lumes/Case/UDK2018/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuEx= ception.c:115
  91      &n= bsp;      (ExternalInterruptHandler[Exception= Type]) (ExceptionType, SystemContext);
  92  &= nbsp;        } else if (ExceptionTy= pe < CPU_EXCEPTION_NUM) {
  93    = ;         //
&nb= sp; 94           &nb= sp; // Get Spinlock to display CPU information
 &nb= sp;95            &nb= sp;//
  96       &nbs= p;     while (!AcquireSpinLockOrFail (&Excepti= onHandlerData->DisplayMessageSpinLock)) {
  97 &= nbsp;           &nbs= p; CpuPause ();
  98     &= nbsp;       }
  = 99             = //
  100        =    // Initialize the serial port before dumping.
  101          &n= bsp;//
  102       &n= bsp;   SerialPortInitialize ();
  10= 3           //
  104         &nbs= p; // Display ExceptionType, CPU information and Image information
  105         =   //
  106      =      DumpImageAndCpuContent (ExceptionType, System= Context);
  107       = ;    //
  108    = ;       // Release Spinlock of output me= ssage
  109       &nb= sp;   //
  110    &nb= sp;      ReleaseSpinLock (&ExceptionHandl= erData->DisplayMessageSpinLock);
  111  &nb= sp;        //
 &= nbsp;112           // Ent= er a dead loop if needn't to execute old IDT handler further
=   113           = ;//
  114        = ;   if (ReservedVectors[ExceptionType].Attribute !=3D EFI_VE= CTOR_HANDOFF_HOOK_BEFORE) {
-> 115     = ;       CpuDeadLoop ();
&n= bsp; 116           }=
  117        &n= bsp;}
  118       }  119
(lldb) p ExceptionType
(EFI_EXCEPTION_TYPE) $0 =3D 0
(lldb) p SystemContext.S= ystemContextX64->Rip
(UINT64) $1 =3D 0x0000000007a9cc38(lldb) p SystemContext.SystemContextX64->Rbp
(= UINT64) $2 =3D 0x0000000007e8fc20
(lldb) efi_backtrace --pc 0= x0000000007a9cc38 --frame 0x0000000007e8fc20 --symbols
 = frame  0: 0x07a9cc38 BdsDxe:PlatformBootManagerWaitCallback + 35 at /V= olumes/Case/UDK2018/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c:16= 46:37
 frame  1: 0x07a9e744 BdsDxe:BdsWait + 269 at= /Volumes/Case/UDK2018/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:344:3
 frame  2: 0x07a9dff9 BdsDxe:BdsEntry + 2620 at /Volumes= /Case/UDK2018/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:1002:5
 frame  3: 0x07eb367d DxeCore:DxeMain + 2680 at /Volumes/Case/UD= K2018/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:544:3
 fra= me  4: 0x07e943cb DxeCore:_ModuleEntryPoint + 20 at /Volumes/Case/UDK2= 018/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:48:3
 frame  5: 0x07edc947 DxeIpl.dll`AsmEnableCache
&n= bsp;frame  6: 0x07ee1e4e DxeIpl:HandOffToDxeCore + 509 at /Volumes/Cas= e/UDK2018/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c:113:3
 frame  7: 0x07ee0604 DxeIpl:DxeLoadCore + 1354 at /Volumes/Cas= e/UDK2018/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:449:3
 = frame  8: 0x07eeff2f PeiCore.dll`PeiCore.cold.3 + 847
&n= bsp;frame  9: 0x07ee9d04 PeiCore:PeiCore + 163 at /Volumes/Case/UDK201= 8/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c:502:3
 frame 1= 0: 0x0082c387 0x0082c387
 frame 11: 0x00825dd7 0x00825dd= 7
 frame 12: 0x0082ad27 0x0082ad27
 f= rame 13: 0x0082b3a8 0x0082b3a8
 frame 14: 0x0082bf23 0x0= 082bf23
 frame 15: 0x00825e24 0x00825e24
&= nbsp;frame 16: 0x00823af2 0x00823af2
 frame 17: 0xfffd1d= b8 SecMain:SecStartupPhase2 + 67 at /Volumes/Case/UDK2018/OvmfPkg/Sec/SecMa= in.c:858:3
 frame 18: 0xfffd1d67 SecMain:SecCoreStartupW= ithStack + 420 at /Volumes/Case/UDK2018/OvmfPkg/Sec/SecMain.c:821:3
 frame 19: 0xfffd1e14 SecMain:ProcessLibraryConstructorList + 0= at /Volumes/Case/UDK2018/Build/OvmfX64/DEBUG_XCODE5/X64/OvmfPkg/Sec/SecMai= n/DEBUG/AutoGen.c:201

(lldb) l /Volumes/Case/U= DK2018/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c:1646
  1646         (Ti= meout - TimeoutRemain) * 100 / Timeout,
  1647 &nbs= p;       0
  164= 8         );
 &n= bsp;1649     }
  1650
  1651     /**
 &nb= sp;1652       The function is called when no = boot option could be launched,
  1653   &= nbsp;   including platform recovery options and options poin= ting to applications
  1654     = ;  built into firmware volumes.
  1655(lldb) l /Volumes/Case/UDK2018/MdeModulePkg/Universal/BdsDxe/Bd= sEntry.c:344
  344      &n= bsp;  PlatformBootManagerWaitCallback (0);
 &n= bsp;345         DEBUG ((EFI_D_INFO,= "[Bds]Exit the waiting!\n"));
  346   &n= bsp;   }
  347
 &= nbsp;348       /**
  = 349         Attempt to boot each bo= ot option in the BootOptions array.
  350
  351         @par= am BootOptions       Input boot option array.=
  352        &n= bsp;@param BootOptionCount   Input boot option count.
  353         @param B= ootManagerMenu   Input boot manager menu.
 &nb= sp;354


Thanks,
Andrew Fish




=
--Apple-Mail=_E374CF02-5BB3-455F-984D-B23E411A1F5C--