Jenkins build is still unstable: FreeBSD_HEAD #472

2016-07-19 Thread jenkins-admin 
See 

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

Re: CURRENT: frequent crashes if mpd5 is running

2016-07-19 Thread Sergey V. Dyatko 
On Thu, 14 Jul 2016 14:38:15 -0400
Allan Jude  wrote: 

> On 2016-07-14 13:13, Oleg V. Nauman wrote:
> >  I'm experiencing frequent CURRENT ( 12.0-CURRENT r302535 amd64 ) crashes 
> > triggered by mpd5:
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x10
> > fault code  = supervisor read data, page not present
> > instruction pointer = 0x20:0x814f6162
> > stack pointer   = 0x28:0xfe011b06d640
> > frame pointer   = 0x28:0xfe011b06d670
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 901 (mpd5)
> > trap number = 12
> > panic: page fault
> > cpuid = 0
> > 
> > #0  doadump (textdump=) at pcpu.h:221
> > 221 pcpu.h: No such file or directory.
> > in pcpu.h
> > (kgdb) #0  doadump (textdump=) at pcpu.h:221
> > #1  0x80749169 in kern_reboot (howto=260)
> > at ../../../kern/kern_shutdown.c:366
> > #2  0x807496e1 in vpanic (fmt=,
> > ap=) at ../../../kern/kern_shutdown.c:759
> > #3  0x80749553 in panic (fmt=0x0)
> > at ../../../kern/kern_shutdown.c:690 #4  0x80a5aca1 in trap_fatal
> > (frame=0xfe011b06d590, eva=16) at ../../../amd64/amd64/trap.c:841
> > #5  0x80a5af51 in trap_pfault (frame=0x0, usermode=0)
> > at ../../../amd64/amd64/trap.c:716
> > #6  0x80a5a430 in trap (frame=0xfe011b06d590)
> > at ../../../amd64/amd64/trap.c:442
> > #7  0x80a3e161 in calltrap ()
> > at ../../../amd64/amd64/exception.S:236 #8  0x814f6162 in
> > ng_uncallout (c=0xf80004842460, node=0xf80004c79a00)
> > at 
> > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3815
> > #9  0x8151bbab in ng_pptpgre_disconnect (hook=)
> > at 
> > /usr/src/sys/modules/netgraph/pptpgre/../../../netgraph/ng_pptpgre.c:966
> > #10 0x814f2928 in ng_destroy_hook (hook=0xf8000487ad80)
> > at 
> > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1219
> > #11 0x814f2635 in ng_rmnode (node=,
> > dummy1=, dummy2=,
> > dummy3=)
> > at 
> > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:744
> > #12 0x814f4832 in ng_apply_item (node=0xf80004c79a00,
> > item=0xf80004e72600, rw=1)
> > at 
> > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2523
> > #13 0x814f41a3 in ng_snd_item (item=,
> > flags=)
> > at 
> > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2320
> > #14 0x814eec4e in ngc_send (so=,
> > flags=, m=,
> > addr=, control=,
> > td=)
> > at 
> > /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:338
> > #15 0x807dee17 in sosend_generic (so=,
> > addr=, uio=,
> > top=, control=,
> > flags=, td=)
> > at ../../../kern/uipc_socket.c:1359
> > #16 0x807e66b8 in kern_sendit (td=,
> > s=, mp=, flags=0, control=0x0,
> > segflg=) at ../../../kern/uipc_syscalls.c:848
> > #17 0x807e6abf in sendit (td=0xf800047caa00,
> > s=, mp=0xfe011b06da60,
> > flags=) at ../../../kern/uipc_syscalls.c:775
> > #18 0x807e690d in sys_sendto (td=0x0, uap=)
> > at ../../../kern/uipc_syscalls.c:899
> > #19 0x80a5b618 in amd64_syscall (td=, traced=0)
> > at subr_syscall.c:135
> > #20 0x80a3e44b in Xfast_syscall ()
> > at ../../../amd64/amd64/exception.S:396
> > #21 0x0008025d284a in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > Current language:  auto; currently minimal
> > 
> 
> There is a patch for this issue:
> 
> https://reviews.freebsd.org/D7209
> 
> You might try seeing if it solves your problem, and reporting that to
> the author
> 

work fine to me too on 12.0-CURRENT #26 r302424M
Thanks!

--
wbr, tiger

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

Re: (boost::)asio and kqueue problem

2016-07-19 Thread Sepherosa Ziehau 
On Wed, Jul 20, 2016 at 12:38 PM, Konstantin Belousov
 wrote:
> On Tue, Jul 19, 2016 at 05:35:59PM +0200, Hartmut Brandt wrote:
>> Hi,
>>
>> I'm trying to use asio (that's boost::asio without boost) to handle
>> listening sockets asynchronuosly. This appears not to work. There are also
>> some reports on the net about this problem. I was able to reproduce the
>> problem with a small C-programm that does the same steps as asio. The
>> relevant sequence of system calls is:
>>
>> kqueue()   = 3 (0x3)
>> socket(PF_INET,SOCK_STREAM,6)  = 4 (0x4)
>> setsockopt(0x4,0x,0x800,0x7fffea2c,0x4)= 0 (0x0)
>> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
>> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
>> setsockopt(0x4,0x,0x4,0x7fffea2c,0x4)  = 0 (0x0)
>> bind(4,{ AF_INET 0.0.0.0:8080 },16)= 0 (0x0)
>> listen(0x4,0x80)   = 0 (0x0)
>> ioctl(4,FIONBIO,0xea2c)= 0 (0x0)
>> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
>> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
>> kevent(3,0x0,0,0x7fffe5a0,32,0x0)  ERR#4 'Interrupted system 
>> call'
>>
>> The problem here is that asio registers each file descriptor with
>> EVFILT_READ and EVFILT_WRITE as soon as it is opened (first kevent call).
>> After bringing the socket into the listening state and when async_accept()
>> is called it registers the socket a second time. According to the man page
>> this is perfectly legal and can be used to modify the registration.
>>
>> With this sequence of calls kevent() does not return when a connection is
>> established successfully.
>>
>> I tracked down the problem and the reason is in soo_kqfilter(). This is
>> called for the first EVFILT_READ registration and decides based on the
>> SO_ACCEPTCONN flag which filter operations to use solisten_filtops or
>> soread_filtops. In this case it chooses soread_filtops.
>>
>> The second EVFILT_READ registration does not call soo_kqfilter() again,
>> but just updates the filter from the data and fflags field so the
>> listening socket ends up with the wrong filter operations.
>>
>> The attached patch fixes this (kind of) by using the f_touch
>> operation (currently used only by the user filter). The filt_sotouch()
>> function changes the operation pointer in the knote when the socket is now
>> in the listening state. I suppose that the required locking is already
>> done in kqueue_register(), but I'm not sure. Asynchronous accepting now 
>> works.
>>
>> A better fix would probably be to change the operation vector on all
>> knotes attached to the socket in solisten(), but I fear I don't have the
>> necessary understanding of the locking that is required for this.
>>
>> Could somebody with enough kqueue() knowledge look whether the patch is
>> correct lock-wise?
> I find it weird that the fix still requires re-registration of the socket
> event to get it working after socket is marked as listen.  In other words,
> until the re-registration is done, the events for the registered filter
> are lost.
>
> IMO more correct solution would be to merge the filt_solisten and
> filt_soread, deciding which path to take by testing the SO_ACCEPTCON
> flag in the f_event() op.

This is reasonable.

Thanks,
sephe

-- 
Tomorrow Will Never Die
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (boost::)asio and kqueue problem

2016-07-19 Thread Slawa Olhovchenkov 
On Wed, Jul 20, 2016 at 07:38:09AM +0300, Konstantin Belousov wrote:

> On Tue, Jul 19, 2016 at 05:35:59PM +0200, Hartmut Brandt wrote:
> > Hi,
> > 
> > I'm trying to use asio (that's boost::asio without boost) to handle 
> > listening sockets asynchronuosly. This appears not to work. There are also
> > some reports on the net about this problem. I was able to reproduce the 
> > problem with a small C-programm that does the same steps as asio. The 
> > relevant sequence of system calls is:
> > 
> > kqueue() = 3 (0x3)
> > socket(PF_INET,SOCK_STREAM,6)= 4 (0x4)
> > setsockopt(0x4,0x,0x800,0x7fffea2c,0x4)  = 0 (0x0)
> > kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
> > 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> > setsockopt(0x4,0x,0x4,0x7fffea2c,0x4)= 0 (0x0)
> > bind(4,{ AF_INET 0.0.0.0:8080 },16)  = 0 (0x0)
> > listen(0x4,0x80) = 0 (0x0)
> > ioctl(4,FIONBIO,0xea2c)  = 0 (0x0)
> > kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
> > 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> > kevent(3,0x0,0,0x7fffe5a0,32,0x0)ERR#4 'Interrupted 
> > system call'
> > 
> > The problem here is that asio registers each file descriptor with 
> > EVFILT_READ and EVFILT_WRITE as soon as it is opened (first kevent call). 
> > After bringing the socket into the listening state and when async_accept() 
> > is called it registers the socket a second time. According to the man page 
> > this is perfectly legal and can be used to modify the registration.
> > 
> > With this sequence of calls kevent() does not return when a connection is 
> > established successfully.
> > 
> > I tracked down the problem and the reason is in soo_kqfilter(). This is 
> > called for the first EVFILT_READ registration and decides based on the 
> > SO_ACCEPTCONN flag which filter operations to use solisten_filtops or 
> > soread_filtops. In this case it chooses soread_filtops.
> > 
> > The second EVFILT_READ registration does not call soo_kqfilter() again, 
> > but just updates the filter from the data and fflags field so the 
> > listening socket ends up with the wrong filter operations.
> > 
> > The attached patch fixes this (kind of) by using the f_touch 
> > operation (currently used only by the user filter). The filt_sotouch() 
> > function changes the operation pointer in the knote when the socket is now 
> > in the listening state. I suppose that the required locking is already 
> > done in kqueue_register(), but I'm not sure. Asynchronous accepting now 
> > works.
> > 
> > A better fix would probably be to change the operation vector on all 
> > knotes attached to the socket in solisten(), but I fear I don't have the 
> > necessary understanding of the locking that is required for this.
> > 
> > Could somebody with enough kqueue() knowledge look whether the patch is 
> > correct lock-wise?
> I find it weird that the fix still requires re-registration of the socket
> event to get it working after socket is marked as listen.  In other words,
> until the re-registration is done, the events for the registered filter
> are lost.
> 
> IMO more correct solution would be to merge the filt_solisten and
> filt_soread, deciding which path to take by testing the SO_ACCEPTCON
> flag in the f_event() op.
> 
> This should also eliminate the concerns with the patching of pointer
> which is not supposed to be changed.

may be this is related to netmap problem also?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

2016-07-19 Thread Warner Losh 
On Tue, Jul 19, 2016 at 1:12 PM, Ed Maste  wrote:
> dtc(1) is the Device Tree Compiler, used for embedded builds. We have
> two versions of dtc(1) in the FreeBSD tree: a GPLv2 one from
> https://git.kernel.org/cgit/utils/dtc/dtc.git and a BSD licensed one
> in https://svn.freebsd.org/base/head/usr.bin/dtc.
>
> We switched back to the GPL one since device tree files in the most
> recent import required features not available in our own at the time.
> However, as of r292876 the BSD licensed dtc(1) is functional and we
> should be able to switch back to it.
>
> I would encourage embedded users (primarily ARM boards) to test with
> WITHOUT_GPL_DTC in /etc/src.conf and report their success or failure.

My concern with this is overlay support. Overlay support for "shields" or
"badges" is going into upstream GPL dtc shortly. The patches have been
kicking around for a while and are almost ready to go in. We need this feature
and I'd planned on bringing it into the tree as soon as it goes into the git
repo. It's sorely needed for things like RPi and BBB that make it super
easy to add boards with parts that need a bit more DTB into the FDT to
describe them. There's been patches to bring this functionality into the
loader and into the in-tree gpl dtc floating around for a while now.

I know that the BSDL compiler doesn't support this. I know from painful
experience that the BSDL compiler is quite hard to fix grammar items
for since it doesn't use yacc, but uses a hand-coded parser / lexer. If
support could be added for this to that, we can throw the switch. Otherwise,
I don't think that it would be wise to switch.

Last time I ran my tests on the BSDL compiler, it failed a few of them. I'll
re-run to see if things have improved since I last checked it out and report
any failures here.

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

Re: (boost::)asio and kqueue problem

2016-07-19 Thread Konstantin Belousov 
On Tue, Jul 19, 2016 at 05:35:59PM +0200, Hartmut Brandt wrote:
> Hi,
> 
> I'm trying to use asio (that's boost::asio without boost) to handle 
> listening sockets asynchronuosly. This appears not to work. There are also
> some reports on the net about this problem. I was able to reproduce the 
> problem with a small C-programm that does the same steps as asio. The 
> relevant sequence of system calls is:
> 
> kqueue()   = 3 (0x3)
> socket(PF_INET,SOCK_STREAM,6)  = 4 (0x4)
> setsockopt(0x4,0x,0x800,0x7fffea2c,0x4)= 0 (0x0)
> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> setsockopt(0x4,0x,0x4,0x7fffea2c,0x4)  = 0 (0x0)
> bind(4,{ AF_INET 0.0.0.0:8080 },16)= 0 (0x0)
> listen(0x4,0x80)   = 0 (0x0)
> ioctl(4,FIONBIO,0xea2c)= 0 (0x0)
> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> kevent(3,0x0,0,0x7fffe5a0,32,0x0)  ERR#4 'Interrupted system call'
> 
> The problem here is that asio registers each file descriptor with 
> EVFILT_READ and EVFILT_WRITE as soon as it is opened (first kevent call). 
> After bringing the socket into the listening state and when async_accept() 
> is called it registers the socket a second time. According to the man page 
> this is perfectly legal and can be used to modify the registration.
> 
> With this sequence of calls kevent() does not return when a connection is 
> established successfully.
> 
> I tracked down the problem and the reason is in soo_kqfilter(). This is 
> called for the first EVFILT_READ registration and decides based on the 
> SO_ACCEPTCONN flag which filter operations to use solisten_filtops or 
> soread_filtops. In this case it chooses soread_filtops.
> 
> The second EVFILT_READ registration does not call soo_kqfilter() again, 
> but just updates the filter from the data and fflags field so the 
> listening socket ends up with the wrong filter operations.
> 
> The attached patch fixes this (kind of) by using the f_touch 
> operation (currently used only by the user filter). The filt_sotouch() 
> function changes the operation pointer in the knote when the socket is now 
> in the listening state. I suppose that the required locking is already 
> done in kqueue_register(), but I'm not sure. Asynchronous accepting now works.
> 
> A better fix would probably be to change the operation vector on all 
> knotes attached to the socket in solisten(), but I fear I don't have the 
> necessary understanding of the locking that is required for this.
> 
> Could somebody with enough kqueue() knowledge look whether the patch is 
> correct lock-wise?
I find it weird that the fix still requires re-registration of the socket
event to get it working after socket is marked as listen.  In other words,
until the re-registration is done, the events for the registered filter
are lost.

IMO more correct solution would be to merge the filt_solisten and
filt_soread, deciding which path to take by testing the SO_ACCEPTCON
flag in the f_event() op.

This should also eliminate the concerns with the patching of pointer
which is not supposed to be changed.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build became unstable: FreeBSD_HEAD #471

2016-07-19 Thread jenkins-admin 
See 

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

Build failed in Jenkins: FreeBSD_HEAD_sparc64 #184

2016-07-19 Thread jenkins-admin 
See 

--
[...truncated 98037 lines...]
--- getdelim_test.full ---
cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign  -o 
getdelim_test.full getdelim_test.o  -lprivateatf-c
--- all_subdir_kerberos5 ---
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/client.c:
 In function 'kcm_ccache_resolve_client':
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/client.c:50:
 warning: 'krb5_get_err_text' is deprecated (declared at 
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/krb5/krb5-protos.h:2134)
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/client.c:
 In function 'kcm_ccache_destroy_client':
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/client.c:74:
 warning: 'krb5_get_err_text' is deprecated (declared at 
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/krb5/krb5-protos.h:2134)
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/client.c:
 In function 'kcm_ccache_new_client':
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/client.c:131:
 warning: 'krb5_get_err_text' is deprecated (declared at 
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/krb5/krb5-protos.h:2134)
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/client.c:143:
 warning: 'krb5_get_err_text' is deprecated (declared at 
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/krb5/krb5-protos.h:2134)
--- all_subdir_gnu ---
--- tree-ssa-operands.o ---
cc   -O2 -pipe   -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" 
-I/builds/workspace/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools
 -I/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber
 -MD  -MF.depend.tree-ssa-operands.o -MTtree-ssa-operands.o -std=gnu89 
-fstack-protector-strong  -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tre
 e-ssa-operands.c -o tree-ssa-operands.o
--- all_subdir_lib ---
--- getdelim_test.debug ---
objcopy --only-keep-debug getdelim_test.full getdelim_test.debug
--- getdelim_test ---
objcopy --strip-debug --add-gnu-debuglink=getdelim_test.debug  
getdelim_test.full getdelim_test
--- mkostemp_test ---
(cd /builds/workspace/FreeBSD_HEAD_sparc64/src/lib/libc/tests/stdio &&  
DEPENDFILE=.depend.mkostemp_test  NO_SUBDIR=1 
/builds/workspace/FreeBSD_HEAD_sparc64/obj/builds/workspace/FreeBSD_HEAD_sparc64/src/make.amd64/bmake
 -f /builds/workspace/FreeBSD_HEAD_sparc64/src/lib/libc/tests/stdio/Makefile 
_RECURSING_PROGS=t  PROG=mkostemp_test )
--- all_subdir_kerberos5 ---
--- config.o ---
cc  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/krb5
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/asn1
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/roken
  
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm
 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/lib/ipc
-DHAVE_CONFIG_H 
-I/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../include
 -g -MD  -MF.depend.config.o -MTconfig.o -std=gnu99 -fstack-protector-strong
  -c 
/builds/workspace/FreeBSD_HEAD_sparc64/src/kerberos5/libexec/kcm/../../../crypto/heimdal/kcm/config.c
 -o config.o
--- all_subdir_lib ---
--- .depend.mkostemp_test ---
echo mkostemp_test.full: 
/builds/workspace/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/workspace/FreeBSD_HEAD_sparc64/src/tmp/usr/lib/libc.a
 
/builds/workspace/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/workspace/FreeBSD_HEAD_sparc64/src/tmp/usr/lib/libprivateatf-c.a
 >> .depend.mkostemp_test
--- mkostemp_test.o ---
cc  -O2 -pipe   -g -MD  -MF.depend.mkostemp_test.mkostemp_test.o 
-MTmkostemp_test.o -std=gnu99 -

FreeBSD_HEAD_i386 - Build #3631 - Fixed

2016-07-19 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3631 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3631/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3631/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3631/console

Change summaries:

303046 by pfg:
libc: tag the Rune initialization function prototypes visibility as hidden.

It is good practice to export as few symbols as possible from your shared
libraries, so use the GCC visibility attribute in this case, matching what
Apple's libc does.

Reference:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html

Hinted by:  Apple's libc 1082.20.4
MFC after:  1 week

303045 by emaste:
arch.7: correct MIPS endianness transcription error

Submitted by:   Nikolai Lifanov 

303044 by emaste:
arch.7: we also use 1M page mappings on armv6

Submitted by:   alc

303043 by cem:
Increase vt(4) framebuffer maximum size

And rename "DEFAULT" constants to the more accurate "MAX."

PR: 210382
Submitted by:   Felix 
Reviewed by:wblock, cem
Tested by:  Dave Cottlehuber 

303042 by scottl:
Remove unused variable from last commit.

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

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

2016-07-19 Thread Emmanuel Vadot 

 Hello,

 I've just tried bsd dtc on all arm dts that we have.
 It doesn't seems to handle multiple include directories.
 Here is how to reproduce :

 $ export SRCROOT=/path/to/fbsd/src
 $ export MACHINE=arm
 $ cd $SRCROOT/sys/boot/fdt/dts/arm
 $ $SRCROOT/sys/tools/fdt/make_dtb.sh $SRCROOT/sys
beaglebone-black.dts . converting beaglebone-black.dts
-> ./beaglebone-black.dtb Unable to open file
'/home/elbarto/Work/freebsd/freebsd.git//sys/boot/fdt/dts/arm/am33xx-clocks.dtsi'.
No such file or directory Unable to open file
'/home/elbarto/Work/freebsd/freebsd.git//sys/boot/fdt/dts/arm/tps65217.dtsi'.
No such file or directory

 Both dtsi files are include with /include/ (i.e. not handled by cpp).
 make_dtb.sh specify : -i $S/boot/fdt/dts/${MACHINE} -i
$S/gnu/dts/${MACHINE}, it looks like the second one isn't added to the
list.

 Trying tegra124-jetson-tk1-fbsd.dts give this :
converting tegra124-jetson-tk1-fbsd.dts
-> /tmp/bsd_dtb//tegra124-jetson-tk1-fbsd.dtb Error on line 1214:
Expected node name interrupt-affinity = <&{/cpus/cpu@0}>,
 ^
Error on line 1214: Expected ; at end of property
  interrupt-affinity = <&{/cpus/cpu@0}>,
 ^
Failed to parse tree.  Unhappy face!

 Cheers,

On Tue, 19 Jul 2016 15:12:02 -0400
Ed Maste  wrote:

> dtc(1) is the Device Tree Compiler, used for embedded builds. We have
> two versions of dtc(1) in the FreeBSD tree: a GPLv2 one from
> https://git.kernel.org/cgit/utils/dtc/dtc.git and a BSD licensed one
> in https://svn.freebsd.org/base/head/usr.bin/dtc.
> 
> We switched back to the GPL one since device tree files in the most
> recent import required features not available in our own at the time.
> However, as of r292876 the BSD licensed dtc(1) is functional and we
> should be able to switch back to it.
> 
> I would encourage embedded users (primarily ARM boards) to test with
> WITHOUT_GPL_DTC in /etc/src.conf and report their success or failure.
> 
> -Ed
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

Call for Testing: Switching back to our BSD licensed dtc(1)

2016-07-19 Thread Ed Maste 
dtc(1) is the Device Tree Compiler, used for embedded builds. We have
two versions of dtc(1) in the FreeBSD tree: a GPLv2 one from
https://git.kernel.org/cgit/utils/dtc/dtc.git and a BSD licensed one
in https://svn.freebsd.org/base/head/usr.bin/dtc.

We switched back to the GPL one since device tree files in the most
recent import required features not available in our own at the time.
However, as of r292876 the BSD licensed dtc(1) is functional and we
should be able to switch back to it.

I would encourage embedded users (primarily ARM boards) to test with
WITHOUT_GPL_DTC in /etc/src.conf and report their success or failure.

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

Re: (boost::)asio and kqueue problem

2016-07-19 Thread Adrian Chadd 
heh, nice catch. Would you please file a PR so we don't forget?

Thanks!


-a


On 19 July 2016 at 08:35, Hartmut Brandt  wrote:
> Hi,
>
> I'm trying to use asio (that's boost::asio without boost) to handle
> listening sockets asynchronuosly. This appears not to work. There are also
> some reports on the net about this problem. I was able to reproduce the
> problem with a small C-programm that does the same steps as asio. The
> relevant sequence of system calls is:
>
> kqueue() = 3 (0x3)
> socket(PF_INET,SOCK_STREAM,6)= 4 (0x4)
> setsockopt(0x4,0x,0x800,0x7fffea2c,0x4)  = 0 (0x0)
> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0
> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> setsockopt(0x4,0x,0x4,0x7fffea2c,0x4)= 0 (0x0)
> bind(4,{ AF_INET 0.0.0.0:8080 },16)  = 0 (0x0)
> listen(0x4,0x80) = 0 (0x0)
> ioctl(4,FIONBIO,0xea2c)  = 0 (0x0)
> kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0
> 4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
> kevent(3,0x0,0,0x7fffe5a0,32,0x0)ERR#4 'Interrupted system
> call'
>
> The problem here is that asio registers each file descriptor with
> EVFILT_READ and EVFILT_WRITE as soon as it is opened (first kevent call).
> After bringing the socket into the listening state and when async_accept()
> is called it registers the socket a second time. According to the man page
> this is perfectly legal and can be used to modify the registration.
>
> With this sequence of calls kevent() does not return when a connection is
> established successfully.
>
> I tracked down the problem and the reason is in soo_kqfilter(). This is
> called for the first EVFILT_READ registration and decides based on the
> SO_ACCEPTCONN flag which filter operations to use solisten_filtops or
> soread_filtops. In this case it chooses soread_filtops.
>
> The second EVFILT_READ registration does not call soo_kqfilter() again, but
> just updates the filter from the data and fflags field so the listening
> socket ends up with the wrong filter operations.
>
> The attached patch fixes this (kind of) by using the f_touch operation
> (currently used only by the user filter). The filt_sotouch() function
> changes the operation pointer in the knote when the socket is now in the
> listening state. I suppose that the required locking is already done in
> kqueue_register(), but I'm not sure. Asynchronous accepting now works.
>
> A better fix would probably be to change the operation vector on all knotes
> attached to the socket in solisten(), but I fear I don't have the necessary
> understanding of the locking that is required for this.
>
> Could somebody with enough kqueue() knowledge look whether the patch is
> correct lock-wise?
>
> Regards,
> harti
>
> Index: kern_event.c
> ===
> --- kern_event.c(revision 302977)
> +++ kern_event.c(working copy)
> @@ -1350,8 +1350,8 @@
> KQ_UNLOCK(kq);
> knl = kn_list_lock(kn);
> kn->kn_kevent.udata = kev->udata;
> -   if (!fops->f_isfd && fops->f_touch != NULL) {
> -   fops->f_touch(kn, kev, EVENT_REGISTER);
> +   if (kn->kn_fop->f_touch != NULL) {
> +   kn->kn_fop->f_touch(kn, kev, EVENT_REGISTER);
> } else {
> kn->kn_sfflags = kev->fflags;
> kn->kn_sdata = kev->data;
> Index: uipc_socket.c
> ===
> --- uipc_socket.c   (revision 302977)
> +++ uipc_socket.c   (working copy)
> @@ -160,6 +160,7 @@
>  static voidfilt_sowdetach(struct knote *kn);
>  static int filt_sowrite(struct knote *kn, long hint);
>  static int filt_solisten(struct knote *kn, long hint);
> +static voidfilt_sotouch(struct knote *kn, struct kevent *kev, u_long
> type);
>  static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t
> h_id);
>  fo_kqfilter_t  soo_kqfilter;
>
> @@ -172,6 +173,7 @@
> .f_isfd = 1,
> .f_detach = filt_sordetach,
> .f_event = filt_soread,
> +   .f_touch = filt_sotouch,
>  };
>  static struct filterops sowrite_filtops = {
> .f_isfd = 1,
> @@ -3091,6 +3093,31 @@
> return (0);
>  }
>
> +static void
> +filt_sotouch(struct knote *kn, struct kevent *kev, u_long type)
> +{
> +   struct socket *so = kn->kn_fp->f_data;
> +
> +   switch (type) {
> +   case EVENT_REGISTER:
> +   if (kn->kn_fop == &soread_filtops &&
> +   (so->so_options & SO_ACCEPTCONN))
> +   kn->kn_fop = &solisten_filtops;
> +
> +   kn->kn_sfflags = kev->fflags;
> +   kn->kn_sdata = kev->data;
> +   break;
> +
> +case EVENT_PROCESS:
> +   *kev = kn->kn_kevent;
> +   break;
> +
> +

Re: Issue of `make distribueworld` with normal user and customized DESTDIR

2016-07-19 Thread Bryan Drewery 
On 7/19/16 9:55 AM, Li-Wen Hsu wrote:
> On Tue, Jul 19, 2016 at 09:35:48 -0700, Bryan Drewery wrote:
>> On 7/19/16 9:14 AM, Bryan Drewery wrote:
>>> On 7/19/16 12:07 AM, Li-Wen Hsu wrote:
 Hi Bryan,

 I am trying to create snapshot *.txz in our CI system, using
 script like this:

 https://gist.github.com/lwhsu/93ece918767694942e9f12186731c622

 Basically it does are build/distribue/package world and kernel with normal
 user, and customize directories.

 But then I hit some problems like trying to install or find files under 
 /base,
 after some research, I have the attached patch to make it work.

 How do you think of this?  Do you have any suggestion about how to test 
 this?

>>>
>>> It seems odd that it would have gone unnoticed for over 14 years.  Still
>>> looking at it.
>>>
 BTW, what's the suitabl mailing list to discuss stuff like this?
>>>
>>> current@ is as good as it gets right now.
>>>

 Thanks,
 Li-Wen

>>>
>>>
>>
>> build(7) has it documented that DISTDIR should be used for
>> packageworld/packagekernel/distributeworld.  I think you should be
>> specifying that instead of DESTDIR.  It seems that originally DISTDIR
>> was intended to be its own thing that had a higher priority than
>> DESTDIR; that DISTDIR was not supposed to be in DESTDIR.  Several places
>> in the build assume this, such as in release/Makefile.  I think that
>> over time people have been adding ${DESTDIR}/${DISTDIR} in Makefile.inc1
>> as a mistake.
> 
> I see, thanks very much for your explanation, I read build(7) but got
> confused by ${DESTDIR}/${DISTDIR} everywhere.
> 
> Maybe we should clean it up after 11.0-R?  Or it's OK to start now?
> 

I think that it would be too risky to apply your change as scripts and
people may be expecting DISTDIR to override DESTDIR.  But it may also be
the opposite for some new targets that have been added.  I'm not sure
what to do.  Needs more discussion in public.

By the way, your "/base" issue is likely a bug either way as things
should probably just work if you don't specify DISTDIR.


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

(boost::)asio and kqueue problem

2016-07-19 Thread Hartmut Brandt 

Hi,

I'm trying to use asio (that's boost::asio without boost) to handle 
listening sockets asynchronuosly. This appears not to work. There are also
some reports on the net about this problem. I was able to reproduce the 
problem with a small C-programm that does the same steps as asio. The 
relevant sequence of system calls is:


kqueue() = 3 (0x3)
socket(PF_INET,SOCK_STREAM,6)= 4 (0x4)
setsockopt(0x4,0x,0x800,0x7fffea2c,0x4)  = 0 (0x0)
kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
setsockopt(0x4,0x,0x4,0x7fffea2c,0x4)= 0 (0x0)
bind(4,{ AF_INET 0.0.0.0:8080 },16)  = 0 (0x0)
listen(0x4,0x80) = 0 (0x0)
ioctl(4,FIONBIO,0xea2c)  = 0 (0x0)
kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 
4,EVFILT_WRITE,EV_ADD|EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) = 0 (0x0)
kevent(3,0x0,0,0x7fffe5a0,32,0x0)ERR#4 'Interrupted system call'

The problem here is that asio registers each file descriptor with 
EVFILT_READ and EVFILT_WRITE as soon as it is opened (first kevent call). 
After bringing the socket into the listening state and when async_accept() 
is called it registers the socket a second time. According to the man page 
this is perfectly legal and can be used to modify the registration.


With this sequence of calls kevent() does not return when a connection is 
established successfully.


I tracked down the problem and the reason is in soo_kqfilter(). This is 
called for the first EVFILT_READ registration and decides based on the 
SO_ACCEPTCONN flag which filter operations to use solisten_filtops or 
soread_filtops. In this case it chooses soread_filtops.


The second EVFILT_READ registration does not call soo_kqfilter() again, 
but just updates the filter from the data and fflags field so the 
listening socket ends up with the wrong filter operations.


The attached patch fixes this (kind of) by using the f_touch 
operation (currently used only by the user filter). The filt_sotouch() 
function changes the operation pointer in the knote when the socket is now 
in the listening state. I suppose that the required locking is already 
done in kqueue_register(), but I'm not sure. Asynchronous accepting now works.


A better fix would probably be to change the operation vector on all 
knotes attached to the socket in solisten(), but I fear I don't have the 
necessary understanding of the locking that is required for this.


Could somebody with enough kqueue() knowledge look whether the patch is 
correct lock-wise?


