Re: sparsemem panic in 2.6.17-rc5-mm1 and -mm2

Chuck Ebbert
2006-06-06T03:54:55Z

In-Reply-To: <4484D174.7080902@google.com>

On Mon, 05 Jun 2006 17:51:00 -0700, Martin Bligh wrote:

> http://test.kernel.org/abat/34264/debug/console.log
>
> Only seems to happen on the sparsemem runs. Possibly a side-effect
> of the page migration stuff, manifesting itself differently?
> Or maybe not?
>
> Out of Memory: Kill process 1 (idle) score 0 and children.
> divide error: 0000 [#1]
> SMP
> last sysfs file:
> CPU: 0
> EIP: 0060:[<c013be6a>] Not tainted VLI
> EFLAGS: 00010246 (2.6.17-rc5-mm2-autokern1 #1)
> EIP is at shrink_active_list+0x5b/0x382
> eax: 00000000 ebx: 00000064 ecx: 00000000 edx: 00000000
> esi: c0474500 edi: c03a8e64 ebp: c03a8dbc esp: c03a8d9c
> ds: 007b es: 007b ss: 0068
> Process idle (pid: 1, threadinfo=c03a8000 task=c0769000)
> Stack: 00000000 00000000 00000020 00000004 c03a8dac c03a8dac c03a8db4 c03a8db4
> c03a8dbc c03a8dbc c03a8dfc c0137a14 00000000 c0137a37 c03a8df8 c03a8df4
> c0474000 00000000 00000000 c03a8e64 c0137c5a 00000000 00028028 000dc0e0
> Call Trace:
> <c0137a14> get_writeback_state+0x30/0x35 <c0137a37> get_dirty_limits+0x1e/0xc4
> <c0137c5a> throttle_vm_writeout+0x18/0x53 <c013c221> shrink_zone+0x90/0xc1
> <c013c29f> shrink_zones+0x4d/0x5e <c013c39d> try_to_free_pages+0xed/0x1a8
> <c0136a91> __alloc_pages+0x16e/0x26a <c014e6c9> kmem_getpages+0x5b/0xac
> <c014f42c> cache_grow+0xb5/0x147 <c014f655> cache_alloc_refill+0x197/0x1d3
> <c014fad0> kmem_cache_alloc+0x4f/0x5e <c0276dd8> sk_alloc+0x15/0x63
> <c02bb9e0> inet_create+0xfb/0x21a <c027546d> __sock_create+0xc0/0xea
> <c02754b0> sock_create_kern+0xb/0xe <c03c413b> icmp_init+0x3a/0xc3
> <c03c445c> inet_init+0x12b/0x174 <c03aa7f6> do_initcalls+0x53/0xe4
> <c01320d8> register_irq_proc+0x6a/0x90 <c0180000> xlate_proc_name+0x87/0x90
> <c0100349> init+0x41/0xdc <c0100308> init+0x0/0xdc
> <c01009d5> kernel_thread_helper+0x5/0xb
> Code: 04 24 00 00 00 00 8d 44 24 10 89 44 24 10 89 44 24 14 83 79 10 00
> 74 38 8b 8a bc 01 00 00 6b 47 04 64 bb 64 00 00 00 31 d2 d3 fb <f7> 35
> 0c 6f 45 c0 ba 02 00 00 00 89 d1 99 f7 f9 01 d8 03 47 18
> EIP: [<c013be6a>] shrink_active_list+0x5b/0x382 SS:ESP 0068:c03a8d9c

static void shrink_active_list(unsigned long nr_pages, struct zone *zone,
struct scan_control *sc)
{
unsigned long pgmoved;
int pgdeactivate = 0;
unsigned long pgscanned;
LIST_HEAD(l_hold); /* The pages which were snipped off */
LIST_HEAD(l_inactive); /* Pages to go onto the inactive_list */
LIST_HEAD(l_active); /* Pages to go onto the active_list */
struct page *page;
struct pagevec pvec;
int reclaim_mapped = 0;

if (sc->may_swap) {
long mapped_ratio;
long distress;
long swap_tendency;

/*
* `distress' is a measure of how much trouble we're having
* reclaiming pages. 0 -> no problems. 100 -> great trouble.
*/
distress = 100 >> zone->prev_priority;

/*
* The point of this algorithm is to decide when to start
* reclaiming mapped memory instead of just pagecache. Work out
* how much memory
* is mapped.
*/
====> mapped_ratio = (sc->nr_mapped * 100) / total_memory;

total_memory == 0 here

--
Chuck