I can confirm same behavior, using bootx64.efi from esxi 7, the following
produces the same behavior he reported:
#!ipxe
chain boot/efi/boot/bootx64.efi -c /path/to/boot.cfg also call
efi_snp_release() of course.
> iPXE then invokes the OS kernel via StartImage(). At this point, the TPL is
> whatever TPL was recorded when iPXE was started, which should be
> TPL_APPLICATION.
Well, iPXE code may still run at this point. In fact it explicitly does for
iPXE booted ESXi boot loader. efi_download.c has three functions that may be
called by the loaded efi executable. At the very least they call
efi_download_start. I don't know the full flow of the code, but I am wondering
if efi_download_start use of intf_init or xfer_open before calling
efi_snp_claim causes a RaiseTPL before efi_snp_claim stores the old TPL causing
it to erroneously 'save' iPXE induced TPL_CALLBACK as the 'old' TPL? I am a bit
preoccupied today, but I'd be tempted to modify efi_download_start() to call
claim earlier and call efi_snp_release() on error. I'm a bit rusty and I
botched even a simple change so I'm not sure.
If my naive guess happens to be in the ballpark, it doesn't explain a *seeming*
improvement in our Linux boot testing, where iPXE DL protocol is not used and
we also were seeing errors on kernel trying to exit boot servicing that
happened *sometimes*. However this was a little fuzzier so it may not be
completely accurate.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/113#issuecomment-651752678
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
