Re: Ifconfig error - SIOCSETPFLOW

2021-10-16 Thread Antonino Sidoti
HI,

I added ‘!dhclient \$if’ to the /etc/hostname.em0 and removed ‘dhcp’. It is 
working now with no errors on startup and the interface ‘pflow0’ now working 
properly.

pf enabled
net.inet.ip.forwarding: 0 -> 1
net.inet6.ip6.forwarding: 0 -> 1
starting network
em0: no linkgot link
em0: no lease.got lease
em0: 122.199.32.172 lease accepted from 116.255.18.1 (3c:fd:fe:bd:95:13)
reordering libraries: done.
starting early daemons: syslogd pflogd unbound ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd snmpd dhcpd rad smtpd.
starting package daemons: dhcpcd.
starting local daemons: cron.
Sun Oct 17 12:24:00 AEDT 2021


Many thanks for your help

Antonino Sidoti




> On 17 Oct 2021, at 1:12 am, Brian Brombacher  wrote:
> 
> 
> 
>> On Oct 15, 2021, at 10:56 PM, Antonino Sidoti  wrote:
>> 
>> HI,
>> 
>> Yes, on my em0 interface I am using ‘dhcp’ and this is the source IP for 
>> pflow. The setup is a basic firewall as described in the PF example 
>> firewall. 
>> 
>> Interface em0 = external using dhcp (Static IP assigned by carrier)
>> Interface em1 = internal with static IP (Lan using 10.0.x.x/24)
>> 
>> Output from /etc/hostname.pflow0 (Not real IPs)
>> flowdst 203.0.113.1:3001 flowsrc 198.51.100.1
>> pflowproto 10
>> 
>> Thanks
>> 
>> Antonino Sidoti
>> 
>> 
> 
> Thanks for the details.  A recent change in 7.0 introduced a change in 
> behavior for DHCP configured interfaces.  The IP could be assigned after 
> other interfaces are configured.  You may need to assign the static IP in 
> hostname.em0 before the dhcp line, or run dhclient directly from hostname.em0 
> and avoid using “dhcp” in there.
> 
>> 
 On 16 Oct 2021, at 10:39 am, Brian Brombacher  wrote:
 
 
 
> On Oct 15, 2021, at 7:09 PM, Antonino Sidoti  wrote:
 
 HI,
 
 I am getting this error since upgrading to v7.0;
 
 pf enabled
 net.inet.ip.forwarding: 0 -> 1
 net.inet6.ip6.forwarding: 0 -> 1
 starting network
 
 ifconfig: SIOCSETPFLOW: Can't assign requested address
 ifconfig: SIOCSETPFLOW: Can't assign requested address
 
 reordering libraries: done.
 starting early daemons: syslogd pflogd unbound ntpd.
 starting RPC daemons:.
 savecore: no core dump
 checking quotas: done.
 clearing /tmp
 kern.securelevel: 0 -> 1
 creating runtime link editor directory cache.
 preserving editor files.
 starting network daemons: sshd snmpd dhcpd rad smtpd.
 starting package daemons: dhcpcd.
 starting local daemons: cron.
 Sat Oct 16 08:06:39 AEDT 2021
 
 I am assuming it is related to the interface ‘pflow0’ which was working 
 fine in version 6.9. The /etc/hostname.pflow0 is exactly the same as the 
 examples in the man pages only that the source and destination IP 
 addresses are different.
 
 Many thanks
 
 Antonino Sidoti
 
 
 
>>> 
>>> Are you using DHCP to configure the interface the source IP is on?  Provide 
>>> some more details of the network setup.



Re: How does bsd.upgrade work?

2021-10-16 Thread tetrahedra

On Sat, Oct 16, 2021 at 10:28:33AM -, Stuart Henderson wrote:

The boot loader looks for /bsd.upgrade with 'x' filesystem permissions.
If present it removes the x flag and boots. (I think this should be
documented in boot(8) for the various arch but is missing).


I agree.


The install kernel looks for /auto_upgrade.conf (written by sysupgrade)
to use as a response file for the autoinstall(8) mechanism.


My setup is a little bit unusual, and I'm trying to understand why
`uname -a` is still reporting 6.9 after I successfully booted
bsd.upgrade and saw the upgrade process scroll past.


The email sent to root ("$hostname upgrade log") may contain
useful information.


