3:15 a.m.
We use this patch to catch incorrect access to per_cpu data. But crash
cant deal with it unfortunately.
http://patchwork.ozlabs.org/linuxppc/patch?id=4423
honeydew:~ # crash -s /root/2.6.15.42-kexec/vmlinux /proc/vmcore
crash: pglist_data.node_mem_map structure member does not exist.
crash: certain memory-related commands will fail or display invalid data
crash: invalid kernel virtual address: aeeeeeeeef3736ae type: "runqueues entry
(per_cpu)"
7:55 a.m.
Olaf Hering wrote:
We use this patch to catch incorrect access to per_cpu data. But
crash
cant deal with it unfortunately.
http://patchwork.ozlabs.org/linuxppc/patch?id=4423
honeydew:~ # crash -s /root/2.6.15.42-kexec/vmlinux /proc/vmcore
crash: pglist_data.node_mem_map structure member does not exist.
crash: certain memory-related commands will fail or display invalid data
crash: invalid kernel virtual address: aeeeeeeeef3736ae type: "runqueues entry
(per_cpu)"
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Hi Olaf,
Thanks for the heads-up:
Index: linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-2.6.16-rc1-git3.orig/arch/powerpc/kernel/setup_64.c
+++ linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
@@ -670,6 +670,14 @@ void __init setup_per_cpu_areas(void)
size = PERCPU_ENOUGH_ROOM;
#endif
+ /*
+ * Poison invalid cpus, with lots of high bits set this should
+ * always fault
+ */
+ for (i = 0; i < NR_CPUS; i++) {
+ paca[i].data_offset = 0xeeeeeeeeeeeeeeeeULL;
+ }
+
for_each_cpu(i) {
ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
if (!ptr)
I'll defer this to the IBM ppc64 guys, but it would seemingly
be simple enough to detect this in ppc64.c:ppc64_paca_init()
by checking for both 0 and 0xeeeeeeeeeeeeeeeeULL:
for (i = cpus = 0; i < nr_paca; i++) {
readmem(symbol_value("paca") + (i * SIZE(ppc64_paca)),
KVADDR, cpu_paca_buf, SIZE(ppc64_paca),
"paca entry", FAULT_ON_ERROR);
per_cpu_offset = ULONG(cpu_paca_buf + data_offset);
- if (per_cpu_offset == 0)
+ if ((per_cpu_offset == 0) ||
+ (per_cpu_offset == 0xeeeeeeeeeeeeeeeeULL))
continue;
kt->__per_cpu_offset[i] = per_cpu_offset;
kt->flags |= PER_CPU_OFF;
cpus++;
}
Thanks again,
Dave
12:51 p.m.
Olaf,
I was looking in 2.6.16-rc5-git8, but did not find the patch that
you mentioned.
arch/powerpc/kernel/setup_64.c:
#ifdef CONFIG_SMP
void __init setup_per_cpu_areas(void)
{
int i;
unsigned long size;
char *ptr;
/* Copy section for each CPU (we discard the original) */
size = ALIGN(__per_cpu_end - __per_cpu_start, SMP_CACHE_BYTES);
#ifdef CONFIG_MODULES
if (size < PERCPU_ENOUGH_ROOM)
size = PERCPU_ENOUGH_ROOM;
#endif
for_each_cpu(i) {
ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
if (!ptr)
panic("Cannot allocate cpu data for CPU %d\n", i);
paca[i].data_offset = ptr - __per_cpu_start;
memcpy(ptr, __per_cpu_start, __per_cpu_end -
__per_cpu_start);
}
}
Instead of depending on paca[#].data_offset, my fix will use
cpu_online_map to read the valid cpu paca structs. But, if the kernel sets
0xeeeeeeeeeeeeeeeeULL, yes, using this value will be the better solution.
Dave, the attached patch contains both fixes that Rachita reported.
- Report an error message if the thread is running in user space
and print regs.
- Finding the valid per_cpu_offset values
Thanks
Haren
crash-utility-bounces(a)redhat.com wrote on 03/09/2006 01:15:56 AM:
We use this patch to catch incorrect access to per_cpu data. But crash
cant deal with it unfortunately.
http://patchwork.ozlabs.org/linuxppc/patch?id=4423
honeydew:~ # crash -s /root/2.6.15.42-kexec/vmlinux /proc/vmcore
crash: pglist_data.node_mem_map structure member does not exist.
crash: certain memory-related commands will fail or display invalid data
crash: invalid kernel virtual address: aeeeeeeeef3736ae type:
"runqueues entry (per_cpu)"
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
1:47 p.m.
Haren Myneni wrote:
Olaf,
I was looking in 2.6.16-rc5-git8, but did not find the patch that you mentioned.
arch/powerpc/kernel/setup_64.c:
#ifdef CONFIG_SMP
void __init setup_per_cpu_areas(void)
{
int i;
unsigned long size;
char *ptr;
/* Copy section for each CPU (we discard the original) */
size = ALIGN(__per_cpu_end - __per_cpu_start, SMP_CACHE_BYTES);
#ifdef CONFIG_MODULES
if (size < PERCPU_ENOUGH_ROOM)
size = PERCPU_ENOUGH_ROOM;
#endif
for_each_cpu(i) {
ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
if (!ptr)
panic("Cannot allocate cpu data for CPU %d\n", i);
paca[i].data_offset = ptr - __per_cpu_start;
memcpy(ptr, __per_cpu_start, __per_cpu_end - __per_cpu_start);
}
}
Instead of depending on paca[#].data_offset, my fix will use cpu_online_map to read the
valid cpu paca structs. But,
if the kernel sets 0xeeeeeeeeeeeeeeeeULL, yes, using this value will be the better
solution.
Dave, the attached patch contains both fixes that Rachita reported.
- Report an error message if the thread is running in user space and print regs.
- Finding the valid per_cpu_offset values
Thanks
Haren
Haren,
Is this right? NR_CPUS is hardcoded (in crash) to 32 for ppc64,
and BITS_FOR_LONG is 64, making it "ulong cpu_online_map[0]":
@@ -2282,21 +2298,22 @@ parse_cmdline_arg(void)
static void
ppc64_paca_init(void)
{
+#define BITS_FOR_LONG sizeof(ulong)*8
int i, cpus, nr_paca;
char *cpu_paca_buf;
ulong data_offset;
- ulong per_cpu_offset;
- ulong cpuid_offset;
- signed short cpuid;
+ ulong cpu_online_map[NR_CPUS/BITS_FOR_LONG];
Or am I missing something obvious?
Also, I get a little nervous about depending upon the NR_CPUS
value compiled into crash being the same as the configured
NR_CPUS in the kernel. As far as crash is concerned, NR_CPUS
means the "largest possible" cpu configuration that this version
of *crash* will support; it's not meant to be aligned with
the kernel's value.
But if you guys are happy with that, it's fine with me.
Dave
2:15 p.m.
Olaf Hering wrote:
On Thu, Mar 09, Dave Anderson wrote:
> Is this right? NR_CPUS is hardcoded (in crash) to 32 for ppc64,
Ugh, cant that be guessed from the core file or from the debuginfo?
It can. But since the crash/2.2.x timeframe, there's been a number of
pre-defined arrays or code sequences in the crash code that were
put in place to gather kernel data during session initialization when
it's unknown how many cpus were configured into the target kernel.
I've regretted that ever since, but never got around to replacing them,
and to complicate matters, other stuff like LKCD data structures got
added which use NR_CPUS, and so on...
Anyway, it's been harmless to date, as long as the NR_CPUS compiled
into crash is equal to or greater than what was compiled into the
kernel. In fact, if you try to run crash on a kernel that has a greater
NR_CPUS value in the kernel than what's in crash, it will recognize that,
report it, and die. But it was never meant to be used as the NR_CPUS
that's configured into the kernel -- I probably should have re-named it
from the start to avoid the confusion.
But back in those days, the concept of running Linux in anything
greater than 32 cpus seemed like a pipe dream...
Dave
6689
days inactive
6689
days old
devel@lists.crash-utility.osci.io
6 comments
3 participants
participants (3)
-
Dave Anderson -
Haren Myneni -
Olaf Hering