| Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback |
| Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
||
 |
||||||||||||||||||||
Solution Type Troubleshooting Sure Solution 2054127.1 : SPARC M10-1/ M10-4 / M10-4S is inaccessible via network due to POST failure. Serial port connection required for root cause investigation.
In this Document
Applies to:Fujitsu M10-4 - Version All Versions to All Versions [Release All Releases]Fujitsu M10-4S - Version All Versions to All Versions [Release All Releases] Fujitsu M10-1 - Version All Versions to All Versions [Release All Releases] Information in this document applies to any platform. PurposeThis document is to assist in troubleshooting M10-1/M10-4/M10-4S HW POST failures and determining the correct action to resolve the issue. In many instances the initial replacement did not resolve the issue. Troubleshooting StepsSymptoms: The XSCFU is not accessible via network and from the serial port connection POST failures are seen. If the XSCF fails post when the network is not configured. Reset button on XSCFU does not resolve issue. You will need to connect a console to serial port and power on the system. The console should start to display POST messages. Prior to this document being released, the usual action plan had been to replace the CMUL(*MBU) as this is where the XSCFU is located. Part of the action plan for replacing the CMUL(*MBU) is to retain the old microSD card which contains pdom configuration information. In the below scenarios, the microSD may need to be replaced along with the CMUL(*MBU). If the microSD is bad, replacing just the CMUL(*MBU) and swapping will not resolve the issue. *MBU = The M10-1 only has a MBU and does not contain CMUU/CMUL. 1. ##REPLACE MICROSD AND CMUL(*MBU)##This sections has 4 examples on with you need to replace the MICROSD and CMUL(*MBU). Example #1. XSCF cannot be booted up with the mount fail message "Flattened Device Tree blob at 00c00000" --- Booting using the fdt blob at 0xc00000 Setting hostname localhost: Checking filesystems Mounting local filesystems: mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p4, <== We can identify it by this message. Example #2. XSCF cannot be booted up by AC-ON with the following message. "ERROR: can't get kernel image!"
--- Welcome to System Control Facility Module Version 2051 Copyright (c) 2011-2012 FUJITSU LIMITED, All Rights Reserved. Diagnostics : 1.CPU Register Test >> OK 2.L2 Cache Test >> OK 3.RTC Low Battery Test >> OK 4.SDRAM Test >> OK 5.RTC Operation Test >> OK 6.SPI-FMEM Test >> OK block read failed: -18 Booting : [06/06] ** Bad partition 1 ** ** Bad partition 1 ** ** Bad partition 1 ** Wrong Image Format for bootm command ERROR: can't get kernel image! <== We can identify it by this message. Hit any key to stop autoboot: 10 9 8 7 6 5 4 3 2 1 0 ** Bad partition 1 ** ** Bad partition 1 ** ** Bad partition 1 ** Wrong Image Format for bootm command ERROR: can't get kernel image! => Example #3. XSCF cannot be booted up with the following message, and cannot be recovered by AC-OFF and ON. "REBOOT: COUNTER ERROR (... counter=4 ...)"
--- -- complete stop (spinit) mainte_dbcopy.sh -- complete tracerotate.sh -- complete init -- complete init: console main process (1995) killed by TERM signal -- process stoped (spinit) Stopping lighttpd: [ OK ] Stopping sshd: [ OK ] Sending all processes the TERM signal... [ OK ] Sending all processes the KILL signal... [ OK ] Saving random seed: [ OK ] Sync file systems Unmounting file systems: [ OK ] mount: /dev/shm [70386.124591] ff72e000: 00000000 00010000 00000000 00000000 [70386.190273] ff72e010: 00000000 00000000 00000000 00000000 [70386.255949] ff72e020: 00000000 ff8d00f8 00000020 00008008 [70386.321636] ff72e030: 00000000 007f0003 007f0003 00000000 [70386.387312] ff72e040: 05f30000 10101010 00000000 00000000 [70386.453803] Starting new kernel setup_arch: bootmem mpc85xx_rdb_setup_arch() arch: exit [70351.725312] ===== DEBUG ===== [70351.760036] FMEM bank/reset : 0000 [70351.805597] timeout control : 004f [70351.851380] ================= 1.FMEM(NAND) Test >> OK Booting : [1/1] REBOOT: COUNTER ERROR (reason=0x00 counter=4 threshold=3 bupmem_counter=0 factor=0000004 <== We can identify it by this "counter=4" message. Example #4. XSCF cannot be booted up by FMEM test error. Welcome to System Control Facility Module Version 2043
Copyright (c) 2011-2012 FUJITSU LIMITED, All Rights Reserved. Diagnostics : 1.CPU Register Test >> OK 2.L2 Cache Test >> OK 3.RTC Low Battery Test >> OK 4.SDRAM Test >> OK 5.RTC Operation Test >> OK 6.SPI-FMEM Test >> OK Booting : [06/06] Factory mode is detected Hit any key to stop autoboot: 0 Loading file "/boot1/uImage" from mmc device 0:1 (xxa1) 2617018 bytes read Loading file "/boot1/initramfs_image" from mmc device 0:1 (xxa1) 3004335 bytes read Loading file "/boot1/p1011scf.dtb" from mmc device 0:1 (xxa1) 8192 bytes read ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-2.6.36.2 Created: 2015-04-02 1:55:40 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 2616954 Bytes = 2.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 02000000 ... Image Name: Initial ramdisk for Service Proc Created: 2015-03-05 0:58:34 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 3004271 Bytes = 2.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00c00000 Booting using the fdt blob at 0xc00000 Uncompressing Kernel Image ... OK Loading Ramdisk to 17b7f000, end 17e5c76f ... OK Loading Device Tree to 00ffb000, end 00ffffff ... OK setup_arch: bootmem mpc85xx_rdb_setup_arch() arch: exit [ 0.412211] ===== DEBUG ===== [ 0.446806] FMEM bank/reset : a080 [ 0.492554] timeout control : 000f [ 0.538281] ================= 7.FMEM(NAND) Test >> Error 2015-05-18 06:58:08 NAND (ErrorCode:15070388) <== We can identify it by this message. Diag: NAND FMEM Fsck Error <Result:00000008> 179 1 35712 mmcblk0p1 179 2 450368 mmcblk0p2 179 3 450368 mmcblk0p3 179 4 1057472 mmcblk0p4 e2fsck 1.41.10 (10-Feb-2009) : : 2. ##REPLACE CMUL(*MBU) ONLY##This section show a case where it is not the MICROSD failing ,but just the XSCF, only CMUL(*MBU) replacement is required. Example #5. XSCF cannot be booted up with the following message. "RAMDISK DB is blank"
--- Welcome to System Control Facility Module Version 2210 Copyright (c) 2011-2012 FUJITSU LIMITED, All Rights Reserved. Diagnostics : Loading file "/boot0/uImage" from mmc device 0:1 (xxa1) 2590443 bytes read Loading file "/boot0/initramfs_image" from mmc device 0:1 (xxa1) 3007058 bytes read Loading file "/boot0/p1011scf.dtb" from mmc device 0:1 (xxa1) 8192 bytes read ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-2.6.36.2 Created: 2014-02-20 1:45:29 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 2590379 Bytes = 2.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 02000000 ... Image Name: Initial ramdisk for Service Proc Created: 2014-02-20 1:46:06 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 3006994 Bytes = 2.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00c00000 Booting using the fdt blob at 0xc00000 Uncompressing Kernel Image ... OK Loading Ramdisk to 17b7e000, end 17e5c212 ... OK Loading Device Tree to 00ffb000, end 00ffffff ... OK setup_arch: bootmem mpc85xx_rdb_setup_arch() arch: exit [ 0.409120] ===== DEBUG ===== [ 0.443710] FMEM bank/reset : 0020 [ 0.489435] timeout control : 000f [ 0.535194] ================= 2.FMEM(NAND) Test >> OK Booting : [2/2] Starting udev: [ OK ] Setting hostname localhost: [ OK ] Checking filesystems Checking all file systems. [ OK ] Mounting local filesystems: [ OK ] Enabling /etc/fstab swaps: [ OK ] Entering non-interactive startup SP-FIRM start ERROR: RAMDISK DB is blank. <== We can identify it by this message. ERROR: SCF is going down. mount_phram.sh -- complete [ 57.167846] ff72e000: 00000000 00010000 00000000 00000000 [ 57.233532] ff72e010: 00000000 00000000 00000000 00000000 [ 57.299238] ff72e020: 00000000 ff8d00f8 00000320 00008008 [ 57.463964] ff72e030: 00000000 007f0003 007f0003 00000000 [ 57.529638] ff72e040: 05f30000 10101010 00000000 00000000 [ 57.595866] Starting new kernel setup_arch: bootmem mpc85xx_rdb_setup_arch() arch: exit [ 0.159023] ===== DEBUG ===== [ 0.193600] FMEM bank/reset : 0020 [ 0.239300] timeout control : 000f [ 0.285092] ================= 1.FMEM(NAND) Test >> OK Booting : [1/1] REBOOT: BOARD ERROR <== We can identify it by this message. (reason=0x03 counter=0 threshold=3 bupmem_counter=0) 3. ##REPLACE PSUBP##The XSCFU data is backed up to memory located on the PSUBP called the "USB-SSD". [ 1030.951893] ===== DEBUG ===== init: rc3 main process (1375) killed by TERM sig setup_arch: bootmem The above error is detected while testing the USB-SSD so this is a problem on the PSUBP. mount: /dev/shm [ 1363.323978] ff72e000: 00000000 00010000 00000000 00000000 [ 1288.649928] ===== DEBUG ===== (reason=0x00 counter=0 threshold=3 bupmem_counter=4 factor=a000004f) In the above example the XSCFU has failed to boot 4 times due to errors on the System backup memory ( USB-SSD ).
Solution: Depending on the above POST failures either the microSD/CMUL(*MBU) or the CMUL(*MBU) only should be replaced. Under normal circumstances when a CMUL(*MBU) is replaced, the microSD is retained from the old CMUL(*MBU) and moved to the new CMUL(*MBU). Attachments This solution has no attachment |
||||||||||||||||||||
|
||||||||||||||||||||