Jenkins build is still unstable: FreeBSD_HEAD-tests2 #865

2015-03-21 Thread jenkins-admin 
See 

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

Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Adrian Chadd 
ok, then hm, where's the gpio pin configured..


-a


On 21 March 2015 at 21:55, Miguel Clara  wrote:
>
>
> On March 22, 2015 4:19:23 AM WET, Adrian Chadd  wrote:
>>Ok, so I'd cycle that rfkill gpio from 1 -> uhm, whatever the max for
>>that thing is (16?)
>>
>>Each time:
>>
>>ifconfig wlan0 down
>>sysctl dev.ath.0.rfkill=X
>>ifconfig wlan0 up
>>ifconfig wlan0 list scan
>>
>>See if it sees anything.
>
> It seems to accept only 0 and 1.
>
>
> I'll have to play with that tomorrow as its almost 5am here.
> But it seems to show no scan results with either 0 or 1 (when running just 
> scan...  list scan works the first time..  but its not really re-scaning)
>
>>
>>
>>
>>-adrian
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Miguel Clara 


On March 22, 2015 4:19:23 AM WET, Adrian Chadd  wrote:
>Ok, so I'd cycle that rfkill gpio from 1 -> uhm, whatever the max for
>that thing is (16?)
>
>Each time:
>
>ifconfig wlan0 down
>sysctl dev.ath.0.rfkill=X
>ifconfig wlan0 up
>ifconfig wlan0 list scan
>
>See if it sees anything.

It seems to accept only 0 and 1. 


I'll have to play with that tomorrow as its almost 5am here. 
But it seems to show no scan results with either 0 or 1 (when running just 
scan...  list scan works the first time..  but its not really re-scaning) 

>
>
>
>-adrian

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Adrian Chadd 
Ok, so I'd cycle that rfkill gpio from 1 -> uhm, whatever the max for
that thing is (16?)

Each time:

ifconfig wlan0 down
sysctl dev.ath.0.rfkill=X
ifconfig wlan0 up
ifconfig wlan0 list scan

See if it sees anything.



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

Jenkins build is unstable: FreeBSD_HEAD-tests2 #864

2015-03-21 Thread jenkins-admin 
See 

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

11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has after

2015-03-21 Thread Mark Millard 
Basic context (more details later):

> # freebsd-version -ku; uname -apKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 
> 05:15:23 PDT 2015 
> root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG  powerpc powerpc64 
> 1100062 1100062

I was seeing what would happen if I tried gcc5 for buildworld/buildkernel and 
gcc5 reported the following.



The problem:

> /usr/local/bin/gcc5 -fpic -DPIC  -O2 -pipe   -I/usr/srcC/lib/libpjdlog 
> -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W 
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs 
> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign   -c 
> /usr/srcC/lib/libpjdlog/pjdlog.c -o pjdlog.So

> In file included from /usr/srcC/lib/libpjdlog/pjdlog.c:44:0:
> /usr/include/printf.h:118:44: error: unknown type name 'va_list'
>  int __xvprintf(FILE *fp, const char *fmt0, va_list ap);
> ^

Looking at the sources suggests that  is explicitly in the #include 
sequence too late to guarantee va_args a definition at the point of its use in 
#include  :  is #include'd in pjdlog.c in the line after 
#include  and printf.h itself does not (directly) include stdarg.h .

/usr/include/printf.h (the LOOK HERE is my message editing) :
> ...
> #include 
> #include   /// < LOOK HERE for lack of 
> ...
> int __xvprintf(FILE *fp, const char *fmt0, va_list ap);
> ...

/usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message editing) :
> ...
> #include 
> __FBSDID("$FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 09:41:06Z 
> pjd $");
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #include 
> #include 
> #include 
> #include 
> #include   /// < LOOK HERE
> #include   /// < LOOK HERE for stdarg.h vs. printf.h order
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #ifdef notyet
> #include 
> #endif
> 
> #include "pjdlog.h"



Context details:

make -j 8 \
WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \
WITHOUT_LLDB= \
WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \
WITH_BOOT= WITH_LIB32= \
buildworld buildkernel \
KERNCONF=GENERIC64vtsc-NODEBUG \
TARGET=powerpc TARGET_ARCH=powerpc64

# more /etc/src.conf 
NO_WERROR=
WITH_LIBCPLUSPLUS=
#
#
# For trying gcc5...
#
CC=/usr/local/bin/gcc5
CXX=/usr/local/bin/g++5
CPP=/usr/local/bin/cpp5
AS=/usr/local/powerpc64-portbld-freebsd11.0/bin/as
R=/usr/local/powerpc64-portbld-freebsd11.0/bin/ar
LD=/usr/local/powerpc64-portbld-freebsd11.0/bin/ld
NM=/usr/local/powerpc64-portbld-freebsd11.0/bin/nm
OBJCOPY=/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy
OBJDUMP=/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump
RANLIB=/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib
SIZE=/usr/local/powerpc64-portbld-freebsd11.0/bin/size
STRINGS=/usr/local/powerpc64-portbld-freebsd11.0/bin/strings

# more /etc/make.conf
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=

# svnlite info /usr/srcC/
Path: /usr/srcC
Working Copy Root Path: /usr/srcC
URL: https://svn0.us-west.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn0.us-west.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 279514
Node Kind: directory
Schedule: normal
Last Changed Author: adrian
Last Changed Rev: 279514
Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015)

# svnlite info /usr/ports/lang/gcc5
Path: /usr/ports/lang/gcc5
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
Relative URL: ^/head/lang/gcc5
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 380943
Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015)


===
Mark Millard
markmi at dsl-only.net

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

Build failed in Jenkins: FreeBSD_HEAD-tests2 #863

2015-03-21 Thread jenkins-admin 
See 

--
[...truncated 658 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.020s]
lib/libc/string/swab:swab_basic  ->  passed  [0.018s]
lib/libc/sys/access_test:access_access  ->  passed  [0.023s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.020s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.028s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.022s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.032s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.018s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.056s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.021s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.033s]
lib/libc/sys/clock_gettime_test:clock_gettime_real  ->  passed  [0.034s]
lib/libc/sys/connect_test:connect_low_port  ->  passed  [0.027s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.024s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.018s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.023s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.053s]
lib/libc/sys/dup_test:dup3_err  ->  passed  [0.024s]
lib/libc/sys/dup_test:dup3_max  ->  passed  [0.020s]
lib/libc/sys/dup_test:dup3_mode  ->  passed  [0.061s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.032s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.025s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.050s]
lib/libc/sys/fsync_test:fsync_err  ->  passed  [0.018s]
lib/libc/sys/fsync_test:fsync_sync  ->  passed  [0.578s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.020s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.021s]
lib/libc/sys/getcontext_test:setcontext_link  ->  passed  [0.020s]
lib/libc/sys/getgroups_test:getgroups_err  ->  expected_failure: Reported as 
kern/189941: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: 
getgroups(-1, gidset) == -1 not met  [0.029s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.045s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.019s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.039s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.018s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.019s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.018s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.026s]
lib/libc/sys/getitimer_test:setitimer_old  ->  passed  [0.017s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.037s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.020s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.035s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.019s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.018s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.041s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.021s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.020s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.020s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.645s]
lib/libc/sys/getrusage_test:getrusage_utime_zero  ->  skipped: this testcase 
passes/fails sporadically on FreeBSD/i386 @ r273153 (at least)  [0.019s]
lib/libc/sys/getsid_test:getsid_current  ->  passed  [0.035s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.020s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.025s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.020s]
lib/libc/sys/gettimeofday_test:gettimeofday_mono  ->  passed  [0.032s]
lib/libc/sys/issetugid_test:issetugid_egid  ->  passed  [0.022s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.267s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.039s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.026s]
lib/libc/sys/kevent_test:kevent_zerotimer  ->  passed  [0.017s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.018s]
lib/libc/sys/kevent_test:kqueue_unsupported_fd  ->  skipped: no /nonexistent 
available for testing  [0.017s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.044s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.017s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.034s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.020s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.022s]
lib/libc/sys/link_test:link_count  ->  passed  [0.031s]
lib/libc/sys/link_test:link_err  ->  passed  [0.027s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.020s]
lib/libc/sys/link_test:link_stat  ->  passed  [0.038s]
lib/libc/sys/listen_test:listen_err  ->  passed  [0.024s]
lib/libc/sys/listen_test:listen_low_port  ->  passed  [0.053s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.030s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.046s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.019s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.018s]
lib/libc/sys/mkdir

Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Miguel Clara 
On Sun, Mar 22, 2015 at 12:38 AM, Adrian Chadd  wrote:

> On 21 March 2015 at 17:33, Miguel Clara  wrote:
> >
> >
> > On Sat, Mar 21, 2015 at 3:21 PM, Adrian Chadd 
> wrote:
> >>
> >> Hi,
> >>
> >> It may be rfkill then. It may be that there's a GPIO pin wired up
> >> somewhere that needs updating. Erk.
> >>
> >> Someone buy me one of these laptops so I can see what's going on? :)
> >>
> >
> > Mine (Acer Acer Aspire S3-391) costs around 650€ I think... The V17 has
> "air
> > plain mode" instead of the Wi-FI on/off, but I guess it does the same
> > thing... it also costs much more because of all the other hardware.
> >
> > I gladly give you one if I could afford it... :P
> >
> > Id be happy to join in a group donation if that's even possible.
> >
> >
> > On another note this module is wifi+bluetooth, I wonder if in my case
> this
> > dmesg log showing:
> > ugen1.4:  at usbus1 (disconnected)
> > ugen1.4:  at usbus1
> >
>
> Is acctaully refering to turning off(hardware) bluetooth since I keep the
> > wireless?
>

ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)

Interesting find:
http://lkml.org/lkml/2013/4/7/162 (guess you're already aware of that... I
was already typing this when I noticed you're reply)


>
> Yup.
>
> (Reminds me, I should update ath3kfw in the base system already; I
> have updated it locally to load in firmware for all the newer NICs.)
>
> It may just be RFKILL. Hm, I wonder how you'd go about fixing that.
>
>

> What are the contents of sysctl dev.ath.0 ? Can you put it up
> somewhere? I think the rfkill setup/gpio pins are there.
>

Full:
http://pastebin.com/raw.php?i=SnMRV7zX

sysctl dev.ath.0 | eg 'rfkill|gpio|setup'

dev.ath.0.rfkill: 1


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

Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Adrian Chadd 
On 21 March 2015 at 17:33, Miguel Clara  wrote:
>
>
> On Sat, Mar 21, 2015 at 3:21 PM, Adrian Chadd  wrote:
>>
>> Hi,
>>
>> It may be rfkill then. It may be that there's a GPIO pin wired up
>> somewhere that needs updating. Erk.
>>
>> Someone buy me one of these laptops so I can see what's going on? :)
>>
>
> Mine (Acer Acer Aspire S3-391) costs around 650€ I think... The V17 has "air
> plain mode" instead of the Wi-FI on/off, but I guess it does the same
> thing... it also costs much more because of all the other hardware.
>
> I gladly give you one if I could afford it... :P
>
> Id be happy to join in a group donation if that's even possible.
>
>
> On another note this module is wifi+bluetooth, I wonder if in my case this
> dmesg log showing:
> ugen1.4:  at usbus1 (disconnected)
> ugen1.4:  at usbus1
>
> Is acctaully refering to turning off(hardware) bluetooth since I keep the
> wireless?

Yup.

(Reminds me, I should update ath3kfw in the base system already; I
have updated it locally to load in firmware for all the newer NICs.)

