Re: panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

2016-11-11 Thread Don Lewis 
On 11 Nov, To: freebsd-current@FreeBSD.org wrote:
> Yesterday I upgraded my ports builder box from r306349 to r308477.  It
> crashed overnight during a poudriere run.
> 
> panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085c2a4100
> vpanic() at vpanic+0x182/frame 0xfe085c2a4180
> panic() at panic+0x43/frame 0xfe085c2a41e0
> __mtx_assert() at __mtx_assert+0xc1/frame 0xfe085c2a41f0
> cache_negative_remove() at cache_negative_remove+0x65/frame 0xfe085c2a4230
> cache_zap_locked() at cache_zap_locked+0x1ca/frame 0xfe085c2a4250
> cache_enter_time() at cache_enter_time+0x1c20/frame 0xfe085c2a4330
> tmpfs_lookup() at tmpfs_lookup+0x47a/frame 0xfe085c2a4390
> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfe085c2a43c0
> vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfe085c2a4420
> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfe085c2a4450
> lookup() at lookup+0x6a2/frame 0xfe085c2a44e0
> namei() at namei+0x57e/frame 0xfe085c2a45a0
> vn_open_cred() at vn_open_cred+0x25b/frame 0xfe085c2a4710
> kern_openat() at kern_openat+0x25c/frame 0xfe085c2a48a0
> ia32_syscall() at ia32_syscall+0x330/frame 0xfe085c2a4a30
> Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe085c2a4a30
> --- syscall (499, FreeBSD ELF32, sys_openat), rip = 0x97b2f57, rsp = 
> 0x7698, rbp = 0x76b0 ---
> KDB: enter: panic
> 
> 
> I was able to get a crash dump.  This is the kgdb backtrace:
> 
> #0  __curthread () at ./machine/pcpu.h:222
> #1  doadump (textdump=1546271680) at /usr/src/sys/kern/kern_shutdown.c:298
> #2  0x80396db6 in db_fncall_generic (nargs=0, addr=, 
> rv=, args=)
> at /usr/src/sys/ddb/db_command.c:581
> #3  db_fncall (dummy1=, dummy2=, 
> dummy3=, dummy4=)
> at /usr/src/sys/ddb/db_command.c:629
> #4  0x80396919 in db_command (last_cmdp=, 
> cmd_table=, dopager=)
> at /usr/src/sys/ddb/db_command.c:453
> #5  0x80396674 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:506
> #6  0x8039972f in db_trap (type=, code=)
> at /usr/src/sys/ddb/db_main.c:248
> #7  0x80aa0a13 in kdb_trap (type=, 
> code=, tf=)
> at /usr/src/sys/kern/subr_kdb.c:654
> #8  0x80ed8cc4 in trap (frame=0xfe085c2a4030)
> at /usr/src/sys/amd64/amd64/trap.c:537
> #9  
> #10 kdb_enter (why=0x8140e5d1 "panic", 
> msg=0x80 )
> at /usr/src/sys/kern/subr_kdb.c:444
> #11 0x80a5eb1f in vpanic (fmt=, ap=0xfe085c2a41c0)
> at /usr/src/sys/kern/kern_shutdown.c:752
> #12 0x80a5eb83 in panic (fmt=0x81bf1de0  
> "\004")
> at /usr/src/sys/kern/kern_shutdown.c:690
> #13 0x80a40191 in __mtx_assert (c=, 
> what=, file=0xfe085c2a3fe0 "", line=0)
> at /usr/src/sys/kern/kern_mutex.c:937
> #14 0x80b0d3d5 in cache_negative_remove (ncp=0xf8062bb8dee0, 
> neg_locked=true) at /usr/src/sys/kern/vfs_cache.c:743
> #15 0x80b0d87a in cache_zap_locked (ncp=0xf8062bb8dee0, 
> neg_locked=true) at /usr/src/sys/kern/vfs_cache.c:886
> #16 0x80b0d210 in cache_negative_zap_one ()
> at /usr/src/sys/kern/vfs_cache.c:835
> #17 cache_enter_time (dvp=, vp=, 
> cnp=, tsp=, dtsp=)
> at /usr/src/sys/kern/vfs_cache.c:1741
> #18 0x82893b3a in tmpfs_lookup (v=)
> at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:199
> #19 0x8103ee4a in VOP_CACHEDLOOKUP_APV (vop=, 
> a=) at vnode_if.c:195
> #20 0x80b0e9d6 in VOP_CACHEDLOOKUP (dvp=0xf8023f3693b0, 
> vpp=0xfe085c2a47d8, cnp=0xfe085c2a4800) at ./vnode_if.h:80
> #21 vfs_cache_lookup (ap=) at 
> /usr/src/sys/kern/vfs_cache.c:2022
> #22 0x8103ecea in VOP_LOOKUP_APV (vop=, 
> a=) at vnode_if.c:127
> #23 0x80b17df2 in VOP_LOOKUP (vpp=0xfe085c2a47d8, 
> cnp=0xfe085c2a4800, dvp=) at ./vnode_if.h:54
> #24 lookup (ndp=) at /usr/src/sys/kern/vfs_lookup.c:830
> #25 0x80b173ae in namei (ndp=)
> at /usr/src/sys/kern/vfs_lookup.c:397
> #26 0x80b333db in vn_open_cred (ndp=, 
> flagp=0xfe085c2a485c, cmode=0, vn_open_flags=, 
> cred=, fp=0x1d0) at /usr/src/sys/kern/vfs_vnops.c:277
> #27 0x80b2c72c in kern_openat (td=0xf8001d68d000, fd=-100, 
> path=0x2c9e71e8 , 
> pathseg=UIO_USERSPACE, 
> flags=, 
> mode=) at /usr/src/sys/kern/vfs_syscalls.c:1016
> #28 0x80ff88a0 in syscallenter (td=0xf8001d68d000, 
> sa=)
> at /usr/src/sys/amd64/ia32/../../kern/subr_syscall.c:135
> #29 ia32_syscall (frame=0xfe085c2a4a40)
> at /usr/src/sys/amd64/ia32/ia32_syscall.c:187
> #30 
> #31 0x097b2f57 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7698
> 
> 
> I don't see any obvious issues in the code.

This problem is very reproduceable for me, so I added

Re: Lenovo X1 Carbon or T460s

2016-11-11 Thread Kevin Oberman 
On Fri, Nov 11, 2016 at 8:08 AM, Mark Heily  wrote:

> On Fri, Nov 11, 2016 at 6:25 AM, Jeremie Le Hen  wrote:
>
> > Hi guys,
> >
> > I'm about to purchase a new laptop, one of the two mentioned in the
> > subject.
> >
> > I'm looking for reports of hardware support for both of them under
> FreeBSD.
> > What are the goods and bads?
> >
> >
> I just purchased a brand new Gen 4 X1 Carbon last week and tried a recent
> TrueOS build on it.  I'm triple booting it with Windows and Linux for
> comparison purposes. Here's what I have seen so far regarding FreeBSD:
>
> - Wifi and the touchpad work fine.
>
> - The latest gen HiDPI screens (aka Retina display) have extremely high
> resolution relative to the size of the screen, which makes the console
> fonts extremely tiny. Even the TrueOS graphical installer was barely usable
> due to small fonts.  If you want a graphical desktop environment, you'll
> have to figure out how to scale applications to look right under HiDPI.
> Lumina and the TrueOS display manager did a decent job of it, but didn't
> give me enough control over the scaling factor. With the latest Gnome on
> Linux, it gives you a lot of control over how applications are scaled. I've
> heard KDE5 also has support for HiDPI.
>
> - Skylake integrated video isn't accelerated. and feels a little slow.
> Video playback is choppy and disappointing.
>
> - Suspend/resume is reported not to work (I have not confirmed this)
>
> At this point, FreeBSD is still unusable due to display issues (IMHO) and I
> spend most of my time booting into Linux :(
>
> The hardware itself is great, other than the black finish seems to attract
> smudges and fingerprints. It's super lightweight, quiet, fast, and the
> keyboard and trackpad feel very comfortable


In regard to video, have you installed and are you using vaapi? It provides
Intel GPU video acceleration sand, on my old Sandy Bridge it made a huge
difference in video, at least with software that supports it.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: 1st build stops when WITH_AUTO_OBJ=yes

2016-11-11 Thread Simon J. Gerraty 
Renato Botelho  wrote:
> > Interesting; what .OBJDIR do you end up with for say bin/cat ?
> 
> 
> In this case it fails the first time pointing to expected .OBJDIR, then 
> second time I run it builds
> 
> /u/s/b/cat # ❯❯❯ make -DWITH_AUTO_OBJ
> [Creating objdir obj...]
> make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj: 
> .OBJDIR=/usr/obj/usr/src/bin/cat

The creating line is the clue, it is just obj
rather than say /usr/obj/usr/src/bin/cat

Do you have MAKEOBJDIRPREFIX set in env?
Or are you relying on bsd.obj.mk to set
CANONICALOBJDIR:=/usr/obj${.CURDIR}

?

Since we need to do auto.obj.mk *very* early (so .PATH is correct),
it is probably relying on MAKEOBJDIRPREFIX or MAKEOBJDIR
(I always have MAKEOBJDIR set) since bsd.obj.mk will not be included
yet.

If that's all the case though I wouldn't expect it to work any better on
subsequent runs.
___
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 #1677 - Fixed

2016-11-11 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1677 - Fixed:

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

Change summaries:

308563 by emaste:
libcc_{s,eh}: build without SSP

As in the gnu/lib/libgcc Makefile:
libgcc is linked in last and thus cannot depend on ssp
symbols coming from earlier libraries. Disable stack protection
for this library.

Reviewed by:dim
Sponsored by:   The FreeBSD Foundation

308562 by rstone:
Fix git tools when run against a worktree

In a git worktree, the gitdir is in an entirely different location.
In arcgit, use git rev-parse --git-dir to get the correct path to it
always.

When running git from outside of the work tree, as in importgit,
the path provided by git rev-parse --git-dir can be either a
relative or absolute path depending on the work tree.  Rather
than trying to deal with that, just use git -C.

Differential Revision:  https://reviews.freebsd.org/D8501
Reviewed by: markj

308561 by gavin:
Correct spelling in syslog: getttimeofday -> gettimeofday

308560 by jhibbits:
Replace another fdt_is_compatible() call.

308559 by dim:
Pull in r263169 from upstream llvm trunk (by Tim Northover):

  AArch64: only try to use scaled fcvt ops on legal vector types.

  Before we ended up calling getSimpleVectorType on a <3 x float>, which
  asserted.

This fixes an assertion when building the print/ghostscript9-agpl-base
port for AArch64.

PR: 213865
MFC after:  3 days

308558 by cem:
queue.3: Document existing QMD_* macros

Feedback from:  bapt, bdrewery, emaste
Sponsored by:   Dell EMC Isilon
Differential Revision:  https://reviews.freebsd.org/D3983

308553 by cem:
ioat(4): Fix race between process_events and reset_hw

In the case where a hardware error is detected during
ioat_process_events, hardware may advance (by one descriptor, probably)
and a subsequent ioat_process_events may race the intended ioat_reset_hw
followup.  In that case, the second process_events would observe a
completion update that does not match the software "last_seen" status,
and attempt to successfully complete already-failed descriptors.

Guard against this race with the resetting_cleanup flag.

Reviewed by:bdrewery, markj
Sponsored by:   Dell EMC Isilon

___
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: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743 in 12.0-CURRENT r308447

2016-11-11 Thread Don Lewis 
Yesterday I upgraded my ports builder box from r306349 to r308477.  It
crashed overnight during a poudriere run.

panic: mutex ncnegl not owned at /usr/src/sys/kern/vfs_cache.c:743
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085c2a4100
vpanic() at vpanic+0x182/frame 0xfe085c2a4180
panic() at panic+0x43/frame 0xfe085c2a41e0
__mtx_assert() at __mtx_assert+0xc1/frame 0xfe085c2a41f0
cache_negative_remove() at cache_negative_remove+0x65/frame 0xfe085c2a4230
cache_zap_locked() at cache_zap_locked+0x1ca/frame 0xfe085c2a4250
cache_enter_time() at cache_enter_time+0x1c20/frame 0xfe085c2a4330
tmpfs_lookup() at tmpfs_lookup+0x47a/frame 0xfe085c2a4390
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfe085c2a43c0
vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfe085c2a4420
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfe085c2a4450
lookup() at lookup+0x6a2/frame 0xfe085c2a44e0
namei() at namei+0x57e/frame 0xfe085c2a45a0
vn_open_cred() at vn_open_cred+0x25b/frame 0xfe085c2a4710
kern_openat() at kern_openat+0x25c/frame 0xfe085c2a48a0
ia32_syscall() at ia32_syscall+0x330/frame 0xfe085c2a4a30
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe085c2a4a30
--- syscall (499, FreeBSD ELF32, sys_openat), rip = 0x97b2f57, rsp = 
0x7698, rbp = 0x76b0 ---
KDB: enter: panic


I was able to get a crash dump.  This is the kgdb backtrace:

#0  __curthread () at ./machine/pcpu.h:222
#1  doadump (textdump=1546271680) at /usr/src/sys/kern/kern_shutdown.c:298
#2  0x80396db6 in db_fncall_generic (nargs=0, addr=, 
rv=, args=)
at /usr/src/sys/ddb/db_command.c:581
#3  db_fncall (dummy1=, dummy2=, 
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:629
#4  0x80396919 in db_command (last_cmdp=, 
cmd_table=, dopager=)
at /usr/src/sys/ddb/db_command.c:453
#5  0x80396674 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:506
#6  0x8039972f in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:248
#7  0x80aa0a13 in kdb_trap (type=, 
code=, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#8  0x80ed8cc4 in trap (frame=0xfe085c2a4030)
at /usr/src/sys/amd64/amd64/trap.c:537
#9  
#10 kdb_enter (why=0x8140e5d1 "panic", 
msg=0x80 )
at /usr/src/sys/kern/subr_kdb.c:444
#11 0x80a5eb1f in vpanic (fmt=, ap=0xfe085c2a41c0)
at /usr/src/sys/kern/kern_shutdown.c:752
#12 0x80a5eb83 in panic (fmt=0x81bf1de0  "\004")
at /usr/src/sys/kern/kern_shutdown.c:690
#13 0x80a40191 in __mtx_assert (c=, 
what=, file=0xfe085c2a3fe0 "", line=0)
at /usr/src/sys/kern/kern_mutex.c:937
#14 0x80b0d3d5 in cache_negative_remove (ncp=0xf8062bb8dee0, 
neg_locked=true) at /usr/src/sys/kern/vfs_cache.c:743
#15 0x80b0d87a in cache_zap_locked (ncp=0xf8062bb8dee0, 
neg_locked=true) at /usr/src/sys/kern/vfs_cache.c:886
#16 0x80b0d210 in cache_negative_zap_one ()
at /usr/src/sys/kern/vfs_cache.c:835
#17 cache_enter_time (dvp=, vp=, 
cnp=, tsp=, dtsp=)
at /usr/src/sys/kern/vfs_cache.c:1741
#18 0x82893b3a in tmpfs_lookup (v=)
at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:199
#19 0x8103ee4a in VOP_CACHEDLOOKUP_APV (vop=, 
a=) at vnode_if.c:195
#20 0x80b0e9d6 in VOP_CACHEDLOOKUP (dvp=0xf8023f3693b0, 
vpp=0xfe085c2a47d8, cnp=0xfe085c2a4800) at ./vnode_if.h:80
#21 vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:2022
#22 0x8103ecea in VOP_LOOKUP_APV (vop=, 
a=) at vnode_if.c:127
#23 0x80b17df2 in VOP_LOOKUP (vpp=0xfe085c2a47d8, 
cnp=0xfe085c2a4800, dvp=) at ./vnode_if.h:54
#24 lookup (ndp=) at /usr/src/sys/kern/vfs_lookup.c:830
#25 0x80b173ae in namei (ndp=)
at /usr/src/sys/kern/vfs_lookup.c:397
#26 0x80b333db in vn_open_cred (ndp=, 
flagp=0xfe085c2a485c, cmode=0, vn_open_flags=, 
cred=, fp=0x1d0) at /usr/src/sys/kern/vfs_vnops.c:277
#27 0x80b2c72c in kern_openat (td=0xf8001d68d000, fd=-100, 
path=0x2c9e71e8 , 
pathseg=UIO_USERSPACE, 
flags=, 
mode=) at /usr/src/sys/kern/vfs_syscalls.c:1016
#28 0x80ff88a0 in syscallenter (td=0xf8001d68d000, 
sa=)
at /usr/src/sys/amd64/ia32/../../kern/subr_syscall.c:135
#29 ia32_syscall (frame=0xfe085c2a4a40)
at /usr/src/sys/amd64/ia32/ia32_syscall.c:187
#30 
#31 0x097b2f57 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7698


I don't see any obvious issues in the code.

___
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 #1676 - Still Failing

2016-11-11 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1676 - Still Failing:

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

Change summaries:

308538 by kib:
Increase the max allowed size of the microcode update blob for x86.

Newer CPUs (SkyLakes) have updates of 100K size, which is bigger than
current limit 32K. Increase it to 4M but leave the check around to
prevent kernel memory allocator abuse.  Some time ago, the memory for
update was allocated by contigmalloc(9), and it was reasonable to be
conservative as much as possible.  Since all uses of contigmalloc(9)
appear to be either misunderstanding or too cautious, and were
removed, provide more slack than strictly neccessary.

Submitted by:   Oliver Pinter
MFC after:  1 week
Differential revision:  https://reviews.freebsd.org/D8486

308537 by gjb:
Spell 'PACKAGE' correctly.

Submitted by:   Kyle Evans, emaste
MFC after:  3 days
Sponsored by:   The FreeBSD Foundation

308536 by jhibbits:
Use ofw_bus_node_is_compatible() instead of fdt_is_compatible()

No need to have two functions that do the same thing, let's let fdt_* go away,
and use ofw_bus_* equivalents instead.

Requested by:   andrew

308535 by stevek:
Add support for LOADER_RC setting in the pkgfs manifest (defaults to
/loader.rc) to specify a Forth file to read from the pkgfs tarball and
process by Ficl.

This allows for the tarball to do runtime things like load a
platform-specific FDT blob, among other things.

Reviewed by:imp
Approved by:sjg (mentor)
MFC after:  2 weeks
Sponsored by:   Juniper Networks, Inc.
Differential Revision:  https://reviews.freebsd.org/D8494



The end of the build log:

[...truncated 197933 lines...]
--- negdf2.pico ---
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc -m32 -DCOMPAT_32BIT -march=i686 
-mmmx -msse -msse2  
-L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
  
--sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32
  -B/usr/local/x86_64-freebsd/bin/ 
-B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
 -isystem 
/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/include
 -fpic -DPIC -g -O2 -pipe 
-I/builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/projects/libunwind/include 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libgcc_s -D_LIBUNWIND_IS_NATIVE_ONLY 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libc/include 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libc/i386 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/msun/src  -MD  -MF.depend.negdf2.pico 
-MTnegdf2.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address 
-Wno-error=array-bounds -Wno-error=a
 ttributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered 
-Wno-error=enum-compare -Wno-error=extra -Wno-error=inline 
-Wno-error=logical-not-parentheses -Wno-error=strict-aliasing 
-Wno-error=uninitialized -Wno-error=unused-but-set-variable 
-Wno-error=unused-function -Wno-error=unused-value -Wno-error=strict-overflow   
  -c /builds/FreeBSD_HEAD_amd64_gcc/contrib/compiler-rt/lib/builtins/negdf2.c 
-o negdf2.pico
--- negdi2.pico ---
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc -m32 -DCOMPAT_32BIT -march=i686 
-mmmx -msse -msse2  
-L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
  
--sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32
  -B/usr/local/x86_64-freebsd/bin/ 
-B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
 -isystem 
/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/include
 -fpic -DPIC -g -O2 -pipe 
-I/builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/projects/libunwind/include 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libgcc_s -D_LIBUNWIND_IS_NATIVE_ONLY 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libc/include 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libc/i386 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/msun/src  -MD  -MF.depend.negdi2.pico 
-MTnegdi2.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address 
-Wno-error=array-bounds -Wno-error=a
 ttributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered 
-Wno-error=enum-compare -Wno-error=extra -Wno-error=inline 
-Wno-error=logical-not-parentheses -Wno-error=strict-aliasing 
-Wno-error=uninitialized -Wno-error=unused-but-set-variable 
-Wno-error=unused-function -Wno-error=unused-value -Wno-error=strict-overflow   
  -c /builds/FreeBSD_HEAD_amd64_gcc/contrib/compiler-rt/lib/builtins/negdi2.c 
-o negdi2.pico
--- multc3.pico ---
/builds/FreeBSD_HEAD_amd64_gcc/contrib/compiler-rt/lib/builtins/multc3.c:21:1: 
warning: conflicting types for built-in function '__multc3'
 __multc3(long

FreeBSD_HEAD_amd64_gcc - Build #1675 - Still Failing

2016-11-11 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1675 - Still Failing:

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

Change summaries:

308534 by stevek:
The file_loadraw function grew an argument, update install function
accordingly.

Reviewed by:imp
Approved by:sjg (mentor)
MFC after:  2 weeks
Sponsored by:   Juniper Networks, Inc.
Differential Revision:  https://reviews.freebsd.org/D8494

308533 by andrew:
Use ofw_bus_node_is_compatible in more drivers used on arm.

Sponsored by:   ABT Systems Ltd

308532 by avg:
update SMB_BWRITE documentation, clarify SMB_BREAD

After removal of SMB_TRANS some information in the description of
SMB_BWRITE has become stale.  E.g., the maximum block size has been
restored to 32.

Also, the descriptions of SMB_BREAD and SMB_BWRITE had some
incorrect information on the SMBus protocol details.

MFC after:  1 week
X-MFC with: r308242
Differential Revision: https://reviews.freebsd.org/D8431

308531 by andrew:
Use the modern spelling of ofw_bus_node_is_compatible in sys/arm.

Sponsored by:   ABT Systems Ltd

308530 by avg:
iicsmb: SMB_MAXBLOCKSIZE can be used again

The constant was set to the correct value in r308242.
While there, fix iicsmb_bread() to not use a value of an out parameter
'count'.

MFC after:  3 weeks
X-MFC after:r308242

308529 by avg:
intpm: clean up intsmb_bread and intsmb_pcall

The hardware does not implement SMBus Process Call command, so remove
ifdef-ed out code from intsmb_pcall.  The code used exactly the same
start sequence as for Write Word command.

intsmb_bread code used to access an in value of the count parameter,
but that parameter is supposed to be an out only parameter.
For example, smb(4) does not initialize it before calling smbus_bread.

MFC after:  3 weeks

308528 by avg:
smbmsg: use a more convenient way of accessing data read from a slave

Developers writing code for accessing /dev/smb may use this base utility
as an example.  Now that SMB_READB, SMB_READW, SMB_PCALL behave as
documented, wwe can use them in a more convenient way than before.

MFC after:  4 weeks
X-MFC after:r308527

308527 by avg:
smb: fix SMB_READB, SMB_READW, SMB_PCALL to work as documented

Previously, those ioctls were defined as 'in' only, so rdata.byte and
rdata.word were never updated in the userland.  The read data went only
to rbuf if it was provided.  Thus, consumers were forced to always use it.

Now the ioctls are marked as in-out.
Compatibility handlers are provided for old ioctls.

PR: 213481
Reported by:Lewis Donzis 
MFC after:  2 weeks
Relnotes:   maybe
Differential Revision: https://reviews.freebsd.org/D8430

308526 by andrew:
Fix ata_at91_alloc_resource to use rman_res_t.

Sponsored by:   ABT Systems Ltd

308525 by andrew:
Remove more unneeded users of the fdt_pic_decode_t table.

Sponsored by:   ABT Systems Ltd

308524 by andrew:
Replace OF_getprop ... fdt32_to_cpu with OF_getencprop. The latter
correctly adjusts for the endian.

MFC after:  1 week
Sponsored by:   ABT Systems Ltd



The end of the build log:

[...truncated 209771 lines...]
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc -m32 -DCOMPAT_32BIT -march=i686 
-mmmx -msse -msse2  
-L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
  
--sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32
  -B/usr/local/x86_64-freebsd/bin/ 
-B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
 -isystem 
/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/include
 -fpic -DPIC -g -O2 -pipe 
-I/builds/FreeBSD_HEAD_amd64_gcc/contrib/llvm/projects/libunwind/include 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libgcc_s -D_LIBUNWIND_IS_NATIVE_ONLY 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libc/include 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/libc/i386 
-I/builds/FreeBSD_HEAD_amd64_gcc/lib/msun/src  -MD  -MF.depend.mulsc3.pico 
-MTmulsc3.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address 
-Wno-error=array-bounds -Wno-error=a
 ttributes -Wno-error=bool mulvdi3.pico ---
--- mulvsi3.pico ---
--- multi3.pico ---
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc -m32 -DCOMPAT_32BIT -march=i686 
-mmmx -msse -msse2  
-L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
  
--sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32
  -B/usr/local/x86_64-freebsd/bin/ 
-B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/lib32
 -isystem 
/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/lib32/usr/include
 -fpic -DPIC -g -O2 -pipe

Re: 1st build stops when WITH_AUTO_OBJ=yes

2016-11-11 Thread Bryan Drewery 
I have pending patches to commit that make this feature usable with buildworld. 
Until then I don't expect the two to work well together.

Regards,
Bryan Drewery

> On Nov 10, 2016, at 02:23, Renato Botelho  wrote:
> 
>> On 9 Nov 2016, at 19:48, Simon J. Gerraty  wrote:
>> 
>> Renato Botelho  wrote:
>> 
>>> I decided to give a try to WITH_AUTO_OBJ and noted the first time I ran 
>>> buildworld it failed with following message:
>>> 
>>> /u/src # ❯❯❯ make WITH_AUTO_OBJ=yes buildworld
>>> [Creating objdir obj...]
>>> make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj: 
>>> .OBJDIR=/usr/src/obj
>>> 
>>> After that I noted it created a directory /usr/src/obj and if I call
>>> it again it runs without issues. If I remove /usr/src/obj directory
>>> error happens again
>> 
>> Interesting; what .OBJDIR do you end up with for say bin/cat ?
> 
> 
> In this case it fails the first time pointing to expected .OBJDIR, then 
> second time I run it builds
> 
> /u/s/b/cat # ❯❯❯ make -DWITH_AUTO_OBJ
> [Creating objdir obj...]
> make: "/usr/src/share/mk/auto.obj.mk" line 61: could not use obj: 
> .OBJDIR=/usr/obj/usr/src/bin/cat
> /u/s/b/cat # ❯❯❯ make -DWITH_AUTO_OBJ 
>   
>⏎
> Building /usr/obj/usr/src/bin/cat/cat.o
> Building /usr/obj/usr/src/bin/cat/cat.full
> Building /usr/obj/usr/src/bin/cat/cat.debug
> Building /usr/obj/usr/src/bin/cat/cat
> --
> Renato Botelho
> 
___
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: Lenovo X1 Carbon or T460s

2016-11-11 Thread Mark Heily 
On Fri, Nov 11, 2016 at 6:25 AM, Jeremie Le Hen  wrote:

> Hi guys,
>
> I'm about to purchase a new laptop, one of the two mentioned in the
> subject.
>
> I'm looking for reports of hardware support for both of them under FreeBSD.
> What are the goods and bads?
>
>
I just purchased a brand new Gen 4 X1 Carbon last week and tried a recent
TrueOS build on it.  I'm triple booting it with Windows and Linux for
comparison purposes. Here's what I have seen so far regarding FreeBSD:

- Wifi and the touchpad work fine.

- The latest gen HiDPI screens (aka Retina display) have extremely high
resolution relative to the size of the screen, which makes the console
fonts extremely tiny. Even the TrueOS graphical installer was barely usable
due to small fonts.  If you want a graphical desktop environment, you'll
have to figure out how to scale applications to look right under HiDPI.
Lumina and the TrueOS display manager did a decent job of it, but didn't
give me enough control over the scaling factor. With the latest Gnome on
Linux, it gives you a lot of control over how applications are scaled. I've
heard KDE5 also has support for HiDPI.

- Skylake integrated video isn't accelerated. and feels a little slow.
Video playback is choppy and disappointing.

- Suspend/resume is reported not to work (I have not confirmed this)

At this point, FreeBSD is still unusable due to display issues (IMHO) and I
spend most of my time booting into Linux :(

The hardware itself is great, other than the black finish seems to attract
smudges and fingerprints. It's super lightweight, quiet, fast, and the
keyboard and trackpad feel very comfortable.
___
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: Lenovo X1 Carbon or T460s

2016-11-11 Thread Ccs189 
Hi,
Prob this may help?
https://wiki.freebsd.org/Laptops

Anywhz I own a a X1 Carbon gen1 type43xx model.

Running FreeBSD 11 without any isssue. 
I recompile the kernel without vesa driver so that it can put in sleep mode, It 
may not need to do it now, but I follow  11 version since the current branch. 
As long as it work, I don bother to change my kernel config.

Just small issue, after the laptop wake up from the sleep, mmc card not working 
properly. 

USB disk plug in previously before sleep mode not work after the laptop Wake 
up. U have to remount the disk.

Hope that helps.

Best regards,
Chan


> On 11 Nov 2016, at 7:25 PM, Jeremie Le Hen  wrote:
> 
> Hi guys,
> 
> I'm about to purchase a new laptop, one of the two mentioned in the subject.
> 
> I'm looking for reports of hardware support for both of them under FreeBSD.
> What are the goods and bads?
> 
> Thanks!
> -- Jeremie
> ___
> 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"

firewire panic

2016-11-11 Thread Andriy Gapon 

Does anyone still use firewire or hack on code?
I've recently tried to connect an external firewire HDD enclosure and got this:

Unread portion of the kernel message buffer:
lock order reversal:
 1st 0xf8002b0f2f48 sbp (sbp) @ /usr/src/sys/kern/kern_mutex.c:158
 2nd 0xf8003f86f460 CAM device lock (CAM device lock) @
/usr/src/sys/cam/scsi/scsi_xpt.c:2323
stack backtrace:
#0 0x8068d220 at witness_debugger+0x70
#1 0x8068cd81 at witness_checkorder+0x7a1
#2 0x8061bab8 at __mtx_lock_flags+0x98
#3 0x802b663d at scsi_scan_lun+0x11d
#4 0x802b51f7 at scsi_action+0x67
#5 0x802a756a at xpt_action+0x1a
#6 0x8047459e at sbp_cam_scan_target+0xce
#7 0x8064f856 at softclock_call_cc+0x2d6
#8 0x8064fbf7 at softclock+0x47
#9 0x80602190 at intr_event_execute_handlers+0xe0
#10 0x806029ec at ithread_execute_handlers+0x2c
#11 0x8060285b at ithread_loop+0x5b
#12 0x805ff72f at fork_exit+0xdf
#13 0x8082483e at fork_trampoline+0xe
lock order reversal:
panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967
cpuid = 2
curthread: 0xf8000ada5000
stack: 0xfe0504ded000 - 0xfe0504df1000
stack pointer: 0xfe0504df0a00
KDB: stack backtrace:
db_trace_self_wrapper() at 0x80420bbb = db_trace_self_wrapper+0x2b/frame
0xfe0504df0930
kdb_backtrace() at 0x80670359 = kdb_backtrace+0x39/frame 
0xfe0504df09e0
vpanic() at 0x8063986c = vpanic+0x14c/frame 0xfe0504df0a20
panic() at 0x806395b3 = panic+0x43/frame 0xfe0504df0a80
__mtx_assert() at 0x8061c40d = __mtx_assert+0xed/frame 
0xfe0504df0ac0
sbp_cam_scan_lun() at 0x80474667 = sbp_cam_scan_lun+0x37/frame
0xfe0504df0af0
xpt_done_process() at 0x802aacfa = xpt_done_process+0x2da/frame
0xfe0504df0b30
xpt_done_td() at 0x802ac2e5 = xpt_done_td+0xd5/frame 0xfe0504df0b80
fork_exit() at 0x805ff72f = fork_exit+0xdf/frame 0xfe0504df0bf0
fork_trampoline() at 0x8082483e = fork_trampoline+0xe/frame
0xfe0504df0bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
-- 
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"

Lenovo X1 Carbon or T460s

2016-11-11 Thread Jeremie Le Hen 
Hi guys,

I'm about to purchase a new laptop, one of the two mentioned in the subject.

I'm looking for reports of hardware support for both of them under FreeBSD.
What are the goods and bads?

Thanks!
-- Jeremie
___
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: FYI: head (12-CURRENT) -r308247 on old 466 MHzPowerMac G4 (1 processor/1 core): taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0

2016-11-11 Thread Claude Buisson 

On 11/11/2016 09:40, Mark Millard wrote:

When using head -r308247 to boot an old PowerMac G4 466 MHz (single processor/single 
core) there are two "taskqgroup_adjust failed cnt" messages:


# dmesg
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r308247M: Thu Nov  3 11:39:11 PDT 2016

markmi@FreeBSDx64:/usr/obj/powerpcvtsc_clang_gcc421_kernel/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG
 powerpc
gcc version 4.2.1 20070831 patched [FreeBSD]
cpu0: Motorola PowerPC 7400 revision 2.9, 466.97 MHz
cpu0: Features 9c00
cpu0: HID0 8094c0a4
real memory  = 1588068352 (1514 MB)
avail memory = 1530961920 (1460 MB)
. . .
 ATA8-ACS SATA 2.x device
ada0: Serial Number 
ada0: 66.700MB/s transfers (UDMA4, PIO 512bytes)
ada0: 114473MB (234441648 512 byte sectors)
taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs [rw,noatime]...
gem0: link state changed to DOWN
gem0: link state changed to UP


The above is repeatable for the indicated PowerMac, so far always at the same 
place in the sequence.

The other booted PowerMac's using this SSD have multiple processors (G4 and G5 
examples). None of them has reported such messages so far but those messages 
could be unrelated to the  processor count for all I know.

This -r308247 build is "stable style" relative to performance choices for the 
KERNCONF. And the KERNCONF disables/excludes PS3 and enables/includes sc (syscons) in 
addition to the normal vt.


I do warn that this is the environment were I experiment with the 
problematical-for-powerpc clang/clang++ 3.8.0 for buildworld. Build kernel is via gcc 
4.2.1. The kernel has so-called "red zone" handling added for signals in order 
to deal with the clang ABI violations (in the stack handling).

At some point when all the available llvm powerpc-target fixes are in place 
I'll switch to the 3.9.0 project if I can. (Similarly for powerpc64.)

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

___
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"



I have the same messages (taskqgroup_adjust..) on an old Pentium 4 and 
and a (less) old Pentium M since current r302216 then stable/11 r303807 
(clang,etc)


The systems seem to run OK

Claude Buisson

___
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"

FYI: head (12-CURRENT) -r308247 still does not boot old iMac G3

2016-11-11 Thread Mark Millard 
My old iMac G3 list report from 2015-Mar-30 ( 
https://lists.freebsd.org/pipermail/freebsd-ppc/2015-March/007563.html ) for 
head (11-CURRENT) -r280598 still basically applies to head (12-CURRENT) 
-r308247 :

> iMac G3 (I've access to only one example G3): 
> 
> After 
> 
> > Time counters tick every 1.000 msec 
> 
> it gets: 
> 
> > [Thread pid 0 tid 100037] 
> > Stopped at pmap_activate+0x7c lwz r11,r1,0x0 
> 
> which may be reporting the instruction after a indirect subroutine jump. 
 
Although the tid is now 100040 if I remember right. If I remember right, the 
0x7c has not changed, nor has the type of instruction listed.

The SSD boots various other PowerMac G4's and G5's just fine.

Back on 2015-Mar-30 I reported that 10.1-STABLE of that time worked fine. (I 
was not explicit about the -r.)


[Unlike back then there is no problem with -r308247 booting the PowerMac G5's.]


[The oddball PowerMac G4 that no version of FreeBSD that I've tried has ever 
managed to boot still has the status as of -r308247: it gets to the same point 
and silently hangs. Mac OS X and Lubuntu and the like boot it just fine.]


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

___
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"

FYI: head (12-CURRENT) -r308247 on old 466 MHzPowerMac G4 (1 processor/1 core): taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0

2016-11-11 Thread Mark Millard 
When using head -r308247 to boot an old PowerMac G4 466 MHz (single 
processor/single core) there are two "taskqgroup_adjust failed cnt" messages:

> # dmesg
> Copyright (c) 1992-2016 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #0 r308247M: Thu Nov  3 11:39:11 PDT 2016
> 
> markmi@FreeBSDx64:/usr/obj/powerpcvtsc_clang_gcc421_kernel/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG
>  powerpc
> gcc version 4.2.1 20070831 patched [FreeBSD]
> cpu0: Motorola PowerPC 7400 revision 2.9, 466.97 MHz
> cpu0: Features 9c00
> cpu0: HID0 8094c0a4
> real memory  = 1588068352 (1514 MB)
> avail memory = 1530961920 (1460 MB)
> . . .
>  ATA8-ACS SATA 2.x device
> ada0: Serial Number 
> ada0: 66.700MB/s transfers (UDMA4, PIO 512bytes)
> ada0: 114473MB (234441648 512 byte sectors)
> taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
> taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
> Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs [rw,noatime]...
> gem0: link state changed to DOWN
> gem0: link state changed to UP

The above is repeatable for the indicated PowerMac, so far always at the same 
place in the sequence.

The other booted PowerMac's using this SSD have multiple processors (G4 and G5 
examples). None of them has reported such messages so far but those messages 
could be unrelated to the  processor count for all I know.

This -r308247 build is "stable style" relative to performance choices for the 
KERNCONF. And the KERNCONF disables/excludes PS3 and enables/includes sc 
(syscons) in addition to the normal vt.


I do warn that this is the environment were I experiment with the 
problematical-for-powerpc clang/clang++ 3.8.0 for buildworld. Build kernel is 
via gcc 4.2.1. The kernel has so-called "red zone" handling added for signals 
in order to deal with the clang ABI violations (in the stack handling).

At some point when all the available llvm powerpc-target fixes are in place 
I'll switch to the 3.9.0 project if I can. (Similarly for powerpc64.)

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

___
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"