ffs_blkfree: freeing free block
OpenBSD 6.8/i386 GENERIC
real mem = 536363008 (511MB)
avail mem = 510287872 (486MB)
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)
500 MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
sea-net-002# df -kh .
Filesystem SizeUsed Avail Capacity Mounted on
/dev/wd0a 1024M 1023M -51.0M 105%/
sea-net-002# ls -lah
total 1584936
drwxr-xr-x 2 _suricata _suricata 512B Jan 1 16:20 .
drwxr-xr-x 4 root wheel 1.0K Jan 8 16:58 ..
-rw-rw-r-- 1 root _suricata 655M Jan 8 16:58 eve.json
-rw-rw-r-- 1 root _suricata 0B Jan 1 16:20 fast.log
-rw-rw-r-- 1 root _suricata 118M Jan 8 16:58 stats.log
sea-net-002# cat /dev/null > eve.json
[... lost connectivity to the host... ]
The rest is from the serial console:
dev = 0x0, block = 85520, fs = /
panic: ffs_blkfree: freeing free block
Stopped at db_enter+0x4: popl%ebp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*421812 80411 00x13 00 ksh
db_enter() at db_enter+0x4
panic(d0bf0a66) at panic+0xd3
ffs_blkfree(f5793c68,47810,0) at ffs_blkfree+0x828
ffs_indirtrunc(f5793c68,87f4,,1357a0,0,) at
ffs_indirtrunc+
0x34a
ffs_indirtrunc(f5793c68,f7f3,,141ee0,0,) at
ffs_indirtrunc+
0x30a
ffs_truncate(f5793c68,0,0,0) at ffs_truncate+0xbb2
ufs_setattr(f5adc458) at ufs_setattr+0x2ab
VOP_SETATTR(d1fe7300,f5adc4a0,d2277240,f5f16dc8) at VOP_SETATTR+0x47
vn_open(f5adc550,602,1a4) at vn_open+0x26a
doopenat(f5f16dc8,ff9c,49f50e68,601,1b6,f5adc6b8) at doopenat+0x16e
sys_open(f5f16dc8,f5adc6c0,f5adc6b8) at sys_open+0x1b
syscall(f5adc700) at syscall+0x28e
Xsyscall_untramp() at Xsyscall_untramp+0xa9
end of kernel
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
Hope this helps, thanks for looking.
J.
panic: ffs_blkfree: freeing free block
OpenBSD 6.8/i386
real mem = 536363008 (511MB)
avail mem = 510287872 (486MB)
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)
500 MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
sea-net-002# df -kh .
Filesystem SizeUsed Avail Capacity Mounted on
/dev/wd0a 1024M 1023M -51.0M 105%/
sea-net-002# ls -lah
total 1584936
drwxr-xr-x 2 _suricata _suricata 512B Jan 1 16:20 .
drwxr-xr-x 4 root wheel 1.0K Jan 8 16:58 ..
-rw-rw-r-- 1 root _suricata 655M Jan 8 16:58 eve.json
-rw-rw-r-- 1 root _suricata 0B Jan 1 16:20 fast.log
-rw-rw-r-- 1 root _suricata 118M Jan 8 16:58 stats.log
sea-net-002# cat /dev/null > eve.json
[... lost connectivity to the host... ]
The rest is from the serial console:
dev = 0x0, block = 85520, fs = /
panic: ffs_blkfree: freeing free block
Stopped at db_enter+0x4: popl%ebp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*421812 80411 00x13 00 ksh
db_enter() at db_enter+0x4
panic(d0bf0a66) at panic+0xd3
ffs_blkfree(f5793c68,47810,0) at ffs_blkfree+0x828
ffs_indirtrunc(f5793c68,87f4,,1357a0,0,) at
ffs_indirtrunc+
0x34a
ffs_indirtrunc(f5793c68,f7f3,,141ee0,0,) at
ffs_indirtrunc+
0x30a
ffs_truncate(f5793c68,0,0,0) at ffs_truncate+0xbb2
ufs_setattr(f5adc458) at ufs_setattr+0x2ab
VOP_SETATTR(d1fe7300,f5adc4a0,d2277240,f5f16dc8) at VOP_SETATTR+0x47
vn_open(f5adc550,602,1a4) at vn_open+0x26a
doopenat(f5f16dc8,ff9c,49f50e68,601,1b6,f5adc6b8) at doopenat+0x16e
sys_open(f5f16dc8,f5adc6c0,f5adc6b8) at sys_open+0x1b
syscall(f5adc700) at syscall+0x28e
Xsyscall_untramp() at Xsyscall_untramp+0xa9
end of kernel
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
Hope this helps, thanks for looking.
J.
Re: calendars: David Bowie died on 2016-01-10, not -11.
On Fri, Jan 08, 2021 at 08:09:59PM +0100, Steffen Nurpmeso wrote: > Two days after his 69th birthday. > fixed, thanks. jmc
Re: vmt(4) module does not correctly report IP address to vCenter
Gotcha. Requiring a pkg_add and rcctl basically makes it inline with every other OS that reports to VMWare; having a kernel driver is the exception rather than the rule. I don't have any issues with the solution as long as I can get proper metadata reported to vCenter. Is the port available for me to test on my end? Do I need to grab the ports tree from source and compile from there or is it already available via pkg_add? Cheers, Alex On Fri, Jan 8, 2021, at 12:29 PM, Klemens Nanni wrote: > On Fri, Jan 08, 2021 at 11:58:25AM -0700, Alex Long wrote: > > Okay. So going forward, vmt(4) is being deprecated in favor of the new > > open-vm-tools port? > The package can do everything the driver does and more, but it also > requires pkg_add and rcctl to work opposed to just a default base > installation in order to automatically provide basic information to the > host. > > Since package and driver do not seem to conflict according to my tests, > there's no need to directly remove vmt(4) after importing the package. > > In the long run however --if there are no problems with open-vm-tools > on OpenBSD-- I don't see why we should keep and maintain our own driver. > > vmt(4) came to be before open-vm-tools was a thing and until now noone > simply ported it to OpenBSD; other than that, there seem to be no > specific reasons not to use upstream's code. >
Re: vmt(4) module does not correctly report IP address to vCenter
On Fri, Jan 08, 2021 at 11:58:25AM -0700, Alex Long wrote: > Okay. So going forward, vmt(4) is being deprecated in favor of the new > open-vm-tools port? The package can do everything the driver does and more, but it also requires pkg_add and rcctl to work opposed to just a default base installation in order to automatically provide basic information to the host. Since package and driver do not seem to conflict according to my tests, there's no need to directly remove vmt(4) after importing the package. In the long run however --if there are no problems with open-vm-tools on OpenBSD-- I don't see why we should keep and maintain our own driver. vmt(4) came to be before open-vm-tools was a thing and until now noone simply ported it to OpenBSD; other than that, there seem to be no specific reasons not to use upstream's code.
Re: 6.6 GENERIC #583 amd64 Crashes after booting on ACER Aspire 3
Sorry for the noise but can someone please show me how i can reply to a thread not in my inbox? i tried 2 times (with In-Reply-To too) without luck, thanks in advance. This time i tried to reply to this one: https://marc.info/?l=openbsd-bugs=157814906618852=2 On Fri, Jan 08, 2021 at 08:09:26PM +0100, Alex Raschi wrote: > Hi, > > I have the same laptop and i installed openbsd on it a few days ago, i > compared the dmesg of bsd.rd and bsd.sp/bsd.mp and i found a workaround: > > At boot prompt (disable the piixpm driver): > > boot> boot -c > UKC> disable piixpm > UKC> quit > > I checked piixpm(4) but i'm not 100% sure what this driver do, anyway > with this my laptop does not shutdown anymore. > > Alex
calendars: David Bowie died on 2016-01-10, not -11.
Two days after his 69th birthday. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: 6.6 GENERIC #583 amd64 Crashes after booting on ACER Aspire 3
Hi, I have the same laptop and i installed openbsd on it a few days ago, i compared the dmesg of bsd.rd and bsd.sp/bsd.mp and i found a workaround: At boot prompt (disable the piixpm driver): boot> boot -c UKC> disable piixpm UKC> quit I checked piixpm(4) but i'm not 100% sure what this driver do, anyway with this my laptop does not shutdown anymore. Alex
Re: vmt(4) module does not correctly report IP address to vCenter
Okay. So going forward, vmt(4) is being deprecated in favor of the new open-vm-tools port? Thanks, Alex On Fri, Jan 8, 2021, at 2:53 AM, Klemens Nanni wrote: > On Thu, Jan 07, 2021 at 09:45:31PM +0100, Klemens Nanni wrote: > > A quick look at upstream seems to indicate that they still use > > `info-set guestinfo.ip %s', but there's also much more in the > > open-vm-tools code I didn't look at (yet): > > > > https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/guestInfo/guestInfoServer.c#L2327 > > > I just sent a new port for open-vm-tools to ports@ that works just fine > with and without vmt(4) running while proving NicInfo objects and much > more. > > This should fix Packer as well. >
pf route-to option does not consider MTU and/or MSS of specified interface
>Synopsis: pf route-to option does not consider MTU and/or MSS of >specified interface >Category: system pf documentation >Environment: System : OpenBSD 6.8 Details : OpenBSD 6.8 (GENERIC.MP) #2: Sat Dec 5 07:17:48 MST 2020 r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: In pf.conf configuration file, when using route-to in order to route packets using another interface, the packets routed this way are not linked with the MTU of the outgoing interface, but keep MTU value of the original route. >How-To-Repeat: Considering two network interfaces: em0 (egress) with MTU=1500 (default route set here) wg0 (wirguard) with MTU=1420 In pf.conf : pass out on em0 from wg0 route-to wg0 #if source addr belong to wireguard, we use its interface to go out Outgoing packets will consider having MTU of 1500 instead of 1420. The issue here is mostly linked to having a wrong mss value computed in outgoing tcp connections. (1460 instead of 1380 for ipv4) >Fix: This can be easily worked around: pass out on em0 from wg0 route-to wg0 scrub (max-mss 1380) but would be better to automatically adapt MTU/MSS of redirected packets to the one of the new interface. Or, at least warn in the documentation (FAQ & man pf.conf) that user should take care MSS when using route-to option set when using interfaces with different MTUs. dmesg: OpenBSD 6.8 (GENERIC.MP) #2: Sat Dec 5 07:17:48 MST 2020 r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8451870720 (8060MB) avail mem = 8180682752 (7801MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec2f0 (81 entries) bios0: vendor American Megatrends Inc. version "1.06" date 03/04/2015 bios0: Shuttle Inc. DS57U acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SLIC SSDT SSDT SSDT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz, 1995.71 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz, 1995.40 MHz, 06-3d-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz, 1995.39 MHz, 06-3d-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz, 1995.39 MHz, 06-3d-04 cpu3:
Re: panic: Non dma-reachable buffer, ix(4)
Hi, this problem has been fixed with a recent commit by sashan@ to sys/netinet/ip_carp.c ip_carp.c,v 1.350 2021/01/04 15:02:34 sashan It is the same issue as discussed in this thread: https://marc.info/?t=16040828376=1=2 /Benno Sebastian Benoit(be...@openbsd.org) on 2020.12.18 19:24:57 +0100: > Hi, > > we observed similar panics on two systems, both have ix(4) network cards and > function as routers/firewalls. > > On both the following panic was seen, after around 15 days of uptime on each > box, afew days apart. > > Both have ix(4) "Intel 82599" rev 0x01, with two 10GBit/s SFP+ in them. > > Unfortunatly there is no coredump even though it looks like it was > succesfully written to disk. > > We have switched to db.panic=1 now, in case it happens again. > > Anything we should try/do? > > panic message and dmesg below. > > Thanks, > Benno > > > > panic: Non dma-reachable buffer at curaddr 0xfd847d21cd40(raw) > Starting stack trace... > panic(81e43181) at panic+0x11d > _bus_dmamap_load_buffer(1,80b77800,50ce540409a3eb84,175b2415,0,20) at > _bus_dmamap_load_buffer+0x19e > _bus_dmamap_load_mbuf(82100818,80b77800,fd8065d7ba00,1) > at _bus_dmamap_load_mbuf+0x93 > ixgbe_encap(8025f290,fd8065d7ba00) at ixgbe_encap+0x67 > ixgbe_start(8025f600) at ixgbe_start+0xcf > ifq_serialize(8025f600,8025f6e0) at ifq_serialize+0xfd > taskq_thread(80044080) at taskq_thread+0x81 > end trace frame: 0x0, count: 250 > End of stack trace. > syncing disks... done > fatal protfeactatil opn roftauecltt ioinn fsaupuletrv iinso sru mpeordevi > storr apmo dtye > pe tr4 acp odteyp 0e 4ri pco fdfe ff0f rffifp 81f4ff7ef1ff04f f8cs1 478 > drc1fl4a cgss 810 2rf82l agcrs2 1 602282a2c c52r02 10e 39cp2l31 74 b5rs0p0 > fcfplff 87 00r0sp1e 8ff97fcf8c00 > 00g1se8ba8sc9e 000 > xffgsffbfasffef 082x0ffe5fff8f00 00 k1ge3sb5a0fsef 0 0x 0kg > sbpaansei c:0x 0tr > app antiypc:e 4tr, acp odteyp=0e, 4 p,c c=fofdeff=f0,ff fpc81=4ff7ef1ff04f > ff8St14a7rtdci1ng4 > stFaaucklt etrd aicen. t..r > acepbaancki,c( afbfforftffinfgf8..1.dd > f041) at panic+0x11d > kerntrap(80001e897c10) at kerntrap+0x114 > alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b > pool_p_alloc(821d04d8,2,80001e897de4) at pool_p_alloc+0x1a4 > pool_do_get(821d04d8,2,80001e897de4) at pool_do_get+0xd2 > pool_get(821d04d8,2) at pool_get+0x8f > m_clget(0,2,802) at m_clget+0x1b4 > ixgbe_get_buf(8023d600,61) at ixgbe_get_buf+0xa3 > ixgbe_rxfill(8023d600) at ixgbe_rxfill+0x93 > ixgbe_queue_intr(80252600) at ixgbe_queue_intr+0x4f > intr_handler(80001e897ff0,80257680) at intr_handler+0x6e > Xintr_ioapic_edge17_untramp() at Xintr_ioapic_edge17_untramp+0x19f > srp_follow(80001e8980c0,fd83befd8100) at srp_follow+0x17 > rtable_walk_helper(fd83cfaea460,80001e8984b0) at > rtable_walk_helper+0x66 > art_table_walk(8024f6c0,fd83bd391690,81285930,80001e8984b0) > at art_table_walk+0x215 > art_table_walk(8024f6c0,fd83aa004020,81285930,80001e8984b0) > at art_table_walk+0x279 > art_table_walk(8024f6c0,fd83bfaab9b0,81285930,80001e8984b0) > at art_table_walk+0x279 > art_table_walk(8024f6c0,fd83bfde0eb0,81285930,80001e8984b0) > at art_table_walk+0x279 > art_table_walk(8024f6c0,fd84838474a0,81285930,80001e8984b0) > at art_table_walk+0x279 > art_walk(8024f6c0,81285930,80001e8984b0) at art_walk+0xd3 > rtable_walk(0,2,80001e898548,81346270,8025b048) at > rtable_walk+0xa0 > rt_if_track(8025b048) at rt_if_track+0xda > if_down(8025b048) at if_down+0xa8 > if_downall() at if_downall+0x5b > boot(100) at boot+0x99 > reboot(100) at reboot+0x5b > panic(81e43181) at panic+0x125 > _bus_dmamap_load_buffer(1,80b77800,50ce540409a3eb84,175b2415,0,20) at > _bus_dmamap_load_buffer+0x19e > _bus_dmamap_load_mbuf(82100818,80b77800,fd8065d7ba00,1) > at _bus_dmamap_load_mbuf+0x93 > ixgbe_encap(8025f290,fd8065d7ba00) at ixgbe_encap+0x67 > ixgbe_start(8025f600) at ixgbe_start+0xcf > ifq_serialize(8025f600,8025f6e0) at ifq_serialize+0xfd > taskq_thread(80044080) at taskq_thread+0x81 > end trace frame: 0x0, count: 224 > End of stack trace. > > dumping to dev 4,1 offset 1724333 > dump 16165 [...] 3 2 1 succeeded > > > boot> [04;00Hdisk: hd0+ > [05;00H>> OpenBSD/amd64 BOOT 3.52 > [06;00Hswitching console to com1 > [07;00H > [08;00H > [09;00H
Re: vmt(4) module does not correctly report IP address to vCenter
On Thu, Jan 07, 2021 at 09:45:31PM +0100, Klemens Nanni wrote: > A quick look at upstream seems to indicate that they still use > `info-set guestinfo.ip %s', but there's also much more in the > open-vm-tools code I didn't look at (yet): > > https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/guestInfo/guestInfoServer.c#L2327 > I just sent a new port for open-vm-tools to ports@ that works just fine with and without vmt(4) running while proving NicInfo objects and much more. This should fix Packer as well.
Re: select performance regression
On Thu, Jan 07, 2021 at 05:49:48PM +0100, Alexander Bluhm wrote: > As you can see here, the iperf3 udp performance dropped by 29% at 22nd > December. > http://bluhm.genua.de/perform/results/2021-01-05T15%3A48%3A19Z/gnuplot/udp.png > > All numbers for each commit at that day are here: > http://bluhm.genua.de/perform/results/2021-01-05T15%3A48%3A19Z/perform.html > > It is caused by this commit: > Implement select(2) and pselect(2) on top of kqueue. > http://bluhm.genua.de/perform/results/cvslog/src/sys/2020-12-22T12%3A59%3A05Z--2020-12-22T13%3A24%3A45Z.html Thank you for reporting this. I have reverted the change.