It may just be RFKILL. Hm, I wonder how you'd go about fixing that.

What are the contents of sysctl dev.ath.0 ? Can you put it up
somewhere? I think the rfkill setup/gpio pins are there.


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

Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Miguel Clara 
On Sat, Mar 21, 2015 at 3:21 PM, Adrian Chadd  wrote:

> Hi,
>
> It may be rfkill then. It may be that there's a GPIO pin wired up
> somewhere that needs updating. Erk.
>
> Someone buy me one of these laptops so I can see what's going on? :)
>
>
Mine (Acer Acer Aspire S3-391) costs around 650€ I think... The V17 has
"air plain mode" instead of the Wi-FI on/off, but I guess it does the same
thing... it also costs much more because of all the other hardware.

I gladly give you one if I could afford it... :P

Id be happy to join in a group donation if that's even possible.


On another note this module is wifi+bluetooth, I wonder if in my case this
dmesg log showing:
ugen1.4:  at usbus1 (disconnected)
ugen1.4:  at usbus1

Is acctaully refering to turning off(hardware) bluetooth since I keep the
wireless?

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

>r280312 - r280332 VirtualBox is broken.

2015-03-21 Thread Ivan Klymenko 
After auditing the r280312 I just upgraded to revision r280332 and then
discovered that my VirtualBox is broken.

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: Use of chunksize before initialization

2015-03-21 Thread Konstantin Belousov 
On Sat, Mar 21, 2015 at 11:20:26AM +0200, Ivan A. Kosarev wrote:
> 
> On 03/21/2015 03:02 AM, Konstantin Belousov wrote:
> > On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote:
> >> #12 0x0008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698
> >> #13 malloc_init () at jemalloc_jemalloc.c:296
> >> #14 0x000801243ea2 in ?? () from /lib/libc.so.7
> >> #15 0x0008006a5400 in ?? ()
> >> #16 0x00080089e5b0 in ?? () from /libexec/ld-elf.so.1
> >> #17 0x7fffe0b0 in ?? ()
> >> #18 0x000801139d06 in _init () from /lib/libc.so.7
> >> #19 0x7fffe0b0 in ?? ()
> > The backtrace is strange.  Did you compiled malloc with the debugging
> > symbols, while keep rest of libc without -g ?
> 
> I've just added the -g flag to CC_FLAGS in the Makefile and made sure to 
> install an unstripped version of the .so . I could investigate more on 
> why the early calls omit debug symbols, if it does any matter.

I want to understand at what stage of the initialization the access happens.
This is why I want to see the complete backtrace.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2015-03-21 Thread Mateusz Guzik 
On Sat, Mar 21, 2015 at 08:14:43PM +, jenkins-ad...@freebsd.org wrote:
> lib/libc/sys/setrlimit_test:setrlimit_nproc  ->  maxproc limit exceeded by 
> uid 977 (pid 31459); see tuning(7) and login.conf(5)
> passed  [0.561s]
> lib/libc/sys/setrlimit_test:setrlimit_perm  ->  panic: mutex process lock not 
> owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00974408e0
> vpanic() at vpanic+0x189/frame 0xfe0097440960
> panic() at panic+0x43/frame 0xfe00974409c0
> __mtx_assert() at __mtx_assert+0xc2/frame 0xfe00974409d0
> proc_set_cred() at proc_set_cred+0x36/frame 0xfe00974409f0
> fork1() at fork1+0x27e/frame 0xfe0097440ac0
> sys_fork() at sys_fork+0x1f/frame 0xfe0097440ae0
> amd64_syscall() at amd64_syscall+0x27f/frame 0xfe0097440bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0097440bf0
> --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c516a, rsp = 
> 0x7fffc2d8, rbp = 0x7fffc340 ---

Should be fixed starting with
https://svnweb.freebsd.org/changeset/base/280331

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

Build failed in Jenkins: FreeBSD_HEAD-tests2 #862

2015-03-21 Thread jenkins-admin 
See 

--
[...truncated 1411 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.013s]
lib/libc/string/swab:swab_basic  ->  passed  [0.012s]
lib/libc/sys/access_test:access_access  ->  passed  [0.019s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.014s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.015s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.015s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.014s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.015s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.709s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.015s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.016s]
lib/libc/sys/clock_gettime_test:clock_gettime_real  ->  passed  [0.016s]
lib/libc/sys/connect_test:connect_low_port  ->  passed  [0.014s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.013s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.013s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.031s]
lib/libc/sys/dup_test:dup3_err  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup3_max  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup3_mode  ->  passed  [0.033s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.019s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.032s]
lib/libc/sys/fsync_test:fsync_err  ->  passed  [0.014s]
lib/libc/sys/fsync_test:fsync_sync  ->  passed  [0.248s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.015s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.015s]
lib/libc/sys/getcontext_test:setcontext_link  ->  passed  [0.015s]
lib/libc/sys/getgroups_test:getgroups_err  ->  expected_failure: Reported as 
kern/189941: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: 
getgroups(-1, gidset) == -1 not met  [0.015s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.015s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.016s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.014s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.014s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.016s]
lib/libc/sys/getitimer_test:setitimer_old  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.016s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.023s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.018s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.015s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.015s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.130s]
lib/libc/sys/getrusage_test:getrusage_utime_zero  ->  skipped: this testcase 
passes/fails sporadically on FreeBSD/i386 @ r273153 (at least)  [0.015s]
lib/libc/sys/getsid_test:getsid_current  ->  passed  [0.015s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.015s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.015s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.015s]
lib/libc/sys/gettimeofday_test:gettimeofday_mono  ->  passed  [0.017s]
lib/libc/sys/issetugid_test:issetugid_egid  ->  passed  [0.017s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.017s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.017s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.017s]
lib/libc/sys/kevent_test:kevent_zerotimer  ->  passed  [0.016s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.017s]
lib/libc/sys/kevent_test:kqueue_unsupported_fd  ->  skipped: no /nonexistent 
available for testing  [0.015s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.017s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.015s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.019s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.016s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.017s]
lib/libc/sys/link_test:link_count  ->  passed  [0.020s]
lib/libc/sys/link_test:link_err  ->  passed  [0.020s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.015s]
lib/libc/sys/link_test:link_stat  ->  passed  [0.018s]
lib/libc/sys/listen_test:listen_err  ->  passed  [0.019s]
lib/libc/sys/listen_test:listen_low_port  ->  passed  [0.015s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.015s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.035s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.016s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.015s]
lib/libc/sys/mkdi