Thanks. I see what looks like a partial log, it couldn't find the sets
in /mnt/home/_sysupgrade and seems to have terminated at that point.


For an unusual setup you may need to look into how the
install/upgrade script works, see /usr/src/distrib/miniroot.


/usr/src/ is empty on my machine.



Re: drmfreeze

2021-10-16 Thread Avon Robertson
On Sat, Oct 16, 2021 at 08:27:03PM +1300, Avon Robertson wrote:
> Avon Robertson [avo...@xtra.co.nz] wrote:
> > Hello misc@,
> > 
> > Earlier today an AMD host I have froze again. I ssh'd into the host
> > and retrieved the output from dmesg, /var/log/messages, and
> > /var/run/dmesg.boot.
> > 
> > I found nothing of note in $HOME/.local/share/xorg/Xorg.0.log.
> > 
> > At the time of the freeze the ksh script I use to update my local /cvs
> > repository was the only programme executing inside the rightmost pane
> > of a 3 pane tmux session. I have a log of the output produced by this
> > script which is probably of no use to those who have been trying to
> > isolate and fix this bug for many months.
> > 
> > Please advise if any of the above is of use or interest to anyone, and
> > if so to which list should I post it.
> > 
> 
> Chris Cappuccio replied with:
> 
> posting the dmesg to this list would be a good start
> 
> Thank you for your reply Chris. I recommend that you read the below
> dmesg from the bottom to the top.
> 
> 
> OpenBSD 7.0 (GENERIC.MP) #212: Mon Sep 13 11:09:43 MDT 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Hello Misc@,

In order to prevent this email becoming a "TLDR" document, please read
earlier posts in this thread to view the above #212 dmesg contents.

Below is yet another dmesg containing similar errors that are reported
near the bottom of the entire dmesg output.

As the latest freeze occurred yesterday, I have kept the machine
running. I can access the frozen machine via ssh so if any interest is
shown w.r.t. providing additional information regarding the freeze
within the next 12 hours, I will try to provide it.

OpenBSD 7.0-current (GENERIC.MP) #40: Fri Oct 15 09:29:25 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 68647477248 (65467MB)
avail mem = 66550951936 (63467MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe8980 (59 entries)
bios0: vendor American Megatrends Inc. version "F2" date 03/14/2018
bios0: Gigabyte Technology Co., Ltd. X470 AORUS ULTRA GAMING
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG HPET SSDT 
UEFI BGRT IVRS SSDT SSDT WSMT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) 
GPPF(S4) GP17(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 Ryzen 7 2700X Eight-Core Processor, 3700.62 MHz, 17-08-02
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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 7 2700X Eight-Core Processor, 3700.03 MHz, 17-08-02
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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02
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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 4-way I-cache, 

Re: Ifconfig error - SIOCSETPFLOW

2021-10-16 Thread Brian Brombacher



> On Oct 15, 2021, at 10:56 PM, Antonino Sidoti  wrote:
> 
> HI,
> 
> Yes, on my em0 interface I am using ‘dhcp’ and this is the source IP for 
> pflow. The setup is a basic firewall as described in the PF example firewall. 
> 
> Interface em0 = external using dhcp (Static IP assigned by carrier)
> Interface em1 = internal with static IP (Lan using 10.0.x.x/24)
> 
> Output from /etc/hostname.pflow0 (Not real IPs)
> flowdst 203.0.113.1:3001 flowsrc 198.51.100.1
> pflowproto 10
> 
> Thanks
> 
> Antonino Sidoti
> 
> 

Thanks for the details.  A recent change in 7.0 introduced a change in behavior 
for DHCP configured interfaces.  The IP could be assigned after other 
interfaces are configured.  You may need to assign the static IP in 
hostname.em0 before the dhcp line, or run dhclient directly from hostname.em0 
and avoid using “dhcp” in there.

> 
>>> On 16 Oct 2021, at 10:39 am, Brian Brombacher  wrote:
>>> 
>>> 
>>> 
 On Oct 15, 2021, at 7:09 PM, Antonino Sidoti  wrote:
>>> 
>>> HI,
>>> 
>>> I am getting this error since upgrading to v7.0;
>>> 
>>> pf enabled
>>> net.inet.ip.forwarding: 0 -> 1
>>> net.inet6.ip6.forwarding: 0 -> 1
>>> starting network
>>> 
>>> ifconfig: SIOCSETPFLOW: Can't assign requested address
>>> ifconfig: SIOCSETPFLOW: Can't assign requested address
>>> 
>>> reordering libraries: done.
>>> starting early daemons: syslogd pflogd unbound ntpd.
>>> starting RPC daemons:.
>>> savecore: no core dump
>>> checking quotas: done.
>>> clearing /tmp
>>> kern.securelevel: 0 -> 1
>>> creating runtime link editor directory cache.
>>> preserving editor files.
>>> starting network daemons: sshd snmpd dhcpd rad smtpd.
>>> starting package daemons: dhcpcd.
>>> starting local daemons: cron.
>>> Sat Oct 16 08:06:39 AEDT 2021
>>> 
>>> I am assuming it is related to the interface ‘pflow0’ which was working 
>>> fine in version 6.9. The /etc/hostname.pflow0 is exactly the same as the 
>>> examples in the man pages only that the source and destination IP addresses 
>>> are different.
>>> 
>>> Many thanks
>>> 
>>> Antonino Sidoti
>>> 
>>> 
>>> 
>> 
>> Are you using DHCP to configure the interface the source IP is on?  Provide 
>> some more details of the network setup.
> 



Re: athn AP

2021-10-16 Thread Stefan Sperling
On Sat, Oct 16, 2021 at 01:40:55PM +0200, Jan Stary wrote:
> Would people now recommend running an AP "natively",
> i.e. a wifi card (plus the anthenas) on and OpenBSD box
> over running wifi over a dedicated device?

Not if you want a modern 11ac/ax AP. There is no driver which supports
hostap and matches off-the-shell APs in terms of stability and speed.

athn(4) mostly works but is slow due to lack of proper 11n support
and has several unresolved performance bugs. And it still lacks
support for 3-antenna devices.

bwfm(4) is fast (11ac) but not yet as stable as athn(4).

If all you need is 11a/g then ral(4) and ath(4) are good options.



athn AP

2021-10-16 Thread Jan Stary
> > > o Worked around a problem with certain athn(4) hardware that caused
> > >   problem when running in HostAP mode with clients that use Tx
> > >   aggregation.

About a year ago, a gave up on having an athn in an ALIX as may home AP,
and just connected a TP-Link AP. That has its disadvantages, but the
actual wifi traffic got much better in terms of reliability and throughput.

Would people now recommend running an AP "natively",
i.e. a wifi card (plus the anthenas) on and OpenBSD box
over running wifi over a dedicated device?

(The clients that mostly had a problem were androids and ipads,
laptops ran more smoothly; but the TP-Link throughput is
a multiple of what the athn-in-ALIX used to do.)

Jan



How to set apparently number of VCPUs in VMM

2021-10-16 Thread Martin
Hi there!

In release notes it seems we can set more than one vCPU for guests running. The 
question is how to set it in vm.conf to achieve better performance for existed 
VMs?

Martin



Re: How does bsd.upgrade work?

2021-10-16 Thread Stuart Henderson
On 2021-10-15, tetrahe...@danwin1210.me  wrote:
> It's not documented in the `sysupgrade` manpage.

sysupgrade(8) only describes what sysupgrade does, not the rest of
the mechanism.

The boot loader looks for /bsd.upgrade with 'x' filesystem permissions.
If present it removes the x flag and boots. (I think this should be
documented in boot(8) for the various arch but is missing).

The install kernel looks for /auto_upgrade.conf (written by sysupgrade)
to use as a response file for the autoinstall(8) mechanism.

> My setup is a little bit unusual, and I'm trying to understand why
> `uname -a` is still reporting 6.9 after I successfully booted
> bsd.upgrade and saw the upgrade process scroll past.

The email sent to root ("$hostname upgrade log") may contain
useful information.

For an unusual setup you may need to look into how the
install/upgrade script works, see /usr/src/distrib/miniroot.

-- 
Please keep replies on the mailing list.



Re: NSD exit status 11 on 7.0

2021-10-16 Thread Peter J. Philipp
On Fri, Oct 15, 2021 at 08:39:16PM -, Stuart Henderson wrote:
> On 2021-10-15, Peter J. Philipp  wrote:
> > On Fri, Oct 15, 2021 at 08:05:08PM +0200, Otto Moerbeek wrote:
> > [ some cut ]
> >
> >> > Anything else I can collect.
> >> 
> >> You might want to compile and install nsd wit debug symbols info:
> >> 
> >>cd /usr/src/usr.sbin/nsd 
> >>make -f Makefile.bsd-wrapper obj
> >>make -f Makefile.bsd-wrapper clean
> >>DEBUG=-g make -f  Makefile.bsd-wrapper
> >>make -f  Makefile.bsd-wrapper install

This will help a great deal...reason below.

> >> 
> >> Then: collect a gdb trace from a running process: install gdb from ports,
> >> run
> >>egdb --pid=pidofnsdchild /usr/sbin/nsd
> >> 
> >> and wait for the crash.
> >> 
> >> But I'm mostly unfamiliar with the nsd code and what has been changed
> >> recently.  I's say make sure sthen@ and florian@ see this: move to
> >> bugs@ as I do not know if they read misc@.
> >> 
> >>-Otto
> >
> > Hi Otto and Mischa,
> >
> > I'm watching this unfold and I'm trying to convert this packet with tr and 
> > sed but I'm having a hard time, getting this to 101 bytes.  It would be cool
> > if you could show this packet in a hex dump ie. kdump -X or kdump -x.
> >
> > If you feel this really is a packet of nsd-death then I'd be interested in
> > seeing the hexdump privately.  I know how to read some DNS formats but the
> > way it is in the kdump I'm having trouble converting that.
> >
> > Best Regards,
> > -peter
> >
> >> > 
> >> > Mischa
> >> > 
> >> > 
> >> > > 
> >> > >-Otto
> >> > > 
> >> > > >  91127 nsd  CALL
> >> > > > recvfrom(7,0xb2ac85b8000,0x20109,0,0xb2acfa96018,0xb27e485a968)
> >> > > >  91127 nsd  GIO   fd 7 read 101 bytes
> >> > > > "By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A0\^A0\^A1\^A0\^A0\^A0\^A6\^A3\^A0\^Aa\^A2\^Cip6\^Darpa\0\0\f\0\
> >> > > >  \^A\0\0)\^E\M-,\0\0\M^@\0\0\0"
> >> > > >  91127 nsd  STRU  struct sockaddr { AF_INET,
> >> > > > 141.101.75.185:10029 }
> >> > > >  91127 nsd  RET   recvfrom 101/0x65
> >> > > >  91127 nsd  PSIG  SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x10
> >> > > > trapno=6
> >> > > >  36104 nsd  STRU  struct pollfd [2] { fd=16, events=0x1,
> >> > > > revents=0<> } { fd=15, events=0x1, revents=0<> }
> >> > > >  36104 nsd  PSIG  SIGCHLD caught handler=0xb27e47fa340 mask=0<>
> >> 
> >
> >
> 
> $ echo 
> 'By\0\0\0\^A\0\0\0\0\0\^A\^A6\^A0\^A1\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A0\^A1\^A0\^A0\^A0\^A4\^A\^A\0\0)\^E\M-,\0\0\M^@\0\0\0'
>  | unvis | hexdump -C
>   42 79 00 00 00 01 00 00  00 00 00 01 01 36 01 30  |By...6.0|
> 0010  01 31 01 30 01 30 01 30  01 30 01 30 01 30 01 30  |.1.0.0.0.0.0.0.0|
> 0020  01 30 01 30 01 30 01 30  01 30 01 30 01 31 01 30  |.0.0.0.0.0.0.1.0|
> 0030  01 30 01 30 01 34 01 01  00 00 29 05 ac 00 00 80  |.0.0.4).|
> 0040  00 00 00 0a   ||
> 0044

