Jenkins build is still unstable: FreeBSD_HEAD #594

2016-09-04 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"

Jenkins build is still unstable: FreeBSD_HEAD #593

2016-09-04 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: warning errors with buildworld with llvm39

2016-09-04 Thread Shawn Webb 
On Tue, Aug 30, 2016 at 06:17:02PM -0700, Ngie Cooper wrote:
> On Tue, Aug 30, 2016 at 5:54 PM, Matthew Macy  wrote:
> >
> >
> > I did a buildworld with llvm39. Unsurprisingly I had to pass NO_WERROR= as 
> > the llvm has added additional warnings since 3.8.
> >
> > https://gist.github.com/mattmacy/5f0c994b7587a10e3f58e7fd9fc1dd01
> 
> dim's working on the issues on ^/projects/clang390-import . Some of
> the issues you've noted have been resolved.
> Cheers,
> -Ngie

Hey Ngie et al,

I've got a few more errors after importing the projects/clang390-import
branch into a local version of the drm-next-4.7 branch.

The log is here:

https://gist.github.com/lattera/e3a9900eff4e3f8425e0ee2242f5ee4b

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Jenkins build is still unstable: FreeBSD_HEAD #592

2016-09-04 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: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

2016-09-04 Thread Andriy Voskoboinyk 
Sun, 04 Sep 2016 11:37:19 +0300 було написано Marcus von Appen  
:


Try to add your vendor / device into sys/dev/rtwn/pci/rtwn_pci_attach.h
(sys/dev/rtwn/if_rtwn.c for current driver in HEAD):
{ 0x10ec, 0x8176, "Realtek RTL8188CE", RTWN_CHIP_RTL8192CE },
+   { , , "Realtek RTL8192CE", RTWN_CHIP_RTL8192CE },
{ 0, 0, NULL, RTWN_CHIP_MAX_PCI }


On, Thu Sep 01, 2016, Andriy Voskoboinyk wrote:


Hi everyone,

rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged
into a
single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is
available on https://github.com/s3erios/rtwn repository. Among bugfixes  
/

code deduplication, there some new features too:

1) multi-vap support (one any wireless interface + one STA interface +
any number of monitor mode interfaces).
2) few new sysctls:
  * dev.rtwn.#.crypto - controls how to use hardware crypto acceleration
  * dev.rtwn.#.ratectl_selected
  * dev.rtwn.#.ratectl - selects current 'rate control' algorithm
(currently only 'none' and 'net80211' are supported; RTL8192CE needs
testing
with the last).


I got a RTL8192CE - what should I look for, when using net80211?

Cheers
Marcus

___
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 is unstable: FreeBSD_HEAD #591

2016-09-04 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 #590

2016-09-04 Thread jenkins-admin 
See 

--
[...truncated 51004 lines...]
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.ToolChain.o -MTToolChain.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspace/FreeBSD_HE
 
AD/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/ToolChain.cpp
 -o ToolChain.o
--- all_subdir_lib/clang/libclangcodegen ---
--- CGClass.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangcodegen/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.CGClass.o -MTCGClass.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspace/FreeBSD_H
 
EAD/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGClass.cpp
 -o CGClass.o
--- all_subdir_lib/clang/libclangast ---
--- CommentParser.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangast/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.CommentParser.o -MTCommentParser.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspace/FreeBSD_HEAD/src/
 
lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentParser.cpp
 -o CommentParser.o
--- all_subdir_lib/clang/libclangdriver ---
--- ToolChains.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -MD -MF.depend.ToolChains.o -MTToolChains.o -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
/builds/workspace/FreeBSD_
 
HEAD/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp
 -o ToolChains.o
--- all_subdir_lib/clang/libclanganalysis ---
--- ThreadSafetyCommon.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libclanganalysis/../../../contrib/llvm/inclu

Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

2016-09-04 Thread Andriy Gapon 
On 04/09/2016 17:51, Konstantin Belousov wrote:
> It is only masked when name cache has an entry for the vnode.  So sometimes
> vn_fullpath() should be broken even if no normalization is applied.

Yes, this is true.

> OTOH, classic filesystems like UFS do not have any other means to translate
> non-directory inode to name and parent at all, except the namecache hint.

In fact, this is true for ZFS as well.  While ZFS znodes have an attribute that
specifies a (single) parent, it's obviously unreliable for files, because a file
can be linked into multiple directories and then unlinked from a directory
specified by the attribute.

