[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