Thanks Stuart, unvis could be a life-saver.  I have analysed this packet
visually and queried it against my own nameserver to get logging.  It really
is fairly normal question packet, the edns0 OPT header is a bit weird in its
size 1452 bytes is what I got (05 ac) and the DO bit is set to on, which is
normal.  In fact there was a lot of these packets in the kdump (about 10 of
them, I didn't check them all though but their size is identical) there was
1 TCP packet with a TCP payload of 103 bytes and DNS payload of 101 bytes,
so even here the packet seems to be fairly identical among all the childs 
that died on sigsegv.  They do differ in the DNS ID among those 10.

I did indulge a little in reading the edns code in nsd, but found no weaknesses
really.

I hope you guys can find more than what I did...

Best Regards,
-peter

> 
> -- 
> Please keep replies on the mailing list.
> 



drmfreeze

2021-10-16 Thread Avon Robertson
Avon Robertson [avo...@xtra.co.nz] wrote:
> Hello misc@,
> 
> Earlier today an AMD host I have froze again. I ssh'd into the host
> and retrieved the output from dmesg, /var/log/messages, and
> /var/run/dmesg.boot.
> 
> I found nothing of note in $HOME/.local/share/xorg/Xorg.0.log.
> 
> At the time of the freeze the ksh script I use to update my local /cvs
> repository was the only programme executing inside the rightmost pane
> of a 3 pane tmux session. I have a log of the output produced by this
> script which is probably of no use to those who have been trying to
> isolate and fix this bug for many months.
> 
> Please advise if any of the above is of use or interest to anyone, and
> if so to which list should I post it.
> 

Chris Cappuccio replied with:

posting the dmesg to this list would be a good start

Thank you for your reply Chris. I recommend that you read the below
dmesg from the bottom to the top.


OpenBSD 7.0 (GENERIC.MP) #212: Mon Sep 13 11:09:43 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 68647477248 (65467MB)
avail mem = 66550976512 (63467MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe8980 (59 entries)
bios0: vendor American Megatrends Inc. version "F2" date 03/14/2018
bios0: Gigabyte Technology Co., Ltd. X470 AORUS ULTRA GAMING
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG HPET SSDT 
UEFI BGRT IVRS SSDT SSDT WSMT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) 
GPPF(S4) GP17(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 Ryzen 7 2700X Eight-Core Processor, 3700.62 MHz, 17-08-02
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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02
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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02
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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache
cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02
cpu3: 

Re: How to set apparently number of VCPUs in VMM

2021-10-16 Thread Omar Polo


Martin  writes:

> Hi there!
>
> In release notes it seems we can set more than one vCPU for guests
> running. The question is how to set it in vm.conf to achieve better
> performance for existed VMs?
>
> Martin

AFAIK a vmd(8) virtual machine can still have only one virtual CPU.  If
I remember correctly the thread on tech@ the "theoretical limit of 512
to the number of allocated vcpus in vmm(4)" should be the global
number of vcpu running, not the cpu per guest (which is still one.)

The thread should be this:

https://marc.info/?l=openbsd-tech=163138318712178=2



Re: Ifconfig error - SIOCSETPFLOW

2021-10-16 Thread Antonino Sidoti
HI,

Yes, on my em0 interface I am using ‘dhcp’ and this is the source IP for pflow. 
The setup is a basic firewall as described in the PF example firewall. 

Interface em0 = external using dhcp (Static IP assigned by carrier)
Interface em1 = internal with static IP (Lan using 10.0.x.x/24)

Output from /etc/hostname.pflow0 (Not real IPs)
flowdst 203.0.113.1:3001 flowsrc 198.51.100.1
pflowproto 10

Thanks

Antonino Sidoti




> On 16 Oct 2021, at 10:39 am, Brian Brombacher  wrote:
> 
> 
> 
>> On Oct 15, 2021, at 7:09 PM, Antonino Sidoti  wrote:
>> 
>> HI,
>> 
>> I am getting this error since upgrading to v7.0;
>> 
>> pf enabled
>> net.inet.ip.forwarding: 0 -> 1
>> net.inet6.ip6.forwarding: 0 -> 1
>> starting network
>> 
>> ifconfig: SIOCSETPFLOW: Can't assign requested address
>> ifconfig: SIOCSETPFLOW: Can't assign requested address
>> 
>> reordering libraries: done.
>> starting early daemons: syslogd pflogd unbound ntpd.
>> starting RPC daemons:.
>> savecore: no core dump
>> checking quotas: done.
>> clearing /tmp
>> kern.securelevel: 0 -> 1
>> creating runtime link editor directory cache.
>> preserving editor files.
>> starting network daemons: sshd snmpd dhcpd rad smtpd.
>> starting package daemons: dhcpcd.
>> starting local daemons: cron.
>> Sat Oct 16 08:06:39 AEDT 2021
>> 
>> I am assuming it is related to the interface ‘pflow0’ which was working fine 
>> in version 6.9. The /etc/hostname.pflow0 is exactly the same as the examples 
>> in the man pages only that the source and destination IP addresses are 
>> different.
>> 
>> Many thanks
>> 
>> Antonino Sidoti
>> 
>> 
>> 
> 
> Are you using DHCP to configure the interface the source IP is on?  Provide 
> some more details of the network setup.