Re: ports and printf("%n") (was: Re: CVS: cvs.openbsd.org: src)
Jeremie Courreges-Anglas wrote: > (cc'ing ports bulk builds herders) > > Hi folks, > > On Mon, Aug 30 2021, Theo de Raadt wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: dera...@cvs.openbsd.org 2021/08/30 05:16:49 > > > > Modified files: > > lib/libc/stdio : vfprintf.c vfwprintf.c > > > > Log message: > > jca and I converted %n to a syslog warning about a year ago, and the ports > > ecosystem experienced a very good cleanup. Time has arrived to switch (as > > planned) to syslog + abort, which will result in a coredump thus identifying > > the remaining culprits in a more visible fashion. > > vfprintf(3) and vfwprintf(3) man pages still require documentation changes. > > with jca > > Ports may suffer from this at build time *and* runtime. Regarding > issues at build time we can ease the debugging with the diff below. > This is not intended for commit, also I intend to drop the _THIS_PORT > getenv from libc before next release. I've been arguing that corefiles will be produced, and the directory the corefile lands in is a pretty strong hint. But .. not my decision.
ports and printf("%n") (was: Re: CVS: cvs.openbsd.org: src)
(cc'ing ports bulk builds herders) Hi folks, On Mon, Aug 30 2021, Theo de Raadt wrote: > CVSROOT: /cvs > Module name: src > Changes by: dera...@cvs.openbsd.org 2021/08/30 05:16:49 > > Modified files: > lib/libc/stdio : vfprintf.c vfwprintf.c > > Log message: > jca and I converted %n to a syslog warning about a year ago, and the ports > ecosystem experienced a very good cleanup. Time has arrived to switch (as > planned) to syslog + abort, which will result in a coredump thus identifying > the remaining culprits in a more visible fashion. > vfprintf(3) and vfwprintf(3) man pages still require documentation changes. > with jca Ports may suffer from this at build time *and* runtime. Regarding issues at build time we can ease the debugging with the diff below. This is not intended for commit, also I intend to drop the _THIS_PORT getenv from libc before next release. Index: bsd.port.mk === RCS file: /d/cvs/ports/infrastructure/mk/bsd.port.mk,v retrieving revision 1.1555 diff -u -p -p -u -r1.1555 bsd.port.mk --- bsd.port.mk 3 May 2021 17:53:15 - 1.1555 +++ bsd.port.mk 9 May 2021 18:50:35 - @@ -793,6 +793,9 @@ CONFIGURE_ENV += ${_EXTRA_ENV} MAKE_ENV += ${_EXTRA_ENV} .endif +CONFIGURE_ENV += _THIS_PORT=${WRKSRC} +MAKE_ENV += _THIS_PORT=${WRKSRC} + .if ${PROPERTIES:Mlld} USE_LLD ?= Yes .else -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
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 wrote: > On Thu, Sep 27 2018, Stuart Henderson 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 > > 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.1src/unix/openbsd.c: which[1] = KERN_CPTIME2; > > cmake-3.10.2Utilities/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 > _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 >
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
Not ports related, but seeing these failures, it would also be worth testing snmpd from base with hw.smt=0 on an HT machine.
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
On Thu, Sep 27 2018, Stuart Henderson 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 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.103rdparty/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 _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
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
Stuart Henderson 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): > > libgtop2-2.38.0 sysdeps/openbsd/cpu.c:static int mib_cptime_s > [] = { CTL_KERN, KERN_CPTIME2, 0 }; > conky-1.9.0 src/openbsd.c:int cp_time_mib[] > = { CTL_KERN, KERN_CPTIME2, i }; > symon-2.88platform/OpenBSD/sm_cpu.c:st->parg.cp.mib[1] = > KERN_CPTIME2; > xstatbar-0.5 stats.c: mib_cpus[1] = KERN_CPTIME2; > xfce4-cpugraph-1.0.5 panel-plugin/os.c: gint mib[] = {CTL_KERN, > KERN_CPTIME2, i - 1}; > net-snmp-5.8 agent/mibgroup/hardware/cpu/cpu_sysctl.c:int > mcpu_mib[] = { CTL_KERN, KERN_CPTIME2, 0 }; > zabbix-3.4.11 src/zabbix_agent/cpustat.c: mib[1] > = KERN_CPTIME2; > filebeat-6.2.4 > vendor/github.com/elastic/gosigar/sigar_openbsd.go:mib = > []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > heartbeat-6.2.4 > vendor/github.com/elastic/gosigar/sigar_openbsd.go: mib = > []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > metricbeat-6.2.4 vendor/github.com/elastic/gosigar/sigar_openbsd.go: > mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > packetbeat-6.2.4 vendor/github.com/elastic/gosigar/sigar_openbsd.go: > mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > collectd-5.8.0src/cpu.c: int mib[] = {CTL_KERN, > KERN_CPTIME2, i}; > consul-1.2.3 vendor/github.com/shirou/gopsutil/cpu/cpu_openbsd.go: > KernCptime2 = 71 // KERN_CPTIME2 > htop-2.2.0openbsd/Platform.c: int mib[] = { CTL_KERN, > KERN_CPTIME2, cpu-1 }; > > 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.103rdparty/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; > > 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; > > rust & vendored copies, consts only I believe: > > cbindgen-0.6.3 > modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > const KERN_CPTIME2: ::c_int = 71; > exa-0.8.0 > modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > const KERN_CPTIME2: ::c_int = 71; > firefox-62.0.2 > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > KERN_CPTIME2: ::c_int = 71; > firefox-esr-60.2.1 > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > KERN_CPTIME2: ::c_int = 71; > librsvg-2.44.4 > vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > KERN_CPTIME2: ::c_int = 71; > ripgrep-0.8.1 > modcargo-crates/libc-0.2.36/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > const KERN_CPTIME2: ::c_int = 71; > rust-1.29.1 > src/liblibc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > KERN_CPTIME2: ::c_int = 71; > rust-1.29.1 > src/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > KERN_CPTIME2: ::c_int = 71; > seamonkey-2.49.4 > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const > KERN_CPTIME2: ::c_int = 71; > seamonkey-2.49.4 > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const > KERN_CPTIME2: ::c_int = 71; > spidermonkey-52.8.1 > third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const > KERN_CPTIME2: ::c_int = 71; > spidermonkey-52.8.1 > third_party
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
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 > > > > > > > > > - Forwarded message from Scott Soule Cheloha ----- > > > > From: Scott Soule Cheloha > > Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT) > > To: source-chan...@openbsd.org > > Subject: CVS: cvs.openbsd.org: src > > > > CVSROOT:/cvs > > Module name:src > > Changes by: chel...@cvs.openbsd.org 2018/09/26 11:23:13 > > > > Modified files: > > sys/kern : kern_sched.c kern_sysctl.c > > sys/sys: sched.h > > usr.bin/systat : cpu.c vmstat.c > > usr.bin/top: display.c display.h machine.c machine.h top.c > > > > Log message: > > KERN_CPTIME2: set ENODEV if the CPU is offline. > > > > This lets userspace distinguish between idle CPUs and those that are > > not schedulable because hw.smt=0. > > > > A subsequent commit probably needs to add documentation for this > > to sysctl.2 (and perhaps elsewhere) after the dust settles. > > > > Also included here are changes to systat(1) and top(1) that account > > for the ENODEV case and adjust behavior accordingly: > > > > - systat(1)'s cpu view prints placeholder marks ('-') instead of > > percentages for each state if the given CPU is offline. > > > > - systat(1)'s vmstat view checks for offline CPUs when computing the > > machine state total and excludes them, so the CPU usage graph > > only represents the states for online CPUs. > > > > - top(1) does not draw CPU rows for offline CPUs when the view is > > redrawn. If CPUs "go offline", percentages for each state are > > replaced by placeholder marks ('-'); the view will need to be > > redrawn to remove these rows. If CPUs "go online" the view will > > need to be redrawn to show these new CPUs. In "combined CPU" mode, > > the count and the state totals only represent online CPUs. > > > > Ports using KERN_CPTIME2 will need to be updated. The changes > > described above to make systat(1) and top(1) aware of the ENODEV > > case *and* gracefully handle a changing HW_NCPUONLINE while the > > application is running are not necessarily appropriate for each > > and every port. > > > > The changes described above are so extensive in part to demonstrate > > one way a program *might* be made robust to changing CPU availability. > > In particular, changing hw.smt after boot is an extremely rare event, > > and this needs to be weighed when updating ports. > > > > The logic needed to account for the KERN_CPTIME2 ENODEV case is > > very roughly: > > > > if (sysctl(...) == -1) { > > if (errno != ENODEV) { > > /* Actual error occurred. */ > > } else { > > /* CPU is offline. */ > > } > > } else { > > /* CPU is online and CPU states were set by sysctl(2). */ > > } > > > > Prompted by deraadt@. Basic idea for ENODEV from kettenis@. Discussed at > > length with kettenis@. Additional testing by tb@. > > > > No complaints from hackers@ after a week. > > > > ok kettenis@, "I think you should commit [now]" deraadt@ > > > > > > - End forwarded message - > > conky hw.smt=0 ERROR : conky Conky: desktop window (1c00010) is subwindow of root window (e1) Conky: window type - desktop Conky: drawing to created window (0x1e1) Conky: drawing to single buffer Conky: sysctl kern.cp_time2 failed Conky: sysctl kern.cp_time2 failed Conky: sysctl kern.cp_time2 failed Conky: sysctl kern.cp_time2 failed conky hw.smt=1 OK htop hw.smt=0 OK htop hw.smt=1 OK top hw.smt=0 OK top hw.smt=1 OK zabbix: hw.smt=0 OK zabbix: hw.smt=1 OK tested with zabbix_get -s loc
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
On Thu, Sep 27, 2018 at 09:25:51PM +0100, Stuart Henderson wrote: > > > > From a search over extracted ports source and cleaned up (ignoring ifdefs > > etc): > > The rust-related things are not going to be actually using it so you > can ignore those. yes. it is the Rust libc (re)definition. so just the constant for program that would use it. but nothing use it currently. > > rust & vendored copies, consts only I believe: > > > > cbindgen-0.6.3 > > modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > > const KERN_CPTIME2: ::c_int = 71; > > exa-0.8.0 > > modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > > const KERN_CPTIME2: ::c_int = 71; > > firefox-62.0.2 > > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > firefox-esr-60.2.1 > > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > librsvg-2.44.4 > > vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > ripgrep-0.8.1 > > modcargo-crates/libc-0.2.36/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > > const KERN_CPTIME2: ::c_int = 71; > > rust-1.29.1 > > src/liblibc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > rust-1.29.1 > > src/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > seamonkey-2.49.4 > > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > seamonkey-2.49.4 > > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > spidermonkey-52.8.1 > > third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > spidermonkey-52.8.1 > > third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > suricata-4.0.5 > > rust/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > tb-browser-7.5.3 > > third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > tb-browser-7.5.3 > > third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > thunderbird-52.9.1 > > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > thunderbird-52.9.1 > > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const > > KERN_CPTIME2: ::c_int = 71; > > > Thanks for the investigation time sthen@. -- Sebastien Marie
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
On 2018/09/27 20:06, Stuart Henderson 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): Before we can figure out how to fix things we need to know what's actually broken by this change. If you have a CPU with hyperthreading available and enabled in BIOS it would be helpful to make sure you have a new enough system (if it's new enough, you willl see output from "strings /usr/bin/top | grep '%s%5s %s'") and try some of the programs from the list below (with the default sysctl hw.smt=0 setting) and exercise any cpu-time related functionality. Ports in the first group below are likely easy enough to figure out how to test (for things like htop and xstatbar just running them should be enough, some others will need config). Second and third groups might be a bit trickier as I don't know what if anything would trigger actually using that. The rust-related things are not going to be actually using it so you can ignore those. > libgtop2-2.38.0 sysdeps/openbsd/cpu.c:static int mib_cptime_s > [] = { CTL_KERN, KERN_CPTIME2, 0 }; > conky-1.9.0 src/openbsd.c:int cp_time_mib[] > = { CTL_KERN, KERN_CPTIME2, i }; > symon-2.88platform/OpenBSD/sm_cpu.c:st->parg.cp.mib[1] = > KERN_CPTIME2; > xstatbar-0.5 stats.c: mib_cpus[1] = KERN_CPTIME2; > xfce4-cpugraph-1.0.5 panel-plugin/os.c: gint mib[] = {CTL_KERN, > KERN_CPTIME2, i - 1}; > net-snmp-5.8 agent/mibgroup/hardware/cpu/cpu_sysctl.c:int > mcpu_mib[] = { CTL_KERN, KERN_CPTIME2, 0 }; > zabbix-3.4.11 src/zabbix_agent/cpustat.c: mib[1] > = KERN_CPTIME2; > filebeat-6.2.4 > vendor/github.com/elastic/gosigar/sigar_openbsd.go:mib = > []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > heartbeat-6.2.4 > vendor/github.com/elastic/gosigar/sigar_openbsd.go: mib = > []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > metricbeat-6.2.4 vendor/github.com/elastic/gosigar/sigar_openbsd.go: > mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > packetbeat-6.2.4 vendor/github.com/elastic/gosigar/sigar_openbsd.go: > mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} > collectd-5.8.0src/cpu.c: int mib[] = {CTL_KERN, > KERN_CPTIME2, i}; > consul-1.2.3 vendor/github.com/shirou/gopsutil/cpu/cpu_openbsd.go: > KernCptime2 = 71 // KERN_CPTIME2 > htop-2.2.0openbsd/Platform.c: int mib[] = { CTL_KERN, > KERN_CPTIME2, cpu-1 }; > > 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.103rdparty/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; > > 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; > > rust & vendored copies, consts only I believe: > > cbindgen-0.6.3 > modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > const KERN_CPTIME2: ::c_int = 71; > exa-0.8.0 > modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub > const KERN_CPTIME2: ::c_int = 71; > firefox-62.0.2 > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > KERN_CPTIME2: ::c_int = 71; > firefox-esr-60.2.1 > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const > KERN_CPTIME2: ::c_int = 71; > librsvg-2.44.4 > vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/m
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
On Thu, Sep 27, 2018 at 08:06:39PM +0100, Stuart Henderson 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): > > > py-psutil-5.4.3 psutil/arch/openbsd/specific.c:mib[1] = > KERN_CPTIME2; For the surrounding code: https://github.com/giampaolo/psutil/blob/master/psutil/arch/openbsd/specific.c#L651
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
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): libgtop2-2.38.0 sysdeps/openbsd/cpu.c:static int mib_cptime_s [] = { CTL_KERN, KERN_CPTIME2, 0 }; conky-1.9.0 src/openbsd.c:int cp_time_mib[] = { CTL_KERN, KERN_CPTIME2, i }; symon-2.88 platform/OpenBSD/sm_cpu.c:st->parg.cp.mib[1] = KERN_CPTIME2; xstatbar-0.5stats.c: mib_cpus[1] = KERN_CPTIME2; xfce4-cpugraph-1.0.5panel-plugin/os.c: gint mib[] = {CTL_KERN, KERN_CPTIME2, i - 1}; net-snmp-5.8agent/mibgroup/hardware/cpu/cpu_sysctl.c:int mcpu_mib[] = { CTL_KERN, KERN_CPTIME2, 0 }; zabbix-3.4.11 src/zabbix_agent/cpustat.c: mib[1] = KERN_CPTIME2; filebeat-6.2.4 vendor/github.com/elastic/gosigar/sigar_openbsd.go: mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} heartbeat-6.2.4 vendor/github.com/elastic/gosigar/sigar_openbsd.go: mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} metricbeat-6.2.4vendor/github.com/elastic/gosigar/sigar_openbsd.go: mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} packetbeat-6.2.4vendor/github.com/elastic/gosigar/sigar_openbsd.go: mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)} collectd-5.8.0 src/cpu.c: int mib[] = {CTL_KERN, KERN_CPTIME2, i}; consul-1.2.3vendor/github.com/shirou/gopsutil/cpu/cpu_openbsd.go: KernCptime2 = 71 // KERN_CPTIME2 htop-2.2.0 openbsd/Platform.c: int mib[] = { CTL_KERN, KERN_CPTIME2, cpu-1 }; libuv & vendored copies libuv-1.19.1src/unix/openbsd.c: which[1] = KERN_CPTIME2; cmake-3.10.2Utilities/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; 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; rust & vendored copies, consts only I believe: cbindgen-0.6.3 modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; exa-0.8.0 modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; firefox-62.0.2 third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; firefox-esr-60.2.1 third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; librsvg-2.44.4 vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; ripgrep-0.8.1 modcargo-crates/libc-0.2.36/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; rust-1.29.1 src/liblibc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; rust-1.29.1 src/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; seamonkey-2.49.4 mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const KERN_CPTIME2: ::c_int = 71; seamonkey-2.49.4 mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const KERN_CPTIME2: ::c_int = 71; spidermonkey-52.8.1 third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const KERN_CPTIME2: ::c_int = 71; spidermonkey-52.8.1 third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const KERN_CPTIME2: ::c_int = 71; suricata-4.0.5 rust/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: ::c_int = 71; tb-browser-7.5.3 third_party/rust/libc/src/unix/bsd/openbsdl
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
On 2018/09/26 12:28, Chris Bennett wrote: > I was about to file a bug report, perhaps this is relevant here? > > This was happening also on a recent snap before this one. > > Using spectrwm, my windows freeze up until I go yo another screen and > back. For example, cat file or ls -la show screen output, but no > scrolling with mouse until I switch screens back and forth. > Same for firefox, etc. It's not going to be related to the current topic of today's commit to KERN_CPTIME2. The spectrwm port was updated recently (9 September) so I'd expect it's probably related to that. > > OpenBSD 6.4-beta (GENERIC.MP) #325: Tue Sep 25 22:24:42 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4077236224 (3888MB) > avail mem = 3944398848 (3761MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdbb33000 (45 entries) > bios0: vendor LENOVO version "5PCN20WW" date 01/15/2018 > bios0: LENOVO 80XV > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST SSDT MSDM BATB SSDT SSDT > IVRS CRAT VFCT SSDT FPDT SSDT BGRT UEFI > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) > GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.81 MHz, 15-70-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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 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 17 (application processor) > cpu1: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.39 MHz, 15-70-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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 1, core 0, package 0 > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped > ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (GPP0) > acpiprt2 at acpi0: bus -1 (GPP1) > acpiprt3 at acpi0: bus 1 (GPP2) > acpiprt4 at acpi0: bus 2 (GPP3) > acpiprt5 at acpi0: bus -1 (GPP4) > acpiprt6 at acpi0: bus -1 (GFX0) > acpiprt7 at acpi0: bus -1 (GFX1) > acpiprt8 at acpi0: bus -1 (GFX2) > acpiprt9 at acpi0: bus -1 (GFX3) > acpiprt10 at acpi0: bus -1 (GFX4) > acpiec0 at acpi0 > acpicpu0 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS > acpicpu1 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS > acpipwrres0 at acpi0: P0U3, resource for XHC0 > acpipwrres1 at acpi0: P3U3, resource for XHC0 > acpipwrres2 at acpi0: P0U2, resource for EHC1 > acpipwrres3 at acpi0: P3U2, resource for EHC1 > acpipwrres4 at acpi0: P0SD > acpipwrres5 at acpi0: P3SD > acpipwrres6 at acpi0: P0ST, resource for SATA > acpipwrres7 at acpi0: P3ST, resource for SATA > acpibtn0 at acpi0: PWRB > acpicmos0 at acpi0 > acpibat0 at acpi0: BAT0 model "L16L2PB2" serial 3458 type LiP oem "LGC" > "VPC2004" at acpi0 not configured > acpiac0 at acpi0: AC unit online > acpibtn1 at acpi0: LID_ > "PNP0C14" at acpi0 not configured > "AMD0030" at acpi0 not configured > "AMD0010" at acpi0 not configured > "ELAN060C" at acpi0 not configured > acpivideo0 at acpi0: VGA_ > acpivideo1 at acpi0: VGA_ > acpivideo2 at acpi0: VGA_ > cpu0: 2994 MHz: speeds: 3000 2700 2400 2100 1800 1400 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "AMD AMD64 15h Root Complex" rev 0x00 > "AMD AMD64 15h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured > vendor "ATI", unkn
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
I was about to file a bug report, perhaps this is relevant here? This was happening also on a recent snap before this one. Using spectrwm, my windows freeze up until I go yo another screen and back. For example, cat file or ls -la show screen output, but no scrolling with mouse until I switch screens back and forth. Same for firefox, etc. OpenBSD 6.4-beta (GENERIC.MP) #325: Tue Sep 25 22:24:42 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4077236224 (3888MB) avail mem = 3944398848 (3761MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdbb33000 (45 entries) bios0: vendor LENOVO version "5PCN20WW" date 01/15/2018 bios0: LENOVO 80XV acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST SSDT MSDM BATB SSDT SSDT IVRS CRAT VFCT SSDT FPDT SSDT BGRT UEFI acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.81 MHz, 15-70-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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 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 17 (application processor) cpu1: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.39 MHz, 15-70-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,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (GPP0) acpiprt2 at acpi0: bus -1 (GPP1) acpiprt3 at acpi0: bus 1 (GPP2) acpiprt4 at acpi0: bus 2 (GPP3) acpiprt5 at acpi0: bus -1 (GPP4) acpiprt6 at acpi0: bus -1 (GFX0) acpiprt7 at acpi0: bus -1 (GFX1) acpiprt8 at acpi0: bus -1 (GFX2) acpiprt9 at acpi0: bus -1 (GFX3) acpiprt10 at acpi0: bus -1 (GFX4) acpiec0 at acpi0 acpicpu0 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS acpipwrres0 at acpi0: P0U3, resource for XHC0 acpipwrres1 at acpi0: P3U3, resource for XHC0 acpipwrres2 at acpi0: P0U2, resource for EHC1 acpipwrres3 at acpi0: P3U2, resource for EHC1 acpipwrres4 at acpi0: P0SD acpipwrres5 at acpi0: P3SD acpipwrres6 at acpi0: P0ST, resource for SATA acpipwrres7 at acpi0: P3ST, resource for SATA acpibtn0 at acpi0: PWRB acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "L16L2PB2" serial 3458 type LiP oem "LGC" "VPC2004" at acpi0 not configured acpiac0 at acpi0: AC unit online acpibtn1 at acpi0: LID_ "PNP0C14" at acpi0 not configured "AMD0030" at acpi0 not configured "AMD0010" at acpi0 not configured "ELAN060C" at acpi0 not configured acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ acpivideo2 at acpi0: VGA_ cpu0: 2994 MHz: speeds: 3000 2700 2400 2100 1800 1400 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 15h Root Complex" rev 0x00 "AMD AMD64 15h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured vendor "ATI", unknown product 0x98e4 (class display subclass VGA, rev 0xda) at pci0 dev 1 function 0 not configured azalia0 at pci0 dev 1 function 1 vendor "ATI", unknown product 0x15b3 rev 0x00: msi azalia0: no supported codecs pchb1 at pci0 dev 2 function 0 "AMD AMD64 15h Host" rev 0x00 ppb0 at pci0 dev 2 function 3 "AMD AMD64 15h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 vendor "Atheros", unknown product 0x0042 (class network s
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
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 > > > > - Forwarded message from Scott Soule Cheloha - > > From: Scott Soule Cheloha > Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT) > To: source-chan...@openbsd.org > Subject: CVS: cvs.openbsd.org: src > > CVSROOT: /cvs > Module name: src > Changes by: chel...@cvs.openbsd.org 2018/09/26 11:23:13 > > Modified files: > sys/kern : kern_sched.c kern_sysctl.c > sys/sys: sched.h > usr.bin/systat : cpu.c vmstat.c > usr.bin/top: display.c display.h machine.c machine.h top.c > > Log message: > KERN_CPTIME2: set ENODEV if the CPU is offline. > > This lets userspace distinguish between idle CPUs and those that are > not schedulable because hw.smt=0. > > A subsequent commit probably needs to add documentation for this > to sysctl.2 (and perhaps elsewhere) after the dust settles. > > Also included here are changes to systat(1) and top(1) that account > for the ENODEV case and adjust behavior accordingly: > > - systat(1)'s cpu view prints placeholder marks ('-') instead of > percentages for each state if the given CPU is offline. > > - systat(1)'s vmstat view checks for offline CPUs when computing the > machine state total and excludes them, so the CPU usage graph > only represents the states for online CPUs. > > - top(1) does not draw CPU rows for offline CPUs when the view is > redrawn. If CPUs "go offline", percentages for each state are > replaced by placeholder marks ('-'); the view will need to be > redrawn to remove these rows. If CPUs "go online" the view will > need to be redrawn to show these new CPUs. In "combined CPU" mode, > the count and the state totals only represent online CPUs. > > Ports using KERN_CPTIME2 will need to be updated. The changes > described above to make systat(1) and top(1) aware of the ENODEV > case *and* gracefully handle a changing HW_NCPUONLINE while the > application is running are not necessarily appropriate for each > and every port. > > The changes described above are so extensive in part to demonstrate > one way a program *might* be made robust to changing CPU availability. > In particular, changing hw.smt after boot is an extremely rare event, > and this needs to be weighed when updating ports. > > The logic needed to account for the KERN_CPTIME2 ENODEV case is > very roughly: > > if (sysctl(...) == -1) { > if (errno != ENODEV) { > /* Actual error occurred. */ > } else { > /* CPU is offline. */ > } > } else { > /* CPU is online and CPU states were set by sysctl(2). */ > } > > Prompted by deraadt@. Basic idea for ENODEV from kettenis@. Discussed at > length with kettenis@. Additional testing by tb@. > > No complaints from hackers@ after a week. > > ok kettenis@, "I think you should commit [now]" deraadt@ > > > - End forwarded message - >
KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
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. - Forwarded message from Scott Soule Cheloha - From: Scott Soule Cheloha Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT) To: source-chan...@openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: chel...@cvs.openbsd.org 2018/09/26 11:23:13 Modified files: sys/kern : kern_sched.c kern_sysctl.c sys/sys: sched.h usr.bin/systat : cpu.c vmstat.c usr.bin/top: display.c display.h machine.c machine.h top.c Log message: KERN_CPTIME2: set ENODEV if the CPU is offline. This lets userspace distinguish between idle CPUs and those that are not schedulable because hw.smt=0. A subsequent commit probably needs to add documentation for this to sysctl.2 (and perhaps elsewhere) after the dust settles. Also included here are changes to systat(1) and top(1) that account for the ENODEV case and adjust behavior accordingly: - systat(1)'s cpu view prints placeholder marks ('-') instead of percentages for each state if the given CPU is offline. - systat(1)'s vmstat view checks for offline CPUs when computing the machine state total and excludes them, so the CPU usage graph only represents the states for online CPUs. - top(1) does not draw CPU rows for offline CPUs when the view is redrawn. If CPUs "go offline", percentages for each state are replaced by placeholder marks ('-'); the view will need to be redrawn to remove these rows. If CPUs "go online" the view will need to be redrawn to show these new CPUs. In "combined CPU" mode, the count and the state totals only represent online CPUs. Ports using KERN_CPTIME2 will need to be updated. The changes described above to make systat(1) and top(1) aware of the ENODEV case *and* gracefully handle a changing HW_NCPUONLINE while the application is running are not necessarily appropriate for each and every port. The changes described above are so extensive in part to demonstrate one way a program *might* be made robust to changing CPU availability. In particular, changing hw.smt after boot is an extremely rare event, and this needs to be weighed when updating ports. The logic needed to account for the KERN_CPTIME2 ENODEV case is very roughly: if (sysctl(...) == -1) { if (errno != ENODEV) { /* Actual error occurred. */ } else { /* CPU is offline. */ } } else { /* CPU is online and CPU states were set by sysctl(2). */ } Prompted by deraadt@. Basic idea for ENODEV from kettenis@. Discussed at length with kettenis@. Additional testing by tb@. No complaints from hackers@ after a week. ok kettenis@, "I think you should commit [now]" deraadt@ - End forwarded message -
Re: CVS: cvs.openbsd.org: src
On 2018/05/01 22:00, Vadim Zhukov wrote: > 2018-04-29 9:48 GMT+03:00 Kirill Bychkov : > > On Sun, April 29, 2018 00:25, Stuart Henderson wrote: > >> It needs more of a change than that, the syntax is different. > >> > > > > Hi! > > It uses /usr/bin/mail so it is safe to drop embedded smtp (see > > /etc/apcupsd/apccontrol) and I doubt someone tweaked it to use > > other mailers instead of its default.So no tweaks for MESSAGE > > are needed, IMO. > > Thanks for noticing it! > > OK kirby@ > > So there are likely literally 0 users of /usr/local/sbin/smtp on > OpenBSD. IIUC, this executable is actually needed on Windows, which > doesn't have an easy to use SMTP mailer bundled.[1] Stuart, the > maintainer (Kirill) proposes just killing the executable in port, do > you still think there should be more work done? When I first looked into this I saw some Linux packaging making changes relating to the smtp command which is why I thought it might be more widely used. OK to remove, I'd prefer no MESSAGE, but think a quick mention in faq/current.html (to add to upgrade64 later) would make sense. > [1] Well, there was Outlook Express at some point, and something > similar nowadays, but that wasn't easy to use, and this is offtopic > anyway. PowerShell's Send-MailMessage, but I digress... :-)
Re: CVS: cvs.openbsd.org: src
2018-04-29 9:48 GMT+03:00 Kirill Bychkov : > On Sun, April 29, 2018 00:25, Stuart Henderson wrote: >> It needs more of a change than that, the syntax is different. >> > > Hi! > It uses /usr/bin/mail so it is safe to drop embedded smtp (see > /etc/apcupsd/apccontrol) and I doubt someone tweaked it to use > other mailers instead of its default.So no tweaks for MESSAGE > are needed, IMO. > Thanks for noticing it! > OK kirby@ So there are likely literally 0 users of /usr/local/sbin/smtp on OpenBSD. IIUC, this executable is actually needed on Windows, which doesn't have an easy to use SMTP mailer bundled.[1] Stuart, the maintainer (Kirill) proposes just killing the executable in port, do you still think there should be more work done? -- WBR, Vadim Zhukov [1] Well, there was Outlook Express at some point, and something similar nowadays, but that wasn't easy to use, and this is offtopic anyway.
Re: CVS: cvs.openbsd.org: src
On Sun, April 29, 2018 00:25, Stuart Henderson wrote: > It needs more of a change than that, the syntax is different. > Hi! It uses /usr/bin/mail so it is safe to drop embedded smtp (see /etc/apcupsd/apccontrol) and I doubt someone tweaked it to use other mailers instead of its default.So no tweaks for MESSAGE are needed, IMO. Thanks for noticing it! OK kirby@ > -- > Sent from a phone, apologies for poor formatting. > On 28 April 2018 18:30:32 Vadim Zhukov wrote: > >> 2018-04-28 19:54 GMT+03:00 Eric Faurot : >> > CVSROOT:/cvs >> > Module name:src >> > Changes by: e...@cvs.openbsd.org2018/04/28 10:54:11 >> > >> > Modified files: >> > usr.sbin/smtpd : Makefile >> > >> > Log message: >> > link smtp(1) to the build >> > >> > ok deraadt@ >> >> Some care would be needed for apcupsd port, which installs >> /usr/local/sbin/smtp. IIUC, it does the same thing as /usr/bin/smtp >> and port could just stop installing it. The existing smtp users could >> be affected, though, so I propose the following patch. Any better >> ideas/objections/okays? >> >> -- >> WBR, >> Vadim Zhukov >> >> >> Index: Makefile >> === >> RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v >> retrieving revision 1.38 >> diff -u -p -r1.38 Makefile >> --- Makefile12 Jan 2018 14:05:10 - 1.38 >> +++ Makefile28 Apr 2018 17:27:33 - >> @@ -9,7 +9,7 @@ PKGNAME-main = ${DISTNAME} >> PKGNAME-cgi = ${DISTNAME:S/-/-cgi-/} >> PKGNAME-x11 = ${DISTNAME:S/-/-x11-/} >> REVISION = 1 >> -REVISION-main =2 >> +REVISION-main =3 >> >> CATEGORIES = sysutils >> >> @@ -108,5 +108,6 @@ post-install: >>${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/ >>cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd >>chmod 755 ${PREFIX}/sbin/apcupsctl >> + rm -f ${PREFIX}/sbin/smtp >> >> .include >> Index: pkg/MESSAGE-main >> === >> RCS file: pkg/MESSAGE-main >> diff -N pkg/MESSAGE-main >> --- /dev/null 1 Jan 1970 00:00:00 - >> +++ pkg/MESSAGE-main28 Apr 2018 17:27:33 - >> @@ -0,0 +1,2 @@ >> +The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4. >> +Any scripts using it should now use the /usr/bin/smtp instead. >> Index: pkg/PLIST-main >> === >> RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v >> retrieving revision 1.9 >> diff -u -p -r1.9 PLIST-main >> --- pkg/PLIST-main 22 Jan 2015 21:23:30 - 1.9 >> +++ pkg/PLIST-main 28 Apr 2018 17:27:33 - >> @@ -14,7 +14,6 @@ >> @mode >> @owner >> sbin/apcupsctl >> -@bin sbin/smtp >> @comment share/applications/ >> @group >> share/doc/apcupsd/ > > > >
Re: CVS: cvs.openbsd.org: src
It needs more of a change than that, the syntax is different. -- Sent from a phone, apologies for poor formatting. On 28 April 2018 18:30:32 Vadim Zhukov wrote: 2018-04-28 19:54 GMT+03:00 Eric Faurot : > CVSROOT:/cvs > Module name:src > Changes by: e...@cvs.openbsd.org2018/04/28 10:54:11 > > Modified files: > usr.sbin/smtpd : Makefile > > Log message: > link smtp(1) to the build > > ok deraadt@ Some care would be needed for apcupsd port, which installs /usr/local/sbin/smtp. IIUC, it does the same thing as /usr/bin/smtp and port could just stop installing it. The existing smtp users could be affected, though, so I propose the following patch. Any better ideas/objections/okays? -- WBR, Vadim Zhukov Index: Makefile === RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v retrieving revision 1.38 diff -u -p -r1.38 Makefile --- Makefile12 Jan 2018 14:05:10 - 1.38 +++ Makefile28 Apr 2018 17:27:33 - @@ -9,7 +9,7 @@ PKGNAME-main = ${DISTNAME} PKGNAME-cgi = ${DISTNAME:S/-/-cgi-/} PKGNAME-x11 = ${DISTNAME:S/-/-x11-/} REVISION = 1 -REVISION-main =2 +REVISION-main =3 CATEGORIES = sysutils @@ -108,5 +108,6 @@ post-install: ${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/ cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd chmod 755 ${PREFIX}/sbin/apcupsctl + rm -f ${PREFIX}/sbin/smtp .include Index: pkg/MESSAGE-main === RCS file: pkg/MESSAGE-main diff -N pkg/MESSAGE-main --- /dev/null 1 Jan 1970 00:00:00 - +++ pkg/MESSAGE-main28 Apr 2018 17:27:33 - @@ -0,0 +1,2 @@ +The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4. +Any scripts using it should now use the /usr/bin/smtp instead. Index: pkg/PLIST-main === RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v retrieving revision 1.9 diff -u -p -r1.9 PLIST-main --- pkg/PLIST-main 22 Jan 2015 21:23:30 - 1.9 +++ pkg/PLIST-main 28 Apr 2018 17:27:33 - @@ -14,7 +14,6 @@ @mode @owner sbin/apcupsctl -@bin sbin/smtp @comment share/applications/ @group share/doc/apcupsd/
Re: CVS: cvs.openbsd.org: src
2018-04-28 19:54 GMT+03:00 Eric Faurot : > CVSROOT:/cvs > Module name:src > Changes by: e...@cvs.openbsd.org2018/04/28 10:54:11 > > Modified files: > usr.sbin/smtpd : Makefile > > Log message: > link smtp(1) to the build > > ok deraadt@ Some care would be needed for apcupsd port, which installs /usr/local/sbin/smtp. IIUC, it does the same thing as /usr/bin/smtp and port could just stop installing it. The existing smtp users could be affected, though, so I propose the following patch. Any better ideas/objections/okays? -- WBR, Vadim Zhukov Index: Makefile === RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v retrieving revision 1.38 diff -u -p -r1.38 Makefile --- Makefile12 Jan 2018 14:05:10 - 1.38 +++ Makefile28 Apr 2018 17:27:33 - @@ -9,7 +9,7 @@ PKGNAME-main = ${DISTNAME} PKGNAME-cgi = ${DISTNAME:S/-/-cgi-/} PKGNAME-x11 = ${DISTNAME:S/-/-x11-/} REVISION = 1 -REVISION-main =2 +REVISION-main =3 CATEGORIES = sysutils @@ -108,5 +108,6 @@ post-install: ${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/ cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd chmod 755 ${PREFIX}/sbin/apcupsctl + rm -f ${PREFIX}/sbin/smtp .include Index: pkg/MESSAGE-main === RCS file: pkg/MESSAGE-main diff -N pkg/MESSAGE-main --- /dev/null 1 Jan 1970 00:00:00 - +++ pkg/MESSAGE-main28 Apr 2018 17:27:33 - @@ -0,0 +1,2 @@ +The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4. +Any scripts using it should now use the /usr/bin/smtp instead. Index: pkg/PLIST-main === RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v retrieving revision 1.9 diff -u -p -r1.9 PLIST-main --- pkg/PLIST-main 22 Jan 2015 21:23:30 - 1.9 +++ pkg/PLIST-main 28 Apr 2018 17:27:33 - @@ -14,7 +14,6 @@ @mode @owner sbin/apcupsctl -@bin sbin/smtp @comment share/applications/ @group share/doc/apcupsd/ Index: Makefile === RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v retrieving revision 1.38 diff -u -p -r1.38 Makefile --- Makefile 12 Jan 2018 14:05:10 - 1.38 +++ Makefile 28 Apr 2018 17:27:33 - @@ -9,7 +9,7 @@ PKGNAME-main = ${DISTNAME} PKGNAME-cgi = ${DISTNAME:S/-/-cgi-/} PKGNAME-x11 = ${DISTNAME:S/-/-x11-/} REVISION = 1 -REVISION-main = 2 +REVISION-main = 3 CATEGORIES = sysutils @@ -108,5 +108,6 @@ post-install: ${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/ cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd chmod 755 ${PREFIX}/sbin/apcupsctl + rm -f ${PREFIX}/sbin/smtp .include Index: pkg/MESSAGE-main === RCS file: pkg/MESSAGE-main diff -N pkg/MESSAGE-main --- /dev/null 1 Jan 1970 00:00:00 - +++ pkg/MESSAGE-main 28 Apr 2018 17:27:33 - @@ -0,0 +1,2 @@ +The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4. +Any scripts using it should now use the /usr/bin/smtp instead. Index: pkg/PLIST-main === RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v retrieving revision 1.9 diff -u -p -r1.9 PLIST-main --- pkg/PLIST-main 22 Jan 2015 21:23:30 - 1.9 +++ pkg/PLIST-main 28 Apr 2018 17:27:33 - @@ -14,7 +14,6 @@ @mode @owner sbin/apcupsctl -@bin sbin/smtp @comment share/applications/ @group share/doc/apcupsd/
Re: salt threads? Re: CVS: cvs.openbsd.org: src
On 17-07-30 22:20:59, viq wrote: > On 17-07-30 22:10:43, viq wrote: > > On 17-07-30 15:50:44, Ted Unangst wrote: > > > viq wrote: > > > > > > anybody know what's going on? > > > > > > > > > > From my running salt with trace logs, it seems that salt initialises > > > > > everything, opens it's IPC sockets, initiates it's AES auth/handshake > > > > > with master, and that's when things die. > > > > > > > > Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines, > > > > 4.2MB compressed > > > > > > not especially. i already know *what* it does. somebody has to read the > > > code > > > to figure out why. > > > > If you tell me what to write, I could create an issue upstream. Or you > > could skip the middleman and do it at > > https://github.com/saltstack/salt/issues and let them deal with reading > > the code ;) > > https://github.com/saltstack/salt/issues/42634 As per https://github.com/saltstack/salt/issues/42634#issuecomment-320029538 this is in ZeroMQ, and currently upstream's advice is we default to TCP transport for Salt on OpenBSD - which would require switching master such nodes are connected to, and all minions that are connected to same master. > > > anyway, i turned the check off for now. it's good to know it triggers, but > > > with clang and other changes now isn't the best time. > > > > Thank you.
Re: salt threads? Re: CVS: cvs.openbsd.org: src
On 17-07-30 22:10:43, viq wrote: > On 17-07-30 15:50:44, Ted Unangst wrote: > > viq wrote: > > > > > anybody know what's going on? > > > > > > > > From my running salt with trace logs, it seems that salt initialises > > > > everything, opens it's IPC sockets, initiates it's AES auth/handshake > > > > with master, and that's when things die. > > > > > > Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines, > > > 4.2MB compressed > > > > not especially. i already know *what* it does. somebody has to read the code > > to figure out why. > > If you tell me what to write, I could create an issue upstream. Or you > could skip the middleman and do it at > https://github.com/saltstack/salt/issues and let them deal with reading > the code ;) https://github.com/saltstack/salt/issues/42634 > > anyway, i turned the check off for now. it's good to know it triggers, but > > with clang and other changes now isn't the best time. > > Thank you.
Re: salt threads? Re: CVS: cvs.openbsd.org: src
On 17-07-30 15:50:44, Ted Unangst wrote: > viq wrote: > > > > anybody know what's going on? > > > > > > From my running salt with trace logs, it seems that salt initialises > > > everything, opens it's IPC sockets, initiates it's AES auth/handshake > > > with master, and that's when things die. > > > > Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines, > > 4.2MB compressed > > not especially. i already know *what* it does. somebody has to read the code > to figure out why. If you tell me what to write, I could create an issue upstream. Or you could skip the middleman and do it at https://github.com/saltstack/salt/issues and let them deal with reading the code ;) > anyway, i turned the check off for now. it's good to know it triggers, but > with clang and other changes now isn't the best time. Thank you.
Re: salt threads? Re: CVS: cvs.openbsd.org: src
viq wrote: > > > anybody know what's going on? > > > > From my running salt with trace logs, it seems that salt initialises > > everything, opens it's IPC sockets, initiates it's AES auth/handshake > > with master, and that's when things die. > > Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines, > 4.2MB compressed not especially. i already know *what* it does. somebody has to read the code to figure out why. anyway, i turned the check off for now. it's good to know it triggers, but with clang and other changes now isn't the best time.
Re: salt threads? Re: CVS: cvs.openbsd.org: src
On 17-07-28 23:34:29, viq wrote: > On 17-07-28 16:04:16, Ted Unangst wrote: > > moving to ports > > > > viq wrote: > > > On 17-07-27 10:35:08, Ted Unangst wrote: > > > > CVSROOT:/cvs > > > > Module name:src > > > > Changes by: t...@cvs.openbsd.org2017/07/27 10:35:08 > > > > > > > > Modified files: > > > > lib/librthread : rthread.c rthread_fork.c > > > > > > > > Log message: > > > > bad things can (and will) happen if a threaded program calls fork() and > > > > then strays off the path to exec(). one common manifestation of this > > > > problem occurs in pthread_join(), so we can add a little check there. > > > > first person to hit this in real life gets to change the error message. > > > > > > So, uh, would that be me? > > > $ doas salt-minion > > > great scott! serious repercussions on future events! > > > $ echo $? > > > 250 > > > $ sysctl kern.version > > > kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT > > > 2017 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > > > i'm not sure what salt is doing (or even what it is), > > I can't tell you what it's doing, but it's a remote execution and > configuration management framework written in python, running (by > default) over ZeroMQ. > > > but this is probably not > > good. calling pthread_join() in the child after fork() is not something > > you're > > supposed to do. > > > > anybody know what's going on? > > From my running salt with trace logs, it seems that salt initialises > everything, opens it's IPC sockets, initiates it's AES auth/handshake > with master, and that's when things die. Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines, 4.2MB compressed
Re: salt threads? Re: CVS: cvs.openbsd.org: src
On 17-07-28 16:04:16, Ted Unangst wrote: > moving to ports > > viq wrote: > > On 17-07-27 10:35:08, Ted Unangst wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: t...@cvs.openbsd.org2017/07/27 10:35:08 > > > > > > Modified files: > > > lib/librthread : rthread.c rthread_fork.c > > > > > > Log message: > > > bad things can (and will) happen if a threaded program calls fork() and > > > then strays off the path to exec(). one common manifestation of this > > > problem occurs in pthread_join(), so we can add a little check there. > > > first person to hit this in real life gets to change the error message. > > > > So, uh, would that be me? > > $ doas salt-minion > > great scott! serious repercussions on future events! > > $ echo $? > > 250 > > $ sysctl kern.version > > kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT 2017 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > i'm not sure what salt is doing (or even what it is), I can't tell you what it's doing, but it's a remote execution and configuration management framework written in python, running (by default) over ZeroMQ. > but this is probably not > good. calling pthread_join() in the child after fork() is not something you're > supposed to do. > > anybody know what's going on? >From my running salt with trace logs, it seems that salt initialises everything, opens it's IPC sockets, initiates it's AES auth/handshake with master, and that's when things die.
salt threads? Re: CVS: cvs.openbsd.org: src
moving to ports viq wrote: > On 17-07-27 10:35:08, Ted Unangst wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: t...@cvs.openbsd.org2017/07/27 10:35:08 > > > > Modified files: > > lib/librthread : rthread.c rthread_fork.c > > > > Log message: > > bad things can (and will) happen if a threaded program calls fork() and > > then strays off the path to exec(). one common manifestation of this > > problem occurs in pthread_join(), so we can add a little check there. > > first person to hit this in real life gets to change the error message. > > So, uh, would that be me? > $ doas salt-minion > great scott! serious repercussions on future events! > $ echo $? > 250 > $ sysctl kern.version > kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT 2017 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC i'm not sure what salt is doing (or even what it is), but this is probably not good. calling pthread_join() in the child after fork() is not something you're supposed to do. anybody know what's going on?
Re: CVS: cvs.openbsd.org: src
On Fri, Sep 02, 2016 at 10:44:52AM +0100, Stuart Henderson wrote: > On 2016/09/02 11:28, Alexandre Ratchov wrote: > > On Fri, Sep 02, 2016 at 10:08:43AM +0200, Antoine Jacoutot wrote: > > > On Wed, Aug 31, 2016 at 01:22:43AM -0600, Alexandre Ratchov wrote: > > > > CVSROOT:/cvs > > > > Module name:src > > > > Changes by: ratc...@cvs.openbsd.org 2016/08/31 01:22:43 > > > > > > > > Modified files: > > > > share/man/man4 : audio.4 > > > > sys/dev: audio.c audio_if.h > > > > sys/sys: audioio.h > > > > sys/kern : kern_pledge.c > > > > > > > > Log message: > > > > Delete unused ioctls and associated macros. Move macros that are still > > > > used internally by low-level drivers from sys/audioio.h to > > > > dev/audio_if.h instead of deleting them. > > > > > > This broke ports/x11/emiclock. > > > > > > error: 'AUDIO_DRAIN' undeclared (first use in this function) > > > > > > > According to sources, sound never worked on modern machines. Given > > that last update of emiclock was in ~2000, $MASTER_SITES is dead, > > before I start fixing this, I'd prefer asking what's the most more > > appropriate: > > - fix sound? > > - disable sound? > > - delete emiclock? > > Since it is marked "PERMIT_PACKAGE_FTP= may not modify/package" > I think deleting it makes sense. I agree. > > > > Meanwhile, below is a quick fix to keep the current behavior: > > AUDIO_DRAIN is useless in this case, because close() drains anyway. > > So just drop the calls to AUDIO_DRAIN. > > > > OK? > > > > (moving discutions to ports@) > > > > Index: Makefile > > === > > RCS file: /cvs/ports/x11/emiclock/Makefile,v > > retrieving revision 1.26 > > diff -u -p -u -p -r1.26 Makefile > > --- Makefile11 Oct 2013 21:21:00 - 1.26 > > +++ Makefile2 Sep 2016 09:18:58 - > > @@ -3,7 +3,7 @@ > > COMMENT= hyper-animated face analog clock for X11 > > > > DISTNAME= emiclock-2.0.2 > > -REVISION= 3 > > +REVISION= 4 > > CATEGORIES=x11 > > > > MASTER_SITES= http://download.vector.co.jp/pack/unix/personal/tokei/ > > Index: patches/patch-sys_FreeBSD_audio_c > > === > > RCS file: /cvs/ports/x11/emiclock/patches/patch-sys_FreeBSD_audio_c,v > > retrieving revision 1.1 > > diff -u -p -u -p -r1.1 patch-sys_FreeBSD_audio_c > > --- patches/patch-sys_FreeBSD_audio_c 26 Oct 2007 20:44:07 - > > 1.1 > > +++ patches/patch-sys_FreeBSD_audio_c 2 Sep 2016 09:18:58 - > > @@ -1,6 +1,6 @@ > > $OpenBSD$ > > --- sys/FreeBSD/audio.c.orig Thu Sep 2 16:34:34 1999 > > -+++ sys/FreeBSD/audio.cFri Oct 26 22:33:32 2007 > > sys/FreeBSD/audio.cFri Sep 2 11:13:33 2016 > > @@ -90,7 +90,9 @@ S_PlaySound(char *soundfile) > > return (SOUND_DEVICE_ERROR); > > } > > @@ -11,19 +11,17 @@ $OpenBSD$ > > > > fstat(sfile, &sstat); > > len = sstat.st_size; > > -@@ -100,7 +102,11 @@ S_PlaySound(char *soundfile) > > +@@ -100,7 +102,9 @@ S_PlaySound(char *soundfile) > > if ( (l = read(sfile, buffer, len)) > 0) > > write(sdev, buffer, l); > > > > +#ifdef __FreeBSD__ > > ioctl(sdev, SNDCTL_DSP_SYNC, 0); > > -+#elif defined(__OpenBSD__) > > -+ioctl(sdev, AUDIO_DRAIN, 0); > > +#endif > > XtFree(buffer); > > > > close(sdev); > > -@@ -159,11 +165,17 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr) > > +@@ -159,11 +163,15 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr) > > return(SOUND_DEVICE_ERROR); > > } > > > > @@ -35,8 +33,6 @@ $OpenBSD$ > > > > +#ifdef __FreeBSD__ > > ioctl(sdev, SNDCTL_DSP_SYNC, 0); > > -+#elif defined(__OpenBSD__) > > -+ioctl(sdev, AUDIO_DRAIN, 0); > > +#endif > > close(sdev); > > > > -- Antoine
Re: CVS: cvs.openbsd.org: src
On 2016/09/02 11:28, Alexandre Ratchov wrote: > On Fri, Sep 02, 2016 at 10:08:43AM +0200, Antoine Jacoutot wrote: > > On Wed, Aug 31, 2016 at 01:22:43AM -0600, Alexandre Ratchov wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: ratc...@cvs.openbsd.org 2016/08/31 01:22:43 > > > > > > Modified files: > > > share/man/man4 : audio.4 > > > sys/dev: audio.c audio_if.h > > > sys/sys: audioio.h > > > sys/kern : kern_pledge.c > > > > > > Log message: > > > Delete unused ioctls and associated macros. Move macros that are still > > > used internally by low-level drivers from sys/audioio.h to > > > dev/audio_if.h instead of deleting them. > > > > This broke ports/x11/emiclock. > > > > error: 'AUDIO_DRAIN' undeclared (first use in this function) > > > > According to sources, sound never worked on modern machines. Given > that last update of emiclock was in ~2000, $MASTER_SITES is dead, > before I start fixing this, I'd prefer asking what's the most more > appropriate: > - fix sound? > - disable sound? > - delete emiclock? Since it is marked "PERMIT_PACKAGE_FTP= may not modify/package" I think deleting it makes sense. > Meanwhile, below is a quick fix to keep the current behavior: > AUDIO_DRAIN is useless in this case, because close() drains anyway. > So just drop the calls to AUDIO_DRAIN. > > OK? > > (moving discutions to ports@) > > Index: Makefile > === > RCS file: /cvs/ports/x11/emiclock/Makefile,v > retrieving revision 1.26 > diff -u -p -u -p -r1.26 Makefile > --- Makefile 11 Oct 2013 21:21:00 - 1.26 > +++ Makefile 2 Sep 2016 09:18:58 - > @@ -3,7 +3,7 @@ > COMMENT= hyper-animated face analog clock for X11 > > DISTNAME=emiclock-2.0.2 > -REVISION=3 > +REVISION=4 > CATEGORIES= x11 > > MASTER_SITES=http://download.vector.co.jp/pack/unix/personal/tokei/ > Index: patches/patch-sys_FreeBSD_audio_c > === > RCS file: /cvs/ports/x11/emiclock/patches/patch-sys_FreeBSD_audio_c,v > retrieving revision 1.1 > diff -u -p -u -p -r1.1 patch-sys_FreeBSD_audio_c > --- patches/patch-sys_FreeBSD_audio_c 26 Oct 2007 20:44:07 - 1.1 > +++ patches/patch-sys_FreeBSD_audio_c 2 Sep 2016 09:18:58 - > @@ -1,6 +1,6 @@ > $OpenBSD$ > --- sys/FreeBSD/audio.c.orig Thu Sep 2 16:34:34 1999 > -+++ sys/FreeBSD/audio.c Fri Oct 26 22:33:32 2007 > sys/FreeBSD/audio.c Fri Sep 2 11:13:33 2016 > @@ -90,7 +90,9 @@ S_PlaySound(char *soundfile) > return (SOUND_DEVICE_ERROR); > } > @@ -11,19 +11,17 @@ $OpenBSD$ > > fstat(sfile, &sstat); > len = sstat.st_size; > -@@ -100,7 +102,11 @@ S_PlaySound(char *soundfile) > +@@ -100,7 +102,9 @@ S_PlaySound(char *soundfile) > if ( (l = read(sfile, buffer, len)) > 0) > write(sdev, buffer, l); > > +#ifdef __FreeBSD__ > ioctl(sdev, SNDCTL_DSP_SYNC, 0); > -+#elif defined(__OpenBSD__) > -+ioctl(sdev, AUDIO_DRAIN, 0); > +#endif > XtFree(buffer); > > close(sdev); > -@@ -159,11 +165,17 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr) > +@@ -159,11 +163,15 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr) > return(SOUND_DEVICE_ERROR); > } > > @@ -35,8 +33,6 @@ $OpenBSD$ > > +#ifdef __FreeBSD__ > ioctl(sdev, SNDCTL_DSP_SYNC, 0); > -+#elif defined(__OpenBSD__) > -+ioctl(sdev, AUDIO_DRAIN, 0); > +#endif > close(sdev); > >
Re: CVS: cvs.openbsd.org: src
On Fri, Sep 02, 2016 at 10:08:43AM +0200, Antoine Jacoutot wrote: > On Wed, Aug 31, 2016 at 01:22:43AM -0600, Alexandre Ratchov wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: ratc...@cvs.openbsd.org 2016/08/31 01:22:43 > > > > Modified files: > > share/man/man4 : audio.4 > > sys/dev: audio.c audio_if.h > > sys/sys: audioio.h > > sys/kern : kern_pledge.c > > > > Log message: > > Delete unused ioctls and associated macros. Move macros that are still > > used internally by low-level drivers from sys/audioio.h to > > dev/audio_if.h instead of deleting them. > > This broke ports/x11/emiclock. > > error: 'AUDIO_DRAIN' undeclared (first use in this function) > According to sources, sound never worked on modern machines. Given that last update of emiclock was in ~2000, $MASTER_SITES is dead, before I start fixing this, I'd prefer asking what's the most more appropriate: - fix sound? - disable sound? - delete emiclock? Meanwhile, below is a quick fix to keep the current behavior: AUDIO_DRAIN is useless in this case, because close() drains anyway. So just drop the calls to AUDIO_DRAIN. OK? (moving discutions to ports@) Index: Makefile === RCS file: /cvs/ports/x11/emiclock/Makefile,v retrieving revision 1.26 diff -u -p -u -p -r1.26 Makefile --- Makefile11 Oct 2013 21:21:00 - 1.26 +++ Makefile2 Sep 2016 09:18:58 - @@ -3,7 +3,7 @@ COMMENT= hyper-animated face analog clock for X11 DISTNAME= emiclock-2.0.2 -REVISION= 3 +REVISION= 4 CATEGORIES=x11 MASTER_SITES= http://download.vector.co.jp/pack/unix/personal/tokei/ Index: patches/patch-sys_FreeBSD_audio_c === RCS file: /cvs/ports/x11/emiclock/patches/patch-sys_FreeBSD_audio_c,v retrieving revision 1.1 diff -u -p -u -p -r1.1 patch-sys_FreeBSD_audio_c --- patches/patch-sys_FreeBSD_audio_c 26 Oct 2007 20:44:07 - 1.1 +++ patches/patch-sys_FreeBSD_audio_c 2 Sep 2016 09:18:58 - @@ -1,6 +1,6 @@ $OpenBSD$ --- sys/FreeBSD/audio.c.orig Thu Sep 2 16:34:34 1999 -+++ sys/FreeBSD/audio.cFri Oct 26 22:33:32 2007 sys/FreeBSD/audio.cFri Sep 2 11:13:33 2016 @@ -90,7 +90,9 @@ S_PlaySound(char *soundfile) return (SOUND_DEVICE_ERROR); } @@ -11,19 +11,17 @@ $OpenBSD$ fstat(sfile, &sstat); len = sstat.st_size; -@@ -100,7 +102,11 @@ S_PlaySound(char *soundfile) +@@ -100,7 +102,9 @@ S_PlaySound(char *soundfile) if ( (l = read(sfile, buffer, len)) > 0) write(sdev, buffer, l); +#ifdef __FreeBSD__ ioctl(sdev, SNDCTL_DSP_SYNC, 0); -+#elif defined(__OpenBSD__) -+ioctl(sdev, AUDIO_DRAIN, 0); +#endif XtFree(buffer); close(sdev); -@@ -159,11 +165,17 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr) +@@ -159,11 +163,15 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr) return(SOUND_DEVICE_ERROR); } @@ -35,8 +33,6 @@ $OpenBSD$ +#ifdef __FreeBSD__ ioctl(sdev, SNDCTL_DSP_SYNC, 0); -+#elif defined(__OpenBSD__) -+ioctl(sdev, AUDIO_DRAIN, 0); +#endif close(sdev);
Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)
On Mon, Mar 23, 2015 at 07:42:02PM -0700, Constantine A. Murenin wrote: > On 23 March 2015 at 15:59, Stuart Henderson wrote: > > On 2015/03/23 10:14, Constantine A. Murenin wrote: > >> May I also ask why is it necessary to remove the timestamp information > >> from the tar archives themselves? > > > > To improve rsyncability. > > Could you elaborate? > > 0. Doesn't rsync ignore timestamps by default anyways? > > 1. Doesn't src/usr.sbin/pkg_add/OpenBSD/ArcCheck.pm#rev1.29 wipe out > the timestamps only directly from the tar archives, still leaving them > intact otherwise? > > C. Dude. Not having timestamps means that when files don't change, the archive chunk doesn't change. We do gzip them by chunks as well, so when a big package like texlive gets updated, a lot of time, most of the actual .tgz package file *doesn't change at all*. Put back timestamps in the tarball, and gzip will compress things differently, thus destroying rsyncability completely.
Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)
On 2015-03-24, Constantine A. Murenin wrote: > On 23 March 2015 at 15:59, Stuart Henderson wrote: >> On 2015/03/23 10:14, Constantine A. Murenin wrote: >>> May I also ask why is it necessary to remove the timestamp information >>> from the tar archives themselves? >> >> To improve rsyncability. > > Could you elaborate? > > 0. Doesn't rsync ignore timestamps by default anyways? > > 1. Doesn't src/usr.sbin/pkg_add/OpenBSD/ArcCheck.pm#rev1.29 wipe out > the timestamps only directly from the tar archives, still leaving them > intact otherwise? You're thinking of timestamps of the tgz here. This is about something else: file *contents*. Packages these days do some smart ordering of files (so that the transfer can be stopped before downloading everything, in the case of an update where binaries change but docs/data files stay the same), to reduce pkg_add time. They also restart the compression stream at various points (i.e new dictionary) to improve the chance of rsync finding common parts between package files. Avoiding timestamps in the tar removes one thing that might change between one build and the next. The packing list (+CONTENTS file) which has the real timestamps (and the signature etc) is in a different compression stream than the main files in the package. the main files.
Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)
On 23 March 2015 at 15:59, Stuart Henderson wrote: > On 2015/03/23 10:14, Constantine A. Murenin wrote: >> May I also ask why is it necessary to remove the timestamp information >> from the tar archives themselves? > > To improve rsyncability. Could you elaborate? 0. Doesn't rsync ignore timestamps by default anyways? 1. Doesn't src/usr.sbin/pkg_add/OpenBSD/ArcCheck.pm#rev1.29 wipe out the timestamps only directly from the tar archives, still leaving them intact otherwise? C.
Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)
On 2015/03/23 10:14, Constantine A. Murenin wrote: > May I also ask why is it necessary to remove the timestamp information > from the tar archives themselves? To improve rsyncability.
Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)
On 14 March 2015 at 02:28, Marc Espie wrote: > On Fri, Mar 13, 2015 at 01:13:39PM -0700, Constantine A. Murenin wrote: >> Hello, >> >> The commit below from 2014-09-16 must have broken the snapshot time >> detection on http://ports.su/ , which must have been broken since >> 2014-09-21. >> >> Is there a cross-platform way to best get it back from the package file? > Yes, parse the +CONTENTS file and restore the associated @ts. > > Any tool that reads files can do so easily. In perl, > perl -ne '$seen = 1 if m/sqlports-compact/; if ($seen == 1 && m/\@ts\s+(.*)/) > { system("date -r $1"); exit 0; }' /var/db/pkg/sqlports-compact-*/+CONTENTS > will retrieve and display the timestamp. May I also ask why is it necessary to remove the timestamp information from the tar archives themselves? I can think of at least one other scenario where the files from the package might be of interest without http://mdoc.su/o/pkg_add.1 -- harvesting the man-pages from the packages. Perhaps the change of deleting mtime from tar could be undone going forward? Especially since mtime already appears to be required as part of the header of the tar format, http://mdoc.su/f/tar.5, thus not even occupying any extra space at all, apart from the possible compression considerations. What do we gain by losing the ability to use the normal and interoperable UNIX tools to examine the archive files of the packages? > > Something similar can be easily cobbled using any kind of sed/awk/grep > > >> I guess the easiest way would be to fix the date with the snippet as >> follows; or is there a better way? >> >> %sh -c 'touch -d $(env TZ=GMT date -r $(stat -f"%m" +CONTENTS) >> +%FT%TZ) share/sqlports-compact' > > You assume sqlports-compacts should/can have the snapshots of +CONTENTS... > this is not quite true. Would any difference be material here? It seems that it's basically the same date, as far as estimating the time of the snapshot is concerned, which in reality is more of an undefined period of multiple hours anyways. Cheers, Constantine.
Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)
On Fri, Mar 13, 2015 at 01:13:39PM -0700, Constantine A. Murenin wrote: > Hello, > > The commit below from 2014-09-16 must have broken the snapshot time > detection on http://ports.su/ , which must have been broken since > 2014-09-21. > > Is there a cross-platform way to best get it back from the package file? Yes, parse the +CONTENTS file and restore the associated @ts. Any tool that reads files can do so easily. In perl, perl -ne '$seen = 1 if m/sqlports-compact/; if ($seen == 1 && m/\@ts\s+(.*)/) { system("date -r $1"); exit 0; }' /var/db/pkg/sqlports-compact-*/+CONTENTS will retrieve and display the timestamp. Something similar can be easily cobbled using any kind of sed/awk/grep > I guess the easiest way would be to fix the date with the snippet as > follows; or is there a better way? > > %sh -c 'touch -d $(env TZ=GMT date -r $(stat -f"%m" +CONTENTS) > +%FT%TZ) share/sqlports-compact' You assume sqlports-compacts should/can have the snapshots of +CONTENTS... this is not quite true.
timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)
Hello, The commit below from 2014-09-16 must have broken the snapshot time detection on http://ports.su/ , which must have been broken since 2014-09-21. Is there a cross-platform way to best get it back from the package file? I see that the timestamps are now embedded within "+CONTENTS", and both "+CONTENTS" and "+DESC" themselves have the correct timestamps, too, just not "share/sqlports-compact". >From the reversing as per below, it seems like there are 4 sources for two timestamps: 2014-09-18T08:47Z +DESC +CONTENTS /@ts 2014-09-18T12:17Z +CONTENTS +CONTENTS /signify: I guess the easiest way would be to fix the date with the snippet as follows; or is there a better way? %sh -c 'touch -d $(env TZ=GMT date -r $(stat -f"%m" +CONTENTS) +%FT%TZ) share/sqlports-compact' Cheers, Constantine. 538 Sep 15 12:29 2014-09-20/+CONTENTS 3936 Sep 14 07:49 2014-09-20/+DESC 36918272 Sep 14 07:49 2014-09-20/share/sqlports-compact 553 Sep 19 05:17 2014-09-21/+CONTENTS 3936 Sep 18 01:47 2014-09-21/+DESC 37057536 Dec 31 1969 2014-09-21/share/sqlports-compact --- 2014-09-20/+CONTENTSMon Sep 15 12:29:20 2014 +++ 2014-09-21/+CONTENTSFri Sep 19 05:17:22 2014 @@ -1,7 +1,7 @@ @comment $OpenBSD: PLIST-compact,v 1.2 2009/12/01 18:27:46 espie Exp $ @name sqlports-compact-4.2 @signer openbsd-56-pkg -@digital-signature signify:2014-09-15T19:29:20Z:RWSPEf7Vpp2j0NzTldW+gbzVKDKUDBNV8yr4qbGsLA1j4qi41qVwdNxzzy5+d4Z6ocIuxOXLGAZkL1rZzO9bIXt8vpm6ia6vxg8= +@digital-signature signify:2014-09-19T12:17:22Z:RWSPEf7Vpp2j0KKBEBZR4Q/ZNEDFC509xrP2LO6eVXgEzctauBidBAZl4/pMWVqfoG9JXABPiI+wlfZobwoZTxZikYLrX5HXRg0= @option always-update @comment pkgpath=databases/sqlports,-compact cdrom=yes ftp=yes @arch amd64 @@ -10,5 +10,6 @@ @size 3936 @cwd /usr/local share/sqlports-compact -@sha E+dRAH5CB2qQd2ZPSRUgGL4uUKYd9WiQDjWkt9lpkP8= -@size 36918272 +@sha QJrtFZ+Kp8m9as8c6iYSqUjytHlIvopDki/vTw7enlE= +@size 37057536 +@ts 1411030040 % cat 2014-09-21/+CONTENTS @comment $OpenBSD: PLIST-compact,v 1.2 2009/12/01 18:27:46 espie Exp $ @name sqlports-compact-4.2 @signer openbsd-56-pkg @digital-signature signify:2014-09-19T12:17:22Z:RWSPEf7Vpp2j0KKBEBZR4Q/ZNEDFC509xrP2LO6eVXgEzctauBidBAZl4/pMWVqfoG9JXABPiI+wlfZobwoZTxZikYLrX5HXRg0= @option always-update @comment pkgpath=databases/sqlports,-compact cdrom=yes ftp=yes @arch amd64 +DESC @sha NdJMzcyumfz+I9nbW0P/qfHc1CT7KcZcGIaCiolyRZo= @size 3936 @cwd /usr/local share/sqlports-compact @sha QJrtFZ+Kp8m9as8c6iYSqUjytHlIvopDki/vTw7enlE= @size 37057536 @ts 1411030040 % date -r 1411030040 Thu Sep 18 01:47:20 PDT 2014 % env TZ=GMT date -r 1411030040 Thu Sep 18 08:47:20 GMT 2014 % sh -c 'touch -d $(env TZ=GMT date -r $(stat -f"%m" +CONTENTS) +%FT%TZ) share/sqlports-compact' % stat share/sqlports-compact ... 37057536 "Sep 19 05:17:22 2014" "Sep 19 05:17:22 2014" "Mar 13 12:49:33 2015" 16384 72416 0 share/sqlports-compact On 16 September 2014 at 01:51, Marc Espie wrote: > CVSROOT:/cvs > Module name:src > Changes by: es...@cvs.openbsd.org 2014/09/16 02:51:38 > > Modified files: > usr.sbin/pkg_add/OpenBSD: ArcCheck.pm > > Log message: > if a @ts annotation is detected, wipe tarball timestamp. Archives will > look as if all files were born in 1970. The useful side-effect is that > meta-data for content-identical files WILL be identical as well. >
Re: syslogd replacements (was: Re: CVS: cvs.openbsd.org: src)
On 2014/07/14 07:56, Christian Weisgerber wrote: > On 2014-07-14, Theo de Raadt wrote: > > > CVSROOT:/cvs > > Module name:src > > Changes by: dera...@cvs.openbsd.org 2014/07/13 22:02:33 > > > > Modified files: > > usr.sbin/syslogd: syslogd.c > > > > Log message: > > Create a socketpair() and tie one end to /dev/klog using ioctl LIOCSFD. > > This allows us to receive messages direct from programs using the > > fd-safe sendsyslog(2), aka. syslog_r(3). Thanks to guenther for this part > > of the solution. > > ok beck tedu miod guenther > > Theo has reminded me that any syslogd replacements we may have in > ports, e.g. sysutils/rsyslog, will require a corresponding change > or they will NOT work as a drop-in replacement. > > Should we mark all candidates we can find as BROKEN to prevent > surprises? I think not. Since it's already very difficult to replace base syslogd with anything from ports (it loads before ldconfig is done), I think these are usually run as additional daemons binding to a different UDP port. Perhaps a warning in README might be warranted, I don't know.
Re: syslogd replacements (was: Re: CVS: cvs.openbsd.org: src)
> On 2014-07-14, Theo de Raadt wrote: > > > CVSROOT:/cvs > > Module name:src > > Changes by: dera...@cvs.openbsd.org 2014/07/13 22:02:33 > > > > Modified files: > > usr.sbin/syslogd: syslogd.c > > > > Log message: > > Create a socketpair() and tie one end to /dev/klog using ioctl LIOCSFD. > > This allows us to receive messages direct from programs using the > > fd-safe sendsyslog(2), aka. syslog_r(3). Thanks to guenther for this part > > of the solution. > > ok beck tedu miod guenther > > Theo has reminded me that any syslogd replacements we may have in > ports, e.g. sysutils/rsyslog, will require a corresponding change > or they will NOT work as a drop-in replacement. > > Should we mark all candidates we can find as BROKEN to prevent > surprises? They are only broken for syslog_r(3). syslog(3) still works. But that does kind of matter... The change to syslogd is fairly simple; it could be ported to others daemons. Based on an #ifdef on the ioctl name.
syslogd replacements (was: Re: CVS: cvs.openbsd.org: src)
On 2014-07-14, Theo de Raadt wrote: > CVSROOT: /cvs > Module name: src > Changes by: dera...@cvs.openbsd.org 2014/07/13 22:02:33 > > Modified files: > usr.sbin/syslogd: syslogd.c > > Log message: > Create a socketpair() and tie one end to /dev/klog using ioctl LIOCSFD. > This allows us to receive messages direct from programs using the > fd-safe sendsyslog(2), aka. syslog_r(3). Thanks to guenther for this part > of the solution. > ok beck tedu miod guenther Theo has reminded me that any syslogd replacements we may have in ports, e.g. sysutils/rsyslog, will require a corresponding change or they will NOT work as a drop-in replacement. Should we mark all candidates we can find as BROKEN to prevent surprises? -- Christian "naddy" Weisgerber na...@mips.inka.de
devel/py-openbsd broken [Re: CVS: cvs.openbsd.org: src]
On 2014/01/23 16:51, Henning Brauer wrote: > CVSROOT: /cvs > Module name: src > Changes by: henn...@cvs.openbsd.org 2014/01/23 16:51:29 > > Modified files: > sys/net: if_bridge.c pf.c > sys/netinet: ip_input.c ip_output.c ip_var.h tcp_input.c >tcp_var.h udp_usrreq.c udp_var.h > sys/netinet6 : ip6_output.c > > Log message: > since the cksum rewrite the counters for hardware checksummed packets > are are lie, since the software engine emulates hardware offloading > and that is later indistinguishable. so kill the hw cksummed counters. > introduce software checksummed packet counters instead. > tcp/udp handles ip & ipvshit, ip cksum covered, 6 has no ip layer cksum. > as before we still have a miscounting bug for inbound with pf on, to be > fixed in the next step. > found by, prodding & ok naddy > This breaks devel/py-openbsd. Looks like it hasn't been developed upstream recently anyway (https://github.com/cortesi/pyopenbsd), so I'm wondering if it's worth fixing or not. Does anyone actually use it?
Re: CVS: cvs.openbsd.org: src
Pascal Stumpf writes: > On Fri, 27 Dec 2013 10:41:30 -0700 (MST), Theo de Raadt wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: dera...@cvs.openbsd.org 2013/12/27 10:41:30 >> >> Modified files: >> etc/mtree : 4.4BSD.dist 4.4BSD.root >> >> Log message: >> /stand has not been used in decades >> ok miod >> >> > > That needs a small adaption in sysutils/memtest86+. I think just > putting the bootable files in / is ok. So do I, ok. > Index: Makefile > === > RCS file: /cvs/ports/sysutils/memtest86+/Makefile,v > retrieving revision 1.9 > diff -u -p -r1.9 Makefile > --- Makefile 11 Mar 2013 11:41:31 - 1.9 > +++ Makefile 27 Dec 2013 18:09:19 - > @@ -7,7 +7,7 @@ COMMENT= thorough, stand alone memory t > VERSION= 4.20 > DISTNAME=memtest86+-${VERSION} > CATEGORIES= sysutils > -REVISION=1 > +REVISION=2 > > HOMEPAGE=http://www.memtest.org/ > > Index: pkg/PLIST > === > RCS file: /cvs/ports/sysutils/memtest86+/pkg/PLIST,v > retrieving revision 1.2 > diff -u -p -r1.2 PLIST > --- pkg/PLIST 7 Nov 2010 18:29:54 - 1.2 > +++ pkg/PLIST 27 Dec 2013 18:09:19 - > @@ -4,9 +4,9 @@ share/doc/pkg-readmes/${FULLPKGNAME} > share/memtest86+/ > share/memtest86+/README > share/memtest86+/memtest > -@sample /stand/memtest > +@sample /memtest > share/memtest86+/memtest-serial > -@sample /stand/memtest-serial > +@sample /memtest-serial > share/memtest86+/memtest-serial.floppy > share/memtest86+/memtest-serial.iso > share/memtest86+/memtest.floppy > Index: pkg/README > === > RCS file: /cvs/ports/sysutils/memtest86+/pkg/README,v > retrieving revision 1.2 > diff -u -p -r1.2 README > --- pkg/README2 Jun 2011 13:41:41 - 1.2 > +++ pkg/README27 Dec 2013 18:09:19 - > @@ -7,7 +7,7 @@ $RuOBSD: README.OpenBSD,v 1.2 2009/02/07 > > Using Memtest86+ in OpenBSD environment > > -o Reboot the machine and boot Memtest86+ using `boot /stand/memtest' command > +o Reboot the machine and boot Memtest86+ using `boot memtest' command >at the `boot>' prompt. You can also boot Memtest86+ from network using >pxeboot(8). > > -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE (previous: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494)
Re: CVS: cvs.openbsd.org: src
On Fri, 27 Dec 2013 10:41:30 -0700 (MST), Theo de Raadt wrote: > CVSROOT: /cvs > Module name: src > Changes by: dera...@cvs.openbsd.org 2013/12/27 10:41:30 > > Modified files: > etc/mtree : 4.4BSD.dist 4.4BSD.root > > Log message: > /stand has not been used in decades > ok miod > > That needs a small adaption in sysutils/memtest86+. I think just putting the bootable files in / is ok. Index: Makefile === RCS file: /cvs/ports/sysutils/memtest86+/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- Makefile11 Mar 2013 11:41:31 - 1.9 +++ Makefile27 Dec 2013 18:09:19 - @@ -7,7 +7,7 @@ COMMENT=thorough, stand alone memory t VERSION= 4.20 DISTNAME= memtest86+-${VERSION} CATEGORIES=sysutils -REVISION= 1 +REVISION= 2 HOMEPAGE= http://www.memtest.org/ Index: pkg/PLIST === RCS file: /cvs/ports/sysutils/memtest86+/pkg/PLIST,v retrieving revision 1.2 diff -u -p -r1.2 PLIST --- pkg/PLIST 7 Nov 2010 18:29:54 - 1.2 +++ pkg/PLIST 27 Dec 2013 18:09:19 - @@ -4,9 +4,9 @@ share/doc/pkg-readmes/${FULLPKGNAME} share/memtest86+/ share/memtest86+/README share/memtest86+/memtest -@sample /stand/memtest +@sample /memtest share/memtest86+/memtest-serial -@sample /stand/memtest-serial +@sample /memtest-serial share/memtest86+/memtest-serial.floppy share/memtest86+/memtest-serial.iso share/memtest86+/memtest.floppy Index: pkg/README === RCS file: /cvs/ports/sysutils/memtest86+/pkg/README,v retrieving revision 1.2 diff -u -p -r1.2 README --- pkg/README 2 Jun 2011 13:41:41 - 1.2 +++ pkg/README 27 Dec 2013 18:09:19 - @@ -7,7 +7,7 @@ $RuOBSD: README.OpenBSD,v 1.2 2009/02/07 Using Memtest86+ in OpenBSD environment -o Reboot the machine and boot Memtest86+ using `boot /stand/memtest' command +o Reboot the machine and boot Memtest86+ using `boot memtest' command at the `boot>' prompt. You can also boot Memtest86+ from network using pxeboot(8).
Re: FHASLOCK -> FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)
On Fri, Jun 07, 2013 at 05:08:37PM +0200, Landry Breuil wrote: > Cant we whack lsof instead so that it doesnt try to reach non-public > includes in /sys ? Also, do you have an up2date src/sys ? I had (and still have) a diff back from 2010, but IIRC, pvalchev@ complained (and was right complaining). I'll try to find the mails from those days. Ciao, Kili
Re: FHASLOCK -> FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)
On 06/07/13 12:17, Philip Guenther wrote: On Fri, 7 Jun 2013, David Coppa wrote: This change broke sysutils/lsof. cc -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 -DHASMSDOSFS=1 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink -DHAS_DINODE_U -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL -DHAS_SYS_PIPEH -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME -DLSOF_VSTR=\"5.3\" -I/usr/include -I/sys -O2 -pipe -c dstore.c dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function) *** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (:87 'dstore.o') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 '/usr/ports/pobj/lsof-4.87/.build_done') *** Error 1 in /usr/ports/sysutils/lsof (/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build') Just delete the { (long)FHASLOCK, FF_HASLOCK }, line from dstore.c, or maybe wrap it in "#if defined(FHASHLOCK)" like FMARK and FDEFER are. Philip I just deleted it and lsof built. Something in kde4 (qt4, I believe) wants it, so now my "make package" of kde4 can continue. BTW, excellent timing with your fix... you sent it within *minutes* of my running into that problem. -- Scott McEachern https://www.blackstaff.ca "Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin
Re: FHASLOCK -> FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)
On Fri, 7 Jun 2013, David Coppa wrote: > This change broke sysutils/lsof. > > cc -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 > -DHASMSDOSFS=1 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink > -DHAS_DINODE_U -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL > -DHAS_SYS_PIPEH -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME > -DLSOF_VSTR=\"5.3\" -I/usr/include -I/sys -O2 -pipe -c dstore.c > dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function) > *** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (:87 > 'dstore.o') > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 > '/usr/ports/pobj/lsof-4.87/.build_done') > *** Error 1 in /usr/ports/sysutils/lsof > (/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build') Just delete the { (long)FHASLOCK, FF_HASLOCK }, line from dstore.c, or maybe wrap it in "#if defined(FHASHLOCK)" like FMARK and FDEFER are. Philip
Re: FHASLOCK -> FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)
On Fri, Jun 07, 2013 at 04:57:25PM +0200, David Coppa wrote: > On Tue, 04 Jun 2013, Philip Guenther wrote: > > > CVSROOT:/cvs > > Module name:src > > Changes by: guent...@cvs.openbsd.org2013/06/04 19:26:00 > > > > Modified files: > > sys/sys: fcntl.h file.h > > sys/kern : kern_descrip.c vfs_syscalls.c vfs_vnops.c > > usr.sbin/pstat : pstat.c > > > > Log message: > > Move FHASLOCK from f_flag to f_iflags, freeing up a bit for passing > > O_* flags and eliminating an XXX comment. > > > > ok matthew@ deraadt@ > > This change broke sysutils/lsof. > > cc -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 > -DHASMSDOSFS=1 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink > -DHAS_DINODE_U -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL > -DHAS_SYS_PIPEH -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME > -DLSOF_VSTR=\"5.3\" -I/usr/include -I/sys -O2 -pipe -c dstore.c > dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function) > *** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (:87 > 'dstore.o') > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 > '/usr/ports/pobj/lsof-4.87/.build_done') > *** Error 1 in /usr/ports/sysutils/lsof > (/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build') Cant we whack lsof instead so that it doesnt try to reach non-public includes in /sys ? Also, do you have an up2date src/sys ? Landry
FHASLOCK -> FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)
On Tue, 04 Jun 2013, Philip Guenther wrote: > CVSROOT: /cvs > Module name: src > Changes by: guent...@cvs.openbsd.org2013/06/04 19:26:00 > > Modified files: > sys/sys: fcntl.h file.h > sys/kern : kern_descrip.c vfs_syscalls.c vfs_vnops.c > usr.sbin/pstat : pstat.c > > Log message: > Move FHASLOCK from f_flag to f_iflags, freeing up a bit for passing > O_* flags and eliminating an XXX comment. > > ok matthew@ deraadt@ This change broke sysutils/lsof. cc -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 -DHASMSDOSFS=1 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink -DHAS_DINODE_U -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL -DHAS_SYS_PIPEH -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME -DLSOF_VSTR=\"5.3\" -I/usr/include -I/sys -O2 -pipe -c dstore.c dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function) *** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (:87 'dstore.o') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 '/usr/ports/pobj/lsof-4.87/.build_done') *** Error 1 in /usr/ports/sysutils/lsof (/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build') Ciao, David
Re: rm nawk (was: Re: CVS: cvs.openbsd.org: src)
On 2010/08/25 21:54, Christian Weisgerber wrote: > Theo de Raadt wrote: > > > CVSROOT:/cvs > > Module name:src > > Changes by: dera...@cvs.openbsd.org 2010/08/25 13:21:04 > > > > Modified files: > > usr.bin/awk: Makefile awk.1 > > > > Log message: > > get rid of the nawk hard link > > ok millert guenther > > People following -current should remove the nawk files from their > system... and pay attention to possible ports fallout. s/possible//. nawk is in our autoconf cache.
rm nawk (was: Re: CVS: cvs.openbsd.org: src)
Theo de Raadt wrote: > CVSROOT: /cvs > Module name: src > Changes by: dera...@cvs.openbsd.org 2010/08/25 13:21:04 > > Modified files: > usr.bin/awk: Makefile awk.1 > > Log message: > get rid of the nawk hard link > ok millert guenther People following -current should remove the nawk files from their system... and pay attention to possible ports fallout. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: erlang [Re: CVS: cvs.openbsd.org: src]
Jon Olsson [2006-03-22, 23:19:41]: > On Tue, Mar 21, 2006 at 07:45:54PM +0100, steven mestdagh wrote: > [snip] > > in the mean time Mark Kettenis has committed a new asm implementation > > for exp(3). anyway, erlang is still failing. it is trying to multiply > > 3.23E+133 by 3.57E+257 and hangs there. no exp(3) involved afaik. > > See: > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/erlang/patches/patch-ac?rev=1.3&content-type=text/x-cvsweb-markup > > and > > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/erlang/patches/patch-ad?rev=1.1&content-type=text/x-cvsweb-markup > > For possible workaronds. I have no amd64 system, so I can't test this. yep, that works, thanks. does not build yet, configure is creating x86_64- directories, but then it wants to use amd64-. ===> Building for erlang-10B_9 cd erts/emulator && ERL_TOP=/home/smestdag/objports/erlang-10B_9/otp_src_R10B-9 gmake generate depend gmake[1]: Entering directory `/home/smestdag/objports/erlang-10B_9/otp_src_R10B-9/erts/emulator' gmake -f amd64-unknown-openbsd3.9/Makefile generate gmake[2]: Entering directory `/home/smestdag/objports/erlang-10B_9/otp_src_R10B-9/erts/emulator' gmake[2]: amd64-unknown-openbsd3.9/Makefile: No such file or directory gmake[2]: *** No rule to make target `amd64-unknown-openbsd3.9/Makefile'. Stop. let me know if you need a build log, or config.log. for the update, it would be good if you could do something about the directories with versions. as nikolay suggested, remove the versions, or failing that, you could put them in variables and use SUBST_VARS or such. steven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: erlang [Re: CVS: cvs.openbsd.org: src]
On Tue, Mar 21, 2006 at 07:45:54PM +0100, steven mestdagh wrote: [snip] > in the mean time Mark Kettenis has committed a new asm implementation > for exp(3). anyway, erlang is still failing. it is trying to multiply > 3.23E+133 by 3.57E+257 and hangs there. no exp(3) involved afaik. See: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/erlang/patches/patch-ac?rev=1.3&content-type=text/x-cvsweb-markup and http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/erlang/patches/patch-ad?rev=1.1&content-type=text/x-cvsweb-markup For possible workaronds. I have no amd64 system, so I can't test this. -- Jon
erlang [Re: CVS: cvs.openbsd.org: src]
Hannah Schroeter [2006-03-21, 19:18:32]: > Hello! > > Could this (and the following commit) affect/fix the problem with > erlang's configure stuff on amd64? Alas, I can't test that myself, > because I don't have any amd64 box at my hands. > > Kind regards, > > Hannah. > > - Forwarded message from Otto Moerbeek <[EMAIL PROTECTED]> - > > From: Otto Moerbeek <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Tue, 14 Mar 2006 12:27:57 -0700 (MST) > Subject: CVS: cvs.openbsd.org: src > > CVSROOT: /cvs > Module name: src > Changes by: [EMAIL PROTECTED] 2006/03/14 12:27:57 > > Modified files: > lib/libm : Makefile > Removed files: > lib/libm/arch/amd64: e_exp.S > > Log message: > amd64 asm code is not correct for exp(+/-Inf), so until somebody > comes up with a correct asm version, use the C version of exp(3). > ok steven@ kettenis@ > > > - End forwarded message - in the mean time Mark Kettenis has committed a new asm implementation for exp(3). anyway, erlang is still failing. it is trying to multiply 3.23E+133 by 3.57E+257 and hangs there. no exp(3) involved afaik. steven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: CVS: cvs.openbsd.org: src
Hello! Could this (and the following commit) affect/fix the problem with erlang's configure stuff on amd64? Alas, I can't test that myself, because I don't have any amd64 box at my hands. Kind regards, Hannah. - Forwarded message from Otto Moerbeek <[EMAIL PROTECTED]> - From: Otto Moerbeek <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Tue, 14 Mar 2006 12:27:57 -0700 (MST) Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: [EMAIL PROTECTED] 2006/03/14 12:27:57 Modified files: lib/libm : Makefile Removed files: lib/libm/arch/amd64: e_exp.S Log message: amd64 asm code is not correct for exp(+/-Inf), so until somebody comes up with a correct asm version, use the C version of exp(3). ok steven@ kettenis@ - End forwarded message -