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 interrup
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 a
> 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 j
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 t
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.
> >
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 d
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
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 f
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
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
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 fl
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-o
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]
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 imm
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
> > > >> [c
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
--- a
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_migra
(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] .fal
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
> >> [c
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+0xd
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: c019c
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: c
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 t
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 h
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
1) The kernel panic on first attempt
Unable to handle kernel paging request for data at address 0x
F
25 matches
Mail list logo
