similar to: How to specify memory mapping to xen?

Hi, I''m trying to boot xen dom0 on a Compaq Proliant 2500 but so far I have been unsuccessful, I get (XEN) Not enough memory to stash the DOM0 kernel image. On a normal linux 2.6 kernel to boot I have pass "memmap=exactmap memmap=640K@0 memmap=319M@1M" to the kernel at boot otherwise it hangs because of the way Compaq Bios reports the system memory. I''ve tryed to use

Hi, I recently took delivery of a bunch of HP BL25p blades to add to my collection. I am attempting to install Centos4 x86_64 using PXE - the initial PXE DHCP stuff works, and the kernel and initrd are downloaded, but the server then immediately clears the screen and displays: "1706-Smart Array Controller Extended BIOS Data Area Memory Corrupted Array Controller Interrupt 14h BIOS Cannot

Matthew Schumacher wrote: > List, > > I think I found a bug here because I can repeatably get the same kernel > (checked with md5sum) to decompress and to fail with the error: > > invalid compressed format (err=2) > > --System halted > > > Here is how I can reproduce the problem: > > Boot 2.6.8-rc1 > Run md5sum on 2.6.8-rc1 kernel >

I am using RHEL4 with kernel 2.6.9. I can load this on my hardware by passing the following kernel parameter: memmap=496M at 16M, and it loads up and runs OK. If I do not use this parameter, I get a kernel panic. When I try to load the same software onto the same hardware using PXE, I add the same parameter on the server's tftpboot/pxelinux/pxelinux.cfg/default file: append

On 01.05.20 22:12, Dan Williams wrote: > On Fri, May 1, 2020 at 12:18 PM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:43, Dan Williams wrote: >>> On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 20:03, Dan Williams wrote: >>>>> On Fri, May 1, 2020 at

On 01.05.20 22:12, Dan Williams wrote: > On Fri, May 1, 2020 at 12:18 PM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:43, Dan Williams wrote: >>> On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 20:03, Dan Williams wrote: >>>>> On Fri, May 1, 2020 at

On Fri, May 1, 2020 at 12:18 PM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 20:43, Dan Williams wrote: > > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: > >> > >> On 01.05.20 20:03, Dan Williams wrote: > >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote:

On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 20:03, Dan Williams wrote: > > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: > >> > >> On 01.05.20 19:45, David Hildenbrand wrote: > >>> On 01.05.20 19:39, Dan Williams wrote: > >>>> On Fri, May 1, 2020

On 30.04.20 10:11, Dan Williams wrote: > On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 29.04.20 18:08, David Hildenbrand wrote: >>> Some paravirtualized devices that add memory via add_memory() and >>> friends (esp. virtio-mem) don't want to create entries in >>> /sys/firmware/memmap/ - primarily to

Some devices/drivers that add memory via add_memory() and friends (e.g., dax/kmem, but also virtio-mem in the future) don't want to create entries in /sys/firmware/memmap/ - primarily to hinder kexec from adding this memory to the boot memmap of the kexec kernel. In fact, such memory is never exposed via the firmware memmap as System RAM (e.g., e820), so exposing this memory via

On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david at redhat.com> wrote: > > On 29.04.20 18:08, David Hildenbrand wrote: > > Some paravirtualized devices that add memory via add_memory() and > > friends (esp. virtio-mem) don't want to create entries in > > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > > memory to the boot memmap

On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 19:45, David Hildenbrand wrote: > > On 01.05.20 19:39, Dan Williams wrote: > >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: > >>> > >>> On 01.05.20 18:56, Dan Williams wrote: > >>>> On Fri, May 1,

On 01.05.20 20:03, Dan Williams wrote: > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 19:45, David Hildenbrand wrote: >>> On 01.05.20 19:39, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On 01.05.20

On 01.05.20 20:03, Dan Williams wrote: > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 19:45, David Hildenbrand wrote: >>> On 01.05.20 19:39, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On 01.05.20

On Fri, May 1, 2020 at 2:11 PM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 22:12, Dan Williams wrote: [..] > >>> Consider the case of EFI Special Purpose (SP) Memory that is > >>> marked EFI Conventional Memory with the SP attribute. In that case the > >>> firmware memory map marked it as conventional RAM, but the kernel >

On 01.05.20 18:56, Dan Williams wrote: > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 00:24, Andrew Morton wrote: >>> On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: >>> >>>>> >>>>> Why does the firmware map support hotplug entries?

Some paravirtualized devices that add memory via add_memory() and friends (esp. virtio-mem) don't want to create entries in /sys/firmware/memmap/ - primarily to hinder kexec from adding this memory to the boot memmap of the kexec kernel. In fact, such memory is never exposed via the firmware (e.g., e820), but only via the device, so exposing this memory via /sys/firmware/memmap/ is wrong:

On 01.05.20 20:43, Dan Williams wrote: > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:03, Dan Williams wrote: >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 19:45, David Hildenbrand wrote: >>>>> On 01.05.20

On 01.05.20 20:43, Dan Williams wrote: > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:03, Dan Williams wrote: >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 19:45, David Hildenbrand wrote: >>>>> On 01.05.20

On 01.05.20 19:39, Dan Williams wrote: > On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 18:56, Dan Williams wrote: >>> On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 00:24, Andrew Morton wrote: >>>>> On Thu, 30 Apr 2020