Ryan Stone | 28 May 17:29 2016
Picon

panic: DI already started in pmap_delayed_invl_started

I updated my system to r254461 on Thursday, and got this panic overnight.
I have a full core and debug symbols if anybody wants me to look at
something.

panic: DI already started
cpuid = 10
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfffffe1838bbc380
vpanic() at vpanic+0x182/frame 0xfffffe1838bbc400
kassert_panic() at kassert_panic+0x126/frame 0xfffffe1838bbc470
pmap_delayed_invl_started() at pmap_delayed_invl_started+0xe1/frame
0xfffffe1838bbc490
pmap_advise() at pmap_advise+0x31/frame 0xfffffe1838bbc540
vm_fault_dontneed() at vm_fault_dontneed+0x12f/frame 0xfffffe1838bbc590
vm_fault_hold() at vm_fault_hold+0x919/frame 0xfffffe1838bbc6a0
vm_fault() at vm_fault+0x78/frame 0xfffffe1838bbc6e0
vm_run() at vm_run+0x5b5/frame 0xfffffe1838bbc880
vmmdev_ioctl() at vmmdev_ioctl+0x8c2/frame 0xfffffe1838bbc940
devfs_ioctl_f() at devfs_ioctl_f+0x156/frame 0xfffffe1838bbc9a0
kern_ioctl() at kern_ioctl+0x246/frame 0xfffffe1838bbca00
sys_ioctl() at sys_ioctl+0x171/frame 0xfffffe1838bbcae0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe1838bbcbf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1838bbcbf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800ff60fa, rsp =
0x7fffdedf4e28, rbp = 0x7fffdedf4ee0 ---
_______________________________________________
freebsd-current <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
(Continue reading)

Bryan Drewery | 28 May 02:16 2016
Picon

[CFT] WITH_META_MODE: Working incremental build

Buildworld/Buildkernel now supports a working incremental build.  Using
-DNO_CLEAN is not needed as it is the default with it (there is no
-DCLEAN for it).  The normal -DNO_CLEAN feature is broken and risky
since it does not track a ton of the dependencies in the build such as
the compiler, other build tools, csu/crt, CFLAGS, build commands, mk
files, etc.

Note that originally WITH_META_MODE initiated a new build system but
that was renamed to WITH_DIRDEPS_BUILD and is something different entirely.

The way that "meta mode" works is to enable the bmake "meta mode"
feature that tracks the build command for each target and uses the
filemon(4) [1] module to track all files read/written/executed for
building target.  If any of these change (see src.conf(5) WITH_META_MODE
for details) then the target will be rebuilt.  This means that even
changes to CFLAGS or the cross compiler will be detected and cause
rebuilds.  This is quite an aggressive system but it works and removes
the need for cleaning any of the tree.  In this mode .depend.* files
(WITH_FAST_DEPEND) are not generated since they are mostly redundant
with filemon(4)'s tracking.

An example in how powerful this is, is that I have today been testing
buildworld with the in-tree clang and also doing builds on the same
objdir with CROSS_TOOLCHAIN=amd64-gcc.  Everything using a compiler
would rebuild and anything not using a compiler would not rebuild.  No
cleaning needed.

To use this you must either add WITH_META_MODE=yes to your environment
or add it into /etc/src-env.conf (not /etc/src.conf or /etc/make.conf).
You will also need to load the filemon(4) module with 'kldload filemon'.
(Continue reading)

jenkins-admin | 27 May 23:36 2016
Picon

FreeBSD_HEAD_i386 - Build #3230 - Failure

FreeBSD_HEAD_i386 - Build #3230 - Failure:

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

Change summaries:

300874 by ngie:
Update usage(..)

- Document missing options
- Sync options with ioatcontrol(8).
- Make it clear that the first 2 parameters are always required.

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

300873 by dim:
After r300770, for libc++ and libcxxrt, use -isystem instead of -I.
This should fix builds with external gcc toolchains from ports, which
also use -isystem to work around problems with gcc's --sysroot
implementation.  Thanks to Bryan Drewery for this workaround.

