FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
Andriy Gapon
avg at FreeBSD.org
Sun Apr 3 17:20:11 UTC 2016
I wasn't able to understand what was the failure here...
On 03/04/2016 12:39, jenkins-admin at FreeBSD.org wrote:
> 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@
> 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
>
--
Andriy Gapon
More information about the freebsd-current
mailing list