[Crash-utility] kmem -[sS] segfault on 2.6.25.17
Mike Snitzer
snitzer at gmail.com
Fri Oct 17 13:44:38 UTC 2008
On Fri, Oct 17, 2008 at 9:35 AM, Dave Anderson <anderson at redhat.com> wrote:
>
>> ----- "Mike Snitzer" <snitzer at 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
More information about the Crash-utility
mailing list