Re: [Crash-utility] crash 4.0-2.8 fails on 2.6.14-rc5 (EM64T)

> > Now I run into next problem :( I am missing something basic. > > > > crash: read error: kernel virtual address: ffff81000000fa90 type: > > "pglist_data node_next" > > > > That's probably coming from node_table_init(). Could the pglist_data > list now be using per-cpu data structures? But again, I don't understand > the significance of the ffff8 at the top of the address. I don't know either. I did some more digging around adding printk() in 2.6.10, 2.6.14-rc5 kernel where data_offset is getting set. Interestingly, allocmem() returns different types of address in 2.6.10 & 2.6.14-rc5 (which is causing this huge numbers). arch/x86_64/kernel/setup.c: setup_per_cpu_areas() for_each_cpu_mask (i, cpu_possible_map) { char *ptr; if (!NODE_DATA(cpu_to_node(i))) { printk("cpu with no node %d, num_online_nodes %d \n", i, num_online_nodes()); ptr = alloc_bootmem(size); } else { ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node (i)), size); } if (!ptr) panic("Cannot allocate cpu data for CPU %d\n", i); cpu_pda[i].data_offset = ptr - __per_cpu_start; printk("i %d ptr %p cpustart %p offset %lx\n", i, ptr, __per_cpu_start, cpu_pda[i].data_offset); memcpy(ptr, __per_cpu_start, __per_cpu_end - __per_cpu_start); } Here is the output: 2.6.14-rc5 i 0 ptr ffff8100050eb000 cpustart ffffffff805f50a0 offset ffff810084af5f60 i 1 ptr ffff8100050f3000 cpustart ffffffff805f50a0 offset ffff810084afdf60 2.6.10 i 0 ptr 0000010005100000 cpustart ffffffff8057f0a0 offset 10084b80f60 i 1 ptr 0000010005108000 cpustart ffffffff8057f0a0 offset 10084b88f60 i 2 ptr 0000010005110000 cpustart ffffffff8057f0a0 offset 10084b90f60 i 3 ptr 0000010005118000 cpustart ffffffff8057f0a0 offset 10084b98f60 i 4 ptr 0000010005120000 cpustart ffffffff8057f0a0 offset 10084ba0f60 i 5 ptr 0000010005128000 cpustart ffffffff8057f0a0 offset 10084ba8f60 i 6 ptr 0000010005130000 cpustart ffffffff8057f0a0 offset 10084bb0f60 i 7 ptr 0000010005138000 cpustart ffffffff8057f0a0 offset 10084bb8f60 Don't know enough about x86-64 stuff. May be I can ask Andi Kleen about this change ?