Re: warning errors with buildworld with llvm39

2016-08-30 Thread Ngie Cooper 
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
___
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"

warning errors with buildworld with llvm39

2016-08-30 Thread Matthew Macy 


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


The most prevalent seems to be:

jemalloc_nstime.c:120:7: warning: macro expansion producing 'defined' has 
undefined behavior [-Wexpansion-to-defined]
#elif JEMALLOC_CLOCK_GETTIME
  ^
/mnt/storage/mmacy/devel/drm-next-merge/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/nstime.h:4:32:
 note: expanded from macro 'JEMALLOC_CLOCK_GETTIME'
#define JEMALLOC_CLOCK_GETTIME defined(_POSIX_MONOTONIC_CLOCK) \
   ^
1 warning generated.
jemalloc_nstime.c:120:7: warning: macro expansion producing 'defined' has 
undefined behavior [-Wexpansion-to-defined]
#elif JEMALLOC_CLOCK_GETTIME
  ^
/mnt/storage/mmacy/devel/drm-next-merge/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/nstime.h:4:32:
 note: expanded from macro 'JEMALLOC_CLOCK_GETTIME'
#define JEMALLOC_CLOCK_GETTIME defined(_POSIX_MONOTONIC_CLOCK) \

It makes sense that a define in a define has undefined behavior because it 
requires a second evaluation by the C preprocessor.



I think constant-conversion warnings are also new:

/mnt/storage/mmacy/devel/drm-next-merge/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/lib_baudrate.c:121:5:
 warning: implicit conversion from 'int' to 'short' changes value from 38400 to 
-27136 [-Wconstant-conversion]
DATA(38400),
^~~
/mnt/storage/mmacy/devel/drm-next-merge/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/lib_baudrate.c:97:24:
 note: expanded from macro 'DATA'
#define DATA(number) { B##number, number }
 ~ ^
:30:1: note: expanded from here
B38400
^~
/home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/include/sys/_termios.h:193:16:
 note: expanded from macro 'B38400'
#define B38400  38400
^
/mnt/storage/mmacy/devel/drm-next-merge/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/lib_baudrate.c:126:5:
 warning: implicit conversion from 'int' to 'short' changes value from 57600 to 
-7936 [-Wconstant-conversion]
DATA(57600),
^~~
/mnt/storage/mmacy/devel/drm-next-merge/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/lib_baudrate.c:97:24:
 note: expanded from macro 'DATA'
#define DATA(number) { B##number, number }
 ~ ^
:31:1: note: expanded from here
B57600

___
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: External toolchain support broken for devel/llvm38 but not devel/llvm37

