Re: Segmentation fault running ntpd

2015-10-30 Thread NGie Cooper 

> On Oct 30, 2015, at 01:42, Dag-Erling Smørgrav  wrote:
> 
> David Wolfskill  writes:
>> ...
>> bound to 172.17.1.245 -- renewal in 43200 seconds.
>> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
>> Starting Network: lo0 em0 iwn0 lagg0.
>> ...
> 
> Did you find a solution?  I'm wondering if the ntpd problems people are
> reporting on freebsd-security@ are related.  I vaguely recall hearing
> that this had been traced to a pthread bug, but can't find anything
> about it in commit logs or mailing list archives.

https://svnweb.freebsd.org/changeset/base/287591 ?
___
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: Segmentation fault running ntpd

2015-10-30 Thread Dag-Erling Smørgrav 
NGie Cooper  writes:
> Dag-Erling Smørgrav  writes:
> > David Wolfskill  writes:
> > > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
> > Did you find a solution?  [...]
> https://svnweb.freebsd.org/changeset/base/287591 ?

Are you certain?  The commit message does not mention David or ntpd.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: Segmentation fault running ntpd

2015-10-30 Thread Dag-Erling Smørgrav 
David Wolfskill  writes:
> ...
> bound to 172.17.1.245 -- renewal in 43200 seconds.
> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
> Starting Network: lo0 em0 iwn0 lagg0.
> ...

Did you find a solution?  I'm wondering if the ntpd problems people are
reporting on freebsd-security@ are related.  I vaguely recall hearing
that this had been traced to a pthread bug, but can't find anything
about it in commit logs or mailing list archives.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread Bryan Drewery 
On 10/30/2015 1:57 PM, NGie Cooper wrote:
> Hi Bryan/Simon!
>   I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS 
> and I ran into this linker issue below. I have no idea (yet) why it’s trying 
> to compile an x64 object when I specify powerpc/powerpc — and more 
> importantly, why is the object not being put in obj.powerpc?
>   I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
> tinderbox".
> Thanks!
> -NGie
> 

Have you modified any of your local toolchain handling, or skipped
CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
there to be a lot more reports if there was a problem with buildworld
cross compiling.

> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
> …
> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
> _RECURSING_PROGS=  PROG=tst.usdt.exe )
> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json 
> -std=gnu99 -fstack-protector-strong-c 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>  -o tst.usdt.o
> dtrace -C -x nolibs -G -o usdt.o -s 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
> tst.usdt.o
> dtrace: failed to link script 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: 
> incorrect ELF machine type for object file: tst.usdt.o
> *** Error code 1
> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread NGie Cooper 
Hi Bryan/Simon!
I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS 
and I ran into this linker issue below. I have no idea (yet) why it’s trying to 
compile an x64 object when I specify powerpc/powerpc — and more importantly, 
why is the object not being put in obj.powerpc?
I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
tinderbox".
Thanks!
-NGie

% make buildworld TARGET=powerpc TARGET_ARCH=powerpc
…
===> cddl/usr.sbin/dtrace/tests/common/json (all)
(cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS=  
PROG=tst.usdt.exe )
cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
-I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json 
-std=gnu99 -fstack-protector-strong-c 
/usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
 -o tst.usdt.o
dtrace -C -x nolibs -G -o usdt.o -s 
/usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
tst.usdt.o
dtrace: failed to link script 
/usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: 
incorrect ELF machine type for object file: tst.usdt.o
*** Error code 1
$ find /usr/obj/usr/src/svn/ -name tst.usdt.o
/usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
$ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
/usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
___
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"

[HEADSUP] OpenSSL updated to 1.0.2d

2015-10-30 Thread Jung-uk Kim 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL on head has been updated to 1.0.2d.  Please make sure to
recompile all binaries depending on libcrypto.so.7 or libssl.so.7.

Cheers!

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWM9nDAAoJEHyflib82/FGuV8H+gKZRDJ/FvPQ/D5wCTBddfgJ
0i8ptgdzWtSABOSOUeKYBceHhiHUOjlnl2UdMv3JWq6virqCx1YXlJTIHACeZL7D
SSqyuMT3qfZFLwi8fw/dnzgIZx1N86wQlIZOU/3807SN0+h0uCcOq1/Dj/j/wsQx
XpM/tLgnQfqiRSl8pZPUleyOKqqhrFv+pJv7uybAQzTwdQ03pzhd694dy4futsg2
wxFLUK8BbXWv1ZW37wDysyMyaem02nqCMYUXPoGfjMEwN6DFsx3WVUyKpZxMYQ8x
fNtV3l61tXRczQWzh/rnslSxjbbjMlS4/DKt2x+mzHELUFiOoPqc3/z0CgFUoNk=
=Wa/Z
-END PGP SIGNATURE-
___
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: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread Bryan Drewery 
On 10/30/2015 2:21 PM, Bryan Drewery wrote:
> On 10/30/2015 1:57 PM, NGie Cooper wrote:
>> Hi Bryan/Simon!
>>  I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS 
>> and I ran into this linker issue below. I have no idea (yet) why it’s trying 
>> to compile an x64 object when I specify powerpc/powerpc — and more 
>> importantly, why is the object not being put in obj.powerpc?
>>  I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
>> tinderbox".
>> Thanks!
>> -NGie
>>
> 
> Have you modified any of your local toolchain handling, or skipped
> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
> there to be a lot more reports if there was a problem with buildworld
> cross compiling.
> 
>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>> …
>> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>> _RECURSING_PROGS=  PROG=tst.usdt.exe )
>> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>>  -std=gnu99 -fstack-protector-strong-c 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>>  -o tst.usdt.o
>> dtrace -C -x nolibs -G -o usdt.o -s 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
>> tst.usdt.o
>> dtrace: failed to link script 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>  incorrect ELF machine type for object file: tst.usdt.o
>> *** Error code 1
>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
>>

