Re: bgpd / vport / veb panic in 7.8

Hello all,

For anyone seeing this in the future; this has been resolved by
updating to the latest snapshot. My thanks to the person that
contacted me off list to suggest this.

My thanks and admiration to everyone who makes this software possible,
Mark


On Fri, Jan 30, 2026 at 4:31 PM Mark Leonard <mark@bernoullinetworks.com> wrote:
>
> Hello all,
>
> I attempted an upgrade from 7.6 to 7.7 to 7.8 a few days ago (all with
> sysupgrade). When I got to 7.8 things went sideways.
>
> I've been trying to isolate the problem as best I can. The original
> problem is happening on physical hardware. I'm able to reproduce the
> problem under VMWare. Panic information is below. Please let me know
> if I can provide any additional information.
>
> There are six rdomains: 10, 11, 101, 102, 103, 104
> Each looks similar to the 101 config shown below (replace 101 with 10,
> 11, 102, etc). System is stable with static routing across the veb.
> The panic only occurs when there is more than one instance of bgpd.
>
> To launch each bgpd instance I'm manually running:
> route -T 101 exec bgpd -f /etc/bgpd-101.conf
> (replacing '101' with whatever the appropriate rdomain is)
>
> I see in the 7.7 changelog there were some bgpd improvements, and some
> veb/vport improvements on 7.8. I've looked through the man pages and
> nothing jumped out at me as new or different in terms of necessary
> config.
>
> The veb seems happy enough with vports in differing rdomains - it
> works fine with static routing.
>
> Can anyone shed some light on where I may have gone wrong?
>
> Thanks,
> Mark
>
> bgpd-test# cat /etc/hostname.lo101
> rdomain 101
> inet 101.101.101.101 255.255.255.255 NONE
> up
>
> bgpd-test# cat /etc/hostname.vport101
> rdomain 101
> inet 198.19.1.101 255.255.255.0 NONE
> up
>
> bgpd-test# cat /etc/bgpd-101.conf
> mynetwork="101.101.101.101/32"
> rid="198.19.1.101"
> rtable 101
> router-id $rid
> listen on $rid
> AS 65101
> network $mynetwork
>
> group "LANs" {
> neighbor 198.19.1.10 {
> remote-as 65010
> }
> neighbor 198.19.1.11 {
> remote-as 65011
> }
> neighbor 198.19.1.102 {
> remote-as 65102
> }
> neighbor 198.19.1.103 {
> remote-as 65103
> }
> neighbor 198.19.1.104 {
> remote-as 65104
> }
> }
>
> bgpd-test# cat /etc/hostname.veb0
> add vport10
> add vport11
> add vport101
> add vport102
> add vport103
> add vport104
>
>
>
> panic: inet rwlock 0xffff80001efd55d0: enter write deadlock
> Stopped at db_enter+0x14: popq %rbp
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> 235033 33212 0 0 0 1 bgpd
> *248122 68830 0 0x14000 0x200 0 softnet0
> db_enter() at db_enter+0x14
> panic(ffffffff826b5b05) at panic+0xd5
> rw_do_enter_write(ffff80001efd55d0,0) at rw_do_enter_write+0x265
> in_pcbsolock(fffffd83bf539900) at in_pcbsolock+0x83
> tcp_input_solocked(ffff8000396998f8,ffff800039699904,6,2,0) at
> tcp_input_solocked+0x71e
> tcp_input(ffff8000396998f8,ffff800039699904,6,2,0) at tcp_input+0x4b
> ip_deliver(ffff8000396998f8,ffff800039699904,6,2,1,0) at ip_deliver+0xfc
> ip_ours(ffff8000396998f8,ffff800039699904,ffff80003969984c,0,0) at ip_ours+0x6f
>
> ip_input_if(ffff8000396998f8,ffff800039699904,0,0,ffff800000acd000,0)
> at ip_input_if+0x21f
> ipv4_input(ffff800000acd000,fffffd800307fc00,0) at ipv4_input+0x3d
> ether_input(ffff800000acd000,fffffd800307fc00,0) at ether_input+0x40f
> vport_if_enqueue(ffff800000acd000,fffffd800307fc00) at vport_if_enqueue+0x5a
> veb_port_input(ffff800000ac2800,fffffd800307fc00,fee1bad5f783,ffff800000ce4100,0)
> at veb_port_input+0x39c
> vport_enqueue(ffff800000ac2800,fffffd800307fc00) at vport_enqueue+0x109
> end trace frame: 0xffff800039699b30, count: 0
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{0}>
> ddb{0}> show panic
> *cpu0: inet rwlock 0xffff80001efd55d0: enter write deadlock
> ddb{0}>
> ddb{0}> trace
> db_enter() at db_enter+0x14
> panic(ffffffff826b5b05) at panic+0xd5
> rw_do_enter_write(ffff80001efd55d0,0) at rw_do_enter_write+0x265
> in_pcbsolock(fffffd83bf539900) at in_pcbsolock+0x83
> tcp_input_solocked(ffff8000396998f8,ffff800039699904,6,2,0) at
> tcp_input_solocked+0x71e
> tcp_input(ffff8000396998f8,ffff800039699904,6,2,0) at tcp_input+0x4b
> ip_deliver(ffff8000396998f8,ffff800039699904,6,2,1,0) at ip_deliver+0xfc
> ip_ours(ffff8000396998f8,ffff800039699904,ffff80003969984c,0,0) at ip_ours+0x6f
>
> ip_input_if(ffff8000396998f8,ffff800039699904,0,0,ffff800000acd000,0)
> at ip_input_if+0x21f
> ipv4_input(ffff800000acd000,fffffd800307fc00,0) at ipv4_input+0x3d
> ether_input(ffff800000acd000,fffffd800307fc00,0) at ether_input+0x40f
> vport_if_enqueue(ffff800000acd000,fffffd800307fc00) at vport_if_enqueue+0x5a
> veb_port_input(ffff800000ac2800,fffffd800307fc00,fee1bad5f783,ffff800000ce4100,0)
> at veb_port_input+0x39c
> vport_enqueue(ffff800000ac2800,fffffd800307fc00) at vport_enqueue+0x109
> ether_output(ffff800000ac2800,fffffd800307fc00,fffffd843e651d58,fffffd843e519560)
> at ether_output+0x9d
> if_output_tso(ffff800000ac2800,ffff800039699c60,fffffd843e651d58,fffffd843e519560,5dc)
> at if_output_tso+0xf6
> ip_output(fffffd800307fc00,0,fffffd843e651d40,800,0,fffffd843e651dd8,b5af8a2933b0ab0)
> at ip_output+0x7ee
> tcp_output(ffff800000dbb148) at tcp_output+0x1a53
> tcp_input_solocked(ffff80003969a298,ffff80003969a2a4,6,2,0) at
> tcp_input_solocked+0x2854
> tcp_input(ffff80003969a298,ffff80003969a2a4,6,2,0) at tcp_input+0x4b
> ip_deliver(ffff80003969a298,ffff80003969a2a4,6,2,1,0) at ip_deliver+0xfc
> ip_ours(ffff80003969a298,ffff80003969a2a4,ffff80003969a1b8,0,0) at ip_ours+0x6f
>
> ip_input_if(ffff80003969a298,ffff80003969a2a4,0,0,ffff800000ac2800,0)
> at ip_input_if+0x21f
> ipv4_input(ffff800000ac2800,fffffd800307fc00,0) at ipv4_input+0x3d
> ether_input(ffff800000ac2800,fffffd800307fc00,0) at ether_input+0x40f
> vport_if_enqueue(ffff800000ac2800,fffffd800307fc00) at vport_if_enqueue+0x5a
> veb_port_input(ffff800000acd000,fffffd800307fc00,fee1bad060ff,ffff800000ce4600,0)
> at veb_port_input+0x39c
> vport_enqueue(ffff800000acd000,fffffd800307fc00) at vport_enqueue+0x109
> ether_output(ffff800000acd000,fffffd800307fc00,fffffd83b76ff318,fffffd843e519230)
> at ether_output+0x9d
> if_output_tso(ffff800000acd000,ffff80003969a600,fffffd83b76ff318,fffffd843e519230,5dc)
> at if_output_tso+0xf6
> ip_output(fffffd800307fc00,0,fffffd83b76ff300,800,0,fffffd83bf539a08,b5af8a2938a1874)
> at ip_output+0x7ee
> syn_cache_respond(fffffd83b76ff2a0,fffffd800307fc00,bcd8d4c624c757e,0)
> at syn_cache_respond+0x6f7
> syn_cache_add(ffff80003969ab90,ffff80003969ab70,fffffd800307fcc4,14,ffff80001efd55c8,fffffd800307fc00,dcd8c2a5db40dac6,fffffd83bf539900,bcd8d4c624c757e,0,ffff80001efd55c8,ffff800000d20cc0)
> at syn_cache_add+0x736
> tcp_input_solocked(ffff80003969af38,ffff80003969af44,6,2,0) at
> tcp_input_solocked+0x156b
> tcp_input(ffff80003969af38,ffff80003969af44,6,2,0) at tcp_input+0x4b
> ip_deliver(ffff80003969af38,ffff80003969af44,6,2,1,0) at ip_deliver+0xfc
> ip_ours(ffff80003969af38,ffff80003969af44,ffff80003969ae8c,0,0) at ip_ours+0x6f
>
> ip_input_if(ffff80003969af38,ffff80003969af44,0,0,ffff800000acd000,0)
> at ip_input_if+0x21f
> ipv4_input(ffff800000acd000,fffffd800307fc00,0) at ipv4_input+0x3d
> ether_input(ffff800000acd000,fffffd800307fc00,0) at ether_input+0x40f
> vport_if_enqueue(ffff800000acd000,fffffd800307fc00) at vport_if_enqueue+0x5a
> veb_port_input(ffff800000ac2800,fffffd800307fc00,fee1bad5f783,ffff800000ce4100,0)
> at veb_port_input+0x39c
> vport_enqueue(ffff800000ac2800,fffffd800307fc00) at vport_enqueue+0x109
> ether_output(ffff800000ac2800,fffffd800307fc00,ffff800000cf3310,fffffd843e519560)
> at ether_output+0x9d
> if_output_mq(ffff800000ac2800,fffffd83beb07a40,ffffffff82a67888,ffff800000cf3310,fffffd843e519560)
> at if_output_mq+0x8e
> arpcache(ffff800000ac2800,fffffd80be0be4c0,fffffd843e519560) at arpcache+0x2ad
> in_arpinput(ffff800000ac2800,fffffd80be0be400) at in_arpinput+0x1da
> arpintr() at arpintr+0xb7
> if_netisr(0) at if_netisr+0xe5
> taskq_thread(ffff800000032000) at taskq_thread+0x129
> end trace frame: 0x0, count: -50
> ddb{0}>
> ddb{0}> ps
> PID TID PPID UID S FLAGS WAIT COMMAND
> 1496 17267 68265 75 3 0x1100092 kqread bgpd
> 69041 381639 68265 75 3 0x1100092 kqread bgpd
> 63388 447180 68265 75 3 0x1100092 kqread bgpd
> 68265 364856 1 0 2 0 bgpd
> 50444 202782 31826 75 3 0x1100092 kqread bgpd
> 74335 384030 31826 75 3 0x1100092 kqread bgpd
> 19222 375007 31826 75 3 0x1100092 kqread bgpd
> 31826 507767 1 0 2 0x80 bgpd
> 3949 507476 33212 75 3 0x1100092 kqread bgpd
> 93170 348775 33212 75 3 0x1100092 kqread bgpd
> 62062 395225 33212 75 3 0x1100092 kqread bgpd
> 33212 235033 1 0 7 0 bgpd
> 44141 41338 73659 75 3 0x1100092 kqread bgpd
> 4588 403342 73659 75 3 0x1100092 kqread bgpd
> 93636 263923 73659 75 3 0x1100092 kqread bgpd
> 73659 394 1 0 2 0x80 bgpd
> 86229 469905 14359 75 3 0x1100092 kqread bgpd
> 46941 203026 14359 75 3 0x1100092 kqread bgpd
> 31053 200804 14359 75 3 0x1100092 kqread bgpd
> 14359 383798 1 0 3 0x80 kqread bgpd
> 54152 519551 946 75 3 0x1100092 kqread bgpd
> 97856 110458 946 75 3 0x1100012 netlock bgpd
> 17826 147606 946 75 3 0x1100092 kqread bgpd
> 946 13063 1 0 2 0 bgpd
> 68620 446763 1 0 3 0x100083 ttyin ksh
> 35902 331893 1 0 3 0x100098 kqread cron
> 66200 306014 1 99 3 0x1100090 kqread sndiod
> 15877 455910 1 110 3 0x100090 kqread sndiod
> 72330 152984 23765 95 3 0x1100092 kqread smtpd
> 22531 450007 23765 103 3 0x1100092 kqread smtpd
> 70473 280225 23765 95 3 0x1100092 kqread smtpd
> 16322 441746 23765 95 3 0x100092 kqread smtpd
> 38657 174061 23765 95 3 0x1100092 kqread smtpd
> 39758 178601 23765 95 3 0x1100092 kqread smtpd
> 23765 222788 1 0 3 0x100080 kqread smtpd
> 67560 415553 1 0 3 0x88 kqread sshd
> 54868 68589 1 0 3 0x100080 kqread ntpd
> 244 61525 53245 83 3 0x100092 kqread ntpd
> 53245 144965 1 83 3 0x1100092 kqread ntpd
> 83961 291509 95038 74 3 0x1100092 bpf pflogd
> 95038 29063 1 0 3 0x80 sbwait pflogd
> 59951 430874 25278 73 3 0x1100090 kqread syslogd
> 25278 312898 1 0 3 0x100082 sbwait syslogd
> 42588 250068 1 0 3 0x100080 kqread resolvd
> 70593 472015 54573 77 3 0x100092 kqread dhcpleased
> 13724 172652 54573 77 3 0x100092 kqread dhcpleased
> 54573 123098 1 0 3 0x80 kqread dhcpleased
> 83363 446758 20907 115 3 0x100092 kqread slaacd
> 69930 49483 20907 115 3 0x100092 kqread slaacd
> 20907 417758 1 0 3 0x100080 kqread slaacd
> 55017 268958 0 0 3 0x14200 bored smr
> 10058 110293 0 0 3 0x14200 pgzero zerothread
> 2912 62489 0 0 3 0x14200 aiodoned aiodoned
> 17218 258242 0 0 3 0x14200 syncer update
> 82831 366423 0 0 3 0x14200 cleaner cleaner
> 48081 180628 0 0 3 0x14200 reaper reaper
> 16239 260093 0 0 3 0x14200 pgdaemon pagedaemon
> 87003 319209 0 0 3 0x40014200 acpi0 acpi0
> 16586 291978 0 0 3 0x40014200 idle1
> 30775 23574 0 0 3 0x14200 bored softnet1
> *68830 248122 0 0 7 0x14200 softnet0
> 35730 303928 0 0 3 0x14200 bored systqmp
> 72631 29706 0 0 3 0x14200 bored systq
> 70811 20495 0 0 3 0x14200 tmoslp softclockmp
> 50744 300006 0 0 3 0x40014200 tmoslp softclock
> 63512 347235 0 0 3 0x40014200 idle0
> 1 344850 0 0 3 0x82 wait init
> 0 0 -1 0 3 0x10200 scheduler swapper
> ddb{0}>

Fwd: NEW databases/openvoxdb

Index: user.list
===================================================================
RCS file: /cvs/ports/infrastructure/db/user.list,v
diff -u -r1.480 user.list
--- user.list 25 Jan 2026 17:24:41 -0000 1.480
+++ user.list 1 Feb 2026 10:42:41 -0000
@@ -227,7 +227,7 @@
716 _c-icap _c-icap www/c-icap/c-icap
717 _uptimed _uptimed sysutils/uptimed
718 _stuntman _stuntman telephony/stuntman
-719 _puppetdb _puppetdb databases/puppetdb
+719 _puppetdb _puppetdb databases/{puppetdb,openvoxdb}
#720 _lldpd _lldpd net/lldpd
721 _dkimproxy _dkimproxy mail/dkimproxy
722 _salt _salt sysutils/salt

Forgot to include ports@ in my reply.

---------- Forwarded message ---------

Hi Klemens,

I think I addressed all your concerns, see below.

Updated tarball attached.

On Sat, Jan 31, 2026 at 2:49 PM Klemens Nanni <kn@openbsd.org> wrote:

28.01.2026 16:55, Sebastian Reitenbach пишет:
> Hi,
>
> cat pkg/DESCR:
> OpenVoxDB is a fork of Open Source PuppetDB.
>
> OpenVoxDB is the fast, scalable, and reliable data warehouse for OpenVox.
> It caches data generated by OpenVox, and gives you advanced features at
> awesome speed with a powerful API.
>
> Similarly to OpenVox server, it will eventually replace PuppetDB. To eventually support multiple major versions, same structure used as databases/puppetdb.

Makes sense.

I don't think '@pkgpath databases/puppetdb/7' is needed.

removed 

 

infrastructure/db/user.list should mention openvoxdb as well.

see attached user.list.diff file

 

patches/ harcodes /var while the .rc file uses LOCALSTATEDIR;
both is fine to me really, but it should be consistent.

I went the /var route.

 

patches/ has files with 'env bash' shebangs and do-configure
sed-patches other files to use an absoloute path.  Both work,
but I'd prefer we stick to one way of fixing/using bash.

I chose the env bash version.

 

Strictly speaking, I think, MAKE_FLAGS should be FAKE_FLAGS
since only do-install uses them and NO_BUILD=Yes.

Renamed

 

Overall, it'd be nice if openvoxdb and openvox-server Makefiles
would match;  they share a lot, but have churn wrt. V/VERSION,
spaces/no spaces before =, etc. which makes reading harder than
it should be.

Should be better now.

 

>
> Same as with OpenVox server, between 8.11 and 8.12, they dropped the Makefile with the install target. Therefore using same approach here, and added the old Makefile to the files directory.

I lack the details/background here, but the approach seems fine
except for

- 'rubylibdir ?= $(shell ruby ...)':
  - needs USE_GMAKE=Yes (only openvox-server sets it)
  - should probably use MODRUBY_* stuff to get the binary name
  or not use a shell command at all

- you default 'confidir ?= /etc' and others, bu then also pass
  them in the ports Makefile;  we control both, so wouldn' it
  be simpler to use SYSCONFDIR in files/Makefile right away?

To the TWO points above:

I don't know yet, why they removed the Makefile, I wanted to check with upstream.

Therefore I intended to keep the way it was working with puppetdb.

Actually, what is in the file, i.e. the 'rubylibdir ?= $(shell ruby ...)' is not executed,

because it's overridden by the FAKE_FLAGS. therefore no USE_GMAKE anymore,

must have been an old leftover....

 

- does it really need to have all the targets we don't use?

removed the superfluous targets.

 

>
> Any concerns, test reports or any other feedback welcome.

I don't run an openvox server/db setup (yet).

>
> Cheers,
> Sebastian

Re: Processes getting killed on OpenBSD 7.8 arm64 RPi5

On Sun, Feb 01, 2026 at 07:29:36AM +0200, ????????? wrote:
> Could you please elaborate?
> Modern hardware has enough RAM to be able to theoretically run without swap.

Yes, and we have been doing this for many years on other architecures.

However there must be a bug somewhere in the arm64 code that is mitigated by
configuring swap - even a tiny swap partiiton of 32 Mb seems to mitigate the
effects, on a machine with over 3 Gb of physical ram free.

I spent a day or so looking at the code a few years ago, but found nothing
obvious. Since there was an obvious work-around, I moved on to other more
important things.

> If you don't need to hibernate, disabling swap to save NVRAM sounds
> reasonable to me.

Presumably by NVRAM you mean writes to flash memory, (which is technically
NVRAM, but NVRAM is generally understood to mean CMOS ram for the RTC, etc).

Yes, in principle you are correct, but in practice it's not going to make much
of a difference, especially if the swap partition is very small.

Remember that by default the swap partition is used for crash dumps as well,
so most machines used for serious development are likely going to have large a
large swap partition configured.

So overall - if you configure your amd64 daily driver laptop to run without
swap to avoid wearing out the SSD, you'll _probably_ be OK.

If you have an esoteric machine of an architecture that only a handful of
other people are using, then I would presume that they are mostly running
with swap, and if you don't configure swap then you are exercising code paths
that are less well tested.

Re: Processes getting killed on OpenBSD 7.8 arm64 RPi5

On Sunday, February 1st, 2026 at 6:30 AM, 山卡洛 <mwpudrtxoe@gmail.com> wrote:

Could you please elaborate?

Modern hardware has enough RAM to be able to theoretically run without swap.

If you don't need to hibernate, disabling swap to save NVRAM sounds reasonable to me.

So far so good SSH daemon hasn't crashed with the swap partition enabled. As you mention it would be interesting to know or understand why some processes get killed without a swap partition on arm64. My Raspberry Pi has 4 GB which should be plenty enough for a typicall firewall usage.

Re: transmission: allow service reload

On Sat, Jan 31, 2026 at 05:35:29PM -0500, Josh Grosse wrote:
> On Sat, Jan 31, 2026 at 07:37:26PM +0000, Klemens Nanni wrote:
> > dhttps://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md#reload-settings
> >
> > transmission-daemon(1) writes out its entire config on exit.
> >
> > Noticed while deploying with openvox, where the usual chain is:
> > - install package
> > - produce (partial) config file
> > - (re)start service (upon change)
> >
> > But as the daemon updates the file, this would obviously cause
> > change -> restart loops, so soft-reload to apply config without
> > process exit is needed.
> >
> > Works like a charm using the package's service as-is.
> >
> > OK?
>
> OK maintainer, and a big thank you for the update commit! If you could,
> would you be kind enough to add this to the Makefile with this revision?
>
> DPB_PROPERTIES= parallel
>
> I have it in my openbsd-wip Makefile, and it's been helpful there
> during integration testing, where it significantly speeds up builds
> on amd64.

I don't object but generally DPB_PROPERTIES should be used sparingly
since it makes it harder for dpb to schedule things. For leaf ports we
set it if they take a significant amount of time to build, i.e., for
ports that are about an order of magnitude larger than transmission.