subject:"OpenBSD 6.5"

Re: Sparc64 LDOM not working past OpenBSD 6.5

2021-05-12 Thread Andrew Grillet

I have a T1000, and it runs 6.9 in primary and 7 guests.
However, attempts to create and install a new ldom config result
in complete loss of the device tree, and consequent inability to boot.

restore to factory, and then restore the ldom config created with OBSD 6.3
will produce a working system.

This system is available and currently could be used for testing, although
not on the public internet, and only during office hours in Europe/London
timezone - machine must be shut down out of office hours.

Andrew
.

On Wed, 12 May 2021 at 03:22, Ax0n  wrote:
>
> I have a SunFire T2000 that I originally installed 6.1 on. I set up LDOMs
> way back in May 2017. I kept all of the domains up to date until OpenBSD
> 6.6. After that, LDOMs would no longer work. The system would not boot
> unless I reverted back to the single domain default using
> bootmode config="factory-default"
>
> I kind of just forgot about the machine until 6.7 came out. I upgraded, and
> got the same errors upon trying to boot. I re-generated the LDOM config as
> outlined in this blog post I wrote:
>
> http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html
>
> That is, I dumped the factory-default config, used it as a template for the
> new LDOM configuration, edited a config file, applied the config to the
> directory and used ldomctl download to apply the LDOM config before
> resetting the system.
>
> Specifically, the errors I get now (and yes, some are repeats, but it's ALL
> I get from the console while booting) are:
>
> ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
> ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
> ERROR: /pci@780: Invalid hypervisor argument(s). function: b5
> WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node
> WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node
>
> And after that, the system hangs and I must exit to the ALOM system
> controller prompt to do anything further, such as revert the configuration
> and reset to make the system able to boot again.
>
> I searched and found one other person with this problem a while back ago,
> but no resolution. I have hardware right here in front of me and I'm not
> afraid to run -CURRENT and/or test patches to help. I am also willing to
> provide remote SSH access to the system controller if someone wants to hack
> on the hardware directly if it would help, though I think there are a few
> LDOM-capable sparc64 machines in developers' hands already.
>
> dmesg:
> console is /virtual-devices@100/console@1
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2021 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 6.9 (GENERIC.MP) #794: Sun Apr 18 12:34:31 MDT 2021
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
> real mem = 34225520640 (32640MB)
> avail mem = 33608228864 (32051MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root: Sun Fire T200
> cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu2 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu3 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu4 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu5 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu6 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu7 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu8 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu9 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu10 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu11 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu12 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu13 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu14 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu15 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu16 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu17 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu18 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu19 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu20 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu21 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu22 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu23 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu24 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu25 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu26 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu27 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu28 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu29 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu30 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
> cpu31 at mainbus0:

Sparc64 LDOM not working past OpenBSD 6.5

2021-05-11 Thread Ax0n

I have a SunFire T2000 that I originally installed 6.1 on. I set up LDOMs
way back in May 2017. I kept all of the domains up to date until OpenBSD
6.6. After that, LDOMs would no longer work. The system would not boot
unless I reverted back to the single domain default using
bootmode config="factory-default"

I kind of just forgot about the machine until 6.7 came out. I upgraded, and
got the same errors upon trying to boot. I re-generated the LDOM config as
outlined in this blog post I wrote:

http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html

That is, I dumped the factory-default config, used it as a template for the
new LDOM configuration, edited a config file, applied the config to the
directory and used ldomctl download to apply the LDOM config before
resetting the system.

Specifically, the errors I get now (and yes, some are repeats, but it's ALL
I get from the console while booting) are:

ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
ERROR: /pci@780: Invalid hypervisor argument(s). function: b5
WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node
WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node

And after that, the system hangs and I must exit to the ALOM system
controller prompt to do anything further, such as revert the configuration
and reset to make the system able to boot again.

I searched and found one other person with this problem a while back ago,
but no resolution. I have hardware right here in front of me and I'm not
afraid to run -CURRENT and/or test patches to help. I am also willing to
provide remote SSH access to the system controller if someone wants to hack
on the hardware directly if it would help, though I think there are a few
LDOM-capable sparc64 machines in developers' hands already.

dmesg:
console is /virtual-devices@100/console@1
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2021 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.9 (GENERIC.MP) #794: Sun Apr 18 12:34:31 MDT 2021
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 34225520640 (32640MB)
avail mem = 33608228864 (32051MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: Sun Fire T200
cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu2 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu3 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu4 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu5 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu6 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu7 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu8 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu9 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu10 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu11 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu12 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu13 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu14 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu15 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu16 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu17 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu18 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu19 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu20 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu21 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu22 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu23 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu24 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu25 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu26 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu27 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu28 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu29 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu30 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
cpu31 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz
vbus0 at mainbus0
"flashprom" at vbus0 not configured
cbus0 at vbus0
vldc0 at cbus0
vldcp0 at vldc0 chan 0x0: ivec 0x0, 0x1 channel "hvctl"
"ldom-primary" at vldc0 chan 0x1 not configured
"fmactl" at vldc0 chan 0x3 not configured
vldc1 at cbus0
"ldmfma" at vldc1 chan 0x4 not configured
vldc2 at cbus0
vldcp1 at vldc2 chan 0x14: ivec 0x28, 0x29 channel "spds"
"system-management" at vldc2 chan 0xd not configured
vcons0 at vbus0: ivec 0x111: console
vrtc0 at vbus0
"fma" at vbus0 not configured
"sunvts" at vbus0 not configured
"sunmc" at vbus0 not configured
"explorer" at vbus0 not configured
"led" at vbus0 not configured
"flashupdate" at vbus0 not configured
"ncp" at vbus0 not

Re: ixl(4) Driver SR-IOV Physical Function Interface has jitter on OpenBSD 6.5 and 6.6

2019-12-17 Thread Tom Smyth

Hello just to update this thread,
that testing SR-IOV with 1G nics seem to work fine on OpenBSD6.6 amd64 stable
 (and I assume the PCI-E Bridge) would be the same
for both ixl(4) , avf(4) and em(4)
so maybe the pci-e bridge is fine ..and it is just the interaction
between the ixl(4) / avf(4) driver
and the pci-e Bridge for SR-IOV

Ill try with ix(4) once I have freed up the hardware to do that testing




On Sun, 3 Nov 2019 at 14:12, Tom Smyth  wrote:
>
> Hello,
> I managed to get another server and card with identical hardware
> and tested ixl4 on bare metal,
>
> there was no jitter or latency issues with ping times never rising above 0.5 
> ms
> so it looks like  issue I orignally reported was
> something possibly with the PCI-E subsystem ( PCI-E bridge) and
> OpenBSDdrivers from the
> virtual machine (KVM Q35)
> are there other tests that I can run that would help diagnose the issue ?
> dmesg of baremetal server running OpenBSD  below
>
> foobare# dmesg
> OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 68619927552 (65441MB)
> avail mem = 66527576064 (63445MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb570 (172 entries)
> bios0: vendor Intel Corp. version
> "SE5C600.86B.02.06.0007.082420181029" date 08/24/2018
> bios0: Intel Corporation S2600GZ
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S1 S5
> acpi0: tables DSDT FACP APIC SPMI FPDT MCFG WDDT SRAT SLIT MSCT HPET
> SSDT SSDT DMAR HEST BERT ERST EINJ SSDT SSDT SSDT
> acpi0: wakeup devices P0P1(S4) RP01(S5) PXSX(S4) RP02(S5) PXSX(S4)
> RP03(S5) PXSX(S4) RP04(S5) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4)
> PXSX(S4) RP07(S4) PXSX(S4) RP08(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) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2195.00 MHz, 06-3e-04
> 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.73 MHz, 06-3e-04
> 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.73 MHz, 06-3e-04
> 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.74 MHz, 06-3e-04
> 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 8 (application processor)
> cpu4: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.73 MHz, 06-3e-04
> cpu4: 
> 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu4: smt 0, core 4, package 0
> cpu5 at

Re: ixl(4) Driver SR-IOV Physical Function Interface has jitter on OpenBSD 6.5 and 6.6

2019-11-03 Thread Tom Smyth

Hello,
I managed to get another server and card with identical hardware
and tested ixl4 on bare metal,

there was no jitter or latency issues with ping times never rising above 0.5 ms
so it looks like  issue I orignally reported was
something possibly with the PCI-E subsystem ( PCI-E bridge) and
OpenBSDdrivers from the
virtual machine (KVM Q35)
are there other tests that I can run that would help diagnose the issue ?
dmesg of baremetal server running OpenBSD  below

foobare# dmesg
OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 68619927552 (65441MB)
avail mem = 66527576064 (63445MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb570 (172 entries)
bios0: vendor Intel Corp. version
"SE5C600.86B.02.06.0007.082420181029" date 08/24/2018
bios0: Intel Corporation S2600GZ
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S5
acpi0: tables DSDT FACP APIC SPMI FPDT MCFG WDDT SRAT SLIT MSCT HPET
SSDT SSDT DMAR HEST BERT ERST EINJ SSDT SSDT SSDT
acpi0: wakeup devices P0P1(S4) RP01(S5) PXSX(S4) RP02(S5) PXSX(S4)
RP03(S5) PXSX(S4) RP04(S5) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4)
PXSX(S4) RP07(S4) PXSX(S4) RP08(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) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2195.00 MHz, 06-3e-04
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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.73 MHz, 06-3e-04
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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.73 MHz, 06-3e-04
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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.74 MHz, 06-3e-04
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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.73 MHz, 06-3e-04
cpu4: 
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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 16 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 2194.73 MHz, 06-3e-04
cpu5: 
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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 0, core 8, package 0
cpu6 at mainbus0: apid 18

Re: Dante proxy in openbsd 6.5

2019-10-28 Thread Flipchan

Thanks ! That got it working !

On October 28, 2019 7:05:47 AM GMT+01:00, Dieter Rauschenberger 
 wrote:
>Hi,
>
>On Mon, Oct 28, 2019 at 12:07:12AM +0100, Flipchan wrote:
>> Dante has been recently upgraded and since upgrading from 6.4 to 6.5
>dante now wants to know which user it is suppose to be runned as, 
>> 
>> The new part is 
>> "user.privileged: 
>
>user.unprivileged: _sockd
>
>Regards
>  Dieter
>
>> Thanks!
>> 
>> Ciao
>> flipchan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Dante proxy in openbsd 6.5

2019-10-28 Thread Dieter Rauschenberger

Hi,

On Mon, Oct 28, 2019 at 12:07:12AM +0100, Flipchan wrote:
> Dante has been recently upgraded and since upgrading from 6.4 to 6.5 dante 
> now wants to know which user it is suppose to be runned as, 
> 
> The new part is 
> "user.privileged: 

user.unprivileged: _sockd

Regards
  Dieter

> Thanks!
> 
> Ciao
> flipchan

Dante proxy in openbsd 6.5

2019-10-27 Thread Flipchan

Hey!

Dante has been recently upgraded and since upgrading from 6.4 to 6.5 dante now 
wants to know which user it is suppose to be runned as, 

The new part is 
"user.privileged: 
user.unprivileged", is anyone running dante as a proxy server on 6.5 and has 
figured this out ? For me i can not run it with the same privs as the user, 
dante just dies without anymessage (even doe i run it with the verbose flag)

cat sockd2.conf | grep -v \# 
internal: em0 
port = 1080 
external: em0 
socksmethod: none 
user.privileged: currentuser 
user.unprivileged: currentuser 
client pass { from: 0.0.0.0/0 port 1-65535 to: 0.0.0.0/0 log: connect 
disconnect error }
 socks pass { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error } 

$ sockd -V -f sockd2.conf 
just dies



Thanks!

Ciao
flipchan

ixl(4) Driver SR-IOV Physical Function Interface has jitter on OpenBSD 6.5 and 6.6

2019-10-22 Thread Tom Smyth

Hello,
further to my testing of Iavf Intel Virtual Function drivers on Intel XL710
I attached the Q35 KVM virtual machine to the Intel XL710 physical function
(rather than the virtual function )
I with further testing using the SR-IOV interface PF function
the jitter issue  was present ...
I have included ping results, pcidump and dmesg for  virtual machine.
the machine was running on a box with an intel 2x 10 COres  Xeon e5 v2 CPUs
with Hyper threading off,
  --- 10.11.100.1 ping statistics ---
1000 packets transmitted, 1000 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.126/163.669/1000.224/207.690 ms

pcidump
openbsd66# pcidump
Domain /dev/pci0:
 0:0:0: Intel 82G33 Host
 0:1:0: Bochs VGA
 0:26:0: Intel 82801I USB
 0:26:1: Intel 82801I USB
 0:26:2: Intel 82801I USB
 0:26:7: Intel 82801I USB
 0:27:0: Intel 82801I HD Audio
 0:28:0: Red Hat unknown
 0:28:1: Red Hat unknown
 0:28:2: Red Hat unknown
 0:28:3: Red Hat unknown
 0:29:0: Intel 82801I USB
 0:29:1: Intel 82801I USB
 0:29:2: Intel 82801I USB
 0:29:7: Intel 82801I USB
 0:30:0: Intel 82801BA Hub-to-PCI
 0:31:0: Intel 82801IB LPC
 0:31:2: Intel 82801I AHCI
 0:31:3: Intel 82801I SMBus
 1:0:0: Intel XL710 QSFP+
 5:1:0: Red Hat Qemu PCI-PCI
 5:2:0: Red Hat Qemu PCI-PCI
 5:3:0: Red Hat Qemu PCI-PCI
 5:4:0: Red Hat Qemu PCI-PCI
 6:7:0: Intel 82801I AHCI

openbsd66# dmesg
OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 4278050816 (4079MB)
avail mem = 4135776256 (3944MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5900 (10 entries)
bios0: vendor SeaBIOS version "rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org"
date 04/01/2014
bios0: QEMU Standard PC (Q35 + ICH9, 2009)
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT HPET MCFG
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(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 89.76 MHz, 06-3e-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,FSGSBASE,TSC_ADJUST,SMEP,ERMS,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN
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 20, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA method
no _STA

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-06 Thread Sean Kamath

On Oct 4, 2019, at 16:28, Stuart Henderson  wrote:
> 
> On 2019-10-03, Sean Kamath  wrote:
>>> You can disable the reordering by removing /var/db/kernel.SHA256
>>> but be aware that syspatch relies on the reorder_kernel mechanism in
>>> order to apply kernel patches. 
>> 
>> Good to know.  I’m going to do everything I can to avoid turning off 
>> relinking, because I want to go on the big boy rides! :-)
> 
> Even if you only occasionally trigger the relinking by hand when you have
> shutdown other daemons,, it's still better than not at all.

Agreed, but not necessary.

For the archives and anyone who might google this:

I installed fresh OBSD6.5 on another box (I have like 6 of these — this 
particular one had 4.7 on it.  Even getting bsd.rd from 6.5 to boot on it took 
installing a new bootbios :-)).  It took a while to relink the kernel before 
the reboot, but it worked just fine.  Reboots were also fine.  OK ,so a stock 
6.5 on the Alix works.

I thought perhaps the disk layout was updated in 6.5.  Nope (in fact, the other 
machine had a slightly larger swap partition).  OK.

Time to just try adding swap: I added progressively larger swap files until it 
worked, then I did some math.  I think I got down to the lowest reliable swap 
size that allows me to reboot and relink:  About 185M.

So, this seems kinda nuts, because literally the only non-stock thing is nsd 
and unbound, and they’re taking up 137M of VM, but whatever.  They’re tiny 
little boxes and someday just won’t work.  One itty bitty box per thingie, I 
guess (my primary reason for upgrading was to install smokeping to be able to 
bitch at AT about my DSL line.  I’ll do that on the box I just rebuilt.).

Just want to say thanks for all the sage advice.  I really do appreciate it.

Sean

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-04 Thread Stuart Henderson

On 2019-10-03, Sean Kamath  wrote:
>> You can disable the reordering by removing /var/db/kernel.SHA256
>> but be aware that syspatch relies on the reorder_kernel mechanism in
>> order to apply kernel patches. 
>
> Good to know.  I’m going to do everything I can to avoid turning off 
> relinking, because I want to go on the big boy rides! :-)

Even if you only occasionally trigger the relinking by hand when you have
shutdown other daemons,, it's still better than not at all.

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Aaron Mason

Hi Sean

Maybe plug in a spare USB drive and format it for swap?  Swap on CF is
rarely a good idea, especially if you swap often.

On Thu, Oct 3, 2019 at 2:01 PM Sean Kamath  wrote:
>
> Just wanted to say a thank you for everyone’s comments.  I’ve combined all my 
> replies into one mostly to sum everything up.
>
> > On Oct 2, 2019, at 02:16, Stefan Sperling  wrote:
> > Try adding swap space.
> > I have added 2GB of swap space on my alix and it has been running fine ever 
> > since.
>
> My “disk” is 2GB. I don’t even have any X sets loaded as they won’t fit.
>
> > On Oct 2, 2019, at 09:03, Olivier Cherrier  wrote:
> > On mine (only 32 MB of swap), I had to disable kernel relinking.
> > Otherwise, the system more or less collapses at boot time.
>
>
> Yeah, I believe I only have 32MB of swap (I chose the default disk layout oh 
> so long ago).
>
>
> > On Oct 2, 2019, at 08:34, Joe Barnett  wrote:
> > I cannot comment on the upgrade process, but I have had zero fatal issues 
> > running 6.5 on my alix2d13 boards.  That said, memory has been getting 
> > tighter with more recent OpenBSD versions, and swap (as someone else 
> > suggested) should help.  I love these reliable boards, but they are 
> > starting to show their age (at least relative to how I use them with 
> > OpenBSD).
>
> Yeah, so I’m wondering if I want to get a larger CompactFlash card and 
> reinstall, try and be clever and go off the reservation, or just pack in the 
> 9 of these things I have and get an APU.
>
> > On Oct 2, 2019, at 09:15, Stuart Henderson  wrote:
> > After boot, the kernel is relinked in a random order in the background
> > ("/usr/libexec/reorder_kernel &" in /etc/rc).
>
> Yes, I’m familiar with why it’s done.  I was mostly wondering if I broke 
> something because I’ve not had this problem since I got these things (I don’t 
> even know how long ago), and 6.5 just killed it.
>
> > Unfortunately the Alix doesn't have much RAM and if you have pretty
> > much anything other than a minimal set of daemons running it won't
> > cope well.
>
> I’m running nsd and unbound.  I can turn off smtpd. . . What I would be nice 
> to do is delay starting daemons until relinking is done.  Regardless, I think 
> I have my answer about why it’s falling over.
>
> > You can disable the reordering by removing /var/db/kernel.SHA256
> > but be aware that syspatch relies on the reorder_kernel mechanism in
> > order to apply kernel patches.
>
> Good to know.  I’m going to do everything I can to avoid turning off 
> relinking, because I want to go on the big boy rides! :-)
>
> Sean
>


