hi Dave, is there any good reason not to include Xen header files into crash code? (for ex, i see that you have copied few Xen structures from xenctrl.h) other thing: would it be better if you put the Changelog file into the source tree? btw, we would love to see the "TODO" list, if you have any. those who are interested will know what is in the priority list, and might help out. what do you think? thanks. Q On 3/24/06, Dave Anderson <anderson(a)redhat.com&gt; wrote: -- regards, Quynh

On Mon, Mar 27, 2006 at 09:27:16AM -0500, Dave Anderson wrote: <snip> Yes, keeping crash up-to-date should be at the top of to-do list. But is it OK to change "crash" for kernel code which is still in -mm, -rc, -rt etc? Like current crash cannot open 2.6.16-mm1 kdump due to pgdat_list related changes. Also, I think developers would like to see crash working even with their developmental kernel. So just wondering if there is any way to address this issue. Thanks Maneesh

Dave I wanted to bring to notice two more issue that I am currently working. One regarding changes done with kmem_cache to make it NUMA compliant. 'lists' which was earlier pointing to kmem_list3 structure, lists has been renamed first as nodelists than it is made into an array of pointer to kmem_list3 structures. So now we have to traverse the whole list iteratively to get the same information. As a result of these change kmem -s command fails. To accomodate these changes we need to change the function do_slab_chain_percpu_v2 to access nodelists iteratively. Still working on it to figure out how I can accommodate these changes. Second objectsize in kmem_cache has been changed to object_size and this is enabled only on selecting config option CONFIG_DEBUG_SLAB in the kernel. Thanks Sharyathi Nagesh On Mon, 2006-03-27 at 13:45 -0500, Dave Anderson wrote:

Dave You were right it should be buffer_size instead of objectsize.(As obj_size is the size of debugging information). I modified function vm_init() and do_slab_chain_percpu_v2() to make it work with current dumps. This is just a code part to show how to fix the problem but it is not a patch as such... Please go through and let me know would it be good idea to write a new function (as you have suggested earlier) or is it possible to accommodate by calling do_slab_chain_percpu_v2() iteratively with different nodes by passing them as parameter. Changes to vm_init() if(MEMBER_EXISTS("kmem_cache","objsize")) MEMBER_OFFSET_INIT(kmem_cache_s_objsize, "kmem_cache", "objsize"); else if(MEMBER_EXISTS("kmem_cache","buffer_size")) MEMBER_OFFSET_INIT(kmem_cache_s_objsize, "kmem_cache", "buffer_size") Changes to do_slab_chain_percpu_v2() ulong start_address[MAX_NUMNODES]; if (!readmem(si->cache+OFFSET(kmem_cache_s_lists), KVADDR, &start_address[0], sizeof(ulong) * MAX_NUMNODES, "array nodelist array", RETURN_ON_ERROR)) {printf("\n Error encountered with readmem \n");exit(0);} for (i = 0; i < MAX_NUMNODES ; i++) { slab_chains[0] = start_address[i] + OFFSET(kmem_list3_slabs_partial); slab_chains[1] = start_address[i] + OFFSET(kmem_list3_slabs_full); slab_chains[2] = start_address[i] + OFFSET(kmem_list3_slabs_free); Thanks Sharyathi Nagesh

Nguyen Anh Quynh wrote: Actually, the version I'm working with now doesn't need the vcpu_guest_context structure, since it's built into the kernel. By moving kernel_init(PRE_GDB) and verify_version() to the point just after gdb_session_init() is called, I get it for free. Dave