Sluggish performance on head r311648

2017-01-10 Thread Ultima 
I'v been noticing lately sluggish performance, maybe zfs? First noticed
this a few days ago right after upgrading on Jan 7th to r311648 and the
last upgrade before that was around dec 30-jan 1 (not sure of rev). Decided
to upgrade again today. I usually build and install head every week or two,
but I have been extremely busy the past couple months.

FreeBSD U1 12.0-CURRENT FreeBSD 12.0-CURRENT #16 r311903: Tue Jan 10
17:20:11 EST 2017 amd64

Normally when one of my services scans a few directories it takes about 15
seconds tops, it has been taking several minutes. I want to note that this
service is running inside a jail with vnet enabled. Also the directory it
scans is a nullfs to a dataset. This is just one of the many side effects
i'v been noticing, another is extremely slow reads with bhyve+zvol.
Starting to wonder if it maybe hardware related.

I decided to check commits log before posting and not much has happened to
zfs recently other than, Add missed vfs.zfs.zfetch.max_idistance in
r309833, and 309714 which doesn't really look related (could be wrong). But
these were committed about a month ago so that is not likely the case.


Anyone else experiences similar results as of recent?


Sorry for being noise if this is hardware related.
___
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: rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature

2017-01-10 Thread Cy Schubert 
In message <1484093380.96230.94.ca...@freebsd.org>, Ian Lepore writes:
> On Wed, 2017-01-11 at 00:48 +0100, Ronald Klop wrote:
> > Hello,
> > 
> > Since the commit in the subject /etc/rc.d/ntpdate does not work
> > anymore.
> > # /etc/rc.d/ntpdate restart
> > Setting date via ntp.
> > 11 Jan 00:35:46 ntpdate[56020]: no servers can be used, exiting
> > 
> > This diff fixes it for me:
> > # diff -u /tmp/ntpdate /etc/rc.d/ntpdate
> > --- /tmp/ntpdate2017-01-11 00:41:58.736138000 +0100
> > +++ /etc/rc.d/ntpdate   2017-01-11 00:42:15.522986000 +0100
> > @@ -20,7 +20,7 @@
> >   if [ -z "$ntpdate_hosts" -a -f "$ntpdate_config" ]; then
> >   ntpdate_hosts=`awk '
> >   /^server[ \t]*127.127/      {next}
> > -   /^(server|peer)/            {
> > +   /^(server|peer|pool)/            {
> >       if ($2 ~/^-/)           
> > {print $3}
> >       else                  
> >   {print $2}}
> >   ' < "$ntpdate_config"`
> > 
> > 
> > Regards,
> > 
> > Ronald.
> 
> Ooops, my bad, I'll get it fixed asap.

Not all your bad. Those of us reviewing the change should picked up on that 
too.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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"

rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature

2017-01-10 Thread Ronald Klop 

Hello,

Since the commit in the subject /etc/rc.d/ntpdate does not work anymore.
# /etc/rc.d/ntpdate restart
Setting date via ntp.
11 Jan 00:35:46 ntpdate[56020]: no servers can be used, exiting

This diff fixes it for me:
# diff -u /tmp/ntpdate /etc/rc.d/ntpdate
--- /tmp/ntpdate2017-01-11 00:41:58.736138000 +0100
+++ /etc/rc.d/ntpdate   2017-01-11 00:42:15.522986000 +0100
@@ -20,7 +20,7 @@
if [ -z "$ntpdate_hosts" -a -f "$ntpdate_config" ]; then
ntpdate_hosts=`awk '
/^server[ \t]*127.127/  {next}
-   /^(server|peer)/{
+   /^(server|peer|pool)/{
if ($2 ~/^-/)   {print $3}
else{print $2}}
' < "$ntpdate_config"`


Regards,

Ronald.
___
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: rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature

2017-01-10 Thread Ian Lepore 
On Wed, 2017-01-11 at 00:48 +0100, Ronald Klop wrote:
> Hello,
> 
> Since the commit in the subject /etc/rc.d/ntpdate does not work
> anymore.
> # /etc/rc.d/ntpdate restart
> Setting date via ntp.
> 11 Jan 00:35:46 ntpdate[56020]: no servers can be used, exiting
> 
> This diff fixes it for me:
> # diff -u /tmp/ntpdate /etc/rc.d/ntpdate
> --- /tmp/ntpdate  2017-01-11 00:41:58.736138000 +0100
> +++ /etc/rc.d/ntpdate 2017-01-11 00:42:15.522986000 +0100
> @@ -20,7 +20,7 @@
>   if [ -z "$ntpdate_hosts" -a -f "$ntpdate_config" ]; then
>   ntpdate_hosts=`awk '
>   /^server[ \t]*127.127/  {next}
> - /^(server|peer)/{
> + /^(server|peer|pool)/{
>   if ($2 ~/^-/)   {print $3}
>   else{print $2}}
>   ' < "$ntpdate_config"`
> 
> 
> Regards,
> 
> Ronald.

Ooops, my bad, I'll get it fixed asap.

-- Ian

___
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: [RFC/RFT] projects/ipsec

2017-01-10 Thread Andrey V. Elsukov 

Hi All,

I ported the changes from projects/ipsec to stable/11 branch.
So, if it is more suitable for testing, please, welcome.

You can checkout the sources from github:
https://github.com/bu7cher/freebsd/tree/stable/11

Also I made the standalone patch:
https://people.freebsd.org/~ae/ipsec.diff

Unfortunately, I did only compile test for stable branch.


I am pleased to announce that projects/ipsec, that I started several
months ago is ready for testing and review.
The main goals were:
  * rework locking to make IPsec code more friendly for concurrent
processing;
  * make lookup in SADB/SPDB faster;
  * revise PFKEY implementation, remove stale code, make it closer
to RFC;
  * implement IPsec VTI (virtual tunneling interface);
  * make IPsec code loadable as kernel module.

Currently all, except the last one is mostly done. So, I decided ask for
a help to test the what already done, while I will work on the last task.

How to try? There are no patches, you need to checkout the full
projects/ipsec source tree, and build the kernel and the base system.
There are very few changes in the base system, mostly the kernel
changes. Thus for testing that old configuration is still work, it is
enough to build only the kernel.

The approximate list of changes that may be visible to users:
* SA bundles now can have only 4 items in the chain. I think it is
enough, I can't imagine configurations when needed more. Also now SA
bundles supported for IPv6 too.
* due to changes in SPDB/SADB, systems where large number of SPs and SAs
are in use should get significant performance benefits.
* the memory consumption should slightly increase. There are several
hash tables and SP cache appeared.
* INPCB SP cache should noticeable increase network performance of
application when security policies are presence.
  https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html
* use transport mode IPsec for forwarded IPv4 packets now unsupported.
This matches the IPv6 behavior, and since we can handle the replies, I
think it is useless.
* Added net.inet.ipsec.check_policy_history sysctl variable. When it is
set, each inbound packet that was handled by IPsec will be checked
according to matching security policy. If not all IPsec transforms were
applied, the check will fail, and packet will be dropped.
* Many PF_KEY messages handlers was updated, probably some IKEd now may
fail due to stricter checks.
* SPI now unique for each SA. This also can break something.
* Added if_ipsec interface. For more info look at
  https://svnweb.freebsd.org/base?view=revision=309115
  https://reviews.freebsd.org/P112
* TCP_SIGNATURE code was reworked and now it behaves closer to RFC
  https://svnweb.freebsd.org/base?view=revision=309610
* NAT-T support was reworked.
  https://svnweb.freebsd.org/base?view=revision=309808
Also I made the patch to racoon that adds better support of NAT-T,
you can use this port to build patched racoon:
  https://people.freebsd.org/~ae/ipsec-tools.tgz

What results is interesting to me?
If you have some nontrivial configuration, please test.
If you have some configuration, that did't work, please test this branch.
If you have performance problems, please test. But don't forget that
this is head/ branch, you need to disable all debugging first.
If you just want to test, pay attention to the output of
`vmstat -m | egrep "sec|sah|pol|crypt"`.
If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this
support was significantly changed.


IPsec as kernel modules was reported here:
https://lists.freebsd.org/pipermail/freebsd-net/2016-December/046762.html

Some additional testing also needed with this...

--
WBR, Andrey V. Elsukov
___
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: r311871: kernel build failure: ieee80211_vht.c:94:2: error: implicit declaration ...

2017-01-10 Thread O. Hartmann 
Am Tue, 10 Jan 2017 11:32:00 +0100
"O. Hartmann"  schrieb:

> On CURRENT (r311871), I'm bothered with this error schown below. Buildkernel
> fails. It is a customized kernel.
> 
> [...]
> Building 
> /usr/obj/usr/src/sys/FREYJA/modules/usr/src/sys/modules/wlan/ieee80211.o
> Building 
> /usr/obj/usr/src/sys/FREYJA/modules/usr/src/sys/modules/wlan/ieee80211_vht.o
> /usr/src/sys/modules/wlan/../../net80211/ieee80211_vht.c:94:2: error: implicit
> declaration of function 'ieee80211_note' is invalid in C99
> [-Werror,-Wimplicit-function-declaration] ieee80211_note(ni->ni_vap, "%s:
> called; fc=0x%.2x/0x%.2x", ^ 1 error generated.
> *** Error code 1
> 
> Kind regards,
> 
> oh


The problem can be avoided by enabling WiFi infrastructure in the kernel:

I have these lines in those boxes which build the kernel in common:

# Wireless NIC cards
device  wlan# 802.11 support
options IEEE80211_DEBUG # enable debug msgs
options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's
options IEEE80211_SUPPORT_MESH  # enable 802.11s draft support
options IEEE80211_SUPPORT_TDMA  #enable TDMA support
device  wlan_wep# 802.11 WEP support
device  wlan_ccmp   # 802.11 CCMP support
device  wlan_tkip   # 802.11 TKIP support
device  wlan_amrr   # AMRR transmit rate control algorithm
device  ath # Atheros NICs
device  ath_pci # Atheros pci/cardbus glue
device  ath_hal # pci/cardbus chip support
options AH_SUPPORT_AR5416   # enable AR5416 tx/rx descriptors
options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation
options ATH_ENABLE_11N  # Enable 802.11n support for AR5416 and later
device  ath_rate_sample # SampleRate tx rate control for ath


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp4HmwfcbRlh.pgp
Description: OpenPGP digital signature

Re: MANPATH not handled correctly

2017-01-10 Thread Simon J. Gerraty 
Steve Kargl  wrote:
> Well, yes, it is the manpage that gets installed.
> 
> > usr.bin/man/apropos.1
> > 
> > is the one that matches apropos(1)

I should have said "in 10.x" ;-)
In current, MK_MANDOCDB defaults yes, so you are right.

So the script needs an update.
Is there a PR filed?
___
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: MANPATH not handled correctly

2017-01-10 Thread Baptiste Daroussin 
On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote:
> MANPATH is not handled correctly.  According to the documentation
> in apropos(1) and whatis(1):
> 
>   MANPATH   The standard search path used by man(1) may be changed by
> specifying a path in the MANPATH environment variable.  Invalid
> paths, or paths without manual databases, are ignored.
> Overridden by -M.  If MANPATH begins with a colon, it is
> appended to the default list; if it ends with a colon, it is
> prepended to the default list; or if it contains two adjacent
> colons, the standard search path is inserted between the
> colons.  If none of these conditions are met, it overrides the
> standard search path.
> 
> I have a manpage named mkpic in $HOME/man/man1.  I also have the FreeBSD
> installed manpages, e.g., /usr/share/man/man1/cat.1.gz.  If I have
> 'setenv MANPATH :$HOME/man' in my .cshrc file, then the following occurs:  
> 
> % setenv | grep MANPATH
> MANPATH=:/home/kargl/man
> % apropos mkpic
> (Warning: MANPATH environment variable set)
> mkpic(1) - construct a contour image in MIFF image format
> % apropos cat
> (Warning: MANPATH environment variable set)
> matrix(3) - Array and matrix allocation for FFT library
> 
> So, the above description of MANPATH is incorrect as :/home/kargl/man
> should have been appended to the default MANPATH.
> 
> Interestingly, manpath(1) seems to described what actually happens
> (long lines wrapped):
> 
> % unsetenv MANPATH
> % manpath
> /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\
>/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\
>/usr/local/share/xpdf/man
> % setenv MANPATH :$HOME/sman
> % manpath
> (Warning: MANPATH environment variable set)
> :/home/kargl/man
> 
> The expected result according apropos(1) and whatis(1) for last command is
> 
> % manpath
> /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\
>/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\
>/usr/local/share/xpdf/man:/home/kargl/man
> 
> Instead of (un)fixing the documentation for apropos(1) and whatis(1), it
> would be preferable to fix manpath to match the description in those
> manpages.  In addition, the Warning should be removed or at least an
> option should be available to suppress the (useless/annoying) Warning.
> This would restore man(1), apropros(1), and whatis(1) to its historical
> behavior prior to svn revision 213317.
> 
> If the documentation for apropos(1) and whatis(1) is unfixed, then manpath(1)
> should have HISTORY and BUGS sections.  The BUGS section should explicitly
> not that MANPATH is no longer a changeable environmental variable by a
> user without incurring the Warning.
> 

