public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Andrew Fish" <afish@apple.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: devel@edk2.groups.io, "Gao, Liming" <liming.gao@intel.com>,
	Pete Batard <pete@akeo.ie>
Subject: Re: [edk2-devel] OVMF is crashing for me in master
Date: Fri, 11 Oct 2019 05:49:48 -0700	[thread overview]
Message-ID: <EEBF661B-9C16-4995-B05A-37A95E5E2B12@apple.com> (raw)
In-Reply-To: <51a06bcf-c22f-464c-bbe4-4006b7e8b4c5@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 10374 bytes --]



> On Oct 11, 2019, 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 expected behavior of taking an exception in OVMF?  Is the CpuDeadloop() expected? 
> 
> Yes, it is.
> 
> The exception handler dumps the register file and the stack to the
> emulated serial port, not to the QEMU debug port.
> 
> 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.
> 

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,
>> 
>> 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 PlatformBootManagerWaitCallback on 0) in Emulator.
>>>  It works, because PCD value is set to 10 in Emulator.
>>> 
>>>  Before this change, if TimeOut PCD is zero, BdsEntry doesn’t call PlatformBootManagerWaitCallback().
>>>  After this change,  if TimeOut PCD is zero, BdsEntry still call PlatformBootManagerWaitCallback(). 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 Groups.Io
>>> Sent: Friday, October 11, 2019 5:12 AM
>>> To: devel@edk2.groups.io; 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 about 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 PlatformBootManagerWaitCallback() will fault if PcdPlatformBootTimeOut is zero? 
>>> /Volumes/Case/UDK2018(master)>git grep PcdPlatformBootTimeOut -- *.dsc
>>> ArmVirtPkg/ArmVirtQemu.dsc:194:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
>>> ArmVirtPkg/ArmVirtQemuKernel.dsc:191:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
>>> ArmVirtPkg/ArmVirtXen.dsc:122:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
>>> EmulatorPkg/EmulatorPkg.dsc:236:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10
>>> OvmfPkg/OvmfPkgIa32.dsc:541:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
>>> OvmfPkg/OvmfPkgIa32X64.dsc:553:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
>>> OvmfPkg/OvmfPkgX64.dsc:552:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
>>> OvmfPkg/OvmfXen.dsc:470:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
>>> UefiPayloadPkg/UefiPayloadPkgIa32.dsc:344:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
>>> UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc:345:  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
>>> 
>>> 
>>> OK PcdPlatformBootTimeOut is zero on Ovmf, so how did this ever work?
>>> 
>>> 
>>> Ahhh gotom.... 
>>> /Volumes/Case/UDK2018(master)>git blame -L344,344  /Volumes/Case/UDK2018/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
>>> 2de1f611be0 (Pete Batard 2019-09-25 23:50:05 +0800 344)   PlatformBootManagerWaitCallback (0);
>>> 
>>> 
>>> This call causes a divide by zero if PcdPlatformBootTimeOut == 0. 
>>> 
>>> This fixes my crash:
>>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/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;
>>> 
>>>   Timeout = PcdGet16 (PcdPlatformBootTimeOut);
>>> +  if (Timeout ==  0) {
>>> +    Timeout = 100;
>>> +  } else {
>>> +    Timeout = (Timeout - TimeoutRemain) * 100 / Timeout;
>>> +  }
>>> 
>>>   Black.Raw = 0x00000000;
>>>   White.Raw = 0x00FFFFFF;
>>> @@ -1643,7 +1648,7 @@ PlatformBootManagerWaitCallback (
>>>     Black.Pixel,
>>>     L"Start boot option",
>>>     White.Pixel,
>>> -    (Timeout - TimeoutRemain) * 100 / Timeout,
>>> +    Timeout,
>>>     0
>>>     );
>>> }
>>> 
>>> 
>>> 
>>> lldb debugger output:
>>> 
>>> (lldb) bt
>>> * thread #1, stop reason = signal SIGTRAP
>>>  * frame #0: 0x0000000007b58a70 CpuDxe.dll:CpuDeadLoop() + 13 at /Volumes/Case/UDK2018/MdePkg/Library/BaseLib/CpuDeadLoop.c:31
>>>    frame #1: 0x0000000007b61222 CpuDxe.dll:CommonExceptionHandlerWorker() + 674 at /Volumes/Case/UDK2018/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c:115
>>>    frame #2: 0x0000000007b61624 CpuDxe.dll:CommonExceptionHandler() + 36 at /Volumes/Case/UDK2018/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.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/PeiDxeSmmCpuException.c:115
>>>   91             (ExternalInterruptHandler[ExceptionType]) (ExceptionType, 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 information
>>>   105           //
>>>   106           DumpImageAndCpuContent (ExceptionType, SystemContext);
>>>   107           //
>>>   108           // Release Spinlock of output message
>>>   109           //
>>>   110           ReleaseSpinLock (&ExceptionHandlerData->DisplayMessageSpinLock);
>>>   111           //
>>>   112           // Enter a dead loop if needn't to execute old IDT handler further
>>>   113           //
>>>   114           if (ReservedVectors[ExceptionType].Attribute != EFI_VECTOR_HANDOFF_HOOK_BEFORE) {
>>> -> 115            CpuDeadLoop ();
>>>   116           }
>>>   117         }
>>>   118       }
>>>   119
>>> (lldb) p ExceptionType
>>> (EFI_EXCEPTION_TYPE) $0 = 0
>>> (lldb) p SystemContext.SystemContextX64->Rip
>>> (UINT64) $1 = 0x0000000007a9cc38
>>> (lldb) p SystemContext.SystemContextX64->Rbp
>>> (UINT64) $2 = 0x0000000007e8fc20
>>> (lldb) efi_backtrace --pc 0x0000000007a9cc38 --frame 0x0000000007e8fc20 --symbols
>>>  frame  0: 0x07a9cc38 BdsDxe:PlatformBootManagerWaitCallback + 35 at /Volumes/Case/UDK2018/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c:1646: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/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/UDK2018/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c:113:3
>>>  frame  7: 0x07ee0604 DxeIpl:DxeLoadCore + 1354 at /Volumes/Case/UDK2018/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/MdeModulePkg/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/UDK2018/OvmfPkg/Sec/SecMain.c:858:3
>>>  frame 18: 0xfffd1d67 SecMain:SecCoreStartupWithStack + 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/SecMain/DEBUG/AutoGen.c:201
>>> 
>>> (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 launched,
>>>   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 array.
>>>   350
>>>   351         @param BootOptions       Input boot option array.
>>>   352         @param BootOptionCount   Input boot option count.
>>>   353         @param BootManagerMenu   Input boot manager menu.
>>>   354
>>> 
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>> 
>> 
>> 
>> 


[-- Attachment #2: Type: text/html, Size: 27212 bytes --]

  reply	other threads:[~2019-10-11 12:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 21:12 OVMF is crashing for me in master Andrew Fish
2019-10-11  1:19 ` [edk2-devel] " Liming Gao
2019-10-11  4:59   ` Andrew Fish
2019-10-11 11:53     ` Laszlo Ersek
2019-10-11 12:49       ` Andrew Fish [this message]
2019-10-11 11:50   ` Laszlo Ersek
2019-10-11 12:16     ` Pete Batard
2019-10-11 13:13     ` Andrew Fish
2019-10-11 16:33       ` Laszlo Ersek
2019-10-11 19:07         ` Andrew Fish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EEBF661B-9C16-4995-B05A-37A95E5E2B12@apple.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox