similar to: [PATCH][git-pull] MEMDISK: Process "mem=" parameter and apply to e820 ranges

git://git.zytor.com/users/genec/syslinux.git Branch memdisk-maxmem-for-hpa This is a preliminary hack to introduce a new option that will allow an end-user to limit the amount of available RAM as returned by any call that MEMDISK touches. This works by adding additional memory reservation(s) (through insertrange()) to reserve the memory between the specified address and the top of RAM. For

Reply All should keep it on the list. On Wed, Sep 9, 2015 at 9:40 PM, <john_cutler at dell.com> wrote: > Gene, > > Thank you for your response I have a follow up to that. > > I have 2 different machines using the same pxe boot for both machines > machine A fails at pxe boot if i don?t have mem=2048m while machine b > will fail if it contains mem=2048m Not

If the kernel is relocatable and the protected mode code will not fit in the initially determined location, that code will be moved to the next available location. However, beginning with commit 8f470e7b, the code is moved to the initially determined location instead of the next available location because prot_mode_base is no longer updated to the correct location. Since whdr->code32_start is

Correct base's type to match its initialization from prot_mode_base and passage to syslinux_memmap_find(). Tested with extlinux. Signed-off-by: Scot Doyle <lkml14 at scotdoyle.com> --- com32/lib/syslinux/load_linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 06ae2a9..ac73729 100644 ---

On Fri, Feb 20, 2015 at 8:08 AM, Patrick Masotta via Syslinux <syslinux at zytor.com> wrote: > This patch adds to the core EFI image booting capabilities. > It was tested on VMware EFI clients and HP Elitebook EFI notebooks, > only on PXE environments but it should work on non-PXE scenarios as well. > > Feedback appreciated. If you've made any changes to this, I'd

On Fri, Jun 10, 2016 at 2:06 AM, Adam Goldman via Syslinux <syslinux at zytor.com> wrote: > PXELINUX has stopped recognizing the keeppxe option on the kernel > command line. Here is a patch to make it work again. > > With COM32, it is no longer possible to use preprocessor directives to > determine the SYSLINUX variant. The code inside the #if will never be > compiled. So,

Hi, in syslinux-386, I think I've found a problem in com32/lib/syslinux/load_linux.c that leads to cmdline being truncated unnecessarily when e.g. linux.c32 is used. The patch below fixes the problem for me. But I don't know, whether the patch is safe in all cases. I tried to reproduce the logic found in runkernel.inc, but I might have missed something. So, feel free to tell me

Impact: None. The end of memory needs to be page aligned: if the initrd expands beyond it, Linux kernels won't be able to access the last few bytes. Signed-off-by: Pierre-Alexandre Meyer <pierre at mouraf.org> --- com32/lib/syslinux/load_linux.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c

I"m sorry if this is not the correct place for this question but i have not been able to locate any documentation on the mem=size option for memdisk The only thing i have found is mem=size Mark available memory above this point as Reserved. But i'm not sure if this is accurate and i'd like to understand the purpose of this option I am PXE booting a LENOVO machine which

On 07/26/2013 01:27 AM, syslinux-bot for Matt Fleming wrote: > diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c > index 851d467..37c8df0 100644 > --- a/com32/lib/syslinux/load_linux.c > +++ b/com32/lib/syslinux/load_linux.c > @@ -125,10 +125,29 @@ static int map_initramfs(struct syslinux_movelist **fraglist, > } > > static size_t

Use reserve_early rather than e820 reservations for Xen start info and mfn->pfn table, so that the memory use is a bit more self-documenting. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/xen/setup.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 15c6c68..ad0047f 100644

Some kernel images use the Linux kernel boot protocol and header structure, but do not actually have any protected-mode code. For instance, grub's 1024-byte lnxboot.img consists of 1024 real-mode bytes and 0 protected-mode bytes; you can concatenate it with a full grub core.img to produce a self-contained bootable kernel, but you can also use it standalone as the kernel with the core.img

move e820 ACPI entries into RAM. ACPI RAM maybe used as RAM after ACPI data is parsed, but current e820 entries don''t comply to this. Signed-off-by: Xin Li <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

All, When attempting to pxeboot the latest Xen3.0 hypervisor/kernel it was failing with the following error: ------ \ \/ /___ _ __ |___ / / _ \ _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ |_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |____(_)___/ \__,_|_|

The following was just sent to me... since some people have experienced these kinds of problems and asked about them I thought I'd forward it. Please leave the discussion on the linux-kernel mailing list, however. -hpa -------------- next part -------------- An embedded message was scrubbed... From: achen at t-online.de (Alexander Achenbach) Subject: [PATCH] zero-size E820 memory (kernel

The changeset ''12803:df5fa63490f4da7b65c56087a68783dbcb7944f8'' added a new hypercall XENMEM_set_memory_map for specifying the e820 mapping. There was a small bug in the userspace side of this change though - the e820 mapping was specified based on the ''memory_static_min'' domain info parameter which means the memory map size is clamped to the value

On 12/04/2013 12:38 AM, Christian Hesse wrote: > > Sure. Here we go: > > boot: debug -e bios_boot_linux calc_cmdline_offset > boot: ipxe.lkrn > Loading ipxe.lkrn... ok > cmdline_offset at 0x9f7e0 > Initial memory map: > Could not find location for protected-mode code > Booting kernel failed: Invalid argument > OK, that was a useful clue. I think I know what is

Hi, I tested this version and it works all right ! Thanks a lot for the quick fix. Do you still want to see the output in order to check everything is OK, or you don't need it ? --------------------- Sylvain Faivre EdifiXio - AIH Team +33 1 56 90 51 24 www.edifixio.com > -----Message d'origine----- > De : H. Peter Anvin [mailto:hpa at zytor.com] > Envoy? : mardi 18 novembre

I'm seeing this on a HP Blade and i'm not sure why this is happning since the nature of the issue is so wierd. I compiled mboot.c with a DEBUG defined in the mboot.c file. In the funciton init_mmap(), it prints the e820 map and on the HP blade this map values come out to be totally random. Some weird numbers which dont make any sense at all. However, if i add a while(1); or a exit(1); at

I can''t find this patch on any mailing list to respond to so starting a new thread. In case I''ve not missed it but instead it really wasn''t posted -- in the future can we try and ensure that any patches have been posted at least once. Same for the pull request, it should go to a list. BTW the version in Konrad''s tree is Stefano''s 2.6.39-rc1-fixes