Re: vmd: keeping time in vm's
It would be a bit of work, but I'd consider looking at how the host clock is exposed by vmt(4) and whether vmm(4) and vmmci(4) could/should be extended in the same way. If so, you could use Ted Unangst's solution to a similar problem with VMWare guests. http://www.tedunangst.com/flak/post/vmtimed On Fri, Feb 10, 2017 at 1:57 AM, Stuart Henderson wrote: > On 2017-02-09, Eric Brown wrote: > > Dear List, > > > > I've recently learned (and discovered) that time in VM's is tricky > > business. I'm looking for the least stupid way to keep any semblance of > > time in vmd instances while I hungrily await a "correct solution" to > > descend from the heavens. > > > > I've disabled openntpd, installed ntp package (but not its daemon). Now > > I am running ntpdate every minute from cron. It seems to keep the > > clock, well, within a minute. > > > > Can anyone think of a better solution to this problem? > > Not a hugely better solution, but rdate(8) is in base, so at least you > don't need the ntp package..
Re: collecting relayd check scripts?
On 2017-02-08, Michael W. Lucas wrote: > Hi, > > I'm collecting relayd check scripts for the httpd/relayd book. > > If you have a check script that you don't mind sharing, please send it > to me. > > Regards, >==ml > > There are lots of "nagios" scripts available (ports/net/monitoring-plugins) which can be used with a wrapper to reverse the return value (they give 0 for success whereas relayd wants a positive value for success).
Re: vmd: keeping time in vm's
On 2017-02-09, Eric Brown wrote: > Dear List, > > I've recently learned (and discovered) that time in VM's is tricky > business. I'm looking for the least stupid way to keep any semblance of > time in vmd instances while I hungrily await a "correct solution" to > descend from the heavens. > > I've disabled openntpd, installed ntp package (but not its daemon). Now > I am running ntpdate every minute from cron. It seems to keep the > clock, well, within a minute. > > Can anyone think of a better solution to this problem? Not a hugely better solution, but rdate(8) is in base, so at least you don't need the ntp package..
Re: In case you need a 4th ethernet port on PC-Engines APU2
On 2017-02-09, Eike Lantzsch wrote: > Hi, > just out of curiosity I purchased a Delock 95228 MiniPCIe I/O 1 x Gigabit LAN > card to test in my PC-Engines APU2C4 board. > Well, it works - somehow. > If the media is set to 100baseTX at least it does but at 1000baseTX it has > about 35 to 72% package loss on ping. > I guess that the pig tail cable, which is supplied with the card, is not > really CAT5e although it is labeled as such. > Anyway - if you need a fourth eth port on your APU for maintenance this is a > possibility. > It's cheaper than a Soekris box ... Or there are various USB ethernet adapters supported which might be less trouble..
In case you need a 4th ethernet port on PC-Engines APU2
Hi, just out of curiosity I purchased a Delock 95228 MiniPCIe I/O 1 x Gigabit LAN card to test in my PC-Engines APU2C4 board. Well, it works - somehow. If the media is set to 100baseTX at least it does but at 1000baseTX it has about 35 to 72% package loss on ping. I guess that the pig tail cable, which is supplied with the card, is not really CAT5e although it is labeled as such. Anyway - if you need a fourth eth port on your APU for maintenance this is a possibility. It's cheaper than a Soekris box ... Cheers and big thank you to the developers Here is the dmesg with Feb 8 snapshot which I also sent to dm...@openbsd.org: OpenBSD 6.0-current (GENERIC.MP) #166: Wed Feb 8 19:15:03 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4261076992 (4063MB) avail mem = 4127272960 (3936MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffb7020 (7 entries) bios0: vendor coreboot version "88a4f96" date 03/07/2016 bios0: PC Engines apu2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S2 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH3(S3) UOH5(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.43 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE, 3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: TSC frequency 998425710 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.14 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE, 3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.14 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE, 3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.14 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE, 3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus 4 (PBR8) acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB "PNP0501" at acpi0 not configured cpu0: 998 MHz: speeds: 1000 800 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Root Complex" rev 0x00 pchb1 at pci0 dev 2 function 0 "AMD AMD64 16h Host" rev 0x00 ppb0
Re: splassert: yield message on 5 Feb snapshot (amd64)
Stefan Wollny wrote: > at least with > > $ dmesg | grep Open > OpenBSD 6.0-current (GENERIC.MP) #166: Wed Feb 8 19:15:03 MST 2017 > > the issue still persists. The patch that solve the issue (at least in my machine) was committed today: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_table.c.diff?r1=1.123&r2=1.124
Re: i3bar iwn info and battery status
Oh, thanks a lot, will wait for current update then :) 2017-02-09 22:25 GMT+03:00 Robert Peichaer : > On Thu, Feb 09, 2017 at 10:18:44PM +0300, Asbel Kiprop wrote: > > hi misc. > > i've moved my -current system from hdd to ssd disk. everything work fine > > for me, but got some strange i3bar behavior. > > wireless _first_ { > > format_up = "W: (%signal at %essid) %ip" > > format_down = "W: down" > > } > > battery 0 { > > format = "%status %percentage \% %remaining" > > } > > > > At first start i get what i want - iwn status and battery life time. But > > after 10-20 minutes it turnes to "W:down" and "can't open /dev/apm" > > > > /dev/apm exesist and and seems no problem with it > > ls -la /dev/apm > > > > crw-r--r-- 1 root wheel 83, 0 Feb 9 14:39 /dev/apm > > > > The problem is i dont even know what should i look for to determine the > > root of the problem.. > > I already tried to update with bsd.rd. > > > > ANy suggestions? > > This has been fixed recently. Update after new packages are on the > mirrors. The current packages were built before this fix. > > http://marc.info/?l=openbsd-ports-cvs&m=148649175810877&w=2
Re: i3bar iwn info and battery status
On Thu, Feb 09, 2017 at 10:18:44PM +0300, Asbel Kiprop wrote: > hi misc. > i've moved my -current system from hdd to ssd disk. everything work fine > for me, but got some strange i3bar behavior. > wireless _first_ { > format_up = "W: (%signal at %essid) %ip" > format_down = "W: down" > } > battery 0 { > format = "%status %percentage \% %remaining" > } > > At first start i get what i want - iwn status and battery life time. But > after 10-20 minutes it turnes to "W:down" and "can't open /dev/apm" > > /dev/apm exesist and and seems no problem with it > ls -la /dev/apm > > crw-r--r-- 1 root wheel 83, 0 Feb 9 14:39 /dev/apm > > The problem is i dont even know what should i look for to determine the > root of the problem.. > I already tried to update with bsd.rd. > > ANy suggestions? This has been fixed recently. Update after new packages are on the mirrors. The current packages were built before this fix. http://marc.info/?l=openbsd-ports-cvs&m=148649175810877&w=2
i3bar iwn info and battery status
hi misc. i've moved my -current system from hdd to ssd disk. everything work fine for me, but got some strange i3bar behavior. wireless _first_ { format_up = "W: (%signal at %essid) %ip" format_down = "W: down" } battery 0 { format = "%status %percentage \% %remaining" } At first start i get what i want - iwn status and battery life time. But after 10-20 minutes it turnes to "W:down" and "can't open /dev/apm" /dev/apm exesist and and seems no problem with it ls -la /dev/apm crw-r--r-- 1 root wheel 83, 0 Feb 9 14:39 /dev/apm The problem is i dont even know what should i look for to determine the root of the problem.. I already tried to update with bsd.rd. ANy suggestions? OpenBSD 6.0-current (GENERIC.MP) #166: Wed Feb 8 19:15:03 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8451125248 (8059MB) avail mem = 8190332928 (7810MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (67 entries) bios0: vendor LENOVO version "8BET62WW (1.42 )" date 07/26/2013 bios0: LENOVO 428445G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.92 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2292916880 Hz 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.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 2, package 0 cpu5 at mainbus0: apid 5 (application processor) cpu5: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 2, package 0 cpu6 at mainbus0: apid 6 (application processor) cpu6: Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz, 2292.56 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu6: 256KB 64b/line 8-way L2 cache cpu6: smt 0, core 3, package 0 cpu7 at mainbus0: apid 7 (ap
Re: vmd: upper limit on number of vm's?
Gregor Best writes: > Hi, > >> [...] >> # tail -4 /var/log/messages >> Feb 9 11:21:44 air vmd[73442]: parent terminating >> Feb 9 11:21:47 air vmd[73405]: config_setvm: can't open tap tap: No >> such file or directory >> [...] > > You're probably missing the device files for the taps in /dev. The > installer creates 4 by default, so you'll have to run > > cd /dev; sh MAKEDEV tap4 > > and so on for each new tap device you need. Worked like a charm. So awesome. Thank you!
Re: vmd: upper limit on number of vm's?
Gregor Best writes: > Hi, > > On Thu, Feb 09, 2017 at 11:33:19AM -0600, Eric Brown wrote: >> [...] >> # tail -4 /var/log/messages >> Feb 9 11:21:44 air vmd[73442]: parent terminating >> Feb 9 11:21:47 air vmd[73405]: config_setvm: can't open tap tap: No such >> file or directory >> [...] > > You're probably missing the device files for the taps in /dev. The > installer creates 4 by default, so you'll have to run > > cd /dev; sh MAKEDEV tap4 > > and so on for each new tap device you need. Worked like a charm. So awesome. Thank you!
Re: vmd: keeping time in vm's
Eric Brown writes: > Dear List, > > I've recently learned (and discovered) that time in VM's is tricky > business. I'm looking for the least stupid way to keep any semblance of > time in vmd instances while I hungrily await a "correct solution" to > descend from the heavens. > > I've disabled openntpd, installed ntp package (but not its daemon). Now > I am running ntpdate every minute from cron. It seems to keep the > clock, well, within a minute. > > Can anyone think of a better solution to this problem? > > Thanks, > Eric It was suggested that dmesg for the host and guest might be helpful. Please find them below: -- host dmesg -- OpenBSD 6.0-current (GENERIC.MP) #163: Sun Feb 5 13:55:12 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 7 real mem = 8475713536 (8083MB) avail mem = 8214179840 (7833MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (54 entries) bios0: vendor Apple Inc. version "MBA51.88Z.00EF.B05.1610241034" date 10/24/2016 bios0: Apple Inc. MacBookAir5,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR MCFG acpi0: wakeup devices P0P2(S4) PEG2(S4) EC__(S4) HDEF(S4) RP02(S4) ARPT(S4) RP05(S4) EHC1(S4) EHC2(S4) XHC1(S4) ADP1(S4) LID0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 2494.75 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2494745050 Hz 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.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz, 2494.34 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT 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) i7-3667U CPU @ 2.00GHz, 2494.34 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT 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) i7-3667U CPU @ 2.00GHz, 2494.34 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xe000, bus 0-153 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus 3 (RP05) acpicpu0 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS "APP0001" at acpi0 not configured acpials0 at acpi0: ALS0 "ACPI0002" at acpi0 not configured acpibat0 at acpi0: BAT0 model "7301496308839493953" type 7301496309193591116 oem "7301496571575100750" acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB "APP0002" at acpi0 not configured acpibtn2 at acpi0: SLPB acpivideo0 at acpi0: IGPU acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2001, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz memory map conflict 0xe00f8000/0x1000 memory map conflict 0xfed1c000/0x4000 memory map conflict 0xffe7/0x3 pci0 at mainbu
Re: splassert: yield message on 5 Feb snapshot (amd64)
Am 02/09/17 um 18:02 schrieb Martin Pieuchot: > On 09/02/17(Thu) 17:55, Stefan Wollny wrote: >> Am 02/08/17 um 17:57 schrieb Hrvoje Popovski: >>> On 8.2.2017. 17:51, Scott Vanderbilt wrote: Updated a machine to latest (5 Feb.) snapshot of amd64. I'm now seeing the following message after booting that I've not recalled seeing before: splassert: yield: want 0 have 1 >>> >>> >>> add sysctl kern.splassert=2 ... >>> >> >> Here you go: >> >> OpenBSD 6.0-current (GENERIC.MP) #163: Sun Feb 5 13:55:12 MST 2017 >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > This should be fixed now. Please update from source or wait for the next > snapshot. If the problem still persist, report back. > Hi Martin, at least with $ dmesg | grep Open OpenBSD 6.0-current (GENERIC.MP) #166: Wed Feb 8 19:15:03 MST 2017 the issue still persists. I'll check with the next snapshot. Thank you for caring! Best, STEFAN
Re: vmd: upper limit on number of vm's?
Hi, On Thu, Feb 09, 2017 at 11:33:19AM -0600, Eric Brown wrote: > [...] > # tail -4 /var/log/messages > Feb 9 11:21:44 air vmd[73442]: parent terminating > Feb 9 11:21:47 air vmd[73405]: config_setvm: can't open tap tap: No such > file or directory > [...] You're probably missing the device files for the taps in /dev. The installer creates 4 by default, so you'll have to run cd /dev; sh MAKEDEV tap4 and so on for each new tap device you need. -- Gregor
vmd: keeping time in vm's
Dear List, I've recently learned (and discovered) that time in VM's is tricky business. I'm looking for the least stupid way to keep any semblance of time in vmd instances while I hungrily await a "correct solution" to descend from the heavens. I've disabled openntpd, installed ntp package (but not its daemon). Now I am running ntpdate every minute from cron. It seems to keep the clock, well, within a minute. Can anyone think of a better solution to this problem? Thanks, Eric
Re: jme0: watchdog timeout
On Wed, Feb 08, 2017 at 10:04:04AM +, Comète wrote: > Hi, > > I use OpenBSD 6.0 amd64 (stable) on a Shuttle XS35v2. I've installed > "ushare" but same problem with "minidlna" and I don't think the problem comes > from these apps... When I try to read a big file (ex.: a 1Go video) from my > DLNA player, nothing starts playing and the jme driver on the Shuttle reports > these warnings on dmesg: > > jme0: watchdog timeout > jme0: stopping transmitter > timeout! > jme0: stopping transmitter timeout! > jme0: stopping transmitter > timeout! > jme0: watchdog timeout > jme0: stopping transmitter timeout! > jme0: > stopping transmitter timeout! > jme0: watchdog timeout > jme0: stopping > transmitter timeout! > jme0: stopping transmitter timeout! > jme0: stopping > transmitter timeout! > jme0: watchdog timeout > jme0: stopping transmitter > timeout! > jme0: stopping transmitter timeout! > jme0: watchdog timeout > jme0: > watchdog timeout > > and the NIC sometimes stops working until I reboot the > machine. > > I saw an identical report on the mailing list some time ago, but I > didn't manage to find it. I did report to bugs@ a while ago: http://marc.info/?l=openbsd-bugs&m=146958374430709&w=2 -- db
vmd: upper limit on number of vm's?
Dear List, I am experimenting with virtual machines (vmd) in recent OpenBSD snapshots. Having gotten a few VMs working, I am eager to make many more and also run them. I'm pleased to have an autoinstall process running from a vmd instance. However, when running more than 4 instances, I run into an error: # /etc/rc.d/vmd stop # ... /etc/vm.conf enable a fifth machine that is confirmed to run # /etc/rc.d/vmd start # vmctl status vmctl: connect: /var/run/vmd.sock: Connection refused # tail -4 /var/log/messages Feb 9 11:21:44 air vmd[73442]: parent terminating Feb 9 11:21:47 air vmd[73405]: config_setvm: can't open tap tap: No such file or directory Feb 9 11:21:47 air vmd[73405]: config_setvm: failed to start vm mirror.ericcbrown.com Feb 9 11:21:47 air vmd[73405]: parent: configuration failed Some evidence that may help: * I can make a bunch of tap's with ifconfig, many more than4. (hostname.bridge0,hostname.bge0,and hostname.vether configured) * I am using i7 2.0 Ghz with 2 cores and 4 hyperthreads that appear in `top' (macbook air 2011) * I confirm that each machine works in any combination of 4 vm's concurrently I've tried to read the source, but I'm totally stuck here, and thought I would ask whether anyone knows what could be the stopper here at running many vm's. Best regards, Eric PS Thank you very much to Mike Larkin and Reyk Floeter for authoring this. It has been a very nice way to explore network and routing concepts while making VM's that do very useful things for me. -- dmesg of host machine -- OpenBSD 6.0-current (GENERIC.MP) #163: Sun Feb 5 13:55:12 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error f7 real mem = 1836232704 (1751MB) avail mem = 1775980544 (1693MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (39 entries) bios0: vendor Apple Inc. version "MB61.88Z.00C8.B00.0908271503" date 08/27/09 bios0: Apple Inc. MacBook6,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT SSDT acpi0: wakeup devices ADP1(S3) LID0(S3) EC__(S3) OHC1(S3) EHC1(S3) OHC2(S3) EHC2(S3) GIGE(S5) ARPT(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2500 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P7550 @ 2.26GHz, 2255.72 MHz 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P7550 @ 2.26GHz, 2255.35 MHz 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 addr 0xf000, bus 0-255 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (IXVE) acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 "APP0002" at acpi0 not configured acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB "APP0001" at acpi0 not configured "APP0003" at acpi0 not configured "ACPI0002" at acpi0 not configured acpibat0 at acpi0: BAT0 model "3545797981023400290" type 3545797981528607052 oem "3545797981528608836" cpu0: Enhanced SpeedStep 2255 MHz: speeds: 2261, 2128, 1862, 1596, 798 MHz memory map conflict 0xffc0/0x40 pci0 at mainbus0 bus 0 0:3:5: mem address conflict 0x9330/0x8 pchb0 at pci0 dev 0 function 0 "NVIDIA MCP79 Host" rev 0xb1 "NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 0 function 1 not configured pcib0 at pci0 dev 3 function 0 "NVIDIA MCP79 ISA" rev 0xb3 "NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 3 function 1 not configured nviic0 at pci0 dev 3 function 2 "NVIDIA MCP79 SMBus" rev 0xb1 iic0 at nviic0 spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-8500 SO-DIMM iic1 at nviic0 iic1: addr 0x4c 00=47 01=5a 02=92 04=07 05=55 07=55 0a=07 0b=55 0d=55 10=e0 15=55 19=55 1a=55 20=55 21=0a 22=70 23=43 24=60 25=0b 26=0f 27=12 28=12 29=a0 35=02 37=02 60=06 70=06 71=03 72=07 8c=ff 8d=ff 8e=ff 8f=ff 90=ff 9a=ff 9b=ff 9c=ff 9d=ff 9e=ff 9f=ff a0=ff a1=ff a2=ff a3=ff a4=ff a5=ff a6=ff a7=ff a8=ff a9=ff aa=ff ab=ff ac=ff ad=ff ae=ff af=ff b0=ff b1=
Re: splassert: yield message on 5 Feb snapshot (amd64)
On 09/02/17(Thu) 17:55, Stefan Wollny wrote: > Am 02/08/17 um 17:57 schrieb Hrvoje Popovski: > > On 8.2.2017. 17:51, Scott Vanderbilt wrote: > >> Updated a machine to latest (5 Feb.) snapshot of amd64. I'm now seeing > >> the following message after booting that I've not recalled seeing before: > >> > >>splassert: yield: want 0 have 1 > > > > > > add sysctl kern.splassert=2 ... > > > > Here you go: > > OpenBSD 6.0-current (GENERIC.MP) #163: Sun Feb 5 13:55:12 MST 2017 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP This should be fixed now. Please update from source or wait for the next snapshot. If the problem still persist, report back. Thanks.
Re: splassert: yield message on 5 Feb snapshot (amd64)
Am 02/08/17 um 17:57 schrieb Hrvoje Popovski: > On 8.2.2017. 17:51, Scott Vanderbilt wrote: >> Updated a machine to latest (5 Feb.) snapshot of amd64. I'm now seeing >> the following message after booting that I've not recalled seeing before: >> >>splassert: yield: want 0 have 1 > > > add sysctl kern.splassert=2 ... > Here you go: OpenBSD 6.0-current (GENERIC.MP) #163: Sun Feb 5 13:55:12 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17079074816 (16287MB) avail mem = 16556802048 (15789MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec080 (35 entries) bios0: vendor American Megatrends Inc. version "1.03.06" date 06/25/2014 bios0: Notebook W65_67SZ acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! TCPA SSDT SSDT SSDT MCFG HPET SSDT SSDT SSDT DMAR acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(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-4210M CPU @ 2.60GHz, 2594.40 MHz 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2594401360 Hz 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, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 2594.00 MHz 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT 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) i5-4210M CPU @ 2.60GHz, 2594.00 MHz 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT 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) i5-4210M CPU @ 2.60GHz, 2594.00 MHz 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 1 (P0P2) acpiprt5 at acpi0: bus -1 (P0PA) acpiprt6 at acpi0: bus -1 (P0PB) acpiprt7 at acpi0: bus 1 (PEG0) acpiec0 at acpi0 acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 120 degC "INT3F0D" at acpi0 not configured "MSFT0001" at acpi0 not configured "ETD0403" at acpi0 not configured tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: Infineon SLB9635 1.2 rev 0x10 "PNPC000" at acpi0 not configured acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: LID0 acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT0 model "BAT" serial 0001 type LION oem "Notebook" "PNP0C14" at acpi0 not configured "INT340E" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: LCD0 cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2300, 2200, 2100, 2000, 1800, 1700, 1600, 1400, 1300, 1200, 1100, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06 ppb0 at pci0 dev 1 function 0 "In
Re: OSPFd stucks in EXCHG/EXSTA
OSPF is sensitive to MTU changes. You probably want the change in http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ospfd/ospfe.c.diff?r1=1.96&r2=1.97 from -current. This will track interface MTU changes. On 2017 Feb 09 (Thu) at 14:51:05 +0100 (+0100), Maxim Bourmistrov wrote: :This actually a default setting for this switch, then you don’t configure :jumbo at all. :'sh running-config all’ shows this. : :I had ’ip ospf mtu-ignore’ in the config as well, but it didn’t help, so :it is gone now. : :I’ll try with 1518. :As seen in tcpdump, both obsd and dell announcing them selves with MTU 1500 in :ospf. :ospfd complains in loggs on bad seq. : :ospfd[39074]: recv_db_description: neighbor ID 10.4.255.29: seq num mismatch, :bad flags : :Question is why ’ifconfig trunk1 mtu 1500’ triggers this, while initial :setup is already with MTU 1500? : ://mxb : : :> 9 feb. 2017 kl. 14:31 skrev Peter Hessler : :> :> Are you establishing an ospf session with the N3048? If you are, then :> there is an MTU miss-match. :> :> Either "system jumbo mtu" refers to the IP packet, which doesn't match :> the 1500 set on trunk1, or it refers to the ethernet packet which should :> be 1518 (16 bytes for the ethernet header). :> :> Is it fixed if you change it to 1518, or drop that line completely? :> :> :> :> On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote: :> :I see similar behavior with Cisco Nexus and 5.9-stable. :> :How ever not 100% sure if it is the same trigger. :> : :> : :> : :> :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov : :> :> :> :> Hey, :> :> :> :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell :N3048 :> :switch. :> :> According to some documentation around, this is due to MTU mismatch. :> :> :> :> This is not in my case. :> :> :> :> N3048: :> :> system jumbo mtu 1512 :> :> :> :> obsd: :> :> trunk1: flags=8943 mtu :1500 :> :>lladdr 00:25:90:78:62:b6 :> :>description: HW_INTERNAL :> :>index 12 priority 0 llprio 3 :> :>trunk: trunkproto lacp :> :>trunk id: [(8000,00:25:90:78:62:b6,4064,,), :> :> (0001,f8:b1:56:61:a1:e4,02AE,,)] :> :>trunkport bnx1 active,collecting,distributing :> :>trunkport em1 active,collecting,distributing :> :>groups: trunk :> :>media: Ethernet autoselect :> :>status: active :> :>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31 :> :> :> :> ping with diff size of pkts and tcpdump reveals that there is no MTU :> :mismatch. :> :> :> :> Restart of ospfd does not helps, only REBOOT. :> :> :> :> I decided to dig into this and found that changing MTU size on trunk1 :can :> :reproduce this 100%. :> :> Actually value does not changes, but problem with ospfd can be triggered :> :this way: :> :> :> :> # ifconfig trunk1 mtu 1500 :> :> # rcctl restart ospfd :> :> :> :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always. :> :> :> :> Then I tried to put mtu for each face involved in trunk1. Result is then :> :same - triggered with ’ifconfig trunk1 mtu 1500’. :> :> :> :> # cat /etc/hostname.bnx1 :> :> up mtu 1500 :> :> :> :> # cat /etc/hostname.em1 :> :> up mtu 1500 :> :> :> :> Any ideas? :> :> :> :> Br :> :> mxb :> : :> :> -- :> No matter how subtle the wizard, a knife in the shoulder blades will :> seriously cramp his style. : -- It's not an optical illusion; it just looks like one. -- Phil White
Re: OSPFd stucks in EXCHG/EXSTA
Hm, seems that I mistyped MTU in my original mail. lacp system-priority 1 rate-limit cpu direction input pps 1024 system jumbo mtu 1518 It is 1518 by default. > 9 feb. 2017 kl. 14:51 skrev Maxim Bourmistrov : > > > This actually a default setting for this switch, then you don’t configure jumbo at all. > 'sh running-config all’ shows this. > > I had ’ip ospf mtu-ignore’ in the config as well, but it didn’t help, so it is gone now. > > I’ll try with 1518. > As seen in tcpdump, both obsd and dell announcing them selves with MTU 1500 in ospf. > ospfd complains in loggs on bad seq. > > ospfd[39074]: recv_db_description: neighbor ID 10.4.255.29: seq num mismatch, bad flags > > Question is why ’ifconfig trunk1 mtu 1500’ triggers this, while initial setup is already with MTU 1500? > > //mxb > > >> 9 feb. 2017 kl. 14:31 skrev Peter Hessler : >> >> Are you establishing an ospf session with the N3048? If you are, then >> there is an MTU miss-match. >> >> Either "system jumbo mtu" refers to the IP packet, which doesn't match >> the 1500 set on trunk1, or it refers to the ethernet packet which should >> be 1518 (16 bytes for the ethernet header). >> >> Is it fixed if you change it to 1518, or drop that line completely? >> >> >> >> On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote: >> :I see similar behavior with Cisco Nexus and 5.9-stable. >> :How ever not 100% sure if it is the same trigger. >> : >> : >> : >> :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov : >> :> >> :> Hey, >> :> >> :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell N3048 >> :switch. >> :> According to some documentation around, this is due to MTU mismatch. >> :> >> :> This is not in my case. >> :> >> :> N3048: >> :> system jumbo mtu 1512 >> :> >> :> obsd: >> :> trunk1: flags=8943 mtu 1500 >> :>lladdr 00:25:90:78:62:b6 >> :>description: HW_INTERNAL >> :>index 12 priority 0 llprio 3 >> :>trunk: trunkproto lacp >> :>trunk id: [(8000,00:25:90:78:62:b6,4064,,), >> :> (0001,f8:b1:56:61:a1:e4,02AE,,)] >> :>trunkport bnx1 active,collecting,distributing >> :>trunkport em1 active,collecting,distributing >> :>groups: trunk >> :>media: Ethernet autoselect >> :>status: active >> :>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31 >> :> >> :> ping with diff size of pkts and tcpdump reveals that there is no MTU >> :mismatch. >> :> >> :> Restart of ospfd does not helps, only REBOOT. >> :> >> :> I decided to dig into this and found that changing MTU size on trunk1 can >> :reproduce this 100%. >> :> Actually value does not changes, but problem with ospfd can be triggered >> :this way: >> :> >> :> # ifconfig trunk1 mtu 1500 >> :> # rcctl restart ospfd >> :> >> :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always. >> :> >> :> Then I tried to put mtu for each face involved in trunk1. Result is then >> :same - triggered with ’ifconfig trunk1 mtu 1500’. >> :> >> :> # cat /etc/hostname.bnx1 >> :> up mtu 1500 >> :> >> :> # cat /etc/hostname.em1 >> :> up mtu 1500 >> :> >> :> Any ideas? >> :> >> :> Br >> :> mxb >> : >> >> -- >> No matter how subtle the wizard, a knife in the shoulder blades will >> seriously cramp his style.
Re: OSPFd stucks in EXCHG/EXSTA
This actually a default setting for this switch, then you don’t configure jumbo at all. 'sh running-config all’ shows this. I had ’ip ospf mtu-ignore’ in the config as well, but it didn’t help, so it is gone now. I’ll try with 1518. As seen in tcpdump, both obsd and dell announcing them selves with MTU 1500 in ospf. ospfd complains in loggs on bad seq. ospfd[39074]: recv_db_description: neighbor ID 10.4.255.29: seq num mismatch, bad flags Question is why ’ifconfig trunk1 mtu 1500’ triggers this, while initial setup is already with MTU 1500? //mxb > 9 feb. 2017 kl. 14:31 skrev Peter Hessler : > > Are you establishing an ospf session with the N3048? If you are, then > there is an MTU miss-match. > > Either "system jumbo mtu" refers to the IP packet, which doesn't match > the 1500 set on trunk1, or it refers to the ethernet packet which should > be 1518 (16 bytes for the ethernet header). > > Is it fixed if you change it to 1518, or drop that line completely? > > > > On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote: > :I see similar behavior with Cisco Nexus and 5.9-stable. > :How ever not 100% sure if it is the same trigger. > : > : > : > :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov : > :> > :> Hey, > :> > :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell N3048 > :switch. > :> According to some documentation around, this is due to MTU mismatch. > :> > :> This is not in my case. > :> > :> N3048: > :> system jumbo mtu 1512 > :> > :> obsd: > :> trunk1: flags=8943 mtu 1500 > :>lladdr 00:25:90:78:62:b6 > :>description: HW_INTERNAL > :>index 12 priority 0 llprio 3 > :>trunk: trunkproto lacp > :>trunk id: [(8000,00:25:90:78:62:b6,4064,,), > :> (0001,f8:b1:56:61:a1:e4,02AE,,)] > :>trunkport bnx1 active,collecting,distributing > :>trunkport em1 active,collecting,distributing > :>groups: trunk > :>media: Ethernet autoselect > :>status: active > :>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31 > :> > :> ping with diff size of pkts and tcpdump reveals that there is no MTU > :mismatch. > :> > :> Restart of ospfd does not helps, only REBOOT. > :> > :> I decided to dig into this and found that changing MTU size on trunk1 can > :reproduce this 100%. > :> Actually value does not changes, but problem with ospfd can be triggered > :this way: > :> > :> # ifconfig trunk1 mtu 1500 > :> # rcctl restart ospfd > :> > :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always. > :> > :> Then I tried to put mtu for each face involved in trunk1. Result is then > :same - triggered with ’ifconfig trunk1 mtu 1500’. > :> > :> # cat /etc/hostname.bnx1 > :> up mtu 1500 > :> > :> # cat /etc/hostname.em1 > :> up mtu 1500 > :> > :> Any ideas? > :> > :> Br > :> mxb > : > > -- > No matter how subtle the wizard, a knife in the shoulder blades will > seriously cramp his style.
Re: OSPFd stucks in EXCHG/EXSTA
Are you establishing an ospf session with the N3048? If you are, then there is an MTU miss-match. Either "system jumbo mtu" refers to the IP packet, which doesn't match the 1500 set on trunk1, or it refers to the ethernet packet which should be 1518 (16 bytes for the ethernet header). Is it fixed if you change it to 1518, or drop that line completely? On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote: :I see similar behavior with Cisco Nexus and 5.9-stable. :How ever not 100% sure if it is the same trigger. : : : :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov : :> :> Hey, :> :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell N3048 :switch. :> According to some documentation around, this is due to MTU mismatch. :> :> This is not in my case. :> :> N3048: :> system jumbo mtu 1512 :> :> obsd: :> trunk1: flags=8943 mtu 1500 :>lladdr 00:25:90:78:62:b6 :>description: HW_INTERNAL :>index 12 priority 0 llprio 3 :>trunk: trunkproto lacp :>trunk id: [(8000,00:25:90:78:62:b6,4064,,), :> (0001,f8:b1:56:61:a1:e4,02AE,,)] :>trunkport bnx1 active,collecting,distributing :>trunkport em1 active,collecting,distributing :>groups: trunk :>media: Ethernet autoselect :>status: active :>inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31 :> :> ping with diff size of pkts and tcpdump reveals that there is no MTU :mismatch. :> :> Restart of ospfd does not helps, only REBOOT. :> :> I decided to dig into this and found that changing MTU size on trunk1 can :reproduce this 100%. :> Actually value does not changes, but problem with ospfd can be triggered :this way: :> :> # ifconfig trunk1 mtu 1500 :> # rcctl restart ospfd :> :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always. :> :> Then I tried to put mtu for each face involved in trunk1. Result is then :same - triggered with ’ifconfig trunk1 mtu 1500’. :> :> # cat /etc/hostname.bnx1 :> up mtu 1500 :> :> # cat /etc/hostname.em1 :> up mtu 1500 :> :> Any ideas? :> :> Br :> mxb : -- No matter how subtle the wizard, a knife in the shoulder blades will seriously cramp his style.
Re: OSPFd stucks in EXCHG/EXSTA
I see similar behavior with Cisco Nexus and 5.9-stable. How ever not 100% sure if it is the same trigger. > 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov : > > Hey, > > ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell N3048 switch. > According to some documentation around, this is due to MTU mismatch. > > This is not in my case. > > N3048: > system jumbo mtu 1512 > > obsd: > trunk1: flags=8943 mtu 1500 >lladdr 00:25:90:78:62:b6 >description: HW_INTERNAL >index 12 priority 0 llprio 3 >trunk: trunkproto lacp >trunk id: [(8000,00:25:90:78:62:b6,4064,,), > (0001,f8:b1:56:61:a1:e4,02AE,,)] >trunkport bnx1 active,collecting,distributing >trunkport em1 active,collecting,distributing >groups: trunk >media: Ethernet autoselect >status: active >inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31 > > ping with diff size of pkts and tcpdump reveals that there is no MTU mismatch. > > Restart of ospfd does not helps, only REBOOT. > > I decided to dig into this and found that changing MTU size on trunk1 can reproduce this 100%. > Actually value does not changes, but problem with ospfd can be triggered this way: > > # ifconfig trunk1 mtu 1500 > # rcctl restart ospfd > > and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always. > > Then I tried to put mtu for each face involved in trunk1. Result is then same - triggered with ’ifconfig trunk1 mtu 1500’. > > # cat /etc/hostname.bnx1 > up mtu 1500 > > # cat /etc/hostname.em1 > up mtu 1500 > > Any ideas? > > Br > mxb
OSPFd stucks in EXCHG/EXSTA
Hey, ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell N3048 switch. According to some documentation around, this is due to MTU mismatch. This is not in my case. N3048: system jumbo mtu 1512 obsd: trunk1: flags=8943 mtu 1500 lladdr 00:25:90:78:62:b6 description: HW_INTERNAL index 12 priority 0 llprio 3 trunk: trunkproto lacp trunk id: [(8000,00:25:90:78:62:b6,4064,,), (0001,f8:b1:56:61:a1:e4,02AE,,)] trunkport bnx1 active,collecting,distributing trunkport em1 active,collecting,distributing groups: trunk media: Ethernet autoselect status: active inet 10.4.255.27 netmask 0xffe0 broadcast 10.4.255.31 ping with diff size of pkts and tcpdump reveals that there is no MTU mismatch. Restart of ospfd does not helps, only REBOOT. I decided to dig into this and found that changing MTU size on trunk1 can reproduce this 100%. Actually value does not changes, but problem with ospfd can be triggered this way: # ifconfig trunk1 mtu 1500 # rcctl restart ospfd and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always. Then I tried to put mtu for each face involved in trunk1. Result is then same - triggered with ’ifconfig trunk1 mtu 1500’. # cat /etc/hostname.bnx1 up mtu 1500 # cat /etc/hostname.em1 up mtu 1500 Any ideas? Br mxb
New Support
0 C Australia P New South Wales T Sydney Z 2000 O NSW IT Support I Suraj Poudel A 19 Martin Pl M binaryit.market...@gmail.com U http://nswits.com.au/ B 1300 138 600 N NSW IT Support provide OpenBSD and Linux installations services that is a secure antispam web server and make any customers happy.
Re: New Support
added, thanks
New Support
0 C Australia P New South Wales T Sydney Z 2000 O NSW IT Support I Suraj Poudel A 19 Martin Pl M binaryit.market...@gmail.com U http://nswits.com.au/ B 1300 138 600 N NSW IT Support provide OpenBSD and Linux installations services that is a secure antispam web server and make any customers happy.
Re: Help with server not accepting new connections but is still accessible through ONE existing open ssh-session
On 02/01/2017 03:41 PM, Erling Westenvik wrote: I have an OpenBSD 5.9 server at a colocation. It stopped accepting new connections (ping, ssh, http, whatever) yesterday night but fortunately I had one ssh session open from my workstation from which I can still access it. Did you think about creation of second sshd instance on other port and start it in debug mode?
Re: relayd send/expect syntax
i came to the same conclusion, ok benno@ Reyk Floeter(r...@openbsd.org) on 2017.02.09 00:25:31 +0100: > On Tue, Feb 07, 2017 at 05:04:18PM -0500, Michael W. Lucas wrote: > > host 104.236.197.233, check send expect (9020ms,tcp read timeout), state > > unknown -> down, availability 0.00% > > The send/expect code looses its error because of its async nature - > it goes like: > > 1. "we got data, let's verify it" > 2. "expect test failed, but maybe we didn't read enough, let's try again" > 3. "no more data, timeout" > > When we reach 3), the code also has to check if there is anything in > the input buffer from 1) and verify it again. The following code > fixes it to show "send/expect failed" instead of "tcp read timeout". > > Reyk > > Index: usr.sbin/relayd/check_tcp.c > === > RCS file: /cvs/src/usr.sbin/relayd/check_tcp.c,v > retrieving revision 1.51 > diff -u -p -u -p -r1.51 check_tcp.c > --- usr.sbin/relayd/check_tcp.c 11 Jan 2016 21:31:42 - 1.51 > +++ usr.sbin/relayd/check_tcp.c 8 Feb 2017 23:16:14 - > @@ -233,8 +233,12 @@ tcp_read_buf(int s, short event, void *a > struct ctl_tcp_event*cte = arg; > > if (event == EV_TIMEOUT) { > - tcp_close(cte, HOST_DOWN); > - hce_notify_done(cte->host, HCE_TCP_READ_TIMEOUT); > + if (ibuf_size(cte->buf)) > + (void)cte->validate_close(cte); > + else > + cte->host->he = HCE_TCP_READ_TIMEOUT; > + tcp_close(cte, cte->host->up == HOST_UP ? 0 : HOST_DOWN); > + hce_notify_done(cte->host, cte->host->he); > return; > }
Re: Per-device multiqueuing would be fantastic. Are there any plans? Are donations a matter here?
2017-02-09 16:41 GMT+08:00 David Gwynne : .. > hey mikael, > > can you be more specific about what you mean by multiqueuing for disks? > even a > reference to an implementation of what youâre asking about would help me > answer this question. > > ill write up a bigger reply after my kids are in bed. > > cheers, > dlg Hi David, Thank you for your answer. The other OpenBSD:ers I talked to also used the wording "multiqueue". My understanding of the kernel's workings here is too limited. If I would give a reference to some implementation out there, I guess I would to the one introduced in Linux 3.13/3.16: "Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems" http://kernel.dk/blk-mq.pdf "Linux Multi-Queue Block IO Queueing Mechanism (blk-mq)" https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mech anism_(blk-mq) "The multiqueue block layer" https://lwn.net/Articles/552904/ Looking forward a lot to your followup. Best regards, Mikael
Re: Per-device multiqueuing would be fantastic. Are there any plans? Are donations a matter here?
> On 9 Feb 2017, at 12:42 pm, Mikael wrote: > > Hi misc@, > > The SSD reading benchmark in the previous email shows that per-device > multiqueuing will boost multithreaded random read performance very much > e.g. by ~7X+, e.g. the current 50MB/sec will increase to ~350MB/sec+. > > (I didn't benchmark yet but I suspect the current 50MB/sec is system-wide, > whereas with multiqueuing the 350MB/sec+ would be per drive.) > > Multiuser databases, and any parallell file reading activity, will/would > see a proportional speedup with multiqueing. hey mikael, can you be more specific about what you mean by multiqueuing for disks? even a reference to an implementation of what you’re asking about would help me answer this question. ill write up a bigger reply after my kids are in bed. cheers, dlg > > > Do you have plans to implement this? > > Was anything done to this end already, any idea when multiqueueing can > happen? > > > Are donations a matter here, if so about what size of donations and to who? > > Someone suggested that implementing it would take a year of work. > > Any clarifications of what's going on and what's possible and how would be > much appreciated. > > > Thanks, > Mikael