Regards,
harti

Index: kern_event.c
===
--- kern_event.c(revision 302977)
+++ kern_event.c(working copy)
@@ -1350,8 +1350,8 @@
KQ_UNLOCK(kq);
knl = kn_list_lock(kn);
kn->kn_kevent.udata = kev->udata;
-   if (!fops->f_isfd && fops->f_touch != NULL) {
-   fops->f_touch(kn, kev, EVENT_REGISTER);
+   if (kn->kn_fop->f_touch != NULL) {
+   kn->kn_fop->f_touch(kn, kev, EVENT_REGISTER);
} else {
kn->kn_sfflags = kev->fflags;
kn->kn_sdata = kev->data;
Index: uipc_socket.c
===
--- uipc_socket.c   (revision 302977)
+++ uipc_socket.c   (working copy)
@@ -160,6 +160,7 @@
 static voidfilt_sowdetach(struct knote *kn);
 static int filt_sowrite(struct knote *kn, long hint);
 static int filt_solisten(struct knote *kn, long hint);
+static voidfilt_sotouch(struct knote *kn, struct kevent *kev, u_long type);
 static int inline hhook_run_socket(struct socket *so, void *hctx, int32_t 
h_id);
 fo_kqfilter_t  soo_kqfilter;

@@ -172,6 +173,7 @@
.f_isfd = 1,
.f_detach = filt_sordetach,
.f_event = filt_soread,
+   .f_touch = filt_sotouch,
 };
 static struct filterops sowrite_filtops = {
.f_isfd = 1,
@@ -3091,6 +3093,31 @@
return (0);
 }

+static void
+filt_sotouch(struct knote *kn, struct kevent *kev, u_long type)
+{
+   struct socket *so = kn->kn_fp->f_data;
+
+   switch (type) {
+   case EVENT_REGISTER:
+   if (kn->kn_fop == &soread_filtops &&
+   (so->so_options & SO_ACCEPTCONN))
+   kn->kn_fop = &solisten_filtops;
+
+   kn->kn_sfflags = kev->fflags;
+   kn->kn_sdata = kev->data;
+   break;
+
+case EVENT_PROCESS:
+   *kev = kn->kn_kevent;
+   break;
+
+   default:
+   panic("filt_sotouch() - invalid type (%ld)", type);
+   break;
+   }
+}
+
 /*
  * Some routines that return EOPNOTSUPP for entry points that are not
  * supported by a protocol.  Fill in as needed.#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include

Re: panic: softclock_call_cc: act 0xfffff80c036eec00 0

2016-07-19 Thread Glen Barber 
On Tue, Jul 19, 2016 at 10:08:40AM +0200, Peter Holm wrote:
> Got this while testing a patch:
> 
> panic: softclock_call_cc: act 0xf80c036eec00 0
> cpuid = 22
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0f940c97d0
> vpanic() at vpanic+0x182/frame 0xfe0f940c9850
> kassert_panic() at kassert_panic+0x126/frame 0xfe0f940c98c0
> softclock_call_cc() at softclock_call_cc+0x5ad/frame 0xfe0f940c99c0
> softclock() at softclock+0x47/frame 0xfe0f940c99e0
> intr_event_execute_handlers() at intr_event_execute_handlers+0x96/frame 
> 0xfe0f940c9a20
> ithread_loop() at ithread_loop+0xa6/frame 0xfe0f940c9a70
> fork_exit() at fork_exit+0x84/frame 0xfe0f940c9ab0
> 
> https://people.freebsd.org/~pho/stress/log/kostik920.txt
> 

Unfortunately, so did others.  :(

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884

Glen



signature.asc
Description: PGP signature

panic: softclock_call_cc: act 0xfffff80c036eec00 0

2016-07-19 Thread Peter Holm 
Got this while testing a patch:

panic: softclock_call_cc: act 0xf80c036eec00 0
cpuid = 22
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0f940c97d0
vpanic() at vpanic+0x182/frame 0xfe0f940c9850
kassert_panic() at kassert_panic+0x126/frame 0xfe0f940c98c0
softclock_call_cc() at softclock_call_cc+0x5ad/frame 0xfe0f940c99c0
softclock() at softclock+0x47/frame 0xfe0f940c99e0
intr_event_execute_handlers() at intr_event_execute_handlers+0x96/frame 
0xfe0f940c9a20
ithread_loop() at ithread_loop+0xa6/frame 0xfe0f940c9a70
fork_exit() at fork_exit+0x84/frame 0xfe0f940c9ab0

https://people.freebsd.org/~pho/stress/log/kostik920.txt

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