Re: ipv6_addrs_IF aliases in rc.conf(5)

[Michael Grimm]

On 2013-07-12 6:56, Hiroki Sato wrote:

Kevin Oberman  wrote
  in 
:


rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder  wrote:
rk>
rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
rk> > trash...@odo.in-berlin.de> wrote:
rk> >
rk> >  Will that patch make it into 9.2? If I am not mistaken, that 
patch isn't

rk> >> in stable yet.
rk> >>
rk> >
rk> > I would also like to see this patch hit 9.x sooner than later. 
It's so
rk> > painful when someone forgets to fix the alias numbering on 
servers with

rk> > many, many IPv4 and IPv6 addresses...
rk> >
rk>
rk> Please, please, please, please, ...!
rk>
rk> Freeze is only two days away, so time for 9.2 is almost over and I 
can see

rk> no good reason NOT to get this done.

 r252015 was merged to stable/9 today.


Thanks! This is highly appreciated. A first glance at network.subr tells 
me that
much more has been modified/simplified regarding alias definitions, 
great.


Regards, Michael

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

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2013-07-12 06:08:25 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 06:08:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 06:08:25 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2013-07-12 06:08:25 - cleaning the object tree
TB --- 2013-07-12 06:08:25 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 06:08:29 - At svn revision 253248
TB --- 2013-07-12 06:08:30 - building world
TB --- 2013-07-12 06:08:30 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 06:08:30 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 06:08:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 06:08:30 - SRCCONF=/dev/null
TB --- 2013-07-12 06:08:30 - TARGET=powerpc
TB --- 2013-07-12 06:08:30 - TARGET_ARCH=powerpc64
TB --- 2013-07-12 06:08:30 - TZ=UTC
TB --- 2013-07-12 06:08:30 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 06:08:30 - cd /src
TB --- 2013-07-12 06:08:30 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 06:08:36 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'long'
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are 
no arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'double'
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are 
no arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'float'
/obj/powerpc.powerpc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are 
no arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 06:37:54 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 06:37:54 - ERROR: failed to build world
TB --- 2013-07-12 06:37:54 - 1387.85 user 247.16 system 1768.52 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full
___
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"

[head tinderbox] failure on powerpc/powerpc

[FreeBSD Tinderbox]

TB --- 2013-07-12 06:07:51 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 06:07:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 06:07:51 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2013-07-12 06:07:51 - cleaning the object tree
TB --- 2013-07-12 06:07:51 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 06:07:56 - At svn revision 253248
TB --- 2013-07-12 06:07:57 - building world
TB --- 2013-07-12 06:07:57 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 06:07:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 06:07:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 06:07:57 - SRCCONF=/dev/null
TB --- 2013-07-12 06:07:57 - TARGET=powerpc
TB --- 2013-07-12 06:07:57 - TARGET_ARCH=powerpc
TB --- 2013-07-12 06:07:57 - TZ=UTC
TB --- 2013-07-12 06:07:57 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 06:07:57 - cd /src
TB --- 2013-07-12 06:07:57 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 06:08:04 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'long'
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'double'
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'float'
/obj/powerpc.powerpc/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 06:37:09 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 06:37:09 - ERROR: failed to build world
TB --- 2013-07-12 06:37:09 - 1373.97 user 243.75 system 1758.21 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full
___
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"

[head tinderbox] failure on sparc64/sparc64

[FreeBSD Tinderbox]

TB --- 2013-07-12 06:09:25 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 06:09:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 06:09:25 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2013-07-12 06:09:25 - cleaning the object tree
TB --- 2013-07-12 06:10:04 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 06:10:08 - At svn revision 253248
TB --- 2013-07-12 06:10:09 - building world
TB --- 2013-07-12 06:10:09 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 06:10:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 06:10:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 06:10:09 - SRCCONF=/dev/null
TB --- 2013-07-12 06:10:09 - TARGET=sparc64
TB --- 2013-07-12 06:10:09 - TARGET_ARCH=sparc64
TB --- 2013-07-12 06:10:09 - TZ=UTC
TB --- 2013-07-12 06:10:09 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 06:10:09 - cd /src
TB --- 2013-07-12 06:10:09 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 06:10:15 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'long'
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'double'
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'float'
/obj/sparc64.sparc64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 06:34:42 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 06:34:42 - ERROR: failed to build world
TB --- 2013-07-12 06:34:42 - 1101.79 user 218.78 system 1517.04 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full
___
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"