I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
to be fine with PROGS.  Here's a test object built via PROGS:

~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
~/git/freebsd # file
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
not stripped
-rw-r--r--  1 root  wheel  21136 Oct 23 17:08
/usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o

I see nothing special with the DTRACE_TESTS to change any of this.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread Mark Johnston 
On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote:
> On 10/30/2015 3:03 PM, NGie Cooper wrote:
> > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery  wrote:
> >> On 10/30/2015 2:21 PM, Bryan Drewery wrote:
> >>> On 10/30/2015 1:57 PM, NGie Cooper wrote:
>  Hi Bryan/Simon!
>   I tried doing buildworld on powerpc/powerpc with 
>  -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no 
>  idea (yet) why it’s trying to compile an x64 object when I specify 
>  powerpc/powerpc — and more importantly, why is the object not being put 
>  in obj.powerpc?
>   I ran into the same issue on ref11-amd64.freebsd.org when I ran 
>  “make tinderbox".
>  Thanks!
>  -NGie
> 
> >>>
> >>> Have you modified any of your local toolchain handling, or skipped
> >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
> >>> there to be a lot more reports if there was a problem with buildworld
> >>> cross compiling.
> >>>
>  % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>  …
>  ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>  (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>  DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>  /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>  _RECURSING_PROGS=  PROG=tst.usdt.exe )
>  cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>  -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>   -std=gnu99 -fstack-protector-strong-c 
>  /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>   -o tst.usdt.o
>  dtrace -C -x nolibs -G -o usdt.o -s 
>  /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>   tst.usdt.o
>  dtrace: failed to link script 
>  /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>   incorrect ELF machine type for object file: tst.usdt.o
>  *** Error code 1
> 
> The problem looks specific to compiling of .d files using dtrace(1). It
> must not have cross-compile support.
> 
> The manpage does say: "The D compiler produces programs using the native
> data model of the operating system kernel.".
> 
> So these will need to be disabled for non-native builds.
> 
> I don't know if it would be possible to build a cross-compile version of
> dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work.

In the snippet above, tst.usdt.o is generated by cc, not dtrace(1).
dtrace is complaining that the input file doesn't have the expected
machine type, which seems valid given the file(1) output below.

> 
>  $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>  /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>  $ file 
>  /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>  /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: 
>  ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
> 
> >>
> >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
> >> to be fine with PROGS.  Here's a test object built via PROGS:
> >>
> >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> >> ~/git/freebsd # file
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
> >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
> >> not stripped
> >> -rw-r--r--  1 root  wheel  21136 Oct 23 17:08
> >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> >>
> >> I see nothing special with the DTRACE_TESTS to change any of this.
> > 
> > I could see there being a possible issue with my host VM, but I
> > haven't modified my environment in ref11-amd64.freebsd.org at all.
> > 
> > Could you please try reproing it there with your user?
> > 
> > Thanks,
> > -NGie
> > 
> 
> 
> -- 
> 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"

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread Bryan Drewery 
On 10/30/2015 4:08 PM, Mark Johnston wrote:
> On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote:
>> On 10/30/2015 3:03 PM, NGie Cooper wrote:
>>> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery  wrote:
 On 10/30/2015 2:21 PM, Bryan Drewery wrote:
> On 10/30/2015 1:57 PM, NGie Cooper wrote:
>> Hi Bryan/Simon!
>>  I tried doing buildworld on powerpc/powerpc with 
>> -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no 
>> idea (yet) why it’s trying to compile an x64 object when I specify 
>> powerpc/powerpc — and more importantly, why is the object not being put 
>> in obj.powerpc?
>>  I ran into the same issue on ref11-amd64.freebsd.org when I ran 
>> “make tinderbox".
>> Thanks!
>> -NGie
>>
>
> Have you modified any of your local toolchain handling, or skipped
> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
> there to be a lot more reports if there was a problem with buildworld
> cross compiling.
>
>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>> …
>> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>> _RECURSING_PROGS=  PROG=tst.usdt.exe )
>> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>>  -std=gnu99 -fstack-protector-strong-c 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>>  -o tst.usdt.o
>> dtrace -C -x nolibs -G -o usdt.o -s 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>>  tst.usdt.o
>> dtrace: failed to link script 
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>  incorrect ELF machine type for object file: tst.usdt.o
>> *** Error code 1
>>
>> The problem looks specific to compiling of .d files using dtrace(1). It
>> must not have cross-compile support.
>>
>> The manpage does say: "The D compiler produces programs using the native
>> data model of the operating system kernel.".
>>
>> So these will need to be disabled for non-native builds.
>>
>> I don't know if it would be possible to build a cross-compile version of
>> dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work.
> 
> In the snippet above, tst.usdt.o is generated by cc, not dtrace(1).
> dtrace is complaining that the input file doesn't have the expected
> machine type, which seems valid given the file(1) output below.
> 

The example output must be a mistake as they are correct on ref11:

ref11-amd64% find
/scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
-name tst.usdt.o -exec file {} +
/scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
  ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
  ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
  ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1
(FreeBSD), not stripped
/scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
(FreeBSD), not stripped

[sorry for bad mail client]



>>
>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> $ file 
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>>

Re: Segmentation fault running ntpd

2015-10-30 Thread Dag-Erling Smørgrav 
Franco Fichtner  writes:
> Well, it’s on stable/10 since September 16 and somebody reported that
> this particular branch would not trigger the crash along with HEAD,
> but any 10.x would.  Can’t find the reference right now though.

OK, we should do an EN with that patch then, but we may have to include
some of the other recent commits to the vm_map.c, which seem (at a quick
glance) to be related.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: Segmentation fault running ntpd

2015-10-30 Thread NGie Cooper 

> On Oct 30, 2015, at 02:32, Franco Fichtner  wrote:
> 
> Well, it’s on stable/10 since September 16 and somebody reported that
> this particular branch would not trigger the crash along with HEAD,
> but any 10.x would.  Can’t find the reference right now though.

You’re right. My Mail.app search fu was failing me for a minute..


r287846 | kib | 2015-09-15 21:20:39 -0700 (Tue, 15 Sep 2015) | 4 lines

MFC r287591:
There is no reason in the current kernel to disallow write access to
the COW wired entry if the entry permissions allow it.  Remove the check.

___
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: Segmentation fault running ntpd

2015-10-30 Thread Franco Fichtner 
Well, it’s on stable/10 since September 16 and somebody reported that
this particular branch would not trigger the crash along with HEAD,
but any 10.x would.  Can’t find the reference right now though.


> On 30 Oct 2015, at 10:24 am, NGie Cooper  wrote:
> 
> 
>> On Oct 30, 2015, at 02:18, Franco Fichtner  wrote:
>> 
>> Hi all,
>> 
>> I did a quick test build and this seems to solve the ntpd crash issue
>> on top of releng/10.1.
> 
> Makes sense … looking through my email r287591 was never MFCed back to 
> stable/9 or stable/10 :/ .
> HTH,
> -NGie
> ___
> 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"

___
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: Segmentation fault running ntpd

2015-10-30 Thread Matthew Seaman 
On 10/30/15 09:32, Franco Fichtner wrote:
> Well, it’s on stable/10 since September 16 and somebody reported that
> this particular branch would not trigger the crash along with HEAD,
> but any 10.x would.  Can’t find the reference right now though.

That was me, amongst others.  There are threads on security@ and questions@.

>> On 30 Oct 2015, at 10:24 am, NGie Cooper  wrote:
>>
>>
>>> On Oct 30, 2015, at 02:18, Franco Fichtner  wrote:
>>>
>>> Hi all,
>>>
>>> I did a quick test build and this seems to solve the ntpd crash issue
>>> on top of releng/10.1.
>>
>> Makes sense … looking through my email r287591 was never MFCed back to 
>> stable/9 or stable/10 :/ .
>> HTH,
>> -NGie

There were two problems reported:

1) ntpdc and ntpq would crash -- this was reported for 9.3-STABLE -- I
don't think it affected other releases, and was diagnosed as due to a
pthreads linking issue.  Solved for 9.x in r290044 and r290046

2) ntpd SEGV's on startup on 10.2-RELEASE-p6 (possibly others).
Curiously, so does net/ntp from ports, but only on the second startup.
Exactly the same ntp package seems to run and restart just fine on
recent 10-STABLE though.  As does the base system ntpd.

Cheers,

Matthew







signature.asc
Description: OpenPGP digital signature

Re: Segmentation fault running ntpd

2015-10-30 Thread NGie Cooper 

> On Oct 30, 2015, at 02:05, Dag-Erling Smørgrav  wrote:
> 
> NGie Cooper  writes:
>> Dag-Erling Smørgrav  writes:
>>> David Wolfskill  writes:
 pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
>>> Did you find a solution?  [...]
>> https://svnweb.freebsd.org/changeset/base/287591 ?
> 
> Are you certain?  The commit message does not mention David or ntpd.

That commit was pretty involved. Peter documented the issue in the thread 
titled "ABORT! ABORT! Re: HEADS UP: this month's cluster refresh” that was sent 
to the internal list.
___
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: Segmentation fault running ntpd

2015-10-30 Thread Franco Fichtner 
Hi all,

I did a quick test build and this seems to solve the ntpd crash issue
on top of releng/10.1.


Cheers,
Franco

> On 30 Oct 2015, at 10:09 am, NGie Cooper  wrote:
> 
> 
>> On Oct 30, 2015, at 02:05, Dag-Erling Smørgrav  wrote:
>> 
>> NGie Cooper  writes:
>>> Dag-Erling Smørgrav  writes:
 David Wolfskill  writes:
> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
 Did you find a solution?  [...]
>>> https://svnweb.freebsd.org/changeset/base/287591 ?
>> 
>> Are you certain?  The commit message does not mention David or ntpd.
> 
> That commit was pretty involved. Peter documented the issue in the thread 
> titled "ABORT! ABORT! Re: HEADS UP: this month's cluster refresh” that was 
> sent to the internal list.
> ___
> 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"

___
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: Segmentation fault running ntpd

2015-10-30 Thread NGie Cooper 

> On Oct 30, 2015, at 02:18, Franco Fichtner  wrote:
> 
> Hi all,
> 
> I did a quick test build and this seems to solve the ntpd crash issue
> on top of releng/10.1.

Makes sense … looking through my email r287591 was never MFCed back to stable/9 
or stable/10 :/ .
HTH,
-NGie
___
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"

unsubscribe me please

2015-10-30 Thread Administrator 
Unsubscribe me please

-Original Message-
From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of 
freebsd-current-requ...@freebsd.org
Sent: 30 October 2015 12:00
To: freebsd-current@freebsd.org
Subject: freebsd-current Digest, Vol 627, Issue 5

Send freebsd-current mailing list submissions to
freebsd-current@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freebsd.org/mailman/listinfo/freebsd-current
or, via email, send a message with subject or body 'help' to
freebsd-current-requ...@freebsd.org

You can reach the person managing the list at
freebsd-current-ow...@freebsd.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of freebsd-current digest..."
___
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"

panic in arptimer in r289937

2015-10-30 Thread Adrian Chadd 
Hiya,

Here's a panic from arptimer:

(kgdb) bt
#0  doadump (textdump=0) at pcpu.h:221
#1  0x803666b6 in db_fncall (dummy1=,
dummy2=, dummy3=,
dummy4=) at
/usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568
#2  0x8036614e in db_command (cmd_table=0x0) at
/usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440
#3  0x80365ee4 in db_command_loop () at
/usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493
#4  0x8036897b in db_trap (type=, code=0)
at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251
#5  0x8096c0f3 in kdb_trap (type=9, code=0, tf=) at
/usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654
#6  0x80d34c81 in trap_fatal (frame=0xfe022815d7a0,
eva=) at
/usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:829
#7  0x80d34951 in trap (frame=) at
/usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/trap.c:203
#8  0x80d149f7 in calltrap () at
/usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:234
#9  0x8092c3fb in _rw_wlock_cookie (c=0xdeadc0dedeadc2de,
file=0x81211b1f
"/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c",
line=205)
at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_rwlock.c:261
#10 0x80a2487f in arptimer (arg=0xf8005ecc4000) at
/usr/home/adrian/work/freebsd/head/src/sys/netinet/if_ether.c:205
#11 0x80944c24 in softclock_call_cc (c=0xf8005ecc40a8,
cc=0x81b2d480, direct=0) at
/usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:722
#12 0x80944f87 in softclock (arg=) at
/usr/home/adrian/work/freebsd/head/src/sys/kern/kern_timeout.c:851
#13 0x808f7eb6 in intr_event_execute_handlers (p=, ie=0xf800035a6600) at
/usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1262
#14 0x808f8546 in ithread_loop (arg=0xf800032c47c0) at
/usr/home/adrian/work/freebsd/head/src/sys/kern/kern_intr.c:1275
#15 0x808f57a4 in fork_exit (callout=0x808f84a0
, arg=0xf800032c47c0, frame=0xfe022815dac0) at
/usr/home/adrian/work/freebsd/head/src/sys/kern/kern_fork.c:1011
#16 0x80d14f2e in fork_trampoline () at
/usr/home/adrian/work/freebsd/head/src/sys/amd64/amd64/exception.S:609
#17 0x in ?? ()
Current language:  auto; currently minimal


(kgdb) print *(struct llentry *)c_arg
$2 = {lle_next = {le_next = 0x0, le_prev = 0xf8005e867dc8},
r_l3addr = {addr4 = {s_addr = 16782508}, addr6 = {__u6_addr =
{__u6_addr8 = 0xf8005ecc4010 "�\024", __u6_addr16 =
0xf8005ecc4010,
__u6_addr32 = 0xf8005ecc4010}}}, ll_addr = {mac_aligned =
110869256150596, mac16 = 0xf8005ecc4020, mac8 = 0xf8005ecc4020
"D\036���d"}, spare0 = 0, spare1 = 0, lle_tbl = 0xf8005e867e00,
  lle_head = 0xf8005e867dc8, lle_free = 0x80a2c5d0
, la_hold = 0x0, la_numheld = 0, la_expire =
2110, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 0,
ln_router = 0, ln_ntick = 0,
  lle_refcnt = 1, lle_chain = {le_next = 0x0, le_prev = 0x0},
lle_timer = {c_links = {le = {le_next = 0x0, le_prev =
0x81b2d588}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
tqe_prev = 0x81b2d588}},
c_time = 9066299815445, c_precision = 322122525000, c_arg =
0xf8005ecc4000, c_func = 0x80a246e0 , c_lock =
0x0, c_flags = 0, c_iflags = 144, c_cpu = 0}, lle_lock = {lock_object
= {
  lo_name = 0x8120fbce "lle", lo_flags = 90374144, lo_data
= 0, lo_witness = 0xfeb53c80}, rw_lock = 1}}

