Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

examine the vmcore.x in offline mode

Status
Not open for further replies.

MoshiachNow

IS-IT--Management
Feb 6, 2002
1,851
0
0
IL
HI,

I'd like to examine the vmcore.x in offline mode - without going interactively into kdb.(I need to establish the reason for the last system dump)

Is there a way to do it ?

Long live king Moshiach !
 
hello,

oups I don't have the kdb manpage under the eyes, but provided you have the /unix file of the faulting system, you can examine offline any vmcore file by specifying it on the kdb command line (there's a -f or equivalent option).

regards,
 
Thanks,I'll explain better:

I am connecting to the target machine with the core file.
However I'd like to get the info from running something like kdb ,but from the script,not interactively,and log the output into some file.

Thanks

Long live king Moshiach !
 
You mean other than calling IBM and opening a PMR and sending them a snap -Dc outputfile and having the dump checked there?

Not that I'm aware of.

The reason for the dump should be in the error log...


HTH,

p5wizard
 
Not always true.
It happened too often to me to fail to find the reason for the dump just by looking at errpt,but having to kdb the vmcore.x file.
There I have managed to find issues with bad FS (nneeding fsck),or a bad driver that our R&D have developed for some board,that would crash the system.
Therefor I have written the below FAQ:


Now I need to do it more automatically,from the script.
(I have gave up sending dumps to IBM 6 years ago ...for different reasons)

Long live king Moshiach !
 
Seems like I did solve the issue,using the "answer" file:

answer file called "ANSWER" :

==========================
stat


status 0
thread -r
q
==========================

Then run kdb as following :

kdb vmcore.3 < ANSWER >LOGFILE

The contents of the LOGFILE:


vmcore.0 mapped from @ 70000000 to @ 78280400
Preserving 991678 bytes of symbol table
First symbol __mulh
Component Names:
1) dmp_minimal [5 entries]
2) proc [423 entries]
3) thrd [1898 entries]
4) ldr [2 entries]
5) errlg [3 entries]
6) bos [7 entries]
7) ipc [7 entries]
8) vmm [21 entries]
9) rtastrc [8 entries]
10) sscsidd [2 entries]
11) aixpcm [3 entries]
12) scdisk [8 entries]
13) lvm [2 entries]
14) netstat [10 entries]
15) phxent_dd [5 entries]
16) kbddd [2 entries]
17) mousedd [2 entries]
Component Dump Table has 2408 entries
START END <name>
0000000000003500 00000000018B4EC8 _system_configuration+000020
000000002FF3B400 000000002FF80A98 __ublock+000000
000000002FF22FF4 000000002FF22FF8 environ+000000
000000002FF22FF8 000000002FF22FFC errno+000000
00000000E0000000 00000000F0000000 lkwseg+10000000
PFT:
id....................000A
raddr.....0000000004000000 eaddr.....0000000004000000
size..............00000000 align.............00000000
valid..1 ros....0 holes..0 fixlmb.0 seg....1 wimg...2

PVT:
id....................0008
raddr.....0000000000800000 eaddr.....0000000000800000
size..............00000000 align.............00000000
valid..1 ros....0 holes..0 fixlmb.1 seg....1 wimg...2
Dump analysis on CHRP_UP_PCI POWER_PC POWER_630 machine with 1 available CPU(s) (64-bit registers)
Processing symbol table...
.......................done
(0)> stat
SYSTEM_CONFIGURATION:
CHRP_UP_PCI POWER_PC POWER_630 machine with 1 available CPU(s) (64-bit registers)

SYSTEM STATUS:
sysname... AIX
nodename.. v5
release... 2
version... 5
machine... 000D68FC4C00
nid....... 0D68FC4C
time of crash: Thu Dec 2 04:21:26 2004
age of system: 9 day, 3 hr., 17 min., 29 sec.
xmalloc debug: disabled

CRASH INFORMATION:
CPU 0 CSA 2FF3B400 at time of crash, error code for LEDs: 70000000
pvthread+00BC00 STACK:
WARNING: bad IAR: 00000000, display stack from LR: 000E0C0C
[000E0C0C]rtalloc1_nolock_gr+00008C (2FF3AE1C, 00000000, 00000000, 00000000,
00000000 [??])
[000F9984]rtalloc_nolock_gr+000060 (??, ??, ??, ??)
[000F9AE8]rtalloc_gr+000064 (??, ??, ??, ??)
[0561D0F0]ip_output_post_fw+00050C (00000000, 700C6300, 2FF3AEF8)
[0561E224]ip_output+0000BC (??, ??, ??, ??, ??, ??)
[05618F00]igmp_sendpkt+00019C (??, ??)
[056159E0]in_delmulti+000084 (??)
[0561A308]ip_freemoptions+000074 (??)
[0563B664]in_pcbdetach+000098 (??)
[05659250]udp_usrreq+0001BC (??, ??, ??, ??, ??)
[0010D6FC]soclose2+0002A8 (??, ??)
[00113AE8]soclose+000010 (??)
[001139B4]soo_close+0000B4 (??)
[00371D70]closef+000060 (??)
[003170C8]closefd+0000C8 (??, ??)
[00396264]fs_exit+000080 ()
[00099BB0]kexitx+0004DC (??)
[00034984]kexit+000048 ()
(0)>
(0)>
(0)> status 0
CPU TID TSLOT PID PSLOT PROC_NAME
(0)> thread -r
SLOT NAME STATE TID PRI RQ CPUID CL WCHAN

pvthread+000100 2>wait RUN 000205 0FF 0 00000 0
pvthread+002900 82>splr_cog RUN 0052AF 03C 0 00000 0
pvthread+004880 145>java RUN 009199 03C 0 00000 0
pvthread+005880 177>Versioni RUN 00B191 03C 0 00000 0
pvthread+005B80 183>HFsd RUN 00B771 03C 0 00000 0
pvthread+006400 200>java RUN 00C895 03C 0 00000 0
pvthread+006700 206>java RUN 00CEA3 03C 0 00000 0
pvthread+006A80 213>rmiregis RUN 00D5BB 03C 0 00000 0
pvthread+006B80 215>java RUN 00D7B1 03C 0 00000 0
pvthread+006D00 218>java RUN 00DAB5 03C 0 00000 0
pvthread+009200 292>java RUN 012449 044 0 00000 0
pvthread+00AF80 351>java RUN 015FBF 03C 0 00000 0
pvthread+00B380 359>java RUN 0167CF 03C 0 00000 0
pvthread+00BC00 376*LocatorS RUN 0178F3 03C 0 00000 0
pvthread+00D980 435>java RUN 01B3A5 03C 0 00000 0
pvthread+00E400 456>java RUN 01C811 03C 0 00000 0
pvthread+00FA80 501>java RUN 01F503 03D 0 00000 0
(0)> q
#



Long live king Moshiach !
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top