[head tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

TB --- 2013-07-12 05:40:17 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 05:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 05:40:17 - starting HEAD tinderbox run for ia64/ia64
TB --- 2013-07-12 05:40:17 - cleaning the object tree
TB --- 2013-07-12 05:40:17 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 05:40:20 - At svn revision 253248
TB --- 2013-07-12 05:40:21 - building world
TB --- 2013-07-12 05:40:21 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 05:40:21 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 05:40:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 05:40:21 - SRCCONF=/dev/null
TB --- 2013-07-12 05:40:21 - TARGET=ia64
TB --- 2013-07-12 05:40:21 - TARGET_ARCH=ia64
TB --- 2013-07-12 05:40:21 - TZ=UTC
TB --- 2013-07-12 05:40:21 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 05:40:21 - cd /src
TB --- 2013-07-12 05:40:21 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 05:40:28 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'long'
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'double'
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'float'
/obj/ia64.ia64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 06:09:25 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 06:09:25 - ERROR: failed to build world
TB --- 2013-07-12 06:09:25 - 1368.02 user 271.21 system 1747.77 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full
___
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"

[head tinderbox] failure on mips64/mips

[FreeBSD Tinderbox]

TB --- 2013-07-12 05:45:37 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 05:45:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 05:45:37 - starting HEAD tinderbox run for mips64/mips
TB --- 2013-07-12 05:45:37 - cleaning the object tree
TB --- 2013-07-12 05:45:37 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 05:45:40 - At svn revision 253248
TB --- 2013-07-12 05:45:41 - building world
TB --- 2013-07-12 05:45:41 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 05:45:41 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 05:45:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 05:45:41 - SRCCONF=/dev/null
TB --- 2013-07-12 05:45:41 - TARGET=mips
TB --- 2013-07-12 05:45:41 - TARGET_ARCH=mips64
TB --- 2013-07-12 05:45:41 - TZ=UTC
TB --- 2013-07-12 05:45:41 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 05:45:41 - cd /src
TB --- 2013-07-12 05:45:41 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 05:45:48 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'long'
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'double'
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'float'
/obj/mips.mips64/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 06:08:25 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 06:08:25 - ERROR: failed to build world
TB --- 2013-07-12 06:08:25 - 1021.77 user 229.49 system 1368.24 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full
___
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"

[head tinderbox] failure on mips/mips

[FreeBSD Tinderbox]

TB --- 2013-07-12 05:45:02 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 05:45:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 05:45:02 - starting HEAD tinderbox run for mips/mips
TB --- 2013-07-12 05:45:02 - cleaning the object tree
TB --- 2013-07-12 05:45:02 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 05:45:05 - At svn revision 253248
TB --- 2013-07-12 05:45:06 - building world
TB --- 2013-07-12 05:45:06 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 05:45:06 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 05:45:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 05:45:06 - SRCCONF=/dev/null
TB --- 2013-07-12 05:45:06 - TARGET=mips
TB --- 2013-07-12 05:45:06 - TARGET_ARCH=mips
TB --- 2013-07-12 05:45:06 - TZ=UTC
TB --- 2013-07-12 05:45:06 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 05:45:06 - cd /src
TB --- 2013-07-12 05:45:06 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 05:45:13 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'long'
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'double'
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'typeof'
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: expected 
primary-expression before 'float'
/obj/mips.mips/src/tmp/usr/include/c++/4.2/cmath:488: error: there are no 
arguments to '__builtin_types_compatible_p' that depend on a template 
parameter, so a declaration of '__builtin_types_compatible_p' must be available
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 06:07:50 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 06:07:50 - ERROR: failed to build world
TB --- 2013-07-12 06:07:50 - 1024.16 user 230.43 system 1368.47 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full
___
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"

[head tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for amd64/amd64
TB --- 2013-07-12 04:10:19 - cleaning the object tree
TB --- 2013-07-12 04:18:47 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 04:18:50 - At svn revision 253248
TB --- 2013-07-12 04:18:51 - building world
TB --- 2013-07-12 04:18:51 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 04:18:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 04:18:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 04:18:51 - SRCCONF=/dev/null
TB --- 2013-07-12 04:18:51 - TARGET=amd64
TB --- 2013-07-12 04:18:51 - TARGET_ARCH=amd64
TB --- 2013-07-12 04:18:51 - TZ=UTC
TB --- 2013-07-12 04:18:51 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 04:18:51 - cd /src
TB --- 2013-07-12 04:18:51 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 04:18:58 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
^~~~
/obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 
'signbit'
#define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl)
   ^~
/obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro 
'__fp_type_select'
__builtin_types_compatible_p(__typeof(x), long double), ld(x),\
^~
6 errors generated.
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 05:45:37 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 05:45:37 - ERROR: failed to build world
TB --- 2013-07-12 05:45:37 - 4353.59 user 679.80 system 5717.27 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full
___
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"

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for i386/i386
TB --- 2013-07-12 04:10:19 - cleaning the object tree
TB --- 2013-07-12 04:18:19 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 04:18:22 - At svn revision 253248
TB --- 2013-07-12 04:18:23 - building world
TB --- 2013-07-12 04:18:23 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 04:18:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 04:18:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 04:18:23 - SRCCONF=/dev/null
TB --- 2013-07-12 04:18:23 - TARGET=i386
TB --- 2013-07-12 04:18:23 - TARGET_ARCH=i386
TB --- 2013-07-12 04:18:23 - TZ=UTC
TB --- 2013-07-12 04:18:23 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 04:18:23 - cd /src
TB --- 2013-07-12 04:18:23 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 04:18:30 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
^~~~
/obj/i386.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 
'signbit'
#define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl)
   ^~
/obj/i386.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro 
'__fp_type_select'
__builtin_types_compatible_p(__typeof(x), long double), ld(x),\
^~
6 errors generated.
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 05:45:02 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 05:45:02 - ERROR: failed to build world
TB --- 2013-07-12 05:45:02 - 4337.52 user 685.93 system 5682.32 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full
___
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"

[head tinderbox] failure on armv6/arm

[FreeBSD Tinderbox]

TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for armv6/arm
TB --- 2013-07-12 04:10:19 - cleaning the object tree
TB --- 2013-07-12 04:10:19 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 04:10:23 - At svn revision 253248
TB --- 2013-07-12 04:10:24 - building world
TB --- 2013-07-12 04:10:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 04:10:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 04:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 04:10:24 - SRCCONF=/dev/null
TB --- 2013-07-12 04:10:24 - TARGET=arm
TB --- 2013-07-12 04:10:24 - TARGET_ARCH=armv6
TB --- 2013-07-12 04:10:24 - TZ=UTC
TB --- 2013-07-12 04:10:24 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 04:10:24 - cd /src
TB --- 2013-07-12 04:10:24 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 04:10:33 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
^~~~
/obj/arm.armv6/src/tmp/usr/include/math.h:128:20: note: expanded from macro 
'signbit'
#define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl)
   ^~
/obj/arm.armv6/src/tmp/usr/include/math.h:91:2: note: expanded from macro 
'__fp_type_select'
__builtin_types_compatible_p(__typeof(x), long double), ld(x),\
^~
6 errors generated.
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 05:40:17 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 05:40:17 - ERROR: failed to build world
TB --- 2013-07-12 05:40:17 - 4330.73 user 682.20 system 5397.30 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full
___
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"

[head tinderbox] failure on arm/arm

[FreeBSD Tinderbox]

TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for arm/arm
TB --- 2013-07-12 04:10:19 - cleaning the object tree
TB --- 2013-07-12 04:10:19 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 04:10:23 - At svn revision 253248
TB --- 2013-07-12 04:10:24 - building world
TB --- 2013-07-12 04:10:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 04:10:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 04:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 04:10:24 - SRCCONF=/dev/null
TB --- 2013-07-12 04:10:24 - TARGET=arm
TB --- 2013-07-12 04:10:24 - TARGET_ARCH=arm
TB --- 2013-07-12 04:10:24 - TZ=UTC
TB --- 2013-07-12 04:10:24 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 04:10:24 - cd /src
TB --- 2013-07-12 04:10:24 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 04:10:32 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
^~~~
/obj/arm.arm/src/tmp/usr/include/math.h:128:20: note: expanded from macro 
'signbit'
#define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl)
   ^~
/obj/arm.arm/src/tmp/usr/include/math.h:91:2: note: expanded from macro 
'__fp_type_select'
__builtin_types_compatible_p(__typeof(x), long double), ld(x),\
^~
6 errors generated.
*** Error code 1

Stop.
make: stopped in /src/gnu/lib/libstdc++
*** Error code 1

Stop.
make: stopped in /src/gnu/lib
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-07-12 05:40:15 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-07-12 05:40:15 - ERROR: failed to build world
TB --- 2013-07-12 05:40:15 - 4327.65 user 679.95 system 5396.15 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full
___
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: ipv6_addrs_IF aliases in rc.conf(5)

[Kevin Oberman]

On Thu, Jul 11, 2013 at 9:56 PM, Hiroki Sato  wrote:

> Kevin Oberman  wrote
>   in :
>
> rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder  wrote:
> rk>
> rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
> rk> > trash...@odo.in-berlin.de> wrote:
> rk> >
> rk> >  Will that patch make it into 9.2? If I am not mistaken, that patch
> isn't
> rk> >> in stable yet.
> rk> >>
> rk> >
> rk> > I would also like to see this patch hit 9.x sooner than later. It's
> so
> rk> > painful when someone forgets to fix the alias numbering on servers
> with
> rk> > many, many IPv4 and IPv6 addresses...
> rk> >
> rk>
> rk> Please, please, please, please, ...!
> rk>
> rk> Freeze is only two days away, so time for 9.2 is almost over and I can
> see
> rk> no good reason NOT to get this done.
>
>  r252015 was merged to stable/9 today.
>
> -- Hiroki
>

Just under the wire! I'm sure that I am not the only one who appreciates it.

-- 
R. Kevin Oberman, Network Engineer
E-mail: rkober...@gmail.com
___
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: ipv6_addrs_IF aliases in rc.conf(5)

[Hiroki Sato]

Kevin Oberman  wrote
  in :

rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder  wrote:
rk>
rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
rk> > trash...@odo.in-berlin.de> wrote:
rk> >
rk> >  Will that patch make it into 9.2? If I am not mistaken, that patch isn't
rk> >> in stable yet.
rk> >>
rk> >
rk> > I would also like to see this patch hit 9.x sooner than later. It's so
rk> > painful when someone forgets to fix the alias numbering on servers with
rk> > many, many IPv4 and IPv6 addresses...
rk> >
rk>
rk> Please, please, please, please, ...!
rk>
rk> Freeze is only two days away, so time for 9.2 is almost over and I can see
rk> no good reason NOT to get this done.

 r252015 was merged to stable/9 today.

-- Hiroki


pgpwhHHP9UTVY.pgp
Description: PGP signature

[head tinderbox] failure on sparc64/sparc64

[FreeBSD Tinderbox]

TB --- 2013-07-12 01:00:05 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-12 01:00:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-12 01:00:05 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2013-07-12 01:00:05 - cleaning the object tree
TB --- 2013-07-12 01:01:29 - /usr/local/bin/svn stat /src
TB --- 2013-07-12 01:01:32 - At svn revision 253214
TB --- 2013-07-12 01:01:33 - building world
TB --- 2013-07-12 01:01:33 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 01:01:33 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 01:01:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 01:01:33 - SRCCONF=/dev/null
TB --- 2013-07-12 01:01:33 - TARGET=sparc64
TB --- 2013-07-12 01:01:33 - TARGET_ARCH=sparc64
TB --- 2013-07-12 01:01:33 - TZ=UTC
TB --- 2013-07-12 01:01:33 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 01:01:33 - cd /src
TB --- 2013-07-12 01:01:33 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jul 12 01:01:40 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Fri Jul 12 02:05:13 UTC 2013
TB --- 2013-07-12 02:05:13 - generating LINT kernel config
TB --- 2013-07-12 02:05:13 - cd /src/sys/sparc64/conf
TB --- 2013-07-12 02:05:13 - /usr/bin/make -B LINT
TB --- 2013-07-12 02:05:13 - cd /src/sys/sparc64/conf
TB --- 2013-07-12 02:05:13 - /usr/sbin/config -m LINT
TB --- 2013-07-12 02:05:13 - building LINT kernel
TB --- 2013-07-12 02:05:13 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-12 02:05:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-12 02:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-12 02:05:13 - SRCCONF=/dev/null
TB --- 2013-07-12 02:05:13 - TARGET=sparc64
TB --- 2013-07-12 02:05:13 - TARGET_ARCH=sparc64
TB --- 2013-07-12 02:05:13 - TZ=UTC
TB --- 2013-07-12 02:05:13 - __MAKE_CONF=/dev/null
TB --- 2013-07-12 02:05:13 - cd /src
TB --- 2013-07-12 02:05:13 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Jul 12 02:05:13 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float 
-ffreestanding -fstack-protector -Werror  /src/sys/net80211/ieee80211_mesh.c
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float 
-ffreestanding -fstack-protector -Werror  /src/sys/net80211/ieee80211_monitor.c
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float 
-ffreestanding -fstack-protector -Werror  /src/sys/net80211/ieee80211_node.c
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-f

Re: hacking - aio_sendfile()

[David Xu]

On 2013/07/11 14:17, Konstantin Belousov wrote:

On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:

Hiya,

I've started writing an aio_sendfile() syscall.

http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff

Yes, the diff is against -HEAD and not stable/9.

It's totally horrible, hackish and likely bad. I've only done some
very, very basic testing to ensure it actually works; i haven't at all
stress tested it out yet. It's also very naive - I'm not at all doing
any checks to see whether I can short-cut to do the aio there and
then; I'm always queuing the sendfile() op through the worker threads.
That's likely stupid and inefficient in a lot of cases, but it at
least gets the syscall up and working.

Yes, it is naive, but for different reason.

The kern_sendfile() is synchronous function, it only completes after
the other end of the network communication allows it. This means
that calling kern_sendfile() from the aio thread blocks the thread
indefinitely by unbounded sleep.

Your implementation easily causes exhaustion of the aio thread pool,
blocking the whole aio subsystem. It is known that our aio does not work
for sockets for the same reason. I object against adding more code with
the same defect.

Proper route seems to rewrite aio for sockets using the upcalls.  The same
should be done for sendfile, if sendfile is given aio flavor.



Yes, current aio implementation is horrible, it only works for fast 
disk I/O, I think the thread pool size is enough to saturate disks,

but for socket or pipe I/O, it does not work well, the thread pool is
too easy to be exhausted.

I even think the support for socket and pipe in aio code should be
cut and thrown away, because you can always use kqueue + non-blocking
I/O.

___
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: NFS panic: newnfs_copycred: negative nfsc_ngroups (client HEAD r253033, server 9.1-R)

[Rick Macklem]

Bryan Drewery wrote:
> I received this panic on the client while doing heavy parallel
> reads/writes over NFS. I only recently moved these files to NFS, so I
> don't know whether or not it's a recent regression.
> 
> Client: HEAD r253033
> Server: 9.1-R
> 
> core.txt: http://people.freebsd.org/~bdrewery/nfs.txt
> 
> fstab of related paths:
> 
> > tank:/tank/distfiles/freebsd/mnt/distfiles
> >  nfs
> > rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv4
> >0   0
> > tank:/usr/packages/
> > /mnt/all-packages   nfs
> > 
> > rw,bg,noatime,soft,retrycnt=3,rsize=65536,wsize=65536,readahead=8,nfsv4
> >0   0
The mount options "soft" and "intr" should never be used for NFSv4. If an RPC 
fails
with ETIMEDOUT or EINTR it can leave the open state in an undefined state. If 
you
still get one of these crashes with all hard mounts, email again, since that 
would
imply a client bug. (This is documented in the BUGS sections of mount_nfs(1), 
but
not very well.;-)

I'm not sure if this undefined open state could cause the crash, but it seems
plausible, since the crash indicates garbage for the credentials in the open 
state 
structure.

rick

> 
> Server: params on these paths: -maproot=root -network 10.10.0.0/16
> 
> tcpdump at the time:
> 
> > 21:43:05.396585 IP 10.10.0.7.4180315003 > 10.10.0.5.2049: 168
> > getattr fh 0,4/2
> > 21:43:05.396589 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48265029:48266477, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396603 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48266477:48267925, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396605 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack
> > 48266477, win 3916, options [nop,nop,TS val 596674 ecr
> > 1950216660], length 0
> > 21:43:05.396608 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48267925:48269373, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396621 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48269373:48270821, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396624 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack
> > 48269373, win 3870, options [nop,nop,TS val 596674 ecr
> > 1950216660], length 0
> > 21:43:05.396641 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48270821:48272269, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396653 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48272269:48273717, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396656 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack
> > 48272269, win 3825, options [nop,nop,TS val 596674 ecr
> > 1950216660], length 0
> > 21:43:05.396659 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48273717:48275165, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396671 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48275165:48276613, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396674 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack
> > 48275165, win 3780, options [nop,nop,TS val 596674 ecr
> > 1950216660], length 0
> > 21:43:05.396676 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48276613:48278061, ack 4394885, win 29124, options [nop,nop,TS val
> > 1950216660 ecr 596674], length 1448
> > 21:43:05.396689 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq
> > 48278061:48279509, ack 4394885, win 29124, options [nop,nop,TS val
> > Write failed: Broken pipe
> 
> I have nfsuserd running on both client/server. nfscbd is running.
> nfs_client_enable=yes in rc.conf.
> 
> User lookups seem to work fine:
> 
> > -rw-r--r--  1 root  bryan  1554804 Jul  6 10:50
> > /mnt/distfiles/pkg-1.1.4.tar.xz
> 
> I ran a find -ls on these paths and all files return a user/group. I
> am
> guessing there is a race condition with files being written and
> looking
> up the associated groups.
> 
> --
> Regards,
> Bryan Drewery
> bdrewery@freenode/EFNet
> ___
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-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"

[head tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2013-07-11 17:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-11 17:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-11 17:00:18 - starting HEAD tinderbox run for amd64/amd64
TB --- 2013-07-11 17:00:18 - cleaning the object tree
TB --- 2013-07-11 17:00:18 - /usr/local/bin/svn stat /src
TB --- 2013-07-11 17:00:23 - At svn revision 253214
TB --- 2013-07-11 17:00:24 - building world
TB --- 2013-07-11 17:00:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 17:00:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 17:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 17:00:24 - SRCCONF=/dev/null
TB --- 2013-07-11 17:00:24 - TARGET=amd64
TB --- 2013-07-11 17:00:24 - TARGET_ARCH=amd64
TB --- 2013-07-11 17:00:24 - TZ=UTC
TB --- 2013-07-11 17:00:24 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 17:00:24 - cd /src
TB --- 2013-07-11 17:00:24 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Jul 11 17:00:31 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Thu Jul 11 20:48:41 UTC 2013
TB --- 2013-07-11 20:48:41 - generating LINT kernel config
TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf
TB --- 2013-07-11 20:48:41 - /usr/bin/make -B LINT
TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf
TB --- 2013-07-11 20:48:41 - /usr/sbin/config -m LINT
TB --- 2013-07-11 20:48:41 - building LINT kernel
TB --- 2013-07-11 20:48:41 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 20:48:41 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 20:48:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 20:48:41 - SRCCONF=/dev/null
TB --- 2013-07-11 20:48:41 - TARGET=amd64
TB --- 2013-07-11 20:48:41 - TARGET_ARCH=amd64
TB --- 2013-07-11 20:48:41 - TZ=UTC
TB --- 2013-07-11 20:48:41 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 20:48:41 - cd /src
TB --- 2013-07-11 20:48:41 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Jul 11 20:48:41 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Thu Jul 11 21:20:29 UTC 2013
TB --- 2013-07-11 21:20:29 - cd /src/sys/amd64/conf
TB --- 2013-07-11 21:20:29 - /usr/sbin/config -m LINT-NOINET
TB --- 2013-07-11 21:20:29 - building LINT-NOINET kernel
TB --- 2013-07-11 21:20:29 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 21:20:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 21:20:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 21:20:29 - SRCCONF=/dev/null
TB --- 2013-07-11 21:20:29 - TARGET=amd64
TB --- 2013-07-11 21:20:29 - TARGET_ARCH=amd64
TB --- 2013-07-11 21:20:29 - TZ=UTC
TB --- 2013-07-11 21:20:29 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 21:20:29 - cd /src
TB --- 2013-07-11 21:20:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Thu Jul 11 21:20:30 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Thu Jul 11 21:50:20 UTC 2013
TB --- 2013-07-11 21:50:20 - cd /src/sys/amd64/conf
TB --- 2013-07-11 21:50:20 - /usr/sbin/config -m LINT-NOINET6
TB --- 2013-07-11 21:50:20 - building LINT-NOINET6 kernel
TB --- 2013-07-11 21:50:20 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 21:50:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 21:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 21:50:20 - SRCCONF=/dev/null
TB --- 2013-07-11 21:50:20 - TARGET=amd64
TB --- 2013-07-11 21:50:20 - TARGET_ARCH=amd64
TB --- 2013-07-11 21:50:20 - TZ=UTC
TB --- 2013-07-11 21:50:20 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 21:50:20 - cd /src
TB --- 2013-07-11 21:50:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Thu Jul 11 21:50:20 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Thu Jul 11 22:20:11 UTC 2013
TB --- 2013-07-11 22:20:11 - cd /src/sys/amd64/conf
TB --- 2013-07-11 22:20:11 - /usr/sbin/confi

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2013-07-11 17:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-11 17:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-11 17:00:18 - starting HEAD tinderbox run for i386/i386
TB --- 2013-07-11 17:00:18 - cleaning the object tree
TB --- 2013-07-11 17:00:18 - /usr/local/bin/svn stat /src
TB --- 2013-07-11 17:00:23 - At svn revision 253214
TB --- 2013-07-11 17:00:24 - building world
TB --- 2013-07-11 17:00:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 17:00:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 17:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 17:00:24 - SRCCONF=/dev/null
TB --- 2013-07-11 17:00:24 - TARGET=i386
TB --- 2013-07-11 17:00:24 - TARGET_ARCH=i386
TB --- 2013-07-11 17:00:24 - TZ=UTC
TB --- 2013-07-11 17:00:24 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 17:00:24 - cd /src
TB --- 2013-07-11 17:00:24 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Jul 11 17:00:31 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Jul 11 20:12:25 UTC 2013
TB --- 2013-07-11 20:12:25 - generating LINT kernel config
TB --- 2013-07-11 20:12:25 - cd /src/sys/i386/conf
TB --- 2013-07-11 20:12:25 - /usr/bin/make -B LINT
TB --- 2013-07-11 20:12:25 - cd /src/sys/i386/conf
TB --- 2013-07-11 20:12:25 - /usr/sbin/config -m LINT
TB --- 2013-07-11 20:12:25 - building LINT kernel
TB --- 2013-07-11 20:12:25 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 20:12:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 20:12:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 20:12:25 - SRCCONF=/dev/null
TB --- 2013-07-11 20:12:25 - TARGET=i386
TB --- 2013-07-11 20:12:25 - TARGET_ARCH=i386
TB --- 2013-07-11 20:12:25 - TZ=UTC
TB --- 2013-07-11 20:12:25 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 20:12:25 - cd /src
TB --- 2013-07-11 20:12:25 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Jul 11 20:12:25 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Thu Jul 11 20:46:43 UTC 2013
TB --- 2013-07-11 20:46:43 - cd /src/sys/i386/conf
TB --- 2013-07-11 20:46:43 - /usr/sbin/config -m LINT-NOINET
TB --- 2013-07-11 20:46:43 - building LINT-NOINET kernel
TB --- 2013-07-11 20:46:43 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 20:46:43 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 20:46:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 20:46:43 - SRCCONF=/dev/null
TB --- 2013-07-11 20:46:43 - TARGET=i386
TB --- 2013-07-11 20:46:43 - TARGET_ARCH=i386
TB --- 2013-07-11 20:46:43 - TZ=UTC
TB --- 2013-07-11 20:46:43 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 20:46:43 - cd /src
TB --- 2013-07-11 20:46:43 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Thu Jul 11 20:46:43 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Thu Jul 11 21:17:55 UTC 2013
TB --- 2013-07-11 21:17:55 - cd /src/sys/i386/conf
TB --- 2013-07-11 21:17:55 - /usr/sbin/config -m LINT-NOINET6
TB --- 2013-07-11 21:17:55 - building LINT-NOINET6 kernel
TB --- 2013-07-11 21:17:55 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 21:17:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 21:17:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 21:17:55 - SRCCONF=/dev/null
TB --- 2013-07-11 21:17:55 - TARGET=i386
TB --- 2013-07-11 21:17:55 - TARGET_ARCH=i386
TB --- 2013-07-11 21:17:55 - TZ=UTC
TB --- 2013-07-11 21:17:55 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 21:17:55 - cd /src
TB --- 2013-07-11 21:17:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Thu Jul 11 21:17:55 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Thu Jul 11 21:49:28 UTC 2013
TB --- 2013-07-11 21:49:28 - cd /src/sys/i386/conf
TB --- 2013-07-11 21:49:28 - /usr/sbin/config -m LINT-NOIP
TB --- 2013-07-11 21:49:28 - building LINT-NOI

Re: hacking - aio_sendfile()

[Konstantin Belousov]

On Thu, Jul 11, 2013 at 12:04:57PM -0700, Scott Long wrote:
> 
> On Jul 11, 2013, at 11:48 AM, Konstantin Belousov  wrote:
> 
> > On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote:
> >> 
> >> On Jul 10, 2013, at 11:17 PM, Konstantin Belousov  
> >> wrote:
> >> 
> >>> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:
>  Hiya,
>  
>  I've started writing an aio_sendfile() syscall.
>  
>  http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff
>  
>  Yes, the diff is against -HEAD and not stable/9.
>  
>  It's totally horrible, hackish and likely bad. I've only done some
>  very, very basic testing to ensure it actually works; i haven't at all
>  stress tested it out yet. It's also very naive - I'm not at all doing
>  any checks to see whether I can short-cut to do the aio there and
>  then; I'm always queuing the sendfile() op through the worker threads.
>  That's likely stupid and inefficient in a lot of cases, but it at
>  least gets the syscall up and working.
> >>> Yes, it is naive, but for different reason.
> >>> 
> >>> The kern_sendfile() is synchronous function, it only completes after
> >>> the other end of the network communication allows it. This means
> >>> that calling kern_sendfile() from the aio thread blocks the thread
> >>> indefinitely by unbounded sleep.
> >> 
> >> 
> >> No, kern_sendfile is async unless you specify the SF_SYNC hack flag.
> >> Otherwise, it'll fill the socket buffer and then return immediately, unless
> >> the socket buffer is full and the socket is set to blocking mode.  That's
> >> outside the scope, as I said in my previous email.
> > 
> > You do not understand what I said, please re-read both my mail and code
> > before replying.  Implementing aio_sendfile() as proposed would create
> > yet another possibility of indefinitely block all processes using aio.
> 
> I'm lost, maybe I missed some emails?  I see a set of emails where you 
> incorrectly
> state that kern_sendfile() will always call sbwait(), and then you backtrack 
> on that
> and claim that it's unacceptable to enforce that SS_NBIO be used for aio 
> operations.
> I apologize if I'm missing something here.

Can you cite my exact text where I claimed that kern_sendfile() always calls
sbwait ?

I wrote about this explicitely, stating that it is very easy to make
kern_sendfile() sleep for the socket buffer space, and the duration
of the sleep is user-controllable.  As result, it allows to hang all
processes doing aio calls, since aio thread pool is finite.  I am sorry
for retyping this and stealing your time by repeating.

Making the kern_sendfile() to behave from the aio context as if the
SS_NBIO was set on the socket contradicts the behaviour of other aio
operations. E.g. aio_read and aio_write do not perform short reads and
writes to not block the aio daemon threads (which is the cause of buggy
behaviour of existing aio syscalls on sockets).

More, I do not think that setting SS_NBIO is enough to prevent the
blocking of aio threads in kern_sendfile(). The send socket buffer
is locked exclusively by kern_sendfile(). Other thread which entered
sendfile(2) and was deliberately put to sleep on the low watermark,
still owns the so_snd sx. This means that aio threads trying to do
kern_sendfile() on this socket would be also blocked, for duration
controlled by other end.

That said, even assuming SS_NBIO is always enforced and other sleep
points are identified and worked around, the only benefit of such
implementation comparing with the direct sendfile(2) call would be
preventing the use of the calling thread context for disk i/o. FreeBSD
recently gained aio_mlock(2) which allows to get the same result in
non-hackish way.


pgp2L4b4m0tRA.pgp
Description: PGP signature

Re: hacking - aio_sendfile()

[Scott Long]

On Jul 11, 2013, at 11:48 AM, Konstantin Belousov  wrote:

> On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote:
>> 
>> On Jul 10, 2013, at 11:17 PM, Konstantin Belousov  
>> wrote:
>> 
>>> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:
 Hiya,
 
 I've started writing an aio_sendfile() syscall.
 
 http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff
 
 Yes, the diff is against -HEAD and not stable/9.
 
 It's totally horrible, hackish and likely bad. I've only done some
 very, very basic testing to ensure it actually works; i haven't at all
 stress tested it out yet. It's also very naive - I'm not at all doing
 any checks to see whether I can short-cut to do the aio there and
 then; I'm always queuing the sendfile() op through the worker threads.
 That's likely stupid and inefficient in a lot of cases, but it at
 least gets the syscall up and working.
>>> Yes, it is naive, but for different reason.
>>> 
>>> The kern_sendfile() is synchronous function, it only completes after
>>> the other end of the network communication allows it. This means
>>> that calling kern_sendfile() from the aio thread blocks the thread
>>> indefinitely by unbounded sleep.
>> 
>> 
>> No, kern_sendfile is async unless you specify the SF_SYNC hack flag.
>> Otherwise, it'll fill the socket buffer and then return immediately, unless
>> the socket buffer is full and the socket is set to blocking mode.  That's
>> outside the scope, as I said in my previous email.
> 
> You do not understand what I said, please re-read both my mail and code
> before replying.  Implementing aio_sendfile() as proposed would create
> yet another possibility of indefinitely block all processes using aio.

I'm lost, maybe I missed some emails?  I see a set of emails where you 
incorrectly
state that kern_sendfile() will always call sbwait(), and then you backtrack on 
that
and claim that it's unacceptable to enforce that SS_NBIO be used for aio 
operations.
I apologize if I'm missing something here.

Scott

___
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: hacking - aio_sendfile()

[Scott Long]

On Jul 11, 2013, at 2:56 AM, Konstantin Belousov  wrote:

> On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote:
>> On 11 July 2013 02:36, Konstantin Belousov  wrote:
>> 
>>> No, it is not disk I/O which is problematic there. It is socket I/O
>>> e.g. wait for the socket buffers lomark in the kern_sendfile() which
>>> causes unbounded sleep. Look for the sbwait() call, both in the
>>> kern_sendfile() itself, and in the pru_send methods of the protocols,
>>> e.g. in sosend_generic(). The wait scope controlled by the other side of
>>> connection and allow it to completely block the aio subsystem.
>>> 
>>> Disk I/O is supposed to finish in the finite time.
>> 
>> Even if the destination socket is marked as NONBLOCK?
> 
> You mean, would a sleep for the socket buffer space cause aio thread
> block is the socket is put in nonblocking mode ?  Or something else ?
> 
> No, it would not block the thread. But I cannot consider the
> aio_sendfile(2) implementation useful if it requires non-blocking
> socket. Also, what about other thread changing the socket to blocking
> mode while sendfile is in flight ?

Just as with other aspects of sendfile, it's up to the caller to protect this 
kind
of state.  Objecting to aio_sendfile() simply for the reason you state is absurd
and against the design goals of sendfile.

Scott

___
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: hacking - aio_sendfile()

[Konstantin Belousov]

On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote:
> 
> On Jul 10, 2013, at 11:17 PM, Konstantin Belousov  wrote:
> 
> > On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:
> >> Hiya,
> >> 
> >> I've started writing an aio_sendfile() syscall.
> >> 
> >> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff
> >> 
> >> Yes, the diff is against -HEAD and not stable/9.
> >> 
> >> It's totally horrible, hackish and likely bad. I've only done some
> >> very, very basic testing to ensure it actually works; i haven't at all
> >> stress tested it out yet. It's also very naive - I'm not at all doing
> >> any checks to see whether I can short-cut to do the aio there and
> >> then; I'm always queuing the sendfile() op through the worker threads.
> >> That's likely stupid and inefficient in a lot of cases, but it at
> >> least gets the syscall up and working.
> > Yes, it is naive, but for different reason.
> > 
> > The kern_sendfile() is synchronous function, it only completes after
> > the other end of the network communication allows it. This means
> > that calling kern_sendfile() from the aio thread blocks the thread
> > indefinitely by unbounded sleep.
> 
> 
> No, kern_sendfile is async unless you specify the SF_SYNC hack flag.
> Otherwise, it'll fill the socket buffer and then return immediately, unless
> the socket buffer is full and the socket is set to blocking mode.  That's
> outside the scope, as I said in my previous email.

You do not understand what I said, please re-read both my mail and code
before replying.  Implementing aio_sendfile() as proposed would create
yet another possibility of indefinitely block all processes using aio.


pgpZPbm2SyxrI.pgp
Description: PGP signature

Re: hacking - aio_sendfile()

[Scott Long]

On Jul 10, 2013, at 11:17 PM, Konstantin Belousov  wrote:

> On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:
>> Hiya,
>> 
>> I've started writing an aio_sendfile() syscall.
>> 
>> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff
>> 
>> Yes, the diff is against -HEAD and not stable/9.
>> 
>> It's totally horrible, hackish and likely bad. I've only done some
>> very, very basic testing to ensure it actually works; i haven't at all
>> stress tested it out yet. It's also very naive - I'm not at all doing
>> any checks to see whether I can short-cut to do the aio there and
>> then; I'm always queuing the sendfile() op through the worker threads.
>> That's likely stupid and inefficient in a lot of cases, but it at
>> least gets the syscall up and working.
> Yes, it is naive, but for different reason.
> 
> The kern_sendfile() is synchronous function, it only completes after
> the other end of the network communication allows it. This means
> that calling kern_sendfile() from the aio thread blocks the thread
> indefinitely by unbounded sleep.


No, kern_sendfile is async unless you specify the SF_SYNC hack flag.
Otherwise, it'll fill the socket buffer and then return immediately, unless
the socket buffer is full and the socket is set to blocking mode.  That's
outside the scope, as I said in my previous email.

Scott

___
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: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[Bruce Evans]

On Thu, 11 Jul 2013, David Chisnall wrote:


On 11 Jul 2013, at 13:11, Bruce Evans  wrote:


The error message for the __builtin_isnan() version is slightly better up
to where it says more.

The less-unportable macro can do more classification and detect problems
at compile time using __typeof().


The attached patch fixes the related test cases in the libc++ test suite.  
Please review.


OK if the ifdefs work and the style bugs are fixed.


This does not use __builtin_isnan(), but it does:

- Stop exposing isnan and isinf in the header.  We already have __isinf in 
libc, so this is used instead.

- Call the static functions for isnan __inline__isnan*() so that they don't 
conflict with the ones in libm.

- Add an __fp_type_select() macro that uses either __Generic(), 
__builtin_choose_expr() / __builtin_choose_expr(), or sizeof() comparisons, 
depending on what the compiler supports.

- Refactor all of the type-generic macros to use __fp_type_select().


% Index: src/math.h
% ===
% --- src/math.h(revision 253148)
% +++ src/math.h(working copy)
% @@ -80,28 +80,39 @@
%  #define  FP_NORMAL   0x04
%  #define  FP_SUBNORMAL0x08
%  #define  FP_ZERO 0x10
% +
% +#if __STDC_VERSION__ >= 201112L
% +#define __fp_type_select(x, f, d, ld) _Generic((x), \
% + float: f(x),\
% + double: d(x),   \
% + long double: ld(x))

The normal formatting of this is unclear.  Except for the tab after #define.
math.h has only 1 other instance of a space after #define.

% +#elif __GNUC_PREREQ__(5, 1)
% +#define __fp_type_select(x, f, d, ld) __builtin_choose_expr( 
  \
% + __builtin_types_compatible_p(__typeof (x), long double), ld(x),\
% +  __builtin_choose_expr(\
% +   __builtin_types_compatible_p(__typeof (x), double), d(x),\
% +__builtin_choose_expr(  \
% + __builtin_types_compatible_p(__typeof (x), float), f(x), (void)0)))

Extra space after __typeof.

Normal formatting doesn't march to the right like this...

% +#else
% +#define __fp_type_select(x, f, d, ld) \
% + ((sizeof (x) == sizeof (float)) ? f(x)\
% +  : (sizeof (x) == sizeof (double)) ? d(x) \
% +  : ld(x))

... or like this.

Extra space after sizeof (bug copied from old code).

% +#endif
% +
% +
% +

Extra blank lines.

%  #define  fpclassify(x) \
% -((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \
% -: (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \
% -: __fpclassifyl(x))

Example of normal style in old code (except for the space after sizeof(),
and the backslashes aren't line up like they are in some other places in
this file).

% ...
% @@ -119,10 +130,8 @@
%  #define  isunordered(x, y)   (isnan(x) || isnan(y))
%  #endif /* __MATH_BUILTIN_RELOPS */
% 
% -#define	signbit(x)	\

% -((sizeof (x) == sizeof (float)) ? __signbitf(x)  \
% -: (sizeof (x) == sizeof (double)) ? __signbit(x) \
% -: __signbitl(x))
% +#define signbit(x) \
% + __fp_type_select(x, __signbitf, __signbit, __signbitl)

The tab lossage is especially obvious here.

This macro definition fits on 1 line now.  Similarly for others except
__inline_isnan*, which takes 2 lines.  __inline_isnan* should be named
less verbosely, without __inline.  I think this doesn't cause any
significant conflicts with libm.  Might need __always_inline.
__fp_type_select is also verbose.

% 
%  typedef	__double_t	double_t;

%  typedef  __float_t   float_t;
% @@ -175,6 +184,7 @@
%  int  __isfinite(double) __pure2;
%  int  __isfinitel(long double) __pure2;
%  int  __isinff(float) __pure2;
% +int  __isinf(double) __pure2;
%  int  __isinfl(long double) __pure2;
%  int  __isnanf(float) __pure2;
%  int  __isnanl(long double) __pure2;
% @@ -185,6 +195,23 @@
%  int  __signbitf(float) __pure2;
%  int  __signbitl(long double) __pure2;

The declarations of old extern functions can probably be removed too
when they are replaced by inlines (only __isnan*() for now) .  I think
the declarations of __isnan*() are now only used to prevent warnings
(at higher warning levels than have ever been used) in the file that
implement the functions.

% 
% +static __inline int

% +__inline_isnanf(float __x)
% +{
% + return (__x != __x);
% +}
% +static __inline int
% +__inline_isnan(double __x)
% +{
% + return (__x != __x);
% +}
% +static __inline int
% +__inline_isnanl(long double __x)
% +{
% + return (__x != __x);
% +}
% +
% +

Extra blank lines.

Some insertion sort errors.  In this file, APIs are mostly sorted in the
order double, float, long double.

All the inline functions except __inline_isnan*() only evaluate their
args once, so they can be simpler shorter and less names

Re: [head tinderbox] failure on sparc64/sparc64

[John Baldwin]

On Thursday, July 11, 2013 3:07:33 am Adrian Chadd wrote:
> On 11 July 2013 00:05, Navdeep Parhar  wrote:
> > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote:
> >> I don't get why this is dying. any ideas?
> >
> > Maybe because sparc64's ucontext.h is getting pulled in, and it has
> > this:
> >
> > #define mc_flagsmc_global[0]
> 
> Ugh, we should fix this. When did this happen?

annotate is your friend.  It's over 10 years old:

Working file: /home/jhb/work/freebsd/svn/head/sys/sparc64/include/ucontext.h

r105733 | jake | 2002-10-22 14:03:15 -0400 (Tue, 22 Oct 2002) | 13 lines

- Expand struct trapframe to 256 bytes, make all fields fixed width and the
  same size.  Add some fields that previously overlapped with something else
  or were missing.
- Make struct regs and struct mcontext (minus floating point) the same as
  struct trapframe so converting between them is easy (null).
- Add space for saving floating point state to struct mcontext.  This requires
  that it be 64 byte aligned.
- Add assertions that none of these structures change size, as they are part
  of the ABI.
- Remove some dead code in sendsig().
- Save and restore %gsr in struct trapframe.  Remember to restore %fsr.
- Add some comments to exception.S.



-- 
John Baldwin
___
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: fix for SVN r253208 breaking buildkernel with gcc

[Andre Oppermann]

On 11.07.2013 18:09, Michael Butler wrote:

On 07/11/13 12:07, Michael Butler wrote:

Seems gcc is rather fussy about propagating 'const' and fails to compile
/usr/src/sys/crypto/siphash/siphash.c after SVN r253208.

I believe the attached patch is correct but please review ..

imb


grr .. missing attachment :-(


Thanks, applied your patch in r253214.

--
Andre


Index: /usr/src/sys/crypto/siphash/siphash.c
===
--- /usr/src/sys/crypto/siphash/siphash.c   (revision 253210)
+++ /usr/src/sys/crypto/siphash/siphash.c   (working copy)
@@ -119,7 +119,8 @@
  void
  SipHash_Update(SIPHASH_CTX *ctx, const void *src, size_t len)
  {
-   uint64_t m, *p;
+   uint64_t m;
+   const uint64_t *p;
 const uint8_t *s;
 size_t rem;

@@ -144,13 +145,13 @@

 /* Optimze for 64bit aligned/unaligned access. */
 if (((uintptr_t)s & 0x7) == 0) {
-   for (p = (uint64_t *)s; len > 0; len--, p++) {
+   for (p = (const uint64_t *)s; len > 0; len--, p++) {
 m = le64toh(*p);
 ctx->v[3] ^= m;
 SipRounds(ctx, 0);
 ctx->v[0] ^= m;
 }
-   s = (uint8_t *)p;
+   s = (const uint8_t *)p;
 } else {
 for (; len > 0; len--, s += 8) {
 m = le64dec(s);


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

Re: fix for SVN r253208 breaking buildkernel with gcc

[Michael Butler]

On 07/11/13 12:07, Michael Butler wrote:
> Seems gcc is rather fussy about propagating 'const' and fails to compile
> /usr/src/sys/crypto/siphash/siphash.c after SVN r253208.
> 
> I believe the attached patch is correct but please review ..
> 
>   imb

grr .. missing attachment :-(

Index: /usr/src/sys/crypto/siphash/siphash.c
===
--- /usr/src/sys/crypto/siphash/siphash.c   (revision 253210)
+++ /usr/src/sys/crypto/siphash/siphash.c   (working copy)
@@ -119,7 +119,8 @@
 void
 SipHash_Update(SIPHASH_CTX *ctx, const void *src, size_t len)
 {
-   uint64_t m, *p;
+   uint64_t m;
+   const uint64_t *p;
const uint8_t *s;
size_t rem;

@@ -144,13 +145,13 @@

/* Optimze for 64bit aligned/unaligned access. */
if (((uintptr_t)s & 0x7) == 0) {
-   for (p = (uint64_t *)s; len > 0; len--, p++) {
+   for (p = (const uint64_t *)s; len > 0; len--, p++) {
m = le64toh(*p);
ctx->v[3] ^= m;
SipRounds(ctx, 0);
ctx->v[0] ^= m;
}
-   s = (uint8_t *)p;
+   s = (const uint8_t *)p;
} else {
for (; len > 0; len--, s += 8) {
m = le64dec(s);


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

fix for SVN r253208 breaking buildkernel with gcc

[Michael Butler]

Seems gcc is rather fussy about propagating 'const' and fails to compile
/usr/src/sys/crypto/siphash/siphash.c after SVN r253208.

I believe the attached patch is correct but please review ..

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

[head tinderbox] failure on sparc64/sparc64

[FreeBSD Tinderbox]

TB --- 2013-07-11 14:27:18 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-07-11 14:27:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-07-11 14:27:18 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2013-07-11 14:27:18 - cleaning the object tree
TB --- 2013-07-11 14:28:24 - /usr/local/bin/svn stat /src
TB --- 2013-07-11 14:28:39 - At svn revision 253186
TB --- 2013-07-11 14:28:40 - building world
TB --- 2013-07-11 14:28:40 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 14:28:40 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 14:28:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 14:28:40 - SRCCONF=/dev/null
TB --- 2013-07-11 14:28:40 - TARGET=sparc64
TB --- 2013-07-11 14:28:40 - TARGET_ARCH=sparc64
TB --- 2013-07-11 14:28:40 - TZ=UTC
TB --- 2013-07-11 14:28:40 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 14:28:40 - cd /src
TB --- 2013-07-11 14:28:40 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Jul 11 14:28:47 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Jul 11 15:39:09 UTC 2013
TB --- 2013-07-11 15:39:09 - generating LINT kernel config
TB --- 2013-07-11 15:39:09 - cd /src/sys/sparc64/conf
TB --- 2013-07-11 15:39:09 - /usr/bin/make -B LINT
TB --- 2013-07-11 15:39:09 - cd /src/sys/sparc64/conf
TB --- 2013-07-11 15:39:09 - /usr/sbin/config -m LINT
TB --- 2013-07-11 15:39:09 - building LINT kernel
TB --- 2013-07-11 15:39:09 - CROSS_BUILD_TESTING=YES
TB --- 2013-07-11 15:39:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-07-11 15:39:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-07-11 15:39:09 - SRCCONF=/dev/null
TB --- 2013-07-11 15:39:09 - TARGET=sparc64
TB --- 2013-07-11 15:39:09 - TARGET_ARCH=sparc64
TB --- 2013-07-11 15:39:09 - TZ=UTC
TB --- 2013-07-11 15:39:09 - __MAKE_CONF=/dev/null
TB --- 2013-07-11 15:39:09 - cd /src
TB --- 2013-07-11 15:39:09 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Jul 11 15:39:09 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float 
-ffreestanding -fstack-protector -Werror  /src/sys/net80211/ieee80211_mesh.c
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float 
-ffreestanding -fstack-protector -Werror  /src/sys/net80211/ieee80211_monitor.c
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float 
-ffreestanding -fstack-protector -Werror  /src/sys/net80211/ieee80211_node.c
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
-Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 
--param large-f

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[Bruce Evans]

On Thu, 11 Jul 2013, David Chisnall wrote:


On 11 Jul 2013, at 13:11, Bruce Evans  wrote:


 is also not required to be conforming C code, let alone C++ code,
so there is only a practical requirement that it works when included
in the C++ implementation.


Working with the C++ implementation is the problem that we are trying to solve.


The compatibility that I'm talking about is with old versions of FreeBSD.
isnan() is still in libc as a function since that was part of the FreeBSD
ABI and too many things depended on getting it from there.  It was recently
...


I don't see a problem with changing the name of the function in the header and 
leaving the old symbol in libm for legacy code.


I don't even see why old code needs the symbol.  Old code should link to
old compat libraries that still have it.




It would also be nice to implement these macros using _Generic when compiling 
in C11 mode, as it will allow the compiler to produce more helpful warning 
messages.  I would propose this implementation:



#if __has_builtin(__builtin_isnan)


This won't work for me, since I develop and test msun with old compilers
that don't support __has_builtin().  Much the same set of compilers also
don't have enough FP builtins.


Please look in cdefs.h, which defines __has_builtin(x) to 0 if we the compiler 
does not support it.  It is therefore safe to use __has_builtin() in any 
FreeBSD header.


The old compilers run on old systems that don't have that in cdefs.h
(though I sometimes edit it to add compatibility cruft like that).  msun
sources are otherwise portable to these systems.  Well, not quite.  They
are not fully modular and also depend on stuff in libc/include and
libc/${ARCH}.  I have to update or edit headers there.

This hack also doesn't work with gcc in -current.  gcc has __builtin_isnan
but not __has_builtin(), so __has_builtin(__builtin_isnan) gives the wrong
result 0.


It also doesn't even work.  clang has squillions of builtins that
aren't really builtines so they reduce to libcalls.


Which, again, is not a problem for code outside of libm.  If libm needs 
different definitions of these macros then that's fine, but they should be 
private to libm, not installed as public headers.


Yes it is.  It means that nothing should use isnan() or FP_FAST_FMA* outside
of libm either, since isnan() is too slow and FP_FAST_FMA* can't be trusted.
Even the implementation can't reliably tell if __builtin_isnan is usuable
or better than alternatives.


The msun implementation knows that isnan() and other classification
macros are too slow to actually use, and rarely uses them.


Which makes any concerns that only apply to msun internals irrelevant from the 
perspective of discussing what goes into this header.


No, the efficiency of isnan() is more important for externals, because the
internals already have work-arounds.


#define isnan(x) __builtin_isnan(x)
#else
static __inline int
__isnanf(float __x)
{
  return (__x != __x);
}


Here we can do better in most cases by hard-coding this without the ifdef.


They will generate the same code.  Clang expands the builtin in the LLVM IR to 
a fcmp uno, so will generate the correct code even when doing fast math 
optimisations.


On some arches the same, and not affected by -ffast-math.  But this
is not necessarily the fastest code, so it is a performance bug if clang
akways generates the same code for the builtin.  Bit tests are faster in
some cases, and may be required to prevent exceptions for signaling NaNs.
-ffast-math could reasonably optimize x != x to "false".  It already assumes
that things like overflow and NaN results can't happen, so why not optimize
further by assuming that NaN inputs can't happen?


Generic stuff doesn't seem to work right for either isnan() or
__builtin_isnan(), though it could for at least the latter.  According
to a quick grep of strings $(which clang), __builtin_classify() is
generic but __builtin_isnan*() isn't (the former has no type suffixes
but the latter does, and testing shows that the latter doesn't work
without the suffices).


I'm not sure what you were testing:


Mostly isnan() without including , and gcc.  I was confused by
gcc converting floats to doubles.


$ cat isnan2.c

int test(float f, double d, long double l)
{
   return __builtin_isnan(f) |
   __builtin_isnan(d) |
   __builtin_isnan(l);
}
$ clang isnan2.c -S -emit-llvm -o - -O1
...
 %cmp = fcmp uno float %f, 0.00e+00
 %cmp1 = fcmp uno double %d, 0.00e+00
 %or4 = or i1 %cmp, %cmp1
 %cmp2 = fcmp uno x86_fp80 %l, 0xK
...

As you can see, it parses them as generics and generates different IR for each. 
 I don't believe that there's a way that these would be translated back into 
libcalls in the back end.


Yes, most cases work right.  gcc converts f to double and compares the
result, but that mostly works.  It would be just a pessimization except
te conversion gives an exception for signaling NaNs.  I hope

Re: hacking - aio_sendfile()

[Adrian Chadd]

On 11 July 2013 07:51, Gleb Smirnoff  wrote:
> On Thu, Jul 11, 2013 at 07:45:19AM -0700, Adrian Chadd wrote:
> A> I reference the source/dest FDs in the queue method. Is that not good 
> enough?
>
> I see. Should probably work, but needs testing.

It's terrible - I'd think I should pass the file ref's into
kern_sendfile() so I'm sure that the process hasn't close/dup'ed an FD
in its place in the meantime.

Is that better?



-adrian
___
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: hacking - aio_sendfile()

[Gleb Smirnoff]

On Thu, Jul 11, 2013 at 07:45:19AM -0700, Adrian Chadd wrote:
A> I reference the source/dest FDs in the queue method. Is that not good enough?

I see. Should probably work, but needs testing.

-- 
Totus tuus, Glebius.
___
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: hacking - aio_sendfile()

[Adrian Chadd]

I reference the source/dest FDs in the queue method. Is that not good enough?


-adrian
___
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: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[David Chisnall]

On 11 Jul 2013, at 13:11, Bruce Evans  wrote:

> The error message for the __builtin_isnan() version is slightly better up
> to where it says more.
> 
> The less-unportable macro can do more classification and detect problems
> at compile time using __typeof().

The attached patch fixes the related test cases in the libc++ test suite.  
Please review.

This does not use __builtin_isnan(), but it does:

- Stop exposing isnan and isinf in the header.  We already have __isinf in 
libc, so this is used instead.

- Call the static functions for isnan __inline__isnan*() so that they don't 
conflict with the ones in libm.

- Add an __fp_type_select() macro that uses either __Generic(), 
__builtin_choose_expr() / __builtin_choose_expr(), or sizeof() comparisons, 
depending on what the compiler supports.

- Refactor all of the type-generic macros to use __fp_type_select().  

David




isnan.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[Bruce Evans]

On Thu, 11 Jul 2013, Tijl Coosemans wrote:


On 2013-07-11 06:21, Bruce Evans wrote:

On Wed, 10 Jul 2013, Garrett Wollman wrote:

< said:

I think isnan(double) and isinf(double) in math.h should only be
visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999.
For C99 and higher there should only be the isnan/isinf macros.


I believe you are correct.  POSIX.1-2008 (which is aligned with C99)
consistently calls isnan() a "macro", and gives a pseudo-prototype of

int isnan(real-floating x);


Almost any macro may be implemented as a function, if no conforming
program can tell the difference.  It is impossible for technical reasons
to implement isnan() as a macro (except on weird implementations where
all real-floating types are physically the same).  In the FreeBSD
implementation, isnan() is a macro, but it is also a function, and
the macro expands to the function in double precision:

% #defineisnan(x)\
% ((sizeof (x) == sizeof (float)) ? __isnanf(x)\
% : (sizeof (x) == sizeof (double)) ? isnan(x)\
% : __isnanl(x))


The C99 standard says isnan is a macro. I would say that only means
defined(isnan) is true. Whether that macro then expands to function
calls or not is not important.


I think it means only that defined(isnan) is true.  isnan() can still be
a function (declared or just in the compile-time namespace somewhere,
or in a library object).  It is reserved in the compile-time namespace,
and the standard doesn't cover library objects, so conforming applications
can't reference either except via the isnan() macro (if that has its
strange historical implementation).


I don't see how any conforming program can access the isnan() function
directly.  It is just as protected as __isnan() would be.  (isnan)()
gives the function (the function prototype uses this), but conforming
programs can't do that since the function might not exist.


I don't think the standard allows a function to be declared with the same
name as a standard macro (it does allow the reverse: define a macro with
the same name as a standard function). I believe the following code is
C99 conforming but it currently does not compile with our math.h:

--
#include 

int (isnan)(int a, int b, int c) {
   return (a + b + c);
}
--


I think isnan is just reserved, so you can't redefine it an any way.  I
think the reverse is even less allowed.  Almost any standard function may
be implemented as a macro, and then any macro definition of it would
conflict with the previous macro even more than with a previous prototype.
E.g.:

/* Header. */
void exit(int);
#define exit(x) __exit(x)

/* Application. */
#undef exit /* non-conforming */
#define exit(x) my_exit(x)  /* conflicts without the #undef */

Now suppose the header doesn't define exit().

#define exit(x) my_exit(x)

This hides the protoype but doesn't automatically cause problems, especially
if exit() is not used after this point.  But this is still non-conforming,
since exit() is reserved.

Here are some relevant parts of C99 (n869.txt):

%%%
 -- Each  identifier  with  file scope listed in any of the
following  subclauses  (including  the  future  library
directions)  is  reserved  for  use  as macro and as an
identifier with file scope in the same  name  space  if
any of its associated headers is included.

   [#2]  No  other  identifiers  are  reserved.  If the program
   declares or defines an identifier in a context in  which  it
   is  reserved  (other than as allowed by 7.1.4), or defines a
   reserved  identifier  as  a  macro  name,  the  behavior  is
   undefined.

   [#3]   If  the  program  removes  (with  #undef)  any  macro
   definition of an identifier in the first group listed above,
   the behavior is undefined.
%%%

Without any include of a header that is specified to declare exit(),
file scope things are permitted for it, including defining it and
making it a static function, but not making it an extern function.

isnan is reserved for use as a macro and as an identifier with file
scope by the first clause above.  Thus (isnan) cannot even be defined
as a static function.  But (isnan) is not reserved in inner scopes.
I thought that declarations like "int (isnan);" are impossible since
they look like syntax errors, but this syntax seems to be allowed an
actually work with gcc-3.3.3 and TenDRA-5.0.0.  So you can have
variables with silly names like (isnan) and (getchar) :-).  However,
(NULL) for a variable name doesn't work, and (isnan) is a syntax error
for struct member names.  The compilers may be correct in allowing
(isnan) but not (NULL) for variables.  isnan happens to be function-like,
so the parentheses are special for (isnan), but the parentheses are not
special for (NULL).  cpp confirms this -- NULL inside of parentheses
still gets expa

Re: Filesystem wedges caused by r251446

[John Baldwin]

On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote:
> John Baldwin wrote:
> > On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote:
> > > Konstantin Belousov wrote:
> > > > 
> > > > Care to provide any useful information ?
> > > > 
> > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-
> > handbook/kerneldebug-deadlocks.html
> > > 
> > > Well, the system doesn't deadlock it's perfectly useable so long
> > > as you don't touch the file that's wedged.  A lot of the time the
> > > userland process is unkillable, but often it is killable.  How do
> > > I get from from the PID to where the FS is stuck in the kernel?
> > 
> > Use kgdb.  'proc ', then 'bt'.
> 
> So, I setup a remote kbgd session, but I still can't figure out how
> to get at the information we need.
> 
> (kgdb) proc 5176
> only supported for core file target
> 
> In the mean time, I'll just force it to make a core dump from ddb.
> However, I can't reacreate the issue while the mirror (gmirror) is
> rebuilding, so we'll have to wait for that to finish.

Sorrry, just run 'sudo kgdb' on the box itself.  You can inspect the running
kernel without having to stop it.

-- 
John Baldwin
___
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: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[David Chisnall]

On 11 Jul 2013, at 13:11, Bruce Evans  wrote:

>  is also not required to be conforming C code, let alone C++ code,
> so there is only a practical requirement that it works when included
> in the C++ implementation.

Working with the C++ implementation is the problem that we are trying to solve.

> The compatibility that I'm talking about is with old versions of FreeBSD.
> isnan() is still in libc as a function since that was part of the FreeBSD
> ABI and too many things depended on getting it from there.  It was recently
> removed from libc.so, but is still in libm.a.  This causes some
> implementation problems in libm that are still not completely solved.  I
> keep having to edit msun/src/s_isnan.c the msun sources are more portable.
> Mostly I need to kill the isnan() there so that it doesn't get in the
> way of the one in libc.  This mostly works even if there is none in libc,
> since the builtins result in neither being used.  isnanf() is more of a
> problem, since it is mapped to __isnanf() and there is no builtin for
> __isnanf().  The old functions have actually been removed from libc.a
> too.  They only in libc_pic.a.  libc.a still has isnan.o, but that is bogus
> since isnan.o is now empty.

I don't see a problem with changing the name of the function in the header and 
leaving the old symbol in libm for legacy code.  

>> It would also be nice to implement these macros using _Generic when 
>> compiling in C11 mode, as it will allow the compiler to produce more helpful 
>> warning messages.  I would propose this implementation:
> 
>> #if __has_builtin(__builtin_isnan)
> 
> This won't work for me, since I develop and test msun with old compilers
> that don't support __has_builtin().  Much the same set of compilers also
> don't have enough FP builtins.

Please look in cdefs.h, which defines __has_builtin(x) to 0 if we the compiler 
does not support it.  It is therefore safe to use __has_builtin() in any 
FreeBSD header.

> It also doesn't even work.  clang has squillions of builtins that
> aren't really builtines so they reduce to libcalls.

Which, again, is not a problem for code outside of libm.  If libm needs 
different definitions of these macros then that's fine, but they should be 
private to libm, not installed as public headers.

> The msun implementation knows that isnan() and other classification
> macros are too slow to actually use, and rarely uses them.  

Which makes any concerns that only apply to msun internals irrelevant from the 
perspective of discussing what goes into this header.

>> #define isnan(x) __builtin_isnan(x)
>> #else
>> static __inline int
>> __isnanf(float __x)
>> {
>>   return (__x != __x);
>> }
> 
> Here we can do better in most cases by hard-coding this without the ifdef.

They will generate the same code.  Clang expands the builtin in the LLVM IR to 
a fcmp uno, so will generate the correct code even when doing fast math 
optimisations.

>> static __inline int
>> __isnand(double __x)
>> {
>>   return (__x != __x);
>> }
> 
> __isnand() is a strange name, and doesn't match compiler conventions for
> builtins.  Compilers use __builtin_isnan() and map this to the libcall
> __isnan().

That's fine.

>> static __inline int
>> __isnanl(long double __x)
>> {
>>   return (__x != __x);
>> }
>> #if __STDC_VERSION__ >= 201112L
>> #define isnan(x) _Generic((x), \
>>   float: __isnanf(x),\
>>   double: __isnand(x),   \
>>   long double: __isnanl(x))
> 
> Does _Generic() have no side effects, like sizeof()?

Yes.

>> #else
>> #define isnan(x)\
>>   ((sizeof (x) == sizeof (float)) ? __isnanf(x)   \
>>: (sizeof (x) == sizeof (double)) ? __isnand(x)\
>>: __isnanl(x))
>> #endif
>> #endif
> 
> Both cases need to use __builtin_isnan[fl]() and depend on compiler
> magic to have any chance of avoiding side effects from loads and
> parameter passing.



> Generic stuff doesn't seem to work right for either isnan() or
> __builtin_isnan(), though it could for at least the latter.  According
> to a quick grep of strings $(which clang), __builtin_classify() is
> generic but __builtin_isnan*() isn't (the former has no type suffixes
> but the latter does, and testing shows that the latter doesn't work
> without the suffices).  

I'm not sure what you were testing:

$ cat isnan2.c 

int test(float f, double d, long double l)
{
return __builtin_isnan(f) |
__builtin_isnan(d) |
__builtin_isnan(l);
}
$ clang isnan2.c -S -emit-llvm -o - -O1
...
  %cmp = fcmp uno float %f, 0.00e+00
  %cmp1 = fcmp uno double %d, 0.00e+00
  %or4 = or i1 %cmp, %cmp1
  %cmp2 = fcmp uno x86_fp80 %l, 0xK
...

As you can see, it parses them as generics and generates different IR for each. 
 I don't believe that there's a way that these would be translated back into 
libcalls in the back end.

>> For a trivial example of why this 

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[Bruce Evans]

On Thu, 11 Jul 2013, David Chisnall wrote:


You're joining in this discussion starting in the middle, so you probably 
missed the earlier explanation.


I was mainly addressing a C99 point.  I know little about C++ or C11.


On 11 Jul 2013, at 05:21, Bruce Evans  wrote:


I don't see how any conforming program can access the isnan() function
directly.  It is just as protected as __isnan() would be.  (isnan)()
gives the function (the function prototype uses this), but conforming
programs can't do that since the function might not exist.  Maybe some
non-conforming program like autoconfig reads  or libm.a and
creates a bug for C++.


The cmath header defines a template function isnan that invokes the isnan 
macro, but then undefines the isnan macro.  This causes a problem because when 
someone does something along the lines of using namespace std then they end up 
with two functions called isnan and the compiler gets to pick the one to use.  
Unfortunately, std::isnan() returns a bool, whereas isnan() returns an int.

The C++ headers are not required to be conforming C code, because they are not C, and 
our math.h causes namespace pollution in C++ when included from .


 is also not required to be conforming C code, let alone C++ code,
so there is only a practical requirement that it works when included
in the C++ implementation.


The FreeBSD isnan() implementation would be broken by removing the
isnan() function from libm.a or ifdefing it in .  Changing the
function to __isnan() would cause compatibility problems.  The function
is intentionally named isnan() to reduce compatibility problems.


On OS X this is avoided because their isnan() macro expands to call one of the 
__-prefixed inline functions (which adopt your suggestion of being implemented 
as x != x, for all types).  I am not sure that this is required for standards 
conformance, but it is certainly cleaner.  Your statement that having the 
function not called isnan() causes compatibility problems is demonstrably 
false, as neither OS X nor glibc has a function called isnan() and, unlike us, 
they do not experience problems with this macro.


The compatibility that I'm talking about is with old versions of FreeBSD.
isnan() is still in libc as a function since that was part of the FreeBSD
ABI and too many things depended on getting it from there.  It was recently
removed from libc.so, but is still in libm.a.  This causes some
implementation problems in libm that are still not completely solved.  I
keep having to edit msun/src/s_isnan.c the msun sources are more portable.
Mostly I need to kill the isnan() there so that it doesn't get in the
way of the one in libc.  This mostly works even if there is none in libc,
since the builtins result in neither being used.  isnanf() is more of a
problem, since it is mapped to __isnanf() and there is no builtin for
__isnanf().  The old functions have actually been removed from libc.a
too.  They only in libc_pic.a.  libc.a still has isnan.o, but that is bogus
since isnan.o is now empty.


It would also be nice to implement these macros using _Generic when compiling 
in C11 mode, as it will allow the compiler to produce more helpful warning 
messages.  I would propose this implementation:



#if __has_builtin(__builtin_isnan)


This won't work for me, since I develop and test msun with old compilers
that don't support __has_builtin().  Much the same set of compilers also
don't have enough FP builtins.

It also doesn't even work.  clang has squillions of builtins that
aren't really builtines so they reduce to libcalls.  gcc has fewer
builtins, but still many that reduce to libcalls.  An example is fma().
__has_builtin(__builtin_fma) is true for clang on amd64 (freefall),
but at least freefalls's CPU doesn't support fma in hardware, so the
builtin can't really work, and in fact it doesn't -- it reduces to a
libcall.  This might change if the hardware supports fma, but then
__has_builtin(__builtin_fma) would be even more useless for telling
if fma is worth using.  C99 has macros FP_FAST_FMA[FL] whose
implementation makes them almost equally useless.  For example, ia64
has fma in hardware and the implementation defines all of
FP_FAST_FMA[FL] for ia64.  But fma is implemented as an extern function,
partly because there is no way to tell if __builtin_fma is any good
(but IIRC, __builtin_fma is no good on ia64 either, since it reduces
to the same extern function).  The extern function is slow (something
like 20 cycles instead of 1 for the fma operation).  But if you ignore
the existence of the C99 fma API and just write expressions of the
form (a*x + b), then gcc on ia64 will automatically use the hardware
fma, although this is technically wrong in some fenv environments.

For gcc-4.2.1, __has_builtin(__builtin_fma) is a syntax error.  I
test with gcc-3.x.  It is also missing __builtin_isnan().

The msun implementation knows that isnan() and other classification
macros are too slow to actually use, and rarely uses the

Re: [head tinderbox] failure on sparc64/sparc64

[Jackson Donadel]

I think it´s in your kernel config file LINT.

In your log we can read this  Kernel build for LINT started on Thu Jul
11 04:07:01 UTC 2013

I had the same issue with current yesterday.



2013/7/11 Navdeep Parhar 

> On Thu, Jul 11, 2013 at 12:07:33AM -0700, Adrian Chadd wrote:
> > On 11 July 2013 00:05, Navdeep Parhar  wrote:
> > > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote:
> > >> I don't get why this is dying. any ideas?
> > >
> > > Maybe because sparc64's ucontext.h is getting pulled in, and it has
> > > this:
> > >
> > > #define mc_flagsmc_global[0]
> >
> > Ugh, we should fix this. When did this happen?
>
> You tell me.  I was just running cscope in my spare time ;-)
> ___
> freebsd-spar...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to "freebsd-sparc64-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"

Re: Filesystem wedges caused by r251446

[Ian FREISLICH]

John Baldwin wrote:
> On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote:
> > Konstantin Belousov wrote:
> > > 
> > > Care to provide any useful information ?
> > > 
> > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-
> handbook/kerneldebug-deadlocks.html
> > 
> > Well, the system doesn't deadlock it's perfectly useable so long
> > as you don't touch the file that's wedged.  A lot of the time the
> > userland process is unkillable, but often it is killable.  How do
> > I get from from the PID to where the FS is stuck in the kernel?
> 
> Use kgdb.  'proc ', then 'bt'.

So, I setup a remote kbgd session, but I still can't figure out how
to get at the information we need.

(kgdb) proc 5176
only supported for core file target

In the mean time, I'll just force it to make a core dump from ddb.
However, I can't reacreate the issue while the mirror (gmirror) is
rebuilding, so we'll have to wait for that to finish.

Ian

-- 
Ian Freislich
___
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: hacking - aio_sendfile()

[Gleb Smirnoff]

  Adrian,

On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote:
A> I've started writing an aio_sendfile() syscall.
A> 
A> http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff
A> 
A> Yes, the diff is against -HEAD and not stable/9.
A> 
A> It's totally horrible, hackish and likely bad. I've only done some
A> very, very basic testing to ensure it actually works; i haven't at all
A> stress tested it out yet. It's also very naive - I'm not at all doing
A> any checks to see whether I can short-cut to do the aio there and
A> then; I'm always queuing the sendfile() op through the worker threads.
A> That's likely stupid and inefficient in a lot of cases, but it at
A> least gets the syscall up and working.
A> 
A> I'd like some feedback and possibly some help in stress testing it to
A> make sure it's functioning well.

Apart from problem pointed out by Kostik, there is a race between
aio thread starting with aio_process_sendfile() and file descriptor
(or socket descriptor) going away.

Thus, kern_sendfile() needs to be split into two parts: kern_sendfile_pre()
and kern_sendfile() that should contain only the sending cycle.

The kern_sendfile_pre() should contain:

fgetvp_read(uap->fd, &vp)
vm_object_reference_locked(vp->v_object)

Referencing the socket is probably also required. Current synchronous
code doesn't do it.

The do_sendfile() function should call kern_sendfile_pre() and then
kern_sendfile(). The aio code should perform kern_sendfile_pre() in the
new syscall itself in context of calling process, and kern_sendfile()
in async context.

P.S. Some time ago I have started hacking on the above.

-- 
Totus tuus, Glebius.
___
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: hacking - aio_sendfile()

[Konstantin Belousov]

On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote:
> On 11 July 2013 02:36, Konstantin Belousov  wrote:
> 
> > No, it is not disk I/O which is problematic there. It is socket I/O
> > e.g. wait for the socket buffers lomark in the kern_sendfile() which
> > causes unbounded sleep. Look for the sbwait() call, both in the
> > kern_sendfile() itself, and in the pru_send methods of the protocols,
> > e.g. in sosend_generic(). The wait scope controlled by the other side of
> > connection and allow it to completely block the aio subsystem.
> >
> > Disk I/O is supposed to finish in the finite time.
> 
> Even if the destination socket is marked as NONBLOCK?

You mean, would a sleep for the socket buffer space cause aio thread
block is the socket is put in nonblocking mode ?  Or something else ?

No, it would not block the thread. But I cannot consider the
aio_sendfile(2) implementation useful if it requires non-blocking
socket. Also, what about other thread changing the socket to blocking
mode while sendfile is in flight ?


pgpJdSazseJ69.pgp
Description: PGP signature

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[Tijl Coosemans]

On 2013-07-11 06:21, Bruce Evans wrote:
> On Wed, 10 Jul 2013, Garrett Wollman wrote:
>> < said:
>>> I think isnan(double) and isinf(double) in math.h should only be
>>> visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999.
>>> For C99 and higher there should only be the isnan/isinf macros.
>>
>> I believe you are correct.  POSIX.1-2008 (which is aligned with C99)
>> consistently calls isnan() a "macro", and gives a pseudo-prototype of
>>
>> int isnan(real-floating x);
> 
> Almost any macro may be implemented as a function, if no conforming
> program can tell the difference.  It is impossible for technical reasons
> to implement isnan() as a macro (except on weird implementations where
> all real-floating types are physically the same).  In the FreeBSD
> implementation, isnan() is a macro, but it is also a function, and
> the macro expands to the function in double precision:
> 
> % #defineisnan(x)\
> % ((sizeof (x) == sizeof (float)) ? __isnanf(x)\
> % : (sizeof (x) == sizeof (double)) ? isnan(x)\
> % : __isnanl(x))

The C99 standard says isnan is a macro. I would say that only means
defined(isnan) is true. Whether that macro then expands to function
calls or not is not important.

> I don't see how any conforming program can access the isnan() function
> directly.  It is just as protected as __isnan() would be.  (isnan)()
> gives the function (the function prototype uses this), but conforming
> programs can't do that since the function might not exist.

I don't think the standard allows a function to be declared with the same
name as a standard macro (it does allow the reverse: define a macro with
the same name as a standard function). I believe the following code is
C99 conforming but it currently does not compile with our math.h:

--
#include 

int (isnan)(int a, int b, int c) {
return (a + b + c);
}
--




signature.asc
Description: OpenPGP digital signature

Re: hacking - aio_sendfile()

[Adrian Chadd]

On 11 July 2013 02:36, Konstantin Belousov  wrote:

> No, it is not disk I/O which is problematic there. It is socket I/O
> e.g. wait for the socket buffers lomark in the kern_sendfile() which
> causes unbounded sleep. Look for the sbwait() call, both in the
> kern_sendfile() itself, and in the pru_send methods of the protocols,
> e.g. in sosend_generic(). The wait scope controlled by the other side of
> connection and allow it to completely block the aio subsystem.
>
> Disk I/O is supposed to finish in the finite time.

Even if the destination socket is marked as NONBLOCK?


-adrian
___
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: hacking - aio_sendfile()

[Konstantin Belousov]

On Thu, Jul 11, 2013 at 01:37:19AM -0700, Adrian Chadd wrote:
> Hiya,
> 
> I'm more interested in the API than the implementation at the moment.
> 
> Yes, you're right - it should eventually be driven using disk io
> completion upcalls which triggers the push of data into the socket
> buffer. I totally agree.
> 
> I'm hacking up some libevent-ish looking thing that uses kqueue and
> wraps aio, read, write, and other event types into something I can
> easily shoehorn this stuff into. I'll then throughly test it (and
> other options) out. You're right, it's likely going to end up with a
> whole lot of aio threads sitting there waiting for disk IO to complete
> - and at that point, I'll start hacking at sendfile() to split it into
> two halves and have it driven by a completion call from g_up or
> wherever, triggering the socket write side of things.
> 
> There are some other questions too - like whether the IO completion
> should just queue socket IO (and have it potentially block in the TCP
> code) or whether it should funnel completions into a per-CPU aio
> completion thread which does the socket write bit. That way disk IO
> completion isn't going to be blocked by longer-held locks in the
> networking stack.

No, it is not disk I/O which is problematic there. It is socket I/O
e.g. wait for the socket buffers lomark in the kern_sendfile() which
causes unbounded sleep. Look for the sbwait() call, both in the
kern_sendfile() itself, and in the pru_send methods of the protocols,
e.g. in sosend_generic(). The wait scope controlled by the other side of
connection and allow it to completely block the aio subsystem.

Disk I/O is supposed to finish in the finite time.


pgpVyo_YYHh1i.pgp
Description: PGP signature

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

[David Chisnall]

Hi Bruce,

You're joining in this discussion starting in the middle, so you probably 
missed the earlier explanation.

On 11 Jul 2013, at 05:21, Bruce Evans  wrote:

> I don't see how any conforming program can access the isnan() function
> directly.  It is just as protected as __isnan() would be.  (isnan)()
> gives the function (the function prototype uses this), but conforming
> programs can't do that since the function might not exist.  Maybe some
> non-conforming program like autoconfig reads  or libm.a and
> creates a bug for C++.

The cmath header defines a template function isnan that invokes the isnan 
macro, but then undefines the isnan macro.  This causes a problem because when 
someone does something along the lines of using namespace std then they end up 
with two functions called isnan and the compiler gets to pick the one to use.  
Unfortunately, std::isnan() returns a bool, whereas isnan() returns an int.  

The C++ headers are not required to be conforming C code, because they are not 
C, and our math.h causes namespace pollution in C++ when included from .

> The FreeBSD isnan() implementation would be broken by removing the
> isnan() function from libm.a or ifdefing it in .  Changing the
> function to __isnan() would cause compatibility problems.  The function
> is intentionally named isnan() to reduce compatibility problems.


On OS X this is avoided because their isnan() macro expands to call one of the 
__-prefixed inline functions (which adopt your suggestion of being implemented 
as x != x, for all types).  I am not sure that this is required for standards 
conformance, but it is certainly cleaner.  Your statement that having the 
function not called isnan() causes compatibility problems is demonstrably 
false, as neither OS X nor glibc has a function called isnan() and, unlike us, 
they do not experience problems with this macro.  

It would also be nice to implement these macros using _Generic when compiling 
in C11 mode, as it will allow the compiler to produce more helpful warning 
messages.  I would propose this implementation:


#if __has_builtin(__builtin_isnan)
#define isnan(x) __builtin_isnan(x)
#else
static __inline int
__isnanf(float __x)
{
return (__x != __x);
}
static __inline int
__isnand(double __x)
{
return (__x != __x);
}
static __inline int
__isnanl(long double __x)
{
return (__x != __x);
}
#if __STDC_VERSION__ >= 201112L
#define isnan(x) _Generic((x), \
float: __isnanf(x),\
double: __isnand(x),   \
long double: __isnanl(x))
#else
#define isnan(x)\
((sizeof (x) == sizeof (float)) ? __isnanf(x)   \
 : (sizeof (x) == sizeof (double)) ? __isnand(x)\
 : __isnanl(x))
#endif
#endif

For a trivial example of why this is an improvement in terms of error 
reporting, consider this trivial piece of code:

int is(int x)
{
return isnan(x);
}

With our current implementation, this compiles and links without any warnings, 
although it will have somewhat interesting results at run time.  With the 
__builtin_isnan() version, clang reports this error:

isnan.c:35:15: error: floating point classification requires argument of
  floating point type (passed in 'int')
return isnan(x);
 ^
(and then some more about the macro expansion)

With the C11 version, it reports this error:

isnan.c:35:15: error: controlling expression type 'int' not compatible with any
  generic association type
return isnan(x);
 ^



David



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: hacking - aio_sendfile()

[Adrian Chadd]

Hiya,

I'm more interested in the API than the implementation at the moment.

Yes, you're right - it should eventually be driven using disk io
completion upcalls which triggers the push of data into the socket
buffer. I totally agree.

I'm hacking up some libevent-ish looking thing that uses kqueue and
wraps aio, read, write, and other event types into something I can
easily shoehorn this stuff into. I'll then throughly test it (and
other options) out. You're right, it's likely going to end up with a
whole lot of aio threads sitting there waiting for disk IO to complete
- and at that point, I'll start hacking at sendfile() to split it into
two halves and have it driven by a completion call from g_up or
wherever, triggering the socket write side of things.

There are some other questions too - like whether the IO completion
should just queue socket IO (and have it potentially block in the TCP
code) or whether it should funnel completions into a per-CPU aio
completion thread which does the socket write bit. That way disk IO
completion isn't going to be blocked by longer-held locks in the
networking stack.

Thanks,


-adrian
___
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: Improved SYN Cookies: Looking for testers

[Andre Oppermann]

On 10.07.2013 15:18, Fabian Keil wrote:

Andre Oppermann  wrote:


We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few available bits.

This patch updates and improves SYN cookies mainly by:

   a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN
  (initial sequence number) without the use of timestamp bits.

   b) switching to the very fast and cryptographically strong SipHash-2-4
  hash MAC algorithm to protect the SYN cookie against forgery.

The patch had been reviewed by dwmalone (cookies) and cperciva (siphash).

Please find it here for testing:

   http://people.freebsd.org/~andre/syncookie-20130708.diff


I've been using the patch for a couple of days and didn't notice any
issues so far. Privoxy's regression tests continue to work as expected
as well.


Thanks for testing and reporting back.

Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1
as well to bypass the syn cache entirely?

It will give a bit of debug log output which is it telling you mostly about
rounding to the next nearest index value.  You can send the output privately
to me to spot unexpected outliers, if any.


BTW, I think kern/173309 could be closed.


OK.

--
Andre

___
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: ipv6_addrs_IF aliases in rc.conf(5)

[Łukasz Wąsikowski]

W dniu 2013-07-10 17:52, Kevin Oberman pisze:

> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder  wrote:
> 
>> On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm <
>> trash...@odo.in-berlin.de> wrote:
>>
>>  Will that patch make it into 9.2? If I am not mistaken, that patch isn't
>>> in stable yet.
>>>
>>
>> I would also like to see this patch hit 9.x sooner than later. It's so
>> painful when someone forgets to fix the alias numbering on servers with
>> many, many IPv4 and IPv6 addresses...
>>
> 
> Please, please, please, please, ...!
> 
> Freeze is only two days away, so time for 9.2 is almost over and I can see
> no good reason NOT to get this done.

+1 to that, please commit it.

-- 
best regards,
Lukasz Wasikowski
___
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: [head tinderbox] failure on sparc64/sparc64

[Navdeep Parhar]

On Thu, Jul 11, 2013 at 12:07:33AM -0700, Adrian Chadd wrote:
> On 11 July 2013 00:05, Navdeep Parhar  wrote:
> > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote:
> >> I don't get why this is dying. any ideas?
> >
> > Maybe because sparc64's ucontext.h is getting pulled in, and it has
> > this:
> >
> > #define mc_flagsmc_global[0]
> 
> Ugh, we should fix this. When did this happen?

You tell me.  I was just running cscope in my spare time ;-)
___
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: [head tinderbox] failure on sparc64/sparc64

[Adrian Chadd]

On 11 July 2013 00:05, Navdeep Parhar  wrote:
> On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote:
>> I don't get why this is dying. any ideas?
>
> Maybe because sparc64's ucontext.h is getting pulled in, and it has
> this:
>
> #define mc_flagsmc_global[0]

Ugh, we should fix this. When did this happen?



-adrian
___
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: [head tinderbox] failure on sparc64/sparc64

[Navdeep Parhar]

On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote:
> I don't get why this is dying. any ideas?

Maybe because sparc64's ucontext.h is getting pulled in, and it has
this:

#define mc_flagsmc_global[0]

Regards,
Navdeep

> 
> 
> 
> adrian
> 
> On 10 July 2013 21:18, FreeBSD Tinderbox  wrote:
> > TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on 
> > freebsd-current.sentex.ca
> > TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca 
> > 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
> > d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
> > TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/sparc64
> > TB --- 2013-07-11 02:56:02 - cleaning the object tree
> > TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src
> > TB --- 2013-07-11 02:57:06 - At svn revision 253161
> > TB --- 2013-07-11 02:57:07 - building world
> > TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=YES
> > TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=/obj
> > TB --- 2013-07-11 02:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
> > TB --- 2013-07-11 02:57:07 - SRCCONF=/dev/null
> > TB --- 2013-07-11 02:57:07 - TARGET=sparc64
> > TB --- 2013-07-11 02:57:07 - TARGET_ARCH=sparc64
> > TB --- 2013-07-11 02:57:07 - TZ=UTC
> > TB --- 2013-07-11 02:57:07 - __MAKE_CONF=/dev/null
> > TB --- 2013-07-11 02:57:07 - cd /src
> > TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld
>  Building an up-to-date make(1)
>  World build started on Thu Jul 11 02:57:14 UTC 2013
>  Rebuilding the temporary build tree
>  stage 1.1: legacy release compatibility shims
>  stage 1.2: bootstrap tools
>  stage 2.1: cleaning up the object tree
>  stage 2.2: rebuilding the object tree
>  stage 2.3: build tools
>  stage 3: cross tools
>  stage 4.1: building includes
>  stage 4.2: building libraries
>  stage 4.3: make dependencies
>  stage 4.4: building everything
>  World build completed on Thu Jul 11 04:07:01 UTC 2013
> > TB --- 2013-07-11 04:07:01 - generating LINT kernel config
> > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf
> > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT
> > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf
> > TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT
> > TB --- 2013-07-11 04:07:01 - building LINT kernel
> > TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=YES
> > TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=/obj
> > TB --- 2013-07-11 04:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
> > TB --- 2013-07-11 04:07:01 - SRCCONF=/dev/null
> > TB --- 2013-07-11 04:07:01 - TARGET=sparc64
> > TB --- 2013-07-11 04:07:01 - TARGET_ARCH=sparc64
> > TB --- 2013-07-11 04:07:01 - TZ=UTC
> > TB --- 2013-07-11 04:07:01 - __MAKE_CONF=/dev/null
> > TB --- 2013-07-11 04:07:01 - cd /src
> > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=LINT
>  Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013
>  stage 1: configuring the kernel
>  stage 2.1: cleaning up the object tree
>  stage 2.2: rebuilding the object tree
>  stage 2.3: build tools
>  stage 3.1: making dependencies
>  stage 3.2: building everything
> > [...]
> > cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
> > -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
> > -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
> > -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. 
> > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
> > -include opt_global.h -fno-common -finline-limit=15000 --param 
> > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
> > -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  
> > /src/sys/net80211/ieee80211_mesh.c
> > cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
> > -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
> > -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
> > -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. 
> > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
> > -include opt_global.h -fno-common -finline-limit=15000 --param 
> > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
> > -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  
> > /src/sys/net80211/ieee80211_monitor.c
> > cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
> > -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
> > -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
> > -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I. 
> > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
> > -include opt_global.h -fno-common -finline-limit=15000 --param 
> > inline-unit-growth