Hi all Regarding this problem, just to let you know. What we did, we changed this device with some other. We tested it, in sense, just turn it on and after a while, even if it's not in production, just laying on table, core dump occurred. So, it seems like some hardware problem on this device. Also, on all other we still didn't receive something similar.
Anyway, for now, we are going forward with implementing wireguard on our systems. Thank you for your help. -- Nemanja Domazetović Senior IT Network inženjer Kappa Star Group, Bulevar kneza Aleksandra Karađorđevića 36, 11000 Beograd, Srbija e-mail: nemanja.domazeto...@kappastar.com web: https://www.kappastar.com mob: +381 60 43 04 435 Čuvajte drveće. Nemojte štampati ovu poruku ako to nije neophodno. / Please consider the environment before printing this email. -----Original Message----- From: owner-b...@openbsd.org <owner-b...@openbsd.org> On Behalf Of Vitaliy Makkoveev Sent: Tuesday, March 5, 2024 9:32 AM To: Nemanja Domazetović <nemanja.domazeto...@kappastar.com> Cc: bugs@openbsd.org; Claudio Jeker <clau...@openbsd.org>; Alexander Haensch <alexander.haen...@ipc.uni-tuebingen.de>; Vitaliy Makkoveev <o...@bsdbox.dev> Subject: Re: wireguard problem? On Tue, Mar 05, 2024 at 07:48:09AM +0000, Nemanja Domazetović wrote: > Hi all > > > > Once again device was restarted. I collected additional information regarding > this problem. (1. show register; 2. show uvm; 3. show bcstats; 4. show panic; > 5. show trace) > > > > kernel: double fault trap, code=0 > > Stopped at setrunnable+0x1df: ret > > > > 1. ddb{1}> show register > > rdi 0xc > > rsi 0 > > rbp 0xffff800022803a90 > > rbx 0xfffffd810003ff00 > > rdx 0x8000000000000000 > > rcx 0x282 > > rax 0xd > > r8 0 > > r9 0 > > r10 0xd9a168fe801b8edb > > r11 0x7e687e3ad68f1356 > > r12 0xffff80000002b380 > > r13 0 > > r14 0xffff8000226b27f8 > > r15 0x8 > > rip 0xffffffff817939ff setrunnable+0x1df > > cs 0x8 > > rflags 0x10246 __ALIGN_SIZE+0xf246 > > rsp 0 > > ss 0x10 > > setrunnable+0x1df: ret > > > > 1. ddb{1}> show uvm > > > > Current UVM status: > > pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12 > > 1005751 VM pages: 22522 active, 154072 inactive, 1 wired, 648129 free > (81908 zero) > > min 10% (25) anon, 10% (25) vnode, 5% (12) vtext > > freemin=33525, free-target=44700, inactive-target=0, wired-max=335250 > > faults=7531385, traps=7529184, intrs=46999471, ctxswitch=112612553 > fpuswitch=0 > > softint=5166285, syscalls=8807983, kmapent=12 > > fault counts: > > noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0 > > ok relocks(total)=207464(210121), anget(retries)=2939116(0), > amapcopy=3057474 > > neighbor anon/obj pg=538323/4590684, gets(lock/unlock)=1630843/210146 > > cases: anon=2448411, anoncow=490705, obj=1366580, prcopy=261581, > przero=2964094 > > > > daemon and swap counts: > > woke=0, revs=0, scans=0, obscans=0, anscans=0 > > busy=0, freed=0, reactivate=0, deactivate=0 > > pageouts=0, pending=0, nswget=0 > > nswapdev=1 > > swpages=263063, swpginuse=0, swpgonly=0 paging=0 > > --db_more-- kernel pointers: > objs(kern)=0xffffffff824c5088 > > > > 1. ddb{1}> show bcstats > > > > Current Buffer Cache status: > > numbufs 41146 busymapped 0, delwri 1 > > kvaslots 6553 avail kva slots 6553 > > bufpages 162588, dmapages 162588, dirtypages 2 > > pendingreads 0, pendingwrites 0 > > highflips 0, highflops 0, dmaflips 0 > > > > 1. ddb{1}> show panic > > > > the kernel did not panic > > > > 1. ddb{1}> trace > > > > setrunnable(ffff8000226b27f8) at setrunnable+0x1df > > wakeup_n(ffff80000002b380,1) at wakeup_n+0x70 > > task_add(ffff80000002b380,ffff80000801ed58) at task_add+0x83 > > wg_decap(ffff800000792000,fffffd80bc4fe200) at wg_decap+0x318 > > wg_decap_worker(ffff800000792000) at wg_decap_worker+0x7a > > taskq_thread(ffff800000791f00) at taskq_thread+0x100 > > end trace frame: 0x0, count: -6 > > > I suspect the races with wg_peer_destroy().