2016-08-30 Thread Brooks Davis 
On Tue, Aug 30, 2016 at 02:50:03PM -0700, Matthew Macy wrote:
> 
> 
> 
>   On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis  
> wrote  
>  > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: 
>  > > It looks like there is something broken with the devel/llvm38 port or 
> external toolchain support has regressed: 
>  > >  
>  > >  
>  > > This works: 
>  > > make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s 
>  > >  
>  > > This fails: 
>  > >  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s 
>  > >  
>  > > with: 
>  > >  
>  > > 
> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>  
> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory 
>  > > clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation) 
>  >  
>  > I've fixed the install problem.  I'm rather confused about why clang 
>  > would try to link with sanitizer libraries when building source.  That's 
>  > certainly not default behavior. 
>  
> Thanks for the extremely prompt response to both issues. I haven't figured 
> out why svn has problems but the libc/tests failure can be traced back to the 
> following commit:
> 
> commit 3d2a537705eca33db3c523f4f92290d382aa7ab1
> Author: ngie 
> Date:   Fri Jan 2 05:40:02 2015 +
> 
> Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 
> Jenkins
> job
> 
> The h_raw application doesn't do proper bounds checking without the option
> being supplied via the build, which means that it doesn't throw signals 
> and
> fail as expected
> 
> PR: 196430
> X-MFC with: r276479
> 
> diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh 
> b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> index 04adc67..362178f 100755
> --- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> +++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> @@ -360,6 +360,9 @@ raw_head()
>  raw_body()
>  {
> prog="$(atf_get_srcdir)/h_raw"
> +   # Begin FreeBSD
> +   [ -x $prog ] || atf_skip "$prog is missing; skipping testcase"
> +   # End FreeBSD
>  
> h_pass "$prog 9"
> # Begin FreeBSD
> diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile
> index 1649cc2..7bc8660 100644
> --- a/lib/libc/tests/ssp/Makefile
> +++ b/lib/libc/tests/ssp/Makefile
> @@ -9,10 +9,7 @@ WARNS?=2
>  
>  CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector
>  .if ${COMPILER_TYPE} == "clang"
> -# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0.
> -.if ${COMPILER_VERSION} < 30500
>  CFLAGS.h_raw+= -fsanitize=bounds
> -.endif

Thanks for hunting this down.

There's no strong reason to assume that a given clang has sanitizers
available.  In the current build system, you need a clang tree to build
the sanitizers, but the build process is separate.  If we're going to
enable sanitizers in tests, we need to do so conditionally so we don't
break the tests on non-x86 systems and so compiler installs don't need
to provide them.

-- Brooks


signature.asc
Description: PGP signature

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

2016-08-30 Thread Matthew Macy 



  On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis  
wrote  
 > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: 
 > > It looks like there is something broken with the devel/llvm38 port or 
 > > external toolchain support has regressed: 
 > >  
 > >  
 > > This works: 
 > > make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
 > > XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s 
 > >  
 > > This fails: 
 > >  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
 > > XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s 
 > >  
 > > with: 
 > >  
 > > /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
 > >  
 > > /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
 > >  No such file: No such file or directory 
 > > clang-3.8: error: linker command failed with exit code 1 (use -v to see 
 > > invocation) 
 >  
 > I've fixed the install problem.  I'm rather confused about why clang 
 > would try to link with sanitizer libraries when building source.  That's 
 > certainly not default behavior. 
 
Thanks for the extremely prompt response to both issues. I haven't figured out 
why svn has problems but the libc/tests failure can be traced back to the 
following commit:

commit 3d2a537705eca33db3c523f4f92290d382aa7ab1
Author: ngie 
Date:   Fri Jan 2 05:40:02 2015 +

Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 
Jenkins
job

The h_raw application doesn't do proper bounds checking without the option
being supplied via the build, which means that it doesn't throw signals and
fail as expected

PR: 196430
X-MFC with: r276479

diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh 
b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
index 04adc67..362178f 100755
--- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
+++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
@@ -360,6 +360,9 @@ raw_head()
 raw_body()
 {
prog="$(atf_get_srcdir)/h_raw"
+   # Begin FreeBSD
+   [ -x $prog ] || atf_skip "$prog is missing; skipping testcase"
+   # End FreeBSD
 
h_pass "$prog 9"
# Begin FreeBSD
diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile
index 1649cc2..7bc8660 100644
--- a/lib/libc/tests/ssp/Makefile
+++ b/lib/libc/tests/ssp/Makefile
@@ -9,10 +9,7 @@ WARNS?=2
 
 CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector
 .if ${COMPILER_TYPE} == "clang"
-# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0.
-.if ${COMPILER_VERSION} < 30500
 CFLAGS.h_raw+= -fsanitize=bounds
-.endif
 .elif ${COMPILER_TYPE} == "gcc"
 CFLAGS.h_raw+= --param ssp-buffer-size=1
 DPADD+=${LIBSSP}
@@ -29,7 +26,11 @@ PROGS+=  h_getcwd
 PROGS+=h_memcpy
 PROGS+=h_memmove
 PROGS+=h_memset
+# This testcase doesn't run properly when not compiled with -fsantize=bounds
+# with clang, which is currently contingent on a compiler_rt update
+.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 30500
 PROGS+=h_raw
+.endif
 PROGS+=h_read
 PROGS+=h_readlink
 PROGS+=h_snprintf


___
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: External toolchain support broken for devel/llvm38 but not devel/llvm37

2016-08-30 Thread Brooks Davis 
On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote:
> It looks like there is something broken with the devel/llvm38 port or 
> external toolchain support has regressed:
> 
> 
> This works:
> make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s
> 
> This fails:
>  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s
> 
> with:
> 
> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>  
> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory
> clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation)

I've fixed the install problem.  I'm rather confused about why clang
would try to link with sanitizer libraries when building source.  That's
certainly not default behavior.

-- Brooks


signature.asc
Description: PGP signature

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

2016-08-30 Thread K. Macy 
On Monday, August 29, 2016, Volodymyr Kostyrko  wrote:

> Matthew Macy wrote:
>
>> It looks like there is something broken with the devel/llvm38 port or
>> external toolchain support has regressed:
>>
>>
>> This works:
>> make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37
>> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s
>>
>> This fails:
>>   make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38
>> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s
>>
>> with:
>>
>> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclan
>> g_rt.ubsan_standalone-x86_64.a: No such file: No such file or directory
>> clang-3.8: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>
>
> I second this - I also faced it. I think this is not a problem with a
> ports but rather with a build as correspondent files can be found in
> /usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/.
> Looks like this files are compiled during build but taken from compilers's
> directory. Linking 'em to the target directory makes build succeed.


The point of using the external toolchain for me is to bypass building
clang in src. ~31 of the ~47 minutes in buildworld are spent compiling
pieces of llvm/clang. I'd much rather fix the ports than make buildworld
require additional work. For the moment I've disconnected the two pieces
that fail: svn and libc/tests. They don't really belong in base any more
than git and piglit do.


>
> --
> Sphinx of black quartz judge my vow.
> ___
> 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: External toolchain support broken for devel/llvm38 but not devel/llvm37

2016-08-30 Thread Dimitry Andric 
On 30 Aug 2016, at 05:12, Matthew Macy  wrote:
> 
> It looks like there is something broken with the devel/llvm38 port or 
> external toolchain support has regressed:
> 
> 
> This works:
> make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s
> 
> This fails:
> make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s
> 
> with:
> 
> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>  
> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory
> clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation)

