similar to: [PATCH] efi/main: add retry to exit_boot()

I am a UEFI/BIOS developer. We UEFI PXE boot dozens of times per night. We have run into this error more than a couple of times. We have also done thousands of UEFI PXE boots with debug statements to prove that the patch works. From: "Tom Huibregtse via Syslinux" <syslinux at syslinux.org> To: syslinux at syslinux.org Sent: Thursday, June 11, 2020 8:04:06 AM Subject:

On Tue, Aug 25, 2015 at 11:54 PM, celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Some firmware implementations may need ExitBootServices to be called > twice. The second time with an updated memory map key. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> > --- > efi/main.c | 75

On Mon, Nov 2, 2015 at 10:23 PM, Celelibi <celelibi at gmail.com> wrote: > 2015-11-02 12:34 UTC+01:00, Gene Cumm <gene.cumm at gmail.com>: >> On Tue, Aug 25, 2015 at 11:54 PM, celelibi--- via Syslinux >> <syslinux at zytor.com> wrote: >>> From: Sylvain Gault <sylvain.gault at gmail.com> >>> >>> Some firmware implementations may need

On Wed, 26 Aug 2015 05:54:04 +0200 celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Some firmware implementations may need ExitBootServices to be called > twice. The second time with an updated memory map key. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> > --- > efi/main.c |

From: Sylvain Gault <sylvain.gault at gmail.com> On some architecture, including my hardware, the function ExitBootServices may need to be called twice in order to successfully exit the boot services. As stated by the UEFI spec, the first call to ExitBootServices may perform a partial shutdown of the services. It seems that during this partial shutdown, the memory map can be modified, thus

2015-11-02 12:34 UTC+01:00, Gene Cumm <gene.cumm at gmail.com>: > On Tue, Aug 25, 2015 at 11:54 PM, celelibi--- via Syslinux > <syslinux at zytor.com> wrote: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> Some firmware implementations may need ExitBootServices to be called >> twice. The second time with an updated memory map key. >>

From: Sylvain Gault <sylvain.gault at gmail.com> Some firmware implementations may need ExitBootServices to be called twice. The second time with an updated memory map key. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/main.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 64 insertions(+), 11 deletions(-) diff --git

2015-11-03 11:24 UTC+01:00, Gene Cumm <gene.cumm at gmail.com>: > On Mon, Nov 2, 2015 at 10:23 PM, Celelibi <celelibi at gmail.com> wrote: >> 2015-11-02 12:34 UTC+01:00, Gene Cumm <gene.cumm at gmail.com>: >>> On Tue, Aug 25, 2015 at 11:54 PM, celelibi--- via Syslinux >>> <syslinux at zytor.com> wrote: >>>> From: Sylvain Gault

On Tue, Nov 3, 2015 at 8:37 AM, Celelibi <celelibi at gmail.com> wrote: > 2015-11-03 11:24 UTC+01:00, Gene Cumm <gene.cumm at gmail.com>: >>> So, why not try a memory allocation anyway? It works on some >>> implementations (including mine) despite being forbidden by the >>> specification, but we're in this situation because the firmware was

Hi, I'm using virtio to implement a mac80211 device in the guest. On the host side I plan to use a simple network simulation to control delivery of frames between guests. Right now I've used the vhost approach on the host side and can pass buffers from guest to host and back using virtio. My immediate problem is how to have the host-side tx kick handler get the host-side rx kick handler

Hi, I'm using virtio to implement a mac80211 device in the guest. On the host side I plan to use a simple network simulation to control delivery of frames between guests. Right now I've used the vhost approach on the host side and can pass buffers from guest to host and back using virtio. My immediate problem is how to have the host-side tx kick handler get the host-side rx kick handler

Hi, Le 18/06/2020 ? 22:24, Tom Huibregtse via Syslinux a ?crit?: > I am a UEFI/BIOS developer. We UEFI PXE boot dozens of times per night. We have run into this error more than a couple of times. We have also done thousands of UEFI PXE boots with debug statements to prove that the patch works. <snip> As far as I can tell, the development of Syslinux has stalled since more than one

Hello, I'm booting linux-3.16-686-pae kernel (32-bit) via syslinux.efi 64-bit version. After boot linux sees only 2.5G of RAM while system has 32G installed. If I boot the same kernel with GRUB64 efi instead of syslinux then amount of RAM available to linux is 32G. Is this a bug or I'm missing something? syslinux.cfg: label live-686-pae menu label Linux (686-pae) menu

On Thu, Jun 18, 2020 at 5:09 PM Didier Spaier via Syslinux < syslinux at syslinux.org> wrote: > > As far as I can tell, the development of Syslinux has stalled since more > than one year as shows the log of the git repository. And if I remember > well many very old patches are still in the waiting list. > FWIW, this is one of the last posts I see from H. Peter Anvin:

Good day, Geoff. On 2024-12-02 03:22, Geoff Winkless wrote: > [...] > > I tried (a truncated version of) your instructions with my kernel and > it boots fine under qemu. Sadly that same kernel will not boot on my > real hardware (an ASRock N100-based board). > Just to confirm, are these 2 points all true?: 1. On the "ASRock N100-based board," your

Hello all, I experienced some problems with "kinit". It had problems to determine my root device (/dev/hda3) and to create /dev/root with the appropriate major and minor device number. I don't use udev or devfs on this system so far. The patch I wrote to solve it is attached to this email. I would like to extend "kinit" a bit: * Removing the pivot_root stuff and

Yes, I think so. The integer really means the same as EFI's ExitBootServices. Matt Fleming <matt at console-pimps.org> wrote: >On Fri, 02 Aug, at 07:50:57AM, H. Peter Anvin wrote: >> I don't know if there is a meaningful difference between "localboot >-1" >> and "localboot 0" on EFI... they are really two different ways to ask >> the BIOS

Hi all, I'm terribly sorry that I cannot follow emails in my gmail inbox, since gmail is blocked by China govement, as many of you may have already known. I'm a HP employee in China and we are going through the splitting process, so the blade server I was using were packed up and should be moved into a new room. I will try the latest source if possible. Thank you very much for your works.

hello hpa, please pull for the latest git pull git://brane.itp.tuwien.ac.at/~mattems/klibc.git maks with the following shortlog: maximilian attems (9): mount: add nodev, noexec and nosuid options mount: add -n option cpio: small cleanups readlink: s/link/link_name/ kinit, mknod: s/(major|minor)/\1_num/ klibc: strcspn, strpbrk, strspn include string.h

On 08/01/2013 01:13 AM, Matt Fleming wrote: > > I've got a patch to support LOCALBOOT -1 on EFI, which will boot the > next entry in the EFI Boot Manager (the thing configured with > efibootmgr), and which I'll commit shortly, but it doesn't support > LOCALBOOT 0. > > I'm not actually convinced that we should support LOCALBOOT 0 under EFI. > Even on BIOS,