..

(kgdb) print *((struct llentry *)c_arg)->lle_tbl
$4 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = -559038242,
llt_hsize = -559038242, lle_head = 0xdeadc0dedeadc0de, llt_ifp =
0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de,
  llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry =
0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de,
llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de,
llt_match_prefix = 0xdeadc0dedeadc0de,
  llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry =
0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de,
llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry =
0xdeadc0dedeadc0de,
  llt_free_tbl = 0xdeadc0dedeadc0de}

:(

Any ideas on where next to look?



-adrian
___
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: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread Simon J. Gerraty 
NGie Cooper  wrote:
>   I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS 
> and I ran into this linker issue below. I have no idea (yet) why it’s trying 
> to compile an x64 object when I specify powerpc/powerpc — and more 
> importantly, why is the object not being put in obj.powerpc?
>   I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
> tinderbox".

Is it possible that the file is left over from a previous build (of amd64?)

Does your log show it being built?


> dtrace -C -x nolibs -G -o usdt.o -s 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d 
> tst.usdt.o
> dtrace: failed to link script 
> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: 
> incorrect ELF machine type for object file: tst.usdt.o
> *** Error code 1
> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
> ___
> 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"
___
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: r288951: ifconfig -alias, arp not removed

2015-10-30 Thread Eric van Gyzen 
On 10/29/2015 16:56, Bryan Drewery wrote:
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>> On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>> On 10/29/2015 11:25, Bryan Drewery wrote:
 # ifconfig
 igb0: flags=8843 metric 0 mtu 1500

 options=403bb
 ether c8:0a:a9:04:39:78
 inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
 inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
 inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
 nd6 options=23
 media: Ethernet autoselect (1000baseT )
 status: active

 # ifconfig igb0 inet 10.10.0.9 -alias
 # arp -an|grep 10.10.0.9
 ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
 # arp -d 10.10.0.9
 arp: writing to routing socket: Operation not permitted

 I swear this is not normal. I'm on an older build as well, r288951.
>>>
>>> That definitely looks abnormal.  See what "route get" says.  I think
>>> that's the error you get when there is a route for that address.
>>>
>>
>> # netstat -rn|grep 10.10.0.9
>> # route get 10.10.0.9
>>route to: lapbox
>> destination: 10.10.0.0
>>mask: 255.255.0.0
>> fib: 0
>>   interface: igb0
>>   flags: 
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500 1 0
>> # route get 5.5.5.5
>>route to: 5.5.5.5
>> destination: default
>>mask: default
>> gateway: router.asus.com
>> fib: 0
>>   interface: igb0
>>   flags: 
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500 1 0
>>
>> For more context, this current system had 10.10.0.9 added to it. I
>> started up a VM which also started using 10.10.0.9 and managed to "win"
>> on the local network for owning it. (I don't know arp and this stuff
>> well). I then came to this system to remove the alias and the arp entry
>> to allow me to connect from it and have gotten into this situation.
>>
> 
> Just saw this in dmesg, which is what I described:
> 
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0

The kernel should have removed the arp entry when you removed the alias.
 I just played with this on r289837 (one week old), and I could not
reproduce the failure.  In particular, r289501 sounds interesting, even
though your interface is up.

Eric
___
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: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread NGie Cooper 
On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery  wrote:
> On 10/30/2015 2:21 PM, Bryan Drewery wrote:
>> On 10/30/2015 1:57 PM, NGie Cooper wrote:
>>> Hi Bryan/Simon!
>>>  I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS 
>>> and I ran into this linker issue below. I have no idea (yet) why it’s 
>>> trying to compile an x64 object when I specify powerpc/powerpc — and more 
>>> importantly, why is the object not being put in obj.powerpc?
>>>  I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
>>> tinderbox".
>>> Thanks!
>>> -NGie
>>>
>>
>> Have you modified any of your local toolchain handling, or skipped
>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
>> there to be a lot more reports if there was a problem with buildworld
>> cross compiling.
>>
>>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>>> …
>>> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
>>> DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
>>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
>>> _RECURSING_PROGS=  PROG=tst.usdt.exe )
>>> cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
>>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>>>  -std=gnu99 -fstack-protector-strong-c 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>>>  -o tst.usdt.o
>>> dtrace -C -x nolibs -G -o usdt.o -s 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
>>>  tst.usdt.o
>>> dtrace: failed to link script 
>>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
>>>  incorrect ELF machine type for object file: tst.usdt.o
>>> *** Error code 1
>>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>>> $ file 
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 
>>> 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
>>>
>
> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
> to be fine with PROGS.  Here's a test object built via PROGS:
>
> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> ~/git/freebsd # file
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
> not stripped
> -rw-r--r--  1 root  wheel  21136 Oct 23 17:08
> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>
> I see nothing special with the DTRACE_TESTS to change any of this.

I could see there being a possible issue with my host VM, but I
haven't modified my environment in ref11-amd64.freebsd.org at all.

Could you please try reproing it there with your user?

