FreeBSD_STABLE_11-i386 - Build #89 - Still Failing

[jenkins-admin]

FreeBSD_STABLE_11-i386 - Build #89 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-i386/89/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-i386/89/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_11-i386/89/console

Change summaries:

304943 by alc:
MFC r304050
  Eliminate two calls to vm_page_xunbusy() that are both unnecessary and
  incorrect from the error cases in exec_map_first_page().  They are
  unnecessary because we automatically unbusy the page in vm_page_free()
  when we remove it from the object.  The calls are incorrect because they
  happen after the page is freed, so we might actually unbusy the page
  after it has been reallocated to a different object.  (This error was
  introduced in r292373.)



The end of the build log:

[...truncated 16285 lines...]
clang-tblgen -gen-clang-diags-defs -clang-component=Sema  -I 
/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include/clang/Basic
 -d DiagnosticSemaKinds.inc.d  -o DiagnosticSemaKinds.inc.h 
/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
--- all_subdir_lib/clang/libclanganalysis ---
--- CommentNodes.inc.h ---
clang-tblgen -gen-clang-comment-nodes  -d CommentNodes.inc.d -o 
CommentNodes.inc.h  
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic/CommentNodes.td
--- DeclNodes.inc.h ---
clang-tblgen -gen-clang-decl-nodes  -d DeclNodes.inc.d -o DeclNodes.inc.h  
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic/DeclNodes.td
--- DiagnosticAnalysisKinds.inc.h ---
clang-tblgen -gen-clang-diags-defs -clang-component=Analysis  -I 
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic
 -d DiagnosticAnalysisKinds.inc.d  -o DiagnosticAnalysisKinds.inc.h 
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
--- all_subdir_lib/clang/libclangbasic ---
--- DiagnosticCommonKinds.inc.h ---
clang-tblgen -gen-clang-diags-defs -clang-component=Common  -I 
/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic
 -d DiagnosticCommonKinds.inc.d  -o DiagnosticCommonKinds.inc.h 
/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
--- all_subdir_lib/clang/libclangast ---
--- DiagnosticCommonKinds.inc.h ---
clang-tblgen -gen-clang-diags-defs -clang-component=Common  -I 
/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include/clang/Basic
 -d DiagnosticCommonKinds.inc.d  -o DiagnosticCommonKinds.inc.h 
/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
--- all_subdir_lib/clang/libclanganalysis ---
--- StmtNodes.inc.h ---
clang-tblgen -gen-clang-stmt-nodes  -d StmtNodes.inc.d -o StmtNodes.inc.h  
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/Basic/StmtNodes.td
--- all_subdir_lib/clang/libclangcodegen ---
--- AttrList.inc.h ---
clang-tblgen -gen-clang-attr-list  -I 
/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -d 
AttrList.inc.d -o AttrList.inc.h  
/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include/clang/Basic/Attr.td
--- all_subdir_lib/clang/libclanganalysis ---
--- AnalysisDeclContext.o ---
c++  -O2 -pipe 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis
 -I. 
-I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"i386-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.AnalysisDeclContext.o 
-MTAnalysisDeclContext.o -Qunused-arguments 
-I/usr/obj/usr/src/tmp/legacy/usr/include  -std=c++11 -fno-exceptions -fno-rtti 
-stdlib=libc++ -Wno-c++11-extensions  -c 
/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/AnalysisDeclContext.cpp
 -o AnalysisDeclContext.o
--- all_subdir_lib/clang/libclangbasic ---
--- DiagnosticDriverKinds.inc.h ---
clang-tblgen -gen-clang-diags-defs -clang-component=Driver  -I 
/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic
 -d DiagnosticDriverKinds.inc.d  -o DiagnosticDriverKinds.inc.h 
/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
--- all_subdir_lib/clang/libclangcodegen ---
--- Attributes.inc.h ---
llvm-tblgen -gen-attrs  -I 
/usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -d 
Attributes.inc.d -o Attributes.inc.h  

Re: Benchmarks results for FreeBSD 11

[K. Macy]

> The problem here is that Phoronix took a Beta version of FreeBSD 11.
> Beta versions have a lot of debugging (malloc, invariants, witness)
> options enabled which make it significantly slower than release
> versions. This is even obviously when you run a Beta as a desktop. It
> just feels much slower.


I don't know what was going on in these particular tests, but in a
more recent benchmarking run
-https://www.phoronix.com/scan.php?page=article=freebsd11-clang-gcc=1
- you're seeing the result of openmp being disabled in base. The clang
maintainer for src refuses to include libomp as required for -fopenmp
because nothing in base requires it. I certainly can't speak for the
community as a whole - but based on my experience when discussing new
features that adversely impact networking performance my impression is
that out of the box performance is generally not a priority.

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