Looks like the llvm38 port didn't build the libclang_rt libraries.  These are 
needed for the sanitizers, and so on.

The llvm37 port does have these:

% ls -l llvm37/lib/clang/3.7.1/lib/freebsd
total 4188
-rw-r--r--  1 root  wheel  2083354 2016-07-12 05:08:14 libclang_rt.asan-i386.a
-rwxr-xr-x  1 root  wheel   705264 2016-07-12 05:09:27 libclang_rt.asan-i386.so*
-rw-r--r--  1 root  wheel 1620 2016-07-12 05:08:06 
libclang_rt.asan-preinit-i386.a
-rw-r--r--  1 root  wheel35914 2016-07-12 05:08:12 
libclang_rt.asan_cxx-i386.a
-rw-r--r--  1 root  wheel   120524 2016-07-12 05:08:18 
libclang_rt.builtins-i386.a
-rw-r--r--  1 root  wheel33904 2016-07-12 05:08:19 
libclang_rt.profile-i386.a
-rw-r--r--  1 root  wheel   417872 2016-07-12 05:08:19 
libclang_rt.safestack-i386.a
-rw-r--r--  1 root  wheel   659270 2016-07-12 05:08:02 
libclang_rt.ubsan_standalone-i386.a
-rw-r--r--  1 root  wheel21234 2016-07-12 05:08:02 
libclang_rt.ubsan_standalone_cxx-i386.a

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: FreeBSD 11.0-RC1 boot prompt kernel load issue.