Re: [PATCH 1/3] fork: assign refed credentials earlier

2015-03-21 Thread Mateusz Guzik 
On Sat, Mar 21, 2015 at 09:29:04PM +0200, Konstantin Belousov wrote:
> On Sat, Mar 21, 2015 at 07:19:31PM +0100, Mateusz Guzik wrote:
> > On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote:
> > > On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote:
> > > > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote:
> > > > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote:
> > > > > > From: Mateusz Guzik 
> > > > > > 
> > > > > > Prior to this change the kernel would take p1's credentials and 
> > > > > > assign
> > > > > > them tempororarily to p2. But p1 could change credentials at that 
> > > > > > time
> > > > > > and in effect give us a use-after-free.
> > > > > In which way could it change the credentials ?  The assigned 
> > > > > credentials
> > > > > are taken from td_ucred, which, I thought, are guaranteed to be stable
> > > > > for the duration of a syscall.
> > > > > 
> > > > 
> > > > It takes thread's credential in do_fork. But initial copy is taken
> > > > unlocked from struct proc.
> > > > 
> > > > Relevant part of the diff:
> > > > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, 
> > > > > > struct proc **procp,
> > > > > >  * XXX: This is ugly; when we copy resource usage, we need to 
> > > > > > bump
> > > > > >  *  per-cred resource counters.
> > > > > >  */
> > > > > > -   proc_set_cred(newproc, p1->p_ucred);
> > > > > > +   proc_set_cred(newproc, crhold(td->td_ucred));
> > > > > >  
> > > 
> > > I do not understand your note, nor I see the chunk above in the patches
> > > you send.  Below is the citation from the patch 1:
> > > 
> > > @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc 
> > > *p2,  
> > > +struct thread *td2,  
> > >   
> > > bzero(&p2->p_startzero,   
> > >   
> > > __rangeof(struct proc, p_startzero, p_endzero));  
> > >   
> > >   
> > >   
> > > -   crhold(td->td_ucred); 
> > >   
> > > -   proc_set_cred(p2, td->td_ucred);  
> > >   
> > > - 
> > >   
> > 
> > fork1 does:
> > 
> > proc_set_cred(newproc, p1->p_ucred);
> > 
> > p1 is unlocked, so whatever memory p1->p_ucred points to may already be
> > freed.
> > 
> > /*
> >  * Initialize resource accounting for the child process.
> >  */
> > error = racct_proc_fork(p1, newproc);
> > if (error != 0) {
> > error = EAGAIN;
> > goto fail1;
> > }
> > 
> > racct_proc_fork -> racct_add_locked results in accessing such
> > now-possibly-freed credentials.
> > 
> > do_fork which properly assigns credentials (from a stable source
> > (td_ucred) + grabs a reference) is called later.
> > 
> > The patch in question moves aforementioned assignent earlier to replace
> > unsafe one with p1->p_ucred.
> 
> It seems that I understand now.
> 
> If you instead assign td->td_ucred for the new process p_ucred temporary,
> would it allow to avoid introducing fail2 label ?  I dislike even more
> contrived cleanup after the patch.

Yes but that seems like a hack awaiting for someone to trip over.

For instance I would say it would be desirable to move stuff like
freeing credentials into zone destructor handler.

A hack like this would leave us with an extra crfree.

Doing this work would require some care and making sure we have garbage
only where we can afford it and I'm not interested in dealing with this
right now.

So tl;dr I strongly prefer the patch as it is.

-- 
Mateusz Guzik 
___
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: What's the official method to test the build now?

2015-03-21 Thread Garrett Cooper 
On Mar 21, 2015, at 12:37, Dimitry Andric  wrote:

> On 21 Mar 2015, at 17:25, Garrett Cooper  wrote:
>> 
>>> On Mar 21, 2015, at 06:35, Ian Lepore  wrote:
>>> 
 On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote:
 "make tinderbox" has been broken for weeks, so I presume it's not what I'm
 supposed to be using to test my commits anymore.  What's the officially
 supported make target that I'm supposed to use?
>>> 
>>> I use "make universe", sometimes with the -DMAKE_JUST_KERNELS option.
>> 
>> make universe doesn't error out; make tinderbox does however.
>> 
>>> But the LINT kernels for x86 and sparc have been broken since January.
> 
> So what's the effective difference between universe and tinderbox then?
> I've built quite a number of universes recently, and I while I did get a
> few errors, they were usually fixed quite quickly.
> 
> Also, universe generates LINT kernel configurations, and builds them.  I
> didn't see errors there either...  Does tinderbox generate LINT configs
> differently, somehow?

universe gets called by tinderbox. From Makefile:

  6 # universe- *Really* build *everything* (buildworld and
  7 #   all kernels on all architectures).
  8 # tinderbox   - Same as universe, but presents a list of failed 
build
  9 #   targets and exits with an error if there were any.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What's the official method to test the build now?

2015-03-21 Thread Dimitry Andric 
On 21 Mar 2015, at 17:25, Garrett Cooper  wrote:
> 
>> On Mar 21, 2015, at 06:35, Ian Lepore  wrote:
>> 
>>> On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote:
>>> "make tinderbox" has been broken for weeks, so I presume it's not what I'm
>>> supposed to be using to test my commits anymore.  What's the officially
>>> supported make target that I'm supposed to use?
>> 
>> I use "make universe", sometimes with the -DMAKE_JUST_KERNELS option.
> 
> make universe doesn't error out; make tinderbox does however.
> 
>> But the LINT kernels for x86 and sparc have been broken since January.

So what's the effective difference between universe and tinderbox then?
I've built quite a number of universes recently, and I while I did get a
few errors, they were usually fixed quite quickly.

Also, universe generates LINT kernel configurations, and builds them.  I
didn't see errors there either...  Does tinderbox generate LINT configs
differently, somehow?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH 1/3] fork: assign refed credentials earlier

2015-03-21 Thread Konstantin Belousov 
On Sat, Mar 21, 2015 at 07:19:31PM +0100, Mateusz Guzik wrote:
> On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote:
> > On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote:
> > > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote:
> > > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote:
> > > > > From: Mateusz Guzik 
> > > > > 
> > > > > Prior to this change the kernel would take p1's credentials and assign
> > > > > them tempororarily to p2. But p1 could change credentials at that time
> > > > > and in effect give us a use-after-free.
> > > > In which way could it change the credentials ?  The assigned credentials
> > > > are taken from td_ucred, which, I thought, are guaranteed to be stable
> > > > for the duration of a syscall.
> > > > 
> > > 
> > > It takes thread's credential in do_fork. But initial copy is taken
> > > unlocked from struct proc.
> > > 
> > > Relevant part of the diff:
> > > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, 
> > > > > struct proc **procp,
> > > > >* XXX: This is ugly; when we copy resource usage, we need to 
> > > > > bump
> > > > >*  per-cred resource counters.
> > > > >*/
> > > > > - proc_set_cred(newproc, p1->p_ucred);
> > > > > + proc_set_cred(newproc, crhold(td->td_ucred));
> > > > >  
> > 
> > I do not understand your note, nor I see the chunk above in the patches
> > you send.  Below is the citation from the patch 1:
> > 
> > @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2,  
> > 
> > +struct thread *td2,
> > 
> > bzero(&p2->p_startzero, 
> > 
> > __rangeof(struct proc, p_startzero, p_endzero));
> > 
> > 
> > 
> > -   crhold(td->td_ucred);   
> > 
> > -   proc_set_cred(p2, td->td_ucred);
> > 
> > -   
> > 
> 
> fork1 does:
> 
> proc_set_cred(newproc, p1->p_ucred);
> 
> p1 is unlocked, so whatever memory p1->p_ucred points to may already be
> freed.
> 
> /*
>  * Initialize resource accounting for the child process.
>  */
> error = racct_proc_fork(p1, newproc);
> if (error != 0) {
> error = EAGAIN;
> goto fail1;
> }
> 
> racct_proc_fork -> racct_add_locked results in accessing such
> now-possibly-freed credentials.
> 
> do_fork which properly assigns credentials (from a stable source
> (td_ucred) + grabs a reference) is called later.
> 
> The patch in question moves aforementioned assignent earlier to replace
> unsafe one with p1->p_ucred.

It seems that I understand now.

If you instead assign td->td_ucred for the new process p_ucred temporary,
would it allow to avoid introducing fail2 label ?  I dislike even more
contrived cleanup after the patch.
___
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: [PATCH 1/3] fork: assign refed credentials earlier

2015-03-21 Thread Mateusz Guzik 
On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote:
> On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote:
> > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote:
> > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote:
> > > > From: Mateusz Guzik 
> > > > 
> > > > Prior to this change the kernel would take p1's credentials and assign
> > > > them tempororarily to p2. But p1 could change credentials at that time
> > > > and in effect give us a use-after-free.
> > > In which way could it change the credentials ?  The assigned credentials
> > > are taken from td_ucred, which, I thought, are guaranteed to be stable
> > > for the duration of a syscall.
> > > 
> > 
> > It takes thread's credential in do_fork. But initial copy is taken
> > unlocked from struct proc.
> > 
> > Relevant part of the diff:
> > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, 
> > > > struct proc **procp,
> > > >  * XXX: This is ugly; when we copy resource usage, we need to 
> > > > bump
> > > >  *  per-cred resource counters.
> > > >  */
> > > > -   proc_set_cred(newproc, p1->p_ucred);
> > > > +   proc_set_cred(newproc, crhold(td->td_ucred));
> > > >  
> 
> I do not understand your note, nor I see the chunk above in the patches
> you send.  Below is the citation from the patch 1:
> 
> @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2,
>   
> +struct thread *td2,  
>   
> bzero(&p2->p_startzero,   
>   
> __rangeof(struct proc, p_startzero, p_endzero));  
>   
>   
>   
> -   crhold(td->td_ucred); 
>   
> -   proc_set_cred(p2, td->td_ucred);  
>   
> - 
>   

fork1 does:

proc_set_cred(newproc, p1->p_ucred);

p1 is unlocked, so whatever memory p1->p_ucred points to may already be
freed.

/*
 * Initialize resource accounting for the child process.
 */
error = racct_proc_fork(p1, newproc);
if (error != 0) {
error = EAGAIN;
goto fail1;
}

racct_proc_fork -> racct_add_locked results in accessing such
now-possibly-freed credentials.

do_fork which properly assigns credentials (from a stable source
(td_ucred) + grabs a reference) is called later.

The patch in question moves aforementioned assignent earlier to replace
unsafe one with p1->p_ucred.

-- 
Mateusz Guzik 
___
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: What's the official method to test the build now?

2015-03-21 Thread Garrett Cooper 

