`SA_SIGINFO | SA_RESETHAND` fix backport (DUP)

[Fedor Indutny]

Hello people!

While trying to fix node.js/io.js issue with signal handling
on FreeBSD 10.1, I have found that the problem was due to a kernel
bug. Luckily that bug is fixed in:

https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451

But it looks like the fix wasn't backported to 10.x .

Do you think it might be possible to do it? I'd really appreciate
this.

Thank you,
Fedor.

P.S.

Sent the duplicate of this before, but I wasn't on the mailing list so
it fell into the moderation list.
___
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"

clang/tblgen: undefined reference to `futimens' c++: error: linker command failed with exit

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Running 

11.0-CURRENT FreeBSD 11.0-CURRENT #2 r277382: Mon Jan 19 16:10:34 CET 2015
amd64

with source tree at revision 
>>> Updating /usr/src using Subversion
- --
Updating '.':
At revision 280275.

and "make buildorld buildkernel"

fails at the below shown point.

The /usr/obj tree is clean - I delete it prior to each build run.

Something is out of sync, sn earlier update process (make installworld) crashed
and I think the kernel, binary tools and rest of sources are some kind of out
of sync.

Is there a way - from the data shown - to resolve the problem?

Building a kernel works great, building toolchains fail also at the very same
point.

Thanks in advance,

oh


[...]
- --- _bootstrap-tools-usr.bin/clang/tblgen ---
- --- TableGen.o ---
c++ -O2 -pipe -O3 -pipe -O3
- -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include
- -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include
- -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I.
- -I/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-freebsd11.0\"
- -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
- -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11
- -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions
- -c 
/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/TableGen.cpp
- -o TableGen.o --- _bootstrap-tools-usr.bin/clang/clang-tblgen
- --- 
/usr/obj/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a(Path.o):
In function `llvm::sys::fs::setLastModificationAndAccessTime(int,
llvm::sys::TimeValue)': 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Path.cpp:(.text+0x4649):
undefined reference to `futimens' c++: error: linker command failed with exit
code 1 (use -v to see invocation) *** [clang-tblgen] Error code 1

make[3]: stopped in /usr/src/usr.bin/clang/clang-tblgen
1 error
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVC81iAAoJEOgBcD7A/5N8CZQH/2OtsoPpelRtP23wOZ/+5/9i
26jz657xPpDjkB61TccUjo3iodC5Rz63ASHpxEEPwEU5BiMBI46AieFIhY41uL4Y
KwXX0PewUSpiltJgNMDp6Fbt2NI5G5QC1Ih/Zkd8dZpMWIdYtvkg2KZmnapiaBuP
KFhuqb3iFhka8GjlJdIlbaWmgzTuuz8fB9l8oGKhObpP0H9TBIBunEgSp65moMHU
KtZigU7zmeBGxREkq2hBEx5WDLj98baziuotDASkeCJKI+T3CB/dLkLzLzudPfn6
k/uApTU9PZU2+PCRkJHznNuUr6M8KkNLUANmRg/V7IsUNxG9PzCdG6ISzuv8GCE=
=IVb6
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: FreeBSD_HEAD-tests2 #855

[jenkins-admin]

See 

--
[...truncated 3430 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.016s]
lib/libc/string/swab:swab_basic  ->  passed  [0.016s]
lib/libc/sys/access_test:access_access  ->  passed  [0.020s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.016s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.016s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.016s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.016s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.015s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.386s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.014s]
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.017s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.016s]
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.017s]
lib/libc/sys/dup_test:dup3_max  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup3_mode  ->  passed  [0.032s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.020s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.034s]
lib/libc/sys/fsync_test:fsync_err  ->  passed  [0.016s]
lib/libc/sys/fsync_test:fsync_sync  ->  passed  [0.311s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.017s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.015s]
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.016s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.014s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.017s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.016s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.016s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.016s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.017s]
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.016s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.017s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.017s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.017s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.025s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.020s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.016s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.016s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.097s]
lib/libc/sys/getrusage_test:getrusage_utime_zero  ->  skipped: this testcase 
passes/fails sporadically on FreeBSD/i386 @ r273153 (at least)  [0.016s]
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.016s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.014s]
lib/libc/sys/gettimeofday_test:gettimeofday_mono  ->  passed  [0.015s]
lib/libc/sys/issetugid_test:issetugid_egid  ->  passed  [0.019s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.018s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.019s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.019s]
lib/libc/sys/kevent_test:kevent_zerotimer  ->  passed  [0.018s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.019s]
lib/libc/sys/kevent_test:kqueue_unsupported_fd  ->  skipped: no /nonexistent 
available for testing  [0.016s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.018s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.017s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.067s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.019s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.017s]
lib/libc/sys/link_test:link_count  ->  passed  [0.023s]
lib/libc/sys/link_test:link_err  ->  passed  [0.021s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.017s]
lib/libc/sys/link_test:link_stat  ->  passed  [0.021s]
lib/libc/sys/listen_test:listen_err  ->  passed  [0.020s]
lib/libc/sys/listen_test:listen_low_port  ->  passed  [0.017s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.017s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.041s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.019s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.017s]
lib/libc/sys/mkdi

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

[Konstantin Belousov]

On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote:
> On Fri, Mar 20, 2015 at 02:08:23AM +, jenkins-ad...@freebsd.org wrote:
> > lib/libc/sys/setrlimit_test:setrlimit_nproc  ->  maxproc limit exceeded by 
> > uid 977 (pid 29170); see tuning(7) and login.conf(5)
> > passed  [0.551s]
> > 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 
> > 0xfe009749a8e0
> > vpanic() at vpanic+0x189/frame 0xfe009749a960
> > panic() at panic+0x43/frame 0xfe009749a9c0
> > __mtx_assert() at __mtx_assert+0xc2/frame 0xfe009749a9d0
> > proc_set_cred() at proc_set_cred+0x36/frame 0xfe009749a9f0
> > fork1() at fork1+0x27e/frame 0xfe009749aac0
> > sys_fork() at sys_fork+0x1f/frame 0xfe009749aae0
> > amd64_syscall() at amd64_syscall+0x27f/frame 0xfe009749abf0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe009749abf0
> > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 
> > 0x7fffc2d8, rbp = 0x7fffc340 ---
> > KDB: enter: panic
> > [ thread pid 660 tid 100065 ]
> > Stopped at  kdb_enter+0x3e: movq$0,kdb_why
> 
> Weird, I'll look at that.

This is due to p_ucred not initialized on allocation of struc proc.
The member is not in p_startzero/p_endzero region, so it contains
garbage at the stage of the fork where proc_set_cred() is called,
while the function makes assertion based on the p_ucred content.
___
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 #854

[Mateusz Guzik]

On Fri, Mar 20, 2015 at 11:34:51AM +0200, Konstantin Belousov wrote:
> On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote:
> > On Fri, Mar 20, 2015 at 02:08:23AM +, jenkins-ad...@freebsd.org wrote:
> > > lib/libc/sys/setrlimit_test:setrlimit_nproc  ->  maxproc limit exceeded 
> > > by uid 977 (pid 29170); see tuning(7) and login.conf(5)
> > > passed  [0.551s]
> > > 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 
> > > 0xfe009749a8e0
> > > vpanic() at vpanic+0x189/frame 0xfe009749a960
> > > panic() at panic+0x43/frame 0xfe009749a9c0
> > > __mtx_assert() at __mtx_assert+0xc2/frame 0xfe009749a9d0
> > > proc_set_cred() at proc_set_cred+0x36/frame 0xfe009749a9f0
> > > fork1() at fork1+0x27e/frame 0xfe009749aac0
> > > sys_fork() at sys_fork+0x1f/frame 0xfe009749aae0
> > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfe009749abf0
> > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe009749abf0
> > > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 
> > > 0x7fffc2d8, rbp = 0x7fffc340 ---
> > > KDB: enter: panic
> > > [ thread pid 660 tid 100065 ]
> > > Stopped at  kdb_enter+0x3e: movq$0,kdb_why
> > 
> > Weird, I'll look at that.
> 
> This is due to p_ucred not initialized on allocation of struc proc.
> The member is not in p_startzero/p_endzero region, so it contains
> garbage at the stage of the fork where proc_set_cred() is called,
> while the function makes assertion based on the p_ucred content.

Yes I figured, but proc_init left me quite puzzled:

static int
proc_init(void *mem, int size, int flags)
{
struct proc *p;

p = (struct proc *)mem;
SDT_PROBE(proc, kernel, init, entry, p, size, flags, 0, 0);
p->p_sched = (struct p_sched *)&p[1];
bzero(&p->p_mtx, sizeof(struct mtx));
mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK);

We bzero only the first mutex to make sure mtx_init works?

mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN);
mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN);
mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN);
mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN);

How about these?

So the trivial fix would be to move p_ucred or explicitely NULL it here.

All these mtx_init calls would use MTX_NEW flag and bzero could be
eliminated.

I'll commit a quick fix shortly.

I'm really confused what's the purpose of checking for double
initialisation of locks. I'm not aware of any actual bug caught by this,
on the other hand I'm aware of quite a few cases where bzero or M_ZERO
were used just to make sure mtx_init passes.

So preferably I would just get rid of such a check and effectively make
the behaviour as if MTX_NEW is always used.

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

SA_SIGINFO | SA_RESETHAND fix backport

[Fedor Indutny]

Hello people!

While trying to fix node.js/io.js issue with signal handling
on FreeBSD 10.1, I have found that the problem was due to a kernel
bug. Luckily that bug is fixed in:

https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451

But it looks like the fix wasn't backported to 10.x .

Do you think it might be possible to do it? I'd really appreciate
this.

Thank you,
Fedor.
___
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 #854

[Konstantin Belousov]

On Fri, Mar 20, 2015 at 10:52:06AM +0100, Mateusz Guzik wrote:
> On Fri, Mar 20, 2015 at 11:34:51AM +0200, Konstantin Belousov wrote:
> > On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote:
> > > On Fri, Mar 20, 2015 at 02:08:23AM +, jenkins-ad...@freebsd.org wrote:
> > > > lib/libc/sys/setrlimit_test:setrlimit_nproc  ->  maxproc limit exceeded 
> > > > by uid 977 (pid 29170); see tuning(7) and login.conf(5)
> > > > passed  [0.551s]
> > > > 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 
> > > > 0xfe009749a8e0
> > > > vpanic() at vpanic+0x189/frame 0xfe009749a960
> > > > panic() at panic+0x43/frame 0xfe009749a9c0
> > > > __mtx_assert() at __mtx_assert+0xc2/frame 0xfe009749a9d0
> > > > proc_set_cred() at proc_set_cred+0x36/frame 0xfe009749a9f0
> > > > fork1() at fork1+0x27e/frame 0xfe009749aac0
> > > > sys_fork() at sys_fork+0x1f/frame 0xfe009749aae0
> > > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfe009749abf0
> > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe009749abf0
> > > > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 
> > > > 0x7fffc2d8, rbp = 0x7fffc340 ---
> > > > KDB: enter: panic
> > > > [ thread pid 660 tid 100065 ]
> > > > Stopped at  kdb_enter+0x3e: movq$0,kdb_why
> > > 
> > > Weird, I'll look at that.
> > 
> > This is due to p_ucred not initialized on allocation of struc proc.
> > The member is not in p_startzero/p_endzero region, so it contains
> > garbage at the stage of the fork where proc_set_cred() is called,
> > while the function makes assertion based on the p_ucred content.
> 
> Yes I figured, but proc_init left me quite puzzled:
> 
> static int
> proc_init(void *mem, int size, int flags)
> {
>   struct proc *p;
> 
>   p = (struct proc *)mem;
>   SDT_PROBE(proc, kernel, init, entry, p, size, flags, 0, 0);
>   p->p_sched = (struct p_sched *)&p[1];
>   bzero(&p->p_mtx, sizeof(struct mtx));
>   mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK);
> 
> We bzero only the first mutex to make sure mtx_init works?
> 
>   mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN);
>   mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN);
>   mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN);
>   mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN);
> 
> How about these?
> 
> So the trivial fix would be to move p_ucred or explicitely NULL it here.
> 
> All these mtx_init calls would use MTX_NEW flag and bzero could be
> eliminated.
It is self-contradicional to initialize p_ucred to pacify assertion,
while removing bzero to avoid doing extra work to silence too eager
assert.

> 
> I'll commit a quick fix shortly.
> 
> I'm really confused what's the purpose of checking for double
> initialisation of locks. I'm not aware of any actual bug caught by this,
> on the other hand I'm aware of quite a few cases where bzero or M_ZERO
> were used just to make sure mtx_init passes.
There were bugs catched by this.

> 
> So preferably I would just get rid of such a check and effectively make
> the behaviour as if MTX_NEW is always used.
___
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"

cant use Xorg after r277486 on Asus Zenbook

[Stefan Parvu]

Hi,

Im currently running 11.0-CURRENT #0 r277486 on Asus Zenbook laptop [1].

Im happy, there are some issues with iwn driver but it does work enough stable.
Xorg, Sound, Networking functional. Even power management works enough
decent to get 3hrs or so without a power adapter connected.

Now I have discovered Im not able to update to any new snapshots after
r277486. Xorg refuses to work, Im getting a blank screen with no possibility to
have a functional vt restoration. I always need to reboot. The kernel is up
I can use the keyboard so the only trouble seems to come from Xorg / vt.

I have tried updating my laptop to: r278452, r278908, r279514, r279813.
No luck.  If I go back to use r277486 then my Xorg and vt start functioning 
correctly. Im using the i915 driver for Xorg and my config is in [1]. 

Any ideas what is this about ? Were any changes after r277486 regarding 
i915 or Xorg ? I tried to create a new xorg.conf, reuse the old one whatever.
No luck.


Many thanks,

-- 
Stefan Parvu 


[1] - http://kronometrix.blogspot.fi/2014/10/asus-zenbook-and-freebsd-11.html
___
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"

Use of chunksize before initialization

[Ivan A. Kosarev]

Hello everybody,

The malloc_init_hard() function defined in jemalloc_jemalloc.c, FreeBSD 
11 r277486 reads:


static bool
malloc_init_hard(void)
{
...
if (base_boot()) {
malloc_mutex_unlock(&init_lock);
eturn (true);
}

if (chunk_boot()) {
malloc_mutex_unlock(&init_lock);
return (true);
}
...

The second call initializes the 'chunksize' global variable defined in 
jemalloc_chunk.c:


bool
chunk_boot(void)
{
/* Set variables according to the value of opt_lg_chunk. */
chunksize = (ZU(1) << opt_lg_chunk);
assert(chunksize >= PAGE);
...

However, it seems the first call to base_boot() depends on that variable 
already:


(gdb) bt
#0  thr_kill () at thr_kill.S:3
#1  0x000801241408 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:51
#2  0x0041d817 in __interceptor_raise () at 
/usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:2097

#3  0x00080123f969 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#4  0x0041c5d9 in __interceptor_abort () at 
/usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1851
#5  0x0008011a8d64 in __je_chunk_alloc (size=, 
alignment=, base=, zero=,

dss_prec=dss_prec_disabled) at jemalloc_chunk.c:150
#6  0x0008011a9bfc in base_pages_alloc (minsize=128) at 
jemalloc_base.c:35

#7  __je_base_alloc (size=) at jemalloc_base.c:57
#8  0x0008011a9c96 in __je_base_calloc (number=, 
size=6) at jemalloc_base.c:74
#9  0x0008008ae548 in mutex_init (calloc_cb=0x0, mutex=out>, mutex_attr=) at 
/usr/src/lib/libthr/thread/thr_mutex.c:145
#10 _pthread_mutex_init_calloc_cb (mutex=0x801487c90, calloc_cb=0x0) at 
/usr/src/lib/libthr/thread/thr_mutex.c:229
#11 0x0008011a18da in __je_malloc_mutex_init (mutex=0x18744) at 
jemalloc_mutex.c:97

#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 ?? ()

Note that base_pages() calls chunk_alloc() with chucksize used as the 
alignment value:


static bool
base_pages_alloc(size_t minsize)
{
...
base_pages = chunk_alloc(csize, chunksize, true, &zero,
chunk_dss_prec_get());
...

and the latter tests it against zero:

void *
chunk_alloc(size_t size, size_t alignment, bool base, bool *zero,
dss_prec_t dss_prec)
{
...
assert(alignment != 0);


so we sometimes we end up with:

: 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?


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: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

[Miguel Clara]

On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper 
wrote:

>
> On Feb 25, 2015, at 18:08, Kevin Oberman  wrote:
>
> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper 
> wrote:
>
>> On Feb 25, 2015, at 14:19, Miguel Clara  wrote:
>>
>> ...
>>
>> > I noticed this too, but in that case why doesn't it affect all users?
>> (or all the ones using dnscrypt+local_unbound) maybe something changed in
>> "NETWORKING" recently?
>> >
>> > Hum:
>> >
>> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704
>> >
>> > Interesting, as I am using the most recent version which does not
>> REQUIRE local_unbound
>> >
>> > I'm even more confused now :|
>> >
>> >
>> > So it has to come after SERVERS but before local_unbound. But
>> NETWORKING depends on local_unbound they are both dependent on NEWORKING
>> which has to be after SERVERS. Can you say fubar! Clearly broken. And this
>> means that removing SERVERS will re-shuffle the order more appropriately.
>> >
>> > It seems that the behavior of rcorder is not as documented as well as
>> being undefined when circular dependencies occur. The man page says that
>> rcorder aborts when it encounters a circular dependency, but that is not
>> the case. It probably is best that it not die, but that leaves things in an
>> unknown and inconsistant state, which is also a very bad idea. I guess when
>> a circular dependency is encountered, a dichotomy occurs.
>>
>> Now you know why I’m so curious about all of this stuff.
>>
>> When I was working on ^/projects/building-blocks, I was able to move most
>> of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that
>> it changes the rcorder a bit, so I haven’t been super gung ho in
>> implementing my change.
>>
>> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT:
>>
>> - Things go awry if named is removed/not installed.
>> - Things go awry if local_unbound is removed (which would have been the
>> case if the rc.d script was removed from your system, which existed before
>> my changes).
>> - Other rc.d scripts not being present might break assumptions.
>>
>> I need to create dummy providers for certain logical stages (DNS is one
>> of them) to solve part of this problem and provide third parties with a
>> mechanism that can be depended on (I wish applications were written in a
>> more robust manner to fail gracefully and retry instead of failing flat on
>> their face, but as I’ve seen at several jobs, getting developers to fail,
>> then retry is hard :(…).
>>
>> Another short-term hack:
>>
>> Install dummy/no-op providers so the ordering is preserved, then remove
>> the hacks after all of the bugs have been shaken out.
>>
>> Thanks!
>>
>
> Garret,
>
> Also undocumented (except in rcorder.c) is that the lack of a provider is
> not an error. This effectively makes a list of providers into an OR. So,
> for name service the normal list is "named local_unbound unbound" and any
> will work for ordering and having none is a no-op, so if you don't run any
> nameserver (or kerberos or whatever provider), it is not an issue. As long
> as rcorder finds a provider, it will be used to set the order, but the lack
> of any or all providers just means that the specified provider is ignored
> and if a REQUIRES or BEFORE lists no existing providers, the statement is
> simply ignored.
>
> The real problem is that there is no defined rule for behavior in the
> event of a circular dependency and any change to any decision point in the
> ordering process may change the way the ordering flips. That is why these
> things are such a royal pain to debug. A change in any rc.d script may
> cause the ordering of seemingly unrelated scripts to change, perhaps
> drastically, and the error messages, while not misleading, is only a
> starting point in tracking this down. This means there may be time bombs
> that break working ports without their being touched or even re-installed.
> And the triggering change my, itself be correct.
>
>
> Or etc/rc.d/named...
>
> PROVIDES: DNS
>
> I'm going to post a fix up for this on arch@/rc@ because it needs to be
> solved in a saner way -- especially for systems that are pedantic about
> rcorder, like our version at $work.
>
>
I re-sync my source and noticed the change while doing the mergemaster
part... with this I can now change dnscrypt to:

@@ -4,7 +4,7 @@
 #
 # PROVIDE: dnscrypt_proxy
 # REQUIRE: SERVERS cleanvar
-# BEFORE: named local_unbound unbound
+# BEFORE: DNS

And this makes the rcorder ok for dnscrypt-proxy
___
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: SA_SIGINFO | SA_RESETHAND fix backport

[Allan Jude]

On 2015-03-20 01:00, Fedor Indutny wrote:
> Hello people!
> 
> While trying to fix node.js/io.js issue with signal handling
> on FreeBSD 10.1, I have found that the problem was due to a kernel
> bug. Luckily that bug is fixed in:
> 
> https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451
> 
> But it looks like the fix wasn't backported to 10.x .
> 
> Do you think it might be possible to do it? I'd really appreciate
> this.
> 
> Thank you,
> Fedor.
> ___
> 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"
> 

That change was merged to the stable/10 branch in December

https://svnweb.freebsd.org/base?view=revision&revision=275456

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: SA_SIGINFO | SA_RESETHAND fix backport

[Fedor Indutny]

Allan,

Thank you for reply! And sorry, I didn't seen it.

How long do you think it may take to get it released and will it be
included in 10.2?

Thank you,
Fedor.

On Friday, March 20, 2015, Allan Jude  wrote:

> On 2015-03-20 01:00, Fedor Indutny wrote:
> > Hello people!
> >
> > While trying to fix node.js/io.js issue with signal handling
> > on FreeBSD 10.1, I have found that the problem was due to a kernel
> > bug. Luckily that bug is fixed in:
> >
> >
> https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451
> >
> > But it looks like the fix wasn't backported to 10.x .
> >
> > Do you think it might be possible to do it? I'd really appreciate
> > this.
> >
> > Thank you,
> > Fedor.
> > ___
> > 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 "
> >
>
> That change was merged to the stable/10 branch in December
>
> https://svnweb.freebsd.org/base?view=revision&revision=275456
>
> --
> Allan Jude
>
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SA_SIGINFO | SA_RESETHAND fix backport

[Allan Jude]

On 2015-03-20 12:14, Fedor Indutny wrote:
> Allan,
> 
> Thank you for reply! And sorry, I didn't seen it.
> 
> How long do you think it may take to get it released and will it be
> included in 10.2?
> 
> Thank you,
> Fedor.
> 
> On Friday, March 20, 2015, Allan Jude  wrote:
> 
>> On 2015-03-20 01:00, Fedor Indutny wrote:
>>> Hello people!
>>>
>>> While trying to fix node.js/io.js issue with signal handling
>>> on FreeBSD 10.1, I have found that the problem was due to a kernel
>>> bug. Luckily that bug is fixed in:
>>>
>>>
>> https://github.com/freebsd/freebsd/commit/4501dadd00cece6d06392c42e5fc6af07731e451
>>>
>>> But it looks like the fix wasn't backported to 10.x .
>>>
>>> Do you think it might be possible to do it? I'd really appreciate
>>> this.
>>>
>>> Thank you,
>>> Fedor.
>>> ___
>>> 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 "
>>>
>>
>> That change was merged to the stable/10 branch in December
>>
>> https://svnweb.freebsd.org/base?view=revision&revision=275456
>>
>> --
>> Allan Jude
>>
>>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

It will be included in 10.2 yes. However you can run 10-stable to get
the fix today

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html#stable

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Build failed in Jenkins: FreeBSD_HEAD-tests2 #856

[jenkins-admin]

See 

--
[...truncated 3009 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.015s]
lib/libc/string/swab:swab_basic  ->  passed  [0.016s]
lib/libc/sys/access_test:access_access  ->  passed  [0.020s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.016s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.016s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.016s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.016s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.015s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.022s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.016s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.017s]
lib/libc/sys/clock_gettime_test:clock_gettime_real  ->  passed  [0.017s]
lib/libc/sys/connect_test:connect_low_port  ->  passed  [0.018s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.016s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.034s]
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.029s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.015s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.021s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.034s]
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.014s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.016s]
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.016s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.016s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.017s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.016s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.016s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.016s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.015s]
lib/libc/sys/getitimer_test:setitimer_old  ->  passed  [0.014s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.016s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.017s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.017s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.017s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.025s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.019s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.016s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.016s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.137s]
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.015s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.015s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.016s]
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.019s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.019s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.019s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.018s]
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.016s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.018s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.015s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.073s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.018s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.018s]
lib/libc/sys/link_test:link_count  ->  passed  [0.022s]
lib/libc/sys/link_test:link_err  ->  passed  [0.022s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.016s]
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.015s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.015s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.038s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.017s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.015s]
lib/libc/sys/mkdi

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

[Anders Bolt-Evensen]

Hello!

Recently I had to buy a new computer as my Mac broke down.
I ended up with an Acer Aspire V17 Nitro, which, except for a couple of 
problems, is all good.
One of the problems is that wifi does not work. The wifi driver is an 
Atheros AR9460.
The problem is that when I attempt to scan for my wireless network, 
nothing shows up at all.
On my previous computer, where I used an external Atheros card, 
everything worked well.

Could the following line from dmesg be a symptom of my problems?
"ath0: 2GHz radio: 0x; 5GHz radio: 0x"

I'm using FreeBSD 11-CURRENT with sources updated today.

Hope you can help me, and thanks in advance.

A zip file, ath_error.zip should be attached. If not, it is available here:
https://www.dropbox.com/s/jfcjam3m63cmbcv/ath_error.zip?dl=0

Have a nice day, everyone.
___
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

[Adrian Chadd]

On 20 March 2015 at 09:52, Anders Bolt-Evensen  wrote:
> Hello!
>
> Recently I had to buy a new computer as my Mac broke down.
> I ended up with an Acer Aspire V17 Nitro, which, except for a couple of
> problems, is all good.
> One of the problems is that wifi does not work. The wifi driver is an
> Atheros AR9460.
> The problem is that when I attempt to scan for my wireless network, nothing
> shows up at all.
> On my previous computer, where I used an external Atheros card, everything
> worked well.
> Could the following line from dmesg be a symptom of my problems?
> "ath0: 2GHz radio: 0x; 5GHz radio: 0x"
>
> I'm using FreeBSD 11-CURRENT with sources updated today.


What else does it log?


-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

[Miguel Clara]

On Fri, Mar 20, 2015 at 6:01 PM, Adrian Chadd  wrote:

> On 20 March 2015 at 09:52, Anders Bolt-Evensen 
> wrote:
> > Hello!
> >
> > Recently I had to buy a new computer as my Mac broke down.
> > I ended up with an Acer Aspire V17 Nitro, which, except for a couple of
> > problems, is all good.
> > One of the problems is that wifi does not work. The wifi driver is an
> > Atheros AR9460.
> > The problem is that when I attempt to scan for my wireless network,
> nothing
> > shows up at all.
> > On my previous computer, where I used an external Atheros card,
> everything
> > worked well.
> > Could the following line from dmesg be a symptom of my problems?
> > "ath0: 2GHz radio: 0x; 5GHz radio: 0x"
> >
> > I'm using FreeBSD 11-CURRENT with sources updated today.
>
>
> What else does it log?
>

I have this same card on a acer s3 (utltrabook)

@adrian this is the one I reported the performance issues but now seems to
be working ok.

For the record this is with --> r280273

commit d7efe7e99e68d52fa754f4e935814c492d818ece
Author: pfg 
Date:   Fri Mar 20 01:07:48 2015 +

Permit multiple arguments for the nonnull attribute.

This is very useful for non-trivial functions and doesn't
affect existing uses.

MFC after:  5 days

Notes:
svn path=/head/; revision=280273


I'm noticing something wron with "ifconfig scan" too, it listed fine as a
normal user, but that's not really re-scanning...

% ifconfig wlan0 scan
SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
   *:1c:681   54M -93:-96  100 EP   RSN HTCAP WPS WPA WME
   *:13:c06   54M -80:-96  100 EP   RSN HTCAP WPS WME
   *:e2:0c6   54M -83:-96  100 EP   RSN HTCAP WME
  *:f7:8c6   54M -109:-96  100 EP   RSN HTCAP WPS WPA WME
   *:4a:12   11   54M -91:-96  100 EP   RSN HTCAP WPS WPA WME
  *:13:c4   48   54M -80:-96  100 EP   RSN HTCAP WME

Trying with sudo gets in a hanged state...

[user@host:/usr/src ]% sudo ifconfig wlan0 scan
load: 0.17  cmd: ifconfig 11320 [sbwait] 35.72r 0.00u 0.00s 0% 2132k
load: 0.17  cmd: ifconfig 11320 [sbwait] 36.20r 0.00u 0.00s 0% 2132k
load: 0.19  cmd: ifconfig 11320 [sbwait] 187.79r 0.00u 0.00s 0% 2132k
load: 0.19  cmd: ifconfig 11320 [sbwait] 187.94r 0.00u 0.00s 0% 2132k
load: 0.19  cmd: ifconfig 11320 [sbwait] 188.08r 0.00u 0.00s 0% 2132k

^C

but after the ^C as a normal user again and:
ifconfig wlan0 scan
SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
*   *:1c:681   54M -94:-96  100 EP   RSN HTCAP WPS WPA WME
*   *:13:c06   54M -80:-96  100 EP   RSN HTCAP WPS WME
*   *:e2:0c6   54M -83:-96  100 EP   RSN HTCAP WME
*   *:f7:8c6   54M -130:-96  100 EP   RSN HTCAP WPS WPA WME
*   *:4a:121   54M -91:-96  100 EP   RSN HTCAP WPS WPA WME
*   *:13:c4   48   54M -80:-96  100 EP   RSN HTCAP WME
* ...   *:99:016   54M -96:-96  100 E  <--- This is new so it
re-scanned


I see nothing in dmesg


>
> -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"
>
___
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: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

[Kevin Oberman]

On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara 
wrote:

>
> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper 
> wrote:
>
>>
>> On Feb 25, 2015, at 18:08, Kevin Oberman  wrote:
>>
>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper 
>> wrote:
>>
>>> On Feb 25, 2015, at 14:19, Miguel Clara  wrote:
>>>
>>> ...
>>>
>>> > I noticed this too, but in that case why doesn't it affect all users?
>>> (or all the ones using dnscrypt+local_unbound) maybe something changed in
>>> "NETWORKING" recently?
>>> >
>>> > Hum:
>>> >
>>> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704
>>> >
>>> > Interesting, as I am using the most recent version which does not
>>> REQUIRE local_unbound
>>> >
>>> > I'm even more confused now :|
>>> >
>>> >
>>> > So it has to come after SERVERS but before local_unbound. But
>>> NETWORKING depends on local_unbound they are both dependent on NEWORKING
>>> which has to be after SERVERS. Can you say fubar! Clearly broken. And this
>>> means that removing SERVERS will re-shuffle the order more appropriately.
>>> >
>>> > It seems that the behavior of rcorder is not as documented as well as
>>> being undefined when circular dependencies occur. The man page says that
>>> rcorder aborts when it encounters a circular dependency, but that is not
>>> the case. It probably is best that it not die, but that leaves things in an
>>> unknown and inconsistant state, which is also a very bad idea. I guess when
>>> a circular dependency is encountered, a dichotomy occurs.
>>>
>>> Now you know why I’m so curious about all of this stuff.
>>>
>>> When I was working on ^/projects/building-blocks, I was able to move
>>> most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed
>>> that it changes the rcorder a bit, so I haven’t been super gung ho in
>>> implementing my change.
>>>
>>> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT:
>>>
>>> - Things go awry if named is removed/not installed.
>>> - Things go awry if local_unbound is removed (which would have been the
>>> case if the rc.d script was removed from your system, which existed before
>>> my changes).
>>> - Other rc.d scripts not being present might break assumptions.
>>>
>>> I need to create dummy providers for certain logical stages (DNS is one
>>> of them) to solve part of this problem and provide third parties with a
>>> mechanism that can be depended on (I wish applications were written in a
>>> more robust manner to fail gracefully and retry instead of failing flat on
>>> their face, but as I’ve seen at several jobs, getting developers to fail,
>>> then retry is hard :(…).
>>>
>>> Another short-term hack:
>>>
>>> Install dummy/no-op providers so the ordering is preserved, then remove
>>> the hacks after all of the bugs have been shaken out.
>>>
>>> Thanks!
>>>
>>
>> Garret,
>>
>> Also undocumented (except in rcorder.c) is that the lack of a provider is
>> not an error. This effectively makes a list of providers into an OR. So,
>> for name service the normal list is "named local_unbound unbound" and any
>> will work for ordering and having none is a no-op, so if you don't run any
>> nameserver (or kerberos or whatever provider), it is not an issue. As long
>> as rcorder finds a provider, it will be used to set the order, but the lack
>> of any or all providers just means that the specified provider is ignored
>> and if a REQUIRES or BEFORE lists no existing providers, the statement is
>> simply ignored.
>>
>> The real problem is that there is no defined rule for behavior in the
>> event of a circular dependency and any change to any decision point in the
>> ordering process may change the way the ordering flips. That is why these
>> things are such a royal pain to debug. A change in any rc.d script may
>> cause the ordering of seemingly unrelated scripts to change, perhaps
>> drastically, and the error messages, while not misleading, is only a
>> starting point in tracking this down. This means there may be time bombs
>> that break working ports without their being touched or even re-installed.
>> And the triggering change my, itself be correct.
>>
>>
>> Or etc/rc.d/named...
>>
>> PROVIDES: DNS
>>
>> I'm going to post a fix up for this on arch@/rc@ because it needs to be
>> solved in a saner way -- especially for systems that are pedantic about
>> rcorder, like our version at $work.
>>
>>
> I re-sync my source and noticed the change while doing the mergemaster
> part... with this I can now change dnscrypt to:
>
> @@ -4,7 +4,7 @@
>  #
>  # PROVIDE: dnscrypt_proxy
>  # REQUIRE: SERVERS cleanvar
> -# BEFORE: named local_unbound unbound
> +# BEFORE: DNS
>
> And this makes the rcorder ok for dnscrypt-proxy
>

This is still broken and only works by random luck. At this time there
appears to be nothing providing DNS. At least the default
/etc/rc.d/local_unbound does not.nor does anything else in /etc/rc.d. It
looks like this change effectively removes all BEFORE constraints, so it
may start any ti

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

[Adrian Chadd]

compile in IEEE80211_DEBUG, then "wlandebug +scan", then do the scan.

I wonder if you're hitting some scan bug where the sheer amount of
traffic going on is causing problems.

Also, seeing RX'ed frames at -130dB is .. oddly wrong for this NIC.
Something odd is going on.


-a


On 20 March 2015 at 11:21, Miguel Clara  wrote:
>
> On Fri, Mar 20, 2015 at 6:01 PM, Adrian Chadd  wrote:
>>
>> On 20 March 2015 at 09:52, Anders Bolt-Evensen 
>> wrote:
>> > Hello!
>> >
>> > Recently I had to buy a new computer as my Mac broke down.
>> > I ended up with an Acer Aspire V17 Nitro, which, except for a couple of
>> > problems, is all good.
>> > One of the problems is that wifi does not work. The wifi driver is an
>> > Atheros AR9460.
>> > The problem is that when I attempt to scan for my wireless network,
>> > nothing
>> > shows up at all.
>> > On my previous computer, where I used an external Atheros card,
>> > everything
>> > worked well.
>> > Could the following line from dmesg be a symptom of my problems?
>> > "ath0: 2GHz radio: 0x; 5GHz radio: 0x"
>> >
>> > I'm using FreeBSD 11-CURRENT with sources updated today.
>>
>>
>> What else does it log?
>
>
> I have this same card on a acer s3 (utltrabook)
>
> @adrian this is the one I reported the performance issues but now seems to
> be working ok.
>
> For the record this is with --> r280273
>
> commit d7efe7e99e68d52fa754f4e935814c492d818ece
> Author: pfg 
> Date:   Fri Mar 20 01:07:48 2015 +
>
> Permit multiple arguments for the nonnull attribute.
>
> This is very useful for non-trivial functions and doesn't
> affect existing uses.
>
> MFC after:  5 days
>
> Notes:
> svn path=/head/; revision=280273
>
>
> I'm noticing something wron with "ifconfig scan" too, it listed fine as a
> normal user, but that's not really re-scanning...
>
> % ifconfig wlan0 scan
> SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
>    *:1c:681   54M -93:-96  100 EP   RSN HTCAP WPS WPA WME
>    *:13:c06   54M -80:-96  100 EP   RSN HTCAP WPS WME
>    *:e2:0c6   54M -83:-96  100 EP   RSN HTCAP WME
>   *:f7:8c6   54M -109:-96  100 EP   RSN HTCAP WPS WPA WME
>    *:4a:12   11   54M -91:-96  100 EP   RSN HTCAP WPS WPA WME
>   *:13:c4   48   54M -80:-96  100 EP   RSN HTCAP WME
>
> Trying with sudo gets in a hanged state...
>
> [user@host:/usr/src ]% sudo ifconfig wlan0 scan
> load: 0.17  cmd: ifconfig 11320 [sbwait] 35.72r 0.00u 0.00s 0% 2132k
> load: 0.17  cmd: ifconfig 11320 [sbwait] 36.20r 0.00u 0.00s 0% 2132k
> load: 0.19  cmd: ifconfig 11320 [sbwait] 187.79r 0.00u 0.00s 0% 2132k
> load: 0.19  cmd: ifconfig 11320 [sbwait] 187.94r 0.00u 0.00s 0% 2132k
> load: 0.19  cmd: ifconfig 11320 [sbwait] 188.08r 0.00u 0.00s 0% 2132k
>
> ^C
>
> but after the ^C as a normal user again and:
> ifconfig wlan0 scan
> SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
> *   *:1c:681   54M -94:-96  100 EP   RSN HTCAP WPS WPA WME
> *   *:13:c06   54M -80:-96  100 EP   RSN HTCAP WPS WME
> *   *:e2:0c6   54M -83:-96  100 EP   RSN HTCAP WME
> *   *:f7:8c6   54M -130:-96  100 EP   RSN HTCAP WPS WPA WME
> *   *:4a:121   54M -91:-96  100 EP   RSN HTCAP WPS WPA WME
> *   *:13:c4   48   54M -80:-96  100 EP   RSN HTCAP WME
> * ...   *:99:016   54M -96:-96  100 E  <--- This is new so it
> re-scanned
>
>
> I see nothing in dmesg
>
>>
>>
>> -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"
>
>
___
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 #857

[jenkins-admin]

See 

--
[...truncated 987 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.013s]
lib/libc/string/swab:swab_basic  ->  passed  [0.013s]
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.013s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.013s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.013s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.013s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.016s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.013s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.014s]
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.013s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.013s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.014s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.029s]
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.031s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.014s]
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.037s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.014s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.013s]
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.016s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.014s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.014s]
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.014s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.014s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.015s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.015s]
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.014s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.149s]
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.014s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.015s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.016s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.014s]
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.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.015s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.016s]
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.017s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.015s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.046s]
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.019s]
lib/libc/sys/link_test:link_err  ->  passed  [0.018s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.013s]
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.014s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.013s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.038s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.017s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.014s]
lib/libc/sys/mkdir

Re: clang/tblgen: undefined reference to `futimens' c++: error: linker command failed with exit

[Dimitry Andric]

On 20 Mar 2015, at 08:33, O. Hartmann  wrote:
> 
> Running
> 
> 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r277382: Mon Jan 19 16:10:34 CET 2015
> amd64
> 
> with source tree at revision
> >>> Updating /usr/src using Subversion
> --
> Updating '.':
> At revision 280275.
> 
> and "make buildorld buildkernel"
> 
> fails at the below shown point.
> 
> The /usr/obj tree is clean - I delete it prior to each build run.
> 
> Something is out of sync, sn earlier update process (make installworld) 
> crashed
> and I think the kernel, binary tools and rest of sources are some kind of out
> of sync.
> 
> Is there a way - from the data shown - to resolve the problem?
> 
> Building a kernel works great, building toolchains fail also at the very same
> point.
> 
> Thanks in advance,
> 
> oh
> 
> 
> [...]
> --- _bootstrap-tools-usr.bin/clang/tblgen ---
> --- TableGen.o ---
> c++ -O2 -pipe -O3 -pipe -O3
> -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include
> -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include
> -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I.
> -I/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-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11
> -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions
> -c 
> /usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen/TableGen.cpp
> -o TableGen.o --- _bootstrap-tools-usr.bin/clang/clang-tblgen
> --- 
> /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/clang-tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a(Path.o):
> In function `llvm::sys::fs::setLastModificationAndAccessTime(int,
> llvm::sys::TimeValue)': 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Path.cpp:(.text+0x4649):
> undefined reference to `futimens' c++: error: linker command failed with exit
> code 1 (use -v to see invocation) *** [clang-tblgen] Error code 1

Somehow, you seem to have messed up your libc, which provides futimens()
since r277610 (about 7 weeks ago).  Maybe you restored a very old
version?

In any case, you might be able to get around it by cheating with
__FreeBSD_version.  What does the following say on your system:

  grep "#define __FreeBSD_version" /usr/include/sys/param.h

If the version is 1100056 or higher, you should have futimens().  You
could try cheating by editing the file and resetting the version to e.g.
1100055.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Anders Bolt-Evensen]

IEEE_80211_DEBUG is compiled into the kernel.
When I ran "wlandebug +scan", I got the following output:
net.wlan.0.debug: 0x0 => 0x20
Then I ran "ifconfig wlan0 up" and then "ifconfig wlan0 scan".
The scan now took a few seconds, but still nothing shows up.
Then I took a look at dmesg -a which was now filled with a loop of the 
following messages:


wlan0: ieee80211_start_scan_locked: active scan, duration 2147483647 
mindwell 0 maxdwell 0, desired mode auto, append, nojoin, once
wlan0: scan set 1g, 6g, 11g, 7g, 13g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 
48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, 149a, 153a, 157a, 161a, 165a, 
100a, 104a, 108a, 112a, 116a, 120a, 124a, 128a, 132a, 136a, 140a dwell 
min 20ms max 200ms

wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan 140a ->   1g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  13g ->  52a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  52a ->  56a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  56a ->  60a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  60a ->  64a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  64a ->  36a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  36a ->  40a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  40a ->  44a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  44a ->  48a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  48a ->   2g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   2g ->   3g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   4g ->   5g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   5g ->   8g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   8g ->   9g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan   9g ->  10g [active, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  10g ->  12g [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan  12g -> 149a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan 149a -> 153a [passive, dwell min 20ms max 200ms]
wlan0: scan_curchan: calling; maxdwell=200
wlan0: scan_task: waiting
wlan0: scan_task: loop start; scandone=0
wlan0: scan_task: chan 153a -> 157a [passive, dwell min 

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

[Adrian Chadd]

Hm, ok. either interrupts arne'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.



-a


On 20 March 2015 at 15:19, Anders Bolt-Evensen  wrote:
>
> IEEE_80211_DEBUG is compiled into the kernel.
> When I ran "wlandebug +scan", I got the following output:
> net.wlan.0.debug: 0x0 => 0x20
> Then I ran "ifconfig wlan0 up" and then "ifconfig wlan0 scan".
> The scan now took a few seconds, but still nothing shows up.
> Then I took a look at dmesg -a which was now filled with a loop of the
> following messages:
>
> wlan0: ieee80211_start_scan_locked: active scan, duration 2147483647
> mindwell 0 maxdwell 0, desired mode auto, append, nojoin, once
> wlan0: scan set 1g, 6g, 11g, 7g, 13g, 52a, 56a, 60a, 64a, 36a, 40a, 44a,
> 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, 149a, 153a, 157a, 161a, 165a, 100a,
> 104a, 108a, 112a, 116a, 120a, 124a, 128a, 132a, 136a, 140a dwell min 20ms
> max 200ms
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan 140a ->   1g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  13g ->  52a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  52a ->  56a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  56a ->  60a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  60a ->  64a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  64a ->  36a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  36a ->  40a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  40a ->  44a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  44a ->  48a [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  48a ->   2g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   2g ->   3g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   4g ->   5g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   5g ->   8g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   8g ->   9g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan   9g ->  10g [active, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_task: loop start; scandone=0
> wlan0: scan_task: chan  10g ->  12g [passive, dwell min 20ms max 200ms]
> wlan0: scan_curchan: calling; maxdwell=200
> wlan0: scan_task: waiting
> wlan0: scan_ta

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

[Ryan Stone]

"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?
___
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 #858

[jenkins-admin]

See 

--
[...truncated 2462 lines...]
lib/libc/string/strspn:strspn  ->  passed  [0.071s]
lib/libc/string/swab:swab_basic  ->  passed  [0.051s]
lib/libc/sys/access_test:access_access  ->  passed  [0.079s]
lib/libc/sys/access_test:access_fault  ->  passed  [0.069s]
lib/libc/sys/access_test:access_inval  ->  passed  [0.045s]
lib/libc/sys/access_test:access_notdir  ->  passed  [0.068s]
lib/libc/sys/access_test:access_notexist  ->  passed  [0.063s]
lib/libc/sys/access_test:access_toolong  ->  passed  [0.036s]
lib/libc/sys/chroot_test:chroot_basic  ->  passed  [0.076s]
lib/libc/sys/chroot_test:chroot_err  ->  passed  [0.053s]
lib/libc/sys/chroot_test:chroot_perm  ->  passed  [0.030s]
lib/libc/sys/clock_gettime_test:clock_gettime_real  ->  passed  [0.056s]
lib/libc/sys/connect_test:connect_low_port  ->  passed  [0.044s]
lib/libc/sys/dup_test:dup2_basic  ->  passed  [0.050s]
lib/libc/sys/dup_test:dup2_err  ->  passed  [0.030s]
lib/libc/sys/dup_test:dup2_max  ->  passed  [0.031s]
lib/libc/sys/dup_test:dup2_mode  ->  passed  [0.077s]
lib/libc/sys/dup_test:dup3_err  ->  passed  [0.022s]
lib/libc/sys/dup_test:dup3_max  ->  passed  [0.028s]
lib/libc/sys/dup_test:dup3_mode  ->  passed  [0.040s]
lib/libc/sys/dup_test:dup_err  ->  passed  [0.031s]
lib/libc/sys/dup_test:dup_max  ->  passed  [0.056s]
lib/libc/sys/dup_test:dup_mode  ->  passed  [0.085s]
lib/libc/sys/fsync_test:fsync_err  ->  passed  [0.062s]
lib/libc/sys/fsync_test:fsync_sync  ->  passed  [0.155s]
lib/libc/sys/getcontext_test:getcontext_err  ->  passed  [0.025s]
lib/libc/sys/getcontext_test:setcontext_err  ->  passed  [0.076s]
lib/libc/sys/getcontext_test:setcontext_link  ->  passed  [0.309s]
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.345s]
lib/libc/sys/getgroups_test:getgroups_getgid  ->  passed  [0.109s]
lib/libc/sys/getgroups_test:getgroups_setgid  ->  passed  [0.030s]
lib/libc/sys/getgroups_test:getgroups_zero  ->  passed  [0.039s]
lib/libc/sys/getitimer_test:getitimer_empty  ->  passed  [0.029s]
lib/libc/sys/getitimer_test:getitimer_err  ->  passed  [0.041s]
lib/libc/sys/getitimer_test:setitimer_basic  ->  passed  [0.033s]
lib/libc/sys/getitimer_test:setitimer_err  ->  passed  [0.030s]
lib/libc/sys/getitimer_test:setitimer_old  ->  passed  [0.023s]
lib/libc/sys/getlogin_test:getlogin_r_err  ->  passed  [0.035s]
lib/libc/sys/getlogin_test:getlogin_same  ->  passed  [0.045s]
lib/libc/sys/getlogin_test:setlogin_basic  ->  passed  [0.033s]
lib/libc/sys/getlogin_test:setlogin_err  ->  passed  [0.031s]
lib/libc/sys/getlogin_test:setlogin_perm  ->  passed  [0.031s]
lib/libc/sys/getpid_test:getpid_process  ->  passed  [0.043s]
lib/libc/sys/getpid_test:getpid_thread  ->  passed  [0.036s]
lib/libc/sys/getrusage_test:getrusage_err  ->  passed  [0.032s]
lib/libc/sys/getrusage_test:getrusage_sig  ->  passed  [0.034s]
lib/libc/sys/getrusage_test:getrusage_utime_back  ->  passed  [2.178s]
lib/libc/sys/getrusage_test:getrusage_utime_zero  ->  skipped: this testcase 
passes/fails sporadically on FreeBSD/i386 @ r273153 (at least)  [0.053s]
lib/libc/sys/getsid_test:getsid_current  ->  passed  [0.076s]
lib/libc/sys/getsid_test:getsid_err  ->  passed  [0.046s]
lib/libc/sys/getsid_test:getsid_process  ->  passed  [0.034s]
lib/libc/sys/gettimeofday_test:gettimeofday_err  ->  passed  [0.054s]
lib/libc/sys/gettimeofday_test:gettimeofday_mono  ->  passed  [0.039s]
lib/libc/sys/issetugid_test:issetugid_egid  ->  passed  [0.056s]
lib/libc/sys/issetugid_test:issetugid_euid  ->  passed  [0.077s]
lib/libc/sys/issetugid_test:issetugid_rgid  ->  passed  [0.046s]
lib/libc/sys/issetugid_test:issetugid_ruid  ->  passed  [0.028s]
lib/libc/sys/kevent_test:kevent_zerotimer  ->  passed  [0.038s]
lib/libc/sys/kevent_test:kqueue_desc_passing  ->  passed  [0.030s]
lib/libc/sys/kevent_test:kqueue_unsupported_fd  ->  skipped: no /nonexistent 
available for testing  [0.023s]
lib/libc/sys/kill_test:kill_basic  ->  passed  [0.027s]
lib/libc/sys/kill_test:kill_err  ->  passed  [0.025s]
lib/libc/sys/kill_test:kill_perm  ->  passed  [1.131s]
lib/libc/sys/kill_test:kill_pgrp_neg  ->  passed  [0.029s]
lib/libc/sys/kill_test:kill_pgrp_zero  ->  passed  [0.035s]
lib/libc/sys/link_test:link_count  ->  passed  [0.063s]
lib/libc/sys/link_test:link_err  ->  passed  [0.056s]
lib/libc/sys/link_test:link_perm  ->  passed  [0.033s]
lib/libc/sys/link_test:link_stat  ->  passed  [0.036s]
lib/libc/sys/listen_test:listen_err  ->  passed  [0.038s]
lib/libc/sys/listen_test:listen_low_port  ->  passed  [0.025s]
lib/libc/sys/mincore_test:mincore_err  ->  passed  [0.027s]
lib/libc/sys/mincore_test:mincore_resid  ->  passed  [0.045s]
lib/libc/sys/mincore_test:mincore_shmseg  ->  passed  [0.025s]
lib/libc/sys/mkdir_test:mkdir_err  ->  passed  [0.045s]
lib/libc/sys/mkdi

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

[Mateusz Guzik]

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.
---
 sys/kern/kern_fork.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index ae86fe1..15833fd 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -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);
-
/* Tell the prison that we exist. */
prison_proc_hold(p2->p_ucred->cr_prison);
 
@@ -832,7 +829,7 @@ fork1(struct thread *td, int flags, int pages, struct proc 
**procp,
td2 = thread_alloc(pages);
if (td2 == NULL) {
error = ENOMEM;
-   goto fail1;
+   goto fail2;
}
proc_linkup(newproc, td2);
} else {
@@ -841,7 +838,7 @@ fork1(struct thread *td, int flags, int pages, struct proc 
**procp,
vm_thread_dispose(td2);
if (!thread_alloc_stack(td2, pages)) {
error = ENOMEM;
-   goto fail1;
+   goto fail2;
}
}
}
@@ -850,7 +847,7 @@ fork1(struct thread *td, int flags, int pages, struct proc 
**procp,
vm2 = vmspace_fork(p1->p_vmspace, &mem_charged);
if (vm2 == NULL) {
error = ENOMEM;
-   goto fail1;
+   goto fail2;
}
if (!swap_reserve(mem_charged)) {
/*
@@ -861,7 +858,7 @@ fork1(struct thread *td, int flags, int pages, struct proc 
**procp,
 */
swap_reserve_force(mem_charged);
error = ENOMEM;
-   goto fail1;
+   goto fail2;
}
} else
vm2 = NULL;
@@ -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));
 
/*
 * Initialize resource accounting for the child process.
@@ -946,6 +943,8 @@ fail:
 #endif
racct_proc_exit(newproc);
 fail1:
+   crfree(proc_set_cred(newproc, NULL));
+fail2:
if (vm2 != NULL)
vmspace_free(vm2);
uma_zfree(proc_zone, newproc);
-- 
2.3.2

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

[PATCH 2/3] cred: add proc_set_cred_init helper

[Mateusz Guzik]

From: Mateusz Guzik 

proc_set_cred_init can be used to set first credentials of a new
process.

Update proc_set_cred assertions so that it only expects already used
processes.

This fixes panics where p_ucred of a new process happens to be non-NULL.
---
 sys/kern/init_main.c |  2 +-
 sys/kern/kern_fork.c |  2 +-
 sys/kern/kern_prot.c | 16 ++--
 sys/sys/ucred.h  |  1 +
 4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c
index 82cf63f..88cd44c 100644
--- a/sys/kern/init_main.c
+++ b/sys/kern/init_main.c
@@ -515,7 +515,7 @@ proc0_init(void *dummy __unused)
newcred->cr_ruidinfo = uifind(0);
newcred->cr_prison = &prison0;
newcred->cr_loginclass = loginclass_find("default");
-   proc_set_cred(p, newcred);
+   proc_set_cred_init(p, newcred);
 #ifdef AUDIT
audit_cred_kproc0(newcred);
 #endif
diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index 15833fd..a3a70b8 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -867,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, crhold(td->td_ucred));
+   proc_set_cred_init(newproc, crhold(td->td_ucred));
 
/*
 * Initialize resource accounting for the child process.
diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c
index 72c9f65..9c49f71 100644
--- a/sys/kern/kern_prot.c
+++ b/sys/kern/kern_prot.c
@@ -1954,8 +1954,19 @@ cred_update_thread(struct thread *td)
 }
 
 /*
+ * Set initial process credentials.
+ * Callers are responsible for providing the reference for provided 
credentials.
+ */
+void
+proc_set_cred_init(struct proc *p, struct ucred *newcred)
+{
+
+   p->p_ucred = newcred;
+}
+
+/*
  * Change process credentials.
- * Callers are responsible for providing the reference for current credentials
+ * Callers are responsible for providing the reference for passed credentials
  * and for freeing old ones.
  *
  * Process has to be locked except when it does not have credentials (as it
@@ -1968,9 +1979,10 @@ proc_set_cred(struct proc *p, struct ucred *newcred)
 {
struct ucred *oldcred;
 
+   MPASS(p->p_ucred != NULL);
if (newcred == NULL)
MPASS(p->p_state == PRS_ZOMBIE);
-   else if (p->p_ucred != NULL)
+   else
PROC_LOCK_ASSERT(p, MA_OWNED);
 
oldcred = p->p_ucred;
diff --git a/sys/sys/ucred.h b/sys/sys/ucred.h
index 2b42b01..9a45308 100644
--- a/sys/sys/ucred.h
+++ b/sys/sys/ucred.h
@@ -106,6 +106,7 @@ voidcrcopy(struct ucred *dest, struct ucred *src);
 struct ucred   *crcopysafe(struct proc *p, struct ucred *cr);
 struct ucred   *crdup(struct ucred *cr);
 void   cred_update_thread(struct thread *td);
+void   proc_set_cred_init(struct proc *p, struct ucred *cr);
 struct ucred   *proc_set_cred(struct proc *p, struct ucred *cr);
 void   crfree(struct ucred *cr);
 struct ucred   *crget(void);
-- 
2.3.2

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

[PATCH 3/3] proc: use MTX_NEW flag in proc_init

[Mateusz Guzik]

From: Mateusz Guzik 

This allows us to get rid of bzero which was added specifically to make
mtx_init on p_mtx reliable.

This also fixes a potential problem where mtx_init on other mutexes
could trip over on unitialized memory and fire an assertion.
---
 sys/kern/kern_proc.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c
index a607d7b1..f72269d 100644
--- a/sys/kern/kern_proc.c
+++ b/sys/kern/kern_proc.c
@@ -225,12 +225,11 @@ proc_init(void *mem, int size, int flags)
p = (struct proc *)mem;
SDT_PROBE(proc, kernel, init, entry, p, size, flags, 0, 0);
p->p_sched = (struct p_sched *)&p[1];
-   bzero(&p->p_mtx, sizeof(struct mtx));
-   mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK);
-   mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN);
-   mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN);
-   mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN);
-   mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN);
+   mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK | 
MTX_NEW);
+   mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN | MTX_NEW);
+   mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN | MTX_NEW);
+   mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN | MTX_NEW);
+   mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN | MTX_NEW);
cv_init(&p->p_pwait, "ppwait");
cv_init(&p->p_dbgwait, "dbgwait");
TAILQ_INIT(&p->p_threads);   /* all threads in proc */
-- 
2.3.2

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

[PATCH 0/3] fix up some recent proc fallout and more

[Mateusz Guzik]

From: Mateusz Guzik 

Patches in this series fix a bug introduced in r280130 and deal with
additional issues.

I'm not happy with how sutff is being done at the moment. In particular
we zero out various fields on process exit, which puts it into a state
state which is not guaranteed when we deal when it is first allocated.
But I guess we can leave it as it is for now.

I don't believe we have a good solution at the moment which would poison
memory returned by uma_zalloc, that would definitely make the issue
apparent right of the bat. Adding such a feature sould be reasonably
simple but fallout may take some time to deal with, I'll make a follow
up thread.

Mateusz Guzik (3):
  fork: assign refed credentials earlier
  cred: add proc_set_cred_init helper
  proc: use MTX_NEW flag in proc_init

 sys/kern/init_main.c |  2 +-
 sys/kern/kern_fork.c | 15 +++
 sys/kern/kern_proc.c | 11 +--
 sys/kern/kern_prot.c | 16 ++--
 sys/sys/ucred.h  |  1 +
 5 files changed, 28 insertions(+), 17 deletions(-)

-- 
2.3.2

___
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

[Konstantin Belousov]

On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote:
> Hello everybody,
> 
> The malloc_init_hard() function defined in jemalloc_jemalloc.c, FreeBSD 
> 11 r277486 reads:
> 
> static bool
> malloc_init_hard(void)
> {
>  ...
>  if (base_boot()) {
>  malloc_mutex_unlock(&init_lock);
>  eturn (true);
>  }
> 
>  if (chunk_boot()) {
>  malloc_mutex_unlock(&init_lock);
>  return (true);
>  }
>  ...
> 
> The second call initializes the 'chunksize' global variable defined in 
> jemalloc_chunk.c:
> 
> bool
> chunk_boot(void)
> {
>  /* Set variables according to the value of opt_lg_chunk. */
>  chunksize = (ZU(1) << opt_lg_chunk);
>  assert(chunksize >= PAGE);
>  ...
> 
> However, it seems the first call to base_boot() depends on that variable 
> already:
> 
> (gdb) bt
> #0  thr_kill () at thr_kill.S:3
> #1  0x000801241408 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:51
> #2  0x0041d817 in __interceptor_raise () at 
> /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:2097
> #3  0x00080123f969 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #4  0x0041c5d9 in __interceptor_abort () at 
> /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1851
> #5  0x0008011a8d64 in __je_chunk_alloc (size=, 
> alignment=, base=, zero=,
>  dss_prec=dss_prec_disabled) at jemalloc_chunk.c:150
> #6  0x0008011a9bfc in base_pages_alloc (minsize=128) at 
> jemalloc_base.c:35
> #7  __je_base_alloc (size=) at jemalloc_base.c:57
> #8  0x0008011a9c96 in __je_base_calloc (number=, 
> size=6) at jemalloc_base.c:74
> #9  0x0008008ae548 in mutex_init (calloc_cb=0x0, mutex= out>, mutex_attr=) at 
> /usr/src/lib/libthr/thread/thr_mutex.c:145
> #10 _pthread_mutex_init_calloc_cb (mutex=0x801487c90, calloc_cb=0x0) at 
> /usr/src/lib/libthr/thread/thr_mutex.c:229
> #11 0x0008011a18da in __je_malloc_mutex_init (mutex=0x18744) at 
> jemalloc_mutex.c:97
> #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 ?

Does it happen always, on only for the early initialization of the 
mutexes ?  It might be related to r276630.  Can you test on, say, 10.1 ?

> 
> Note that base_pages() calls chunk_alloc() with chucksize used as the 
> alignment value:
> 
> static bool
> base_pages_alloc(size_t minsize)
> {
>  ...
>  base_pages = chunk_alloc(csize, chunksize, true, &zero,
>  chunk_dss_prec_get());
>  ...
> 
> and the latter tests it against zero:
> 
> void *
> chunk_alloc(size_t size, size_t alignment, bool base, bool *zero,
>  dss_prec_t dss_prec)
> {
>  ...
>  assert(alignment != 0);
>  
> 
> so we sometimes we end up with:
> 
> : 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.
___
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?

[NGie Cooper]

On Fri, Mar 20, 2015 at 4:52 PM, 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?

It should work. If it doesn't, then we need to do a fixathon for it..

Folks might not have been setting SRCCONF / __MAKE_CONF to /dev/null
before committing to head by accident :/..
___
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

[Konstantin Belousov]

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.

Other two patches look fine.
> ---
>  sys/kern/kern_fork.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
> index ae86fe1..15833fd 100644
> --- a/sys/kern/kern_fork.c
> +++ b/sys/kern/kern_fork.c
> @@ -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);
> -
>   /* Tell the prison that we exist. */
>   prison_proc_hold(p2->p_ucred->cr_prison);
>  
> @@ -832,7 +829,7 @@ fork1(struct thread *td, int flags, int pages, struct 
> proc **procp,
>   td2 = thread_alloc(pages);
>   if (td2 == NULL) {
>   error = ENOMEM;
> - goto fail1;
> + goto fail2;
>   }
>   proc_linkup(newproc, td2);
>   } else {
> @@ -841,7 +838,7 @@ fork1(struct thread *td, int flags, int pages, struct 
> proc **procp,
>   vm_thread_dispose(td2);
>   if (!thread_alloc_stack(td2, pages)) {
>   error = ENOMEM;
> - goto fail1;
> + goto fail2;
>   }
>   }
>   }
> @@ -850,7 +847,7 @@ fork1(struct thread *td, int flags, int pages, struct 
> proc **procp,
>   vm2 = vmspace_fork(p1->p_vmspace, &mem_charged);
>   if (vm2 == NULL) {
>   error = ENOMEM;
> - goto fail1;
> + goto fail2;
>   }
>   if (!swap_reserve(mem_charged)) {
>   /*
> @@ -861,7 +858,7 @@ fork1(struct thread *td, int flags, int pages, struct 
> proc **procp,
>*/
>   swap_reserve_force(mem_charged);
>   error = ENOMEM;
> - goto fail1;
> + goto fail2;
>   }
>   } else
>   vm2 = NULL;
> @@ -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));
>  
>   /*
>* Initialize resource accounting for the child process.
> @@ -946,6 +943,8 @@ fail:
>  #endif
>   racct_proc_exit(newproc);
>  fail1:
> + crfree(proc_set_cred(newproc, NULL));
> +fail2:
>   if (vm2 != NULL)
>   vmspace_free(vm2);
>   uma_zfree(proc_zone, newproc);
> -- 
> 2.3.2
___
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

[Mateusz Guzik]

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));
> >  

-- 
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: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

[Miguel Clara]

On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman  wrote:

> On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara 
> wrote:
>
>>
>> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper 
>> wrote:
>>
>>>
>>> On Feb 25, 2015, at 18:08, Kevin Oberman  wrote:
>>>
>>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper 
>>> wrote:
>>>
 On Feb 25, 2015, at 14:19, Miguel Clara  wrote:

 ...

 > I noticed this too, but in that case why doesn't it affect all users?
 (or all the ones using dnscrypt+local_unbound) maybe something changed in
 "NETWORKING" recently?
 >
 > Hum:
 >
 https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704
 >
 > Interesting, as I am using the most recent version which does not
 REQUIRE local_unbound
 >
 > I'm even more confused now :|
 >
 >
 > So it has to come after SERVERS but before local_unbound. But
 NETWORKING depends on local_unbound they are both dependent on NEWORKING
 which has to be after SERVERS. Can you say fubar! Clearly broken. And this
 means that removing SERVERS will re-shuffle the order more appropriately.
 >
 > It seems that the behavior of rcorder is not as documented as well as
 being undefined when circular dependencies occur. The man page says that
 rcorder aborts when it encounters a circular dependency, but that is not
 the case. It probably is best that it not die, but that leaves things in an
 unknown and inconsistant state, which is also a very bad idea. I guess when
 a circular dependency is encountered, a dichotomy occurs.

 Now you know why I’m so curious about all of this stuff.

 When I was working on ^/projects/building-blocks, I was able to move
 most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed
 that it changes the rcorder a bit, so I haven’t been super gung ho in
 implementing my change.

 I think there are a couple bugs present on
 9-STABLE/10-STABLE/11-CURRENT:

 - Things go awry if named is removed/not installed.
 - Things go awry if local_unbound is removed (which would have been the
 case if the rc.d script was removed from your system, which existed before
 my changes).
 - Other rc.d scripts not being present might break assumptions.

 I need to create dummy providers for certain logical stages (DNS is one
 of them) to solve part of this problem and provide third parties with a
 mechanism that can be depended on (I wish applications were written in a
 more robust manner to fail gracefully and retry instead of failing flat on
 their face, but as I’ve seen at several jobs, getting developers to fail,
 then retry is hard :(…).

 Another short-term hack:

 Install dummy/no-op providers so the ordering is preserved, then remove
 the hacks after all of the bugs have been shaken out.

 Thanks!

>>>
>>> Garret,
>>>
>>> Also undocumented (except in rcorder.c) is that the lack of a provider
>>> is not an error. This effectively makes a list of providers into an OR. So,
>>> for name service the normal list is "named local_unbound unbound" and any
>>> will work for ordering and having none is a no-op, so if you don't run any
>>> nameserver (or kerberos or whatever provider), it is not an issue. As long
>>> as rcorder finds a provider, it will be used to set the order, but the lack
>>> of any or all providers just means that the specified provider is ignored
>>> and if a REQUIRES or BEFORE lists no existing providers, the statement is
>>> simply ignored.
>>>
>>> The real problem is that there is no defined rule for behavior in the
>>> event of a circular dependency and any change to any decision point in the
>>> ordering process may change the way the ordering flips. That is why these
>>> things are such a royal pain to debug. A change in any rc.d script may
>>> cause the ordering of seemingly unrelated scripts to change, perhaps
>>> drastically, and the error messages, while not misleading, is only a
>>> starting point in tracking this down. This means there may be time bombs
>>> that break working ports without their being touched or even re-installed.
>>> And the triggering change my, itself be correct.
>>>
>>>
>>> Or etc/rc.d/named...
>>>
>>> PROVIDES: DNS
>>>
>>> I'm going to post a fix up for this on arch@/rc@ because it needs to be
>>> solved in a saner way -- especially for systems that are pedantic about
>>> rcorder, like our version at $work.
>>>
>>>
>> I re-sync my source and noticed the change while doing the mergemaster
>> part... with this I can now change dnscrypt to:
>>
>> @@ -4,7 +4,7 @@
>>  #
>>  # PROVIDE: dnscrypt_proxy
>>  # REQUIRE: SERVERS cleanvar
>> -# BEFORE: named local_unbound unbound
>> +# BEFORE: DNS
>>
>> And this makes the rcorder ok for dnscrypt-proxy
>>
>
> This is still broken and only works by random luck. At this time there
> appears to be nothing providing DNS

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

[Kevin Oberman]

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"

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

[Rui Paulo]

It's worth noting that some laptops have special keys to enable/disable WiFi 
and sometimes that just kills the radio.  Do you have that function key and 
does toggling it have any effect?

--
Rui Paulo



___
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: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

[Kevin Oberman]

On Fri, Mar 20, 2015 at 7:14 PM, Miguel Clara 
wrote:

>
> On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman 
> wrote:
>
>> On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara 
>> wrote:
>>
>>>
>>> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper 
>>> wrote:
>>>

 On Feb 25, 2015, at 18:08, Kevin Oberman  wrote:

 On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper 
 wrote:

> On Feb 25, 2015, at 14:19, Miguel Clara 
> wrote:
>
> ...
>
> > I noticed this too, but in that case why doesn't it affect all
> users? (or all the ones using dnscrypt+local_unbound) maybe something
> changed in "NETWORKING" recently?
> >
> > Hum:
> >
> https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704
> >
> > Interesting, as I am using the most recent version which does not
> REQUIRE local_unbound
> >
> > I'm even more confused now :|
> >
> >
> > So it has to come after SERVERS but before local_unbound. But
> NETWORKING depends on local_unbound they are both dependent on NEWORKING
> which has to be after SERVERS. Can you say fubar! Clearly broken. And this
> means that removing SERVERS will re-shuffle the order more appropriately.
> >
> > It seems that the behavior of rcorder is not as documented as well
> as being undefined when circular dependencies occur. The man page says 
> that
> rcorder aborts when it encounters a circular dependency, but that is not
> the case. It probably is best that it not die, but that leaves things in 
> an
> unknown and inconsistant state, which is also a very bad idea. I guess 
> when
> a circular dependency is encountered, a dichotomy occurs.
>
> Now you know why I’m so curious about all of this stuff.
>
> When I was working on ^/projects/building-blocks, I was able to move
> most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed
> that it changes the rcorder a bit, so I haven’t been super gung ho in
> implementing my change.
>
> I think there are a couple bugs present on
> 9-STABLE/10-STABLE/11-CURRENT:
>
> - Things go awry if named is removed/not installed.
> - Things go awry if local_unbound is removed (which would have been
> the case if the rc.d script was removed from your system, which existed
> before my changes).
> - Other rc.d scripts not being present might break assumptions.
>
> I need to create dummy providers for certain logical stages (DNS is
> one of them) to solve part of this problem and provide third parties with 
> a
> mechanism that can be depended on (I wish applications were written in a
> more robust manner to fail gracefully and retry instead of failing flat on
> their face, but as I’ve seen at several jobs, getting developers to fail,
> then retry is hard :(…).
>
> Another short-term hack:
>
> Install dummy/no-op providers so the ordering is preserved, then
> remove the hacks after all of the bugs have been shaken out.
>
> Thanks!
>

 Garret,

 Also undocumented (except in rcorder.c) is that the lack of a provider
 is not an error. This effectively makes a list of providers into an OR. So,
 for name service the normal list is "named local_unbound unbound" and any
 will work for ordering and having none is a no-op, so if you don't run any
 nameserver (or kerberos or whatever provider), it is not an issue. As long
 as rcorder finds a provider, it will be used to set the order, but the lack
 of any or all providers just means that the specified provider is ignored
 and if a REQUIRES or BEFORE lists no existing providers, the statement is
 simply ignored.

 The real problem is that there is no defined rule for behavior in the
 event of a circular dependency and any change to any decision point in the
 ordering process may change the way the ordering flips. That is why these
 things are such a royal pain to debug. A change in any rc.d script may
 cause the ordering of seemingly unrelated scripts to change, perhaps
 drastically, and the error messages, while not misleading, is only a
 starting point in tracking this down. This means there may be time bombs
 that break working ports without their being touched or even re-installed.
 And the triggering change my, itself be correct.


 Or etc/rc.d/named...

 PROVIDES: DNS

 I'm going to post a fix up for this on arch@/rc@ because it needs to
 be solved in a saner way -- especially for systems that are pedantic about
 rcorder, like our version at $work.


>>> I re-sync my source and noticed the change while doing the mergemaster
>>> part... with this I can now change dnscrypt to:
>>>
>>> @@ -4,7 +4,7 @@
>>>  #
>>>  # PROVIDE: dnscrypt_proxy
>>>  # REQUIRE: SERVERS cleanvar
>>> -# BEFORE: named