daily CVS update output

Updating src tree: P src/external/gpl3/gcc/dist/gcc/ira-color.c P src/external/gpl3/gcc.old/dist/gcc/ira-color.c P src/lib/libcurses/curses_inch.3 P src/share/man/man4/mvsata.4 P src/share/man/man4/umass.4 P src/share/man/man8/diskless.8 P src/sys/arch/amd64/include/vmparam.h P

Re: "dmesg -T" date doesn't match "date" output

Date:Mon, 29 Oct 2018 07:03:21 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | Being "plausible" is irrelevant here, we are just talking about | time stamps that are useful, not some meaning in the real world. That might be what you're

Automated report: NetBSD-current/i386 build success

The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2018.10.29.15.37.45 christos src/sys/rump/net/lib/libnpf/Makefile,v 1.26 Log files can be found at:

Re: X server being killed a lot

In article , Michael van Elst wrote: >chris...@astron.com (Christos Zoulas) writes: > >>But we kill the process that faulted in this case not the process that >>likely caused the shortage. We should be keeping stats so that we can >>select a better victim, then kill that instead and retry. But

Automated report: NetBSD-current/i386 build failure

This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2018.10.29.15.37.06. An extract from the build.sh output follows:

Re: X server being killed a lot

Izumi Tsutsui wrote: >> Do we know what combination of things is causing X to be killed ? > >I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating >4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images). How is your X server configured ? Is it operating on a framebuffer

Re: X server being killed a lot

Izumi Tsutsui wrote: >> Izumi Tsutsui wrote: >> >> Do we know what combination of things is causing X to be killed ? >> > >> >I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating >> >4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images). >> >> How is your X server

Re: X server being killed a lot

> Izumi Tsutsui wrote: > >> Do we know what combination of things is causing X to be killed ? > > > >I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating > >4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images). > > How is your X server configured ? Is it operating on a

Re: X server being killed a lot

> Do we know what combination of things is causing X to be killed ? I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating 4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images). IIRC no such problem on 7.x days. (though Firefox was also smaller in those days) --- Izumi

Re: Building fails for am64

k...@ub.uni-mainz.de ("K. Schreiner") writes: >/u/NetBSD/src/usr.sbin/crash/../../sys/arch/x86/x86/db_trace.c: In function >'db_stack_trace_print': >/u/NetBSD/arch/amd64/obj/usr.sbin/crash/x86/db_machdep.h:6:42: error: >'VM_MIN_KERNEL_ADDRESS' undeclared (first use in this function) > #define

Building fails for am64

Hi, with sources cvs'uped some minutes ago > 1029: ./build.sh -u -N 1 -j 8 -U -m amd64 -O /u/NetBSD/arch/amd64/obj -D > /u/NetBSD/arch/amd64/dest -R /u/NetBSD/arch/amd64/release -T > /u/NetBSD/arch/amd64/TOOLS distribution respectively >-1038: cd /u/NetBSD/src/usr.sbin/crash >-1038:

Re: X server being killed a lot

Do we know what combination of things is causing X to be killed ? I have never seen it happen and am running X, Firefox and several other big packages as well as doing builds on the same machine. Robert Swindells

Re: X server being killed a lot

chris...@astron.com (Christos Zoulas) writes: >But we kill the process that faulted in this case not the process that >likely caused the shortage. We should be keeping stats so that we can >select a better victim, then kill that instead and retry. But this is >easier said than done :-) Linux

Re: X server being killed a lot

In article , Michael van Elst wrote: >mlel...@serpens.de (Michael van Elst) writes: > >>filemax is not the limit for the cache but the level it tries to keep >>when pressed for memory. > >None of these settings are directly responsible for killing a process, >they just help to avoid that the

Re: X server being killed a lot

mlel...@serpens.de (Michael van Elst) writes: >filemax is not the limit for the cache but the level it tries to keep >when pressed for memory. None of these settings are directly responsible for killing a process, they just help to avoid that the system runs against the wall. A process is

Re: X server being killed a lot

t...@giga.or.at (Thomas Klausner) writes: >On Mon, Oct 22, 2018 at 12:18:01PM -0400, Michael wrote: >> It helped somewhat to add this to sysctl.conf: >> vm.filemin=2 >> vm.filemax=10 >> now it still uses well over 10% or memory as file cache but seems more >> willing to shrink it. filemax is not

Re: X server being killed a lot

On Mon, 29 Oct 2018 09:46:34 +0100 Thomas Klausner wrote: > On Mon, Oct 22, 2018 at 12:18:01PM -0400, Michael wrote: > > I've had firefox starting to get swapped out ( and everything > > slowing to a crawl because of it ) while in active use, with more > > than half of RAM being used as file

Re: X server being killed a lot

On Mon, Oct 22, 2018 at 12:18:01PM -0400, Michael wrote: > I've had firefox starting to get swapped out ( and everything slowing > to a crawl because of it ) while in active use, with more than half of > RAM being used as file cache, and nothing hammering the filesystem > either. > One would think

Re: "dmesg -T" date doesn't match "date" output

k...@munnari.oz.au (Robert Elz) writes: > | > 1. when the firmware is told to boot > | > 2. when the boot loader gets control from the firmware > | > 3. when the kernel first starts executing. > | 3a. when the kernel has started clock > | 3b. when the kernel has mounted root > | > 4.