Re: Benchmarks results for Compilers on FreeBSD 11

[Fernando Herrero Carrón]

El 28/8/2016 0:06, "Erich Dollansky"  escribió:
>
> Hi,
>
> Micheal did a plain compiler benchmark on FreeBSD 11:
>
>
http://www.phoronix.com/scan.php?page=article=freebsd11-clang-gcc=1
>
> It shows clearly how slow CLang is compared to GCC.
>
> This is the price FreeBSD has to pay to be free of GPL in the base
> system.
>
> Erich

Very cool comparison, thanks a lot!

I think gcc has a lot of knowledge and experience under its belt, a larger
user base so no wonder it performs [slightly] worse. What has really
surprised me has been ImageMagick, apparently because of openmp. The OpenMP
stack has been contributed by intel, clang 3.4 if I recall it right.
Surprising.

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

Build Failing 11/stable - svn r304921 - "ld: cannot find -lsbuf"

[David P. Discher]

I’ve been having an issue for a few days on 11-stable (… maybe longer with 
-current/-head in general) … especially with parallel makes (-j12) on amd64.   
I wasn’t capturing the logs, so finally did, and looking back, the error 
appears to be :


--- lib/libgeom__L ---
cc  -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings 
-Wl,--warn-shared-textrel  -o libgeom.so.5.full -Wl,-soname,libgeom.so.5  
`NM='nm' NMFLAGS='' lorder geom_getxml.So geom_stats.So geom_xml2tree.So 
geom_ctl.So geom_util.So | tsort -q`  -lbsdxml  -lsbuf
/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lsbuf
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libgeom.so.5.full] Error code 1


This is a clean chroot,  with just make installworld from a previous 
11-pre-release that the host is running.  /usr/src and /usr/obj are NFS mounts 
from a 10.3 machine with ZFS.

Appears to be some sort of race condition?   I’ve build 10-stable, and probably 
9.X this way for years, but -current seems to have this issue.

Will try local disks, then single process … but it would be nice to get this 
parallel build fixed.



Building the lib alone works:

root@borg:/usr/src/lib/libgeom # ls
Makefilegeom_ctl.c  geom_stats.cgeom_xml2tree.c libgeom.h
Makefile.depend geom_getxml.c   geom_util.c libgeom.3
root@borg:/usr/src/lib/libgeom # make
cc -pg  -O2 -pipe -I/usr/src/lib/libgeom   -MD  -MF.depend.geom_getxml.po 
-MTgeom_getxml.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-arguments  -c /usr/src/lib/libgeom/geom_getxml.c -o geom_getxml.po
cc -pg  -O2 -pipe -I/usr/src/lib/libgeom   -MD  -MF.depend.geom_stats.po 
-MTgeom_stats.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-arguments  -c /usr/src/lib/libgeom/geom_stats.c -o geom_stats.po
cc -pg  -O2 -pipe -I/usr/src/lib/libgeom   -MD  -MF.depend.geom_xml2tree.po 
-MTgeom_xml2tree.po -std=gnu99 -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-arguments  -c /usr/src/lib/libgeom/geom_xml2tree.c -o geom_xml2tree.po
cc -pg  -O2 -pipe -I/usr/src/lib/libgeom   -MD  -MF.depend.geom_ctl.po 
-MTgeom_ctl.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-arguments  -c /usr/src/lib/libgeom/geom_ctl.c -o geom_ctl.po
cc -pg  -O2 -pipe -I/usr/src/lib/libgeom   -MD  -MF.depend.geom_util.po 
-MTgeom_util.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-arguments  -c /usr/src/lib/libgeom/geom_util.c -o geom_util.po
building profiled geom library
ar -crD libgeom_p.a `NM='nm' NMFLAGS='' lorder geom_getxml.po geom_stats.po 
geom_xml2tree.po geom_ctl.po geom_util.po  | tsort -q`
ranlib -D libgeom_p.a
make: /usr/obj/usr/src/lib/libgeom/.depend, 1: ignoring stale .depend for 
/usr/obj/usr/src/tmp/usr/lib/libsbuf.a
building shared library libgeom.so.5
cc  -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings 
-Wl,--warn-shared-textrel  -o libgeom.so.5.full -Wl,-soname,libgeom.so.5  
`NM='nm' NMFLAGS='' lorder geom_getxml.So geom_stats.So geom_xml2tree.So 
geom_ctl.So geom_util.So | tsort -q`  -lbsdxml  -lsbuf
objcopy --only-keep-debug libgeom.so.5.full libgeom.so.5.debug
objcopy --strip-debug --add-gnu-debuglink=libgeom.so.5.debug  