2016-08-30 Thread Murthy Bhat 
Hi John,

Thanks for your quick response.

I did the same exercise on a super micro(X59SRL model) server, to segregate the 
issue. The same issue is reproduced again.

So IMHO this may not be the system UEFI firmware issue due to following two 
reasons.
1.  "load kernel" does not work on 2 different hardware platforms.
2.  On FreeBSD 10.3 and 10.2, both the hardware platforms (HP ProLiant 
ML110 Gen9 and Super micro X59SRL) work without problem.

Could you please advise some work around or any other exercise to narrow down 
the issue.

Regards/Ram


-Original Message-
From: John Baldwin [mailto:j...@freebsd.org] 
Sent: Tuesday, August 30, 2016 3:57 AM
To: Murthy Bhat 
Cc: freebsd-current@freebsd.org; FreeBSD-current@FreeBSD.org
Subject: Re: FreeBSD 11.0-RC1 boot prompt kernel load issue.

EXTERNAL EMAIL


On Monday, August 29, 2016 05:37:57 PM Murthy Bhat wrote:
> Thanks for the response.
>
> It is UEFI boot. As such there is no stack dumped on the console 
> during crash. System restarts from the FreeBSD boot prompt without any 
> message on the console. Still I have a picture where monitor goes off 
> during data load. PFA(sorry for the flash)

Ugh.  I don't have a good suggestion on debugging this besides adding printfs 
to the EFI loader code and/or moving an infinite loop around in the code to 
narrow down exactly when it resets.  It is quite possibly specific to the EFI 
firmware on your machine (at least, reproducing the issue might be).

> Regards/Murthy Bhat
>
> -Original Message-
> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Monday, August 29, 2016 10:52 PM
> To: freebsd-current@freebsd.org
> Cc: Murthy Bhat ; 
> FreeBSD-current@FreeBSD.org
> Subject: Re: FreeBSD 11.0-RC1 boot prompt kernel load issue.
>
> EXTERNAL EMAIL
>
>
> On Wednesday, August 24, 2016 01:35:08 PM Murthy Bhat wrote:
> >
> > Hi,
> >
> > This is regarding issue faced during OS(FreeBSD 11.0-RC1) installation on 
> > the storage behind our smartpqi storage controller.
>
> Are you using EFI or legacy boot?  Also, can you capture a screenshot of the 
> crash messages?  If it is not EFI, we probably crashed in the BIOS routines 
> used to read data from the USB drive.  It may be a BIOS bug (which isn't 
> easily fixable), but we would need the register dump from the crash to figure 
> anything out.
>
> --
> John Baldwin


--
John Baldwin
___
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 #574

2016-08-30 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"

FreeBSD_HEAD_amd64_gcc - Build #1505 - Still Failing

2016-08-30 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1505 - Still Failing:

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

Change summaries:

305058 by jmcneill:
Add support for Allwinner A64 watchdog timer.

305057 by kevlo:
Update a comment to reflect r305051.

305056 by markj:
Restore swap pager readahead after r292373.

The removal of vm_fault_additional_pages() meant that a hard fault on
a swap-backed page would result in only that page being read in. This
change implements readahead and readbehind for the swap pager in
swap_pager_getpages(). swap_pager_haspage() is modified to return the
largest contiguous non-resident range of pages containing the requested
range.

Reviewed by:alc, kib
Tested by:  pho
MFC after:  1 month
Differential Revision:  https://reviews.freebsd.org/D7677

305055 by markj:
Recursively enumerate anonymous structs and unions in ctf_member_info().

Previously, ctf_member_info() would ignore members belonging to an
anonymous struct or union. This made it impossible to, for example, trace
the m_next field of an mbuf using DTrace.

Reported and tested by: gallatin
MFC after:  2 weeks

305054 by sephe:
hyperv/hn: Remove unnecessary NULL check.

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7690

305053 by sephe:
hyperv/hn: Log packet message alignment.

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7689

305052 by sephe:
hyperv/hn: Remove the useless rndis_device and related bits

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7687

305051 by kevlo:
Zap M_IOVEC.

Reviewed by:Matthew Macy

305050 by sephe:
hyperv/hn: Switch to new RNDIS transaction execution for halt.

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7686

305049 by sephe:
hyperv/hn: Factor out func to exec RNDIS transaction w/o checking result

It will be used by RNDIS HALT and RESET.

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7685

305048 by sephe:
hyperv/hn: Remove unused function

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7684

305047 by sephe:
hyperv/hn: Switch to new RNDIS set for RX filters.

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7683

305046 by sephe:
net/rndis: Packet types are defined by NDIS; not RNDIS specific.

Reviewed by:hps
MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7681

305045 by sephe:
hyperv/hn: Indentation and field comment fixup for ndis.h.

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7680

305044 by sephe:
hyperv/hn: Move OIDs to net/rndis.h; they are standard NDIS OIDs.

Actually all OIDs defined in net/rndis.h are standard NDIS OIDs.
While I'm here, use the verbose macro name as in NDIS spec.

MFC after:  1 week
Sponsored by:   Microsoft
Differential Revision:  https://reviews.freebsd.org/D7679

305043 by jhibbits:
Attach and LAW problems to fix

Summary:
1) Attach problem - mpc85xx_probe() relies on fact that 0xfff0 mask matches all
QorIQ CPUs what is not true since e6500. This shall be reworked to match against
all supported CPUs.

2) There is no any reason for operating system to re-program or anyhow else
touch the LAWs programmed by firmware (u-boot). Right now mpc85xx_attach()
removes all LaW entries except for DRAM. This causes MCE to be generated when
later any of driver maps DTB-provided hardware addresses which do not exist
anymore because corresponding LaWs were removed.

Submitted by:   Ivan Krivonos 
Differential Revision: https://reviews.freebsd.org/D7663

305041 by ngie:
Filter certain compile-time options into -DATF_BUILD_*

Items filtered through are:

- Constant defines (-D)
- Include flags (-I)
- Linker flags (-L)
- Optimization level (-O)
- Warnings / linker flags (-W)
- Preprocessor options (-f)

This fixes the scenario hit by the Jenkins job where it's infecting
the build with --sysroot, etc options from the Jenkins build in the
tests.

Prefix all intermediate variables (_CFLAGS, etc) with "ATF_BUILD" [*].

MFC after:  2 weeks
Reported by:Jenkins
Requested by:   jmmv
Reviewed by:jmmv
Sponsored by:   EMC / Isilon Storage Division
Differential Revision:  https://reviews.freebsd.org/D7702

305040 by jhibbits:
Add support for NXP/Freescale etsec2 ethernet controller

Adding the compatible property check isn't enough.  Device trees for eTSEC2
devices are missing a 'reg' property on the eTSEC node itself, relegating it to
the queue group child

Re: problems with mouse

2016-08-30 Thread Antonio Olivares 
Dear folks,

