Date: Wed, 12 Aug 2015 20:51:18 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: delphij@FreeBSD.org, imp@FreeBSD.org, mav@FreeBSD.org, ian@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: FreeBSD_HEAD_arm64 - Build #846 - Fixed Message-ID: <955934915.80.1439412679521.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1528517481.72.1439404951382.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1528517481.72.1439404951382.JavaMail.jenkins@jenkins-9.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD_HEAD_arm64 - Build #846 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/846/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/846/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/846/console Change summaries: 286696 by ian: Remove all dregs of the old PPS driver from this code, in preparation for redoing it as a separate driver. Now that each hardware timer is handled by a separate instance of the timer driver, it no longer makes sense to bundle the pps driver with the regular timecounter code. (When all 8 timers were handled by one driver there was no choice about this.) Split the hardware register definitions out to their own file, so that the new pps driver (coming in a separate commit later) can share them. With the PPS driver gone, the question of which hardware timer to use for what purpose becomes much easier (some instances can't do the PPS capture). Now we can just hardcore timer2 for eventtimer and timer3 for timecounter. This also now only instantiates devices for the 2 hardware timers actually used to implement eventtimer and timecounter. This is required so that other drivers can come along and attach to other hardware timers to provide other functionality. (In addition to PPS, this hardware can also do PWM stuff, general pulse width and frequency measurements, etc. Maybe some day we'll have drivers for those things.) 286695 by imp: Fix the fixing of the build I broke. rescue/rescue has the right target, but rescue doesn't. Pointy hat: imp@ 286693 by ian: Remove a bogus printf that whines every time loading a driver module triggers a fresh round of probing. 286692 by ian: Add a MODULE_VERSION(), because other things MODULE_DEPEND() on this. 286691 by delphij: Fix build. 286689 by mav: MFV r284763: 5981 Deadlock in dmu_objset_find_dp illumos/illumos-gate@1d3f896f5469c69c1339890ec3d68e9feddb0343 https://www.illumos.org/issues/5981 When dmu_objset_find_dp gets called with a read lock held, it fans out the work to the task queue. Each task in turn acquires its own read lock before calling the callback. If during this process anyone tries to a acquire a write lock, it will stall all read lock requests.Thus the tasks will never finish, the read lock of the caller will never get freed and the write lock never acquired. deadlock. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan McDonald <danmcd@omniti.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Arne Jansen <jansen@webgods.de> 286687 by imp: Document build-tools better. Add rescue back because it builds /bin/sh which has a build-tools target (see commit for how build-tools and cross-tools differ). 286686 by mav: MFV r284762: 5269 zpool import slow illumos/illumos-gate@12380e1e701fda28c9e9f32d01cafb54af279eb5 https://www.illumos.org/issues/5269 When importing a pool (at boot or with zpool import) with many filesystem, the process can take minutes. It doesn't matter whether the pool has been exported cleanly or uncleanly. The problem is that each dataset has its own log chain. On import, all datasets have to be checked if there are logs to replay. The idea is to speed up this process by paralellizing it. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george@delphix.com> Reviewed by: Dan McDonald <danmcd@omniti.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Arne Jansen <jansen@webgods.de> 286683 by mav: MFV r286682: 5765 add support for estimating send stream size with lzc_send_space when source is a bookmark Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Christopher Siden <christopher.siden@delphix.com> Reviewed by: Steven Hartland <killing@multiplay.co.uk> Reviewed by: Bayard Bell <buffer.g.overflow@gmail.com> Approved by: Albert Lee <trisk@nexenta.com> Author: Max Grossman <max.grossman@delphix.com> illumos/illumos-gate@643da460c8ca583e39ce053081754e24087f84c8
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?955934915.80.1439412679521.JavaMail.jenkins>