Re: [Crash-utility] [PATCH] Display online cpus value in preference to kt->cpus
by Dave Anderson
----- "Luciano Chavez" <lnx1138(a)linux.vnet.ibm.com> wrote:
> > So if you want to do something specifically for ppc64, please
> > re-post a patch for just that architecture.
> >
> > Dave
> >
>
> Dave,
>
> Thanks for taking a good look at all the many cases that would make a
> general solution of using online cpu count messy. I originally did want
> to make this change only applicable to ppc64. The thing was, only
> ppc64_display_machine_stats() was possible to affect and to make the
> value displayed consistent, changing display_sys_stats() and
> dump_kernel_table() was necessary.
>
> So, re-thinking this to be a ppc64 specific change to CPUS to be
> displayed as the online count when possible and having everyone else do
> what they do now, which is to display kt->cpus, I suggest the following:
>
> 1. Add a get_cpus_to_display as a machdep function
> 2. For ppc64, initialize machdep->get_cpus_to_display to ppc64_get_cpus_to_display()
> which will attempt to use get_cpus_online() or fallback to using kt->cpus
> 3. For all other architectures, have them initialize machdep->get_cpus_to_display
> to generic_get_cpus_to_display() which returns kt->cpus to maintain the status
> quo of the code as it is now
> 4. Replace kt->cpus in display_sys_stats() and dump_kernel_table() in kernel.c to
> invoke machdep->get_cpus_to_display() when displaying CPUS
Well, we certainly don't want to change the "cpus:" output of dump_kernel_table()
because its purpose there *is* specifically to dump the kt->cpus value.
>
> Let me know what you think. I think this solution allows for future
> flexibility for other architectures if in the future they individually
> need to change what they display for the cpu count.
The fact of the matter is that it's really not machine-specific in the
sense that your function is just parsing the architecture-neutral cpu maps.
And even the "online-oddities" that I mentioned were not machine-specific,
but rather virtual-vs-baremetal issues.
For now, all I was thinking would be to simply change display_sys_stats()
to something like:
if (machine_type("PPC64"))
your_function();
else
fprintf(fp, " CPUS: %d\n", kt->cpus);
and since your_function() does not need to be in a machine-specific
file, just put in kernel.c. And you can also call it from the
ppc64_display_machine_stats() function.
Dave
14 years, 9 months
Re: [Crash-utility] [PATCH] Display online cpus value in preference to kt->cpus
by Dave Anderson
----- "Dave Anderson" <anderson(a)redhat.com> wrote:
> ----- "Luciano Chavez" <lnx1138(a)linux.vnet.ibm.com> wrote:
>
> > Hi Dave,
> >
> > Thinking about backward compatibility, would displaying "ONLINE CPUS"
> > still seem OK for the case where kernel_init() finds the smp_num_cpus
> > symbol (as for a 2.4 kernel)? Before there were the various cpu maps, I
> > think smp_num_cpus was analogous to the possible cpus as opposed to
> > online. I can see this requiring some thought as to what CPUS in the
> > output means when you have various different maps now (online, possible,
> > and present). That being said, it would be good to leave no doubt and
> > explicitly state the count is for the present or online CPUS with the
> > latter being my suggestion.
> >
> > I forgot to mention that I suspect the problem I mentioned before would
> > get stranger for POWER7 which offers 4 threads per core. I didn't have
> > access to a POWER7 machine to see just what it would do if we tried
> > disabling SMT as before but it follows the same pattern the count
> > displayed would be way off from the online count.
>
> I just ran through a bunch of stashed dumpfiles I have on hand, and
> it gets even murkier when dealing with Xen or KVM kernels, because
> as part of the post-crash shutdown (or forced dump), all but one of
> the cpus may be taken "offline". So even though there may be 4 vcpus,
> and crash correctly shows 4 "CPUS", the cpu_online_map shows only one
> cpu bit. So if we went ahead and displayed a number based upon the
> cpu_online_map, it would completely misleading. Incorrect
> actually...
You can always dump the possible/present/online map information with
the "help -k" debug option.
So for example, taking a 2.6.9-era (RHEL4) xen kernel that crashed
on vcpu 3 due to a NULL reference, the hypervisor made a callback to
the other vcpus to shut them down prior to the core dumping procedure:
crash> help -k
...
cpu_possible_map: (does not exist)
cpu_present_map: 0 1 2 3
cpu_online_map: 3
...
So the online map cannot be used for the cpu count, and for that
matter, it wouldn't make any sense to even display the online map
count.
In any case, for now I prefer not to change things, at least for the
other architectures.
That being said, I defer machine-specific items for ppc64, s390
and s390x to the IBM maintainers, and to HP for ia64. (The ppc
and alpha architectures have no active "maintainers" any more,
so those arches are pretty much withering on the vine.)
So if you want to do something specifically for ppc64, please
re-post a patch for just that architecture.
Dave
14 years, 9 months
Re: [Crash-utility] [PATCH] Display online cpus value in preference to kt->cpus
by Dave Anderson
----- "Luciano Chavez" <lnx1138(a)linux.vnet.ibm.com> wrote:
> Hi Dave,
>
> Thinking about backward compatibility, would displaying "ONLINE CPUS"
> still seem OK for the case where kernel_init() finds the smp_num_cpus
> symbol (as for a 2.4 kernel)? Before there were the various cpu maps, I
> think smp_num_cpus was analogous to the possible cpus as opposed to
> online. I can see this requiring some thought as to what CPUS in the
> output means when you have various different maps now (online, possible,
> and present). That being said, it would be good to leave no doubt and
> explicitly state the count is for the present or online CPUS with the
> latter being my suggestion.
>
> I forgot to mention that I suspect the problem I mentioned before would
> get stranger for POWER7 which offers 4 threads per core. I didn't have
> access to a POWER7 machine to see just what it would do if we tried
> disabling SMT as before but it follows the same pattern the count
> displayed would be way off from the online count.
I just ran through a bunch of stashed dumpfiles I have on hand, and
it gets even murkier when dealing with Xen or KVM kernels, because
as part of the post-crash shutdown (or forced dump), all but one of
the cpus may be taken "offline". So even though there may be 4 vcpus,
and crash correctly shows 4 "CPUS", the cpu_online_map shows only one
cpu bit. So if we went ahead and displayed a number based upon the
cpu_online_map, it would completely misleading. Incorrect actually...
Dave
14 years, 9 months
[PATCH] Display online cpus value in preference to kt->cpus
by Luciano Chavez
Howdy,
crash 5.0.0 introduced a change to ppc64_paca_init() in ppc64.c to
manipulate kt->cpus to fix a 4.0-8.11 regression when
cpu_possible_map has more cpus than cpu_online_map. The change basically
adjusts kt->cpus to the highest cpu index + 1. In situations where cpus
from 0 through highest index are all online, this will equal online cpus.
On IBM POWER based system supporting SMT, we can have it dynamically
enabled and disabled and so we can go from:
brucelp3:~ # ppc64_cpu --smt=on
brucelp3:~ # cat /sys/devices/system/cpu/online
0-9
to
brucelp3:~ # ppc64_cpu --smt=off
brucelp3:~ # cat /sys/devices/system/cpu/online
0,2,4,6,8
In this situation, the new code will determine that kt->cpus is 9. crash
will display:
KERNEL: /boot/vmlinux
DUMPFILE: /dev/mem
CPUS: 9 ===============> Rather than 5
DATE: Fri Feb 26 06:06:51 2010
UPTIME: 04:22:34
LOAD AVERAGE: 0.49, 0.14, 0.05
TASKS: 320
NODENAME: brucelp3
RELEASE: 2.6.32.8-0.3-ppc64
VERSION: #1 SMP 2010-02-22 16:22:25 +0100
MACHINE: ppc64 (unknown Mhz)
MEMORY: 1 GB
PID: 19948
COMMAND: "crash"
TASK: c00000002433be50 [THREAD_INFO: c0000000238a0000]
CPU: 2
STATE: TASK_RUNNING (ACTIVE)
kernel_init() initially does come up with 5 for kt->cpus initially before
the machdep init routine (ppc64_paca_init) ends up changing it to 9 in
the above situation.
Because of the way other parts of the code seem to iterate, allowing kt->cpus
to get set to the number of online cpus (5) would make them not work properly
either. Case in point, the ps command. It would iterate through the first 5
cpus for the swapper tasks and stop, providing no information for swapper tasks
on online cpus 6 and 8.
Rather than displaying kt->cpu for cpu count to display to users, can we call
get_cpus_online() itself. This will solve the problem of keeping kt->cpu
separate from get_cpus_online(). So commands like ps, set etc can still rely on
kt->cpu as set for each architecture. Additionally, we need to consider
providing the value as it exists after machine dependent init in case
the symbols required by get_cpus_online() are not available.
The patch provided creates a new routine called get_cpus_to_display() in
kernel.c that simply attempts to retrieve the count of
online CPUs with get_cpus_online(). However, since the cpu_online_map symbol
may not be available with all kernels, the cpus_to_display() routine will
return the value for kt->cpus if get_cpus_online() return 0 for that case
to maintain backwards compatibility.
With this in mind, all locations (mainly the display_machine_stats() routines
for each architecture, display_sys_stats() and dump_kernel_table()) in the
source that would print the cpu count using kt->cpus now call
get_cpus_to_display() to obtain that value.
This should hopefully provide the user with an expected CPU count regardless of
the internal manipulation that is sometimes done to the kt->cpus value.
regards,
--
Luciano Chavez <lnx1138(a)linux.vnet.ibm.com>
IBM Linux Technology Center
diff -up crash-5.0.1/alpha.c.orig crash-5.0.1/alpha.c
--- crash-5.0.1/alpha.c.orig 2010-03-04 07:19:23.000000000 -0600
+++ crash-5.0.1/alpha.c 2010-03-04 07:20:43.000000000 -0600
@@ -2641,7 +2641,7 @@ alpha_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
diff -up crash-5.0.1/defs.h.orig crash-5.0.1/defs.h
--- crash-5.0.1/defs.h.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/defs.h 2010-03-04 07:20:43.000000000 -0600
@@ -3717,6 +3717,7 @@ int get_cpus_online(void);
int get_cpus_present(void);
int get_cpus_possible(void);
int get_highest_cpu_online(void);
+int get_cpus_to_display(void);
int in_cpu_map(int, int);
void paravirt_init(void);
void print_stack_text_syms(struct bt_info *, ulong, ulong);
diff -up crash-5.0.1/ia64.c.orig crash-5.0.1/ia64.c
--- crash-5.0.1/ia64.c.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/ia64.c 2010-03-04 07:20:43.000000000 -0600
@@ -2325,7 +2325,7 @@ ia64_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
diff -up crash-5.0.1/kernel.c.orig crash-5.0.1/kernel.c
--- crash-5.0.1/kernel.c.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/kernel.c 2010-03-04 07:20:43.000000000 -0600
@@ -3871,7 +3871,7 @@ display_sys_stats(void)
}
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
if (ACTIVE())
get_symbol_data("xtime", sizeof(struct timespec), &kt->date);
fprintf(fp, " DATE: %s\n",
@@ -4289,7 +4289,7 @@ dump_kernel_table(int verbose)
fprintf(fp, " init_begin: %lx\n", kt->init_begin);
fprintf(fp, " init_end: %lx\n", kt->init_end);
fprintf(fp, " end: %lx\n", kt->end);
- fprintf(fp, " cpus: %d\n", kt->cpus);
+ fprintf(fp, " cpus: %d\n", get_cpus_to_display());
fprintf(fp, " cpus_override: %s\n", kt->cpus_override);
fprintf(fp, " NR_CPUS: %d (compiled-in to this version of %s)\n",
NR_CPUS, pc->program_name);
@@ -6257,6 +6257,16 @@ get_cpus_possible()
}
/*
+ * For when displaying cpus, return the number of cpus online if possible, otherwise kt->cpus.
+ */
+int
+get_cpus_to_display(void)
+{
+ int online = get_cpus_online();
+ return (online ? online : kt->cpus);
+}
+
+/*
* Xen machine-address to pseudo-physical-page translator.
*/
ulonglong
diff -up crash-5.0.1/ppc64.c.orig crash-5.0.1/ppc64.c
--- crash-5.0.1/ppc64.c.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/ppc64.c 2010-03-04 07:20:43.000000000 -0600
@@ -2215,7 +2215,7 @@ ppc64_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
diff -up crash-5.0.1/ppc.c.orig crash-5.0.1/ppc.c
--- crash-5.0.1/ppc.c.orig 2010-03-04 07:20:14.000000000 -0600
+++ crash-5.0.1/ppc.c 2010-03-04 07:20:43.000000000 -0600
@@ -1355,7 +1355,7 @@ ppc_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
diff -up crash-5.0.1/s390.c.orig crash-5.0.1/s390.c
--- crash-5.0.1/s390.c.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/s390.c 2010-03-04 07:20:43.000000000 -0600
@@ -1032,7 +1032,7 @@ s390_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
diff -up crash-5.0.1/s390x.c.orig crash-5.0.1/s390x.c
--- crash-5.0.1/s390x.c.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/s390x.c 2010-03-04 07:20:43.000000000 -0600
@@ -1284,7 +1284,7 @@ s390x_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
diff -up crash-5.0.1/x86_64.c.orig crash-5.0.1/x86_64.c
--- crash-5.0.1/x86_64.c.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/x86_64.c 2010-03-04 07:20:43.000000000 -0600
@@ -4412,7 +4412,7 @@ x86_64_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
diff -up crash-5.0.1/x86.c.orig crash-5.0.1/x86.c
--- crash-5.0.1/x86.c.orig 2010-02-17 15:21:24.000000000 -0600
+++ crash-5.0.1/x86.c 2010-03-04 07:20:43.000000000 -0600
@@ -3950,7 +3950,7 @@ x86_display_machine_stats(void)
fprintf(fp, " MACHINE TYPE: %s\n", uts->machine);
fprintf(fp, " MEMORY SIZE: %s\n", get_memory_size(buf));
- fprintf(fp, " CPUS: %d\n", kt->cpus);
+ fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
fprintf(fp, " PROCESSOR SPEED: ");
if ((mhz = machdep->processor_speed()))
fprintf(fp, "%ld Mhz\n", mhz);
14 years, 9 months
How to read from a vmcore dump ala /dev/kmem
by John Groves
I'm debugging a new driver module using kdump and crash, which is great.
However, I need to extract a large binary trace buffer for analysis by a
project-specific program. The buffer contains trace entries, most of which
contain pointers to strings and other stuff outside the trace buffer. So my
trace analyzer needs to get the big buffer, and than read other virtual
addresses referenced by the big buffer.
On live kernels, my trace module facilitates grabbing the necessary memory
via ioctls in my trace module (In 2.4 I used /dev/kmem, but that stopped
working in early 2.6, and I don't know the current state since the current
approach works fine). I need a way to do the same thing from a vmcore file.
Clearly the answer is in the crash program source code, but I'm wondering if
there is a "libcrash" or "libvmcore" or some such that might save me some
time in that area.
Thanks for any suggestions,
John Groves
14 years, 9 months
[PATCH] sial: Oops drilldowntype for bool
by Michael Holzheu
Hi Luc,
I have a sial script that uses structures that contain members of type
"bool". When I run the script I get:
File ../devices.sial, line 279, Error: Oops drilldowntype
I looked into the sial code and found that the drilldowntype() functions
fails because no "case TYPE_CODE_BOOL" is defined.
Here the break point at sial.c (323):
default:.
sial_error("Oops drilldowntype");
Breakpoint 1, drilldowntype (type=0x81f088a8, t=0x808023e8) at
sial.c:323
323 sial_error("Oops drilldowntype");
(gdb) print *type
$1 = {pointer_type = 0x0, reference_type = 0x0, chain = 0x81f088a8,
instance_flags = 0, length = 1, main_type = 0x81f088d0}
(gdb) print *type->main_type
$2 = {code = TYPE_CODE_BOOL, flag_unsigned = 1, flag_nosign = 0,
flag_stub = 0, flag_target_stub = 0, flag_static = 0, flag_prototyped
= 0,
flag_incomplete = 0, flag_varargs = 0, flag_vector = 0,
flag_stub_supported = 0, flag_nottext = 0, flag_fixed_instance = 0,
flag_objfile_owned = 1, nfields = 0, vptr_fieldno = -1,
name = 0x200040d8257 "_Bool", tag_name = 0x0, owner = {objfile =
0x80618e10,
gdbarch = 0x80618e10}, target_type = 0x0, fields = 0x0,
vptr_basetype = 0x0, type_specific = {cplus_stuff = 0x0, floatformat =
0x0,
calling_convention = 0}}
When I add "case TYPE_CODE_BOOL" and handle it like "case TYPE_CODE_INT"
my script works, but I am not sure if that fix is correct.
What do you think?
Michael
---
extensions/sial.c | 1 +
1 file changed, 1 insertion(+)
--- a/extensions/sial.c
+++ b/extensions/sial.c
@@ -286,6 +286,7 @@ int nidx=0;
type=TYPE_TARGET_TYPE(type);
break;
+ case TYPE_CODE_BOOL:
case TYPE_CODE_INT:
sial_parsetype(tstr=TYPE_NAME(type), t, 0);
14 years, 9 months
