Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Marcus Reid 
On Tue, Nov 04, 2014 at 06:13:44PM +, Steven Hartland wrote:
> 
> On 04/11/2014 17:22, Allan Jude wrote:
> > snip...
> > Justin Gibbs and I were helping George from Voxer look at the same issue
> > they are having. They had ~169GB in inact, and only ~60GB being used for
> > ARC.
> >
> > Are there any further debugging steps we can recommend to him to help
> > investigate this?
> The various scripts attached to the ZS ARC behavior problem and fix PR 
> will help provide detail this.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594
> 
> I've seen it here where there's been bursts of ZFS I/O specifically 
> write bursts.
> 
> What happens is that ZFS will consume large amounts of space in various 
> UMA zones to accommodate these bursts.

If you push the vmstat -z that he provided through the arc summary
script, you'll see that this is not what is happening.  His uma stats
match up with his arc, and do not account for his inactive memory.

uma script summary:

Totals
oused: 5.860GB, ofree: 1.547GB, ototal: 7.407GB
zused: 56.166GB, zfree: 3.918GB, ztotal: 60.084GB
used: 62.026GB, free: 5.465GB, total: 67.491GB

His provided top stats:

Mem: 19G Active, 20G Inact, 81G Wired, 59M Cache, 3308M Buf, 4918M Free
ARC: 66G Total, 6926M MFU, 54G MRU, 8069K Anon, 899M Header, 5129M Other   


The big uma buckets (zio_buf_16384 and zio_data_buf_131072, 18.002GB and
28.802GB respectively) are nearly 0% free.

Marcus

> The VM only triggers UMA reclaim when it sees pressure, however if the 
> main memory consumer is ZFS ARC its possible that the require pressure 
> will not be applied because when allocating ARC ZFS takes into account 
> free memory.
> 
> The result is it will back off its memory requirements before the 
> reclaim is triggered leaving all the space allocated but not used.
> 
> I was playing around with a patch, on that bug report, which added clear 
> down of UMA within ZFS ARC to avoid just this behavior, but its very 
> much me playing for testing the theory only.
> 
>  From what I've seen UMA needs something like the coloring which can be 
> used to trigger clear down over time to prevent UMA zones sitting their 
> eating large amounts of memory like they currently do.
> 
>  Regards
>  Steve
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #189

2014-11-04 Thread jenkins-admin 
See 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is back to normal : FreeBSD_HEAD #1773

2014-11-04 Thread jenkins-admin 
See 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Build failed in Jenkins: FreeBSD_HEAD #1772

2014-11-04 Thread dteske 
OK OK... my bad!

I wasn't doing buildworld for my test.

This should address the issue... (would love a quick test feedback)

Thank you so much, by the way.

http://svnweb.freebsd.org/base?view=revision&revision=274123

-- 
Devin

> -Original Message-
> From: Larry Rosenman [mailto:l...@lerctr.org]
> Sent: Tuesday, November 4, 2014 6:04 PM
> To: dte...@freebsd.org
> Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #1772
> 
> cc  -fpic -DPIC  -O2 -pipe -fno-omit-frame-pointer   -I/usr/src/lib/libdpv
-
> std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-
> y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -
> Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -
> Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-
> sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -
> Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
> /usr/src/lib/libdpv/dprompt.c -o dprompt.So
> ctfconvert -L VERSION dprompt.So
> ERROR: ctfconvert: dprompt.So doesn't have type data to convert
> cc  -fpic -DPIC  -O2 -pipe -fno-omit-frame-pointer   -I/usr/src/lib/libdpv
-
> std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-
> y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -
> Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -
> Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-
> sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -
> Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
> /usr/src/lib/libdpv/dpv.c -o dpv.So
> ctfconvert -L VERSION dpv.So
> ERROR: ctfconvert: dpv.So doesn't have type data to convert
> cc  -fpic -DPIC  -O2 -pipe -fno-omit-frame-pointer   -I/usr/src/lib/libdpv
-
> std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-
> y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -
> Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -
> Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-
> sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -
> Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
> /usr/src/lib/libdpv/status.c -o status.So
> ctfconvert -L VERSION status.So
> ERROR: ctfconvert: status.So doesn't have type data to convert
> cc  -fpic -DPIC  -O2 -pipe -fno-omit-frame-pointer   -I/usr/src/lib/libdpv
-
> std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-
> y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -
> Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -
> Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-
> sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -
> Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
> /usr/src/lib/libdpv/util.c -o util.So
> ctfconvert -L VERSION util.So
> ERROR: ctfconvert: util.So doesn't have type data to convert
> building shared library libdpv.so.1
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lfigpar
> cc: error: linker command failed with exit code 1 (use -v to see
invocation)
> *** Error code 1
> 
> Stop.
> make[5]: stopped in /usr/src/lib/libdpv
> *** 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
> ^C
> [1]   Done(1) nohup make -DNO_CLEAN buildworld buildkernel
> >>make.noc.out 2>&1
> borg.lerctr.org /usr/src #
> 
> borg.lerctr.org /usr/src # svn info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 274121
> Node Kind: directory
> Schedule: normal
> Last Changed Author: dteske
> Last Changed Rev: 274121
> Last Changed Date: 2014-11-04 19:57:32 -0600 (Tue, 04 Nov 2014)
> 
> borg.lerctr.org /usr/src #
> 
> On Tue, Nov 04, 2014 at 05:58:19PM -0800, dte...@freebsd.org wrote:
> > Actually... really fixed! ;D Thanks again!
> > http://svnweb.freebsd.org/base?view=revision&revision=274121
> >
> > --
> > Devin
> >
> > > -Original Message-
> > > From: de...@shxd.cx [mailto:de...@shxd.cx] On Behalf Of
> > > dte...@freebsd.org
> > > Sent: Tuesday, November 4, 2014 5:48 PM
> > > To: 'Larry Rosenman'
> > > Cc: dte...@freebsd.org
> > > Subject: RE: Build failed in Jenkins: FreeBSD_HEAD #1772
> > >
> > > Thanks!
> >

Re: HEADS UP: Enabling vt(4) by default

2014-11-04 Thread Chris H 
On Tue, 04 Nov 2014 18:22:06 +0100 Jean-Sébastien Pédron
 wrote

> Hello!
> 
> As announced a week ago, vt(4) is now the default console driver in
> 11-CURRENT as of r274085.
> 
> You may have to update your console settings in /etc/rc.conf. During
> boot, /etc/rc.d/syscons will indicate what you need to do.
> 
> The original HEADS UP mentioned several known issues. Among them, the
> following were fixed:
> 
> o  A video mode can be selected using the following tunable in
>/boot/loader.conf:
>kern.vt.fb.default_mode="1024x768"
> 
>This only works when using a KMS video driver. It's not
>supported by the VGA backend. See vt(4) man page for further
>documentation.
> 
> o  The keyboard was not working when kbdmux(4) was disabled. This
>is fixed.
> 
> o  After loading a KMS driver, the text cursor was in the middle of
>the kernel messages. The problem was that the cursor position was
>not updated after the change in window size. This is fixed.
> 
> Up-to-date information can be found on the wiki page:
> https://wiki.freebsd.org/Newcons
> 
> If you want to keep using syscons(4), you can add the following line to
> /boot/loader.conf:
> kern.vty=sc
> 
> Thank you to everyone who tested and reported problems! Please continue
> to do so, especially if you find the need to go back to syscons.

No. Thank _you_! :)

I was unable to determine from the wiki. But do all these wonderful
new features also work with the nVidia blob, under vt(4)?
I'm currently building a new 11-CURRENT from the 10-26 iso, as I write
this, and was wondering if the graphics mode at higher resolutions was
now possible using the nVidia blob.

Thank you again, for all your work on this!

--Chris

> 
> -- 
> Jean-Sébastien Pédron


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Build failed in Jenkins: FreeBSD_HEAD #1772

2014-11-04 Thread dteske 
Build is unbroken ;D Thanks! hehe (and sorry)

http://svnweb.freebsd.org/base?view=revision&revision=274121

shurd and I learned today that WARNS=6 means something
different on -CURRENT than on 9 or 10 (or at least, the 9 and 10
that I have deployed for my testing [smiles]).
-- 
Devin

