Re: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory

2018-09-27 Thread Shane Ambler
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

2018-09-27 Thread Rebecca Cran
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

2018-09-27 Thread Pete Wright



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

2018-09-27 Thread Allan Jude
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

2018-09-27 Thread Johannes Lundberg
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

2018-09-27 Thread Rebecca Cran
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

2018-09-27 Thread Steve Kargl
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

2018-09-27 Thread Dimitry Andric
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

2018-09-27 Thread Steve Kargl
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

2018-09-27 Thread Steve Kargl
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

2018-09-27 Thread Steve Kargl
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

2018-09-27 Thread Pete Wright

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

2018-09-27 Thread Michael Schmiedgen

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

2018-09-27 Thread Glen Barber
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

2018-09-27 Thread Rodney W. Grimes
> 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

2018-09-27 Thread Ed Maste
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

2018-09-27 Thread Lev Serebryakov


 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

2018-09-27 Thread tech-lists

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"