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-f...@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@ 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 _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"