Re: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
On 28/9/18 7:31 am, Rebecca Cran wrote: > I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap. > I've found it running out of memory when building ports via synth: I > think I've also seen it when running a buildworld. Johannes on > FreeBSDDesktop suggested it might be related to ZFS, and setting > vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem. > > > Shortly after running out of memory (with |"swap_pager_getswapspace(32): > failed" messages)|, the first few lines of 'top' were: I believe the default arc settings are wrong, arc_max defaults to 1G less than ram, with arc being wired this collides with other ram that may be wired, by default the kernel is allowed to wire 30% of ram which is in addition of any arc allocation. So arc should remain less than 70% of ram. I submitted bug 229764 with this. Also consider any bhyve usage, the -S option will wire guest ram, which one of the bhyve tools enables as default. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
On 9/27/18 9:00 PM, Allan Jude wrote: > > It doesn't appear like ZFS is dominating memory usage there. Using less > than the 8GB you indicated that setting the max to solved the problem... Yeah, I'm not sure how that works. -- Rebecca ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: resume issues on ALPHA7
On 9/27/18 12:12 PM, Pete Wright wrote: Hello, I am having issues resuming my system under ALPHA7. Under ALPHA5 I was able to suspend/resume my kabylake laptop without issues, but under ALPHA7 when I attempt to resume it seems to lock up (no input working from keyboard) requiring a hard reboot of my system. Not sure how I can debug this, so any tips would be appreciated. Here's my current dmesg: http://termbin.com/y4lk probably worth noting I've seen those ACPI errors since around ALPHA3 IIRC. bumping this thread with an update. i re-installed my laptop from the ALPHA7 snapshot to ensure i had a clean env, and am unable to wake from resume. i had misspoke regarding ALPHA5, as i tested that as well and it failed to resume. my plan is to go back to ALPHA3 and see if it worked then. one question, i've enabled: debug.acpi.resume_beep:1 and it indeed does beep on resume, and does not stop beeping until i hit power button. does that ring any bells? thanks! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
On 2018-09-27 18:01, Rebecca Cran wrote: > I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap. > I've found it running out of memory when building ports via synth: I > think I've also seen it when running a buildworld. Johannes on > FreeBSDDesktop suggested it might be related to ZFS, and setting > vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem. > > > Shortly after running out of memory (with |"swap_pager_getswapspace(32): > failed" messages)|, the first few lines of 'top' were: > > > Mem: 4335M Active, 4854M Inact, 7751M Laundry, 9410M Wired, 48K Buf, > 5332M Free > > ARC: 5235M Total, 4169M MFU, 497M MRU, 172K Anon, 97M Header, 471M Other > > 3479M Compressed, 5930M Uncompressed, 1.70:1 Ratio > > Swap: 2048M Total, 2009M Used, 39M Free, 98% Inuse > > > > I've not seen this happen before on ZFS systems, so is it a regression > in 12? > > It doesn't appear like ZFS is dominating memory usage there. Using less than the 8GB you indicated that setting the max to solved the problem... -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
On Thu, Sep 27, 2018 at 15:03 Rebecca Cran wrote: > I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap. > I've found it running out of memory when building ports via synth: I > think I've also seen it when running a buildworld. Johannes on > FreeBSDDesktop suggested it might be related to ZFS, and setting > vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem. > > > Shortly after running out of memory (with |"swap_pager_getswapspace(32): > failed" messages)|, the first few lines of 'top' were: > > > Mem: 4335M Active, 4854M Inact, 7751M Laundry, 9410M Wired, 48K Buf, > 5332M Free > > ARC: 5235M Total, 4169M MFU, 497M MRU, 172K Anon, 97M Header, 471M Other > > 3479M Compressed, 5930M Uncompressed, 1.70:1 Ratio > > Swap: 2048M Total, 2009M Used, 39M Free, 98% Inuse > > > > I've not seen this happen before on ZFS systems, so is it a regression > in 12? Hi It’s been a few months since I did the same thing so it’s not a recent issue. > > > -- > Rebecca Cran > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap. I've found it running out of memory when building ports via synth: I think I've also seen it when running a buildworld. Johannes on FreeBSDDesktop suggested it might be related to ZFS, and setting vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem. Shortly after running out of memory (with |"swap_pager_getswapspace(32): failed" messages)|, the first few lines of 'top' were: Mem: 4335M Active, 4854M Inact, 7751M Laundry, 9410M Wired, 48K Buf, 5332M Free ARC: 5235M Total, 4169M MFU, 497M MRU, 172K Anon, 97M Header, 471M Other 3479M Compressed, 5930M Uncompressed, 1.70:1 Ratio Swap: 2048M Total, 2009M Used, 39M Free, 98% Inuse I've not seen this happen before on ZFS systems, so is it a regression in 12? -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LLVM breaks buildworld
On Thu, Sep 27, 2018 at 10:32:35PM +0200, Dimitry Andric wrote: > On 27 Sep 2018, at 22:06, Steve Kargl > wrote: > > > > Hmmm, deleting the file MipsDSPInstrInfo.td seems to flip > > SHRD to SHRL. Oddly, 'svn diff' did not show a diff with > > the corrupt file. :(. > > Looks like one flipped bit, indeed. Maybe Subversion's pristine copy > was bad to begin with? > I took the system down, and ran fsck -y on my filesystems. Four of the 8 filesystems had so inconsistency. I'm afraid that parts of my system may be starting to show their age. Sorry about the noise. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LLVM breaks buildworld
On 27 Sep 2018, at 22:06, Steve Kargl wrote: > > On Thu, Sep 27, 2018 at 12:39:07PM -0700, Steve Kargl wrote: >> On Thu, Sep 27, 2018 at 12:34:39PM -0700, Steve Kargl wrote: >>> cd /usr/obj >>> rm -f usr >>> cd /usr/src >>> svn update >>> make buildworld >>> (wait a long time) >>> >>> ===> lib/clang/libllvm (all) >>> llvm-tblgen -gen-asm-matcher -I /usr/src/contrib/llvm/include -I >>> /usr/src/contrib/llvm/lib/Target/Mips -d MipsGenAsmMatcher.inc.d -o >>> MipsGenAsmMatcher.inc /usr/src/contrib/llvm/lib/Target/Mips/Mips.td >>> Included from /usr/src/contrib/llvm/lib/Target/Mips/Mips.td:57: >>> Included from /usr/src/contrib/llvm/lib/Target/Mips/MipsInstrInfo.td:3010: >>> /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:1142:25: error: >>> Couldn't find class 'SHRD_QB_ENC' >>> def SHRL_QB : DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC; >>>^ >> >> % find /usr/src/contrib/llvm -type f | xargs grep SHRD_QB >> /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:def SHRL_QB : >> DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC; >> >> >> This is only place under llvm that SHRD_QB appears? >> > > Hmmm, deleting the file MipsDSPInstrInfo.td seems to flip > SHRD to SHRL. Oddly, 'svn diff' did not show a diff with > the corrupt file. :(. Looks like one flipped bit, indeed. Maybe Subversion's pristine copy was bad to begin with? -Dimitry signature.asc Description: Message signed with OpenPGP
Re: LLVM breaks buildworld
On Thu, Sep 27, 2018 at 12:39:07PM -0700, Steve Kargl wrote: > On Thu, Sep 27, 2018 at 12:34:39PM -0700, Steve Kargl wrote: > > cd /usr/obj > > rm -f usr > > cd /usr/src > > svn update > > make buildworld > > (wait a long time) > > > > ===> lib/clang/libllvm (all) > > llvm-tblgen -gen-asm-matcher -I /usr/src/contrib/llvm/include -I > > /usr/src/contrib/llvm/lib/Target/Mips -d MipsGenAsmMatcher.inc.d -o > > MipsGenAsmMatcher.inc /usr/src/contrib/llvm/lib/Target/Mips/Mips.td > > Included from /usr/src/contrib/llvm/lib/Target/Mips/Mips.td:57: > > Included from /usr/src/contrib/llvm/lib/Target/Mips/MipsInstrInfo.td:3010: > > /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:1142:25: error: > > Couldn't find class 'SHRD_QB_ENC' > > def SHRL_QB : DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC; > > ^ > > % find /usr/src/contrib/llvm -type f | xargs grep SHRD_QB > > > /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:def SHRL_QB : > DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC; > > > This is only place under llvm that SHRD_QB appears? > Hmmm, deleting the file MipsDSPInstrInfo.td seems to flip SHRD to SHRL. Oddly, 'svn diff' did not show a diff with the corrupt file. :(. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LLVM breaks buildworld
On Thu, Sep 27, 2018 at 12:34:39PM -0700, Steve Kargl wrote: > cd /usr/obj > rm -f usr > cd /usr/src > svn update > make buildworld > (wait a long time) > > ===> lib/clang/libllvm (all) > llvm-tblgen -gen-asm-matcher -I /usr/src/contrib/llvm/include -I > /usr/src/contrib/llvm/lib/Target/Mips -d MipsGenAsmMatcher.inc.d -o > MipsGenAsmMatcher.inc /usr/src/contrib/llvm/lib/Target/Mips/Mips.td > Included from /usr/src/contrib/llvm/lib/Target/Mips/Mips.td:57: > Included from /usr/src/contrib/llvm/lib/Target/Mips/MipsInstrInfo.td:3010: > /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:1142:25: error: > Couldn't find class 'SHRD_QB_ENC' > def SHRL_QB : DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC; > ^ % find /usr/src/contrib/llvm -type f | xargs grep SHRD_QB /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:def SHRL_QB : DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC; This is only place under llvm that SHRD_QB appears? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LLVM breaks buildworld
cd /usr/obj rm -f usr cd /usr/src svn update make buildworld (wait a long time) ===> lib/clang/libllvm (all) llvm-tblgen -gen-asm-matcher -I /usr/src/contrib/llvm/include -I /usr/src/contrib/llvm/lib/Target/Mips -d MipsGenAsmMatcher.inc.d -o MipsGenAsmMatcher.inc /usr/src/contrib/llvm/lib/Target/Mips/Mips.td Included from /usr/src/contrib/llvm/lib/Target/Mips/Mips.td:57: Included from /usr/src/contrib/llvm/lib/Target/Mips/MipsInstrInfo.td:3010: /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:1142:25: error: Couldn't find class 'SHRD_QB_ENC' def SHRL_QB : DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC; ^ *** Error code 1 Stop. make[6]: stopped in /usr/src/lib/clang/libllvm *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/clang *** Error code 1 Stop. make[4]: stopped in /usr/src/lib *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
resume issues on ALPHA7
Hello, I am having issues resuming my system under ALPHA7. Under ALPHA5 I was able to suspend/resume my kabylake laptop without issues, but under ALPHA7 when I attempt to resume it seems to lock up (no input working from keyboard) requiring a hard reboot of my system. Not sure how I can debug this, so any tips would be appreciated. Here's my current dmesg: http://termbin.com/y4lk probably worth noting I've seen those ACPI errors since around ALPHA3 IIRC. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
zfs command dumps core
Hi List, # uname -a FreeBSD antares.takwa.de 12.0-ALPHA6 FreeBSD 12.0-ALPHA6 r338827 amd64 here, if I issue # zfs get all I get Assertion failed: (avl_find() succeeded inside avl_add()), file /usr/src/sys/cddl/contrib/opensolaris/common/avl/avl.c, line 649. Abort (core dumped) Thanks, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[REVISED] Update to 12.0-RELEASE schedule
The 12.0-RELEASE schedule will slip while last-minute work-in-progress continues to be completed before branching stable/12. At present, the project branch used to update OpenSSL to version 1.1.1 is expected to be ready to merge to head at some point early next week. As such, to err on the side of caution, the branch point of stable/12 is now planned for October 12 in order to plan for at least one ALPHA build before beginning the BETA build phase of the release cycle. The 12.0 schedule has been updated on the website at: https://www.freebsd.org/releases/12.0R/schedule.html Thank you in advance for your patience. Glen On behalf of: re@ signature.asc Description: PGP signature
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
> On 27 September 2018 at 06:46, tech-lists wrote: > > > > So, I want to know where and when each system was compiled. > > Why lose this information by default? > > This comes down to the simple fact that our build / release process > does not currently distinguish between building a world or kernel > that's destined for a binary release, and building for a bespoke > install. Right now the release process inherently builds with knobs > set at their defaults. > > The original plan would have flipped the default on the branch as part > of the release process, but there was a concern we might miss > something so it was enabled in advance of the branch. And as further information the plan is to flip this back off in ^head after the stable/12 branch is made, and then again, flip it off in stable/12 after the releng/12.0 branch is made, thus returning everything back to how it was, except in releng branch. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 27 September 2018 at 06:46, tech-lists wrote: > > So, I want to know where and when each system was compiled. > Why lose this information by default? This comes down to the simple fact that our build / release process does not currently distinguish between building a world or kernel that's destined for a binary release, and building for a bespoke install. Right now the release process inherently builds with knobs set at their defaults. The original plan would have flipped the default on the branch as part of the release process, but there was a concern we might miss something so it was enabled in advance of the branch. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
IPsec on ALPHA7 — reproducible crash
I have reproducible crash of ALPHA7 when I try to benchmark IPsec. Could somebody look at it? I could provide additional info, if needed. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659 -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL
On 11/09/2018 20:35, Ed Maste wrote: On 11 September 2018 at 07:35, Tomoaki AOKI wrote: I prefer releng, rather than stable, to make it default. Binary releases requiring reproducible builds are built from release and releng branches. This might be the reasonable long-term strategy, but we don't yet have experience running through the release process with it enabled. I would like to enable it by default on the branch, at least initially, to avoid discovering issues only immediately prior to the release. Hi, Personally I think this should (after testing on -current) be enabled only where binary-only updates (for everything) are anticipated. Then again, I don't run a binary-only system despite having to manage more than 16 systems. One reason is the hardware is all different, so different things are enabled in the kernel. The other reason is that I can reduce a machines security overhead if only what is required is available. This all requires source builds. So, I want to know where and when each system was compiled. Why lose this information by default? thanks, -- J. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"