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

Displaying 20 results from an estimated 3000 matches similar to: "[PATCH] Fix for crash with certain EFIs"

2016 Oct 19
4
[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
2016 Oct 17
1
[PATCH] Fix for crash with certain EFIs
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
2016 Oct 26
2
[PATCH] Fix for crash with certain EFIs
> >> 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
2016 Oct 18
0
[PATCH] Fix for crash with certain EFIs
> 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
2016 Oct 20
2
[PATCH] Fix for crash with certain EFIs
> 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
2016 Oct 20
2
[PATCH] Fix for crash with certain EFIs
> 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 >
2016 Oct 20
0
[PATCH] Fix for crash with certain EFIs
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
2015 Nov 27
8
[PATCH 0/2] Do not use the "red zone" on EFI
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 Nov 28
3
[PATCH 0/2] Do not use the "red zone" on EFI
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
2015 Nov 29
2
[PATCH 0/2] Do not use the "red zone" on 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
2015 Mar 14
0
[PATCH 0/1] EFI access from Com32 modules
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 Dec 01
1
[PATCH 0/2] Do not use the "red zone" on 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
2016 Oct 19
0
[PATCH] Fix for crash with certain EFIs
>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
2017 Nov 02
3
low end file server with h/w RAID - recommendations
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
2016 Oct 20
0
[PATCH] Fix for crash with certain EFIs
> 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
2017 Nov 02
5
low end file server with h/w RAID - recommendations
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
2017 Nov 02
6
low end file server with h/w RAID - recommendations
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
2016 Mar 08
2
Syslinux 6.04-pre1
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
2015 Oct 29
1
Isohybrid wiki page and UEFI
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
2015 Mar 05
4
Problem boot PXE UEFI on HP ML350 Gen9
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