Re: Benchmarks results for Compilers on FreeBSD 11

[Erich Dollansky]

Hi,

Micheal did a plain compiler benchmark on FreeBSD 11:

http://www.phoronix.com/scan.php?page=article=freebsd11-clang-gcc=1

It shows clearly how slow CLang is compared to GCC. 

This is the price FreeBSD has to pay to be free of GPL in the base
system. 

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

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

[Frederic Chardon]

2016-08-25 13:29 GMT+02:00 Frederic Chardon :
>
> Le 23 août 2016 20:24, "Frederic Chardon"  a
> écrit :
>>
>> 2016-08-23 19:35 GMT+02:00 Frederic Chardon :
>> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov :
>> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon"
>> >>>  a
>> >>> ??crit :
>> >>> >
>> >>> > Hi
>> >>> >
>> >>> > I see a strange interaction between zfs on root and
>> >>> > kern.proc.pathname
>> >>> > on my laptop. Whenever I try to use gcore it fails with:
>> >>> > gcore 1023
>> >>> > gcore: kern.proc.pathname failure
>> >>> >
>> >>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>> >>> >
>> >>> > I made some tests booting from usb stick (fresh installworld, no
>> >>> > src.conf, no make.conf, GENERIC kernel)
>> >>> > What works: having / on ufs and importing a zfs pool later on.
>> >>> > What doesn't: having / on zfs, whatever the settings for checksum,
>> >>> > compression, or normalization.
>> >>> >
>> >>> > Both 11-stable and 12-current behave this way. Current from may-june
>> >>> > worked properly.
>> >>> > adb, chromium and virtualbox as well stopped working at
>> >>> > approximately
>> >>> > the same time, however I don't know if it is linked ("truss -f adb
>> >>> > start-server" shows that garbage is passed to execl after forking).
>> >>> >
>> >>> > Any idea what's going on? Does anybody else see this?
>> >>> >
>> >>> > Thanks!
>> >>>
>> >>> Nobody else have this problem? I reinstalled the system from scratch
>> >>> and
>> >>> still gcore fails with the same error, even in single user mode.
>> >>
>> >> Do you have a property on your root fs which forces it to ignore case
>> >> in
>> >> the file names ?
>> >
>> > No. I do have normalization set to formC though. I observed the same
>> > behavior with the property unset (in fact, with no property set to
>> > anything but default as well).
>> > If I boot from usb stick and import the pool afterwards it works
>> > properly.
>> >
>> > zpool get all zbase
>> > NAME   PROPERTY   VALUE
>> > SOURCE
>> > zbase  size   9,94G  -
>> > zbase  capacity   43%-
>> > zbase  altroot-
>> > default
>> > zbase  health ONLINE -
>> > zbase  guid   8964242380523899513
>> > default
>> > zbase  version-
>> > default
>> > zbase  bootfs zbase/bootenv/11-STABLE
>> > local
>> > zbase  delegation on
>> > default
>> > zbase  autoreplaceoff
>> > default
>> > zbase  cachefile  -
>> > default
>> > zbase  failmode   wait
>> > default
>> > zbase  listsnapshots  off
>> > default
>> > zbase  autoexpand off
>> > default
>> > zbase  dedupditto 0
>> > default
>> > zbase  dedupratio 1.00x  -
>> > zbase  free   5,65G  -
>> > zbase  allocated  4,29G  -
>> > zbase  readonly   off-
>> > zbase  comment-
>> > default
>> > zbase  expandsize -  -
>> > zbase  freeing0
>> > default
>> > zbase  fragmentation  41%-
>> > zbase  leaked 0
>> > default
>> > zbase  feature@async_destroy  enabled
>> > local
>> > zbase  feature@empty_bpobjactive
>> > local
>> > zbase  feature@lz4_compress   active
>> > local
>> > zbase  feature@multi_vdev_crash_dump  enabled
>> > local
>> > zbase  feature@spacemap_histogram active
>> > local
>> > zbase  feature@enabled_txgactive
>> > local
>> > zbase  feature@hole_birth active
>> > local
>> > zbase  feature@extensible_dataset enabled
>> > local
>> > zbase  feature@embedded_data  active
>> > local
>> > zbase  feature@bookmarks  enabled
>> > local
>> > zbase  feature@filesystem_limits  enabled
>> > local
>> > zbase  feature@large_blocks   enabled
>> > local
>> > zbase  feature@sha512 enabled
>> > local
>> > zbase  feature@skein  enabled
>> > local
>> >
>> >
>> > zfs get all zbase/bootenv/11-STABLE
>> > NAME PROPERTY  VALUE
>> > SOURCE
>> > zbase/bootenv/11-STABLE  type  filesystem
>> > -
>> > zbase/bootenv/11-STABLE  creation  sam. août 20 13:07 2016
>> > -
>> > zbase/bootenv/11-STABLE  used  4,23G
>> > -
>> > 

Re: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?]

[Mark Millard]

Quick top post: retrying "portmaster -DKa" after rebooting did not repeat the 
panic.

OPTIONS_FILE_SET+=RELRO likely has nothing to do with the unusual panic.

===
Mark Millard
markmi at dsl-only.net

On 2016-Aug-27, at 3:35 AM, Mark Millard  wrote:

[I've no solid evidence of what the panic is tied to. OPTIONS_FILE_SET+=RELRO 
ise is just what was new/unusual in the portmaster -DKa that was going on when 
the rpi2 had the panic.]

The console history shows (the cc quoted just gives a ball park for where it 
was in the binutils build):

> cc -DHAVE_CONFIG_H -I.  -I. -I. -I../bfd -I./../bfd -I./../include  -pipe 
> -mcpu=cortex-a7  -I/usr/local/include -g -fno-strict-aliasing 
> -DENABLE_PLUGINS -DLOCAL
> EDIR="\"/usr/local/share/locale\"" -mcpu=cortex-a7 -W -Wall 
> -Wstrict-prototypes -Wmissing-prototypes -Wshadow -DELF_LIST_OPTIONS=TRUE 
> -DELF_SHLIB_LIST_OPTIONS=T
> RUE -DELF_PLT_UNWIND_LIST_OPTIONS=TRUE -pipe -mcpu=cortex-a7  
> -I/usr/local/include -g -fno-strict-aliasing -MT eavrxmega2.o -MD -MP -MF 
> .deps/eavrxmega2.Tpo -c 
> -o eavrxmega2.o eavrxmega2.c
> panic: pmap_fault: PT2MAP abort
> cpuid = 3
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> pc = 0xc06b2ad0  lr = 0xc014edf4 (db_trace_self_wrapper+0x30)
> sp = 0xed27c880  fp = 0xed27c998
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> pc = 0xc014edf4  lr = 0xc0336968 (vpanic+0x13c)
> sp = 0xed27c9a0  fp = 0xed27c9c0
> r4 = 0x0100  r5 = 0xc4125a50
> r6 = 0xc076ab91  r7 = 0x0001
> vpanic() at vpanic+0x13c
> pc = 0xc0336968  lr = 0xc033682c (vpanic)
> sp = 0xed27c9c8  fp = 0xed27c9cc
> r4 = 0xc0991ba0  r5 = 0x
> r6 = 0xbfefefe8  r7 = 0x0007
> r8 = 0x0013  r9 = 0x0007
>r10 = 0xc41daf44
> vpanic() at vpanic
> pc = 0xc033682c  lr = 0xc06ce40c (pmap_fault+0x638)
> sp = 0xed27c9d4  fp = 0xed27ca08
> r4 = 0x0007  r5 = 0x0013
> r6 = 0x0007  r7 = 0xc41daf44
> r8 = 0xed27c9cc  r9 = 0xc033682c
>r10 = 0xed27c9d4
> pmap_fault() at pmap_fault+0x638
> pc = 0xc06ce40c  lr = 0xc06d30f8 (abort_handler+0xbc)
> sp = 0xed27ca10  fp = 0xed27caa0
> r4 = 0xc0991ba0  r5 = 0x0007
> r6 = 0x  r7 = 0x0007
> r8 = 0x0013  r9 = 0xc4125a50
>r10 = 0xed27caa8
> abort_handler() at abort_handler+0xbc
> pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
> sp = 0xed27caa8  fp = 0xed27cb60
> r4 = 0xc0991ba0  r5 = 0x
> r6 = 0xbfbfaa04  r7 = 0x0006
> r8 = 0xc41daf54  r9 = 0x0806
>r10 = 0xc41daf44
> exception_exit() at exception_exit
> pc = 0xc06b53b8  lr = 0xc03131e8 (__mtx_lock_sleep+0x220)
> sp = 0xed27cb38  fp = 0xed27cb60
> r0 = 0x002fefe8  r1 = 0xbfc0
> r2 = 0xc41daf44  r3 = 0x0001
> r4 = 0xc0991ba0  r5 = 0x
> r6 = 0xbfbfaa04  r7 = 0x0006
> r8 = 0xc41daf54  r9 = 0x0806
>r10 = 0xc41daf44 r12 = 0xed27ca78
> pmap_fault() at pmap_fault+0x1b4
> pc = 0xc06cdf88  lr = 0xc06d30f8 (abort_handler+0xbc)
> sp = 0xed27cb68  fp = 0xed27cbf8
> r4 = 0x0030  r5 = 0x0006
> r6 = 0x  r7 = 0x0806
> r8 = 0x0013  r9 = 0xc4125a50
>r10 = 0xed27cc00
> abort_handler() at abort_handler+0xbc
> pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
> sp = 0xed27cc00  fp = 0x
> r4 = 0x0030  r5 = 0x
> r6 = 0x  r7 = 0xed27ccb4
> r8 = 0xed27ce00  r9 = 0x
>r10 = 0xed27cea0
> exception_exit() at exception_exit
> pc = 0xc06b53b8  lr = 0xc06ad77c (copyout+0x9c)
> sp = 0xed27cc94  fp = 0x
> r0 = 0xed27ccb8  r1 = 0xbfbfaa04
> r2 = 0x  r3 = 0x
> r4 = 0x0030  r5 = 0x
> r6 = 0x  r7 = 0xed27ccb4
> r8 = 0xed27ce00  r9 = 0x
>r10 = 0xed27cea0 r12 = 0x
> copyout() at copyout+0x2c4
> pc = 0xc06ad9a4  lr = 0xc06ad77c (copyout+0x9c)
> sp = 0xed27cc94  fp = 0x
> copyout() at copyout+0x9c
> pc = 0xc06ad77c  lr = 0xc06ad77c (copyout+0x9c)
> sp = 0xed27cc94  fp = 0x
> Unwind failure (no registers changed)
> KDB: enter: panic
> [ thread pid 54457 tid 100158 ]
> Stopped at  $d.6:   ldrbr15, [r15, r15, ror r15]!
> db> 

