On Fri, Oct 17, 2008 at 9:35 AM, Dave Anderson <anderson(a)redhat.com> wrote:
> ----- "Mike Snitzer" <snitzer(a)gmail.com> wrote:
> > BTW, if need be, would you be able to make the vmlinux/vmcore pair
> > available for download somewhere? (You can contact me off-list
> with the particulars...)
>
> I can work to make that happen if needed...
OK, I've got your vmlinux/vmcore pair, and right away I can see
what the problem is. The BZERO/memset runs into the weeds here:
BZERO(si->cpudata[i], sizeof(ulong) * vt->kmem_max_limit);
Running "help -v" dumps the crash-internal VM-related table, and the
initialization-time determination of vt->kmem_max_limit is absurd
(-32512, or ffffffffffff8100):
crash> help -v
flags: 5c52
(NODES_ONLINE|ZONES|PERCPU_KMALLOC_V2|KMEM_CACHE_INIT|SPARSEMEM|SPARSEMEM_EX|PERCPU_KMALLOC_V2_NODES)
kernel_pgd[NR_CPUS]: ffffffff80201000 ...
high_memory: ffff81007fb50000
vmalloc_start: ffffc20000000000
mem_map: 0
total_pages: 523088
max_mapnr: 0
totalram_pages: 479819
totalhigh_pages: 0
num_physpages: 523088
page_hash_table: 0
page_hash_table_len: 0
kmem_max_c_num: 92
kmem_max_limit: -32512
kmem_max_cpus: 4
kmem_cache_count: 184
...
Wow, interesting. I didn't think to check that value in the vmcore
crash session; I just thought the value from a live crash session (as
I reported yesterday) was representative of both.
When you run this same kernel on the live system, what do you see
when you enter "help -v"?
I see:
kmem_max_limit: 128
Mike