Re: [Crash-utility] Test patch to fix kmem -s bug
by Dave Anderson
Hi Sharyathi,
With the "limit/readmem()" fix to max_cpudata_limit(), an additional
check in gather_cpudata_list_v2_nodes() to make sure that the
multiple-index list doesn't get overflowed, and a few cosmetic mods,
this patch looks good to go. (No further patch is required.)
Nice work -- this part of the crash code has always been a huge
PITA to keep functional...
We're overdue for a release -- but it would be nice if you can
come up with a reason for your arithmetic bug in "kmem -i".
Like I said, it works OK for me on x86 and x86_64. Let me know
what you find.
And again, multiple thanks for undertaking this "kmem -s" effort.
Dave
18 years, 7 months
Re: [Crash-utility] Test patch to fix kmem -s bug
by Dave Anderson
Hi Sharyathi,
I'm getting a lot of these on a live x86_64 system:
if (avail > vt->kmem_max_limit) {
error(INFO,
"\"%s\" cache: shared array_cache.avail %d greater than limit %ld\n",
si->curname, avail, vt->kmem_max_limit);
si->errors++;
FREEBUF(start_address);
return;
}
I believe that the kmem_max_limit should be be multiplied by the number
of nodes in this function, but since I have only one node, it appears that the
the "max" calculation is significantly different at init-time vs. when the kmem
command is run later? At a minimum, I would argue for noting somewhere
that vt->kmem_max_limit should be bumped up the next time the kmem
command is run. Or perhaps it should be recalculated prior to each kmem
command run?
Did you ever see this occurrance on a live ppc64 machine?
Dave
18 years, 7 months
Re: [Crash-utility] Test patch to fix kmem -s bug
by Sharyathi Nagesh
This is the patch after making following changes
o Created a new function gather_cpudata_list_v2_nodes().
o gather_cpudata_list_v2_nodes() will be called for each node and it will update avail with corresponding value of shared memory..
o gather_cpudata_list_v2_nodes() is called inside do_slab_chain_percpu_v2_nodes during SLAB_WALKTHROUGH instead outside as earlier..
o Have removed the commented out section of SLAB_WALKTHROUGH (specified slab).
o updated with FREEBUF at possible exit points.
o updated dump_vm_table() to dump vt->kmem_cache_len_nodes
Opens
o The si->found field was not getting set for the dump I analysed. so if(si->found) part of the code was not getting executed.
Needs to be checked for this case.
Please go through the patch and let me know of your opinions.
Thanks
Sharyathi Nagesh
18 years, 7 months
cannot determine idle task and cannot resolve init_task_union on x86
by Steve Dickson
Hello,
I'm getting the following errors using crash 4.0-2.22 on a
2.6.16-1.2087_FC5.smp kernel.
crash: cannot determine idle task addresses from init_tasks[] or runqueues[]
crash: cannot resolve "init_task_union"
Now I just read the threads about this same error on
ppc64 as well as read the crash version 4.0-2.21 is available
release notes, but this is happening on x86 UP kernel
(although I'm using an SMP kernel) and with the latest
crash version 4.0-2.22
any ideas?
steved.
Disclaimer: I don't follow this mailing list as close as I probably
should so I'll pre-apologize is this has already been discussed
in a previous thread... If so please simply send the pointer...
18 years, 7 months
crash TODO list
by Dave Anderson
Nguyen Anh Quynh wrote:
>
> 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?
>
On the http://people.redhat.com/anderson page I've added a
new link to a "crash TODO list". For each item in the list
there is a "DESCRIPTION" and a "RESOLUTION STATUS". If somebody
(including me) has started work on the issue, it will be marked
as such; if nobody has undertaken the issue, it will be marked
as "TBD".
I've seeded the list with 4 issues.
And Q, thanks for the suggestion, it was a good idea.
Dave
18 years, 8 months
