Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 04, 2016 at 08:38:03PM +0800, Li-Wen Hsu wrote: > On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote: > > On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote: > > > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > > > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > > > > I've checked this a little more, I found the return code of > > > > > > > "installing a installed package" has been changed. > > > > > > > > > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > > > > > consider the build script execution failure. > > > > > > > > > > > > > > > > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can > > > > > > fix, I need > > > > > > to know more about what is failing to be able to fix > > > > > > > > > > What else information do you need? My experiment is as following: > > > > > > > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > > > > > installed package. I choose rsync here, then echo $?, it returns 0. > > > > > > > > > > And I switch to latest branch, also use `pkg install -y rsync`, but > > > > > this > > > > > time $? is 70. > > > > > > > > > > Jenkins "Execute shell" build step checks return value of each command > > > > > in the shell script, if it is non-zero, it aborts the build and > > > > > considers if failure. > > > > > > > > Return 70 means an error occured. if I look at the log I can see that > > > > powerpc64-gcc is not installed for sure, hence the error 70 > > > > > > > > What is strange it that no "error message is shown" > > > > > > Very strange, no further error message is shown, even -d provided. > > > > > > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc > > > DBG(1)[44393]> pkg initialized > > > Updating FreeBSD repository catalogue... > > > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD > > > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' > > > DBG(1)[44393]> Fetch: fetching from: > > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts > > > "i" > > > DBG(1)[44393]> Fetch: fetching from: > > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz > > > with opts "i" > > > FreeBSD repository is up-to-date. > > > All repositories are up-to-date. > > > DBG(1)[44393]> want to get an advisory lock on a database > > > DBG(1)[44393]> release an advisory lock on a database > > > root@jenkins10a:~ # echo $? > > > 70 > > > > > > Is there anything I can help on debugging this? > > > > > pkg info amd64-xtoolchain-gcc please > > root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc > DBG(1)[44644]> pkg initialized > amd64-xtoolchain-gcc-0.1 > Name : amd64-xtoolchain-gcc > Version: 0.1 > Installed on : Tue Mar 3 07:32:25 2015 UTC > Origin : devel/amd64-xtoolchain-gcc > Architecture : freebsd:10:x86:64 > Prefix : /usr/local > Categories : devel > Licenses : > Maintainer : b...@freebsd.org > WWW: UNKNOWN > Comment: Pre seeded toolchain to cross build FreeBSD base > Annotations: > repo_type : binary > repository : FreeBSD > Flat size : 225B > Description: > Pre seeded cross toolchain definition to cross build FreeBSD base > Ok I see the issue, I will fix it thanks. Bapt signature.asc Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote: > On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote: > > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > > > I've checked this a little more, I found the return code of > > > > > > "installing a installed package" has been changed. > > > > > > > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > > > > consider the build script execution failure. > > > > > > > > > > > > > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can > > > > > fix, I need > > > > > to know more about what is failing to be able to fix > > > > > > > > What else information do you need? My experiment is as following: > > > > > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > > > > installed package. I choose rsync here, then echo $?, it returns 0. > > > > > > > > And I switch to latest branch, also use `pkg install -y rsync`, but this > > > > time $? is 70. > > > > > > > > Jenkins "Execute shell" build step checks return value of each command > > > > in the shell script, if it is non-zero, it aborts the build and > > > > considers if failure. > > > > > > Return 70 means an error occured. if I look at the log I can see that > > > powerpc64-gcc is not installed for sure, hence the error 70 > > > > > > What is strange it that no "error message is shown" > > > > Very strange, no further error message is shown, even -d provided. > > > > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc > > DBG(1)[44393]> pkg initialized > > Updating FreeBSD repository catalogue... > > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD > > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' > > DBG(1)[44393]> Fetch: fetching from: > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i" > > DBG(1)[44393]> Fetch: fetching from: > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with > > opts "i" > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > DBG(1)[44393]> want to get an advisory lock on a database > > DBG(1)[44393]> release an advisory lock on a database > > root@jenkins10a:~ # echo $? > > 70 > > > > Is there anything I can help on debugging this? > > > pkg info amd64-xtoolchain-gcc please root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc DBG(1)[44644]> pkg initialized amd64-xtoolchain-gcc-0.1 Name : amd64-xtoolchain-gcc Version: 0.1 Installed on : Tue Mar 3 07:32:25 2015 UTC Origin : devel/amd64-xtoolchain-gcc Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : devel Licenses : Maintainer : b...@freebsd.org WWW: UNKNOWN Comment: Pre seeded toolchain to cross build FreeBSD base Annotations: repo_type : binary repository : FreeBSD Flat size : 225B Description: Pre seeded cross toolchain definition to cross build FreeBSD base -- Li-Wen Hsuhttps://lwhsu.org pgpdHfuwNBFfu.pgp Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote: > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > > I've checked this a little more, I found the return code of > > > > > "installing a installed package" has been changed. > > > > > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > > > consider the build script execution failure. > > > > > > > > > > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, > > > > I need > > > > to know more about what is failing to be able to fix > > > > > > What else information do you need? My experiment is as following: > > > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > > > installed package. I choose rsync here, then echo $?, it returns 0. > > > > > > And I switch to latest branch, also use `pkg install -y rsync`, but this > > > time $? is 70. > > > > > > Jenkins "Execute shell" build step checks return value of each command > > > in the shell script, if it is non-zero, it aborts the build and > > > considers if failure. > > > > Return 70 means an error occured. if I look at the log I can see that > > powerpc64-gcc is not installed for sure, hence the error 70 > > > > What is strange it that no "error message is shown" > > Very strange, no further error message is shown, even -d provided. > > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc > DBG(1)[44393]> pkg initialized > Updating FreeBSD repository catalogue... > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' > DBG(1)[44393]> Fetch: fetching from: > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i" > DBG(1)[44393]> Fetch: fetching from: > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with > opts "i" > FreeBSD repository is up-to-date. > All repositories are up-to-date. > DBG(1)[44393]> want to get an advisory lock on a database > DBG(1)[44393]> release an advisory lock on a database > root@jenkins10a:~ # echo $? > 70 > > Is there anything I can help on debugging this? > pkg info amd64-xtoolchain-gcc please Bapt signature.asc Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote: > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > > I've checked this a little more, I found the return code of > > > > "installing a installed package" has been changed. > > > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > > consider the build script execution failure. > > > > > > > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I > > > need > > > to know more about what is failing to be able to fix > > > > What else information do you need? My experiment is as following: > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > > installed package. I choose rsync here, then echo $?, it returns 0. > > > > And I switch to latest branch, also use `pkg install -y rsync`, but this > > time $? is 70. > > > > Jenkins "Execute shell" build step checks return value of each command > > in the shell script, if it is non-zero, it aborts the build and > > considers if failure. > > Return 70 means an error occured. if I look at the log I can see that > powerpc64-gcc is not installed for sure, hence the error 70 > > What is strange it that no "error message is shown" Very strange, no further error message is shown, even -d provided. root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc DBG(1)[44393]> pkg initialized Updating FreeBSD repository catalogue... DBG(1)[44393]> PkgRepo: verifying update for FreeBSD DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite' DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i" DBG(1)[44393]> Fetch: fetching from: http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with opts "i" FreeBSD repository is up-to-date. All repositories are up-to-date. DBG(1)[44393]> want to get an advisory lock on a database DBG(1)[44393]> release an advisory lock on a database root@jenkins10a:~ # echo $? 70 Is there anything I can help on debugging this? Li-Wen -- Li-Wen Hsuhttps://lwhsu.org pgpeYe5_Z1goK.pgp Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote: > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > > I've checked this a little more, I found the return code of > > > "installing a installed package" has been changed. > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > > consider the build script execution failure. > > > > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I > > need > > to know more about what is failing to be able to fix > > What else information do you need? My experiment is as following: > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a > installed package. I choose rsync here, then echo $?, it returns 0. > > And I switch to latest branch, also use `pkg install -y rsync`, but this > time $? is 70. > > Jenkins "Execute shell" build step checks return value of each command > in the shell script, if it is non-zero, it aborts the build and > considers if failure. Return 70 means an error occured. if I look at the log I can see that powerpc64-gcc is not installed for sure, hence the error 70 What is strange it that no "error message is shown" Best regards, Bapt signature.asc Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote: > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > > I've checked this a little more, I found the return code of > > "installing a installed package" has been changed. > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > > consider the build script execution failure. > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I need > to know more about what is failing to be able to fix What else information do you need? My experiment is as following: On a machine uses quarterly branch, where pkg is 1.6.4_1, install a installed package. I choose rsync here, then echo $?, it returns 0. And I switch to latest branch, also use `pkg install -y rsync`, but this time $? is 70. Jenkins "Execute shell" build step checks return value of each command in the shell script, if it is non-zero, it aborts the build and considers if failure. Regards, Li-Wen -- Li-Wen Hsuhttps://lwhsu.org pgp4Q687kR8Pv.pgp Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote: > On Mon, Apr 4, 2016 at 1:59 AM, Dimitry Andric <d...@freebsd.org> wrote: > > On 03 Apr 2016, at 19:19, Andriy Gapon <a...@freebsd.org> wrote: > >> On 03/04/2016 12:39, jenkins-ad...@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 > >>> > >> > >> I wasn't able to understand what was the failure here... > > > > The step to install the amd64-xtoolchain-gcc package failed, apparently > > because it decided to auto-upgrade pkg first, without actually installing > > the package that was asked for: > > > > + 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 > > > > I'd consider this a bug in pkg? Is it suppose to return a failure code in > > this case? > > I've checked this a little more, I found the return code of > "installing a installed package" has been changed. > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins > consider the build script execution failure. > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I need to know more about what is failing to be able to fix Best regards, Bapt signature.asc Description: PGP signature
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On Mon, Apr 4, 2016 at 1:59 AM, Dimitry Andric <d...@freebsd.org> wrote: > On 03 Apr 2016, at 19:19, Andriy Gapon <a...@freebsd.org> wrote: >> On 03/04/2016 12:39, jenkins-ad...@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 >>> >> >> I wasn't able to understand what was the failure here... > > The step to install the amd64-xtoolchain-gcc package failed, apparently > because it decided to auto-upgrade pkg first, without actually installing the > package that was asked for: > > + 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 > > I'd consider this a bug in pkg? Is it suppose to return a failure code in > this case? I've checked this a little more, I found the return code of "installing a installed package" has been changed. For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins consider the build script execution failure. Li-Wen -- Li-Wen Hsu <lw...@freebsd.org> https://lwhsu.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"
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
On 03 Apr 2016, at 19:19, Andriy Gapon <a...@freebsd.org> wrote: > On 03/04/2016 12:39, jenkins-ad...@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 >> > > I wasn't able to understand what was the failure here... The step to install the amd64-xtoolchain-gcc package failed, apparently because it decided to auto-upgrade pkg first, without actually installing the package that was asked for: + 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 I'd consider this a bug in pkg? Is it suppose to return a failure code in this case? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure
I wasn't able to understand what was the failure here... On 03/04/2016 12:39, jenkins-ad...@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-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 > +' > 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
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-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 +' 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 repos