The portmaster -DKa attempt to rebuild binutils-2.27 on the rpi2 got my first 
armv6 stable/11 panic (and it has been much longer then that since I've gotten 
a 11.0-CURRENT panic). I was not around when the panic happened but it is still 
sitting at the db> serial console prompt and I can enter commands if 
appropriate.

FreeBSD 11.0 context: The rpi2 was/is at /usr/src/ stable/11 -r304029 : it has 
been a while since I've updated to track stable/11 . The few differences in my 

Wifi laggy in RC2 - was: FreeBSD 11 RC1 - no wifi

[Stefan Wendler]

On 08/26/2016 05:17, lenz wrote:
> I run a X1 Carbon 4th gen and can report that the iwm driver now runs very
> reliable with RC2, reliable enough that I moved it back into loader.conf
> and did not see any panics after a bunch or reboots. Thanks for the good
> work on this :)
> 
> cheers
> Lenz
> 
With my W530 Wifi with iwn works now without the lagg config as well as
with the patch from here
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211689#c4 and lagg config

Anyway. I have switched now to my T540p with a 7260AC wifi chip. When I
load iwm during boot, the computer crashes and enters a boot loop until
I disable iwm at the loader prompt. I can then load it manually after
boot and have wifi for some time. But it is pretty laggy and reconnects
every 5 minutes or so with the following dmesg entry.

-- dmesg --
wlan0: link state changed to DOWN
wlan0: ieee80211_new_state_locked: pending SCAN -> ASSOC transition lost
iwm0: iwm_update_edca: called
iwm0: dumping device error log
iwm0: Start Error Log Dump:
iwm0: Status: 0x3, count: 6
iwm0: 0x0086 | NMI_INTERRUPT_INST_ACTION_PT
iwm0: 02F0 | trm_hw_status0
iwm0:  | trm_hw_status1
iwm0: 0B2C | branchlink2
iwm0: 00016A90 | interruptlink1
iwm0: 00015A28 | interruptlink2
iwm0:  | data1
iwm0: 0004 | data2
iwm0: 0703 | data3
iwm0: 00307A6F | beacon time
iwm0: 000F858F | tsf low
iwm0:  | tsf hi
iwm0:  | time gp1
iwm0: 000F8590 | time gp2
iwm0:  | uCode revision type
iwm0: 0010 | uCode version major
iwm0: 0003B2EE | uCode version minor
iwm0: 0144 | hw version
iwm0: 9004 | board version
iwm0: 001C | hcmd
iwm0: 00022088 | isr0
iwm0: 0080 | isr1
iwm0: 0002 | isr2
iwm0: 004034C1 | isr3
iwm0:  | isr4
iwm0: 01010112 | last cmd Id
iwm0:  | wait_event
iwm0: 00A0 | l2p_control
iwm0:  | l2p_duration
iwm0:  | l2p_mhvalid
iwm0:  | l2p_addr_match
iwm0: 0007 | lmpm_pmg_sel
iwm0: 22121936 | timestamp
iwm0: 00342028 | flow_handler
iwm0: driver status:
iwm0:   tx ring  0: qid=0  cur=2   queued=2
iwm0:   tx ring  1: qid=1  cur=0   queued=0
iwm0:   tx ring  2: qid=2  cur=0   queued=0
iwm0:   tx ring  3: qid=3  cur=0   queued=0
iwm0:   tx ring  4: qid=4  cur=0   queued=0
iwm0:   tx ring  5: qid=5  cur=0   queued=0
iwm0:   tx ring  6: qid=6  cur=0   queued=0
iwm0:   tx ring  7: qid=7  cur=0   queued=0
iwm0:   tx ring  8: qid=8  cur=0   queued=0
iwm0:   tx ring  9: qid=9  cur=34  queued=0
iwm0:   tx ring 10: qid=10 cur=0   queued=0
iwm0:   tx ring 11: qid=11 cur=0   queued=0
iwm0:   tx ring 12: qid=12 cur=0   queued=0
iwm0:   tx ring 13: qid=13 cur=0   queued=0
iwm0:   tx ring 14: qid=14 cur=0   queued=0
iwm0:   tx ring 15: qid=15 cur=0   queued=0
iwm0:   tx ring 16: qid=16 cur=0   queued=0
iwm0:   tx ring 17: qid=17 cur=0   queued=0
iwm0:   tx ring 18: qid=18 cur=0   queued=0
iwm0:   tx ring 19: qid=19 cur=0   queued=0
iwm0:   tx ring 20: qid=20 cur=0   queued=0
iwm0:   tx ring 21: qid=21 cur=0   queued=0
iwm0:   tx ring 22: qid=22 cur=0   queued=0
iwm0:   tx ring 23: qid=23 cur=0   queued=0
iwm0:   tx ring 24: qid=24 cur=0   queued=0
iwm0:   tx ring 25: qid=25 cur=0   queued=0
iwm0:   tx ring 26: qid=26 cur=0   queued=0
iwm0:   tx ring 27: qid=27 cur=0   queued=0
iwm0:   tx ring 28: qid=28 cur=0   queued=0
iwm0:   tx ring 29: qid=29 cur=0   queued=0
iwm0:   tx ring 30: qid=30 cur=0   queued=0
iwm0:   rx ring: cur=34
iwm0:   802.11 state 1
iwm0: iwm_intr: controller panicked, iv_state = 1; restarting
wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost
iwm0: PHY ctxt cmd error. ret=35
iwm0: iwm_auth: failed add phy ctxt!
iwm0: iwm_newstate: could not move to auth state: 60
iwm0: iwm_update_edca: called
iwm0: iwm_update_edca: called
iwm0: iwm_update_edca: called
wlan0: link state changed to UP
-- end dmesg --

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

Re: Error compiling stable/11 from stable/10

[Matt Smith]

On Aug 27 08:56, Matt Smith wrote:
I have not been running this build within script(1) though I am afraid 
so I don't have a copy of the whole build.  I might stop the build and 
reenable all of the options again, but this time with a completely 
empty ccache.


I just tried this, and it bombed out again. This time I have a full 
build log which you can find at https://xtaz.uk/temp/build.log


This was with all of those commented out options in make.conf and 
src.conf from my last email uncommented once again, but with a 
completely clean ccache. This time I'm trying another build but with 
ccache commented out, but the three src.conf options still enabled.  
Luckily when it bombs out it bombs out within an hour or so. Whereas 
last night with both the src.conf and make.conf options commented out it 
was still compiling stuff after 14 hours, so I assume that made it past 
that point. Although I'm still shocked why it was still going after 14 
hours when it completed the process within 5 hours on 10.x.


I'll let you know how this build goes with the current settings.

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

Re: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?]

[Mark Millard]

[I've no solid evidence of what the panic is tied to. OPTIONS_FILE_SET+=RELRO 
ise is just what was new/unusual in the portmaster -DKa that was going on when 
the rpi2 had the panic.]

The console history shows (the cc quoted just gives a ball park for where it 
was in the binutils build):

> cc -DHAVE_CONFIG_H -I.  -I. -I. -I../bfd -I./../bfd -I./../include  -pipe 
> -mcpu=cortex-a7  -I/usr/local/include -g -fno-strict-aliasing 
> -DENABLE_PLUGINS -DLOCAL
> EDIR="\"/usr/local/share/locale\"" -mcpu=cortex-a7 -W -Wall 
> -Wstrict-prototypes -Wmissing-prototypes -Wshadow -DELF_LIST_OPTIONS=TRUE 
> -DELF_SHLIB_LIST_OPTIONS=T
> RUE -DELF_PLT_UNWIND_LIST_OPTIONS=TRUE -pipe -mcpu=cortex-a7  
> -I/usr/local/include -g -fno-strict-aliasing -MT eavrxmega2.o -MD -MP -MF 
> .deps/eavrxmega2.Tpo -c 
> -o eavrxmega2.o eavrxmega2.c
> panic: pmap_fault: PT2MAP abort
> cpuid = 3
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
>  pc = 0xc06b2ad0  lr = 0xc014edf4 (db_trace_self_wrapper+0x30)
>  sp = 0xed27c880  fp = 0xed27c998
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>  pc = 0xc014edf4  lr = 0xc0336968 (vpanic+0x13c)
>  sp = 0xed27c9a0  fp = 0xed27c9c0
>  r4 = 0x0100  r5 = 0xc4125a50
>  r6 = 0xc076ab91  r7 = 0x0001
> vpanic() at vpanic+0x13c
>  pc = 0xc0336968  lr = 0xc033682c (vpanic)
>  sp = 0xed27c9c8  fp = 0xed27c9cc
>  r4 = 0xc0991ba0  r5 = 0x
>  r6 = 0xbfefefe8  r7 = 0x0007
>  r8 = 0x0013  r9 = 0x0007
> r10 = 0xc41daf44
> vpanic() at vpanic
>  pc = 0xc033682c  lr = 0xc06ce40c (pmap_fault+0x638)
>  sp = 0xed27c9d4  fp = 0xed27ca08
>  r4 = 0x0007  r5 = 0x0013
>  r6 = 0x0007  r7 = 0xc41daf44
>  r8 = 0xed27c9cc  r9 = 0xc033682c
> r10 = 0xed27c9d4
> pmap_fault() at pmap_fault+0x638
>  pc = 0xc06ce40c  lr = 0xc06d30f8 (abort_handler+0xbc)
>  sp = 0xed27ca10  fp = 0xed27caa0
>  r4 = 0xc0991ba0  r5 = 0x0007
>  r6 = 0x  r7 = 0x0007
>  r8 = 0x0013  r9 = 0xc4125a50
> r10 = 0xed27caa8
> abort_handler() at abort_handler+0xbc
>  pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
>  sp = 0xed27caa8  fp = 0xed27cb60
>  r4 = 0xc0991ba0  r5 = 0x
>  r6 = 0xbfbfaa04  r7 = 0x0006
>  r8 = 0xc41daf54  r9 = 0x0806
> r10 = 0xc41daf44
> exception_exit() at exception_exit
>  pc = 0xc06b53b8  lr = 0xc03131e8 (__mtx_lock_sleep+0x220)
>  sp = 0xed27cb38  fp = 0xed27cb60
>  r0 = 0x002fefe8  r1 = 0xbfc0
>  r2 = 0xc41daf44  r3 = 0x0001
>  r4 = 0xc0991ba0  r5 = 0x
>  r6 = 0xbfbfaa04  r7 = 0x0006
>  r8 = 0xc41daf54  r9 = 0x0806
> r10 = 0xc41daf44 r12 = 0xed27ca78
> pmap_fault() at pmap_fault+0x1b4
>  pc = 0xc06cdf88  lr = 0xc06d30f8 (abort_handler+0xbc)
>  sp = 0xed27cb68  fp = 0xed27cbf8
>  r4 = 0x0030  r5 = 0x0006
>  r6 = 0x  r7 = 0x0806
>  r8 = 0x0013  r9 = 0xc4125a50
> r10 = 0xed27cc00
> abort_handler() at abort_handler+0xbc
>  pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
>  sp = 0xed27cc00  fp = 0x
>  r4 = 0x0030  r5 = 0x
>  r6 = 0x  r7 = 0xed27ccb4
>  r8 = 0xed27ce00  r9 = 0x
> r10 = 0xed27cea0
> exception_exit() at exception_exit
>  pc = 0xc06b53b8  lr = 0xc06ad77c (copyout+0x9c)
>  sp = 0xed27cc94  fp = 0x
>  r0 = 0xed27ccb8  r1 = 0xbfbfaa04
>  r2 = 0x  r3 = 0x
>  r4 = 0x0030  r5 = 0x
>  r6 = 0x  r7 = 0xed27ccb4
>  r8 = 0xed27ce00  r9 = 0x
> r10 = 0xed27cea0 r12 = 0x
> copyout() at copyout+0x2c4
>  pc = 0xc06ad9a4  lr = 0xc06ad77c (copyout+0x9c)
>  sp = 0xed27cc94  fp = 0x
> copyout() at copyout+0x9c
>  pc = 0xc06ad77c  lr = 0xc06ad77c (copyout+0x9c)
>  sp = 0xed27cc94  fp = 0x
> Unwind failure (no registers changed)
> KDB: enter: panic
> [ thread pid 54457 tid 100158 ]
> Stopped at  $d.6:   ldrbr15, [r15, r15, ror r15]!
> db> 

The portmaster -DKa attempt to rebuild binutils-2.27 on the rpi2 got my first 
armv6 stable/11 panic (and it has been much longer then that since I've gotten 
a 11.0-CURRENT panic). I was not around when the panic happened but it is still 
sitting at the db> serial console prompt and I can enter commands if 
appropriate.

FreeBSD 11.0 context: The rpi2 was/is at /usr/src/ stable/11 -r304029 : it has 
been a while since I've updated to track stable/11 . The few differences in my 
/usr/src are mostly for powerpc and powerpc64 specific changes: I normally use 
the same tree content everywhere that I build FreeBSD. The build used 
-mcpu=cortex-a7 as I've been doing 

Re: Error compiling stable/11 from stable/10

[Matt Smith]

On Aug 26 22:49, Bryan Drewery wrote:

On 8/26/2016 6:38 AM, Matt Smith wrote:

Hi, I'm attempting to compile the latest stable/11 from a 12 day old
stable/10 system and I'm getting the following error. I've tried
completely deleting /usr/obj. I've tried without make -j. And I've tried
commenting out options from src.conf and make.conf and nothing seems to
make any difference. Any ideas? I haven't tried it yet but I'm wondering
if I should do RC2 before stable/11.

In file included from
/usr/src/lib/liblzma/../../contrib/xz/src/liblzma/lz/lz_encoder.c:
23:
/usr/src/lib/liblzma/../../contrib/xz/src/liblzma/common/memcmplen.h:19:11:
fatal error:

 'immintrin.h' file not found
 #   include 
  ^
  1 error generated.
  *** Error code 1

  Stop.
  bmake[4]: stopped in /usr/src/lib/liblzma





Can you provide a full log of buildworld somewhere for me to look at?

What's in your make.conf and src.conf?



Hi, I have a feeling this might have been ccache at fault. Since sending 
this email I had also tried commenting out ccache from make.conf and 
running another compile attempt. This attempt is *still* going?! I 
started it 14 hours ago now and it has only reached here:


===> gnu/usr.bin/groff/src/preproc/tbl (all)

What on earth is so different between 10 and 11 to cause build times 
that much longer? Without ccache and running without -j this box would 
have built 10 in around 5 hours. Is that the result of not having 
WITHOUT_DEBUG_FILES as I think that was something new for 11 wasn't it? 

I have not been running this build within script(1) though I am afraid 
so I don't have a copy of the whole build.  I might stop the build and 
reenable all of the options again, but this time with a completely empty 
ccache.


FYI though, my src.conf and make.conf are below. You can see what I have 
now commented out that was enabled before. I don't think it's the 
src.conf entries that caused the problem as I tried it with those 
commented out before and it still failed. I think it could probably be 
the ccache lines.


$ cat /etc/src.conf
#WITHOUT_DEBUG_FILES=yes
#WITHOUT_LIB32=yes
#WITHOUT_PROFILE=yes

$ cat /etc/make.conf
KERNCONF=TAO
BATCH_DELETE_OLD_FILES=yes
SVN_UPDATE=yes
SVN=/usr/local/bin/svn
WRKDIRPREFIX=/usr/obj

DEFAULT_VERSIONS=gcc=6 perl5=5.24 pgsql=9.5 php=7.0 python=2.7 
python2=2.7 python3=3.5 ssl=libressl-devel

WITH_OPENSSL_PORT=yes
OPENSSL_PORT=security/libressl-devel
OPTIONS_UNSET+=X11

#WITH_CCACHE_BUILD=yes

#.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
#.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
#CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
#CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
#.endif
#.endif


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