Closed #113.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/113#event-3547720442___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
Merged in #120
Thank you for all the debugging!
--
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-658659393___
ipxe-devel mailing list
@mcb30
We have tested [this](https://github.com/ipxe/ipxe/pull/120) on 2 systems and
it fixes the problem. Thanks!
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Hi Michael,
Thanks for the fix, we will try that. I have updated my profile with the
public name and email address.
Name: James Wang
Email: jamesw...@ami.com.tw
From: Michael Brown [mailto:notificati...@github.com]
Sent: Wednesday, July 15, 2020 1:42 AM
To: ipxe/ipxe
Cc: JamesWang [王家明];
I have created #120 which seems to fix the root cause. With this fix, I am
able to boot ESXi as expected.
@JamesWangAmiTw I don't have a name and email address for you: could you please
let me know which name and e-mail to use for the commit log message?
--
You are receiving this because you
@jjohnson42 Your suspicion seems to be correct: the TPL is being raised by the
call to `xfer_open()` and so `efi_snp_claim()` is saving the wrong TPL.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@JamesWangAmiTw Thanks for the link. I have reproduced some kind of lockup
using qemu with an iPXE ROM (8086100e.efirom). The last messages seen on
screen are:
```
Shutting down firmware services...
Using 'simple offset' UEFI RTS mapping policy
```
Booting qemu from the ISO does not hang at
@mcb30
We followed [PXE Boot the ESXi Installer Using a Web
Server](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-147D7509-EFB1-4391-973F-48B015B85C83.html)
In AMI BIOS Setup: Advanced - Network Stack Configuration: Enable all "Network
Stack"and "Ipv4 PXE
@mcb30
Yes you are right, I have the wrong impression without double checking the
code, the timer calls 'efi_tick()' indeed.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@JamesWangAmiTw The timer callback function is `efi_tick()`, not
`efi_currticks()`. The timer event controlled by
`efi_tick_startup()`/`efi_tick_shutdown()` does not execute the code in
`efi_currticks()`.
There should not be any code path that leads to `efi_currticks()` while at
@mcb30
Sorry for not being specific in my [previous
comment](https://github.com/ipxe/ipxe/pull/113#issuecomment-651511355). I
didn't mean TPL is never restored anywhere but it was changed in timer event.
When OS image starts, is the `efi_currticks()` still active?
I assume it only stops
@jjohnson42 Thanks for the hints about reproduction via ESXi 7's bootx64.efi.
I will try to assemble a test case in qemu that demonstrates the problem. If
you have a minimal test case ready to use, that would be really helpful.
@huanghe4 What you are describing is not a **root** cause. If
@mcb30 ,
The root cause is in static unsigned long efi_currticks ( void );
Then please print the original TPL in this function.
Because this TPL is always raised to TPL_CALLBACK, then when
gEfiEventExitBootServicesGuid is triggerred, some notify function which are
registerred at TPL_CALLBACK
Alternatively, if efi_snp_old_tpl seems to have been previously assigned,
perhaps don't save a new 'old' value?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
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
>
@huanghe4 The expected mechanism (as documented in [[efi] Run at TPL_CALLBACK
to protect against UEFI
timers](https://github.com/ipxe/ipxe/commit/c89a446cf09f30a121ae21d91f4a1aa071044084#diff-8abaf825db412e28b0c57b0f8947ed23)
is that iPXE code runs at TPL_CALLBACK almost all of the time, in
@mcb30,
It raised TPL to TPL_CALLBACK and never restored it. NotifyFunction of
EVT_SIGNAL_EXIT_BOOT_SERVICES will not be called because of that while booting.
The change of efi_currticks() causing this problem was from [[efi] Run at
TPL_CALLBACK to protect against UEFI
And it also does not make sense to me that iPXE always restore to TPL_CALLBACK,
even the original TPL is TPL_APPLICATION.
If you do not have env to reproduct this issue, would you print log to monitor
the original/old TPL? Then you will see, it is not always the TPL_CALLBACK.
Please read UEFI
You need an AMI based UEFI BIOS, and then power on and boot ESXi 6.5U3 through
UEFI iPXE and without norts =1 as the parameter of boot loader.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Neither the code change nor the commit message make any sense to me, sorry.
Instead of the commit, could you please provide a way to reproduce your
observed problem?
Thanks.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
I'll second this as a problem. Have been testing 'snponly.efi' and I'm not sure
the circumstances, but occasionally linux will error about trying to exit boot
services, and esxi pretty much always hangs trying to exit boot services (also
some 'keyboard errors' are printed early on) when booted
What's the process to get this fix in?
--
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-635605580___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
This is related to a urgent issue. System would hang.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/113#issuecomment-635241491___
ipxe-devel
@huanghe4 commented on this pull request.
> if ( efi_shutdown_in_progress ) {
efi_jiffies++;
} else {
- bs->RestoreTPL ( TPL_APPLICATION );
- bs->RaiseTPL ( TPL_CALLBACK );
+ Efi_OldTPL = bs->RaiseTPL(
@huanghe4 pushed 1 commit.
1ac1a5067860842fe96f803f6c2e1038971b294c [efi] Adjust Indentation again
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@huanghe4 pushed 1 commit.
ddc0d6049bf44860fe18c14db5ea61d1dd0fb131 [efi] Adjust the Indentation
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@huanghe4 commented on this pull request.
> if ( efi_shutdown_in_progress ) {
efi_jiffies++;
} else {
- bs->RestoreTPL ( TPL_APPLICATION );
- bs->RaiseTPL ( TPL_CALLBACK );
+ Efi_OldTPL = bs->RaiseTPL(
@NiKiZe commented on this pull request.
> if ( efi_shutdown_in_progress ) {
efi_jiffies++;
} else {
- bs->RestoreTPL ( TPL_APPLICATION );
- bs->RaiseTPL ( TPL_CALLBACK );
+ Efi_OldTPL = bs->RaiseTPL( TPL_CALLBACK);
iPXE added a workaround to raise TPL to TPL_CALLBACK always, but it
would cause UEFI firmware exit boot service callback with the same TPL
level cannot be executed. Worse, some UEFI modules set a pointer at exit
boot service callback and use later, then will encounter exception /
hang for invalid
29 matches
Mail list logo
