similar to: pxelinux and 2.6.9 kernel parameters

Displaying 20 results from an estimated 2000 matches similar to: "pxelinux and 2.6.9 kernel parameters"

[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
2020 Apr 30
2
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
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 of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
2020 Apr 30
2
[PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED
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 of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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? > >> > >> I assume: > >> > >> The
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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? > >> > >> I assume: > >> > >> The
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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 20:43:39 +0200 David Hildenbrand <david at redhat.com>
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 May 01
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
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 20:43:39 +0200 David Hildenbrand <david at redhat.com>
Re: Possible bug with kernel decompressor.
2004 Jul 15
3
Re: Possible bug with kernel decompressor.
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 >
[PATCH v2 0/3] mm/memory_hotplug: Allow to not create firmware memmap entries
2020 Apr 30
5
[PATCH v2 0/3] mm/memory_hotplug: Allow to not create firmware memmap entries
This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 Apr 30
3
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
David Hildenbrand <david at redhat.com> writes: > 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
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 Apr 30
3
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
David Hildenbrand <david at redhat.com> writes: > 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
[PATCH RFC v3 6/9] mm: Allow to offline PageOffline() pages with a reference count of 0
2019 Oct 16
3
[PATCH RFC v3 6/9] mm: Allow to offline PageOffline() pages with a reference count of 0
On Wed 16-10-19 14:50:30, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that
[PATCH RFC v3 6/9] mm: Allow to offline PageOffline() pages with a reference count of 0
2019 Oct 16
3
[PATCH RFC v3 6/9] mm: Allow to offline PageOffline() pages with a reference count of 0
On Wed 16-10-19 14:50:30, David Hildenbrand wrote: > On 16.10.19 13:43, Michal Hocko wrote: > > On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > > > virtio-mem wants to allow to offline memory blocks of which some parts > > > were unplugged, especially, to later offline and remove completely > > > unplugged memory blocks. The important part is that
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 Apr 30
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: > > > > Why does the firmware map support hotplug entries? > > I assume: > > The firmware memmap was added primarily for x86-64 kexec (and still, is > mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs > get hotplugged on real HW, they get added to e820.
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
2020 Apr 30
2
[PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: > > > > Why does the firmware map support hotplug entries? > > I assume: > > The firmware memmap was added primarily for x86-64 kexec (and still, is > mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs > get hotplugged on real HW, they get added to e820.