[head tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

TB --- 2014-04-03 07:33:05 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-04-03 07:33:05 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-04-03 07:33:05 - starting HEAD tinderbox run for ia64/ia64
TB --- 2014-04-03 07:33:05 - cleaning the object tree
TB --- 2014-04-03 07:33:21 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-04-03 07:33:37 - At svn revision 264059
TB --- 2014-04-03 07:33:38 - building world
TB --- 2014-04-03 07:33:38 - CROSS_BUILD_TESTING=YES
TB --- 2014-04-03 07:33:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-04-03 07:33:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-04-03 07:33:38 - SRCCONF=/dev/null
TB --- 2014-04-03 07:33:38 - TARGET=ia64
TB --- 2014-04-03 07:33:38 - TARGET_ARCH=ia64
TB --- 2014-04-03 07:33:38 - TZ=UTC
TB --- 2014-04-03 07:33:38 - __MAKE_CONF=/dev/null
TB --- 2014-04-03 07:33:38 - cd /src
TB --- 2014-04-03 07:33:38 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Apr  3 07:33:45 UTC 2014
>>> 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
[...]
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/ia64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_gethex.c -o 
gdtoa_gethex.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/ia64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_gmisc.c -o 
gdtoa_gmisc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/ia64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_hd_init.c -o 
gdtoa_hd_init.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/ia64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_hexnan.c -o 
gdtoa_hexnan.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/ia64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_misc.c -o 
gdtoa_misc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/ia64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_smisc.c -o 
gdtoa_smisc.o
cc   -O2 -pipe   

Re: Leaving the Desktop Market

[Matthias Gamsjager]

> There are a few alternatives to Lightroom available in Ports Collection,
> you might want to give them a try one day.
>
offtopic:
But it does not even come close to Lightroom. Gimp is also not even
close to Photoshop. Maybe Pixelmator. But Gimp? The UI and usability
is such a mess.
But again it's the difference between free and paying alot of money.
___
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 --- 2014-04-03 07:46:09 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-04-03 07:46:09 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-04-03 07:46:09 - starting HEAD tinderbox run for mips/mips
TB --- 2014-04-03 07:46:09 - cleaning the object tree
TB --- 2014-04-03 07:46:28 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-04-03 07:46:31 - At svn revision 264059
TB --- 2014-04-03 07:46:32 - building world
TB --- 2014-04-03 07:46:32 - CROSS_BUILD_TESTING=YES
TB --- 2014-04-03 07:46:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-04-03 07:46:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-04-03 07:46:32 - SRCCONF=/dev/null
TB --- 2014-04-03 07:46:32 - TARGET=mips
TB --- 2014-04-03 07:46:32 - TARGET_ARCH=mips
TB --- 2014-04-03 07:46:32 - TZ=UTC
TB --- 2014-04-03 07:46:32 - __MAKE_CONF=/dev/null
TB --- 2014-04-03 07:46:32 - cd /src
TB --- 2014-04-03 07:46:32 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Apr  3 07:46:39 UTC 2014
>>> 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
[...]
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_gethex.c -o 
gdtoa_gethex.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_gmisc.c -o 
gdtoa_gmisc.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_hd_init.c -o 
gdtoa_hd_init.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_hexnan.c -o 
gdtoa_hexnan.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_misc.c -o 
gdtoa_misc.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFAC

[head tinderbox] failure on mips64/mips

[FreeBSD Tinderbox]

TB --- 2014-04-03 07:57:51 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-04-03 07:57:51 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-04-03 07:57:51 - starting HEAD tinderbox run for mips64/mips
TB --- 2014-04-03 07:57:51 - cleaning the object tree
TB --- 2014-04-03 07:58:08 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-04-03 07:58:11 - At svn revision 264059
TB --- 2014-04-03 07:58:12 - building world
TB --- 2014-04-03 07:58:12 - CROSS_BUILD_TESTING=YES
TB --- 2014-04-03 07:58:12 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-04-03 07:58:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-04-03 07:58:12 - SRCCONF=/dev/null
TB --- 2014-04-03 07:58:12 - TARGET=mips
TB --- 2014-04-03 07:58:12 - TARGET_ARCH=mips64
TB --- 2014-04-03 07:58:12 - TZ=UTC
TB --- 2014-04-03 07:58:12 - __MAKE_CONF=/dev/null
TB --- 2014-04-03 07:58:12 - cd /src
TB --- 2014-04-03 07:58:12 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Apr  3 07:58:19 UTC 2014
>>> 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
[...]
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_gethex.c -o 
gdtoa_gethex.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_gmisc.c -o 
gdtoa_gmisc.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_hd_init.c -o 
gdtoa_hd_init.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_hexnan.c -o 
gdtoa_hexnan.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-I/src/lib/libc/mips/softfloat  -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -w -c gdtoa_misc.c -o 
gdtoa_misc.o
cc   -O -pipe -G0   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/mips -DNLS  -DSOFTFLOAT 

Re: gcc compilation broken with SVN r264042

[David Chisnall]

On 3 Apr 2014, at 00:23, Warner Losh  wrote:

> So less carping and more fixing is needed here.

Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it 
isn't...

libc now builds for me with gcc and clang.

David
___
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 --- 2014-04-03 08:09:47 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-04-03 08:09:47 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-04-03 08:09:47 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2014-04-03 08:09:47 - cleaning the object tree
TB --- 2014-04-03 08:10:05 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-04-03 08:10:09 - At svn revision 264059
TB --- 2014-04-03 08:10:10 - building world
TB --- 2014-04-03 08:10:10 - CROSS_BUILD_TESTING=YES
TB --- 2014-04-03 08:10:10 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-04-03 08:10:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-04-03 08:10:10 - SRCCONF=/dev/null
TB --- 2014-04-03 08:10:10 - TARGET=powerpc
TB --- 2014-04-03 08:10:10 - TARGET_ARCH=powerpc
TB --- 2014-04-03 08:10:10 - TZ=UTC
TB --- 2014-04-03 08:10:10 - __MAKE_CONF=/dev/null
TB --- 2014-04-03 08:10:10 - cd /src
TB --- 2014-04-03 08:10:10 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Apr  3 08:10:17 UTC 2014
>>> 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
[...]
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_gethex.c -o gdtoa_gethex.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_gmisc.c -o gdtoa_gmisc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_hd_init.c -o gdtoa_hd_init.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_hexnan.c -o gdtoa_hexnan.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_misc.c -o gdtoa_misc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKE

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2014-04-03 08:26:18 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-04-03 08:26:18 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-04-03 08:26:18 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2014-04-03 08:26:18 - cleaning the object tree
TB --- 2014-04-03 08:26:36 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-04-03 08:26:40 - At svn revision 264059
TB --- 2014-04-03 08:26:41 - building world
TB --- 2014-04-03 08:26:41 - CROSS_BUILD_TESTING=YES
TB --- 2014-04-03 08:26:41 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-04-03 08:26:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-04-03 08:26:41 - SRCCONF=/dev/null
TB --- 2014-04-03 08:26:41 - TARGET=powerpc
TB --- 2014-04-03 08:26:41 - TARGET_ARCH=powerpc64
TB --- 2014-04-03 08:26:41 - TZ=UTC
TB --- 2014-04-03 08:26:41 - __MAKE_CONF=/dev/null
TB --- 2014-04-03 08:26:41 - cd /src
TB --- 2014-04-03 08:26:41 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Apr  3 08:26:48 UTC 2014
>>> 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
[...]
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_gethex.c -o gdtoa_gethex.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_gmisc.c -o gdtoa_gmisc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_hd_init.c -o gdtoa_hd_init.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_hexnan.c -o gdtoa_hexnan.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc 
-DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99  -fstack-protector -w -c 
gdtoa_misc.c -o gdtoa_misc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/powerpc64 -DNLS  -D__DBINTERFACE_PRIVATE 
-I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis 
-DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I

[head tinderbox] failure on sparc64/sparc64

[FreeBSD Tinderbox]

TB --- 2014-04-03 08:42:23 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-04-03 08:42:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-04-03 08:42:23 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2014-04-03 08:42:23 - cleaning the object tree
TB --- 2014-04-03 08:42:44 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-04-03 08:42:48 - At svn revision 264059
TB --- 2014-04-03 08:42:49 - building world
TB --- 2014-04-03 08:42:49 - CROSS_BUILD_TESTING=YES
TB --- 2014-04-03 08:42:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-04-03 08:42:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-04-03 08:42:49 - SRCCONF=/dev/null
TB --- 2014-04-03 08:42:49 - TARGET=sparc64
TB --- 2014-04-03 08:42:49 - TARGET_ARCH=sparc64
TB --- 2014-04-03 08:42:49 - TZ=UTC
TB --- 2014-04-03 08:42:49 - __MAKE_CONF=/dev/null
TB --- 2014-04-03 08:42:49 - cd /src
TB --- 2014-04-03 08:42:49 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Thu Apr  3 08:42:56 UTC 2014
>>> 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
[...]
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/sparc64 -DNLS  -I/src/lib/libc/sparc64/sys 
-D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa 
-I/src/lib/libc/../../contrib/libc-vis -DINET6 
-I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP 
-DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
-std=gnu99  -fstack-protector -w -c gdtoa_gethex.c -o gdtoa_gethex.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/sparc64 -DNLS  -I/src/lib/libc/sparc64/sys 
-D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa 
-I/src/lib/libc/../../contrib/libc-vis -DINET6 
-I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP 
-DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
-std=gnu99  -fstack-protector -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/sparc64 -DNLS  -I/src/lib/libc/sparc64/sys 
-D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa 
-I/src/lib/libc/../../contrib/libc-vis -DINET6 
-I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP 
-DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
-std=gnu99  -fstack-protector -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/sparc64 -DNLS  -I/src/lib/libc/sparc64/sys 
-D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa 
-I/src/lib/libc/../../contrib/libc-vis -DINET6 
-I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP 
-DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
-std=gnu99  -fstack-protector -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/sparc64 -DNLS  -I/src/lib/libc/sparc64/sys 
-D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa 
-I/src/lib/libc/../../contrib/libc-vis -DINET6 
-I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE 
-DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include 
-I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime  
-I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP 
-DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
-std=gnu99  -fstack-protector -w -c gdtoa_misc.c -o gdtoa_misc.o
cc   -O2 -pipe   -I/src/lib/libc/include -I/src/lib/libc/../../include 
-I/src/lib/libc/sparc64 -DNLS  -I/src/lib/libc/sparc64/sys 
-D__DBINTERFACE_PRIVATE -I/src/lib/

Re: Leaving the Desktop Market

[Matthias Gamsjager]

> Since when is GIMP an alternative to Lightroom?  I was talking about
> raw processors, not raster image manipulators.
>

The opensource alternatives to Lightroom come not close to the
original. The _same_ is true for GIMP which is hardly workable and is
not more then a nice showcase but its usability is just horrible.
___
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: kevent has bug?

[Kohji Okuno]

From: Konstantin Belousov 
Date: Wed, 2 Apr 2014 20:44:00 +0300
> On Wed, Apr 02, 2014 at 09:45:43AM -0700, John-Mark Gurney wrote:
>> Konstantin Belousov wrote this message on Wed, Apr 02, 2014 at 15:07 +0300:
>> Well, it's not that its preventing waking up the waiter, but failing to
>> register the event on the knote because of the _INFLUX flag...
> Yes, I used the wrong terminology.
> 
>> 
>> > Patch below fixed your test case for me, also tools/regression/kqueue did
>> > not noticed a breakage.  I tried to describe the situation in the
>> > comment in knote().  Also, I removed unlocked check for the KN_INFLUX
>> > in knote, since it seems to be an optimization for rare case, and is
>> > the race on its own.
>> 
>> Comments below...
>> 
>> > diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
>> > index b3fb23d..380f1ff 100644
>> > --- a/sys/kern/kern_event.c
>> > +++ b/sys/kern/kern_event.c
>> 
>> [...]
>> 
>> > @@ -1506,7 +1506,7 @@ retry:
>> >KQ_LOCK(kq);
>> >kn = NULL;
>> >} else {
>> > -  kn->kn_status |= KN_INFLUX;
>> > +  kn->kn_status |= KN_INFLUX | KN_SCAN;
>> >KQ_UNLOCK(kq);
>> >if ((kn->kn_status & KN_KQUEUE) == KN_KQUEUE)
>> >KQ_GLOBAL_LOCK(&kq_global, haskqglobal);
>> 
>> Is there a reason you don't add the KN_SCAN to the other cases in
>> kqueue_scan that set the _INFLUX flag?
> Other cases in kqueue_scan() which set influx do the detach and drop,
> so I do not see a need to ensure that note is registered.  Except I missed
> one case, which you pointed out.
> 
>> 
>> [...]
>> 
>> > @@ -1865,28 +1866,33 @@ knote(struct knlist *list, long hint, int 
>> > lockflags)
>> > */
>> >SLIST_FOREACH(kn, &list->kl_list, kn_selnext) {
>> >kq = kn->kn_kq;
>> > -  if ((kn->kn_status & KN_INFLUX) != KN_INFLUX) {
>> > +  KQ_LOCK(kq);
>> > +  if ((kn->kn_status & (KN_INFLUX | KN_SCAN)) == KN_INFLUX) {
>> > +  /*
>> > +   * Do not process the influx notes, except for
>> > +   * the influx coming from the kq unlock in the
>> > +   * kqueue_scan().  In the later case, we do
>> > +   * not interfere with the scan, since the code
>> > +   * fragment in kqueue_scan() locks the knlist,
>> > +   * and cannot proceed until we finished.
>> > +   */
>> 
>> We might want to add a marker node, and reprocess the list from the
>> marker node, because this might introduce other races in the code too...
>> but the problem with that is that knote is expected to keep the list
>> locked throughout the call if called w/ it already locked, and so we
>> can't do that, without major work... :(
> Why ? If the knlist lock is not dropped, I do not see a need for the
> marker.  The patch does not introduce the sleep point for the KN_SCAN
> knotes anyway.
> 
>> 
>> I added a similar comment in knote_fork:
>>  * XXX - Why do we skip the kn if it is _INFLUX?  Does this
>>  * mean we will not properly wake up some notes?
>> 
>> and it looks like it was true...
>> 
>> So, upon reading the other _INFLUX cases, it looks like we should change
>> _SCAN to be, _CHANGING or something similar, and any place we don't end
>> up dropping the knote, we set this flag also...  Once such case is at
>> the end of kqueue_register, just before the label done_ev_add, where we
>> update the knote w/ new udata and other fields..  Or change the logic
>> of the flag, and set it for all the cases we are about to drop the
>> knote..
> So do you prefer KN_CHANGING instead of KN_SCAN ?  I do not have any
> objections against renaming the flag, but _CHANGING seems to not say
> anything about the flag intent.  I would say that KN_STABLE is more
> useful, or KN_INFLUX_NODEL, or whatever.
> 
> The done_ev_add case is indeed missed in my patch, thank you for noting.
> The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the
> race is possible just by the nature of adding the knote.
> 
>> 
>> > +  KQ_UNLOCK(kq);
>> > +  } else if ((lockflags & KNF_NOKQLOCK) != 0) {
>> > +  kn->kn_status |= KN_INFLUX;
>> > +  KQ_UNLOCK(kq);
>> > +  error = kn->kn_fop->f_event(kn, hint);
>> >KQ_LOCK(kq);
>> 
>> I believe we can drop this unlock/lock pair as it's safe to hold the
>> KQ lock over f_event, we do that in knote_fork...
> The knote_fork() is for the special kinds of knote only, where we indeed know
> in advance that having the kqueue locked around f_event does not break things.
> 
> Updated patch below.
> 
> diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
> index b3fb23d..fadb8fd 100644
> --- a/sys/kern/kern_event.c
> +++ b/sys/kern/kern_event.c
> @@ -474,7 +474,7 @@ knote_fork(struct knlist *list, int pid)

Re: Leaving the Desktop Market

[Alexey Dokuchaev]

On Tue, Apr 01, 2014 at 03:10:22PM -0700, Kevin Oberman wrote:
> FreeBSD desktop since 3.3 (makes me a newbie!) I really dislike pulseaudio
> and have managed to live without it. Firefox works fine without it.
> Unfortunately they dropped OSS support a while go, so I now must use alsa,
> but it works well and without the pain of dealing with pulseaudio, a
> solution in search of a problem it I ever saw one.

PA should just die, of course, just like that kid's other "products".  OSS
is so nice; it supports all those nifty features like per-application mixing
and stuff, we have a very strong implementation of it (kudos to ariff@, let
me remind us all: http://people.freebsd.org/~ariff/SOUND_4.TXT.html).

Giving Firerox back its OSS support is my on TODO list, unfortunately I do
not have any idea when (or if) I can look at it, but that would be a nice
step in dealsificaion of our Ports Collection.  OSS was, and should remain,
the standard Unixish sound system API.

> Audio output is pretty system dependent, but I had little problem getting
> my audio to auto-switch to headphones when I plugged them in. The setup is
> a bit ugly,but I only had to check the available PINs (ugly, ugly) and set
> up stuff once. It just works.

Not always, unfortunately.  I also had a working pin override configuration
in /boot/loader.conf, but after r236750 (major snd_hda driver rewrite) it
stopped working.  I've reported it and tried to get some support from mav@
but he never replied.  Since then, I have to carry pre-r236750 version of
snd_hda(4) to have working sound.

> Power is an issue and I find the current defaults suck. Read mav's article
> on the subject on the wiki.

>From reading that article, I've only added hw.pci.do_power_nodriver="3" and
hw.pci.do_power_resume="0" to /boot/loader.conf.  More aggressive settings,
like cx_lowest="C2", made my laptop very sluggish and unpleasant to operate;
powerd(8) behaves sanely with no tuning, so I wouldn't say that our current
defaults suck.  The reason why we're behind on the "green" lane is because
we generally do not pay much attention when it comes to power-saving during
development of FreeBSD.  (I'd like to be proven wrong.)

./danfe
___
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: Leaving the Desktop Market

[Alexey Dokuchaev]

On Thu, Apr 03, 2014 at 11:21:34AM +0200, Matthias Gamsjager wrote:
> > Since when is GIMP an alternative to Lightroom?  I was talking about
> > raw processors, not raster image manipulators.
> 
> The opensource alternatives to Lightroom come not close to the original.

They maybe not yet a drop-in replacement, but they are competitive enough
to be discussed on photo forums (read: outside open source geeky cabal):

http://www.pentaxforums.com/forums/32-digital-processing-software-printing/242584-darktable-vs-lightroom.html
http://photo.stackexchange.com/questions/37238/how-does-darktable-compare-to-adobe-lightroom-for-editing-jpegs
http://photo.stackexchange.com/questions/23272/simple-comparison-of-lightroom-4-corel-aftershot-pro-darktable
http://www.dpreview.com/forums/post/39475179

As they say, "The differences in actual editing are negligible. It's not
even worth migrating between the two.  LR comes with a price-tag, Darktable
comes with bugs."

./danfe
___
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: Leaving the Desktop Market

[Alexey Dokuchaev]

On Thu, Apr 03, 2014 at 09:49:31AM +0200, Matthias Gamsjager wrote:
> > There are a few alternatives to Lightroom available in Ports Collection,
> > you might want to give them a try one day.
> >
> offtopic:
> But it does not even come close to Lightroom. Gimp is also not even
> close to Photoshop. Maybe Pixelmator. But Gimp? The UI and usability
> is such a mess.

Since when is GIMP an alternative to Lightroom?  I was talking about
raw processors, not raster image manipulators.

./danfe
___
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: Leaving the Desktop Market

[Alexey Dokuchaev]

On Tue, Apr 01, 2014 at 08:38:28AM +0100, David Chisnall wrote:
> On 1 Apr 2014, at 08:11, Jordan Hubbard  wrote:
> > 1. Power.  As you point out, being truly power efficient is a complete
> > top-to-bottom engineering effort and it takes a lot more than just trying
> > to idle the processor whenever possible to achieve that.  You need to
> > optimize all of the hot-spot routines in the system for power efficiency
> > (which actually involves a fair amount of micro architecture knowledge),
> > you need a kernel scheduler that is power management aware, you need a
> > process management system that runs as few things as possible and knows
> > how to schedule things during package wake-up intervals, you need timers
> > to be coalesced at the level where applications consume them, the list
> > just goes on and on.  It's a lot of engineering work, and to drive that
> > work you also need a lot of telemetry data and people with big sticks
> > running around hitting people who write power-inefficient code.  FreeBSD
> > has neither.

Thanks Jordan, this is an excellent elaboration on why exactly we're behind
on the "green" lane, and on power-neglective FreeBSD development overall.

> Just a small note here: Improving power management is something that the
> Core Team and the Foundation have jointly identified as an important goal,
> in particular for mobile/embedded scenarios.  We're currently coordinating
> potential sponsors for the work and soliciting proposals from people
> interested in doing the work.  If you know of anyone in either category
> then please drop either me, core, or the Foundation an email.
> 
> Some things have already seen progress, for example Davide's calloutng work
> includes timer coalescing, but there are still a lot of, uh, opportunities
> for improvement.  The Symbian EKA2 book has some very interesting detail on
> their power management infrastructure, which would be worth looking at for
> anyone interested in working on this, and I believe your former employer
> had some expertise in this area.

Now that's something I'm glad to hear.  It would be cool if FreeBSD gained
some power-efficient software that run smoothly together with hardware (and
laptops in particular) developed by Jordan's former employer. ;-)

> For example, currently hald wakes up every 30 seconds and polls the optical
> drive if you have one.  Why?  Because there's no devd event when a CD is
> inserted, so the only way for it to get these notifications is polling.

I'm surprised to find out that our devd(8) does not emit some event on CD
insertion.  On the other, if by "hald" you mean the one installed by the
`sysutils/hal' port, I've personally never run it, and do not recommend it
to anyone.

./danfe
___
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: iwn(4) in -HEAD supporting Centrino Wireless-N 135

[Tom Murphy]

Hi,

  I'm just wondering if you had any time to look at this? I'm happy to test
any patches or diffs.

Regards,
Tom

On Tue, Mar 11, 2014 at 11:03:20AM -0700, Adrian Chadd wrote:
> I still don't have any ideas here. I do however want to try hacking
> the driver to transmit EAPOL frames at the management rate, and then
> ensure the management rate is non-MCS.
> 
> 
> -a
> 
> 
> On 28 February 2014 15:14, Adrian Chadd  wrote:
> > Hi,
> >
> > the interesting bits:
> >
> >
> > Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate
> > 0002 plcp 0x420a
> > Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate
> > 0002 plcp 0x420a
> > Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate
> > 0002 plcp 0x420a
> > Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate
> > 0002 plcp 0x420a
> > Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate
> > 0002 plcp 0x420a
> > Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate
> > 0002 plcp 0x420a
> > Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> >
> > .. so it's failing to transmit the management frames after association
> > - they're being transmitted at MCS0 and the AP is just plain not
> > ACKing them.
> >
> > Now, I don't know why this is. It's trying to transmit the initial
> > frame at non-MCS rates, but I have a feeling the multi-rate retry
> > table thing is confusing it and it's trying to send it as MCS. So
> > maybe the AP doesn't like management frames at MCS rates.
> >
> > I'll have to think about this a little.
> >
> > -a
> >
> >
> > On 28 February 2014 15:07, Tom Murphy  wrote:
> >> I've attached my iwn debug messages to this email starting
> >> with the point I tried to associate to the Wifi.
> >>
> >> Thanks again for looking at this!
> >>
> >> Kind regards,
> >> Tom
> >>
> >> On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote:
> >>> On 26 February 2014 23:52, Alexandr  wrote:
> >>> > Tom, could you:
> >>> >
> >>> > 1. compile kernel WITH_IWNDEBUG
> >>> > 2. sysctl dev.iwn.0.debug=0x1
> >>> > 3. wlandebug -i wlan0 auth+assoc
> >>> > 4. Associate with AP in 11n mode
> >>> > 5. Send us appropriate /var/log/messages
> >>> >
> >>> > Then I try to compare it with my log.
> >>>
> >>> Please do. I've been trying to track down the source of this "ht just
> >>> doesn't work!" but it works fine with all of the Intel NICs I have
> >>> here.
> >>>
> >>> Can someone see if they can find a mtaching NIC online (amazon,ebay?)
> >>> Owning one that I can whack in a laptop is likely going ot help things
> >>> a lot.
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> -a
___
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"

svn commits r264007-264011: disks missing

[Nikolai Lifanov]

On 04/01/14 12:02, Ryan Stone wrote:
> Author: rstone
> Date: Tue Apr  1 16:02:02 2014
> New Revision: 264011
> URL: http://svnweb.freebsd.org/changeset/base/264011
> 
> Log:
>   Add support for PCIe ARI
>   

With the changes between r264007-264011, my 4-port RocketRAID 640 card
in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci
passthrough, tried looking for these disks with various tools, but no
luck. There is no trace of them being available in dmesg, etc.

I narrowed it down to that range of revisions, and
going back to r264006 makes the disks show up again.

- Nikolai Lifanov
___
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: Call for testers: SNMPv3 support for bsnmpd(1)

[Shteryana Shopova]

Hi all,

OK, I discovered and fixed several v3 bugs while testing this config.

1) A regresion introduced with SVN r256678 breaking parsing of v3
authentication part of a PDU - this is only in current; stable should
be fine; I've uploaded a patch here -
http://people.freebsd.org/~syrinx/snmp/libsnmp-v3-auth-20140403-01.diff

2) A bug in decoding string indexes in snmp_target(3), thus causing
bsnmpd(1) to not send v3 notifications properly and two missing return
statements which could lead to abort() in case of a rollback - this
has never worked in the svn tree, I am not sure why the patch didn't
make it - a patch is available here -
http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff,
it was generated against head, but should apply cleanly against stable
too - to patch the module

#cd
#fetch http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff
#cd /contrib/bsnmp
#patch < snmp_target-20140403-01.diff
#cd ../../usr.sbin/bsnmpd/modules/snmp_target/
#make && make install

3) A problem with old SNMP engine time being returned to the client in
some cases (relevant to v3 only again) which would cause subsequent
PDUs comming from the same client to be considered out-of-time-window
and discarded - patch is available here -
http://people.freebsd.org/~syrinx/snmp/bsnmpd-engine-time-20140403-01.diff

4) There is also a problem with the handling of the connected UDP
sockets - e.g. if the client listening for the trap has not been
available for sometime, the socket error is not cleared until the
first send() - causing "snmpd[8573]: send: Connection refused"
messages in syslog even though the trap was successfully send - an old
patch (pre-v3 sources) is available here -
http://people.freebsd.org/~syrinx/snmp/bsnmp-20101220-03.diff, I'll
update it against head too

Comments, reviews and test reports are very welcome.

Now, the needed configuration for encrypted traps -
1) bsnmpd(1) part

#First v3 SNMP Engine value should be set, e.g.
engine := 0x80:0x10:0x08:0x10:0x80:0x25
snmpEngineID = $(engine)

#USM module should be enabled and at least one user with proper
credentials created
user1 := "bsnmp"
user1passwd := 
0x22:0x98:0x1a:0x6e:0x39:0x93:0x16:0x5e:0x6a:0x21:0x1b:0xd8:0xa9:0x81:0x31:0x05:0x16:0x33:0x38:0x60
#
# SNMPv3 User-based security module - must be loaded for SNMPv3 USM
#
begemotSnmpdModulePath."usm"= "/usr/lib/snmp_usm.so"

# Definition of user "bsnmp" with password "bsnmptest"
usmUserStatus.$(engine).$(user1) = 5
usmUserAuthProtocol.$(engine).$(user1) = $(HMACSHAAuthProtocol)
usmUserAuthKeyChange.$(engine).$(user1) = $(user1passwd)
usmUserPrivProtocol.$(engine).$(user1) = $(AesCfb128Protocol)
usmUserPrivKeyChange.$(engine).$(user1) = $(user1passwd)
usmUserStatus.$(engine).$(user1) = 1

#Definition of a Notification target where traps will be sent with the
credentials of $user1
#
# SNMPv3 Notification Targets module
#
begemotSnmpdModulePath."target"= "/usr/lib/snmp_target.so"
tag:= "test"
snmpNotifyRowStatus.$(tag) = 4
snmpNotifyTag.$(tag) = $(tag)

#
# Specify the target parameters for the notifications - send with the
credentials
# of user $user1
#
snmpTargetParamsRowStatus.$(tag) = 5
snmpTargetParamsMPModel.$(tag) = $(MPmodelSNMPv3)
snmpTargetParamsSecurityModel.$(tag) = $(securityModelUSM)
snmpTargetParamsSecurityName.$(tag) = $(user1)
snmpTargetParamsSecurityLevel.$(tag) = $(authPriv)
snmpTargetParamsRowStatus.$(tag) = 1

#
# Define the notifications' target address - port 162 on localhost
#
snmpTargetAddrRowStatus.$(tag) = 5
snmpTargetAddrTAddress.$(tag) = 0x0a:0x0:0x0:0x01:0x0:0xa2 # hexstring
representing 10.0.0.119 in 4 octets and port 162 in two octets
snmpTargetAddrTagList.$(tag) = "test notification"
snmpTargetAddrParams.$(tag) = $(tag)
snmpTargetAddrRowStatus.$(tag) = 1

2) To receive the traps with net-snmp's snmptrapd put the following
coonfiguration in /etc/snmp/snmptrapd.conf
createUser -e 0x801008108025 bsnmp SHA "bsnmptest" AES "bsnmptest"
authuser log bsnmp

and start it e.g.
#snmptrapd -f -C -c /etc/snmp/snmptrapd.conf -Le

cheers,
Shteryana

On Tue, Apr 1, 2014 at 2:47 PM, Marciano, Anthony  wrote:
> Thank Harti.
>
> Tony
>
> -Original Message-
> From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de]
> Sent: Tuesday, April 01, 2014 2:06 AM
> To: Marciano, Anthony
> Cc: syr...@freebsd.org; Bjoern A. Zeeb; freebsd-current@freebsd.org; 
> tomaro...@gmail.com
> Subject: RE: Call for testers: SNMPv3 support for bsnmpd(1)
>
> On Mon, 31 Mar 2014, Marciano, Anthony wrote:
>
> MA>Currently, we are just looking to monitor standard objects such as
> MA>interfaces and send traps accordingly. Would it be possible to
> MA>provide a trap example of what needs to be added to the snmpd.config
> MA>file to monitor an object and h

Re: another Make (maybe) problem

[Warner Losh]

On Apr 2, 2014, at 9:47 PM, Robert Huff  wrote:

> Warner:
> 
> >  This will happen with fmake. I?ve put some safety belts in place in
> >  another fix to keep this from tripping people up (and plan on using >  a 
> > similar technique to keep people from hitting the aicasm bug on
> >  such systems).
> 
>   As long as make-related issues are on the table ...
> 
>   I have a system, running
> 
> FreeBSD 11.0-CURRENT #0 r263263: Mon Mar 17 15:09:18 EDT 2014 amd64
> 
>   where "make buildworld" fails.  The immediate problem can be seen at:
> 
> http://users.rcn.com/roberthuff/bw_tail
> 
>   the full log at
> 
> http://users.rcn.com/roberthuff/bwl.bz2
> 
>   "make.conf" is appended.  There is no "src.conf".
> 
>   I never seen anything like this before; nothing like has come across 
> current@ (recently); and nothing in src/UPDATING appears relevant.
>   Help, please?

Neither have I. That’s a weird issue.

amd64, I assume? Can you prune down your make.conf to find the minimal line(s) 
that cause this?

Warner

>   Robert Huff
> 
> ◙♪
>   make.conf
> 
> BDBCFLAGS+=   -O -pipe
> DEBUG_FLAGS+= -g
> STRIP=
> SYMVER_ENABLED=   yes
> X_WINDOW_SYSTEM=  xorg
> HAVE_MOTIF=   yes
> 
> #FC="gfortran42"
> 
> KERNCONF=JERUSALEM
> 
> # To avoid building various parts of the base system:
> # (copied from /usr/share/examples/etc/make.conf
> 
> NO_BIND_ETC=   true# Do not install files to /etc/namedb
> NO_BLUETOOTH=  true# do not build Bluetooth related stuff
> NO_PROFILE= true# Avoid compiling profiled libraries
> 
> # to get automatic SASL in sendmail
> 
> SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2
> SENDMAIL_LDFLAGS+=-L/usr/local/lib
> SENDMAIL_LDADD+=  -lsasl2
> 
> #
> # to make CUPS magically keep working
> # See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html
> #
> 
> CUPS_OVERWRITE_BASE=  yes
> NO_LPR=   true
> 
> # added per /usr/ports/UPDATING entry 20090401
> 
> OVERRIDE_LINUX_BASE_PORT=f10
> OVERRIDE_LINUX_NONBASE_PORTS=f10
> 
> #
> 
> WITH_MOZILLA= libxul
> WITH_GECKO=   libxul
> 
> #
> # added 2007/03/04 per advice of 
> # in re science/gramps
> #
> 
> WITH_BERKELEYDB=db6
> WITH_BDB_VER=6
> WANT_OPENLDAP_VER=24
> WANT_OPENLDAP_SASL=true
> 
> #
> #  as required by ports/UPDATING of 20121012
> #
> 
> SAMBA_ENABLE=YES
> 
> #
> # PORTS: use clang unless gcc is explicitly required
> #
> 
> #
> # default to using clang for all port builds, with the following
> # exceptions
> 
> .if !empty(.CURDIR:M/usr/ports/graphics/libcdr) && 
> exists(/usr/local/bin/gcc47)
> CC=gcc47
> CXX=g++47
> CPP=cpp47
> .endif
> 
> 
> .if ${.CURDIR:M*/usr/ports/*}
> .if !defined(USE_GCC)
> .if !defined(CC) || ${CC} == "cc"
> CC=clang
> .endif
> .if !defined(CXX) || ${CXX} == "c++"
> CXX=clang++
> .endif
> .if !defined(CPP) || ${CPP} == "cpp"
> CPP=clang-cpp
> .endif
> .endif
> .endif
> 
> 
> WITH_NEW_XORG="yes"
> WITH_GALLIUM="yes"
> 
> WITH_BSD_SORT=
> 
> 
> WITH_PKGNG=yes
> 
> 
> ___
> 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: gcc compilation broken with SVN r264042

[Warner Losh]

On Apr 3, 2014, at 2:11 AM, David Chisnall  wrote:

> On 3 Apr 2014, at 00:23, Warner Losh  wrote:
> 
>> So less carping and more fixing is needed here.
> 
> Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it 
> isn't...
> 
> libc now builds for me with gcc and clang.

thanks David…  I’d planned a universe run later today to test some of my
changes, so this will help…

Warner
___
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: gcc compilation broken with SVN r264042

[David Chisnall]

On 3 Apr 2014, at 14:26, Warner Losh  wrote:

> 
> On Apr 3, 2014, at 2:11 AM, David Chisnall  wrote:
> 
>> On 3 Apr 2014, at 00:23, Warner Losh  wrote:
>> 
>>> So less carping and more fixing is needed here.
>> 
>> Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it 
>> isn't...
>> 
>> libc now builds for me with gcc and clang.
> 
> thanks David…  I’d planned a universe run later today to test some of my
> changes, so this will help…

Let me know if you encounter any issues.  I've built libc now with:

- clang 3.4 (FreeBSD edition)
- clang 3.4 (FreeBSD edition) -fblocks
- gcc 4.2.1 FreeBSD edition
- gcc 4.2.1 FreeBSD edition -fblocks
- gcc 4.7.3 (from ports)

All of these seem to work, and all produce a libc with _b functions that work 
with my clang-compiled test program.  

David

___
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: gcc compilation broken with SVN r264042

[Warner Losh]

On Apr 3, 2014, at 7:35 AM, David Chisnall  wrote:

> On 3 Apr 2014, at 14:26, Warner Losh  wrote:
> 
>> 
>> On Apr 3, 2014, at 2:11 AM, David Chisnall  wrote:
>> 
>>> On 3 Apr 2014, at 00:23, Warner Losh  wrote:
>>> 
 So less carping and more fixing is needed here.
>>> 
>>> Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if 
>>> it isn't...
>>> 
>>> libc now builds for me with gcc and clang.
>> 
>> thanks David…  I’d planned a universe run later today to test some of my
>> changes, so this will help…
> 
> Let me know if you encounter any issues.  I've built libc now with:
> 
> - clang 3.4 (FreeBSD edition)
> - clang 3.4 (FreeBSD edition) -fblocks
> - gcc 4.2.1 FreeBSD edition
> - gcc 4.2.1 FreeBSD edition -fblocks
> - gcc 4.7.3 (from ports)
> 
> All of these seem to work, and all produce a libc with _b functions that work 
> with my clang-compiled test program.  

Cool. In the background, I’m also testing patches against gcc48 and gcc49 ports 
to allow them to compile FreeBSD, though I’m not through all the bootstrapping 
issues for cross builds…

Warner

___
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: kevent has bug?

[Konstantin Belousov]

On Thu, Apr 03, 2014 at 06:26:56PM +0900, Kohji Okuno wrote:
> > The done_ev_add case is indeed missed in my patch, thank you for noting.
> > The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the
> > race is possible just by the nature of adding the knote.

> I think, we should add KN_SCAN after knote_attach() in
> kqueue_register(), too. What do you think about this?
See above, I noted this case in the previous mail.  This may be elaborated.

First, I think it is technically incorrect to allow the event
notification before the f_attach() method is finished. So the KN_SCAN
flag could be set only after f_attach() call, but due to both kq and
knlist not locked there, we still have the same race. And this race is
in fact acceptable, since it is the race between application calling
EV_ADD, and external event occuring, which cannot be avoided. Until the
kevent(EV_ADD) syscall returned, we do not have an obligation to report
the event from the kqfd. Having the race somewhat bigger by not setting
KN_SCAN is fine in my opinion.


pgp_eM3PUg0OL.pgp
Description: PGP signature

Re: another Make (maybe) problem

[Robert Huff]

Warner Losh  writes

>  amd64, I assume?

Yes, as per the provided uname.

>  Can you prune down your make.conf to find the minimal line(s) that
>  cause this?

Yes, but each run will take about three hours 

Starting with an empty make.conf,


Robert Huff

___
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: Call for testers: SNMPv3 support for bsnmpd(1)

[Marciano, Anthony]

Awesome!

Thanks so much for all of your work.

Much appreciated.

Tony

-Original Message-
From: shtery...@gmail.com [mailto:shtery...@gmail.com] On Behalf Of Shteryana 
Shopova
Sent: Thursday, April 03, 2014 9:09 AM
To: Marciano, Anthony
Cc: Hartmut Brandt; Bjoern A. Zeeb; freebsd-current@freebsd.org; 
tomaro...@gmail.com
Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)

Hi all,

OK, I discovered and fixed several v3 bugs while testing this config.

1) A regresion introduced with SVN r256678 breaking parsing of v3 
authentication part of a PDU - this is only in current; stable should be fine; 
I've uploaded a patch here - 
http://people.freebsd.org/~syrinx/snmp/libsnmp-v3-auth-20140403-01.diff

2) A bug in decoding string indexes in snmp_target(3), thus causing
bsnmpd(1) to not send v3 notifications properly and two missing return 
statements which could lead to abort() in case of a rollback - this has never 
worked in the svn tree, I am not sure why the patch didn't make it - a patch is 
available here - 
http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff,
it was generated against head, but should apply cleanly against stable too - to 
patch the module

#cd
#fetch http://people.freebsd.org/~syrinx/snmp/snmp_target-20140403-01.diff
#cd /contrib/bsnmp
#patch < snmp_target-20140403-01.diff
#cd ../../usr.sbin/bsnmpd/modules/snmp_target/
#make && make install

3) A problem with old SNMP engine time being returned to the client in some 
cases (relevant to v3 only again) which would cause subsequent PDUs comming 
from the same client to be considered out-of-time-window and discarded - patch 
is available here - 
http://people.freebsd.org/~syrinx/snmp/bsnmpd-engine-time-20140403-01.diff

4) There is also a problem with the handling of the connected UDP sockets - 
e.g. if the client listening for the trap has not been available for sometime, 
the socket error is not cleared until the first send() - causing "snmpd[8573]: 
send: Connection refused"
messages in syslog even though the trap was successfully send - an old patch 
(pre-v3 sources) is available here - 
http://people.freebsd.org/~syrinx/snmp/bsnmp-20101220-03.diff, I'll update it 
against head too

Comments, reviews and test reports are very welcome.

Now, the needed configuration for encrypted traps -
1) bsnmpd(1) part

#First v3 SNMP Engine value should be set, e.g.
engine := 0x80:0x10:0x08:0x10:0x80:0x25
snmpEngineID = $(engine)

#USM module should be enabled and at least one user with proper credentials 
created
user1 := "bsnmp"
user1passwd := 
0x22:0x98:0x1a:0x6e:0x39:0x93:0x16:0x5e:0x6a:0x21:0x1b:0xd8:0xa9:0x81:0x31:0x05:0x16:0x33:0x38:0x60
#
# SNMPv3 User-based security module - must be loaded for SNMPv3 USM #
begemotSnmpdModulePath."usm"= "/usr/lib/snmp_usm.so"

# Definition of user "bsnmp" with password "bsnmptest"
usmUserStatus.$(engine).$(user1) = 5
usmUserAuthProtocol.$(engine).$(user1) = $(HMACSHAAuthProtocol)
usmUserAuthKeyChange.$(engine).$(user1) = $(user1passwd)
usmUserPrivProtocol.$(engine).$(user1) = $(AesCfb128Protocol)
usmUserPrivKeyChange.$(engine).$(user1) = $(user1passwd)
usmUserStatus.$(engine).$(user1) = 1

#Definition of a Notification target where traps will be sent with the 
credentials of $user1 # # SNMPv3 Notification Targets module #
begemotSnmpdModulePath."target"= "/usr/lib/snmp_target.so"
tag:= "test"
snmpNotifyRowStatus.$(tag) = 4
snmpNotifyTag.$(tag) = $(tag)

#
# Specify the target parameters for the notifications - send with the 
credentials # of user $user1 #
snmpTargetParamsRowStatus.$(tag) = 5
snmpTargetParamsMPModel.$(tag) = $(MPmodelSNMPv3)
snmpTargetParamsSecurityModel.$(tag) = $(securityModelUSM)
snmpTargetParamsSecurityName.$(tag) = $(user1)
snmpTargetParamsSecurityLevel.$(tag) = $(authPriv)
snmpTargetParamsRowStatus.$(tag) = 1

#
# Define the notifications' target address - port 162 on localhost #
snmpTargetAddrRowStatus.$(tag) = 5
snmpTargetAddrTAddress.$(tag) = 0x0a:0x0:0x0:0x01:0x0:0xa2 # hexstring 
representing 10.0.0.119 in 4 octets and port 162 in two octets
snmpTargetAddrTagList.$(tag) = "test notification"
snmpTargetAddrParams.$(tag) = $(tag)
snmpTargetAddrRowStatus.$(tag) = 1

2) To receive the traps with net-snmp's snmptrapd put the following 
coonfiguration in /etc/snmp/snmptrapd.conf createUser -e 0x801008108025 bsnmp 
SHA "bsnmptest" AES "bsnmptest"
authuser log bsnmp

and start it e.g.
#snmptrapd -f -C -c /etc/snmp/snmptrapd.conf -Le

cheers,
Shteryana

On Tue, Apr 1, 2014 at 2:47 PM, Marciano, Anthony  wrote:
> Thank Harti.
>
> Tony
>
> -Original Message-
> From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de]
> Sent: Tuesday, April 01, 2014 2:06 AM
> To: Marciano, Anthony
> Cc: syr...@freebsd.org; Bjoern A. Zeeb; freebsd-current@freebsd.org; 
> tom

Boot fails @r264070

[David Wolfskill]

Building/installing is fine, and building, installing, and booting
stable/9 @r264061 on the same hardware (different slice) is fine.  (I
didn't rebuild stable/10 this morning, asth only change was to
src/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c, and I don't use
ZFS.  stable/10 works fine on the same hardware @r264032.)

And on my laptop, I had no problems (using AHCI).  The build machine,
though, starts OK, then comes to an inglorious end:

Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #1455  r264070M/264070:1100016: Thu Apr  3 07:48:16 PDT 
2014
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.21-MHz 686-class CPU)
  Origin="GenuineIntel"  Id=0xf41  Family=0xf  Model=0x4  Stepping=1
  
Features=0xbfebfbff
  Features2=0x659d
  AMD Features=0x2010
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 2080395264 (1984 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  6
random device not loaded; using insecure entropy
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
ioapic2  irqs 48-71 on motherboard
random:  initialized
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
atrtc0:  port 0x70-0x77 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pci0:  at device 0.1 (no driver attached)
pci0:  at device 1.0 (no driver attached)
pcib1:  irq 16 at device 2.0 on pci0
pci1:  on pcib1
pcib2:  at device 0.0 on pci1
pci2:  on pcib2
pcib3:  at device 0.2 on pci1
pci3:  on pcib3
em0:  port 0x2040-0x207f mem 
0xd822-0xd823 irq 55 at device 2.1 on pci3
em0: Ethernet address: 00:30:48:2d:32:6b
pcib4:  irq 16 at device 4.0 on pci0
pci4:  on pcib4
pcib5:  irq 16 at device 6.0 on pci0
pci5:  on pcib5
uhci0:  port 0x1400-0x141f irq 16 at 
device 29.0 on pci0
usbus0 on uhci0
uhci1:  port 0x1420-0x143f irq 19 at 
device 29.1 on pci0
usbus1 on uhci1
uhci2:  port 0x1440-0x145f irq 18 at 
device 29.2 on pci0
usbus2 on uhci2
uhci3:  port 0x1460-0x147f irq 16 at 
device 29.3 on pci0
usbus3 on uhci3
ehci0:  mem 0xd8001000-0xd80013ff 
irq 23 at device 29.7 on pci0
usbus4: EHCI version 1.0
usbus4 on ehci0
pcib6:  at device 30.0 on pci0
pci6:  on pcib6
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
pci0:  at device 31.3 (no driver attached)
acpi_button0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Generic PS/2 mouse, device ID 0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
fdc0:  port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
orm0:  at iomem 
0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcf7ff 
pnpid ORM on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
ppc0: parallel port not found.
acpi_perf0:  on cpu0
acpi_perf1:  on cpu1
p4tcc0:  on cpu0
p4tcc1:  on cpu1
Timecounters tick every 1.000 msec
random: unblocking device.
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
ugen0.1:  at usbus0
uhub0:  on usbus0
ugen1.1:  at usbus1
uhub1:  on usbus1
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
ugen2.1:  at usbus2
uhub2:  on usbus2
ugen3.1:  at usbus3
uhub3:  on usbus3
usbus4: 480Mbps High Speed USB v2.0
ugen4.1:  at usbus4
uhub4:  on usbus4
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
ata1: DMA limited to UDMA33, controller found non-ATA66 cable
cd0 at ata1 bus 0 scbus1 target 1 lun 0
uhub3: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
cd0:  Removable CD-ROM SCSI-0 device 
SMP:

Re: Boot fails @r264070

[Benjamin Kaduk]

On Thu, 3 Apr 2014, David Wolfskill wrote:


And on my laptop, I had no problems (using AHCI).  The build machine,
though, starts OK, then comes to an inglorious end:

Trying to mount root from ufs:/dev/aacd0s4a [rw]...
mountroot: waiting for device /dev/aacd0s4a ...
Mounting from ufs:/dev/aacd0s4a failed with error 19.


[...]


mountroot>


So... I have serial console access; is there any debugging I might
do to help figure out what's wrong?  Or is what's wrong already
known?

I have been able to reboot from this point to one of the other
slices; I could probably also unload the default kernel & load
yesterday's (err... make that "the day before's" -- yesterday's
didn't build -- @r263983).


I'm also having some trouble booting (into single user mode, so as to run 
the installworld), at r264039.  It seems that ciss never attaches, so my 
da0 (which is supposed to be on ciss0) does not appear.  My kernel.old is 
much older, __FreeBSD_version 115, but does boot.  However, attempting 
to boot kernel.old in either single-user mode or verbse mode also drops me 
to mountroot> .  That would seem to indicate some hardware problem or 
timing issues more than a problem with the code itself, so I had been 
holding off on posting until I could get more information.


Unfortunately, my serial console is not working at the moment, so getting 
more information is a bit challenging.  Diffing the dmesg from the good 
and bad boots would probably be helpful for you to do.


-Ben
___
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: Boot fails @r264070

[Nikolai Lifanov]

On 04/03/14 12:06, Benjamin Kaduk wrote:
> On Thu, 3 Apr 2014, David Wolfskill wrote:
> 
>> And on my laptop, I had no problems (using AHCI).  The build machine,
>> though, starts OK, then comes to an inglorious end:
>>
>> Trying to mount root from ufs:/dev/aacd0s4a [rw]...
>> mountroot: waiting for device /dev/aacd0s4a ...
>> Mounting from ufs:/dev/aacd0s4a failed with error 19.
>>
> [...]
>>
>> mountroot>
>>
>>
>> So... I have serial console access; is there any debugging I might
>> do to help figure out what's wrong?  Or is what's wrong already
>> known?
>>
>> I have been able to reboot from this point to one of the other
>> slices; I could probably also unload the default kernel & load
>> yesterday's (err... make that "the day before's" -- yesterday's
>> didn't build -- @r263983).
> 
> I'm also having some trouble booting (into single user mode, so as to
> run the installworld), at r264039.  It seems that ciss never attaches,
> so my da0 (which is supposed to be on ciss0) does not appear.  My
> kernel.old is much older, __FreeBSD_version 115, but does boot. 
> However, attempting to boot kernel.old in either single-user mode or
> verbse mode also drops me to mountroot> .  That would seem to indicate
> some hardware problem or timing issues more than a problem with the code
> itself, so I had been holding off on posting until I could get more
> information.
> 
> Unfortunately, my serial console is not working at the moment, so
> getting more information is a bit challenging.  Diffing the dmesg from
> the good and bad boots would probably be helpful for you to do.
> 
> -Ben

I reported a similar problem on freebsd-current@ earlier today.
Fortunately, my boot zpool is still fine, but a RocketRAID controller
only shows 2/4 disks, which just happens to be a full leg of another
raid10-like zpool.

Try reverting revisions r264007-264013. This fixes the problem for me.

- Nikolai Lifanov
___
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: svn commits r264007-264011: disks missing

[Nikolai Lifanov]

On 04/03/14 08:58, Nikolai Lifanov wrote:
> On 04/01/14 12:02, Ryan Stone wrote:
>> Author: rstone
>> Date: Tue Apr  1 16:02:02 2014
>> New Revision: 264011
>> URL: http://svnweb.freebsd.org/changeset/base/264011
>>
>> Log:
>>   Add support for PCIe ARI
>>   
> 
> With the changes between r264007-264011, my 4-port RocketRAID 640 card
> in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci
> passthrough, tried looking for these disks with various tools, but no
> luck. There is no trace of them being available in dmesg, etc.
> 
> I narrowed it down to that range of revisions, and
> going back to r264006 makes the disks show up again.
> 
> - Nikolai Lifanov
> 

I updated to r264073 with revisions r264007-264013 reverted, and all my
disks show up. Could you look into this please? I'll provide any
information that can be helpful.

- Nikolai Lifanov

___
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: Boot fails @r264070

[David Wolfskill]

On Thu, Apr 03, 2014 at 12:06:51PM -0400, Benjamin Kaduk wrote:
> ...
> I'm also having some trouble booting (into single user mode, so as to run 
> the installworld), at r264039

Sympathy

> That would seem to indicate some hardware problem or 
> timing issues more than a problem with the code itself,

Maybe

> so I had been holding off on posting until I could get more information.

Fair enough.

> Unfortunately, my serial console is not working at the moment, so getting 
> more information is a bit challenging.  Diffing the dmesg from the good 
> and bad boots would probably be helpful for you to do.
> 

OK; here it is.  I was able to boot from the last-built kernel (01 Apr):

--- ok  2014-04-03 09:12:45.0 -0700
+++ fail2014-04-03 09:13:16.0 -0700
@@ -6,11 +6,11 @@
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
-FreeBSD 11.0-CURRENT #1453  r263983M/263984:1100016: Tue Apr  1 08:09:27 PDT 
2014
+FreeBSD 11.0-CURRENT #1455  r264070M/264070:1100016: Thu Apr  3 07:48:16 PDT 
2014
 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
 WARNING: WITNESS option enabled, expect reduced performance.
-CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU)
+CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.21-MHz 686-class CPU)
   Origin="GenuineIntel"  Id=0xf41  Family=0xf  Model=0x4  Stepping=1
   
Features=0xbfebfbff
   Features2=0x659d
@@ -49,18 +49,10 @@
 pci1:  on pcib1
 pcib2:  at device 0.0 on pci1
 pci2:  on pcib2
-aac0:  mem 0xdc00-0xdfff irq 24 at device 1.0 
on pci2
-aac0: Enable Raw I/O
-aac0: New comm. interface enabled
-aac0: Adaptec 2200S, aac driver 2.1.9-1
-aacp0 on aac0
-aacp1 on aac0
 pcib3:  at device 0.2 on pci1
 pci3:  on pcib3
-em0:  port 0x2000-0x203f 
mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
-em0: Ethernet address: 00:30:48:2d:32:6a
-em1:  port 0x2040-0x207f 
mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
-em1: Ethernet address: 00:30:48:2d:32:6b
+em0:  port 0x2040-0x207f 
mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
+em0: Ethernet address: 00:30:48:2d:32:6b
 pcib4:  irq 16 at device 4.0 on pci0
 pci4:  on pcib4
 pcib5:  irq 16 at device 6.0 on pci0
@@ -78,8 +70,6 @@
 usbus4 on ehci0
 pcib6:  at device 30.0 on pci0
 pci6:  on pcib6
-vgapci0:  port 0x3000-0x30ff mem 
0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
-vgapci0: Boot video device
 isab0:  at device 31.0 on pci0
 isa0:  on isab0
 atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x14a0-0x14af at device 31.1 on pci0
@@ -110,10 +100,6 @@
 p4tcc0:  on cpu0
 p4tcc1:  on cpu1
 Timecounters tick every 1.000 msec
-aacd0 on aac0
-aacd0: 34970MB (71619584 sectors)
-aacd1 on aac0
-aacd1: 69974MB (143307008 sectors)
 random: unblocking device.
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 12Mbps Full Speed USB v1.0
@@ -132,59 +118,45 @@
 uhub4:  on usbus4
 uhub0: 2 ports with 2 removable, self powered
 uhub1: 2 ports with 2 removable, self powered
-uhub2: 2 ports with 2 removable, self powered
 ata1: DMA limited to UDMA33, controller found non-ATA66 cable
+cd0 at ata1 bus 0 scbus1 target 1 lun 0
 uhub3: 2 ports with 2 removable, self powered
-uhub4: 8 ports with 8 removable, self powered
-ses0 at aacp0 bus 0 scbus0 target 6 lun 0
-ses0:  Fixed Uninstalled SCSI-2 device 
-ses0: 3.300MB/s transfers
-ses0: SAF-TE Compliant Device
-pass0 at aacp0 bus 0 scbus0 target 0 lun 0
-pass0: cd0 at ata1 bus 0 scbus3 target 1 lun 0
+uhub2: 2 ports with 2 removable, self powered
 cd0:  Removable CD-ROM SCSI-0 device 
-cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
-cd0: Attempt to query device size failed: NOT READY, Medium not present
- Fixed Uninstalled SCSI-3 device 
-pass0: 0KB/s transfers
-pass1 at aacp0 bus 0 scbus0 target 1 lun 0
-pass1:  Fixed Uninstalled SCSI-3 device 
-pass1: 0KB/s transfers
-pass2 at aacp0 bus 0 scbus0 target 2 lun 0
-pass2:  Fixed Uninstalled SCSI-3 device 
-pass2: 0KB/s transfers
-pass3 at aacp0 bus 0 scbus0 target 3 lun 0
-pass3:  Fixed Uninstalled SCSI-3 device 
-pass3: 0KB/s transfers
 SMP: AP CPU #1 Launched!
-Timecounter "TSC-low" frequency 1800101709 Hz quality 1000
+cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)Timecounter 
"TSC-low" frequency 1800104058 Hz quality 1000
 WARNING: WITNESS option enabled, expect reduced performance.
+
+cd0: Attempt to query device size failed: NOT READY, Medium not present
+Root mount waiting for: usbus4
+Root mount waiting for: usbus4
+Root mount waiting for: usbus4
+uhub4: 8 ports with 8 removable, self powered
 Trying to mount root from ufs:/dev/aacd0s4a [rw]...
-Enter full pathname of shell or RETURN for /bin/sh: 
-Cannot read termcap database;
-using dumb terminal settings.
-# swapon -a && fsck -p 

Re: svn commits r264007-264011: disks missing

[Konstantin Belousov]

On Thu, Apr 03, 2014 at 12:17:13PM -0400, Nikolai Lifanov wrote:
> On 04/03/14 08:58, Nikolai Lifanov wrote:
> > On 04/01/14 12:02, Ryan Stone wrote:
> >> Author: rstone
> >> Date: Tue Apr  1 16:02:02 2014
> >> New Revision: 264011
> >> URL: http://svnweb.freebsd.org/changeset/base/264011
> >>
> >> Log:
> >>   Add support for PCIe ARI
> >>   
> > 
> > With the changes between r264007-264011, my 4-port RocketRAID 640 card
> > in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci
> > passthrough, tried looking for these disks with various tools, but no
> > luck. There is no trace of them being available in dmesg, etc.
> > 
> > I narrowed it down to that range of revisions, and
> > going back to r264006 makes the disks show up again.
> > 
> > - Nikolai Lifanov
> > 
> 
> I updated to r264073 with revisions r264007-264013 reverted, and all my
> disks show up. Could you look into this please? I'll provide any
> information that can be helpful.

I think verbose dmesg from failing and running kernel should be good
for the start.


pgpgyzpADcs9r.pgp
Description: PGP signature

Re: Boot fails @r264070

[Benjamin Kaduk]

On Thu, 3 Apr 2014, David Wolfskill wrote:


-em0:  port 0x2000-0x203f 
mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
-em0: Ethernet address: 00:30:48:2d:32:6a
-em1:  port 0x2040-0x207f 
mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
-em1: Ethernet address: 00:30:48:2d:32:6b
+em0:  port 0x2040-0x207f 
mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
+em0: Ethernet address: 00:30:48:2d:32:6b


I should also note that I lost my bge1 with the "bad" kernel, as well.



The part:

pci2:  on pcib2
-aac0:  mem 0xdc00-0xdfff irq 24 at device 1.0 
on pci2
-aac0: Enable Raw I/O
-aac0: New comm. interface enabled
-aac0: Adaptec 2200S, aac driver 2.1.9-1
-aacp0 on aac0
-aacp1 on aac0
pcib3:  at device 0.2 on pci1

looks a tad suspicious to me.


Indeed.


Also, thanks to Nikolai for pointing out his experiences; I will try 
reverting those revisions and rebuilding.


-Ben
___
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: svn commits r264007-264011: disks missing

[David Wolfskill]

On Thu, Apr 03, 2014 at 07:23:57PM +0300, Konstantin Belousov wrote:
> ...
> I think verbose dmesg from failing and running kernel should be good
> for the start.

 contains:

[TXT] boot_diff.txt   03-Apr-2014 09:55   15K  
[TXT] boot_fail.txt   03-Apr-2014 09:55   40K  
[TXT] boot_ok.txt 03-Apr-2014 09:55   44K  

Here's a copy of the diff:

--- ok  2014-04-03 09:48:33.0 -0700
+++ fail2014-04-03 09:53:14.0 -0700
@@ -1,7 +1,4 @@
 Type '?' for a list of commands, 'help' for more detailed help.
-OK unload
-OK load /boot/kernel.old/kernel
-/boot/kernel.old/kernel text=0xf2ed81 data=0xd30f0+0x3843f0 
syms=[0x4+0xd8c40+0x4+0x15fc28]
 OK boot -v -s
 Booting...
 GDB: no debug ports present
@@ -32,12 +29,12 @@
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
-FreeBSD 11.0-CURRENT #1453  r263983M/263984:1100016: Tue Apr  1 08:09:27 PDT 
2014
+FreeBSD 11.0-CURRENT #1455  r264070M/264070:1100016: Thu Apr  3 07:48:16 PDT 
2014
 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
 WARNING: WITNESS option enabled, expect reduced performance.
-Preloaded elf kernel "/boot/kernel.old/kernel" at 0xc19c.
-Calibrating TSC clock ... TSC clock: 3600201519 Hz
+Preloaded elf kernel "/boot/kernel/kernel" at 0xc19c2000.
+Calibrating TSC clock ... TSC clock: 3600202176 Hz
 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.20-MHz 686-class CPU)
   Origin="GenuineIntel"  Id=0xf41  Family=0xf  Model=0x4  Stepping=1
   
Features=0xbfebfbff
@@ -449,27 +446,6 @@
 pci2:  on pcib2
 pcib2: allocated bus range (2-2) for rid 0 of pci2
 pci2: domain=0, physical bus=2
-found-> vendor=0x9005, dev=0x0285, revid=0x01
-domain=0, bus=2, slot=1, func=0
-class=01-04-00, hdrtype=0x00, mfdev=0
-cmdreg=0x0316, statreg=0x04b0, cachelnsz=8 (dwords)
-lattimer=0x20 (960 ns), mingnt=0x01 (250 ns), maxlat=0x01 (250 ns)
-intpin=a, irq=5
-powerspec 2  supports D0 D3  current D0
-map[10]: type Prefetchable Memory, range 32, base 0xdc00, size 26, 
enabled
-pcib2: allocated prefetch range (0xdc00-0xdfff) for rid 10 of 
pci0:2:1:0
-pcib2: matched entry for 2.1.INTA
-pcib2: slot 1 INTA hardwired to IRQ 24
-aac0:  mem 0xdc00-0xdfff irq 24 at device 1.0 
on pci2
-aac0: Enable Raw I/O
-aac0: New comm. interface enabled
-ioapic1: routing intpin 0 (PCI IRQ 24) to lapic 0 vector 51
-aac0: i960 80303 100MHz, 64MB memory (48MB cache, 16MB execution), optional 
battery present
-aac0: Kernel 4.2-0, Build 7349, S/N   BAD0
-aac0: Supported 
Options=31d7e
-aac0: Adaptec 2200S, aac driver 2.1.9-1
-aacp0 on aac0
-aacp1 on aac0
 pcib3:  at device 0.2 on pci1
 pcib3: allocating non-ISA range 0x2000-0x20ff
 pcib1: allocated I/O port range (0x2000-0x20ff) for rid 1c of pcib3
@@ -490,20 +466,6 @@
 pcib3: allocated bus range (3-3) for rid 0 of pci3
 pci3: domain=0, physical bus=3
 found-> vendor=0x8086, dev=0x1079, revid=0x03
-domain=0, bus=3, slot=2, func=0
-class=02-00-00, hdrtype=0x00, mfdev=1
-cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords)
-lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns)
-intpin=a, irq=7
-powerspec 2  supports D0 D3  current D0
-MSI supports 1 message, 64 bit
-map[10]: type Memory, range 64, base 0xd820, size 17, enabled
-pcib3: allocated memory range (0xd820-0xd821) for rid 10 of pci0:3:2:0
-map[20]: type I/O Port, range 32, base 0x2000, size  6, enabled
-pcib3: allocated I/O port range (0x2000-0x203f) for rid 20 of pci0:3:2:0
-pcib3: matched entry for 3.2.INTA
-pcib3: slot 2 INTA hardwired to IRQ 54
-found-> vendor=0x8086, dev=0x1079, revid=0x03
 domain=0, bus=3, slot=2, func=1
 class=02-00-00, hdrtype=0x00, mfdev=1
 cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords)
@@ -517,14 +479,10 @@
 pcib3: allocated I/O port range (0x2040-0x207f) for rid 20 of pci0:3:2:1
 pcib3: matched entry for 3.2.INTB
 pcib3: slot 2 INTB hardwired to IRQ 55
-em0:  port 0x2000-0x203f 
mem 0xd820-0xd821 irq 54 at device 2.0 on pci3
-ioapic2: routing intpin 6 (PCI IRQ 54) to lapic 0 vector 52
+em0:  port 0x2040-0x207f 
mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
+ioapic2: routing intpin 7 (PCI IRQ 55) to lapic 0 vector 51
 em0: bpf attached
-em0: Ethernet address: 00:30:48:2d:32:6a
-em1:  port 0x2040-0x207f 
mem 0xd822-0xd823 irq 55 at device 2.1 on pci3
-ioapic2: routing intpin 7 (PCI IRQ 55) to lapic 0 vector 53
-em1: bpf attached
-em1: Ethernet address: 00:30:48:2d:32:6b
+em0: Ethernet address: 00:30:48:2d:32:6b
 pcib4:  irq 16 at device 4.0 on pci0
 pcib4:   domain0
 pcib4:   secondary bus 4
@@ -5

Re: svn commits r264007-264011: disks missing

[Nikolai Lifanov]

On 2014-04-03 12:23, Konstantin Belousov wrote:

On Thu, Apr 03, 2014 at 12:17:13PM -0400, Nikolai Lifanov wrote:

On 04/03/14 08:58, Nikolai Lifanov wrote:
> On 04/01/14 12:02, Ryan Stone wrote:
>> Author: rstone
>> Date: Tue Apr  1 16:02:02 2014
>> New Revision: 264011
>> URL: http://svnweb.freebsd.org/changeset/base/264011
>>
>> Log:
>>   Add support for PCIe ARI
>>
>
> With the changes between r264007-264011, my 4-port RocketRAID 640 card
> in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci
> passthrough, tried looking for these disks with various tools, but no
> luck. There is no trace of them being available in dmesg, etc.
>
> I narrowed it down to that range of revisions, and
> going back to r264006 makes the disks show up again.
>
> - Nikolai Lifanov
>

I updated to r264073 with revisions r264007-264013 reverted, and all 
my

disks show up. Could you look into this please? I'll provide any
information that can be helpful.


I think verbose dmesg from failing and running kernel should be good
for the start.


Sure, here!

http://lifanov.com/files/freebsd/bugs/dmesg.broken.txt
http://lifanov.com/files/freebsd/bugs/dmesg.working.txt

- Nikolai Lifanov

___
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: another Make (maybe) problem

[Robert Huff]

Warner Losh  writes


 >  Can you prune down your make.conf to find the minimal line(s) that
 >  cause this?

 Yes, but each run will take about three hours 

 Starting with an empty make.conf,


Empty make.conf = same result.
Where do I look next?
	1) I know very little about make, but I have seen additional debugging 
options in the man page.  Are there any particular ones which are likely 
to be helpful?

2) Is there a way to just re-try the affected part of buildworld?

Thanks,


Robert Huff


___
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: Boot fails @r264070

[Ryan Stone]

Can somebody please confirm whether setting hw.pci.enable_ari=0 in the
loader fixes the issue or not.  That will help me to figure out if the
issue is with ARI or if I have somehow broken PCI enumeration in
general (I suspect the later).
___
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: Boot fails @r264070

[Nikolai Lifanov]

On 04/03/14 14:05, Ryan Stone wrote:
> Can somebody please confirm whether setting hw.pci.enable_ari=0 in the
> loader fixes the issue or not.  That will help me to figure out if the
> issue is with ARI or if I have somehow broken PCI enumeration in
> general (I suspect the later).
> __

I already tried it.
I can confirm that it does not help.

- Nikolai Lifanov


___
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: Boot fails @r264070

[Nikolai Lifanov]

On 04/03/14 14:25, Nikolai Lifanov wrote:
> On 04/03/14 14:05, Ryan Stone wrote:
>> Can somebody please confirm whether setting hw.pci.enable_ari=0 in the
>> loader fixes the issue or not.  That will help me to figure out if the
>> issue is with ARI or if I have somehow broken PCI enumeration in
>> general (I suspect the later).
>> __
> 
> I already tried it.
> I can confirm that it does not help.
> 
> - Nikolai Lifanov
> 

In fact, here is what it looks like: the disk discovery skips the first
2 and enumerates the rest. Thankfully, this isn't my boot pool and
rebooting without ARI changes discovers every disk and imports it correctly.

$ sysctl hw.pci.enable_ari
hw.pci.enable_ari: 0
$ zpool status data
  pool: data
 state: UNAVAIL
status: One or more devices could not be opened.  There are insufficient
replicas for the pool to continue functioning.
action: Attach the missing device and online it using 'zpool online'.
   see: http://illumos.org/msg/ZFS-8000-3C
  scan: none requested
config:

NAME STATE READ WRITE CKSUM
data UNAVAIL  0 0 0
  mirror-0   UNAVAIL  0 0 0
820204606399244410   UNAVAIL  0 0 0  was /dev/ada0
7129954888383586426  UNAVAIL  0 0 0  was /dev/ada1
  mirror-1   ONLINE   0 0 0
ada0 ONLINE   0 0 0
ada1 ONLINE   0 0 0

- Nikolai Lifanov

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

Bad judgement using chflags

[Joe Nosay]

I thought I could clear the .svn directory using chflag -R noschg
/usr/src/.svn/* and..
I screwed up my system for svn checkout of CURRENT.
Live and learn.
Anyway, how do I fix this?
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Bad judgement using chflags

[Mike Tancsa]

chflags 0 will remove the flags

---Mike

On 4/3/2014 4:52 PM, Joe Nosay wrote:

I thought I could clear the .svn directory using chflag -R noschg
/usr/src/.svn/* and..
I screwed up my system for svn checkout of CURRENT.
Live and learn.
Anyway, how do I fix this?
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"





--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.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: svn commits r264007-264011: disks missing

[Ryan Stone]

This is fixed in r264091.  Apologies for the breakage; it seems to
mostly effect legacy PCI devices and my testing was on PCIe-only
systems.  Thanks to everyone who reported the issue and provided
verbose dmesgs; that really helped me to understand the problem.
___
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: kevent has bug?

[Kohji Okuno]

From: Konstantin Belousov 
Date: Thu, 3 Apr 2014 16:48:14 +0300
> On Thu, Apr 03, 2014 at 06:26:56PM +0900, Kohji Okuno wrote:
>> > The done_ev_add case is indeed missed in my patch, thank you for noting.
>> > The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the
>> > race is possible just by the nature of adding the knote.
> 
>> I think, we should add KN_SCAN after knote_attach() in
>> kqueue_register(), too. What do you think about this?
> See above, I noted this case in the previous mail.  This may be elaborated.
> 
> First, I think it is technically incorrect to allow the event
> notification before the f_attach() method is finished. So the KN_SCAN
> flag could be set only after f_attach() call, but due to both kq and
> knlist not locked there, we still have the same race. And this race is
> in fact acceptable, since it is the race between application calling
> EV_ADD, and external event occuring, which cannot be avoided. Until the
> kevent(EV_ADD) syscall returned, we do not have an obligation to report
> the event from the kqfd. Having the race somewhat bigger by not setting
> KN_SCAN is fine in my opinion.

Hi,

Thank you for your detailed commnet. And I uderstood about your opinion.
By the way, do you commit your change to HEAD?

Regards,
 Kohji Okuno
___
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: iwn(4) in -HEAD supporting Centrino Wireless-N 135

[Adrian Chadd]

I've had no time to continue looking at this, I'm sorry.

I'm very overworked and I'm not able to be both the net80211, ath and
iwn maintainer given how much actual attention they all require.
Someone has to step up and take command of the iwn code.


-a


On 3 April 2014 03:02, Tom Murphy  wrote:
> Hi,
>
>   I'm just wondering if you had any time to look at this? I'm happy to test
> any patches or diffs.
>
> Regards,
> Tom
>
> On Tue, Mar 11, 2014 at 11:03:20AM -0700, Adrian Chadd wrote:
>> I still don't have any ideas here. I do however want to try hacking
>> the driver to transmit EAPOL frames at the management rate, and then
>> ensure the management rate is non-MCS.
>>
>>
>> -a
>>
>>
>> On 28 February 2014 15:14, Adrian Chadd  wrote:
>> > Hi,
>> >
>> > the interesting bits:
>> >
>> >
>> > Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate
>> > 0002 plcp 0x420a
>> > Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate
>> > 0002 plcp 0x420a
>> > Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill
>> > 0 rate 80006902 duration 2815 status 83
>> > Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill
>> > 0 rate 80006902 duration 2815 status 83
>> > Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate
>> > 0002 plcp 0x420a
>> > Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate
>> > 0002 plcp 0x420a
>> > Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill
>> > 0 rate 80006902 duration 2815 status 83
>> > Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill
>> > 0 rate 80006902 duration 2815 status 83
>> > Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate
>> > 0002 plcp 0x420a
>> > Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate
>> > 0002 plcp 0x420a
>> > Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill
>> > 0 rate 80006902 duration 2815 status 83
>> > Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill
>> > 0 rate 80006902 duration 2815 status 83
>> >
>> > .. so it's failing to transmit the management frames after association
>> > - they're being transmitted at MCS0 and the AP is just plain not
>> > ACKing them.
>> >
>> > Now, I don't know why this is. It's trying to transmit the initial
>> > frame at non-MCS rates, but I have a feeling the multi-rate retry
>> > table thing is confusing it and it's trying to send it as MCS. So
>> > maybe the AP doesn't like management frames at MCS rates.
>> >
>> > I'll have to think about this a little.
>> >
>> > -a
>> >
>> >
>> > On 28 February 2014 15:07, Tom Murphy  wrote:
>> >> I've attached my iwn debug messages to this email starting
>> >> with the point I tried to associate to the Wifi.
>> >>
>> >> Thanks again for looking at this!
>> >>
>> >> Kind regards,
>> >> Tom
>> >>
>> >> On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote:
>> >>> On 26 February 2014 23:52, Alexandr  wrote:
>> >>> > Tom, could you:
>> >>> >
>> >>> > 1. compile kernel WITH_IWNDEBUG
>> >>> > 2. sysctl dev.iwn.0.debug=0x1
>> >>> > 3. wlandebug -i wlan0 auth+assoc
>> >>> > 4. Associate with AP in 11n mode
>> >>> > 5. Send us appropriate /var/log/messages
>> >>> >
>> >>> > Then I try to compare it with my log.
>> >>>
>> >>> Please do. I've been trying to track down the source of this "ht just
>> >>> doesn't work!" but it works fine with all of the Intel NICs I have
>> >>> here.
>> >>>
>> >>> Can someone see if they can find a mtaching NIC online (amazon,ebay?)
>> >>> Owning one that I can whack in a laptop is likely going ot help things
>> >>> a lot.
>> >>>
>> >>> Thanks,
>> >>>
>> >>>
>> >>> -a
___
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"

cannot build 9.2 from an 11-current host

[Benjamin Kaduk]

Hi all,

I've got a build machine that does package builds of net/openafs for 
upstream OpenAFS, and is supposed to build packages for all supported 
FreeBSD versions (and a few unsupported ones, too).  I've recently updated 
to r264039M (the 'M' is reverting PCI ARI bits as discussed in a different 
thread), and now when I go back to build a 9.2 chroot, I find that I 
cannot build world:


[...]
c++ -O2 -pipe 
-I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include 
-I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include 
-I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen 
-I. 
-I/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include 
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd9.2\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd9.2\" -DDEFAULT_SYSROOT=\"\" 
-I/usr/obj/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/tmp/legacy/usr/include 
-fno-exceptions -fno-rtti -c 
/usr/jail/amd64_fbsd_92/JAILROOT/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/X86RecognizableInstr.cpp

make: don't know how to make /usr/lib/libstdc++.a. Stop
*** [bootstrap-tools] Error code 2

Stop in /usr/jail/amd64_fbsd_92/JAILROOT/usr/src.
*** [_bootstrap-tools] Error code 1

Stop in /usr/jail/amd64_fbsd_92/JAILROOT/usr/src.
*** Error code 1

sys/conf/newvers.sh is at r260647 (9.2-RELEASE-p3), and the source tree 
was generated by performing a svn checkout on a different machine and 
tarring up the tree.  (That would be a checkout of releng/9.2 .)


This is supposed to be a supported operation, right?

-Ben
___
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: cannot build 9.2 from an 11-current host

[Ryan Stone]

On Thu, Apr 3, 2014 at 9:09 PM, Benjamin Kaduk  wrote:
> Hi all,
>
> I've got a build machine that does package builds of net/openafs for
> upstream OpenAFS, and is supposed to build packages for all supported
> FreeBSD versions (and a few unsupported ones, too).  I've recently updated
> to r264039M (the 'M' is reverting PCI ARI bits as discussed in a different
> thread), and now when I go back to build a 9.2 chroot, I find that I cannot
> build world:

Unfortunately the bug is in 9.2-RELEASE, not 11-CURRENT.  This patch
fixes it, but it came in after 9.2-RELEASE:

http://svnweb.freebsd.org/changeset/base/257812
___
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: cannot build 9.2 from an 11-current host

[Benjamin Kaduk]

On Thu, 3 Apr 2014, Ryan Stone wrote:


On Thu, Apr 3, 2014 at 9:09 PM, Benjamin Kaduk  wrote:

Hi all,

I've got a build machine that does package builds of net/openafs for
upstream OpenAFS, and is supposed to build packages for all supported
FreeBSD versions (and a few unsupported ones, too).  I've recently updated
to r264039M (the 'M' is reverting PCI ARI bits as discussed in a different
thread), and now when I go back to build a 9.2 chroot, I find that I cannot
build world:


Unfortunately the bug is in 9.2-RELEASE, not 11-CURRENT.  This patch
fixes it, but it came in after 9.2-RELEASE:


I figured it would be, and almost sent to -stable instead of here.


http://svnweb.freebsd.org/changeset/base/257812


Well, that was easy.  Thanks for the quick pointer!

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