APU2 fails to boot on OpenBSD 6.6-current #521

[Mischa]

Hi All,

FYI
Just upgraded my APU2 to the latest -current and it seems to hang on the disk.
It was fine running on -current #512.

Mischa

###

SeaBIOS (version rel-1.12.1.3-0-g300e8b7)

Press F10 key now for boot menu

Booting from Hard Disk...
Using drive 0, partition 3.
Loading..
probing: pc0 com0 com1 com2 com3 mem[639K 3581M 496M a20=on] 
disk: hd0+
>> OpenBSD/amd64 BOOT 3.46
switching console to com>> OpenBSD/amd64 BOOT 3.46
boot> 0

booting hd0a:/bsd: 12817736+2741256+335904+0+708608 
[794080+128+1015800+742813]=0x12477f8
entry point at 0x81001000
[ using 2553848 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.6-current (GENERIC.MP) #521: Wed Dec 11 21:30:47 MST 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259885056 (4062MB)
avail mem = 4118376448 (3927MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xdfe8c020 (13 entries)
bios0: vendor coreboot version "v4.11.0.1" date 12/09/2019
bios0: PC Engines apu2
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST IVRS SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) 
UOH1(S3) UOH2(
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-64
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.26 MHz, 16-30-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,F
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cac
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,F
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cac
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,F
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cac
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.38 MHz, 16-30-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,F
cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cac
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 -1 (PCI0)
acpiprt1 at acpi0: bus -1 (PBR4)
acpiprt2 at acpi0: bus -1 (PBR5)
acpiprt3 at acpi0: bus -1 (PBR6)
acpiprt4 at acpi0: bus -1 (PBR7)
acpiprt5 at acpi0: bus -1 (PBR8)
acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpibtn0 at acpi0: PWRB
acpicmos0 at acpi0
"AMD0030" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
"BOOT" at acpi0 not configured
cpu0: 998 MHz: speeds: 1000 800 600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Root Complex" rev 0x00
vendor "AMD", unknown product 0x1567 (class system subclass IOMMU, rev 0x00) at 
pci0 dev 0
pchb1 at pci0 dev 2 function 0 "AMD AMD64 16h Host" rev 0x00
ppb0 at pci0 dev 2 function 1 "AMD AMD64 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x73, msi
ppb1 at pci0 dev 2 function 2 "AMD AMD64 16h PCIE" rev 0x00: msi
pci2 

Re: unbound network optimizations

[Winter Paulson]

Hello,

I'm also experiencing the "Host is down" problem:

unbound: [85343:0] error: recvfrom 361 failed: Host is down

Running openbsd 6.6 (GENERIC.MP), current syspatch,
native unbound as a full resolver, pf disabled.

OpenBSD is a guest VM on a debian buster host using virtual e1000
network card ("Intel 82540EM" driver in openbsd). No firewall
in between. The VM is a tor-exit node.

$ netstat -s -p udp
udp:
9379065 datagrams received
0 with incomplete header
0 with bad data length field
16 with bad checksum
32675 with no checksum
9346390 input packets software-checksummed
6059478 output packets software-checksummed
201392 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to missing IPsec protection
0 dropped due to full socket buffers
9177657 delivered
18686884 datagrams output
9378087 missed PCB cache


/etc/sysctl.conf

kern.maxfiles=3
net.inet.udp.sendspace=262144
net.inet.udp.recvspace=262144
kern.somaxconn=2500
kern.maxproc=3000
kern.bufcachepercent=50
net.inet.tcp.rfc3390=1

/etc/login.conf

unbound:\
:openfiles=13500:\
:tc=daemon:

/var/unbound/etc/unbound.conf

num-threads: 2
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
rrset-cache-size: 100m
msg-cache-size: 50m
outgoing-range: 450
outgoing-num-tcp: 25
incoming-num-tcp: 25
msg-buffer-size: 65552


Each unbound thread is doing around 1.2 million queries a day.

I'd also be interested in knowing if increasing udp.sendspace and
udp.recvspace has negative implications or what else might be done.

Thank you!

w.

Re: unbound network optimizations

[Jordan Geoghegan]

On 2019-12-12 06:21, Winter Paulson wrote:

Hello,

I'm also experiencing the "Host is down" problem:

unbound: [85343:0] error: recvfrom 361 failed: Host is down

Running openbsd 6.6 (GENERIC.MP), current syspatch,
native unbound as a full resolver, pf disabled.

OpenBSD is a guest VM on a debian buster host using virtual e1000
network card ("Intel 82540EM" driver in openbsd). No firewall
in between. The VM is a tor-exit node.


I've heard others recommend using the vio driver over the em driver 
numerous times on here if running a virtualized instance. You may have a 
better time than you are now by using the VirtIO drivers. The intel nic 
emulation can sometimes have issues. Better to use an interface designed 
for virtualized environments.



Cheers,

Jordan

ipv6 via he.net connectivity issues - possible regression?

[Pedro Caetano]

Hi misc,

I'm running amd64 -current, snapshot #518.

My router has 4 em(4) interfaces.
em0 provides ipv4 internet via vlan100 which is connected to ISP ont.
em1, em2, em3 are bonded using aggr(4) to a lacp capable switch.

A /48 subnet is routed via gif(4) tunnel to he.net, then subnetted into
/64s.

Three vlans exist on top of the aggr(4) device.
Ipv4 addresses are assigned by dhcpd(8), ipv6 addresses are assigned by
rad(8).

Hosts can acquire ip via rad(8), but are unable to access the internet
unless the gateway is pinged.
Hosts are also unreachable from the internet.

Unfortunately I cannot tell precisely when this behavior started, but I
guess this was not an issue on 6.5.

Please let me know if any more information is needed.

Best regards,
Pedro Caetano