Re: Windows guest fails to boot into recovery mode due to commit 5267926
Hello Laszlo,toggle quoted messageShow quoted text
In my previous email, the exception is reproduced with pretty old code base from where I started bisecting the comments. This time I reproduce this issue with the code of branch 'stable/202011' of upstream. All the log I am collecting is from this code base(75ab038). Since the overall size of all log is pretty big, I'll attach all the data you required in to this bug(https://bugzilla.tianocore.org/show_bug.cgi?id=3269).
I dump the register by qmp-regdump, and the result(regdump) is uploaded into this bug. If this log doesn't suffice, can you please suggest the way you prefer?
The objdump is uploaded, as well as the details of page fault exception, please check the details there.
From: Laszlo Ersek [mailto:email@example.com]
Sent: Thursday, March 18, 2021 9:23 AM
To: Annie Li <firstname.lastname@example.org>; email@example.com
Cc: firstname.lastname@example.org; Andrew Fish <email@example.com>
Subject: Re: Windows guest fails to boot into recovery mode due to commit 5267926
On 03/18/21 02:48, Annie Li wrote:
Hello,In addition to what Andrew said, I suggest the following:
(1) Please rebuild OVMF *locally*, using the same edk2 tree, and the same toolchain, and the same "build" flags.
(2) Reproduce the issue, capture the register dump.
(3) Run the following command:
objdump -f -S Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe/DEBUG/TerminalDxe.debug
The point of this exercise is to reproduce the issue with such an OVMF build for which you have a matching "TerminalDxe.debug" file. Once you do that, you can run "objdump" on the ".debug" file, and get a disassembly of the TerminalDxe driver, inter-leaved with the C language source code.
Then, we can do two things:
- we can verify whether (EntryPoint - ImageBase), from the register dump, matches the (relative) "start address" that "objdump -f" reports,
- we can take the crash offset (RIP - ImageBase), from the register dump, and use that offset into the "objdump -S" disassembly, to narrow down what the terminal driver may have been doing to trigger the crash.
It's not necessarily the terminal driver's fault that encounter a crash, but knowing what TerminalDxe was up to, might shed light on the actual reason. It's of course also possible that TerminalDxe *is* at fault. We'll see.
If possible, please post:
- your precise edk2 version (if you have local patches, it would be best to reproduce with an upstream-only tree),
- your full firmware log (feel free to compress it),
- the register dump from serial,
- the objdump (disassembly) output (feel free to compress it).