On Tue, 2008-03-04 at 18:42 +0530, Kamalesh Babulal wrote:
Hi Andrew,
The 2.6.25-rc3-mm1 kernel panics while bootup on power box. The machine
booted up
without the panic on the third attempt, but badness call trace were seen
while running
tests
We are taking a HW interrupt ... we
On Tue, 2008-03-04 at 10:33 -0800, Andrew Morton wrote:
Are we somehow enabling interrupts before we've setup
ppc_md.get_irq?
Yes, we are - it's the semaphore rewrite which is doing this in
start_kernel(). It's being discussed.
Enabling interrupts too early on powerpc was discovered
On (04/03/08 12:34), Andrew Morton didst pronounce:
On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a
On (04/03/08 12:07), Christoph Lameter didst pronounce:
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
passing on flags to the page allocator on the
Yes, we are - it's the semaphore rewrite which is doing this in
start_kernel(). It's being discussed.
Enabling interrupts too early on powerpc was discovered to be fatal on
powerpc years ago. It looks like that remains the case.
Regarding these issues. I could make it non fatal and just
On Thu, 06 Mar 2008 11:03:31 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Yes, we are - it's the semaphore rewrite which is doing this in
start_kernel(). It's being discussed.
Enabling interrupts too early on powerpc was discovered to be fatal on
powerpc years ago. It
On Wed, 2008-03-05 at 16:44 -0800, Andrew Morton wrote:
On Thu, 06 Mar 2008 11:03:31 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Yes, we are - it's the semaphore rewrite which is doing this in
start_kernel(). It's being discussed.
Enabling interrupts too early on
In message [EMAIL PROTECTED] you wrote:
Hi Andrew,
The 2.6.25-rc3-mm1 kernel panics while bootup on power box. The machine boote
d up
without the panic on the third attempt, but badness call trace were seen whil
e running
tests
1) The kernel panic on first attempt
Unable to handle
On Tue, 04 Mar 2008 15:40:56 +0100 Michael Neuling [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED] you wrote:
Hi Andrew,
The 2.6.25-rc3-mm1 kernel panics while bootup on power box. The machine
boote
d up
without the panic on the third attempt, but badness call trace were seen
On Tue, 04 Mar 2008 18:42:19 +0530 Kamalesh Babulal
[EMAIL PROTECTED] wrote:
3) Third attempt kernel booted up but had the following call trace 264
times while running
test
Badness at include/linux/gfp.h:110
NIP: c00b4ff0 LR: c00b4fa0 CTR: c019cdb4
REGS:
On Tue, 04 Mar 2008 18:42:19 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
3) Third attempt kernel booted up but had the following call trace 264 times
while running
test
Badness at include/linux/gfp.h:110
NIP: c00b4ff0 LR: c00b4fa0 CTR: c019cdb4
REGS:
Andrew Morton wrote:
[c9edf5f0] [c00b56e4] .__alloc_pages_internal+0xf8/0x470
[c9edf6e0] [c00e0458] .kmem_getpages+0x8c/0x194
[c9edf770] [c00e1050] .fallback_alloc+0x194/0x254
[c9edf820] [c00e14b0] .kmem_cache_alloc+0xd8/0x144
On (04/03/08 21:18), Pekka Enberg didst pronounce:
Andrew Morton wrote:
[c9edf5f0] [c00b56e4] .__alloc_pages_internal+0xf8/0x470
[c9edf6e0] [c00e0458] .kmem_getpages+0x8c/0x194
[c9edf770] [c00e1050] .fallback_alloc+0x194/0x254
On Tue, 4 Mar 2008, Pekka Enberg wrote:
I suspect the WARN_ON() is bogus although I really don't know that part
of the code all too well. Mel?
The warn-on is valid. A situation should not exist that allows both flags
to
be set. I suspect if remove-set_migrateflags.patch
On Tue, 4 Mar 2008, Christoph Lameter wrote:
Slab allocations should never be passed these flags since the slabs do
their own thing there.
The following patch would clear these in slub:
Here's the same fix for SLAB:
diff --git a/mm/slab.c b/mm/slab.c
index 473e6c2..c6dbf7e 100644
---
On Tue, 4 Mar 2008, Pekka Enberg wrote:
[c9edf5f0] [c00b56e4]
.__alloc_pages_internal+0xf8/0x470
[c9edf6e0] [c00e0458] .kmem_getpages+0x8c/0x194
[c9edf770] [c00e1050] .fallback_alloc+0x194/0x254
[c9edf820]
On Tue, 4 Mar 2008, Pekka J Enberg wrote:
On Tue, 4 Mar 2008, Christoph Lameter wrote:
Slab allocations should never be passed these flags since the slabs do
their own thing there.
The following patch would clear these in slub:
Here's the same fix for SLAB:
That is an immediate fix
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
passing on flags to the page allocator on the fallback path.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Christoph Lameter wrote:
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
passing on flags to the page allocator on the fallback path.
Signed-off-by:
(adding Christoph as cc)
On Tue, Mar 4, 2008 at 9:35 PM, Mel Gorman [EMAIL PROTECTED] wrote:
[c9edf5f0] [c00b56e4] .__alloc_pages_internal+0xf8/0x470
[c9edf6e0] [c00e0458] .kmem_getpages+0x8c/0x194
[c9edf770] [c00e1050]
Andrew Morton wrote:
On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
passing on flags to
On Tue, 4 Mar 2008, Pekka Enberg wrote:
Looking at the code, it's triggerable in 2.6.24.3 at least. Why we don't have
a report yet, probably because (1) the default allocator is SLUB which doesn't
suffer from this and (2) you need a big honkin' NUMA box that causes fallback
allocations to
Pekka Enberg wrote:
Christoph Lameter wrote:
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
passing on flags to the page allocator on the fallback path.
24 matches
Mail list logo
