[PATCH] arm32: fix "unknown HZ value" error
by HuKeping
This patch fix the error info
"UPTIME: (cannot calculate: unknown HZ value)"
on arm(32 bit), if the CONFIG_IKCONFIG was not selected.
Signed-off-by: Hu Keping <hukeping(a)huawei.com>
---
arm.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arm.c b/arm.c
index 7405583..cfdc5f1 100644
--- a/arm.c
+++ b/arm.c
@@ -315,6 +315,9 @@ arm_init(int when)
"pr_pid");
MEMBER_OFFSET_INIT(elf_prstatus_pr_reg, "elf_prstatus",
"pr_reg");
+
+ if(!machdep->hz)
+ machdep->hz = 100;
break;
case POST_VM:
--
1.8.5.5
10 years
building an RPM w/ LZO support
by Mark Vitale
I've been using crash 6.x for some time on Centos6, a binary RPM installed from a yum repo.
Yesterday I realized I didn't have the crash extensions installed. And a yum
search found no listing for crash-extensions in my current repos.
So I downloaded a 7.0.8 source RPM from crash-utility.com, built and installed it:
$ rpmbuild -vv --rebuild crash-7.0.8-0.src.rpm
$ cd ~/rpmbuild/RPMS/x86
$ sudo yum localinstall --nogpgcheck crash-7.0.8-0.rpm
But when I tested it on a previously working set of vmlinux/vmcore files,
I got the following error:
crash: compressed kdump: uncompress failed: no lzo compression support
I eventually ended up extracting the source rpm and doing:
$ cd ~/dev/src/crash-7.0.8
$ make lzo
and this copy of crash works.
However, I really wanted to make a new RPM out of this, but everything I tried
always ended up reverting to no LZO. Looking at the configure.c source, I see
that 'make release' has a different method for building the Makefile which does
not seem to allow for LZO. Is it possible to build an lzo-enabled rpm using
crash configure and make? Or with rpmbuild? If so, how?
Thanks,
--
Mark Vitale
mvitale(a)sinenomine.net
10 years
About the comments
by Hu Keping
hi there,
I'm a freshman to CRASH, I want to make some contribute for it as I
found it very usefull, especially with Kdump.
But i run to a little trouble when i read the source code of it for
there is not enough comments for some critical data structures say,
struct syment, struct bt_info, etc.
I would really appreciate it if there would be some progress on that.
Thanks.
--
Hu Keping
10 years
[RFC] autokdump - automated kdump testsuite
by CAI Qian
I plan to release an automated kdump testsuite that will be
focus on testing kernel and the crash utility. It should work
for all major distros since it will use none of distro-specific
stuff, and also support different arches including x86, ARM,
PPC64 and s390x.
It does the following:
1) check if there is a memory reserved for kdump. If not,
reserve the memory and reboot the system.
2) once the system is back, load kexec on panic and
prepare a separate initramfs that including needed
modules to load a local filesystem and necessary utilities
in order to analyse /proc/vmcore in the 2nd kernel.
3) trigger the system crash using methods like sysrq-c, NMI,
and panic_on_hung_task etc.
4) in the 2nd kernel, mount a filesystem and use the crash
utility to analyse /proc/vmcore. Then, gather the analyse
logs, serial console output, dmesg etc into the filesystem.
5) reboot back into the 1st kernel.
implementation:
It will setup a daemon to handle reboots.
plan:
I might also to test the makedumpfile all together later.
CAI Qian
10 years
Re: [Crash-utility] improve ps performance
by Dave Anderson
----- Original Message -----
> On 09/06/2014 04:11 AM, Dave Anderson wrote:
> > Hello Pan,
> >
> > The patch looks to run OK. Here are my comments and suggestions:
> >
> > # make warn
> > cc -c -g -DX86_64 -DLZO -DSNAPPY -DGDB_7_6 memory.c -Wall -O2
> > -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
> > -Wformat-security
> > memory.c: In function 'get_task_mem_usage':
> > memory.c:4157:10: warning: variable 'tgid' set but not used
> > [-Wunused-but-set-variable]
> > ...
> >
> > And speaking of tgid, I don't see why it's necessary to keep two
> > copies of the tgid:?
> >
> > @@ -758,13 +758,23 @@ struct task_context { /* context
> > stored for each task */
> > int processor;
> > ulong ptask;
> > ulong mm_struct;
> > + ulong tgid;
> > + ulong tgid_task_context_index;
> > struct task_context *tc_next;
> > };
> >
> > +struct tgid_task_context{ /* context and tgid stored for
> > each task */
> > + ulong tgid;
> > + struct task_context *tc;
> > +};
> > +
> >
> > These 3 functions are always called together, in task_init(),
> > and in exec_command() if (ct->flags& REFRESH_TASK_TABLE):
> >
> > tt->refresh_task_table() -> calls store_context()
> > sort_context_array()
> > set_tgid_context_array()
> >
> > It would seem that store_context(), which reads the tgid value,
> > could call a new function, say, something like:
> >
> > store_tgid_context(struct task_context *tc, ulong tgid);
> >
> > The store_tgid_context() function could determine the index
> > into the tt->context_array from the address "tc", and therefore
> > could populate both fields of each tgid_task_context array entry.
> >
> > Then, the set_tgid_context_array() function could be renamed
> > to sort_tgid_context_array() and it could just do the sorting
> > operation on the array that has already been initialized.
> >
> > Unfortunately I can't see a obvious way to remove the new
> > tc->tgid_context_index field...
> >
> > Another question: why is it necessary to call sort_tgid_context_array()
> > both here:
> >
> > @ -2916,7 +2981,10 @@ cmd_ps(void)
> > cmd_usage(pc->curcmd, SYNOPSIS);
> >
> > if (flag& (PS_LAST_RUN|PS_MSECS))
> > + {
> > sort_context_array_by_last_run();
> > + set_tgid_context_array();
> > + }
> >
> > and here:
> >
> > @@ -5966,7 +6034,10 @@ foreach(struct foreach_data *fd)
> > }
> > }
> > if (fd->flags& (FOREACH_l_FLAG|FOREACH_m_FLAG))
> > + {
> > sort_context_array_by_last_run();
> > + set_tgid_context_array();
> > +
> >
> > The "ps -l" and "ps -m" options don't need anything in the
> > tgid_context_array, and everything will get re-sorted when
> > the next "ps" command is attempted.
> >
> > Lastly, the tgid_task_context array should be dumped at the
> > end of the "help -T" display after the task_context array.
> >
> > Dave
> >
> >
> > .
> >
> I see. But I can't understand the meaning of "The store_tgid_context()
> function could determine the index into the tt->context_array from
> the address "tc", and therefore could populate both fields of each
> tgid_task_context array entry.", because the sort_context_array() function
> would change the tt->context_array, so it is different with the tc of
> tgid_context_array.
Ah yes, you're right.
> Can I do it like this:
> "
> +struct task_table { /* kernel/local task table data */
> + struct task_context *current;
> + struct task_context *context_array, *tgid_context_array;
> + void (*refresh_task_table)(void);
> " the context_array sort by pid, or the tgid_context_array sort by tgid.
That would be a waste of space because of the unused fields in the
task_context structure used by the new tt->tgid_context_array.
>
> Or like this:
> "
>
> +struct tgid_task_context{ /* context and tgid stored for each
> task */
> + ulong tgid;
> + ulong task;
> +};
>
> +struct task_table { /* kernel/local task table data */
> + struct task_context *current;
> + struct task_context *context_array;
> + struct tgid_task_context *ttc_array;
>
> the ttc_array sort by tgid
That would be much better! And if you did it that way, *then* my suggestion
of populating the unsorted ttc_array during store_context() would make sense,
i.e., when the tgid is readily available in the "tp" task_struct buffer.
Thanks,
Dave
10 years
[PATCH V2] crash: arm32: a better way to identify LPAE enabled kernel
by Liu Hua
Thanks to Dave's suggest, I impove the way to identify
LPAE enabled kernel for arm platform, for compatibility with
some old kernel.
If a vmcore santisfy one of the following conditions, It must
be generated by a LPAE enabled kernel.
(1) it has CONFIG_ARM_LPAE=y vmcore_info
(2) swapper_pg_dir and its next symbol value differ by 0x5000
changes from V1:
- drop function next_symbol_value
Signed-off-by: Liu Hua <sdu.liu(a)huawei.com>
---
arm.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arm.c b/arm.c
index cb7d841..e7d3dbc 100644
--- a/arm.c
+++ b/arm.c
@@ -190,6 +190,8 @@ void
arm_init(int when)
{
ulong vaddr;
+ char *string;
+ struct syment *sp;
#if defined(__i386__) || defined(__x86_64__)
if (ACTIVE())
@@ -229,8 +231,13 @@ arm_init(int when)
* LPAE requires an additional page for the PGD,
* so PG_DIR_SIZE = 0x5000 for LPAE
*/
- if ((symbol_value("_text") - symbol_value("swapper_pg_dir")) == 0x5000)
+ if ((string = pc->read_vmcoreinfo("CONFIG_ARM_LPAE"))) {
machdep->flags |= PAE;
+ free(string);
+ } else if ((sp = next_symbol("swapper_pg_dir", NULL)) &&
+ (sp->value - symbol_value("swapper_pg_dir")) == 0x5000)
+ machdep->flags |= PAE;
+
machdep->kvbase = symbol_value("_stext") & ~KVBASE_MASK;
machdep->identity_map_base = machdep->kvbase;
machdep->is_kvaddr = arm_is_kvaddr;
--
1.9.0
10 years
[patch] incorrect pid_ns check
by Vasily Averin
Dear Dave,
I've found that crash does not find all tasks on OpenVZ kernels.
Currently pid_ns check in refresh_hlist_task_table_v3() checks only first entry
in pid_hash[i] hlist. If this entry is not related to init_pid_ns
it forget about other entries in hlist and switches to next element
in pid_hash array.
Attached patch fix this problem.
Thank you,
Vasily Averin
10 years
[PATCH] crash: arm32: a better way to identify LPAE enabled kernel
by Liu Hua
Thanks to Dave's suggest, I impove the way to identify
LPAE enabled kernel for arm platform, for compatibility with
some old kernel.
If a vmcore santisfy one of the following conditions, It must
be generated by a LPAE enabled kernel.
(1) it has CONFIG_ARM_LPAE=y vmcore_info
(2) swapper_pg_dir and its next symbol value differ by 0x5000
Signed-off-by: Liu Hua <sdu.liu(a)huawei.com>
---
arm.c | 11 ++++++++++-
symbols.c | 10 ++++++++++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arm.c b/arm.c
index cb7d841..76ba699 100644
--- a/arm.c
+++ b/arm.c
@@ -190,6 +190,8 @@ void
arm_init(int when)
{
ulong vaddr;
+ char *string;
+ ulong difference;
#if defined(__i386__) || defined(__x86_64__)
if (ACTIVE())
@@ -229,8 +231,15 @@ arm_init(int when)
* LPAE requires an additional page for the PGD,
* so PG_DIR_SIZE = 0x5000 for LPAE
*/
- if ((symbol_value("_text") - symbol_value("swapper_pg_dir")) == 0x5000)
+ if ((string = pc->read_vmcoreinfo("CONFIG_ARM_LPAE"))) {
machdep->flags |= PAE;
+ free(string);
+ } else {
+ difference = next_symbol_value("swapper_pg_dir", NULL)
+ - symbol_value("swapper_pg_dir");
+ if (difference == 0x5000)
+ machdep->flags |= PAE;
+ }
machdep->kvbase = symbol_value("_stext") & ~KVBASE_MASK;
machdep->identity_map_base = machdep->kvbase;
machdep->is_kvaddr = arm_is_kvaddr;
diff --git a/symbols.c b/symbols.c
index a0f256e..b294cd2 100644
--- a/symbols.c
+++ b/symbols.c
@@ -4936,6 +4936,16 @@ try_get_symbol_data(char *symbol, long size, void *local)
return FALSE;
}
+ulong
+next_symbol_value(char *symbol, struct syment *psb)
+{
+ struct syment *sp;
+
+ if (!(sp = next_symbol(symbol, psb)))
+ error(FATAL, "cannot resolve \"%s\"\n", symbol);
+ return(sp->value);
+}
+
/*
* Return the value of a given symbol.
*/
--
1.9.0
10 years
x86_64: supporting cpu hot remove
by qiaonuohan
Hello Dave,
This patchset is used to fix some bug and modify display of some commands.
When some cpus are removed, the related data is not reasonable to be displayed,
so hide them.
Please check the patches to see detailed information.
--
Regards
Qiao Nuohan
10 years
[PATCH] crash: arm32: a better way to identify LPAE enabled kernel
by Liu Hua
Thanks to Dave's suggest, I impove the way to identify
LPAE enabled kernel for arm platform, for compatibility with
some old kernel.
If a vmcore santisfy one of the following conditions, It must
be generated by a LPAE enabled kernel.
(1) it has CONFIG_ARM_LPAE=y vmcore_info
(2) swapper_pg_dir and its next symbol value differ by 0x5000
Signed-off-by: Liu Hua <sdu.liu(a)huawei.com>
---
arm.c | 11 ++++++++++-
symbols.c | 10 ++++++++++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arm.c b/arm.c
index cb7d841..76ba699 100644
--- a/arm.c
+++ b/arm.c
@@ -190,6 +190,8 @@ void
arm_init(int when)
{
ulong vaddr;
+ char *string;
+ ulong difference;
#if defined(__i386__) || defined(__x86_64__)
if (ACTIVE())
@@ -229,8 +231,15 @@ arm_init(int when)
* LPAE requires an additional page for the PGD,
* so PG_DIR_SIZE = 0x5000 for LPAE
*/
- if ((symbol_value("_text") - symbol_value("swapper_pg_dir")) == 0x5000)
+ if ((string = pc->read_vmcoreinfo("CONFIG_ARM_LPAE"))) {
machdep->flags |= PAE;
+ free(string);
+ } else {
+ difference = next_symbol_value("swapper_pg_dir", NULL)
+ - symbol_value("swapper_pg_dir");
+ if (difference == 0x5000)
+ machdep->flags |= PAE;
+ }
machdep->kvbase = symbol_value("_stext") & ~KVBASE_MASK;
machdep->identity_map_base = machdep->kvbase;
machdep->is_kvaddr = arm_is_kvaddr;
diff --git a/symbols.c b/symbols.c
index a0f256e..b294cd2 100644
--- a/symbols.c
+++ b/symbols.c
@@ -4936,6 +4936,16 @@ try_get_symbol_data(char *symbol, long size, void *local)
return FALSE;
}
+ulong
+next_symbol_value(char *symbol, struct syment *psb)
+{
+ struct syment *sp;
+
+ if (!(sp = next_symbol(symbol, psb)))
+ error(FATAL, "cannot resolve \"%s\"\n", symbol);
+ return(sp->value);
+}
+
/*
* Return the value of a given symbol.
*/
--
1.9.0
10 years
