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 src/sys/arch/evbar
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 concer
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:
http://releng.NetBSD.org/b5reports/i386/commits-20
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 thi
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:
/tmp/bracket/build/2018.10.29.15.37.06-i386/tools/
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 i
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 conf
> 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 f
> 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 Tsu
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 IN
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: /u/NetBSD
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
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 trie
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 syste
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 killed
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
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 cach
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
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. Whe
19 matches
Mail list logo