So, at the moment I do not have any good ideas on how to make this work.
Maybe trying to use the parent attribute and failing when it's inconsistent
would be good enough...


-- 
Andriy Gapon
___
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: SVN r305382 breaks world32 on amd64 (and native 32-bit)

2016-09-04 Thread Bruce Evans 

On Sun, 4 Sep 2016, Michael Butler wrote:


Build fails with:

===> lib/msun (obj,all,install)
Building /usr/obj/usr/src/lib/msun/e_fmodf.o
/usr/src/lib/msun/i387/e_fmodf.S:10:17: error: register %rsp is only
available in 64-bit mode
movss %xmm0,-4(%rsp)
   ^~~~
/usr/src/lib/msun/i387/e_fmodf.S:11:17: error: register %rsp is only


Fixed.  I noticed it proof-reading the committed sources instead of
the commit mail, and missed it for a while since I checked amd64 first.

The bug was there for a couple of hours.  At least the build failure
prevented it being run.

Bruce
___
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: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

2016-09-04 Thread Konstantin Belousov 
On Sun, Sep 04, 2016 at 04:11:39PM +0300, Andriy Gapon wrote:
> On 04/09/2016 11:24, Andriy Gapon wrote:
> > On 27/08/2016 22:09, Frederic Chardon wrote:
> >>> Anybody is able to reproduce this behavior or is it a local problem?
> >> Reverting 303970 solves this issue. gcore and adb works again, and I
> >> can start the vboxnet service.
> >> I recreated my boot pool with no properties defined, just to be sure.
> > 
> > I can not reproduce this issue here.
> 
> I was not trying hard enough.  I've just reproduced the problem using a
> non-default normalization property.  The issue is that 303970 disabled the use
> of VFS name cache when any name "mangling" (normalization, case-insensitivity)
> is enabled.  And apparently I misunderstood how vop_stdvptocnp() works.  So,
> right now zfs_vptocnp() is broken when its argument is a non-directory vnode.
> That fact is masked when the name cache is used and is exposed otherwise.
It is only masked when name cache has an entry for the vnode.  So sometimes
vn_fullpath() should be broken even if no normalization is applied.

OTOH, classic filesystems like UFS do not have any other means to translate
non-directory inode to name and parent at all, except the namecache hint.
___
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"

SVN r305382 breaks world32 on amd64 (and native 32-bit)

2016-09-04 Thread Michael Butler 
Build fails with:

===> lib/msun (obj,all,install)
Building /usr/obj/usr/src/lib/msun/e_fmodf.o
/usr/src/lib/msun/i387/e_fmodf.S:10:17: error: register %rsp is only
available in 64-bit mode
 movss %xmm0,-4(%rsp)
^~~~
/usr/src/lib/msun/i387/e_fmodf.S:11:17: error: register %rsp is only
available in 64-bit mode
 movss %xmm1,-8(%rsp)
^~~~
/usr/src/lib/msun/i387/e_fmodf.S:12:10: error: register %rsp is only
available in 64-bit mode
 flds -8(%rsp)
 ^~~~
/usr/src/lib/msun/i387/e_fmodf.S:13:10: error: register %rsp is only
available in 64-bit mode
 flds -4(%rsp)
 ^~~~
/usr/src/lib/msun/i387/e_fmodf.S:18:11: error: register %rsp is only
available in 64-bit mode
 fstps -4(%rsp)
  ^~~~
/usr/src/lib/msun/i387/e_fmodf.S:19:11: error: register %rsp is only
available in 64-bit mode
 movss -4(%rsp),%xmm0
  ^~~~
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib/msun
___
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: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

2016-09-04 Thread Andriy Gapon 
On 04/09/2016 11:24, Andriy Gapon wrote:
> On 27/08/2016 22:09, Frederic Chardon wrote:
>>> Anybody is able to reproduce this behavior or is it a local problem?
>> Reverting 303970 solves this issue. gcore and adb works again, and I
>> can start the vboxnet service.
>> I recreated my boot pool with no properties defined, just to be sure.
> 
> I can not reproduce this issue here.

I was not trying hard enough.  I've just reproduced the problem using a
non-default normalization property.  The issue is that 303970 disabled the use
of VFS name cache when any name "mangling" (normalization, case-insensitivity)
is enabled.  And apparently I misunderstood how vop_stdvptocnp() works.  So,
right now zfs_vptocnp() is broken when its argument is a non-directory vnode.
That fact is masked when the name cache is used and is exposed otherwise.