> -Original Message-
> From: de...@shxd.cx [mailto:de...@shxd.cx] On Behalf Of
> dte...@freebsd.org
> Sent: Tuesday, November 4, 2014 5:35 PM
> To: freebsd-current@freebsd.org; dumbb...@freebsd.org;
> d...@freebsd.org; b...@freebsd.org; dte...@freebsd.org
> Subject: RE: Build failed in Jenkins: FreeBSD_HEAD #1772
> 
> Fixing!
> 
> Sorry! Pointy-Hat (really pointy)
> --
> Devin
> 
> > -Original Message-
> > From: jenkins-ad...@freebsd.org [mailto:jenkins-ad...@freebsd.org]
> > Sent: Tuesday, November 4, 2014 5:16 PM
> > To: jenkins-ad...@freebsd.org; freebsd-current@freebsd.org;
> > dumbb...@freebsd.org; d...@freebsd.org; b...@freebsd.org;
> > dte...@freebsd.org
> > Subject: Build failed in Jenkins: FreeBSD_HEAD #1772
> >
> > See
> > 
> >
> > Changes:
> >
> > [dumbbell] vt(4): Support syscons' SC_HISTORY_SIZE to configure history
> size
> >
> > Therefore, to set histry size to 2000 lines, add the following line to
> > your kernel configuration file:
> > options SC_HISTORY_SIZE=2000
> >
> > The default history remains at 500 lines.
> >
> > MFC after:  1 week
> >
> > [dteske] Add new libraries/utilities for data throughput visualization.
> > dpv(3): dialog progress view library
> > dpv(1): stream data from stdin or multiple paths with dialog progress view
> > figpar(3): configuration file parsing library
> >
> > Reviews:D714
> > Reviewed by:jelischer, shurd
> > Discussed at:   MeetBSD California 2014 Vendor/Dev Summit
> > Discussed on:   -current
> > MFC after:  21 days
> > X-MFC-to:   stable/10 stable/9
> >
> > [des] [SA-14:25] Fix kernel stack disclosure in setlogin(2) / getlogin(2).
> > [SA-14:26] Fix remote command execution in ftp(1).
> >
> > Approved by:so (des)
> >
> > [bapt] Partially fix indentation issues to improve readability helping
> > cooperation with
> > Dragonfly folks
> >
> > PR: 194785
> > Submitted by:   François Tigeot (ftig...@wolfpond.org)
> >
> > [des] When reseeding the DPRNG, we're supposed to hash the current key
> > and
> > some accumulated entropy twice and use that as the new key.  Due to a
> > typo, we were using the output of the first hash round instead of the
> > second.  Correct this, but eliminate temp[] since we can reuse hash[].
> > Also add comments explaining what is going on and why.
> >
> > Noticed by: Sami Farin 
> > Reviewed by:markm@
> > Approved by:so (des)
> >
> > --
> > [...truncated 97827 lines...]
> > --- all_subdir_libcalendar ---
> > --- easter.So ---
> > cc  -fpic -DPIC  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -
> > Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-
> > prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-
> > qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-
> align
> > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-
> > style-definition -Wno-pointer-sign -Wmissing-variable-declarations -
> > Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-
> > const-variable -Qunused-arguments -c
> >
>  > /easter.c> -o easter.So
> > --- all_subdir_libbsm ---
> > --- bsm_fcntl.So ---
> > cc  -fpic -DPIC  -O2 -pipe   -
> >
> I > ./contrib/openbsm> -
> >
> I > ./contrib/openbsm/libbsm> -std=gnu99 -fstack-protector -Wsystem-
> headers
> > -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-
> > unused-const-variable -Wno-tautological-compare -Wno-unused-value -
> > Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -
> > Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-
> > parentheses -Qunused-arguments -c
> >
>  > /contrib/openbsm/libbsm/bsm_fcntl.c> -o bsm_fcntl.So
> > --- bsm_flags.So ---
> > cc  -fpic -DPIC  -O2 -pipe   -
> >
> I > ./contrib/openbsm> -
> >
> I > ./contrib/openbsm/libbsm> -std=gnu99 -fstack-protector -Wsystem-
> headers
> > -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-
> > unused-const-variable -Wno-tautological-compare -Wno-unused-value -
> > Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -
> > Wno-switch -Wno-switch-enum -Wno-knr-promoted-param

RE: Build failed in Jenkins: FreeBSD_HEAD #1772

2014-11-04 Thread dteske 
Fixing!

Sorry! Pointy-Hat (really pointy)
-- 
Devin

> -Original Message-
> From: jenkins-ad...@freebsd.org [mailto:jenkins-ad...@freebsd.org]
> Sent: Tuesday, November 4, 2014 5:16 PM
> To: jenkins-ad...@freebsd.org; freebsd-current@freebsd.org;
> dumbb...@freebsd.org; d...@freebsd.org; b...@freebsd.org;
> dte...@freebsd.org
> Subject: Build failed in Jenkins: FreeBSD_HEAD #1772
> 
> See
> 
> 
> Changes:
> 
> [dumbbell] vt(4): Support syscons' SC_HISTORY_SIZE to configure history size
> 
> Therefore, to set histry size to 2000 lines, add the following line to
> your kernel configuration file:
> options SC_HISTORY_SIZE=2000
> 
> The default history remains at 500 lines.
> 
> MFC after:1 week
> 
> [dteske] Add new libraries/utilities for data throughput visualization.
> dpv(3): dialog progress view library
> dpv(1): stream data from stdin or multiple paths with dialog progress view
> figpar(3): configuration file parsing library
> 
> Reviews:  D714
> Reviewed by:  jelischer, shurd
> Discussed at: MeetBSD California 2014 Vendor/Dev Summit
> Discussed on: -current
> MFC after:21 days
> X-MFC-to: stable/10 stable/9
> 
> [des] [SA-14:25] Fix kernel stack disclosure in setlogin(2) / getlogin(2).
> [SA-14:26] Fix remote command execution in ftp(1).
> 
> Approved by:  so (des)
> 
> [bapt] Partially fix indentation issues to improve readability helping
> cooperation with
> Dragonfly folks
> 
> PR:   194785
> Submitted by: François Tigeot (ftig...@wolfpond.org)
> 
> [des] When reseeding the DPRNG, we're supposed to hash the current key
> and
> some accumulated entropy twice and use that as the new key.  Due to a
> typo, we were using the output of the first hash round instead of the
> second.  Correct this, but eliminate temp[] since we can reuse hash[].
> Also add comments explaining what is going on and why.
> 
> Noticed by:   Sami Farin 
> Reviewed by:  markm@
> Approved by:  so (des)
> 
> --
> [...truncated 97827 lines...]
> --- all_subdir_libcalendar ---
> --- easter.So ---
> cc  -fpic -DPIC  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -
> Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-
> prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-
> qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-
> style-definition -Wno-pointer-sign -Wmissing-variable-declarations -
> Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-
> const-variable -Qunused-arguments -c
>  /easter.c> -o easter.So
> --- all_subdir_libbsm ---
> --- bsm_fcntl.So ---
> cc  -fpic -DPIC  -O2 -pipe   -
> I ./contrib/openbsm> -
> I ./contrib/openbsm/libbsm> -std=gnu99 -fstack-protector -Wsystem-headers
> -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-
> unused-const-variable -Wno-tautological-compare -Wno-unused-value -
> Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -
> Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-
> parentheses -Qunused-arguments -c
>  /contrib/openbsm/libbsm/bsm_fcntl.c> -o bsm_fcntl.So
> --- bsm_flags.So ---
> cc  -fpic -DPIC  -O2 -pipe   -
> I ./contrib/openbsm> -
> I ./contrib/openbsm/libbsm> -std=gnu99 -fstack-protector -Wsystem-headers
> -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-
> unused-const-variable -Wno-tautological-compare -Wno-unused-value -
> Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -
> Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-
> parentheses -Qunused-arguments -c
>  /contrib/openbsm/libbsm/bsm_flags.c> -o bsm_flags.So
> --- all_subdir_libcalendar ---
> --- calendar.o ---
> cc   -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -
> Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-
> strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-
> subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-
> definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-
> safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -
> Qunused-arguments -c
>  /calendar.c> -o calenda

dpv: lots of errors, breaks WORLD

2014-11-04 Thread Larry Rosenman 

--- all_subdir_libdpv ---
static struct config dialogrc_config[] = {
^
/usr/src/lib/libdpv/dialogrc.h:53:8: note: forward declaration of 
'struct config'

struct config   *dialogrc_config_option(const char *_directive);
   ^
/usr/src/lib/libdpv/dialogrc.c:64:6: error: use of undeclared identifier 
'TYPE_INT'
{TYPE_INT,  "aspect",   {(void *)0},
&setnum},

 ^
/usr/src/lib/libdpv/dialogrc.c:65:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "separate_widget",  {separator},
&setstr},

 ^
/usr/src/lib/libdpv/dialogrc.c:66:6: error: use of undeclared identifier 
'TYPE_INT'
{TYPE_INT,  "tab_len",  {(void *)0},
&setnum},

 ^
/usr/src/lib/libdpv/dialogrc.c:67:6: error: use of undeclared identifier 
'TYPE_BOOL'; did you mean 'FP_TYPE_BOOL'?
{TYPE_BOOL, "visit_items",  {(void *)0},
&setbool},

 ^
 FP_TYPE_BOOL
/usr/obj/usr/src/tmp/usr/include/figpar.h:51:2: note: 'FP_TYPE_BOOL' 
declared here