> On Mar 21, 2015, at 06:35, Ian Lepore  wrote:
> 
>> On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote:
>> "make tinderbox" has been broken for weeks, so I presume it's not what I'm
>> supposed to be using to test my commits anymore.  What's the officially
>> supported make target that I'm supposed to use?
> 
> I use "make universe", sometimes with the -DMAKE_JUST_KERNELS option.

make universe doesn't error out; make tinderbox does however.

> But the LINT kernels for x86 and sparc have been broken since January.

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

Build failed in Jenkins: FreeBSD_HEAD-tests2 #861

2015-03-21 Thread jenkins-admin 
See 

--
[...truncated 1078 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.014s]
lib/libc/string/swab:swab_basic  ->  passed  [0.015s]
lib/libc/sys/access_test:access_access  ->  passed  [0.019s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.015s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.015s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.015s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.015s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.014s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.018s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.015s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.016s]
lib/libc/sys/clock_gettime_test:clock_gettime_real  ->  passed  [0.016s]
lib/libc/sys/connect_test:connect_low_port  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.014s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.014s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.014s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.027s]
lib/libc/sys/dup_test:dup3_err  ->  passed  [0.013s]
lib/libc/sys/dup_test:dup3_max  ->  passed  [0.013s]
lib/libc/sys/dup_test:dup3_mode  ->  passed  [0.031s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.020s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.031s]
lib/libc/sys/fsync_test:fsync_err  ->  passed  [0.013s]
lib/libc/sys/fsync_test:fsync_sync  ->  passed  [2.014s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.016s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.014s]
lib/libc/sys/getcontext_test:setcontext_link  ->  passed  [0.013s]
lib/libc/sys/getgroups_test:getgroups_err  ->  expected_failure: Reported as 
kern/189941: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: 
getgroups(-1, gidset) == -1 not met  [0.014s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.014s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.015s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.013s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.013s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.013s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.014s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:setitimer_old  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.014s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.015s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.023s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.019s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.013s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.013s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.107s]
lib/libc/sys/getrusage_test:getrusage_utime_zero  ->  skipped: this testcase 
passes/fails sporadically on FreeBSD/i386 @ r273153 (at least)  [0.014s]
lib/libc/sys/getsid_test:getsid_current  ->  passed  [0.014s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.015s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.015s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.015s]
lib/libc/sys/gettimeofday_test:gettimeofday_mono  ->  passed  [0.015s]
lib/libc/sys/issetugid_test:issetugid_egid  ->  passed  [0.018s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.017s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.016s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.017s]
lib/libc/sys/kevent_test:kevent_zerotimer  ->  passed  [0.030s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.017s]
lib/libc/sys/kevent_test:kqueue_unsupported_fd  ->  skipped: no /nonexistent 
available for testing  [0.014s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.019s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.016s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.019s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.017s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.016s]
lib/libc/sys/link_test:link_count  ->  passed  [0.019s]
lib/libc/sys/link_test:link_err  ->  passed  [0.019s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.015s]
lib/libc/sys/link_test:link_stat  ->  passed  [0.020s]
lib/libc/sys/listen_test:listen_err  ->  passed  [0.018s]
lib/libc/sys/listen_test:listen_low_port  ->  passed  [0.014s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.015s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.039s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.018s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.016s]
lib/libc/sys/mkdi

Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Adrian Chadd 
Hi,

It may be rfkill then. It may be that there's a GPIO pin wired up
somewhere that needs updating. Erk.

Someone buy me one of these laptops so I can see what's going on? :)


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

Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Miguel Clara 
On Sat, Mar 21, 2015 at 8:17 AM, Anders Bolt-Evensen 
wrote:

> Do you mean to check dmesg -a while doing "vmstat -ia | grep ath0"?
> I did run "wlandebug +scan", then ifconfig wlan0 up scan and then "vmstat
> -ia | grep ath0".
> The only output I got from "vmstat -ia | grep ath0" is:
> irq18: ath021   0
> The second time I ran that last command I got
> irq18: ath0220
>
> It is worth mentioning that wifi with this Atheros card works just fine on
> Windows (I am using this wlan when typing this answer on Windows).
> There is a button that seems to enable airplane mode, but pressing this
> button does not seem to change anything as far as FreeBSD is concerned.
> Other than that button I can't find any button that enables or disables
> wifi.
>
>
> On 3/21/2015 5:22 AM, Kevin Oberman wrote:
>
>> On Fri, Mar 20, 2015 at 4:31 PM, Adrian Chadd  wrote:
>>
>>  Hm, ok. either interrupts aren't working, or the thing is deaf. :(
>>>
>>> can you do that and then in another screen run vmstat -ia | grep ath0 ?
>>>
>>> I'd like to see if it's at least posting interrupts.
>>>
>>>  Could a bad antenna connection (loose plug/broken conductor/pinch to
>> chassis shorting to ground) explain this? Or would the hardware notice and
>> report this in all cases?
>>
>
Guess it depends on the laptop model, on my acer I do have Fn-F3 (antena
icon) playing with with seems to have some effect:
ugen1.4:  at usbus1 (disconnected)
ugen1.4:  at usbus1

But I didn't loose connection.

If relevant:
ugen0.1:  at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=SAVE (0mA)
ugen1.1:  at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen2.1:  at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen0.2:  at usbus0, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON (100mA)
ugen1.2:  at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen2.2:  at usbus2, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.3: <1.3M HD WebCam SuYin> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=ON (500mA)
ugen1.3:  at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=ON (500mA)
ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)


--
>> Kevin Oberman, Network Engineer, Retired
>> E-mail: rkober...@gmail.com
>> ___
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
> ___
> 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: [PATCH 1/3] fork: assign refed credentials earlier

