I hope fixing these ports is easy and fast.
LOOK, let me be clear.
At the very last minute, the sysctl can be changed to return success
But if you guys aren't even going to try to cope with change, that's
coming off a little lame.
There are bad side effects from the past behaviour as well.
Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> On Thu, Sep 27 2018, Stuart Henderson <s...@spacehopper.org> wrote:
> > On 2018/09/26 20:15, Stuart Henderson wrote:
> >> On 2018/09/26 19:16, Stuart Henderson wrote:
> >> > N.B. "Ports using KERN_CPTIME2 will need to be updated."
> >> >
> >> > This is likely to cause a bunch of breakage in things reporting CPU stats
> >> > and time is very short to fix them before release.
> >> >
> >> > If you look after ports that do this, get onto a kernel with this change
> >> > (very new commit so it probably won't be in snaps quite just yet) and
> >> > test ASAP.
> >>
> >> Some starting points for investigation,
> >>
> >> assorted mozillas
> >> collectd
> >> conky
> >> go
> >> htop
> >> libgtop2
> >> net-snmp
> >> node
> >> pgtop
> >> py-psutil
> >> libuv (+ embedded copies, at least in cmake, maybe more)
> >> zabbix
> >
> > From a search over extracted ports source and cleaned up (ignoring ifdefs
> > etc):
>
> The tests I did so far, thinkpad x230 with HT enabled and hw.smt=0:
>
> > libgtop2-2.38.0 sysdeps/openbsd/cpu.c:static int mib_cptime_s
> > [] = { CTL_KERN, KERN_CPTIME2, 0 };
>
> glibtop_get_cpu() from libgtop2 is broken, I get an abort due to
> a double-free error when using the short program below.
>
> --8<--
> // cc -g $(pkg-config --cflags libgtop-2.0) gtop2.c $(pkg-config --libs
> libgtop-2.0) -L/usr/X11R6/lib
>
> #include <glibtop/cpu.h>
>
> int
> main(void)
> {
> glibtop_cpu gcpu;
>
> glibtop_get_cpu(&gcpu);
> return 0;
> }
> -->8--
>
> 100% failures with malloc.conf -> S, 5% without malloc.conf.
>
> > libuv & vendored copies
> >
> > libuv-1.19.1 src/unix/openbsd.c: which[1] = KERN_CPTIME2;
> > cmake-3.10.2 Utilities/cmlibuv/src/unix/openbsd.c: which[1]
> > = KERN_CPTIME2;
> > moarvm-2017.10 3rdparty/libuv/src/unix/openbsd.c: which[1] =
> > KERN_CPTIME2;
> > node-8.12.0 deps/uv/src/unix/openbsd.c: which[1] = KERN_CPTIME2;
> > passenger-5.1.11
> > src/cxx_supportlib/vendor-copy/libuv/src/unix/openbsd.c: which[1] =
> > KERN_CPTIME2;
> > py-uv-1.3.0 deps/libuv/src/unix/openbsd.c: which[1] = KERN_CPTIME2;
>
> Looking at the code, uv_cpu_info() will now fail (but at least it
> shouldn't crash). dunno how many ports actually use it.
>
> > psutil & vendored copies
> >
> > py-psutil-5.4.3 psutil/arch/openbsd/specific.c: mib[1] =
> > KERN_CPTIME2;
> > firefox-esr-60.2.1
> > third_party/python/psutil/psutil/arch/openbsd/specific.c: mib[1] =
> > KERN_CPTIME2;
> > firefox-62.0.2
> > third_party/python/psutil/psutil/arch/openbsd/specific.c: mib[1] =
> > KERN_CPTIME2;
>
> py-psutil is completely broken, ''import psutil'' fails:
>
> --8<--
> >>> import psutil
> python2: failed to get kern.cptime2: Operation not supported by device
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/site-packages/psutil/__init__.py", line
> 1617, in <module>
> _last_per_cpu_times = cpu_times(percpu=True)
> File "/usr/local/lib/python2.7/site-packages/psutil/__init__.py", line
> 1606, in cpu_times
> return _psplatform.per_cpu_times()
> File "/usr/local/lib/python2.7/site-packages/psutil/_psbsd.py", line 218,
> in per_cpu_times
> for cpu_t in cext.per_cpu_times():
> -->8--
>
> Both the libgtop2 and the py-psutil problems are fixed with hw.smt=1.
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