FP_TYPE_BOOL= 0x0001, /* boolean */
^
/usr/src/lib/libdpv/dialogrc.c:68:6: error: use of undeclared identifier 
'TYPE_BOOL'; did you mean 'FP_TYPE_BOOL'?
{TYPE_BOOL, "use_shadow",   {(void *)1},
&setbool},

 ^
 FP_TYPE_BOOL
/usr/obj/usr/src/tmp/usr/include/figpar.h:51:2: note: 'FP_TYPE_BOOL' 
declared here

FP_TYPE_BOOL= 0x0001, /* boolean */
^
/usr/src/lib/libdpv/dialogrc.c:69:6: error: use of undeclared identifier 
'TYPE_BOOL'; did you mean 'FP_TYPE_BOOL'?
{TYPE_BOOL, "use_colors",   {(void *)1},
&setbool},

 ^
 FP_TYPE_BOOL
/usr/obj/usr/src/tmp/usr/include/figpar.h:51:2: note: 'FP_TYPE_BOOL' 
declared here

FP_TYPE_BOOL= 0x0001, /* boolean */
^
--- all_subdir_libdevinfo ---
ERROR: ctfmerge: No ctf sections found to merge
--- all_subdir_libdpv ---
/usr/src/lib/libdpv/dialogrc.c:70:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "screen_color", {NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:71:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "shadow_color", {NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:72:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "dialog_color", {NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:73:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "title_color",  {NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:74:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "border_color", {NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:75:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "button_active_color",  {NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:76:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "button_inactive_color",{NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:77:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "button_key_active_color",  {NULL}, 
&setattr},

 ^
/usr/src/lib/libdpv/dialogrc.c:78:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "button_key_inactive_color",{NULL}, 
&setattr},

 ^
--- all_subdir_libkvm ---
===> lib/libkvm (all)
--- all_subdir_libdpv ---
/usr/src/lib/libdpv/dialogrc.c:79:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "button_label_active_color",{NULL}, 
&setattr},

 ^

--- all_subdir_libdpv ---
static struct config dialogrc_config[] = {
^
/usr/src/lib/libdpv/dialogrc.h:53:8: note: forward declaration of 
'struct config'

struct config   *dialogrc_config_option(const char *_directive);
   ^
/usr/src/lib/libdpv/dialogrc.c:64:6: error: use of undeclared identifier 
'TYPE_INT'
{TYPE_INT,  "aspect",   {(void *)0},
&setnum},

 ^
/usr/src/lib/libdpv/dialogrc.c:65:6: error: use of undeclared identifier 
'TYPE_STR'
{TYPE_STR,  "separate_widget",  {separator},
&setstr},

 ^
/usr/src/lib/libdpv/dialogrc.c:66:6: error: use of undeclared identifier 
'TYPE_INT'
{TYPE_INT,  "tab_len",  {(void *)0},
&setnum},

 ^
/usr/src/lib/libdpv/dialogrc.c:67:6: error: use of undeclared identifier 
'TYPE_BOOL'; did you mean 'FP_TYPE_BOOL'?
{TYPE_BOOL, "visit_items",  {(void *)0},
&setbool},

 ^
 FP_TYPE_BOOL
/usr/obj/usr/src/tmp/usr/include/figpar.h:51:2: note: 'FP_TYPE_BOOL' 
declared here

FP_TYPE_BOOL= 0x0001, /* boolean */
^
/usr/src/lib/libdpv/dialogrc.c:68:6: error: use of undeclared identifier 
'TYPE_BOO

Build failed in Jenkins: FreeBSD_HEAD #1772

2014-11-04 Thread jenkins-admin 
See 

Changes:

[dumbbell] vt(4): Support syscons' SC_HISTORY_SIZE to configure history size

Therefore, to set histry size to 2000 lines, add the following line to
your kernel configuration file:
options SC_HISTORY_SIZE=2000

The default history remains at 500 lines.

MFC after:  1 week

[dteske] Add new libraries/utilities for data throughput visualization.
dpv(3): dialog progress view library
dpv(1): stream data from stdin or multiple paths with dialog progress view
figpar(3): configuration file parsing library

Reviews:D714
Reviewed by:jelischer, shurd
Discussed at:   MeetBSD California 2014 Vendor/Dev Summit
Discussed on:   -current
MFC after:  21 days
X-MFC-to:   stable/10 stable/9

[des] [SA-14:25] Fix kernel stack disclosure in setlogin(2) / getlogin(2).
[SA-14:26] Fix remote command execution in ftp(1).

Approved by:so (des)

[bapt] Partially fix indentation issues to improve readability helping 
cooperation with
Dragonfly folks

PR: 194785
Submitted by:   François Tigeot (ftig...@wolfpond.org)

[des] When reseeding the DPRNG, we're supposed to hash the current key and
some accumulated entropy twice and use that as the new key.  Due to a
typo, we were using the output of the first hash round instead of the
second.  Correct this, but eliminate temp[] since we can reuse hash[].
Also add comments explaining what is going on and why.

Noticed by: Sami Farin 
Reviewed by:markm@
Approved by:so (des)

--
[...truncated 97827 lines...]
--- all_subdir_libcalendar ---
--- easter.So ---
cc  -fpic -DPIC  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c 

 -o easter.So
--- all_subdir_libbsm ---
--- bsm_fcntl.So ---
cc  -fpic -DPIC  -O2 -pipe   
-I
 
-I
 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c 

 -o bsm_fcntl.So
--- bsm_flags.So ---
cc  -fpic -DPIC  -O2 -pipe   
-I
 
-I
 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c 

 -o bsm_flags.So
--- all_subdir_libcalendar ---
--- calendar.o ---
cc   -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c 

 -o calendar.o
--- easter.o ---
cc   -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c

Re: Jenkins build is unstable: FreeBSD_HEAD-tests2 #188

2014-11-04 Thread Garrett Cooper 
On Nov 4, 2014, at 15:10, jenkins-ad...@freebsd.org wrote:

> See 

Hi!
I’ve filed the following bugs to track these failures. I’ll closely 
monitor the tests for another couple hours, then open up reviews to fix the 
issues noted:
- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194828
- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194829
Thank you!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Jenkins build is unstable: FreeBSD_HEAD-tests2 #188

2014-11-04 Thread jenkins-admin 
See 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #187

2014-11-04 Thread Garrett Cooper 
On Nov 4, 2014, at 12:09, jenkins-ad...@freebsd.org wrote:

> See 

...

Hi Craig/Jenkins admins,
I opened a pull request to increase the timeout from 1 to 2 hours when 
running "kyua test”: https://github.com/freebsd/freebsd-ci/pull/1/files .
Thank you!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Build failed in Jenkins: FreeBSD_HEAD-tests2 #187

2014-11-04 Thread jenkins-admin 
See 

--
[...truncated 3505 lines...]
local/lutok/state_test:set_metatable  ->  passed  [0.024s]
local/lutok/state_test:set_table__ok  ->  passed  [0.023s]
local/lutok/state_test:set_table__nil  ->  passed  [0.026s]
local/lutok/state_test:to_boolean  ->  passed  [0.025s]
local/lutok/state_test:to_integer  ->  passed  [0.027s]
local/lutok/state_test:to_string  ->  passed  [0.026s]
local/lutok/state_test:to_userdata  ->  passed  [0.028s]
local/lutok/state_test:upvalue_index  ->  passed  [0.027s]
libexec/atf/atf-check/atf-check_test:sflag_eq_ne  ->  passed  [0.162s]
libexec/atf/atf-check/atf-check_test:sflag_exit  ->  passed  [0.199s]
libexec/atf/atf-check/atf-check_test:sflag_ignore  ->  passed  [0.089s]
libexec/atf/atf-check/atf-check_test:sflag_signal  ->  passed  [0.211s]
libexec/atf/atf-check/atf-check_test:xflag  ->  passed  [0.120s]
libexec/atf/atf-check/atf-check_test:oflag_empty  ->  passed  [0.090s]
libexec/atf/atf-check/atf-check_test:oflag_ignore  ->  passed  [0.085s]
libexec/atf/atf-check/atf-check_test:oflag_file  ->  passed  [0.133s]
libexec/atf/atf-check/atf-check_test:oflag_inline  ->  passed  [0.230s]
libexec/atf/atf-check/atf-check_test:oflag_match  ->  passed  [0.151s]
libexec/atf/atf-check/atf-check_test:oflag_save  ->  passed  [0.073s]
libexec/atf/atf-check/atf-check_test:oflag_multiple  ->  passed  [0.130s]
libexec/atf/atf-check/atf-check_test:oflag_negated  ->  passed  [0.123s]
libexec/atf/atf-check/atf-check_test:eflag_empty  ->  passed  [0.086s]
libexec/atf/atf-check/atf-check_test:eflag_ignore  ->  passed  [0.087s]
libexec/atf/atf-check/atf-check_test:eflag_file  ->  passed  [0.135s]
libexec/atf/atf-check/atf-check_test:eflag_inline  ->  passed  [0.206s]
libexec/atf/atf-check/atf-check_test:eflag_match  ->  passed  [0.136s]
libexec/atf/atf-check/atf-check_test:eflag_save  ->  passed  [0.074s]
libexec/atf/atf-check/atf-check_test:eflag_multiple  ->  passed  [0.134s]
libexec/atf/atf-check/atf-check_test:eflag_negated  ->  passed  [0.123s]
libexec/atf/atf-check/atf-check_test:stdin  ->  passed  [0.068s]
libexec/atf/atf-check/atf-check_test:invalid_umask  ->  passed  [0.062s]
libexec/atf/atf-sh/atf_check_test:info_ok  ->  passed  [0.152s]
libexec/atf/atf-sh/atf_check_test:expout_mismatch  ->  passed  [0.130s]
libexec/atf/atf-sh/atf_check_test:experr_mismatch  ->  passed  [0.130s]
libexec/atf/atf-sh/atf_check_test:null_stdout  ->  passed  [0.122s]
libexec/atf/atf-sh/atf_check_test:null_stderr  ->  passed  [0.124s]
libexec/atf/atf-sh/atf_check_test:equal  ->  passed  [0.249s]
libexec/atf/atf-sh/atf_check_test:flush_stdout_on_timeout  ->  passed  [1.122s]
libexec/atf/atf-sh/config_test:has  ->  passed  [0.203s]
libexec/atf/atf-sh/config_test:get  ->  passed  [0.147s]
libexec/atf/atf-sh/integration_test:no_args  ->  passed  [0.064s]
libexec/atf/atf-sh/integration_test:missing_script  ->  passed  [0.062s]
libexec/atf/atf-sh/integration_test:arguments  ->  passed  [0.095s]
libexec/atf/atf-sh/integration_test:custom_shell__command_line  ->  passed  
[0.081s]
libexec/atf/atf-sh/integration_test:custom_shell__shebang  ->  passed  [0.082s]
libexec/atf/atf-sh/integration_test:set_e  ->  passed  [0.086s]
libexec/atf/atf-sh/normalize_test:main  ->  passed  [0.104s]
libexec/atf/atf-sh/tc_test:default_status  ->  passed  [0.230s]
libexec/atf/atf-sh/tc_test:missing_body  ->  passed  [0.086s]
libexec/atf/atf-sh/tp_test:srcdir  ->  passed  [0.116s]
libexec/rtld-elf/ld_library_pathfds:missing_library  ->  passed  [0.034s]
libexec/rtld-elf/ld_library_pathfds:wrong_library_directories  ->  passed  
[0.028s]
libexec/rtld-elf/ld_library_pathfds:bad_library_directories  ->  passed  
[0.029s]
libexec/rtld-elf/ld_library_pathfds:single_library_directory  ->  passed  
[0.032s]
libexec/rtld-elf/ld_library_pathfds:first_library_directory  ->  passed  
[0.029s]
libexec/rtld-elf/ld_library_pathfds:middle_library_directory  ->  passed  
[0.030s]
libexec/rtld-elf/ld_library_pathfds:last_library_directory  ->  passed  [0.031s]
sbin/devd/client_test:seqpacket  ->  passed  [0.049s]
sbin/devd/client_test:stream  ->  passed  [0.045s]
sbin/dhclient/option-domain-search_test:main  ->  passed  [0.023s]
sbin/growfs/legacy_test:main  ->  passed  [13.539s]
sbin/mdconfig/legacy_test:main  ->  passed  [0.695s]
usr.bin/cut/cut_test:basic  ->  passed  [0.144s]
usr.bin/cut/cut_test:sflag  ->  passed  [0.074s]
usr.bin/cut/cut_test:dflag  ->  passed  [0.099s]
usr.bin/cut/cut_test:dsflag  ->  passed  [0.077s]
usr.bin/cut/cut_test:latin1  ->  passed  [0.071s]
usr.bin/cut/cut_test:utf8  ->  passed  [0.096s]
usr.bin/lastcomm/legacy_test:main  ->  passed  [0.089s]
usr.bin/mkimg/mkimg:apm_1x1_512_qcow  ->  passed  [1.126s]
usr.bin/mkimg/mkimg:apm_1x1_512_qcow2  ->  passed  [0.629s]
usr.bin/mkimg/mkimg:apm_1x1_512_raw  ->  passed  [0.669s]
usr.bin/mkimg/mkimg:apm_1x1_512_vhd  ->  passed  [0.814s]
usr.bin/mkimg/mkimg:apm_1x1_512_vhdf  ->  p

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Miguel Clara 
On Tue, Nov 4, 2014 at 5:10 PM, Allan Jude  wrote:

> On 11/04/2014 11:17, Kris Moore wrote:
> > On 11/04/2014 10:24, Kurt Jaeger wrote:
> >> Hi!
> >>
> >>> If you don't need any USB devices to boot, you can delay their
> >>> detection by loading the modules through /etc/rc.d/kld instead
> >>> of the loader:
> >>>
> >>> fk@r500 ~ $grep kld /etc/rc.conf
> >>> kld_list="usb.ko usb_quirk.ko ehci.ko umass.ko"
> >> Does this really help with the GENERIC kernel ?
> >>
> >> If I add this to /etc/rc.conf and do
> >>
> >> /etc/rc.d/kld start
> >>
> >> this spews a load of errors.
> >>
> >
> > Colin added this to HEAD recently:
> >
> >
> https://github.com/freebsd/freebsd/commit/bdb0ac02b9fd8f331fa70c8a4c29495b7ee43293
> >
> > This will allow setting the passphrase at the boot-loader, so it doesn't
> > get prompted for again during boot. I think there was some work by
> > dteske@ to add this to the FreeBSD boot menus, but maybe you can use it
> > manually for now.
> >
> > We are using it in PC-BSD to supply the passphrase directly from GRUB,
> > so we only get prompted a single time.
> >
> > (Before somebody asks why we use grub)
> > We are using grub to do full-disk encryption, without a unencrypted
> > /boot, among other things :)
> >
> >
>
> Yes, as Kris mentioned, the solution is being working on here at MeetBSD
> by dteske@ (with some advice from jmg@) at the request of cperciva@,
> using the functionality Colin added to head for Kris to be able to do
> this for PCBSD.
>
> Hopefully this problem will be solved soon.
>
>
Seems interesting, but if I got it right, for now the boot loader still
doesn't have a way to pass this right?

Could I for example drop to prompt and set "g_eli_boot_passcache"? and ofc
in the future it would be ideal to do it from/during the boot menu.
However it should should only do it if  "root" is encrypted right (not just
if geli is loaded, cause it might not be used for root... say a user just
encrypts the /home dir, in that case having this on boot is not needed).
But if there's a way to tell the root device is encrypted at boot time,
then It would be the perfect solution indeed!

Pity is only usable with grub for now, but still nice to see its being
worked!

Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: current panic: Lock (sx) random_adaptors not locked @

2014-11-04 Thread Xin Li 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/04/14 06:01, Julian H. Stacey wrote:
> Hi current@
> 
> Maybe this is a transient no one else will see ?: with no
> /boot/loader.conf, my old custom kernel booted & my new one
> paniced:
> 
> panic: Lock (sx) random_adaptors not locked @
> dev/random/random_adaptors.c:278

This was fixed in r274006 FYI.

Cheers,
- -- 
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQIcBAEBCgAGBQJUWRmsAAoJEJW2GBstM+nsvZEP/1JKJsptJGPrkOfhE9MznH03
dD9TeDN1fZUvi+54ZZue78SS/hE4/Nbga62nWc5ml8mZkHwrEF/N1+xgHR5Scfw9
EPFFY/bvmzAB9AKDyFLPC7IYLCQ+G9lZKbkNbeSc8q4tze0nmc4Sgpum1FVstS46
njU9cnhIJZ9yScVkofhBuaAeGgbD5w4zK6Ezr1aLdfhTil2cs9nZlN2fuRBTDIot
v8PS52ZZw2pQJZ9SSZaYlB9fbT5vsH3cCUzxFpr5EH7oJdlNs6fPknYoy+2q4SkT
9yjIg+P96jdB42c0HaSO7DvJOzDIrtG8Dy1hMDpxJUkHodwa0HqQWNRYDZ8t3d2f
gEgwwO3/t8H6jyzPqPIwFj5nQuI6ErKfwDOUm/kORWy18zFiApDHhiAltMPsryCo
nz3swJEgmW//viYEW25Yi/WHEBvzrTa3736Q/r5/I6Ssz2nJX/wehuRQ4+pPHKGx
OponYjXeXlHj/1dVjdnieYgC+aCVSQTBiF5i+QBV6gD+NvLosjH2u73aQ73lQisD
AUiGw7AvwfuDaxvqhjT+hu69hCrpRcDhL9QEJZ6TmoPOnL0kaz70iVfO9khEoObr
MbODB+eqDn7j2tZ+klVWagRgFyjRX7uCGi9A3wLD43nvcd7wquNJVRFnSxN3NJD2
hhlH+sXhtcxZcyhwjWo3
=nu2x
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Steven Hartland 


On 04/11/2014 17:57, Ben Perrault wrote:

snip...

I would also be interested in any additional debugging steps and would be 
willing to help test in any way I can - as I've seen the behavior a few times 
as well. As recently a Sunday evening, I caught a system running with ~44GB ARC 
but ~117GB inactive.


You should find the UMA summary script quite helpful in this regard:
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147754
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Steven Hartland 


On 04/11/2014 17:22, Allan Jude wrote:

snip...
Justin Gibbs and I were helping George from Voxer look at the same issue
they are having. They had ~169GB in inact, and only ~60GB being used for
ARC.

Are there any further debugging steps we can recommend to him to help
investigate this?
The various scripts attached to the ZS ARC behavior problem and fix PR 
will help provide detail this.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594

I've seen it here where there's been bursts of ZFS I/O specifically 
write bursts.


What happens is that ZFS will consume large amounts of space in various 
UMA zones to accommodate these bursts.


The VM only triggers UMA reclaim when it sees pressure, however if the 
main memory consumer is ZFS ARC its possible that the require pressure 
will not be applied because when allocating ARC ZFS takes into account 
free memory.


The result is it will back off its memory requirements before the 
reclaim is triggered leaving all the space allocated but not used.


I was playing around with a patch, on that bug report, which added clear 
down of UMA within ZFS ARC to avoid just this behavior, but its very 
much me playing for testing the theory only.


From what I've seen UMA needs something like the coloring which can be 
used to trigger clear down over time to prevent UMA zones sitting their 
eating large amounts of memory like they currently do.


Regards
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Ben Perrault 


> On Nov 4, 2014, at 9:22 AM, Allan Jude  wrote:
> 
>> On 11/04/2014 08:22, Dmitriy Makarov wrote:
>> ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
>> 
>> UMA Kegs:   384,  0, 210,  10, 216,   0,   0
>> UMA Zones: 2176,  0, 210,   0, 216,   0,   0
>> UMA Slabs:   80,  0, 2921231, 1024519,133906002,   0,   0
>> UMA RCntSlabs:   88,  0,8442,1863,  771451,   0,   0
>> UMA Hash:   256,  0,   2,  28,  79,   0,   0
>> 4 Bucket:32,  0,5698,   16052,424047094,   0,   0
>> 6 Bucket:48,  0, 220,8993,77454827,   0,   0
>> 8 Bucket:64,  0, 260,6808,56285069,  15,   0
>> 12 Bucket:   96,  0, 302,2568,42712743, 192,   0
>> 16 Bucket:  128,  0,1445,1903,86971183,   0,   0
>> 32 Bucket:  256,  0, 610,2870,96758244, 215,   0
>> 64 Bucket:  512,  0,1611,1117,55896361,77166469,   0
>> 128 Bucket:1024,  0, 413, 635,99338830,104451029,  
>> 0
>> 256 Bucket:2048,  0,1100, 222,164776092,24917372,  
>> 0
>> vmem btag:   56,  0, 1889493,  502639,30117503,16948,   0
>> VM OBJECT:  256,  0,  970434,  174126,1080667061,   0,   0
>> RADIX NODE: 144,  0, 2792188,  882809,1489929489,   0,   0
>> MAP:240,  0,   3,  61,   3,   0,   0
>> KMAP ENTRY: 128,  0,  13, 173,  37,   0,   0
>> MAP ENTRY:  128,  0,   82182,   11624,3990141990,   0,   0
>> VMSPACE:496,  0, 615, 761,41838231,   0,   0
>> fakepg: 104,  0,   0,   0,   0,   0,   0
>> mt_zone:  16400,  0, 261,   0, 267,   0,   0
>> 16:  16,  0, 3650397, 6166213,6132198534,   0,   0
>> 32:  32,  0, 1118176,  259824,9115561085,   0,   0
>> 64:  64,  0,14496058,14945820,11266627738,   0,   0
>> 128:128,  0, 1337428,  319398,15463968444,   0,   0
>> 256:256,  0, 1103937,  258183,8392009677,   0,   0
>> 512:512,  0,1714, 470,7174436957,   0,   0
>> 1024:  1024,  0,   29033, 347,131133987,   0,   0
>> 2048:  2048,  0, 869, 275,1001770010,   0,   0
>> 4096:  4096,  0,  730319,3013,332721996,   0,   0
>> 8192:  8192,  0,  47,  11,  487154,   0,   0
>> 16384:16384,  0,  65,   5,1788,   0,   0
>> 32768:32768,  0,  54,  13,  103482,   0,   0
>> 65536:65536,  0, 627,   8, 8172809,   0,   0
>> SLEEPQUEUE:  80,  0,1954,1053,2812,   0,   0
>> 64 pcpu:  8,  0, 558, 594, 793,   0,   0
>> Files:   80,  0,   16221,2579,1549799224,   0,   0
>> TURNSTILE:  136,  0,1954, 506,2812,   0,   0
>> rl_entry:40,  0,1114,2186,1114,   0,   0
>> umtx pi: 96,  0,   0,   0,   0,   0,   0
>> MAC labels:  40,  0,   0,   0,   0,   0,   0
>> PROC:  1208,  0, 635, 514,41838196,   0,   0
>> THREAD:1168,  0,1840, 113,   12778,   0,   0
>> cpuset:  96,  0, 705, 361,1490,   0,   0
>> audit_record:  1248,  0,   0,   0,   0,   0,   0
>> sendfile_sync:  128,  0,   0,   0,   0,   0,   0
>> mbuf_packet:256, 46137345,8199,5074,15123806588,   0,  
>> 0
>> mbuf:   256, 46137345,   25761,   13076,21621129305,   0,  
>> 0
>> mbuf_cluster:  2048, 7208960,   13273, 315, 2905465,   0,   0
>> mbuf_jumbo_page:   4096, 3604480, 786, 862,628074105,   0,   0
>> mbuf_jumbo_9k: 9216, 1067994,   0,   0,   0,   0,   0
>> mbuf_jumbo_16k:   16384, 600746,   0,   0,   0,   0,   0
>> mbuf_ext_refcnt:  4,  0,   0,   0,   0,   0,   0
>> g_bio:  248,  0,  36,2348,2894002696,   0,   0
>> DMAR_MAP_ENTRY: 120,  0,   0,   0,   0,   0,   0
>> ttyinq: 160,  0, 180, 195,4560,   0,   0
>> ttyoutq:256,  0,  95, 190,2364,   0,   0
>> FPU_save_area:  832,  0,   0,   0,   0,   0,   0
>> taskq_zone:  48,  0,   0,4814,108670448,   0,   0
>> VNODE:  472,  0, 1115838,  293402,379118791,   0,   0
>> VNODEPOLL:  112,

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Allan Jude 
On 11/04/2014 08:22, Dmitriy Makarov wrote:
> ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
> 
> UMA Kegs:   384,  0, 210,  10, 216,   0,   0
> UMA Zones: 2176,  0, 210,   0, 216,   0,   0
> UMA Slabs:   80,  0, 2921231, 1024519,133906002,   0,   0
> UMA RCntSlabs:   88,  0,8442,1863,  771451,   0,   0
> UMA Hash:   256,  0,   2,  28,  79,   0,   0
> 4 Bucket:32,  0,5698,   16052,424047094,   0,   0
> 6 Bucket:48,  0, 220,8993,77454827,   0,   0
> 8 Bucket:64,  0, 260,6808,56285069,  15,   0
> 12 Bucket:   96,  0, 302,2568,42712743, 192,   0
> 16 Bucket:  128,  0,1445,1903,86971183,   0,   0
> 32 Bucket:  256,  0, 610,2870,96758244, 215,   0
> 64 Bucket:  512,  0,1611,1117,55896361,77166469,   0
> 128 Bucket:1024,  0, 413, 635,99338830,104451029,  
> 0
> 256 Bucket:2048,  0,1100, 222,164776092,24917372,  
> 0
> vmem btag:   56,  0, 1889493,  502639,30117503,16948,   0
> VM OBJECT:  256,  0,  970434,  174126,1080667061,   0,   0
> RADIX NODE: 144,  0, 2792188,  882809,1489929489,   0,   0
> MAP:240,  0,   3,  61,   3,   0,   0
> KMAP ENTRY: 128,  0,  13, 173,  37,   0,   0
> MAP ENTRY:  128,  0,   82182,   11624,3990141990,   0,   0
> VMSPACE:496,  0, 615, 761,41838231,   0,   0
> fakepg: 104,  0,   0,   0,   0,   0,   0
> mt_zone:  16400,  0, 261,   0, 267,   0,   0
> 16:  16,  0, 3650397, 6166213,6132198534,   0,   0
> 32:  32,  0, 1118176,  259824,9115561085,   0,   0
> 64:  64,  0,14496058,14945820,11266627738,   0,   0
> 128:128,  0, 1337428,  319398,15463968444,   0,   0
> 256:256,  0, 1103937,  258183,8392009677,   0,   0
> 512:512,  0,1714, 470,7174436957,   0,   0
> 1024:  1024,  0,   29033, 347,131133987,   0,   0
> 2048:  2048,  0, 869, 275,1001770010,   0,   0
> 4096:  4096,  0,  730319,3013,332721996,   0,   0
> 8192:  8192,  0,  47,  11,  487154,   0,   0
> 16384:16384,  0,  65,   5,1788,   0,   0
> 32768:32768,  0,  54,  13,  103482,   0,   0
> 65536:65536,  0, 627,   8, 8172809,   0,   0
> SLEEPQUEUE:  80,  0,1954,1053,2812,   0,   0
> 64 pcpu:  8,  0, 558, 594, 793,   0,   0
> Files:   80,  0,   16221,2579,1549799224,   0,   0
> TURNSTILE:  136,  0,1954, 506,2812,   0,   0
> rl_entry:40,  0,1114,2186,1114,   0,   0
> umtx pi: 96,  0,   0,   0,   0,   0,   0
> MAC labels:  40,  0,   0,   0,   0,   0,   0
> PROC:  1208,  0, 635, 514,41838196,   0,   0
> THREAD:1168,  0,1840, 113,   12778,   0,   0
> cpuset:  96,  0, 705, 361,1490,   0,   0
> audit_record:  1248,  0,   0,   0,   0,   0,   0
> sendfile_sync:  128,  0,   0,   0,   0,   0,   0
> mbuf_packet:256, 46137345,8199,5074,15123806588,   0,  
> 0
> mbuf:   256, 46137345,   25761,   13076,21621129305,   0,  
> 0
> mbuf_cluster:  2048, 7208960,   13273, 315, 2905465,   0,   0
> mbuf_jumbo_page:   4096, 3604480, 786, 862,628074105,   0,   0
> mbuf_jumbo_9k: 9216, 1067994,   0,   0,   0,   0,   0
> mbuf_jumbo_16k:   16384, 600746,   0,   0,   0,   0,   0
> mbuf_ext_refcnt:  4,  0,   0,   0,   0,   0,   0
> g_bio:  248,  0,  36,2348,2894002696,   0,   0
> DMAR_MAP_ENTRY: 120,  0,   0,   0,   0,   0,   0
> ttyinq: 160,  0, 180, 195,4560,   0,   0
> ttyoutq:256,  0,  95, 190,2364,   0,   0
> FPU_save_area:  832,  0,   0,   0,   0,   0,   0
> taskq_zone:  48,  0,   0,4814,108670448,   0,   0
> VNODE:  472,  0, 1115838,  293402,379118791,   0,   0
> VNODEPOLL:  112,  0,   0,   0,  12,   0,   0
> BUF TRIE:   144,  0,  96,  105852, 5530345,   0,   0
> S VFS

Re: HEADS UP: Enabling vt(4) by default

2014-11-04 Thread Jean-Sébastien Pédron 
Hello!

As announced a week ago, vt(4) is now the default console driver in
11-CURRENT as of r274085.

You may have to update your console settings in /etc/rc.conf. During
boot, /etc/rc.d/syscons will indicate what you need to do.

The original HEADS UP mentioned several known issues. Among them, the
following were fixed:

o  A video mode can be selected using the following tunable in
   /boot/loader.conf:
   kern.vt.fb.default_mode="1024x768"

   This only works when using a KMS video driver. It's not
   supported by the VGA backend. See vt(4) man page for further
   documentation.

o  The keyboard was not working when kbdmux(4) was disabled. This
   is fixed.

o  After loading a KMS driver, the text cursor was in the middle of
   the kernel messages. The problem was that the cursor position was
   not updated after the change in window size. This is fixed.

Up-to-date information can be found on the wiki page:
https://wiki.freebsd.org/Newcons

If you want to keep using syscons(4), you can add the following line to
/boot/loader.conf:
kern.vty=sc

Thank you to everyone who tested and reported problems! Please continue
to do so, especially if you find the need to go back to syscons.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Allan Jude 
On 11/04/2014 11:17, Kris Moore wrote:
> On 11/04/2014 10:24, Kurt Jaeger wrote:
>> Hi!
>>
>>> If you don't need any USB devices to boot, you can delay their
>>> detection by loading the modules through /etc/rc.d/kld instead
>>> of the loader:
>>>
>>> fk@r500 ~ $grep kld /etc/rc.conf
>>> kld_list="usb.ko usb_quirk.ko ehci.ko umass.ko"
>> Does this really help with the GENERIC kernel ?
>>
>> If I add this to /etc/rc.conf and do
>>
>> /etc/rc.d/kld start
>>
>> this spews a load of errors.
>>
> 
> Colin added this to HEAD recently:
> 
> https://github.com/freebsd/freebsd/commit/bdb0ac02b9fd8f331fa70c8a4c29495b7ee43293
> 
> This will allow setting the passphrase at the boot-loader, so it doesn't
> get prompted for again during boot. I think there was some work by
> dteske@ to add this to the FreeBSD boot menus, but maybe you can use it
> manually for now.
> 
> We are using it in PC-BSD to supply the passphrase directly from GRUB,
> so we only get prompted a single time.
> 
> (Before somebody asks why we use grub)
> We are using grub to do full-disk encryption, without a unencrypted
> /boot, among other things :)
> 
> 

Yes, as Kris mentioned, the solution is being working on here at MeetBSD
by dteske@ (with some advice from jmg@) at the request of cperciva@,
using the functionality Colin added to head for Kris to be able to do
this for PCBSD.

Hopefully this problem will be solved soon.

-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Fabian Keil 
Kurt Jaeger  wrote:

> > If you don't need any USB devices to boot, you can delay their
> > detection by loading the modules through /etc/rc.d/kld instead
> > of the loader:
> > 
> > fk@r500 ~ $grep kld /etc/rc.conf
> > kld_list="usb.ko usb_quirk.ko ehci.ko umass.ko"
> 
> Does this really help with the GENERIC kernel ?

I didn't say it did. You need a kernel that doesn't already
contain the USB modules in /boot/kernel/kernel, this excludes
GENERIC kernels.

Fabian


pgphzo8bV6YHH.pgp
Description: OpenPGP digital signature

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Kris Moore 
On 11/04/2014 10:24, Kurt Jaeger wrote:
> Hi!
>
>> If you don't need any USB devices to boot, you can delay their
>> detection by loading the modules through /etc/rc.d/kld instead
>> of the loader:
>>
>> fk@r500 ~ $grep kld /etc/rc.conf
>> kld_list="usb.ko usb_quirk.ko ehci.ko umass.ko"
> Does this really help with the GENERIC kernel ?
>
> If I add this to /etc/rc.conf and do
>
> /etc/rc.d/kld start
>
> this spews a load of errors.
>

Colin added this to HEAD recently:

https://github.com/freebsd/freebsd/commit/bdb0ac02b9fd8f331fa70c8a4c29495b7ee43293

This will allow setting the passphrase at the boot-loader, so it doesn't
get prompted for again during boot. I think there was some work by
dteske@ to add this to the FreeBSD boot menus, but maybe you can use it
manually for now.

We are using it in PC-BSD to supply the passphrase directly from GRUB,
so we only get prompted a single time.

(Before somebody asks why we use grub)
We are using grub to do full-disk encryption, without a unencrypted
/boot, among other things :)


-- 
Kris Moore
PC-BSD Software
iXsystems

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Jenkins build became unstable: FreeBSD_HEAD-tests2 #184

2014-11-04 Thread Garrett Cooper 
On Nov 4, 2014, at 0:06, jenkins-ad...@freebsd.org wrote:

> See 

It appears that some of the new results from the libc testcases are causing 
Jenkins to crash in some cases:
- https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/186/testReport/

And it appears that kyua is creating “malformed XML” (invalid XML character) in 
others:
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/184/testReport/junit/test-report/xml/_init_/

I’m not sure about the former case, but the latter case has to do with the fact 
that one of the testcases outputs invalid UTF-8 which is then turning up in the 
output. Even python complains about it:

% kyua report-junit > ~/report.junit
% python2 -c 'import os.path; import xml.dom.minidom as md; 
md.parse(os.path.expanduser("~/report.junit"))'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/xml/dom/minidom.py", line 1918, in parse
return expatbuilder.parse(file)
  File "/usr/local/lib/python2.7/xml/dom/expatbuilder.py", line 924, in parse
result = builder.parseFile(fp)
  File "/usr/local/lib/python2.7/xml/dom/expatbuilder.py", line 207, in 
parseFile
parser.Parse(buffer, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 27137, 
column 13

The problem testcase is lib.libc.locale.t_io:bad_big5_wprintf; once I remove 
that from the output, python no longer complains:

% python2 -c 'import os.path; import xml.dom.minidom as md; 
md.parse(os.path.expanduser("~/report.junit"))'

I fixed this issue in r274090.

Thank you!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Kurt Jaeger 
Hi!

> If you don't need any USB devices to boot, you can delay their
> detection by loading the modules through /etc/rc.d/kld instead
> of the loader:
> 
> fk@r500 ~ $grep kld /etc/rc.conf
> kld_list="usb.ko usb_quirk.ko ehci.ko umass.ko"

Does this really help with the GENERIC kernel ?

If I add this to /etc/rc.conf and do

/etc/rc.d/kld start

this spews a load of errors.

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Fabian Keil 
Miguel Clara  wrote:

> Sorry to bring this one back but I see no changes have been made to this in
> current.
> 
> The issue is that USB devices are detected after the geli prompt and so the
> "geli paraphrase" prompt becomes hidden, and the simple solution would be
> to change the order the prompt show as in wait a few secs for the usb
> devices to be detected.

If you don't need any USB devices to boot, you can delay their
detection by loading the modules through /etc/rc.d/kld instead
of the loader:

fk@r500 ~ $grep kld /etc/rc.conf
kld_list="usb.ko usb_quirk.ko ehci.ko umass.ko"

Fabian


pgpd6329GXoxZ.pgp
Description: OpenPGP digital signature

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Kurt Jaeger 
Hi!

> The issue is that USB devices are detected after the geli prompt and so the
> "geli paraphrase" prompt becomes hidden, and the simple solution would be
> to change the order the prompt show as in wait a few secs for the usb
> devices to be detected.

I've seen the same issue on 10.x, and a solution for this would be
useful, yes.

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Order of geli "passphrase prompt" on boot

2014-11-04 Thread Miguel Clara 
Sorry to bring this one back but I see no changes have been made to this in
current.

The issue is that USB devices are detected after the geli prompt and so the
"geli paraphrase" prompt becomes hidden, and the simple solution would be
to change the order the prompt show as in wait a few secs for the usb
devices to be detected.

Also the FreeBSD installer includes the zfs+geli install options, which
encrypts root, so any user can do it now, yet when they boot they won't
even see the passphrase prompt, which to me is really not inviting when we
want to bring over the linux folks!

Some linux distros even allow you to type the passphrase for the device in
a neat prompt (black background mint logo ec...) but I don't think we need
to go that far, that's probably something PC-BSD folks can do though (if
they don't already).

I understand tough that what some times seems simple from user perspective
its really not for devs, so my question is: Is this a hard change to
implement, and by change I just mean change the order or wait a few secs
for usb device detection, or somehow stop this detection of the devices to
"spam" the screen until a passphrase is entered!?

Thanks


Melhores Cumprimentos // Best Regards
---
*Miguel Clara*
*IT - Sys Admin & Developer*
*E-mail:*miguelmcl...@gmail.com
 www.linkedin.com/in/miguelmclara/

On Thu, Aug 28, 2014 at 5:01 PM, dweimer  wrote:

> On 08/28/2014 10:20 am, Francesco Toscan wrote:
>
>> On Wed, Aug 27, 2014 at 12:42:31PM +0100, Miguel Clara wrote:
>>
>>> Hi,
>>>
>>
>> Hi,
>>
>>>
>>> Does any one know if there's a way to change the order of the passphrase
>>> prompt when the disk is encrypted?
>>>
>>> The ways it is now devices get detected after this prompt (usb devices it
>>> seems) and makes the prompt kind of hidden which complicates things for
>>> less experience users!
>>>
>>
>> I experienced this issue running 9.0.
>> 10-RELEASE seems fine (as works for me...) but i didn't investigate.
>>
>> If your root partition is not encrypted, you can try to mount encrypted
>> volumes later, adding the relevant bits into /etc/rc.local or a rc.d
>> script. Just remove the BOOT flag from your volumes with
>>
>> geli configure -B provider
>>
>
> I can confirm the issue on my laptop (Dell Lattitude E6520) with
> 10.0-RELEASE-p7 using an encrypted boot on zfs, and booting from usb thumb
> drive.  It doesn't do it if I have no other USB devices plugged in in
> addition to the USB thumb frive.  However if its in the port replicator,
> with external mouse/keyboard I get a lot of device discovery prompts
> following the prompt for the password.  Its only a nuisance for me, though
> when I built it off the port replicator then took it into the office and
> booted it the first time I thought I broke it and hard reset it.  The next
> boot I was watching closely and saw the prompt go by.
>
> --
> Thanks,
>Dean E. Weimer
>http://www.dweimer.net/
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #186

2014-11-04 Thread jenkins-admin 
See 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

current panic: Lock (sx) random_adaptors not locked @

2014-11-04 Thread Julian H. Stacey 
Hi current@

Maybe this is a transient no one else will see ?:
  with no /boot/loader.conf, my old custom kernel booted & my new one paniced:

  panic: Lock (sx) random_adaptors not locked @ dev/random/random_adaptors.c:278

  -r-xr-xr-x  1 root  wheel  13625036 Nov  1 18:37 /boot/kernel.old/kernel*
  -r-xr-xr-x  1 root  wheel  13629202 Nov  4 11:09 /boot/kernel/kernel*

I can not give an SVN revision number as I did not use svn myself to extract 
that /usr/src/ which I received via CTM, but as it was:
cd /usr/src
cat .ctm_status
src-cur 11681
ls -l .ctm_status
-rw-r--r--  1 jhs  staff  14 Nov  3 16:13 .ctm_status

By Tue Nov  4 13:12:39 CET 2014 I had since received a new ctm mail
-r--r--r--  1 mailnull  mailnull  14858 Nov  3 21:25 
/pub/FreeBSD/development/CTM/src-cur/src-cur.11682.gz

I built a GENERIC kernel which booted OK, Then a custom kernel also booted OK.
(maybe someone fixed the panic).


Seperately after, trying to look where I might find an svn number
to quote non ctm users for the above, I ran:
svn export -q file:///usr/svn/base/head # Exported revision 274078
find + grep 274078 ...
./head/lib/libnetbsd/sys/time.h:
/* $FreeBSD: head/lib/libnetbsd/sys/time.h 274078 2014-11-04 
02:00:07Z ngie $ 

Is there a better place in src/ to look for svn numbers to quote ?

Normaly I only have what's in src/ ... maybe the ctm server 
should catch the stdout or stderr from svn & write it to eg 
src/.svn_revision ?


BTW I've been seeing boot lock order reversals for week[s], without panics.

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Dmitriy Makarov 
ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP

UMA Kegs:   384,  0, 210,  10, 216,   0,   0
UMA Zones: 2176,  0, 210,   0, 216,   0,   0
UMA Slabs:   80,  0, 2921231, 1024519,133906002,   0,   0
UMA RCntSlabs:   88,  0,8442,1863,  771451,   0,   0
UMA Hash:   256,  0,   2,  28,  79,   0,   0
4 Bucket:32,  0,5698,   16052,424047094,   0,   0
6 Bucket:48,  0, 220,8993,77454827,   0,   0
8 Bucket:64,  0, 260,6808,56285069,  15,   0
12 Bucket:   96,  0, 302,2568,42712743, 192,   0
16 Bucket:  128,  0,1445,1903,86971183,   0,   0
32 Bucket:  256,  0, 610,2870,96758244, 215,   0
64 Bucket:  512,  0,1611,1117,55896361,77166469,   0
128 Bucket:1024,  0, 413, 635,99338830,104451029,  
0
256 Bucket:2048,  0,1100, 222,164776092,24917372,  
0
vmem btag:   56,  0, 1889493,  502639,30117503,16948,   0
VM OBJECT:  256,  0,  970434,  174126,1080667061,   0,   0
RADIX NODE: 144,  0, 2792188,  882809,1489929489,   0,   0
MAP:240,  0,   3,  61,   3,   0,   0
KMAP ENTRY: 128,  0,  13, 173,  37,   0,   0
MAP ENTRY:  128,  0,   82182,   11624,3990141990,   0,   0
VMSPACE:496,  0, 615, 761,41838231,   0,   0
fakepg: 104,  0,   0,   0,   0,   0,   0
mt_zone:  16400,  0, 261,   0, 267,   0,   0
16:  16,  0, 3650397, 6166213,6132198534,   0,   0
32:  32,  0, 1118176,  259824,9115561085,   0,   0
64:  64,  0,14496058,14945820,11266627738,   0,   0
128:128,  0, 1337428,  319398,15463968444,   0,   0
256:256,  0, 1103937,  258183,8392009677,   0,   0
512:512,  0,1714, 470,7174436957,   0,   0
1024:  1024,  0,   29033, 347,131133987,   0,   0
2048:  2048,  0, 869, 275,1001770010,   0,   0
4096:  4096,  0,  730319,3013,332721996,   0,   0
8192:  8192,  0,  47,  11,  487154,   0,   0
16384:16384,  0,  65,   5,1788,   0,   0
32768:32768,  0,  54,  13,  103482,   0,   0
65536:65536,  0, 627,   8, 8172809,   0,   0
SLEEPQUEUE:  80,  0,1954,1053,2812,   0,   0
64 pcpu:  8,  0, 558, 594, 793,   0,   0
Files:   80,  0,   16221,2579,1549799224,   0,   0
TURNSTILE:  136,  0,1954, 506,2812,   0,   0
rl_entry:40,  0,1114,2186,1114,   0,   0
umtx pi: 96,  0,   0,   0,   0,   0,   0
MAC labels:  40,  0,   0,   0,   0,   0,   0
PROC:  1208,  0, 635, 514,41838196,   0,   0
THREAD:1168,  0,1840, 113,   12778,   0,   0
cpuset:  96,  0, 705, 361,1490,   0,   0
audit_record:  1248,  0,   0,   0,   0,   0,   0
sendfile_sync:  128,  0,   0,   0,   0,   0,   0
mbuf_packet:256, 46137345,8199,5074,15123806588,   0,  
0
mbuf:   256, 46137345,   25761,   13076,21621129305,   0,  
0
mbuf_cluster:  2048, 7208960,   13273, 315, 2905465,   0,   0
mbuf_jumbo_page:   4096, 3604480, 786, 862,628074105,   0,   0
mbuf_jumbo_9k: 9216, 1067994,   0,   0,   0,   0,   0
mbuf_jumbo_16k:   16384, 600746,   0,   0,   0,   0,   0
mbuf_ext_refcnt:  4,  0,   0,   0,   0,   0,   0
g_bio:  248,  0,  36,2348,2894002696,   0,   0
DMAR_MAP_ENTRY: 120,  0,   0,   0,   0,   0,   0
ttyinq: 160,  0, 180, 195,4560,   0,   0
ttyoutq:256,  0,  95, 190,2364,   0,   0
FPU_save_area:  832,  0,   0,   0,   0,   0,   0
taskq_zone:  48,  0,   0,4814,108670448,   0,   0
VNODE:  472,  0, 1115838,  293402,379118791,   0,   0
VNODEPOLL:  112,  0,   0,   0,  12,   0,   0
BUF TRIE:   144,  0,  96,  105852, 5530345,   0,   0
S VFS Cache:108,  0,  995997,  161558,523325155,   0,   0
STS VFS Cache:  148,  0,   0,   0,   0,   0,   0
L VFS Cache:328,  0,  25,

Re: CTF: geom gate network patch

2014-11-04 Thread Fabian Keil 
John-Mark Gurney  wrote:

> John-Mark Gurney wrote this message on Fri, Oct 17, 2014 at 09:58 -0700:
 
> > I did some work at this a while back... and if you're interested in
> > improving performance and willing to do some testing... I can send you
> > some patches..
> > 
> > There are a couple issues that I know about..
> > 
> > First, ggate specificly sets the buffer sizes, which disables the
> > autosizing of TCP's window.. This means that if you have a high latency,
> > high bandwidth link, you'll be limited to 128k / rtt of bandwidth.
> > 
> > Second is that ggate isn't issueing multiple IOs at a time.  This means
> > that any NCQ or tagging isn't able to be used, where as when running
> > natively they can be used...
> 
> I've attached a patch I would like other ggate users to test and
> verify that there aren't bugs, or performance regressions by using
> this patch.
> 
> The patch is also available at:
> https://www.funkthat.com/~jmg/patches/ggate.patch

I tested the patch on a recent 11-CURRENT system (ggatec/ggated)
and a 9.0-CURRENT system from 2009 (only ggated) and didn't notice
any problems.

The patch didn't seem to affect the performance either way,
but then again I'm using slow disks and ssh so I didn't expect
geom gate to be the bottle neck.

Fabian


pgpSuTNRvSM3g.pgp
Description: OpenPGP digital signature

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Steven Hartland 

This is likely spikes in uma zones used by ARC.

The VM doesn't ever clean uma zones unless it hits a low memory 
condition, which explains why your little script helps.


Check the output of vmstat -z to confirm.

On 04/11/2014 11:47, Dmitriy Makarov wrote:

Hi Current,

It seems like there is constant flow (leak) of memory from ARC to Inact in 
FreeBSD 11.0-CURRENT #0 r273165.

Normally, our system (FreeBSD 11.0-CURRENT #5 r260625) keeps ARC size very 
close to vfs.zfs.arc_max:

Mem: 16G Active, 324M Inact, 105G Wired, 1612M Cache, 3308M Buf, 1094M Free
ARC: 88G Total, 2100M MFU, 78G MRU, 39M Anon, 2283M Header, 6162M Other


But after an upgrade to (FreeBSD 11.0-CURRENT #0 r273165) we observe enormous 
numbers of Inact memory in the top:

Mem: 21G Active, 45G Inact, 56G Wired, 357M Cache, 3308M Buf, 1654M Free
ARC: 42G Total, 6025M MFU, 30G MRU, 30M Anon, 819M Header, 5214M Other

Funny thing is that when we manually allocate and release memory, using simple 
python script:

#!/usr/local/bin/python2.7

import sys
import time

if len(sys.argv) != 2:
 print "usage: fillmem "
 sys.exit()

count = int(sys.argv[1])

megabyte = (0,) * (1024 * 1024 / 8)

data = megabyte * count

as:

# ./simple_script 1

all those allocated megabyes 'migrate' from Inact to Free, and afterwards they 
are 'eaten' by ARC with no problem.
Until Inact slowly grows back to the number it was before we ran the script.

Current workaround is to periodically invoke this python script by cron.
This is an ugly workaround and we really don't like it on our production


To answer possible questions about ARC efficience:
Cache efficiency drops dramatically with every GiB pushed off the ARC.

Before upgrade:
 Cache Hit Ratio:99.38%

After upgrade:
 Cache Hit Ratio:81.95%

We believe that ARC misbehaves and we ask your assistance.


--

Some values from configs.

HW: 128GB RAM, LSI HBA controller with 36 disks (stripe of mirrors).

top output:

In /boot/loader.conf :
vm.kmem_size="110G"
vfs.zfs.arc_max="90G"
vfs.zfs.arc_min="42G"
vfs.zfs.txg.timeout="10"

---

Thanks.

Regards,
Dmitriy
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r273165. ZFS ARC: possible memory leak to Inact

2014-11-04 Thread Dmitriy Makarov 
Hi Current,

It seems like there is constant flow (leak) of memory from ARC to Inact in 
FreeBSD 11.0-CURRENT #0 r273165. 

Normally, our system (FreeBSD 11.0-CURRENT #5 r260625) keeps ARC size very 
close to vfs.zfs.arc_max:

Mem: 16G Active, 324M Inact, 105G Wired, 1612M Cache, 3308M Buf, 1094M Free
ARC: 88G Total, 2100M MFU, 78G MRU, 39M Anon, 2283M Header, 6162M Other


But after an upgrade to (FreeBSD 11.0-CURRENT #0 r273165) we observe enormous 
numbers of Inact memory in the top:

Mem: 21G Active, 45G Inact, 56G Wired, 357M Cache, 3308M Buf, 1654M Free
ARC: 42G Total, 6025M MFU, 30G MRU, 30M Anon, 819M Header, 5214M Other

Funny thing is that when we manually allocate and release memory, using simple 
python script:

#!/usr/local/bin/python2.7

import sys
import time

if len(sys.argv) != 2:
print "usage: fillmem "
sys.exit()

count = int(sys.argv[1])

megabyte = (0,) * (1024 * 1024 / 8)

data = megabyte * count

as:

# ./simple_script 1

all those allocated megabyes 'migrate' from Inact to Free, and afterwards they 
are 'eaten' by ARC with no problem.
Until Inact slowly grows back to the number it was before we ran the script.

Current workaround is to periodically invoke this python script by cron.
This is an ugly workaround and we really don't like it on our production 


To answer possible questions about ARC efficience:
Cache efficiency drops dramatically with every GiB pushed off the ARC.

Before upgrade:  
Cache Hit Ratio:99.38%

After upgrade:
Cache Hit Ratio:81.95%

We believe that ARC misbehaves and we ask your assistance.


--

Some values from configs.

HW: 128GB RAM, LSI HBA controller with 36 disks (stripe of mirrors). 

top output:

In /boot/loader.conf :
vm.kmem_size="110G"
vfs.zfs.arc_max="90G"
vfs.zfs.arc_min="42G"
vfs.zfs.txg.timeout="10"

---

Thanks.

Regards,
Dmitriy
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #185

2014-11-04 Thread jenkins-admin 
See 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build became unstable: FreeBSD_HEAD-tests2 #184

2014-11-04 Thread jenkins-admin 
See 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"