-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Sean Kamath

Just wanted to say a thank you for everyone’s comments.  I’ve combined all my 
replies into one mostly to sum everything up.

> On Oct 2, 2019, at 02:16, Stefan Sperling  wrote:
> Try adding swap space.
> I have added 2GB of swap space on my alix and it has been running fine ever 
> since.

My “disk” is 2GB. I don’t even have any X sets loaded as they won’t fit.

> On Oct 2, 2019, at 09:03, Olivier Cherrier  wrote:
> On mine (only 32 MB of swap), I had to disable kernel relinking.
> Otherwise, the system more or less collapses at boot time.

Yeah, I believe I only have 32MB of swap (I chose the default disk layout oh so 
long ago).

> On Oct 2, 2019, at 08:34, Joe Barnett  wrote:
> I cannot comment on the upgrade process, but I have had zero fatal issues 
> running 6.5 on my alix2d13 boards.  That said, memory has been getting 
> tighter with more recent OpenBSD versions, and swap (as someone else 
> suggested) should help.  I love these reliable boards, but they are starting 
> to show their age (at least relative to how I use them with OpenBSD).

Yeah, so I’m wondering if I want to get a larger CompactFlash card and 
reinstall, try and be clever and go off the reservation, or just pack in the 9 
of these things I have and get an APU.

> On Oct 2, 2019, at 09:15, Stuart Henderson  wrote:
> After boot, the kernel is relinked in a random order in the background
> ("/usr/libexec/reorder_kernel &" in /etc/rc). 

Yes, I’m familiar with why it’s done.  I was mostly wondering if I broke 
something because I’ve not had this problem since I got these things (I don’t 
even know how long ago), and 6.5 just killed it.

> Unfortunately the Alix doesn't have much RAM and if you have pretty
> much anything other than a minimal set of daemons running it won't
> cope well.

I’m running nsd and unbound.  I can turn off smtpd. . . What I would be nice to 
do is delay starting daemons until relinking is done.  Regardless, I think I 
have my answer about why it’s falling over.

> You can disable the reordering by removing /var/db/kernel.SHA256
> but be aware that syspatch relies on the reorder_kernel mechanism in
> order to apply kernel patches. 

Good to know.  I’m going to do everything I can to avoid turning off relinking, 
because I want to go on the big boy rides! :-)

Sean

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Stuart Henderson

On 2019-10-02, Sean Kamath  wrote:
> Hi.
>
> I’m hoping someone either has a cluebat or some helpful suggestions beyond 
> “reinstall”.
>
> I had an alix 2d13 running OpenBSD 6.3.  I finally got around to upgrading to 
> 6.4 (via https://www.openbsd.org/faq/upgrade64.html), and that seemed to go 
> just fine (I used the Upgrading Manually section, since I don’t have (easy) 
> access to the console).
>
> I let that run for a day, just to make sure all was well, and then attempted 
> an upgrade to 6.5 (via https://www.openbsd.org/faq/upgrade65.html), again 
> using the “Upgrading Manually” section.
>
> This time, between smtpd and relinking the kernel, it appears my Alix board 
> is quickly running out of memory.  Within a few seconds the sr rate is in the 
> 20K range.  I stopped the ld for relinking, and killed SMTPD in order to 
> finish the install (the makedev ALL, sysmerge, pkg_update -u bits), and that 
> all ran fine.  But about 15-20 minutes after a reboot, the box just goes off 
> the network, and there’s not much I can do.
>
> I can download and reinstall 6.5, but was hoping to avoid that pain, but I 
> just want to make sure 6.5 has no issues on the Alix boards. . .
>
> Thanks!  I’d attach dmesg, but the box is dead again. . .  If anyone wants to 
> dive into what’s going on, just let me know what info you want to see.
>
> Sean
>
>

After boot, the kernel is relinked in a random order in the background
("/usr/libexec/reorder_kernel &" in /etc/rc). This is done so that
there will be a different memory layout on different boots, making
it harder to carry out types of attack that rely on knowing where
things are in the kernel.

Unfortunately the Alix doesn't have much RAM and if you have pretty
much anything other than a minimal set of daemons running it won't
cope well.

You can disable the reordering by removing /var/db/kernel.SHA256
but be aware that syspatch relies on the reorder_kernel mechanism in
order to apply kernel patches. So if you do this and need to apply
such patches, re-enable it temporarily before running syspatch:
"sha256 -h /var/db/kernel.SHA256 /bsd" - stop any unnecessary
processes - then run syspatch. After syspatch has finished
you can remove kernel.SHA256 again before rebooting.

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Theo de Raadt

Olivier Cherrier  wrote:

> On Wed, Oct 02, 2019 at 11:16:21AM +0200, s...@stsp.name wrote:
> > Try adding swap space.
> > I have added 2GB of swap space on my alix and it has been running fine ever 
> > since.
>  
> On mine (only 32 MB of swap), I had to disable kernel relinking.
> Otherwise, the system more or less collapses at boot time.

You must be at least this tall to go onto the big boy rides.

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Olivier Cherrier

On Wed, Oct 02, 2019 at 11:16:21AM +0200, s...@stsp.name wrote:
> Try adding swap space.
> I have added 2GB of swap space on my alix and it has been running fine ever 
> since.

On mine (only 32 MB of swap), I had to disable kernel relinking.
Otherwise, the system more or less collapses at boot time.

-- 
Olivier Cherrier
mailto:o...@symacx.com

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Joe Barnett


On 2019-10-01 22:46, Sean Kamath wrote:

Hi.

I’m hoping someone either has a cluebat or some helpful suggestions
beyond “reinstall”.

I had an alix 2d13 running OpenBSD 6.3.  I finally got around to
upgrading to 6.4 (via https://www.openbsd.org/faq/upgrade64.html), and
that seemed to go just fine (I used the Upgrading Manually section,
since I don’t have (easy) access to the console).

I let that run for a day, just to make sure all was well, and then
attempted an upgrade to 6.5 (via
https://www.openbsd.org/faq/upgrade65.html), again using the
“Upgrading Manually” section.

This time, between smtpd and relinking the kernel, it appears my Alix
board is quickly running out of memory.  Within a few seconds the sr
rate is in the 20K range.  I stopped the ld for relinking, and killed
SMTPD in order to finish the install (the makedev ALL, sysmerge,
pkg_update -u bits), and that all ran fine.  But about 15-20 minutes
after a reboot, the box just goes off the network, and there’s not
much I can do.

I can download and reinstall 6.5, but was hoping to avoid that pain,
but I just want to make sure 6.5 has no issues on the Alix boards. . .


I cannot comment on the upgrade process, but I have had zero fatal 
issues running 6.5 on my alix2d13 boards.  That said, memory has been 
getting tighter with more recent OpenBSD versions, and swap (as someone 
else suggested) should help.  I love these reliable boards, but they are 
starting to show their age (at least relative to how I use them with 
OpenBSD).




Thanks!  I’d attach dmesg, but the box is dead again. . .  If anyone
wants to dive into what’s going on, just let me know what info you
want to see.

Sean

Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Stefan Sperling

On Tue, Oct 01, 2019 at 10:46:50PM -0700, Sean Kamath wrote:
> Hi.
> 
> I’m hoping someone either has a cluebat or some helpful suggestions beyond 
> “reinstall”.

Try adding swap space.
I have added 2GB of swap space on my alix and it has been running fine ever 
since.

I avoided a reinstall by repurposing unused /usr/src and /usr/obj partitions.
Snippet from /etc/fstab:

#/dev/wd0i /usr/src ffs rw,nodev,nosuid,softdep 1 2
#/dev/wd0j /usr/obj ffs rw,nodev,nosuid,softdep 1 2
/dev/wd0i none swap sw 0 0
/dev/wd0j none swap sw 0 0

Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Sean Kamath

Hi.

I’m hoping someone either has a cluebat or some helpful suggestions beyond 
“reinstall”.

I had an alix 2d13 running OpenBSD 6.3.  I finally got around to upgrading to 
6.4 (via https://www.openbsd.org/faq/upgrade64.html), and that seemed to go 
just fine (I used the Upgrading Manually section, since I don’t have (easy) 
access to the console).

I let that run for a day, just to make sure all was well, and then attempted an 
upgrade to 6.5 (via https://www.openbsd.org/faq/upgrade65.html), again using 
the “Upgrading Manually” section.

This time, between smtpd and relinking the kernel, it appears my Alix board is 
quickly running out of memory.  Within a few seconds the sr rate is in the 20K 
range.  I stopped the ld for relinking, and killed SMTPD in order to finish the 
install (the makedev ALL, sysmerge, pkg_update -u bits), and that all ran fine. 
 But about 15-20 minutes after a reboot, the box just goes off the network, and 
there’s not much I can do.

I can download and reinstall 6.5, but was hoping to avoid that pain, but I just 
want to make sure 6.5 has no issues on the Alix boards. . .

Thanks!  I’d attach dmesg, but the box is dead again. . .  If anyone wants to 
dive into what’s going on, just let me know what info you want to see.

Sean

Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Maurice McCarthy

Thank you for the clarification!

Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Theo de Raadt

Harald Dunkel  wrote:

> On 8/1/19 2:33 PM, Maurice McCarthy wrote:
> > In the past it was not uncommon for non-X programs in base to have
> > dependencies in Xenocara. Are you certain that this is no longer so?
> >
> 
> Yup

Never been the case.  No base program uses a include or library from X.
There is 1 feature that has a runtime dependency, and there used to be
a 2nd one which was deleted.  X needs base, but base does not need X.

The real issue is we rarely create non-X variations of ports. Users
can install a package intending to only used the non-X aspects of
such software, but if it links against X ... if they avoided install
the X sets in particularily xbase, then they are SOL.

So, I'll say it again: people saving disk space in this way are largely
being foolish, or selecting the practice of "non-default install, so
you own all the pieces".  When people make non-default changes to
their systems they should think long and hard before submitting any
bug reports of any kind, since the problem could be caused by their
own decisions...

Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Harald Dunkel


On 8/1/19 2:33 PM, Maurice McCarthy wrote:

In the past it was not uncommon for non-X programs in base to have
dependencies in Xenocara. Are you certain that this is no longer so?



Yup

Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Stuart Henderson

On 2019-08-01, Harald Dunkel  wrote:
> Hi folks,
>
> On 7/30/19 3:08 PM, Hrvoje Popovski wrote:
>> 
>> try to update both boxes to latest snapshot at least because in snapshot
>> you have excellent tool called sysupgrade ... you will love it :)
>> 
>> with this tool you can upgrade os to latest snapshot without any problem
>> over ssh :)
>> 
> This is cool.
>
> Due to space and speed restrictions (compact flash card) and to reduce
> downtime I would like to avoid the games and the Xwindow "balast" on my
> gateways. Does sysupgrade recognize the tar balls that are already
> installed, or does it become a "sysinstall" in this case?
>
> Sorry for asking, but the man page https://man.openbsd.org/sysupgrade
> doesn't tell.

A normal sysupgrade run installs all sets.

You can manually do part of what you want with sysupgrade -n, this still
downloads all sets but you're able to rm the unwanted ones before rebooting
onto the bsd.upgrade kernel and at least save untarring them.

Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Maurice McCarthy

In the past it was not uncommon for non-X programs in base to have
dependencies in Xenocara. Are you certain that this is no longer so?

Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Brian Brombacher

Use the -n option to sysupgrade to not reboot after files are downloaded and 
verified.  Then delete the unwanted tarballs as mentioned from 
/home/_sysupgrade/ and reboot.

See sysupgrade(8): https://man.openbsd.org/sysupgrade

> On Aug 1, 2019, at 7:31 AM, Antal Ispanovity  wrote:
> 
> 2019-08-01 8:08 GMT+02:00, Harald Dunkel :
>> Hi folks,
>> 
>>> On 7/30/19 3:08 PM, Hrvoje Popovski wrote:
>>> 
>>> try to update both boxes to latest snapshot at least because in snapshot
>>> you have excellent tool called sysupgrade ... you will love it :)
>>> 
>>> with this tool you can upgrade os to latest snapshot without any problem
>>> over ssh :)
>>> 
>> This is cool.
>> 
>> Due to space and speed restrictions (compact flash card) and to reduce
>> downtime I would like to avoid the games and the Xwindow "balast" on my
>> gateways. Does sysupgrade recognize the tar balls that are already
>> installed, or does it become a "sysinstall" in this case?
> Iif I remember correctly it doesn't. Someone solved this by removing
> the unnecessary tarballs from the _sysupgrade folder and performed the
> upgrade after it.
>> 
>> Sorry for asking, but the man page https://man.openbsd.org/sysupgrade
>> doesn't tell.
>> 
>> 
>> Thanx in advance
>> Harri
>> 
>> 
>

Re: sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Antal Ispanovity

2019-08-01 8:08 GMT+02:00, Harald Dunkel :
> Hi folks,
>
> On 7/30/19 3:08 PM, Hrvoje Popovski wrote:
>>
>> try to update both boxes to latest snapshot at least because in snapshot
>> you have excellent tool called sysupgrade ... you will love it :)
>>
>> with this tool you can upgrade os to latest snapshot without any problem
>> over ssh :)
>>
> This is cool.
>
> Due to space and speed restrictions (compact flash card) and to reduce
> downtime I would like to avoid the games and the Xwindow "balast" on my
> gateways. Does sysupgrade recognize the tar balls that are already
> installed, or does it become a "sysinstall" in this case?
Iif I remember correctly it doesn't. Someone solved this by removing
the unnecessary tarballs from the _sysupgrade folder and performed the
upgrade after it.
>
> Sorry for asking, but the man page https://man.openbsd.org/sysupgrade
> doesn't tell.
>
>
> Thanx in advance
> Harri
>
>

sysupgrade (Was: Re: Kernel crash in OpenBSD 6.5)

2019-08-01 Thread Harald Dunkel


Hi folks,

On 7/30/19 3:08 PM, Hrvoje Popovski wrote:


try to update both boxes to latest snapshot at least because in snapshot
you have excellent tool called sysupgrade ... you will love it :)

with this tool you can upgrade os to latest snapshot without any problem
over ssh :)


This is cool.

Due to space and speed restrictions (compact flash card) and to reduce
downtime I would like to avoid the games and the Xwindow "balast" on my
gateways. Does sysupgrade recognize the tar balls that are already
installed, or does it become a "sysinstall" in this case?

Sorry for asking, but the man page https://man.openbsd.org/sysupgrade
doesn't tell.


Thanx in advance
Harri

OpenBSD 6.5 is much less responsive (high "spin" state)

2019-07-21 Thread Federico Giannici

Recently I upgraded an OpenBSD amd64 server from 6.3 to 6.5 (rapidly 
passing through 6.4). This a monitoring server with a lot of processes 
that send "ping" (both ICMP and UDP) packets to a great number of hosts. 
So there is a great number of processes but they spend most of their 
time waiting (for packets to return).


Since the upgrade to 6.5 I have seen a GREAT increase in ping delays and 
variance. It seems that the system is much less "real-time" (yes, I know 
that OpenBSD is not a REAL real-time system).


I noticed that, when many processes are running, a lot of time is spent 
in "spin" state (even more than 50%).


Here it is an example of "top" output:

load averages:  5.98,  5.65,  5.82
350 processes: 68 running, 278 idle, 4 on processor
CPU0 states:  0.0% user,  6.7% nice, 42.3% sys, 39.4% spin,  1.0% intr, 
10.6% idle
CPU1 states:  1.0% user,  5.7% nice, 28.6% sys, 57.1% spin,  0.0% intr, 
7.6% idle
CPU2 states:  0.0% user,  1.9% nice, 24.8% sys, 61.0% spin,  0.0% intr, 
12.4% idle
CPU3 states:  1.9% user,  4.8% nice, 21.9% sys, 63.8% spin,  0.0% intr, 
7.6% idle

Memory: Real: 6309M/8558M act/tot Free: 23G Cache: 1031M Swap: 0K/20G

Is this something "normal"?

Is there something I can do to return the system to be more responsive?
Where I have to direct my efforts?

Thanks.

Re: Blank screen after installing OpenBSD 6.5 - solved

2019-07-17 Thread oxstone

Hello,

I reinstalled using the OpenBSD/amd64 install65.fs file.

It works. =)

Thank you very much to all of you for your help !

Nicolas.


> Gesendet: Mittwoch, 17. Juli 2019 um 13:32 Uhr
> Von: "Stefan Sperling" 
> An: oxst...@gmx.net
> Cc: misc@openbsd.org
> Betreff: Re: Blank screen after installing OpenBSD 6.5
>
> On Wed, Jul 17, 2019 at 01:15:26PM +0200, oxst...@gmx.net wrote:
> > Hello,
> > 
> > I recently installed OpenBSD 6.5 on an i386 router.
> > The intallation process went fine. However, I got a black screen after 
> > rebooting.
> > 
> > I tried opening a SSH session, but the computer doesn't reply.
> > 
> > The screen is attached using a VGA cable. The computer send a signal over 
> > that cable. If I detach it from the router, the screen turns off. If I plug 
> > it back, the screen turns on (but nothing is displayed).
> > 
> > I send you the dmesg output. I took pictures of the output and used an OCR 
> > to convert them to text format.
> > 
> > Thank you !
> 
> Your CPU should be capable of running OpenBSD/amd64.
> 
> Please try to install that instead of OpenBSD/i386.
>  
> > OpenBSD 6.5 (RAMDISC_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISC_CD
> > real mem  = 2029793280 (1935MB)
> > avail mem = 1983680512 (1891MB)
> > mainbus0 at root
> > bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
> > bios0: vendor American Megatrends Inc. version "4.6.5" date 07/10/2016
> > bios0: INTEL Corporation ChiefRiver
> > acpi0 at bios0: rev 2
> > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT
> > acpimadt0 at acpi0 addr 0xfee0: PC—AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("Genuinelntel" 686-class) 
> > 1.80 GH
> > z, 06-3a-09
> > cpu0: 
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
> > LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> > .EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NX
> > E,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SHEP,ERMS,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> 
>

Re: Blank screen after installing OpenBSD 6.5

2019-07-17 Thread Jonathan Gray

On Wed, Jul 17, 2019 at 01:32:37PM +0200, Stefan Sperling wrote:
> On Wed, Jul 17, 2019 at 01:15:26PM +0200, oxst...@gmx.net wrote:
> > Hello,
> > 
> > I recently installed OpenBSD 6.5 on an i386 router.
> > The intallation process went fine. However, I got a black screen after 
> > rebooting.
> > 
> > I tried opening a SSH session, but the computer doesn't reply.
> > 
> > The screen is attached using a VGA cable. The computer send a signal over 
> > that cable. If I detach it from the router, the screen turns off. If I plug 
> > it back, the screen turns on (but nothing is displayed).
> > 
> > I send you the dmesg output. I took pictures of the output and used an OCR 
> > to convert them to text format.
> > 
> > Thank you !
> 
> Your CPU should be capable of running OpenBSD/amd64.
> 
> Please try to install that instead of OpenBSD/i386.

Or an i386 snapshot.  There were known problems running the linux 4.4 based
drm that was part of OpenBSD 6.5 on ivy bridge with i386 that don't show up
with the linux 4.19 based drm we have in -current.

>  
> > OpenBSD 6.5 (RAMDISC_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISC_CD
> > real mem  = 2029793280 (1935MB)
> > avail mem = 1983680512 (1891MB)
> > mainbus0 at root
> > bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
> > bios0: vendor American Megatrends Inc. version "4.6.5" date 07/10/2016
> > bios0: INTEL Corporation ChiefRiver
> > acpi0 at bios0: rev 2
> > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT
> > acpimadt0 at acpi0 addr 0xfee0: PC???AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("Genuinelntel" 686-class) 
> > 1.80 GH
> > z, 06-3a-09
> > cpu0: 
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
> > LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> > .EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NX
> > E,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SHEP,ERMS,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>

Re: Blank screen after installing OpenBSD 6.5

2019-07-17 Thread Stefan Sperling

On Wed, Jul 17, 2019 at 01:15:26PM +0200, oxst...@gmx.net wrote:
> Hello,
> 
> I recently installed OpenBSD 6.5 on an i386 router.
> The intallation process went fine. However, I got a black screen after 
> rebooting.
> 
> I tried opening a SSH session, but the computer doesn't reply.
> 
> The screen is attached using a VGA cable. The computer send a signal over 
> that cable. If I detach it from the router, the screen turns off. If I plug 
> it back, the screen turns on (but nothing is displayed).
> 
> I send you the dmesg output. I took pictures of the output and used an OCR to 
> convert them to text format.
> 
> Thank you !

Your CPU should be capable of running OpenBSD/amd64.

Please try to install that instead of OpenBSD/i386.
 
> OpenBSD 6.5 (RAMDISC_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISC_CD
> real mem  = 2029793280 (1935MB)
> avail mem = 1983680512 (1891MB)
> mainbus0 at root
> bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
> bios0: vendor American Megatrends Inc. version "4.6.5" date 07/10/2016
> bios0: INTEL Corporation ChiefRiver
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT
> acpimadt0 at acpi0 addr 0xfee0: PC—AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("Genuinelntel" 686-class) 1.80 
> GH
> z, 06-3a-09
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
> LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> .EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NX
> E,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SHEP,ERMS,SENSOR,ARAT,XSAVEOPT,MELTDOWN

Re: Blank screen after installing OpenBSD 6.5

2019-07-17 Thread Tom Smyth

have a look at man boot ...
you need to set tty to the correct serial port com0 com1 etc...
and you need to set the Baud rate... spec .. depending rotuer baud settings
115200  and N 8 1 ...

On Wed, 17 Jul 2019 at 12:22,  wrote:

> Hello,
>
> I recently installed OpenBSD 6.5 on an i386 router.
> The intallation process went fine. However, I got a black screen after
> rebooting.
>
> I tried opening a SSH session, but the computer doesn't reply.
>
> The screen is attached using a VGA cable. The computer send a signal over
> that cable. If I detach it from the router, the screen turns off. If I plug
> it back, the screen turns on (but nothing is displayed).
>
> I send you the dmesg output. I took pictures of the output and used an OCR
> to convert them to text format.
>
> Thank you !
>
> OpenBSD 6.5 (RAMDISC_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISC_CD
> real mem  = 2029793280 (1935MB)
> avail mem = 1983680512 (1891MB)
> mainbus0 at root
> bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
> bios0: vendor American Megatrends Inc. version "4.6.5" date 07/10/2016
> bios0: INTEL Corporation ChiefRiver
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT
> acpimadt0 at acpi0 addr 0xfee0: PC—AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("Genuinelntel" 686-class)
> 1.80 GH
> z, 06-3a-09
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
>
> LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
>
> .EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NX
>
> E,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SHEP,ERMS,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpiprt0 at acpi0: bus (PCI0)
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (P0P1)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus 2 (RP02)
> acpiprt4 at acpi0: bus 3 (RP03)
> acpiprt5 at acpi0: bus 4 (RP04)
> acpiprt6 at acpi0: bus 5 (RP05)
> acpiprt7 at acpi0: bus 6 (RP06)
> acpiprt8 at acpi0: bus -1 (RP07)
> acpiprt9 at acpi0: bus -1 (RP08)
> acpiprt10 at acpi0: bus -1 (PEG0)
> acpiprt11 at acpi0: bus -1 (PEG1)
> acpiprt12 at acpi0: bus -1 (PEG2)
> acpiprt13 at acpi0: bus -1 (PEG3)
> acpiec0 at acpi0: not present
> acpicpu at acpi0 not configured
> acpipwrres at acpi0 not configured
> acpipwrres at acpi0 not configured
> acpipwrres at acpi0 not configured
> acpipwrres at acpi0 not configured
> acpipwrres at acpi0 not configured
> acpitz at acpi0 not configured
> acpitz at acpi0 not configured
> "PNP0A08" at acpi0 not configured
> acpicmos0 at acpi0
> "PNP0C0C" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> bios0: ROM list: 0xc/0xf000
> pci at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 2500" rev 0x09
> wsdisplay0 at vgal mux 1: console (80x25, vt100 emulation)
> xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI
> 1.0
> usb0 at xhciO: USB revision 3.0
> uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
> 3.00/1.00 ad
> dr 1
> "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
> ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int
> 16
> usbl at ehci0: USB revision 2.0
> uhubl at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev
> 2.00/1.00 ad
> dr 1
> "Intel 7 Series HD Audio" rev 0x04 at pcio dev 27 function 0 not configured
> ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: apic 2 int
> 16
> pci1 at ppb0 bus 1
> em0 at pci1 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address
> 0c:e8:5c:68:c
> e:88
> ppb1 at pci0 dev 28 function "Intel 7 Series PCIE" rev 0xc4: apic 2 int 17
> pci2 at ppb1 bus 2
> em1 at pci2 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address
> 0c:e8:5c:68:c
> e:89
> ppb2 at pci0 dev 28 function "Intel 7 Series PCIE" rev 0xc4: apic 2 int 18
> pci3 at ppb2 bus 3
> em2 at pci3

Blank screen after installing OpenBSD 6.5

2019-07-17 Thread oxstone

Hello,

I recently installed OpenBSD 6.5 on an i386 router.
The intallation process went fine. However, I got a black screen after 
rebooting.

I tried opening a SSH session, but the computer doesn't reply.

The screen is attached using a VGA cable. The computer send a signal over that 
cable. If I detach it from the router, the screen turns off. If I plug it back, 
the screen turns on (but nothing is displayed).

I send you the dmesg output. I took pictures of the output and used an OCR to 
convert them to text format.

Thank you !

OpenBSD 6.5 (RAMDISC_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISC_CD
real mem  = 2029793280 (1935MB)
avail mem = 1983680512 (1891MB)
mainbus0 at root
bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
bios0: vendor American Megatrends Inc. version "4.6.5" date 07/10/2016
bios0: INTEL Corporation ChiefRiver
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC—AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("Genuinelntel" 686-class) 1.80 GH
z, 06-3a-09
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
.EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NX
E,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SHEP,ERMS,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus (PCI0)
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus 4 (RP04)
acpiprt6 at acpi0: bus 5 (RP05)
acpiprt7 at acpi0: bus 6 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: not present
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
acpitz at acpi0 not configured
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
"PNP0C0C" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xf000
pci at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 2500" rev 0x09
wsdisplay0 at vgal mux 1: console (80x25, vt100 emulation)
xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI 1.0
usb0 at xhciO: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 ad
dr 1
"Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16
usbl at ehci0: USB revision 2.0
uhubl at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 ad
dr 1
"Intel 7 Series HD Audio" rev 0x04 at pcio dev 27 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: apic 2 int 16
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address 0c:e8:5c:68:c
e:88
ppb1 at pci0 dev 28 function "Intel 7 Series PCIE" rev 0xc4: apic 2 int 17
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address 0c:e8:5c:68:c
e:89
ppb2 at pci0 dev 28 function "Intel 7 Series PCIE" rev 0xc4: apic 2 int 18
pci3 at ppb2 bus 3
em2 at pci3 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address 0c:e8:5c:68:c
e:8a
ppb3 at pci0 dev 28 function "Intel 7 Series PCIE" rev 0xc4: apic 2 int 19
pci4 at ppb3 bus 4
em3 at pci4 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address 0c:e8:5c:68:c
e:8b
ppb4 at pci0 dev 28 function "Intel 7 Series PCIE" rev 0xc4: apic 2 int 16
pci5 at ppb4 bus 5
em4 at pci5 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address 0c:e8:5c:68:c
e:8c
ppb5 at pci0 dev 28 function "Intel 7 Series PCIE" rev 0xc4: apic 2 int 17
pci6 at ppb5 bus 6
em5 at pci6 dev 0 function 0 "Intel 8258V" rev 0x00: msi, address 0c:e8:5c:68:c
e:8d
ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 i

Re: rrdtool libpthread-stubs error / openbsd 6.5

2019-07-12 Thread Tor Houghton

On Fri, Jul 12, 2019 at 12:11:55PM -, Stuart Henderson wrote:
> 
> I don't think you have updated your packages.
> 

You're right of course. :-#

Thanks!

Tor

Re: rrdtool libpthread-stubs error / openbsd 6.5

2019-07-12 Thread Stuart Henderson

On 2019-07-12, Tor Houghton  wrote:
> Hello,
>
> When I try to run rrdtool, I get the followiing error:
>
> $ rrdtool 
> ld.so: rrdtool: can't load library 'libpthread-stubs.so.2.0'
> Killed
>
> This, I suppose, has been happening since I upgraded from 6.2, but didn't
> catch as it's something I run at home.
>
> Anyone got any hints as to what to do to resolve it?
>
> Tor
>
>

I don't think you have updated your packages.

rrdtool libpthread-stubs error / openbsd 6.5

2019-07-12 Thread Tor Houghton

Hello,

When I try to run rrdtool, I get the followiing error:

$ rrdtool 
ld.so: rrdtool: can't load library 'libpthread-stubs.so.2.0'
Killed

This, I suppose, has been happening since I upgraded from 6.2, but didn't
catch as it's something I run at home.

Anyone got any hints as to what to do to resolve it?

Tor

Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

2019-06-05 Thread Russell Sutherland

Done.

Russell P. Sutherland   Email: russell . sutherland @ utoronto dawt ca
Network Engineer, I+TS   Voice: +1.416.978.0470
4 Bancroft Ave., Rm. 102  Cell: +1.416.803.0080
University of TorontoFax:   +1.416.978.6620
Toronto, ON  M5S 1C1

From: owner-m...@openbsd.org  on behalf of Hrvoje 
Popovski 
Sent: Wednesday, June 5, 2019 05:59
To: misc@openbsd.org
Subject: Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

On 4.6.2019. 21:22, Russell Sutherland wrote:
> I tried loading current on the device and the same result:
>
> OpenBSD 6.5-current (GENERIC.MP) #5: Mon Jun  3 07:46:49 MDT 2019
>
> # netstat -in
> NameMtu   Network Address  Ipkts IfailOpkts Ofail 
> Colls
> lo0 327680 00 0 > 0
> lo0 32768 ::1/128 ::1  0 00 0 > 0
> lo0 32768 fe80::%lo0/ fe80::1%lo0  0 00 0 > 0
> lo0 32768 127/8   127.0.0.10 00 0 > 0
> em0 150000:0d:b9:43:9b:3031715 0   120479 7 > 0
> em1 150000:0d:b9:43:9b:31   123252   11630860 0 > 0
> em2 150000:0d:b9:43:9b:32 1672 0  625 0 > 0
> em2 1500  128.100.103 128.100.103.831672 0  625 0 > 0
> enc0*   00 00 0 > 0
> bridge0 1500152255 0   151339 0 > 0
> pflog0  331360 0   70 0 > 0
> freenas-fw# ifconfig bridge0
> bridge0: flags=4WARNING: SPL NOT LOWERED ON S1
> YSCALL 5index 6 llprio 34 3 EXIT 0
> groups: bridg 9
> e
> priorStopped at  savectx+0xb1:   movl$0,%gs:0x530
> ddb{2}>


Hi,

can you take a look at this link
https://www.openbsd.org/ddb.html

when your box is up and running execute sendbug -P > bridge-problem.txt
and when your box is in ddb type this commands
trace, ps

and send all those to b...@openbsd.org mailing list ...

Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

2019-06-05 Thread Hrvoje Popovski

On 4.6.2019. 21:22, Russell Sutherland wrote:
> I tried loading current on the device and the same result:
> 
> OpenBSD 6.5-current (GENERIC.MP) #5: Mon Jun  3 07:46:49 MDT 2019
> 
> # netstat -in
> NameMtu   Network Address  Ipkts IfailOpkts Ofail 
> Colls
> lo0 327680 00 0 > 0
> lo0 32768 ::1/128 ::1  0 00 0 > 0
> lo0 32768 fe80::%lo0/ fe80::1%lo0  0 00 0 > 0
> lo0 32768 127/8   127.0.0.10 00 0 > 0
> em0 150000:0d:b9:43:9b:3031715 0   120479 7 > 0
> em1 150000:0d:b9:43:9b:31   123252   11630860 0 > 0
> em2 150000:0d:b9:43:9b:32 1672 0  625 0 > 0
> em2 1500  128.100.103 128.100.103.831672 0  625 0 > 0
> enc0*   00 00 0 > 0
> bridge0 1500152255 0   151339 0 > 0
> pflog0  331360 0   70 0 > 0
> freenas-fw# ifconfig bridge0
> bridge0: flags=4WARNING: SPL NOT LOWERED ON S1
> YSCALL 5index 6 llprio 34 3 EXIT 0
> groups: bridg 9
> e
> priorStopped at  savectx+0xb1:   movl$0,%gs:0x530
> ddb{2}>


Hi,

can you take a look at this link
https://www.openbsd.org/ddb.html

when your box is up and running execute sendbug -P > bridge-problem.txt
and when your box is in ddb type this commands
trace, ps

and send all those to b...@openbsd.org mailing list ...

Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

2019-06-04 Thread Russell Sutherland

I tried loading current on the device and the same result:

OpenBSD 6.5-current (GENERIC.MP) #5: Mon Jun  3 07:46:49 MDT 2019

# netstat -in
NameMtu   Network Address  Ipkts IfailOpkts Ofail Colls
lo0 327680 00 0 0
lo0 32768 ::1/128 ::1  0 00 0 0
lo0 32768 fe80::%lo0/ fe80::1%lo0  0 00 0 0
lo0 32768 127/8   127.0.0.10 00 0 0
em0 150000:0d:b9:43:9b:3031715 0   120479 7 0
em1 150000:0d:b9:43:9b:31   123252   11630860 0 0
em2 150000:0d:b9:43:9b:32 1672 0  625 0 0
em2 1500  128.100.103 128.100.103.831672 0  625 0 0
enc0*   00 00 0 0
bridge0 1500152255 0   151339 0 0
pflog0  331360 0   70 0 0
freenas-fw# ifconfig bridge0
bridge0: flags=4WARNING: SPL NOT LOWERED ON S1
YSCALL 5index 6 llprio 34 3 EXIT 0
groups: bridg 9
e
priorStopped at  savectx+0xb1:   movl$0,%gs:0x530
ddb{2}>







Russell P. Sutherland   Email: russell . sutherland @ utoronto dawt ca
Network Engineer, I+TS   Voice: +1.416.978.0470
4 Bancroft Ave., Rm. 102  Cell: +1.416.803.0080
University of Toronto    Fax:   +1.416.978.6620
Toronto, ON  M5S 1C1  



From: owner-m...@openbsd.org  on behalf of Stuart 
Henderson 
Sent: Tuesday, June 4, 2019 13:53
To: misc@openbsd.org
Subject: Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command
 
>There was a crash fixed in bridge(4) a few weeks ago, can you try reproducing
on -current?


On 2019-06-04, Lee Nelson  wrote:
> I have twice seen kernel panics in the same situation. It drops to "ddb>"
> but the system is unresponsive. Unfortunately, other than taking a picture
> of the screen with my cellphone, I do not have any further information from
> the system. On both occasions, I was issuing "ifconfig bridge42" without
> any arguments. (and no, there aren't 41 other bridges. 42 has other
> significance in my network)
>
> On Tue, Jun 4, 2019, 08:41 Russell Sutherland <
> russell.sutherl...@utoronto.ca> wrote:
>
>> I began to install resflash (https://stable.rcesoftware.com/resflash/)
>> which is based on OpenBSD) to build a small firewall on an PC Engines apu2
>> board. Three interfaces, two bridged and one with an IP for management.
>>
>> I found the system would crash and drop down to the debugger interface
>> whenever I issued the:
>>
>> # ifconfig bridge0
>>
>> command.
>>
>> # ifconfig -a
>>
>> worked fine. After discussing this with the author we thought it good to
>> try the same configuration on vanilla 6.5 install.
>>
>> This worked better, but after a short period of operation the same
>> symptoms occured:
>>
>> # ifconfig bridge0
>>
>> bridge0: flags=4WAR1
>>
>> Nindex 6 llprio ING: SPL NOT
>>
>> groups: bridgLOWEe
>>
>> priority 327RED68 hellotime 2 f ONwddelay 15 maxag e 20 holdcnt 6
>> pSYSCALL 5roto rstp
>>
>>     desi4gnated: id 00:0 3 EXIT 0:00:00:00:00 pri 9
>>
>>    ority 0
>>
>> agsStopped at  savectx+0xb1:   movl    $0,%gs:0x508
>>
>> ddb{3}>
>>
>>
>> Here is the output from dmesg:
>>
>>
>> OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 1996148736 (1903MB)
>> avail mem = 1926090752 (1836MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (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.28 MHz, 16-30-01
>> 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,PA

Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

2019-06-04 Thread Stuart Henderson

There was a crash fixed in bridge(4) a few weeks ago, can you try reproducing
on -current?


On 2019-06-04, Lee Nelson  wrote:
> I have twice seen kernel panics in the same situation. It drops to "ddb>"
> but the system is unresponsive. Unfortunately, other than taking a picture
> of the screen with my cellphone, I do not have any further information from
> the system. On both occasions, I was issuing "ifconfig bridge42" without
> any arguments. (and no, there aren't 41 other bridges. 42 has other
> significance in my network)
>
> On Tue, Jun 4, 2019, 08:41 Russell Sutherland <
> russell.sutherl...@utoronto.ca> wrote:
>
>> I began to install resflash (https://stable.rcesoftware.com/resflash/)
>> which is based on OpenBSD) to build a small firewall on an PC Engines apu2
>> board. Three interfaces, two bridged and one with an IP for management.
>>
>> I found the system would crash and drop down to the debugger interface
>> whenever I issued the:
>>
>> # ifconfig bridge0
>>
>> command.
>>
>> # ifconfig -a
>>
>> worked fine. After discussing this with the author we thought it good to
>> try the same configuration on vanilla 6.5 install.
>>
>> This worked better, but after a short period of operation the same
>> symptoms occured:
>>
>> # ifconfig bridge0
>>
>> bridge0: flags=4WAR1
>>
>> Nindex 6 llprio ING: SPL NOT
>>
>> groups: bridgLOWEe
>>
>> priority 327RED68 hellotime 2 f ONwddelay 15 maxag e 20 holdcnt 6
>> pSYSCALL 5roto rstp
>>
>>     desi4gnated: id 00:0 3 EXIT 0:00:00:00:00 pri 9
>>
>>ority 0
>>
>> agsStopped at  savectx+0xb1:   movl$0,%gs:0x508
>>
>> ddb{3}>
>>
>>
>> Here is the output from dmesg:
>>
>>
>> OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 1996148736 (1903MB)
>> avail mem = 1926090752 (1836MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (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.28 MHz, 16-30-01
>> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BM/tmp/qwe.txt
>> (15I1,XSAVEOPT
>> 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: 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, 16-30-01
>> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
>> 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.23 MHz, 16-30-01
>> 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,

Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

2019-06-04 Thread Lee Nelson

I have twice seen kernel panics in the same situation. It drops to "ddb>"
but the system is unresponsive. Unfortunately, other than taking a picture
of the screen with my cellphone, I do not have any further information from
the system. On both occasions, I was issuing "ifconfig bridge42" without
any arguments. (and no, there aren't 41 other bridges. 42 has other
significance in my network)

On Tue, Jun 4, 2019, 08:41 Russell Sutherland <
russell.sutherl...@utoronto.ca> wrote:

> I began to install resflash (https://stable.rcesoftware.com/resflash/)
> which is based on OpenBSD) to build a small firewall on an PC Engines apu2
> board. Three interfaces, two bridged and one with an IP for management.
>
> I found the system would crash and drop down to the debugger interface
> whenever I issued the:
>
> # ifconfig bridge0
>
> command.
>
> # ifconfig -a
>
> worked fine. After discussing this with the author we thought it good to
> try the same configuration on vanilla 6.5 install.
>
> This worked better, but after a short period of operation the same
> symptoms occured:
>
> # ifconfig bridge0
>
> bridge0: flags=4WAR1
>
> Nindex 6 llprio ING: SPL NOT
>
> groups: bridgLOWEe
>
> priority 327RED68 hellotime 2 f ONwddelay 15 maxag e 20 holdcnt 6
> pSYSCALL 5roto rstp
>
> desi4gnated: id 00:0 3 EXIT 0:00:00:00:00 pri 9
>
>    ority 0
>
> agsStopped at  savectx+0xb1:   movl$0,%gs:0x508
>
> ddb{3}>
>
>
> Here is the output from dmesg:
>
>
> OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1996148736 (1903MB)
> avail mem = 1926090752 (1836MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (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.28 MHz, 16-30-01
> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BM/tmp/qwe.txt
> (15I1,XSAVEOPT
> 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: 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, 16-30-01
> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> 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.23 MHz, 16-30-01
> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> 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)
> c

Re: OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

2019-06-04 Thread Tom Smyth

Hi Russell
I had this issue when bridging vio()  interfaces  in kvm / proxmox ...  but
not with em() interfaces
can you try with a uni-processor kernel ...  to see does it crash /  dump
?   mpi@ had asked me to enable witness in the kernel and send the output
of the dumps
(I haven't gotten around to  that yet ) ...





On Tue, 4 Jun 2019 at 16:45, Russell Sutherland <
russell.sutherl...@utoronto.ca> wrote:

> I began to install resflash (https://stable.rcesoftware.com/resflash/)
> which is based on OpenBSD) to build a small firewall on an PC Engines apu2
> board. Three interfaces, two bridged and one with an IP for management.
>
> I found the system would crash and drop down to the debugger interface
> whenever I issued the:
>
> # ifconfig bridge0
>
> command.
>
> # ifconfig -a
>
> worked fine. After discussing this with the author we thought it good to
> try the same configuration on vanilla 6.5 install.
>
> This worked better, but after a short period of operation the same
> symptoms occured:
>
> # ifconfig bridge0
>
> bridge0: flags=4WAR1
>
> Nindex 6 llprio ING: SPL NOT
>
> groups: bridgLOWEe
>
> priority 327RED68 hellotime 2 f ONwddelay 15 maxag e 20 holdcnt 6
> pSYSCALL 5roto rstp
>
> desi4gnated: id 00:0 3 EXIT 0:00:00:00:00 pri 9
>
>ority 0
>
> agsStopped at  savectx+0xb1:   movl$0,%gs:0x508
>
> ddb{3}>
>
>
> Here is the output from dmesg:
>
>
> OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1996148736 (1903MB)
> avail mem = 1926090752 (1836MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (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.28 MHz, 16-30-01
> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BM/tmp/qwe.txt
> (15I1,XSAVEOPT
> 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: 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, 16-30-01
> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> 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.23 MHz, 16-30-01
> 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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> 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.13 MHz, 16-30-01
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX

OpenBSD 6.5 dumps to debugger when using ifconfig bridge command

2019-06-04 Thread Russell Sutherland

I began to install resflash (https://stable.rcesoftware.com/resflash/) which is 
based on OpenBSD) to build a small firewall on an PC Engines apu2 board. Three 
interfaces, two bridged and one with an IP for management.

I found the system would crash and drop down to the debugger interface whenever 
I issued the:

# ifconfig bridge0

command.

# ifconfig -a

worked fine. After discussing this with the author we thought it good to try 
the same configuration on vanilla 6.5 install.

This worked better, but after a short period of operation the same symptoms 
occured:

# ifconfig bridge0

bridge0: flags=4WAR1

        Nindex 6 llprio ING: SPL NOT

        groups: bridgLOWEe

        priority 327RED68 hellotime 2 f ONwddelay 15 maxag e 20 holdcnt 6 
pSYSCALL 5roto rstp

        desi4gnated: id 00:0 3 EXIT 0:00:00:00:00 pri 9

                                                       ority 0

agsStopped at      savectx+0xb1:   movl    $0,%gs:0x508

ddb{3}> 


Here is the output from dmesg:


OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019
    dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1996148736 (1903MB)
avail mem = 1926090752 (1836MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (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.28 MHz, 16-30-01
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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BM/tmp/qwe.txt
 (15I1,XSAVEOPT
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: 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, 16-30-01
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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
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.23 MHz, 16-30-01
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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
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.13 MHz, 16-30-01
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,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
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, remapped
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

Re: Software caused connection abort (53) squid 4.6 on OpenBSD 6.5

2019-05-24 Thread wrh

I have applied that diff to my system and will post once I know the results.

Thank you.

On Thu, May 23, 2019 at 11:41 AM Kasak  wrote:

> Have you seen this https://github.com/squid-cache/squid/pull/404 ?
>
> 23 мая 2019 г., в 18:12, Marcus MERIGHI  написал(а):
>
> Hello,
>
> same here.
>
> I guess bugs@ or ports@ would be better.
>
> w...@wootsie.com (w...@wootsie.com), 2019.05.23 (Thu) 14:36 (CEST):
>
> I have been running into a repeatable error reported by squid 4.6 from
>
> packages once the system has been under a steady load for ~12 hours.
>
>
> I would not call it repeatable because I can't repeat it at will.
> I did not notice the 12 hours interval. But I have by far less users
> behind squid.
>
> Example squid cache.log entry:
>
> 2019/05/22 15:03:41 kid1| oldAccept  FD 18, 0.0.0.0 [ job2]: (53) Software
>
> caused connection abort
>
>
> 2019/05/23 11:51:43 kid1| oldAccept  FD 18, 0.0.0.0 [ job4]: (53)
>  Software caused connection abort
>
> I see this on one machine with windows clients (max. 4) behind it.
> I do not see this on another machine with an OpenBSD client (just 1)
> behind it.
>
> Both are pcengines APUs, but different versions. dmesgs below.
>
> Both setups are up for years, the problem on one of the machines showed
> right after upgrading last week.
>
> Marcus
>
> the machine that does *not* show the symptom:
>
> OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019
>r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> GENERIC.MP
> real mem = 4246003712 (4049MB)
> avail mem = 4107694080 (3917MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
> bios0: vendor coreboot version "4.0" date 09/08/2014
> bios0: PC Engines APU
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
> acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
> PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3)
> UOH3(S3) UOH4(S3) UOH5(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD G-T40E Processor, 1000.14 MHz, 14-02-00
> 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu0: 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 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 200MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD G-T40E Processor, 1000.00 MHz, 14-02-00
> 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu1: 8 4MB entries fully associative
> cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully
> associative
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
> acpiprt0 at acpi0: bus -1 (AGPB)
> acpiprt1 at acpi0: bus -1 (HDMI)
> acpiprt2 at acpi0: bus 1 (PBR4)
> acpiprt3 at acpi0: bus 2 (PBR5)
> acpiprt4 at acpi0: bus 3 (PBR6)
> acpiprt5 at acpi0: bus -1 (PBR7)
> acpiprt6 at acpi0: bus 5 (PE20)
> acpiprt7 at acpi0: bus -1 (PE21)
> acpiprt8 at acpi0: bus -1 (PE22)
> acpiprt9 at acpi0: bus -1 (PE23)
> acpiprt10 at acpi0: bus 0 (PCI0)
> acpiprt11 at acpi0: bus 4 (PIBR)
> acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> cpu0: 1000 MHz: speeds: 1000 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
> ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
> pci1 at ppb0 bus 1
> re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
> (0x2c00), msi, address 00:0d:b9:3f:78:18
> rgephy0 at re0 phy 7: RTL8169S/8110S/821

Re: Software caused connection abort (53) squid 4.6 on OpenBSD 6.5

2019-05-23 Thread Kasak

Have you seen this https://github.com/squid-cache/squid/pull/404 ?

> 23 мая 2019 г., в 18:12, Marcus MERIGHI  написал(а):
> 
> Hello, 
> 
> same here.
> 
> I guess bugs@ or ports@ would be better.
> 
> w...@wootsie.com (w...@wootsie.com), 2019.05.23 (Thu) 14:36 (CEST):
>> I have been running into a repeatable error reported by squid 4.6 from
>> packages once the system has been under a steady load for ~12 hours.
> 
> I would not call it repeatable because I can't repeat it at will.
> I did not notice the 12 hours interval. But I have by far less users
> behind squid.
> 
>> Example squid cache.log entry:
>> 2019/05/22 15:03:41 kid1| oldAccept  FD 18, 0.0.0.0 [ job2]: (53) Software
>> caused connection abort
> 
> 2019/05/23 11:51:43 kid1| oldAccept  FD 18, 0.0.0.0 [ job4]: (53)
>  Software caused connection abort
> 
> I see this on one machine with windows clients (max. 4) behind it. 
> I do not see this on another machine with an OpenBSD client (just 1)
> behind it. 
> 
> Both are pcengines APUs, but different versions. dmesgs below. 
> 
> Both setups are up for years, the problem on one of the machines showed
> right after upgrading last week. 
> 
> Marcus
> 
> the machine that does *not* show the symptom:
> 
> OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019
>
> r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4246003712 (4049MB)
> avail mem = 4107694080 (3917MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
> bios0: vendor coreboot version "4.0" date 09/08/2014
> bios0: PC Engines APU
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
> acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
> PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) 
> UOH4(S3) UOH5(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD G-T40E Processor, 1000.14 MHz, 14-02-00
> 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu0: 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 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 200MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD G-T40E Processor, 1000.00 MHz, 14-02-00
> 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu1: 8 4MB entries fully associative
> cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
> acpiprt0 at acpi0: bus -1 (AGPB)
> acpiprt1 at acpi0: bus -1 (HDMI)
> acpiprt2 at acpi0: bus 1 (PBR4)
> acpiprt3 at acpi0: bus 2 (PBR5)
> acpiprt4 at acpi0: bus 3 (PBR6)
> acpiprt5 at acpi0: bus -1 (PBR7)
> acpiprt6 at acpi0: bus 5 (PE20)
> acpiprt7 at acpi0: bus -1 (PE21)
> acpiprt8 at acpi0: bus -1 (PE22)
> acpiprt9 at acpi0: bus -1 (PE23)
> acpiprt10 at acpi0: bus 0 (PCI0)
> acpiprt11 at acpi0: bus 4 (PIBR)
> acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> cpu0: 1000 MHz: speeds: 1000 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
> ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
> pci1 at ppb0 bus 1
> re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E 
> (0x2c00), msi, address 00:0d:b9:3f:78:18
> rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
> ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
> pci2 at ppb1 bus 2
> re1 at pci2 dev 0 fun

Re: Software caused connection abort (53) squid 4.6 on OpenBSD 6.5

2019-05-23 Thread Marcus MERIGHI

Hello, 

same here.

I guess bugs@ or ports@ would be better.

w...@wootsie.com (w...@wootsie.com), 2019.05.23 (Thu) 14:36 (CEST):
> I have been running into a repeatable error reported by squid 4.6 from
> packages once the system has been under a steady load for ~12 hours.

I would not call it repeatable because I can't repeat it at will.
I did not notice the 12 hours interval. But I have by far less users
behind squid.

> Example squid cache.log entry:
> 2019/05/22 15:03:41 kid1| oldAccept  FD 18, 0.0.0.0 [ job2]: (53) Software
> caused connection abort

2019/05/23 11:51:43 kid1| oldAccept  FD 18, 0.0.0.0 [ job4]: (53)
  Software caused connection abort

I see this on one machine with windows clients (max. 4) behind it. 
I do not see this on another machine with an OpenBSD client (just 1)
behind it. 

Both are pcengines APUs, but different versions. dmesgs below. 

Both setups are up for years, the problem on one of the machines showed
right after upgrading last week. 

Marcus

the machine that does *not* show the symptom:

OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019

r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4246003712 (4049MB)
avail mem = 4107694080 (3917MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) 
UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.14 MHz, 14-02-00
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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 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 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.00 MHz, 14-02-00
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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:3f:78:18
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:3f:78:19
rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), 
msi, address 00:0d:b9:3f:78:1a
rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, AHCI 
1.2
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed

Re: Software caused connection abort (53) squid 4.6 on OpenBSD 6.5

2019-05-23 Thread Jeremy Evans

On Thu, May 23, 2019 at 5:37 AM  wrote:

> I have been running into a repeatable error reported by squid 4.6 from
> packages once the system has been under a steady load for ~12 hours.
>

I have also experienced this, though in my case the issue appeared to be
isolated to a single site (which started working correctly after
restarting).  I'm considering downgrading squid locally to the version that
shipped with 6.4 in order to work around the issue.

Jeremy

Software caused connection abort (53) squid 4.6 on OpenBSD 6.5

2019-05-23 Thread wrh

Hello,

I have been running into a repeatable error reported by squid 4.6 from
packages once the system has been under a steady load for ~12 hours.

Example squid cache.log entry:
2019/05/22 15:03:41 kid1| oldAccept  FD 18, 0.0.0.0 [ job2]: (53) Software
caused connection abort
The file descriptor given is always squid's main listening socket:
18 Socket0   00  0.0.0.0:3128  HTTP Socket

Approx 120 clients using this system as their proxy.

Once this error hits, then web clients fail and squid needs to be restarted
to restore operation.


At first I had an LACP based trunk with the system's two em interfaces,
which I thought might be causing the issue (my first time using trunk).  So
I switched to using the single bge interface but the errors still occur.


Can anyone suggest what I should be looking at to find the cause?

Thank you.


# netstat -in
NameMtu   Network Address  Ipkts IfailOpkts Ofail
Colls
lo0 32768   66 0   66 0
  0
lo0 32768 ::1/128 ::1 66 0   66 0
  0
lo0 32768 fe80::%lo0/ fe80::1%lo0 66 0   66 0
  0
lo0 32768 127/8   127.0.0.1   66 0   66 0
  0
bge01500d4:ae:52:c1:07:f2 32563772 0 34912639 0
  0
bge01500  172.16.1/24 172.16.1.16   32563772 0 34912639 0
  0
em0*150000:1b:21:5e:06:410 00 0
  0
em1*150000:1b:21:5e:06:850 00 0
  0
enc0*   00 00 0
  0
pflog0  331360 00 0
  0

# netstat -m
820 mbufs in use:
408 mbufs allocated to data
396 mbufs allocated to packet headers
16 mbufs allocated to socket names and addresses
398/1328 mbuf 2048 byte clusters in use (current/peak)
0/60 mbuf 2112 byte clusters in use (current/peak)
0/200 mbuf 4096 byte clusters in use (current/peak)
0/144 mbuf 8192 byte clusters in use (current/peak)
0/42 mbuf 9216 byte clusters in use (current/peak)
0/60 mbuf 12288 byte clusters in use (current/peak)
0/48 mbuf 16384 byte clusters in use (current/peak)
0/8 mbuf 65536 byte clusters in use (current/peak)
6452/7796/524288 Kbytes allocated to network (current/peak/max)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019
r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 12865998848 (12269MB)
avail mem = 12466450432 (11888MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (77 entries)
bios0: vendor Dell Inc. version "A16" date 07/06/2012
bios0: Dell Inc. Precision WorkStation T3500
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA DMAR SLIC SSDT
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI4(S5)
PCI5(S5) PCI6(S5) KBD_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3)
USB5(S3)
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) Xeon(R) CPU W3565 @ 3.20GHz, .80 MHz, 06-1a-05
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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
cpu0: 256KB 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 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU W3565 @ 3.20GHz, .28 MHz, 06-1a-05
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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU W3565 @ 3.20GHz, .28 MHz, 06-1a-05
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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU W3565 @ 3.20GHz, .28 MHz, 06-1a-05
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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTP

Re: Samba rlimit on OpenBSD 6.5

2019-05-22 Thread Stuart Henderson

On 2019-05-22, Stephane HUC "PengouinBSD"  wrote:
>
> Hi, all.
>
> How resolve 'rlimit' in Samba on OpenBSD 6.5?
>
> $ testparm
>
> rlimit_max: increasing rlimit_max (512) to minimum Windows limit (16384)
> Load smb config files from /etc/samba/smb.conf
> rlimit_max: increasing rlimit_max (512) to minimum Windows limit (16384)
> (...)
>
> However:
> $ grep kern.maxfiles /etc/sysctl.conf
> kern.maxfiles=16384
> $ tail -n8 /etc/login.conf
> samba:\
>:openfiles=1024:\
>:openfiles-max=16384:\
>:tc=daemon:
> (...)
>
> Machine rebooted after!
>
> One idea?

It could be inheriting openfiles-cur from another class (daemon/default).
I would set openfiles-max and openfiles-cur not openfiles.

Samba rlimit on OpenBSD 6.5

2019-05-22 Thread Stephane HUC "PengouinBSD"

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi, all.

How resolve 'rlimit' in Samba on OpenBSD 6.5?

$ testparm

rlimit_max: increasing rlimit_max (512) to minimum Windows limit (16384)
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (512) to minimum Windows limit (16384)
(...)

However:
$ grep kern.maxfiles /etc/sysctl.conf
kern.maxfiles=16384
$ tail -n8 /etc/login.conf
samba:\
   :openfiles=1024:\
   :openfiles-max=16384:\
   :tc=daemon:
(...)

Machine rebooted after!

One idea?

- -- 
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<
- 
Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net
-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQScTRXz7kMlZfGpDZMTq98t3AMG7wUCXOUEPwAKCRATq98t3AMG
73ajAQDqmDmHZF32h5tJtX09o435f7maaSjj7AAMjZUiYJeZEQD/clne4QIVi6A1
NkTv78Wx04tLjE+U5b/m9x9XLD35Pgg=
=+Zjs
-END PGP SIGNATURE-

PKCS11 on OpenBSD 6.5 ?

2019-05-11 Thread Rachel Roch

Hi,

To save me hours of Googling followed by hours of console bashing I thought 
perhaps someone here who's "been there, done that, got the T-shirt" can point 
me in the right direction.

So far I've got:
• A USB HSM
• OpenSC installed (from package) and working (i.e. no problems using 
pkcs11-tool / pkcs15-tool)

But now I'm struggling with the main event.  Creating an HSM-backed CA, so 
something along these lines 
:https://framkant.org/2018/04/smartcard-hsm-backed-openssl-ca/ 


>From the man pages it seems the bundled libressl has no PKCS11 support built 
>in.

The OpenSC package seems to deliver "/usr/local/lib/pkcs11/opensc-pkcs11.so" 
(i.e. for openssl MODULE_PATH), but there's no sign of "pkcs11.so" (i.e. for 
openssl SO_PATH) anywhere on the system.

If some kind soul could point me in the right direction as to what parts of the 
puzzle I'm missing, that would be much appreciated.

Thanks !

Rachel

new CPAN Smoker release for OpenBSD 6.5

2019-05-04 Thread Alceu Rodrigues de Freitas Junior


Hello folks,

I just release a new version of the custom Perl CPAN smoker on OpenBSD 
6.5 as a Vagrant box:


https://app.vagrantup.com/arfreitas/boxes/openbsd-6.5-cpan-smoker

Regards,

Alceu

Re: OpenBSD 6.5

2019-04-25 Thread Luke A. Call

On 04-24 15:31:34+, Mik J wrote:
> Thank you for this new release and all of those who contributed.

Echoed by many, for past and future work on this excellent
system.  Thanks very much indeed.

OpenBSD 6.5

2019-04-24 Thread Mik J

Thank you for this new release and all of those who contributed.

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-28 Thread Fox Steward

Dear Peter and all,

I could find a fix/hack for the BIOS boot problem as described.

I did not manage to file a bug report for it yet though.

After successfully installing I now have more problems such as

- zzz (suspend) and (hibernate) not working (see bug report [1])
- function keys for screen brightness not working 

@Peter: did these things work for you?

It seems the reason for all this trouble is a broken/outdated BIOS.

I wonder if Clevo - the manufacturer - would be eager to bring some fixes.

And of course, in the long run, we need a "free" BIOS for everyone. ;-)

Sincerely,

Fox


[1] https://marc.info/?t=15535409473=1=2

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-25 Thread finkfox

Hi again.

Just a quick update.

After adding some "bogus" partitions 0 to 2 in front of openbsd paritition 3 
the BIOS no longer hangs with disklabel data. I can now install, boot and run 
OpenBSD from SSD on SATA.


$ doas fdisk sd0

Disk: sd0   geometry: 31130/255/63 [500118192 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
 0: EE  0   0   2 -  0   0  11 [   1:  10 ] EFI GPT 
 1: 05  0   0  12 -  0   0  32 [  11:  21 ] Extended DOS
 2: 83  0   0  23 -  0   0  54 [  22:  32 ] Linux files*
*3: A6  0   1   2 -  31129 254  63 [  64:   500103386 ] OpenBSD



I tried this with the intuition that this might stop the BIOS from "seeing" the 
disklabel data. And fortunately it worked. To really understand what is going 
on I guess one would need access to the BIOS source code, or? 

Should this issue be reported as an "official" bug?

At least other Clevo W840SU laptop users could benefit from this knowledge.

Best regards,

Fox

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-23 Thread finkfox

Hello again.

Thank you Peter for your feedback and describing the steps that 
seem to have solved your problems so long time ago.

To be hontest, at this point in time I feel a bit reluctant to test
with two disks attached mSATA and SATA, I would rather focus
just on one disk attached via SATA.

For that purpose I have now executed a bit more debugging work.

>From this work I conclude: the BIOS hang up is introduced by the writing
of disklabel data. The disklabel data that remains, after all disklabel
partitions where removed (in disklabel editor command z).

Further below you can find a detailed log with hex dumps which which gives
reason for this claim.

Questions:

Does anyone have an idea what could be the problem with this disklabel data?

Why does the BIOS even care about this data and at this point of time in the 
first place?
Especially since I did not complete a OpenBSD install, there is no Partition 
Boot Record / stage 1
bootloader in place yet the BIOS could trigger.

Any help for this issue is greatly welcome.

Thank you very much.

Fox


== LOG START ==

Given:

1. SSD connected via SATA port (no mSATA connected) on Clevo W840SU laptop

Steps:

0. Connect SSD disk to other openbsd system/laptop 

With OpenBSD -current via USB adapter here it appears as sd2 device.

1. Remove any data from first 2M of disk: 

$ doas dd if=/dev/zero of=/dev/sd2rc bs=2M count=1 

2. Initialize MBR: 

$ doas fdisk -iy sd2

3. Check: attach disk to Clevo laptop at SATA port 

=> Bios does not(!) hang upon boot, Bios boot works!

4. Re-attach disk to other laptop via usb adapter

5. Write disklabel: 

$ doas disklabel -E sd2 

In the editor menu: A; q

6. Extract disklabel data

Which is written to the first 512 Bytes after the partion boot record (PBR).
The PBR is written in the first 512 Byte of the OpenBSD partition,
With the default fdisk MBR layout the PBR is written to sector 64.

$ doas dd if=/dev/rsd2c of=/home/user/debug skip=65 bs=512 count=1
$ hexdump -C /home/user/debug

 57 45 56 82 04 00 00 00 53 43 53 49 20 64 69 73 |WEV.SCSI dis|
0010 6b 00 00 00 00 00 00 00 53 53 44 20 38 34 30 20 |k...SSD 840 |
0020 50 52 4f 20 53 65 72 69 00 02 00 00 3f 00 00 00 |PRO Seri?...|
0030 ff 00 00 00 9a 79 00 00 c1 3e 00 00 b0 32 cf 1d |.y...>...2..|
0040 76 bc fc 2c 21 23 84 61 00 00 00 00 00 00 00 00 |v..,!#.a|
0050 40 00 00 00 1a f9 ce 1d 00 00 00 00 00 00 00 00 |@...|
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0070 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0080 00 00 00 00 57 45 56 82 ce a5 10 00 00 20 00 00 |WEV.. ..|
0090 00 00 01 00 00 00 20 00 40 00 00 00 00 00 00 00 |.. .@...|
00a0 07 14 01 00 30 59 ff 00 40 00 20 00 00 00 00 00 |0Y..@. .|
00b0 01 00 00 00 b0 32 cf 1d 00 00 00 00 00 00 00 00 |.2..|
00c0 00 00 00 00 e0 ff 7f 00 80 59 1f 01 00 00 00 00 |.Y..|
00d0 07 14 01 00 60 b2 6e 02 60 59 9f 01 00 00 00 00 |`.n.`Y..|
00e0 07 14 01 00 00 00 40 00 c0 0b 0e 04 00 00 00 00 |..@.|
00f0 07 14 01 00 00 00 20 00 c0 0b 4e 04 00 00 00 00 |.. ...N.|
0100 07 14 01 00 00 00 80 02 c0 0b 6e 04 00 00 00 00 |..n.|
0110 07 14 01 00 00 00 40 00 c0 0b ee 06 00 00 00 00 |..@.|
0120 07 14 01 00 00 00 c0 00 c0 0b 2e 07 00 00 00 00 ||
0130 07 14 01 00 40 ed e0 15 c0 0b ee 07 00 00 00 00 |@...|
0140 07 1c 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||

7. Check: attach disk to Clevo laptop at SATA port

=> Bios hangs at boot.

8. Re-attach disk to other laptop via usb adapter

9. Remove disklabel partitions: 

$ doas disklabel -E sd2

In the editor menu: z

10. Extract disklabel data (compare step 6)

$ doas dd if=/dev/rsd2c of=/home/user/debug2 skip=65 bs=512 count=1
$ hexdump -C /home/user/debug2

 57 45 56 82 04 00 00 00 53 43 53 49 20 64 69 73 |WEV.SCSI dis|
0010 6b 00 00 00 00 00 00 00 53 53 44 20 38 34 30 20 |k...SSD 840 |
0020 50 52 4f 20 53 65 72 69 00 02 00 00 3f 00 00 00 |PRO Seri?...|
0030 ff 00 00 00 9a 79 00 00 c1 3e 00 00 b0 32 cf 1d |.y...>...2..|
0040 76 bc fc 2c 21 23 84 61 00 00 00 00 00 00 00 00 |v..,!#.a|
0050 40 00 00 00 1a f9 ce 1d 00 00 00 00 00 00 00 00 |@...|
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0070 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0080 00 00 00 00 57 45 56 82 36 4b 10 00 00 20 00 00 |WEV.6K... ..|
0090 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
00a0 00 14 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
00b0 00 00 00 00 b0 32 cf 1d 00 00 00 00 00 00 00 00 |.2..|
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-22 Thread Peter Nicolai Mathias Hansteen



> 22. mar. 2019 kl. 07:16 skrev Peter Nicolai Mathias Hansteen 
> :
>> Dear Peter, can you remember more details how you got OpenBSD to work on that
>> Clevo W840-SU by any chance? Did you use SSD or HDD for the booting disk?
> 
> I considered it fairly obvious that I wanted the fastest one (the SSD) for 
> the system disk. I did not make any special preparations for that one (which 
> means the MBR would be intact), but it is entirely possible that I went for 
> the old-style (non-UEFI) option. The MBR removal was on the slightly roomier 
> HDD which I intended to use for /home.
> 

I should perhaps add to that, I was a little quick in typing up the previous 
answer.

If I remember correctly, I chose the old-style (not «secure boot») BIOS 
options, did a fairly regular install at first, but ran into something very 
much like the symptoms you describe. My conclusion then was that for whatever 
reason the system was trying to boot from the HDD (which then had an MBR but 
nothing else required for a boot disk), not the SSD.

After quite a bit of mucking about with options I never documented properly, as 
I remember it what gave me a functional system with the SSD as the system disk 
and I think something very close to the OpenBSD installer’s default 
partitioning plus the roomier HDD (later replaced with a same-size SSD but 
that@s another story) involved removing the MBR on the HDD. Then again, this 
was several years ago so and I did not make any notes that have survived while 
I was doing this. As you have seen already, you will need an MBR on the disk 
you intend to boot from.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-22 Thread Peter Nicolai Mathias Hansteen


> 21. mar. 2019 kl. 22:55 skrev fink...@dismail.de:
> 
> Dear Peter and all.
> 
> Unfortunately I celebrated to early it seems. :-/
> 
> In my last post I described a hack in which I let the OpenBSD partition
> start at "sector 0" in order to avoid BIOS hangup.
> 
> When I now tried this way of setup with a SSD disk instead of HDD,
> after a succesful install, OpenBSD boots with the following Kernel panic:
> 
> "openbsd panic root filesystem has size 0"
> 
> For this I found the following post talking about "partition offset" [1].
> 
> It explains:
> 
> "Sector 0 can't be used for a partition, because it's occupied by the MBR 
> partition table"
> 
> So I believe the "Sector 0" hack is actually breaking things (as the fdisk 
> output
> of the result parition table also suggests).
> 
> Dear Peter, can you remember more details how you got OpenBSD to work on that
> Clevo W840-SU by any chance? Did you use SSD or HDD for the booting disk?

I considered it fairly obvious that I wanted the fastest one (the SSD) for the 
system disk. I did not make any special preparations for that one (which means 
the MBR would be intact), but it is entirely possible that I went for the 
old-style (non-UEFI) option. The MBR removal was on the slightly roomier HDD 
which I intended to use for /home.

- Peter
—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-21 Thread finkfox

Dear Peter and all.

Unfortunately I celebrated to early it seems. :-/

In my last post I described a hack in which I let the OpenBSD partition
start at "sector 0" in order to avoid BIOS hangup.

When I now tried this way of setup with a SSD disk instead of HDD,
after a succesful install, OpenBSD boots with the following Kernel panic:

"openbsd panic root filesystem has size 0"

For this I found the following post talking about "partition offset" [1].

It explains:

"Sector 0 can't be used for a partition, because it's occupied by the MBR 
partition table"

So I believe the "Sector 0" hack is actually breaking things (as the fdisk 
output 
of the result parition table also suggests).

Dear Peter, can you remember more details how you got OpenBSD to work on that
Clevo W840-SU by any chance? Did you use SSD or HDD for the booting disk?

> March 20, 2019 8:46 AM, "Peter N. M. Hansteen"  wrote:

> "I *think* what I did back then was set the all parts to size zero, except 
> the OpenBSD part which I set to the largest > the program would let me."

What were the other parts (partitions)?

Any further ideas and hints what I could try?

Thank you very much.

Fox

---
[1] https://unix.stackexchange.com/questions/148589/partition-offset-at-63-or-64

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-20 Thread finkfox

Dear Peter and all,

> I believe both should be doable using openbsd's fdisk (available I think from 
> the bsd.rd
> installer image), try escaping to the shell from the installer, possibly 
> fdisk -e and
> keep the man page handy. I *think* what I did back then was set the all parts 
> to size
> zero, except the OpenBSD part which I set to the largest the program would 
> let me.

Thank you. With this hint of yours I managed to finally find a solution.

1. I noticed that after doing with OpenBSD "fdisk -e sdx; reinit mbr", booting 
disk form SATA (no mSata 
connected) would result in a BIOS hangup. 

Here is the fdisk output of that state:

Disk: sd2   geometry: 121601/255/63 [1953525168 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
 0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
*3: A6  0   1   2 - 121600 254  63 [  64:  1953520001 ] OpenBSD

2. I then went back to the fdisk editor and changed the C/H/S size of the 
partition 3 Openbsd to the maximum values.

Disk: sd2   geometry: 121601/255/63 [1953525168 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
 0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
*3: A6  0   0   1 - 121600 254  63 [   0:  1953520065 ] OpenBSD  

3. As a result, with this disk attached vis SATA, the BIOS would no longer hang

4. I then installed OpenBSD, choosding "OpenBSD" in the partitioning step

After this step the fdisk layout looks like this:

Disk: sd2   geometry: 121601/255/63 [1953525168 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:   


 #: id  C   H   S -  C   H   S [   start:size ]
---
 0: E8  15356  77   8 - 229721 118   4 [   246698998:  3443776305 ] 
 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused  
 3: 00  0   0   0 -  0   0   0 [   0:   0 ] unused 

Isn't that a bit weird? The type ID is E8, Unknown?

5. On reboot, OpenBSD system boots and works fine. 

Now I don't really understand why this "hack" works.

Maybe someone has a valid explanation?

Lastly, this is just a first quick response, I haven't really tested the 
resulting
system, only logged in.

Thank you very much.

Fox

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-20 Thread Peter N. M. Hansteen

On Wed, Mar 20, 2019 at 08:17:51AM +, fink...@dismail.de wrote:
> In your blog post [1] you describe installing OpenBSD on your then (2017) new 
> silver colored laptop, a (Multicom) Clevo U831 with dmesg [2].
> 
> In the post you also mention your previous (2014) black colored laptop, a 
> Clevo W840SU with dmesg [3].
> This is the model I'm having trouble with.

Ah, I got that backwards, sorry. I claim a slight caffeine deficiency (soon to 
be corrected)

> Sepcifically you write:
> 
> "The main hurdle back when I was installing the 2014-vintage 14" model was 
> getting the system to consider the SSD which showed up as sd1 the automatic 
> choice for booting (I solved that by removing the MBR, setting the size of 
> the MBR on the hard drive that showed up as sd0 to 0 and enlarging the 
> OpenBSD part to fill the entire drive)."
> 
> It would be great to learn more details on these steps, that is
> 
> - how do I remove an MBR
> - how do I set the size of an MBR to 0
> 
> I believe these MBR tweaks might solve my hanging BIOS issue.

I believe both should be doable using openbsd's fdisk (available I think from 
the bsd.rd
installer image), try escaping to the shell from the installer, possibly fdisk 
-e and
keep the man page handy. I *think* what I did back then was set the all parts 
to size
zero, except the OpenBSD part which I set to the largest the program would let 
me.

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-20 Thread finkfox

Dear Peter,

thank you for your reply.

> Odd. I vaguely remember having to set the BIOS to look at the SSD (which 
> OpenBSD sees as sd1) but
> IIRC I only booted the machine from a USB drive once, for the initial install.
> 
> The only obvious points I see are that you’re pointing to the wrong dmesg 
> (the correct one is at
> https://home.nuug.no/~peter/20170927_dmesg_greyhame.txt) 

I'm sorry, I think I should have been more clear to avoid confusion.

Please correct me if I'm wrong:

In your blog post [1] you describe installing OpenBSD on your then (2017) new 
silver colored laptop, a (Multicom) Clevo U831 with dmesg [2].

In the post you also mention your previous (2014) black colored laptop, a Clevo 
W840SU with dmesg [3].
This is the model I'm having trouble with.

Sepcifically you write:

"The main hurdle back when I was installing the 2014-vintage 14" model was 
getting the system to consider the SSD which showed up as sd1 the automatic 
choice for booting (I solved that by removing the MBR, setting the size of the 
MBR on the hard drive that showed up as sd0 to 0 and enlarging the OpenBSD part 
to fill the entire drive)."

It would be great to learn more details on these steps, that is

- how do I remove an MBR
- how do I set the size of an MBR to 0

I believe these MBR tweaks might solve my hanging BIOS issue.

> I need to be off to work now, but I could perhaps compare more notes sometime 
> in the afternoon if
> needed.

That would great! Thank you very much!

Fox


[1] https://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html
[2] https://home.nuug.no/~peter/20170927_dmesg_greyhame.txt
[3] https://home.nuug.no/~peter/dmesg.elke.20170709.txt

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-20 Thread Peter Nicolai Mathias Hansteen


> 19. mar. 2019 kl. 20:59 skrev fink...@dismail.de:
> 
> I'm trying to run OpenBSD on a Clevo W840SU laptop. After a successful install
> and starting the machine the BIOS hangs. That is, when the booting drive is
> connected via SATA/mSATA. When connected via USB, it works just fine.

Odd. I vaguely remember having to set the BIOS to look at the SSD (which 
OpenBSD sees as sd1) but IIRC I only booted the machine from a USB drive once, 
for the initial install.

The only obvious points I see are that you’re pointing to the wrong dmesg (the 
correct one is at https://home.nuug.no/~peter/20170927_dmesg_greyhame.txt 
) and that I 
distinctly remember telling the installer to use the "W)hole disk» option on 
the SSD, with the UEFI options enabled — basically not changing anything from 
the default settings.

Off the top of my head I’d check that you’re actually telling the machine to 
boot off the drive that has the operating system installed. If you choose the 
wrong one, you would get behavior that matches (at least superficially) what 
you describe.

I need to be off to work now, but I could perhaps compare more notes sometime 
in the afternoon if needed.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-19 Thread finkfox

> Is your BIOS set to RAID for the HDD? If so try setting it to AHCI in the 
> BIOS.

Nope, it is set to AHCI as the documentation attached to my original post 
describes.

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-19 Thread tfrohw...@fastmail.com

On March 19, 2019 7:59:49 PM UTC, fink...@dismail.de wrote:
>Dear Community.
> 
>   
>I'm trying to run OpenBSD on a Clevo W840SU laptop. After a successful
>install 
>and starting the machine the BIOS hangs. That is, when the booting
>drive is 
>connected via SATA/mSATA. When connected via USB, it works just fine.
>
>The identical laptop model is mentioned as a working one 
>in Peter Hansteen's blog (including a dmesg log) [1].  
>   
>
>A detailed documentation of the issue is given in the plain text
>document 
>attached. 
>   
>So is this a broken BIOS issue?
>What else could I try to get this to work?
>How to debug this issue further?   
>
>   
>I've been using GNU/Linux before and have had not problem with a
>hanging BIOS
>whatsoever. In fact it's still working without a problem on this
>machine.   
>  
>   
>Thank you very much for your attention and help.   
>   
>   
>Fox
>
>--
>[1] https://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html

Is your BIOS set to RAID for the HDD? If so try setting it to AHCI in the BIOS.

OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

2019-03-19 Thread finkfox

Dear Community. 
 

   
I'm trying to run OpenBSD on a Clevo W840SU laptop. After a successful install  
   
and starting the machine the BIOS hangs. That is, when the booting drive is 

connected via SATA/mSATA. When connected via USB, it works just fine.

The identical laptop model is mentioned as a working one 
in Peter Hansteen's blog (including a dmesg log) [1].   



A detailed documentation of the issue is given in the plain text document   
  
attached. 

 
So is this a broken BIOS issue?
What else could I try to get this to work?
How to debug this issue further?


   
I've been using GNU/Linux before and have had not problem with a hanging BIOS   
 
whatsoever. In fact it's still working without a problem on this machine.   

   




 
Thank you very much for your attention and help.
   

   
Fox

--
[1] https://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html
OpenBSD 6.5 on Clevo W840SU: BIOS hangs when disk attached via SATA
===

== Error Description

=== With BIOS UEFI disabled 

That is, BIOS Settings _Boot -> UEFI Setting -> UEFI Boot_ disabled.

* Successfully installed install65.fs from USB to SATA/mSATA connected disk
* With
** Fdisk MBR whole
** Disklabling auto

 Result

1. Upon restart system hangs showing only the American Megatrends logo and 
version.
2. CPU fan starts to turn up.
3. BIOS settings cannot be reached. (press/hold ESC key upon boot)

NOTE: Attaching the same disk via USB, BIOS boot does not hang, system can be 
successfully booted.  

=== With BIOS UEFI enabled

That is, BIOS Settings _Boot -> UEFI Setting -> UEFI Boot_ enabled.

* Successfully installed install65.fs from USB to SATA connected disk
* With
** Fdisk GPT whole
** Disklabling auto

 Result

1. Upon system start screen remains blank (not black) and goes in a restart 
loop.  
2. CPU fan starts to turn up.
3. BIOS settings cannot be reached. (press/hold ESC key upon boot)
 
NOTE: Attaching the same disk via USB, BIOS boot does not hang, system can be 
successfully booted.

== Machine Description

* Clevo W840SU
* American Megatrends Version 2.15.1236 2012
* ME FW Version 9.5.13.1706
* BIOS Version 1.03.02
* KBC/EC Firmware Revision 1.03.02

=== BIOS Settings

 Advanced

* Intel(R) Smart Connect Technology : disabled
* Intel(R) Rapid Start Technology : disabled
* SATA Mode : AHCI Mode
* Boot Logo: Disabled
* Power On Boot Beep: Enabled
* Battery Low Alarm Beep: Disabled

 Security

* TPM Configuration : disabled


== Things tried but did not work

=== Clear partition table

* Erase first 2M of disk before install 


dd if=/dev/zero of=/dev/sdx bs=2M count=1


=== Initialized EFI boot files with MBR

See https://marc.info/?m=15190459022533

Step 1 : Initialize MBR


newfs -t msdos sdNi
mount /dev/sdNi /mnt
mkdir -p /mnt/efi/boot
cp /usr/mdec/BOOT*.EFI /efi/boot/
umount /mnt
sync


Step 2 : install openbsd -> choose "OpenBSD" configure disk fdisk step (which 
supposedly does not alter the MBR)

Step 3 : reboot with and without UEFI enabled.

 Result

* MBR after successfull install

$ doas fdisk -v sd2

Primary GPT:
Not Found

Secondary GPT:
Not Found

MBR:
Disk: sd2   geometry: 121601/255/63 [1953525168 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending

66 matches

Mail list logo