崩潰的HP-UX系統在調換空間中保存RAM的瞬間映像，重新啟動。然後從調換空間拷貝轉儲映像到/var/adm/crash 中。按照這個步驟，針對您的O/S版本來處理調換映像，然後將該文檔結尾處需要的文件用電子郵件發送到HP回復中心以供分析。 =============第一步 轉儲映
崩潰的HP-UX系統在調換空間中保存RAM的瞬間映像，重新啟動。然後從調換空間拷貝轉儲映像到/var/adm/crash 中。按照這個步驟，針對您的O/S版本來處理調換映像，然後將該文檔結尾處需要的文件用電子郵件發送到HP回復中心以供分析。
=============第一步 轉儲映像在哪？ ==============================
轉儲映像被保存到下面這行所提示的目錄中:
/etc/rc.config.d/savecore (10.X):
SAVECORE_DIR=/var/adm/crash (缺省目標)
或 /etc/rc.config.d/savecrash (11.00)
SAVECRASH_DIR=/var/adm/crash
注意：如果你想控制以後的轉儲映像到一個更大的文件系統，為他們創建一個新目錄，並更新SAVECORE_DIR變量。
現在，確保你有一個轉儲映像以供分析：
# ll /var/adm/crash/c* (or your dump directory)
在10.X上, 您將看到:
/var/adm/crash/core.0/INDEX
/var/adm/crash/core.0/vmunix.gz
/var/adm/crash/core.0/core.0.1.gz
/var/adm/crash/core.0/core.0.2.gz
^ suffix increments on su
clearcase/" target="_blank" >ccessive dumps
在11.00上, 您將看到:
/var/adm/crash/crash.1/INDEX
/var/adm/crash/crash.1/image.1.1.gz
/var/adm/crash/crash.1/image.1.2.gz
/var/adm/crash/crash.1/image.1.3.gz
/var/adm/crash/crash.1/vmunix.gz
^ suffix increments on successive dumps
INDEX 文件和/etc/shu
tdownlog 包含"panic"語句，如果沒有，請`touch /etc/shutdownlog` .
如果系統轉儲沒有在預想的位置，請試著使用下面的方法重新保存轉儲:
10.X # savecore -vr
11.00 # savecrash -vr
在兩種情況下, "invalid dump header" 都是指轉儲映像已經沒了.
=============第二步 是否安裝了Q4的某個版本？ ======================
有兩個版本的Q4，大多數系統上運行的標准版本並不足以分析有關掛起的轉儲映像問題。Q4的現行的版本（這是一個當安裝時並不重新啟動系統的補丁程序）可以適用於由於系統掛起造成的系統轉儲映像崩潰的情況。要確定安裝了Q4的哪個版本:
# swlist -l fileset | grep -i Q4
您會看到下面的反應之一：
OS-Core.Q4 B.10.20 HP-UX Crash Dump De
bugger for PA-RISC systems
或者
OS-Core.Q4 B.11.00 HP-UX Crash Dump Debugger for PA-RISC systems
(給定O/S的標准版本)
可能會出現一個補丁程序的版本:
PHCO_20261.PHCO_20261 B.10.00.00.AA q4 patch version A.11.10c (10.20)
或者
PHCO_20262.Q4 1.0 OS-Core.Q4 (11.00)
(在第三步之前會出現一個補丁程序的版本)
如果您的系統沒有顯示Q4的補丁程序的版本，而且轉儲是由於掛起造成的，請安裝一個版本的補丁程序。
---------------------------------------------------------
如果您沒有任何版本的Q4,請安裝它的補丁程序。在補丁中有它的安裝指示.您可以從下面的站點中
下載合適的版本:
ftp://i3107ffs.external.hp.com/hp-ux_patches/s700_800/___ (select 10.X or 11.X)
Retrieve PHCO_20262 for 11.0, PHCO_20261 for 10.10 or 10.20
(注意：補丁程序號會在一段時間後被替換)
如果您上網不方便，但是您有安裝光盤，您可以安裝q4的標准版本:
安裝INSTALL media 並確保您能夠安裝 Q4:
# swlist -l fileset -s / | grep Q4
OS-Core.Q4 B.10.10 HP-UX Crash Dump Debugger for PA-RISC systems
^^^^^-This should match OS release.
使用 swinstall 來安裝它:
# swinstall -vs / OS-Core.Q4
============= 第三步 ===== 進入轉儲目錄 =======================
注意: 在Q4中，csh (c-shell) 會引起錯誤.請使用ksh.
# cd (這很重要!)
例如: cd /var/adm/crash/core.0 OR /var/adm/crash/crash.0
============= 第四步 ===== 對於沒有補丁的 Q4 ==============================
如果您的Q4版本由補丁程序，請直接進行第五步.
注意: 對於 10.20, 10.30 或 11.00 DUMPS, 跳到步驟4.5執行這些命令：
4.1) # uncompress /usr/contrib/lib/Q4Lib.tar.Z
(ignore the error if this was done previously)
4.2) # tar -xf /usr/contrib/lib/Q4Lib.tar
(output goes into your current directory)
4.3) # cp q4lib/sample.q4rc.pl ~/q4rc.pl.
^ ^
Note tilde (^) and letter (el) -not digit 1
4.4) # /usr/contrib/bin/gunzip vmunix.gz
(uncompresses the kernel file)
4.5) 對於 10.10版本的O/S, 輸入:
# /usr/contrib/bin/q4pxdb vmunix
(this may complain if vmunix is a
lready preprocessed)
對於10.20 或 10.30 或 11.00版本的O/S, 輸入:
# /usr/contrib/bin/q4prep -p
4.6) 如果在這些命令中，您遇到了下列信息: "/var: file system full"
... move the core. directory to a file system with adequate
(approx. 2x the sum of the core.x.y.gz files) space and start at
this point again.
繼續輸入命令:
# q4 -p .
\_注意這裡的 "."
4.7) 在 q4> 提示符下，輸入: trace event 0 > trace
4.8) 在 q4> 提示符下，輸入: include analyze.pl
NOTE letter "el"_/
4.9) 在 q4> 提示符下，輸入: run Analyze AU >> ana.out
注意： ctrl-c 將會中止 q4
4.10) 在下面的提示符下，輸入: exit
跳到第六步
============= 第五步 ===== 如果您使用的是有補丁的Q4==============
如果您懷疑dump 不是由ServiceGuard (如果裝載了)引起的,請跳到5.2
5.1) # nm -xv /usr/lbin/cmcld | grep cl_log_cache
記錄hex號以便5.5使用:
例如:
cl_log_cache |0x4007a6b8|extern|data |$BSS$
^^^^^^^^^^
5.2)按照下面進行輸入:
# . /usr/contrib/Q4/bin/set_env
\___ 注意該行開始的'.'
5.3) 如果在下面的命令中,您遇到信息:
"/var: file system full"
將core. 或or crash. 目錄移動到有足夠可用空間的文件系統中,並從這裡開始執行.
(足夠是指大約c*x.y.gz.文件的2倍)
輸入:
# /usr/contrib/Q4/bin/q4pxdb vmunix 不要管 “unneccessary" 信息）
# /usr/contrib/Q4/bin/q4 -p
5.4)注意: ctrl-c可以中下面的兩個命令.
在q4>提示符下輸入: run Analyze AU > ana.out
(執行這步可能需要幾分鐘)
在q4>提示符下輸入: run WhatHappened -HANG > what.out
(執行這步可能需要幾分鐘)
5.5) 如果您懷疑dump 是由ServiceGuard引起的,:
在q4>提示符下輸入 include cmcld.pl
對於SG A.10.10 版本和上面的:
q4> run PrintCmcldLog
> cmcld.log
對於SG 比A.10.10早的版本:
q4> run PrintCmcldLogOLD
> cmcld.log
5.6) 在q4>提示符下輸入 exit
============= 第六步===== 收集和發送數據 ===========================
檢查是否硬件問題引起了系統崩潰
在提示符下輸入
# grep HPMC ana.out
如果您看到了下面的信息之一,那麼處理器檢測到了系統錯誤.如果有/var/tombstones 存在，最近的文件 (ts99)會有於崩潰事件對應的硬件錯誤代碼數據戳.對於您的CE. Log硬件調用解決崩潰原因很有用.
"crash event was an HPMC"
或
"Crash Event 0 (HPMC, struct crash_event_table_struct..."
生成補丁列表:
對於10.X
# /usr/sbin/swlist -l product | grep PH >patch_list
對於 11.X
# /usr/sbin/swlist -l patch -a patch_state PH\* | grep -e applied -e \
committed > patch_list
使用回復中心的SOFTWARE CASE ID作為主題(這很重要!),
將補丁列表, ana.out, /etc/shutdownlog,what.out (如果創建了)cmcld.log (如果創建了), "trace" 文件和/var/adm/ts99 (如果檢測了HPMC) 發送到:
[email protected] 注意:
- hpcu 具有最大3MB的郵箱大小
- 以後，您可能希望在使用回復中心的解答之前通過執行這些步驟快速解決問題.
那麼將這些文件以新賦予的callID作為主題發送給我們.
- 如果系統只是ServiceGuard 的一部分,而您認為ServiceGuard 可能會引起系統重新啟動,閱讀電子支持中心技術
數據庫中的這篇文章,來得到更詳細的信息: UXSGLVKBAN00000010
*** END ***
文件名: /CSCinfo/9000/SWinfo/DownSystems/Dumps/using_q4
最後一次修改時間:
Fri Dec 31 08:55:01 EST 1999
ALT KEYWORDS