Sounds like a bug, I will have a look as soon as I can

Thanks for reporting,
Best regards,
Bapt


signature.asc
Description: PGP signature

Re: MANPATH not handled correctly

2017-01-10 Thread Steve Kargl 
On Mon, Jan 09, 2017 at 10:26:16PM -0800, Simon J. Gerraty wrote:
> Steve Kargl  wrote:
> 
> > On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote:
> > > Steve Kargl  wrote:
> > > 
> > > > MANPATH is not handled correctly.  According to the documentation
> > > > in apropos(1) and whatis(1):
> > > 
> > > Can you clarify where you are seeing this documentation?
> > > I don't see it in 7.x 10.x or current.
> > > 
> > 
> > This an unaltered FreeBSD-current at r311832.
> > 
> > The text I quoted can be seen at 
> > 
> > https://svnweb.freebsd.org/base/head/contrib/mdocml/apropos.1?revision=294113=markup
> > 
> 
> But that isn't the man page that gets installed.
> 

Well, yes, it is the manpage that gets installed.

> usr.bin/man/apropos.1
> 
> is the one that matches apropos(1)
> 

>From src/usr.bin/man/Makefile

.if ${MK_MANDOCDB} == no
LINKS+= ${BINDIR}/man ${BINDIR}/apropos \
${BINDIR}/man ${BINDIR}/whatis
MAN+=   apropos.1
MLINKS= apropos.1 whatis.1
.endif

I have not set or unset MK_MANDOCDB.  From src.opt.mk

__DEFAULT_YES_OPTIONS = \
...
MANDOCDB \
...

% svn blame src.opts.mk | grep MANDOC
283777   bapt MANDOCDB \
% svn log -r 283777

r283777 | bapt | 2015-05-30 10:41:37 -0700 (Sat, 30 May 2015) | 11 lines

Switch to mandoc's version of makewhatis(8), whatis(1), apropos(1) utilities.

This change among other things improve search capabilities over the manpages
allowing fine grain query.

A new build option WITHOUT_MANDOCDB has been added to keep the ancient version
of the database and the tools. The plan is to entirely remove this option before
11.0-RELEASE.

Differential Revision:  https://reviews.freebsd.org/D2603

-- 
Steve
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"

Re: MANPATH not handled correctly

2017-01-10 Thread Steve Kargl 
On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote:
> Steve Kargl  wrote:
> 
> > MANPATH is not handled correctly.  According to the documentation
> > in apropos(1) and whatis(1):
> 
> Can you clarify where you are seeing this documentation?
> I don't see it in 7.x 10.x or current.
> 

This an unaltered FreeBSD-current at r311832.

The text I quoted can be seen at 

https://svnweb.freebsd.org/base/head/contrib/mdocml/apropos.1?revision=294113=markup

starting at line 346 and ending at 362.

The Makefile in /usr/src/usr.bin at line 93 points at the 
directory mandoc.  The Makefile in /usr/src/usr.bin/mandoc
points at ../../contrib/mdocml.

-- 
Steve
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"

r311871: kernel build failure: ieee80211_vht.c:94:2: error: implicit declaration ...

2017-01-10 Thread O. Hartmann 
On CURRENT (r311871), I'm bothered with this error schown below. Buildkernel
fails. It is a customized kernel.

[...]
Building 
/usr/obj/usr/src/sys/FREYJA/modules/usr/src/sys/modules/wlan/ieee80211.o
Building 
/usr/obj/usr/src/sys/FREYJA/modules/usr/src/sys/modules/wlan/ieee80211_vht.o
/usr/src/sys/modules/wlan/../../net80211/ieee80211_vht.c:94:2: error: implicit
declaration of function 'ieee80211_note' is invalid in C99
[-Werror,-Wimplicit-function-declaration] ieee80211_note(ni->ni_vap, "%s:
called; fc=0x%.2x/0x%.2x", ^ 1 error generated.
*** Error code 1

Kind regards,

oh
___
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"