The post provides a description of forcing a crash dump on T1000/T2000 servers from ALOM. Typically, when a system hang occurs, it is required to collect a crash dump. In such case, the ALOM break command is the command to drop the system to OBP (ok prompt), which then allows user to run “ok> sync” to save crash dump. However, if “break” command can’t drop the system to ok prompt, the ‘-D’ option of the command may allow the user to get a coredump directly. This is new option is introduced with system firmware 6.3.0 or later and also requires Solaris [TM] 10 Kernel Update 118833-24 or later.
Options for the ‘break’ command:
-D: Forces a panic coredump of the managed system OS (not supported by all OS versions). -y: Instructs ALOM CMT to proceed without first asking the confirmation question: Are you sure you want to send a break to the system [y/n]? -c: Instructs ALOM CMT to connect to the system console after performing the operation.
Example:
sc> break -Dyc SC Alert: SC Request to Dump core host. Enter #. to return to ALOM. 100% done: 53847 pages dumped, compression ratio 5.54, dump succeeded rebooting...
You will see the following panic message and FMA MSG-ID: SUNOS-8000-0G when the command is executed.
Feb 8 17:35:27 eslab63 unix: [ID 760255 kern.warning] WARNING: Panic - Error Descriptor 0x5 invalid in non-resumable error handler Feb 8 17:35:27 eslab63 genunix: [ID 843051 kern.info] NOTICE: SUNW-MSG-ID: SUNOS-8000-0G, TYPE: Error, VER: 1, SEVERITY: Major Feb 8 17:35:29 eslab63 unix: [ID 836849 kern.notice] Feb 8 17:35:29 eslab63 panic[cpu0]/thread=2a10001fcc0: Feb 8 17:35:29 eslab63 unix: [ID 400509 kern.notice] Unrecoverable hardware error Feb 8 17:35:29 eslab63 unix: [ID 100000 kern.notice] Feb 8 17:35:29 eslab63 genunix: [ID 723222 kern.notice] 000002a10001f6e0 unix:process_nonresumable_error+224 (2a10001f8d0, 0, 107c000, 40, 0, 5)Feb 8 17:35:30 eslab63 genunix: [ID 179002 kern.notice] %l0-3: 0000000000000040 0000000003000000 0000000000000001 0000000000000000 Feb 8 17:35:30 eslab63 %l4-7: 000000000180c5c0 0000000100000000 00000000ffffffff 0000000000000001 Feb 8 17:35:30 eslab63 genunix: [ID 723222 kern.notice] 000002a10001f820 unix:ktl0+64 (0, 0, d77e, ffffffffffffffff, 0, 12) Feb 8 17:35:30 eslab63 genunix: [ID 179002 kern.notice] %l0-3: 000000000180c000 0000000000000000 0000000000001406 0000000001023534 Feb 8 17:35:30 eslab63 %l4-7: 0000000000000000 0000000000000000 0000000000000000 000002a10001f8d0 Feb 8 17:35:31 eslab63 genunix: [ID 723222 kern.notice] 000002a10001f970 unix:cpu_halt+b8 (0, 0, 300013c8000, 16, 180c000, 1) Feb 8 17:35:31 eslab63 genunix: [ID 179002 kern.notice] %l0-3: 000000000184ca08 0000000000000001 0000000000000002 0000000000000000 Feb 8 17:35:31 eslab63 %l4-7: 0000000000000000 0000000000000000 0000000000000000 000000000103af04 Feb 8 17:35:31 eslab63 genunix: [ID 723222 kern.notice] 000002a10001fa20 unix:idle+128 (1819c00, 10, 180c000, ffffffffffffffff, 1, 1818800) Feb 8 17:35:32 eslab63 genunix: [ID 179002 kern.notice] %l0-3: 0000000001846420 000000000000001b 0000000000000000 ffffffffffffffff Feb 8 17:35:32 eslab63 %l4-7: 0000000000000000 0000000000000000 0000000000000000 000000000103af04 Feb 8 17:35:32 eslab63 unix: [ID 100000 kern.notice] Feb 8 17:35:32 eslab63 genunix: [ID 672855 kern.notice] syncing file systems... Feb 8 17:35:32 eslab63 genunix: [ID 733762 kern.notice] 1 Feb 8 17:35:34 eslab63 genunix: [ID 904073 kern.notice] done Feb 8 17:35:35 eslab63 genunix: [ID 111219 kern.notice] dumping to /dev/dsk/c1t0d0s1, offset 429654016, content: kernel Feb 8 17:36:18 eslab63 genunix: [ID 409368 kern.notice] 100% done: 53847 pages dumped, compression ratio 5.54, Feb 8 17:36:18 eslab63 genunix: [ID 851671 kern.notice] dump succeeded