similar to: [PATCH] Fix for crash with certain EFIs

Hi Ady, Would it work if we removed "ifdef EFI_BUILD" condition and just add -mno-red-zone for all x86_64 builds? If not, do you have any ideas how to pass this flag? This could work, because the patch is adding the -mno-red-zone flag only for x86_64 builds, which are only used in the form of the efi64 target. The efi32 and bios targets are both 32-bit. BTW. I also tried 6.04-pre1 and

Hello syslinux maintainers, I came across the issue of syslinux crashing with some EFIs in the UEFI boot mode. Upon closer investigation it turned out that most object files which go into syslinux efi64 are compiled with the so-called red zone. Some EFIs follow Windows ABI more strictly and cause syslinux to crash due to stack overwrite. Looking at mk/efi.mk there was a previous attempt to fix

> >> Let me double check what the status of 6.04-pre1 is. Maybe this patch > >> is not necessary at all! > > OK, I have verified beyond doubt that 6.04-pre1 (prebuilt from > kernel.org) indeed does fix the issue on the affected systems. > > Again, sorry for the churn! > > Best Regards, > - Chris OK, so, from the user's point of view, the

> Thank you very much for this, I have been running into this issue a number > of times but could never get a firm grip on it. > > Especially HP Gen9 proliants seem to suffer from it by sometimes throwing a > stack dump very early in the boot. In the past we worked around it by > forcing bios boot. > > > > After rebuilding it with -mno-red-zone the problem

> Let me double check what the status of 6.04-pre1 is. Maybe this patch > is not necessary at all! Just a reminder: _ 6.04-pre1 can be downloaded from kernel.org, and it includes pre-built binaries, so no "make" anything is needed (and to some degree, not always recommended). _ In many cases, testing with pre-built official binaries is desired, so others can attempt to

> Thank you all. > > It looks like -mno-red-zone flag is already in master branch since > commit 7d70885d, but it seems it is applied to all EFI builds. Finally we are on the same page. > > IIUC, the problem only affects efi64 builds. Have you actually tested efi32 (ia32) builds? > > So here's the modification of my patch to only apply -mno-red-zone >

Thank you all. It looks like -mno-red-zone flag is already in master branch since commit 7d70885d, but it seems it is applied to all EFI builds. IIUC, the problem only affects efi64 builds. So here's the modification of my patch to only apply -mno-red-zone flag to efi64 target. The patch is against master. I verified that it builds correctly in master. Please feel free to accept or reject

From: Sylvain Gault <sylvain.gault at gmail.com> The System V ABI for x86-64 specify that a "red zone" is an area of 128 bytes above the current stack frame. This area can be used by a called function in order to avoid the overhead of modifying the stack pointer. The direct effect is that interrupt/event/signal handlers must not write to this area. In the UEFI calling convention,

2015-11-28 8:47 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>: > >> From: Sylvain Gault <sylvain.gault at gmail.com> >> >> The System V ABI for x86-64 specify that a "red zone" is an area of 128 >> bytes >> above the current stack frame. This area can be used by a called function >> in >> order to avoid the overhead of

This patch adds to Com32 modules the capabilities of accessing the EFI environment The idea is simple, the EFI parameters "image" and "table" received by syslinux.efi's efi_main() are stored in the "firmware" structure, next they are retrieved from the Com32 module which is linked against the gnu-efi static library. The Com32 module can use the EFI

2015-11-30 14:14 UTC+01:00, Patrick Masotta <masottaus at yahoo.com>: >>>> >> The addition of the EFI_BUILD variable inside Makefiles could potentially >> affect scripts such as package builders, perhaps even the way the >> official (pre)release archives are built(?). > <<< > > I think the -mno-red-zone thing is a good catch, the rest of EFI

On Nov 28, 2015 2:51 AM, "Ady via Syslinux" <syslinux at zytor.com> wrote: > > From: Sylvain Gault <sylvain.gault at gmail.com> > > > > The System V ABI for x86-64 specify that a "red zone" is an area of 128 bytes > > above the current stack frame. This area can be used by a called function in > > order to avoid the overhead of

>Have you tried 6.04-pre1 or later? With pre-built binaries? > >Would you please clarify? Are you saying that 6.04-pre1 is failing too, >but building 6.03 with this proposed patch is working correctly? I should have been clear about which version I used. I modified 6.03 and built with -mno-red-zone and that seems to fix the problem. I also tried 6.04-pre1 with the pre-built binaries

DO NOT buy the newer HPE DL20 gen9 or ML10 gen9 servers then (especially if using CentOS 6.x) I don't use hardware raid (mdadm for the win!) so cannot speak to that. DL20, bought it on a stock 'B' sale. Great price. Works well on Windows. HPE doesn't sell hard drive trays, etc. You pretty much have to buy their equipment. You CAN get 3rd party parts (drive trays, etc.) but will

> If the -mno-red-zone flag was already applied for all EFI builds (in > the current git master head and in 6.04-pre1), then what exactly makes > the current 6.04-pre1 *pre-built* binaries fail for you? You are right, Ady. I have no way of knowing whether 6.04-pre1 works or not. I've got this bug from a customer who has systems where syslinux fails. Unfortunately I don't have

I'm just about to build a new server and I'm looking for recommendations on what hardware to use. I'm happy with either a brand name, or building my own, but would like a hardware RAID controller to run a pair of disks as RAID1 that is actually compatible with and manageable through Linux. Any recommendations would be appreciated. Gary

hw wrote: > Richard Zimmerman wrote: >> DO NOT buy the newer HPE DL20 gen9 or ML10 gen9 servers then (especially >> if using CentOS 6.x) > > What would you suggest as alternative, something from Dell? Yep, Dell's are good. And I do *not* want to buy from HP, because their support is nothing like good. And once you run out the warranty, they don't want to even let you

On 03/08/16 08:58, Shao Miller via Syslinux wrote: > While building on AMD64 CentOS 6, I noticed that glibc-devel.i686 was > needed for some (U)EFI stuff, but isn't in the README. I'm not sure if > other Linux flavours will have counterpart needs. - Shao Hmmm... that makes me somewhat nervous. I'm wondering if we're pulling in stuff we should not. -hpa

Bruno Cornec via Syslinux said on Sun, Oct 25, 2015 at 12:39:53PM +0100: >I'm indeed trying to have everything I need on the boot part of the >ISO9660 image (kernel and an initrd which is normally built by >MondoRescue which then mounts the ISO9660 FS to have access to >additional content once booted). For now I do not seem to get to boot the >kernel. > >My machines are HP

Hi All, My PXE configurations works fine for a bios PXE (the server in legacy mode) but hangs in an EUFI mode. Look like it can transfer the bootx64.efi but not the next one ldlinux.e64 Any ideas? Thanks Software> syslinux ver 6.3 atftp 7.1 Log server side >> Booting Embedded LOM 1 Port 1 : HP Ethernet 1Gb 4-port 331i Adapter - NIC (PXE IPv4) >> Booting PXE over