Thanks,
-NGie
___
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: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread Bryan Drewery 
On 10/30/2015 3:03 PM, NGie Cooper wrote:
> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery  wrote:
>> On 10/30/2015 2:21 PM, Bryan Drewery wrote:
>>> On 10/30/2015 1:57 PM, NGie Cooper wrote:
 Hi Bryan/Simon!
  I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS 
 and I ran into this linker issue below. I have no idea (yet) why it’s 
 trying to compile an x64 object when I specify powerpc/powerpc — and more 
 importantly, why is the object not being put in obj.powerpc?
  I ran into the same issue on ref11-amd64.freebsd.org when I ran “make 
 tinderbox".
 Thanks!
 -NGie

>>>
>>> Have you modified any of your local toolchain handling, or skipped
>>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
>>> there to be a lot more reports if there was a problem with buildworld
>>> cross compiling.
>>>
 % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
 …
 ===> cddl/usr.sbin/dtrace/tests/common/json (all)
 (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&  
 DEPENDFILE=.depend.tst.usdt.exe  NO_SUBDIR=1 make -f 
 /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile 
 _RECURSING_PROGS=  PROG=tst.usdt.exe )
 cc  -O2 -pipe -fno-strict-aliasing -O2 -pipe   -O0 -g 
 -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
  -std=gnu99 -fstack-protector-strong-c 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
  -o tst.usdt.o
 dtrace -C -x nolibs -G -o usdt.o -s 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d
  tst.usdt.o
 dtrace: failed to link script 
 /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d:
  incorrect ELF machine type for object file: tst.usdt.o
 *** Error code 1

The problem looks specific to compiling of .d files using dtrace(1). It
must not have cross-compile support.

The manpage does say: "The D compiler produces programs using the native
data model of the operating system kernel.".

So these will need to be disabled for non-native builds.

I don't know if it would be possible to build a cross-compile version of
dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work.

 $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
 $ file 
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
 /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: 
 ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

>>
>> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed
>> to be fine with PROGS.  Here's a test object built via PROGS:
>>
>> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>> ~/git/freebsd # file
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o:
>> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD),
>> not stripped
>> -rw-r--r--  1 root  wheel  21136 Oct 23 17:08
>> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o
>>
>> I see nothing special with the DTRACE_TESTS to change any of this.
> 
> I could see there being a possible issue with my host VM, but I
> haven't modified my environment in ref11-amd64.freebsd.org at all.
> 
> Could you please try reproing it there with your user?
> 
> Thanks,
> -NGie
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: r288951: ifconfig -alias, arp not removed

2015-10-30 Thread Alexander V . Chernikov 
30.10.2015, 00:57, "Bryan Drewery" :
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>>  On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>>  On 10/29/2015 11:25, Bryan Drewery wrote:
  # ifconfig
  igb0: flags=8843 metric 0 mtu 1500

  
 options=403bb
  ether c8:0a:a9:04:39:78
  inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
  inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
  inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
  nd6 options=23
  media: Ethernet autoselect (1000baseT )
  status: active

  # ifconfig igb0 inet 10.10.0.9 -alias
  # arp -an|grep 10.10.0.9
  ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
  # arp -d 10.10.0.9
  arp: writing to routing socket: Operation not permitted

  I swear this is not normal. I'm on an older build as well, r288951.
Well, there were changes on arpscrub procedures in r287789.
(There was one bug fixed in r289501, but I think it is not relevant).
Could you consider trying more recent HEAD and check if this is still 
reproducible?
I was not able to reproduce that behavior.
>>>
>>>  That definitely looks abnormal. See what "route get" says. I think
>>>  that's the error you get when there is a route for that address.
>>
>>  # netstat -rn|grep 10.10.0.9
>>  # route get 10.10.0.9
>> route to: lapbox
>>  destination: 10.10.0.0
>> mask: 255.255.0.0
>>  fib: 0
>>    interface: igb0
>>    flags: 
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>  # route get 5.5.5.5
>> route to: 5.5.5.5
>>  destination: default
>> mask: default
>>  gateway: router.asus.com
>>  fib: 0
>>    interface: igb0
>>    flags: 
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>
>>  For more context, this current system had 10.10.0.9 added to it. I
>>  started up a VM which also started using 10.10.0.9 and managed to "win"
>>  on the local network for owning it. (I don't know arp and this stuff
>>  well). I then came to this system to remove the alias and the arp entry
>>  to allow me to connect from it and have gotten into this situation.
>
> Just saw this in dmesg, which is what I described:
>
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
>
> --
> 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"

FreeBSD_HEAD_amd64_gcc4.9 - Build #719 - Fixed

2015-10-30 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc4.9 - Build #719 - Fixed:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/719/console

Change summaries:

290193 by zbb:
Use PCB/LR from PCB rather from stack on armv7-gdb

The kernel dump does not store these values on the stack.
Use PCB structure to resolve PC and LR properly.

Submitted by:  Wojciech Macek 
Reviewed by:   jhb, kib
Obtained from: Semihalf
Sponsored by:  Juniper Networks Inc.
Differential Revision: https://reviews.freebsd.org/D4013

290192 by zbb:
Workaround KGDB issues on ARM by ignoring ARM EABI version higher than 5

