Re: swap space issues
On Mon, 13 Jul 2020 00:45:36 -0500 Scott Bennett benn...@sdf.org said Don Wilde wrote: > > On 7/11/20 11:28 PM, Scott Bennett via freebsd-stable wrote: > > I have read this entire thread to date with growing dismay, and I > > thank Donald Wilde for reporting his ongoing troubles, although they > > spoil my hopes that the kernel's memory management bugs that first became > > apparent in 11.2-RELEASE (and -STABLE around the same time) were not > > propagated into 12.x. A recent update to stable/12 source tree made it > > finally possible for me to build 12.1-STABLE under 11.4-PRERELEASE, and I > > was just about to install the upgrade when this thread appeared. > Spoiler alert. Since I gave up on Synth, I haven't had a single swap > issue. It does appear to be one particular port that drove it nuts > (apparently, one of the 'Google performance' bits, with a > mismatched-brackets problem). I have rebuilt the machine several times, > but that's more for my sense of tidiness than anything. > > I've got a little Crystal script that walks the installed packages and > ports and updates them with system() calls. > The machine is very slow, but it's not swapping at all. That's good. I use portmaster, but not often at present because a "portmaster -a" run can only be done two or three times per boot before real memory is locked down to the extent that the system is no longer functional (i.e., even a scrub of ZFS pools comes to a halt in mid scrub due to lack of a sufficient supply of free page frames). The build procedures of certain ports consistently get killed by the OOM killer, along with much collateral damage. I've noticed that lang/golang and lang/rust are prime examples now, although both used to build without problems. > > It is quite usable now with 12-STABLE. I don't see any good reason to go through the hassle and lost time of an upgrade across a major release boundary if I still won't have a production OS afterward. I'm already dealing with a graphics stack rendered unsafe to use by the ongoing churn in X11 code. (See PR #247441, kindly filed for me by Pau Amma.) > > > > On Fri, 26 Jun 2020 03:55:04 -0700 : Donald Wilde > > wrote: > > > >> On 6/26/20, Peter Jeremy wrote: > >>> > [snip] > >>> I strongly suggest you don't have more than one swap device on spinning > >>> rust - the VM system will stripe I/O across the available devices and > >>> that will give particularly poor results when it has to seek between the > >>> partitions. > > True. The only reason I can think of to use more than one swapping/ > > paging area on the same device for the same OS instance is for emergencies > > or highly unusual, temporary situations in which more space is needed > until > > those situations conclude. and even in such situations, if the space can > be > > found on another device, it should be placed there. Interleaving of swap > > space across multiple devices is intended as a performance enhancement > > akin to striping (a.k.a. RAID0), although the virtual memory isn't > > necessarily always actually striped across those devices. Adding a paging > > area on the same device as an existing one is an abhorrent situation, as > > Peter Jeremy noted, and it should be eliminated via swapoff(8) as soon as > > the extraordinary situation has passed. N.B. the GENERIC kernel sets a > > limit of four swap devices, although it can be rebuilt with a different > > limit. > That's good data, Scott, thanks! The only reason I got into that > situation of trying to add another swap device was that it was crashing > with OO swap messages. I don't recall you posting those messages, but it sounds like exactly the *temporary* situation in which adding an inappropriately placed paging area can be used long enough to get you out of a bind without a reboot, even though performance will probably suffer until you have removed it again. Poor performance is usually preferable to no performance if it is only temporary. One cautionary note in such situations, though, applies to remote paging areas. Sparse files allocated on the remote system should not be used as paging areas. For example, I discovered the hard way (i.e., the problem was not documented) that SunOS would crash if a sparse file via NFS were added as a paging area and the SunOS system tried to write a page out to an unallocated region of the file, which was essentially all of the file at first. > >> My intent is to make this machine function -- getting the bear > >> dancing. How deftly she dances is less important than that she dances > >> at all. My for-real boxen will have real HP and real cores and RAM. > >> > >>> Also, you can't actually use 64GB swap with 4GB RAM. If you look back > >>> through your boot messages, I expect you'll find messages like: > >>> warning: total configured swap (524288 pages) exceeds maximum > recommended > >>> amount (498848 pages). > >>> warning: increase kern.maxswzone or reduce
Re: 12.1p7 no longer boots after doing zpool upgrade -a
On Fri, Jul 10, 2020 at 02:28:12PM -0500, Kyle Evans wrote: > > > > There was one question I forgot to ask: > > Could I have known that my method of updating the ESP was not correct? > > If so, where is this documented? > > > > It is probably unlikely, to be honest. I don't know that we do a good > job of advising people/documenting how to update the ESP. In fact, I > have no idea where any of it's documented except the wiki: > https://wiki.freebsd.org/UEFI > Hi Kyle, I think that if the "new" method is stable as you say, the changes done in r342283 based on https://reviews.freebsd.org/D17947 should be MFC'ed, don't you think? Because then boot1.efi and boot1.efifat wil not even be created anymore and the old documentation would be clearly out of date (in fact it would even be better when both boot1.efi and boot1.efifat would be mentioned in ObsoleteFiles.inc) -Guido ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD CI Weekly Report 2020-07-12
FreeBSD CI Weekly Report 2020-07-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-07-06 to 2020-07-12. During this period, we have: * 1964 builds (95.7% (+0.0) passed, 4.3% (+0.0) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 225 test runs (86.7% (-4.7) passed, 13.3% (+6.1) unstable, 0.0% (-1.4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 36 doc and www builds (100% (+4.3) passed) Test case status (on 2020-07-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | - | - | --- | | head/amd64 | 7859 (+2) | 7767 (+5) | 0 (0) | 92 (-3) | | head/i386 | 7857 (+2) | 7758 (+5) | 0 (0) | 99 (-3) | | 12-STABLE/amd64 | 7617 (0) | 7557 (+1) | 0 (0) | 60 (-1) | | 12-STABLE/i386 | 7615 (0) | 7547 (+1) | 0 (0) | 68 (-1) | | 11-STABLE/amd64 | 6912 (0) | 6861 (0) | 0 (0) | 51 (0) | | 11-STABLE/i386 | 6910 (0) | 6854 (-3) | 0 (0) | 56 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200712 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import https://bugs.freebsd.org/244732 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix in review: https://reviews.freebsd.org/D25284 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 647 failures, 825 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib
