Alan Hargreaves' Blog

The ramblings of a former Australian SaND TSC* Principal Field Technologist

What does “panic: sync initiated” mean?

Twice in the last week I’ve received crashdumps for analysis with this panic string, and customers concerned that they need to replace hardware.

Let’s just walk through an example.

On the system console we something like

panic[cpu0]/thread=2a10007dd20: sync initiated
sched: software trap 0x7f
pid=0, pc=0xf0050c7c, sp=0x2a10007cd41, tstate=0x8800001404, context=0x0
g1-g7: 1003a07c, 10418000, 10418000, 6b, 0, 0, 2a10007dd20
00000000fffa9d00 unix:sync_handler+150 (1041ae50, 10000000, b, 2a10004bd20, 2a10007dd20, 0)
%l0-3: 0000000010027ff8 0000000000000003 0000000000000000 000002a1000abd20
%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
00000000fffa9de0 unix:vx_handler+8c (f0000000, 10418348, 10418240, fff9b840, f003bda1, 0)
%l0-3: 000000001002866c 0000000000000016 000000000000000a 000000001000a408
%l4-7: 000000000000004e 00000300009af5ec 0000000000000006 000002a10007d6f0
00000000fffa9e90 unix:callback_handler+20 (fff9b840, fffde280, 0, 0, 0, 0)
%l0-3: 0000000000000016 00000000fffa9741 0000000000000009 000000001000a408
%l4-7: 000000001041b5b8 0000000000000000 0000000000000000 000002a10007d7b0
syncing file systems... 7 2 done
dumping to /dev/dsk/c0t0d0s1, offset 53805056

So we see that we are in the sync handler, which kind of makes sense given the panic string. What this actually means is that someone has typed

sync

at the ok prompt.

OK, so how did we get to the ok prompt? Let’s have a look at the stack.

unix:client_handler+0x2c()
unix:p1275_sparc_cif_handler(0x2a10007d6a8) - frame recycled
unix:prom_enter_mon+0x38()
unix:debug_enter+0x15c()
unix:abort_sequence_enter(0x0) - frame recycled
kb:kbdinput+0x304(0x300003edd68, 0x1046b000?)
kb:kbdrput+0x13c(, 0x30000d92300)
unix:putnext+0x1cc(0x300007a6e48?, 0x30000d92300)
su:async_softint+0x58c(0x3000013c008)
su:asysoftintr+0x70()
unix:intr_thread+0xa4()
unix:prom_rtt+0x0()

The important one here is abort_sequence enter().

This only gets called when the abort sequence has been entered on the console. If it’s a serial console (like this one), this means <BREAK> or the alternate abort sequence if KEYBOARD_ABORT=alternate in /etc/default/kbd has been detected. On a Sun console, it’s STOP-A.

So, what do we actually have here?

We have the system receiving the abort sequence, dropping the system to the ok prompt and then someone forcing a crashdump by typing sync.

Generally this would be a deliberate action, done to capture the system state of something like a hang condition for analysis.

The only other thing that occurs to me as a possibility is that a serial console is connected to something that dropped the DTR signal (eg a VDU or a terminal server).

There are a number of infodocs that discuss how to deal with this.

For example:

  • Infodoc 16093: Configuration of serial consoles (headless) on Solaris[TM]
  • Infodoc 13031: Annex Network Terminal Server (NTS) PSD/MFAQ
  • Infodoc 15721: NTS as console server

The upshot of this is, with a panic: sync initiated core, it’s unlikely you have broken hardware.

Advertisements

Written by Alan

October 29, 2004 at 3:06 am

Posted in Solaris

2 Responses

Subscribe to comments with RSS.

  1. And, as usual, the infodocs are only available to Sun employees or people paying for support contracts. The logic of this completely escapes me, it’s as if Sun don’t want people to play around with Solaris. Which, of course, is most definitely not the case.

    Anonymous

    October 29, 2004 at 5:20 am

  2. Alan, you may want to mention the usual ways to disable Stop-A from the keyboard, which will prevent this sort of thing happening.

    PatrickG

    October 29, 2004 at 6:36 am


Comments are closed.

%d bloggers like this: