After trying lots of different combinations in ESXi (VM templates, Cores
per Socket) w/o luck, i've even disabled SMT in BIOS. Although ESXi says
"SMT disabled" now, OpenBSD still shows the following:
$ dmesg | grep smt
cpu0: smt 0, core 0, package 0
cpu1: smt 1, core 0, package 0
cpu2: smt 2, core 0, package 0
cpu3: smt 3, core 0, package 0
cpu4: smt 4, core 0, package 0
cpu5: smt 5, core 0, package 0
instead of "core 0, core 1, core 2, ..."
Aside from that i see lots of *.core files lying around directly after
setting hw.smt=1 (sshd.core, ksh.core, sh.core, tmux.core), but after
additional 10-20sec the system becomes more stable.
On 9/24/19 6:36 PM, Mark Patruck wrote:
As written earlier, when booting bsd.mp leaving smt off, everything's
fine - the system boots till the end.
The interesting thing is, it seems like turning hw.smt=1 instantly kills
the current shell and because of that, turning hw.smt=1 via sysctl.conf
stops the whole /etc/rc stuff after sysctl has been called.
For example:
The system is up and running with hw.smt=0
$ su
Password:
# sysctl hw.ncpuonline
hw.ncpuonline=1
# sysctl hw.smt=1
Segmentation fault
-----ssh connection gets dropped-- -> reconnect-----
$ sysctl hw.ncpuonline
hw.ncpuonline=6
$ ls /home
ksh.core
Besides that, i'm also wondering why dmesg says, the L3 cache is
disabled...
----
cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 128MB 64b/line disabled L3 cache
----
On 9/24/19 12:56 PM, Mark Patruck wrote:
Hi,
while doing some tests on an AMD Epyc VM on ESXi 6.7 with a fresh
OpenBSD 6.6-beta (2019-09-23), the system crashes as soon as SMT is
involved (either by manually setting # sysctl hw.smt=1 after boot, or
via /etc/sysctl.conf) and you've assigned more than 2 cpus (hw.ncpu > 2)
dmesg, panic, trace, ps attached.
Thanks,
-Mark
--
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51
https://www.wrapped.cx
