[PATCH] increase the number of concurrent sial commands
by Cliff Wickman
From: Cliff Wickman <cpw(a)sgi.com>
The number of concurrently loaded sial commands is limited to 100.
Any beyond that number are silently ignored.
That limit may seem quite large, but we've run up against it.
I would like to increase it to 200.
Diffed against crash-4.0-4.7
Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
---
extensions/sial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: crash-4.0-4.7/extensions/sial.c
===================================================================
--- crash-4.0-4.7.orig/extensions/sial.c
+++ crash-4.0-4.7/extensions/sial.c
@@ -789,7 +789,7 @@ char *sclass_help[]={
NULL
};
-#define NCMDS 100
+#define NCMDS 200
static struct command_table_entry command_table[NCMDS] = {
{"edit", edit_cmd, edit_help},
15 years, 12 months
[PATCH] CONFIG_SPARSEMEM for s390(x)
by Michael Holzheu
Hi Dave,
When starting crash on s390(x) with CONFIG_SPARSEMEM enabled we get the
following error message:
crash: CONFIG_SPARSEMEM kernels not supported for this architecture
The following patch fixes this problem, but I am not sure, if I set
_MAX_PHYSMEM_BITS to the correct value (I used 31 for s390 and 64 for
s390x). Could you please explain the meaning of _MAX_PHSYSMEM_BITS?
---
diff -Naurp crash-4.0-6.3/defs.h crash-4.0-6.3-config-sparse/defs.h
--- crash-4.0-6.3/defs.h 2008-04-29 19:39:17.000000000 +0200
+++ crash-4.0-6.3-config-sparse/defs.h 2008-08-12 17:03:54.000000000 +0200
@@ -2634,6 +2634,8 @@ struct efi_memory_desc_t {
#define TIF_SIGPENDING (2)
+#define _MAX_PHYSMEM_BITS 31
+
#endif /* S390 */
#ifdef S390X
@@ -2656,6 +2658,8 @@ struct efi_memory_desc_t {
#define TIF_SIGPENDING (2)
+#define _MAX_PHYSMEM_BITS 64
+
#endif /* S390X */
#ifdef PLATFORM
diff -Naurp crash-4.0-6.3/s390.c crash-4.0-6.3-config-sparse/s390.c
--- crash-4.0-6.3/s390.c 2008-04-29 19:39:17.000000000 +0200
+++ crash-4.0-6.3-config-sparse/s390.c 2008-08-12 17:04:03.000000000 +0200
@@ -130,6 +130,7 @@ s390_init(int when)
machdep->dump_irq = s390_dump_irq;
if (!machdep->hz)
machdep->hz = HZ;
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
break;
case POST_INIT:
diff -Naurp crash-4.0-6.3/s390x.c crash-4.0-6.3-config-sparse/s390x.c
--- crash-4.0-6.3/s390x.c 2008-04-29 19:39:16.000000000 +0200
+++ crash-4.0-6.3-config-sparse/s390x.c 2008-08-12 17:04:01.000000000 +0200
@@ -128,6 +128,7 @@ s390x_init(int when)
machdep->dump_irq = s390x_dump_irq;
if (!machdep->hz)
machdep->hz = HZ;
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
break;
case POST_INIT:
16 years
Re: [PATCH 1/2] Add x86_64 linux-2.6.27 support: Catch up the PAGE_OFFSET change.
by Dave Anderson
Hello Ken'ichi,
First let me say that I very much appreciate your looking into
this issue.
However, there is a problem with your patch such that it won't work
with the sample Fedora kernel that I was planning to use as a test case.
That kernel is this Fedora version:
Linux version 2.6.27-0.244.rc2.git1.fc10.x86_64
When I run with your patches, I still get the same initialization
time failure:
crash: cannot resolve: "end_pfn"
With the Fedora kernel, your changes to x86_64_init() are not executed because
the VM_2_6_11 flag does not get set here, but rather VM_XEN get set:
case PRE_GDB:
if (!(machdep->flags & VM_FLAGS)) {
if (symbol_exists("xen_start_info")) {
if (symbol_exists("low_pml4") &&
symbol_exists("swap_low_mappings"))
machdep->flags |= VM_XEN_RHEL4;
else
==============> machdep->flags |= VM_XEN;
} else if (symbol_exists("boot_vmalloc_pgt"))
machdep->flags |= VM_ORIG;
else
machdep->flags |= VM_2_6_11;
}
And that's because the Fedora kernel contains a "xen_start_info" symbol,
and so it presumes it's a xen kernel. Even if I force it to use
VM_2_6_11 with "--machdep vm=2.6.11" on the command line, it still
fails the same way in kernel_init() because, again, it thinks it's a xen
kernel:
if (symbol_exists("xen_start_info")) {
kt->flags |= ARCH_XEN;
if (!(kt->xen_flags & (SHADOW_PAGE_TABLES|CANONICAL_PAGE_TABLES)))
kt->xen_flags |= WRITABLE_PAGE_TABLES;
if (symbol_exists("phys_to_machine_mapping"))
get_symbol_data("phys_to_machine_mapping", sizeof(ulong),
&kt->phys_to_machine_mapping);
else if (!(kt->xen_flags & CANONICAL_PAGE_TABLES)) {
kt->xen_flags &= ~WRITABLE_PAGE_TABLES;
kt->xen_flags |= SHADOW_PAGE_TABLES;
}
if (machine_type("X86"))
get_symbol_data("max_pfn", sizeof(ulong), &kt->p2m_table_size);
if (machine_type("X86_64"))
===========> get_symbol_data("end_pfn", sizeof(ulong), &kt->p2m_table_size);
if ((kt->m2p_page = (char *)malloc(PAGESIZE())) == NULL)
error(FATAL, "cannot malloc m2p page.");
}
I made a preliminary inquiry as to why a bare-metal kernel would have
a bunch of (unused) xen* symbols built into it, and as I understand it,
the pv_ops implementation allows for the same kernel (vmlinux) to be
used for bare-metal, or for xen/pv_ops, and for that matter kvm/pv_ops
and VMI/pv_ops (?).
Now, clearly the linux-2.6.27-rc5 vmlinux that you used for testing your
patch does *not* have the "xen_start_info" symbol contained in it, because
if it did, you would have run into the same problem as me. I'm guessing
that all of the xen symbols I seen in my kernel are due to a CONFIG-option
used by the Fedora kernel build? And perhaps the same thing is done for KVM?
(VMI?) By any chance, do you know exactly how the pv_ops implementations fit
together?
In any case, the benefit of the pv_ops implementation is supposed to be
the fact that the same vmlinux kernel can be used for bare-metal or virtualized
kernels, but it potentially makes things more difficult for the crash
utility. But given that the bare-metal/virualized kernels are identical, then
presumably the kernel's PAGE_OFFSET would be identical, and that's what your patch
is addressing. However, crash will also need a way to determine whether
it's a xen kernel or not. For example, look at the crash sources for all
users of the XEN() macro.
So I'm thinking that there may have to be something like a new
virtualization_init() function called very early on that can determine
whether this kernel is a newer pv_ops kernel with xen, kvm, etc. possibly
built-in? So in your linux-2.6.27-rc5 vmlinux, the new function would see the
pv_ops symbols but no xen symbols, so it could set some "bare-metal" flag.
But in the Fedora kernel's case, it would see both pv_ops and xen symbols,
and then would have to actually read (if possible) the xen_start_info pointer
to see if it's been initialized to something -- hopefully without getting into
a chicken-and-egg situation. Worst case, it may require new crash command line
arguments such as --xen or --kvm. But I'm hoping to avoid that if at all possible.
Whatever gets done, it has the potential to be pretty ugly...
Do you have any thoughts on the matter?
Dave
----- "Ken'ichi Ohmichi" <oomichi(a)mxs.nes.nec.co.jp> wrote:
> Hi,
>
> Since linux-2.6.27 of x86_64, PAGE_OFFSET has been changed to
> 0xffff880000000000 from 0xffff810000000000.
> This patch catches up this change.
>
> I tested it on linux-2.6.27-rc5, and it works fine.
>
>
> Thanks
> Ken'ichi Ohmichi
>
> Signed-off-by: Ken'ichi Ohmichi <oomichi(a)mxs.nes.nec.co.jp>
> ---
> diff -rpuN crash-4.0-7.1.orig/defs.h crash-4.0-7.1/defs.h
> --- crash-4.0-7.1.orig/defs.h 2008-09-01 20:19:06.000000000 +0900
> +++ crash-4.0-7.1/defs.h 2008-09-01 20:22:07.000000000 +0900
> @@ -2124,6 +2124,8 @@ struct load_module {
> #define VMEMMAP_VADDR_2_6_24 0xffffe20000000000
> #define VMEMMAP_END_2_6_24 0xffffe2ffffffffff
>
> +#define PAGE_OFFSET_2_6_27 0xffff880000000000
> +
> #define USERSPACE_TOP_XEN 0x0000800000000000
> #define PAGE_OFFSET_XEN 0xffff880000000000
> #define VMALLOC_START_ADDR_XEN 0xffffc20000000000
> diff -rpuN crash-4.0-7.1.orig/x86_64.c crash-4.0-7.1/x86_64.c
> --- crash-4.0-7.1.orig/x86_64.c 2008-09-01 20:19:06.000000000 +0900
> +++ crash-4.0-7.1/x86_64.c 2008-09-01 20:32:14.000000000 +0900
> @@ -178,7 +178,6 @@ x86_64_init(int when)
> case VM_2_6_11:
> /* 2.6.11 layout */
> machdep->machspec->userspace_top = USERSPACE_TOP_2_6_11;
> - machdep->machspec->page_offset = PAGE_OFFSET_2_6_11;
> machdep->machspec->vmalloc_start_addr =
> VMALLOC_START_ADDR_2_6_11;
> machdep->machspec->vmalloc_end = VMALLOC_END_2_6_11;
> machdep->machspec->modules_vaddr = MODULES_VADDR_2_6_11;
> @@ -190,6 +189,13 @@ x86_64_init(int when)
> if (symbol_exists("vmemmap_populate"))
> machdep->flags |= VMEMMAP;
>
> + if (symbol_exists("end_pfn"))
> + /* 2.6.11 layout */
> + machdep->machspec->page_offset = PAGE_OFFSET_2_6_11;
> + else
> + /* 2.6.27 layout */
> + machdep->machspec->page_offset = PAGE_OFFSET_2_6_27;
> +
> machdep->uvtop = x86_64_uvtop_level4;
> break;
>
> ---
16 years
crash on x86_64: how to dump arg registers?
by Paul Sanders
Hello all,
I'm trying to get myself ramped to using crash on x86_64.
In x86_64 there is no register stack and function arguments aren't
typically placed on the stack, therefore we aren't able to see the
function arguments in the bt -f output.
Is there a trick to dumping out %rdi, %rsi, %rdx, etc?
I hope this isn't too lame of a question. I'm just getting my toes wet
with x86_64 and kdump/crash.
Thanks in advance,
Paul Sanders
SGI Global Product Support
16 years
[PATCH] crash: memory.c handling of node_online_map
by Cliff Wickman
This patch enables finding of node_states (instead of node_online_map)
when using a kerntypes file for a namelist.
I tested this against the dump of a 2.6.26 kernel.
Diffed against crash-4.0-7.1
Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
---
memory.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
Index: crash-4.0-7.1/memory.c
===================================================================
--- crash-4.0-7.1.orig/memory.c
+++ crash-4.0-7.1/memory.c
@@ -12850,14 +12850,17 @@ get_nodes_online(void)
!symbol_exists("node_states"))
return 0;
- if (LKCD_KERNTYPES()) {
- if ((len = STRUCT_SIZE("nodemask_t")) < 0)
- error(FATAL, "cannot determine type nodemask_t\n");
- mapaddr = symbol_value("node_online_map");
- } else if (symbol_exists("node_online_map")) {
- len = get_symbol_type("node_online_map", NULL, &req)
- == TYPE_CODE_UNDEF ? sizeof(ulong) : req.length;
- mapaddr = symbol_value("node_online_map");
+ if (symbol_exists("node_online_map")) {
+ if (LKCD_KERNTYPES()) {
+ if ((len = STRUCT_SIZE("nodemask_t")) < 0)
+ error(FATAL,
+ "cannot determine type nodemask_t\n");
+ mapaddr = symbol_value("node_online_map");
+ } else {
+ len = get_symbol_type("node_online_map", NULL, &req)
+ == TYPE_CODE_UNDEF ? sizeof(ulong) : req.length;
+ mapaddr = symbol_value("node_online_map");
+ }
} else if (symbol_exists("node_states")) {
if ((get_symbol_type("node_states", NULL, &req) != TYPE_CODE_ARRAY) ||
!(len = get_array_length("node_states", NULL, 0)) ||
16 years
[PATCH 2/2] Add x86_64 linux-2.6.27 support: Catch up the _cpu_pda change.
by Ken'ichi Ohmichi
Hi,
Since linux-2.6.27 of x86_64, _cpu_pda has been changed to **_cpu_pda
from *_cpu_pda[NR_CPUS].
This patch catches up this change.
I tested it on linux-2.6.27-rc5, and it works fine.
Thanks
Ken'ichi Ohmichi
Signed-off-by: Ken'ichi Ohmichi <oomichi(a)mxs.nes.nec.co.jp>
---
diff -rpuN crash-4.0-7.1.orig/defs.h crash-4.0-7.1/defs.h
--- crash-4.0-7.1.orig/defs.h 2008-09-02 11:14:45.000000000 +0900
+++ crash-4.0-7.1/defs.h 2008-09-02 11:16:50.000000000 +0900
@@ -2223,6 +2223,17 @@ struct load_module {
#define PAGEBASE(X) (((ulong)(X)) & (ulong)machdep->pagemask)
+#define _CPU_PDA_READ2(CPU, BUFFER) \
+ ((readmem(symbol_value("_cpu_pda"), \
+ KVADDR, &cpu_pda_addr, sizeof(unsigned long), \
+ "_cpu_pda addr", FAULT_ON_ERROR)) && \
+ (readmem(cpu_pda_addr + ((CPU) * sizeof(void *)), \
+ KVADDR, &cpu_pda_addr, sizeof(unsigned long), \
+ "_cpu_pda addr", FAULT_ON_ERROR)) && \
+ (cpu_pda_addr) && \
+ (readmem(cpu_pda_addr, KVADDR, (BUFFER), SIZE(x8664_pda), \
+ "cpu_pda entry", FAULT_ON_ERROR)))
+
#define _CPU_PDA_READ(CPU, BUFFER) \
((STRNEQ("_cpu_pda", closest_symbol((symbol_value("_cpu_pda") + \
((CPU) * sizeof(unsigned long)))))) && \
diff -rpuN crash-4.0-7.1.orig/x86_64.c crash-4.0-7.1/x86_64.c
--- crash-4.0-7.1.orig/x86_64.c 2008-09-02 11:14:45.000000000 +0900
+++ crash-4.0-7.1/x86_64.c 2008-09-02 11:14:55.000000000 +0900
@@ -540,7 +540,7 @@ x86_64_dump_machdep_table(ulong arg)
static void
x86_64_cpu_pda_init(void)
{
- int i, cpus, nr_pda, cpunumber, _cpu_pda;
+ int i, cpus, nr_pda, cpunumber, _cpu_pda, _boot_cpu_pda;
char *cpu_pda_buf;
ulong level4_pgt, data_offset, cpu_pda_addr;
struct syment *sp, *nsp;
@@ -575,11 +575,21 @@ x86_64_cpu_pda_init(void)
_cpu_pda = FALSE;
}
}
-
+ if (_cpu_pda) {
+ if (symbol_exists("_boot_cpu_pda"))
+ _boot_cpu_pda = TRUE;
+ else
+ _boot_cpu_pda = FALSE;
+ }
for (i = cpus = 0; i < nr_pda; i++) {
if (_cpu_pda) {
- if (!_CPU_PDA_READ(i, cpu_pda_buf))
- break;
+ if (_boot_cpu_pda) {
+ if (!_CPU_PDA_READ2(i, cpu_pda_buf))
+ break;
+ } else {
+ if (!_CPU_PDA_READ(i, cpu_pda_buf))
+ break;
+ }
} else {
if (!CPU_PDA_READ(i, cpu_pda_buf))
break;
@@ -3920,7 +3930,7 @@ x86_64_dis_filter(ulong vaddr, char *inb
int
x86_64_get_smp_cpus(void)
{
- int i, cpus, nr_pda, cpunumber, _cpu_pda;
+ int i, cpus, nr_pda, cpunumber, _cpu_pda, _boot_cpu_pda;
char *cpu_pda_buf;
ulong level4_pgt, cpu_pda_addr;
@@ -3946,10 +3956,21 @@ x86_64_get_smp_cpus(void)
_cpu_pda = FALSE;
}
}
+ if (_cpu_pda) {
+ if (symbol_exists("_boot_cpu_pda"))
+ _boot_cpu_pda = TRUE;
+ else
+ _boot_cpu_pda = FALSE;
+ }
for (i = cpus = 0; i < nr_pda; i++) {
if (_cpu_pda) {
- if (!_CPU_PDA_READ(i, cpu_pda_buf))
- break;
+ if (_boot_cpu_pda) {
+ if (!_CPU_PDA_READ2(i, cpu_pda_buf))
+ break;
+ } else {
+ if (!_CPU_PDA_READ(i, cpu_pda_buf))
+ break;
+ }
} else {
if (!CPU_PDA_READ(i, cpu_pda_buf))
break;
---
16 years
[PATCH 1/2] Add x86_64 linux-2.6.27 support: Catch up the PAGE_OFFSET change.
by Ken'ichi Ohmichi
Hi,
Since linux-2.6.27 of x86_64, PAGE_OFFSET has been changed to
0xffff880000000000 from 0xffff810000000000.
This patch catches up this change.
I tested it on linux-2.6.27-rc5, and it works fine.
Thanks
Ken'ichi Ohmichi
Signed-off-by: Ken'ichi Ohmichi <oomichi(a)mxs.nes.nec.co.jp>
---
diff -rpuN crash-4.0-7.1.orig/defs.h crash-4.0-7.1/defs.h
--- crash-4.0-7.1.orig/defs.h 2008-09-01 20:19:06.000000000 +0900
+++ crash-4.0-7.1/defs.h 2008-09-01 20:22:07.000000000 +0900
@@ -2124,6 +2124,8 @@ struct load_module {
#define VMEMMAP_VADDR_2_6_24 0xffffe20000000000
#define VMEMMAP_END_2_6_24 0xffffe2ffffffffff
+#define PAGE_OFFSET_2_6_27 0xffff880000000000
+
#define USERSPACE_TOP_XEN 0x0000800000000000
#define PAGE_OFFSET_XEN 0xffff880000000000
#define VMALLOC_START_ADDR_XEN 0xffffc20000000000
diff -rpuN crash-4.0-7.1.orig/x86_64.c crash-4.0-7.1/x86_64.c
--- crash-4.0-7.1.orig/x86_64.c 2008-09-01 20:19:06.000000000 +0900
+++ crash-4.0-7.1/x86_64.c 2008-09-01 20:32:14.000000000 +0900
@@ -178,7 +178,6 @@ x86_64_init(int when)
case VM_2_6_11:
/* 2.6.11 layout */
machdep->machspec->userspace_top = USERSPACE_TOP_2_6_11;
- machdep->machspec->page_offset = PAGE_OFFSET_2_6_11;
machdep->machspec->vmalloc_start_addr = VMALLOC_START_ADDR_2_6_11;
machdep->machspec->vmalloc_end = VMALLOC_END_2_6_11;
machdep->machspec->modules_vaddr = MODULES_VADDR_2_6_11;
@@ -190,6 +189,13 @@ x86_64_init(int when)
if (symbol_exists("vmemmap_populate"))
machdep->flags |= VMEMMAP;
+ if (symbol_exists("end_pfn"))
+ /* 2.6.11 layout */
+ machdep->machspec->page_offset = PAGE_OFFSET_2_6_11;
+ else
+ /* 2.6.27 layout */
+ machdep->machspec->page_offset = PAGE_OFFSET_2_6_27;
+
machdep->uvtop = x86_64_uvtop_level4;
break;
---
16 years
