Cisco Cisco UCS B440 M1 High-Performance Blade Server トラブルシューティングガイド

ページ / 3
              You can check for cores dump files  via CLI or GUI
                   
                   
                   UCS-FI /monitoring/sysdebug # show cores detail
      If the FI has been configured to export logs to syslog server, please gather log messages
from syslog server for the device that provides 7 days of history prior to reboot timestamp. 
     Kernel stack trace ( If reboot  is due to kernel panic )
                   
Analyzing logs for initial clues
1)  Check for reboot reason and time stamp from Nexus Operating System (NX-OS)  " show
version
 " command output
  
2)  Check " show logging nvram " command output for log messages prior to reboot time stamp
3)  Check log messages stored on syslog server for additional clues
4)  If reboot was triggered by user space process crash, check core dump that matches process
name and reboot time stamp.
6) If it is kernel panic, check for kernel stack trace output in file named " sw_kernel_trace_log " 
From UCSM 2.2.1b, this file is included UCSM show techsupport bundle.
                       
For UCSM version earlier than 2.2.1b, please collect output of following commands 
7) " topout.log " contains output of " top " command every two seconds. Before reboot, UCSM
saves old set of logs as /opt/sam_logs.tgz file It can provide information about memory, utilization
or processes. 
8) If you notice messages like Out of Memory ( OOM )  killed a process and the process crash
could trigger reboot of FI and would be isted as reset reason.In such scenarios, it is most likely the
process is victim of low memory condition and might not be the cause behind crash or memory
leak. 
Gather information about UCS setup
Answering following questions helps to better understand the system setup and it's state prior to reboot.
1)  Has this problem happened before ?