DNS Server System Crashes (kernel panic) Regularly Running Late Solaris 11.3
(Doc ID 2529150.1)
Last updated on FEBRUARY 03, 2025
Applies to:
Solaris Operating System - Version 11.3 to 11.4 [Release 11.0]Information in this document applies to any platform.
Symptoms
A system operating as a DNS server repeatedly panics with a panic stack similar to this:
==== panic thread: 0xffffa1c00a829680 ==== CPU: 48 ====
==== panic user (LWP_SYS) thread: 0xffffa1c00a829680 PID: 5063 on CPU: 48 ====
cmd: /opt/local/sbin/named -n 64
fmri: svc:/network/dns/server:default
<snip>
pc: unix:vpanic_common+0x13a: addq $0xf0,%rsp
unix:vpanic_common+0x13a()
unix:0xfffffffffb8a5590()
unix:0xfffffffffb8567a3()
void unix:trap+0x3f1((struct regs *)0xfffffffc85bf36e0, (caddr_t)0, (processorid_t)0x30)
-- panic trap data type: 0xd (General protection)
addr 0 rp 0xfffffffc85bf36e0
trapno 0xd (General protection)
err 0
%rfl 0x10282 (negative|interrupt enable|resume)
savfp 0xfffffffc85bf37f0
savpc unix:atomic_add_32+0: lock addl %esi,(%rdi)
%rbp 0xfffffffc85bf37f0 %rsp 0xfffffffc85bf37d8
%rip unix:atomic_add_32+0: lock addl %esi,(%rdi)
0%rdi 0xdeadbeefdeadbeef 1%rsi 1 2%rdx 0x10
3%rcx 1 4%r8 0xdeadbeefdeadbeef 5%r9 1
%rax 0xdeadbeef %rbx 0xffffa1c029be0800
%r10 0xdeadbeefdeadbeef %r11 0 %r12 0
%r13 0xffffa1c0146d3ac0 %r14 1 %r15 0
%cs 0x30 (KDS_SEL) %ds 0x4b (UCS_SEL)
%es 0x4b (UCS_SEL) %ss 0x38 (GDT_U32CODE,KPL)
%fs 0 (KFS_SEL) %gs 0 (KFS_SEL)
fsbase 0xfffffc85bf37f0ff
gsbase 0xfffffc85bf37f0ff
<trap>unix:atomic_add_32+0()
genunix:label_hold - frame recycled
void ip:ixa_safe_copy+0x88((ip_xmit_attr_t *)0xffffa1c029b8a200, (ip_xmit_attr_t *)0xffffa1c029be0800)
ip_xmit_attr_t *ip:conn_get_ixa_impl+0x6e((conn_t *)0xffffa1c0146d3ac0, (boolean_t)0, (int)1)
ip_xmit_attr_t *ip:conn_get_ixa+0x1a((conn_t *)0xffffa1c0146d3ac0, (boolean_t)0)
int ip:udp_send_cmn+0x118((sock_lower_handle_t)0xffffa1c0146d3ac0, (mblk_t *)0, (uio_t *)0xfffffffc85bf3e80, (struct msghdr *)0xfffffffc85bf3cd0, (cred_t *)0xffffa1c00a54d9c0)
int ip:udp_send_uio+0x34((sock_lower_handle_t)0xffffa1c0146d3ac0, (uio_t *)0xfffffffc85bf3e80, (struct msghdr *)0xfffffffc85bf3cd0, (cred_t *)0xffffa1c00a54d9c0)
int sockfs:so_sendmsg_cmn+0x1b8((struct sonode *)0xffffa1c0146b1000, (struct msghdr *)0xfffffffc85bf3cd0, (struct uio *)0xfffffffc85bf3e80, (struct cred *)0xffffa1c00a54d9c0, (int)0x8000, (boolean_t)1)
int sockfs:so_sendmsg+0xea((struct sonode *)0xffffa1c0146b1000, (struct msghdr *)0xfffffffc85bf3cd0, (struct uio *)0xfffffffc85bf3e80, (struct cred *)0xffffa1c00a54d9c0)
int sockfs:socket_sendmsg+0x64((struct sonode *)0xffffa1c0146b1000, (struct msghdr *)0xfffffffc85bf3cd0, (struct uio *)0xfffffffc85bf3e80, (cred_t *)0xffffa1c00a54d9c0)
ssize_t sockfs:sendit+0x1c0((int)0x245, (struct msghdr *)0xfffffffc85bf3cd0, (struct uio *)0xfffffffc85bf3e80, (int)0x8000)
ssize_t sockfs:sendmsg+0x294((int)0x245, (struct msghdr *)0xffff80ffbec59560, (int)0x8000)
unix:_syscall_invoke+0x30()
-- switch to user thread's user stack --
Notice the process sending a UDP datagram is named - a DNS server process.
This issue may be triggered by any application sending UDP data, but DNS servers do so very often, to many destinations - we've seen more than one customer experience this issue when running a DNS server.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Cause |
| Solution |
| References |