2015-03-21 Thread Konstantin Belousov 
On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote:
> On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote:
> > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote:
> > > From: Mateusz Guzik 
> > > 
> > > Prior to this change the kernel would take p1's credentials and assign
> > > them tempororarily to p2. But p1 could change credentials at that time
> > > and in effect give us a use-after-free.
> > In which way could it change the credentials ?  The assigned credentials
> > are taken from td_ucred, which, I thought, are guaranteed to be stable
> > for the duration of a syscall.
> > 
> 
> It takes thread's credential in do_fork. But initial copy is taken
> unlocked from struct proc.
> 
> Relevant part of the diff:
> > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct 
> > > proc **procp,
> > >* XXX: This is ugly; when we copy resource usage, we need to bump
> > >*  per-cred resource counters.
> > >*/
> > > - proc_set_cred(newproc, p1->p_ucred);
> > > + proc_set_cred(newproc, crhold(td->td_ucred));
> > >  

I do not understand your note, nor I see the chunk above in the patches
you send.  Below is the citation from the patch 1:

@@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2,  
+struct thread *td2,
bzero(&p2->p_startzero, 
__rangeof(struct proc, p_startzero, p_endzero));

-   crhold(td->td_ucred);   
-   proc_set_cred(p2, td->td_ucred);
-   
___
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: What's the official method to test the build now?

2015-03-21 Thread Ian Lepore 
On Fri, 2015-03-20 at 19:52 -0400, Ryan Stone wrote:
> "make tinderbox" has been broken for weeks, so I presume it's not what I'm
> supposed to be using to test my commits anymore.  What's the officially
> supported make target that I'm supposed to use?

I use "make universe", sometimes with the -DMAKE_JUST_KERNELS option.
But the LINT kernels for x86 and sparc have been broken since January.

-- Ian


___
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: What's the official method to test the build now?

2015-03-21 Thread Ryan Stone 
I still see the compile errors that I reported here:

https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054803.html

It affects these builds:

sparc64 LINT kernel failed, check _.sparc64.LINT for details
powerpc LINT kernel failed, check _.powerpc.LINT for details
powerpc LINT64 kernel failed, check _.powerpc.LINT64 for details
i386 LINT-NOINET kernel failed, check _.i386.LINT-NOINET for details
i386 LINT-NOINET6 kernel failed, check _.i386.LINT-NOINET6 for details
i386 LINT kernel failed, check _.i386.LINT for details
i386 LINT-NOIP kernel failed, check _.i386.LINT-NOIP for details
i386 LINT-VIMAGE kernel failed, check _.i386.LINT-VIMAGE for details
___
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: What parts of UMA are part of the stable ABI?

2015-03-21 Thread Ryan Stone 
I've put the full patch to convert uma_malloc and uma_free to accept a
vm_size_t up for review[1].  It ended up being more extensive than expected
as a fair number of places do use uma_set_allocf().  I do plan on MFC'ing
this patch.  This survive a make tinderbox (ignoring some vt-related LINT
kernel build failures)

I haven't attempted converting the uma ctors, etc over to vm_size_t yet,
but I do plan on doing that still.

[1] https://reviews.freebsd.org/D2106
___
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"

Build failed in Jenkins: FreeBSD_HEAD-tests2 #860

2015-03-21 Thread jenkins-admin 
See 

--
[...truncated 1289 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.014s]
lib/libc/string/swab:swab_basic  ->  passed  [0.015s]
lib/libc/sys/access_test:access_access  ->  passed  [0.018s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.015s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.015s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.013s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.014s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.014s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.017s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.014s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.014s]
lib/libc/sys/clock_gettime_test:clock_gettime_real  ->  passed  [0.014s]
lib/libc/sys/connect_test:connect_low_port  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.033s]
lib/libc/sys/dup_test:dup3_err  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup3_max  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup3_mode  ->  passed  [0.028s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.013s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.018s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.032s]
lib/libc/sys/fsync_test:fsync_err  ->  passed  [0.015s]
lib/libc/sys/fsync_test:fsync_sync  ->  passed  [0.037s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.013s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.014s]
lib/libc/sys/getcontext_test:setcontext_link  ->  passed  [0.016s]
lib/libc/sys/getgroups_test:getgroups_err  ->  expected_failure: Reported as 
kern/189941: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: 
getgroups(-1, gidset) == -1 not met  [0.015s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.015s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.017s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.014s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:setitimer_old  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.016s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.023s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.018s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.016s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.014s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.142s]
lib/libc/sys/getrusage_test:getrusage_utime_zero  ->  skipped: this testcase 
passes/fails sporadically on FreeBSD/i386 @ r273153 (at least)  [0.017s]
lib/libc/sys/getsid_test:getsid_current  ->  passed  [0.014s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.014s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.014s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.015s]
lib/libc/sys/gettimeofday_test:gettimeofday_mono  ->  passed  [0.016s]
lib/libc/sys/issetugid_test:issetugid_egid  ->  passed  [0.017s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.018s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.017s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.017s]
lib/libc/sys/kevent_test:kevent_zerotimer  ->  passed  [0.015s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.017s]
lib/libc/sys/kevent_test:kqueue_unsupported_fd  ->  skipped: no /nonexistent 
available for testing  [0.015s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.017s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.016s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.048s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.016s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.016s]
lib/libc/sys/link_test:link_count  ->  passed  [0.020s]
lib/libc/sys/link_test:link_err  ->  passed  [0.020s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.014s]
lib/libc/sys/link_test:link_stat  ->  passed  [0.019s]
lib/libc/sys/listen_test:listen_err  ->  passed  [0.020s]
lib/libc/sys/listen_test:listen_low_port  ->  passed  [0.015s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.016s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.031s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.016s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.014s]
lib/libc/sys/mkdi

Re: Use of chunksize before initialization

2015-03-21 Thread Ivan A. Kosarev 


On 03/21/2015 03:02 AM, Konstantin Belousov wrote:

On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote:

#12 0x0008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698
#13 malloc_init () at jemalloc_jemalloc.c:296
#14 0x000801243ea2 in ?? () from /lib/libc.so.7
#15 0x0008006a5400 in ?? ()
#16 0x00080089e5b0 in ?? () from /libexec/ld-elf.so.1
#17 0x7fffe0b0 in ?? ()
#18 0x000801139d06 in _init () from /lib/libc.so.7
#19 0x7fffe0b0 in ?? ()

The backtrace is strange.  Did you compiled malloc with the debugging
symbols, while keep rest of libc without -g ?


I've just added the -g flag to CC_FLAGS in the Makefile and made sure to 
install an unstripped version of the .so . I could investigate more on 
why the early calls omit debug symbols, if it does any matter.



Does it happen always, on only for the early initialization of the
mutexes ?


I'm not sure I understand the whole logic of the initialization process, 
but we could put a statement initializing the chunksize variable to 0 to 
the beginning of malloc_init_hard() and see if the assertion (or any 
other before it) fails. Since my suspicion is that the variable get 
random values at base_boot(), the presence of the failure depends on 
random factors. For a simple one-line program calling malloc() it is 
known to not to fail, of course. I should be able to to more tests on Mon.



   It might be related to r276630.  Can you test on, say, 10.1 ?


The Tsan tests mentioned below that cause mass (alignment != 0) failures 
are known to work fine on 10.1.



: jemalloc_chunk.c:152: Failed assertion: "alignment != 0"

Here's more of failures of this kind around:

http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd/builds/4758/steps/make-check-tsan/logs/stdio

Can you please let me know if the analysis is correct and there's
something to fix about initialization of the variable?

Backtrace looks valid.


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: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working

2015-03-21 Thread Anders Bolt-Evensen 

Do you mean to check dmesg -a while doing "vmstat -ia | grep ath0"?
I did run "wlandebug +scan", then ifconfig wlan0 up scan and then 
"vmstat -ia | grep ath0".

The only output I got from "vmstat -ia | grep ath0" is:
irq18: ath021   0
The second time I ran that last command I got
irq18: ath0220

It is worth mentioning that wifi with this Atheros card works just fine 
on Windows (I am using this wlan when typing this answer on Windows).
There is a button that seems to enable airplane mode, but pressing this 
button does not seem to change anything as far as FreeBSD is concerned. 
Other than that button I can't find any button that enables or disables 
wifi.


On 3/21/2015 5:22 AM, Kevin Oberman wrote:

On Fri, Mar 20, 2015 at 4:31 PM, Adrian Chadd  wrote:


Hm, ok. either interrupts aren't working, or the thing is deaf. :(

can you do that and then in another screen run vmstat -ia | grep ath0 ?

I'd like to see if it's at least posting interrupts.


Could a bad antenna connection (loose plug/broken conductor/pinch to
chassis shorting to ground) explain this? Or would the hardware notice and
report this in all cases?
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

Build failed in Jenkins: FreeBSD_HEAD-tests2 #859

2015-03-21 Thread jenkins-admin 
See 

--
[...truncated 2595 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.149s]
lib/libc/string/swab:swab_basic  ->  passed  [0.209s]
lib/libc/sys/access_test:access_access  ->  passed  [0.482s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.170s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.187s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.947s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.146s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.242s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.584s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.163s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.198s]
lib/libc/sys/clock_gettime_test:clock_gettime_real  ->  passed  [0.236s]
lib/libc/sys/connect_test:connect_low_port  ->  passed  [0.231s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.294s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.175s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.177s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.349s]
lib/libc/sys/dup_test:dup3_err  ->  passed  [0.171s]
lib/libc/sys/dup_test:dup3_max  ->  passed  [0.138s]
lib/libc/sys/dup_test:dup3_mode  ->  passed  [0.965s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.476s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.245s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.346s]
lib/libc/sys/fsync_test:fsync_err  ->  passed  [0.678s]
lib/libc/sys/fsync_test:fsync_sync  ->  passed  [0.985s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.164s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.145s]
lib/libc/sys/getcontext_test:setcontext_link  ->  passed  [0.175s]
lib/libc/sys/getgroups_test:getgroups_err  ->  expected_failure: Reported as 
kern/189941: 
/builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/sys/t_getgroups.c:63: 
getgroups(-1, gidset) == -1 not met  [0.312s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.300s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.205s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.150s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.642s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.331s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.235s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.253s]
lib/libc/sys/getitimer_test:setitimer_old  ->  passed  [0.234s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.113s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.141s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.187s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.099s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.106s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.078s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.076s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.255s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.134s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.538s]
lib/libc/sys/getrusage_test:getrusage_utime_zero  ->  skipped: this testcase 
passes/fails sporadically on FreeBSD/i386 @ r273153 (at least)  [0.146s]
lib/libc/sys/getsid_test:getsid_current  ->  passed  [0.241s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.345s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.216s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.178s]
lib/libc/sys/gettimeofday_test:gettimeofday_mono  ->  passed  [0.212s]
lib/libc/sys/issetugid_test:issetugid_egid  ->  passed  [0.139s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.157s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.168s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.110s]
lib/libc/sys/kevent_test:kevent_zerotimer  ->  passed  [0.112s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.193s]
lib/libc/sys/kevent_test:kqueue_unsupported_fd  ->  skipped: no /nonexistent 
available for testing  [0.134s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.177s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.220s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.467s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.453s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.203s]
lib/libc/sys/link_test:link_count  ->  passed  [0.485s]
lib/libc/sys/link_test:link_err  ->  passed  [0.226s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.141s]
lib/libc/sys/link_test:link_stat  ->  passed  [0.262s]
lib/libc/sys/listen_test:listen_err  ->  passed  [0.108s]
lib/libc/sys/listen_test:listen_low_port  ->  passed  [0.143s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.086s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.143s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.136s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.169s]
lib/libc/sys/mkdi