kmemleak, cpu usage jump out of nowhere
in [Kernel]
|
From: Zeno Davatz on 16 Jul 2010 05:50 On Fri, Jul 16, 2010 at 11:32 AM, Pekka Enberg <penberg(a)cs.helsinki.fi> wrote: > Zeno Davatz wrote: >> >> This version has some problem with the DRM but no CPU eater yet. >> >> http://www.flickr.com/photos/zrr/4798885756/ >> >> This version boots again just fine: >> >> Linux zenogentoo 2.6.34-rc5-00059-gc2b4127 #105 SMP Fri Jul 16 >> 11:13:21 CEST 2010 i686 Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz >> GenuineIntel GNU/Linux > > You're going into the wrong direction. If 2.6.34-rc7 works just fine, you > shouldn't be testing 2.6.34-rc5. > >> >> As I understand I am bisecting upwards. Every time it does not boot >> correctly I do >> >> git bisect bad after the next boot. > > No, you should only do "git bisect bad" if you find a CPU eater and "git > bisect good" if you don't. For the non-booting kernels you should do "git > bisect skip"; otherwise git gets confused as we can see here. > > Did you test v2.6.35-rc1? Does it have the CPU eater problem? If yes, please > just reset your bisection > > �git bisect reset > �git bisect start > �git bisect good v2.6.34-rc7 > �git bisect bad v2.6.35-rc1 > > and use 'git bisect skip' for kernels that don't boot or build. This one looks good to: Linux zenogentoo 2.6.34-06562-gd79df0b #107 SMP Fri Jul 16 11:44:36 CEST 2010 i686 Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux Best Zeno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 16 Jul 2010 14:40 it seems that you are using 32bit kernel. please check if this one help. Thanks Yinghai Subject: [PATCH -v3] x86,mm: fix 32bit numa sparsemem Borislav Petkov <borislav.petkov(a)amd.com> reported his 32bit numa has problem: [ 0.000000] Reserving total of 4c00 pages for numa KVA remap [ 0.000000] kva_start_pfn ~ 32800 max_low_pfn ~ 375fe [ 0.000000] max_pfn = 238000 [ 0.000000] 8202MB HIGHMEM available. [ 0.000000] 885MB LOWMEM available. [ 0.000000] mapped low ram: 0 - 375fe000 [ 0.000000] low ram: 0 - 375fe000 [ 0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 1000 1000 => 34e7000 [ 0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 200 40 => 34c9d80 [ 0.000000] alloc (nid=0 100000 - 7ee00000) (1000000 - ffffffffffffffff) 180 40 => 34e6140 [ 0.000000] alloc (nid=1 80000000 - c7e60000) (1000000 - ffffffffffffffff) 240 40 => 80000000 [ 0.000000] BUG: unable to handle kernel paging request at 40000000 [ 0.000000] IP: [<c2c8cff1>] __alloc_memory_core_early+0x147/0x1d6 [ 0.000000] *pdpt = 0000000000000000 *pde = f000ff53f000ff00 .... [ 0.000000] Call Trace: [ 0.000000] [<c2c8b4f8>] ? __alloc_bootmem_node+0x216/0x22f [ 0.000000] [<c2c90c9b>] ? sparse_early_usemaps_alloc_node+0x5a/0x10b [ 0.000000] [<c2c9149e>] ? sparse_init+0x1dc/0x499 [ 0.000000] [<c2c79118>] ? paging_init+0x168/0x1df [ 0.000000] [<c2c780ff>] ? native_pagetable_setup_start+0xef/0x1bb looks like it allocate much high address for bootmem. try to cut limit with get_max_mapped() -v3: make alloc_bootmem_node could fallback to other node. just like old alloc_bootmem_node did need this patch for 2.6.34 and 2.6.35 Reported-by: Borislav Petkov <borislav.petkov(a)amd.com> Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> Cc: stable(a)kernel.org --- mm/bootmem.c | 24 ++++++++++++++++++++---- mm/page_alloc.c | 3 +++ 2 files changed, 23 insertions(+), 4 deletions(-) Index: linux-2.6/mm/page_alloc.c =================================================================== --- linux-2.6.orig/mm/page_alloc.c +++ linux-2.6/mm/page_alloc.c @@ -3634,6 +3634,9 @@ void * __init __alloc_memory_core_early( int i; void *ptr; + if (limit > get_max_mapped()) + limit = get_max_mapped(); + /* need to go over early_node_map to find out good range for node */ for_each_active_range_index_in_nid(i, nid) { u64 addr; Index: linux-2.6/mm/bootmem.c =================================================================== --- linux-2.6.orig/mm/bootmem.c +++ linux-2.6/mm/bootmem.c @@ -833,15 +833,24 @@ static void * __init ___alloc_bootmem_no void * __init __alloc_bootmem_node(pg_data_t *pgdat, unsigned long size, unsigned long align, unsigned long goal) { + void *ptr; + if (WARN_ON_ONCE(slab_is_available())) return kzalloc_node(size, GFP_NOWAIT, pgdat->node_id); #ifdef CONFIG_NO_BOOTMEM - return __alloc_memory_core_early(pgdat->node_id, size, align, + ptr = __alloc_memory_core_early(pgdat->node_id, size, align, + goal, -1ULL); + if (ptr) + return ptr; + + ptr = __alloc_memory_core_early(MAX_NUMNODES, size, align, goal, -1ULL); #else - return ___alloc_bootmem_node(pgdat->bdata, size, align, goal, 0); + ptr = ___alloc_bootmem_node(pgdat->bdata, size, align, goal, 0); #endif + + return ptr; } void * __init __alloc_bootmem_node_high(pg_data_t *pgdat, unsigned long size, @@ -977,14 +986,21 @@ void * __init __alloc_bootmem_low(unsign void * __init __alloc_bootmem_low_node(pg_data_t *pgdat, unsigned long size, unsigned long align, unsigned long goal) { + void *ptr; + if (WARN_ON_ONCE(slab_is_available())) return kzalloc_node(size, GFP_NOWAIT, pgdat->node_id); #ifdef CONFIG_NO_BOOTMEM - return __alloc_memory_core_early(pgdat->node_id, size, align, + ptr = __alloc_memory_core_early(pgdat->node_id, size, align, + goal, ARCH_LOW_ADDRESS_LIMIT); + if (ptr) + return ptr; + ptr = __alloc_memory_core_early(MAX_NUMNODES, size, align, goal, ARCH_LOW_ADDRESS_LIMIT); #else - return ___alloc_bootmem_node(pgdat->bdata, size, align, + ptr = ___alloc_bootmem_node(pgdat->bdata, size, align, goal, ARCH_LOW_ADDRESS_LIMIT); #endif + return ptr; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Zeno Davatz on 16 Jul 2010 16:40 Am 16.07.2010 um 20:27 schrieb Yinghai Lu <yinghai(a)kernel.org>: > it seems that you are using 32bit kernel. please check if this one help. Thanks! What RC should I patch? 2.6.35-rc5? Best Zeno > Subject: [PATCH -v3] x86,mm: fix 32bit numa sparsemem > > Borislav Petkov <borislav.petkov(a)amd.com> reported his 32bit numa has problem: > > [ 0.000000] Reserving total of 4c00 pages for numa KVA remap > [ 0.000000] kva_start_pfn ~ 32800 max_low_pfn ~ 375fe > [ 0.000000] max_pfn = 238000 > [ 0.000000] 8202MB HIGHMEM available. > [ 0.000000] 885MB LOWMEM available. > [ 0.000000] mapped low ram: 0 - 375fe000 > [ 0.000000] low ram: 0 - 375fe000 > [ 0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 1000 1000 => 34e7000 > [ 0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 200 40 => 34c9d80 > [ 0.000000] alloc (nid=0 100000 - 7ee00000) (1000000 - ffffffffffffffff) 180 40 => 34e6140 > [ 0.000000] alloc (nid=1 80000000 - c7e60000) (1000000 - ffffffffffffffff) 240 40 => 80000000 > [ 0.000000] BUG: unable to handle kernel paging request at 40000000 > [ 0.000000] IP: [<c2c8cff1>] __alloc_memory_core_early+0x147/0x1d6 > [ 0.000000] *pdpt = 0000000000000000 *pde = f000ff53f000ff00 > ... > [ 0.000000] Call Trace: > [ 0.000000] [<c2c8b4f8>] ? __alloc_bootmem_node+0x216/0x22f > [ 0.000000] [<c2c90c9b>] ? sparse_early_usemaps_alloc_node+0x5a/0x10b > [ 0.000000] [<c2c9149e>] ? sparse_init+0x1dc/0x499 > [ 0.000000] [<c2c79118>] ? paging_init+0x168/0x1df > [ 0.000000] [<c2c780ff>] ? native_pagetable_setup_start+0xef/0x1bb > > looks like it allocate much high address for bootmem. > > try to cut limit with get_max_mapped() > > -v3: make alloc_bootmem_node could fallback to other node. > just like old alloc_bootmem_node did > > need this patch for 2.6.34 and 2.6.35 > > Reported-by: Borislav Petkov <borislav.petkov(a)amd.com> > Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > Cc: stable(a)kernel.org > > --- > mm/bootmem.c | 24 ++++++++++++++++++++---- > mm/page_alloc.c | 3 +++ > 2 files changed, 23 insertions(+), 4 deletions(-) > > Index: linux-2.6/mm/page_alloc.c > =================================================================== > --- linux-2.6.orig/mm/page_alloc.c > +++ linux-2.6/mm/page_alloc.c > @@ -3634,6 +3634,9 @@ void * __init __alloc_memory_core_early( > int i; > void *ptr; > > + if (limit > get_max_mapped()) > + limit = get_max_mapped(); > + > /* need to go over early_node_map to find out good range for node */ > for_each_active_range_index_in_nid(i, nid) { > u64 addr; > Index: linux-2.6/mm/bootmem.c > =================================================================== > --- linux-2.6.orig/mm/bootmem.c > +++ linux-2.6/mm/bootmem.c > @@ -833,15 +833,24 @@ static void * __init ___alloc_bootmem_no > void * __init __alloc_bootmem_node(pg_data_t *pgdat, unsigned long size, > unsigned long align, unsigned long goal) > { > + void *ptr; > + > if (WARN_ON_ONCE(slab_is_available())) > return kzalloc_node(size, GFP_NOWAIT, pgdat->node_id); > > #ifdef CONFIG_NO_BOOTMEM > - return __alloc_memory_core_early(pgdat->node_id, size, align, > + ptr = __alloc_memory_core_early(pgdat->node_id, size, align, > + goal, -1ULL); > + if (ptr) > + return ptr; > + > + ptr = __alloc_memory_core_early(MAX_NUMNODES, size, align, > goal, -1ULL); > #else > - return ___alloc_bootmem_node(pgdat->bdata, size, align, goal, 0); > + ptr = ___alloc_bootmem_node(pgdat->bdata, size, align, goal, 0); > #endif > + > + return ptr; > } > > void * __init __alloc_bootmem_node_high(pg_data_t *pgdat, unsigned long size, > @@ -977,14 +986,21 @@ void * __init __alloc_bootmem_low(unsign > void * __init __alloc_bootmem_low_node(pg_data_t *pgdat, unsigned long size, > unsigned long align, unsigned long goal) > { > + void *ptr; > + > if (WARN_ON_ONCE(slab_is_available())) > return kzalloc_node(size, GFP_NOWAIT, pgdat->node_id); > > #ifdef CONFIG_NO_BOOTMEM > - return __alloc_memory_core_early(pgdat->node_id, size, align, > + ptr = __alloc_memory_core_early(pgdat->node_id, size, align, > + goal, ARCH_LOW_ADDRESS_LIMIT); > + if (ptr) > + return ptr; > + ptr = __alloc_memory_core_early(MAX_NUMNODES, size, align, > goal, ARCH_LOW_ADDRESS_LIMIT); > #else > - return ___alloc_bootmem_node(pgdat->bdata, size, align, > + ptr = ___alloc_bootmem_node(pgdat->bdata, size, align, > goal, ARCH_LOW_ADDRESS_LIMIT); > #endif > + return ptr; > } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 16 Jul 2010 17:10 On 07/16/2010 01:29 PM, Zeno Davatz wrote: > > Am 16.07.2010 um 20:27 schrieb Yinghai Lu <yinghai(a)kernel.org>: > >> it seems that you are using 32bit kernel. please check if this one help. > > Thanks! What RC should I patch? 2.6.35-rc5? current linus tree or 2.6.35-rc5. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Zeno Davatz on 17 Jul 2010 04:50
On Fri, Jul 16, 2010 at 10:59 PM, Yinghai Lu <yinghai(a)kernel.org> wrote: > On 07/16/2010 01:29 PM, Zeno Davatz wrote: >> >> Am 16.07.2010 um 20:27 schrieb Yinghai Lu <yinghai(a)kernel.org>: >> >>> it seems that you are using 32bit kernel. please check if this one help. >> >> Thanks! What RC should I patch? 2.6.35-rc5? > > current linus tree or 2.6.35-rc5. Tried to patch 2.6.35-rc5 but I get: /usr/src/my2.6> sudo patch -p1 < patch_yinghai patching file mm/page_alloc.c Hunk #1 FAILED at 3634. 1 out of 1 hunk FAILED -- saving rejects to file mm/page_alloc.c.rej patching file mm/bootmem.c Hunk #1 FAILED at 833. Hunk #2 FAILED at 986. 2 out of 2 hunks FAILED -- saving rejects to file mm/bootmem.c.rej Any hints? It seems that 2.6.35-rc1 does not have the CPU eater problem. I still running it without any interference (though I was away from the computer for some time). Best Zeno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |