On Wed, Dec 03, 2025 at 08:51:10PM +0100, Mike Fischer wrote: > > > Am 03.12.2025 um 19:08 schrieb Mike Larkin <[email protected]>: > > > > On Wed, Dec 03, 2025 at 04:40:14PM +0100, Mike Fischer wrote: > >> Sorry, forgot the desmg: > >> > >> OpenBSD 7.8 (GENERIC.MP) #1: Sat Nov 29 11:02:59 MST 2025 > >> > >> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > >> real mem = 4261408768 (4063MB) > >> avail mem = 4105592832 (3915MB) > >> random: good seed from bootblocks > >> mpath0 at root > >> scsibus0 at mpath0: 256 targets > >> mainbus0 at root > >> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc100000 (12 entries) > >> bios0: vendor Xen version "4.15.2" date 06/26/2022 > >> bios0: Xen HVM domU > > > > what's the host? > > No idea unfortunately. This is located at a hosting provider and they don’t > specify the details. The customer gets 2 x86 vCPUs, 4 GB RAM and some SSD > disk space. But that’s it for the specification. The dmesg contains any other > info I can get. > > The main reason we are using this is that the IPs are completely separate > from our other servers. This can matter for e.g. mail servers when some > subnet is placed on a blocklist. (At least that was the original idea.) > Mostly this machine is idle or dealing with unwanted traffic. > > > Since the forced reboot after the panic, the VM has stayed up so far. I’ll > continue to monitor of course. > > I do know that their IPv6 environment is somewhat unusual as the grant only a > /128 address out of a /64 subnet for the guest VMs. Among other things my VM > sees a lot of ND (broadcast) traffic for other hosts on the same subnet, even > though static IPv4 and IPv6 addresses are configured on my VM. > > slaacd is running but »slaacctl show interface xnf0« shows no output. It is > probably not needed but has never hurt in the last few years. > > Default routes are statically configured in /etc/mygate. > > A local unbound is running and is used as the local resolver. > > There is a wireguard tunnel to one of our other servers, used mainly for > monitoring purposes, i.e. the other server monitors this one. > > > Does the message »panic: grant table reference 1908 is held by« imply an > involvement of pf(4)? A non-default pf.conf is used, basically to block all > traffic except the wanted traffic. SSHGuard is also running and it modifies > one of the tables in pf(4). > > > I mainly posted here to give a heads-up in case one of the recent syspatches > is involved. The timing of the panic suggest this. But it could be unrelated > of course. > > > Thanks! > Mike >
no idea then... let us know if it happens again. > > > >> acpi0 at bios0: ACPI 4.0 > >> acpi0: sleep states S3 S4 S5 > >> acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT > >> acpi0: wakeup devices > >> acpitimer0 at acpi0: 3579545 Hz, 32 bits > >> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat > >> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 11, 48 pins, remapped > >> cpu0 at mainbus0: apid 0 (boot processor) > >> cpu0: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz, 2300.33 MHz, 06-55-07 > >> cpu0: cpuid 1 > >> edx=1fcbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT> > >> > >> ecx=f7fa3223<SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV> > >> cpu0: cpuid 7.0 > >> ebx=d19f27eb<FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,AVX512CD,AVX512BW,AVX512VL> > >> ecx=808<PKU> edx=9c000400<MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD> > >> cpu0: cpuid d.1 eax=f<XSAVEOPT,XSAVEC,XGETBV1,XSAVES> > >> cpu0: cpuid 80000001 edx=2c100800<NXE,PAGE1GB,RDTSCP,LONG> > >> ecx=121<LAHF,ABM,3DNOWP> > >> cpu0: MELTDOWN > >> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > >> 64b/line 16-way L2 cache, 22MB 64b/line 11-way L3 cache > >> cpu0: smt 0, core 0, package 0 > >> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > >> cpu0: apic clock running at 100MHz > >> cpu1 at mainbus0: apid 2 (application processor) > >> cpu1: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz, 2303.91 MHz, 06-55-07 > >> cpu1: smt 0, core 1, package 0 > >> acpihpet0 at acpi0: 62500000 Hz > >> acpiprt0 at acpi0: bus 0 (PCI0) > >> acpipci0 at acpi0 PCI0 > >> acpicmos0 at acpi0 > >> "PNP0F13" at acpi0 not configured > >> "PNP0303" at acpi0 not configured > >> com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > >> acpicpu0 at acpi0: C1(@1 halt!) > >> acpicpu1 at acpi0: C1(@1 halt!) > >> cpu0: using VERW MDS workaround (except on vmm entry) > >> pvbus0 at mainbus0: Xen 4.15 > >> xen0 at pvbus0: features 0x2705, 64 grant table frames, event channel 1 > >> xbf0 at xen0 backend 0 channel 6: disk > >> scsibus1 at xbf0: 1 targets > >> sd0 at scsibus1 targ 0 lun 0: <Xen, phy xvda 51712, 0000> > >> sd0: 61440MB, 512 bytes/sector, 125829120 sectors > >> xbf1 at xen0 backend 0 channel 7: cdrom > >> scsibus2 at xbf1: 1 targets > >> cd0 at scsibus2 targ 0 lun 0: <Xen, qdisk xvdc 5174, 0000> > >> xnf0 at xen0 backend 0 channel 8: address 00:50:56:22:63:94 > >> "vkbd" at xen0: device/vkbd/0 not configured > >> pci0 at mainbus0 bus 0 > >> 0:1:2: io address conflict 0xc200/0x20 > >> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > >> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 > >> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, > >> channel 0 wired to compatibility, channel 1 wired to compatibility > >> pciide0: channel 0 disabled (no drives) > >> atapiscsi0 at pciide0 channel 1 drive 0 > >> scsibus3 at atapiscsi0: 2 targets > >> cd1 at scsibus3 targ 0 lun 0: <QEMU, QEMU DVD-ROM, 2.5+> removable > >> cd1(pciide0:1:0): using PIO mode 4, DMA mode 2 > >> uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 1 int 23 > >> piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: SMBus > >> disabled > >> xspd0 at pci0 dev 2 function 0 "XenSource Platform Device" rev 0x01 > >> vga1 at pci0 dev 3 function 0 "Bochs VGA" rev 0x02 > >> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > >> wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > >> isa0 at pcib0 > >> isadma0 at isa0 > >> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 > >> pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > >> pckbd0 at pckbc0 (kbd slot) > >> wskbd0 at pckbd0: console keyboard, using wsdisplay0 > >> pms0 at pckbc0 (aux slot) > >> wsmouse0 at pms0 mux 0 > >> pcppi0 at isa0 port 0x61 > >> spkr0 at pcppi0 > >> usb0 at uhci0: USB revision 1.0 > >> uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev > >> 1.00/1.00 addr 1 > >> vmm0 at mainbus0: VMX/EPT > >> uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet" > >> rev 2.00/0.00 addr 2 > >> uhidev0: iclass 3/0 > >> ums0 at uhidev0: 3 buttons, Z dir > >> wsmouse1 at ums0 mux 0 > >> vscsi0 at root > >> scsibus4 at vscsi0: 256 targets > >> softraid0 at root > >> scsibus5 at softraid0: 256 targets > >> root on sd0a (51df7c0a61aa8e9b.a) swap on sd0b dump on sd0b > >> WARNING: / was not properly unmounted > >> fd0 at fdc0 drive 1: density unknown > >> > >> > >>> Am 03.12.2025 um 16:38 schrieb Mike Fischer <[email protected]>: > >>> > >>> OpenBSD 7.8 (-stable) > >>> pkg_add -u (all ports up to date) > >>> syspatch > >>> reboot > >>> > >>> The machine bootet normally. > >>> > >>> After about 1:40 min. the kernel paniced: > >>> > >>> /dev/sdoi (51df7c0a61aaße9b.i): file system is clean; not checking > >>> /dev/sdOe (51df?c0a61aaße9b.e): file system is clean; not checking kbd: > >>> keyboard mapping set to de pf enabled starting network > >>> ifconfig: wg0: SIOCIFCREATE: File exists fdo at fdc® drive 1: density > >>> unknown reordering: Id.so libc libcrypto sshd sshd-session sshd-auth > >>> ssh-agent. starting early daemons: syslogd pflogd unbound ntpd. starting > >>> RPC daemons:. savecore: no core dump checking quotas: done. clearing /tmp > >>> kern.securelevel: 0 -> 1 > >>> creating runtime link editor directory cache. preserving editor files. > >>> starting network daemons: sshd snmpd httpd. > >>> starting package daemons: milter_spand postgrey spamassassin dovecot > >>> postfix ssh guard symon unstatd opendkim. starting local daemons: cron. > >>> Wed Dec 3 16:18:49 CET 2025 > >>> OpenBSD/amd64 (REDACTED) (ttyCO) > >>> login: panic: grant table reference 1908 is held by > >>> > >>> > >>> I restarted the machine and so far it is working … > >>> > >>> I suspect something in the latest syspatch as the machine was running > >>> without any panics before: > >>> Get/Verify syspatch78-007_drm.tgz 100% > >>> |**************************************************************************************************************| > >>> 264 KB 00:00 Installing patch 007_drm > >>> Get/Verify syspatch78-008_libpng.tgz 100% > >>> |***********************************************************************************************************| > >>> 539 KB 00:00 Installing patch 008_libpng > >>> Get/Verify syspatch78-009_xkbcomp... 100% > >>> |***********************************************************************************************************| > >>> 104 KB 00:00 Installing patch 009_xkbcomp > >>> Get/Verify syspatch78-010_unbound... 100% > >>> |***********************************************************************************************************| > >>> 2953 KB 00:00 Installing patch 010_unbound > >>> Get/Verify syspatch78-011_nd6.tgz 100% > >>> |**************************************************************************************************************| > >>> 77300 00:00 Installing patch 011_nd6 > >>> Relinking to create unique kernel... done; reboot to load the new kernel > >>> Errata can be reviewed under /var/syspatch > >>> > >>> > >>> Any ideas? > >>> > >>> Mike > >> > >> > >> > >
