[Crash-utility] Problem with "xm save" x86-64 cores -crash.4.0-3.5
Dave Anderson
anderson at redhat.com
Wed Oct 4 18:44:14 UTC 2006
Another thing to check -- there are two places that print that
"cannot determine..." error message. Can you verify that it's
happening in refresh_hlist_task_table()? That's where the
previous reporter said that it happened on his system, but I
just want to make absolutely sure.
Thanks,
Dave
Dave Anderson wrote:
> Tejasvi Aswathanarayana wrote:
>
>> Crash exits with an error "cannot determine pid_hash array
>> dimensions". Looking at the crash change log, it appears that it was
>> fixed in 4.0-2.24 for the 2.6.17 kernel. The core I have is of a
>> 2.6.16.13 xenified kernel. Is the fix even relevant ?
>>
>> <output>
>> $ ./crash vmlinux-2.6.16.13-xen test.core
>>
>> crash 4.0-3.5
>> Copyright (C) 2002, 2003, 2004, 2005, 2006 Red Hat, Inc.
>> Copyright (C) 2004, 2005, 2006 IBM Corporation
>> Copyright (C) 1999-2006 Hewlett-Packard Co
>> Copyright (C) 2005 Fujitsu Limited
>> Copyright (C) 2005 NEC Corporation
>> Copyright (C) 1999, 2002 Silicon Graphics, Inc.
>> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
>> This program is free software, covered by the GNU General Public License,
>> and you are welcome to change it and/or distribute copies of it under
>> certain conditions. Enter "help copying" to see the conditions.
>> This program has absolutely no warranty. Enter "help warranty" for details.
>>
>> GNU gdb 6.1
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "x86_64-unknown-linux-gnu"...
>>
>> please wait... (gathering task table data)
>> crash: cannot determine pid_hash array dimensions
>> </output>
>>
>> Is there a way I can get crash's source at releases 4.0-2.24 and
>> 4.0-2.23 so that I can try a fix for this kernel in case it is a
>> specific kernel fix ?
>>
>> Thanks
>> -Tejasvi
>
> Interesting -- I got a private message yesterday from another
> 2.6.16-era xen user with the same problem.
>
> Anyway, over time the manner of pid table handling has
> changed several times, and so to handle the various manners,
> the crash utility's task_init() function assigns an appropriate
> function to gather all pids/tasks running on the system.
>
> You're referring to this entry in the changelog:
>
> 4.0-2.24 - Fix for 2.6.17 kernels that do not use "pgdat_list" memory node
> list header, which would cause crash to fail during initialization
> with a "crash: cannot resolve: pgdat_list" error message.
> (anderson at redhat.com)
>
> - Fix for 2.6.17 kernels that have re-worked the kernel pid_hash
> handling, which would cause crash to fail during initialization
> with a "crash: cannot determine pid_hash array dimensions" error
> message. (anderson at redhat.com)
> ...
>
>
> The change above implemented yet another pid hash handler
> called refresh_hlist_task_table_v2(), which as the comments
> above indicate, was required for 2.6.17 kernels. In crash
> version 4.0-2.24, a new refresh_hlist_task_table_v2() function
> was added to replace refresh_hlist_task_table(), to account
> for this change:
>
> /*
> * 2.6.17 replaced:
> * static struct hlist_head *pid_hash[PIDTYPE_MAX];
> * with
> * static struct hlist_head *pid_hash;
> */
>
> So, for starters, can you display how "pid_hash" is
> declared in your kernel?
>
> Unfortunately the only 2.6.16-era x86_64 kernel dumpfile that
> I have on-hand as a reference is an early kdump dumpfile,
> (non-xen) which selects the older refresh_hlist_task_table():
>
> crash> sys
> KERNEL: /usr/dumps/kdump/vmlinux (2.6.16-20-smp)
> DUMPFILE: /usr/dumps/kdump/vmcore
> CPUS: 2
> DATE: Mon Apr 24 11:02:03 2006
> UPTIME: 00:31:04
> LOAD AVERAGE: 0.00, 0.00, 0.00
> TASKS: 63
> NODENAME: elm3a242
> RELEASE: 2.6.16-20-smp
> VERSION: #1 SMP Mon Apr 10 04:51:13 UTC 2006
> MACHINE: x86_64 (3000 Mhz)
> MEMORY: 4.6 GB
> PANIC: "SysRq : Trigger a crashdump"
> crash> help -t
> current: 1678f60 [62]
> .pid: 3235
> .comm: "bash"
> .task: ffff810121a7d810
> .thread_info: ffff81011d826000
> .processor: 1
> .ptask: ffff810121d91790
> .mm_struct: ffff810122f9eb00
> .tc_next: 0
> context_array: 1677df0
> refresh_task_table: refresh_hlist_task_table()
> ...
>
> This is the code sequence in task_init() that selects
> refresh_hlist_task_table() or refresh_hlist_task_table_v2():
>
> } else {
> tt->pidhash_addr = symbol_value("pid_hash");
> if (!get_array_length("pid_hash", NULL, sizeof(void *)) &&
> VALID_STRUCT(pid_link))
> tt->refresh_task_table = refresh_hlist_task_table_v2;
> else
> tt->refresh_task_table = refresh_hlist_task_table;
> }
>
> Since you are breaking down on initialization, can you put
> some debug code in place that displays?:
>
> 1. the output of the get_array_length("pid_hash",...) call, and
> 2. the output of VALID_STRUCT(pid_link)
>
> Something must be slightly different between the mainline
> and xen 2.6.16-era kernels.
>
> What appears to be happening is that refresh_hlist_task_table()
> is being selected, but in that function, this subsequent call
> is failing:
>
> if (!(plen = get_array_length("pid_hash", NULL, sizeof(void *))))
> error(FATAL, "cannot determine pid_hash array dimensions\n");
>
> Alternatively, if you want to make the vmlinux/dumpfile pair
> available to me, I can take a look at it.
>
> Thanks,
> Dave
>
>
>
>
>
>
> -----------------------------------------------------------------------------------------------------------
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061004/1f4598c8/attachment.htm>
More information about the Crash-utility
mailing list