Re: intermittent keyboard freezes
Not sure if my case is exactly related, but I experienced a similar issue with some variation. In my situation for OpenBSD current and previous releases, sometimes (!) the whole system freezes, the screen turns black and GPU fan starts throttling rhythmically up and down. Only hard reboot with power button helps. Similarly to you, I also have AMD card (mine is RX580), and strange coincidence - it is also Polaris arch (Polaris20 in my case). Now to the most interesting part - I also experience very rare but same issues on Linux 6.1.20, and I did report the problem happening always (!) on NetBSD-current (https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=56566). Obviously, these references mean little here, as drm and amdgpu driver implementations differ between systems, but more important is a pattern - this sounds like some bug either in original amdgpu driver contributed to Linux and ported elsewhere, or with polaris firmware. Hope that provides some insights to whoever might be further looking into the issue. On Sat, 15 Apr 2023, at 00:45, Allan Streib wrote: > I've had this problem for a while, over several releases. > > Keyboard will freeze up (key presses do nothing). Mouse pointer > can be moved but clicks do nothing. Only solution was to reboot > using the power button, which does trigger a clean shutdown. > > I've been chalking it up to some kind of hardware issue. Nothing > is ever logged. But today it happened again, and I found these > messages in /var/log/messages just before the reboot: > > Apr 14 18:17:50 fabrik /bsd: [drm] *ERROR* ring sdma1 timeout, signaled > seq=10792, emitted seq=10792 > Apr 14 18:17:50 fabrik /bsd: [drm] *ERROR* Process information: process > pid 0 thread pid 0 > Apr 14 18:17:50 fabrik /bsd: amdgpu_device_suspend_display_audio: stub > > dmesg below, happy for any suggestions what this might mean, or > is it likely unrelated, or what additional info may be helpful. > > > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17103970304 (16311MB) > avail mem = 16566206464 (15798MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed5e0 (86 entries) > bios0: vendor American Megatrends Inc. version "V10.6" date 08/13/2015 > bios0: MSI MS-7922 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT ASF! SSDT SSDT SSDT MCFG HPET > SSDT SSDT UEFI DMAR > 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) i7-4770 CPU @ 3.40GHz, 3400.12 MHz, 06-3c-03 > 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3400.12 MHz, 06-3c-03 > 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3400.24 MHz, 06-3c-03 > 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBD
InfluxDB stopped working on OpenBSD 7.3
I have a fresh OpenBSD 7.3 install (no update) with InfluxDB installed
from packages.
When I try to start it, it did start initially, but eventually it
crashed. Now I can't start it again.
It complains about bad system call. Could that be related to latest
security features?
Below is rcctl -d output. I'd be thankful for any suggestions.
dev# rcctl -d start influxdb
doing _rc_parse_conf
influxdb_flags empty, using default ><
doing rc_check
influxdb
doing rc_start
doing _rc_wait_for_start
doing rc_check
influxdb[2285]: ts=2023-04-15T00:19:33.358242Z lvl=info msg="InfluxDB
starting" log_id=0hC_LoRW000 version=unknown branch=unknown
commit=unknown
influxdb[2285]: ts=2023-04-15T00:19:33.358479Z lvl=info msg="Go
runtime" log_id=0hC_LoRW000 version=go1.20.1 maxprocs=1
influxdb[2285]: ts=2023-04-15T00:19:33.383092Z lvl=info msg="Using data
dir" log_id=0hC_LoRW000 service=store path=/var/influxdb/data
influxdb[2285]: ts=2023-04-15T00:19:33.383498Z lvl=info msg="Compaction
settings" log_id=0hC_LoRW000 service=store max_concurrent_compactions=1
throughput_bytes_per_second=50331648
throughput_bytes_per_second_burst=50331648
influxdb[2285]: ts=2023-04-15T00:19:33.383565Z lvl=info msg="Open store
(start)" log_id=0hC_LoRW000 service=store trace_id=0hC_LoXl000
op_name=tsdb_open op_event=start
influxdb[2285]: SIGSYS: bad system call
influxdb[2285]: PC=0x23c8afdf7 m=0 sigcode=0
influxdb[2285]:
influxdb[2285]: goroutine 0 [idle]:
influxdb[2285]: syscall.rawSyscall10X(0x1d704e0, 0xc5, 0x0, 0x10248,
0x1, 0x1, 0x18, 0x0, 0x0, 0x0, ...)
influxdb[2285]: runtime/sys_openbsd3.go:114 +0x4d
fp=0xc6d820 sp=0xc6d800 pc=0x1d10bad
influxdb[2285]: syscall.rawSyscall10X(0x0?, 0xc6d900?, 0x1ce9291?,
0x1?, 0x0?, 0xc0002b7380?, 0xc6d900?, 0x0?, 0xc6d938?, 0x0,
...)
influxdb[2285]: :1 +0x59 fp=0xc6d8a0
sp=0xc6d820 pc=0x1d16d79
influxdb[2285]: syscall.syscall9Internal(0xc0002b7380?, 0x20003?,
0xc6d958?, 0x1ce89e5?, 0xc0002b7380?, 0xc6d978?, 0x1d0eabb?,
0xc0002b7380?, 0x20003?, 0x0)
influxdb[2285]: syscall/syscall_openbsd_libc.go:38 +0x49
fp=0xc6d908 sp=0xc6d8a0 pc=0x1d6a489
influxdb[2285]: syscall.syscall9Internal(0xc5, 0x0, 0x10248, 0x1, 0x1,
0x18, 0x0, 0x0, 0x0, 0x0)
influxdb[2285]: :1 +0x68 fp=0xc6d968
sp=0xc6d908 pc=0x1d70f08
influxdb[2285]: golang.org/x/sys/unix.mmap(0x1d6d534?, 0x0?,
0xc6da60?, 0xc6da18?, 0x1d90366?, 0xc0005275f8?)
influxdb[2285]:
golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_openbsd_amd64.go:1639+0x52fp=0xc6d9e8sp=0xc6d968pc=0x2062532
influxdb[2285]: golang.org/x/sys/unix.(*mmapper).Mmap(0x2a60da0,
0xc6dab0?, 0xcc4900?, 0x10248, 0xc6db20?, 0x1d902cc?)
influxdb[2285]:
golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/syscall_unix.go:113+0x89fp=0xc6da90sp=0xc6d9e8pc=0x2061d69
influxdb[2285]: golang.org/x/sys/unix.Mmap(...)
influxdb[2285]:
golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/syscall_bsd.go:650
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1.mmap(0xc0003a61d0?,
0xc0003a61d0?, 0x60?)
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1/mmap_unix.go:18 +0x65
fp=0xc6dad8sp=0xc6da90pc=0x29b5d65
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*mmapAccessor).init(0x
c000430d20)
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1/reader.go:1335 +0x113
fp=0xc6db70sp=0xc6dad8pc=0x29bedf3
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1.NewTSMReader(0xc0003a61
d0, {0xc6dc80, 0x1, 0x0?})
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1/reader.go:239 +0x18d
fp=0xc6dbe8sp=0xc6db70pc=0x29b802d
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*FileStore).Open.func1
(0x0, 0xc0003a61d0)
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1/file_store.go:543
+0x115fp=0xc6dfc0sp=0xc6dbe8pc=0x299f1d5
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*FileStore).Open.func3
()
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1/file_store.go:565
+0x2efp=0xc6dfe0sp=0xc6dfc0pc=0x299f08e
influxdb[2285]: runtime.goexit()
influxdb[2285]: runtime/asm_amd64.s:1598 +0x1 fp=0xc6dfe8
sp=0xc6dfe0 pc=0x1d14141
influxdb[2285]: created by
github.com/influxdata/influxdb/tsdb/engine/tsm1.(*FileStore).Open
influxdb[2285]:
github.com/influxdata/influxdb/tsdb/engine/tsm1/file_store.go:535 +0x4a5
influxdb[2285]:
influxdb[2285]: goroutine 16 [running]:
influxdb[2285]: runtime.systemstack_switch()
influxdb[2285]: runtime/asm_amd64.s:463 fp=0xc6d7d0
sp=0xc6d7c8 pc=0x1d11f00
influxdb[2285]: runtime.libcCall(0x0?, 0xc0002b7380?)
influxdb[2285]: runtime/sys_libc.go:49 +0x66 fp=0xc6d800
sp=0xc6d7d0 pc=0x1cfdee6
influxdb[2285]: syscall.rawSyscall10X(0x1d704e0, 0xc5, 0x0, 0x10248,
0x1, 0x
intermittent keyboard freezes
I've had this problem for a while, over several releases. Keyboard will freeze up (key presses do nothing). Mouse pointer can be moved but clicks do nothing. Only solution was to reboot using the power button, which does trigger a clean shutdown. I've been chalking it up to some kind of hardware issue. Nothing is ever logged. But today it happened again, and I found these messages in /var/log/messages just before the reboot: Apr 14 18:17:50 fabrik /bsd: [drm] *ERROR* ring sdma1 timeout, signaled seq=10792, emitted seq=10792 Apr 14 18:17:50 fabrik /bsd: [drm] *ERROR* Process information: process pid 0 thread pid 0 Apr 14 18:17:50 fabrik /bsd: amdgpu_device_suspend_display_audio: stub dmesg below, happy for any suggestions what this might mean, or is it likely unrelated, or what additional info may be helpful. OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17103970304 (16311MB) avail mem = 16566206464 (15798MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed5e0 (86 entries) bios0: vendor American Megatrends Inc. version "V10.6" date 08/13/2015 bios0: MSI MS-7922 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT ASF! SSDT SSDT SSDT MCFG HPET SSDT SSDT UEFI DMAR 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) i7-4770 CPU @ 3.40GHz, 3400.12 MHz, 06-3c-03 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3400.12 MHz, 06-3c-03 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3400.24 MHz, 06-3c-03 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3400.25 MHz, 06-3c-03 cpu3: 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,SMX,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0
Re: ixl not seeing SFP+ modules ?
The Intel 710 only works with Intel brand optics. It is possible you can find optics which will report as Intel, though I've never tried. I do use FlexOptix programmable optics in various network devices. When I get to the office I'll plug in the programmer and see if it can code Intel optic info. 73 diana On April 14, 2023 11:39:06 AM MDT, Theo de Raadt wrote: >Welcome to the world of vendor optic locking. > >Laura Smith wrote: > >> I have an ixl card (ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev >> 0x02: port 3, FW 6.0.48442 API 1.7, msix, 4 queues) on OpenBSD that doesn't >> seem to be seeing any of my SFP+ modules. >> >> >> The modules are all MSA coded and from different manufacturers. >> >> >> ifconfig ixl shows "status: no carrier" (but light is confirmed as existing >> both ways and all patching has been triple checked). >> >> Additionally "ifconfig ixl transciever" reports "ifconfig: transciever: bad >> value" whilst I believe this should be showing transceiver stats ? >> >> >> Am I missing something here ? >> >
Re: ixl not seeing SFP+ modules ?
On 2023-04-14, Laura Smith wrote: > I have an ixl card (ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: > port 3, FW 6.0.48442 API 1.7, msix, 4 queues) on OpenBSD that doesn't seem to > be seeing any of my SFP+ modules. > > > The modules are all MSA coded and from different manufacturers. > > ifconfig ixl shows "status: no carrier" (but light is confirmed as existing > both ways and all patching has been triple checked). ixl can be vendor locked in firmware. also iirc they can be funny about when the module was plugged in, if it was hotplugged try rebooting, though vendor lock is more likely. > Additionally "ifconfig ixl transciever" reports "ifconfig: transciever: bad > value" whilst I believe this should be showing transceiver stats ? typo, "transceiver" (or "sff").
Re: carp status master on both firewalls
--- Original Message --- On Friday, April 14th, 2023 at 7:14 AM, Janne Johansson wrote: > Not impossible to have switches(*) that dislike/filter/bug on > multicast too I guess, so I would suggest rigging the carps up (at > least temporary) with carppeer against the "real" ip of the remote > ext_if to make carp use normal unicast ip for sync and just see if it > helps. If it does, it is related to the boxes ability to talk > multicast and you would have to either stick with carppeer setup, or > "fix" the multicast issue, which can be hard to pin down where exactly > it is. Thank you Janne for pointing out the switch. I would have never thought about that. So indeed, I just upgraded my Cisco Catalyst 2960L switch the latest IOS version of 2022 and now the 2nd firewall correctly reports backup as status. I was running an IOS version from 2018. Strangely enough both firewalls are connected to that switch with both carp0 to the public VLAN and both carp1 to the private VLAN so I would have expected the same odd double master status on both carp interfaces and not just on carp0. But anyway it works now.
Re: ixl not seeing SFP+ modules ?
On 14.4.2023. 19:36, Laura Smith wrote: > I have an ixl card (ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: > port 3, FW 6.0.48442 API 1.7, msix, 4 queues) on OpenBSD that doesn't seem to > be seeing any of my SFP+ modules. > > > The modules are all MSA coded and from different manufacturers. > > > ifconfig ixl shows "status: no carrier" (but light is confirmed as existing > both ways and all patching has been triple checked). > > Additionally "ifconfig ixl transciever" reports "ifconfig: transciever: bad > value" whilst I believe this should be showing transceiver stats ? > > Hi, try ifconfig ixl0 sff if you have some other 10G card ix(4) x520 intel or bnxt, try put that sfp+ in them, maybe there will work, or just buy intel compatible sfp+ from fs.com or similar stores ...
Re: pkg_info -Q confusion
> Am 14.04.2023 um 18:24 schrieb Allan Streib :
>
> On Fri, Apr 14, 2023, at 05:50, Stuart Henderson wrote:
>> I never found pkg_info -Q to be a useful tool.
>>
>> Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
>> searching on an index that is built from : - as a
>> result it lets you do a substring match on package names, not just
>> on filenames.
>
> Also, as mentioned in packages(7) man page, there is a site at
> https://openports.pl/ that can be used, though obviously that requires
> internet access so may not be appropriate for all cases. I tend to
> use it a lot, personally.
It does not seem to differentiate between different OpenBSD versions or
architectures though?
I’m generally interested in what is available for the exact machine I am
running on. But I guess at least knowing that there is a port for some version
on some platform might be helpful — at least the inverse means I can stop
looking now ;-)
But still thanks for reminding me of this site. I had forgotten about that.
Mike
Re: carp status master on both firewalls
--- Original Message --- On Friday, April 14th, 2023 at 10:50 AM, Markus Wernig wrote: Thank you Markus for your answer, as mentioned to Janne it was the switch the problem. For the sake of documenting I answered your questions below. > - Do the two fw actually have a link on their carp0 carpdev interfaces? Yes. > If both are master, both should be sending out CARP advertisements, so > I'd try to run tcpdump on both external interfaces and look for those: > tcpdump -n -e -i carp0 proto carp I did that yesterday and for both firewalls I could see the CARPv2 advertisements. > - Did you enable CARP preemption? Try setting these via sysctl: > net.inet.carp.preempt=1 > net.inet.carp.log=3 I have CARP preemption enabled but my carp log level is 2 and not 3. > - In your config one fw has carpdev em2, the other carpdev em0. Could be > OK, or could be an error. Well spotted but indeed it is correct, both firewalls have different hardware and the first interface on the first firewall is em2 whereas on the 2nd firewall it is em0.
Re: ixl not seeing SFP+ modules ?
Welcome to the world of vendor optic locking. Laura Smith wrote: > I have an ixl card (ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: > port 3, FW 6.0.48442 API 1.7, msix, 4 queues) on OpenBSD that doesn't seem to > be seeing any of my SFP+ modules. > > > The modules are all MSA coded and from different manufacturers. > > > ifconfig ixl shows "status: no carrier" (but light is confirmed as existing > both ways and all patching has been triple checked). > > Additionally "ifconfig ixl transciever" reports "ifconfig: transciever: bad > value" whilst I believe this should be showing transceiver stats ? > > > Am I missing something here ? >
ixl not seeing SFP+ modules ?
I have an ixl card (ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 3, FW 6.0.48442 API 1.7, msix, 4 queues) on OpenBSD that doesn't seem to be seeing any of my SFP+ modules. The modules are all MSA coded and from different manufacturers. ifconfig ixl shows "status: no carrier" (but light is confirmed as existing both ways and all patching has been triple checked). Additionally "ifconfig ixl transciever" reports "ifconfig: transciever: bad value" whilst I believe this should be showing transceiver stats ? Am I missing something here ?
Re: After sysupgrade, computer hangs after efi0
On 4/14/23 3:08 AM, Stuart Henderson wrote: On 2023-04-13, Jeff Ross wrote: On 4/12/23 12:22 PM, Jeff Ross wrote: OpenBSD 7.3 (GENERIC.MP) #1125 Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8469549056 (8077MB) avail mem = 8193462272 (7813MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe8ad9 (27 entries) bios0: vendor Hewlett-Packard version "L04 v02.16" date 03/24/2015 bios0: Hewlett-Packard HP EliteDesk 800 G1 DM efi0 at bios0: UEFI 2.3.1 efi0: American Megatrends rev 0x4028e I was able to "Upgrade" back to 7.2. Below is the dmesg from the installed 7.2. How can I force 7.3 to use acpi0 instead of efi0? Note that in this state you will have newer libraries on the system; this is likely to give some issues if you compile anything from source Good point. I don't have to very often but don't want to be locked out of the possibility. [..] I suggest generating a sendbug template from 7.2, run as root to include all the information, and send it to bugs@ sendbug will be on its way shortly. Thanks! Jeff
Re: After sysupgrade, computer hangs after efi0
On 4/14/23 9:14 AM, Rod Person wrote: On Wed, 12 Apr 2023 12:22:14 -0600 Jeff Ross wrote: Hi all, I did a sysupgrade from 7.2 to 7.3 on an HP EliteDesk (amd64). The upgrade went great but now the computer will not boot. I also have the same issue and I also have an HP Elite (8300)... I was able to get around this by doing: boot> boot -c UKC> disable efi Thanks! I'll give this a try. Jeff
Re: After sysupgrade, computer hangs after efi0
On Wed, 12 Apr 2023 12:22:14 -0600 Jeff Ross wrote: > Hi all, > > I did a sysupgrade from 7.2 to 7.3 on an HP EliteDesk (amd64). The > upgrade went great but now the computer will not boot. > I also have the same issue and I also have an HP Elite (8300)... I was able to get around this by doing: boot> boot -c UKC> disable efi -- Rod https://rodperson.com He who seeks the real no longer puts any trust in appearance. -The Sage Her-Bak, Egyptian Initiate Isha Schwaller De Lubicz
Re: pkg_info -Q confusion
On Fri, Apr 14, 2023, at 05:50, Stuart Henderson wrote:
> I never found pkg_info -Q to be a useful tool.
>
> Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
> searching on an index that is built from : - as a
> result it lets you do a substring match on package names, not just
> on filenames.
Also, as mentioned in packages(7) man page, there is a site at
https://openports.pl/ that can be used, though obviously that requires
internet access so may not be appropriate for all cases. I tend to
use it a lot, personally.
Re: pkg_info -Q confusion
Inline…
> Am 14.04.2023 um 12:50 schrieb Stuart Henderson :
>
> On 2023-04-14, Mike Fischer wrote:
>> Usually when looking for a port to install I use `pkg_info -Q name` to
>> search for the the port.
>>
>> Strangely this does not completely work for PHP on OpenBSD 7.3:
>>
>> `pkg_info -Q php` does not list PHP 7.4.33 and related ports which are
>> clearly available.
>>
>> It seems that -Q only finds ports in packages-stable/, not packages/?
>>
>> pkg_info(1) does not seem to mention this limitation (or I have missed it).
>
> That's what is meant by "in the first repository of the package search
> path" but it's not very obvious.
Ah, I see. Indeed I didn’t realise that was meant by the statement.
> If PKG_PATH is not set and you're on a release version, the
> pkg_add-based tools (including pkg_info) construct one starting with
> the packages-stable directory, in order that -stable updates are
> preferred over release packages. This is (mostly) described in
> pkg_add(1).
>
> You can search just the release packages with
>
> PKG_PATH=http://cdn.openbsd.org/pub/OpenBSD/%v/packages/%a/ pkg_info -Q php
Ok, thanks. Not very comfortable but at least a possibility.
>
>> Is this working as intended?
>
> Yes though it's a little unfriendly.
Yep!
>
>> Is there a better way to look for available packages?
>
> I never found pkg_info -Q to be a useful tool.
Up to now I never had an issue. But I never noticed this limitation before. (I
did notice the lack of being able to search for partial package names but I
have gotten used to that.)
> Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
> searching on an index that is built from : - as a
> result it lets you do a substring match on package names, not just
> on filenames.
>
> For a package which includes many files you'll get a lot of output
> lines, so something like "pkglocate moo | cut -d: -f1 | uniq" maybe
> useful, or "pkglocate moo | grep ^moo".
>
> And if you're looking for the package containing a particular
> binary, "pkglocate bin/moo" cuts out a lot of the useless stuff.
Very helpful!
Thanks Stuart!
Mike
Re: pkg_info -Q confusion
On 2023-04-14, Mike Fischer wrote:
> Usually when looking for a port to install I use `pkg_info -Q name` to
> search for the the port.
>
> Strangely this does not completely work for PHP on OpenBSD 7.3:
>
> `pkg_info -Q php` does not list PHP 7.4.33 and related ports which are
> clearly available.
>
> It seems that -Q only finds ports in packages-stable/, not packages/?
>
> pkg_info(1) does not seem to mention this limitation (or I have missed it).
That's what is meant by "in the first repository of the package search
path" but it's not very obvious.
If PKG_PATH is not set and you're on a release version, the
pkg_add-based tools (including pkg_info) construct one starting with
the packages-stable directory, in order that -stable updates are
preferred over release packages. This is (mostly) described in
pkg_add(1).
You can search just the release packages with
PKG_PATH=http://cdn.openbsd.org/pub/OpenBSD/%v/packages/%a/ pkg_info -Q php
> Is this working as intended?
Yes though it's a little unfriendly.
> Is there a better way to look for available packages?
I never found pkg_info -Q to be a useful tool.
Try pkglocate instead ("pkg_add pkglocatedb" first) which allows
searching on an index that is built from : - as a
result it lets you do a substring match on package names, not just
on filenames.
For a package which includes many files you'll get a lot of output
lines, so something like "pkglocate moo | cut -d: -f1 | uniq" maybe
useful, or "pkglocate moo | grep ^moo".
And if you're looking for the package containing a particular
binary, "pkglocate bin/moo" cuts out a lot of the useless stuff.
pkg_info -Q confusion
Usually when looking for a port to install I use `pkg_info -Q name` to search for the the port. Strangely this does not completely work for PHP on OpenBSD 7.3: `pkg_info -Q php` does not list PHP 7.4.33 and related ports which are clearly available. It seems that -Q only finds ports in packages-stable/, not packages/? pkg_info(1) does not seem to mention this limitation (or I have missed it). Is this working as intended? Is there a better way to look for available packages? Thanks! Mike
Re: carp status master on both firewalls
for my external carp interface both firewalls show master as status
The config is below for reference:
/etc/hostname.carp0 on fw1
inet x.x.x.114 255.255.255.240 x.x.x.127 vhid 40 carpdev em2 pass password
advskew 1
inet alias x.x.x.115 0xfff0
inet alias x.x.x.116 0xfff0
/etc/hostname.carp0 on fw2
inet x.x.x.114 255.255.255.240 x.x.x.127 vhid 40 carpdev em0 pass password advskew 128
inet alias x.x.x.115 0xfff0
inet alias x.x.x.116 0xfff0
On both firewalls I have added the following in /etc/pf.conf:
pass on { $ext_if $int_if } proto carp keep state (no-sync)
Did anyone already encounter this issue or has any idea what might be wrong?
Hard to tell without logs. Some things that come to mind:
- Do the two fw actually have a link on their carp0 carpdev interfaces?
If both are master, both should be sending out CARP advertisements, so
I'd try to run tcpdump on both external interfaces and look for those:
tcpdump -n -e -i carp0 proto carp
- Did you enable CARP preemption? Try setting these via sysctl:
net.inet.carp.preempt=1
net.inet.carp.log=3
- In your config one fw has carpdev em2, the other carpdev em0. Could be
OK, or could be an error.
Re: After sysupgrade, computer hangs after efi0
On 2023-04-13, Jeff Ross wrote: > On 4/12/23 12:22 PM, Jeff Ross wrote: >> >> OpenBSD 7.3 (GENERIC.MP) #1125 Sat Mar 25 10:36:29 MDT 2023 >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> real mem = 8469549056 (8077MB) >> avail mem = 8193462272 (7813MB) >> random: good seed from bootblocks >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe8ad9 (27 entries) >> bios0: vendor Hewlett-Packard version "L04 v02.16" date 03/24/2015 >> bios0: Hewlett-Packard HP EliteDesk 800 G1 DM >> efi0 at bios0: UEFI 2.3.1 >> efi0: American Megatrends rev 0x4028e > I was able to "Upgrade" back to 7.2. Below is the dmesg from the > installed 7.2. How can I force 7.3 to use acpi0 instead of efi0? Note that in this state you will have newer libraries on the system; this is likely to give some issues if you compile anything from source > OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8469549056 (8077MB) > avail mem = 8195461120 (7815MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe8ad9 (27 entries) > bios0: vendor Hewlett-Packard version "L04 v02.16" date 03/24/2015 > bios0: Hewlett-Packard HP EliteDesk 800 G1 DM > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT SSDT SSDT SSDT MCFG HPET SSDT SSDT > SSDT SLIC ASF! TCPA > acpi0: wakeup devices PS2K(S3) PS2M(S3) PXSX(S4) PXSX(S4) PXSX(S4) > PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) > XHC_(S3) HDEF(S4) PEG0(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) i5-4590T CPU @ 2.00GHz, 1995.53 MHz, 06-3c-03 [..] I suggest generating a sendbug template from 7.2, run as root to include all the information, and send it to bugs@