I will think about a fix.  Could you please file a bug report for this (if not
already)?
Sorry about the breakage.

-- 
Andriy Gapon
___
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: commits between r305191 - r305211 broke zfs list

2016-09-04 Thread Alexander Motin 
On 04.09.2016 13:14, Subbsd wrote:
> Thanks for  the pointer, after server rebooting to new kernel problem is gone

Do I understand right that you've used new binary with old kernel?  In
such case crash is predictable.  There are compatibility shims allowing
to run old binary with the new kernel (and I've event tested it last
night), but not opposite.

> On Sun, Sep 4, 2016 at 10:08 AM, Peter Wemm  wrote:
>> On Saturday, September 03, 2016 10:31:04 PM Steven Hartland wrote:
>>> Out of sync kernel / world?
>>>
>>> Do you have a crash dump?
>>
>> This has caused a considerable amount of excitement on the freebsd.org
>> cluster.  Having kernel+world out of sync causes zfs(8) to abort rather
>> ungracefully.
>>
>>> On 03/09/2016 21:50, Subbsd wrote:
 Hi.

 Can anybody test of output for:

 zfs list

 command on FreeBSD current after r305211 ? On my hosts his leads to
 zfs segfault.
>>
>> --
>> Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
>> UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

-- 
Alexander Motin
___
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: commits between r305191 - r305211 broke zfs list

2016-09-04 Thread Subbsd 
Thanks for  the pointer, after server rebooting to new kernel problem is gone

On Sun, Sep 4, 2016 at 10:08 AM, Peter Wemm  wrote:
> On Saturday, September 03, 2016 10:31:04 PM Steven Hartland wrote:
>> Out of sync kernel / world?
>>
>> Do you have a crash dump?
>
> This has caused a considerable amount of excitement on the freebsd.org
> cluster.  Having kernel+world out of sync causes zfs(8) to abort rather
> ungracefully.
>
>> On 03/09/2016 21:50, Subbsd wrote:
>> > Hi.
>> >
>> > Can anybody test of output for:
>> >
>> > zfs list
>> >
>> > command on FreeBSD current after r305211 ? On my hosts his leads to
>> > zfs segfault.
>
> --
> Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
> UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
___
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: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)

2016-09-04 Thread Marcus von Appen 
On, Thu Sep 01, 2016, Andriy Voskoboinyk wrote:

> Hi everyone,
>
> rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged
> into a
> single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is
> available on https://github.com/s3erios/rtwn repository. Among bugfixes /
> code deduplication, there some new features too:
>
> 1) multi-vap support (one any wireless interface + one STA interface +
> any number of monitor mode interfaces).
> 2) few new sysctls:
>   * dev.rtwn.#.crypto - controls how to use hardware crypto acceleration
>   * dev.rtwn.#.ratectl_selected
>   * dev.rtwn.#.ratectl - selects current 'rate control' algorithm
> (currently only 'none' and 'net80211' are supported; RTL8192CE needs
> testing
> with the last).

I got a RTL8192CE - what should I look for, when using net80211?

Cheers
Marcus


signature.asc
Description: PGP signature

Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

2016-09-04 Thread Andriy Gapon 
On 27/08/2016 22:09, Frederic Chardon wrote:
>> Anybody is able to reproduce this behavior or is it a local problem?
> Reverting 303970 solves this issue. gcore and adb works again, and I
> can start the vboxnet service.
> I recreated my boot pool with no properties defined, just to be sure.

I can not reproduce this issue here.
Unfortunately, I have no clue how kern.proc.pathname works, so I would
appreciate any hints at what filesystem operations I should look for potential
problems.

-- 
Andriy Gapon
___
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: commits between r305191 - r305211 broke zfs list

2016-09-04 Thread Peter Wemm 
On Saturday, September 03, 2016 10:31:04 PM Steven Hartland wrote:
> Out of sync kernel / world?
> 
> Do you have a crash dump?

This has caused a considerable amount of excitement on the freebsd.org 
cluster.  Having kernel+world out of sync causes zfs(8) to abort rather 
ungracefully.

> On 03/09/2016 21:50, Subbsd wrote:
> > Hi.
> > 
> > Can anybody test of output for:
> > 
> > zfs list
> > 
> > command on FreeBSD current after r305211 ? On my hosts his leads to
> > zfs segfault.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.