Re: ffmpeg6 and SSP?

[Tobias Nygren]

On Tue, 14 Nov 2023 11:30:27 +
Patrick Welche  wrote:

> Userland was built with MKUPDATE=yes - maybe I didn't rebuild whichever
> library should contain the extern definition of __ssp_protected_read ?

Same problem with a clean userland build. I'll also note it doesn't
work to override _FORTIFY_SOURCE with CFLAGS in pkgsrc, because SSP is
enforced through wrappers. Minimal reproducer:

#define _FORTIFY_SOURCE 2
#include 
ssize_t (*myread)(int d, void *buf, size_t nbytes);
int main(void) {
char c;
myread = 
return myread(STDIN_FILENO, , sizeof(c));
}

Re: Can't cross-build on macOS: clock.h

[Tobias Nygren]

On Fri, 27 Oct 2023 08:03:48 +0200
Adam  wrote:

> Greetings,
> 
> This change:
> 
> --- clock.h 26 Oct 2023 00:59:16 - 1.5
> +++ clock.h 26 Oct 2023 14:04:45 - 1.6
> @@ -1,4 +1,4 @@
> -/* $NetBSD: clock.h,v 1.5 2023/10/26 00:59:16 jschauma Exp $ */
> +/* $NetBSD: clock.h,v 1.6 2023/10/26 14:04:45 jschauma Exp $ */
>/*-
>   * Copyright (c) 1996 The NetBSD Foundation, Inc.
> @@ -32,9 +32,7 @@
>  #ifndef _SYS_CLOCK_H_
>  #define _SYS_CLOCK_H_
>   -#if !defined(_KERNEL) && !defined(_STANDALONE)
> -#include 
> -#endif
> +#include 
>/* Some handy constants. */
>  #define SECS_PER_MINUTE 60
> 
> 
> breaks building current on macOS, because stdint.h is in usr/include, and not 
> in usr/include/sys.
> 
> 
> dependall ===> tools/makefs
> In file included from /dist/src/sys/dev/clock_subr.c:64:
> /dist/src/sys/dev/../sys/clock.h:35:10: fatal error: 'sys/stdint.h' file not 
> found
> #include 
>  ^~
> 1 error generated.
> 
> 
> I don't know how to fix this properly. Probably #if defined(__NetBSD__). 
> Please, advise.

The header being used from the tools build was an unexpected surprise
but such reasons are why those ifdef guards exist. So I think it
just just be put back the way it was. The example came from
sys/atomic.h so it shouldn't be controversial.

Re: prctl(2) of compat_linux for Firefox for Linux/x86_64

[Tobias Nygren]

On Tue, 22 Aug 2023 04:56:18 +0900
Ryo ONODERA  wrote:

> Hi,
> 
> The recent improvements in compat_linux reduces unimplemented
> Linux system calls that is used by the official Firefox binary
> for Linux/x86_64.
> Great thanks for Theodore Preduta and their great works.
> 
> Sadly, the official Firefox 117.0b9 binary for Linux/x86_64 does not
> start its GUI yet.
> From the result of ktrace command, the following calls remain unimplemented.
> 
>  22518  12874 firefox-bin CALL  #157 (unimplemented prctl)
>  22518  12874 firefox-bin RET   #157 (unimplemented prctl) -1 errno -38 Too 
> many processes
> 
> I have no idea whether prctl(2) is the last unimplemented system call.
> So I may find another unimplemented during starting process of GUI.
> 
> Is there any plan to implement prctl(2) for compat_linux?

It looks like a kitchen sink syscall that provides all sorts
of functionality. Implementing full emulation would be very difficult.
Partial support for some of the options looks doable.

grep through the Firefox source code found these uses:

PR_SET_NAME - this is straightforward to emulate
PR_SET_VMA - this can be made a no-op

These are difficult because they depend on the kernel security model,
but it should be OK to just return EINVAL for both.

PR_SET_SECCOMP
PR_SET_NO_NEW_PRIVS

-Tobias

Re: clang-built NetBSD and rust

[Tobias Nygren]

On Mon, 27 Mar 2023 14:18:30 +0200 (CEST)
Havard Eidnes  wrote:

> a user contacted me about having a freshly installed version of
> NetBSD-current for amd64 built with clang, and a failure to run
> the provided "bootstrap kit" for rust, with the following error:
> 
> /usr/lib/libgcc_s.so.1: version GCC_3.3 required by 
> /tmp/pkgsrc/wip/rust/work/rust-bootstrap/bin/cargo not found

NetBSD from HEAD-llvm does not ship with libgcc_s.so.1, so one has to
manually provide it in order to run foreign binaries built with GCC.
Where did the user get libgcc_s.so.1 from?
I have rust-1.66.1 (not the latest) on my HEAD-llvm amd64 system.
Base is 9.99.107 (again not the latest) and libgcc_so.so.1 is from
9.99.99. So if this broke it did so fairly recently.

> So ... what should I/we do about this?  Do we need a separate rust
> bootstrap kit built with clang and built with a clang-built "target
> root"?  It looks like there's no netbsd-9 nor netbsd-10 built with
> clang, only HEAD?

Until clang ships as part of a formal release (with NetBSD release
binaries) I think it is OK to require users to manually provide
libgcc_s.so.1.

Re: error installing libiconv-1.17

[Tobias Nygren]

On Mon, 27 Mar 2023 10:03:18 +
Riccardo Mottola  wrote:

> I am trying to upgrade current pkgsrc packages on current.
> 
> Any ideas?

> -Wl,-rpath,/usr/pkg/lib
> ld: cannot find -liconv: No such file or directory
> *** Error code 1

PR pkg/57222.
One way to work around the problem without having to
resort to pkg_delete -f is:

libiconv# mv /usr/pkg/lib/libiconv.so* /root
libiconv# make clean replace

ECONNREFUSED no longer works

[Tobias Nygren]

Hi,

Could this be fallout from recent network changes?

$ nc -n -v 127.0.0.1 1234
# hangs forever in connect(2) instead of exiting w/ connection refused.

Kind regards,
-Tobias

Re: i915 observations

[Tobias Nygren]

> I also wouldn?t call the keyboard input delayed. I would say
> that visual effects of keyboard input usually were delayed due
> to the fact that they tend to require just a small part of the
> screen updated. This is most visible when logging in with xdm.
>
> Once logged in, I have a clock displayed, which enforces an update
> every second, which also updates some of the remaining dashes.
> Eventu?lly, the image tends to converge to the intended one (except
> maybe for the clock itself, which tends to lag behind all the time).

I believe the effect you see is framebuffer contents written to
the CPU cache but not flushed out to memory. This is why the artefacts
lazily repair themselves when background jobs that cause frequent cache
line misses are run. (Note how the artefacts are always 1 pixel high,
64-bytes wide and seemingly randomly positioned.)

Re: Threaded version of TOOL_XZ ?

[Tobias Nygren]

On Tue, 19 Apr 2022 10:18:20 -0700 (PDT)
Paul Goyette  wrote:

> Using TOOL_XZ instead of TOOL_GZ satisfies requirement #1, and use of
> (unsupported) TOOL_PIGZ satisfies #2, but neither option can meet
> both.  TOOL_XZ is explicitly built without thread support, and simply
> modifying its Makefile to enable_threads=yes doesn't build.

This patch does more or less what you want. But doing it this way means
NetBSD can no longer be cross-compiled from a host without pthreads.
Not sure if we care about this anymore or if we need to hide this
behind a toggle. You also need to hook "-T 0" into xz args for sets.

# set cpu on fire
/work/tools/bin/nbxz -T 0 -9c < /dev/zero > /dev/null

Index: external/public-domain/xz/bin/xz/Makefile
===
RCS file: /cvsroot/src/external/public-domain/xz/bin/xz/Makefile,v
retrieving revision 1.6
diff -p -u -r1.6 Makefile
--- external/public-domain/xz/bin/xz/Makefile   12 Apr 2021 02:54:08 -  
1.6
+++ external/public-domain/xz/bin/xz/Makefile   19 Apr 2022 18:03:58 -
@@ -44,7 +44,7 @@ FILESNAME_${XZSRCDIR}/po/${lang}.gmo= xz
 .if defined(HOSTPROG)
 HOST_CPPFLAGS+=${CPPFLAGS:N-Wp,-iremap,*}
 XZLIBDIR!= cd ${NETBSDSRCDIR}/tools/xz-lib && ${PRINTOBJDIR}
-LDADD+=-L${XZLIBDIR} -llzma
+LDADD+=-L${XZLIBDIR} -llzma -lpthread
 DPADD+=${XZLIBDIR}/liblzma.a
 .else
 DPADD+=${LIBLZMA} ${LIBINTL} ${LIBPTHREAD}
Index: external/public-domain/xz/lib/Makefile
===
RCS file: /cvsroot/src/external/public-domain/xz/lib/Makefile,v
retrieving revision 1.10
diff -p -u -r1.10 Makefile
--- external/public-domain/xz/lib/Makefile  25 Sep 2018 05:42:08 -  
1.10
+++ external/public-domain/xz/lib/Makefile  19 Apr 2022 18:03:58 -
@@ -57,9 +57,7 @@ SRCS+=common.c block_util.c easy_preset
index_decoder.c index_hash.c stream_buffer_decoder.c \
stream_decoder.c stream_flags_decoder.c vli_decoder.c
 
-.if !defined(HOSTLIB)
 SRCS+=  stream_encoder_mt.c
-.endif
 
 .PATH: ${XZSRCDIR}/src/liblzma/delta
 SRCS+= delta_common.c delta_encoder.c delta_decoder.c
Index: tools/xz-include/Makefile
===
RCS file: /cvsroot/src/tools/xz-include/Makefile,v
retrieving revision 1.4
diff -p -u -r1.4 Makefile
--- tools/xz-include/Makefile   18 Sep 2021 01:47:11 -  1.4
+++ tools/xz-include/Makefile   19 Apr 2022 18:03:59 -
@@ -8,7 +8,7 @@
 #
 .include "Makefile.inc"
 
-CONFIGURE_ARGS+=   --enable-threads=no --disable-nls
+CONFIGURE_ARGS+=   --enable-threads=posix --disable-nls
 .if ${MAKEVERBOSE} == 0
 CONFIGURE_ARGS+=   --silent
 .endif

Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE

[Tobias Nygren]

On Sat, 16 Apr 2022 16:51:31 +0200
Thomas Klausner  wrote:

> panic: kernel diagnostic assertion "VOP_ISLOCKED(vp) == LK_EXCLUSIVE" failed: 
> file "/usr/src/sys/miscfs/specfs/spec_vnops.c", line 1555
> cpu1: Begin traceback...
> vpanic()
> kern_assert()
> spec_close() at netbsd:spec_close+0x2fc
> VOP_CLOE() at netbsd:vop_close+0x42
> sequenceropen() at netbsd:sequenceropen+0x359

"cat /dev/sequencer" as a regular user is enough to trigger this. In
the midiseq_open() error path it is trying to VOP_CLOSE without the
vnode lock held. Maybe this patch helps. (Someone with filesystem
clue please sanity check this.)

--- sys/dev/sequencer.c 31 Mar 2022 19:30:15 -  1.76
+++ sys/dev/sequencer.c 16 Apr 2022 15:23:54 -
@@ -1452,8 +1452,9 @@ midiseq_open(int unit, int flags)
if ((mi.props & MIDI_PROP_CAN_INPUT) == 0)
flags &= ~FREAD;
if ((flags & (FREAD|FWRITE)) == 0) {
+   vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
VOP_CLOSE(vp, oflags, kauth_cred_get());
-   vrele(vp);
+   vput(vp);
return NULL;
}

Re: well-supported card for new DRM?

[Tobias Nygren]

On Fri, 31 Dec 2021 15:34:35 +0100
Thomas Klausner  wrote:

> Any suggestions how I can force the xserver in 3840x2160 mode?

> NOUVEAU(0): Printing DDC gathered Modelines:
> NOUVEAU(0): Modeline "3840x2160"x0.0  533.25  3840 3888 3920 4000  2160 2163 
> 2168  +hsync -vsync (133.3 kHz eP)

>  NOUVEAU(0): HDMI max TMDS frequency 30KHz

Maybe the 4k mode is rejected due to too high pixel clock.
4k@60 should work on the DisplayPort if you have one of
those cables.

-Tobias

Re: Orange pi support for i2c

[Tobias Nygren]

On Sat, 07 Aug 2021 21:54:40 +
Dave Tyson  wrote:

> The Banana pi seems to work OK with i2c with light testing, but I would 
> really 
> like a more 'lightweight' platform like the Orange pi zero or Orange pi one. 
> Under a recent current both these boot up OK, but there doesn't appear to be 
> any support for i2c - how hard would that be to add?

Already supported -- but you need to enable the i2c nodes in the device tree
with a dtb overlay. It will be something like below. You'll have to consult
the data sheet to see if any of the respective i2c controller's pins are used
for conflicting purposes.

--- sys/arch/arm/dts/sun8i-h3-orangepi-one.dts  30 Nov 2017 21:39:35 -  
1.3
+++ sys/arch/arm/dts/sun8i-h3-orangepi-one.dts  7 Aug 2021 21:47:46 -
@@ -29,3 +29,12 @@
 #include 
"../../../external/gpl2/dts/dist/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts"
 #include "sun8i-h3.dtsi"

+ {
+status = "okay";
+};
+ {
+status = "okay";
+};
+ {
+status = "okay";
+};

Re: Best practice for setting up disks for ZFS on NetBSD

[Tobias Nygren]

On Thu, 3 Dec 2020 00:30:17 +
David Brownlee  wrote:

> In the event of disk renumbering both are thrown out, needing a "zfs
> export foo;zfs import foo" to recover. Is there some way to avoid
> that?

You can use named gpt wedges and symlink them to a stable path in /dev.
I did this manually for my storage box setup but was later informed we
have devpubd(8) which is capable of doing this.

Re: [HEADS UP] pkgsrc default database directory changed

[Tobias Nygren]

On Wed, 2 Dec 2020 11:28:41 +0100
Thomas Klausner  wrote:

> The new default for the pkgsrc database (which contains information
> about all installed packages) in pkgsrc-HEAD has changed from
> /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).

Since this is about changing a default, it should be mentioned in the
heads-up how to stay on the old path if migration is currently not
convenient. To do this one can add PKG_DBDIR=/var/db/pkg to mk.conf
before the new pkg_install is built.

-Tobias

Re: build-success/install-fault on i486 with xsrc

[Tobias Nygren]

On Tue, 27 Oct 2020 22:57:28 +0100
Miranda van den Breukelingen  wrote:

> libGL.so.3 text relocations
> libGL.so3 cannot write enable text sements: permission deniend

Is base mesa not built with GLX_X86_READONLY_TEXT on i386? I suspect
i386 users are few and far apart these days. You may need to dig into
the source and patch things. Alternatively try pkgsrc's Xorg with
X11_TYPE=modular. I think we enable that option there for i386.

Kind regards,
-Tobias

Re: mesalib abort

[Tobias Nygren]

On Thu, 17 Sep 2020 12:04:10 +0100
Patrick Welche  wrote:

> When running glmark2 with native xsrc on -current/amd64, I get
> 
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7f7ff5844a2a in _sys___sigprocmask14 () from /usr/lib/libc.so.12
> (gdb) bt
> #0  0x7f7ff5844a2a in _sys___sigprocmask14 () from /usr/lib/libc.so.12
> #1  0x7f7ff160a461 in pthread_sigmask (how=, 
> set=, oset=)
> at /usr/src/lib/libpthread/pthread_misc.c:164
> #2  0x7f7fed75fec3 in u_thread_create (
> routine=0x7f7fed75ff06 , param=0x7f7ff7e9f220)
> at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_thread.h:50
> #3  util_queue_create_thread (queue=queue@entry=0x7f7ff7e8b900, 
> index=index@entry=0)
> at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_queue.c:350
> #4  0x7f7fed7604ad in util_queue_init (queue=queue@entry=0x7f7ff7e8b900, 
> name=name@entry=0x7f7fef727c8b "disk$", max_jobs=max_jobs@entry=32, 
> num_threads=num_threads@entry=1, flags=flags@entry=7)
> at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_queue.c:466
> ...
> 
> /usr/xsrc/external/mit/MesaLib/dist/src/util/u_thread.h:50:
> 41 thrd_t thread;
> 42  #ifdef HAVE_PTHREAD
> 43 sigset_t saved_set, new_set;
> 44 int ret;
> 45  
> 46 sigfillset(_set);
> 47 sigdelset(_set, SIGSYS);
> 48 pthread_sigmask(SIG_BLOCK, _set, _set);
> 49 ret = thrd_create( , routine, param );
> 50 pthread_sigmask(SIG_SETMASK, _set, NULL);
> 51  #else
> 52 int ret;
> 53 ret = thrd_create( , routine, param );
> 54  #endif
> 55 if (ret)
> 56return 0;
> 57  
> 58 return thread;
> 
> 
> It looks as though line 50 simply undoes line 48, and it doesn't matter
> whether or not line 49 fails. How can this break?

This is a red herring. Because they mask the SIGSEGV/SIGBUS handlers
you are not getting the actual fault location which happens inside
thrd_create. Instead the process takes the fault when the signal mask
is restored. This code is severly broken and upstream should fix it.
Anyway, If you comment out the signal masking crap you will get a
proper backtrace.

-Tobias

Re: Possible rust issue on -current

[Tobias Nygren]

On Thu, 20 Aug 2020 05:04:37 +0200
Tobias Nygren  wrote:

> This doesn't sound like a rust problem but rather some crate is trying
> to do something nonportable while attempting to fix a portability
> issue. If it is really important to detect at run time if some code
> runs on the main thread (doubtful) you should patch the code to mark
> the main thread as such on startup with one of the available portable
> thread local storage APIs. Alternatively you can patch out the entire
> check from the offending create with a pkgsrc patch if you know for
> sure it's initialization is running on the main thread.

The upstream project created a tentative fix for this issue already.

https://github.com/rust-windowing/winit/pull/1664/commits/b1a90fd5c52ac2aff45558ff932a61892859859e

I added it to wip. The package seems to works fine for me now.
Shows a terminal window.

-Tobias

Re: Possible rust issue on -current

[Tobias Nygren]

On Wed, 19 Aug 2020 22:14:09 +0100
Chavdar Ivanov  wrote:

Hello,

> pkgsrc/wip/alacritty builds fine under -current, only two warnings for
> obsolete constructs. Apart from the issue of not  getting right the
> shared library locations and the need to run it with LD_LIBRARY_PATH,
> one gets on start:

I've fixed this problem in the alacritty package.

> Thread 'main' panicked at 'Initializing the event loop outside of the
> main thread is a significant cross-platform compatibility hazard.
> The suggestion on https://github.com/alacritty/alacritty/issues/2631
> was that for some reason under NetBSD the detection of whether one is
> on a main thread is incorrect. I wonder if there is anything similar
> seen elsewhere.

This doesn't sound like a rust problem but rather some crate is trying
to do something nonportable while attempting to fix a portability
issue. If it is really important to detect at run time if some code
runs on the main thread (doubtful) you should patch the code to mark
the main thread as such on startup with one of the available portable
thread local storage APIs. Alternatively you can patch out the entire
check from the offending create with a pkgsrc patch if you know for
sure it's initialization is running on the main thread.

-Tobias

Re: System panicing on boot since recent uvm changes

[Tobias Nygren]

On Sun, 16 Aug 2020 19:35:47 +0300
Andreas Gustafsson  wrote:

> Tobias Nygren wrote:
> > Seems there is still something wrong with -current.
> > ./build.sh -j8 hangs in <10 seconds on a t3.2xlarge EC2 instance.
> > Reverting to a -D20200812 kernel makes it stable.
> 
> FWIW, I successfully completed a "build.sh -j 24 release" of 9.0
> hosted on a -current built from source date 2020.08.16.00.24.41,
> running on real amd64 hardware.

I've tried to bisect the problem and it is not related to the UVM
changes. I now think it is a local problem. Maybe toolchain is broken.
Will clean and try again.

Re: System panicing on boot since recent uvm changes

[Tobias Nygren]

On Sun, 16 Aug 2020 13:58:46 +0200
Tobias Nygren  wrote:

> Seems there is still something wrong with -current.
> ./build.sh -j8 hangs in <10 seconds on a t3.2xlarge EC2 instance.
> Reverting to a -D20200812 kernel makes it stable.

This is a known clean filesystem that was just fsck'ed:

panic: /work: bad dir ino 12 at offset 208: NUL in name [name.d] i=6, namlen=10
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x152
panic() at netbsd:panic+0x3c
ufs_lookup() at netbsd:ufs_lookup+0x5ab
VOP_LOOKUP() at netbsd:VOP_LOOKUP+0x42
lookup_once() at netbsd:lookup_once+0x1ac
namei_tryemulroot() at netbsd:namei_tryemulroot+0xb44
namei() at netbsd:namei+0x29
vn_open() at netbsd:vn_open+0x9c
do_open() at netbsd:do_open+0x124
do_sys_openat() at netbsd:do_sys_openat+0x72
sys_open() at netbsd:sys_open+0x24
syscall() at netbsd:syscall+0x275

Reproducable by fsck, reboot, mount and build.sh. fs corruption is a
bit concerning. People should probably hold off on updating for now.

Re: System panicing on boot since recent uvm changes

[Tobias Nygren]

On Sun, 16 Aug 2020 12:36:21 +0300
Andreas Gustafsson  wrote:

> Chuck Silvers wrote:
> > this should be fixed now.
> > sorry about that, the problem did not happen for me and
> > it took me forever to find a way that I could reproduce it.
> 
> This is not to pick on you specifically as almost everyone is doing
> the same thing, but IMO, in cases like this it would generally be
> better to revert the commit immediately and later re-commit a correct
> version rather than leaving things broken during the entire process of
> reproducing and fixing the issue.

Seems there is still something wrong with -current.
./build.sh -j8 hangs in <10 seconds on a t3.2xlarge EC2 instance.
Reverting to a -D20200812 kernel makes it stable.

Re: openjdk11 and tomcat

[Tobias Nygren]

On Tue, 30 Jun 2020 15:17:52 +0100
David Brownlee  wrote:

> Can anyone run a listening webserver under openjdk11 (eg:
> apache-tomcat, wildfly)?
> 
> Whenever I try it never seems to handle any connections, but
> everything works under openjdk8.
> 
> Its easy to test with packages from pkgsrc:
> Install openjdk8 openjdk11 apache-tomcat9
> 
> # env JRE_HOME=/usr/pkg/java/openjdk8 /etc/rc.d/tomcat onestart
> # ftp -o - http://localhost:8080/
> (happy output)
> 
> # /etc/rc.d/tomcat onestop
> 
> # env JRE_HOME=/usr/pkg/java/openjdk11 /etc/rc.d/tomcat onestart
> # ftp -o - http://localhost:8080/
> Trying 127.0.0.1:8080 ...
> Requesting http://localhost:8080/
> (some time passes)
> ftp: Receiving HTTP reply: EOF received
> 
> This is amd64 under netbsd-9, and netbsd-9 binaries running under a
> current kernel.

There something wrong with non-blocking I/O (possibly kqueue
related). You don't need to debug it with tomcat, it can be reproduced
by running jtreg on the openjdk test suite. There are also some other
test cases that fail on NetBSD that need to be analyzed and fixed.

Re: static linking glxgears and glxinfo now fails (mult. def. _glapi_tls_Context, etc.)

[Tobias Nygren]

On Tue, 02 Jun 2020 18:23:21 -0700
"Greg A. Woods"  wrote:

> Fixes dlopen of libGL reported by prlw1 on current users.
> From tnn, via pkgsrc/graphics/MesaLib*.
> 
> 
> 
> I'm guessing I just want to avoid GLX_USE_TLS for the static libraries
> for now, though I'm guessing also that a proper fix to allow use of TLS
> in the static-linked case would still be desirable?  Or does this only
> matter for loadable drivers, which cannot be in the static-linked world?

I'm not sureu_current.o should even be included in libglapi.
These symbols aren't present in pkgsrc's libglapi.so.
Maybe this patch helps? (I don't know if it will break anything else.)

--- external/mit/xorg/lib/libglapi/Makefile 23 Feb 2020 02:02:32 -  
1.7
+++ external/mit/xorg/lib/libglapi/Makefile 3 Jun 2020 07:18:44 -
@@ -15,7 +15,6 @@ SRCS.mapi=\
shared_entry.c \
stub.c \
table.c \
-   u_current.c \
u_execmem.c

 BUILDSYMLINKS+=${X11SRCDIR.Mesa}/src/mapi/entry.c shared_entry.c

dhcpd broken on -current (Re: CVS commit: src/external/mpl/dhcp)

[Tobias Nygren]

Hi,

On Sun, 24 May 2020 15:50:13 -0400
Christos Zoulas  wrote:

> Modified Files:
>   src/external/mpl/dhcp: Makefile.inc
>   src/external/mpl/dhcp/dist/omapip: isclib.c
> 
> Log Message:
> Adjust for bind-9.16.3

After the bind update I found my dhcpd is no longer giving out
leases and it again started exhibiting the old problem where
"/etc/rc.d/dhcpd stop" hangs. Probably there is a libisc
incompatibility again?

-Tobias

Re: build failure when optimizing

[Tobias Nygren]

On Tue, 26 May 2020 23:01:36 +0200
os...@fessel.org wrote:

> Hej again,
> 
> > Am 24.05.2020 um 01:06 schrieb Tobias Nygren :
> > 
> > On Sat, 23 May 2020 22:25:55 +0200
> > os...@fessel.org wrote:
> > 
> >> I just tried to build release with optimisation for my little xeon server.
> >> That fails, but I don?t understand why it seems to build some 386 32bit 
> >> libs.
> > 
> > You can build with MKCOMPAT=no to avoid this problem if you don't need
> > 32-bit compatibility libs.
> 
> Thanks again, MKCOMPAT really is case-sensitive, so no is better than NO, but 
> nevertheless, im still not getting through the build process:
> 
> ?schnipp?
> 
> #   compile  ld.elf_so/mdreloc.o
> /hurz/obj/tooldir.NetBSD-9.99.63-amd64/bin/x86_64--netbsd-gcc -O2
> -mfpmath=sse -msse3 -march=native  -fvisibility=hidden -O3 
> -fomit-frame-pointer -mno-3dnow -mno-mmx -mno-sse -mno-sse2
> -mno-sse3 -fstack-protector -Wstack-protector   --param ssp-buffer-size=1
> -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
> -Wno-sign-compare  -Wsystem-header
> s   -Wno-traditional   -Wa,--fatal-warnings  -Wreturn-type -Wswitch -Wshadow 
> -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare 
> -Wsign-compare -Wformat=2  -Wno-for
> mat-zero-length  -Werror --sysroot=/hurz/obj/destdir.NetBSD-9.99.64-amd64 
> -fPIC -DELFSIZE=64 -DRTLD_COMMON_CALL_IFUNC_RELA -DLIBDIR=\"/usr/lib\" 
> -D_PATH_RTLD=\"/libexec/ld.elf_so\" -I/
> hurz/src/libexec/ld.elf_so -I. -D_KERNTYPES -DRTLD_LOADER -DGNU_RELRO 
> -D_RTLD_SOURCE -DHAVE_INITFINI_ARRAY  -D_FORTIFY_SOURCE=2 -c
> /hurz/src/libexec/ld.elf_so/arch/x86_64/mdreloc.c
> cc1: error: SSE instruction set disabled, using 387 arithmetics [-Werror]
> cc1: all warnings being treated as errors
> 
> *** Failed target:  mdreloc.o
> ?schnapp?
> 
> how comes?  And what can I do?

There is an -mno-sse2 flag on the command line and it conflicts with
your -mfpmath=sse flag. This COPTS setting comes from
src/libexec/ld.elf_so/Makefile. You can remove the flag but expect
random breakage, it is there for a reason. Probably the easiest fix is
to add something like CFLAGS:=${CFLAGS:N-msse*:N-mfpmath=sse} at the
bottom on the Makefile to undo your settings for this file only.

Re: build failure when optimizing

[Tobias Nygren]

On Sat, 23 May 2020 22:25:55 +0200
os...@fessel.org wrote:

> I just tried to build release with optimisation for my little xeon server.
> That fails, but I don?t understand why it seems to build some 386 32bit libs.

You can build with MKCOMPAT=no to avoid this problem if you don't need
32-bit compatibility libs.

-Tobias

Re: crashes with current on amd64

[Tobias Nygren]

On Wed, 1 Apr 2020 12:32:46 +0200
Riccardo Mottola  wrote:

> pmap_remove_all() at pmap_remove_all+0x311
> uvmspace_free() at uvmspace_free+0x3f
> exit1() at exit1+0x1b8

This one is fixed already, you should update to 9.99.52.

-Tobias

Re: pmap panic

[Tobias Nygren]

On Tue, 17 Mar 2020 23:36:23 +
Andrew Doran  wrote:

> Ok.  I think the problems here should be fixed.
> 
> Andrew

Hi,

I confirm my bare metal desktop system is stable now. It does feel
much snappier than before so the pain was worth it in the end. :)

On my VirtualBox machine I have a feeling that it is spending more time
doing TLB shootdowns than before on /some/ workloads. Running cvs update
on a cgd(4) is definitely slower than before. Randomly breaking into
ddb shows that it's always spinning in pmap_tlb_shootnow() rather than
waiting for disk or net I/O which I would expect. I couldn't reproduce
the problem on bare metal so it might just be the usual VirtualBox jank.

-Tobias

Re: change within last day broke nvmm

[Tobias Nygren]

On Sun, 15 Mar 2020 17:12:38 +0200
Yorick Hardy  wrote:

> On 2020-03-15, Tobias Nygren wrote:
> > 
> > This is consistently reproducable while trying to boot Linux on nvmm.
> > panic: LIST_INSERT_HEAD 0x88713368 x86/pmap.c:2135
>
> I think Maxime would like to be Cc'd on NVMM issues, so I am doing that here.

Looks like it's fixed with the latest pmap.c r1.369.

-Tobias

change within last day broke nvmm

[Tobias Nygren]

Hi,

This is consistently reproducable while trying to boot Linux on nvmm.

panic: LIST_INSERT_HEAD 0x88713368 x86/pmap.c:2135
vpanic()
panic()
pmap_enter_pv()
pmap_ept_enter()
uvm_fault_lower_enter()
uvm_fault_internal()
nvmm_ioctl()
sys_ioctl()
syscall()

-Tobias

Re: parallel cgd

[Tobias Nygren]

On Mon, 9 Mar 2020 08:42:17 - (UTC)
Michael van Elst  wrote:

> This should improve performance on multi-core systems.

Nominated for understatement of the year.

# dd if=/dev/rcgd0d bs=1m count=4096 of=/dev/null
Before:
4294967296 bytes transferred in 58.928 secs (72885000 bytes/sec)
After:
4294967296 bytes transferred in 9.712 secs (442233041 bytes/sec)

On "Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz" w/ NVMe disk.

> Feedback welcome.

It's a huge win. Thanks!
Candidate for netbsd-9?

Kind regards,
-Tobias

panic: _pmap_enter: cannot allocate L3 table (aarch64)

[Tobias Nygren]

Hi,

This has started happening quite often for me, but I don't see any
recent MD change that could be related. Maybe recent UVM changes?

panic: _pmap_enter: cannot allocate L3 table
cpu12: Begin traceback...
vpanic() at ffc0004ebe94 netbsd:vpanic+0x210
panic() at ffc0004ebc80 netbsd:panic+0x44
_pmap_enter() at ffc8bc74 netbsd:_pmap_enter+0xe44
pmap_kenter_pa() at ffc8ae14 netbsd:pmap_kenter_pa+0x4c
uvm_pagermapin() at ffc000469bdc netbsd:uvm_pagermapin+0x1d8
uvm_swap_io() at ffc000472200 netbsd:uvm_swap_io+0x98
swapcluster_flush() at ffc00046b5dc netbsd:swapcluster_flush+0x74
uvm_pageout() at ffc00046acb0 netbsd:uvm_pageout+0x638

-Tobias

Re: lockdebug kernel instacrash when npf enabled

[Tobias Nygren]

On Mon, 18 Feb 2019 22:59:58 +0100
Tobias Nygren  wrote:

> Hi,
> 
> I updated an evbarm host from current as of 2018-12-09 to today's
> sources. Had some issues with hangs in npf so enabled lockdebug and it
> crashed immediately with this message:
> 
> Enabling NPF.
> [  22.6038371] panic: kernel debugging assertion 
> "pserialize_not_in_read_section()" failed: file 
> "/work/src/sys/kern/kern_mutex.c", line 527
> [  22.7529500] cpu0: Begin traceback...
> [  22.7976654] 0x99deba54: netbsd:db_panic+0x14
> [  22.8465447] 0x99deba6c: netbsd:vpanic+0x194
> [  22.8985454] 0x99deba84: netbsd:__aeabi_uldivmod
> [  22.9505468] 0x99debb04: netbsd:mutex_enter+0x5f4
> [  22.9994280] 0x99debb4c: netbsd:npf_table_lookup+0x134
> [  23.0597517] 0x99debb74: netbsd:npf_cop_table+0x70
> [  23.1169500] 0x99debba4: netbsd:bpf_filter_ext+0x73c
> [  23.1741482] 0x99debc24: netbsd:npf_ruleset_inspect+0x164
> [  23.2375871] 0x99debccc: netbsd:npf_packet_handler+0x1cc
> [  23.2999868] 0x99debd24: netbsd:pfil_run_hooks+0x128
> [  23.3582278] 0x99debe1c: netbsd:ip_output+0x7ac
> [  23.4175060] 0x99debe7c: netbsd:ip_forward+0x1a4
> [  23.4653506] 0x99debf4c: netbsd:ipintr+0x115c
> [  23.5225442] 0x99debfac: netbsd:softint_dispatch+0x114
> [  23.5766292] 0x9a729cc4: netbsd:softint_switch+0x58
> [  23.6348677] 0x9a729d44: netbsd:irq_entry+0x88
> [  23.6920657] 0x9a729db4: netbsd:mutex_enter+0x5bc
> [  23.7409489] 0x9a729e24: netbsd:pmap_remove+0x15c
> [  23.7960705] 0x9a729e7c: netbsd:uvm_unmap_remove+0x258
> [  23.8563886] 0x9a729eac: netbsd:uvmspace_free+0xec
> [  23.9135859] 0x9a729f14: netbsd:exit1+0x1a0
> [  23.9697447] 0x9a729f34: netbsd:sys_exit+0x3c
> [  24.0186247] 0x9a729fac: netbsd:syscall+0x18c

r1.29 of npf_tableset.c changed t_lock from IPL_NET to IPL_NONE.
Based on the above it looks like it needs to be at IPL_SOFTNET.
@rmind you could please have a look?

Kind regards,
-Tobias

lockdebug kernel instacrash when npf enabled

[Tobias Nygren]

Hi,

I updated an evbarm host from current as of 2018-12-09 to today's
sources. Had some issues with hangs in npf so enabled lockdebug and it
crashed immediately with this message:

Enabling NPF.
[  22.6038371] panic: kernel debugging assertion 
"pserialize_not_in_read_section()" failed: file 
"/work/src/sys/kern/kern_mutex.c", line 527
[  22.7529500] cpu0: Begin traceback...
[  22.7976654] 0x99deba54: netbsd:db_panic+0x14
[  22.8465447] 0x99deba6c: netbsd:vpanic+0x194
[  22.8985454] 0x99deba84: netbsd:__aeabi_uldivmod
[  22.9505468] 0x99debb04: netbsd:mutex_enter+0x5f4
[  22.9994280] 0x99debb4c: netbsd:npf_table_lookup+0x134
[  23.0597517] 0x99debb74: netbsd:npf_cop_table+0x70
[  23.1169500] 0x99debba4: netbsd:bpf_filter_ext+0x73c
[  23.1741482] 0x99debc24: netbsd:npf_ruleset_inspect+0x164
[  23.2375871] 0x99debccc: netbsd:npf_packet_handler+0x1cc
[  23.2999868] 0x99debd24: netbsd:pfil_run_hooks+0x128
[  23.3582278] 0x99debe1c: netbsd:ip_output+0x7ac
[  23.4175060] 0x99debe7c: netbsd:ip_forward+0x1a4
[  23.4653506] 0x99debf4c: netbsd:ipintr+0x115c
[  23.5225442] 0x99debfac: netbsd:softint_dispatch+0x114
[  23.5766292] 0x9a729cc4: netbsd:softint_switch+0x58
[  23.6348677] 0x9a729d44: netbsd:irq_entry+0x88
[  23.6920657] 0x9a729db4: netbsd:mutex_enter+0x5bc
[  23.7409489] 0x9a729e24: netbsd:pmap_remove+0x15c
[  23.7960705] 0x9a729e7c: netbsd:uvm_unmap_remove+0x258
[  23.8563886] 0x9a729eac: netbsd:uvmspace_free+0xec
[  23.9135859] 0x9a729f14: netbsd:exit1+0x1a0
[  23.9697447] 0x9a729f34: netbsd:sys_exit+0x3c
[  24.0186247] 0x9a729fac: netbsd:syscall+0x18c