I am not sure if hald_enable="YES" is still needed, but I will add it
to see if the mouse problem goes away, because mouse works, but when I
switch apps, ie. firefox to xterm, then I cannot switch back to
firefox till I finish with xterm :(.  If it works well and fixes the
problem, I will let you all know and hopefully it does fix the issue.

Best Regards,


Antonio

On Tue, Aug 30, 2016 at 12:15 AM, Bruce Evans  wrote:
> On Mon, 29 Aug 2016, Hans Petter Selasky wrote:
>
>> On 08/29/16 22:12, Antonio Olivares wrote:
>>>
>>>
>>> I apologize in advance if this is not in the right list, if I need to
>>> pose this question in questions, I will do so as soon as I find out.
>>> I am having trouble with switching apps in Lumina desktop with the
>>> mouse, I removed moused from /etc/rc.conf because I have a usb mouse
>>> and still lose when I switch from firefox to terminal or vice versa.
>>>
>>> $ uname -a
>>> FreeBSD hp 11.0-RC2 FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03
>>> UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
>>>  amd64
>>>
>>> Is there a way to troubleshoot this?  Is there something that can fix
>>> this?
>>
>>
>> Bruce Evans has fixed some issues with SC/VT mouse/keyboard stuff in
>> 12-current. Maybe he has some ideas.
>
>
> I only know about sc/atkbd and am trying not to break ukbd.
>
> The cause of Bug 211884 (ukbd?) is still unknown.  Bugzilla is too hard
> to access for me, but the PR seems to be missing critical info about the
> environment (is the console vt or sc?).
>
> kbdmux is still missing the fix that is blamed for causing Bug 211884.
> I need to fix kbdmux before changing sc to depend on it being fixed.
> vt already depends on it being fixed.  Howver, vt also depends on
> going through kbdmux.  ukbd doesn't attach properly directly for vt.
>
> ukbd passed tests of working in panic mode yesterday.  It actually
> works perfectly in panic + ddb (polled) mode.  Much better than in
> just ddb mode.  Panic mode turns off its locking and thus gives
> races instead of deadlocks and assertion failures, and the races
> aren't very harmful in panic mode.  So the basic polling method in
> ukbd is working except when it tries to do correct locking.
>
> 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"

Jenkins build is still unstable: FreeBSD_HEAD #573

2016-08-30 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: External toolchain support broken for devel/llvm38 but not devel/llvm37

2016-08-30 Thread Volodymyr Kostyrko 

Matthew Macy wrote:

It looks like there is something broken with the devel/llvm38 port or external 
toolchain support has regressed:


This works:
make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s

This fails:
  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s

with:

/home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: 
/usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
 No such file: No such file or directory
clang-3.8: error: linker command failed with exit code 1 (use -v to see 
invocation)


I second this - I also faced it. I think this is not a problem with a 
ports but rather with a build as correspondent files can be found in 
/usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/. 
Looks like this files are compiled during build but taken from 
compilers's directory. Linking 'em to the target directory makes build 
succeed.


--
Sphinx of black quartz judge my vow.
___
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: problems with mouse

2016-08-30 Thread Bruce Evans 

On Mon, 29 Aug 2016, Hans Petter Selasky wrote:


On 08/29/16 22:12, Antonio Olivares wrote:


I apologize in advance if this is not in the right list, if I need to
pose this question in questions, I will do so as soon as I find out.
I am having trouble with switching apps in Lumina desktop with the
mouse, I removed moused from /etc/rc.conf because I have a usb mouse
and still lose when I switch from firefox to terminal or vice versa.

$ uname -a
FreeBSD hp 11.0-RC2 FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03
UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
 amd64

Is there a way to troubleshoot this?  Is there something that can fix this?


Bruce Evans has fixed some issues with SC/VT mouse/keyboard stuff in 
12-current. Maybe he has some ideas.


I only know about sc/atkbd and am trying not to break ukbd.

The cause of Bug 211884 (ukbd?) is still unknown.  Bugzilla is too hard
to access for me, but the PR seems to be missing critical info about the
environment (is the console vt or sc?).

kbdmux is still missing the fix that is blamed for causing Bug 211884.
I need to fix kbdmux before changing sc to depend on it being fixed.
vt already depends on it being fixed.  Howver, vt also depends on
going through kbdmux.  ukbd doesn't attach properly directly for vt.

ukbd passed tests of working in panic mode yesterday.  It actually
works perfectly in panic + ddb (polled) mode.  Much better than in
just ddb mode.  Panic mode turns off its locking and thus gives
races instead of deadlocks and assertion failures, and the races
aren't very harmful in panic mode.  So the basic polling method in
ukbd is working except when it tries to do correct locking.

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"

Jenkins build is still unstable: FreeBSD_HEAD #572

2016-08-30 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 #571

2016-08-30 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"