Alan Hargreaves' Weblog

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.

Posted at 08:06PM Oct 29, 2004 by Alan Hargreaves in Solaris  |  Comments[3]