dhcpd broken in current?

[Tobias Nygren]

Hello,

My dhcpd isn't serving requests anymore and /etc/rc.d/dhcpd restart
hangs. My best guess is that it is fallout from the bind-9.13.2-P1
update because a new version of libisc came with the update.

I installed dhcpd from pkgsrc and that works for now.
Anyone else?

Kind regards,
-Tobias

Re: pool_grow hangs (Re: CVS commit: src/sys)

[Tobias Nygren]

On Fri, 29 Dec 2017 16:40:52 +
co...@sdf.org wrote:

> On Fri, Dec 29, 2017 at 03:41:42PM +0100, Tobias Nygren wrote:
> > The machine has survived for 30+ minutes where it previously hung after
> > just 20 seconds.
> 
> Do you mean "30+ minutes so far" or does it still hang somewhere? where?

No, I did not manage to break it yet.

Re: pool_grow hangs (Re: CVS commit: src/sys)

[Tobias Nygren]

> Meanwhile another process, waiting for the grower to finish, is
> spinning forever at 100% doing the mutex_exit/mutex_enter/ERESTART
> thing on the same pool. It looks to me like the grower never actually
> gets scheduled to run.

The attached diff works around the problem by not releasing the lock
during allocation in the PR_NOWAIT case. I don't know if doing it that
way could have any negative side effects?
The machine has survived for 30+ minutes where it previously hung after
just 20 seconds.

Kind regards,
-Tobias
Index: subr_pool.c
===
RCS file: /cvsroot/src/sys/kern/subr_pool.c,v
retrieving revision 1.219
diff -u -r1.219 subr_pool.c
--- subr_pool.c 16 Dec 2017 03:13:29 -  1.219
+++ subr_pool.c 29 Dec 2017 14:33:40 -
@@ -1091,7 +1091,9 @@
if ((flags & PR_WAITOK) == 0)
pp->pr_flags |= PR_GROWINGNOWAIT;
 
-   mutex_exit(>pr_lock);
+   if (flags & PR_WAITOK)
+   mutex_exit(>pr_lock);
+
char *cp = pool_allocator_alloc(pp, flags);
if (__predict_false(cp == NULL))
goto out;
@@ -1102,7 +1104,8 @@
goto out;
}
 
-   mutex_enter(>pr_lock);
+   if (flags & PR_WAITOK)
+   mutex_enter(>pr_lock);
pool_prime_page(pp, cp, ph);
pp->pr_npagealloc++;
KASSERT(pp->pr_flags & PR_GROWING);
@@ -1115,8 +1118,9 @@
return 0;
 out:
KASSERT(pp->pr_flags & PR_GROWING);
+   if (flags & PR_WAITOK)
+   mutex_enter(>pr_lock);
pp->pr_flags &= ~(PR_GROWING|PR_GROWINGNOWAIT);
-   mutex_enter(>pr_lock);
return ENOMEM;
 }
 

pool_grow hangs (Re: CVS commit: src/sys)

[Tobias Nygren]

On Sat, 16 Dec 2017 03:13:29 +
matthew green  wrote:

> Module Name:  src
> Committed By: mrg
> Date: Sat Dec 16 03:13:29 UTC 2017
> 
> Modified Files:
>   src/sys/kern: subr_pool.c
>   src/sys/sys: pool.h
> 
> Log Message:
> hopefully workaround the irregularly "fork fails in init" problem.
> 
> if a pool is growing, and the grower is PR_NOWAIT, mark this.
> if another caller wants to grow the pool and is also PR_NOWAIT,
> busy-wait for the original caller, which should either succeed
> or hard-fail fairly quickly.
> 
> implement the busy-wait by unlocking and relocking this pools
> mutex and returning ERESTART.  other methods (such as having
> the caller do this) were significantly more code and this hack
> is fairly localised.
> 
> ok chs@ riastradh@

Hi!

I have an easily reproducable system hang that I believe originates
from this change. It can be triggered by doing lots of block and
network i/o (like 3 multiple rsyncs) on a uniprocessor system
running under Linux KVM.

Basically what happens is that for unknown reasons the PR_NOWAIT
grower blocks forever when it tries to reaquire the pool lock to
do pool_prime_page() in pool_grow().

Meanwhile another process, waiting for the grower to finish, is
spinning forever at 100% doing the mutex_exit/mutex_enter/ERESTART
thing on the same pool. It looks to me like the grower never actually
gets scheduled to run.

Also, although it doesn't fix the issue, this pr_flags modification
looks like it should be moved to after the mutex is acquired:

pp->pr_flags &= ~(PR_GROWING|PR_GROWINGNOWAIT);
mutex_enter(>pr_lock);

Kind regards,
-Tobias

Re: Status of xsrc/native X?

[Tobias Nygren]

On Wed, 17 Aug 2016 07:03:06 +
Thomas Mueller  wrote:

> What is now the status of native vs. modular (pkgsrc) X in NetBSD-current?
> 
> I seemed to read something about native X being deprecated in favor of pkgsrc 
> X, but keep seeing xsrc in nightly build logs, and recently noticed a big 
> upgrade in native X in xsrc tree as well as supporting files in src tree.
> 
> Native X used to be a very old version of xorg-server.
> 
> I am already on modular X, should I switch to native, and how do I do it 
> elegantly, or should I do a new installation?  I have space for lots of 
> partitions using GPT on 3 TB or 4 TB hard drive.
> 
> Is the intention now to keep native X current?

I can't speak for the native X11 maintainers nor comment on what the
original plan was, but the way things de facto turned out is that
pkgsrc X11 provides the latest stable upstream versions for up-to-date
hardware- and operating system combinations (not limited to NetBSD!)
while native X11 provides something that works well for the associated
NetBSD release and hardware available at that time.

If you are already on pkgsrc X11 and your intent is to stay up-to-date
I don't see any reason to switch back.

My vision is that pkgsrc X11 should always work better than
native X11 on modern x86 and ARM. That said there are still plenty
of NetBSD specific patches in the xsrc tree (mostly for the tier2/tier3
platforms) that don't exist in pkgsrc nor upstream. I encourage
maintainers to always commit their fixes in both trees AND upstream
them.

Kind regards,
-Tobias

Re: (almost) full disk encryption, cgdroot and firmware

[Tobias Nygren]

On Mon, 20 Jun 2016 20:15:00 +0100
Alexander Nasonov  wrote:

> This is my story on (almost) full disk encryption.
> 
> I followed Pierre Proncher's instruction from Mar 2013. To my
> surprise, it worked on the first boot. However, networking didn't
> work because the kernel couldn't load iwm firmware.
> 
> After a couple of attempts to fix firmware loading, I gave up on
> cgdroot ramdisk and switched to a fake root on wd0a. It's similar
> to cgdroot but with modules and firmware files. I hard-linked few
> binaries including init from /rescue.
> 
> My setup has not one but two cgd devices: cgd0 for a real root and
> cgd1 for other partitions. cgd0's key is stored on unencrypted
> wd0a, cgd1's key is stored on the real root cgd0a. I have to enter
> two passwords instead of one but this setup gives me some protection
> from an unsophisticated keylogger. Since wd0a is read-only, I can
> add wd0a integrity check before running the second cgdconfig -C
> command and abort before entering the second password if the check
> fails. A real rootkit can easily fool the integrity checker, though.

