From owner-freebsd-bugs@freebsd.org Mon Jan 15 23:47:28 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4ED4AE7F881 for ; Mon, 15 Jan 2018 23:47:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35E8A76646 for ; Mon, 15 Jan 2018 23:47:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2776721595 for ; Mon, 15 Jan 2018 23:47:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w0FNlSn4052206 for ; Mon, 15 Jan 2018 23:47:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w0FNlS7R052205 for freebsd-bugs@FreeBSD.org; Mon, 15 Jan 2018 23:47:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225197] `make buildkernel' fails on a machine with 1GB RAM Date: Mon, 15 Jan 2018 23:47:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 23:47:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225197 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markmi@dsl-only.net --- Comment #4 from Mark Millard --- (In reply to Wolfram Schneider from comment #3) Also, as I understand it, with only 1 GiByte of RAM assigned FreeBSD will self limit the swap space, reporting somethings like (not necessarily with matching figures): warning: total configured swap (524288 pages) exceeds maximum recommended amount (405460 pages). [Note the above is from a RPi2B V1.1 with 1 GiByte of RAM (armv7). An RPi3B (aarch64) allows far more but still limits it.] It will also say something like: warning: increase kern.maxswzone or reduce amount of swap. but looking at the code that "increase kern.maxswzone" only applies if one has already set kern.maxswzone to a figure that limited the amount of swap. The default value of zero makes kern.maxswzone be otherwise ignored. (But i386 seemed to have a non-zero default, if I remember correctly.) Quoting "man 8 loader" : kern.maxswzone . . . Note that swap metadata can be fragmented, which means th= at the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken to not configure more swap than approximately half of the theoretical maximum. . . . It turns out that the "maximum recommended amount" earlier is that "half". But the theoretical maximum is not always the "8 times the amount of physical memory" that man page indicates (or anywhere near even 6 times). (The RPi2B V1.1 is an example of that.) --=20 You are receiving this mail because: You are the assignee for the bug.=