[patch] Crash-Utility: ppc64: Fix a crash issue where it fails to read vmcore generated by post-v2.6.34 kernel version.
by Mahesh J Salgaonkar
With some changes in the upstream ppc64 kernel starting from 2.6.34, the
crash utility fails to read vmcore generated by post-v2.6.34 kernel versions.
In v2.6.34 ppc64, the upstream commit 1426d5a3bd07589534286375998c0c8c6fdc5260
(powerpc: Dynamically allocate pacas) now dynamically allocates the paca and
have changed data type of 'paca' symbol from array to pointer. With this change
in place crash utility fails to read vmcore generated for upstream kernel.
This patch fixes the crash tool to get correct address value for paca
symbol depending on its data type.
In v2.6.36 ppc64, the upstream commit fc53b4202e61c7e9008c241933ae282aab8a6082
overwrites the paca pointer variable to point to static paca (during crash
just before kexec) that contains valid data_offset only for crashing cpu.
Hence we can not rely on paca symbol anymore to get valid per cpu data_offset
values. Instead, this version introduces __per_cpu_offset array again which
was removed post v2.6.15 ppc64. This patch checks for existence of
'__per_cpu_offset' symbol before calling ppc64_paca_init().
This fix is backward compatible and works fine with vmcore generated by older
kernel (pre-2.6.34).
Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
---
ppc64.c | 34 ++++++++++++++++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
Index: crash-5.1.7/ppc64.c
===================================================================
--- crash-5.1.7.orig/ppc64.c
+++ crash-5.1.7/ppc64.c
@@ -201,7 +201,22 @@ ppc64_init(int when)
machdep->section_size_bits = _SECTION_SIZE_BITS;
machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
- ppc64_paca_init();
+ /*
+ * starting from v2.6.36 we can not rely on paca structure
+ * to get per cpu data_offset. The upstream commit
+ * fc53b4202e61c7e9008c241933ae282aab8a6082 overwrites the
+ * paca pointer variable to point to static paca that contains
+ * valid data_offset only for crashing cpu.
+ *
+ * But the kernel v2.6.36 ppc64 introduces __per_cpu_offset
+ * symbol which was removed post v2.6.15 ppc64 and now we
+ * get the per cpu data_offset from __per_cpu_offset symbol
+ * during kernel_init() call. Hence for backward (pre-2.6.36)
+ * compatibility, call ppc64_paca_init() only if symbol
+ * __per_cpu_offset does not exist.
+ */
+ if (!symbol_exists("__per_cpu_offset"))
+ ppc64_paca_init();
machdep->vmalloc_start = ppc64_vmalloc_start;
MEMBER_OFFSET_INIT(thread_struct_pg_tables,
"thread_struct", "pg_tables");
@@ -2606,10 +2621,25 @@ ppc64_paca_init(void)
char *cpu_paca_buf;
ulong data_offset;
int map;
+ ulong paca;
if (!symbol_exists("paca"))
error(FATAL, "PPC64: Could not find 'paca' symbol\n");
+ /*
+ * In v2.6.34 ppc64, the upstream commit
+ * 1426d5a3bd07589534286375998c0c8c6fdc5260 (powerpc: Dynamically
+ * allocate pacas) now dynamically allocates the paca and have
+ * changed data type of 'paca' symbol from array to pointer. With this
+ * change in place crash utility fails to read vmcore generated for
+ * upstream kernel.
+ * Add a check for paca variable data type before accessing.
+ */
+ if (get_symbol_type("paca", NULL, NULL) == TYPE_CODE_PTR)
+ readmem(symbol_value("paca"), KVADDR, &paca, sizeof(ulong),
+ "paca", FAULT_ON_ERROR);
+ else
+ paca = symbol_value("paca");
if (cpu_map_addr("possible"))
map = POSSIBLE;
else if (cpu_map_addr("present"))
@@ -2648,7 +2678,7 @@ ppc64_paca_init(void)
if (!in_cpu_map(map, i))
continue;
- readmem(symbol_value("paca") + (i * SIZE(ppc64_paca)),
+ readmem(paca + (i * SIZE(ppc64_paca)),
KVADDR, cpu_paca_buf, SIZE(ppc64_paca),
"paca entry", FAULT_ON_ERROR);
12 years, 9 months
[PATCH] s390: Fix printing of control and floating point registers
by Michael Holzheu
Hi Dave,
Control registers 8-15 (s390x and s390) and floating point registers 8-15
(s390x only) are not printed correctly because the we copy the content from
the wrong location of the save area.
Looks like nobody has realized this problem in the past because those
registers are not too important for debugging kernel problems...
This patch fixes this problem and now control and floating point registers
are printed correctly.
Signed-off-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
---
s390.c | 16 ++++++++--------
s390x.c | 32 ++++++++++++++++----------------
2 files changed, 24 insertions(+), 24 deletions(-)
--- a/s390.c
+++ b/s390.c
@@ -861,16 +861,16 @@ s390_print_lowcore(char* lc, struct bt_i
fprintf(fp," %#010lx %#010lx %#010lx %#010lx\n",
tmp[0], tmp[1], tmp[2], tmp[3]);
- tmp[0]=ULONG(ptr);
- tmp[1]=ULONG(ptr + S390_WORD_SIZE);
- tmp[2]=ULONG(ptr + 2 * S390_WORD_SIZE);
- tmp[3]=ULONG(ptr + 3 * S390_WORD_SIZE);
+ tmp[0]=ULONG(ptr + 8);
+ tmp[1]=ULONG(ptr + 9 * S390_WORD_SIZE);
+ tmp[2]=ULONG(ptr + 10 * S390_WORD_SIZE);
+ tmp[3]=ULONG(ptr + 11 * S390_WORD_SIZE);
fprintf(fp," %#010lx %#010lx %#010lx %#010lx\n",
tmp[0], tmp[1], tmp[2], tmp[3]);
- tmp[0]=ULONG(ptr + 4 * S390_WORD_SIZE);
- tmp[1]=ULONG(ptr + 5 * S390_WORD_SIZE);
- tmp[2]=ULONG(ptr + 6 * S390_WORD_SIZE);
- tmp[3]=ULONG(ptr + 7 * S390_WORD_SIZE);
+ tmp[0]=ULONG(ptr + 12 * S390_WORD_SIZE);
+ tmp[1]=ULONG(ptr + 13 * S390_WORD_SIZE);
+ tmp[2]=ULONG(ptr + 14 * S390_WORD_SIZE);
+ tmp[3]=ULONG(ptr + 15 * S390_WORD_SIZE);
fprintf(fp," %#010lx %#010lx %#010lx %#010lx\n",
tmp[0], tmp[1], tmp[2], tmp[3]);
--- a/s390x.c
+++ b/s390x.c
@@ -1184,16 +1184,16 @@ s390x_print_lowcore(char* lc, struct bt_
tmp[3]=ULONG(ptr + 7 * S390X_WORD_SIZE);
fprintf(fp," %#018lx %#018lx\n", tmp[0],tmp[1]);
fprintf(fp," %#018lx %#018lx\n", tmp[2],tmp[3]);
- tmp[0]=ULONG(ptr);
- tmp[1]=ULONG(ptr + S390X_WORD_SIZE);
- tmp[2]=ULONG(ptr + 2 * S390X_WORD_SIZE);
- tmp[3]=ULONG(ptr + 3 * S390X_WORD_SIZE);
+ tmp[0]=ULONG(ptr + 8);
+ tmp[1]=ULONG(ptr + 9 * S390X_WORD_SIZE);
+ tmp[2]=ULONG(ptr + 10 * S390X_WORD_SIZE);
+ tmp[3]=ULONG(ptr + 11 * S390X_WORD_SIZE);
fprintf(fp," %#018lx %#018lx\n", tmp[0],tmp[1]);
fprintf(fp," %#018lx %#018lx\n", tmp[2],tmp[3]);
- tmp[0]=ULONG(ptr + 4 * S390X_WORD_SIZE);
- tmp[1]=ULONG(ptr + 5 * S390X_WORD_SIZE);
- tmp[2]=ULONG(ptr + 6 * S390X_WORD_SIZE);
- tmp[3]=ULONG(ptr + 7 * S390X_WORD_SIZE);
+ tmp[0]=ULONG(ptr + 12 * S390X_WORD_SIZE);
+ tmp[1]=ULONG(ptr + 13 * S390X_WORD_SIZE);
+ tmp[2]=ULONG(ptr + 14 * S390X_WORD_SIZE);
+ tmp[3]=ULONG(ptr + 15 * S390X_WORD_SIZE);
fprintf(fp," %#018lx %#018lx\n", tmp[0],tmp[1]);
fprintf(fp," %#018lx %#018lx\n", tmp[2],tmp[3]);
@@ -1211,16 +1211,16 @@ s390x_print_lowcore(char* lc, struct bt_
tmp[3]=ULONG(ptr + 7 * S390X_WORD_SIZE);
fprintf(fp," %#018lx %#018lx\n", tmp[0],tmp[1]);
fprintf(fp," %#018lx %#018lx\n", tmp[2],tmp[3]);
- tmp[0]=ULONG(ptr + 6 * S390X_WORD_SIZE);
- tmp[1]=ULONG(ptr + 7 * S390X_WORD_SIZE);
- tmp[2]=ULONG(ptr + 8 * S390X_WORD_SIZE);
- tmp[3]=ULONG(ptr + 9 * S390X_WORD_SIZE);
+ tmp[0]=ULONG(ptr + 8 * S390X_WORD_SIZE);
+ tmp[1]=ULONG(ptr + 9 * S390X_WORD_SIZE);
+ tmp[2]=ULONG(ptr + 10 * S390X_WORD_SIZE);
+ tmp[3]=ULONG(ptr + 11 * S390X_WORD_SIZE);
fprintf(fp," %#018lx %#018lx\n", tmp[0],tmp[1]);
fprintf(fp," %#018lx %#018lx\n", tmp[2],tmp[3]);
- tmp[0]=ULONG(ptr + 10* S390X_WORD_SIZE);
- tmp[1]=ULONG(ptr + 11* S390X_WORD_SIZE);
- tmp[2]=ULONG(ptr + 12* S390X_WORD_SIZE);
- tmp[3]=ULONG(ptr + 13* S390X_WORD_SIZE);
+ tmp[0]=ULONG(ptr + 12 * S390X_WORD_SIZE);
+ tmp[1]=ULONG(ptr + 13 * S390X_WORD_SIZE);
+ tmp[2]=ULONG(ptr + 14 * S390X_WORD_SIZE);
+ tmp[3]=ULONG(ptr + 15 * S390X_WORD_SIZE);
fprintf(fp," %#018lx %#018lx\n", tmp[0],tmp[1]);
fprintf(fp," %#018lx %#018lx\n", tmp[2],tmp[3]);
}
12 years, 9 months
Re: [Crash-utility] [PATCH v2 00/12] Add sadump format support
by Dave Anderson
----- Original Message -----
> Hello Dave,
>
> Thanks for reviewing. I've reflected your comments and this is the
> second version.
>
> About sample vmcores, I'll send email to you in private.
> Please wait for a while.
>
> Change Log
>
> v0 => v1)
>
> * Move REMOTE_DAEMON bit from pc->flags to pc->flags2; See PATCH
> 01. SADUMP bit is now introduced in pc->flags.
>
> * Fix the bug, I found locally, that in per_cpu_ptr(), symbol
> value of symbol __per_cpu_offset was directly used. Here should
> have dereferenced the symbol value.
Hello Daisuke,
Except for these 3 issues (which I will fix), the second patch looks good:
(1) I'll fix this bug in the sadump_cleanup_sadump_data() function:
+ pc->flags2 &= ~SADUMP;
(2) I'll add SADUMP bit display in dump_program_context() for "help -p"
(3) I'll add percpu_data size display in dump_offset_table() for "help -o"
With those 3 adjustments, the patch is queued for crash-5.1.8.
Thanks,
Dave
12 years, 9 months
[RESEND] Re: [PATCH 00/12] Add sadump format support
by Dave Anderson
For whatever reason, the archived version of my response was completely
screwed up:
https://www.redhat.com/archives/crash-utility/2011-September/msg00001.html
So the digest version will probably be borked as well...
This was my response:
----- Original Message -----
> Hello Dave,
>
> I'm sorry for taking considerably long time. Now I post a patch set
> implementing sadump support for crash utility.
>
> Applying this patch set, crash utility will be able to recognize
> sadump-related formats on 3 kinds configurations: single partition,
> diskset and media backup file.
>
> The crash version the patch set can be applied to is 5.1.7.
>
> Please look at each patch description for detailed explanation.
Hello Daisuke,
The patch-set looks good, and the changes to the common code are
nicely segregated.
But let's simplify things. I'd prefer to avoid all of these constructs:
if (!(pc->flags & DUMPFILE_TYPES) && !(pc->flags2 & SADUMP))
...
if ((pc->flags & MEMORY_SOURCES) || (pc->flags2 & MEMORY_SOURCES2))
...
Can you move the REMOTE_DAEMON bit from pc->flags to the next available
pc->flags2 bit, and then change these four references appropriately:
C symbol: REMOTE_DAEMON
File Function Line
0 defs.h <global> 145 #define REMOTE_DAEMON (0x200ULL)
1 defs.h REMOTE 206 #define REMOTE() (pc->flags & REMOTE_DAEMON)
2 main.c main 375 pc->flags |= REMOTE_DAEMON;
3 main.c dump_program_context 1084 if (pc->flags & REMOTE_DAEMON)
Then you can make SADUMP equal to 0x200ULL, and put it in pc->flags,
DUMPFILE_TYPES and MEMORY_SOURCES. That will signficantly simplify
the patch-set.
> BTW, do you want sadump dumpfiles? I geuss you need them for testing
> samples.
Definitely -- but please make them as small as possible, and you can
send me the dumpfile-access details privately if you prefer.
Depending upon how quickly you can create an updated patchset, I may defer
this to crash-5.1.9 because I'm just about to release 5.1.8.
Thanks,
Dave
12 years, 9 months