Re: [Crash-utility] can't get hba info
----- "Mike Miller (OS Dev)" <Mike.Miller(a)hp.com> wrote:
Hello,
I'm trying to debug an issue using crash. I've moved the vmcore file
over to a system other than the system from which the dump was
collected. I've installed a variety of debug rpms including the
kernel-debuginfo, kernel-debug-debuginfo, glib-debuginfo, and
kernel-debuginfo-common. I've also copied the lib/modules from the
test system to mine.
When I run the command "p hba" it returns:
Crash > p hba
Hba = $2 = 778764288 (please ignore the uppercase, stupid mail client)
I expect to see something like:
Hba = $1 = {0x102170b0000, 0x0, 0x0,..., 0x0}
Why is that?
I'm not sure without more info...
Do I need to be running crash on the test system itself?
No.
I thought all relevant info would be contained in the vmcore file
and
I could attempt the analysis on any system?.
True.
(although if the debuginfo data you need is not contained in the vmlinux file,
you may need to load debuginfo data from the relevant module's debuginfo data.)
Anyway, I wonder if your kernel has another "hba" symbol that's being
selected by the embedded gdb module?
The only sample vmlinux/vmcore I have on hand that knows about an "hba"
symbol is this one:
crash> whatis hba
ctlr_info_t *hba[32];
crash>
But I see that that kernel has two of them, so they must be statically defined:
crash> sym hba
ffffffff82700620 (b) hba
ffffffff82700aa0 (b) hba
crash>
When I run the command, the embedded gdb module picks the second one
at ffffffff82700aa0:
crash> p hba
hba = $4 =
{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0}
crash> p &hba
$11 = (ctlr_info_t *(*)[32]) 0xffffffff82700aa0
crash>
So if I want to look at the first one at ffffffff82700620, I'd do this:
crash> p *(ctlr_info_t *(*)[32]) 0xffffffff82700620
$14 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0}
crash>
But since your example is displaying hba as "778764288", perhaps it's
using a different "hba" instance that's something different? So enter
this:
crash> whatis hba
And confirm whether it's the data structure instance you're referring to.
And if it's some other hba, then do this to get the possible addresses:
crash> sym hba
And using casting on the relevant address to create the output you want
(like I did above to access the ctlr_info_t array at the other address).
Also, if the the data structure definition is in a module code, (i.e.,
not declared in a kernel header), then that module's debuginfo data would
needs to be loaded with the "mod" command.
The crash version command returns version = $3 = v0.25941.
Huh? (Sorry -- I don't know what you're talking about...)
My running kernel is 2.6.18-prep. /etc/issue reports rhel5.5.
The kernel on the test system is 2.6.18-164.el5. That is also the
version of the debug packages I installed as well as the vmlinux file
I'm using. Any problems mixing and matching like that? I have not
rebooted my system since installing the debug packages but that
doesn't seem necessary. Thanks in advance.
If you install the complete kernel-debuginfo/kernel-debuginfo-common
package pair that goes along with the vmlinux/vmcore pair that you're
working with, then there should be no problem loading all module
debuginfo data by just entering "mod -S".
The kernel-debug-debuginfo package is for the "debug" kernel, which
is a completely separate kernel from the base 2.6.18-164.el5 kernel.
The glib-debuginfo package is also unnecessary...
Hope this helps,
Dave