On Wed, 15 Aug 2007, Lucio Correia wrote:
> It worked fine, both for normal kernel and for dump kernel on Cell. Is
> this patch intended to go mainline?
Yes it is now in my to-linus archive on git.kernel.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Tue, 2007-08-14 at 19:11 -0700, Christoph Lameter wrote:
> Can you try this patch?
Thanks, Christoph
It worked fine, both for normal kernel and for dump kernel on Cell. Is
this patch intended to go mainline?
>
> From 74863f472810cb58dc56dde050616581d38f7673 Mon Sep 17 00:00:00 2001
> From:
On Tue, 2007-08-14 at 19:11 -0700, Christoph Lameter wrote:
Can you try this patch?
Thanks, Christoph
It worked fine, both for normal kernel and for dump kernel on Cell. Is
this patch intended to go mainline?
From 74863f472810cb58dc56dde050616581d38f7673 Mon Sep 17 00:00:00 2001
From:
On Wed, 15 Aug 2007, Lucio Correia wrote:
It worked fine, both for normal kernel and for dump kernel on Cell. Is
this patch intended to go mainline?
Yes it is now in my to-linus archive on git.kernel.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Can you try this patch?
>From 74863f472810cb58dc56dde050616581d38f7673 Mon Sep 17 00:00:00 2001
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Tue, 14 Aug 2007 19:09:00 -0700
Subject: [PATCH] SLUB: Do not fail on broken memory configurations
Print a big fat warning and do what is necessary to
On Wed, 15 Aug 2007, Michael Ellerman wrote:
> > Yes SLUB will fall back but not during bootstrap. Bootstrap needs to
> > carefully place structures on the right nodes. We fail during bootstrap
> > because there is *no* memory available on it.
>
> Sure, you want to have the structures on the
On 8/15/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 14 Aug 2007, Lucio Correia wrote:
>
> > > SLAB boots because it falls back to node 0 for the control structures. So
> > > it creates useless control structures for node 1. These are then never
> > > used since any allocation
On Tue, 14 Aug 2007, Lucio Correia wrote:
> > SLAB boots because it falls back to node 0 for the control structures. So
> > it creates useless control structures for node 1. These are then never
> > used since any allocation attempt to node 1 falls back to node 0.
>
> Hi Christoph,
>
>
On Wed, 2007-08-08 at 13:26 -0700, Christoph Lameter wrote:
> On Wed, 8 Aug 2007, Lucio Correia wrote:
>
> > Hi Christoph,
> >
> > I found a problem with SLUB when trying to boot a kdump kernel on a Cell
> > QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
> > kdump kernel,
On Wed, 2007-08-08 at 13:26 -0700, Christoph Lameter wrote:
On Wed, 8 Aug 2007, Lucio Correia wrote:
Hi Christoph,
I found a problem with SLUB when trying to boot a kdump kernel on a Cell
QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
kdump kernel, everything
On Tue, 14 Aug 2007, Lucio Correia wrote:
SLAB boots because it falls back to node 0 for the control structures. So
it creates useless control structures for node 1. These are then never
used since any allocation attempt to node 1 falls back to node 0.
Hi Christoph,
Shouldn't SLUB
On 8/15/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Tue, 14 Aug 2007, Lucio Correia wrote:
SLAB boots because it falls back to node 0 for the control structures. So
it creates useless control structures for node 1. These are then never
used since any allocation attempt to node 1
On Wed, 15 Aug 2007, Michael Ellerman wrote:
Yes SLUB will fall back but not during bootstrap. Bootstrap needs to
carefully place structures on the right nodes. We fail during bootstrap
because there is *no* memory available on it.
Sure, you want to have the structures on the right node
Can you try this patch?
From 74863f472810cb58dc56dde050616581d38f7673 Mon Sep 17 00:00:00 2001
From: Christoph Lameter [EMAIL PROTECTED]
Date: Tue, 14 Aug 2007 19:09:00 -0700
Subject: [PATCH] SLUB: Do not fail on broken memory configurations
Print a big fat warning and do what is necessary to
On Friday 10 August 2007, Michael Ellerman wrote:
> It comes out of the device tree, just like a regular kernel. The
> device tree for the kdump kernel is built by kexec-tools, it parses
> /proc/device-tree and does a bunch of logic to avoid various reserved
> regions: the kernel, TCE tables, RTAS
On Friday 10 August 2007, Michael Ellerman wrote:
It comes out of the device tree, just like a regular kernel. The
device tree for the kdump kernel is built by kexec-tools, it parses
/proc/device-tree and does a bunch of logic to avoid various reserved
regions: the kernel, TCE tables, RTAS
On 8/9/07, Lucio Correia <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-08-08 at 23:10 +0200, Arnd Bergmann wrote:
> > On Wednesday 08 August 2007, Lucio Correia wrote:
> > > DMA 0 ->12288
> > > Normal 12288 ->12288
> > > early_node_map[2] active PFN ranges
> > > 0:
On 8/9/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Wednesday 08 August 2007, Lucio Correia wrote:
> > DMA 0 -> 12288
> > Normal 12288 -> 12288
> > early_node_map[2] active PFN ranges
> > 0: 0 -> 2560
> > 1: 12287 -> 12288
>
> As Christoph found, this memory map is really strange. Other
On Wed, 2007-08-08 at 23:10 +0200, Arnd Bergmann wrote:
> On Wednesday 08 August 2007, Lucio Correia wrote:
> > DMA 0 ->12288
> > Normal 12288 ->12288
> > early_node_map[2] active PFN ranges
> > 0:0 -> 2560
> > 1:12287 ->12288
>
> As
On Wed, 2007-08-08 at 23:10 +0200, Arnd Bergmann wrote:
On Wednesday 08 August 2007, Lucio Correia wrote:
DMA 0 -12288
Normal 12288 -12288
early_node_map[2] active PFN ranges
0:0 - 2560
1:12287 -12288
As Christoph found, this
On 8/9/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Wednesday 08 August 2007, Lucio Correia wrote:
DMA 0 - 12288
Normal 12288 - 12288
early_node_map[2] active PFN ranges
0: 0 - 2560
1: 12287 - 12288
As Christoph found, this memory map is really strange. Other machines
have something
On 8/9/07, Lucio Correia [EMAIL PROTECTED] wrote:
On Wed, 2007-08-08 at 23:10 +0200, Arnd Bergmann wrote:
On Wednesday 08 August 2007, Lucio Correia wrote:
DMA 0 -12288
Normal 12288 -12288
early_node_map[2] active PFN ranges
0:0 - 2560
On Wednesday 08 August 2007, Lucio Correia wrote:
> DMA 0 -> 12288
> Normal 12288 -> 12288
> early_node_map[2] active PFN ranges
> 0: 0 -> 2560
> 1: 12287 -> 12288
As Christoph found, this memory map is really strange. Other machines
have
On Wed, 8 Aug 2007, Arnd Bergmann wrote:
> In the future, we also may have configurations where we need to run with
> memoryless nodes on a production environment, so it should really just
> work.
Memoryless node support is work in progress currently in mm. You may
encounter strange NUMA issues
On Wednesday 08 August 2007, Christoph Lameter wrote:
>
> > I found a problem with SLUB when trying to boot a kdump kernel on a Cell
> > QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
> > kdump kernel, everything works ok. The fact is that SLUB doesn't find a
> > page frame
On Wed, 8 Aug 2007, Lucio Correia wrote:
> Hi Christoph,
>
> I found a problem with SLUB when trying to boot a kdump kernel on a Cell
> QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
> kdump kernel, everything works ok. The fact is that SLUB doesn't find a
> page frame for
Hi Christoph,
I found a problem with SLUB when trying to boot a kdump kernel on a Cell
QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
kdump kernel, everything works ok. The fact is that SLUB doesn't find a
page frame for allocation in the current node, due to the flag
Hi Christoph,
I found a problem with SLUB when trying to boot a kdump kernel on a Cell
QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
kdump kernel, everything works ok. The fact is that SLUB doesn't find a
page frame for allocation in the current node, due to the flag
On Wed, 8 Aug 2007, Lucio Correia wrote:
Hi Christoph,
I found a problem with SLUB when trying to boot a kdump kernel on a Cell
QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
kdump kernel, everything works ok. The fact is that SLUB doesn't find a
page frame for
On Wednesday 08 August 2007, Christoph Lameter wrote:
I found a problem with SLUB when trying to boot a kdump kernel on a Cell
QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
kdump kernel, everything works ok. The fact is that SLUB doesn't find a
page frame for
On Wed, 8 Aug 2007, Arnd Bergmann wrote:
In the future, we also may have configurations where we need to run with
memoryless nodes on a production environment, so it should really just
work.
Memoryless node support is work in progress currently in mm. You may
encounter strange NUMA issues if
On Wednesday 08 August 2007, Lucio Correia wrote:
DMA 0 - 12288
Normal 12288 - 12288
early_node_map[2] active PFN ranges
0: 0 - 2560
1: 12287 - 12288
As Christoph found, this memory map is really strange. Other machines
have something like
32 matches
Mail list logo
