FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure:

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

Change summaries:

297521 by avg:
fix zfs set canmount=off on an unmounted filesystem

Previously this operation tried to unmount and remount children.
Also see https://www.illumos.org/issues/6428.

MFC after:	2 weeks
X-Needs-Upstreaming:	illumos

297520 by avg:
zfs receive: -u can be ignored sometimes

When force-receiving a filesystem that was already mounted the re-created
filesystem is mounted despite -u flag.

Also see https://www.illumos.org/issues/6412.

PR:		204705
Tested by:	Vladimir Krstulja <vlad-fbsd_at_acheronmedia.com>
MFC after:	2 weeks
X-Needs-Upstreaming:	illumos

297519 by dchagin:
Move Linux specific times tests up to guarantee the values are defined.

CID:		1305178
Submitted by:	pfg_at_
MFC after:	1 week

297514 by jmcneill:
Improve HDMI display detection by searching the CEA-861 extension block for
an HDMI vendor-specific data block (VSDB) containing the HDMI 24-bit IEEE
registration ID (0x000C03).

Approved by:	gonzo (mentor)

297513 by avg:
remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat

On FreeBSD VFS_HOLD/VN_RELE were mapped to MNT_REF/MNT_REL that
manipulate mnt_ref.  But the job of properly maintaining the reference
count is already automatically performed by insmntque(9) and
delmntque(9).  So, in effect all ZFS vnodes referenced the corresponding
mountpoint twice.

That was completely harmless, but we want to be very explicit about what
FreeBSD VFS APIs are used, because illumos VFS_HOLD and FreeBSD MNT_REF
provide quite different guarantees with respect to the held vfs_t /
mountpoint.  On illumos VFS_HOLD is sufficient to guarantee that
vfs_t.vfs_data stays valid.  On the other hand, on FreeBSD MNT_REF does
*not* provide the same guarantee about mnt_data.  We have to use
vfs_busy() to get that guarantee.

Thus, the calls to VFS_HOLD/VFS_RELE on vnode init and fini are removed.
VFS_HOLD calls are replaced with vfs_busy in the ioctl handlers.

And because vfs_busy has a richer interface that can not be dumbed down
in all cases it's better to explicitly use it rather than trying to mask
it behind VFS_HOLD.

This change fixes a panic that could result from a race between
zfs_umount() and zfs_ioc_rollback().  We observed a case where
zfsvfs_free() tried to destroy data that zfsvfs_teardown() was still
using.  That happened because there was nothing to prevent unmounting of
a ZFS filesystem that was in between zfs_suspend_fs() and
zfs_resume_fs().

Reviewed by:	kib, smh
MFC after:	3 weeks
Sponsored by:	ClusterHQ
Differential Revision: https://reviews.freebsd.org/D2794



The end of the build log:

Started by an SCM change
Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace /builds/FreeBSD_HEAD_amd64_gcc
Updating svn://svn.freebsd.org/base/head at revision '2016-04-03T09:38:08.949 +0000'
U         cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
U         cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
U         sys/compat/linux/linux_misc.c
U         sys/arm/allwinner/a10_hdmi.c
U         sys/cddl/compat/opensolaris/sys/vfs.h
U         sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c
U         sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
U         sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
At revision 297521

No emails were triggered.
[FreeBSD_HEAD_amd64_gcc] $ /bin/sh -xe /tmp/hudson8754098237068074298.sh
+ cat
+ svn revert Makefile.inc1
+ svn revert sys/boot/i386/Makefile
Reverted 'sys/boot/i386/Makefile'
+ patch -f
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: sys/boot/i386/Makefile
|===================================================================
|--- sys/boot/i386/Makefile	(revision 280912)
|+++ sys/boot/i386/Makefile	(working copy)
--------------------------
Patching file sys/boot/i386/Makefile using Plan A...
Hunk #1 succeeded at 16 (offset 4 lines).
Hmm...  Ignoring the trailing garbage.
done
+ /vm/freebsd-ci/scripts/build/cross-build.sh
+ [ -z /builds/FreeBSD_HEAD_amd64_gcc ]
+ [ -z amd64 ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD_amd64_gcc/obj
+ mkdir -p /builds/FreeBSD_HEAD_amd64_gcc/obj
+ echo -e 'NO_WERROR=yes
WERROR=
WITH_FAST_DEPEND=yes'
+ cat
+ set +x
--------------------------------------------------------------
>>> /builds/FreeBSD_HEAD_amd64_gcc/make.conf contains:
+ cat /builds/FreeBSD_HEAD_amd64_gcc/make.conf
# Put make.conf entries here
NO_WERROR=yes
WERROR=
WITH_FAST_DEPEND=yes
+ set +x
--------------------------------------------------------------
+ sudo pkg install -y devel/amd64-xtoolchain-gcc
Updating FreeBSD repository catalogue...
Fetching meta.txz: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
FreeBSD repository update completed. 25093 packages processed.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
	pkg: 1.6.4_1 -> 1.7.1

The process will require 84 KiB more space.
2 MiB to be downloaded.
Fetching pkg-1.7.1.txz: .......... done
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.6.4_1 to 1.7.1...
[1/1] Extracting pkg-1.7.1: .......... done
Updating FreeBSD repository catalogue...
Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Build step 'Execute shell' marked build as failure
[WARNINGS] Skipping publisher since build result is FAILURE
IRC notifier plugin: Sending notification to: #freebsd-commits
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any