Re: QEMU user-mode

2018-04-27 Thread Vijay Sankar


Quoting Warner Losh :


Greetings,

I was wondering if anybody is using the current stock qemu user-mode code
to run OpenBSD code. The code looks woefully incomplete to my eye, so
incomplete I can't see how it would work for anything useful. I'm not even
sure it would work for anything trivial.

My searching has lead me to conclude that other than Sean Bruno's
qemu-bsd-user github branch, there's no other changes to qemu's bsd-user
patches. However, I thought I'd ask here as well.

Warner


I am not sure if it is user-mode code etc., so the following may not  
be relevant.


The qemu package on OpenBSD 6.2 works very well for my purposes.

In case it helps I am using

/usr/bin/doas env ETHER=em0 /usr/local/bin/qemu-system-x86_64
-net nic,vlan=0,macaddr=AA:BB:CC:01:01:01 -net tap,vlan=0 \
-serial telnet:127.0.0.1:1080,server,nowait \
-monitor telnet:127.0.0.1:1081,server,nowait \
-m 4096 -hda openbsd63.img -nographic &


Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca



Re: Clarification re: rebuilding softraid mirror

2018-04-27 Thread Jordan Geoghegan
Thanks for the reply, I have rebuilt a softraid mirror before, I was 
just hoping for some clarification as the faq wording is a little 
ambiguous as to whether drives can be rebuilt in multi user mode or not. 
I was also curious how the system handles write operations to the array 
while it is rebuilding. Similarly, is the reboot required for the newly 
repaired array to be initialized/function?


I have a simple production storage NAS I am setting up, and would 
appreciate any input on softraid "best practices".




On 04/26/18 17:48, IL Ka wrote:

Hello,

No, you do not need to reboot. At least this is how it worked for me 
for raid 1:


1) bioctl softraid0 said raid degraded
2) I installed new disk (sd2).
3) kenrel reported on console that disk is detected
4) I created MBR using fdisk on it
5) I created disklabel with RAID type on it
6) bioctl -R /dev/sd2a sd0

I suggest you to try it yourself, but not on production system)



On Fri, Apr 27, 2018 at 2:21 AM, Jordan Geoghegan 
> wrote:


Hello,

Sorry for my ignorance, I was hoping someone could clarify for me
the proper procedure for rebuilding a softraid mirror. The man
page/faq says:


        Rebuilding a mirror

When a drive failure happens, you will replace the failed
drive, create the RAID and other disklabel partitions, then
rebuild the mirror. Assuming your RAID volume is sd2 and you
are replacing the failed device with sd1m, the following
commands should work:

    #*bioctl -R /dev/sd1m sd2*
    #*reboot*

These steps can be performed in either single user mode
> or from the
install kernel >.

Does this mean that a RAID rebuild can *only* be performed from
single user mode or install kernel, or is it possible to rebuild
an array while the system is in full operation?

To phrase my question a different way:
Is it possible to hot swap drives and rebuild arrays on the fly,
or will this bork my system?

Thanks,
Jordan Geoghegan






Re: /etc/netstart - order of operations (lo vs physical interfaces)

2018-04-27 Thread Hess THR
who is "jmc" in the header? can someone cc him? or the people who are doing the 
doc? :)

Many thanks. 

> Sent: Friday, April 27, 2018 at 3:28 PM
> From: "Amelia A Lewis" 
> To: misc@openbsd.org
> Subject: Re: /etc/netstart - order of operations (lo vs physical interfaces)
>
> A read of the script itself shows loopback initialized prior to 
> hardware interfaces, at least in 6.2 (haven't upgraded yet).
> 
> On Fri, 27 Apr 2018 08:21:54 -0400, Gabriel Guzman wrote:
> > Just a quick clarification, lo(4) says that the loopback interface
> > should be configured last, and /etc/netstart seems to support this
> > but netstart(8) says that the loopback interface is configured `before`
> > physical interfaces: 
> 
> Date in the man page for lo(4) is 2013. I'm guessing that the network 
> system has moved on since then, and it's actually the lo(4) source 
> that's out of date.
> 
> Or, possibly, the netstart authors aren't aware of the potential 
> problems, so started initializing loopback devices first, and ought to 
> change things.
> 
> :-)
> 
> Amy!
> -- 
> Amelia A. Lewisamyzing {at} talsever.com
> There's someone in my head, but it's not me.
> -- Pink Floyd
> 
> 



Disabling message CRCs in SSHD

2018-04-27 Thread Hess THR
Based on the: 

http://www.vegardno.net/2017/03/fuzzing-openssh-daemon-using-afl.html

I tried to search for these code pieces (I know he was using openbsd-compat and 
not the original OpenSSH code) but didn't found it, didn't even find similar 
for disabling message CRCs:

in the ( https://github.com/openbsd/src )

$ pwd
/src/usr.bin/ssh
$ find . -name packet.c
./packet.c
$ grep -i checksum packet.c
$

Does anyone has any idea, where to disable message CRCs in SSHD? 

It is needed for testing purposes. 

Many-many thanks. 



Openbsd 6.3 + VirtualBox + Vagrant

2018-04-27 Thread Alceu R. de Freitas Jr.
Hello folks,

I just tried a combination of OpenBSD, Vagrant and Virtualbox that's been 
working since OpenBSD version 6.0 and the provisioning fails quite soon after I 
hit "vagrant up".

Initially I thought was something regarding my own scripts, but after some 
testing, I realized that anything execute over the shell (doesn't matter if 
"shell" or "inline" from config.vm.provision), even I simple "echo" returns a 
non-zero exit code.

Following the non-zero return message from Vagrant, I got absolutely nothing 
from STDOUT or STDERR from the executed commands. Even running:

vb.customize ["modifyvm", :id, "--natdnspassdomain1", "off"]

>From the Vagrantfile I got the same behavior.

I tried connecting right after the provisioning failed and was able to find the 
same scripts ("inline") inside /tmp... running them over there didn't generated 
any error.

Here the Vagranfile being used to test this:

https://github.com/glasswalk3r/cpan-openbsd-smoker/blob/master/vagrant/Vagrantfile

By any change anybody experimented such problem?

Thanks!

Alceu





QEMU user-mode

2018-04-27 Thread Warner Losh
Greetings,

I was wondering if anybody is using the current stock qemu user-mode code
to run OpenBSD code. The code looks woefully incomplete to my eye, so
incomplete I can't see how it would work for anything useful. I'm not even
sure it would work for anything trivial.

My searching has lead me to conclude that other than Sean Bruno's
qemu-bsd-user github branch, there's no other changes to qemu's bsd-user
patches. However, I thought I'd ask here as well.

Warner


dmesg - Asus X555LA

2018-04-27 Thread jungle Boogie
Hi All,

Figured I'd see what happens when I load openBSD on a laptop that I
haven't used very much.

dmesg shows several 'not configured' devices, including the Atheros
AR9485 wifi card.


Looks like in March 2014 Stefan said the wifi wasn't ready yet. Given
that four years have passed, I'll probably just use my urtwn0
https://marc.info/?l=openbsd-tech=139963461524621=2



OpenBSD 6.3-current (GENERIC.MP) #11: Tue Apr 24 23:05:32 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4176748544 (3983MB)
avail mem = 4042244096 (3854MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa47be000 (26 entries)
bios0: vendor American Megatrends Inc. version "X555LAB.602" date 07/27/2016
bios0: ASUSTeK COMPUTER INC. X555LAB
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT ECDT MCFG HPET SSDT UEFI SSDT
LPIT ASF! SSDT SSDT SSDT SSDT PCCT SSDT SSDT DMAR BGRT TPM2 MSDM
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4)
PEG2(S4) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP06(S4) RP07(S4)
RP08(S4) PXSX(S4) RP05(S4) GLAN(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-5020U CPU @ 2.20GHz, 2197.10 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,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-5020U CPU @ 2.20GHz, 2196.83 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,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-5020U CPU @ 2.20GHz, 2196.83 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,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-5020U CPU @ 2.20GHz, 2196.83 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,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 1 (RP01)
acpiprt5 at acpi0: bus -1 (RP02)
acpiprt6 at acpi0: bus 2 (RP03)
acpiprt7 at acpi0: bus 3 (RP04)
acpiprt8 at acpi0: bus -1 (RP06)
acpiprt9 at acpi0: bus -1 (RP07)
acpiprt10 at acpi0: bus -1 (RP08)
acpiprt11 at acpi0: bus -1 (RP05)
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PG00, resource for PEG0
acpipwrres1 at acpi0: PG01, resource for PEG1
acpipwrres2 at acpi0: PG02, resource for PEG2
acpipwrres3 at acpi0: WRST
acpipwrres4 at acpi0: WRST
acpipwrres5 at acpi0: WRST
acpipwrres6 at acpi0: WRST

Re: Disk disappeared from system after cold reboot .

2018-04-27 Thread IL Ka
Hello.
I am not OVH expert, but from dmesg
I can't see second drive.

I see only sd0 (20480MB) connected to your VirtIO.
Dobule check that both drives are connected.

> why is it mentioning GUID and not disk path ?

It can work with drive names also, i.e:

"/dev/sd0a /"
but name may be changed when you connect drive to different port.
That is why people use unique disk id

Id is written on disklabel, so you can move drive to different port,
making it appear as sd1 or even sd4, and it still be supported.

To check DUID, use disklabel(8):

$ doas disklabel sd0 | grep duid







On Fri, Apr 27, 2018 at 5:18 PM, Paul Florence <
pflor...@etud.insa-toulouse.fr> wrote:

> Hello everyone,
> I am sending this mail because I currently have a problem with
> OpenBSD 6.2 running on a VM on an OVH server
> (OpenBSD ovhvps.openstacklocal 6.2 GENERIC#132 amd64).
>
> I followed this tutorial for the installation, since it is not
> natively supported by OVH [0].
>
>
> Now my problem is that I have a disk that changed DUID an I can't find it.
> I have two hard-drive : a 20 Gb one for the system, and a 50 Gb one for
> the data. On the OVH control panel both disk are labeled as connected.
>
> Now this is my  `/etc/fstab` :
> a8e29a56dba81f59.b none swap sw
> a8e29a56dba81f59.a / ffs rw 1 1
> a8e29a56dba81f59.k /home ffs rw,nodev,nosuid 1 2
> a8e29a56dba81f59.d /tmp ffs rw,nodev,nosuid 1 2
> a8e29a56dba81f59.f /usr ffs rw,nodev 1 2
> a8e29a56dba81f59.g /usr/X11R6 ffs rw,nodev 1 2
> a8e29a56dba81f59.h /usr/local ffs rw,wxallowed,nodev 1 2
> a8e29a56dba81f59.j /usr/obj ffs rw,nodev,nosuid 1 2
> a8e29a56dba81f59.i /usr/src ffs rw,nodev,nosuid 1 2
> a8e29a56dba81f59.e /var ffs rw,nodev,nosuid 1 2
> 00e91f190cdc9d32.a /var/www/data ffs rw,nodev,auto 1 2
>
> The problem is that upon loading fsck and mount can't find
> `00e91f190cdc9d32`.
>
> Here is the output of `sysctl -a | grep -i disk` :
> hw.disknames=sd0:a8e29a56dba81f59,fd0:
> hw.diskcount=2
> machdep.bios.diskinfo.128=bootdev = 0xa204, \
> cylinders = 1023, heads = 255, sectors = 63
> machdep.bios.diskinfo.129=bootdev = 0xa0010204, \
> cylinders = 1023, heads = 255, sectors = 63
>
> I also have to mention that at first this setup was working perfectly
> but I had to do a cold reboot and then this problem appeared.
>
> I hope I didn't make too much grammar mistakes since English is not my
> native language I try to do my best to write as perfectly as possible.
>
> Please be patient, I am still a student and posting here to learn as
> much as possible. I spent a few weeks searching for solutions, reading
> man pages and trying to understand the root of this problem but I just
> can't figure it out.
>
> Do you have any idea what should I do to recover this disk and finally
> mount it ? What about my strange fstab file, why is it mentioning GUID
> and not disk path ? Does it comes from my installation process ?
>
> I attached the output of dmesg to this mail.
>
> Thanks for your time,
>
> Paul
>
> [0] : (https://raby.sh/installing-openbsd-on-ovhs-vps-2016-kvm-mac
> hines.html).
>
>


Disk disappeared from system after cold reboot .

2018-04-27 Thread Paul Florence

Hello everyone,
I am sending this mail because I currently have a problem with
OpenBSD 6.2 running on a VM on an OVH server
(OpenBSD ovhvps.openstacklocal 6.2 GENERIC#132 amd64).

I followed this tutorial for the installation, since it is not
natively supported by OVH [0].


Now my problem is that I have a disk that changed DUID an I can't find it.
I have two hard-drive : a 20 Gb one for the system, and a 50 Gb one for
the data. On the OVH control panel both disk are labeled as connected.

Now this is my  `/etc/fstab` :
a8e29a56dba81f59.b none swap sw
a8e29a56dba81f59.a / ffs rw 1 1
a8e29a56dba81f59.k /home ffs rw,nodev,nosuid 1 2
a8e29a56dba81f59.d /tmp ffs rw,nodev,nosuid 1 2
a8e29a56dba81f59.f /usr ffs rw,nodev 1 2
a8e29a56dba81f59.g /usr/X11R6 ffs rw,nodev 1 2
a8e29a56dba81f59.h /usr/local ffs rw,wxallowed,nodev 1 2
a8e29a56dba81f59.j /usr/obj ffs rw,nodev,nosuid 1 2
a8e29a56dba81f59.i /usr/src ffs rw,nodev,nosuid 1 2
a8e29a56dba81f59.e /var ffs rw,nodev,nosuid 1 2
00e91f190cdc9d32.a /var/www/data ffs rw,nodev,auto 1 2

The problem is that upon loading fsck and mount can't find 
`00e91f190cdc9d32`.


Here is the output of `sysctl -a | grep -i disk` :
hw.disknames=sd0:a8e29a56dba81f59,fd0:
hw.diskcount=2
machdep.bios.diskinfo.128=bootdev = 0xa204, \
cylinders = 1023, heads = 255, sectors = 63
machdep.bios.diskinfo.129=bootdev = 0xa0010204, \
cylinders = 1023, heads = 255, sectors = 63

I also have to mention that at first this setup was working perfectly
but I had to do a cold reboot and then this problem appeared.

I hope I didn't make too much grammar mistakes since English is not my
native language I try to do my best to write as perfectly as possible.

Please be patient, I am still a student and posting here to learn as
much as possible. I spent a few weeks searching for solutions, reading
man pages and trying to understand the root of this problem but I just
can't figure it out.

Do you have any idea what should I do to recover this disk and finally
mount it ? What about my strange fstab file, why is it mentioning GUID
and not disk path ? Does it comes from my installation process ?

I attached the output of dmesg to this mail.

Thanks for your time,

Paul

[0] : 
(https://raby.sh/installing-openbsd-on-ovhs-vps-2016-kvm-machines.html).


OpenBSD 6.2 (GENERIC) #132: Tue Oct  3 21:18:21 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 4177371136 (3983MB)
avail mem = 4043841536 (3856MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6880 (10 entries)
bios0: vendor SeaBIOS version "2:1.10.2-58953eb7" date 04/01/2014
bios0: OpenStack Foundation OpenStack Nova
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel Core Processor (Haswell, no TSX), 2394.81 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,ARAT
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address fa:16:3e:b6:bc:d2
virtio0: msix shared
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio SCSI" rev 0x00
vioscsi0 at virtio1: qsize 128
scsibus1 at vioscsi0: 255 targets

Re: /etc/netstart - order of operations (lo vs physical interfaces)

2018-04-27 Thread Amelia A Lewis
A read of the script itself shows loopback initialized prior to 
hardware interfaces, at least in 6.2 (haven't upgraded yet).

On Fri, 27 Apr 2018 08:21:54 -0400, Gabriel Guzman wrote:
> Just a quick clarification, lo(4) says that the loopback interface
> should be configured last, and /etc/netstart seems to support this
> but netstart(8) says that the loopback interface is configured `before`
> physical interfaces: 

Date in the man page for lo(4) is 2013. I'm guessing that the network 
system has moved on since then, and it's actually the lo(4) source 
that's out of date.

Or, possibly, the netstart authors aren't aware of the potential 
problems, so started initializing loopback devices first, and ought to 
change things.

:-)

Amy!
-- 
Amelia A. Lewisamyzing {at} talsever.com
There's someone in my head, but it's not me.
-- Pink Floyd



/etc/netstart - order of operations (lo vs physical interfaces)

2018-04-27 Thread Gabriel Guzman

Just a quick clarification, lo(4) says that the loopback interface
should be configured last, and /etc/netstart seems to support this
but netstart(8) says that the loopback interface is configured `before`
physical interfaces: 


from netstart(8): 

> netstart performs the following operations, in the sequence given:
>
>   •   Set the machine's name.
>   •   Configure the loopback interface.
>   •   Configure all the physical interfaces.

from lo(4):
> The loopback interface should be the last interface configured, as
> protocols may use the order of configuration as an indication of
> priority.  The loopback should never be configured first unless no
> hardware interfaces exist.

Typo, or am I misunderstanding something? 
If it's a typo, patch to update netstart(8) inline.

Thanks,
gabe.


index: netstart.8   

   │··
=== 

   │··
RCS file: /cvs/src/share/man/man8/netstart.8,v  

   │··
retrieving revision 1.23

   │··
diff -u -p -r1.23 netstart.8

   │··
--- netstart.8  7 Mar 2018 09:54:23 -   1.23

   │··
+++ netstart.8  27 Apr 2018 12:18:44 -  

   │··
@@ -60,9 +60,9 @@ performs the following operations, in th  

   │··
 .It

   │··
 Set the machine's name.

   │··
 .It

   │··
-Configure the loopback interface.  

   │··
-.It

   │··
 Configure all the physical interfaces. 

   │··
+.It

   │··
+Configure the loopback interface.  

   │··
 .It

   │··
 Configure the following non-physical interfaces:   

   │··
 .Xr trunk 4 ,



Re: crash of OpenBSD 6.3 -stable (amd64 MP kernel) - unswapping kills connections

2018-04-27 Thread Philip Guenther
On Thu, Apr 26, 2018 at 11:21 PM, Infoomatic  wrote:
>
> thanks for your input! Actually, I was never really satisfied with the
> stability of ntopng, so this problem of the memory leak does not really
> surprise me. However, when killing the process, which also means freeing
> swap space, I think it is not an expected behaviour that the system does
> not handle any tcp/ip or icmp connections any more until the swap space is
> fully freed (which, in my case when ntopng used 3 out of 4GB swap, lastet
> for nearly 20 minutes). IMHO, unswapping a process should not influence
> network connectivity that much.
>

You're correct that we don't want the clean up of an exiting process to
affect network processing.  The issue is that our UVM is still under the
kernel lock; work into using more fine-grained locking there has begun but
nothing has really hit the tree yet.


Philip Guenther


Re: crash of OpenBSD 6.3 -stable (amd64 MP kernel) - unswapping kills connections

2018-04-27 Thread Stuart Longland
On 27/04/18 07:21, Infoomatic wrote:
> I think it is not an expected behaviour that the system does not handle any 
> tcp/ip or icmp connections any more until the swap space is fully freed 
> (which, in my case when ntopng used 3 out of 4GB swap, lastet for nearly 20 
> minutes). IMHO, unswapping a process should not influence network 
> connectivity that much.

If physical memory is full, and virtual memory is full, where do you
suppose the kernel should buffer incoming network traffic?

-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



Re: Dell PowerEdge R430/R440 support

2018-04-27 Thread Jan Vlach
Hello Giannis and Claudio,

thank you both for dmesg and confirmation what works. The test system is
on its way, I'll report back with dmesg when it's here.

Have a nice day,
Jan



Re: crash of OpenBSD 6.3 -stable (amd64 MP kernel) - unswapping kills connections

2018-04-27 Thread Otto Moerbeek
On Thu, Apr 26, 2018 at 11:21:57PM +0200, Infoomatic wrote:

> Hi Stuart, 

> thanks for your input! Actually, I was never really satisfied with
> the stability of ntopng, so this problem of the memory leak does not
> really surprise me. However, when killing the process, which also
> means freeing swap space, I think it is not an expected behaviour that
> the system does not handle any tcp/ip or icmp connections any more
> until the swap space is fully freed (which, in my case when ntopng
> used 3 out of 4GB swap, lastet for nearly 20 minutes). IMHO,
> unswapping a process should not influence network connectivity that
> much.

Please wrap your lines.

Depening on how you killed it, it's way more than unswapping: the
program likely accesses (all) its data while shutting down, and as a
conseqeunce is swappping in gigs of data, possibly repeatedly.

If the working set is larger han physical memory, all bets are off.

-Otto


> 
> Regards,
> infoomatic
> 
> 
> > Gesendet: Donnerstag, 26. April 2018 um 16:10 Uhr
> > Von: "Stuart Henderson" 
> > An: misc@openbsd.org
> > Betreff: Re: crash of OpenBSD 6.3 -stable (amd64 MP kernel) - unswapping 
> > kills connections
> >
> > On 2018-04-26, Infoomatic  wrote:
> > > Hi,
> > >
> > > Today I discovered some interesting details: I guess ntopng has a memory 
> > > leak, thus eating all my 4GB RAM and some 3GB swap - this appeared in the 
> > > morning, so after all the backups and heavy traffic occured.
> > > When I fired up a rcctl stop ntopng the ssh connection stalled. The 
> > > firewall could not handle further connections, and established 
> > > connections dropped. The system could not answer to ping packets etc.
> > > This now also happened on a 2nd machine. After 20 minutes (when I was in 
> > > a taxi to the datacenter) I could login again and realized that ntopng 
> > > was stopped and swap was freed.
> > >
> > > I have now disabled ntopng. I kindly ask the devs to take a look at this! 
> > > If you need a testsetup for this or if I can do anything, just contact me.
> > 
> > First off, it's not a big surprise to have a hanging machine if you
> > run it out of memory.
> > 
> > ntopng is not really stable. There is a newer version upstream but it
> > crashes very often with certain packet types suggesting bugs in the packet
> > parsers.
> > 
> > If you run ntopng at all, I would recommend you only run it while you
> > need to investigate traffic, not leave it running unattended permanently.
> > 
> > It might also be a good idea to set login.conf limits for it, if you
> > start it via the rc.d script you can add an "ntopng" class with say
> > datasize=2500M.
> > 
> > 
> > 



Re: Return back dhclient lease time displaying after renew an IP address manually

2018-04-27 Thread Denis
It was favourable to have lease information visible without any
additional commands right after new lease has been obtained...


On 4/26/2018 11:21 PM, Daniel Melameth wrote:
> On Thu, Apr 26, 2018 at 2:11 PM, Denis  wrote:
>> After upgrading 6.2amd64 -> 6.3amd64 there is no lease time info present
>> by renewing an IP address using '#sh /etc/netstart if0' command.
>>
>> Manually run dhclinent shows MAC address of a dhcpd server (very useful)
>> but lease time has been deprecated since 6.2 (very useful for different
>> dhcp servers lease time determining). Hope this helpful information will
>> be returned back in additional to dhcpd server's MAC added in 6.3.
> 
> cat /var/db/dhclient.leases.?
>