To make KGDB working, it needs to understand kernel ELF image.
By default it is compiled using EABI_5, which is not supported
on the gdb-6. As a workaround, treat these images as EABI_2 because
they share a lot of things in common.

This workaround does not guarantee ALL funtionalities
to work.

Submitted by:  Wojciech Macek 
Reviewed by:   jhb
Obtained from: Semihalf
Sponsored by:  Juniper Networks Inc.
Differential Revision: https://reviews.freebsd.org/D4012

290191 by avg:
l2arc: do not call trim_map_free() for blocks with zero b_asize

b_asize can be zero if the block is compressed into an empty block
(ZIO_COMPRESS_EMPTY) and the trim code asserts that meaningless
zero-sized trimming is not attempted.
The logic for calling trim_map_free() is extracted into a new function
l2arc_trim() to minimize code duplication.

PR: 203473
Reported by:Willem Jan Withagen 
Tested by:  Willem Jan Withagen 
MFC after:  11 days

290190 by ngie:
Fix compiler warnings with open_to_operation.c

Other sidenotes:
- Remove unused variables with main(..)
- Convert errx/exit with -1 to errx/exit with 1
- Fix a bogus test in try_directory_open
  (expected_errno == expected_errno -> errno == expected_errno) [*]
- Fix some warnings related to discarded qualifiers
- Remove a bogus else-statement at the end of check_mmap_exec(..) in the
  successful case. mmap(2), POSIX, Linux, etc all don't state what the
  behavior is when mixing O_WRONLY + PROT_EXEC, so assume success for now to
  get the test program to pass again.

PR: 201286 [*]
MFC after: 1 week
Submitted by: David Binderman 
Sponsored by: EMC / Isilon Storage Division

290188 by kib:
The prefix for CLFLUSHOPT is 0x66.  It was right on amd64.

Sponsored by:   The FreeBSD Foundation

290186 by ed:
Make truss work for CloudABI processes on aarch64.

This change copies over amd64-cloudabi64.c to aarch64-cloudabi.c and
adjusts it to fetch the proper registers on aarch64. To reduce the
amount of shared code, the errno conversion function is moved into a
separate source file.

Reviewed by:jhb, andrew
Differential Revision:  https://reviews.freebsd.org/D4023

290185 by ngie:
Disable h_raw/h_read with gcc

I forgot that these testcases fail with gcc 4.2.1; add a note to that effect

MFC after: never
Sponsored by: EMC / Isilon Storage Division

290184 by ngie:
Fix a set but not used variable warning flagged by gcc 4.9 with
lib/libc/ssp/h_readlink

MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division

290183 by ngie:
- Re-enable h_raw with clang 3.7.0+
- Fix the compiler check to allow the test to be compiled for gcc

PR: 196430
MFC after: never
Sponsored by: EMC / Isilon Storage Division

290182 by ngie:
Fix rtsold's usage message

- Remove -a from the usage message example dealing with specific
  interfaces. -a only makes sense when not specifying an interface,
  such that it's to be run on all interfaces
- Fix the pidfile option (it's -p, not -P)
- Change `interfaces` to `interface` to match the manpage

MFC after: 3 days
PR: 173744
Sponsored by: EMC / Isilon Storage Division

290181 by ngie:
Unbreak bsd.progs.mk with PROGS (but not PROGS_CXX) and when invoking the
"one of many" targets, e.g. `make hello_world`, where hello_world is a C
program

Tested with: PROGS and PROGS_CXX
MFC after: 1 week
X-MFC with: r289289
Sponsored by: EMC / Isilon Storage Division

290180 by ngie:
Follow up to roundup feature addition in r289203

- Rename -r to -R to avoid the clash with makefs -r in NetBSD
- Note that -R is an FFS-specific option because it's not implemented
  in cd9660 today
- Rename the roundup variable to "roundup-size" in the manpage and help
  text for consistency with other variables.
- Bump .Dd (missed in r289203)

PR: 203707
MFC after: 1 week
X-MFC with: r289203
Differential Revision: https://reviews.freebsd.org/D3959
Reviewed by: adrian (earlier patch), emaste
Sponsored by: EMC / Isilon Storage Division

290179 by ngie:
Remove a set but unused variable in __getgroupmembership to fix a gcc 4.9+ 
warning

MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division

290178 by ngie:
Fix GOST engine

Re: Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

2015-10-30 Thread NGie Cooper 
On Fri, Oct 30, 2015 at 4:09 PM, Bryan Drewery  wrote:
...
> The example output must be a mistake as they are correct on ref11:
>
> ref11-amd64% find
> /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
> -name tst.usdt.o -exec file {} +
> /scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>   ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>   ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
>   ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1
> (FreeBSD), not stripped
> /scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
> (FreeBSD), not stripped
>
> [sorry for bad mail client]

Weird. Ok, I'll do some more digging into this.
Thanks for the input!
___
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: Segmentation fault running ntpd

2015-10-30 Thread Mark Martinec 

Not sure if it's the same issue, but it sure looks like it is.

I have upgraded a couple of hosts (amd64) from 10.2-RELEASE-p5
to 10.2-RELEASE-p6, i.e. the freebsd-upgrade essentially just
replaced the /usr/sbin/ntpd with a new one; then I restarted
the ntpd.

On all host but one this was successful: the new ntpd starts
fine and works normally. But on one of these machines the
ntpd process immediately crashes with SIGSEGV. That machine
has an Intel Xeon cpu. It is not apparent to me in what way
this machine differs from others,

Played with some variations of ntpd on that host, here are
some findings:

- the new ntpd (that came with 10.2-RELEASE-p6) runs fine
  if it does *not* daemonize, i.e. ntpd with an option -n or -d
  stays attached to a terminal and works fine; the same
  happens when run under ktrace -d -i ntpd  ... it works fine,
  even when it daemonizes;

- the ntpd built from fresh net/ntp-devel behaves exactly
  the same: crashes on that machine when it daemonizes

- a previous ntpd (from 10.2-RELEASE-p5) works fine,
  so I ended up downgrading ntpd to that previous version
  on that machine. Also a ntpd from a recent 10-STABLE
  when copied to that host runs fine there!

I haven't tried yet to build it with debugging, or capture
a core dump.

Puzzling...

   Mark



2015-10-30 12:34, je David Wolfskill napisal

On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote:

David Wolfskill  writes:
> ...
> bound to 172.17.1.245 -- renewal in 43200 seconds.
> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
> Starting Network: lo0 em0 iwn0 lagg0.
> ...

Did you find a solution?  I'm wondering if the ntpd problems people 
are

reporting on freebsd-security@ are related.  I vaguely recall hearing
that this had been traced to a pthread bug, but can't find anything
about it in commit logs or mailing list archives.



I don't recall finding "a solution" per se; that said, I also don't
recall seeing an occurrence of the above for enough time that I'm not
sure when I sent that message. :-}