300872 by ian:
Go back to unconditionally compiling modules/gpio now that the parts of it
dependent on FDT support are conditionally compiled only on FDT platforms.

300871 by ian:
Don't wrap the declaration of gpio_alloc_intr_resource() in #ifdef INTRNG,
(Continue reading)

Alan Somers | 27 May 21:48 2016
Picon

cannot represent machine `mips:amd64'

Starting today, I get this error for several mips targets whenever I
do "make universe".  Does anybody know what might be causing it?  I
see it for mips.mips64, mips.mipsn32, and mips.mips64el .

--------------------------------------------------------------
>>> stage 4.2: building libraries
--------------------------------------------------------------
===> gnu/lib/libssp/libssp_nonshared (obj,all,install)
===> gnu/lib/libgcc (obj,all,install)
===> lib/libcompiler_rt (obj,all,install)
===> gnu/lib/csu (obj,all,install)
===> lib/csu (obj,all,install)
===> lib/csu/mips (obj)
===> lib/csu/mips (all)
===> lib/csu/mips (install)
===> lib/libcompiler_rt (obj,all,install)
===> lib/libc (obj,all,install)
===> lib/libc_nonshared (obj,all,install)
/scratch/tmp/asomers/obj/mips.mips64/home/asomers/freebsd/head/tmp/usr/bin/ld:
cannot represent machine `mips:amd64'
--- libc.so.7.full ---
*** [libc.so.7.full] Error code 1

-Alan
_______________________________________________
freebsd-current <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

(Continue reading)

Mateusz Guzik | 27 May 21:17 2016
Picon

[PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

Hello there,

quite some time ago I posted a trivial patch to locking primitives. What
they do is the inline part tries an atomic op and if that fails the
actual function is called, which immediately tries the same op.

The obvious optimisation checks for the availability of the lock first.

There concerns about the way it was done previously by relying on
volatile behaving in a specific way.

Later a simplified version was posted which should not have the concern,
but the thread died.

I refer you to https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058100.html
for simple benchmark results.

I would like to get the patch in before 11 freeze.

diff --git a/sys/kern/kern_lock.c b/sys/kern/kern_lock.c
index 34d7b34..1b10623 100644
--- a/sys/kern/kern_lock.c
+++ b/sys/kern/kern_lock.c
 <at>  <at>  -787,8 +787,10  <at>  <at>  __lockmgr_args(struct lock *lk, u_int flags, struct lock_object *ilk,
 			break;
 		}

-		while (!atomic_cmpset_acq_ptr(&lk->lk_lock, LK_UNLOCKED,
-		    tid)) {
+		for (;;) {
(Continue reading)

jenkins-admin | 27 May 12:59 2016
Picon

FreeBSD_HEAD_amd64_gcc - Build #1266 - Failure

FreeBSD_HEAD_amd64_gcc - Build #1266 - Failure:

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

Change summaries:

300836 by ngie:
Quell false positives in svc_vc_create and svc_vc_create_conn with cd and xprt

Both cd and xprt will be non-NULL after their respective malloc(9) wrappers are
called (mem_alloc and svc_xprt_alloc, which calls mem_alloc) as mem_alloc
always gets called with M_WAITOK|M_ZERO today. Thus, testing for them being
non-NULL is incorrect -- it misleads Coverity and it misleads the reader.

Remove some unnecessary NULL initializations as a follow up to help solidify
the fact that these pointers will be initialized properly in sys/rpc/.. with
the interfaces the way they are currently.

Differential Revision: https://reviews.freebsd.org/D6572
MFC after: 2 weeks
Reported by: Coverity
CID: 1007338, 1007339, 1007340
Reviewed by: markj, truckman
Sponsored by: EMC / Isilon Storage Division

300835 by hselasky:
The SCHEDULER_STOPPED() macro already contains a predict false statement.
Remove superfluous unlikely() wrapper.
(Continue reading)

jenkins-admin | 27 May 04:15 2016
Picon

FreeBSD_HEAD_i386 - Build #3222 - Failure

FreeBSD_HEAD_i386 - Build #3222 - Failure:

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

Change summaries:

300814 by gjb:
Make Makefile.mirrors -ALPHA${N}-aware.

Approved by:	re (implicit)
Sponsored by:	The FreeBSD Foundation

300813 by gjb:
Update head from 11.0-CURRENT to 11.0-ALPHA1, marking the official
start of the code slush.

Approved by:	re (implicit)
Sponsored by:	The FreeBSD Foundation

300812 by ian:
Revert changes for local testing, inadvertantly commited in r300811.

300811 by ian:
Add a PPS driver that takes the timing pulse from a gpio pin.  Currently
supports only ofw/fdt systems.  Some day, hinted attachment for non-fdt
systems should be possible too.

300810 by jhb:
(Continue reading)

Ngie Cooper | 27 May 04:12 2016
Picon

exports(5) no longer allows multiple paths per line?

Hi,
    It seems like the following /etc/exports should work, but for some
odd reason specifying both paths on a single line doesn't work (I
swore it was working on a kernel/userland built in the past month,
i.e. ^/head <at> r297950, but I might be misremembering things).
    exports(5) claims that 2 mountpoints (at least) can be used on a
single line, but my experiments prove otherwise.
Thanks,
-Ngie

    Example from exports(5):

EXAMPLES
           /usr /usr/local -maproot=0:10 friends

    Failing example:

# df -h /tftpboot /home/ngie
Filesystem         Size    Used   Avail Capacity  Mounted on
zroot/tftpboot     232G    1.2G    231G     1%    /tftpboot
zroot/home/ngie    236G    5.5G    231G     2%    /home/ngie
# cat /etc/exports
/home/ngie/freebsd /tftpboot -maproot=0:0 -alldirs -ro
# stat -f '%d %r %N' /tftpboot/ /home/ngie
3945781817 4294967295 /tftpboot/
3049773785 4294967295 /home/ngie
# showmount -e
Exports list on localhost:
#

(Continue reading)

Eric van Gyzen | 26 May 16:44 2016
Picon

Date formatting with en_US locale

Baptiste and -current,

I noticed two annoyances with date formatting on head, and I wonder how
we can fix them.

I have these settings:

    LC_ALL=en_US.ISO8859-1
    LANG=en_US.ISO8859-1

First, Thunderbird displays the date as, for example:

    03/ 6/16 ...

The leading space on the day (6) looks weird.  I might even say it's
simply wrong.  Zero-padding would better.  (/No/ padding would be best,
but I don't think strftime supports that.)

Second, date(1) no longer shows the day-of-week:

    $ date
    March 26, 2016 at 09:21:55 AM CDT

For many years, I have been typing "date" to see the day-of-week (and
other things).  I like the new human-friendly format, but I miss the
day-of-week.

Of course, I can fix these locally, but I wonder how we can fix them for
everyone.  I see that the formats come from CLDR.  I also see that ume <at> 
restored the day-of-week for ja_JP in r292512.  Is this the best
(Continue reading)

Juan Ramón Molina Menor | 26 May 10:54 2016
Picon

dmesg: can't reuse a leaf (ixl_rx_miss_bufs)!

Hi!

In three different machines running HEAD I have this message in the very 
first lines of the dmesg output:

can't reuse a leaf (ixl_rx_miss_bufs)!

I don’t remember seeing it before and I have not configured any ixl 
device. It seems harmless, but I wonder if it’s a sign of a bug somewhere.

Cheers,
Juan
_______________________________________________
freebsd-current <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Gary Jennejohn | 26 May 08:42 2016
Picon

Recognizing SMR HDDs

Now that ken <at>  has checked in the SMR code I'm wondering how I can see
whether it's having any effect.

I have a 8TB SMR disk in a USB3 enclosure.  Does the kernel emit any
sort of trace to indicate that it sees the drive as SMR and takes
that into account?

I have the probe trace enabled in my kernel config, but I don't see
anything special pop out when I turn the drive on.

Does the fact that the drive appears as a /dev/daX play any role?

BTW the disk returns an error when multiple LUNs are probed.

--

-- 
Gary Jennejohn
_______________________________________________
freebsd-current <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"


Gmane