Re: vmd: keeping time in vm's

[Colin Bortner]

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?

[Stuart Henderson]

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

[Stuart Henderson]

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

[Stuart Henderson]

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

[Eike Lantzsch]

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)

[Walter Alejandro Iglesias]

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=1.124

Re: i3bar iwn info and battery status

[Asbel Kiprop]

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=148649175810877=2

Re: i3bar iwn info and battery status

[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=148649175810877=2

i3bar iwn info and battery status

[Asbel Kiprop]

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 

Re: vmd: upper limit on number of vm's?

[Eric Brown]

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?

[Eric Brown]

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]

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 

Re: splassert: yield message on 5 Feb snapshot (amd64)

[Stefan Wollny]

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?

[Gregor Best]

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

[Eric Brown]

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

[Daniel Bolgheroni]

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=146958374430709=2

-- 
db

vmd: upper limit on number of vm's?

[Eric Brown]

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 

Re: splassert: yield message on 5 Feb snapshot (amd64)

[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.

Thanks.

Re: splassert: yield message on 5 Feb snapshot (amd64)

[Stefan Wollny]

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 

Re: OSPFd stucks in EXCHG/EXSTA

[Peter Hessler]

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=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

[Maxim Bourmistrov]

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

[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

[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

[Maxim Bourmistrov]

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

[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

New Support

[NSW IT 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

[Theo Buehler]

added, thanks

New Support

[NSW IT 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

[lilit-aibolit]

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

[Sebastian Benoit]

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?

[Mikael]

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?

[David Gwynne]

> 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