As a reality check:

g1-252(11.0-C)[1] ls -lT /*.core
-rw-r--r--  1 root  wheel  13783040 Aug 18 04:19:03 2015 /ntpd.core
g1-252(11.0-C)[2]

So -- among other points -- my last sighting of whatever was causing
that was the day I built:

FreeBSD 11.0-CURRENT #157  r286880M/286880:1100079: Tue Aug 18
04:45:25 PDT 2015
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Note that the machines where I run head get updated daily (unless
there's enough of a problem with head that I can't build it or can't
boot it (and I'm unable to circumvent the issue within a reasonable
time)) -- and while I do attempt to run ntpd on the machines, the above
failure is more "annoying" than "crippling" in my particular case.

And I'm presently running:

FreeBSD 11.0-CURRENT #227  r290138M/290138:1100084: Thu Oct 29
05:12:58 PDT 2015
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

and building head @r290190 as I type.

And FWIW, I *suspect* that one of the issues involved (in my case)
was a ... lack of determinism ... in events involving getting the
(wireless) network connectivity into a usable state as part of the
initial transition to multi-user mode.  (I only have evidence at
the moment of the issue on my laptop; my build machine, which only
uses a wired NIC, has no /ntpd.core file.  It and my laptop are updated
pretty much in lock-step; it runs a completely GENERIC kernel, while
the laptop runs a modestly customized one based on GENERIC.)

Peace,
david

___
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: Segmentation fault running ntpd

2015-10-30 Thread David Wolfskill 
On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote:
> David Wolfskill  writes:
> > ...
> > bound to 172.17.1.245 -- renewal in 43200 seconds.
> > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
> > Starting Network: lo0 em0 iwn0 lagg0.
> > ...
> 
> Did you find a solution?  I'm wondering if the ntpd problems people are
> reporting on freebsd-security@ are related.  I vaguely recall hearing
> that this had been traced to a pthread bug, but can't find anything
> about it in commit logs or mailing list archives.
> 

I don't recall finding "a solution" per se; that said, I also don't
recall seeing an occurrence of the above for enough time that I'm not
sure when I sent that message. :-}

As a reality check:

g1-252(11.0-C)[1] ls -lT /*.core
-rw-r--r--  1 root  wheel  13783040 Aug 18 04:19:03 2015 /ntpd.core
g1-252(11.0-C)[2] 

So -- among other points -- my last sighting of whatever was causing
that was the day I built:

FreeBSD 11.0-CURRENT #157  r286880M/286880:1100079: Tue Aug 18 04:45:25 PDT 
2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Note that the machines where I run head get updated daily (unless
there's enough of a problem with head that I can't build it or can't
boot it (and I'm unable to circumvent the issue within a reasonable
time)) -- and while I do attempt to run ntpd on the machines, the above
failure is more "annoying" than "crippling" in my particular case.

And I'm presently running:

FreeBSD 11.0-CURRENT #227  r290138M/290138:1100084: Thu Oct 29 05:12:58 PDT 
2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

and building head @r290190 as I type.

And FWIW, I *suspect* that one of the issues involved (in my case)
was a ... lack of determinism ... in events involving getting the
(wireless) network connectivity into a usable state as part of the
initial transition to multi-user mode.  (I only have evidence at
the moment of the issue on my laptop; my build machine, which only
uses a wired NIC, has no /ntpd.core file.  It and my laptop are updated
pretty much in lock-step; it runs a completely GENERIC kernel, while
the laptop runs a modestly customized one based on GENERIC.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature