From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 01:32:51 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF622832; Sun, 5 Oct 2014 01:32:50 +0000 (UTC) Date: Sat, 4 Oct 2014 21:32:47 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 10.1-RC1 Now Available Message-ID: <20141005013247.GH1171@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 01:32:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The first RC build of the 10.1-RELEASE release cycle is now available on the FTP servers for the amd64, armv6, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The image checksums follow at the end of this email. Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/10.1" branch. A list of changes since 10.0-RELEASE are available here: https://www.freebsd.org/releases/10.1R/relnotes.html Important note to ZFS users on the i386 architecture: A regression has been discovered that affects multi-disk (mirror, raidz-1, raidz-2, etc.) installations that may cause a kernel panic on boot. If using a multi-disk ZFS setup, adding 'options KSTACK_PAGES=4' is suspected to resolve the problem. Please *do* *not* upgrade your system with freebsd-update(8) if using a multi-disk ZFS setup, since this will override the kernel configuration with the GENERIC kernel. Some of the changes between 10.1-BETA3 and 10.1-RC1 include: o A bug that would cause all processes to appear to have the parent PID of '1' has been fixed. o Various updates to bsdinstall(8) and bsdconfig(8). o The Hyper-V KVP (key-value pair) driver has been added, and enabled by default on amd64 and i386 architectures. Pre-installed virtual machine images for 10.1-RC1 are also available for amd64 and i386 architectures. The images are located here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.1-RC1/ The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB, which decompress to a 20GB sparse image. The partition layout is: . 512k - freebsd-boot GPT partition type (bootfs GPT label) . 1GB - freebsd-swap GPT partition type (swapfs GPT label) . ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Note to consumers of the dvd1.iso image: The packages included on the dvd will not be recognized by bsdconfig(8), and the cause is being investigated. The packages, however, can be installed manually. To install packages from the dvd1.iso installer, create and mount the /dist directory: # mkdir -p /dist # mount -t cd9660 /dev/cd0 /dist Next, install pkg(8) from the DVD: # env REPOS_DIR=/dist/packages/repos \ pkg bootstrap At this point, pkg-install(8) can be used to install additional packages from the DVD. Please note, the REPOS_DIR environment variable should be used each time using the DVD as the package repository, otherwise conflicts with packages from the upstream mirrors may occur when they are fetched. For example, to install Gnome and Xorg, run: # env REPOS_DIR=/dist/packages/repos \ pkg install xorg-server xorg gnome2 [...] The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.1-RC1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 8.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.1-RC1 amd64 GENERIC: SHA256 (FreeBSD-10.1-RC1-amd64-bootonly.iso) = 2eed2af8fb933383da64c3c5467815f115e71233514fee50e31f98134e9e23e1 SHA256 (FreeBSD-10.1-RC1-amd64-bootonly.iso.xz) = 6f59a7b0559825ee23baf2bc8db0743baff2d8c300361a6977bb0786dbad6e7c SHA256 (FreeBSD-10.1-RC1-amd64-disc1.iso) = ca81416dfe24ba79b902bdf4fbb904e7ab8490f14cd32a4a6ccd87f51d9d9578 SHA256 (FreeBSD-10.1-RC1-amd64-disc1.iso.xz) = 29da4a6aef2cf316ad93a87f1ecbb148de80f648fdb71f6efd5009cf938d81d2 SHA256 (FreeBSD-10.1-RC1-amd64-dvd1.iso) = ecec9e2d8051cf97fd428c639fc3851401383582e083fc0664920626d4fc5e97 SHA256 (FreeBSD-10.1-RC1-amd64-dvd1.iso.xz) = edc578241162f8015e657b46e93bfbe99d73fd533da56508bed2f5185cd643f5 SHA256 (FreeBSD-10.1-RC1-amd64-memstick.img) = b046148a4c9377c7709da76eaddbe87128ab1c99fcf1dfd46bb4d5216a3053be SHA256 (FreeBSD-10.1-RC1-amd64-memstick.img.xz) = c1b76f936c6c547126f6e142c510fdb594f2c7d53ddd1d14b4fe710e0cd4cf2e SHA256 (FreeBSD-10.1-RC1-amd64-mini-memstick.img) = e1ac432fb1bbe4029038d25853e38590bb7c43eae0e772159d4ecdd373d63d90 SHA256 (FreeBSD-10.1-RC1-amd64-mini-memstick.img.xz) = 35a98206f82d1eddcb5a1be029b2ac37af5783de94812ae4165a1492ec871c6f SHA256 (FreeBSD-10.1-RC1-amd64-uefi-bootonly.iso) = 2180d1f8a12e2a556114a03d7fceea87d259c184f1bdd4bf235e09be15aa7943 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-bootonly.iso.xz) = 126fd529a5ed5605327ec47da912c25d7293c7e058672610e63f500169d492e0 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-disc1.iso) = 391a605bcfd46e2430db52021438aee439f6b26528299cfae6132d6c363f94e2 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-disc1.iso.xz) = c182dbcf9c0a7c53d696804ef9bc32ade8456479e5a03c6aaeeb9ff1cfef7aa2 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-dvd1.iso) = 02d9bb96ffa2afe24d1ffa44d01e69bd5178b1c3976c35c0d3bdc38479729f7e SHA256 (FreeBSD-10.1-RC1-amd64-uefi-dvd1.iso.xz) = 7b42038b09db5a7297c496de985e07443f329f9e51301b437a9440d582479009 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-memstick.img) = 94c5de6d49ae270e7c1ee9808771821b62af6438f884425cded9ccbb5844b671 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-memstick.img.xz) = e46efd9571de7a0e507a6fa5ebd7109d62b13df548e8a3e5bb84e21d88a47ad1 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-mini-memstick.img) = c37fb85f285d5c6a3905ce86b6921a96e17b6d23daac498bc75e2233ae7d93e6 SHA256 (FreeBSD-10.1-RC1-amd64-uefi-mini-memstick.img.xz) = 492a446c1b44860893c5bcd8511b4ab47fb86b0ef0046fe3917cc0dc46713387 MD5 (FreeBSD-10.1-RC1-amd64-bootonly.iso) = 3cec3641157b62e4834adaa77aa65b21 MD5 (FreeBSD-10.1-RC1-amd64-bootonly.iso.xz) = 6f7aad84c2b9549d4bd1a47fea6572a4 MD5 (FreeBSD-10.1-RC1-amd64-disc1.iso) = 694b7415a0ec11b34374f51682358fed MD5 (FreeBSD-10.1-RC1-amd64-disc1.iso.xz) = a6489119f0fb3bdca246c85a72fc00be MD5 (FreeBSD-10.1-RC1-amd64-dvd1.iso) = 20f4ca51e63f85703ca918a44439e4af MD5 (FreeBSD-10.1-RC1-amd64-dvd1.iso.xz) = 0f14b016d32395ba6b5ad778449cf370 MD5 (FreeBSD-10.1-RC1-amd64-memstick.img) = ea31857ad3ef7ac0524ea5dfb29ea494 MD5 (FreeBSD-10.1-RC1-amd64-memstick.img.xz) = 3ea3514fdb8ef77532e9a3f46f946e75 MD5 (FreeBSD-10.1-RC1-amd64-mini-memstick.img) = e28e55a49352442773ff3c7421fc6544 MD5 (FreeBSD-10.1-RC1-amd64-mini-memstick.img.xz) = 31ed3a59ceb30469c727681e791ac611 MD5 (FreeBSD-10.1-RC1-amd64-uefi-bootonly.iso) = 84fde2d9f4a0f356c774272994e76651 MD5 (FreeBSD-10.1-RC1-amd64-uefi-bootonly.iso.xz) = 3cec1cc74cfe3f59319d4bc8730b9e3b MD5 (FreeBSD-10.1-RC1-amd64-uefi-disc1.iso) = 7708a54beaafe6c7430926b0bc39c123 MD5 (FreeBSD-10.1-RC1-amd64-uefi-disc1.iso.xz) = dd5ca2c9a165542674fe4e44c7c67f8a MD5 (FreeBSD-10.1-RC1-amd64-uefi-dvd1.iso) = 6044cef9da5ec926538135fb962d76f7 MD5 (FreeBSD-10.1-RC1-amd64-uefi-dvd1.iso.xz) = d569a12ef599a289134588135390c32a MD5 (FreeBSD-10.1-RC1-amd64-uefi-memstick.img) = c6e16065cc337dd403c7ebc9a0f781c8 MD5 (FreeBSD-10.1-RC1-amd64-uefi-memstick.img.xz) = 657b1bf49c55fc72be46e31ff42048bd MD5 (FreeBSD-10.1-RC1-amd64-uefi-mini-memstick.img) = b2157141a3704cbdc7c0bb1330d37303 MD5 (FreeBSD-10.1-RC1-amd64-uefi-mini-memstick.img.xz) = a6326bbac68159a06b84ef519c7d6676 o 10.1-RC1 i386 GENERIC: SHA256 (FreeBSD-10.1-RC1-i386-bootonly.iso) = d9e44dc052e52d6578beecd8cd511defbfa6e8d672cc0109450861e29c2f3aba SHA256 (FreeBSD-10.1-RC1-i386-bootonly.iso.xz) = 598c0d915b4ec25d92d1d2bbc8be493bb881fa1f111161aa32b67aacb0160e69 SHA256 (FreeBSD-10.1-RC1-i386-disc1.iso) = 492e52c43e23c3f8e62bed71658a464913201f39f0877aad9bbfd0c8fb553c97 SHA256 (FreeBSD-10.1-RC1-i386-disc1.iso.xz) = 6bb2657b45a74158e54016f03a7baa67216df0b8324a25213977eb84bc6635b8 SHA256 (FreeBSD-10.1-RC1-i386-dvd1.iso) = 6266ea4bd0ae6df75bd36338284f826d931546dabbce02d4d5b07d4c04adf34a SHA256 (FreeBSD-10.1-RC1-i386-dvd1.iso.xz) = 743016edcf6e6b08495dd8ca088b1a1a4903b80461972bab162d648fb3af5e56 SHA256 (FreeBSD-10.1-RC1-i386-memstick.img) = e03846abbec5c64cfb6ea8f2c16d9622652725ce787f23ba32a9e5400d053a93 SHA256 (FreeBSD-10.1-RC1-i386-memstick.img.xz) = 1b0ef91cbeb799396140fa9e8b82820f103dda668df6b0a03be20e5430ccc906 SHA256 (FreeBSD-10.1-RC1-i386-mini-memstick.img) = 9c59fdcd07f9ab4fa3ee527d18ed8c65ea4527e029bc71b454a034da9826f3cc SHA256 (FreeBSD-10.1-RC1-i386-mini-memstick.img.xz) = 1c4ffbdc1353d279ba06da8797f6119a1e9f8ca8470e94f1a05d614930042544 MD5 (FreeBSD-10.1-RC1-i386-bootonly.iso) = 45b48b7f831388d733d8969e9d6852c6 MD5 (FreeBSD-10.1-RC1-i386-bootonly.iso.xz) = 654a9fec528a83b9e012672660bf51ff MD5 (FreeBSD-10.1-RC1-i386-disc1.iso) = bf8197b99cd1b56d5a325fc449bb5442 MD5 (FreeBSD-10.1-RC1-i386-disc1.iso.xz) = a3eac0c4eca9cad3c5527852db28784e MD5 (FreeBSD-10.1-RC1-i386-dvd1.iso) = 8c7f687a3d23866d34f7fe723cbbc50e MD5 (FreeBSD-10.1-RC1-i386-dvd1.iso.xz) = 9120a2d5a9c3c792bec855cfe76f5fe0 MD5 (FreeBSD-10.1-RC1-i386-memstick.img) = 1e7618b61e06155c7c7585bb360d7ffe MD5 (FreeBSD-10.1-RC1-i386-memstick.img.xz) = 8c713265a46635caa12dfd2949faf262 MD5 (FreeBSD-10.1-RC1-i386-mini-memstick.img) = 8d4fbee73e663b39dd770ce8eb7114fe MD5 (FreeBSD-10.1-RC1-i386-mini-memstick.img.xz) = e40f07023af3bb714dcc7b7b663491b5 o 10.1-RC1 ia64 GENERIC: SHA256 (FreeBSD-10.1-RC1-ia64-bootonly.iso) = 9785f71de0a5585eec0edad92aae97422deecc654f7786558bdc240351f65cf8 SHA256 (FreeBSD-10.1-RC1-ia64-bootonly.iso.xz) = 27ea04173bd49718abc124a282cee6bcb6713c39f98bd3905435f5b71a1a2304 SHA256 (FreeBSD-10.1-RC1-ia64-disc1.iso) = fe4be1e6d704d429865aa177a5bb2db309d670b8c5b5bd26583edfee7ad56d1f SHA256 (FreeBSD-10.1-RC1-ia64-disc1.iso.xz) = 34a06438036b69c388706c553041080be4210a1923924dbf4604aaccae621bb9 SHA256 (FreeBSD-10.1-RC1-ia64-memstick.img) = 789a6daabb5a8f0916267adcfb1f12584961dbf1dc2c8ebbc99ee5b47851a1b4 SHA256 (FreeBSD-10.1-RC1-ia64-memstick.img.xz) = 99fb6018d3e51ecb382965c67ada6d9b77bf4ae54ddd7602b2c7b853fb17b555 SHA256 (FreeBSD-10.1-RC1-ia64-mini-memstick.img) = 725964963a295ceae8dbe50c58346357837a045af2debf27c358accb35787266 SHA256 (FreeBSD-10.1-RC1-ia64-mini-memstick.img.xz) = 66e06a357324a212e707bd12096ba2df438e905326a8cbe2997e7f1f830642fd MD5 (FreeBSD-10.1-RC1-ia64-bootonly.iso) = a4e5f48b9a72483f752757f4762c2d8d MD5 (FreeBSD-10.1-RC1-ia64-bootonly.iso.xz) = ec7d0edb555f1124167bbc3c091ebfc3 MD5 (FreeBSD-10.1-RC1-ia64-disc1.iso) = bebd00ee4de432d28936f12063631b0a MD5 (FreeBSD-10.1-RC1-ia64-disc1.iso.xz) = 395420fbbe57f1a39a01a36ea050ab58 MD5 (FreeBSD-10.1-RC1-ia64-memstick.img) = 9356570876ba1897e4fba7cabe2c76c4 MD5 (FreeBSD-10.1-RC1-ia64-memstick.img.xz) = 9e8e687862ef2820353abb0134580813 MD5 (FreeBSD-10.1-RC1-ia64-mini-memstick.img) = 2815c790cee3c08936cfc5bcca9a968f MD5 (FreeBSD-10.1-RC1-ia64-mini-memstick.img.xz) = e072378ba20a23c6e72357e793e225d1 o 10.1-RC1 powerpc GENERIC: SHA256 (FreeBSD-10.1-RC1-powerpc-bootonly.iso) = 1e1786dd3733486e8f69d7e7a61bc4658a25a47d4278df8be9a917dde3d642b3 SHA256 (FreeBSD-10.1-RC1-powerpc-bootonly.iso.xz) = 3e33508d5ca8bcdfeff337ea9926bd6df4e4b127b190a644875acfb16af16d00 SHA256 (FreeBSD-10.1-RC1-powerpc-disc1.iso) = 10fd31c20fe946fac07f595acdee85ba9e37c9cf94c06c7f59f70cadc79fb2f6 SHA256 (FreeBSD-10.1-RC1-powerpc-disc1.iso.xz) = 25433ce14a0ca8e14b0f46d43ea1a702e8c9275acac33eb8203906b75f864124 SHA256 (FreeBSD-10.1-RC1-powerpc-memstick.img) = 0fc4953714413d2afddf6a99c93caff9ba7d17e9a1ed8505c7748ccdf8ca1f68 SHA256 (FreeBSD-10.1-RC1-powerpc-memstick.img.xz) = 7093e321ed22396e9051e971780a45dae38c4b1aad01635865321f591f8087f4 SHA256 (FreeBSD-10.1-RC1-powerpc-mini-memstick.img) = daa0fd2a3dc65dbf397982bef2a05dcf4cf9e84855042de9772c6a7ec429faf7 SHA256 (FreeBSD-10.1-RC1-powerpc-mini-memstick.img.xz) = b58dec5803eeec12453627f4834b37161fffd07677b4ca29c32981b7d34baa89 MD5 (FreeBSD-10.1-RC1-powerpc-bootonly.iso) = 34e46cb239a12d23cdf33a256a1129f2 MD5 (FreeBSD-10.1-RC1-powerpc-bootonly.iso.xz) = 5142053b6e142479ab1f9a8171cb562f MD5 (FreeBSD-10.1-RC1-powerpc-disc1.iso) = 6068393764c9187567a29c982f3170b2 MD5 (FreeBSD-10.1-RC1-powerpc-disc1.iso.xz) = 9bc027f4844f4b81172463f110bee62c MD5 (FreeBSD-10.1-RC1-powerpc-memstick.img) = 94e8fb911bd1e518aaeb5a7aeeff1590 MD5 (FreeBSD-10.1-RC1-powerpc-memstick.img.xz) = ba5073172bd89424b69e8f35b4291beb MD5 (FreeBSD-10.1-RC1-powerpc-mini-memstick.img) = 60b33d70f8140c6c27bb2d0940b51359 MD5 (FreeBSD-10.1-RC1-powerpc-mini-memstick.img.xz) = 52e59a5d8ce84d3a41e3bf12d3369cd8 o 10.1-RC1 powerpc64 GENERIC64: SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-bootonly.iso) = 29ab39b0314f82a6047a95b46ea27422cd28b6f56b274c088f7ebfdb1b780d9b SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-bootonly.iso.xz) = 5c68b307f7b007f4e4c932997b71350fb9836647fe7e8e93a572d8ef1efefaad SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-disc1.iso) = 49586a342a41c6694e6f891f61b3901e0aea5e1c516609a5e9a0782a7d1f52de SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-disc1.iso.xz) = 2d62cec427ebdb44dd46bd162a94e34175377bd48bb8012a940da2461ed5e3cb SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-memstick.img) = 1acd0f035c9314211606b56565d7806923e128d8df018ba55a5ce377c6eb7dbc SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-memstick.img.xz) = 089e3c541ac97d4f948b3bcb8e706aedb54dde07f91e4a02db0f9326e59b82ba SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-mini-memstick.img) = 13846c3b8d07d2c72443e6bdc84facb6afc77bf7f20bee7738bfb26c5394f1e6 SHA256 (FreeBSD-10.1-RC1-powerpc-powerpc64-mini-memstick.img.xz) = e613d64b85dd07f6773adff779825d7b3eb08c4b6000e2676b077f8624c292fc MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-bootonly.iso) = ca61b198ed5fe1170f17e94c072785fb MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-bootonly.iso.xz) = 9c4e9e44afac2b049b6cdc3ba9f3b3f2 MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-disc1.iso) = d0696be2ccc47075214698ca47318874 MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-disc1.iso.xz) = 640967e8d5ee583ee84cf90eeece4f2e MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-memstick.img) = b7df8e38962aaec5dbbab99d9494ec0a MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-memstick.img.xz) = 9a74ae8f85339656db55e8b259f4b508 MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-mini-memstick.img) = 578e3f8917dbdebe31f5d795ee791fe8 MD5 (FreeBSD-10.1-RC1-powerpc-powerpc64-mini-memstick.img.xz) = b537ef455b857f5d79281ef82ffcfe22 o 10.1-RC1 sparc64 GENERIC: SHA256 (FreeBSD-10.1-RC1-sparc64-bootonly.iso) = 0303bd3a639857d36a172ec6aa24fb262928b122d3b684076d182318dd267f7b SHA256 (FreeBSD-10.1-RC1-sparc64-bootonly.iso.xz) = 25ae45d13822d78e62e8d8894076e413562c33b708b88d7daff90640f89a5890 SHA256 (FreeBSD-10.1-RC1-sparc64-disc1.iso) = c5aca888ff3976828680702831527ac097ccdfecdd3c3973205ff73167c2b16a SHA256 (FreeBSD-10.1-RC1-sparc64-disc1.iso.xz) = fbd8e84c023d60104379e9606b499b6c5580d1967089fe41f3757068d5504aa1 MD5 (FreeBSD-10.1-RC1-sparc64-bootonly.iso) = 1592754606077dc737c853cdf77a72fb MD5 (FreeBSD-10.1-RC1-sparc64-bootonly.iso.xz) = c56499efb07bb81f87a017619a71e619 MD5 (FreeBSD-10.1-RC1-sparc64-disc1.iso) = c367d7588ab539c94b2ae65e4a24f5bb MD5 (FreeBSD-10.1-RC1-sparc64-disc1.iso.xz) = 5e17b993399cbe0213c74e19ae7bae22 o 10.1-RC1 armv6 BEAGLEBONE: SHA256 (FreeBSD-10.1-RC1-arm-armv6-BEAGLEBONE.img.bz2) = 3ba36b7cd82bb70fb8a923bf8c8e1412bb655bf9449888e548e9617fd91532f6 MD5 (FreeBSD-10.1-RC1-arm-armv6-BEAGLEBONE.img.bz2) = 586631be5a4bfd9d04b135318a6c5d13 o 10.1-RC1 armv6 RPI-B: SHA256 (FreeBSD-10.1-RC1-arm-armv6-RPI-B.img.bz2) = 39f94bca5a252034ce01e4044aa4e6150fae59dff31e3aed9faeddba1799ee86 MD5 (FreeBSD-10.1-RC1-arm-armv6-RPI-B.img.bz2) = 672aa1b356ede1d9e6f07f9cf7d4290d o 10.1-RC1 armv6 PANDABOARD: SHA256 (FreeBSD-10.1-RC1-arm-armv6-PANDABOARD.img.bz2) = ac27999b27c4fb7622e5e71275daf9ae7052b056dada256abc535221aa13c027 MD5 (FreeBSD-10.1-RC1-arm-armv6-PANDABOARD.img.bz2) = 43e2f4508ae30ae7dfcf5bd6e8082d71 o 10.1-RC1 armv6 ZEDBOARD: SHA256 (FreeBSD-10.1-RC1-arm-armv6-ZEDBOARD.img.bz2) = b15d353053324a194326725f66d19c3d290985baafc548ce1891a971c2144183 MD5 (FreeBSD-10.1-RC1-arm-armv6-ZEDBOARD.img.bz2) = e82b8265728bd11f72176dba225598a3 == VM IMAGE CHECKSUMS == o 10.1-RC1 amd64: SHA256 (FreeBSD-10.1-RC1-amd64.qcow2.xz) = 8ea0d81112a75d5c4d4af51ec7ba9bf5a008006eded524d1699e6c8e6f4e6751 SHA256 (FreeBSD-10.1-RC1-amd64.raw.xz) = a10e8004011193c33b3cc79d80c8a4c301ba0828930b4f341a27373ca1e4511c SHA256 (FreeBSD-10.1-RC1-amd64.vhd.xz) = f512502858cbfad678211a51bfa852a4ee6ca2711936df9296b1222152448be8 SHA256 (FreeBSD-10.1-RC1-amd64.vmdk.xz) = b77f94f17f59ae6db96b45dd17affa3f35d7b8a9374caab27a915611205b2626 MD5 (FreeBSD-10.1-RC1-amd64.qcow2.xz) = 7310e1511144dd77f215eecd04409bf2 MD5 (FreeBSD-10.1-RC1-amd64.raw.xz) = 0bcdf88b14c344822be7a21c9d5a17a0 MD5 (FreeBSD-10.1-RC1-amd64.vhd.xz) = 23d81fdac993a67ef9c19fd5a4d3fb5d MD5 (FreeBSD-10.1-RC1-amd64.vmdk.xz) = e8114d0fa97c60605c112bc160b3329b o 10.1-RC1 i386: SHA256 (FreeBSD-10.1-RC1-i386.qcow2.xz) = 4f645fac9c9527cedaa100a25de241eeb11286c98fce2cde1207c989385248d9 SHA256 (FreeBSD-10.1-RC1-i386.raw.xz) = 4c9cb5f96ea365259aeb594d818710a1d48e3657e21ccec760e09c5e651cd106 SHA256 (FreeBSD-10.1-RC1-i386.vhd.xz) = 2433c477fdbbe9539b1e1202e2c0b7c4eb23d0cba6d06040897dee6ac97500ba SHA256 (FreeBSD-10.1-RC1-i386.vmdk.xz) = 390a7f9f7b04b73ad7adc1149c7a3c308c3994561e7d90153b5b2279c11ef39c MD5 (FreeBSD-10.1-RC1-i386.qcow2.xz) = f17404b10f8f6808b043999264e655ed MD5 (FreeBSD-10.1-RC1-i386.raw.xz) = abb0c06cab05988d853bbfdba29d71a6 MD5 (FreeBSD-10.1-RC1-i386.vhd.xz) = 834bb33663e5673df3da1b4858a0d6cf MD5 (FreeBSD-10.1-RC1-i386.vmdk.xz) = 8b735084edb779d731a3030d6c35bd55 Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUMJ+/AAoJEAMUWKVHj+KTcxoP/Ay7ic5d+W85ouvze5vsdhp5 f0HqYAu7wWIPi/v1KNh9WYhkgXYk6T9ZJ6BOV0ao2bouQJeDHeaA7qs2RgDI3SsV t6zqYDYk+Ix+RCp7yJT26yuR5sHtnY2V8optTMRjS2rm7S9JZOwrItkxSXTzONta CTjU79NPSdpBsvLJCm8dmtkCv76oizXSbD8/Zykc4SDDX/RdJgYCEOpOpIxMZdHq JFt4V2r7sIZHwZfsxmUtkfVdsfjD4TPbc4NSC+SHBAnI9cK1EiwpmaVhZcxVuv8C SOd7Pa7M18S7WtKhIxebVnAEuPsvh83XQSdbe9f54CCzT0HNmk3ftvWsABKDR0m9 gMSJUbIe4spc/ABEDBwLwow02XLa4MFHZhqKrI3jegzWj5i2hMDKNBRNmV+uL9rJ XnPJpuZG86AA3g26zr+4WMTkDsVSEROnF5jdW/umvVC72F5S1vAGB0LMBWWFvldO h6SSYGdHe+AdBRai9Xlu3jbs+2oLgDhndLckbjYXteKZTtE9NDfh/uMzySlTjVek TlcFRNEnTAaggGUd3minGBc6z6FLLFcULE9q2DBiYamgfxsjvROyExyDbLTY9lt3 G15ITpo9Cx6T50nV8oRsOhzcKCW6zbtqu/BCQMiFV8XAaiH4Cz4ofCRHwOzTaNsj vA1rnkV5vXKmJuincFaW =rb+f -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 04:15:16 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABF5CA42; Sun, 5 Oct 2014 04:15:16 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 5056FCA4; Sun, 5 Oct 2014 04:15:15 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id s954FElJ029632; Sun, 5 Oct 2014 13:15:14 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili11) with ESMTP id s954FDR01421; Sun, 5 Oct 2014 13:15:13 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi15) id s954FDCZ024723; Sun, 5 Oct 2014 13:15:13 +0900 Received: from localhost by lomi15.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s954FDZa024711; Sun, 5 Oct 2014 13:15:13 +0900 Date: Sun, 05 Oct 2014 13:15:12 +0900 (JST) Message-Id: <20141005.131512.606074419488263735.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno In-Reply-To: <20141004155803.GQ26076@kib.kiev.ua> References: <20141004092030.GP26076@kib.kiev.ua> <20141004.205335.1782700760623869892.okuno.kohji@jp.panasonic.com> <20141004155803.GQ26076@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 04:15:16 -0000 Hi, > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote: >> Hi Konstantin, >> >> Thank you for your prompt response. >> I will test and report from next monday. >> >> >> In addtion, I have one question. >> >> In current and 10-stable, is vm_map_delete() called by kva_free()? >> > No, kva_free() only releases the vmem backing, leaving the page >> > tables intact. This is why I only did the stable/9 patch. >> >> Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? >> Could you please explain me? > They are not freed. The removal of the vmem which covers the address > space managed by corresponding ptes, allows the reuse of both KVA region > and corresponding PTEs in the tables. The only concern with the resident > page tables is to avoid two kva_alloc() to step over each other, and > this is ensured by vmem. I agree that normal pages are reusable. But, since the pages mapped by pmap_mapdev() are concerned with the physicall address of device (For example: video memory), these PTEs aren't reusable, I think. So, should we free these PTEs by pmap_unmapdev()? Best regards, Kohji Okuno From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 08:57:59 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15D6F3DA; Sun, 5 Oct 2014 08:57:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C83E86A; Sun, 5 Oct 2014 08:57:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s958vrt8068472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Oct 2014 11:57:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s958vrt8068472 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s958vrON068471; Sun, 5 Oct 2014 11:57:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 5 Oct 2014 11:57:53 +0300 From: Konstantin Belousov To: stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: About pmap_mapdev() & pmap_unmapdev() Message-ID: <20141005085753.GX26076@kib.kiev.ua> References: <20141004092030.GP26076@kib.kiev.ua> <20141004.205335.1782700760623869892.okuno.kohji@jp.panasonic.com> <20141004155803.GQ26076@kib.kiev.ua> <20141005.131512.606074419488263735.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141005.131512.606074419488263735.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 08:57:59 -0000 On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote: > Hi, > > > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote: > >> Hi Konstantin, > >> > >> Thank you for your prompt response. > >> I will test and report from next monday. > >> > >> >> In addtion, I have one question. > >> >> In current and 10-stable, is vm_map_delete() called by kva_free()? > >> > No, kva_free() only releases the vmem backing, leaving the page > >> > tables intact. This is why I only did the stable/9 patch. > >> > >> Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? > >> Could you please explain me? > > They are not freed. The removal of the vmem which covers the address > > space managed by corresponding ptes, allows the reuse of both KVA region > > and corresponding PTEs in the tables. The only concern with the resident > > page tables is to avoid two kva_alloc() to step over each other, and > > this is ensured by vmem. > > I agree that normal pages are reusable. But, since the pages mapped by > pmap_mapdev() are concerned with the physicall address of device (For > example: video memory), these PTEs aren't reusable, I think. > So, should we free these PTEs by pmap_unmapdev()? There is no hold on any physical pages which were referenced by the ptes. The only thing which is left out are the records in the page tables which map the KVA to said device memory. It is harmless. When the KVA is reused, the ptes in page tables are overwritten. It might be argued that clearing PTEs, or at least removing the PG_V bit catches erronous unintended accesses to the freed range, but by the cost of the overhead of re-polluting the caches. And since clearing is not effective without doing TLB flush, which requires broadcast IPI, it is more trouble than advantage. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 09:34:37 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71461F6D for ; Sun, 5 Oct 2014 09:34:37 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08CB8C75 for ; Sun, 5 Oct 2014 09:34:36 +0000 (UTC) Received: from walrus.pepperland ([81.217.76.60]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOfQw-1XXx3b1FOI-0063Hn; Sun, 05 Oct 2014 11:34:29 +0200 Message-ID: <543110A4.7040505@gmx.net> Date: Sun, 05 Oct 2014 11:34:28 +0200 From: Stefan Ehmann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Mark Felder , freebsd-stable@freebsd.org Subject: Re: xzgrep: incomplete results on larger files References: <541DE9FC.2090003@gmx.net> <1412000043.1250852.172976197.0B46058D@webmail.messagingengine.com> In-Reply-To: <1412000043.1250852.172976197.0B46058D@webmail.messagingengine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:T2g+e9HcGq0BrAyR/92/0c1ncli0d9jT1jVRsB8crLpq61FB7QP oQdeVUHPacJbWu0WXkF2Ozp0UllOdFDlP+dLYSnOQHoqjKo3ZtRe50aNGvETZgWX2XeXk0A OTO9Qwe7tBmmz6Hi3T+9h42zDhRDdCXwPim+C45MhBMpbuf2vcJx98w1BL3iH9BZwdumdzD AfbjJAKljhfWg5nrP58yw== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 09:34:37 -0000 On 29.09.2014 16:14, Mark Felder wrote: > > > On Sat, Sep 20, 2014, at 15:56, Stefan Ehmann wrote: >> I observed the following behavior on 10.1-BETA1 r271683M (amd64): >> >> xzgrep doesn't search the complete file: >> $ seq 10000 | xz > seq.xz >> $ xzgrep -c . seq.xz >> 6775 >> >> Using regular grep works as expected: >> $ xzcat seq.xz | grep -c . >> 10000 >> >> Processing seems to stop after 32KB (uncompressed). >> > > Wow, this is bizarre... Compression with xz is getting more and more > popular. This may have bit me a few times and I didn't even know it! > > I'll see what I can to do bring this to someone's attention. Any progress on this issue? Would have been nice if 10.1 included the patch and had a working xzgrep. But it's probably already a bit late for that. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 11:23:55 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82E64D18; Sun, 5 Oct 2014 11:23:55 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0B908A89; Sun, 5 Oct 2014 11:23:54 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id s95BNlAB018986; Sun, 5 Oct 2014 20:23:47 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili11) with ESMTP id s95BNlR10517; Sun, 5 Oct 2014 20:23:47 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi14) id s95BNlpQ029678; Sun, 5 Oct 2014 20:23:47 +0900 Received: from localhost by lomi14.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s95BNlp4029658; Sun, 5 Oct 2014 20:23:47 +0900 Date: Sun, 05 Oct 2014 20:23:47 +0900 (JST) Message-Id: <20141005.202347.1457045051130679424.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno In-Reply-To: <20141005085753.GX26076@kib.kiev.ua> References: <20141004155803.GQ26076@kib.kiev.ua> <20141005.131512.606074419488263735.okuno.kohji@jp.panasonic.com> <20141005085753.GX26076@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 11:23:55 -0000 Hi Konstantin, Thank you very much for your detailed explanatin. I understood the policy of vmem. Many thanks, Kohji Okuno > On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote: >> Hi, >> >> > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote: >> >> Hi Konstantin, >> >> >> >> Thank you for your prompt response. >> >> I will test and report from next monday. >> >> >> >> >> In addtion, I have one question. >> >> >> In current and 10-stable, is vm_map_delete() called by kva_free()? >> >> > No, kva_free() only releases the vmem backing, leaving the page >> >> > tables intact. This is why I only did the stable/9 patch. >> >> >> >> Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? >> >> Could you please explain me? >> > They are not freed. The removal of the vmem which covers the address >> > space managed by corresponding ptes, allows the reuse of both KVA region >> > and corresponding PTEs in the tables. The only concern with the resident >> > page tables is to avoid two kva_alloc() to step over each other, and >> > this is ensured by vmem. >> >> I agree that normal pages are reusable. But, since the pages mapped by >> pmap_mapdev() are concerned with the physicall address of device (For >> example: video memory), these PTEs aren't reusable, I think. >> So, should we free these PTEs by pmap_unmapdev()? > There is no hold on any physical pages which were referenced by the ptes. > The only thing which is left out are the records in the page tables > which map the KVA to said device memory. It is harmless. > > When the KVA is reused, the ptes in page tables are overwritten. > > It might be argued that clearing PTEs, or at least removing the PG_V > bit catches erronous unintended accesses to the freed range, but by the > cost of the overhead of re-polluting the caches. And since clearing is > not effective without doing TLB flush, which requires broadcast IPI, > it is more trouble than advantage. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 12:34:16 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4CF69FC; Sun, 5 Oct 2014 12:34:16 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D615129; Sun, 5 Oct 2014 12:34:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=jAcTV5aO3UurYVUkMwF3k61Xnhst4RsFxb7XySD7YdU=; b=dU0v3UTJVX/+wNCrIQGRi2uNaKsOewliTe5HZSFylCL/N6EhWUU8JgowBnX9Z17k9mbMq2dsv8qIF3trS/FEkwYrvoJs8f7EahW5uFGWXCicvIyJhCkORm3WjfWadNmAHyJFDUSVYqLDcEQ58nm3C53pQwCX2cc7M9ClqAp6T9s=; Received: from [182.1.193.13] (port=14242 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xal0w-004KbJ-4P; Sun, 05 Oct 2014 06:34:14 -0600 Date: Sun, 5 Oct 2014 20:34:01 +0800 From: Erich Dollansky To: Glen Barber Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails Message-ID: <20141005203401.440afc31@X220.alogt.com> In-Reply-To: <20141005013247.GH1171@hub.FreeBSD.org> References: <20141005013247.GH1171@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Release Engineering Team , freebsd-jail@freebsd.org, freebsd-stable@FreeBSD.org, freebsd-net@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 12:34:16 -0000 Hi, On Sat, 4 Oct 2014 21:32:47 -0400 Glen Barber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > The first RC build of the 10.1-RELEASE release cycle is now available I installed this shortly after your e-mail came. The result was the same as with BETA3. If you remember, I have had the problem that the network inside jails stopped working after I installed BETA3. The upgrade to RC1 did not change anything. I took now the time to investigate a bit. The result is simple. All works as expected until lagg becomes enabled. If I remember right, BETA1 was my last working version. I have an em and an iwn interface in the machine. I can use both of them without any problems. As I can reproduce this problem 100%, it might be a good idea if I help you to find the source of the problem. My problem would be: how. If somebody could tell me where to start looking for the error, we might find it soon. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 13:42:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39D1A636 for ; Sun, 5 Oct 2014 13:42:02 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F92F933 for ; Sun, 5 Oct 2014 13:42:00 +0000 (UTC) Received: (qmail 7755 invoked from network); 5 Oct 2014 13:41:59 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Oct 2014 13:41:59 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sun, 05 Oct 2014 09:41:59 -0400 (EDT) Received: (qmail 14821 invoked from network); 5 Oct 2014 13:41:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Oct 2014 13:41:58 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 043321C4056; Sun, 5 Oct 2014 06:41:55 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) [NVIDIA vs. powerpc64 for vt console switching; Radeon X1950 not working for powerpc64 Xorg generally] From: Mark Millard In-Reply-To: <8BAFEFD4-2FC3-4566-9CCE-F039594BDE7F@dsl-only.net> Date: Sun, 5 Oct 2014 06:41:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83AFBF78-CBE1-4651-B3D6-A83168956D93@dsl-only.net> References: <2C74DFEC-D943-4237-8988-B9657240EC21@dsl-only.net> <82C08920-CF4B-441F-8162-9F6D2625E927@dsl-only.net> <8BAFEFD4-2FC3-4566-9CCE-F039594BDE7F@dsl-only.net> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: dumbbell@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 13:42:02 -0000 [The first try was big enough to require the moderator. So I cancelled = and am trying again as plain-text only.] =3D=3D=3D Mark Millard markmi at dsl-only.net On Oct 5, 2014, at 6:20 AM, Mark Millard wrote: [This is a reply to Jean-S=E9bastien P=E9dron's Sat Oct 4 15:31:47 UTC = 2014 reply to my notes about how things are on PowerMac G5's and I quote = from his material without further attribution.] > Could you please connect from a remote computer to your Power Mac G5 = and > run the following command as root? > truss -fd -o truss-$(sysctl -n kern.vty).txt /usr/local/bin/Xorg >=20 > Wait a couple seconds and hit Control-C to stop the X server. >=20 > Please do this for both vt(4) and syscons. Then post both truss-vt.txt > and truss-sc.txt files to this list. This will help us to determine if > vt(4) lacks an ioctl, compared to syscons. Sure (and waiting longer per a later note). But I had started a = different type of experiment (with KTR enabled but modified) and I = wanted to revert to the simpler context first. It will be 10.1-RC1 as = well (I already updated). (I was not expecting any tier 2 effort and = kept on with my personal investigations and progressed.) I ran the = commands on the console display and used remote only to pkill Xorg = during the nearly-black-on-block vt issue. The activity spanned below includes a Control/Option-Fn in each case = just in case that gave any extra information. vt did have the = nearly-black-on-black issue, sc did not. root@FBSDG5M1:~ # ls -Fpal truss-*.txt -rw-r--r-- 1 root wheel 964591 Oct 5 04:14 truss-sc.txt -rw-r--r-- 1 root wheel 964188 Oct 5 04:29 truss-vt.txt Each file is rather large. So here is an extraction that will hopefully = have enough context around each ioctl but that is vastly smaller. (There = are initial-replies to other request after this extraction from the two = files.) root@FBSDG5M1:~ # grep -B 10 -A 10 -i ioctl truss-*.txt truss-sc.txt- 1150: 0.098803283 clock_gettime(4,{495.112432416 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.098899556 write(0,"[ 495.112] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.098999878 write(0,"\tX.Org Video Driver: = 12.1\n",26) =3D 26 (0x1a) truss-sc.txt- 1150: 0.099074489 clock_gettime(4,{495.112703712 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.099169382 write(0,"[ 495.112] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.099262534 write(0,"\tX.Org XInput driver : = 16.0\n",28) =3D 28 (0x1c) truss-sc.txt- 1150: 0.099338645 clock_gettime(4,{495.112968228 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.099433267 write(0,"[ 495.112] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.099527110 write(0,"\tX.Org Server Extension : = 6.0\n",30) =3D 30 (0x1e) truss-sc.txt- 1150: 0.133257555 open("(null)",O_RDWR|O_CLOEXEC,00) =3D 6 = (0x6) truss-sc.txt: 1150: 0.133399128 ioctl(6,PCIOCGETCONF,0xffffa590) =3D 0 = (0x0) truss-sc.txt- 1150: 0.133515741 clock_gettime(4,{495.147142024 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.133626804 write(0,"[ 495.147] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.133733306 write(0,"(WW) xf86EnableIO -1\n",21) =3D = 21 (0x15) truss-sc.txt: 1150: 0.133872659 ioctl(6,PCIOCREAD,0xffffd414) =3D 0 = (0x0) truss-sc.txt: 1150: 0.133961581 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-sc.txt: 1150: 0.134047473 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-sc.txt: 1150: 0.134130965 ioctl(6,PCIOCGETBAR,0xffffd608) ERR#22 = 'Invalid argument' truss-sc.txt: 1150: 0.134219347 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-sc.txt: 1150: 0.134303409 ioctl(6,PCIOCGETBAR,0xffffd608) ERR#22 = 'Invalid argument' truss-sc.txt: 1150: 0.134390201 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-sc.txt: 1150: 0.134487733 ioctl(6,PCIOCREAD,0xffffd564) =3D 0 = (0x0) truss-sc.txt- 1150: 0.134574585 clock_gettime(4,{495.148200927 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.134678987 write(0,"[ 495.148] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.134786480 write(0,"(--) PCI: (0:10:0:0) = 10de:0092:1"...,41) =3D 41 (0x29) truss-sc.txt- 1150: 0.134886562 write(0,"rev 161",7) =3D 7 = (0x7) truss-sc.txt- 1150: 0.134983284 write(0,", Mem @ ",8) =3D 8 (0x8) truss-sc.txt- 1150: 0.135088586 write(0,"0xa1000000/16777216",19) =3D 19 = (0x13) truss-sc.txt- 1150: 0.135182549 write(0,", ",2) =3D 2 (0x2) truss-sc.txt- 1150: 0.135287311 write(0,"0x90000000/268435456",20) =3D = 20 (0x14) truss-sc.txt- 1150: 0.135379863 write(0,", ",2) =3D 2 (0x2) truss-sc.txt- 1150: 0.135482225 write(0,"0xa0000000/16777216",19) =3D 19 = (0x13) -- truss-sc.txt- 1150: 0.308280277 clock_gettime(4,{495.321909289 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.308378409 write(0,"[ 495.321] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.308477921 write(0,"(II) VESA: driver for VESA = chips"...,36) =3D 36 (0x24) truss-sc.txt- 1150: 0.308563993 write(0," ",1) =3D 1 (0x1) truss-sc.txt- 1150: 0.308650905 write(0,"vesa",4) =3D 4 = (0x4) truss-sc.txt- 1150: 0.308738387 write(0,"\n",1) =3D 1 (0x1) truss-sc.txt- 1150: 0.308808858 geteuid() =3D 0 = (0x0) truss-sc.txt- 1150: 0.308871350 getpid() =3D = 1150 (0x47e) truss-sc.txt- 1150: 0.308980612 = setpgid(0x0,0x47e,0x1,0x50cda5f0,0x0,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 0.309133106 open("/dev/tty",O_RDWR,00) =3D 7 = (0x7) truss-sc.txt: 1150: 0.309242488 ioctl(7,TIOCNOTTY,0x0) ERR#25 = 'Inappropriate ioctl for device' truss-sc.txt- 1150: 0.309326550 close(7) =3D 0 = (0x0) truss-sc.txt- 1150: 0.309419102 open("/dev/ttyv0",O_RDWR|O_NONBLOCK,00) = =3D 7 (0x7) truss-sc.txt: 1150: 0.309517714 ioctl(7,0xc0185671 { IORW 0x56('V'), = 113, 24 },0xffffd230) ERR#25 'Inappropriate ioctl for device' truss-sc.txt- 1150: 0.309592716 close(7) =3D 0 = (0x0) truss-sc.txt- 1150: 0.309683558 open("/dev/ttyv0",O_RDWR|O_NONBLOCK,00) = =3D 7 (0x7) truss-sc.txt: 1150: 0.309762070 ioctl(7,VT_GETMODE,0xffffd228) =3D 0 = (0x0) truss-sc.txt: 1150: 0.309840012 ioctl(7,CONS_GETVERS,0xffffd240) =3D 0 = (0x0) truss-sc.txt: 1150: 0.309919093 ioctl(7,VT_GETACTIVE,0x102f1608) =3D 0 = (0x0) truss-sc.txt: 1150: 0.309997275 ioctl(7,VT_OPENQRY,0x102f1254) =3D 0 = (0x0) truss-sc.txt- 1150: 0.310072577 close(7) =3D 0 = (0x0) truss-sc.txt- 1150: 0.310179469 open("/dev/ttyv8",O_RDWR|O_NONBLOCK,00) = =3D 7 (0x7) truss-sc.txt: 1150: 0.310257111 ioctl(7,VT_GETMODE,0xffffd228) =3D 0 = (0x0) truss-sc.txt- 1150: 0.310332293 clock_gettime(4,{495.323961035 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.310431775 write(0,"[ 495.323] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.310531227 write(0,"(--) Using syscons driver with = X"...,40) =3D 40 (0x28) truss-sc.txt- 1150: 0.310628969 write(0," (version = 8595229351.252)\n",26) =3D 26 (0x1a) truss-sc.txt- 1150: 0.310702381 clock_gettime(4,{495.324331333 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.310795503 write(0,"[ 495.324] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.310896845 write(0,"(--) using VT number 9\n\n",24) = =3D 24 (0x18) truss-sc.txt- 1150: 0.310976677 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd2e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-sc.txt- 1150: 0.311063979 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd3e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-sc.txt- 1150: 0.311140031 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd4e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-sc.txt- 1150: 0.311216172 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd5e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-sc.txt- 1150: 0.311292044 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd6e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-sc.txt: 1150: 0.316820448 ioctl(7,VT_ACTIVATE,0x9) =3D 0 = (0x0) truss-sc.txt: 1150: 0.316957251 ioctl(7,VT_WAITACTIVE,0x9) =3D 0 = (0x0) truss-sc.txt- 1150: 0.317113914 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEM= T|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGS= TOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALR= M|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 0.317214717 sigaction(SIGUSR1,{ 0x506d05e0 = SA_RESTART|SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) =3D 0 (0x0) truss-sc.txt- 1150: 0.317298869 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt: 1150: 0.317392711 ioctl(7,VT_SETMODE,0xffffd7e8) =3D 0 = (0x0) truss-sc.txt: 1150: 0.317472693 ioctl(7,KDENABIO,0x0) =3D 0 (0x0) truss-sc.txt: 1150: 0.317554144 ioctl(7,KDSETMODE,0x1) =3D 0 (0x0) truss-sc.txt- 1150: 0.317644206 clock_gettime(4,{495.331270129 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.317763909 write(0,"[ 495.331] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.317876982 write(0,"(WW) xf86EnableIO 7\n",20) =3D = 20 (0x14) truss-sc.txt- 1150: 0.318029055 clock_gettime(4,{495.331655187 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.318131807 write(0,"[ 495.331] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.318239540 write(0,"(--) NV: Found NVIDIA GeForce = 78"...,52) =3D 52 (0x34) truss-sc.txt- 1150: 0.318360202 clock_gettime(4,{495.331986425 }) =3D 0 = (0x0) truss-sc.txt- 1150: 0.318470605 write(0,"[ 495.331] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 0.318675959 write(0,"(WW) Falling back to old probe = m"...,47) =3D 47 (0x2f) truss-sc.txt- 1150: 0.318783662 clock_gettime(4,{495.332409314 }) =3D 0 = (0x0) -- truss-sc.txt- 1150: 1.373021921 write(0,"(II) UnloadModule: = "vesa"\n",26) =3D 26 (0x1a) truss-sc.txt- 1150: 1.373103073 clock_gettime(4,{496.386729625 }) =3D 0 = (0x0) truss-sc.txt- 1150: 1.373204235 write(0,"[ 496.386] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 1.373309267 write(0,"(II) Unloading vesa\n",20) =3D = 20 (0x14) truss-sc.txt- 1150: 1.373489391 munmap(0x50fad000,110592) =3D 0 = (0x0) truss-sc.txt- 1150: 1.373583203 clock_gettime(4,{496.387209246 }) =3D 0 = (0x0) truss-sc.txt- 1150: 1.373691356 write(0,"[ 496.387] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 1.373798728 write(0,"(--) Depth 24 pixmap format is = 3"...,38) =3D 38 (0x26) truss-sc.txt- 1150: 1.373946991 open("(null)",O_RDWR|O_CLOEXEC,00) =3D 8 = (0x8) truss-sc.txt- 1150: 1.391350501 = mmap(0x0,268435456,PROT_READ|PROT_WRITE,MAP_SHARED,8,0x0) =3D 1386889216 = (0x52aa4000) truss-sc.txt: 1150: 1.391450434 ioctl(8,MEMRANGE_SET,0xffffd4f0) =3D 0 = (0x0) truss-sc.txt- 1150: 1.391540796 close(8) =3D 0 = (0x0) truss-sc.txt- 1150: 1.393266614 clock_gettime(4,{496.406891487 }) =3D 0 = (0x0) truss-sc.txt- 1150: 1.393400207 write(0,"[ 496.406] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 1.393510940 write(0,"(II) NV(0): Using XFree86 = Accele"...,58) =3D 58 (0x3a) truss-sc.txt- 1150: 1.393604272 clock_gettime(4,{496.407230284 }) =3D 0 = (0x0) truss-sc.txt- 1150: 1.393709034 write(0,"[ 496.407] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 1.393812207 write(0,"\tScreen to screen bit = blits\n",28) =3D 28 (0x1c) truss-sc.txt- 1150: 1.393903498 clock_gettime(4,{496.407529481 }) =3D 0 = (0x0) truss-sc.txt- 1150: 1.394008411 write(0,"[ 496.407] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 1.394117073 write(0,"\tSolid filled = rectangles\n",25) =3D 25 (0x19) -- truss-sc.txt- 1150: 2.674729482 write(0," "us"",5) =3D 5 = (0x5) truss-sc.txt- 1150: 2.674819754 write(0,"\n",1) =3D 1 (0x1) truss-sc.txt- 1150: 2.674964208 clock_gettime(4,{497.688593340 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.675061200 write(0,"[ 497.688] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.675161522 write(0,"(**) Option "config_info"",25) = =3D 25 (0x19) truss-sc.txt- 1150: 2.675262984 write(0," = "hal:/org/freedesktop/Hal/devic"...,67) =3D 67 (0x43) truss-sc.txt- 1150: 2.675351786 write(0,"\n",1) =3D 1 (0x1) truss-sc.txt- 1150: 2.675428888 clock_gettime(4,{497.689057811 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.675524710 write(0,"[ 497.689] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.675626562 write(0,"(II) XINPUT: Adding extended = inp"...,95) =3D 95 (0x5f) truss-sc.txt: 1150: 2.675751995 ioctl(7,TIOCGETA,0x636bb490) =3D 0 = (0x0) truss-sc.txt: 1150: 2.676423860 ioctl(7,KDSETLED,0x0) =3D 0 (0x0) truss-sc.txt: 1150: 2.676521993 ioctl(7,KDGETLED,0xffffcb60) =3D 0 = (0x0) truss-sc.txt: 1150: 2.676602154 ioctl(7,KDSETLED,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 2.676682946 clock_gettime(4,{497.690311989 }) =3D 0 = (0x0) truss-sc.txt: 1150: 2.676803819 ioctl(7,TIOCSETA,0xffffcbe0) =3D 0 = (0x0) truss-sc.txt: 1150: 2.676884941 ioctl(7,KDSKBMODE,0x0) =3D 0 (0x0) truss-sc.txt: 1150: 2.677133316 ioctl(7,KDSKBMODE,0x0) =3D 0 (0x0) truss-sc.txt: 1150: 2.677231329 ioctl(7,TIOCFLUSH,0xffffcadc) =3D 0 = (0x0) truss-sc.txt: 1150: 2.677315150 ioctl(7,KDGETLED,0xffffcb50) =3D 0 = (0x0) truss-sc.txt: 1150: 2.677417153 ioctl(7,KDSETLED,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 2.677577836 clock_gettime(4,{497.691205829 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.677948284 = sendmsg(0x8,0xffffffffffffc940,0x20000,0xc8,0x5154a390,0x0) =3D 221 = (0xdd) truss-sc.txt- 1150: 2.678040927 clock_gettime(4,{497.691669429 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.678493187 poll({8/POLLIN},1,25000) =3D 1 = (0x1) truss-sc.txt- 1150: 2.678590059 = recvmsg(0x8,0xffffffffffffc9e0,0x40000,0x6368ff40,0xffffffffffffcaf8,0x514= 4dd48) =3D 74 (0x4a) truss-sc.txt- 1150: 2.678724132 = recvmsg(0x8,0xffffffffffffc9e0,0x40000,0x6368ff40,0xffffffffffffcaf8,0x514= 4dd48) ERR#35 'Resource temporarily unavailable' truss-sc.txt- 1150: 2.678944517 = sendmsg(0x8,0xffffffffffffc940,0x20000,0xc8,0x5154a2d0,0x0) =3D 217 = (0xd9) truss-sc.txt- 1150: 2.679028159 clock_gettime(4,{497.692656481 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.679470669 poll({8/POLLIN},1,25000) =3D 1 = (0x1) truss-sc.txt- 1150: 2.679550290 = recvmsg(0x8,0xffffffffffffc9e0,0x40000,0x6368ff40,0xffffffffffffcaf8,0x514= 4dd48) =3D 82 (0x52) -- truss-sc.txt- 1150: 2.705855000 write(0,"(**) Option "Device"",20) =3D = 20 (0x14) truss-sc.txt- 1150: 2.705970172 write(0," "/dev/sysmouse"",16) =3D 16 = (0x10) truss-sc.txt- 1150: 2.706064524 write(0,"\n",1) =3D 1 (0x1) truss-sc.txt- 1150: 2.706157797 clock_gettime(4,{497.719784409 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.706259409 write(0,"[ 497.719] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.706366631 write(0,"(=3D=3D) Apple Optical USB = Mouse: Pr"...,47) =3D 47 (0x2f) truss-sc.txt- 1150: 2.706485554 clock_gettime(4,{497.720111986 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.706587346 write(0,"[ 497.720] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.706694839 write(0,"(**) Apple Optical USB Mouse: = al"...,57) =3D 57 (0x39) truss-sc.txt- 1150: 2.706837882 = open("/dev/sysmouse",O_RDWR|O_NONBLOCK,00) =3D 9 (0x9) truss-sc.txt: 1150: 2.706964815 ioctl(9,TIOCGETA,0xffffcd6c) =3D 0 = (0x0) truss-sc.txt: 1150: 2.707051906 ioctl(9,TIOCGETA,0xffffce40) =3D 0 = (0x0) truss-sc.txt: 1150: 2.707162639 ioctl(9,TIOCSETA,0xffffce40) =3D 0 = (0x0) truss-sc.txt: 1150: 2.707246281 ioctl(9,TIOCGETA,0xffffcc8c) =3D 0 = (0x0) truss-sc.txt: 1150: 2.707329203 ioctl(9,TIOCGETA,0xffffcd60) =3D 0 = (0x0) truss-sc.txt: 1150: 2.707444225 ioctl(9,TIOCSETA,0xffffcd60) =3D 0 = (0x0) truss-sc.txt- 1150: 2.707549258 fcntl(9,F_GETFL,) =3D 6 = (0x6) truss-sc.txt- 1150: 2.707628429 fcntl(9,F_SETFL,0x2) =3D 0 = (0x0) truss-sc.txt- 1150: 2.707724011 close(9) =3D 0 = (0x0) truss-sc.txt- 1150: 2.707828414 clock_gettime(4,{497.721454636 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.707939266 write(0,"[ 497.721] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.708040849 write(0,"(=3D=3D) Apple Optical USB = Mouse: Em"...,67) =3D 67 (0x43) truss-sc.txt- 1150: 2.708210262 clock_gettime(4,{497.721839335 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.708308845 write(0,"[ 497.721] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.708409947 write(0,"(**) Apple Optical USB Mouse: = ZA"...,60) =3D 60 (0x3c) truss-sc.txt- 1150: 2.708518969 clock_gettime(4,{497.722148192 }) =3D 0 = (0x0) -- truss-sc.txt- 1150: 2.710151156 clock_gettime(4,{497.723780498 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.710246978 write(0,"[ 497.723] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.710347600 write(0,"(**) Apple Optical USB Mouse: = (a"...,61) =3D 61 (0x3d) truss-sc.txt- 1150: 2.710469103 clock_gettime(4,{497.724098476 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.710564535 write(0,"[ 497.724] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.710665277 write(0,"(**) Apple Optical USB Mouse: = (a"...,65) =3D 65 (0x41) truss-sc.txt- 1150: 2.710740669 clock_gettime(4,{497.724370012 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.710835861 write(0,"[ 497.724] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.710937713 write(0,"(**) Apple Optical USB Mouse: = (a"...,64) =3D 64 (0x40) truss-sc.txt- 1150: 2.711065846 = open("/dev/sysmouse",O_RDWR|O_NONBLOCK,00) =3D 9 (0x9) truss-sc.txt: 1150: 2.711145798 ioctl(9,TIOCGETA,0xffffcb8c) =3D 0 = (0x0) truss-sc.txt: 1150: 2.711222270 ioctl(9,TIOCGETA,0xffffcc60) =3D 0 = (0x0) truss-sc.txt: 1150: 2.711299402 ioctl(9,TIOCSETA,0xffffcc60) =3D 0 = (0x0) truss-sc.txt: 1150: 2.711376593 ioctl(9,TIOCGETA,0xffffcaac) =3D 0 = (0x0) truss-sc.txt: 1150: 2.711453335 ioctl(9,TIOCGETA,0xffffcb80) =3D 0 = (0x0) truss-sc.txt: 1150: 2.711563138 ioctl(9,TIOCSETA,0xffffcb80) =3D 0 = (0x0) truss-sc.txt- 1150: 2.711638379 fcntl(9,F_GETFL,) =3D 6 = (0x6) truss-sc.txt- 1150: 2.711711611 fcntl(9,F_SETFL,0x2) =3D 0 = (0x0) truss-sc.txt: 1150: 2.711831014 ioctl(9,MOUSE_SETLEVEL,0xffffcac0) =3D 0 = (0x0) truss-sc.txt: 1150: 2.711913155 ioctl(9,MOUSE_GETHWINFO,0xffffcac4) =3D = 0 (0x0) truss-sc.txt- 1150: 2.711993167 clock_gettime(4,{497.725622480 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.712093039 write(0,"[ 497.725] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.712194232 write(0,"(II) Apple Optical USB Mouse: = Se"...,71) =3D 71 (0x47) truss-sc.txt: 1150: 2.712270373 ioctl(9,MOUSE_GETMODE,0xffffcad8) =3D 0 = (0x0) truss-sc.txt- 1150: 2.712346845 clock_gettime(4,{497.725976188 }) =3D 0 = (0x0) truss-sc.txt- 1150: 2.712441707 write(0,"[ 497.725] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 2.712543020 write(0,"(II) Apple Optical USB Mouse: = Se"...,62) =3D 62 (0x3e) truss-sc.txt: 1150: 2.712680213 ioctl(9,MOUSE_SETMODE,0xffffcaa8) =3D 0 = (0x0) truss-sc.txt: 1150: 2.712767424 ioctl(9,TIOCFLUSH,0xffffcb5c) =3D 0 = (0x0) truss-sc.txt- 1150: 2.712871617 fstat(9,{ mode=3Dcrw------- = ,inode=3D13,size=3D0,blksize=3D4096 }) =3D 0 (0x0) truss-sc.txt- 1150: 2.712960809 = sigprocmask(SIG_BLOCK,SIGIO,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|= SIGVTALRM|SIGWINCH) =3D 0 (0x0) truss-sc.txt- 1150: 2.713059451 fcntl(9,F_GETFL,) =3D 2 = (0x2) truss-sc.txt- 1150: 2.713132113 fcntl(9,F_SETFL,O_ASYNC|0x2) =3D 0 = (0x0) truss-sc.txt- 1150: 2.713206214 getpid() =3D = 1150 (0x47e) truss-sc.txt- 1150: 2.713273356 fcntl(9,F_SETOWN,0x47e) =3D 0 (0x0) truss-sc.txt- 1150: 2.713414029 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEM= T|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGS= TOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALR= M|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN= |SIGTTOU|SIGIO|SIGVTALRM|SIGWINCH) =3D 0 (0x0) truss-sc.txt- 1150: 2.713522962 sigaction(SIGIO,{ 0x506d05e0 SA_SIGINFO = ss_t },{ SIG_DFL SA_RESTART ss_t }) =3D 0 (0x0) truss-sc.txt- 1150: 2.713621694 = sigprocmask(SIG_SETMASK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGV= TALRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 2.713710946 clock_gettime(4,{497.727340258 }) =3D 0 = (0x0) -- truss-sc.txt- 1150: 11.936811668 sigprocmask(SIG_UNBLOCK,SIGIO,0x0) =3D = 0 (0x0) truss-sc.txt- 1150: 11.936925581 clock_gettime(4,{506.950551833 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.608439438 select(256,{1 3 4 7 = 8},0x0,0x0,{590.700000 }) =3D 1 (0x1) truss-sc.txt- 1150: 12.608546120 sigprocmask(SIG_BLOCK,SIGIO,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.608637112 read(7,"<",64) =3D 1 (0x1) truss-sc.txt- 1150: 12.608729604 clock_gettime(4,{507.622356127 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.608824856 sigprocmask(SIG_UNBLOCK,SIGIO,0x0) =3D = 0 (0x0) truss-sc.txt- 1150: 12.608934209 clock_gettime(4,{507.622560671 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.609042001 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.609138243 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt: 1150: 12.609258276 ioctl(7,VT_ACTIVATE,0x2) =3D 0 = (0x0) truss-sc.txt- 1150: 12.609258276 SIGNAL 30 (SIGUSR1) truss-sc.txt- 1150: 12.609383589 sigprocmask(SIG_SETMASK,SIGUSR1,0x0) =3D = 0 (0x0) truss-sc.txt- 1150: 12.609491471 = sigreturn(0xffffffffffffb9b0,0xffffffffffffb9b0,0x4c0,0x50caa7e8,0x130,0xf= fffffffffffc4c0) =3D 0 (0x0) truss-sc.txt- 1150: 12.609578653 clock_gettime(4,{507.623205296 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.609684376 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.609779778 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.609874910 clock_gettime(4,{507.623501432 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.776435639 select(256,{1 3 4 7 = 8},0x0,0x0,{0.659000 }) =3D 1 (0x1) truss-sc.txt- 1150: 12.776530412 sigprocmask(SIG_BLOCK,SIGIO,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.776620654 read(7,"\M-<",64) =3D 1 = (0x1) -- truss-sc.txt- 1150: 12.779171611 clock_gettime(4,{507.792798733 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.779274333 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.779366855 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.779473028 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.779565460 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.779654502 clock_gettime(4,{507.793281624 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.779756774 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.779851426 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.779957898 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.780050601 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt: 1150: 12.780157133 ioctl(7,KDSKBMODE,0x1) =3D 0 (0x0) truss-sc.txt: 1150: 12.780247285 ioctl(7,TIOCSETA,0x636bb490) =3D 0 = (0x0) truss-sc.txt- 1150: 12.780348747 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.780441869 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.780536731 clock_gettime(4,{507.794163674 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.780634954 fcntl(9,F_GETFL,) =3D 66 = (0x42) truss-sc.txt- 1150: 12.780714605 fcntl(9,F_SETFL,0x2) =3D 0 (0x0) truss-sc.txt- 1150: 12.780858069 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEM= T|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGS= TOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALR= M|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.780957131 sigaction(SIGIO,{ SIG_IGN 0x0 ss_t },{ = 0x506d05e0 SA_SIGINFO ss_t }) =3D 0 (0x0) truss-sc.txt- 1150: 12.781045693 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.781162995 close(9) =3D 0 = (0x0) truss-sc.txt- 1150: 12.781263678 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 12.781356650 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 12.781452352 clock_gettime(4,{507.795079504 }) =3D 0 = (0x0) truss-sc.txt- 1150: 12.781545594 sigprocmask(SIG_BLOCK,SIGIO,0x0) =3D 0 = (0x0) truss-sc.txt- 1150: 13.813138283 nanosleep({1.000000000 }) =3D 0 = (0x0) truss-sc.txt: 1150: 14.093091291 ioctl(7,VT_RELDISP,0x1) =3D 0 = (0x0) truss-sc.txt- 1150: 14.093176883 clock_gettime(4,{509.106808236 }) =3D 0 = (0x0) truss-sc.txt- 1150: 14.093282515 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGIO) =3D 0 (0x0) truss-sc.txt- 1150: 14.093369847 sigprocmask(SIG_SETMASK,SIGIO,0x0) =3D = 0 (0x0) truss-sc.txt- 1150: 14.093466870 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGIO) =3D 0 (0x0) truss-sc.txt- 1150: 14.093550601 sigprocmask(SIG_SETMASK,SIGIO,0x0) =3D = 0 (0x0) truss-sc.txt- 1150: 14.093627733 clock_gettime(4,{509.107259536 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.798503651 select(256,{1 3 4 = 8},0x0,0x0,{118.685000 }) ERR#4 'Interrupted system call' truss-sc.txt- 1150: 17.798503651 SIGNAL 15 (SIGTERM) truss-sc.txt- 1150: 17.799020983 = sigprocmask(SIG_SETMASK,SIGTERM|SIGIO,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 17.799121365 = sigreturn(0xffffffffffffc900,0xffffffffffffc900,0x4c0,0x50caa7b8,0x130,0xf= fffffffffffd410) ERR#4 'Interrupted system call' -- truss-sc.txt- 1150: 17.800114627 = madvise(0x5154e000,0x45000,0x5,0x0,0x763,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.800232410 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGIO) =3D 0 (0x0) truss-sc.txt- 1150: 17.800343502 clock_gettime(4,{512.813969484 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.800444634 clock_gettime(4,{512.814070677 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.800535117 clock_gettime(4,{512.814161279 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.800664449 clock_gettime(4,{512.814290552 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.800772782 clock_gettime(4,{512.814399064 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.800875504 clock_gettime(4,{512.814500947 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.801020647 write(0,"[ 512.814] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 17.801131560 write(0,"(II) UnloadModule: = "mouse"\n",27) =3D 27 (0x1b) truss-sc.txt: 1150: 17.801244182 ioctl(7,KDSKBMODE,0x1) =3D 0 (0x0) truss-sc.txt: 1150: 17.801333944 ioctl(7,TIOCSETA,0x636bb490) =3D 0 = (0x0) truss-sc.txt- 1150: 17.801449057 clock_gettime(4,{512.815075669 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.801535309 clock_gettime(4,{512.815162041 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.801637821 write(0,"[ 512.815] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 17.801743064 write(0,"(II) UnloadModule: = "kbd"\n",25) =3D 25 (0x19) truss-sc.txt- 1150: 17.802068451 = madvise(0x6374e000,0xa6000,0x5,0x0,0xc000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.802168323 = madvise(0x63501000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.802284606 = madvise(0x63503000,0x3f000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.802367828 = madvise(0x636bf000,0x2000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.802449969 = madvise(0x636c3000,0x2000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.802533971 = madvise(0x63806000,0x3000,0x5,0x0,0x3f7000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.802708125 sigprocmask(SIG_SETMASK,SIGIO,0x0) =3D = 0 (0x0) truss-sc.txt- 1150: 17.803044193 munmap(0x50fad000,102400) =3D 0 = (0x0) truss-sc.txt- 1150: 17.804530996 munmap(0x62aa4000,7327744) =3D 0 = (0x0) truss-sc.txt- 1150: 17.804700590 munmap(0x631a1000,360448) =3D 0 = (0x0) truss-sc.txt- 1150: 17.805119819 munmap(0x631f9000,1519616) =3D 0 = (0x0) truss-sc.txt- 1150: 17.805398465 open("(null)",O_RDWR|O_CLOEXEC,00) =3D = 9 (0x9) truss-sc.txt: 1150: 17.805491797 ioctl(9,MEMRANGE_SET,0xffffd348) =3D 0 = (0x0) truss-sc.txt- 1150: 17.805581589 close(9) =3D 0 = (0x0) truss-sc.txt- 1150: 17.805701232 munmap(0x52aa4000,268435456) =3D 0 = (0x0) truss-sc.txt- 1150: 17.807361409 = madvise(0x51523000,0x14000,0x5,0x0,0x10000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.807446161 = madvise(0x5154b000,0x3000,0x5,0x0,0x10000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.807555814 = madvise(0x51476000,0x45000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.807639275 = madvise(0x51597000,0x3000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.807720907 = madvise(0x515a4000,0x1000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.807807879 = madvise(0x515a6000,0xd000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.807893201 = madvise(0x515b4000,0x5000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.807978823 = madvise(0x515dc000,0xc000,0x5,0x0,0x695,0x400) =3D 0 (0x0) -- truss-sc.txt- 1150: 17.826398035 = madvise(0x636b6000,0x2000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.826496738 = madvise(0x6368d000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.826571469 = madvise(0x636af000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.826645841 = madvise(0x636b8000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.826749703 = madvise(0x63704000,0x4a000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-sc.txt- 1150: 17.826894337 close(1) =3D 0 = (0x0) truss-sc.txt- 1150: 17.826974498 close(3) =3D 0 = (0x0) truss-sc.txt- 1150: 17.827061470 close(4) =3D 0 = (0x0) truss-sc.txt- 1150: 17.827196503 unlink("/tmp/.X11-unix/X0") =3D 0 = (0x0) truss-sc.txt- 1150: 17.827305916 unlink("/tmp/.X0-lock") =3D 0 = (0x0) truss-sc.txt: 1150: 17.827425349 ioctl(7,KDSETMODE,0x0) =3D 0 (0x0) truss-sc.txt: 1150: 17.827505210 ioctl(7,VT_GETMODE,0xffffd940) =3D 0 = (0x0) truss-sc.txt: 1150: 17.827584202 ioctl(7,VT_SETMODE,0xffffd940) =3D 0 = (0x0) truss-sc.txt: 1150: 17.827661784 ioctl(7,KDDISABIO,0x0) =3D 0 (0x0) truss-sc.txt: 1150: 17.833176507 ioctl(7,VT_ACTIVATE,0x1) =3D 0 = (0x0) truss-sc.txt- 1150: 17.833277520 close(7) =3D 0 = (0x0) truss-sc.txt- 1150: 17.833486564 write(2,"Server terminated successfully = ("...,54) =3D 54 (0x36) truss-sc.txt- 1150: 17.833569726 clock_gettime(4,{512.847195858 }) =3D 0 = (0x0) truss-sc.txt- 1150: 17.833697439 write(0,"[ 512.847] ",13) =3D 13 = (0xd) truss-sc.txt- 1150: 17.833804811 write(0,"Server terminated successfully = ("...,54) =3D 54 (0x36) truss-sc.txt- 1150: 17.833902674 close(0) =3D 0 = (0x0) truss-sc.txt- 1150: 17.833902674 SIGNAL 11 (SIGSEGV) truss-sc.txt- 1150: 17.834105508 = sigprocmask(SIG_SETMASK,SIGSEGV|SIGIO,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 17.834349653 = stat("/usr/share/nls/C/libc.cat",0xffffffffffffc5c8) ERR#2 'No such file = or directory' truss-sc.txt- 1150: 17.834448416 = stat("/usr/share/nls/libc/C",0xffffffffffffc5c8) ERR#2 'No such file or = directory' -- truss-sc.txt- 1150: 17.835754345 write(2,"\nPlease consult the The X.Org = F"...,85) =3D 85 (0x55) truss-sc.txt- 1150: 17.835927059 write(2,"Please also check the log file = a"...,84) =3D 84 (0x54) truss-sc.txt- 1150: 17.836072322 write(2,"\n",1) =3D 1 = (0x1) truss-sc.txt- 1150: 17.836151074 close(1) ERR#9 = 'Bad file descriptor' truss-sc.txt- 1150: 17.836228055 close(3) ERR#9 = 'Bad file descriptor' truss-sc.txt- 1150: 17.836298677 close(4) ERR#9 = 'Bad file descriptor' truss-sc.txt- 1150: 17.836396959 unlink("/tmp/.X0-lock") ERR#2 = 'No such file or directory' truss-sc.txt- 1150: 17.836494161 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGSEGV|SIGIO) =3D 0 (0x0) truss-sc.txt- 1150: 17.836593614 = sigprocmask(SIG_SETMASK,SIGSEGV|SIGIO,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 17.836680466 = sigprocmask(SIG_BLOCK,SIGIO,SIGSEGV|SIGIO) =3D 0 (0x0) truss-sc.txt: 1150: 17.836776348 ioctl(7,KDSETMODE,0x0) ERR#9 'Bad file = descriptor' truss-sc.txt: 1150: 17.836856810 ioctl(7,VT_GETMODE,0xffffc940) ERR#9 = 'Bad file descriptor' truss-sc.txt: 1150: 17.836933401 ioctl(7,KDDISABIO,0x0) ERR#9 'Bad file = descriptor' truss-sc.txt- 1150: 17.837067714 write(2,"xf86CloseConsole: KDDISABIO = fail"...,56) =3D 56 (0x38) truss-sc.txt- 1150: 17.837209888 write(2,"\n",1) =3D 1 = (0x1) truss-sc.txt- 1150: 17.837307450 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGSEGV|SIGIO) =3D 0 (0x0) truss-sc.txt- 1150: 17.837512624 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGEMT|SIGFPE= |SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGT= STP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPRO= F|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 17.837649907 = thr_kill(0x1873b,0x6,0x0,0x50cda850,0x0,0x0) =3D 0 (0x0) truss-sc.txt- 1150: 17.837649907 SIGNAL 6 (SIGABRT) truss-sc.txt- 1150: 17.837649907 process exit, rval =3D 0 -- truss-vt.txt- 1106: 0.215505716 clock_gettime(4,{150.074116831 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.215606098 write(0,"[ 150.074] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.215711341 write(0,"\tX.Org Video Driver: = 12.1\n",26) =3D 26 (0x1a) truss-vt.txt- 1106: 0.215791292 clock_gettime(4,{150.074402467 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.215895454 write(0,"[ 150.074] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.215995567 write(0,"\tX.Org XInput driver : = 16.0\n",28) =3D 28 (0x1c) truss-vt.txt- 1106: 0.216077078 clock_gettime(4,{150.074688253 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.216178061 write(0,"[ 150.074] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.216277513 write(0,"\tX.Org Server Extension : = 6.0\n",30) =3D 30 (0x1e) truss-vt.txt- 1106: 0.216471047 open("(null)",O_RDWR|O_CLOEXEC,00) =3D 6 = (0x6) truss-vt.txt: 1106: 0.216617750 ioctl(6,PCIOCGETCONF,0xffffa590) =3D 0 = (0x0) truss-vt.txt- 1106: 0.216735592 clock_gettime(4,{150.075346647 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.216843535 write(0,"[ 150.075] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.216952587 write(0,"(WW) xf86EnableIO -1\n",21) =3D = 21 (0x15) truss-vt.txt: 1106: 0.217366506 ioctl(6,PCIOCREAD,0xffffd414) =3D 0 = (0x0) truss-vt.txt: 1106: 0.217485609 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-vt.txt: 1106: 0.217572881 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-vt.txt: 1106: 0.217656552 ioctl(6,PCIOCGETBAR,0xffffd608) ERR#22 = 'Invalid argument' truss-vt.txt: 1106: 0.217747064 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-vt.txt: 1106: 0.217830256 ioctl(6,PCIOCGETBAR,0xffffd608) ERR#22 = 'Invalid argument' truss-vt.txt: 1106: 0.217918758 ioctl(6,PCIOCGETBAR,0xffffd608) =3D 0 = (0x0) truss-vt.txt: 1106: 0.218021270 ioctl(6,PCIOCREAD,0xffffd564) =3D 0 = (0x0) truss-vt.txt- 1106: 0.218108452 clock_gettime(4,{150.076719536 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.218221914 write(0,"[ 150.076] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.218331687 write(0,"(--) PCI: (0:10:0:0) = 10de:0092:1"...,41) =3D 41 (0x29) truss-vt.txt- 1106: 0.218426699 write(0,"rev 161",7) =3D 7 = (0x7) truss-vt.txt- 1106: 0.218522551 write(0,", Mem @ ",8) =3D 8 (0x8) truss-vt.txt- 1106: 0.218625483 write(0,"0xa1000000/16777216",19) =3D 19 = (0x13) truss-vt.txt- 1106: 0.218718455 write(0,", ",2) =3D 2 (0x2) truss-vt.txt- 1106: 0.218823667 write(0,"0x90000000/268435456",20) =3D = 20 (0x14) truss-vt.txt- 1106: 0.218920299 write(0,", ",2) =3D 2 (0x2) truss-vt.txt- 1106: 0.219022811 write(0,"0xa0000000/16777216",19) =3D 19 = (0x13) -- truss-vt.txt- 1106: 0.426740571 clock_gettime(4,{150.285355045 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.426839663 write(0,"[ 150.285] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.426940975 write(0,"(II) VESA: driver for VESA = chips"...,36) =3D 36 (0x24) truss-vt.txt- 1106: 0.427028067 write(0," ",1) =3D 1 (0x1) truss-vt.txt- 1106: 0.427116359 write(0,"vesa",4) =3D 4 = (0x4) truss-vt.txt- 1106: 0.427204771 write(0,"\n",1) =3D 1 (0x1) truss-vt.txt- 1106: 0.427275392 geteuid() =3D 0 = (0x0) truss-vt.txt- 1106: 0.427335634 getpid() =3D = 1106 (0x452) truss-vt.txt- 1106: 0.427444416 = setpgid(0x0,0x452,0x1,0x50cda5f0,0x0,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 0.427594449 open("/dev/tty",O_RDWR,00) =3D 7 = (0x7) truss-vt.txt: 1106: 0.427703322 ioctl(7,TIOCNOTTY,0x0) ERR#25 = 'Inappropriate ioctl for device' truss-vt.txt- 1106: 0.427786123 close(7) =3D 0 = (0x0) truss-vt.txt- 1106: 0.427881975 open("/dev/ttyv0",O_RDWR|O_NONBLOCK,00) = =3D 7 (0x7) truss-vt.txt: 1106: 0.427986078 ioctl(7,0xc0185671 { IORW 0x56('V'), = 113, 24 },0xffffd230) ERR#25 'Inappropriate ioctl for device' truss-vt.txt- 1106: 0.428061259 close(7) =3D 0 = (0x0) truss-vt.txt- 1106: 0.428153541 open("/dev/ttyv0",O_RDWR|O_NONBLOCK,00) = =3D 7 (0x7) truss-vt.txt: 1106: 0.428232563 ioctl(7,VT_GETMODE,0xffffd228) =3D 0 = (0x0) truss-vt.txt: 1106: 0.428308884 ioctl(7,CONS_GETVERS,0xffffd240) =3D 0 = (0x0) truss-vt.txt: 1106: 0.428387216 ioctl(7,VT_GETACTIVE,0x102f1608) =3D 0 = (0x0) truss-vt.txt: 1106: 0.428465728 ioctl(7,VT_OPENQRY,0x102f1254) =3D 0 = (0x0) truss-vt.txt- 1106: 0.428540969 close(7) =3D 0 = (0x0) truss-vt.txt- 1106: 0.428660222 open("/dev/ttyv8",O_RDWR|O_NONBLOCK,00) = =3D 7 (0x7) truss-vt.txt: 1106: 0.428738554 ioctl(7,VT_GETMODE,0xffffd228) =3D 0 = (0x0) truss-vt.txt- 1106: 0.428814545 clock_gettime(4,{150.287428510 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.428921798 write(0,"[ 150.287] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.429023440 write(0,"(--) Using syscons driver with = X"...,40) =3D 40 (0x28) truss-vt.txt- 1106: 0.429122802 write(0," (version = 8595229351.252)\n",26) =3D 26 (0x1a) truss-vt.txt- 1106: 0.429197144 clock_gettime(4,{150.287811108 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.429292006 write(0,"[ 150.287] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.429390348 write(0,"(--) using VT number 9\n\n",24) = =3D 24 (0x18) truss-vt.txt- 1106: 0.429470059 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd2e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-vt.txt- 1106: 0.429558171 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd3e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-vt.txt- 1106: 0.429634883 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd4e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-vt.txt- 1106: 0.429711385 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd5e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-vt.txt- 1106: 0.429787616 = __sysctl(0xffffffffffffd1a8,0x2,0xffffffffffffd6e8,0xffffffffffffd1a0,0x0,= 0x0) =3D 0 (0x0) truss-vt.txt: 1106: 0.429909749 ioctl(7,VT_ACTIVATE,0x9) =3D 0 = (0x0) truss-vt.txt: 1106: 0.430002451 ioctl(7,VT_WAITACTIVE,0x9) =3D 0 = (0x0) truss-vt.txt- 1106: 0.430155094 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEM= T|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGS= TOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALR= M|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 0.430256436 sigaction(SIGUSR1,{ 0x506d05e0 = SA_RESTART|SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) =3D 0 (0x0) truss-vt.txt- 1106: 0.430344698 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt: 1106: 0.430445230 ioctl(7,VT_SETMODE,0xffffd7e8) =3D 0 = (0x0) truss-vt.txt: 1106: 0.430525272 ioctl(7,KDENABIO,0x0) =3D 0 (0x0) truss-vt.txt: 1106: 0.430604684 ioctl(7,KDSETMODE,0x1) =3D 0 (0x0) truss-vt.txt- 1106: 0.430698256 clock_gettime(4,{150.289312790 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.430817808 write(0,"[ 150.289] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.430924281 write(0,"(WW) xf86EnableIO 7\n",20) =3D = 20 (0x14) truss-vt.txt- 1106: 0.431106415 clock_gettime(4,{150.289720799 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.431204157 write(0,"[ 150.289] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.431305469 write(0,"(--) NV: Found NVIDIA GeForce = 78"...,52) =3D 52 (0x34) truss-vt.txt- 1106: 0.431426821 clock_gettime(4,{150.290041326 }) =3D 0 = (0x0) truss-vt.txt- 1106: 0.431524863 write(0,"[ 150.290] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 0.431625635 write(0,"(WW) Falling back to old probe = m"...,47) =3D 47 (0x2f) truss-vt.txt- 1106: 0.431726198 clock_gettime(4,{150.290340882 }) =3D 0 = (0x0) -- truss-vt.txt- 1106: 1.197730956 write(0,"(II) UnloadModule: = "vesa"\n",26) =3D 26 (0x1a) truss-vt.txt- 1106: 1.197812768 clock_gettime(4,{151.056423972 }) =3D 0 = (0x0) truss-vt.txt- 1106: 1.197919330 write(0,"[ 151.056] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 1.198026252 write(0,"(II) Unloading vesa\n",20) =3D = 20 (0x14) truss-vt.txt- 1106: 1.198217296 munmap(0x50fad000,110592) =3D 0 = (0x0) truss-vt.txt- 1106: 1.198311858 clock_gettime(4,{151.056922643 }) =3D 0 = (0x0) truss-vt.txt- 1106: 1.198420310 write(0,"[ 151.056] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 1.198528703 write(0,"(--) Depth 24 pixmap format is = 3"...,38) =3D 38 (0x26) truss-vt.txt- 1106: 1.198672826 open("(null)",O_RDWR|O_CLOEXEC,00) =3D 8 = (0x8) truss-vt.txt- 1106: 1.216064558 = mmap(0x0,268435456,PROT_READ|PROT_WRITE,MAP_SHARED,8,0x0) =3D 1386889216 = (0x52aa4000) truss-vt.txt: 1106: 1.216162781 ioctl(8,MEMRANGE_SET,0xffffd4f0) =3D 0 = (0x0) truss-vt.txt- 1106: 1.216255123 close(8) =3D 0 = (0x0) truss-vt.txt- 1106: 1.218431879 clock_gettime(4,{151.077041164 }) =3D 0 = (0x0) truss-vt.txt- 1106: 1.218565052 write(0,"[ 151.077] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 1.218676714 write(0,"(II) NV(0): Using XFree86 = Accele"...,58) =3D 58 (0x3a) truss-vt.txt- 1106: 1.218771787 clock_gettime(4,{151.077382271 }) =3D 0 = (0x0) truss-vt.txt- 1106: 1.218879309 write(0,"[ 151.077] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 1.218985991 write(0,"\tScreen to screen bit = blits\n",28) =3D 28 (0x1c) truss-vt.txt- 1106: 1.219073113 clock_gettime(4,{151.077683507 }) =3D 0 = (0x0) truss-vt.txt- 1106: 1.219178775 write(0,"[ 151.077] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 1.219288458 write(0,"\tSolid filled = rectangles\n",25) =3D 25 (0x19) -- truss-vt.txt- 1106: 3.001457402 write(0," "us"",5) =3D 5 = (0x5) truss-vt.txt- 1106: 3.001548064 write(0,"\n",1) =3D 1 (0x1) truss-vt.txt- 1106: 3.001690537 clock_gettime(4,{152.860303932 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.001788429 write(0,"[ 152.860] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.001892021 write(0,"(**) Option "config_info"",25) = =3D 25 (0x19) truss-vt.txt- 1106: 3.001994534 write(0," = "hal:/org/freedesktop/Hal/devic"...,67) =3D 67 (0x43) truss-vt.txt- 1106: 3.002083395 write(0,"\n",1) =3D 1 (0x1) truss-vt.txt- 1106: 3.002161277 clock_gettime(4,{152.860774582 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.002257849 write(0,"[ 152.860] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.002359671 write(0,"(II) XINPUT: Adding extended = inp"...,95) =3D 95 (0x5f) truss-vt.txt: 1106: 3.002483544 ioctl(7,TIOCGETA,0x636bb490) =3D 0 = (0x0) truss-vt.txt: 1106: 3.003164349 ioctl(7,KDSETLED,0x0) =3D 0 (0x0) truss-vt.txt: 1106: 3.003264911 ioctl(7,KDGETLED,0xffffcb60) =3D 0 = (0x0) truss-vt.txt: 1106: 3.003345673 ioctl(7,KDSETLED,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 3.003428654 clock_gettime(4,{152.862041779 }) =3D 0 = (0x0) truss-vt.txt: 1106: 3.003552527 ioctl(7,TIOCSETA,0xffffcbe0) =3D 0 = (0x0) truss-vt.txt: 1106: 3.003632059 ioctl(7,KDSKBMODE,0x0) =3D 0 (0x0) truss-vt.txt: 1106: 3.003869934 ioctl(7,KDSKBMODE,0x0) =3D 0 (0x0) truss-vt.txt: 1106: 3.003972926 ioctl(7,TIOCFLUSH,0xffffcadc) =3D 0 = (0x0) truss-vt.txt: 1106: 3.004056718 ioctl(7,KDGETLED,0xffffcb50) =3D 0 = (0x0) truss-vt.txt: 1106: 3.004211401 ioctl(7,KDSETLED,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 3.004346704 clock_gettime(4,{152.862960609 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.004785313 = sendmsg(0x8,0xffffffffffffc940,0x20000,0xc8,0x5154a390,0x0) =3D 221 = (0xdd) truss-vt.txt- 1106: 3.004917796 clock_gettime(4,{152.863530801 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.005384786 poll({8/POLLIN},1,25000) =3D 1 = (0x1) truss-vt.txt- 1106: 3.005476768 = recvmsg(0x8,0xffffffffffffc9e0,0x40000,0x6368ff40,0xffffffffffffcaf8,0x514= 4dd48) =3D 74 (0x4a) truss-vt.txt- 1106: 3.005622721 = recvmsg(0x8,0xffffffffffffc9e0,0x40000,0x6368ff40,0xffffffffffffcaf8,0x514= 4dd48) ERR#35 'Resource temporarily unavailable' truss-vt.txt- 1106: 3.005850006 = sendmsg(0x8,0xffffffffffffc940,0x20000,0xc8,0x5154a2d0,0x0) =3D 217 = (0xd9) truss-vt.txt- 1106: 3.005935778 clock_gettime(4,{152.864548873 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.006368837 poll({8/POLLIN},1,25000) =3D 1 = (0x1) truss-vt.txt- 1106: 3.006449629 = recvmsg(0x8,0xffffffffffffc9e0,0x40000,0x6368ff40,0xffffffffffffcaf8,0x514= 4dd48) =3D 82 (0x52) -- truss-vt.txt- 1106: 3.033945488 write(0,"(**) Option "Device"",20) =3D = 20 (0x14) truss-vt.txt- 1106: 3.034054960 write(0," "/dev/sysmouse"",16) =3D 16 = (0x10) truss-vt.txt- 1106: 3.034144782 write(0,"\n",1) =3D 1 (0x1) truss-vt.txt- 1106: 3.034236224 clock_gettime(4,{152.892850129 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.034334536 write(0,"[ 152.892] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.034437709 write(0,"(=3D=3D) Apple Optical USB = Mouse: Pr"...,47) =3D 47 (0x2f) truss-vt.txt- 1106: 3.034554111 clock_gettime(4,{152.893167956 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.034651853 write(0,"[ 152.893] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.034754665 write(0,"(**) Apple Optical USB Mouse: = al"...,57) =3D 57 (0x39) truss-vt.txt- 1106: 3.034902928 = open("/dev/sysmouse",O_RDWR|O_NONBLOCK,00) =3D 9 (0x9) truss-vt.txt: 1106: 3.035025991 ioctl(9,TIOCGETA,0xffffcd6c) ERR#25 = 'Inappropriate ioctl for device' truss-vt.txt- 1106: 3.035120373 close(9) =3D 0 = (0x0) truss-vt.txt- 1106: 3.035223785 clock_gettime(4,{152.893837210 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.035327198 write(0,"[ 152.893] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.035430280 write(0,"(=3D=3D) Apple Optical USB = Mouse: Em"...,67) =3D 67 (0x43) truss-vt.txt- 1106: 3.035600114 clock_gettime(4,{152.894213778 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.035700466 write(0,"[ 152.894] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.035803998 write(0,"(**) Apple Optical USB Mouse: = ZA"...,60) =3D 60 (0x3c) truss-vt.txt- 1106: 3.035915750 clock_gettime(4,{152.894529655 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.036014782 write(0,"[ 152.894] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.036117955 write(0,"(**) Apple Optical USB Mouse: = Bu"...,41) =3D 41 (0x29) -- truss-vt.txt- 1106: 3.037564496 clock_gettime(4,{152.896178280 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.037662598 write(0,"[ 152.896] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.037765470 write(0,"(**) Apple Optical USB Mouse: = (a"...,61) =3D 61 (0x3d) truss-vt.txt- 1106: 3.037890723 clock_gettime(4,{152.896500937 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.037989425 write(0,"[ 152.896] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.038092147 write(0,"(**) Apple Optical USB Mouse: = (a"...,65) =3D 65 (0x41) truss-vt.txt- 1106: 3.038167898 clock_gettime(4,{152.896781563 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.038265491 write(0,"[ 152.896] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.038368663 write(0,"(**) Apple Optical USB Mouse: = (a"...,64) =3D 64 (0x40) truss-vt.txt- 1106: 3.038491815 = open("/dev/sysmouse",O_RDWR|O_NONBLOCK,00) =3D 9 (0x9) truss-vt.txt: 1106: 3.038572667 ioctl(9,TIOCGETA,0xffffcb8c) ERR#25 = 'Inappropriate ioctl for device' truss-vt.txt: 1106: 3.038693000 ioctl(9,MOUSE_SETLEVEL,0xffffcac0) =3D 0 = (0x0) truss-vt.txt: 1106: 3.038773432 ioctl(9,MOUSE_GETHWINFO,0xffffcac4) =3D = 0 (0x0) truss-vt.txt- 1106: 3.038853953 clock_gettime(4,{152.897467318 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.038956315 write(0,"[ 152.897] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.039060298 write(0,"(II) Apple Optical USB Mouse: = Se"...,71) =3D 71 (0x47) truss-vt.txt: 1106: 3.039136919 ioctl(9,MOUSE_GETMODE,0xffffcad8) =3D 0 = (0x0) truss-vt.txt- 1106: 3.039213781 clock_gettime(4,{152.897827355 }) =3D 0 = (0x0) truss-vt.txt- 1106: 3.039310773 write(0,"[ 152.897] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 3.039413435 write(0,"(II) Apple Optical USB Mouse: = Se"...,62) =3D 62 (0x3e) truss-vt.txt: 1106: 3.039553658 ioctl(9,MOUSE_SETMODE,0xffffcaa8) =3D 0 = (0x0) truss-vt.txt: 1106: 3.039645280 ioctl(9,TIOCFLUSH,0xffffcb5c) ERR#25 = 'Inappropriate ioctl for device' truss-vt.txt- 1106: 3.039813824 select(1024,{9},0x0,0x0,{0.000000 }) =3D = 0 (0x0) truss-vt.txt- 1106: 3.039923776 fstat(9,{ mode=3Dcrw------- = ,inode=3D28,size=3D0,blksize=3D4096 }) =3D 0 (0x0) truss-vt.txt- 1106: 3.040014828 = sigprocmask(SIG_BLOCK,SIGIO,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|= SIGVTALRM|SIGWINCH) =3D 0 (0x0) truss-vt.txt- 1106: 3.040140021 fcntl(9,F_GETFL,) =3D 6 = (0x6) truss-vt.txt- 1106: 3.040214242 fcntl(9,F_SETFL,O_ASYNC|O_NONBLOCK|0x2) = =3D 0 (0x0) truss-vt.txt- 1106: 3.040287324 getpid() =3D = 1106 (0x452) truss-vt.txt- 1106: 3.040354525 fcntl(9,F_SETOWN,0x452) =3D 0 (0x0) truss-vt.txt- 1106: 3.040495138 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEM= T|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGS= TOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALR= M|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN= |SIGTTOU|SIGIO|SIGVTALRM|SIGWINCH) =3D 0 (0x0) truss-vt.txt- 1106: 3.040606741 sigaction(SIGIO,{ 0x506d05e0 SA_SIGINFO = ss_t },{ SIG_DFL SA_RESTART ss_t }) =3D 0 (0x0) truss-vt.txt- 1106: 3.040707813 = sigprocmask(SIG_SETMASK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGV= TALRM|SIGWINCH,0x0) =3D 0 (0x0) -- truss-vt.txt- 1106: 17.676966736 sigprocmask(SIG_UNBLOCK,SIGIO,0x0) =3D = 0 (0x0) truss-vt.txt- 1106: 17.677078758 clock_gettime(4,{167.535689513 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.084594398 select(256,{1 3 4 7 = 8},0x0,0x0,{585.285000 }) =3D 1 (0x1) truss-vt.txt- 1106: 19.084715691 sigprocmask(SIG_BLOCK,SIGIO,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.084812473 read(7,"<",64) =3D 1 (0x1) truss-vt.txt- 1106: 19.084913755 clock_gettime(4,{168.943523999 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.085011677 sigprocmask(SIG_UNBLOCK,SIGIO,0x0) =3D = 0 (0x0) truss-vt.txt- 1106: 19.085125079 clock_gettime(4,{168.943735744 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.085235002 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.085333584 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt: 1106: 19.085456436 ioctl(7,VT_ACTIVATE,0x2) =3D 0 = (0x0) truss-vt.txt- 1106: 19.085456436 SIGNAL 30 (SIGUSR1) truss-vt.txt- 1106: 19.085581449 sigprocmask(SIG_SETMASK,SIGUSR1,0x0) =3D = 0 (0x0) truss-vt.txt- 1106: 19.085693952 = sigreturn(0xffffffffffffb9b0,0xffffffffffffb9b0,0x4c0,0x50caa7e8,0x130,0xf= fffffffffffc4c0) =3D 0 (0x0) truss-vt.txt- 1106: 19.085783623 clock_gettime(4,{168.944394468 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.085894626 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.085993178 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.086088220 clock_gettime(4,{168.944699004 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.260592808 select(256,{1 3 4 7 = 8},0x0,0x0,{0.659000 }) =3D 1 (0x1) truss-vt.txt- 1106: 19.260775362 sigprocmask(SIG_BLOCK,SIGIO,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.260875924 read(7,"\M-<",64) =3D 1 = (0x1) -- truss-vt.txt- 1106: 19.263525041 clock_gettime(4,{169.122137025 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.263628573 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.263722295 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.263829697 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.263924829 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.264015551 clock_gettime(4,{169.122627626 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.264119353 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.264213225 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.264320358 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.264413480 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt: 1106: 19.264531022 ioctl(7,KDSKBMODE,0x1) =3D 0 (0x0) truss-vt.txt: 1106: 19.264621054 ioctl(7,TIOCSETA,0x636bb490) =3D 0 = (0x0) truss-vt.txt- 1106: 19.264723536 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.264818068 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.264920310 clock_gettime(4,{169.123532085 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.265018323 fcntl(9,F_GETFL,) =3D 70 = (0x46) truss-vt.txt- 1106: 19.265098034 fcntl(9,F_SETFL,O_NONBLOCK|0x2) =3D 0 = (0x0) truss-vt.txt- 1106: 19.265242577 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEM= T|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGS= TOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALR= M|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.265342719 sigaction(SIGIO,{ SIG_IGN 0x0 ss_t },{ = 0x506d05e0 SA_SIGINFO ss_t }) =3D 0 (0x0) truss-vt.txt- 1106: 19.265432362 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.265540754 close(9) =3D 0 = (0x0) truss-vt.txt- 1106: 19.265642156 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 19.265736118 sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 19.265833200 clock_gettime(4,{169.124445185 }) =3D 0 = (0x0) truss-vt.txt- 1106: 19.265927702 sigprocmask(SIG_BLOCK,SIGIO,0x0) =3D 0 = (0x0) truss-vt.txt- 1106: 20.297172402 nanosleep({1.000000000 }) =3D 0 = (0x0) truss-vt.txt: 1106: 20.297540210 ioctl(7,VT_RELDISP,0x1) =3D 0 = (0x0) truss-vt.txt- 1106: 20.297643412 clock_gettime(4,{170.156254796 }) =3D 0 = (0x0) truss-vt.txt- 1106: 20.297757144 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGIO) =3D 0 (0x0) truss-vt.txt- 1106: 20.297861366 sigprocmask(SIG_SETMASK,SIGIO,0x0) =3D = 0 (0x0) truss-vt.txt- 1106: 20.297979269 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGIO) =3D 0 (0x0) truss-vt.txt- 1106: 20.298080731 sigprocmask(SIG_SETMASK,SIGIO,0x0) =3D = 0 (0x0) truss-vt.txt- 1106: 20.298174723 clock_gettime(4,{170.156786198 }) =3D 0 = (0x0) truss-vt.txt- 1106: 127.184243240 select(256,{1 3 4 = 8},0x0,0x0,{118.966000 }) ERR#4 'Interrupted system call' truss-vt.txt- 1106: 127.184243240 SIGNAL 15 (SIGTERM) truss-vt.txt- 1106: 127.184756880 = sigprocmask(SIG_SETMASK,SIGTERM|SIGIO,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 127.184863082 = sigreturn(0xffffffffffffc900,0xffffffffffffc900,0x4c0,0x50caa7b8,0x130,0xf= fffffffffffd410) ERR#4 'Interrupted system call' -- truss-vt.txt- 1106: 127.185885593 = madvise(0x5154e000,0x45000,0x5,0x0,0x763,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.186004486 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGIO) =3D 0 (0x0) truss-vt.txt- 1106: 127.186115968 clock_gettime(4,{277.044727382 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.186217940 clock_gettime(4,{277.044829474 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.186308872 clock_gettime(4,{277.044920407 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.186439225 clock_gettime(4,{277.045050759 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.186548247 clock_gettime(4,{277.045159751 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.186648269 clock_gettime(4,{277.045259773 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.186796142 write(0,"[ 277.045] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 127.186913054 write(0,"(II) UnloadModule: = "mouse"\n",27) =3D 27 (0x1b) truss-vt.txt: 1106: 127.187026697 ioctl(7,KDSKBMODE,0x1) =3D 0 = (0x0) truss-vt.txt: 1106: 127.187116159 ioctl(7,TIOCSETA,0x636bb490) =3D 0 = (0x0) truss-vt.txt- 1106: 127.187233011 clock_gettime(4,{277.045844875 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.187320463 clock_gettime(4,{277.045932597 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.187424205 write(0,"[ 277.045] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 127.187530707 write(0,"(II) UnloadModule: = "kbd"\n",25) =3D 25 (0x19) truss-vt.txt- 1106: 127.187864524 = madvise(0x6374e000,0xa6000,0x5,0x0,0xc000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.187967666 = madvise(0x63501000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.188079178 = madvise(0x63503000,0x3f000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.188162970 = madvise(0x636bf000,0x2000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.188246192 = madvise(0x636c3000,0x2000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.188331573 = madvise(0x63806000,0x3000,0x5,0x0,0x3f7000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.188509507 sigprocmask(SIG_SETMASK,SIGIO,0x0) =3D = 0 (0x0) truss-vt.txt- 1106: 127.188843264 munmap(0x50fad000,102400) =3D 0 = (0x0) truss-vt.txt- 1106: 127.190297363 munmap(0x62aa4000,7327744) =3D 0 = (0x0) truss-vt.txt- 1106: 127.190475657 munmap(0x631a1000,360448) =3D 0 = (0x0) truss-vt.txt- 1106: 127.190845115 munmap(0x631f9000,1519616) =3D 0 = (0x0) truss-vt.txt- 1106: 127.191125051 open("(null)",O_RDWR|O_CLOEXEC,00) =3D = 9 (0x9) truss-vt.txt: 1106: 127.191218322 ioctl(9,MEMRANGE_SET,0xffffd348) =3D 0 = (0x0) truss-vt.txt- 1106: 127.191309014 close(9) =3D 0 = (0x0) truss-vt.txt- 1106: 127.191427907 munmap(0x52aa4000,268435456) =3D 0 = (0x0) truss-vt.txt- 1106: 127.193081360 = madvise(0x51523000,0x14000,0x5,0x0,0x10000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.193167312 = madvise(0x5154b000,0x3000,0x5,0x0,0x10000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.193276574 = madvise(0x51476000,0x45000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.193361026 = madvise(0x51597000,0x3000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.193554650 = madvise(0x515a4000,0x1000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.193644862 = madvise(0x515a6000,0xd000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.193729164 = madvise(0x515b4000,0x5000,0x5,0x0,0x695,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.193816015 = madvise(0x515dc000,0xc000,0x5,0x0,0x695,0x400) =3D 0 (0x0) -- truss-vt.txt- 1106: 127.212440696 = madvise(0x636b6000,0x2000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.212540388 = madvise(0x6368d000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.212616620 = madvise(0x636af000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.212692911 = madvise(0x636b8000,0x1000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.212801004 = madvise(0x63704000,0x4a000,0x5,0x0,0xb2000,0x400) =3D 0 (0x0) truss-vt.txt- 1106: 127.212948967 close(1) =3D 0 = (0x0) truss-vt.txt- 1106: 127.213035698 close(3) =3D 0 = (0x0) truss-vt.txt- 1106: 127.213128040 close(4) =3D 0 = (0x0) truss-vt.txt- 1106: 127.213267633 unlink("/tmp/.X11-unix/X0") =3D 0 = (0x0) truss-vt.txt- 1106: 127.213383135 unlink("/tmp/.X0-lock") =3D 0 = (0x0) truss-vt.txt: 1106: 127.213482828 ioctl(7,KDSETMODE,0x0) =3D 0 = (0x0) truss-vt.txt: 1106: 127.213568479 ioctl(7,VT_GETMODE,0xffffd940) =3D 0 = (0x0) truss-vt.txt: 1106: 127.213655421 ioctl(7,VT_SETMODE,0xffffd940) =3D 0 = (0x0) truss-vt.txt: 1106: 127.213740383 ioctl(7,KDDISABIO,0x0) =3D 0 = (0x0) truss-vt.txt: 1106: 127.213883456 ioctl(7,VT_ACTIVATE,0x1) =3D 0 = (0x0) truss-vt.txt- 1106: 127.214061600 close(7) =3D 0 = (0x0) truss-vt.txt- 1106: 127.214237583 write(2,"Server terminated = successfully ("...,54) =3D 54 (0x36) truss-vt.txt- 1106: 127.214324105 clock_gettime(4,{277.072935219 }) =3D = 0 (0x0) truss-vt.txt- 1106: 127.214455837 write(0,"[ 277.072] ",13) =3D 13 = (0xd) truss-vt.txt- 1106: 127.214566630 write(0,"Server terminated = successfully ("...,54) =3D 54 (0x36) truss-vt.txt- 1106: 127.214663112 close(0) =3D 0 = (0x0) truss-vt.txt- 1106: 127.214663112 SIGNAL 11 (SIGSEGV) truss-vt.txt- 1106: 127.214934197 = sigprocmask(SIG_SETMASK,SIGSEGV|SIGIO,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 127.215207443 = stat("/usr/share/nls/C/libc.cat",0xffffffffffffc5c8) ERR#2 'No such file = or directory' truss-vt.txt- 1106: 127.215313315 = stat("/usr/share/nls/libc/C",0xffffffffffffc5c8) ERR#2 'No such file or = directory' -- truss-vt.txt- 1106: 127.216193533 write(2,"\nPlease consult the The = X.Org F"...,85) =3D 85 (0x55) truss-vt.txt- 1106: 127.216330996 write(2,"Please also check the log = file a"...,84) =3D 84 (0x54) truss-vt.txt- 1106: 127.216423818 write(2,"\n",1) =3D 1 = (0x1) truss-vt.txt- 1106: 127.216503949 close(1) ERR#9 = 'Bad file descriptor' truss-vt.txt- 1106: 127.216583301 close(3) ERR#9 = 'Bad file descriptor' truss-vt.txt- 1106: 127.216662233 close(4) ERR#9 = 'Bad file descriptor' truss-vt.txt- 1106: 127.216765615 unlink("/tmp/.X0-lock") ERR#2 = 'No such file or directory' truss-vt.txt- 1106: 127.216874907 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGSEGV|SIGIO) =3D 0 (0x0) truss-vt.txt- 1106: 127.216985129 = sigprocmask(SIG_SETMASK,SIGSEGV|SIGIO,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 127.217080531 = sigprocmask(SIG_BLOCK,SIGIO,SIGSEGV|SIGIO) =3D 0 (0x0) truss-vt.txt: 1106: 127.217192313 ioctl(7,KDSETMODE,0x0) ERR#9 = 'Bad file descriptor' truss-vt.txt: 1106: 127.217279195 ioctl(7,VT_GETMODE,0xffffc940) ERR#9 = 'Bad file descriptor' truss-vt.txt: 1106: 127.217365567 ioctl(7,KDDISABIO,0x0) ERR#9 = 'Bad file descriptor' truss-vt.txt- 1106: 127.217515150 write(2,"xf86CloseConsole: KDDISABIO = fail"...,56) =3D 56 (0x38) truss-vt.txt- 1106: 127.217607342 write(2,"\n",1) =3D 1 = (0x1) truss-vt.txt- 1106: 127.217708714 = sigprocmask(SIG_BLOCK,SIGALRM|SIGTSTP|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGVTA= LRM|SIGWINCH,SIGSEGV|SIGIO) =3D 0 (0x0) truss-vt.txt- 1106: 127.217917998 = sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGEMT|SIGFPE= |SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGT= STP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPRO= F|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 127.218058371 = thr_kill(0x1870f,0x6,0x0,0x50cda850,0x0,0x0) =3D 0 (0x0) truss-vt.txt- 1106: 127.218058371 SIGNAL 6 (SIGABRT) truss-vt.txt- 1106: 127.218058371 process exit, rval =3D 0 root@FBSDG5M1:~ #=20 I will note that the process tree does get a defunct process when I do = this (and Xorg never displays the cursor or anything else --as reported = in the later note): $ ps -aud USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND markmi 1113 0.1 0.0 11804 3292 0 Ss 4:28AM 0:00.01 -sh (sh) markmi 1115 0.0 0.0 11404 2764 0 R+ 4:28AM 0:00.01 - ps -aud root 1042 0.0 0.0 12716 3464 v0 Is 4:25AM 0:00.03 login [pam] = (login) root 1092 0.0 0.0 12372 4028 v0 I 4:25AM 0:00.04 - -csh (csh) root 1105 0.0 0.0 11032 2560 v0 I+ 4:27AM 0:00.88 `-- truss = -fd -o truss-vt.txt /usr/local/bin/Xorg root 1106 0.0 0.3 323868 33208 v0 IX 4:27AM 0:01.42 |-- = /usr/local/bin/Xorg root 1108 0.0 0.0 0 0 v0 Z+ 4:27AM 0:00.04 `-- = root 1043 0.0 0.0 11104 2516 v1 Is+ 4:25AM 0:00.01 = /usr/libexec/getty Pc ttyv1 root 1044 0.0 0.0 11104 2516 v2 Is+ 4:25AM 0:00.01 = /usr/libexec/getty Pc ttyv2 root 1045 0.0 0.0 11104 2516 v3 Is+ 4:25AM 0:00.04 = /usr/libexec/getty Pc ttyv3 root 1046 0.0 0.0 11104 2516 v4 Is+ 4:25AM 0:00.04 = /usr/libexec/getty Pc ttyv4 root 1047 0.0 0.0 11104 2516 v5 Is+ 4:25AM 0:00.01 = /usr/libexec/getty Pc ttyv5 root 1048 0.0 0.0 11104 2516 v6 Is+ 4:25AM 0:00.04 = /usr/libexec/getty Pc ttyv6 root 1049 0.0 0.0 11104 2516 v7 Is+ 4:25AM 0:00.01 = /usr/libexec/getty Pc ttyv7 Still it is enough to have the nearly-black-on-black issue when = switching to consoles when vt-based. Of the 2560x1440 vt-based boot-time pictures requested for the path of = issues that I said that I was not going down... > Could you please post pictures of this screen with both -BETA2 and > -BETA3? I'd like to understand this regression on your side. For -BETA3 (and probably now -RC1?) I greatly doubt that I can get a = useful screen picture for the vt with 2560x1440 on Radeon x1950 issue. = The -BETA3 2560x1440 boot-display seems to be text a couple of pixels = high/wide per character and fairly dark. (Presumes that the pattern is = from tiny text since it is too small to read.) The same display pattern = seems to repeat several times across the display. Most of the display is = just black except for the band across the top that has that rectangular = area repeated, each of the same size and internal pattern. And the boot = seems to hang after not very long, limiting what I can do to figure = anything out. I might try to see if I get a picture better than I expect = I would get. For -BETA2 2560x1440 pictures for the Radeon X1950 are possible (if I = re-establish a -BETA2 boot media that uses vt) but the oddity was just = the beginning of the next line/row also being visible on the far right = side of the display and it appeared to be a simple issue: normal display = but COL in /usr/src/sys/powerpc/ofw/ofw_syscons.c and = /usr/src/sys/dev/syscons/syscons.h was likely smaller than the 2560 = pixel wide space would require in order to fill it and so the displayed = text wrapped to the next line (next row) at the right hand side when it = was using ofwfb_static_window... #define COL 240 ... static u_int16_t ofwfb_static_window[ROW*COL]; Once the initial, static display storage was replaced with one correctly = sized it was completely fine in -BETA2. Before that replacement it was = easily used despite the extra text at the right. (Of course wrapping to = the potential next row could also go out of bounds depending on ROW's = value vs. the 1440 pixels. And ROW may or may not have been big enough = to span the 1440 as well. But all the lines for the 1440 height seemed = to be displayed and scrolled correctly [ignoring the right-side extra = text issue].) (Other _static_window's around likely would have the same COL/ROW = issues for big enough displays, not just ofwfb_static_window.) I'll note that for the GeForce 7800 GT's the 2560x1440 vt-based display = shows normal text during boot but using only a small area in the middle = of the display. (Small compared to the display pixel counts.) = Essentially no different then just having a smaller pixel-count display = in the first place. For my current activities I prefer the -BETA2 vt or = the sc behavior for the additional text displayed (early-boot debug = information sometimes, it need not fit in the smaller effective = display). Let me know if I should re-establish a -BETA2 and make a picture of the = right hand side extra-text despite the simplicity of what was odd. That = might take a bit for me to do. Of the kms-drm-update-38 request... > If you have some time, could you please test my "kms-drm-update-38", > available on GitHut? > https://github.com/dumbbell/freebsd/tree/kms-drm-update-38 I probably will experiment with this at some point but it may take a = while to get there. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@FreeBSD.ORG Sun Oct 5 16:38:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FFB7B0A; Sun, 5 Oct 2014 16:38:50 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7082ABEE; Sun, 5 Oct 2014 16:38:49 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so4812345wgg.1 for ; Sun, 05 Oct 2014 09:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FXt2vO22Acd9nfQmxJwlvWo7CLSREI/mZ1swBTNyGCo=; b=Bf4IIFWRxhpJTvAGdQA4aXw3diAAPbhTdyCqpJJ0xjcO0rr/8m3qvRcYj7XIOfkGh1 Ta0+WKZ+qGB9AhprIDiVO6HEtXiLyLLbp2uzM0hG9QWhhMc4m39jBBDagoOlH1yM8Fwf 8XkqypGk8TIkrb6cnn3lvhlnwefdgy5s2mlW7mc8oPecFAYZ/hKoAM93EC+ukj2wDj6v CgzFoomUlNL28+E69awjvPVwLQ7jbI1lE+ZtMLfMCaH5I5AA4mXC3HGlSeC0MmH5uu2s qL1ZoT9KG6hOeyvQ8+K2BTQ0czCbJkA4jOYXyh/hYFLoeq6Pmra7ofXnkbUBDcHbsSR3 op3w== MIME-Version: 1.0 X-Received: by 10.194.57.237 with SMTP id l13mr24066398wjq.102.1412527127747; Sun, 05 Oct 2014 09:38:47 -0700 (PDT) Received: by 10.27.46.14 with HTTP; Sun, 5 Oct 2014 09:38:47 -0700 (PDT) In-Reply-To: <20141005203401.440afc31@X220.alogt.com> References: <20141005013247.GH1171@hub.FreeBSD.org> <20141005203401.440afc31@X220.alogt.com> Date: Sun, 5 Oct 2014 11:38:47 -0500 Message-ID: Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails From: Scot Hetzel To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , freebsd-jail@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Stable , freebsd-net@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 16:38:50 -0000 On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky wrote: > Hi, > > On Sat, 4 Oct 2014 21:32:47 -0400 > Glen Barber wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> The first RC build of the 10.1-RELEASE release cycle is now available > > I installed this shortly after your e-mail came. The result was the > same as with BETA3. If you remember, I have had the problem that the > network inside jails stopped working after I installed BETA3. The > upgrade to RC1 did not change anything. > > I took now the time to investigate a bit. The result is simple. All > works as expected until lagg becomes enabled. > > If I remember right, BETA1 was my last working version. > > I have an em and an iwn interface in the machine. I can use both of them > without any problems. > > As I can reproduce this problem 100%, it might be a good idea if I help > you to find the source of the problem. My problem would be: how. > > If somebody could tell me where to start looking for the error, we > might find it soon. > You'll need to identify where in the src caused the issue for you. To do this, you will need to identify where it was working (BETA1?). You would then have to step thru the sources until you find the point where it breaks. The easiest way would be to take the svn revision that is half way between BETA1 and BETA3, compile and install it and see if it works. You keep halving the result until you identify the commit that broke it. Once the offending commit is identified, email the list. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 00:56:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D85BF8E9; Mon, 6 Oct 2014 00:56:25 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEA7330C; Mon, 6 Oct 2014 00:56:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=+7UMKAiqJFV/RI4PZZYQ3LYPK9zcLgFryw4O2OrKgkg=; b=Y23houYCS4Ge/Sxi0zPkFSNDWeAqfB3usm6TTkJAr3eflXs7Qz2LlA7FZ2YaJoXW03JqkCwJ3PkA67/AZPPoXej6JUKFSnmmh/GjIPeyxVuZ8YdmiMTQAq7vLt3j6jfXp8xVPGQ89tYtuwlkLkqaezPVagVSs5D0p/qd1kNXPII=; Received: from [182.1.193.13] (port=23547 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xawb4-003GY4-JX; Sun, 05 Oct 2014 18:56:19 -0600 Date: Mon, 6 Oct 2014 08:56:06 +0800 From: Erich Dollansky To: Scot Hetzel Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails Message-ID: <20141006085606.1d55fe5e@X220.alogt.com> In-Reply-To: References: <20141005013247.GH1171@hub.FreeBSD.org> <20141005203401.440afc31@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Glen Barber , freebsd-jail@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Stable , freebsd-net@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 00:56:26 -0000 Hi, On Sun, 5 Oct 2014 11:38:47 -0500 Scot Hetzel wrote: > On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky > wrote: > > On Sat, 4 Oct 2014 21:32:47 -0400 > > Glen Barber wrote: > > > >> The first RC build of the 10.1-RELEASE release cycle is now > >> available > > > > I installed this shortly after your e-mail came. The result was the > > same as with BETA3. If you remember, I have had the problem that the > > network inside jails stopped working after I installed BETA3. The > > upgrade to RC1 did not change anything. > > > You'll need to identify where in the src caused the issue for you. To > do this, you will need to identify where it was working (BETA1?). > You would then have to step thru the sources until you find the point > where it breaks. > > The easiest way would be to take the svn revision that is half way > between BETA1 and BETA3, compile and install it and see if it works. > You keep halving the result until you identify the commit that broke > it. > > Once the offending commit is identified, email the list. > this is what I wanted to avoid. A shame that -Dno_clean will not work here. It would save a lot of compile time without running the risk missing out some files. Anyway, I compile world and kernel just to make sure that the problem is caught. This will take some time. Erich From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 04:25:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5779E4E9; Mon, 6 Oct 2014 04:25:59 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 43E23936; Mon, 6 Oct 2014 04:25:59 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 321A0296; Mon, 6 Oct 2014 04:25:59 +0000 (UTC) Date: Mon, 6 Oct 2014 04:25:56 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, bdrewery@FreeBSD.org Message-ID: <1034454679.1.1412569559067.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #820 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 04:25:59 -0000 See Changes: [bdrewery] MFC r272579: Bump .Dd missed in r271424 ------------------------------------------ [...truncated 214558 lines...] --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_aio --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- ===> acpi/acpi_panasonic (cleandir) --- cleandir_subdir_alc --- --- cleandir_subdir_aic7xxx --- --- _sub.cleandir --- --- cleandir_subdir_alc --- ===> alc (cleandir) --- cleandir_subdir_aic7xxx --- ===> aic7xxx/ahc/ahc_eisa (cleandir) --- clean --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- rm -f export_syms ahc_eisa.ko ahc_eisa.kld ahc_eisa.o ahc_eisa.ko.debug ahc_eisa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h eisa_if.h pci_if.h bus_if.h device_if.h --- cleandir_subdir_alc --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- cleanilinks --- rm -f @ machine x86 --- cleandir_subdir_acpi --- ===> acpi/acpi_sony (cleandir) --- cleandir_subdir_aic7xxx --- --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_ale --- --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_ale --- ===> ale (cleandir) --- cleandir_subdir_aic7xxx --- ===> aic7xxx/ahc/ahc_isa (cleandir) --- cleandir_subdir_acpi --- --- cleanobj --- ===> acpi/acpi_toshiba (cleandir) --- cleandir_subdir_aic7xxx --- --- clean --- --- cleandir_subdir_ale --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- rm -f export_syms ahc_isa.ko ahc_isa.kld ahc_isa.o ahc_isa.ko.debug ahc_isa.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h pci_if.h isa_if.h bus_if.h device_if.h --- cleanilinks --- rm -f @ machine x86 --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_alq --- --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_alq --- ===> alq (cleandir) --- cleandir_subdir_aic7xxx --- ===> aic7xxx/ahc/ahc_pci (cleandir) --- cleandir_subdir_acpi --- ===> acpi/acpi_video (cleandir) --- cleandir_subdir_aic7xxx --- --- clean --- rm -f export_syms ahc_pci.ko ahc_pci.kld ahc_pci.o aic7xxx_pci.o ahc_pci.ko.debug ahc_pci.ko.symbols opt_scsi.h opt_cam.h opt_aic7xxx.h pci_if.h bus_if.h device_if.h --- cleandir_subdir_alq --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- cleanilinks --- rm -f @ machine x86 --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_amdsbwd --- --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_amdsbwd --- ===> amdsbwd (cleandir) --- cleandir_subdir_acpi --- ===> acpi/acpi_dock (cleandir) --- cleandir_subdir_aic7xxx --- ===> aic7xxx/ahd (cleandir) --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_amdsbwd --- --- cleanobj --- --- cleandir_subdir_aic7xxx --- --- cleanobj --- --- cleandir_subdir_acpi --- ===> acpi/acpi_wmi (cleandir) --- cleandir_subdir_amdtemp --- ===> amdtemp (cleandir) --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_amr --- --- cleandir_subdir_amdtemp --- --- cleanobj --- --- cleandir_subdir_amr --- ===> amr (cleandir) --- cleandir_subdir_acpi --- ===> acpi/aibs (cleandir) --- cleandir_subdir_an --- ===> an (cleandir) --- cleandir_subdir_amr --- --- cleanobj --- --- cleandir_subdir_acpi --- --- cleanobj --- --- cleandir_subdir_an --- --- cleanobj --- --- cleandir_subdir_aout --- --- cleandir_subdir_amr --- --- _sub.cleandir --- ===> amr/amr_cam (cleandir) --- cleandir_subdir_aout --- ===> aout (cleandir) --- cleandir_subdir_arcmsr --- ===> arcmsr (cleandir) --- cleandir_subdir_amr --- --- clean --- rm -f export_syms amr_cam.ko amr_cam.kld amr_cam.o amr_cam.ko.debug amr_cam.ko.symbols opt_cam.h opt_scsi.h bus_if.h device_if.h --- cleandir_subdir_aout --- --- cleanobj --- --- cleandir_subdir_amr --- --- cleanilinks --- rm -f @ machine x86 --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_asmc --- --- cleandir_subdir_amr --- --- cleanobj --- --- cleandir_subdir_asmc --- ===> asmc (cleandir) --- cleandir_subdir_arcmsr --- --- cleanobj --- --- cleandir_subdir_amr --- ===> amr/amr_linux (cleandir) --- clean --- rm -f export_syms amr_linux.ko amr_linux.kld amr_linux.o amr_linux.ko.debug amr_linux.ko.symbols bus_if.h device_if.h --- cleandir_subdir_ata --- ===> ata (cleandir) --- cleandir_subdir_amr --- --- cleanilinks --- --- cleandir_subdir_asmc --- --- cleanobj --- --- cleandir_subdir_amr --- rm -f @ machine x86 --- cleandepend --- rm -f .depend GPATH GRTAGS GSYMS GTAGS --- cleandir_subdir_ath --- --- cleandir_subdir_ata --- --- _sub.cleandir --- --- cleandir_subdir_amr --- --- cleanobj --- --- cleandir_subdir_ata --- ===> ata/atacore (cleandir) --- cleandir_subdir_ath --- ===> ath (cleandir) --- cleandir_subdir_ath_pci --- ===> ath_pci (cleandir) --- cleandir_subdir_ata --- --- cleanobj --- ===> ata/atacard (cleandir) --- cleandir_subdir_ath_pci --- --- cleanobj --- --- cleandir_subdir_ata --- --- cleanobj --- ===> ata/ataisa (cleandir) --- cleandir_subdir_autofs --- ===> autofs (cleandir) --- cleandir_subdir_ata --- --- cleanobj --- --- cleandir_subdir_autofs --- --- cleanobj --- --- cleandir_subdir_ata --- ===> ata/atapci (cleandir) --- cleandir_subdir_ath --- --- cleanobj --- --- cleandir_subdir_bce --- ===> bce (cleandir) --- cleandir_subdir_ata --- --- cleanobj --- --- cleandir_subdir_bce --- --- cleanobj --- --- cleandir_subdir_ata --- --- _sub.cleandir --- ===> ata/atapci/chipsets (cleandir) --- _sub.cleandir --- ===> ata/atapci/chipsets/ataacard (cleandir) --- cleanobj --- ===> ata/atapci/chipsets/ataacerlabs (cleandir) --- cleanobj --- rm: fts_read: No such file or directory *** [cleanobj] Error code 1 make[5]: stopped in --- _sub.cleandir --- A failure has been detected in another branch of the parallel make make[7]: stopped in *** [_sub.cleandir] Error code 2 make[6]: stopped in 1 error make[6]: stopped in *** [_sub.cleandir] Error code 2 make[5]: stopped in 2 errors make[5]: stopped in *** [_sub.cleandir] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [cleandir_subdir_ata] Error code 2 make[3]: stopped in --- cleandir_subdir_ath --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [cleandir_subdir_ath] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [modules-cleandir] Error code 2 make[2]: stopped in /usr/obj 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 06:25:41 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A8CFC06; Mon, 6 Oct 2014 06:25:41 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id BCFA9634; Mon, 6 Oct 2014 06:25:40 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id s966Pcgb007855; Mon, 6 Oct 2014 15:25:38 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili14) with ESMTP id s966PcL16355; Mon, 6 Oct 2014 15:25:38 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi17) id s966PcVp026544; Mon, 6 Oct 2014 15:25:38 +0900 Received: from localhost by lomi17.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s966Pc4q026482; Mon, 6 Oct 2014 15:25:38 +0900 Date: Mon, 06 Oct 2014 15:25:38 +0900 (JST) Message-Id: <20141006.152538.1986502749881070938.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno In-Reply-To: <20141004092030.GP26076@kib.kiev.ua> References: <20141004082943.GN26076@kib.kiev.ua> <20141004.175326.766405563100788209.okuno.kohji@jp.panasonic.com> <20141004092030.GP26076@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 06:25:41 -0000 Hi Konstantin, I tested your patch. It was no problem. Thank you for your kind correspondence. Regards, Kohji Okuno > On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote: >> Hi, Konstantin, >> >> > At the end of the mail is commit candidate. I did not even compiled this. >> > Can you test and report back, please ? >> >> Could you check the following? >> (1) should use kernel_pmap->pm_stats.resident_count >> ^^^ >> I'm sorry. My patch was wrong. > As well as mine. > >> >> (2) should use pmap_resident_count_inc() in amd64. > Correct. > >> >> >> I will test, later. >> >> In addtion, I have one question. >> In current and 10-stable, is vm_map_delete() called by kva_free()? > No, kva_free() only releases the vmem backing, leaving the page > tables intact. This is why I only did the stable/9 patch. > >> If vm_map_delete() is called, this fix is needed in current and >> 10-stable, I think. > > Updated patch below. > > Index: amd64/amd64/pmap.c > =================================================================== > --- amd64/amd64/pmap.c (revision 272506) > +++ amd64/amd64/pmap.c (working copy) > @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in > pa = trunc_page(pa); > for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) > pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); > + PMAP_LOCK(kernel_pmap); > + pmap_resident_count_inc(kernel_pmap, OFF_TO_IDX(size)); > + PMAP_UNLOCK(kernel_pmap); > pmap_invalidate_range(kernel_pmap, va, va + tmpsize); > pmap_invalidate_cache_range(va, va + tmpsize); > return ((void *)(va + offset)); > Index: i386/i386/pmap.c > =================================================================== > --- i386/i386/pmap.c (revision 272506) > +++ i386/i386/pmap.c (working copy) > @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in > size = roundup(offset + size, PAGE_SIZE); > pa = pa & PG_FRAME; > > - if (pa < KERNLOAD && pa + size <= KERNLOAD) > + if (pa < KERNLOAD && pa + size <= KERNLOAD) { > va = KERNBASE + pa; > - else > + } else { > va = kmem_alloc_nofault(kernel_map, size); > + PMAP_LOCK(kernel_pmap); > + kernel_pmap->pm_stats.resident_count += OFF_TO_IDX(size); > + PMAP_UNLOCK(kernel_pmap); > + } > if (!va) > panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 07:20:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98CE79B4; Mon, 6 Oct 2014 07:20:07 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 88080B17; Mon, 6 Oct 2014 07:20:07 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4AB3F2DE; Mon, 6 Oct 2014 07:20:07 +0000 (UTC) Date: Mon, 6 Oct 2014 07:20:05 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, bdrewery@FreeBSD.org, hselasky@FreeBSD.org Message-ID: <2119239031.2.1412580005647.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1034454679.1.1412569559067.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1034454679.1.1412569559067.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #821 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:20:07 -0000 See From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 08:27:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21ABD89E for ; Mon, 6 Oct 2014 08:27:28 +0000 (UTC) Received: from asp.reflexion.net (outbound-246.asp.reflexion.net [69.84.129.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB682377 for ; Mon, 6 Oct 2014 08:27:26 +0000 (UTC) Received: (qmail 13951 invoked from network); 6 Oct 2014 08:27:25 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Oct 2014 08:27:25 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 06 Oct 2014 04:27:25 -0400 (EDT) Received: (qmail 9481 invoked from network); 6 Oct 2014 08:27:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Oct 2014 08:27:24 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 87C751C405B; Mon, 6 Oct 2014 01:27:23 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) [NVIDIA vs. powerpc64 for vt console switching; Radeon X1950 not working for powerpc64 Xorg generally] From: Mark Millard In-Reply-To: <83AFBF78-CBE1-4651-B3D6-A83168956D93@dsl-only.net> Date: Mon, 6 Oct 2014 01:27:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <19458DB3-FBDE-4BC5-867C-63E875E9261B@dsl-only.net> References: <2C74DFEC-D943-4237-8988-B9657240EC21@dsl-only.net> <82C08920-CF4B-441F-8162-9F6D2625E927@dsl-only.net> <8BAFEFD4-2FC3-4566-9CCE-F039594BDE7F@dsl-only.net> <83AFBF78-CBE1-4651-B3D6-A83168956D93@dsl-only.net> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: dumbbell@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 08:27:28 -0000 [This is another reply to Jean-S=E9bastien P=E9dron's Sat Oct 4 15:31:47 = UTC 2014 reply to my notes about how things are on PowerMac G5's. This = note is just about attempting use a build of the kernel from the = kms-drm-update-38 source code.] Context: PowerMac G5's with PCI-Express and 2 processors with dual cores = and the kms-drm-update-38 kernel. Some use 12 GBytes RAM other use 16 = GBytes RAM. Radeon X1950 for 2560x1440: A pure black screen for boot after the clear = that FreeBSD does of the openfirmware black-text on white background = stage of booting, no evidence is anything else in any lighting. So this = is somewhat different from 10.1-RC1/BETA3 but not like 10.1-BETA2. (The = X1950 card is fairly recently available to me and I've never tried it = with anything before 10.1-BETA2 or so.) (With the general, long-known PowerPac G5 boot-hang problems I'd not = conclude much from the apparent hangs I got for this context.) Radeon X1950 for 1920x1200: The boot text is fine. Xorg behavior is no = different than with 10.1-RC1/BETA3/... The same Xorg.0.log messages = result and the same failures to find a screen to use happens. (scfb = too.) (Xorg -configure produced xorg.conf.new being a match to my usual = xorg.conf_radeon_pciex that I copy to /etc/X11/xorg.conf when I switch = the SSD to the X1950 based G5.) GeForce 7800 GT (used with 1920x1200): boot/console display is fine but = Xorg/xfce4 had display problems that I've never seen before. As I moved the mouse around similar, smaller scale shapes were drawn up = towards the top of the screen (compared to the mouse position), with = that shape pattern repeating going across the screen. When I closed windows blocks of mostly black (rectangular) would be = drawn in the same sort of areas. Again a repeating pattern going across = the screen. The nearly black text on black display problem was present when = switching to consoles from Xorg/xfce4. Other points: the boots with that kernel consistently reported... lock order reversal: 1st 0xad67d50 ufs (ufs) @ = /usr/home/markmi/fbsd_dumbbell_src/kms-drm-update-38/sys/kern/vfs_subr.c:2= 137 2nd 0xc0000000d0434fb8 bufwait (bufwait) @ = /usr/home/markmi/fbsd_dumbbell_src/kms-drm-update-38/sys/ufs/ffs/ffs_vnops= .c:262 3rd 0xad67418 ufs (ufs) @ = /usr/home/markmi/fbsd_dumbbell_src/kms-drm-update-38/sys/kern/vfs_subr.c:2= 137 KDB: stack backtrace: 0xc000000115f97fb0: at .kdb_backtrace+0x5c 0xc000000115f980e0: at ._witness_debugger+0x3c 0xc000000115f98170: at .witness_checkorder+0xa7c 0xc000000115f98260: at .__lockmgr_args+0x9d4 0xc000000115f983a0: at .ffs_lock+0xa8 0xc000000115f98450: at .VOP_LOCK1_APV+0x158 0xc000000115f984e0: at ._vn_lock+0x88 0xc000000115f985d0: at .vget+0x88 0xc000000115f98680: at .vfs_hash_get+0x12c 0xc000000115f98740: at .ffs_vgetf+0x60 0xc000000115f98830: at .softdep_sync_buf+0xbd0 0xc000000115f98980: at .ffs_syncvnode+0x278 0xc000000115f98a60: at .ffs_truncate+0x6cc 0xc000000115f98ca0: at .ufs_direnter+0x9cc 0xc000000115f98dd0: at .ufs_makeinode+0x5bc 0xc000000115f98ff0: at .ufs_create+0x44 0xc000000115f99070: at .VOP_CREATE_APV+0x14c 0xc000000115f99100: at .vn_open_cred+0x1e0 0xc000000115f992c0: at .vn_open+0x24 0xc000000115f99340: at .kern_openat+0x284 0xc000000115f99520: at .kern_open+0x34 0xc000000115f995a0: at .sys_open+0x28 0xc000000115f99620: at .trap+0x564 0xc000000115f99880: at .powerpc_interrupt+0x1e0 0xc000000115f99920: user SC trap by 0x502d4af8: srr1=3D0x900000000000d032 r1=3D0xffffffffffffa3e0 cr=3D0x48004082 xer=3D0x20000000 = ctr=3D0x502d4af0 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 20:49:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64A72694 for ; Mon, 6 Oct 2014 20:49:32 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CAF483C for ; Mon, 6 Oct 2014 20:49:32 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 47C05B949; Mon, 6 Oct 2014 16:49:30 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: vt does not resume properly after zzz Date: Mon, 06 Oct 2014 16:47:49 -0400 Message-ID: <2384548.yqFzOG8bcA@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <864mvqfabt.fsf@gmail.com> <86vbo2tcrn.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Oct 2014 16:49:30 -0400 (EDT) Cc: marekrud@gmail.com, Kevin Oberman X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:49:32 -0000 On Saturday, October 04, 2014 04:24:11 PM Kevin Oberman wrote: > On Thu, Oct 2, 2014 at 1:52 PM, wrote: > > - DELL M1330 with Intel graphics card (Xorg used to work with intel > > > > driver > > All of the information I can find says that this unit has nVidia graphics, > but Intel may be a low-priced option, as well. Again, /var/log/Xorg.0.log > should have this information as should "pciconf -lv | grep -A3 vga". This > laptop goes back to 2007, so it should be using the old UMS Intel graphics. > It should not be using VESA, but if it is, that might point out a common > thread. > > I don't know the details and the actual problem was never identified, but I > know that some systems needed to have a kernel built with "NOOPTION VESA" > to get it to resume. I had this problem on my Lenovo T520 (which I am using > to send this reply). That doesn't apply to his system. I have an older HP netbook (i386) that resumes fine in text mode with syscons, but does not resume in text mode in vt(4). (This is a case where the VESA bits actually help rather than hurt.) However, if I kldload the kms driver ('kldload i915kms') when using vt(4), then resume works fine (and it also works fine in X). Marek, Can you try 'kldload i915kms' before you suspend and see if that fixes your issue? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 20:49:35 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51F59761; Mon, 6 Oct 2014 20:49:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B58F83A; Mon, 6 Oct 2014 20:49:32 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E495FB96B; Mon, 6 Oct 2014 16:49:30 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, nathanw@freebsd.org Subject: Re: Media image names - Document & rationalise. Date: Mon, 06 Oct 2014 16:34:49 -0400 Message-ID: <88376822.lFZdKxbhSR@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <201410011358.s91DwOXJ033137@fire.js.berklix.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Oct 2014 16:49:31 -0400 (EDT) Cc: Glen Barber , Ed Maste X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:49:35 -0000 On Wednesday, October 01, 2014 04:56:02 PM Mehmet Erol Sanliturk wrote: > On Wed, Oct 1, 2014 at 12:54 PM, Ed Maste wrote: > > On 1 October 2014 10:37, Glen Barber wrote: > > > On Wed, Oct 01, 2014 at 03:58:24PM +0200, Julian H. Stacey wrote: > > >> Maybe there was an explanation of -uefi- on a mail list. One can > > >> guess: for [some?] newer machines try uefi. But could we put a more > > >> exact purpose of uefi images in a README ? > > > > > > The UEFI images will be documented in the release announcement email, > > > because they are specific to the 10.1-RELEASE cycle. 11.0-RELEASE will > > > have the functionality in the default installation medium. > > > > To be clear, the existing, legacy-only images are built the same way > > as they always have been. The reason there are separate -uefi- images > > is to avoid accidental regression in legacy-only boot support. > > > > The 10.1 -uefi- images (as well as the 11.0 images) are actually > > dual-mode, and should boot in both UEFI and legacy configurations. > > I'm interested in receiving test reports of installations using the > > -uefi- images, in both UEFI and legacy boot configurations. > > > > (Technical detail: The image contains legacy MBR boot code, and is > > partitioned using the MBR scheme. One of the MBR partitions is an EFI > > system partition of type 0xEF. Legacy boot uses the MBR, while UEFI > > loads the first-stage loader /EFI/BOOT/BOOTX64.EFI. Both cases use > > the same root file system and boot the same kernel.) > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I have installed both of the > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/FreeBSD-10.1-BETA > 2-amd64-dvd1.iso.xz > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/FreeBSD-10.1-BET > A2-amd64-uefi-dvd1.iso.xz > > distributions into the same HDD in a non-UEFI mainboard ( Intel DG965WHM > ) . > > No one of them produced a bootable installation . > > Previously I have sent the message > > https://lists.freebsd.org/pipermail/freebsd-current/2014-August/051617.html > > about this issue . > > The problem is still persisting in Beta 2 . > > On the same computer , Fedora 21 Alpha is booting very well ( means there > is not any hardware problem ) . > > > I did not try 10.1 Beta 3 because there is no any mention of this problem > in the announcement message . > > > Thank you very much . I believe the issue here as I discussed with Marcel last year is that the x86 installer needs to tell gpart to set the active flag on the dummy MBR slice in the PMBR if GPT is being used without EFI (the installer knows if it is booted via EFI or not). In 9.2 and older, the flag was always set, but that violated the EFI spec and broke several systems, so in 9.3 and later, gpart was changed to not set the flag by default. However, we should still set it for non-EFI booting via GPT to cater to broken BIOSes (such as yours). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 20:59:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83561B15 for ; Mon, 6 Oct 2014 20:59:14 +0000 (UTC) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44716965 for ; Mon, 6 Oct 2014 20:59:13 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id z60so4374904qgd.33 for ; Mon, 06 Oct 2014 13:59:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=c/Fp01BBikfD6hS/mgxUynB+zL7PdxohiTL7a8slgEk=; b=XgDje50iYZCvOAlo1oqMXdk+J5fJpnl7BKrRefDURXLTZYOPpWE0r+OztzGsv+8uTN TtY/TQwvbCap1kNQn7jqGrHk9qpvNTUaxrJwj+5Cawyk2Q6ehmYxP9ubrOncEaDCJiPW 69hJoIVYx4qHiT6/vygjvRO4hD6HAPoNReUH2g64/dbIHXs9c3t8qOFsOUTJ6Ck2CXFl tAnO94KhG1JknVkas2tZkNnnvzmCgDCYS2pIgxR8txTJH2ygKRn1JnTTqvUq8//w10mn lv4efqKVX+TVwGoI7/FKk3/tInFGWMn6ywaWVzp1wLARvGRrgNDYmMq3UWlQEnEmS4HP SQ4Q== X-Gm-Message-State: ALoCoQnzE4DdPOWpOP+r5qo1Mrn2EekCjo7kQU6xkXioSB9hDxLOg9x82eBy32Pt8+UBMUQ/aKyT MIME-Version: 1.0 X-Received: by 10.140.29.71 with SMTP id a65mr30319274qga.45.1412629152532; Mon, 06 Oct 2014 13:59:12 -0700 (PDT) Sender: daniel@otherware.org Received: by 10.140.20.248 with HTTP; Mon, 6 Oct 2014 13:59:12 -0700 (PDT) X-Originating-IP: [216.207.42.140] Date: Mon, 6 Oct 2014 13:59:12 -0700 X-Google-Sender-Auth: Y_E7KjeVRWuqz5BUws2tNAaxl38 Message-ID: Subject: USB keyboard not recognized during boot From: Daniel To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:59:14 -0000 My problem stems from not being able to use my keyboard during the geli password prompt for the encrypted root drive. This is not a new issue: - https://forums.freebsd.org/viewtopic.php?f=4&t=40965 - https://docs.freebsd.org/cgi/getmsg.cgi?fetch=11610+0+current/freebsd-questions - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131415 Both people who have had the problem aside from me mention that the issue did not exist pre FreeBSD-9.1 At this time I'm wondering what I should do. I really would like to have my root encrypted. The actual bug hasn't moved for quite some time. Should I open up a new one? Since my motherboard does not have non-USB keyboard options, I'm not able of encryption on root. Does anyone have ideas? suggestions? I have tried waiting and then type, but nothing has helped. How can I move this forward? Motherboard: http://www.amazon.com/gp/product/B00FM4M7TQ -d From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 21:23:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91327245; Mon, 6 Oct 2014 21:23:23 +0000 (UTC) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 163D5C25; Mon, 6 Oct 2014 21:23:23 +0000 (UTC) Received: by mail-yk0-f173.google.com with SMTP id 200so2335718ykr.18 for ; Mon, 06 Oct 2014 14:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QFleegqTwSm2KMtWpdqRRk1f14tnN50tj/cKh/KPwL8=; b=xmIVLFcc4y5I+xri9DdFfxxFYB54txYcB+WWbYkKgEvF44c1IXeR4KI+zLhfcoVmzW c4ElsftbTliDAMEos2gPryGrLDjXdkvOKM/QY9lAYkVBQhpxospWis2We6gCQztm34o2 PJ9G+tQTfJHEtzQpq38u7f3Qa4CVBZ9tgr6fOaDdc0ksxsj0KaSsDb5cWJ7LZQLhje9o 6tXcMCjVVnOVLsX2HMP6sr0IwcPNZ28II8TMYyjLKQ4pMcFiPLFZTsfwqUMWhTzltPNg 3eHp/P0ZvN/o2XwBkirAAtgKq4MVissXAkHjJanFny28SeMtSj2rv33KeVTzAUzFA0iM esKw== MIME-Version: 1.0 X-Received: by 10.236.41.199 with SMTP id h47mr39731812yhb.1.1412630602270; Mon, 06 Oct 2014 14:23:22 -0700 (PDT) Received: by 10.170.206.10 with HTTP; Mon, 6 Oct 2014 14:23:22 -0700 (PDT) In-Reply-To: <88376822.lFZdKxbhSR@ralph.baldwin.cx> References: <201410011358.s91DwOXJ033137@fire.js.berklix.net> <88376822.lFZdKxbhSR@ralph.baldwin.cx> Date: Mon, 6 Oct 2014 17:23:22 -0400 Message-ID: Subject: Re: Media image names - Document & rationalise. From: Mehmet Erol Sanliturk To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ed Maste , nathanw@freebsd.org, freebsd-stable , Glen Barber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:23:23 -0000 On Mon, Oct 6, 2014 at 4:34 PM, John Baldwin wrote: > On Wednesday, October 01, 2014 04:56:02 PM Mehmet Erol Sanliturk wrote: > > On Wed, Oct 1, 2014 at 12:54 PM, Ed Maste wrote: > > > On 1 October 2014 10:37, Glen Barber wrote: > > > > On Wed, Oct 01, 2014 at 03:58:24PM +0200, Julian H. Stacey wrote: > > > >> Maybe there was an explanation of -uefi- on a mail list. One can > > > >> guess: for [some?] newer machines try uefi. But could we put a more > > > >> exact purpose of uefi images in a README ? > > > > > > > > The UEFI images will be documented in the release announcement email, > > > > because they are specific to the 10.1-RELEASE cycle. 11.0-RELEASE > will > > > > have the functionality in the default installation medium. > > > > > > To be clear, the existing, legacy-only images are built the same way > > > as they always have been. The reason there are separate -uefi- images > > > is to avoid accidental regression in legacy-only boot support. > > > > > > The 10.1 -uefi- images (as well as the 11.0 images) are actually > > > dual-mode, and should boot in both UEFI and legacy configurations. > > > I'm interested in receiving test reports of installations using the > > > -uefi- images, in both UEFI and legacy boot configurations. > > > > > > (Technical detail: The image contains legacy MBR boot code, and is > > > partitioned using the MBR scheme. One of the MBR partitions is an EFI > > > system partition of type 0xEF. Legacy boot uses the MBR, while UEFI > > > loads the first-stage loader /EFI/BOOT/BOOTX64.EFI. Both cases use > > > the same root file system and boot the same kernel.) > > > _______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to " > freebsd-stable-unsubscribe@freebsd.org" > > > > I have installed both of the > > > > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/FreeBSD-10.1-BETA > > 2-amd64-dvd1.iso.xz > > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/FreeBSD-10.1-BET > > A2-amd64-uefi-dvd1.iso.xz > > > > distributions into the same HDD in a non-UEFI mainboard ( Intel DG965WHM > > ) . > > > > No one of them produced a bootable installation . > > > > Previously I have sent the message > > > > > https://lists.freebsd.org/pipermail/freebsd-current/2014-August/051617.html > > > > about this issue . > > > > The problem is still persisting in Beta 2 . > > > > On the same computer , Fedora 21 Alpha is booting very well ( means there > > is not any hardware problem ) . > > > > > > I did not try 10.1 Beta 3 because there is no any mention of this problem > > in the announcement message . > > > > > > Thank you very much . > > I believe the issue here as I discussed with Marcel last year is that the > x86 > installer needs to tell gpart to set the active flag on the dummy MBR > slice in > the PMBR if GPT is being used without EFI (the installer knows if it is > booted > via EFI or not). > > In 9.2 and older, the flag was always set, but that violated the EFI spec > and > broke several systems, so in 9.3 and later, gpart was changed to not set > the > flag by default. However, we should still set it for non-EFI booting via > GPT > to cater to broken BIOSes (such as yours). > > -- > John Baldwin > Some Linux distibutions are published ( on the same .iso ) as installable onto both old BIOS and new UEFI capable BIOS , but I do not know how they are doing it . I am installing the same Linux distribution onto computer with old BIOS ( Intel mainboard ) and another computer with UEFI capable BIOS ( ASUS mainboard ) without activating UEFI mode and both of them are booting successfully after installation and working . When I move a FreeBSD or Linux installed HDD booting successfully in an old BIOS having computer to a new UEFI capable BIOS having computer , they are booting and working successfully . Therefore I can not say anything about what FreeBSD Project can decide what to do on this problem , but I think there are a large number of main boards that are using old BIOSes which they have been programmed to boot from an MBR enabled device ( perhaps ONLY from such a device or from ONLY "active" partitions ) . Actually I am not mentioning this problem only for my benefit . I can find a way to solve this problem . Important point is less experienced users encountering a very disappointing outcome old style computers . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 21:23:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1D4833C for ; Mon, 6 Oct 2014 21:23:57 +0000 (UTC) Received: from sasl.smtp.pobox.com (smtp.pobox.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4CAB3C37 for ; Mon, 6 Oct 2014 21:23:56 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 9F8E81365F for ; Mon, 6 Oct 2014 17:19:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=7QIlQb19YbMqDDpkCWQfAohdbFk=; b=rEhOGIK S8jOrvfsOb4RcZTQ8Ffa4jXRMfb7xt2WmlkqVigoaklhvuwDhQWeUBFDB/58uo23 PqQ/gcJ/t/z/dr7oOuaKgpDtC7RWEXUDDigB41tA5ezFu7m98AeChIfkNkGd1Bnu hBPXMfG+ga9dREnv/FtVwXICfw2KeTjpkpzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sasl; b=RNDFnvO73EStWlmCLEEOqLu3qZe9SeT+z /TeSmDTPUKfdg4W0XIMLytNOV0etuhQCHOJxzzVfycRuBz9nfu0zhAqSRfFCN07u gD59uKjPPCzN6RtdjVhfSy8L2qoWJBKoOSN5DikseGgty/lALhTNeTPLPz8joX6Z QyelZWKR/w= Received: from pb-smtp1. (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 980E91365E for ; Mon, 6 Oct 2014 17:19:52 -0400 (EDT) Received: from localhost (unknown [50.90.2.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 3ED1F1365C for ; Mon, 6 Oct 2014 17:19:52 -0400 (EDT) Date: Mon, 6 Oct 2014 17:19:51 -0400 From: Chris Nehren To: freebsd-stable@freebsd.org Subject: Re: USB keyboard not recognized during boot Message-ID: <20141006211951.GD24785@satori.lan> Mail-Followup-To: freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0hHDr/TIsw4o3iPK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: 82CDB6CC-4D9E-11E4-B89C-855A93717476-49531120!pb-smtp1.pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:23:57 -0000 --0hHDr/TIsw4o3iPK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 06, 2014 at 13:59:12 -0700, Daniel wrote: > My problem stems from not being able to use my keyboard during the geli > password prompt for the encrypted root drive. >=20 > This is not a new issue: >=20 >=20 > - https://forums.freebsd.org/viewtopic.php?f=3D4&t=3D40965 > - > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D11610+0+current/freebs= d-questions > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D131415 >=20 >=20 > Both people who have had the problem aside from me mention that the issue > did not exist pre FreeBSD-9.1 >=20 > At this time I'm wondering what I should do. I really would like to have = my > root encrypted. The actual bug hasn't moved for quite some time. Should I > open up a new one? >=20 > Since my motherboard does not have non-USB keyboard options, I'm not able > of encryption on root. >=20 > Does anyone have ideas? suggestions? I have tried waiting and then type, > but nothing has helped. How can I move this forward? >=20 > Motherboard: http://www.amazon.com/gp/product/B00FM4M7TQ I have a Supermicro X10SAE, also using GELI-encrypted root ZFS. I have found that, comical as it may seem, mashing the keyboard during the system's initial device probing allows me to hit enter at the password prompt (which gets printed in between some of the USB device probes) and then enter the password properly. I'm running on: FreeBSD behemoth 10.1-RC1 FreeBSD 10.1-RC1 #0 r272473: Fri Oct 3 14:56:28 = UTC 2014 root@behemoth:/usr/obj/usr/src/sys/GENERIC amd64 Here's my /boot/loader.conf: geli_ada0p4_keyfile0_load=3D"YES" geli_ada0p4_keyfile0_type=3D"ada0p4:geli_keyfile0" geli_ada0p4_keyfile0_name=3D"/boot/encryption.key" geli_ada2p4_keyfile0_load=3D"YES" geli_ada2p4_keyfile0_type=3D"ada2p4:geli_keyfile0" geli_ada2p4_keyfile0_name=3D"/boot/encryption.key" aesni_load=3D"YES" geom_eli_load=3D"YES" vfs.root.mountfrom=3D"zfs:rpool/ROOT/default" zfs_load=3D"YES" zpool_cache_load=3D"YES" zpool_cache_type=3D"/boot/zfs/zpool.cache" zpool_cache_name=3D"/boot/zfs/zpool.cache" So, it "works" for me, but I need to be attentive during boot or I see the same problems that you do. --=20 Chris Nehren --0hHDr/TIsw4o3iPK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJbBAABAgBFBQJUMwd3PhSAAAAAABUAIHBrYS1hZGRyZXNzQGdudXBnLm9yZ2Nu ZWhyZW4rZnJlZWJzZC1zdGFibGVAcG9ib3guY29tAAoJEBHA+GJAM0vPNycP/3Ar BzJCkmNDNK2cdQ1BRfs4RP7jB70dFjMGlv6bu63dSQkcUnwU4WX7M3f5BS7I3WnI cdbl0pKmVilnA2B/fCLwS6weHd3uAuCYntcSYYEf/z17GxhvdiiWxgU3O+Nb6mPJ dQ9FVs3IFxC7Qt/+yfIzSbsHJ9upL8mn8ASyvINh8UlcJZcLHngyduGpu5ZE1LL2 isAQBNaEps1AxZzRAOPe+xz6qFpVe5xIBvcaSperupasnmomC05HtUsiIS4hmsXr /sqeBT//gPSNEONeSi3CMataSE/sGYMOlNCChRujDtfYhgcmxVy2j7x6f6oS2nzG zQnkQL/2RCI+lRdAV/8ZM+lYsSRt+3IAHnRj6QSimAD606xtKU3ildmrJhhcMRI1 f2ePhRedwaf8cOR+dn/BRPubSxo0tytydf6Qjw0Mkn7SXSszUReJelMlcZK1AD/O NUvZn93L3Yl/jve6BtsP2U6NJ0wbB7or2ElQwcuv7zJgnnJMZUKcJIS49Rea3Pxq yikzoxwcdm6dKMTHkFj75YGGMDP4ELNfFPs3ygASjKIRiec4WlNfpFJ1JmL2DDIB yuCAHj3Da2CmMzaqy4aBbtOwvMoFCJgPssrwckgsvtiP8pSb4A+Yrp8HTGNm+y9X P0qqiM+L/MQ9LPtkLD5EJE0vNLhgtJuNi8CUM4CH =z81/ -----END PGP SIGNATURE----- --0hHDr/TIsw4o3iPK-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 23:32:30 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCF5D827 for ; Mon, 6 Oct 2014 23:32:30 +0000 (UTC) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 813BCC39 for ; Mon, 6 Oct 2014 23:32:29 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j7so4295252qaq.29 for ; Mon, 06 Oct 2014 16:32:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=DS/bcRH5bsYXXFFoOnK3ItkZJTsl6SSrF2G/S02pcTg=; b=RdEG5zJD1yvSav97DdavGRy+fAiFAv83ed6trRUCfUTdZJSo6YHSNeTYMJC8jPzrB3 pYvyoBpQMYpBEncqNLOw8V8DZbjuIYtzz/nOpGLKV913wKPKQQBa4aLUdvJm4PcFt0UC hqON+f8wg07JMWa8fWYD3i5mqEGrQHfKlWs0ZUjWNXwNukeTA9CRqhdDApd/JR5L9eHB VMusFzKPuHeOxmlEzMhHSaxtajT2ghmjqiFaAZ0ViwhPb5kNP6Ca1FmfWE63vhRrAnrT 2J8yPILJmW4jOVgF/1duFeTxBd7/u5ffxmLI624pvP7yyLWNGMp04KRUpFLmwpSEmXC3 2HMg== X-Gm-Message-State: ALoCoQnD0urTfnCfSBQTXvODH6D2P17vZwPgn+KXj2LmOGyarFunBvZ9lD8CWpuNExf8lg0vtU+e MIME-Version: 1.0 X-Received: by 10.224.171.74 with SMTP id g10mr27141qaz.102.1412638343530; Mon, 06 Oct 2014 16:32:23 -0700 (PDT) Received: by 10.140.233.142 with HTTP; Mon, 6 Oct 2014 16:32:23 -0700 (PDT) Date: Tue, 7 Oct 2014 02:32:23 +0300 Message-ID: Subject: Booting from ZFS - fail. From: Stefan Lambrev To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 23:32:30 -0000 Hi, I have some problems to boot from raidz/zfs mirror with FreeBSD 10.1* with AHCI enabled. Detailed description is available at https://forums.freebsd.org/viewtopic.php?f=48&t=48324&p=270114 If I turn AHCI to "legacy" in BIOS it works but I guess it should work with AHCI enabled also. I know some people are having the same HW (except the HDDs) running without a problem so I'm not sure whether this is some regression. Can someone advice what's going on? P.S. The system is amd64 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 6 23:50:29 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D356B6B for ; Mon, 6 Oct 2014 23:50:29 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85447D67 for ; Mon, 6 Oct 2014 23:50:29 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 4AF191C937; Mon, 6 Oct 2014 16:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1412639428; x=1412653828; bh=L5L7p2bOa7NvUFZxIkAB1DZtxcTxDvgN5accfJcrRg4=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=u5eg+p7nega202LDqfbrWXsbpQWYivPj3QW6iDACyxLn4sQrjjlwWQnLXT7pzhVEg Rd8OTsCtGvULqb81RoGSxAOqxW6m2iO09pm+ccVBXbjrvmmQFSZ9glJX/uZueARYeI xB+Uq6XaapSXsloS/EV76QaaqljVgwFg0pHrohMw= Message-ID: <54332AC3.4090606@delphij.net> Date: Mon, 06 Oct 2014 16:50:27 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Stefan Lambrev , stable@freebsd.org Subject: Re: Booting from ZFS - fail. References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 23:50:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/06/14 16:32, Stefan Lambrev wrote: > Hi, > > I have some problems to boot from raidz/zfs mirror with FreeBSD > 10.1* with AHCI enabled. Detailed description is available at > https://forums.freebsd.org/viewtopic.php?f=48&t=48324&p=270114 > > If I turn AHCI to "legacy" in BIOS it works but I guess it should > work with AHCI enabled also. I know some people are having the same > HW (except the HDDs) running without a problem so I'm not sure > whether this is some regression. > > Can someone advice what's going on? I noticed that you are using 3TB hard drives (ST3000VN000). What's your partition layout? For instance have you tried booting from smaller ZFS pools that does not exceed a few gigabytes instead? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUMyrDAAoJEJW2GBstM+ns5vgP/3OMHwzsIOMHer7DX/5xh6tL W5rjI+TwJmQMXU2JTmEb0vTHDf7s97l1eo2nkdRDHTDqjx6tR5+Gou3xqt7nInMr R9YyyQRGH46fJ1vqse3DpvyzZuMxtYfXnraI/TX3E3T9gAevs7+4uic90btroRZ6 qDI6T/+dhuh6MuzDPogB2JxXyfWBHx+pxb0AiWXXesEFnUzr8r4DcXI+D5hpOoky rrwkNiiRLrwsHaQoNkQ3AFRpT8T24tbLLhYZi0r8DWKej6gne+17FgEEnN69SBAO fhTSagklYA7t0WlMliDu7thSmB71HE+6f56JGkl65kLk+EDCNuCGYquGG5lJtekE MFBNX4Xg4wU0Ltn6LyKFzOFcDN+9ag4hOUqzVhSrBKcm8ktlzjqJwKAKn2pekIrg wwIUpYpoDEJVj+UMSur+0xkPEyGnWPQ06JOIZdqIUmB6uKtIfBKVzuf/b8K+qqGR 3B3N9RQyJHfn8uaCqGn/6Op6+QY+WONgFhFKt3dn6Ib6OVx47mhd60YDkHyLnA10 QrPkmD3MmB/vGx9sf5skFDShNb9pBAoL057VIvQLJjzCXi7Rony1DZu7DlGUnKB8 n/ad+/Eda0Yp+JFvLCMdEyahGaNbqWwRqHolSo95P2XLhguOR7ENOvcomvlIQuIU 4+MU0fdI0LkKBUuq+QbJ =tPaI -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 7 00:13:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B103E00; Tue, 7 Oct 2014 00:13:16 +0000 (UTC) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id 62F7DFD4; Tue, 7 Oct 2014 00:13:15 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 9E7FC25ECD; Mon, 6 Oct 2014 20:13:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46w3EqaTU84s; Mon, 6 Oct 2014 20:13:14 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <54333019.9010304@egr.msu.edu> Date: Mon, 06 Oct 2014 20:13:13 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Media image names - Document & rationalise. References: <201410011358.s91DwOXJ033137@fire.js.berklix.net> <88376822.lFZdKxbhSR@ralph.baldwin.cx> In-Reply-To: <88376822.lFZdKxbhSR@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Glen Barber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 00:13:16 -0000 On 10/06/2014 16:34, John Baldwin wrote: > I believe the issue here as I discussed with Marcel last year is that the x86 > installer needs to tell gpart to set the active flag on the dummy MBR slice in > the PMBR if GPT is being used without EFI (the installer knows if it is booted > via EFI or not). I ran into this today too with 10.1-RC1 (and recent 11 I think) on a BIOS based desktop freshly liberated from windows. It would not boot. I got it going with gpart but as a new user I'd be in trouble. > > In 9.2 and older, the flag was always set, but that violated the EFI spec and > broke several systems, so in 9.3 and later, gpart was changed to not set the > flag by default. However, we should still set it for non-EFI booting via GPT > to cater to broken BIOSes (such as yours). > From owner-freebsd-stable@FreeBSD.ORG Tue Oct 7 07:21:15 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3683A41 for ; Tue, 7 Oct 2014 07:21:15 +0000 (UTC) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73544195 for ; Tue, 7 Oct 2014 07:21:14 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id x12so4568775qac.31 for ; Tue, 07 Oct 2014 00:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LH91LbmRrLx1Mk9QUna2OCMxDacgm0pSYBoN7Egno+U=; b=PE5aKPWaU5w1WyMWwqPLinNuBFo4sgTSsQrjq0Wzw77HvftKOuwwL8PFZ26qVQL50n WRzs4I2IEVs+FxitEjQ9z28iojd6niT8adqA1WIv0MDvFezp8dx5Pi6YxjXtWeDxwEyi JCGl+v/UWcmNcixv5AzalbV7h6bDmx3+CV1VwwzWe1sOV8od/kZGQmN2WbseD0IE4Dcg iOC9CJMrXlMQ+wqjaM8Y4o8sWIGrlqmnhRluJ/XdJOQqW1zbzV8vgeae98Yh5RcZ0h// VXUyfqnLshFSdeB6qqKylbvwNs7LP8AHuKzanPs/J1zuPQZOrT34jGvwg/QLwCPgC2cE o7rQ== X-Gm-Message-State: ALoCoQmOUikD5/ZH+H2pLPVdXG7JuCnh6VmWyF8YDlxQgFcb+5CN0LXT+W4v/RkJGofS5j+79F8L MIME-Version: 1.0 X-Received: by 10.140.29.71 with SMTP id a65mr32874578qga.45.1412666087097; Tue, 07 Oct 2014 00:14:47 -0700 (PDT) Received: by 10.140.233.142 with HTTP; Tue, 7 Oct 2014 00:14:47 -0700 (PDT) In-Reply-To: <54332AC3.4090606@delphij.net> References: <54332AC3.4090606@delphij.net> Date: Tue, 7 Oct 2014 10:14:47 +0300 Message-ID: Subject: Re: Booting from ZFS - fail. From: Stefan Lambrev To: d@delphij.net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 07:21:15 -0000 Hi, I have tested with a mirror from just 2x3TB HDDs but with no difference. Though the layout of the partitions was the same (e.g. the smallest partition I have tried is 2.7TB): gpart show ada0 (This is valid for all four disks) => 34 5860533101 ada0 GPT (2.7T) 34 6 - free - (3.0K) 40 512 1 freebsd-boot (256K) 552 5860532576 2 freebsd-zfs [bootme] (2.7T) 5860533128 7 - free - (3.5K) On Tue, Oct 7, 2014 at 2:50 AM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 10/06/14 16:32, Stefan Lambrev wrote: > > Hi, > > > > I have some problems to boot from raidz/zfs mirror with FreeBSD > > 10.1* with AHCI enabled. Detailed description is available at > > https://forums.freebsd.org/viewtopic.php?f=48&t=48324&p=270114 > > > > If I turn AHCI to "legacy" in BIOS it works but I guess it should > > work with AHCI enabled also. I know some people are having the same > > HW (except the HDDs) running without a problem so I'm not sure > > whether this is some regression. > > > > Can someone advice what's going on? > > I noticed that you are using 3TB hard drives (ST3000VN000). What's > your partition layout? For instance have you tried booting from > smaller ZFS pools that does not exceed a few gigabytes instead? > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0 > > iQIcBAEBCgAGBQJUMyrDAAoJEJW2GBstM+ns5vgP/3OMHwzsIOMHer7DX/5xh6tL > W5rjI+TwJmQMXU2JTmEb0vTHDf7s97l1eo2nkdRDHTDqjx6tR5+Gou3xqt7nInMr > R9YyyQRGH46fJ1vqse3DpvyzZuMxtYfXnraI/TX3E3T9gAevs7+4uic90btroRZ6 > qDI6T/+dhuh6MuzDPogB2JxXyfWBHx+pxb0AiWXXesEFnUzr8r4DcXI+D5hpOoky > rrwkNiiRLrwsHaQoNkQ3AFRpT8T24tbLLhYZi0r8DWKej6gne+17FgEEnN69SBAO > fhTSagklYA7t0WlMliDu7thSmB71HE+6f56JGkl65kLk+EDCNuCGYquGG5lJtekE > MFBNX4Xg4wU0Ltn6LyKFzOFcDN+9ag4hOUqzVhSrBKcm8ktlzjqJwKAKn2pekIrg > wwIUpYpoDEJVj+UMSur+0xkPEyGnWPQ06JOIZdqIUmB6uKtIfBKVzuf/b8K+qqGR > 3B3N9RQyJHfn8uaCqGn/6Op6+QY+WONgFhFKt3dn6Ib6OVx47mhd60YDkHyLnA10 > QrPkmD3MmB/vGx9sf5skFDShNb9pBAoL057VIvQLJjzCXi7Rony1DZu7DlGUnKB8 > n/ad+/Eda0Yp+JFvLCMdEyahGaNbqWwRqHolSo95P2XLhguOR7ENOvcomvlIQuIU > 4+MU0fdI0LkKBUuq+QbJ > =tPaI > -----END PGP SIGNATURE----- > From owner-freebsd-stable@FreeBSD.ORG Tue Oct 7 09:43:37 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F8CBA30 for ; Tue, 7 Oct 2014 09:43:37 +0000 (UTC) Received: from forward3l.mail.yandex.net (forward3l.mail.yandex.net [IPv6:2a02:6b8:0:1819::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 459B8306 for ; Tue, 7 Oct 2014 09:43:36 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward3l.mail.yandex.net (Yandex) with ESMTP id 995FC1501B2A; Tue, 7 Oct 2014 13:43:32 +0400 (MSK) Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id D8E307E14B6; Tue, 7 Oct 2014 13:43:31 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:81f::cb]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 1NlpQNv22s-hVkeeKAQ; Tue, 7 Oct 2014 13:43:31 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 092b6e0c-7b1b-41ec-a705-3d0d33e0b372 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1412675011; bh=O0flNo/8vAIwG01aG1U5Lra7kJrVpMGem69GJUkxJ18=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=N0/7NtPwLS5Z1tWe++R/I5l9cWkQF3tm0S5oGX1aXwqfVsi0dkvxGR5/m6uh1sdji MhblUr+03CJ7V9SlwOB4oZ6ylqflV16RDPz8/zsiBCXuKpxvDF2ShTFFYrxPKzFCPF 5cfuLiFmH3iyifRi7LcS53SchQ4dNxLYSGQ7UEbc= Authentication-Results: smtp11.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5433B56D.3060904@yandex.ru> Date: Tue, 07 Oct 2014 13:42:05 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stefan Lambrev , d@delphij.net Subject: Re: Booting from ZFS - fail. References: <54332AC3.4090606@delphij.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:43:37 -0000 On 07.10.2014 11:14, Stefan Lambrev wrote: > Hi, > > I have tested with a mirror from just 2x3TB HDDs but with no difference. > Though the layout of the partitions was the same (e.g. the smallest > partition I have tried is 2.7TB): > > gpart show ada0 (This is valid for all four disks) > => 34 5860533101 ada0 GPT (2.7T) > 34 6 - free - (3.0K) > 40 512 1 freebsd-boot (256K) > 552 5860532576 2 freebsd-zfs [bootme] (2.7T) > 5860533128 7 - free - (3.5K) Hi, The problem might be in your BIOS, probably if you create ZFS pool on small partitions, then it will boot. Also bootme/bootonce attributes work only with gptboot and freebsd-ufs partitions. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Tue Oct 7 11:22:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0A89748; Tue, 7 Oct 2014 11:22:07 +0000 (UTC) Received: from relaygateway02.edpnet.net (relaygateway02.edpnet.net [212.71.1.211]) by mx1.freebsd.org (Postfix) with ESMTP id 90178EE8; Tue, 7 Oct 2014 11:22:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAGjMM1TV25TV/2dsb2JhbABfgw5TWIMDyWAMh0sCgRAXAXuEAwEBAQMBAQIgBC8jEAsRAwECAQkTDgICDwUUERYOE4g2DAmsSo5YhjQBF49iEQE/EQcGgnGBVAWGK5AJgkGBSYMDAYEtg0SNGIN/giCBRTsvAYEOgTsBAQE X-IPAS-Result: AngGAGjMM1TV25TV/2dsb2JhbABfgw5TWIMDyWAMh0sCgRAXAXuEAwEBAQMBAQIgBC8jEAsRAwECAQkTDgICDwUUERYOE4g2DAmsSo5YhjQBF49iEQE/EQcGgnGBVAWGK5AJgkGBSYMDAYEtg0SNGIN/giCBRTsvAYEOgTsBAQE X-IronPort-AV: E=Sophos;i="5.04,669,1406584800"; d="scan'208";a="268820423" Received: from 213.219.148.213.adsl.dyn.edpnet.net (HELO mordor.lan) ([213.219.148.213]) by relaygateway02.edpnet.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2014 12:46:31 +0200 Date: Tue, 7 Oct 2014 13:21:47 +0200 From: Julien Cigar To: hiren panchasara Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] Message-ID: <20141007112147.GI63350@mordor.lan> References: <20141002164202.GI29361@mordor.lan> <20141002181958.GJ29361@mordor.lan> <20141003080150.GL29361@mordor.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VSaCG/zfRnOiPJtU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 11:22:07 -0000 --VSaCG/zfRnOiPJtU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 03, 2014 at 10:31:56AM -0700, hiren panchasara wrote: > On Fri, Oct 3, 2014 at 1:01 AM, Julien Cigar wrote: > > On Thu, Oct 02, 2014 at 04:36:49PM -0700, hiren panchasara wrote: > >> On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote: > >> > On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote: > >> >> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wro= te: > >> >> > sorry for cross-posting, I'm forwarding this as it seems that par= t of > >> >> > the problem is also related to: > >> >> > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/03= 9664.html > >> >> > >> >> Umm, this looks like a different problem than the subject of this e= mail. > >> > > >> > yes and no, seems the same hardware (HP and igb) and I have also some > >> > "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any > >> > reasons. I should add that the box hanged a week ago and I had to do= a > >> > hard reboot, I have the feeling that it's somewhat related to this > >> > problem .. > >> > > >> I suggest you try to debug these 2 problems separately. Did you get a > >> chance to look at kgdb to find the culprit process as I suggested > >> below? > > > > I tried what you suggested, but I get a "No struct type named inpcb" > > Any idea ? :) >=20 > Is your kernel not build with debug symbols? Can you share your kernconf? indeed.. I always disable debug symbols on the production machines this is my kernconf: https://dpaste.de/8658/raw maybe I should give 10.1-RELEASE a try now that it's out soon .. >=20 > I have following in my kernconf: >=20 > makeoptions DEBUG=3D-g > options KDB > options KDB_TRACE > options DDB >=20 > cheers, > Hiren >=20 > >> > >> cheers, > >> Hiren > >> >> > > >> >> > I also wonder if something has been fixed in -STABLE in this area= .. > >> >> > > >> >> > (please keep me in CC as I'm not subscribed on freebsd-net@ an > >> >> > freebsd-stable@) > >> >> > > >> >> > -- > >> >> > Julien Cigar > >> >> > Belgian Biodiversity Platform (http://www.biodiversity.be) > >> >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23= C0 > >> >> > No trees were killed in the creation of this message. > >> >> > However, many electrons were terribly inconvenienced. > >> >> > > >> >> > > >> >> > ---------- Forwarded message ---------- > >> >> > From: Julien Cigar > >> >> > To: freebsd-questions@freebsd.org > >> >> > Cc: > >> >> > Date: Thu, 2 Oct 2014 11:52:06 +0200 > >> >> > Subject: Listen queue overflow: 8 already in queue awaiting accep= tance > >> >> > Hello, > >> >> > > >> >> > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing= the > >> >> > following in my kernel logs: > >> >> > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 alrea= dy in > >> >> > queue awaiting acceptance > >> >> > >> >> This usually means the application is not keeping up with the incom= ing > >> >> connections. > >> >> > > >> >> > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA= | grep > >> >> > "fffff8010e561310" returns nothing > >> >> > >> >> This is the usual way of finding the culprit process. If this doesn= 't > >> >> return anything, it probably means that it is a short-lived process. > >> >> > >> >> Here is an example of what you could do: > >> >> > >> >> sonewconn: pcb 0xfffff8008f40cb10: Listen queue overflow: 1 already= in queue > >> >> awaiting acceptance > >> >> > >> >> From kgdb, > >> >> (kgdb) p ((struct inpcb *)0xfffff8008f40cb10)->inp_inc > >> >> $3 =3D {inc_flags =3D 0 '\0', inc_len =3D 0 '\0', inc_fibnum =3D 0,= inc_ie =3D {ie_fport > >> >> =3D 0, ie_lport =3D 10295, ie_dependfaddr =3D { > >> >> ie46_foreign =3D {ia46_pad32 =3D {0, 0, 0}, ia46_addr4 =3D {s= _addr =3D 0}}, > >> >> ie6_foreign =3D {__u6_addr =3D { > >> >> __u6_addr8 =3D '\0' , __u6_addr16 =3D {= 0, 0, 0, 0, 0, > >> >> 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}, > >> >> ie_dependladdr =3D {ie46_local =3D {ia46_pad32 =3D {0, 0, 0}, i= a46_addr4 =3D > >> >> {s_addr =3D 0}}, ie6_local =3D {__u6_addr =3D { > >> >> __u6_addr8 =3D '\0' , __u6_addr16 =3D {= 0, 0, 0, 0, 0, > >> >> 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}}} > >> >> > >> >> Here, ie_lport =3D 10295 which is in n/w byte order and converting = it to host > >> >> byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which= is 14120. > >> >> > >> >> Now, use sockstat to find out what process is on that port: > >> >> > >> >> $ sockstat -l | grep 14120 > >> >> > >> >> cheers, > >> >> Hiren > >> > > >> > -- > >> > Julien Cigar > >> > Belgian Biodiversity Platform (http://www.biodiversity.be) > >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > >> > No trees were killed in the creation of this message. > >> > However, many electrons were terribly inconvenienced. > > > > -- > > Julien Cigar > > Belgian Biodiversity Platform (http://www.biodiversity.be) > > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > > No trees were killed in the creation of this message. > > However, many electrons were terribly inconvenienced. --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --VSaCG/zfRnOiPJtU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJUM8zLAAoJEAi2KiTKQR5pRKUQALrPkS3bp0m0eQsZW5x0kH8L B3Mvkenq2GlaK8F5WtrQCwMsjoTyDrI2AOZ959nal2zOKY+ZxlF9b0F+Umjz25Pc XkgdMJdCKcQ/LRicfz2EzYUzfygcYA4DB8OOc3O+12Oaz/J75s/AeFUoo54gjRb8 ylAlfGWkos+dr6xp/Sws6k+G2WYTYNehirdrx+RsKg+6wDvlOH47gMvqiIb8c3FR RvSZ3BxDRpLZRkkNMlPgs/fAXxuK80mwgTEW3DAomr50GyuN15Dnr9B6Hoybyvfr ngCs0gXVyaK06RLnGTS9jn9FAeOWPOd4ok6ChRZMPx/3FwRhpfK5zHcNGpowq3u1 zbYgRCuSAH+QTY+nfOW4O/jjaQ5goGOiOcSHtr0azHaMNW8KfHmXu/AeG+xqPP7y tYXj4Xx4nl5kmhyscROcRjng+cRA1EXWnuU+moUhgaDU2sBIv8o/JvjY642poNHu njjr37Ya7o7nFZ4iQ73PWgG20bQOlFp0Knk8hCkIWjohQVRiQIZ3tZw7VCOK3dI3 DuwdGI13Oe54tJIUG1iMlxgOC0ZyDK9EKJeIZ9T4odrRO+kYcQbOjMj3Mv3Qj5/8 O20+43aa27XgwHEOyycNRycA4Czf0so8UKMpFpmw9u3m5jQD5r7MC1xu67PLBmEc mBbrpxpTcPVabVnFh0WE =+Pub -----END PGP SIGNATURE----- --VSaCG/zfRnOiPJtU-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 7 16:13:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 496252F6 for ; Tue, 7 Oct 2014 16:13:25 +0000 (UTC) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09D7B86F for ; Tue, 7 Oct 2014 16:13:24 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id i50so5617700qgf.6 for ; Tue, 07 Oct 2014 09:13:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=73+YDm+8TsMjZVMhuf39L4rRYMR4OmzqnBmf0/eAY+M=; b=fnRpEEpm8teULIfc/13+/1tvCR3sZ+ruHoywPd5aBwYWC3Gqd0vGxA2o6EO88AKcHK 0uZE+htG3IM5XsxA8gk769TjjvjAbyeiUi6F4HvD+rGeXBwKhI7l7wTY2erVzUywhlXn gjeUMDRoZnTLu3p72278kI/0qpG3Sf2QnkGpJ0amXSI0PdtU283OMIoKZqfRXHdzDvQZ C5QH3T0e0eWgwUFr+jIsHjGOUDX8YvDMndmmcXGtrjLVo8rbEMUFctS6g9WSfDhtAUF/ qXDACY3uSJ/kAlAuJENYKr/XNnoXHmAbsJmNLSq+Z0mJQ4o1pd3+OS0uRxm5X7GBuw+Y bYJg== X-Gm-Message-State: ALoCoQkl3P7NECUoRFuAjJb5pfDDq06PYe0jnhu40qAvOg8jbdGpdpbQsgHgc+GeF3qXuxaRWXrr MIME-Version: 1.0 X-Received: by 10.224.46.6 with SMTP id h6mr5769211qaf.45.1412698398047; Tue, 07 Oct 2014 09:13:18 -0700 (PDT) Sender: daniel@otherware.org Received: by 10.140.20.248 with HTTP; Tue, 7 Oct 2014 09:13:17 -0700 (PDT) X-Originating-IP: [66.220.121.156] Date: Tue, 7 Oct 2014 09:13:17 -0700 X-Google-Sender-Auth: PL6eCz92qN7j-i_e8adm-ublkXw Message-ID: Subject: Re: USB keyboard not recognized during boot From: Daniel To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:13:25 -0000 > > > On Mon, Oct 06, 2014 at 13:59:12 -0700, Daniel wrote: > > My problem stems from not being able to use my keyboard during the geli > > password prompt for the encrypted root drive. > > > > > I have a Supermicro X10SAE, also using GELI-encrypted root ZFS. > I have found that, comical as it may seem, mashing the keyboard > during the system's initial device probing allows me to hit enter > at the password prompt (which gets printed in between some of the > USB device probes) and then enter the password properly. I'm > running on: > > FreeBSD behemoth 10.1-RC1 FreeBSD 10.1-RC1 #0 r272473: Fri Oct 3 14:56:28 > UTC 2014 root@behemoth:/usr/obj/usr/src/sys/GENERIC amd64 > > Hi Chris, thank you so much for your response. It prompted me to try again. Your suggestion failed but I revisited the BIOS settings in the hope that something would work. I found a setting called "Port 60/64 Emulation which when disabled allowed me to enter the password for encryption. (Woo-hoo!) The description in the BIOS for this setting is: "Enables I/O Port 60h/64h emulation support" I also noticed that when I do a system halt, there is a prompt to press keyboard to reboot. That also didn't work with the way things work. So, it seems to me there's a fix related to this Port 60/64 that could be done on the OS side of things. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 00:34:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAB5DEB7; Wed, 8 Oct 2014 00:34:32 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B07A1965; Wed, 8 Oct 2014 00:34:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=oKGaD4bnX6AWf2IeWTMIIbtUu9CmWuPHCo2V532FS0w=; b=WeGbWp08JcbGTZfEN5bnN5dgcM/FQkLz3dsT4rzLTgg61SHy4126RIPo5q4gLQREiDMV0gizgssAGIzalWntuJKt/RdXxihK2CYmVKAXM6B1o54jdNCl/Suz0PlaZoF1ZzfUyejnl0wBWJuP57tVXIEIYX0te14Y+/0PmEuB/FU=; Received: from [182.9.144.112] (port=47866 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XbfD4-003JJO-K1; Tue, 07 Oct 2014 18:34:31 -0600 Date: Wed, 8 Oct 2014 08:34:24 +0800 From: Erich Dollansky To: Scot Hetzel Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails Message-ID: <20141008083424.354b9d7c@X220.alogt.com> In-Reply-To: References: <20141005013247.GH1171@hub.FreeBSD.org> <20141005203401.440afc31@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Glen Barber , freebsd-jail@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Stable , freebsd-net@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 00:34:33 -0000 Hi, jails work now with lagg0 again on my machine. It seems to me that it was a specific problem of this one machine. I installed the following revisions: 272555 starting point which failed 272400 failed 272000 works 272200 works 272300 works 272400 test again and it works 272400 installing world inside the jail and it works I then went to 272672 and it also works. It might was the sequence, it might was a configuration error on my side, all I know is that it works again. I also cross-compiled a kernel for the Raspberry which also works when using the latest firmware as YAMAMOTO Shigeru suggested. Erich On Sun, 5 Oct 2014 11:38:47 -0500 Scot Hetzel wrote: > On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky > wrote: > > Hi, > > > > On Sat, 4 Oct 2014 21:32:47 -0400 > > Glen Barber wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> The first RC build of the 10.1-RELEASE release cycle is now > >> available > > > > I installed this shortly after your e-mail came. The result was the > > same as with BETA3. If you remember, I have had the problem that the > > network inside jails stopped working after I installed BETA3. The > > upgrade to RC1 did not change anything. > > > > I took now the time to investigate a bit. The result is simple. All > > works as expected until lagg becomes enabled. > > > > If I remember right, BETA1 was my last working version. > > > > I have an em and an iwn interface in the machine. I can use both of > > them without any problems. > > > > As I can reproduce this problem 100%, it might be a good idea if I > > help you to find the source of the problem. My problem would be: > > how. > > > > If somebody could tell me where to start looking for the error, we > > might find it soon. > > > You'll need to identify where in the src caused the issue for you. To > do this, you will need to identify where it was working (BETA1?). > You would then have to step thru the sources until you find the point > where it breaks. > > The easiest way would be to take the svn revision that is half way > between BETA1 and BETA3, compile and install it and see if it works. > You keep halving the result until you identify the commit that broke > it. > > Once the offending commit is identified, email the list. > From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 15:47:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF583611; Wed, 8 Oct 2014 15:47:02 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2351814D; Wed, 8 Oct 2014 15:47:01 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so11798547wgh.35 for ; Wed, 08 Oct 2014 08:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; bh=U9ah9rfY8yY9qXWT8UM58upjEKEP5/SGjx5W4F19Kpo=; b=UUjdAxHwk+6K0oayTU6vsnHFSYCDPP6kQVRLPAHJsYp/Alb9zXqa/8fknIRWkIqE/P ahgm+O9MmARLVJFxlCgmwokexGmtE29YID9xXGh7DGLmiaUXp9mAKBGiHRB4+N8y6fdU eG5MZz729Vgm9UF/IkbUccpiBlVDfOnvv/of2gxvlVpxJJi1VY4gHGJUa4+5JpBecL0H r7yxQejMfK8/Qc+YtNVpMtNAu4MIbh1liaW72A5A3d2UwewWuH+JQLc/TsdxRJ6nsW7j 2AGUdTkSH2ZrCSvBnokphCQ6ihjbm+mBA94kUax4N8aC/OG73UOPtWS82m7cplX9Nqbs 3l1w== X-Received: by 10.180.73.173 with SMTP id m13mr34623720wiv.18.1412783220095; Wed, 08 Oct 2014 08:47:00 -0700 (PDT) Received: from localhost (ns314608.ip-188-165-240.eu. [188.165.240.102]) by mx.google.com with ESMTPSA id ma8sm468914wjb.46.2014.10.08.08.46.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Oct 2014 08:46:59 -0700 (PDT) From: marekrud@gmail.com To: John Baldwin , freebsd-stable@freebsd.org Subject: Re: vt does not resume properly after zzz In-Reply-To: <2384548.yqFzOG8bcA@ralph.baldwin.cx> References: <864mvqfabt.fsf@gmail.com> <86vbo2tcrn.fsf@gmail.com> <2384548.yqFzOG8bcA@ralph.baldwin.cx> Date: Wed, 08 Oct 2014 17:47:14 +0200 Message-ID: <86d2a21s3h.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:47:02 -0000 John Baldwin writes: > On Saturday, October 04, 2014 04:24:11 PM Kevin Oberman wrote: >> On Thu, Oct 2, 2014 at 1:52 PM, wrote: >> > - DELL M1330 with Intel graphics card (Xorg used to work with intel >> > >> > driver >> >> All of the information I can find says that this unit has nVidia graphics, >> but Intel may be a low-priced option, as well. Again, /var/log/Xorg.0.log >> should have this information as should "pciconf -lv | grep -A3 vga". This >> laptop goes back to 2007, so it should be using the old UMS Intel graphics. >> It should not be using VESA, but if it is, that might point out a common >> thread. >> >> I don't know the details and the actual problem was never identified, but I >> know that some systems needed to have a kernel built with "NOOPTION VESA" >> to get it to resume. I had this problem on my Lenovo T520 (which I am using >> to send this reply). > > That doesn't apply to his system. I have an older HP netbook (i386) that > resumes fine in text mode with syscons, but does not resume in text mode in > vt(4). (This is a case where the VESA bits actually help rather than hurt.) > However, if I kldload the kms driver ('kldload i915kms') when using vt(4), > then resume works fine (and it also works fine in X). > > Marek, > > Can you try 'kldload i915kms' before you suspend and see if that fixes your > issue? 1. On the laptop with Intel graphics card, when i915kms is loaded, vt resumes without problems. On the laptop with the ATI graphics card (Radeon HD 8240), I use vesa driver at the moment, and it does not resume the screen. 2. I wanted to make sure, that the problem has nothing to do with my local system settings, so I dd'ed 10.1-RC1 image onto memory stick, added `kern.vty=vt' to /boot/loader.conf and booted both laptops with it. After they started, I suspended them, tried to resume and there was the same problem: blank screen, but system seemed to be running. (syscons resumed properly with the same method. There were problems with the USB stick and root partition, but I think that's normal and irrelevant.) Thank you! Marek From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 18:00:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3986F819 for ; Wed, 8 Oct 2014 18:00:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10DB9319 for ; Wed, 8 Oct 2014 18:00:16 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8E56EB9A1; Wed, 8 Oct 2014 14:00:14 -0400 (EDT) From: John Baldwin To: marekrud@gmail.com Subject: Re: vt does not resume properly after zzz Date: Wed, 08 Oct 2014 12:14:06 -0400 Message-ID: <1506050.d54hhbRZ6V@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <86d2a21s3h.fsf@gmail.com> References: <864mvqfabt.fsf@gmail.com> <2384548.yqFzOG8bcA@ralph.baldwin.cx> <86d2a21s3h.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 14:00:14 -0400 (EDT) Cc: Kevin Oberman , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 18:00:16 -0000 On Wednesday, October 08, 2014 05:47:14 PM marekrud@gmail.com wrote: > John Baldwin writes: > > On Saturday, October 04, 2014 04:24:11 PM Kevin Oberman wrote: > >> On Thu, Oct 2, 2014 at 1:52 PM, wrote: > >> > - DELL M1330 with Intel graphics card (Xorg used to work with intel > >> > > >> > driver > >> > >> All of the information I can find says that this unit has nVidia > >> graphics, > >> but Intel may be a low-priced option, as well. Again, /var/log/Xorg.0.log > >> should have this information as should "pciconf -lv | grep -A3 vga". This > >> laptop goes back to 2007, so it should be using the old UMS Intel > >> graphics. > >> It should not be using VESA, but if it is, that might point out a common > >> thread. > >> > >> I don't know the details and the actual problem was never identified, but > >> I > >> know that some systems needed to have a kernel built with "NOOPTION VESA" > >> to get it to resume. I had this problem on my Lenovo T520 (which I am > >> using > >> to send this reply). > > > > That doesn't apply to his system. I have an older HP netbook (i386) that > > resumes fine in text mode with syscons, but does not resume in text mode > > in > > vt(4). (This is a case where the VESA bits actually help rather than > > hurt.) However, if I kldload the kms driver ('kldload i915kms') when > > using vt(4), then resume works fine (and it also works fine in X). > > > > Marek, > > > > Can you try 'kldload i915kms' before you suspend and see if that fixes > > your > > issue? > > 1. On the laptop with Intel graphics card, when i915kms is loaded, vt > resumes without problems. On the laptop with the ATI graphics card > (Radeon HD 8240), I use vesa driver at the moment, and it does not > resume the screen. Let's just be clear: For laptop 1 with Intel graphics card: - syscons + text mode: resumes ok - syscons + X: resumes ok? - vt: blank screen - vt + i915kms + text mode: resumes ok - vt + X: resumes ok? For laptop 2 with ATI graphics card: - syscons + text mode: resumes ok - syscons + X: resumes ok? - vt + text mode: blank screen - vt + X: ??? For ATI, there is a radeonkms driver I believe. Can you try loading that when you are using vt(4) to see if it makes a difference? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 18:39:56 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 026E41EB; Wed, 8 Oct 2014 18:39:56 +0000 (UTC) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA501962; Wed, 8 Oct 2014 18:39:55 +0000 (UTC) Received: by mail-yk0-f170.google.com with SMTP id 20so4084369yks.29 for ; Wed, 08 Oct 2014 11:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; bh=TCIRo545Q8tA85WhyHJu+Kc/muxjXl7KVILUzW5ZJx4=; b=YQozP0HDL6uvH6RtiaHOe4zYs1ixRsm1DDpVBVAp/9Gg+JHQyr7ORkYvFjiSCNZBeo AalMwsXEQbAvNDIkeK8P0i+fAL22s+GAJNzm5FaobASoDvm9q18ZSOjdJWydmruW1rSE h6wBvodCDJZGzNwv7TXLnoyN9PiW3XGC1lBC7FpWIGYGsJ10H4X5LfdX4b+WNQcWvBkI 8HE5FIEUvJrZudtkn7JyOTkIO9BGBfDCs4jCb+eg02lX1ccBVuC0rbB13gC8RcdN4zjW AchETil4WjdXuke4tjGyfS4aH2H4k0CqRdS52458gCyR327zs32XO1Zoqa3MbMNmkFo/ OcNg== X-Received: by 10.236.73.42 with SMTP id u30mr5081815yhd.168.1412793594753; Wed, 08 Oct 2014 11:39:54 -0700 (PDT) Received: from localhost (wannabe.torservers.net. [96.47.226.22]) by mx.google.com with ESMTPSA id t72sm361158yho.56.2014.10.08.11.39.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Oct 2014 11:39:54 -0700 (PDT) From: marekrud@gmail.com To: John Baldwin Subject: Re: vt does not resume properly after zzz In-Reply-To: <1506050.d54hhbRZ6V@ralph.baldwin.cx> References: <864mvqfabt.fsf@gmail.com> <2384548.yqFzOG8bcA@ralph.baldwin.cx> <86d2a21s3h.fsf@gmail.com> <1506050.d54hhbRZ6V@ralph.baldwin.cx> Date: Wed, 08 Oct 2014 20:39:58 +0200 Message-ID: <86h9ze9zi9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 18:39:56 -0000 John Baldwin writes: > On Wednesday, October 08, 2014 05:47:14 PM marekrud@gmail.com wrote: >> John Baldwin writes: >> > On Saturday, October 04, 2014 04:24:11 PM Kevin Oberman wrote: >> >> On Thu, Oct 2, 2014 at 1:52 PM, wrote: >> >> > - DELL M1330 with Intel graphics card (Xorg used to work with intel >> >> > >> >> > driver >> >> >> >> All of the information I can find says that this unit has nVidia >> >> graphics, >> >> but Intel may be a low-priced option, as well. Again, /var/log/Xorg.0.log >> >> should have this information as should "pciconf -lv | grep -A3 vga". This >> >> laptop goes back to 2007, so it should be using the old UMS Intel >> >> graphics. >> >> It should not be using VESA, but if it is, that might point out a common >> >> thread. >> >> >> >> I don't know the details and the actual problem was never identified, but >> >> I >> >> know that some systems needed to have a kernel built with "NOOPTION VESA" >> >> to get it to resume. I had this problem on my Lenovo T520 (which I am >> >> using >> >> to send this reply). >> > >> > That doesn't apply to his system. I have an older HP netbook (i386) that >> > resumes fine in text mode with syscons, but does not resume in text mode >> > in >> > vt(4). (This is a case where the VESA bits actually help rather than >> > hurt.) However, if I kldload the kms driver ('kldload i915kms') when >> > using vt(4), then resume works fine (and it also works fine in X). >> > >> > Marek, >> > >> > Can you try 'kldload i915kms' before you suspend and see if that fixes >> > your >> > issue? >> >> 1. On the laptop with Intel graphics card, when i915kms is loaded, vt >> resumes without problems. On the laptop with the ATI graphics card >> (Radeon HD 8240), I use vesa driver at the moment, and it does not >> resume the screen. > > Let's just be clear: > > For laptop 1 with Intel graphics card: > - syscons + text mode: resumes ok > - syscons + X: resumes ok? > - vt: blank screen > - vt + i915kms + text mode: resumes ok > - vt + X: resumes ok? For laptop 1 with Intel graphics card: - syscons + text mode: resumes ok - syscons + X: resumes ok - vt: blank screen - vt + i915kms + text mode: resumes ok - vt + X: blank screen - vt + i915kms + X: resumes ok > For laptop 2 with ATI graphics card: > - syscons + text mode: resumes ok > - syscons + X: resumes ok? > - vt + text mode: blank screen > - vt + X: ??? For laptop 2 with ATI graphics card: - syscons + text mode: resumes ok - syscons + X: resumes ok - vt + text mode: blank screen - vt + X: blank screen > For ATI, there is a radeonkms driver I believe. Can you try loading that when > you are using vt(4) to see if it makes a difference? - vt + text mode + radeonkms: blank screen Marek From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:16:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F342CC9 for ; Wed, 8 Oct 2014 19:16:43 +0000 (UTC) Received: from artif-webmail.de (artif-webmail.de [144.76.156.78]) by mx1.freebsd.org (Postfix) with ESMTP id 135F2D59 for ; Wed, 8 Oct 2014 19:16:42 +0000 (UTC) Received: from [192.168.178.21] (port-92-193-126-51.dynamic.qsc.de [92.193.126.51]) (Authenticated sender: huerter) by artif-webmail.de (Postfix) with ESMTPA id 5F08E2E0293 for ; Wed, 8 Oct 2014 21:16:41 +0200 (CEST) Message-ID: <54358D99.5090403@guckux.de> Date: Wed, 08 Oct 2014 21:16:41 +0200 From: Stefan Huerter Reply-To: maulwurf@guckux.de User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: LSI 1030 and LTO-3 won't work Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:16:43 -0000 Guckux I have problems with following configuration: FreeBSD whisky 10.1-RC1 FreeBSD 10.1-RC1 #0 r272711M: Tue Oct 7, LSILogic 1030 Ultra4 Adapter Sun StorEdge C2 - LTO-3 library I've included the mpt-module to load at boot time in loader.conf. part from dmesg: mpt0: port 0xc400-0xc4ff mem 0xff9a0000-0xff9bffff,0xff980000-0xff99ffff irq 23 at device 2.0 on pci5 mpt0: MPI Version=1.2.14.0 mpt1: port 0xc800-0xc8ff mem 0xff9c0000-0xff9dffff irq 20 at device 2.1 on pci5 mpt1: MPI Version=1.2.14.0 (sa0:mpt0:0:5:0): 32768-byte tape record bigger than supplied buffer (sa0:mpt0:0:5:0): 32768-byte tape record bigger than supplied buffer I've tried to resize the blocksize to 10240 via mt blocksize 10240. Nothing works - dump and tar... dump reports shortly, that the End of tape is detected, tar reports "write error". With the same controller no Problem with Backup Exec under Windows, or Solaris with EMC networker. Hugh? Any hints for me? Or can I give you some other informations, which you need? Thx in advance Bye Stefan From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E7D615F; Wed, 8 Oct 2014 19:30:53 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79571E7A; Wed, 8 Oct 2014 19:30:53 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 81F4BB9B0; Wed, 8 Oct 2014 15:30:52 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Lock scsi_low, ct(4), ncv(4), nsp(4), stg(4): test or these drivers will be removed Date: Wed, 08 Oct 2014 14:59:19 -0400 Message-ID: <3043229.M27y2ykeNt@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:52 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:53 -0000 This patch adds locking to the scsi_low subsystem and the drivers that use it: ct(4), ncv(4), nsp(4), and stg(4). The drivers are all marked MPSAFE. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/scsi_low_locking.patch Note that these drivers are using a deprecated API that will be removed in 11. If no one tests updates to these drivers then it is not feasible to continue maintaining them in the tree. In that case, they will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FA131F5 for ; Wed, 8 Oct 2014 19:30:54 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 378A1E7B for ; Wed, 8 Oct 2014 19:30:54 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C644B9BB for ; Wed, 8 Oct 2014 15:30:53 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Lock spic(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:57:49 -0400 Message-ID: <2820270.ZoPxhjeYmv@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:53 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:54 -0000 This patch adds locking to spic(4) and marks it MPSAFE. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/spic_locking.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D6C5145 for ; Wed, 8 Oct 2014 19:30:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08FEAE76 for ; Wed, 8 Oct 2014 19:30:52 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 09B57B99A for ; Wed, 8 Oct 2014 15:30:51 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Convert some timers in isp(4) from timeout(9) to callout(9) Date: Wed, 08 Oct 2014 15:02:23 -0400 Message-ID: <1927168.M9YyXzXvZZ@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:51 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:52 -0000 This patch converts a few timers in isp(4) from timeout(9) to callout(9). It already used callout(9) for normal command timeouts. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/isp_callout.patch Note that I believe that this patch only affects the target mode of isp(4), so simply testing it as an HBA probably doesn't not exercise these code paths. I would still welcome testing as an HBA to ensure there are no regressions. If no one tests these I will not remove this driver. I may remove the target code if it is easily separable however. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A82F47C for ; Wed, 8 Oct 2014 19:30:58 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 056EBE82 for ; Wed, 8 Oct 2014 19:30:58 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E5C60B9BB for ; Wed, 8 Oct 2014 15:30:56 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Fix callouts in rp(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:52:29 -0400 Message-ID: <2183726.56eTCFgtJQ@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:57 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:58 -0000 This patch converts rp(4) from timeout(9) to callout(9). To do this cleanly, it replaces a single, global timer that walks tables of controllers and ports to a per-controller timer. This works much better with locking (since the locks are per-controller) and removes the need for various global lookup tables in the driver. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/rp_callout.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 934AD142 for ; Wed, 8 Oct 2014 19:30:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 697ACE74 for ; Wed, 8 Oct 2014 19:30:51 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 43C64B987; Wed, 8 Oct 2014 15:30:50 -0400 (EDT) From: John Baldwin To: marekrud@gmail.com Subject: Re: vt does not resume properly after zzz Date: Wed, 08 Oct 2014 15:07:11 -0400 Message-ID: <1526283.Onb3mfWQFN@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <86h9ze9zi9.fsf@gmail.com> References: <864mvqfabt.fsf@gmail.com> <1506050.d54hhbRZ6V@ralph.baldwin.cx> <86h9ze9zi9.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:50 -0400 (EDT) Cc: Kevin Oberman , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:51 -0000 On Wednesday, October 08, 2014 08:39:58 PM marekrud@gmail.com wrote: > John Baldwin writes: > > On Wednesday, October 08, 2014 05:47:14 PM marekrud@gmail.com wrote: > >> John Baldwin writes: > >> > On Saturday, October 04, 2014 04:24:11 PM Kevin Oberman wrote: > >> >> On Thu, Oct 2, 2014 at 1:52 PM, wrote: > >> >> > - DELL M1330 with Intel graphics card (Xorg used to work with intel > >> >> > > >> >> > driver > >> >> > >> >> All of the information I can find says that this unit has nVidia > >> >> graphics, > >> >> but Intel may be a low-priced option, as well. Again, > >> >> /var/log/Xorg.0.log > >> >> should have this information as should "pciconf -lv | grep -A3 vga". > >> >> This > >> >> laptop goes back to 2007, so it should be using the old UMS Intel > >> >> graphics. > >> >> It should not be using VESA, but if it is, that might point out a > >> >> common > >> >> thread. > >> >> > >> >> I don't know the details and the actual problem was never identified, > >> >> but > >> >> I > >> >> know that some systems needed to have a kernel built with "NOOPTION > >> >> VESA" > >> >> to get it to resume. I had this problem on my Lenovo T520 (which I am > >> >> using > >> >> to send this reply). > >> > > >> > That doesn't apply to his system. I have an older HP netbook (i386) > >> > that > >> > resumes fine in text mode with syscons, but does not resume in text > >> > mode > >> > in > >> > vt(4). (This is a case where the VESA bits actually help rather than > >> > hurt.) However, if I kldload the kms driver ('kldload i915kms') when > >> > using vt(4), then resume works fine (and it also works fine in X). > >> > > >> > Marek, > >> > > >> > Can you try 'kldload i915kms' before you suspend and see if that fixes > >> > your > >> > issue? > >> > >> 1. On the laptop with Intel graphics card, when i915kms is loaded, vt > >> resumes without problems. On the laptop with the ATI graphics card > >> (Radeon HD 8240), I use vesa driver at the moment, and it does not > >> resume the screen. > > > > Let's just be clear: > > > > For laptop 1 with Intel graphics card: > > - syscons + text mode: resumes ok > > - syscons + X: resumes ok? > > - vt: blank screen > > - vt + i915kms + text mode: resumes ok > > - vt + X: resumes ok? > > For laptop 1 with Intel graphics card: > - syscons + text mode: resumes ok > - syscons + X: resumes ok > - vt: blank screen > - vt + i915kms + text mode: resumes ok > - vt + X: blank screen > - vt + i915kms + X: resumes ok Ok, this is similar to my little HP netbook where-in suspend/resume on the console without kms loaded is a regression relative to syscons. This is not trivial to fix I'm afraid, though the idea would be to take the existing VESA code for suspend and resume from syscons and port it to vt, but in a way that i915kms can disable it when it is loaded. > > For laptop 2 with ATI graphics card: > > - syscons + text mode: resumes ok > > - syscons + X: resumes ok? > > - vt + text mode: blank screen > > - vt + X: ??? > > For laptop 2 with ATI graphics card: > - syscons + text mode: resumes ok > - syscons + X: resumes ok > - vt + text mode: blank screen > - vt + X: blank screen I assume with X here that radeonkms is not being auto-loaded? (i.e. you are using the vesa driver or some such)? > > For ATI, there is a radeonkms driver I believe. Can you try loading that > > when you are using vt(4) to see if it makes a difference? > > - vt + text mode + radeonkms: blank screen Ok. You might try e-mailing dumbbell@ about the laptop with an ATI card as he is maintaining the radeonkms bits. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B990516 for ; Wed, 8 Oct 2014 19:30:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9D04E83 for ; Wed, 8 Oct 2014 19:30:58 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AC001B9C2 for ; Wed, 8 Oct 2014 15:30:57 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Lock mse(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:51:19 -0400 Message-ID: <9831000.NFouVsJ1m1@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:57 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:59 -0000 This patch adds locking to mse(4) and marks it MPSAFE. It also adds some other cleanups such as using bus_*() instead of bus_space_*() and consolidating duplicate copies of its detach routine. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/mse_locking.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:55 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23D7B2B3 for ; Wed, 8 Oct 2014 19:30:55 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F38F9E7C for ; Wed, 8 Oct 2014 19:30:54 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 14DCAB99A for ; Wed, 8 Oct 2014 15:30:54 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Various fixes to wl(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:56:58 -0400 Message-ID: <2088717.MBgzFlH7D4@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:54 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:55 -0000 This patch fixes various issues in wl(4) including: - Use bus_space instead of inb/outb. - Use device_printf() and if_printf() - Use callout(9) instead of timeout(9) - Don't hold the driver lock across sleeping actions like bus_teardown_intr(), subyte(), etc. - Don't recurse on the driver lock. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/wl_cleanup.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:56 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96B7A3DD for ; Wed, 8 Oct 2014 19:30:56 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 713E7E7E for ; Wed, 8 Oct 2014 19:30:56 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6714FB9B0 for ; Wed, 8 Oct 2014 15:30:55 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Lock wds(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:54:23 -0400 Message-ID: <2281372.1jzHLaaoQJ@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:55 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:56 -0000 This patch adds locking to wds(4) and marks it MPSAFE. It also includes several other cleanups such as using bus_space instead of inb/outb. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/wds_locking.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:31:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F04A807 for ; Wed, 8 Oct 2014 19:31:01 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A624E87 for ; Wed, 8 Oct 2014 19:31:01 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2D456B987 for ; Wed, 8 Oct 2014 15:31:00 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Add locking to mcd(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:43:02 -0400 Message-ID: <6451527.hhbda82NYX@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:31:00 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:31:01 -0000 This patch adds locking to mcd(4) and marks it MPSAFE. This patch is against HEAD but probably applies to 9 and 10 as well. Please enable INVARIANTS while testing. http://www.FreeBSD.org/~jhb/patches/mcd_locking.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:31:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D89F68D7 for ; Wed, 8 Oct 2014 19:31:01 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B26ABE88 for ; Wed, 8 Oct 2014 19:31:01 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BE339B9A1 for ; Wed, 8 Oct 2014 15:31:00 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Replace timeout(9) with callout(9) in ips(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:30:54 -0400 Message-ID: <5359207.JB6qLMnRIW@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:31:00 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:31:01 -0000 This patch converts the ips(4) driver to the callout(9) API and adds additional locking to remove its use of Giant. The patch is against HEAD but probably applies to 9 and 10 as well. Please test with INVARIANTS enabled. http://www.FreeBSD.org/~jhb/patches/ips_callout.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:31:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A5A26FB for ; Wed, 8 Oct 2014 19:31:00 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 654F9E86 for ; Wed, 8 Oct 2014 19:31:00 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 74C04B99A for ; Wed, 8 Oct 2014 15:30:59 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Add locking to mly(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:44:13 -0400 Message-ID: <37266377.aTAjsx0psn@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:59 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:31:00 -0000 This patch adds locking to mly(4) and marks it MPSAFE. This patch is against HEAD but probably applies to 9 and 10 as well. Please enable INVARIANTS while testing. http://www.FreeBSD.org/~jhb/patches/mly_locking.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07E0614A for ; Wed, 8 Oct 2014 19:30:53 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8A73E79 for ; Wed, 8 Oct 2014 19:30:52 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BE482B9A1 for ; Wed, 8 Oct 2014 15:30:51 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Add locking to iir(4): test or the driver will be removed Date: Wed, 08 Oct 2014 14:59:57 -0400 Message-ID: <4502575.2pjX9fa7nd@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:51 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:53 -0000 This patch fixes various issues in the iir(4) driver and adds locking to make it MPSAFE. The patch is against HEAD though I expect it probably applies to 9 and 10 as well. Please test with INVARIANTS enabled. http://www.FreeBSD.org/~jhb/patches/iir_locking.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:30:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C80F0619 for ; Wed, 8 Oct 2014 19:30:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A004BE84 for ; Wed, 8 Oct 2014 19:30:59 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86C7FB9A1 for ; Wed, 8 Oct 2014 15:30:58 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: [PATCH] Switch pst(4) to callout(9): test or the driver will be removed Date: Wed, 08 Oct 2014 14:48:36 -0400 Message-ID: <13804039.OhSEeCZFjP@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:58 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:30:59 -0000 This patch switches the pst(4) driver from timeout(9) to callout(9). It also cleans up detach a bit. The patch is against HEAD but probably applies to 9 and 10. Please test with INVARIANTS enabled. http://www.FreeBSD.org/~jhb/patches/pst_callout.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 8 19:46:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B79CD6C8; Wed, 8 Oct 2014 19:46:18 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E5B7226; Wed, 8 Oct 2014 19:46:18 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cc10so12978267wib.0 for ; Wed, 08 Oct 2014 12:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; bh=Vygb0oW0KYrokKaYbpuPQkbxB1no3UgL/VX2OaKUX0E=; b=w+z7WuQJiWKig1HTly4lY/jraaTU6BpLE8tPX6+EuINNdHquheB5VpL4iZxZlpQaEs 8ANjoXUgt4lGO0zJgNS4RqtzQPBHAFzQCp6YB5WoNFhvoFvbapb9v/Khs1UY+u+OA+y6 IdMVZlZhHzZs7DXxewACcMJLJkCmjlAID8epVbZ3sQcZ2SuZ58rebH9CL5Su12sa1xAc knHmwxCTne0lg0XN9fOTtaUYeD3IXWytyXVkOvDM6fKbbHnK898zNJfoib6akmMjcciO hz5vqNXpWUanMivIwKQNi/IYFjTUtY0Dx/fg2n6Yq/9aYIonidOnVUSF1ZqAR+Qr4pIr /rjw== X-Received: by 10.194.249.164 with SMTP id yv4mr14042731wjc.34.1412797576408; Wed, 08 Oct 2014 12:46:16 -0700 (PDT) Received: from localhost (ns314608.ip-188-165-240.eu. [188.165.240.102]) by mx.google.com with ESMTPSA id y5sm3204198wix.10.2014.10.08.12.46.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Oct 2014 12:46:15 -0700 (PDT) From: marekrud@gmail.com To: John Baldwin Subject: Re: vt does not resume properly after zzz In-Reply-To: <1526283.Onb3mfWQFN@ralph.baldwin.cx> References: <864mvqfabt.fsf@gmail.com> <1506050.d54hhbRZ6V@ralph.baldwin.cx> <86h9ze9zi9.fsf@gmail.com> <1526283.Onb3mfWQFN@ralph.baldwin.cx> Date: Wed, 08 Oct 2014 21:46:29 +0200 Message-ID: <86d2a29wfe.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:46:18 -0000 John Baldwin writes: > On Wednesday, October 08, 2014 08:39:58 PM marekrud@gmail.com wrote: >> John Baldwin writes: >> > On Wednesday, October 08, 2014 05:47:14 PM marekrud@gmail.com wrote: >> >> John Baldwin writes: >> >> > On Saturday, October 04, 2014 04:24:11 PM Kevin Oberman wrote: >> >> >> On Thu, Oct 2, 2014 at 1:52 PM, wrote: >> >> >> > - DELL M1330 with Intel graphics card (Xorg used to work with intel >> >> >> > >> >> >> > driver >> >> >> >> >> >> All of the information I can find says that this unit has nVidia >> >> >> graphics, >> >> >> but Intel may be a low-priced option, as well. Again, >> >> >> /var/log/Xorg.0.log >> >> >> should have this information as should "pciconf -lv | grep -A3 vga". >> >> >> This >> >> >> laptop goes back to 2007, so it should be using the old UMS Intel >> >> >> graphics. >> >> >> It should not be using VESA, but if it is, that might point out a >> >> >> common >> >> >> thread. >> >> >> >> >> >> I don't know the details and the actual problem was never identified, >> >> >> but >> >> >> I >> >> >> know that some systems needed to have a kernel built with "NOOPTION >> >> >> VESA" >> >> >> to get it to resume. I had this problem on my Lenovo T520 (which I am >> >> >> using >> >> >> to send this reply). >> >> > >> >> > That doesn't apply to his system. I have an older HP netbook (i386) >> >> > that >> >> > resumes fine in text mode with syscons, but does not resume in text >> >> > mode >> >> > in >> >> > vt(4). (This is a case where the VESA bits actually help rather than >> >> > hurt.) However, if I kldload the kms driver ('kldload i915kms') when >> >> > using vt(4), then resume works fine (and it also works fine in X). >> >> > >> >> > Marek, >> >> > >> >> > Can you try 'kldload i915kms' before you suspend and see if that fixes >> >> > your >> >> > issue? >> >> >> >> 1. On the laptop with Intel graphics card, when i915kms is loaded, vt >> >> resumes without problems. On the laptop with the ATI graphics card >> >> (Radeon HD 8240), I use vesa driver at the moment, and it does not >> >> resume the screen. >> > >> > Let's just be clear: >> > >> > For laptop 1 with Intel graphics card: >> > - syscons + text mode: resumes ok >> > - syscons + X: resumes ok? >> > - vt: blank screen >> > - vt + i915kms + text mode: resumes ok >> > - vt + X: resumes ok? >> >> For laptop 1 with Intel graphics card: >> - syscons + text mode: resumes ok >> - syscons + X: resumes ok >> - vt: blank screen >> - vt + i915kms + text mode: resumes ok >> - vt + X: blank screen >> - vt + i915kms + X: resumes ok > > Ok, this is similar to my little HP netbook where-in suspend/resume on the > console without kms loaded is a regression relative to syscons. This is not > trivial to fix I'm afraid, though the idea would be to take the existing VESA > code for suspend and resume from syscons and port it to vt, but in a way that > i915kms can disable it when it is loaded. > >> > For laptop 2 with ATI graphics card: >> > - syscons + text mode: resumes ok >> > - syscons + X: resumes ok? >> > - vt + text mode: blank screen >> > - vt + X: ??? >> >> For laptop 2 with ATI graphics card: >> - syscons + text mode: resumes ok >> - syscons + X: resumes ok >> - vt + text mode: blank screen >> - vt + X: blank screen > > I assume with X here that radeonkms is not being auto-loaded? (i.e. you are > using the vesa driver or some such)? Yes, using vesa. >> > For ATI, there is a radeonkms driver I believe. Can you try loading that >> > when you are using vt(4) to see if it makes a difference? >> >> - vt + text mode + radeonkms: blank screen > > Ok. You might try e-mailing dumbbell@ about the laptop with an ATI card as he > is maintaining the radeonkms bits. Thank you, I'll try that. Marek From owner-freebsd-stable@FreeBSD.ORG Thu Oct 9 04:08:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 802FF7A6 for ; Thu, 9 Oct 2014 04:08:12 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BD4CC79 for ; Thu, 9 Oct 2014 04:08:11 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id s993mJcI030528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Oct 2014 21:48:19 -0600 (MDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id s993mJts030527; Wed, 8 Oct 2014 21:48:19 -0600 (MDT) (envelope-from ken) Date: Wed, 8 Oct 2014 21:48:19 -0600 From: "Kenneth D. Merry" To: Stefan Huerter Subject: Re: LSI 1030 and LTO-3 won't work Message-ID: <20141009034819.GA30406@mithlond.kdm.org> References: <54358D99.5090403@guckux.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54358D99.5090403@guckux.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Wed, 08 Oct 2014 21:48:19 -0600 (MDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 04:08:12 -0000 On Wed, Oct 08, 2014 at 21:16:41 +0200, Stefan Huerter wrote: > Guckux > > I have problems with following configuration: > FreeBSD whisky 10.1-RC1 FreeBSD 10.1-RC1 #0 r272711M: Tue Oct 7, > LSILogic 1030 Ultra4 Adapter > Sun StorEdge C2 - LTO-3 library > > I've included the mpt-module to load at boot time in loader.conf. > > part from dmesg: > mpt0: port 0xc400-0xc4ff mem > 0xff9a0000-0xff9bffff,0xff980000-0xff99ffff irq 23 at device 2.0 on pci5 > mpt0: MPI Version=1.2.14.0 > mpt1: port 0xc800-0xc8ff mem > 0xff9c0000-0xff9dffff irq 20 at device 2.1 on pci5 > mpt1: MPI Version=1.2.14.0 > > (sa0:mpt0:0:5:0): 32768-byte tape record bigger than supplied buffer > (sa0:mpt0:0:5:0): 32768-byte tape record bigger than supplied buffer > > I've tried to resize the blocksize to 10240 via mt blocksize 10240. > > Nothing works - dump and tar... > dump reports shortly, that the End of tape is detected, tar reports > "write error". > > With the same controller no Problem with Backup Exec under Windows, or > Solaris with EMC networker. > > Hugh? > Any hints for me? Or can I give you some other informations, which you need? The error messages above usually indicate that you're trying to read a block from the tape (in this case a 32K block) that is bigger than the blocksize that you specified. But it can also happen on a write to a tape when you're in fixed block mode and you try to write less than the blocksize. What does 'mt status' show? If it shows 32KB blocks, then that may be your problem. What blocksize are you using with tar and dump? (I believe they default to 10240 bytes.) It's generally easier to run in variable blocksize mode. You can specify variable blocksize with 'mt blocksize 0'. You can verify which mode you're in with 'mt status'. For instance, this tape drive is in variable block mode: Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 0xff ---------available modes--------- 0: 0x5a:LTO-6 variable 384607 0xff 1: 0x5a:LTO-6 variable 384607 0xff 2: 0x5a:LTO-6 variable 384607 0xff 3: 0x5a:LTO-6 variable 384607 0xff --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count -1 I would try something like this: mt rewind mt blocksize 0 mt status (verify that it says variable block mode) dump -C 16 -b 64 -0ua -f /dev/nsa0 / That specifies: - 16MB read cache size (for reading the disk) - 64K output blocksize - level 0 dump - update /etc/dumpdates - write until the end of tape - use the non-rewound tape device - dump the root partition It is generally better to write to the tape drive with the largest blocksize that your tape drive and controller support. You'll get better throughput that way. The tape driver in FreeBSD 10 will not allow you to read or write a blocksize that your drive and controller don't support. To see what they support, try: sysctl kern.cam.sa.0 maxio is the what we think you can effectively write given the limits of the system and the controller. cpi_maxio is what the controller claims to support. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-stable@FreeBSD.ORG Thu Oct 9 05:23:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5E2B4EE for ; Thu, 9 Oct 2014 05:23:32 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C104C39F for ; Thu, 9 Oct 2014 05:23:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=FSsz5kj+TZ7Ow5Fl9NUasFIY9MMEIj7ifnJdK7j8B0U=; b=lKhTPurDLwTEFewPTpvx5DSDmNz20eY9yPlV/K7AqBKs/ElhlT4pXQC9fFZ6eDZq6iWjIpqM/ovJBQV42P3XvfiOIcTZ3p7gtlN4qN2iPHTdMGoegUfi3gYr12m3/52r9lrYdtEQDZLW3EWQcqnkLJemITkhAXBHAlRm2betGtk=; Received: from [182.4.89.165] (port=63836 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xc6CD-000vnr-44 for freebsd-stable@freebsd.org; Wed, 08 Oct 2014 23:23:25 -0600 Date: Thu, 9 Oct 2014 13:23:21 +0800 From: Erich Dollansky To: freebsd-stable@freebsd.org Subject: fsck after recovery, journal seems to be wrong Message-ID: <20141009132321.25e91ead@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 05:23:33 -0000 Hi, my machine rebooted last night while doing a backup and formating a device. Ok, can happen, but the difference between an fsck useing the journal and a full fsck without using the journal surprises me a bit. While fsck with the journal showed no error, a full fsck came to this result: ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y uname -a says: FreeBSD X220.alogt.com 10.1-RC1 FreeBSD 10.1-RC1 #8 r272672: Tue Oct 7 14:35:32 WITA 2014 erich@X220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 I did not realise any damage until just now when I found one file missing. This made me doing the fsckes. At the end, I also found the missing file under a different name in the proper directory. It could have been that the machine crashed while kate was trying to save this file and left it with the extention cppgh6857.new. It seems that nothing is missing from the file. Erich PS: The full information: [X220]/usr (root) > fsck -t ufs /dev/label/H500GB2home.eli ** /dev/label/H500GB2home.eli USE JOURNAL? [yn] y ** SU+J Recovering /dev/label/H500GB2home.eli ** Reading 33554432 byte journal from inode 27. [X220]/usr (root) > fsck -t ufs /dev/label/H500GB2home.eli ** /dev/label/H500GB2home.eli USE JOURNAL? [yn] y ** SU+J Recovering /dev/label/H500GB2home.eli ** Reading 33554432 byte journal from inode 27. ======================= fsck -t ufs /dev/label/H500GB2home.eli ** /dev/label/H500GB2home.eli USE JOURNAL? [yn] y ** SU+J Recovering /dev/label/H500GB2home.eli ** Reading 33554432 byte journal from inode 27. RECOVER? [yn] y ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ***** FILE SYSTEM MARKED CLEAN ***** [X220]/usr (root) > fsck -t ufs /dev/label/H500GB2home.eli ** /dev/label/H500GB2home.eli USE JOURNAL? [yn] n ** Skipping journal, falling through to full fsck ** Last Mounted on /usr/home ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 2799785 files, 87344020 used, 12632063 free (131743 frags, 1562540 blocks, 0.1% fragmentation) ***** FILE SYSTEM IS CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** From owner-freebsd-stable@FreeBSD.ORG Thu Oct 9 07:35:11 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 700F2B42 for ; Thu, 9 Oct 2014 07:35:11 +0000 (UTC) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F25C1DC for ; Thu, 9 Oct 2014 07:35:10 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id q107so832809qgd.4 for ; Thu, 09 Oct 2014 00:35:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QugJWqUP3L6LYV4UXWeoxMt9bB9Uygdfu0nle6GflDg=; b=Kbrne4RypyzY+BPZA4ZcdXAMCyEypKwK/VOgO9qvHwTb7cX6EnZH1nRh16tjMBWGeB hi9FUGrdvCDh9mPrNsUE93UL8CaBNSI5JI/1OdCz9KxvjM4YwC43dV6MhhgwKpKB2R5J TZS8haIB9uZsEtDznPejJ8Q7/DZLRGQcAirYI0PUqg26gWJ7DT6HFSrV0QMCghipuAwt WYBW1G6exfbbLutDAyr990WXuSxnzv2g8aqpxhRMt1mX9E2Vc37mOzKpFq5IJZ6jBwOv RsfViL1LtA1UY6waJ0+Ts6mhC2I9KK1nJOVJ6vBt0ZwGxHkkF3mYs3Hounsad3qfNG2A 9UBg== X-Gm-Message-State: ALoCoQlGFw4DfjIJyBAo2u23uhyiznkATM93Kx/iCJUbRJcpoaQVJv6Xqf2Phj7XJBiuJ2qKZ0c9 MIME-Version: 1.0 X-Received: by 10.224.23.131 with SMTP id r3mr20950235qab.90.1412840103121; Thu, 09 Oct 2014 00:35:03 -0700 (PDT) Received: by 10.140.233.142 with HTTP; Thu, 9 Oct 2014 00:35:03 -0700 (PDT) In-Reply-To: <5433B56D.3060904@yandex.ru> References: <54332AC3.4090606@delphij.net> <5433B56D.3060904@yandex.ru> Date: Thu, 9 Oct 2014 10:35:03 +0300 Message-ID: Subject: Re: Booting from ZFS - fail. From: Stefan Lambrev To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: stable@freebsd.org, d X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 07:35:11 -0000 Hi, I have tried with 5G partitions: gpart add -s 5g -a 4k -t freebsd-zfs -l disk0 ada0 ( I have four disks with raidz) Same issue ... I'm little puzzled as I know people runnign the same configuration on same HW except the HDDs. Even firmware versions are the same. On Tue, Oct 7, 2014 at 12:42 PM, Andrey V. Elsukov wrote: > On 07.10.2014 11:14, Stefan Lambrev wrote: > > Hi, > > > > I have tested with a mirror from just 2x3TB HDDs but with no difference. > > Though the layout of the partitions was the same (e.g. the smallest > > partition I have tried is 2.7TB): > > > > gpart show ada0 (This is valid for all four disks) > > => 34 5860533101 ada0 GPT (2.7T) > > 34 6 - free - (3.0K) > > 40 512 1 freebsd-boot (256K) > > 552 5860532576 2 freebsd-zfs [bootme] (2.7T) > > 5860533128 7 - free - (3.5K) > > Hi, > > The problem might be in your BIOS, probably if you create ZFS pool on > small partitions, then it will boot. > > Also bootme/bootonce attributes work only with gptboot and freebsd-ufs > partitions. > > -- > WBR, Andrey V. Elsukov > From owner-freebsd-stable@FreeBSD.ORG Thu Oct 9 14:07:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C3115C7; Thu, 9 Oct 2014 14:07:11 +0000 (UTC) Received: from mail.beastielabs.net (unknown [IPv6:2001:888:1227:0:200:24ff:fec9:5934]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52B971B9; Thu, 9 Oct 2014 14:07:11 +0000 (UTC) Received: from beastie.hotsoft.nl (beastie.hotsoft.nl [IPv6:2001:888:1227:0:219:d1ff:fee8:91eb]) by mail.beastielabs.net (8.14.7/8.14.7) with ESMTP id s99E73kD071133; Thu, 9 Oct 2014 16:07:03 +0200 (CEST) (envelope-from hans@beastielabs.net) Message-ID: <54369687.5020807@beastielabs.net> Date: Thu, 09 Oct 2014 16:07:03 +0200 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Media image names - Document & rationalise. References: <201410011358.s91DwOXJ033137@fire.js.berklix.net> <88376822.lFZdKxbhSR@ralph.baldwin.cx> <54333019.9010304@egr.msu.edu> In-Reply-To: <54333019.9010304@egr.msu.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Glen Barber , Adam McDougall X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 14:07:11 -0000 On 10/07/14 02:13, Adam McDougall wrote: > On 10/06/2014 16:34, John Baldwin wrote: >> I believe the issue here as I discussed with Marcel last year is that the x86 >> installer needs to tell gpart to set the active flag on the dummy MBR slice in >> the PMBR if GPT is being used without EFI (the installer knows if it is booted >> via EFI or not). > > I ran into this today too with 10.1-RC1 (and recent 11 I think) on a > BIOS based desktop freshly liberated from windows. It would not boot. > I got it going with gpart but as a new user I'd be in trouble. > This is exactly what I see with my oldish Intel DP965LT main board. Installation went perfect up to 9.2, but for later releases I have to issue /sbin/gpart set -a active ada0 either from a shell before rebooting the fresh installation or after rebooting single user from the install media. I also hear from several acquaintances (potential "switchers"), often with similar Intel (or Foxconn) boards that their fresh install of FreeBSD "does not even boot". On the other hand my even older Asus NL4VM-DH board does not have this issue (It does complain about being unable to read the backup GPT header, but that is another issue.) If it is not possible to have the installer set the active flag when a BIOS is detected, the remedy using gpart could at least be documented in the installation notes, maybe even in the handbook. >> >> In 9.2 and older, the flag was always set, but that violated the EFI spec and >> broke several systems, so in 9.3 and later, gpart was changed to not set the >> flag by default. However, we should still set it for non-EFI booting via GPT >> to cater to broken BIOSes (such as yours). >> Kind regards, Hans From owner-freebsd-stable@FreeBSD.ORG Thu Oct 9 15:23:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7249A1CD; Thu, 9 Oct 2014 15:23:40 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D82D2DA9; Thu, 9 Oct 2014 15:23:39 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so1591989wgg.20 for ; Thu, 09 Oct 2014 08:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5GVxhhjMS1KkGcMg9/iQOhXftDY0i6mNGo5q4w5plPI=; b=EyFQkwuN9A6Z61JkLRRUqo8UJbdM0ZHuyQq20HeQRN0KBSebZicRsri+LqfrkWc1lx kxZPTz76qQLtyU4r8ma265Y5ZlyTe99ycrn2y3xoXUN2I5+XMXdYTY8yjgL38ISM4Tr2 bLDdYNf08t0iRRWeH8QFijyX94vIuHdxBymEYN/bvdAxkB48lL/NlE6bFiNQTHqQbP7S yBODytxniN22p7dVtHlwc14RjTHkb7UnVJ9Bzqv2I49xj52VAHg4jr/JagqYO5SBZksA Zywv/ObQOGR7bEp+O8EeDPF15LOH9dt5l+HDiwT8mcokFrqjDzpH7/T/DWicFsPQuHwd zxYQ== MIME-Version: 1.0 X-Received: by 10.180.187.83 with SMTP id fq19mr40183327wic.59.1412868218050; Thu, 09 Oct 2014 08:23:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 9 Oct 2014 08:23:37 -0700 (PDT) In-Reply-To: <54369687.5020807@beastielabs.net> References: <201410011358.s91DwOXJ033137@fire.js.berklix.net> <88376822.lFZdKxbhSR@ralph.baldwin.cx> <54333019.9010304@egr.msu.edu> <54369687.5020807@beastielabs.net> Date: Thu, 9 Oct 2014 08:23:37 -0700 X-Google-Sender-Auth: wOJbYYDHuF1Cht6WinBKmT5Ahqs Message-ID: Subject: Re: Media image names - Document & rationalise. From: Adrian Chadd To: Hans Ottevanger Content-Type: text/plain; charset=UTF-8 Cc: Glen Barber , Adam McDougall , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 15:23:40 -0000 Hi! Can you bug this? http://bugs.freebsd.org/submit/ ? This is likely not the only board with this behaviour and having it in the bug system with the motherboard vendor/type will be really helpful. Thanks! -a On 9 October 2014 07:07, Hans Ottevanger wrote: > On 10/07/14 02:13, Adam McDougall wrote: >> >> On 10/06/2014 16:34, John Baldwin wrote: >>> >>> I believe the issue here as I discussed with Marcel last year is that the >>> x86 >>> installer needs to tell gpart to set the active flag on the dummy MBR >>> slice in >>> the PMBR if GPT is being used without EFI (the installer knows if it is >>> booted >>> via EFI or not). >> >> >> I ran into this today too with 10.1-RC1 (and recent 11 I think) on a >> BIOS based desktop freshly liberated from windows. It would not boot. >> I got it going with gpart but as a new user I'd be in trouble. >> > > This is exactly what I see with my oldish Intel DP965LT main board. > Installation went perfect up to 9.2, but for later releases I have to issue > > /sbin/gpart set -a active ada0 > > either from a shell before rebooting the fresh installation or after > rebooting single user from the install media. > > I also hear from several acquaintances (potential "switchers"), often with > similar Intel (or Foxconn) boards that their fresh install of FreeBSD "does > not even boot". On the other hand my even older Asus NL4VM-DH board does not > have this issue (It does complain about being unable to read the backup GPT > header, but that is another issue.) > > If it is not possible to have the installer set the active flag when a BIOS > is detected, the remedy using gpart could at least be documented in the > installation notes, maybe even in the handbook. > >>> >>> In 9.2 and older, the flag was always set, but that violated the EFI spec >>> and >>> broke several systems, so in 9.3 and later, gpart was changed to not set >>> the >>> flag by default. However, we should still set it for non-EFI booting via >>> GPT >>> to cater to broken BIOSes (such as yours). >>> > > Kind regards, > > Hans > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Oct 9 21:21:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BC08691 for ; Thu, 9 Oct 2014 21:21:21 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07E65D11 for ; Thu, 9 Oct 2014 21:21:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0060DB96E for ; Thu, 9 Oct 2014 17:21:20 -0400 (EDT) To: freebsd-stable@freebsd.org Subject: [PATCH] Fix si(4) to use bus_space: test or the driver will be removed From: John Baldwin Date: Thu, 9 Oct 2014 14:03:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201410091403.11117.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 09 Oct 2014 17:21:20 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:21:21 -0000 This patch fixes the si(4) driver to use the bus_space methods to access memory and I/O resources instead of directly calling inb()/outb() and using rman_get_virtual(). The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/si_bus_space.patch If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Oct 9 21:21:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A185668E for ; Thu, 9 Oct 2014 21:21:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EFD5D10 for ; Thu, 9 Oct 2014 21:21:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8C0FEB94C for ; Thu, 9 Oct 2014 17:21:19 -0400 (EDT) To: freebsd-stable@freebsd.org Subject: [PATCH] Lock scd(4): test or the driver will be removed From: John Baldwin Date: Thu, 9 Oct 2014 14:02:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201410091402.53853.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 09 Oct 2014 17:21:19 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:21:20 -0000 This patch adds locking to scd(4) and marks it MPSAFE. It also uses bus_*() instead of bus_space_*(). The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/scd_locking.patch Note that this driver is using a deprecated API that will be removed in 11. If no one tests updates to this driver then it is not feasible to continue maintaining it in the tree. In that case, it will be removed from HEAD one month from today. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 00:00:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9CAAA3B for ; Fri, 10 Oct 2014 00:00:11 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 44252F39 for ; Fri, 10 Oct 2014 00:00:11 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jDTtd3Mq1z2XV for ; Fri, 10 Oct 2014 02:00:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:organization:from:from:date :date:message-id:received:received:received; s=jakla4; t= 1412899204; x=1415491205; bh=Qzl/v0MuT9Y37KtDOXIROU9MTG91MQMkoKh rj31V6Cc=; b=o/jpdkcowtHeZVRfRetPz7vowXpSbZiPkrVsgPBpKgjwWnhQzKs EH8fur6D5chzEXS6wKkKSOTCLdnJ3t//EQ1EeYv04g9lhiPbAkwxrDEbogdi2oQY jVgODM7zxOpPZHQRy/kX2cwUbZWfuaJl2IHE6ppySWGkQecCjbAJzVEc= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id jVJC2NFbKIUR for ; Fri, 10 Oct 2014 02:00:04 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Fri, 10 Oct 2014 02:00:04 +0200 (CEST) Received: from sleepy.ijs.si (msleepy-1-pt.tunnel.tserv27.prg1.ipv6.he.net [IPv6:2001:470:6e:18e::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 3jDTtX13nYz1q for ; Fri, 10 Oct 2014 02:00:04 +0200 (CEST) Message-ID: <54372173.1010100@ijs.si> Date: Fri, 10 Oct 2014 01:59:47 +0200 From: Mark Martinec Organization: J. Stefan Institute User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: zfs pool import hangs on [tx->tx_sync_done_cv] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 00:00:11 -0000 In short, after upgrading to 10.1-BETA3 or -RC1 I ended up with several zfs pools that can no longer be imported. The zpool import command (with no arguments) does show all available pools, but trying to import one just hangs and the command cannot be aborted, although the rest of the system is still alive and fine: # zpool import -f Typing ^T just shows an idle process, waiting on [tx->tx_sync_done_cv]: load: 0.20 cmd: zpool 939 [tx->tx_sync_done_cv] 5723.65r 0.01u 0.02s 0% 8220k load: 0.16 cmd: zpool 939 [tx->tx_sync_done_cv] 5735.73r 0.01u 0.02s 0% 8220k load: 0.14 cmd: zpool 939 [tx->tx_sync_done_cv] 5741.83r 0.01u 0.02s 0% 8220k load: 0.13 cmd: zpool 939 [tx->tx_sync_done_cv] 5749.16r 0.01u 0.02s 0% 8220k ps shows (on a system re-booted to a LiveCD running FreeBSD-10.1-RC1): PID TID COMM TDNAME CPU PRI STATE WCHAN 939 100632 zpool - 5 122 sleep tx->tx_s UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 939 801 0 22 0 107732 8236 tx->tx_s D+ v0 0:00.04 zpool import -f -o cachefile=/tmp/zpool.cache -R /tmp/sys0boot sys0boot NWCHAN fffff8007b0f2a20 # procstat -kk 939 PID TID COMM TDNAME KSTACK 939 100632 zpool - mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d txg_wait_synced+0x85 spa_load+0x1cd1 spa_load_best+0x6f spa_import+0x1ff zfs_ioc_pool_import+0x137 zfsdev_ioctl+0x6f0 devfs_ioctl_f+0x114 kern_ioctl+0x255 sys_ioctl+0x13c amd64_syscall+0x351 Xfast_syscall+0xfb Background story: the system where this happened was being kept to a fairly recent 10-STABLE. The last upgrade was very close to a BETA3 release. There are a couple of zfs pools there, one on a mirrored pair of SSDs mostly holding the OS, one with a mirrored pair of large spindles, and three more small ones (4 GiB each), mostly for boot redundancy or testing - these small ones are on old smallish disks. These disks are different, and attached to different SATA controllers (LSI and onboard Intel). Pools were mostly kept up-to-date to the most recent zpool features set through their lifetime (some starting their life with 9.0, some with 10.0). About two weeks ago after a reboot to a 10-STABLE of the day the small pools became unavailable, but the regular two large pools were still normal. At first I wasn't giving much attention to that, as these pools were on oldish disks and nonessential for normal operation, blaming a potentially crappy hw. Today I needed to do a reboot (for unrelated reason), and the machine was no longer able to mount the boot pool. The first instinct was - disks are malfunctioning - but ... Booting it to a FreeBSD-10.1-RC1 LiveCD was successful. smartmon disk test shows no problems. dd is able to read whole partititions of each problematic pool. And most importantly, running a 'zdb -e -cc' on each (non-imported) pool was churning normally and steadily, producing a stats report at the end and reported no errors. As a final proof that disks are fine I sacrificed one of the broken 4 GiB GPT partitions with one of the problematic pools, and did a fresh 10.1-RC1 install on it from a distribution ISO DVD. The installation went fine and the system does boot and run fine from the newly installed OS. Trying to import one of the remaining old pools hangs the import command as before. As a final proof, I copied (with dd) one of the broken 4 GiB partitions to a file on another system (running 10.1-BETA3, which did not suffer from this problem), made a memory disk out of this file, then run zfs import on this pool - and it hangs there too! So hardware was not a problem - either these partitions are truly broken (even though zdb -cc says they are fine), or the new OS is somehow no longer able to import them. Please advise. I have a copy of the 4 GiB partition on a 400 MB compressed file available, if somebody would be willing to play with it. Also have a ktrace of the 'zpool import' command. It's last actions before it hangs are: 939 zpool RET madvise 0 939 zpool CALL madvise(0x80604e000,0x1000,MADV_FREE) 939 zpool RET madvise 0 939 zpool CALL close(0x6) 939 zpool RET close 0 939 zpool CALL ioctl(0x3,0xc0185a05,0x7fffffffbf00) 939 zpool RET ioctl -1 errno 2 No such file or directory 939 zpool CALL madvise(0x802c71000,0x10000,MADV_FREE) 939 zpool RET madvise 0 939 zpool CALL madvise(0x802ca5000,0x1000,MADV_FREE) 939 zpool RET madvise 0 939 zpool CALL ioctl(0x3,0xc0185a06,0x7fffffffbf60) 939 zpool RET ioctl 0 939 zpool CALL ioctl(0x3,0xc0185a06,0x7fffffffbf60) 939 zpool RET ioctl 0 939 zpool CALL stat(0x802c380e0,0x7fffffffbc58) 939 zpool NAMI "/tmp" 939 zpool STRU struct stat {dev=273, ino=2, mode=041777, nlink=8, uid=0, gid=0, rdev=96, atime=1412866648, stime=1412871393, ctime=1412871393, birthtime=1412866648, size=512, blksize=32768, blocks=8, flags=0x0 } 939 zpool RET stat 0 939 zpool CALL ioctl(0x3,0xc0185a02,0x7fffffffbc60) Mark From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 00:06:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46177C85 for ; Fri, 10 Oct 2014 00:06:52 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id C63D09 for ; Fri, 10 Oct 2014 00:06:51 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id D9EEA20E709A1; Fri, 10 Oct 2014 00:06:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id E65C420E7099D; Fri, 10 Oct 2014 00:06:41 +0000 (UTC) Message-ID: <644FA8299BF848E599B82D2C2C298EA7@multiplay.co.uk> From: "Steven Hartland" To: "Mark Martinec" , References: <54372173.1010100@ijs.si> Subject: Re: zfs pool import hangs on [tx->tx_sync_done_cv] Date: Fri, 10 Oct 2014 01:06:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 00:06:52 -0000 What does procstat -k -k report? ----- Original Message ----- From: "Mark Martinec" To: Sent: Friday, October 10, 2014 12:59 AM Subject: zfs pool import hangs on [tx->tx_sync_done_cv] > In short, after upgrading to 10.1-BETA3 or -RC1 I ended up with several > zfs pools that can no longer be imported. The zpool import command > (with no arguments) does show all available pools, but trying to > import one just hangs and the command cannot be aborted, although > the rest of the system is still alive and fine: > > # zpool import -f > > Typing ^T just shows an idle process, waiting on [tx->tx_sync_done_cv]: > > load: 0.20 cmd: zpool 939 [tx->tx_sync_done_cv] 5723.65r 0.01u 0.02s 0% > 8220k > load: 0.16 cmd: zpool 939 [tx->tx_sync_done_cv] 5735.73r 0.01u 0.02s 0% > 8220k > load: 0.14 cmd: zpool 939 [tx->tx_sync_done_cv] 5741.83r 0.01u 0.02s 0% > 8220k > load: 0.13 cmd: zpool 939 [tx->tx_sync_done_cv] 5749.16r 0.01u 0.02s 0% > 8220k > > ps shows (on a system re-booted to a LiveCD running FreeBSD-10.1-RC1): > > PID TID COMM TDNAME CPU PRI STATE WCHAN > 939 100632 zpool - 5 122 sleep tx->tx_s > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 939 801 0 22 0 107732 8236 tx->tx_s D+ v0 0:00.04 > zpool import -f -o cachefile=/tmp/zpool.cache -R /tmp/sys0boot sys0boot > > NWCHAN > fffff8007b0f2a20 > > # procstat -kk 939 > > PID TID COMM TDNAME KSTACK > 939 100632 zpool - mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d txg_wait_synced+0x85 spa_load+0x1cd1 > spa_load_best+0x6f spa_import+0x1ff zfs_ioc_pool_import+0x137 > zfsdev_ioctl+0x6f0 devfs_ioctl_f+0x114 kern_ioctl+0x255 sys_ioctl+0x13c > amd64_syscall+0x351 Xfast_syscall+0xfb > > > Background story: the system where this happened was being kept > to a fairly recent 10-STABLE. The last upgrade was very close to > a BETA3 release. There are a couple of zfs pools there, one on a > mirrored pair of SSDs mostly holding the OS, one with a mirrored > pair of large spindles, and three more small ones (4 GiB each), > mostly for boot redundancy or testing - these small ones are on > old smallish disks. These disks are different, and attached to > different SATA controllers (LSI and onboard Intel). Pools were > mostly kept up-to-date to the most recent zpool features set > through their lifetime (some starting their life with 9.0, some > with 10.0). > > About two weeks ago after a reboot to a 10-STABLE of the day > the small pools became unavailable, but the regular two large > pools were still normal. At first I wasn't giving much attention > to that, as these pools were on oldish disks and nonessential > for normal operation, blaming a potentially crappy hw. > > Today I needed to do a reboot (for unrelated reason), and the > machine was no longer able to mount the boot pool. > The first instinct was - disks are malfunctioning - but ... > > Booting it to a FreeBSD-10.1-RC1 LiveCD was successful. > smartmon disk test shows no problems. dd is able to read whole > partititions of each problematic pool. And most importantly, > running a 'zdb -e -cc' on each (non-imported) pool was churning > normally and steadily, producing a stats report at the end > and reported no errors. > > As a final proof that disks are fine I sacrificed one of the broken > 4 GiB GPT partitions with one of the problematic pools, and > did a fresh 10.1-RC1 install on it from a distribution ISO DVD. > The installation went fine and the system does boot and run > fine from the newly installed OS. Trying to import one of the > remaining old pools hangs the import command as before. > > As a final proof, I copied (with dd) one of the broken 4 GiB > partitions to a file on another system (running 10.1-BETA3, > which did not suffer from this problem), made a memory disk > out of this file, then run zfs import on this pool - and it hangs > there too! So hardware was not a problem - either these partitions > are truly broken (even though zdb -cc says they are fine), > or the new OS is somehow no longer able to import them. > > Please advise. > > I have a copy of the 4 GiB partition on a 400 MB compressed > file available, if somebody would be willing to play with it. > > Also have a ktrace of the 'zpool import' command. It's last > actions before it hangs are: > > 939 zpool RET madvise 0 > 939 zpool CALL madvise(0x80604e000,0x1000,MADV_FREE) > 939 zpool RET madvise 0 > 939 zpool CALL close(0x6) > 939 zpool RET close 0 > 939 zpool CALL ioctl(0x3,0xc0185a05,0x7fffffffbf00) > 939 zpool RET ioctl -1 errno 2 No such file or directory > 939 zpool CALL madvise(0x802c71000,0x10000,MADV_FREE) > 939 zpool RET madvise 0 > 939 zpool CALL madvise(0x802ca5000,0x1000,MADV_FREE) > 939 zpool RET madvise 0 > 939 zpool CALL ioctl(0x3,0xc0185a06,0x7fffffffbf60) > 939 zpool RET ioctl 0 > 939 zpool CALL ioctl(0x3,0xc0185a06,0x7fffffffbf60) > 939 zpool RET ioctl 0 > 939 zpool CALL stat(0x802c380e0,0x7fffffffbc58) > 939 zpool NAMI "/tmp" > 939 zpool STRU struct stat {dev=273, ino=2, mode=041777, > nlink=8, uid=0, gid=0, rdev=96, atime=1412866648, stime=1412871393, > ctime=1412871393, birthtime=1412866648, size=512, blksize=32768, > blocks=8, flags=0x0 } > 939 zpool RET stat 0 > 939 zpool CALL ioctl(0x3,0xc0185a02,0x7fffffffbc60) > > > Mark > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 00:56:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 104CBCBB for ; Fri, 10 Oct 2014 00:56:42 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 36F2F795 for ; Fri, 10 Oct 2014 00:56:40 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jDW7q3mq1z2sJ for ; Fri, 10 Oct 2014 02:56:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:organization :from:from:date:date:message-id:received:received:received; s= jakla4; t=1412902587; x=1415494588; bh=UoEnN6woFX9VcQxtiipWz9sOK WWaqDe0AOtdMA2BnH0=; b=icSr5QVtoiJwAj/sUbobDhNhyRPosWuNgXO6evdUB gDWTnWj64iqWHWJ1FKxp9co+IPBSONZbQgnAGqNWSyCPQdm7x8J1E/FujhXVnvT0 7sthuiRv7gmvoBEJi8fkeuavzPdGJoA5JyLwyJfwxWajl3TsH/sjcbzGdn4Q6+hM fI= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id usJnjbWJVGhz for ; Fri, 10 Oct 2014 02:56:27 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Fri, 10 Oct 2014 02:56:26 +0200 (CEST) Received: from sleepy.ijs.si (msleepy-1-pt.tunnel.tserv27.prg1.ipv6.he.net [IPv6:2001:470:6e:18e::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 3jDW7Z4Kl3z5X for ; Fri, 10 Oct 2014 02:56:26 +0200 (CEST) Message-ID: <54372EBA.1000908@ijs.si> Date: Fri, 10 Oct 2014 02:56:26 +0200 From: Mark Martinec Organization: J. Stefan Institute User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: zfs pool import hangs on [tx->tx_sync_done_cv] References: <54372173.1010100@ijs.si> <644FA8299BF848E599B82D2C2C298EA7@multiplay.co.uk> In-Reply-To: <644FA8299BF848E599B82D2C2C298EA7@multiplay.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 00:56:42 -0000 On 10/10/2014 02:06, Steven Hartland wrote: > What does procstat -k -k report? For the hung process the procstat -k -k was (as in my previous posting): # procstat -kk 939 PID TID COMM TDNAME KSTACK 939 100632 zpool - mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d txg_wait_synced+0x85 spa_load+0x1cd1 spa_load_best+0x6f spa_import+0x1ff zfs_ioc_pool_import+0x137 zfsdev_ioctl+0x6f0 devfs_ioctl_f+0x114 kern_ioctl+0x255 sys_ioctl+0x13c amd64_syscall+0x351 Xfast_syscall+0xfb For the whole system (-k -k -a) it's here (needed to re-do the experiment, the hung PID this time is 2074) PID TID COMM TDNAME KSTACK 0 100000 kernel swapper mi_switch+0xe1 sleepq_timedwait+0x3a _sleep+0x26e swapper+0x28f btext+0x2c 0 100024 kernel firmware taskq mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100026 kernel thread taskq mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100027 kernel ffs_trim taskq mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100029 kernel kqueue taskq mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100032 kernel acpi_task_0 mi_switch+0xe1 sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd fork_exit+0x9a fork_trampoline+0xe 0 100033 kernel acpi_task_1 mi_switch+0xe1 sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd fork_exit+0x9a fork_trampoline+0xe 0 100034 kernel acpi_task_2 mi_switch+0xe1 sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd fork_exit+0x9a fork_trampoline+0xe 0 100037 kernel mps0 taskq mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100039 kernel em0 que mi_switch+0xe1 sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd fork_exit+0x9a fork_trampoline+0xe 0 100040 kernel em0 txq mi_switch+0xe1 sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd fork_exit+0x9a fork_trampoline+0xe 0 100079 kernel em1 taskq mi_switch+0xe1 sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd fork_exit+0x9a fork_trampoline+0xe 0 100098 kernel mca taskq mi_switch+0xe1 sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd fork_exit+0x9a fork_trampoline+0xe 0 100099 kernel system_taskq_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100100 kernel system_taskq_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100101 kernel system_taskq_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100102 kernel system_taskq_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100103 kernel system_taskq_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100104 kernel system_taskq_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100105 kernel system_taskq_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100106 kernel system_taskq_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100110 kernel CAM taskq mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100119 kernel zio_null_issue mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100120 kernel zio_null_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100121 kernel zio_read_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100122 kernel zio_read_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100176 kernel zio_read_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100180 kernel zio_read_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100182 kernel zio_read_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100183 kernel zio_read_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100185 kernel zio_read_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100187 kernel zio_read_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100188 kernel zio_read_intr_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100189 kernel zio_read_intr_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100190 kernel zio_read_intr_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100191 kernel zio_read_intr_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100192 kernel zio_read_intr_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100193 kernel zio_read_intr_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100194 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100195 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100196 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100197 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100198 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100199 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100200 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100201 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100202 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100203 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100204 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100205 kernel zio_write_intr_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100206 kernel zio_write_intr_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100207 kernel zio_write_intr_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100208 kernel zio_write_intr_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100209 kernel zio_write_intr_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100210 kernel zio_write_intr_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100211 kernel zio_write_intr_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100212 kernel zio_write_intr_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100213 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100214 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100215 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100216 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100217 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100218 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100219 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100220 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100221 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100222 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100223 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100224 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100225 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100226 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100227 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100228 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100229 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100230 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100231 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100232 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100233 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100234 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100235 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100236 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100237 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100238 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100239 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100240 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100241 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100242 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100243 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100244 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100245 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100246 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100247 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100248 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100249 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100250 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100251 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100252 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100253 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100254 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100255 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100256 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100257 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100258 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100259 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100260 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100261 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100262 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100264 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100265 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100266 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100267 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100268 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100269 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100270 kernel zio_null_issue mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100271 kernel zio_null_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100272 kernel zio_read_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100273 kernel zio_read_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100274 kernel zio_read_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100275 kernel zio_read_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100276 kernel zio_read_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100277 kernel zio_read_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100278 kernel zio_read_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100279 kernel zio_read_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100280 kernel zio_read_intr_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100281 kernel zio_read_intr_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100282 kernel zio_read_intr_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100283 kernel zio_read_intr_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100284 kernel zio_read_intr_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100285 kernel zio_read_intr_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100286 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100287 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100288 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100289 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100290 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100291 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100292 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100293 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100294 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100295 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100296 kernel zio_write_issue_ mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100297 kernel zio_write_intr_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100298 kernel zio_write_intr_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100299 kernel zio_write_intr_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100300 kernel zio_write_intr_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100301 kernel zio_write_intr_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100302 kernel zio_write_intr_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100303 kernel zio_write_intr_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100304 kernel zio_write_intr_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100305 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100306 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100307 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100308 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100309 kernel zio_write_intr_h mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100310 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100311 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100312 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100313 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100314 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100315 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100316 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100317 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100318 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100319 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100320 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100321 kernel zio_free_issue_0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100322 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100323 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100324 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100325 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100326 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100327 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100328 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100329 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100330 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100331 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100332 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100333 kernel zio_free_issue_1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100334 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100335 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100336 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100337 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100338 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100339 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100340 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100341 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100342 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100343 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100344 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100345 kernel zio_free_issue_2 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100346 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100347 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100348 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100349 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100350 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100351 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100352 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100353 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100354 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100355 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100356 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100357 kernel zio_free_issue_3 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100358 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100359 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100360 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100361 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100362 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100363 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100364 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100365 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100366 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100367 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100368 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100369 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100370 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100371 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100372 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100373 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100374 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100375 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100376 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100377 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100378 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100379 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100380 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100381 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100382 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100383 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100384 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100385 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100386 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100387 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100388 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100389 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100390 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100391 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100392 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100393 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100394 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100395 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100396 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100397 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100398 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100399 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100400 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100401 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100402 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100403 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100404 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100405 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100406 kernel zio_free_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100407 kernel zio_claim_issue mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100408 kernel zio_claim_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100409 kernel zio_ioctl_issue mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100410 kernel zio_ioctl_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100412 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100413 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100414 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100415 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100416 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100417 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100418 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100419 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100420 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100423 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100433 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100438 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100439 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100440 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100441 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100442 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100443 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100444 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100445 kernel zil_clean mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100526 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100527 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100528 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100529 kernel zio_free_issue_4 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100530 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100531 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100532 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100533 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100534 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100535 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100536 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100537 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100538 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100539 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100540 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100541 kernel zio_free_issue_5 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100647 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100649 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100651 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100652 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100653 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100654 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100655 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100656 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100657 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100658 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100659 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100660 kernel zio_free_issue_6 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100661 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100662 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100663 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100664 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100665 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100666 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100667 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100668 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100669 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100670 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100671 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 100672 kernel zio_free_issue_7 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101449 kernel zio_free_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101450 kernel zio_claim_issue mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101451 kernel zio_claim_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101452 kernel zio_ioctl_issue mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101454 kernel zio_ioctl_intr mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101527 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101528 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101529 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101530 kernel metaslab_group_t mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101531 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 1 100002 init - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb 2 100030 cam doneq0 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 xpt_done_td+0x8e fork_exit+0x9a fork_trampoline+0xe 2 100031 cam doneq1 mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 xpt_done_td+0x8e fork_exit+0x9a fork_trampoline+0xe 2 100111 cam scanner mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 xpt_scanner_thread+0x7c fork_exit+0x9a fork_trampoline+0xe 3 100107 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b arc_reclaim_thread+0x301 fork_exit+0x9a fork_trampoline+0xe 3 100108 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b l2arc_feed_thread+0x16f fork_exit+0x9a fork_trampoline+0xe 3 100177 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+0xe 3 100181 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d zio_wait+0x5b dsl_pool_sync+0x371 spa_sync+0x530 txg_sync_thread+0x3a6 fork_exit+0x9a fork_trampoline+0xe 3 100411 zfskern trim zroot mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b trim_thread+0x9e fork_exit+0x9a fork_trampoline+0xe 3 100421 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d txg_quiesce_thread+0x39b fork_exit+0x9a fork_trampoline+0xe 3 100422 zfskern txg_thread_enter mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b txg_sync_thread+0x1dc fork_exit+0x9a fork_trampoline+0xe 3 101526 zfskern trim sys1boot mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b trim_thread+0x9e fork_exit+0x9a fork_trampoline+0xe 4 100109 sctp_iterator - mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 sctp_iterator_thread+0x69 fork_exit+0x9a fork_trampoline+0xe 5 100112 enc_daemon0 - mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 enc_daemon+0x140 fork_exit+0x9a fork_trampoline+0xe 6 100113 pagedaemon - mi_switch+0xe1 sleepq_timedwait+0x3a _sleep+0x26e vm_pageout+0x275 fork_exit+0x9a fork_trampoline+0xe 7 100114 vmdaemon - mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 vm_daemon+0x91 fork_exit+0x9a fork_trampoline+0xe 8 100115 pagezero - mi_switch+0xe1 sleepq_timedwait+0x3a _sleep+0x26e vm_pagezero+0x98 fork_exit+0x9a fork_trampoline+0xe 9 100116 bufdaemon - mi_switch+0xe1 sleepq_timedwait+0x3a _sleep+0x26e buf_daemon+0x78 fork_exit+0x9a fork_trampoline+0xe 10 100001 audit - mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d audit_worker+0xa3 fork_exit+0x9a fork_trampoline+0xe 11 100003 idle idle: cpu0 11 100004 idle idle: cpu1 11 100005 idle idle: cpu2 11 100006 idle idle: cpu3 11 100007 idle idle: cpu4 11 100008 idle idle: cpu5 11 100009 idle idle: cpu6 11 100010 idle idle: cpu7 mi_switch+0xe1 critical_exit+0x7a sched_idletd+0x1d5 fork_exit+0x9a fork_trampoline+0xe 12 100011 intr swi4: clock mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100012 intr swi4: clock 12 100013 intr swi4: clock 12 100014 intr swi4: clock 12 100015 intr swi4: clock 12 100016 intr swi4: clock 12 100017 intr swi4: clock 12 100018 intr swi4: clock 12 100019 intr swi1: netisr 0 mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100020 intr swi3: vm 12 100028 intr swi5: fast taskq mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100035 intr swi6: task queue mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100036 intr swi6: Giant task mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100038 intr irq256: mps0 mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100041 intr irq16: uhci0+ 12 100046 intr irq21: uhci1 12 100051 intr irq19: uhci2 uhc 12 100056 intr irq18: em1 ehci0 12 100061 intr irq258: hdac0 mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100062 intr irq23: uhci3 ehc mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100080 intr irq259: ahci1:ch mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100081 intr irq260: ahci1:ch mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100082 intr irq261: ahci1:ch 12 100083 intr irq262: ahci1:ch mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100084 intr irq263: ahci1:ch mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100085 intr irq264: ahci1:ch mi_switch+0xe1 ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe 12 100086 intr irq265: ahci1:6 12 100087 intr irq266: ahci1:7 12 100088 intr irq267: ahci1:8 12 100089 intr irq268: ahci1:9 12 100090 intr irq269: ahci1:10 12 100091 intr irq270: ahci1:11 12 100092 intr irq271: ahci1:12 12 100093 intr irq272: ahci1:13 12 100094 intr irq273: ahci1:14 12 100095 intr irq274: ahci1:15 12 100096 intr irq1: atkbd0 12 100097 intr swi0: uart 13 100021 geom g_event mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 g_run_events+0x4d fork_exit+0x9a fork_trampoline+0xe 13 100022 geom g_up mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 g_io_schedule_up+0xbc g_up_procbody+0x6d fork_exit+0x9a fork_trampoline+0xe 13 100023 geom g_down mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 g_io_schedule_down+0x4c g_down_procbody+0x6d fork_exit+0x9a fork_trampoline+0xe 14 100025 rand_harvestq - mi_switch+0xe1 sleepq_timedwait+0x3a msleep_spin_sbt+0x191 random_kthread+0x276 fork_exit+0x9a fork_trampoline+0xe 15 100042 usb usbus0 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100043 usb usbus0 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100044 usb usbus0 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100045 usb usbus0 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100047 usb usbus1 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100048 usb usbus1 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100049 usb usbus1 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100050 usb usbus1 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100052 usb usbus2 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100053 usb usbus2 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100054 usb usbus2 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100055 usb usbus2 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100057 usb usbus3 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100058 usb usbus3 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100059 usb usbus3 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100060 usb usbus3 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100063 usb usbus4 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100064 usb usbus4 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100065 usb usbus4 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100066 usb usbus4 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100067 usb usbus5 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100068 usb usbus5 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100069 usb usbus5 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100070 usb usbus5 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100071 usb usbus6 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100072 usb usbus6 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100073 usb usbus6 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100074 usb usbus6 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100075 usb usbus7 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100076 usb usbus7 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100077 usb usbus7 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100078 usb usbus7 mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 15 100457 usb ucom mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a fork_trampoline+0xe 16 100117 syncer - mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b sched_sync+0x6be fork_exit+0x9a fork_trampoline+0xe 17 100118 vnlru - mi_switch+0xe1 sleepq_timedwait+0x3a _sleep+0x26e vnlru_proc+0x48 fork_exit+0x9a fork_trampoline+0xe 479 100454 devd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_timedwait_sig+0x10 _cv_timedwait_sig_sbt+0x18b seltdwait+0xa4 kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 Xfast_syscall+0xfb 554 100452 syslogd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 Xfast_syscall+0xfb 750 100455 sshd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 Xfast_syscall+0xfb 808 100424 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 809 100470 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 810 100471 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 811 100472 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 812 100473 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 813 100474 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 814 100475 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 815 100476 getty - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 Xfast_syscall+0xfb 1661 100498 sshd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a seltdwait+0xae sys_poll+0x3a3 amd64_syscall+0x351 Xfast_syscall+0xfb 1664 100514 sshd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 Xfast_syscall+0xfb 1665 100425 sh - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb 2000 100477 su - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb 2001 100503 csh - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_sigsuspend+0xf4 sys_sigsuspend+0x31 amd64_syscall+0x351 Xfast_syscall+0xfb 2074 100524 zpool - mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d txg_wait_synced+0x85 spa_load+0x1cd1 spa_load_best+0x6f spa_import+0x1ff zfs_ioc_pool_import+0x137 zfsdev_ioctl+0x6f0 devfs_ioctl_f+0x114 kern_ioctl+0x255 sys_ioctl+0x13c amd64_syscall+0x351 Xfast_syscall+0xfb 2075 100430 sshd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a seltdwait+0xae sys_poll+0x3a3 amd64_syscall+0x351 Xfast_syscall+0xfb 2079 100446 sshd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 Xfast_syscall+0xfb 2080 100488 sh - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb 2081 100517 su - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb 2082 100465 csh - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_sigsuspend+0xf4 sys_sigsuspend+0x31 amd64_syscall+0x351 Xfast_syscall+0xfb 2085 100451 procstat - Mark From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 01:02:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E61F15 for ; Fri, 10 Oct 2014 01:02:51 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id F0FDD855 for ; Fri, 10 Oct 2014 01:02:49 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id D261120E709A4; Fri, 10 Oct 2014 01:02:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id BE4BC20E709A2; Fri, 10 Oct 2014 01:02:43 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Mark Martinec" , References: <54372173.1010100@ijs.si> <644FA8299BF848E599B82D2C2C298EA7@multiplay.co.uk> <54372EBA.1000908@ijs.si> Subject: Re: zfs pool import hangs on [tx->tx_sync_done_cv] Date: Fri, 10 Oct 2014 02:02:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 01:02:51 -0000 Sorry to be a pain but could you attach the full output or link it somewhere as mail has messed up the formatting :( ----- Original Message ----- From: "Mark Martinec" To: Sent: Friday, October 10, 2014 1:56 AM Subject: Re: zfs pool import hangs on [tx->tx_sync_done_cv] > On 10/10/2014 02:06, Steven Hartland wrote: > > What does procstat -k -k report? > > For the hung process the procstat -k -k was (as in my previous posting): > > # procstat -kk 939 > > PID TID COMM TDNAME KSTACK > 939 100632 zpool - mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d txg_wait_synced+0x85 spa_load+0x1cd1 > spa_load_best+0x6f spa_import+0x1ff zfs_ioc_pool_import+0x137 > zfsdev_ioctl+0x6f0 devfs_ioctl_f+0x114 kern_ioctl+0x255 sys_ioctl+0x13c > amd64_syscall+0x351 Xfast_syscall+0xfb > > > > For the whole system (-k -k -a) it's here > (needed to re-do the experiment, the hung PID this time is 2074) > > PID TID COMM TDNAME KSTACK > > 0 100000 kernel swapper mi_switch+0xe1 > sleepq_timedwait+0x3a _sleep+0x26e swapper+0x28f btext+0x2c > 0 100024 kernel firmware taskq mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100026 kernel thread taskq mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100027 kernel ffs_trim taskq mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100029 kernel kqueue taskq mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100032 kernel acpi_task_0 mi_switch+0xe1 > sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd > fork_exit+0x9a fork_trampoline+0xe > 0 100033 kernel acpi_task_1 mi_switch+0xe1 > sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd > fork_exit+0x9a fork_trampoline+0xe > 0 100034 kernel acpi_task_2 mi_switch+0xe1 > sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd > fork_exit+0x9a fork_trampoline+0xe > 0 100037 kernel mps0 taskq mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100039 kernel em0 que mi_switch+0xe1 > sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd > fork_exit+0x9a fork_trampoline+0xe > 0 100040 kernel em0 txq mi_switch+0xe1 > sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd > fork_exit+0x9a fork_trampoline+0xe > 0 100079 kernel em1 taskq mi_switch+0xe1 > sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd > fork_exit+0x9a fork_trampoline+0xe > 0 100098 kernel mca taskq mi_switch+0xe1 > sleepq_wait+0x3a msleep_spin_sbt+0x1a3 taskqueue_thread_loop+0xfd > fork_exit+0x9a fork_trampoline+0xe > 0 100099 kernel system_taskq_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100100 kernel system_taskq_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100101 kernel system_taskq_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100102 kernel system_taskq_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100103 kernel system_taskq_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100104 kernel system_taskq_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100105 kernel system_taskq_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100106 kernel system_taskq_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100110 kernel CAM taskq mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100119 kernel zio_null_issue mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100120 kernel zio_null_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100121 kernel zio_read_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100122 kernel zio_read_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100176 kernel zio_read_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100180 kernel zio_read_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100182 kernel zio_read_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100183 kernel zio_read_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100185 kernel zio_read_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100187 kernel zio_read_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100188 kernel zio_read_intr_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100189 kernel zio_read_intr_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100190 kernel zio_read_intr_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100191 kernel zio_read_intr_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100192 kernel zio_read_intr_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100193 kernel zio_read_intr_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100194 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100195 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100196 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100197 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100198 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100199 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100200 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100201 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100202 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100203 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100204 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100205 kernel zio_write_intr_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100206 kernel zio_write_intr_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100207 kernel zio_write_intr_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100208 kernel zio_write_intr_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100209 kernel zio_write_intr_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100210 kernel zio_write_intr_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100211 kernel zio_write_intr_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100212 kernel zio_write_intr_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100213 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100214 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100215 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100216 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100217 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100218 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100219 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100220 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100221 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100222 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100223 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100224 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100225 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100226 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100227 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100228 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100229 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100230 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100231 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100232 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100233 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100234 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100235 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100236 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100237 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100238 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100239 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100240 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100241 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100242 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100243 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100244 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100245 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100246 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100247 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100248 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100249 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100250 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100251 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100252 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100253 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100254 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100255 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100256 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100257 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100258 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100259 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100260 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100261 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100262 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100264 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100265 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100266 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100267 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100268 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100269 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100270 kernel zio_null_issue mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100271 kernel zio_null_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100272 kernel zio_read_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100273 kernel zio_read_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100274 kernel zio_read_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100275 kernel zio_read_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100276 kernel zio_read_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100277 kernel zio_read_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100278 kernel zio_read_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100279 kernel zio_read_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100280 kernel zio_read_intr_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100281 kernel zio_read_intr_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100282 kernel zio_read_intr_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100283 kernel zio_read_intr_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100284 kernel zio_read_intr_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100285 kernel zio_read_intr_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100286 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100287 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100288 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100289 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100290 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100291 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100292 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100293 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100294 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100295 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100296 kernel zio_write_issue_ mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100297 kernel zio_write_intr_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100298 kernel zio_write_intr_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100299 kernel zio_write_intr_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100300 kernel zio_write_intr_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100301 kernel zio_write_intr_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100302 kernel zio_write_intr_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100303 kernel zio_write_intr_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100304 kernel zio_write_intr_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100305 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100306 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100307 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100308 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100309 kernel zio_write_intr_h mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100310 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100311 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100312 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100313 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100314 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100315 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100316 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100317 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100318 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100319 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100320 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100321 kernel zio_free_issue_0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100322 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100323 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100324 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100325 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100326 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100327 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100328 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100329 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100330 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100331 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100332 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100333 kernel zio_free_issue_1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100334 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100335 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100336 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100337 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100338 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100339 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100340 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100341 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100342 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100343 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100344 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100345 kernel zio_free_issue_2 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100346 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100347 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100348 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100349 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100350 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100351 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100352 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100353 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100354 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100355 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100356 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100357 kernel zio_free_issue_3 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100358 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100359 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100360 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100361 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100362 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100363 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100364 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100365 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100366 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100367 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100368 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100369 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100370 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100371 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100372 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100373 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100374 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100375 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100376 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100377 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100378 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100379 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100380 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100381 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100382 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100383 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100384 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100385 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100386 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100387 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100388 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100389 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100390 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100391 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100392 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100393 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100394 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100395 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100396 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100397 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100398 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100399 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100400 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100401 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100402 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100403 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100404 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100405 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100406 kernel zio_free_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100407 kernel zio_claim_issue mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100408 kernel zio_claim_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100409 kernel zio_ioctl_issue mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100410 kernel zio_ioctl_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100412 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100413 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100414 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100415 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100416 kernel zfs_vn_rele_task mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100417 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100418 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100419 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100420 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100423 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100433 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100438 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100439 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100440 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100441 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100442 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100443 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100444 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100445 kernel zil_clean mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100526 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100527 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100528 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100529 kernel zio_free_issue_4 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100530 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100531 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100532 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100533 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100534 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100535 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100536 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100537 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100538 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100539 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100540 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100541 kernel zio_free_issue_5 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100647 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100649 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100651 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100652 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100653 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100654 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100655 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100656 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100657 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100658 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100659 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100660 kernel zio_free_issue_6 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100661 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100662 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100663 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100664 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100665 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100666 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100667 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100668 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100669 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100670 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100671 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 100672 kernel zio_free_issue_7 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101449 kernel zio_free_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101450 kernel zio_claim_issue mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101451 kernel zio_claim_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101452 kernel zio_ioctl_issue mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101454 kernel zio_ioctl_intr mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101527 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101528 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101529 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101530 kernel metaslab_group_t mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 0 101531 kernel zfs_vn_rele_task mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a > fork_trampoline+0xe > 1 100002 init - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d > kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb > 2 100030 cam doneq0 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 xpt_done_td+0x8e fork_exit+0x9a > fork_trampoline+0xe > 2 100031 cam doneq1 mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 xpt_done_td+0x8e fork_exit+0x9a > fork_trampoline+0xe > 2 100111 cam scanner mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 xpt_scanner_thread+0x7c fork_exit+0x9a > fork_trampoline+0xe > 3 100107 zfskern arc_reclaim_thre mi_switch+0xe1 > sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b arc_reclaim_thread+0x301 > fork_exit+0x9a fork_trampoline+0xe > 3 100108 zfskern l2arc_feed_threa mi_switch+0xe1 > sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b l2arc_feed_thread+0x16f > fork_exit+0x9a fork_trampoline+0xe > 3 100177 zfskern txg_thread_enter mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d txg_quiesce_thread+0x39b fork_exit+0x9a > fork_trampoline+0xe > 3 100181 zfskern txg_thread_enter mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d zio_wait+0x5b dsl_pool_sync+0x371 > spa_sync+0x530 txg_sync_thread+0x3a6 fork_exit+0x9a fork_trampoline+0xe > 3 100411 zfskern trim zroot mi_switch+0xe1 > sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b trim_thread+0x9e > fork_exit+0x9a fork_trampoline+0xe > 3 100421 zfskern txg_thread_enter mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d txg_quiesce_thread+0x39b fork_exit+0x9a > fork_trampoline+0xe > 3 100422 zfskern txg_thread_enter mi_switch+0xe1 > sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b txg_sync_thread+0x1dc > fork_exit+0x9a fork_trampoline+0xe > 3 101526 zfskern trim sys1boot mi_switch+0xe1 > sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b trim_thread+0x9e > fork_exit+0x9a fork_trampoline+0xe > 4 100109 sctp_iterator - mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 sctp_iterator_thread+0x69 fork_exit+0x9a > fork_trampoline+0xe > 5 100112 enc_daemon0 - mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 enc_daemon+0x140 fork_exit+0x9a > fork_trampoline+0xe > 6 100113 pagedaemon - mi_switch+0xe1 > sleepq_timedwait+0x3a _sleep+0x26e vm_pageout+0x275 fork_exit+0x9a > fork_trampoline+0xe > 7 100114 vmdaemon - mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 vm_daemon+0x91 fork_exit+0x9a > fork_trampoline+0xe > 8 100115 pagezero - mi_switch+0xe1 > sleepq_timedwait+0x3a _sleep+0x26e vm_pagezero+0x98 fork_exit+0x9a > fork_trampoline+0xe > 9 100116 bufdaemon - mi_switch+0xe1 > sleepq_timedwait+0x3a _sleep+0x26e buf_daemon+0x78 fork_exit+0x9a > fork_trampoline+0xe > 10 100001 audit - mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d audit_worker+0xa3 fork_exit+0x9a > fork_trampoline+0xe > 11 100003 idle idle: cpu0 > > 11 100004 idle idle: cpu1 > > 11 100005 idle idle: cpu2 > > 11 100006 idle idle: cpu3 > > 11 100007 idle idle: cpu4 > > 11 100008 idle idle: cpu5 > > 11 100009 idle idle: cpu6 > > 11 100010 idle idle: cpu7 mi_switch+0xe1 > critical_exit+0x7a sched_idletd+0x1d5 fork_exit+0x9a fork_trampoline+0xe > 12 100011 intr swi4: clock mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100012 intr swi4: clock > > 12 100013 intr swi4: clock > > 12 100014 intr swi4: clock > > 12 100015 intr swi4: clock > > 12 100016 intr swi4: clock > > 12 100017 intr swi4: clock > > 12 100018 intr swi4: clock > > 12 100019 intr swi1: netisr 0 mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100020 intr swi3: vm > > 12 100028 intr swi5: fast taskq mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100035 intr swi6: task queue mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100036 intr swi6: Giant task mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100038 intr irq256: mps0 mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100041 intr irq16: uhci0+ > > 12 100046 intr irq21: uhci1 > > 12 100051 intr irq19: uhci2 uhc > > 12 100056 intr irq18: em1 ehci0 > > 12 100061 intr irq258: hdac0 mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100062 intr irq23: uhci3 ehc mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100080 intr irq259: ahci1:ch mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100081 intr irq260: ahci1:ch mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100082 intr irq261: ahci1:ch > > 12 100083 intr irq262: ahci1:ch mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100084 intr irq263: ahci1:ch mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100085 intr irq264: ahci1:ch mi_switch+0xe1 > ithread_loop+0x190 fork_exit+0x9a fork_trampoline+0xe > 12 100086 intr irq265: ahci1:6 > > 12 100087 intr irq266: ahci1:7 > > 12 100088 intr irq267: ahci1:8 > > 12 100089 intr irq268: ahci1:9 > > 12 100090 intr irq269: ahci1:10 > > 12 100091 intr irq270: ahci1:11 > > 12 100092 intr irq271: ahci1:12 > > 12 100093 intr irq272: ahci1:13 > > 12 100094 intr irq273: ahci1:14 > > 12 100095 intr irq274: ahci1:15 > > 12 100096 intr irq1: atkbd0 > > 12 100097 intr swi0: uart > > 13 100021 geom g_event mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 g_run_events+0x4d fork_exit+0x9a > fork_trampoline+0xe > 13 100022 geom g_up mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 g_io_schedule_up+0xbc g_up_procbody+0x6d > fork_exit+0x9a fork_trampoline+0xe > 13 100023 geom g_down mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 g_io_schedule_down+0x4c > g_down_procbody+0x6d fork_exit+0x9a fork_trampoline+0xe > 14 100025 rand_harvestq - mi_switch+0xe1 > sleepq_timedwait+0x3a msleep_spin_sbt+0x191 random_kthread+0x276 > fork_exit+0x9a fork_trampoline+0xe > 15 100042 usb usbus0 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100043 usb usbus0 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100044 usb usbus0 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100045 usb usbus0 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100047 usb usbus1 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100048 usb usbus1 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100049 usb usbus1 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100050 usb usbus1 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100052 usb usbus2 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100053 usb usbus2 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100054 usb usbus2 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100055 usb usbus2 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100057 usb usbus3 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100058 usb usbus3 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100059 usb usbus3 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100060 usb usbus3 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100063 usb usbus4 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100064 usb usbus4 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100065 usb usbus4 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100066 usb usbus4 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100067 usb usbus5 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100068 usb usbus5 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100069 usb usbus5 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100070 usb usbus5 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100071 usb usbus6 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100072 usb usbus6 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100073 usb usbus6 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100074 usb usbus6 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100075 usb usbus7 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100076 usb usbus7 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100077 usb usbus7 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100078 usb usbus7 mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 15 100457 usb ucom mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d usb_process+0xe0 fork_exit+0x9a > fork_trampoline+0xe > 16 100117 syncer - mi_switch+0xe1 > sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b sched_sync+0x6be > fork_exit+0x9a fork_trampoline+0xe > 17 100118 vnlru - mi_switch+0xe1 > sleepq_timedwait+0x3a _sleep+0x26e vnlru_proc+0x48 fork_exit+0x9a > fork_trampoline+0xe > 479 100454 devd - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_timedwait_sig+0x10 > _cv_timedwait_sig_sbt+0x18b seltdwait+0xa4 kern_select+0x8fa > sys_select+0x54 amd64_syscall+0x351 Xfast_syscall+0xfb > 554 100452 syslogd - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 > Xfast_syscall+0xfb > 750 100455 sshd - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 > Xfast_syscall+0xfb > 808 100424 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 809 100470 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 810 100471 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 811 100472 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 812 100473 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 813 100474 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 814 100475 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 815 100476 getty - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > tty_wait+0x1c ttydisc_read+0x2d4 ttydev_read+0x86 devfs_read_f+0xeb > dofileread+0x95 kern_readv+0x68 sys_read+0x63 amd64_syscall+0x351 > Xfast_syscall+0xfb > 1661 100498 sshd - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > seltdwait+0xae sys_poll+0x3a3 amd64_syscall+0x351 Xfast_syscall+0xfb > 1664 100514 sshd - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 > Xfast_syscall+0xfb > 1665 100425 sh - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d > kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb > 2000 100477 su - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d > kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb > 2001 100503 csh - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d > kern_sigsuspend+0xf4 sys_sigsuspend+0x31 amd64_syscall+0x351 > Xfast_syscall+0xfb > 2074 100524 zpool - mi_switch+0xe1 > sleepq_wait+0x3a _cv_wait+0x16d txg_wait_synced+0x85 spa_load+0x1cd1 > spa_load_best+0x6f spa_import+0x1ff zfs_ioc_pool_import+0x137 > zfsdev_ioctl+0x6f0 devfs_ioctl_f+0x114 kern_ioctl+0x255 sys_ioctl+0x13c > amd64_syscall+0x351 Xfast_syscall+0xfb > 2075 100430 sshd - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > seltdwait+0xae sys_poll+0x3a3 amd64_syscall+0x351 Xfast_syscall+0xfb > 2079 100446 sshd - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a > seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x351 > Xfast_syscall+0xfb > 2080 100488 sh - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d > kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb > 2081 100517 su - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d > kern_wait6+0x5f4 sys_wait4+0x72 amd64_syscall+0x351 Xfast_syscall+0xfb > 2082 100465 csh - mi_switch+0xe1 > sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d > kern_sigsuspend+0xf4 sys_sigsuspend+0x31 amd64_syscall+0x351 > Xfast_syscall+0xfb > 2085 100451 procstat - > > > Mark > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 01:10:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B511011B for ; Fri, 10 Oct 2014 01:10:19 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 652DB8A4 for ; Fri, 10 Oct 2014 01:10:19 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jDWRZ2R6cz35j for ; Fri, 10 Oct 2014 03:10:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:organization :from:from:date:date:message-id:received:received:received; s= jakla4; t=1412903412; x=1415495413; bh=0dDLOvH9cXc5TPr+bfC5TJS3q cZgGOPkxC3945l70ac=; b=WintIflOKEJfN3Ood4xp7UlgZmuON+1ynOtb943v/ VWgawl9a4LeS08m1etXtXWYPWAiz+u8O+awA7u5l3FSkwv4ogKIC2uARJN6vhiHs Q1mpiquqyKjMnAQnUcyusdU9nRBjeZ2SMXUtd3XfNwTCbwvqNGj2cLRe6x6RWUgX dA= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id cYxVhHd0VZM1 for ; Fri, 10 Oct 2014 03:10:12 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Fri, 10 Oct 2014 03:10:12 +0200 (CEST) Received: from sleepy.ijs.si (msleepy-1-pt.tunnel.tserv27.prg1.ipv6.he.net [IPv6:2001:470:6e:18e::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 3jDWRS3t86z7D for ; Fri, 10 Oct 2014 03:10:12 +0200 (CEST) Message-ID: <543731F3.8090701@ijs.si> Date: Fri, 10 Oct 2014 03:10:11 +0200 From: Mark Martinec Organization: J. Stefan Institute User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: zfs pool import hangs on [tx->tx_sync_done_cv] References: <54372173.1010100@ijs.si> <644FA8299BF848E599B82D2C2C298EA7@multiplay.co.uk> <54372EBA.1000908@ijs.si> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 01:10:19 -0000 On 10/10/2014 03:02, Steven Hartland wrote: > Sorry to be a pain but could you attach the full output or link it > somewhere as mail has messed up the formatting :( (sent the attachment to Steven directly, if somebody else is interested please let me know) Mark From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 02:06:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74EE0957 for ; Fri, 10 Oct 2014 02:06:54 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 29278D8E for ; Fri, 10 Oct 2014 02:06:53 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jDXhr6cd2zDQ for ; Fri, 10 Oct 2014 04:06:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:organization:from:from:date :date:message-id:received:received:received; s=jakla4; t= 1412906808; x=1415498809; bh=5FglQZWAR3lkTrTQBnGq1c+S7tlegWwv1nN vq1uEXRA=; b=KjfFVjugYqO8PgUgxj3sVAA/GWPsu9+518eFVDCd3VX53LgeIIB c8YnGgqtPnvMWtPiCsJRHLz6I0Ks9wiaWNQLmu+qWtDpKWDI4DXq0F5pr3EeqBmY kxuBbGpMlPRkWs+KO9epWjDQiMXRFaotmKUUfy8vVliJj42At5zyilvI= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id uXwbWiyWT4BT for ; Fri, 10 Oct 2014 04:06:48 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Fri, 10 Oct 2014 04:06:48 +0200 (CEST) Received: from sleepy.ijs.si (msleepy-1-pt.tunnel.tserv27.prg1.ipv6.he.net [IPv6:2001:470:6e:18e::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 3jDXhm08VTzBv for ; Fri, 10 Oct 2014 04:06:47 +0200 (CEST) Message-ID: <54373F37.9030304@ijs.si> Date: Fri, 10 Oct 2014 04:06:47 +0200 From: Mark Martinec Organization: J. Stefan Institute User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: GPT partitions not 4k aligned by 10.1-RC1 installer Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 02:06:54 -0000 Today I did a quick install of a 10.1-RC1 from an installation ISO DVD. Apart from choosing a ZFS filesystem, other options were left to their default. In particular, the align-to-4k ZFS options was left enabled. Guess what, the ZFS really ended up with ashift 12, but neither the swap nor the zfs partition is 4k aligned: # gpart show /dev/ada0 => 34 625142381 ada0 GPT (298G) 34 1024 1 freebsd-boot (512K) 1058 8388608 2 freebsd-swap (4.0G) 8389666 616752749 3 freebsd-zfs (294G) I find this unacceptable and surprising, regardless of what the underlying media is. Now that even Windows is aligning partitions to 1 MiB, and SSD erase block is often cited as 1 MiB ... Worried about space waste of half of one JPG photo? Mark From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 14:07:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C68FCB4 for ; Fri, 10 Oct 2014 14:07:15 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 339CDDB4 for ; Fri, 10 Oct 2014 14:07:15 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id n3so2127415wiv.17 for ; Fri, 10 Oct 2014 07:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=eK+3QvqOmCDWhMnaHTt7AwDuqS7GqhJ8z3NbhMByc3k=; b=yD7LfHGnJYN8qXvvFo8VX2EGgZDR1vZupVUjLh7OLekE1+aOV25DjqPDfuXzpUKonv Nq4kyakigXK+pecGvUglIi2d+7PuDqnppjUsRqF7vTa85ylCBJBmjxFYxut8tZ1h9xck pdWaMnb8hnoWMgeq+5DVnnGuvb/ir+OC9oQBeVTo+ql8dECegqaMfKnjTj6h54jdcZg2 fPf6uyviBMZaObTqoJ7TeDi4hRoiyVmevQWqxB8f/gnmUtTGiCeMYW9IN0VtA5J59rq+ UDIDGb6Ef9wiR0Kyd6C4SE41nkWsXzFGurgPydrrJy1d+Ppwp6i7TN4dxOV/pftSLiOP kuzA== X-Received: by 10.194.193.105 with SMTP id hn9mr3159903wjc.120.1412950033386; Fri, 10 Oct 2014 07:07:13 -0700 (PDT) Received: from [192.168.1.145] (static-228-200-167-83.thenetworkfactory.nl. [83.167.200.228]) by mx.google.com with ESMTPSA id b6sm2745242wiy.22.2014.10.10.07.07.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Oct 2014 07:07:13 -0700 (PDT) Message-ID: <5437E811.1030304@gmail.com> Date: Fri, 10 Oct 2014 16:07:13 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Naming of Stable Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 14:07:15 -0000 Hello all. I used to track Stable 10, when I do a uname -a now I get the following. FreeBSD beasty.mylab.local 10.1-RC1 FreeBSD 10.1-RC1 #0 r272893: Fri Oct 10 15:40:39 CEST 2014 root@beasty.mylab.local:/usr/obj/usr/src/sys/KRNL amd64 When I did a svnup today there where a lot of updates to zfs and the cam subsytem. * svn commit: r272629 - in stable/10: sys/cam/ctl usr.sbin/ctladm /Alexander Motin / * svn commit: r272630 - in stable/10: sys/cam/ctl usr.sbin/ctladm /Alexander Motin / * svn commit: r272631 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272632 - in stable/10/sys/cam: ctl scsi /Alexander Motin / * svn commit: r272633 - in stable/10/sys/cam: ctl scsi /Alexander Motin / * svn commit: r272634 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272635 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272636 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272637 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272638 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272639 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272640 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272641 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272642 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272643 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272644 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272645 - in stable/10/sys: netinet netinet6 /Michael Tuexen / * svn commit: r272646 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272647 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272648 - stable/10/sys/modules/netmap /Luigi Rizzo / * svn commit: r272654 - stable/10/sys/dev/iscsi_initiator /Alexander Motin / * svn commit: r272656 - stable/10/sys/cam/scsi /Alexander Motin / * svn commit: r272657 - stable/10/sys/cam/scsi /Alexander Motin / * svn commit: r272660 - stable/10/sys/netinet /Michael Tuexen / * svn commit: r272661 - in stable/10: share/man/man4 sys/netinet sys/netinet6 /Michael Tuexen / * svn commit: r272662 - stable/10/sys/netinet6 /Michael Tuexen / * svn commit: r272663 - stable/10/sys/netinet6 /Michael Tuexen / * svn commit: r272664 - stable/10/sys/netinet6 /Michael Tuexen / * svn commit: r272665 - stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs /Xin LI / * svn commit: r272672 - stable/10/sys/net /Alan Somers / * svn commit: r272676 - stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs /Marcelo Araujo / * svn commit: r272680 - stable/10/sys/net /Andrey V. Elsukov / * svn commit: r272688 - stable/10/cddl/contrib/opensolaris/cmd/zpool /Andriy Gapon / * svn commit: r272690 - stable/10/cddl/contrib/opensolaris/cmd/zfs /Andriy Gapon / * svn commit: r272693 - in stable/10/etc: . devd /Andriy Gapon / * svn commit: r272696 - in stable/10/sys/boot: common i386/gptzfsboot i386/zfsboot /Andriy Gapon / * svn commit: r272722 - stable/10/sys/vm /Bryan Venteicher / * svn commit: r272724 - in stable/10: release release/amd64 release/i386 share/man/man7 /Glen Barber / * svn commit: r272726 - stable/10/sys/kern /Neel Natu / * svn commit: r272727 - in stable/10: release release/amd64 release/i386 share/man/man7 /Glen Barber / o svn commit: r272727 - in stable/10: release release/amd64 release/i386 share/man/man7 /Glen Barber / * svn commit: r272753 - stable/10/contrib/libc-vis /Brooks Davis / * svn commit: r272754 - stable/10/sys/netinet6 /Michael Tuexen / * svn commit: r272758 - stable/10/lib/libc/stdtime /Pedro F. Giffuni / * svn commit: r272773 - stable/10/usr.bin/mkimg /Marcel Moolenaar / * svn commit: r272774 - stable/10/usr.bin/mkimg /Marcel Moolenaar / * svn commit: r272775 - stable/10/usr.bin/mkimg /Marcel Moolenaar / * svn commit: r272776 - stable/10/usr.bin/mkimg /Marcel Moolenaar / * svn commit: r272790 - in stable/10: sbin/ifconfig sys/netinet6 usr.bin/netstat /Andrey V. Elsukov / * svn commit: r272798 - stable/10/sys/cam/ctl /Alexander Motin / * svn commit: r272846 - stable/10/usr.bin/netstat /Hiroki Sato / * svn commit: r272847 - stable/10/sys/netinet6 /Hiroki Sato / * svn commit: r272850 - in stable/10: include/rpcsvc lib/libc/rpc lib/libc/xdr usr.sbin/ypbind /Hiroki Sato / * svn commit: r272852 - stable/10/sbin/route /Hiroki Sato / * svn commit: r272853 - stable/10/sbin/route /Hiroki Sato / * svn commit: r272854 - stable/10/sbin/mdconfig /Hiroki Sato / * svn commit: r272855 - stable/10/usr.bin/netstat /Hiroki Sato / * svn commit: r272856 - stable/10/etc /Hiroki Sato / * svn commit: r272857 - stable/10/sys/netinet6 /Hiroki Sato / * svn commit: r272858 - stable/10/etc /Hiroki Sato / * svn commit: r272859 - in stable/10/sys: netinet netinet6 /Hiroki Sato / * svn commit: r272860 - stable/10/usr.sbin/route6d /Hiroki Sato / * svn commit: r272861 - in stable/10/etc: defaults rc.d /Hiroki Sato / * svn commit: r272862 - in stable/10/etc: defaults rc.d /Hiroki Sato / o svn commit: r272862 - in stable/10/etc: defaults rc.d /Garrett Cooper / * svn commit: r272863 - stable/10/etc/rc.d /Hiroki Sato / * svn commit: r272864 - stable/10/etc/rc.d /Hiroki Sato / * svn commit: r272865 - stable/10/etc/rc.d /Hiroki Sato / * svn commit: r272866 - stable/10/usr.bin/vmstat /Hiroki Sato / * svn commit: r272867 - stable/10/sbin/dump /Hiroki Sato / * svn commit: r272868 - in stable/10: etc sys/netinet /Hiroki Sato / * svn commit: r272869 - stable/10/sys/netinet /Hiroki Sato / * svn commit: r272870 - in stable/10/etc: defaults rc.d /Hiroki Sato / * svn commit: r272871 - stable/10/sbin/ping6 /Hiroki Sato / o svn commit: r272871 - stable/10/sbin/ping6 /Bryan Drewery / + svn commit: r272871 - stable/10/sbin/ping6 /Hiroki Sato / * svn commit: r272872 - stable/10/sbin/routed /Hiroki Sato / * svn commit: r272873 - stable/10/sbin/routed /Hiroki Sato / * svn commit: r272874 - stable/10/etc /Hiroki Sato / * svn commit: r272875 - in stable/10/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm /Steven Hartland / * svn commit: r272877 - in stable/10: share/man/man9 sys/cddl/compat/opensolaris/kern sys/cddl/compat/opensolaris/sys sys/conf sys/modules/zfs /Steven Hartland / * svn commit: r272879 - in stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys /Steven Hartland / * svn commit: r272882 - stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs /Steven Hartland / * svn commit: r272883 - stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs /Steven Hartland / * svn commit: r272892 - stable/10/sys/dev/hwpmc /Bjoern A. Zeeb / On a second system witch is tracking RELENG/10.1 I do not get these updates. I think it is a little confusing to know which updates will make it into 10.1 and which not at this point. Both systems report there are 10.1, should the stable tree not be renamed to 10.1 post-release or just stable/10 regards Johan From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 17:28:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 881D34EE for ; Fri, 10 Oct 2014 17:28:44 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5187D8E3 for ; Fri, 10 Oct 2014 17:28:44 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id h15so3599543igd.4 for ; Fri, 10 Oct 2014 10:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CMx/2+PzdY0xFv2xH8UH6gMuzDyN1DojqO8jEZK49ms=; b=BSytPehOdE66/OjNICbUHFLfhGAwK92Lhrru/9DbSYh1UuWOqRQxS/dF/TIs+9HL2q qzko/eEkQ0RukPlmtUd50ycnRTf/MUvKJOaNjGnxfNJZCrq2eFR70huoW3yMBssvbVmQ UT/hT7f39rBFHmuWieXZ7H9V76BgYI2kUqGHGsZJtjS+eG0LeEkb4f0KoKAIrzeCkq+8 4f4q3QimiHuThh0ZhlSlty+920V2HW+gxYVEpJCrLu2YMIXFjx54/7b0Ww1TEbAeI4ib JKzAWF134o2KUDsUoIK5Erco/IVUAM4KJMI7M/hAjBwQYaHwwCpohGqRI+TH9Is9iWJ2 LnYw== MIME-Version: 1.0 X-Received: by 10.50.50.175 with SMTP id d15mr8743310igo.35.1412962123651; Fri, 10 Oct 2014 10:28:43 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.170.157 with HTTP; Fri, 10 Oct 2014 10:28:43 -0700 (PDT) In-Reply-To: <5437E811.1030304@gmail.com> References: <5437E811.1030304@gmail.com> Date: Fri, 10 Oct 2014 10:28:43 -0700 X-Google-Sender-Auth: VmfKORcj9RIFHWI8oywDzZWJS8Y Message-ID: Subject: Re: Naming of Stable From: Kevin Oberman To: Johan Hendriks Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 17:28:44 -0000 On Fri, Oct 10, 2014 at 7:07 AM, Johan Hendriks wrote: > Hello all. > > I used to track Stable 10, when I do a uname -a now I get the following. > > FreeBSD beasty.mylab.local 10.1-RC1 FreeBSD 10.1-RC1 #0 r272893: Fri Oct > 10 15:40:39 CEST 2014 root@beasty.mylab.local:/usr/obj/usr/src/sys/KRNL > amd64 > > When I did a svnup today there where a lot of updates to zfs and the cam > subsytem. > > * svn commit: r272629 - in stable/10: sys/cam/ctl usr.sbin/ctladm > 2014-October/003378.html>/Alexander > Motin / > * svn commit: r272630 - in stable/10: sys/cam/ctl usr.sbin/ctladm > 2014-October/003379.html>/Alexander > Motin / > * svn commit: r272631 - stable/10/sys/cam/ctl > 2014-October/003380.html>/Alexander > Motin / > * svn commit: r272632 - in stable/10/sys/cam: ctl scsi > 2014-October/003381.html>/Alexander > Motin / > * svn commit: r272633 - in stable/10/sys/cam: ctl scsi > 2014-October/003382.html>/Alexander > Motin / > * svn commit: r272634 - stable/10/sys/cam/ctl > 2014-October/003383.html>/Alexander > Motin / > * svn commit: r272635 - stable/10/sys/cam/ctl > 2014-October/003384.html>/Alexander > Motin / > * svn commit: r272636 - stable/10/sys/cam/ctl > 2014-October/003385.html>/Alexander > Motin / > * svn commit: r272637 - stable/10/sys/cam/ctl > 2014-October/003386.html>/Alexander > Motin / > * svn commit: r272638 - stable/10/sys/cam/ctl > 2014-October/003387.html>/Alexander > Motin / > * svn commit: r272639 - stable/10/sys/cam/ctl > 2014-October/003388.html>/Alexander > Motin / > * svn commit: r272640 - stable/10/sys/cam/ctl > 2014-October/003389.html>/Alexander > Motin / > * svn commit: r272641 - stable/10/sys/cam/ctl > 2014-October/003390.html>/Alexander > Motin / > * svn commit: r272642 - stable/10/sys/cam/ctl > 2014-October/003391.html>/Alexander > Motin / > * svn commit: r272643 - stable/10/sys/cam/ctl > 2014-October/003392.html>/Alexander > Motin / > * svn commit: r272644 - stable/10/sys/cam/ctl > 2014-October/003393.html>/Alexander > Motin / > * svn commit: r272645 - in stable/10/sys: netinet netinet6 > 2014-October/003394.html>/Michael > Tuexen / > * svn commit: r272646 - stable/10/sys/cam/ctl > 2014-October/003395.html>/Alexander > Motin / > * svn commit: r272647 - stable/10/sys/cam/ctl > 2014-October/003396.html>/Alexander > Motin / > * svn commit: r272648 - stable/10/sys/modules/netmap > 2014-October/003397.html>/Luigi > Rizzo / > * svn commit: r272654 - stable/10/sys/dev/iscsi_initiator > 2014-October/003398.html>/Alexander > Motin / > * svn commit: r272656 - stable/10/sys/cam/scsi > 2014-October/003399.html>/Alexander > Motin / > * svn commit: r272657 - stable/10/sys/cam/scsi > 2014-October/003400.html>/Alexander > Motin / > * svn commit: r272660 - stable/10/sys/netinet > 2014-October/003401.html>/Michael > Tuexen / > * svn commit: r272661 - in stable/10: share/man/man4 sys/netinet > sys/netinet6 > 2014-October/003402.html>/Michael > Tuexen / > * svn commit: r272662 - stable/10/sys/netinet6 > 2014-October/003403.html>/Michael > Tuexen / > * svn commit: r272663 - stable/10/sys/netinet6 > 2014-October/003404.html>/Michael > Tuexen / > * svn commit: r272664 - stable/10/sys/netinet6 > 2014-October/003405.html>/Michael > Tuexen / > * svn commit: r272665 - > stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs > 2014-October/003406.html>/Xin > LI / > * svn commit: r272672 - stable/10/sys/net > 2014-October/003407.html>/Alan > Somers / > * svn commit: r272676 - > stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs > 2014-October/003408.html>/Marcelo > Araujo / > * svn commit: r272680 - stable/10/sys/net > 2014-October/003409.html>/Andrey > V. Elsukov / > * svn commit: r272688 - stable/10/cddl/contrib/opensolaris/cmd/zpool > 2014-October/003410.html>/Andriy > Gapon / > * svn commit: r272690 - stable/10/cddl/contrib/opensolaris/cmd/zfs > 2014-October/003411.html>/Andriy > Gapon / > * svn commit: r272693 - in stable/10/etc: . devd > 2014-October/003412.html>/Andriy > Gapon / > * svn commit: r272696 - in stable/10/sys/boot: common i386/gptzfsboot > i386/zfsboot > 2014-October/003413.html>/Andriy > Gapon / > * svn commit: r272722 - stable/10/sys/vm > 2014-October/003414.html>/Bryan > Venteicher / > * svn commit: r272724 - in stable/10: release release/amd64 > release/i386 share/man/man7 > 2014-October/003415.html>/Glen > Barber / > * svn commit: r272726 - stable/10/sys/kern > 2014-October/003416.html>/Neel > Natu / > * svn commit: r272727 - in stable/10: release release/amd64 > release/i386 share/man/man7 > 2014-October/003417.html>/Glen > Barber / > o svn commit: r272727 - in stable/10: release release/amd64 > release/i386 share/man/man7 > 2014-October/003418.html>/Glen > Barber / > * svn commit: r272753 - stable/10/contrib/libc-vis > 2014-October/003419.html>/Brooks > Davis / > * svn commit: r272754 - stable/10/sys/netinet6 > 2014-October/003420.html>/Michael > Tuexen / > * svn commit: r272758 - stable/10/lib/libc/stdtime > 2014-October/003421.html>/Pedro > F. Giffuni / > * svn commit: r272773 - stable/10/usr.bin/mkimg > 2014-October/003422.html>/Marcel > Moolenaar / > * svn commit: r272774 - stable/10/usr.bin/mkimg > 2014-October/003423.html>/Marcel > Moolenaar / > * svn commit: r272775 - stable/10/usr.bin/mkimg > 2014-October/003424.html>/Marcel > Moolenaar / > * svn commit: r272776 - stable/10/usr.bin/mkimg > 2014-October/003425.html>/Marcel > Moolenaar / > * svn commit: r272790 - in stable/10: sbin/ifconfig sys/netinet6 > usr.bin/netstat > 2014-October/003426.html>/Andrey > V. Elsukov / > * svn commit: r272798 - stable/10/sys/cam/ctl > 2014-October/003427.html>/Alexander > Motin / > * svn commit: r272846 - stable/10/usr.bin/netstat > 2014-October/003428.html>/Hiroki > Sato / > * svn commit: r272847 - stable/10/sys/netinet6 > 2014-October/003429.html>/Hiroki > Sato / > * svn commit: r272850 - in stable/10: include/rpcsvc lib/libc/rpc > lib/libc/xdr usr.sbin/ypbind > 2014-October/003430.html>/Hiroki > Sato / > * svn commit: r272852 - stable/10/sbin/route > 2014-October/003431.html>/Hiroki > Sato / > * svn commit: r272853 - stable/10/sbin/route > 2014-October/003432.html>/Hiroki > Sato / > * svn commit: r272854 - stable/10/sbin/mdconfig > 2014-October/003433.html>/Hiroki > Sato / > * svn commit: r272855 - stable/10/usr.bin/netstat > 2014-October/003434.html>/Hiroki > Sato / > * svn commit: r272856 - stable/10/etc > 2014-October/003435.html>/Hiroki > Sato / > * svn commit: r272857 - stable/10/sys/netinet6 > 2014-October/003436.html>/Hiroki > Sato / > * svn commit: r272858 - stable/10/etc > 2014-October/003437.html>/Hiroki > Sato / > * svn commit: r272859 - in stable/10/sys: netinet netinet6 > 2014-October/003438.html>/Hiroki > Sato / > * svn commit: r272860 - stable/10/usr.sbin/route6d > 2014-October/003439.html>/Hiroki > Sato / > * svn commit: r272861 - in stable/10/etc: defaults rc.d > 2014-October/003440.html>/Hiroki > Sato / > * svn commit: r272862 - in stable/10/etc: defaults rc.d > 2014-October/003441.html>/Hiroki > Sato / > o svn commit: r272862 - in stable/10/etc: defaults rc.d > 2014-October/003459.html>/Garrett > Cooper / > * svn commit: r272863 - stable/10/etc/rc.d > 2014-October/003442.html>/Hiroki > Sato / > * svn commit: r272864 - stable/10/etc/rc.d > 2014-October/003443.html>/Hiroki > Sato / > * svn commit: r272865 - stable/10/etc/rc.d > 2014-October/003444.html>/Hiroki > Sato / > * svn commit: r272866 - stable/10/usr.bin/vmstat > 2014-October/003445.html>/Hiroki > Sato / > * svn commit: r272867 - stable/10/sbin/dump > 2014-October/003446.html>/Hiroki > Sato / > * svn commit: r272868 - in stable/10: etc sys/netinet > 2014-October/003447.html>/Hiroki > Sato / > * svn commit: r272869 - stable/10/sys/netinet > 2014-October/003448.html>/Hiroki > Sato / > * svn commit: r272870 - in stable/10/etc: defaults rc.d > 2014-October/003449.html>/Hiroki > Sato / > * svn commit: r272871 - stable/10/sbin/ping6 > 2014-October/003450.html>/Hiroki > Sato / > o svn commit: r272871 - stable/10/sbin/ping6 > 2014-October/003452.html>/Bryan > Drewery / > + svn commit: r272871 - stable/10/sbin/ping6 > 2014-October/003455.html>/Hiroki > Sato / > * svn commit: r272872 - stable/10/sbin/routed > 2014-October/003451.html>/Hiroki > Sato / > * svn commit: r272873 - stable/10/sbin/routed > 2014-October/003453.html>/Hiroki > Sato / > * svn commit: r272874 - stable/10/etc > 2014-October/003454.html>/Hiroki > Sato / > * svn commit: r272875 - in stable/10/sys: cddl/compat/opensolaris/kern > cddl/compat/opensolaris/sys > cddl/contrib/opensolaris/uts/common/fs/zfs vm > 2014-October/003456.html>/Steven > Hartland / > * svn commit: r272877 - in stable/10: share/man/man9 > sys/cddl/compat/opensolaris/kern sys/cddl/compat/opensolaris/sys > sys/conf sys/modules/zfs > 2014-October/003457.html>/Steven > Hartland / > * svn commit: r272879 - in > stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys > 2014-October/003458.html>/Steven > Hartland / > * svn commit: r272882 - > stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs > 2014-October/003460.html>/Steven > Hartland / > * svn commit: r272883 - > stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs > 2014-October/003461.html>/Steven > Hartland / > * svn commit: r272892 - stable/10/sys/dev/hwpmc > 2014-October/003462.html>/Bjoern > A. Zeeb / > > On a second system witch is tracking RELENG/10.1 I do not get these > updates. > I think it is a little confusing to know which updates will make it into > 10.1 and which not at this point. > Both systems report there are 10.1, should the stable tree not be renamed > to 10.1 post-release or just stable/10 > > regards > Johan > This pops up most every time through the release cycle. A week ago releng/10.1 was branched off of sable/10. At this point the stable path was unfrozen and MFH of non-critical patches can begin. RE typically requests that major changes be held until the actual release, but other MFHs that have been held up due to the freeze so start getting committed to stable. Any committer can request that RE allow any of these changes be allowed into the RELENG branch, but RE is generally very hard to convince unless the MFH fixes a critical issue (show stopper)or is clearly innocuous. the latter is usually things like correcting errors in man pages and text output to logs. This has resulted in heated discussions which have. on occasion, made it to core. It comes down to "This is a critical fix" vs. "The problem can be worked around and it is too late to do adequate testing to be sure that there are no hidden regressions". RE tends to always be on the conservative side. So, without knowing anything about these commits, it is unlikely that any will be in 10.1. Whether RE is considering any, I have no idea, but odds are that, unless they fix real serious issues, they will not be committed to RELENG and will not be in 10.1. Also, the tree is stable/10, not stable/10.1. It is only the string in uname that uses the RC-10.1 as that is the name of the stable code at the time releng is branched. I think it would minimize confusion if it was changed back to "stable" after branching, but that raises the bikeshed of whether it would be 10.0-STABLE or 10.1-STABLE until 10.1 is released. Now that the uname includes the subversion revision number, I think it should just be tagged as 10-STABLE as that is what it really is. There is no stable/10.1 in the tree, so why do we tag the system with a name that does not exist? But that is just my opinion. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 18:03:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C283D12 for ; Fri, 10 Oct 2014 18:03:04 +0000 (UTC) Received: from list.sco.com (list.sco.com [69.36.163.214]) by mx1.freebsd.org (Postfix) with SMTP id EC591CD4 for ; Fri, 10 Oct 2014 18:03:03 +0000 (UTC) Received: (qmail 5073 invoked from network); 10 Oct 2014 17:56:22 -0000 Received: from nimbus.nj.sco.com (69.36.163.214) by tasmania.ut.sco.com with SMTP; 10 Oct 2014 17:56:22 -0000 Received: from [127.0.0.1] (ip-132147089 [132.147.83.89]) by nimbus.nj.sco.com (8.12.9/UW7.1.3) with ESMTP id s9AHuKHH017866; Fri, 10 Oct 2014 13:56:21 -0400 (EDT) Message-ID: <54381DBF.5020907@xinuos.com> Date: Fri, 10 Oct 2014 13:56:15 -0400 From: John Wolfe User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kevin Oberman , Johan Hendriks Subject: Re: Naming of Stable References: <5437E811.1030304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 18:03:04 -0000 I took Johan's e-mail to be a suggestion that the changes made by Glen B. to sys/conf/newvers.h through the 10.1 Beta and RC1 stages be reverted back to "10-STABLE" now that the releng/10.1 branch has been made. -- John On 10/10/2014 1:28 PM, Kevin Oberman wrote: > On Fri, Oct 10, 2014 at 7:07 AM, Johan Hendriks > wrote: > >> Hello all. >> >> I used to track Stable 10, when I do a uname -a now I get the following. >> >> FreeBSD beasty.mylab.local 10.1-RC1 FreeBSD 10.1-RC1 #0 r272893: Fri Oct >> 10 15:40:39 CEST 2014 root@beasty.mylab.local:/usr/obj/usr/src/sys/KRNL >> amd64 >> >> When I did a svnup today there where a lot of updates to zfs and the cam >> subsytem. >> >> * svn commit: r272629 - in stable/10: sys/cam/ctl usr.sbin/ctladm >> > 2014-October/003378.html>/Alexander >> Motin / >> * svn commit: r272630 - in stable/10: sys/cam/ctl usr.sbin/ctladm >> > 2014-October/003379.html>/Alexander >> Motin / >> * svn commit: r272631 - stable/10/sys/cam/ctl >> > 2014-October/003380.html>/Alexander >> Motin / >> * svn commit: r272632 - in stable/10/sys/cam: ctl scsi >> > 2014-October/003381.html>/Alexander >> Motin / >> * svn commit: r272633 - in stable/10/sys/cam: ctl scsi >> > 2014-October/003382.html>/Alexander >> Motin / >> * svn commit: r272634 - stable/10/sys/cam/ctl >> > 2014-October/003383.html>/Alexander >> Motin / >> * svn commit: r272635 - stable/10/sys/cam/ctl >> > 2014-October/003384.html>/Alexander >> Motin / >> * svn commit: r272636 - stable/10/sys/cam/ctl >> > 2014-October/003385.html>/Alexander >> Motin / >> * svn commit: r272637 - stable/10/sys/cam/ctl >> > 2014-October/003386.html>/Alexander >> Motin / >> * svn commit: r272638 - stable/10/sys/cam/ctl >> > 2014-October/003387.html>/Alexander >> Motin / >> * svn commit: r272639 - stable/10/sys/cam/ctl >> > 2014-October/003388.html>/Alexander >> Motin / >> * svn commit: r272640 - stable/10/sys/cam/ctl >> > 2014-October/003389.html>/Alexander >> Motin / >> * svn commit: r272641 - stable/10/sys/cam/ctl >> > 2014-October/003390.html>/Alexander >> Motin / >> * svn commit: r272642 - stable/10/sys/cam/ctl >> > 2014-October/003391.html>/Alexander >> Motin / >> * svn commit: r272643 - stable/10/sys/cam/ctl >> > 2014-October/003392.html>/Alexander >> Motin / >> * svn commit: r272644 - stable/10/sys/cam/ctl >> > 2014-October/003393.html>/Alexander >> Motin / >> * svn commit: r272645 - in stable/10/sys: netinet netinet6 >> > 2014-October/003394.html>/Michael >> Tuexen / >> * svn commit: r272646 - stable/10/sys/cam/ctl >> > 2014-October/003395.html>/Alexander >> Motin / >> * svn commit: r272647 - stable/10/sys/cam/ctl >> > 2014-October/003396.html>/Alexander >> Motin / >> * svn commit: r272648 - stable/10/sys/modules/netmap >> > 2014-October/003397.html>/Luigi >> Rizzo / >> * svn commit: r272654 - stable/10/sys/dev/iscsi_initiator >> > 2014-October/003398.html>/Alexander >> Motin / >> * svn commit: r272656 - stable/10/sys/cam/scsi >> > 2014-October/003399.html>/Alexander >> Motin / >> * svn commit: r272657 - stable/10/sys/cam/scsi >> > 2014-October/003400.html>/Alexander >> Motin / >> * svn commit: r272660 - stable/10/sys/netinet >> > 2014-October/003401.html>/Michael >> Tuexen / >> * svn commit: r272661 - in stable/10: share/man/man4 sys/netinet >> sys/netinet6 >> > 2014-October/003402.html>/Michael >> Tuexen / >> * svn commit: r272662 - stable/10/sys/netinet6 >> > 2014-October/003403.html>/Michael >> Tuexen / >> * svn commit: r272663 - stable/10/sys/netinet6 >> > 2014-October/003404.html>/Michael >> Tuexen / >> * svn commit: r272664 - stable/10/sys/netinet6 >> > 2014-October/003405.html>/Michael >> Tuexen / >> * svn commit: r272665 - >> stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs >> > 2014-October/003406.html>/Xin >> LI / >> * svn commit: r272672 - stable/10/sys/net >> > 2014-October/003407.html>/Alan >> Somers / >> * svn commit: r272676 - >> stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs >> > 2014-October/003408.html>/Marcelo >> Araujo / >> * svn commit: r272680 - stable/10/sys/net >> > 2014-October/003409.html>/Andrey >> V. Elsukov / >> * svn commit: r272688 - stable/10/cddl/contrib/opensolaris/cmd/zpool >> > 2014-October/003410.html>/Andriy >> Gapon / >> * svn commit: r272690 - stable/10/cddl/contrib/opensolaris/cmd/zfs >> > 2014-October/003411.html>/Andriy >> Gapon / >> * svn commit: r272693 - in stable/10/etc: . devd >> > 2014-October/003412.html>/Andriy >> Gapon / >> * svn commit: r272696 - in stable/10/sys/boot: common i386/gptzfsboot >> i386/zfsboot >> > 2014-October/003413.html>/Andriy >> Gapon / >> * svn commit: r272722 - stable/10/sys/vm >> > 2014-October/003414.html>/Bryan >> Venteicher / >> * svn commit: r272724 - in stable/10: release release/amd64 >> release/i386 share/man/man7 >> > 2014-October/003415.html>/Glen >> Barber / >> * svn commit: r272726 - stable/10/sys/kern >> > 2014-October/003416.html>/Neel >> Natu / >> * svn commit: r272727 - in stable/10: release release/amd64 >> release/i386 share/man/man7 >> > 2014-October/003417.html>/Glen >> Barber / >> o svn commit: r272727 - in stable/10: release release/amd64 >> release/i386 share/man/man7 >> > 2014-October/003418.html>/Glen >> Barber / >> * svn commit: r272753 - stable/10/contrib/libc-vis >> > 2014-October/003419.html>/Brooks >> Davis / >> * svn commit: r272754 - stable/10/sys/netinet6 >> > 2014-October/003420.html>/Michael >> Tuexen / >> * svn commit: r272758 - stable/10/lib/libc/stdtime >> > 2014-October/003421.html>/Pedro >> F. Giffuni / >> * svn commit: r272773 - stable/10/usr.bin/mkimg >> > 2014-October/003422.html>/Marcel >> Moolenaar / >> * svn commit: r272774 - stable/10/usr.bin/mkimg >> > 2014-October/003423.html>/Marcel >> Moolenaar / >> * svn commit: r272775 - stable/10/usr.bin/mkimg >> > 2014-October/003424.html>/Marcel >> Moolenaar / >> * svn commit: r272776 - stable/10/usr.bin/mkimg >> > 2014-October/003425.html>/Marcel >> Moolenaar / >> * svn commit: r272790 - in stable/10: sbin/ifconfig sys/netinet6 >> usr.bin/netstat >> > 2014-October/003426.html>/Andrey >> V. Elsukov / >> * svn commit: r272798 - stable/10/sys/cam/ctl >> > 2014-October/003427.html>/Alexander >> Motin / >> * svn commit: r272846 - stable/10/usr.bin/netstat >> > 2014-October/003428.html>/Hiroki >> Sato / >> * svn commit: r272847 - stable/10/sys/netinet6 >> > 2014-October/003429.html>/Hiroki >> Sato / >> * svn commit: r272850 - in stable/10: include/rpcsvc lib/libc/rpc >> lib/libc/xdr usr.sbin/ypbind >> > 2014-October/003430.html>/Hiroki >> Sato / >> * svn commit: r272852 - stable/10/sbin/route >> > 2014-October/003431.html>/Hiroki >> Sato / >> * svn commit: r272853 - stable/10/sbin/route >> > 2014-October/003432.html>/Hiroki >> Sato / >> * svn commit: r272854 - stable/10/sbin/mdconfig >> > 2014-October/003433.html>/Hiroki >> Sato / >> * svn commit: r272855 - stable/10/usr.bin/netstat >> > 2014-October/003434.html>/Hiroki >> Sato / >> * svn commit: r272856 - stable/10/etc >> > 2014-October/003435.html>/Hiroki >> Sato / >> * svn commit: r272857 - stable/10/sys/netinet6 >> > 2014-October/003436.html>/Hiroki >> Sato / >> * svn commit: r272858 - stable/10/etc >> > 2014-October/003437.html>/Hiroki >> Sato / >> * svn commit: r272859 - in stable/10/sys: netinet netinet6 >> > 2014-October/003438.html>/Hiroki >> Sato / >> * svn commit: r272860 - stable/10/usr.sbin/route6d >> > 2014-October/003439.html>/Hiroki >> Sato / >> * svn commit: r272861 - in stable/10/etc: defaults rc.d >> > 2014-October/003440.html>/Hiroki >> Sato / >> * svn commit: r272862 - in stable/10/etc: defaults rc.d >> > 2014-October/003441.html>/Hiroki >> Sato / >> o svn commit: r272862 - in stable/10/etc: defaults rc.d >> > 2014-October/003459.html>/Garrett >> Cooper / >> * svn commit: r272863 - stable/10/etc/rc.d >> > 2014-October/003442.html>/Hiroki >> Sato / >> * svn commit: r272864 - stable/10/etc/rc.d >> > 2014-October/003443.html>/Hiroki >> Sato / >> * svn commit: r272865 - stable/10/etc/rc.d >> > 2014-October/003444.html>/Hiroki >> Sato / >> * svn commit: r272866 - stable/10/usr.bin/vmstat >> > 2014-October/003445.html>/Hiroki >> Sato / >> * svn commit: r272867 - stable/10/sbin/dump >> > 2014-October/003446.html>/Hiroki >> Sato / >> * svn commit: r272868 - in stable/10: etc sys/netinet >> > 2014-October/003447.html>/Hiroki >> Sato / >> * svn commit: r272869 - stable/10/sys/netinet >> > 2014-October/003448.html>/Hiroki >> Sato / >> * svn commit: r272870 - in stable/10/etc: defaults rc.d >> > 2014-October/003449.html>/Hiroki >> Sato / >> * svn commit: r272871 - stable/10/sbin/ping6 >> > 2014-October/003450.html>/Hiroki >> Sato / >> o svn commit: r272871 - stable/10/sbin/ping6 >> > 2014-October/003452.html>/Bryan >> Drewery / >> + svn commit: r272871 - stable/10/sbin/ping6 >> > 2014-October/003455.html>/Hiroki >> Sato / >> * svn commit: r272872 - stable/10/sbin/routed >> > 2014-October/003451.html>/Hiroki >> Sato / >> * svn commit: r272873 - stable/10/sbin/routed >> > 2014-October/003453.html>/Hiroki >> Sato / >> * svn commit: r272874 - stable/10/etc >> > 2014-October/003454.html>/Hiroki >> Sato / >> * svn commit: r272875 - in stable/10/sys: cddl/compat/opensolaris/kern >> cddl/compat/opensolaris/sys >> cddl/contrib/opensolaris/uts/common/fs/zfs vm >> > 2014-October/003456.html>/Steven >> Hartland / >> * svn commit: r272877 - in stable/10: share/man/man9 >> sys/cddl/compat/opensolaris/kern sys/cddl/compat/opensolaris/sys >> sys/conf sys/modules/zfs >> > 2014-October/003457.html>/Steven >> Hartland / >> * svn commit: r272879 - in >> stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys >> > 2014-October/003458.html>/Steven >> Hartland / >> * svn commit: r272882 - >> stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs >> > 2014-October/003460.html>/Steven >> Hartland / >> * svn commit: r272883 - >> stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs >> > 2014-October/003461.html>/Steven >> Hartland / >> * svn commit: r272892 - stable/10/sys/dev/hwpmc >> > 2014-October/003462.html>/Bjoern >> A. Zeeb / >> >> On a second system witch is tracking RELENG/10.1 I do not get these >> updates. >> I think it is a little confusing to know which updates will make it into >> 10.1 and which not at this point. >> Both systems report there are 10.1, should the stable tree not be renamed >> to 10.1 post-release or just stable/10 >> >> regards >> Johan >> > This pops up most every time through the release cycle. > > A week ago releng/10.1 was branched off of sable/10. At this point the > stable path was unfrozen and MFH of non-critical patches can begin. RE > typically requests that major changes be held until the actual release, but > other MFHs that have been held up due to the freeze so start getting > committed to stable. Any committer can request that RE allow any of these > changes be allowed into the RELENG branch, but RE is generally very hard to > convince unless the MFH fixes a critical issue (show stopper)or is clearly > innocuous. the latter is usually things like correcting errors in man pages > and text output to logs. > > This has resulted in heated discussions which have. on occasion, made it to > core. It comes down to "This is a critical fix" vs. "The problem can be > worked around and it is too late to do adequate testing to be sure that > there are no hidden regressions". RE tends to always be on the conservative > side. > > So, without knowing anything about these commits, it is unlikely that any > will be in 10.1. Whether RE is considering any, I have no idea, but odds > are that, unless they fix real serious issues, they will not be committed > to RELENG and will not be in 10.1. Also, the tree is stable/10, not > stable/10.1. It is only the string in uname that uses the RC-10.1 as that > is the name of the stable code at the time releng is branched. I think it > would minimize confusion if it was changed back to "stable" after > branching, but that raises the bikeshed of whether it would be 10.0-STABLE > or 10.1-STABLE until 10.1 is released. Now that the uname includes the > subversion revision number, I think it should just be tagged as 10-STABLE > as that is what it really is. There is no stable/10.1 in the tree, so why > do we tag the system with a name that does not exist? But that is just my > opinion. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Oct 10 20:15:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24BAE1DB for ; Fri, 10 Oct 2014 20:15:57 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB2A6D10 for ; Fri, 10 Oct 2014 20:15:56 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id DC70A2175 for ; Fri, 10 Oct 2014 16:15:55 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Fri, 10 Oct 2014 16:15:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:subject :date:in-reply-to:references; s=smtpout; bh=E7JX0APGYbbOx+LwVv5h HU4K6mw=; b=sQJX+y/9Aw9i9FygBNHQKf6Eokbq0vFY7AFg6GBqIUh+jySD+caQ vJGDB7pSAgYY4Jn0Kt9gpu/+DJWvBpsSetQG7kyx6eaMERD8L5ONnc4Y+Q6ixSMd 0TZM52vY8VWBjZKLudtZsxvrjpn1UhbRarkZjGwVk3nRvpsj0nCpPMs= Received: by web6.nyi.internal (Postfix, from userid 99) id 9C31B5C1DFB; Fri, 10 Oct 2014 16:15:55 -0400 (EDT) Message-Id: <1412972155.2402830.177608133.7B9238D9@webmail.messagingengine.com> X-Sasl-Enc: R1C90XafzHLF0G5tjjPsKolyISQmkRPAlP5dIu5r3Q7j 1412972155 From: Mark Felder To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-7434a20c Subject: Re: GPT partitions not 4k aligned by 10.1-RC1 installer Date: Fri, 10 Oct 2014 15:15:55 -0500 In-Reply-To: <54373F37.9030304@ijs.si> References: <54373F37.9030304@ijs.si> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 20:15:57 -0000 On Thu, Oct 9, 2014, at 21:06, Mark Martinec wrote: > Today I did a quick install of a 10.1-RC1 from an installation > ISO DVD. Apart from choosing a ZFS filesystem, other options were > left to their default. In particular, the align-to-4k ZFS options > was left enabled. > > Guess what, the ZFS really ended up with ashift 12, > but neither the swap nor the zfs partition is 4k aligned: > > # gpart show /dev/ada0 > => 34 625142381 ada0 GPT (298G) > 34 1024 1 freebsd-boot (512K) > 1058 8388608 2 freebsd-swap (4.0G) > 8389666 616752749 3 freebsd-zfs (294G) > > I find this unacceptable and surprising, > regardless of what the underlying media is. > > Now that even Windows is aligning partitions to 1 MiB, > and SSD erase block is often cited as 1 MiB ... > > Worried about space waste of half of one JPG photo? > Thanks for the report. The installer should be using gpart -a to create the partition aligned, but your result shows that did not happen. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 09:45:26 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D69E9AD5 for ; Sat, 11 Oct 2014 09:45:26 +0000 (UTC) Received: from mail.webmatic.de (mail.webmatic.de [212.78.101.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.webmatic.de", Issuer "PositiveSSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CE71F1A for ; Sat, 11 Oct 2014 09:45:25 +0000 (UTC) Received: from [192.168.178.27] (p548A7BA5.dip0.t-ipconnect.de [84.138.123.165]) by mail.webmatic.de (Postfix) with ESMTPSA id E46668A06E for ; Sat, 11 Oct 2014 11:39:17 +0200 (CEST) Message-ID: <5438FAC6.3000807@chef-ingenieur.de> Date: Sat, 11 Oct 2014 11:39:18 +0200 From: Thomas Krause User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: 3 TB USB disk Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 09:45:27 -0000 Hi, I connected a 3TB USB disk to a FreeBSD 9.3 server. The drive is recognized as 2 disks (da0: 2 TB and da1: 1TB). What is wrong here? Oct 9 14:14:54 mail kernel: ugen1.3: at usbus1 Oct 9 14:14:54 mail kernel: umass0: on usbus1 Oct 9 14:14:54 mail kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Oct 9 14:14:54 mail kernel: umass0:3:0:-1: Attached to scbus3 Oct 9 14:14:54 mail kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Oct 9 14:14:54 mail kernel: da0: Fixed Direct Access SCSI-4 device Oct 9 14:14:54 mail kernel: da0: Serial Number FDC0FD300100000FD0FCC139FA8F2F Oct 9 14:14:54 mail kernel: da0: 40.000MB/s transfers Oct 9 14:14:54 mail kernel: da0: 2097151MB (4294967295 512 byte sectors: 255H 63S/T 267349C) Oct 9 14:14:54 mail kernel: da0: quirks=0x2 Oct 9 14:14:54 mail kernel: da1 at umass-sim0 bus 0 scbus3 target 0 lun 1 Oct 9 14:14:54 mail kernel: da1: Fixed Direct Access SCSI-4 device Oct 9 14:14:54 mail kernel: da1: Serial Number FDC0FD300100000FD0FCC139FA8F2F Oct 9 14:14:54 mail kernel: da1: 40.000MB/s transfers Oct 9 14:14:54 mail kernel: da1: 764436MB (1565565872 512 byte sectors: 255H 63S/T 97451C) Oct 9 14:14:54 mail kernel: da1: quirks=0x2 Best regards, Thomas. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 09:53:19 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48A70C10 for ; Sat, 11 Oct 2014 09:53:19 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 36213FF6 for ; Sat, 11 Oct 2014 09:53:18 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0ND90046OYBPAB00@hades.sorbs.net> for freebsd-stable@FreeBSD.org; Sat, 11 Oct 2014 02:57:26 -0700 (PDT) Message-id: <5438FE0B.5020303@sorbs.net> Date: Sat, 11 Oct 2014 11:53:15 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Thomas Krause Subject: Re: 3 TB USB disk References: <5438FAC6.3000807@chef-ingenieur.de> In-reply-to: <5438FAC6.3000807@chef-ingenieur.de> Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 09:53:19 -0000 Thomas Krause wrote: > Hi, > I connected a 3TB USB disk to a FreeBSD 9.3 server. The drive is > recognized as 2 disks (da0: 2 TB and da1: 1TB). What is > wrong here? > > Oct 9 14:14:54 mail kernel: ugen1.3: > at usbus1 > Oct 9 14:14:54 mail kernel: umass0: on usbus1 > Oct 9 14:14:54 mail kernel: umass0: SCSI over Bulk-Only; quirks = > 0x0000 > Oct 9 14:14:54 mail kernel: umass0:3:0:-1: Attached to scbus3 > Oct 9 14:14:54 mail kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > lun 0 > Oct 9 14:14:54 mail kernel: da0: Fixed Direct > Access SCSI-4 device > Oct 9 14:14:54 mail kernel: da0: Serial Number > FDC0FD300100000FD0FCC139FA8F2F > Oct 9 14:14:54 mail kernel: da0: 40.000MB/s transfers > Oct 9 14:14:54 mail kernel: da0: 2097151MB (4294967295 512 byte > sectors: 255H 63S/T 267349C) > Oct 9 14:14:54 mail kernel: da0: quirks=0x2 > Oct 9 14:14:54 mail kernel: da1 at umass-sim0 bus 0 scbus3 target 0 > lun 1 > Oct 9 14:14:54 mail kernel: da1: External\000\000\000\000LUN1 0200> Fixed Direct Access SCSI-4 device > Oct 9 14:14:54 mail kernel: da1: Serial Number > FDC0FD300100000FD0FCC139FA8F2F > Oct 9 14:14:54 mail kernel: da1: 40.000MB/s transfers > Oct 9 14:14:54 mail kernel: da1: 764436MB (1565565872 512 byte > sectors: 255H 63S/T 97451C) > Oct 9 14:14:54 mail kernel: da1: quirks=0x2 Think the interface/enclosure has a RAID controller in it (notice da1 has 'LUN1' in it's id?) Michelle -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 10:30:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BDD23F9 for ; Sat, 11 Oct 2014 10:30:53 +0000 (UTC) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A66143CD for ; Sat, 11 Oct 2014 10:30:51 +0000 (UTC) Received: from msx3.exchange.alogis.com (msxcn2.exchange.alogis.com [10.1.1.22]) by alogis.com (8.13.4/8.13.1) with ESMTP id s9BAQMCb064679; Sat, 11 Oct 2014 12:26:22 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::1d83:c3db:ce3c:c06c]) by msxcn2.exchange.alogis.com ([::1]) with mapi id 14.03.0181.006; Sat, 11 Oct 2014 12:26:22 +0200 From: Holger Kipp To: Thomas Krause Subject: Re: 3 TB USB disk Thread-Topic: 3 TB USB disk Thread-Index: AQHP5ThEcRyAIrYnzkSMENEOTSYm25wqsSnT Date: Sat, 11 Oct 2014 10:26:21 +0000 Message-ID: References: <5438FAC6.3000807@chef-ingenieur.de> In-Reply-To: <5438FAC6.3000807@chef-ingenieur.de> Accept-Language: de-DE, en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 10:30:53 -0000 Hi Thomas, > On 11.10.2014, at 11:46, "Thomas Krause" wrote: >=20 > Hi, > I connected a 3TB USB disk to a FreeBSD 9.3 server. The drive is > recognized as 2 disks (da0: 2 TB and da1: 1TB). What is > wrong here? You might need to convert the disk to GPT. It might also be the case that t= he USB disk enclosure itself does not support larger disks. Best regards, Holger Further reading: http://ubuntuforums.org/showthread.php?t=3D2168222 http://www.avsforum.com/forum/26-home-theater-computers/1392024-help-3tb-dr= ives-shows-up-2048gb-second-drive.html#/forumsite/3207/topics/1392024 http://windowstipoftheday.blogspot.de/2011/04/windows-7-3tb-hard-drives-and= -larger.html?m=3D1 http://en.wikipedia.org/wiki/GUID_Partition_Table= From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:00:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB253C70 for ; Sat, 11 Oct 2014 13:00:48 +0000 (UTC) Received: from burnus.net (burnus.net [IPv6:2a01:238:4398:e500:7617:1fbd:1257:b2c7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E0642F5 for ; Sat, 11 Oct 2014 13:00:48 +0000 (UTC) Received: from nullzonenkonverter.lan (p508C71AD.dip0.t-ipconnect.de [80.140.113.173]) by burnus.net (Postfix) with ESMTPSA id 9979E2872034 for ; Sat, 11 Oct 2014 11:26:00 +0200 (CEST) Message-ID: <5438F7A4.4070908@burnus.net> Date: Sat, 11 Oct 2014 11:25:56 +0200 From: Christian Alge User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Server insists on wrong hostname Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:00:48 -0000 Hi, I am operating a FreeBSD 10.0-STABLE server and once upon a time I decided to change its hostname. I edited it in /etc/rc.conf, /etc/hosts and /etc/defaults/rc.conf. I also set it by invoking `sudo hostname`, but every time I restart it, it aquires the old name again. I fail to see, where that setting comes from. Can any of you help me out with that? Thanks in advance. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:02:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66337D65 for ; Sat, 11 Oct 2014 13:02:18 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 52AA930D for ; Sat, 11 Oct 2014 13:02:17 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NDA00D1U72OUT00@hades.sorbs.net> for freebsd-stable@freebsd.org; Sat, 11 Oct 2014 06:06:26 -0700 (PDT) Message-id: <54392A57.7020704@sorbs.net> Date: Sat, 11 Oct 2014 15:02:15 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Christian Alge Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> In-reply-to: <5438F7A4.4070908@burnus.net> Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:02:18 -0000 Christian Alge wrote: > Hi, > > I am operating a FreeBSD 10.0-STABLE server and once upon a time I > decided to change its hostname. I edited it in /etc/rc.conf, /etc/hosts > and /etc/defaults/rc.conf. I also set it by invoking `sudo hostname`, > but every time I restart it, it aquires the old name again. I fail to > see, where that setting comes from. Can any of you help me out with > that? Thanks in advance. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > If DHCPd probably from the DHCP server(and client).. If not DHCP check /etc/rc.conf and /etc/rc.conf.local. -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:26:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07237209; Sat, 11 Oct 2014 13:26:33 +0000 (UTC) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B126F6BF; Sat, 11 Oct 2014 13:26:32 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id s9BDQPrs019072; Sat, 11 Oct 2014 22:26:28 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Sat, 11 Oct 2014 22:26:24 +0900 (JST) Message-Id: <20141011.222624.2093799558803418171.nyan@FreeBSD.org> To: jhb@freebsd.org Subject: Re: [PATCH] Lock mse(4): test or the driver will be removed From: TAKAHASHI Yoshihiro In-Reply-To: <9831000.NFouVsJ1m1@ralph.baldwin.cx> References: <9831000.NFouVsJ1m1@ralph.baldwin.cx> X-Mailer: Mew version 6.3 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:26:33 -0000 In article <9831000.NFouVsJ1m1@ralph.baldwin.cx> John Baldwin writes: > This patch adds locking to mse(4) and marks it MPSAFE. It also adds some > other cleanups such as using bus_*() instead of bus_space_*() and > consolidating duplicate copies of its detach routine. The patch is against > HEAD but probably applies to 9 and 10 as well. I've tested this patch on current/pc98, and it works fine. --- TAKAHASHI Yoshihiro From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:32:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 672233B6 for ; Sat, 11 Oct 2014 13:32:20 +0000 (UTC) Received: from burnus.net (burnus.net [85.214.218.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BFDF7E2 for ; Sat, 11 Oct 2014 13:32:19 +0000 (UTC) Received: from nullzonenkonverter.lan (unknown [80.140.113.173]) by burnus.net (Postfix) with ESMTPSA id 13FB82872249 for ; Sat, 11 Oct 2014 15:32:17 +0200 (CEST) Message-ID: <54393142.4050005@burnus.net> Date: Sat, 11 Oct 2014 15:31:46 +0200 From: Christian Alge User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> In-Reply-To: <54392A57.7020704@sorbs.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:32:20 -0000 Thanks for your quick answer. The DHCP server is configured to assign the correct hostname to this server's MAC. /etc/rc.conf states the correct hostname, /etc/rc.conf.local does not exist. Neither do /usr/local/etc/rc.conf*. > Christian Alge > 11. Oktober 2014 11:25 > Hi, > > I am operating a FreeBSD 10.0-STABLE server and once upon a time I > decided to change its hostname. I edited it in /etc/rc.conf, /etc/hosts > and /etc/defaults/rc.conf. I also set it by invoking `sudo hostname`, > but every time I restart it, it aquires the old name again. I fail to > see, where that setting comes from. Can any of you help me out with > that? Thanks in advance. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Michelle Sullivan > 11. Oktober 2014 15:02 > If DHCPd probably from the DHCP server(and client).. If not DHCP check > /etc/rc.conf and /etc/rc.conf.local. > From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:34:47 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C487155D for ; Sat, 11 Oct 2014 13:34:47 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0FA380B for ; Sat, 11 Oct 2014 13:34:47 +0000 (UTC) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 494AC52AFA for ; Sat, 11 Oct 2014 06:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1413034481; bh=xMp8m1BzRoWRpU90rV3YsPHgssybLgI++KvsnTOtLxo=; h=Date:From:To:Subject:From; b=Vq5snwqHk6v6r2/ySHklpAtopW+3927utjmfZarGl0mLNkY+HauyglqKM/qnEtLx3 CFMe+YCb3lUEymE6XXBvuaTJCZ3TjNFwSS/KGxcu/nURna+ZwM2w5A2eSGfWK1b7D1 cN9pV8a8J7O7ZwjmLpbZz+TFgP9596BdzxiDDLoQ= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id BB48521D4B Message-ID: <543931EE.2060704@riseup.net> Date: Sat, 11 Oct 2014 15:34:38 +0200 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: ssh-copy-id doesn't work on 10.1-RC2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V1WvtP0LK1Nkg6DkmT2Rj1uOS5vubt1Bm" X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:34:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V1WvtP0LK1Nkg6DkmT2Rj1uOS5vubt1Bm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I use releng/10.1 at r272885. When I try to copy my private key with 'ssh-copy-id ~/.ssh/id_rsa.pub root@IP', I get: Unmatched '. Unmatched '. It worked before on releng/10.0. --V1WvtP0LK1Nkg6DkmT2Rj1uOS5vubt1Bm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUOTHuAAoJEC9nKukRsfY+bwsP/1CWEAYPnSOwqKvtVkOpfGMi 68zY6VNC3G0BIIT9b5+0N7I2guUWzQNWB9oITN0EMzrTY3ylyYVV5JZgDLi483Dk iWbJ/VH1K8cyUSby4RZ8CyR8jtspfXPUp6KCBrqluEAKq/bIrT/UFXd/ByY6Cfb5 A/gUr0Lyh3hT/MWg/f0qOejQEp8zKnh49YRMTBxDldF9pACKWHECtgoodrelAVB8 e1dlqM1Iiu2qHmxrn5m3jpC5PxojILHBk5vWu2mplEORK+Hlp2Os3eOQWX6MX4dQ kVsy3DhcU3BAiC4YoNcxA2VXzuwSWtAftq4jkWjKMg7SLC68zyKaOMJuEG2v5FCP Q6tfdbiWFtsPsAk7+lY+XxGxzlisc1ViPIRLIkklYVX8R5PZZeY0v6vULxVXzOpR oZpQYQKPCJ3j8LeJJRkdNsNJQ3Wy6MigwQRi+hIxmSZ4v68dLrrsNuoPkc7qUYZt VoY0EIsQ6be4VN/3UkAVmejrymYSjUsH5N6uEdqh4YYLy16uUdQI7jPczmefZ+gC jcZc2pKmLoYUDVD13IIG1iroze6MuOkzpujXTFM9ILA5Ii2XvlS6ybuhHVq2xYJA ugQbG7ugPsQLF34lPK6yX+QSwJ/ZvLvy67SO0+oL+ZIlrY56ZZpbDZmxI55+wwLE RneTLYWtaL7F5B4zWuQG =T6mZ -----END PGP SIGNATURE----- --V1WvtP0LK1Nkg6DkmT2Rj1uOS5vubt1Bm-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:36:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 536B36E4 for ; Sat, 11 Oct 2014 13:36:45 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 3F25282B for ; Sat, 11 Oct 2014 13:36:45 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NDA00D288O4UT00@hades.sorbs.net> for freebsd-stable@freebsd.org; Sat, 11 Oct 2014 06:40:53 -0700 (PDT) Message-id: <5439326B.3070508@sorbs.net> Date: Sat, 11 Oct 2014 15:36:43 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Christian Alge Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> In-reply-to: <54393142.4050005@burnus.net> Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:36:45 -0000 Christian Alge wrote: > Thanks for your quick answer. The DHCP server is configured to assign > the correct hostname to this server's MAC. /etc/rc.conf states the > correct hostname, /etc/rc.conf.local does not exist. Neither do > /usr/local/etc/rc.conf*. > > Doesn't sound right... I assume its just the 'hostname' command that is reporting the wrong information? What is it being set/reset to? Michelle -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:36:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 087B67CE for ; Sat, 11 Oct 2014 13:36:51 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 965A282E for ; Sat, 11 Oct 2014 13:36:50 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id em10so4207989wid.16 for ; Sat, 11 Oct 2014 06:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dCiNiEmNGgbLKfEQqbN8+SpOR+bDe7cNw4cVzJo13rA=; b=d42SsHSJ3mVwxVg5fVC/mlz5ibsEhny2r4RQ0z8WMHBwSRkx28XXLvK1doJj/FxLgN ne99iVp8sjDknGdJKJdovn6CJ4kWOe2IOnxkVWm0IfA+5hhz090DpuUGCOkiVPA7UEvA Hjifm7bamt2fuXBZ5QuFllQydbEH5tUNx4yU+qmsgQkikakL8297UcH0eOztLD4KiRJj IlSmaR+2jodwiwwXGn6Hx2a6KoWPMguzWW//ko30H+YSpIPmEbyvdIqQHUOJ3b09zTMr NQjgIITRp4MA6qrhIjAcwAVX+wD0Bd7BJFo2A6vzXNx0npMIeYbfa2X2EQUGm3oGoA3l YY0Q== MIME-Version: 1.0 X-Received: by 10.194.110.130 with SMTP id ia2mr1879887wjb.112.1413034608802; Sat, 11 Oct 2014 06:36:48 -0700 (PDT) Received: by 10.216.39.1 with HTTP; Sat, 11 Oct 2014 06:36:48 -0700 (PDT) In-Reply-To: <543931EE.2060704@riseup.net> References: <543931EE.2060704@riseup.net> Date: Sat, 11 Oct 2014 09:36:48 -0400 Message-ID: Subject: Re: ssh-copy-id doesn't work on 10.1-RC2 From: Brandon Allbery To: Piotr Kubaj Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:36:51 -0000 On Sat, Oct 11, 2014 at 9:34 AM, Piotr Kubaj wrote: > I use releng/10.1 at r272885. When I try to copy my private key with > 'ssh-copy-id ~/.ssh/id_rsa.pub root@IP', I get: > Unmatched '. > Unmatched '. > o.O is it missing a shebang? That looks like csh interpreting a /bin/sh script, possibly because it starts with a # that isn't a #!. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:37:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D40558C1 for ; Sat, 11 Oct 2014 13:37:11 +0000 (UTC) Received: from phoenix.eternamente.info (phoenix.arroway.org [109.169.80.17]) by mx1.freebsd.org (Postfix) with ESMTP id 59BA7844 for ; Sat, 11 Oct 2014 13:37:10 +0000 (UTC) Received: from [10.1.1.52] (unknown [179.156.47.80]) by phoenix.eternamente.info (Postfix) with ESMTPA id 35D8F1CC8F for ; Sat, 11 Oct 2014 10:29:04 -0300 (BRT) User-Agent: K-9 Mail for Android In-Reply-To: References: <5438FAC6.3000807@chef-ingenieur.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: 3 TB USB disk From: Nenhum_de_Nos Date: Sat, 11 Oct 2014 10:29:07 -0300 CC: "freebsd-stable@freebsd.org" Message-ID: <729FD171-6362-4CA3-A0BA-2BF827A3EFB8@eternamente.info> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:37:11 -0000 On October 11, 2014 7:26:21 AM GMT-03:00, Holger Kipp wrote: >Hi Thomas, > >> On 11.10.2014, at 11:46, "Thomas Krause" > wrote: >> >> Hi, >> I connected a 3TB USB disk to a FreeBSD 9.3 server. The drive is >> recognized as 2 disks (da0: 2 TB and da1: 1TB). What is >> wrong here? > >You might need to convert the disk to GPT. It might also be the case >that the USB disk enclosure itself does not support larger disks. > >Best regards, >Holger Could you tell the hardware model and manufacturer? Thanks, Matheus > >Further reading: >http://ubuntuforums.org/showthread.php?t=2168222 >http://www.avsforum.com/forum/26-home-theater-computers/1392024-help-3tb-drives-shows-up-2048gb-second-drive.html#/forumsite/3207/topics/1392024 >http://windowstipoftheday.blogspot.de/2011/04/windows-7-3tb-hard-drives-and-larger.html?m=1 > >http://en.wikipedia.org/wiki/GUID_Partition_Table >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to >"freebsd-stable-unsubscribe@freebsd.org" -- "We will call you Cygnus, the God of balance you shall be." From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 13:47:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C230DEE for ; Sat, 11 Oct 2014 13:47:52 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55A6B9D3 for ; Sat, 11 Oct 2014 13:47:52 +0000 (UTC) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 6A45C54792; Sat, 11 Oct 2014 06:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1413035271; bh=aHzavI9hO8sMkU20BuZPYIhxqXiyFXUHtu+AdynHoKU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=FwP4aA0u/OxArZ9XcIZciUxYLiMP99AStKYutZt/gibRRPOoy7IQ73LXJi7EKIBtL BNOsixmSAtuh3dxK3ZYzx5XzGCbdj1jPbxy2XYiRVxDAuUh2zQs00ERlUUAUutkVPR AvOf3xNAYJHW9QGoRm79PbcDCL5YzrLBu4sPpnIs= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id 7604421E0C Message-ID: <54393504.9090608@riseup.net> Date: Sat, 11 Oct 2014 15:47:48 +0200 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Brandon Allbery Subject: Re: ssh-copy-id doesn't work on 10.1-RC2 References: <543931EE.2060704@riseup.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TSB5BdmB5Qhigr71xt61bpPNUfA276DCq" X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 13:47:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TSB5BdmB5Qhigr71xt61bpPNUfA276DCq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/11/2014 15:36, Brandon Allbery wrote: > On Sat, Oct 11, 2014 at 9:34 AM, Piotr Kubaj > wrote: >=20 > I use releng/10.1 at r272885. When I try to copy my private key wit= h > 'ssh-copy-id ~/.ssh/id_rsa.pub root@IP', I get: > Unmatched '. > Unmatched '. >=20 >=20 > o.O is it missing a shebang? That looks like csh interpreting a /bin/sh= > script, possibly because it starts with a # that isn't a #!. >=20 > --=20 > brandon s allbery kf8nh sine nomine assoc= iates > allbery.b@gmail.com = =20 > ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomin= e.net No, there's "#!/bin/sh" at the beginning. To clear any possible confusion, I was obviously trying to copy my public key, not the private one :) Anyway, executing 'sh /usr/bin/ssh-copy-id -i .ssh/id_ecdsa.pub root@IP' doesn't change anything. --TSB5BdmB5Qhigr71xt61bpPNUfA276DCq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUOTUEAAoJEC9nKukRsfY+NgAQAM/MCUHA5MTR0Wloql49Vx5N j9oPSYjFgO9++/8iSkToYOkoYGSzBxjZhRPFbrDfpzWHDB68BuwGgfHXX21vMvML eZTNeU7N8KOSxVyhPn89BT44Jxr2Lp6d6TglWc8rdqQmpWxXR0xe0J1gEeFcK3N2 UzksmTxXWkGjyqMa5hiGRGefDHUCN785cZwcKyxhv/IHKa7fiHQg2CgJlp093mcg 2mseL3RgC1znna0sieUMBYCg55CgU/PoBkOASTcT1zJ023ZVF1zTJiQu04rEmQ1J 87HVt5hkR4cdDHkIuQunvMEFiusJaj4WXVtPNeILE0uL/C3s4yY9Lr8OhDeuk5H/ GD0CiF1t0ITCrQ1ucun4wxweRy/sohw8wskpQ95tgOopjkmEwuVstHCvPFBwbLH/ 22iWcbtYIvTo2+C446CmLq03UcylSyJ/ClVtobIxM+ogQ/u83KLPRe+Pswk0zsnV 7+lEwXuT/dl+WmclbCyuuUygDiLrE0pRRetYJKOk45ic8XejtX2Sik7P6nXpMfY8 213KJ1l0M+2wpVMjBR1CA5SbSshUDh2W7EpZFg14XCVXoBOgOlRAXe7VE0plnFfg +/BWBuEk0U//FYxDYeQeF6eJ9LSIX1363o6ocS5mVi4bjj32p3pJtA3mRN0a8yhx 8nbRglZ7O6DRxowvngu/ =B8Y3 -----END PGP SIGNATURE----- --TSB5BdmB5Qhigr71xt61bpPNUfA276DCq-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 14:19:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32C82CFA for ; Sat, 11 Oct 2014 14:19:48 +0000 (UTC) Received: from burnus.net (burnus.net [85.214.218.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E66B5CB9 for ; Sat, 11 Oct 2014 14:19:47 +0000 (UTC) Received: from nullzonenkonverter.lan (p508C71AD.dip0.t-ipconnect.de [80.140.113.173]) by burnus.net (Postfix) with ESMTPSA id 4DC5A2872034 for ; Sat, 11 Oct 2014 16:19:44 +0200 (CEST) Message-ID: <54393C76.7090702@burnus.net> Date: Sat, 11 Oct 2014 16:19:34 +0200 From: Christian Alge User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> In-Reply-To: <5439326B.3070508@sorbs.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 14:19:48 -0000 Doesn't sound right indeed.. The name is being set to the server's previous name ("Freie Energie" instead of "freieenergie"). Would that issue in the hostname command also concern the output of `print -P %m`? Also why would hostname do that? On a side note, I had the complete file system searched for any file containing the old name and none was returned. So where could it be stored? > Christian Alge > 11. Oktober 2014 11:25 > Hi, > > I am operating a FreeBSD 10.0-STABLE server and once upon a time I > decided to change its hostname. I edited it in /etc/rc.conf, /etc/hosts > and /etc/defaults/rc.conf. I also set it by invoking `sudo hostname`, > but every time I restart it, it aquires the old name again. I fail to > see, where that setting comes from. Can any of you help me out with > that? Thanks in advance. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Michelle Sullivan > 11. Oktober 2014 15:02 > If DHCPd probably from the DHCP server(and client).. If not DHCP check > /etc/rc.conf and /etc/rc.conf.local. > > Christian Alge > 11. Oktober 2014 15:31 > Thanks for your quick answer. The DHCP server is configured to assign > the correct hostname to this server's MAC. /etc/rc.conf states the > correct hostname, /etc/rc.conf.local does not exist. Neither do > /usr/local/etc/rc.conf*. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Michelle Sullivan > 11. Oktober 2014 15:36 > > Doesn't sound right... I assume its just the 'hostname' command that is > reporting the wrong information? What is it being set/reset to? > > Michelle > From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 14:25:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5500EF90 for ; Sat, 11 Oct 2014 14:25:04 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 3F98DD7E for ; Sat, 11 Oct 2014 14:25:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NDA00D2SAWMUT00@hades.sorbs.net> for freebsd-stable@freebsd.org; Sat, 11 Oct 2014 07:29:11 -0700 (PDT) Message-id: <54393DBD.4030602@sorbs.net> Date: Sat, 11 Oct 2014 16:25:01 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Christian Alge Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> <54393C76.7090702@burnus.net> In-reply-to: <54393C76.7090702@burnus.net> Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 14:25:04 -0000 Christian Alge wrote: > Doesn't sound right indeed.. The name is being set to the server's > previous name ("Freie Energie" instead of "freieenergie"). Would that > issue in the hostname command also concern the output of `print -P %m`? > Also why would hostname do that? On a side note, I had the complete file > system searched for any file containing the old name and none was > returned. So where could it be stored? > > > Put the DHCP client in debug mode - it's most likely coming from the DHCP server (did you restart it after changing the config?) Michelle >> Christian Alge >> 11. Oktober 2014 11:25 >> Hi, >> >> I am operating a FreeBSD 10.0-STABLE server and once upon a time I >> decided to change its hostname. I edited it in /etc/rc.conf, /etc/hosts >> and /etc/defaults/rc.conf. I also set it by invoking `sudo hostname`, >> but every time I restart it, it aquires the old name again. I fail to >> see, where that setting comes from. Can any of you help me out with >> that? Thanks in advance. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> Michelle Sullivan >> 11. Oktober 2014 15:02 >> If DHCPd probably from the DHCP server(and client).. If not DHCP check >> /etc/rc.conf and /etc/rc.conf.local. >> >> Christian Alge >> 11. Oktober 2014 15:31 >> Thanks for your quick answer. The DHCP server is configured to assign >> the correct hostname to this server's MAC. /etc/rc.conf states the >> correct hostname, /etc/rc.conf.local does not exist. Neither do >> /usr/local/etc/rc.conf*. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> Michelle Sullivan >> 11. Oktober 2014 15:36 >> >> Doesn't sound right... I assume its just the 'hostname' command that is >> reporting the wrong information? What is it being set/reset to? >> >> Michelle >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 15:10:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C08A5A6E for ; Sat, 11 Oct 2014 15:10:46 +0000 (UTC) Received: from burnus.net (burnus.net [85.214.218.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C5E819C for ; Sat, 11 Oct 2014 15:10:46 +0000 (UTC) Received: from nullzonenkonverter.lan (unknown [IPv6:2a01:1e8:e1a0:0:c35:ce96:33c7:2f25]) by burnus.net (Postfix) with ESMTPSA id 87C502872034 for ; Sat, 11 Oct 2014 17:10:41 +0200 (CEST) Message-ID: <5439485F.4000002@burnus.net> Date: Sat, 11 Oct 2014 17:10:23 +0200 From: Christian Alge User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> <54393C76.7090702@burnus.net> <54393DBD.4030602@sorbs.net> In-Reply-To: <54393DBD.4030602@sorbs.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 15:10:46 -0000 I do not know, how to put it in debug mode. The manpages of dhclient and dhclient.conf are not very helpful.. Instead I reinvoked dhclient for the interface with dhcpdump running. The output looks right to me (see below, slightly obfuscated).. Notice that both the request and the reply contain the correct hostname (in option 12). However, the hostname does not seem to be set in the end (hostname still reports the old name). And yes, I did restart the DHCP server after changing the config. TIME: 2014-10-11 16:58:09.563 IP: 192.168.1.5 (00:22:xx:xx:xx:xx) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 1 (BOOTPREQUEST) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: xxxxxxxx SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 0.0.0.0 SIADDR: 0.0.0.0 GIADDR: 0.0.0.0 CHADDR: 00:22:xx:xx:xx:xx:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST) OPTION: 50 ( 4) Request IP address 192.168.1.5 OPTION: 61 ( 7) Client-identifier 01:00:22:xx:xx:xx:xx OPTION: 12 ( 12) Host name freieenergie OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) 28 (Broadcast address) 2 (Time offset) 121 (Classless Static Route) 3 (Routers) 15 (Domainname) 6 (DNS server) 12 (Host name) 119 (Domain Search) --------------------------------------------------------------------------- TIME: 2014-10-11 16:58:09.564 IP: 192.168.1.1 (a0:f3:xx:xx:xx:xx) > 192.168.1.5 (00:22:xx:xx:xx:xx) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: a4xxxxxx SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 192.168.1.5 SIADDR: 192.168.1.1 GIADDR: 0.0.0.0 CHADDR: 00:22:xx:xx:xx:xx:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 5 (DHCPACK) OPTION: 54 ( 4) Server identifier 192.168.1.1 OPTION: 51 ( 4) IP address leasetime 43200 (12h) OPTION: 58 ( 4) T1 21600 (6h) OPTION: 59 ( 4) T2 37800 (10h30m) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 28 ( 4) Broadcast address 192.168.1.255 OPTION: 3 ( 4) Routers 192.168.1.1 OPTION: 6 ( 4) DNS server 192.168.1.1 OPTION: 15 ( 3) Domainname lan OPTION: 12 ( 12) Host name freieenergie --------------------------------------------------------------------------- Michelle Sullivan schrieb: > Put the DHCP client in debug mode - it's most likely coming from the > DHCP server (did you restart it after changing the config?) From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 15:21:24 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0B25D49 for ; Sat, 11 Oct 2014 15:21:24 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1BB32E for ; Sat, 11 Oct 2014 15:21:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NDA00D3ADIIUT00@hades.sorbs.net> for freebsd-stable@freebsd.org; Sat, 11 Oct 2014 08:25:32 -0700 (PDT) Message-id: <54394AF1.7000807@sorbs.net> Date: Sat, 11 Oct 2014 17:21:21 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Christian Alge Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> <54393C76.7090702@burnus.net> <54393DBD.4030602@sorbs.net> <5439485F.4000002@burnus.net> In-reply-to: <5439485F.4000002@burnus.net> Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 15:21:24 -0000 Christian Alge wrote: > I do not know, how to put it in debug mode. The manpages of dhclient and > dhclient.conf are not very helpful.. > Instead I reinvoked dhclient for the interface with dhcpdump running. > The output looks right to me (see below, slightly obfuscated).. Notice > that both the request and the reply contain the correct hostname (in > option 12). However, the hostname does not seem to be set in the end > (hostname still reports the old name). > And yes, I did restart the DHCP server after changing the config. > :) you are correct it does show the correct hostname in the DHCP reply... ok I'm as stumped as you... the only other option I can think is if something is setting HOSTNAME as an environmental variable (in your login shell) .. but I thought using the hostname command would read the system not your env ... so am stumped without getting onto the system myself and poking around (which even if that was an option for you, it wouldn't be for me, sorry.) Michelle -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 15:29:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13FF6F0A for ; Sat, 11 Oct 2014 15:29:44 +0000 (UTC) Received: from burnus.net (burnus.net [85.214.218.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5ABB36C for ; Sat, 11 Oct 2014 15:29:43 +0000 (UTC) Received: from nullzonenkonverter.lan (unknown [IPv6:2a01:1e8:e1a0:0:c35:ce96:33c7:2f25]) by burnus.net (Postfix) with ESMTPSA id E2B682872034 for ; Sat, 11 Oct 2014 17:29:41 +0200 (CEST) Message-ID: <54394CDB.5050504@burnus.net> Date: Sat, 11 Oct 2014 17:29:31 +0200 From: Christian Alge User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> <54393C76.7090702@burnus.net> <54393DBD.4030602@sorbs.net> <5439485F.4000002@burnus.net> <54394AF1.7000807@sorbs.net> In-Reply-To: <54394AF1.7000807@sorbs.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 15:29:44 -0000 That would be rather unlikely. I definitely haven't set it manually. And my husband, who is using a different shell (bash instead of zsh) with a completely different config, has neither, but can reproduce the problem as well.. Hope, someone here knows more.. Michelle Sullivan schrieb: > the only other option I can think > is if something is setting HOSTNAME as an environmental variable (in > your login shell) From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 16:23:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E804BD83; Sat, 11 Oct 2014 16:23:18 +0000 (UTC) Date: Sat, 11 Oct 2014 16:23:14 +0000 From: Glen Barber To: John Wolfe Subject: Re: Naming of Stable Message-ID: <20141011162314.GB26035@hub.FreeBSD.org> References: <5437E811.1030304@gmail.com> <54381DBF.5020907@xinuos.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: <54381DBF.5020907@xinuos.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Johan Hendriks , Kevin Oberman , FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 16:23:19 -0000 --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 10, 2014 at 01:56:15PM -0400, John Wolfe wrote: > I took Johan's e-mail to be a suggestion that the changes made by Glen B. > to sys/conf/newvers.h through the 10.1 Beta and RC1 stages be reverted ba= ck > to "10-STABLE" now that the releng/10.1 branch has been made. >=20 This is how I took it, as well. I forgot to change stable/10 back to -PRERELEASE after the -RC1 builds completed. It has been done as r272942. Glen --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUOVlyAAoJEAMUWKVHj+KTyNIP/23QWZpRkus+QB+QLBT948vM WqcPEYU9YHKVNYI5W0W1XjbcJft/I2hvo/gCQgHQz6/QPsiThw5yha1yY/rgPR0W 6k9Yeh155hH0cBzJ60se+P2TXbB0VlJ3HpGS0mm5H8OaTp83HU5G2jYJo5zcKTpN k0ZKPtmSsJWI7plI7EzXsz9dDL3itHqZiU4Qba2MFXf3WbB8hA0OP6poyDjRV3H2 7hrEAyGsxfmIs4k8DNRV9UBYZYNQrmDhOFhDiB1Mby8KX8Z98MpMHfsSDNE3WDFy umT4bSeyewFtDUUNZ4oaAqGS9t/MNQz5tvOh6bnH7WenQ7TAXR6yj4r2TXNxvw15 5AYFy3wo1FpyvdJmFbfvPXRoi8RHj05JvrPLl6bXdu1as1bh0G8IgSYbE+DGdCx5 SQNp2s65Hq4m/5Tyxh1q9WbyeVtlbCR+g+7I/NVbFQS8vyH5CxTbhq2GpAehHDPe NQjMurnG/ykV/8io7P7rEzkftPkB299sCdsH5xqY9b2/ggvmV4mG7wk1MG44KF9t 0JgkLAJgENR0+sNz+9BoygVve5wy438ClerumAaUzEZ+iR44Wphj8geNIEg/or62 DpkrLEyiPm4lQ1l3/cwmjjhNCQRepBas7UQMZTrfMN96exBxiuIZum1P712vY6Te +26/A+c6jGZi7DYDbFrF =TBmf -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 16:33:24 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C92EF63 for ; Sat, 11 Oct 2014 16:33:24 +0000 (UTC) Received: from burnus.net (burnus.net [85.214.218.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F28C2B6A for ; Sat, 11 Oct 2014 16:33:23 +0000 (UTC) Received: from nullzonenkonverter.lan (p508C71AD.dip0.t-ipconnect.de [80.140.113.173]) by burnus.net (Postfix) with ESMTPSA id 37D7C2872034 for ; Sat, 11 Oct 2014 18:33:20 +0200 (CEST) Message-ID: <54395BC2.7090204@burnus.net> Date: Sat, 11 Oct 2014 18:33:06 +0200 From: Christian Alge User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Re: Server insists on wrong hostname References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> <54393C76.7090702@burnus.net> <54393DBD.4030602@sorbs.net> <5439485F.4000002@burnus.net> <54394AF1.7000807@sorbs.net> In-Reply-To: <54394AF1.7000807@sorbs.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 16:33:24 -0000 That returns nothing. > Well, a rather "brute force" approach would be: > > grep -r 'Freie Energie' /etc/ > > (Mind, you may need root access to avoid "permission denied" messages > -- or you culd just ignore them, if you are confident that the files > in question are sufficiently unlikely to be at fault.) > > If that fails, I have a possible other approach in mind, but it's a bit > of a mess, so I'd rather not even try to describe it unless nothing else > works. > > Peace, > david > From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 16:40:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6F0D383 for ; Sat, 11 Oct 2014 16:40:45 +0000 (UTC) Received: from mout.web.de (mout.web.de [212.227.15.3]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.web.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63735BB9 for ; Sat, 11 Oct 2014 16:40:44 +0000 (UTC) Received: from [10.0.0.2] ([91.60.11.245]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MH2Fm-1XQMbH0GjC-00Domo for ; Sat, 11 Oct 2014 18:35:25 +0200 Subject: Re: 3 TB USB disk From: Marc Santhoff To: freebsd-stable@freebsd.org In-Reply-To: References: <5438FAC6.3000807@chef-ingenieur.de> Content-Type: text/plain; charset="ISO-8859-15" Date: Sat, 11 Oct 2014 18:33:29 +0200 Message-ID: <1413045209.5590.5.camel@puma.das.netz> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qON8koixBpjEiw0smbOGh2XvYMlhuAnlRalJNbO0X8N3RvO1cVU hQAu9aajEDGNBeQ7a9y+/IpGY4mDakXoO2SnA7CKjmeYHBNFelbm9v+8bwQlPTwvp+ro71k R7TKtSTpGZQJ0Lu86NqxmW91D74Y/zu23/BBEVz1C0LoqVxvOUgN9MGHjZ05BzOyFZ/P4gX bE5UUJEQFSkxRl7tclphQ== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 16:40:45 -0000 On Sa, 2014-10-11 at 10:26 +0000, Holger Kipp wrote: > Hi Thomas, > > > On 11.10.2014, at 11:46, "Thomas Krause" wrote: > > > > Hi, > > I connected a 3TB USB disk to a FreeBSD 9.3 server. The drive is > > recognized as 2 disks (da0: 2 TB and da1: 1TB). What is > > wrong here? > > You might need to convert the disk to GPT. It might also be the case > that the USB disk enclosure itself does not support larger disks. It's most probably the controller chip in the enclosure that cannot handle the size of the disk. Seen that myself once, the enclosure was not specified for any disk size. After buying the same model but looking for a specifiaction saying "up to 4 GB" anything worked nicely having one disk wiht full capacity. -- Marc Santhoff From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 18:51:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 211BAC4D for ; Sat, 11 Oct 2014 18:51:25 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E15B4AA9 for ; Sat, 11 Oct 2014 18:51:24 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id hn15so6411728igb.9 for ; Sat, 11 Oct 2014 11:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GdxbaSm8ks6okUC0XmO2QT7/AhE7BvMPyVeAqD/TRCc=; b=FJO47o28RXs5HZswTe/0ILwYz6tXECMk0LTWwlnKJ9r6W8km13RdBL8fgp+nxuRILc aSmvRDYwo7762DF2tpmkY1MPlpp41+Eox0T5crP6qaNQrJXbEHtrkagmxu8mM/Fz9CGU z31SZ8Yj+2KyiK4CWtg5GsSfL5+HdyITiylx3H8XtTD9XM4prSgyzNWKvMapaxU/ED9V VQCsUnoilE6QApGQf4I8JqIHJ+k9wt2qounGNuklf4n5pNLBXvtNakeNRiasWr+Ogz6q I0TC3E6+jjGmBHGctteaSWai4bdXBy+A/RYtH/78zbjWLjV+tCPIb4RtAwC6HElnISa3 afRw== MIME-Version: 1.0 X-Received: by 10.50.43.193 with SMTP id y1mr17360336igl.32.1413053484330; Sat, 11 Oct 2014 11:51:24 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.11.141 with HTTP; Sat, 11 Oct 2014 11:51:24 -0700 (PDT) In-Reply-To: <54395BC2.7090204@burnus.net> References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> <54393C76.7090702@burnus.net> <54393DBD.4030602@sorbs.net> <5439485F.4000002@burnus.net> <54394AF1.7000807@sorbs.net> <54395BC2.7090204@burnus.net> Date: Sat, 11 Oct 2014 11:51:24 -0700 X-Google-Sender-Auth: 4PS7O0N3CxRTQ-08tbuYau-SuLE Message-ID: Subject: Re: Server insists on wrong hostname From: Kevin Oberman To: Christian Alge Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 18:51:25 -0000 On Sat, Oct 11, 2014 at 9:33 AM, Christian Alge wrote: > That returns nothing. > > Well, a rather "brute force" approach would be: > > > > grep -r 'Freie Energie' /etc/ > > > > (Mind, you may need root access to avoid "permission denied" messages > > -- or you culd just ignore them, if you are confident that the files > > in question are sufficiently unlikely to be at fault.) > > > > If that fails, I have a possible other approach in mind, but it's a bit > > of a mess, so I'd rather not even try to describe it unless nothing else > > works. > > > > Peace, > > david > > > I suspect some script is executing a hostname(1), but this is just guessing. I'd suggest adding "hostname" in a few places in startup scripts (/etc/rc.d and /usr/local/etc/rc.d). If you see which script is doing it, use rcorder(8) to see what scripts could be triggering it. Turning on debugging in startup may also help, but will produce a LOT of output during startup and shutdown. (Set rc_debug="YES") Unrelated, but important... you mentioned editing /etc/defaults/rc.conf. This is a VERY bad idea. Those scripts are always overridden by the matching scripts, if any, in /etc. System upgrades assume that they are untouched and changing them can really break things. If /etc/rc.conf has a "hostname="freieenergie" line, it will override anything in /etc/defaults/rc.conf. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 19:37:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BCAE99; Sat, 11 Oct 2014 19:37:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34EECE9F; Sat, 11 Oct 2014 19:37:17 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7D771B962; Sat, 11 Oct 2014 15:37:15 -0400 (EDT) From: John Baldwin To: TAKAHASHI Yoshihiro Subject: Re: [PATCH] Lock mse(4): test or the driver will be removed Date: Sat, 11 Oct 2014 15:37:09 -0400 Message-ID: <2763834.PSmF5d9rpd@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <20141011.222624.2093799558803418171.nyan@FreeBSD.org> References: <9831000.NFouVsJ1m1@ralph.baldwin.cx> <20141011.222624.2093799558803418171.nyan@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 11 Oct 2014 15:37:15 -0400 (EDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 19:37:17 -0000 On Saturday, October 11, 2014 10:26:24 PM TAKAHASHI Yoshihiro wrote: > In article <9831000.NFouVsJ1m1@ralph.baldwin.cx> > > John Baldwin writes: > > This patch adds locking to mse(4) and marks it MPSAFE. It also adds some > > other cleanups such as using bus_*() instead of bus_space_*() and > > consolidating duplicate copies of its detach routine. The patch is > > against > > HEAD but probably applies to 9 and 10 as well. > > I've tested this patch on current/pc98, and it works fine. Great, thanks! -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sat Oct 11 22:32:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECAF0652 for ; Sat, 11 Oct 2014 22:32:27 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id C3D8FE2 for ; Sat, 11 Oct 2014 22:32:26 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 581C145087; Sat, 11 Oct 2014 22:22:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 581C145087 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1413066170; bh=Wd3YyG53XlAUfFVjnfGhcKL0bvmF5OooRaOF23UyeLQ=; h=Date:From:To:Subject:References:In-Reply-To; b=Zht/vogFjAPQNoglu76C4ujRe+u5BaaRCyNux+2+W8HNue99VGj2cw/QmbuoTU5uh 7ewhdsJcmlt9fiQ+OQSxkJJUE4G2dAcPXa2EQqWPGgfN2exG7gXl1UMkpQj1c5h3EH 4Gd18F6S7xplhsiNTTGOWNgHWj5MKIZav7/J/giA= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 1F9A8153BE; Sat, 11 Oct 2014 23:22:45 +0100 (BST) Date: Sat, 11 Oct 2014 23:22:45 +0100 From: Ben Morrow To: Christian Alge , freebsd-stable@freebsd.org Subject: Re: Server insists on wrong hostname Message-ID: <20141011222243.GA23187@anubis.morrow.me.uk> Mail-Followup-To: Christian Alge , freebsd-stable@freebsd.org References: <5438F7A4.4070908@burnus.net> <54392A57.7020704@sorbs.net> <54393142.4050005@burnus.net> <5439326B.3070508@sorbs.net> <54393C76.7090702@burnus.net> <54393DBD.4030602@sorbs.net> <5439485F.4000002@burnus.net> <54394AF1.7000807@sorbs.net> <54395BC2.7090204@burnus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 22:32:28 -0000 Quoth Kevin Oberman : > On Sat, Oct 11, 2014 at 9:33 AM, Christian Alge wrote: > > > > Well, a rather "brute force" approach would be: > > > > > > grep -r 'Freie Energie' /etc/ > > > > > > (Mind, you may need root access to avoid "permission denied" messages > > > -- or you culd just ignore them, if you are confident that the files > > > in question are sufficiently unlikely to be at fault.) > > > > > > If that fails, I have a possible other approach in mind, but it's a bit > > > of a mess, so I'd rather not even try to describe it unless nothing else > > > works. > > > > That returns nothing. > > I suspect some script is executing a hostname(1), but this is just > guessing. I'd suggest adding "hostname" in a few places in startup scripts > (/etc/rc.d and /usr/local/etc/rc.d). If you see which script is doing it, > use rcorder(8) to see what scripts could be triggering it. You could also try renaming /bin/hostname to /bin/hostname.real and putting something like this in /bin/hostname: #!/bin/sh if [ $# -gt 0 ] then echo "PID: $$" >>/tmp/hostname.log echo "ARGS: $*" >>/tmp/hostname.log /bin/ps axd >>/tmp/hostname.log fi exec /bin/hostname.real "$@" Remember to put it back afterwards. (It ought to be possible to do this by using dtrace to catch calls to set the kern.hostname sysctl, but I don't know how to do that.) Ben