If someone wants to add real kernel level cgd root configuration it is
actually not all that difficult to do. I'll attach the patch I've been
using for many years to this mail.

I never contributed it because it requires hardwiring the cgd
parameters into the kernel configuration and I think a proper
implementation should be more user friendly and be able to get the
parameters from the boot loader or some kind of super block.

Usage example:

options CGD_ROOT_FSDEV="\"cgd0a\""
options CGD_ROOT_FSMAJOR=20
options CGD_ROOT_FSMINOR=0

options CGD_ROOT_DEV="\"/dev/wd0e\""
options CGD_ROOT_MAJOR=0
options CGD_ROOT_MINOR=4
options CGD_ROOT_CIPHER="\"blowfish-cbc\""
options CGD_ROOT_KEYLEN=256
options
CGD_ROOT_SALT="0x01,0x01,0x02,0xaa,0xbb,0xaa,0xbb,0xaa,0xbb,0xaa,0xbb,0xaa,0xbb,0xaa,0xbb,0xaa"
options CGD_ROOT_ITERATIONS=12345

On bootup you should see a password prompt followed by:

cgdroot_finalize()
cgdroot_finalize: finished
root on cgd0a dumps on cgd0b

Kind regards,
-Tobias
Index: sys/kern/init_main.c
===
RCS file: /cvsroot/src/sys/kern/init_main.c,v
retrieving revision 1.481
diff -u -r1.481 init_main.c
--- sys/kern/init_main.c4 Jun 2016 21:10:56 -   1.481
+++ sys/kern/init_main.c20 Jun 2016 19:59:00 -
@@ -245,6 +245,8 @@
 static void configure(void);
 static void configure2(void);
 static void configure3(void);
+void cgdroot_finalize(void);
+void cgdroot_getpass(void);
 void main(void);
 
 /*
@@ -277,6 +279,13 @@
 * in case of early panic or other messages.
 */
consinit();
+#ifdef CGD_ROOT_DEV
+   /*
+* XXX if we are using a USB keyboard we have to do this later,
+ * after the keyboard is attached.
+   */
+   cgdroot_getpass();
+#endif
 
kernel_lock_init();
once_init();
@@ -603,6 +612,14 @@
 
sysctl_finalize();
 
+#ifdef CGD_ROOT_DEV
+#if 0
+   /* if USB keyboard */
+   cgdroot_getpass();
+#endif
+   cgdroot_finalize();
+#endif
+
/*
 * Now that autoconfiguration has completed, we can determine
 * the root and dump devices.
Index: sys/dev/cgd.c
===
RCS file: /cvsroot/src/sys/dev/cgd.c,v
retrieving revision 1.106
diff -u -r1.106 cgd.c
--- sys/dev/cgd.c   28 Nov 2015 21:06:30 -  1.106
+++ sys/dev/cgd.c   20 Jun 2016 19:59:00 -
@@ -51,6 +51,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -115,6 +117,22 @@
 static voidcgd_cipher(struct cgd_softc *, void *, void *,
   size_t, daddr_t, size_t, int);
 
+#ifdef CGD_ROOT_DEV
+void cgdroot_getpass(void);
+static int cgd_cngetsn(char *cp, int size);
+static int cgd_pkcs5_pbkdf2_sha1(u_int8_t *r, size_t dkLen,
+ const u_int8_t *P, size_t Plen,
+ const u_int8_t *S, size_t Slen, size_t c);
+static voidcgd_sha1_hmac(const uint8_t *p, size_t Plen, uint8_t *data,
+ size_t datalen, uint8_t out[20]);
+static voidcgd_prf_iterate(u_int8_t *r, const u_int8_t *P, size_t Plen,
+   const u_int8_t *S, size_t Slen, size_t c,
+   size_t ind);
+static int cgd_pkcs5_pbkdf2_sha1(u_int8_t *r, size_t dkLen,
+ const u_int8_t *P, size_t Plen,
+ const u_int8_t *S, size_t Slen, size_t c);
+#endif
+
 static struct dkdriver cgddkdriver = {
 .d_minphys  = minphys,
 .d_open = cgdopen,
@@ -622,6 +640,8 @@
const char *cp;
struct pathbuf *pb;
char *inbuf;
+   char *tmppath;
+   size_t   tmppathlen;
struct dk_softc *dksc = >sc_dksc;
 
cp = 

Re: current/amd64 randomly shuts down after a few minutes when running under VirtualBox (ACPI problem?)

[Tobias Nygren]

Hi,

On Wed, 25 May 2016 04:14:38 +0200
Tobias Nygren <t...@netbsd.org> wrote:

> For some reason -current decides that the power button has been
> pressed after a few minutes and shuts down. Normally I'd suspect bad
> hardware but since this is a virtual machine I'm not sure what to think.
> Here is what I managed to grab with a screenshot when it happened after
> around 4 minutes of uptime:
> 
> ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling 
> (20160422/evevent-325)
> ACPI Error: No installed handler for fixed event - RealTimeClock (4), 
> disabling (20160422/evevent-325)
> [...]

salazar@ found that FreeBSD encountered the same problem:
https://www.mail-archive.com/freebsd-current@freebsd.org/msg165688.html

Look like there is an upstream patch available:
https://github.com/acpica/acpica/pull/138

Kind regards,
-Tobias

current/amd64 randomly shuts down after a few minutes when running under VirtualBox (ACPI problem?)

[Tobias Nygren]

Hi!

For some reason -current decides that the power button has been
pressed after a few minutes and shuts down. Normally I'd suspect bad
hardware but since this is a virtual machine I'm not sure what to think.
Here is what I managed to grab with a screenshot when it happened after
around 4 minutes of uptime:

ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling 
(20160422/evevent-325)
ACPI Error: No installed handler for fixed event - RealTimeClock (4), disabling 
(20160422/evevent-325)
ACPI Error: No handler or method for GPE 01, disabling event 
(20160422/evgpe-836)
ACPI Error: No handler or method for GPE 03, disabling event 
(20160422/evgpe-836)
ACPI Error: No handler or method for GPE 04, disabling event 
(20160422/evgpe-836)
ACPI Error: No handler or method for GPE 05, disabling event 
(20160422/evgpe-836)
ACPI Error: No handler or method for GPE 06, disabling event 
(20160422/evgpe-836)
ACPI Error: No handler or method for GPE 07, disabling event 
(20160422/evgpe-836)
acpivga0: connected output devices:
acpivga0:   0x0100 (acpiout0): VGA Analog Monitor, index 0, port 0, head 0
acpi0: entering state S3

-Tobias

Re: PaX mprotect now on for amd64

[Tobias Nygren]

On Sun, 15 May 2016 12:29:16 +0200
Kamil Rytarowski  wrote:

> On 15.05.2016 10:22, David Brownlee wrote:
> > Would it make sense to (possibly optionally) integrate this into
> > pkgsrc builds for at least java? (the paxctl +m call)
> 
> It makes sense, it has been already done for editors/emacs24 (but for
> the +a option).

I'm also having trouble with nodejs and firefox segfaulting from this.
I bet there are many other packages yet to be discovered to be broken.
We need to invent some better way to deal with this than how it was
done for emacs.

-Tobias

Re: wm devices don't work under current amd64

[Tobias Nygren]

On Mon, 7 Mar 2016 20:57:02 +0900
Masanobu SAITOH  wrote:

> One of the possibility is that the multicast filter table and broadcast
> bit in a register aren't set correctly on ICH9.

I'm not sure if this is relevant to the discussion, but I have a wm(4)
device (8086:1502) on -current that does not work after boot. It comes
to life only after running "tcpdump -n -i wm0" once. I am using vlan(4),
but haven't checked if that makes any difference. I usually run the
tcpdump command then forget about it until the next reboot.

wm0 at pci0 dev 25 function 0: PCH2 LAN (82579LM) Controller (rev. 0x06)
wm0: interrupting at msi0 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address xx:xx:xx:xx:xx:xx
ihphy0 at wm0 phy 2: i82579 10/100/1000 media interface, rev. 3
ihphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto

current tmux signal handling bug

[Tobias Nygren]

Hi,

It looks like the recently imported tmux 2.1 has some bug that can
wedge the backend process, making your panes unresponsive.

If you encounter this situation and need to recover your session,
a workaround is to manually kill all tmux child processes and send
a SIGCHLD to the backend process.

Steps to reproduce:
1. run "tmux attach" on the same session in two xterms
2. xkill one of the xterms
3. resume work in the first xterm
4. typically it gets wedged within 5 seconds

It might be the same issue as https://github.com/tmux/tmux/issues/298
so it's worth monitoring that for possible fix.

Kind regards,
-Tobias

can't build.sh tools natively on arm (binutils config.sub issue)

[Tobias Nygren]

Hi,

$ uname -smr
NetBSD 7.99.26 evbarm
$ ./build.sh -m evbarm -a earmv7hf -T ../tools -O ../obj -u -U -N 1 tools

yields:

dependall ===> binutils
Cleaning stale cache files NetBSD-7.99.26-evbarm != none
checking build system type...
Invalid configuration `arm-unknown-netbsdelf-eabihf7.99-eabihf':
machine `arm-unknown-netbsdelf-eabihf7.99' not recognized
configure: error: /bin/sh 
/work/src/tools/binutils/../../external/gpl3/binutils/dist/config.sub 
arm-unknown-netbsdelf-eabihf7.99-eabihf failed

I'm fairly sure it used to work before the binutils update.
A workaround is:

$ cp pkgsrc/mk/gnu-config/config.* src/external/gpl3/binutils/dist/.

Kind regards,
-Tobias

Re: showstopper, libGL error with (at least) radeon in -current

[Tobias Nygren]

On Fri, 30 Oct 2015 17:49:28 +0100
Reinoud Zandijk  wrote:

> I've just basically re-installed my NetBSD/amd64 to -current of the 26st of
> October and I'm running into libGL init issues:
> 
> > glxgears 
> libGL error: unable to load driver: r600_dri.so
> Any ideas?

Check /var/log/Xorg.0.log if Xorg itself was able to load r600_dri.so.
It might provide more useful diagnostics than glxgears. You should see
lines similar to:

[26.881] (II) RADEON(0): [DRI2] Setup complete
[26.881] (II) RADEON(0): [DRI2]   DRI driver: r600
[26.881] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[26.963] (II) AIGLX: Loaded and initialized r600
[26.963] (II) GLX: Initialized DRI2 GL provider for screen 0

(HD5450, current amd64, pkgsrc X.org)

-Tobias

Re: kqueue: SIGIO?

[Tobias Nygren]

On Tue, 29 Sep 2015 12:56:36 +0200
Joerg Sonnenberger  wrote:

> On Tue, Sep 29, 2015 at 11:31:20AM +0200, Thomas Klausner wrote:

> > During the XDC last week, Keith Packard talked about a select(2) issue
> > in xserver he would like to fix with epoll and its support for SIGIO.
> > Is there a similar feature in kqueue in NetBSD?
> 
> It would be easier to answer that question if we know what issue he was
> actually talking about.

>From my (limited) understanding it is about preventing starvation of
other X clients when one client is hammering the server with requests.

When they are processing events for one client in a tight loop they
don't want to periodically check if other clients are ready for I/O,
but would instead like to get notified via a signal.

Here is the relevant bit of the talk if you are curious:

https://www.youtube.com/watch?v=t400SmZlnO8=youtu.be=1888

ssh forced commands broken in current? (ssh_packet_send_debug: unknown error)

[Tobias Nygren]

Hi,

I got an alert that backups weren't running. It looks like forced
commands no longer work on the server side. Anyone else see this?

OpenSSH_6.8 NetBSD_Secure_Shell-20150403, OpenSSL 1.0.1m 19 Mar 2015
MKLLVM=yes

Test case in ~/.ssh/authorized_keys:

command=/usr/bin/uname -a,no-port-forwarding,no-X11-forwarding,no-pty
ssh-rsa ...

Results in:

$ ssh -T tnn@localhost /usr/bin/uname -a
Connection to localhost closed by remote host.

# /usr/sbin/sshd -d
...
Accepted publickey for tnn from ::1 port 64821 ssh2: RSA SHA256:...
debug1: monitor_child_preauth: tnn has been authenticated by privileged process
debug1: mac 0x7f7ff7b2f9b0, 1 1 [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
User child is on pid 12298
debug1: PAM: establishing credentials
debug1: ssh_packet_set_postauth: called
debug1: mac 0x7f7ff7b2f2b0, 1 1
debug1: mac 0x7f7ff7b2f2b0, 1 1
ssh_packet_send_debug: unknown error 1048
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session

Re: OpenSSL 1.0.1m imported

[Tobias Nygren]

On Mon, 23 Mar 2015 10:23:42 +
S.P.Zeidler s...@netbsd.org wrote:

 the vulnerability fixes for the latest advisory set from OpenSSL went
 in last week; this is merely an exercise getting to a clean copy,
 especially since OpenSSL changed the source format and we'll want to
 do updates in the future, too. As a result, the diffs are sadly very messy.
 
 I've tested amd64. i386 and sparc will get a run by the automated tester;
 if people with powerpc and sparc64 running -current could give it a whirl
 before pullups to the release branches, that would be helpful.

Hi,
Thanks for doing this. pkgsrc does not seem to detect this new version
correctly though. The BUILTIN_VERSION.openssl awk script in
security/openssl/builtin.mk is returning empty string leading to all
packages depending on openssl from pkgsrc.
(If I force BUILTIN_VERSION.openssl to 1.0.1m it works fine.)

-Tobias

Re: firefox eats threads

[Tobias Nygren]

On Wed, 18 Mar 2015 14:26:04 +0100
Thomas Klausner w...@netbsd.org wrote:

 Over the last months I have noticed a pattern. When I leave a firefox
 process running for some time, it reduces the available threads for
 other programs. The symptom is that other programs (like git, gnucash,
 or anything that needs threads) don't start or have weird failure
 modes.
 
 When I quit and restart firefox, there are immediately enough threads
 available again. So I'm sure it's firefox-related.
 
 Last night I noticed that this even happens when I'm not actively
 doing anything in it (so perhaps extensions or firefox sync also have
 an influence).
 
 Did anyone else notice this?
 
 Any ideas how to fix this?

Firefox names all it's threads by type with pthread_setname_np(3).
The following command is useful to find out what kind of threads are in
use:

$ ps -sp 12501 -O lname

Firefox after startup pools 45 threads so that's one third of your
available LWPs. My opinion is that the default ulimits on amd64 have not
caught up with the times. 1024 would be a more reasonable figure than
128  160 for open files and lwps.

Kind regards,
-Tobias