freebsd stable - Apr 2019 - Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()

On 15.04.2019 16:31, Trond Endrest?l wrote:
> Has anyone else witnessed a panic during reboot involving 
> softclock_call_cc(), nd6_timer(), and nd6_dad_start()?
> 
> The stack trace goes more or less like this:
> 
> db_trace_self_wrapper()
> vpanic()
> panic()
> trap_fatal()
> trap()
> calltrap()
> nd6_dad_start()
> nd6_timer()
> softclock_call_cc()
> softclock()
> ithread_loop()
> fork_exit()
> fork_trampoline()
> 
> This was last seen while transitioning from r345628 to r346220 on 
> amd64 stable/12.
Hi,

do you have exact panic message and/or backtrace from core dump?
It would be good to submit PR about such problems.

-- 
WBR, Andrey V. Elsukov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20190417/e6938a63/attachment.sig>

On Wed, 17 Apr 2019 12:41+0300, Andrey V. Elsukov wrote:
> On 15.04.2019 16:31, Trond Endrest?l wrote:
> > Has anyone else witnessed a panic during reboot involving 
> > softclock_call_cc(), nd6_timer(), and nd6_dad_start()?
> > 
> > The stack trace goes more or less like this:
> > 
> > db_trace_self_wrapper()
> > vpanic()
> > panic()
> > trap_fatal()
> > trap()
> > calltrap()
> > nd6_dad_start()
> > nd6_timer()
> > softclock_call_cc()
> > softclock()
> > ithread_loop()
> > fork_exit()
> > fork_trampoline()
> > 
> > This was last seen while transitioning from r345628 to r346220 on 
> > amd64 stable/12.
> 
> Hi,
> 
> do you have exact panic message and/or backtrace from core dump?
Here's another system I had to shut down recently:

root at HOSTNAME:/var/crash # kgdb /boot/kernel/kernel vmcore.0
[...]
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x410
fault code              = supervisor read data  , page not present
instruction pointer     = 0x20:0xffffffff807ea33d
stack pointer           = 0x28:0xfffffe005ad3c8d0
frame pointer           = 0x28:0xfffffe005ad3c960
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 12 (swi4: clock (0))
trap number             = 12
panic: page fault
cpuid = 0
time = 1555402802
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8054125b = db_trace_self_wrapper+0x2b/frame
0xfffffe005ad3c570
vpanic() at 0xffffffff8080aae4 = vpanic+0x1b4/frame 0xfffffe005ad3c5d0
panic() at 0xffffffff8080a923 = panic+0x43/frame 0xfffffe005ad3c630
trap_fatal() at 0xffffffff80b76244 = trap_fatal+0x394/frame 0xfffffe005ad3c690
trap_pfault() at 0xffffffff80b762a9 = trap_pfault+0x49/frame 0xfffffe005ad3c6f0
trap() at 0xffffffff80b7588f = trap+0x29f/frame 0xfffffe005ad3c800
calltrap() at 0xffffffff80b514c5 = calltrap+0x8/frame 0xfffffe005ad3c800
--- trap 0xc, rip = 0xffffffff807ea33d, rsp = 0xfffffe005ad3c8d0, rbp =
0xfffffe005ad3c960 ---
__mtx_lock_sleep() at 0xffffffff807ea33d = __mtx_lock_sleep+0xbd/frame
0xfffffe005ad3c960
mld_fasttimo() at 0xffffffff80a3ae32 = mld_fasttimo+0x492/frame
0xfffffe005ad3ca50
pffasttimo() at 0xffffffff80899fa4 = pffasttimo+0x54/frame 0xfffffe005ad3ca80
softclock_call_cc() at 0xffffffff80824e0e = softclock_call_cc+0x12e/frame
0xfffffe005ad3cb30
softclock() at 0xffffffff808252f9 = softclock+0x79/frame 0xfffffe005ad3cb50
ithread_loop() at 0xffffffff807cd824 = ithread_loop+0x1d4/frame
0xfffffe005ad3cbb0
fork_exit() at 0xffffffff807ca2d3 = fork_exit+0x83/frame 0xfffffe005ad3cbf0
fork_trampoline() at 0xffffffff80b524be = fork_trampoline+0xe/frame
0xfffffe005ad3cbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 34d16h8m2s
Dumping 4593 out of 12258 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

This particular system uses lagg0 comprised of bce0, bce1, em0, and 
em1. Also, it runs a custom kernel.
> It would be good to submit PR about such problems.
I'll submit the details in a PR.

-- 
Trond.