From owner-freebsd-stable@FreeBSD.ORG Sun Nov 2 16:10: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 3A29DA5B for ; Sun, 2 Nov 2014 16:10:37 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F13DB3EC for ; Sun, 2 Nov 2014 16:10:36 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XkxjS-0001co-Ss for freebsd-stable@freebsd.org; Sun, 02 Nov 2014 17:10:28 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: CFT: Update to xf86-video-ati 7.5.0 References: <544E0FC8.8090605@FreeBSD.org> Date: Sun, 02 Nov 2014 17:10:21 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <544E0FC8.8090605@FreeBSD.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: dfea3049d3b923820beb462d65569822 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, 02 Nov 2014 16:10:37 -0000 On Mon, 27 Oct 2014 10:26:32 +0100, Jean-S=C3=A9bastien P=C3=A9dron = wrote: > Hi! > > Before updating xf86-video-ati to 7.5.0, we would like some people to > try it out. The reason is that 7.4.0 was crashing for several users, s= o > we want to be sure it's fixed in 7.5.0. > > Here's patch: > https://people.freebsd.org/~dumbbell/graphics/ports-xf86-video-ati-7.5= .0.patch > > To apply it: > cd /usr/ports > patch -p1 < /path/to/ports-xf86-video-ati-7.5.0.patch > > Then update x11-drivers/xf86-video-ati with your method of choice. > > What we're especially looking for is report of successful or failed > startup of the X server. With 7.4.0, the server would crash during > startup. But with 7.5.0, none of us could reproduce the problem. > > When you're finished, you may restore your vanilla ports tree: > cd /usr/ports > patch -p1 -R < /path/to/ports-xf86-video-ati-7.5.0.patch > find x11-drivers/xf86-video-ati -name "*.orig" -delete > > Thank you for your help! > Works ok here. FreeBSD 10-STABLE/amd64 ATI Radeon HD 2600 XT RV630 From owner-freebsd-stable@FreeBSD.ORG Sun Nov 2 17:36: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 2AD28B55 for ; Sun, 2 Nov 2014 17:36:57 +0000 (UTC) Received: from epost.telsys.no (epost.telsys.no [213.188.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id D6127D85 for ; Sun, 2 Nov 2014 17:36:56 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by epost.telsys.no (Postfix) with ESMTP id 7FC5F4003DA for ; Sun, 2 Nov 2014 18:36:55 +0100 (CET) Received: from epost.telsys.no ([127.0.0.1]) by localhost (epost.telsys.no [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7tFknEq32Qul for ; Sun, 2 Nov 2014 18:36:54 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by epost.telsys.no (Postfix) with ESMTP id E3D3F400480 for ; Sun, 2 Nov 2014 18:36:54 +0100 (CET) X-Virus-Scanned: amavisd-new at epost.telsys.no Received: from epost.telsys.no ([127.0.0.1]) by localhost (epost.telsys.no [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id x_5Op_75pvXc for ; Sun, 2 Nov 2014 18:36:54 +0100 (CET) Received: from ms3.telsys.no (ms3.telsys.no [213.188.12.46]) by epost.telsys.no (Postfix) with ESMTP id CF41A4003DA for ; Sun, 2 Nov 2014 18:36:54 +0100 (CET) Date: Sun, 2 Nov 2014 18:36:54 +0100 (CET) From: "Thor E. Lie" To: freebsd-stable@freebsd.org Message-ID: <637493342.277606.1414949814817.JavaMail.zimbra@thorerik.com> In-Reply-To: <935627270.271423.1414945303076.JavaMail.zimbra@thorerik.com> References: <935627270.271423.1414945303076.JavaMail.zimbra@thorerik.com> Subject: PF NAT seeminglt drops TCP connections at random MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - FF33 (Win)/8.0.8_GA_6184) Thread-Topic: PF NAT seeminglt drops TCP connections at random Thread-Index: YLmRwbftFHujuwkdknkKjdpWDl6mvd5DAzLX 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, 02 Nov 2014 17:36:57 -0000 Hi, I've been configuring a new server with FreeBSD 10.0-RELEASE-p10, Jails(via ezjail) and PF with NAT Translation rules. Initially when logging in to a jail the connection would randomly drop, usually when there where (relativel) large databursts(eg. tailing a log, opening vi(m) or similar that would clear the screen). When running a TCPdump and analyzing it seemed to drop right around when tcpdump recorded a "IP bad-len 0", which led me to this february 2008 post[1] on the list, which at least in terms of the nic fits the bill[2], so I proceeded to follow 2 of the suggestions that where posted there(net.inet.tcp.rfc1323=0 and net.inet.tcp.tso=0), disabling rfc1323 sysctl resolved the SSH sessions dropping. However when downloading a package, or downloading something with fetch, it drops the connection again, it seems like it sends a fin(or fin-ack? I'm not terribly comfortable with tcpdump yet)[3]. [1]: https://lists.freebsd.org/pipermail/freebsd-current/2008-February/083056.html [2]: http://pastebin.com/MQAkmW14 [3]: http://pastebin.com/wDU9xYK5 -- Thor From owner-freebsd-stable@FreeBSD.ORG Sun Nov 2 19:23:34 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 4466AA8; Sun, 2 Nov 2014 19:23:34 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EA6DD9D4; Sun, 2 Nov 2014 19:23:33 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sA2JNWxO090212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Nov 2014 12:23:32 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sA2JNVI4090209; Sun, 2 Nov 2014 12:23:31 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 2 Nov 2014 12:23:31 -0700 (MST) From: Warren Block To: John Baldwin Subject: Re: Small motd nit in 10.1 In-Reply-To: Message-ID: References: <8C81A636-D2B5-4EFB-9EA3-58E88E16CA94@spam.lifeforms.nl> <93E9657A-737E-4705-A0E5-01F9E9110261@gromit.dlib.vt.edu> <201410301554.03504.jhb@freebsd.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 02 Nov 2014 12:23:32 -0700 (MST) Cc: freebsd-stable@freebsd.org, Walter Hop 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, 02 Nov 2014 19:23:34 -0000 On Thu, 30 Oct 2014, Warren Block wrote: > On Thu, 30 Oct 2014, Warren Block wrote: > >> There is room on that line to show both: >> >> Show details of the FreeBSD installation: uname -a ; freebsd-version >> >> Or some combination like that. > > Actually, I think the output from 'freebsd-version ; uname -a' is less > ambiguous. Since nobody has complained about this, I'll update head now and plan to MFC it. Hopefully it will be in time for 10.1-RELEASE. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 2 19:43:53 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 492D26E8; Sun, 2 Nov 2014 19:43:53 +0000 (UTC) Date: Sun, 2 Nov 2014 19:43:44 +0000 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 10.1-RC4 Now Available Message-ID: <20141102194344.GA21862@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, 02 Nov 2014 19:43:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The fourth 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. This is anticipated to be the final RC build of the 10.1-RELEASE cycle. 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: Using multi-disk ZFS configurations on i386 (mirror, raidz-1, raidz-2, etc.) may cause a kernel panic on boot. Adding 'options KSTACK_PAGES=4' to the kernel configuration is observed 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. This is also mentioned in the 10.1-RELEASE Errata Documentation: https://www.freebsd.org/releases/10.1R/errata.html Some of the changes between 10.1-RC3 and 10.1-RC4 include: o Fix ATA CF ERASE breakage for certain CF cards. o Fix a race in pmap_emulate_accessed_dirty() that could trigger a EPT misconfiguration VM-exit. Pre-installed virtual machine images for 10.1-RC4 are also available for amd64 and i386 architectures. The images are located here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.1-RC4/ 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-RC4 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 9.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-RC4 amd64 GENERIC: SHA256 (FreeBSD-10.1-RC4-amd64-bootonly.iso) = 2320c4e01621c33e4a42da5c58db28530be87c30d0d908dbabb7327de3da1012 SHA256 (FreeBSD-10.1-RC4-amd64-bootonly.iso.xz) = 418495d16e12223d4651c3dd9fa57f388e86b2ebe63cb4ee5dc7f5bb144e2a3c SHA256 (FreeBSD-10.1-RC4-amd64-disc1.iso) = 6d383269211de555de7678cd5adb89aa239c88aa77bb929da464c2e390aed6db SHA256 (FreeBSD-10.1-RC4-amd64-disc1.iso.xz) = c562aba0efa64df1c2a5d171549e4f14d91d6937f4b38a542038f6c9d12b74ba SHA256 (FreeBSD-10.1-RC4-amd64-dvd1.iso) = ebab4fa59299989674426111eb9a91e5525374f76840d3a5103bc05a5bce603b SHA256 (FreeBSD-10.1-RC4-amd64-dvd1.iso.xz) = 7b092d0734305e9dc6baaf06d38ed9f60f5be97c4ddad032a206f984e77dc136 SHA256 (FreeBSD-10.1-RC4-amd64-memstick.img) = 498db8ec6dfcb3974a298c4053ca7cdf34a3a310d72f289d73ac1316418cf03b SHA256 (FreeBSD-10.1-RC4-amd64-memstick.img.xz) = 09a2b354929a87a83f7a704e54d93a5a29df35cd1fd1b842e5a8b18c20dee90a SHA256 (FreeBSD-10.1-RC4-amd64-mini-memstick.img) = ef4468f13f0009d1d2ac9325416a1f29c182fad45479cdaf3cd8312bbade3be1 SHA256 (FreeBSD-10.1-RC4-amd64-mini-memstick.img.xz) = 25bbe34ed21ab21d9f983ec7edb723ec8adf0e69a3b73aad8db33d7f75c9f190 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-bootonly.iso) = 2d4f1d097d23eafd61dd2730e1e923a150b9c5da4218f3365bf7b50bbb3f4df6 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-bootonly.iso.xz) = 789efb8f204e9ab7bd74911c9b7110c9ec890f2f1cbe6eea1a0219867f9b7600 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-disc1.iso) = 1535f3965e3456471756195a8bde5d84ad39967b7dd2db321096740f026104fd SHA256 (FreeBSD-10.1-RC4-amd64-uefi-disc1.iso.xz) = 457bc2502fdb8e7ce7fc95bf7a9a7e6134796520c2f3fb56d446d8f77690f249 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-dvd1.iso) = 750ceb0951a43a190863ae7f37915e10f30acb72e28648a23c63debf50e5f5dd SHA256 (FreeBSD-10.1-RC4-amd64-uefi-dvd1.iso.xz) = 84ecbd79d5d1047bc6153ba1e78c0c357c8318ad0d59d12167a2ee9068fc6dc8 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-memstick.img) = 214e83c9038ea92c75f571987879cbad4b63e57efc8c6c6b3920b8f63a364c10 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-memstick.img.xz) = eaf18598b2684a64372953e18d4a701aeff2c96025bbb0f2d13314d468cecbb1 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-mini-memstick.img) = 38964e02056bbf7cbb635ebfb5b2b827376de067e841f63f4bba218176b694d1 SHA256 (FreeBSD-10.1-RC4-amd64-uefi-mini-memstick.img.xz) = eae505b7de0954c6d88517ed1708a0ba772a9eb0e970702d692f4e9d562d2a53 MD5 (FreeBSD-10.1-RC4-amd64-bootonly.iso) = f747b7213d43402cb5789c2b18cdd33d MD5 (FreeBSD-10.1-RC4-amd64-bootonly.iso.xz) = 964452a1360e28b7fa8672a7b595a6c0 MD5 (FreeBSD-10.1-RC4-amd64-disc1.iso) = 0f877850ff9e3bf8df2ed3c31749ddaf MD5 (FreeBSD-10.1-RC4-amd64-disc1.iso.xz) = 3035f8005b5518b24e7f1c3cbb83e458 MD5 (FreeBSD-10.1-RC4-amd64-dvd1.iso) = 18d58ef84aaf52124c368e5145742a6a MD5 (FreeBSD-10.1-RC4-amd64-dvd1.iso.xz) = d479c16aabc0b6f91ac89cacbffdf3c3 MD5 (FreeBSD-10.1-RC4-amd64-memstick.img) = 00e467dfba91b88d87f2c7c34eb4894c MD5 (FreeBSD-10.1-RC4-amd64-memstick.img.xz) = 679efb2e94600033a76a07407cc0b574 MD5 (FreeBSD-10.1-RC4-amd64-mini-memstick.img) = 60f729913b9e0a043a7973e933ebd283 MD5 (FreeBSD-10.1-RC4-amd64-mini-memstick.img.xz) = 9b06d17588a0cca0a9f0cf28f16621b2 MD5 (FreeBSD-10.1-RC4-amd64-uefi-bootonly.iso) = 4e9663341487f21d0d5a2743f775b790 MD5 (FreeBSD-10.1-RC4-amd64-uefi-bootonly.iso.xz) = f031f84784b494646d322748c39711a9 MD5 (FreeBSD-10.1-RC4-amd64-uefi-disc1.iso) = 1417d3016c62386985f317db07e72b6a MD5 (FreeBSD-10.1-RC4-amd64-uefi-disc1.iso.xz) = bf3e6fcab06d68933b65bcd45b165557 MD5 (FreeBSD-10.1-RC4-amd64-uefi-dvd1.iso) = 8da2c87004dbfd5fe854a6a9ffd664ec MD5 (FreeBSD-10.1-RC4-amd64-uefi-dvd1.iso.xz) = 8a9a2784566fd1dffab0f01bf35f714b MD5 (FreeBSD-10.1-RC4-amd64-uefi-memstick.img) = ccd291582064965abd90b40e2cd74d0e MD5 (FreeBSD-10.1-RC4-amd64-uefi-memstick.img.xz) = 4b15094660ed36159c2d0bb9b62b1dc2 MD5 (FreeBSD-10.1-RC4-amd64-uefi-mini-memstick.img) = 6a645c91435d7c8cc4fecd184e4fe734 MD5 (FreeBSD-10.1-RC4-amd64-uefi-mini-memstick.img.xz) = 46a71679ab6052e4de03cdfe12cd7d8a o 10.1-RC4 i386 GENERIC: SHA256 (FreeBSD-10.1-RC4-i386-bootonly.iso) = db36ee81ece495ab829e637b89d9f25283c9ff012a4784d9c4a7056bdfea2def SHA256 (FreeBSD-10.1-RC4-i386-bootonly.iso.xz) = 48cecfa2a41164da52129c13ee0348d0e6425b3557ec6b83b64d2bce7e75765d SHA256 (FreeBSD-10.1-RC4-i386-disc1.iso) = e8bd449ab79712b805cae4fd6319c4aab227506fb78c548ef8d7832128c7abd6 SHA256 (FreeBSD-10.1-RC4-i386-disc1.iso.xz) = 9f1a0fe1574f88e38c00a8c8841f17451c77a29652eab3a527d82c8f39b51afb SHA256 (FreeBSD-10.1-RC4-i386-dvd1.iso) = baf886163505be1429dc7567242ce5a37687fa6f8aca4ac36db635173265dede SHA256 (FreeBSD-10.1-RC4-i386-dvd1.iso.xz) = f4fa982419e0b55d19e7bd539998d608cb4c9ef3904e1c5731a1f41c3b258b6f SHA256 (FreeBSD-10.1-RC4-i386-memstick.img) = 8b978f535746604ff9938a9332fb2199268d9a59756de48b8b9fa143dfff4a21 SHA256 (FreeBSD-10.1-RC4-i386-memstick.img.xz) = 4d288659f353b9abe158951662324e19f8331c1f8f5762a6fe654ce1503ce293 SHA256 (FreeBSD-10.1-RC4-i386-mini-memstick.img) = 4335504f0e7a5a2689ad2b913e1e22938cf716a2db80806e61318af5fd5f56e0 SHA256 (FreeBSD-10.1-RC4-i386-mini-memstick.img.xz) = 5629a292977af3d4cf771f7c23092ff952795d6ae01cf6e2f25bd422180f04e3 MD5 (FreeBSD-10.1-RC4-i386-bootonly.iso) = d497a9d7459e73f06556f739433e263f MD5 (FreeBSD-10.1-RC4-i386-bootonly.iso.xz) = 4383faf9c06fd86460fda44bd0a3d620 MD5 (FreeBSD-10.1-RC4-i386-disc1.iso) = 6e36b7440803a085862a2fed03458ddc MD5 (FreeBSD-10.1-RC4-i386-disc1.iso.xz) = eb8dbcd3a320d6c58ebf59b5e510b995 MD5 (FreeBSD-10.1-RC4-i386-dvd1.iso) = 442c9290ed7fcdf82ad7ce11d1bf3ff1 MD5 (FreeBSD-10.1-RC4-i386-dvd1.iso.xz) = ee690610fc8715b090bff79ab73b87d8 MD5 (FreeBSD-10.1-RC4-i386-memstick.img) = ea5aa0beedaa27e005af1f32c9215839 MD5 (FreeBSD-10.1-RC4-i386-memstick.img.xz) = a46c04c3f3b576c838c799e47777daae MD5 (FreeBSD-10.1-RC4-i386-mini-memstick.img) = ee3950ecaf57959b0ecd8f08bcc581ad MD5 (FreeBSD-10.1-RC4-i386-mini-memstick.img.xz) = b48f46490afcc9e8aee7e8d93ab4c399 o 10.1-RC4 ia64 GENERIC: SHA256 (FreeBSD-10.1-RC4-ia64-bootonly.iso) = 5f1d624ad6b21890a8e8798303b92577ff3b70c543a8f680879fdbcdff9ab659 SHA256 (FreeBSD-10.1-RC4-ia64-bootonly.iso.xz) = 7ad5db19298acc38c8280b446a50b000b24e17fe20250e3ff55e90a1ddb7d7c6 SHA256 (FreeBSD-10.1-RC4-ia64-disc1.iso) = 7cd159f6a3a7ab1145abd6f5e935dd541b76b016b1c775cd1131ae6049530f73 SHA256 (FreeBSD-10.1-RC4-ia64-disc1.iso.xz) = 0164c82c3923057a3131c253242a79903879c34118117fb526d291d29033ec43 SHA256 (FreeBSD-10.1-RC4-ia64-memstick.img) = 027a3a7c85e6530121d05a4fd200bf37a16d8b60d6e06c05f415334c51ce1e55 SHA256 (FreeBSD-10.1-RC4-ia64-memstick.img.xz) = 6a67b0b21a5e60fd48a84b821565380ee1eaee3273b6646febff4d1ffaea57b9 SHA256 (FreeBSD-10.1-RC4-ia64-mini-memstick.img) = 45f52a9c7472edf73dd61518730d878a8759a5296a8be65b24b4f2613f051eb3 SHA256 (FreeBSD-10.1-RC4-ia64-mini-memstick.img.xz) = 5d038d060a96fe01040daa59a532a9ad5b8efa8dba3943140c67f255edad29bb MD5 (FreeBSD-10.1-RC4-ia64-bootonly.iso) = 860420cfcd521dbe96ce778d8024814b MD5 (FreeBSD-10.1-RC4-ia64-bootonly.iso.xz) = c0614ff37d6d0e6e4a9c292b39fbab7f MD5 (FreeBSD-10.1-RC4-ia64-disc1.iso) = 48504ca67129090d0e2dddecf53bfbc2 MD5 (FreeBSD-10.1-RC4-ia64-disc1.iso.xz) = 1a050a23f89bb34b395fc25ab035b3fe MD5 (FreeBSD-10.1-RC4-ia64-memstick.img) = 884570678ef94b720d32e15919723000 MD5 (FreeBSD-10.1-RC4-ia64-memstick.img.xz) = f17c8fd79fbd1bc2257b345078f53166 MD5 (FreeBSD-10.1-RC4-ia64-mini-memstick.img) = be21ff04b891c973965e53dd3026edd7 MD5 (FreeBSD-10.1-RC4-ia64-mini-memstick.img.xz) = 46439b2d3647763944fc877723899ca9 o 10.1-RC4 powerpc GENERIC: SHA256 (FreeBSD-10.1-RC4-powerpc-bootonly.iso) = b1293f6cee612c70b5260f514c1f99c5aa60da7020235c1d829f10ec255bf55b SHA256 (FreeBSD-10.1-RC4-powerpc-bootonly.iso.xz) = 440bec7bdddea7f11374db20d59f28b02ee2ec8b1678c2ab73ff5f2671c00c2d SHA256 (FreeBSD-10.1-RC4-powerpc-disc1.iso) = 81b82df0f9c0be25d18b94c1f758593b951ebb1b3af6a7ef9265fe88d3bb4ba0 SHA256 (FreeBSD-10.1-RC4-powerpc-disc1.iso.xz) = e3cb7c8e421fdebf8ce6ac46cbee2c58bfff5a780ad96c450e42d5f7069c2282 SHA256 (FreeBSD-10.1-RC4-powerpc-memstick.img) = 4550cc2a4eb53d42b3c81ec59f8f6b130c3859cf63c28a5972cf77febe2ebb09 SHA256 (FreeBSD-10.1-RC4-powerpc-memstick.img.xz) = a50316156fdc9b08d510e6aa133f2d3567f64ffe7b48cc9de9c65b8823ab9fcd SHA256 (FreeBSD-10.1-RC4-powerpc-mini-memstick.img) = ac3fab418942323defd66b6ab11b13af9fc7a720452af0d62983ab40c4353041 SHA256 (FreeBSD-10.1-RC4-powerpc-mini-memstick.img.xz) = 5707508d2f2dd64a0105e90df75eceb247c66f7f382628aded28fa0c93545115 MD5 (FreeBSD-10.1-RC4-powerpc-bootonly.iso) = b62291ef73885a08f1f102e7447c019f MD5 (FreeBSD-10.1-RC4-powerpc-bootonly.iso.xz) = 9b2152b88c43ac420107fb2e843ce196 MD5 (FreeBSD-10.1-RC4-powerpc-disc1.iso) = 99fbf5c45df90a75522ba0e4f41f3b7f MD5 (FreeBSD-10.1-RC4-powerpc-disc1.iso.xz) = 907b889156c4732e8967d4b989358ee1 MD5 (FreeBSD-10.1-RC4-powerpc-memstick.img) = cb3e5bd880ac1b1a14dc0fc96a943140 MD5 (FreeBSD-10.1-RC4-powerpc-memstick.img.xz) = 7c156551ac0198d1d892791fef7dcf50 MD5 (FreeBSD-10.1-RC4-powerpc-mini-memstick.img) = 5efff51e7355f5fbd8ebd9f9f0d1aec4 MD5 (FreeBSD-10.1-RC4-powerpc-mini-memstick.img.xz) = c2d88fad8f0b4646ae4aff45f4c04512 o 10.1-RC4 powerpc64 GENERIC64: SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-bootonly.iso) = a180a62f267ceb755cc65c9e2cafb9924f52e1c1da75c1c5435c9c041e2330cd SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-bootonly.iso.xz) = 5a39eb3311c73642838fe313aab1cada7d28fafb4075f6793dd1238c71b97745 SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-disc1.iso) = 91d5de128e217ec263d59f3ab127b46f5d9313d9b30eb0f3d3673e6630058716 SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-disc1.iso.xz) = f2a6914a6a1c8499f361b2fda3af9e1877320bfe3b3f2be605ad056855345723 SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-memstick.img) = b2ca746669a6e60c666628ddc0a5bf45dfd28d0d6be714af892fe0c2f86323c3 SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-memstick.img.xz) = 7a7f30742032cafd543fb49aae31e23f4f76e6023406fe1066b7d297bbc0bba3 SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-mini-memstick.img) = 8b8fbc76f15bc32715285287102edbb905c9e374a5788e62570fb529546f0c01 SHA256 (FreeBSD-10.1-RC4-powerpc-powerpc64-mini-memstick.img.xz) = f95cce09be5d89b39ba529312106751c518e725b9a7ee82affcf1385dea30dca MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-bootonly.iso) = 22364422f409c5afb098c1c7656d4d5d MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-bootonly.iso.xz) = ec13703893752e4414b103f2bfe1a5e6 MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-disc1.iso) = 0faf10728429cdd0d094c05748aaadc2 MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-disc1.iso.xz) = f5777c51374013064f31af5a47e5e069 MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-memstick.img) = 6c208d9e334dd92a868d8f822efbde28 MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-memstick.img.xz) = 3edfeb2d4dbe4c84ab9a9d346ccdf1c5 MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-mini-memstick.img) = cb733bbf654d0b517a3d9391a95a7981 MD5 (FreeBSD-10.1-RC4-powerpc-powerpc64-mini-memstick.img.xz) = 808cb060cd86ca4bc86bd4560d07380e o 10.1-RC4 sparc64 GENERIC: SHA256 (FreeBSD-10.1-RC4-sparc64-bootonly.iso) = adcc7ffc20250b8564f10adebe22b3734641d10337fd415bbc8adcf81252bd82 SHA256 (FreeBSD-10.1-RC4-sparc64-bootonly.iso.xz) = a387927d036d13b57d0fb691c7bcc21899f4dfa675a09d5e757c7d1ee8e857cc SHA256 (FreeBSD-10.1-RC4-sparc64-disc1.iso) = ea7160147e298ba05d3eea6a226908f9dbe3cabe9895db6ee058e250973c9e7d SHA256 (FreeBSD-10.1-RC4-sparc64-disc1.iso.xz) = 3f32cf42a65d48310650d1b07913732b2b69acc3078db756a6e19b464ca6b741 MD5 (FreeBSD-10.1-RC4-sparc64-bootonly.iso) = 1626f4d8e8be3001c6c01bad9d323218 MD5 (FreeBSD-10.1-RC4-sparc64-bootonly.iso.xz) = 5f8cfaf14fe43b7e766ac93a3502e464 MD5 (FreeBSD-10.1-RC4-sparc64-disc1.iso) = 0b2430f1f4ba8a2f2a29bb983361fced MD5 (FreeBSD-10.1-RC4-sparc64-disc1.iso.xz) = 895ffa215b4dabddb88467df554906da o 10.1-RC4 armv6 BEAGLEBONE: SHA256 (FreeBSD-10.1-RC4-arm-armv6-BEAGLEBONE.img.bz2) = ada68a6436cb6a8eb81b651b9e468d956e67fa46fb2679d57f82bd122e0ccda9 MD5 (FreeBSD-10.1-RC4-arm-armv6-BEAGLEBONE.img.bz2) = 33640349f340580c590c90f9cda1ba16 o 10.1-RC4 armv6 RPI-B: SHA256 (FreeBSD-10.1-RC4-arm-armv6-RPI-B.img.bz2) = f9d12a5a801bbe7f072236b55eb1b5b7a93decd02dc00c5c90276c8ae87e4a7e MD5 (FreeBSD-10.1-RC4-arm-armv6-RPI-B.img.bz2) = 0fa25e8b81aa19eeca345c28ebaa202e o 10.1-RC4 armv6 PANDABOARD: SHA256 (FreeBSD-10.1-RC4-arm-armv6-PANDABOARD.img.bz2) = df83d664fe36d83e46e623d65dcc2287dddf8184802a4c78f173356dfe059c72 MD5 (FreeBSD-10.1-RC4-arm-armv6-PANDABOARD.img.bz2) = 0e9bdbe7e42d17e458fc6a4283dc0ed8 o 10.1-RC4 armv6 ZEDBOARD: SHA256 (FreeBSD-10.1-RC4-arm-armv6-ZEDBOARD.img.bz2) = a786fe4d46d0079a302582fb4693faef335ef1eadb0a7f22bf9ecac3abb4fdfc MD5 (FreeBSD-10.1-RC4-arm-armv6-ZEDBOARD.img.bz2) = 67f0008dab0f1751be17a9b9703d1269 == VM IMAGE CHECKSUMS == o 10.1-RC4 amd64: SHA256 (FreeBSD-10.1-RC4-amd64.qcow2.xz) = 8ee0454e452db0e3ae30352d4912edae9e585a5970b89617bb3e8ffbe2c3df83 SHA256 (FreeBSD-10.1-RC4-amd64.raw.xz) = 382c18f5b13eb687af9904565d3dbe440ba7813609210e4cec52e999931743f0 SHA256 (FreeBSD-10.1-RC4-amd64.vhd.xz) = 6fd90a299536c8907dba9bafd79f059b679010e4cd2e4d88edc16b3403175bae SHA256 (FreeBSD-10.1-RC4-amd64.vmdk.xz) = 52deabc8fe9b3f88446f282ada1b7c460dff04ed3ff118d270f4e2605089c5e1 MD5 (FreeBSD-10.1-RC4-amd64.qcow2.xz) = 8de21c62863f9ec04e5be4477d0062a7 MD5 (FreeBSD-10.1-RC4-amd64.raw.xz) = c0c0f5d15087d5cedefdd15534b41a9c MD5 (FreeBSD-10.1-RC4-amd64.vhd.xz) = 80cc474fd685c61b8d9e8d8cc0989a71 MD5 (FreeBSD-10.1-RC4-amd64.vmdk.xz) = fa603ec28de847260f465107eb66d654 o 10.1-RC4 i386: SHA256 (FreeBSD-10.1-RC4-i386.qcow2.xz) = b866b95d58cc49586a104d5c53f9b4e2af60aa8fe7a526bbd9ef6b6bd3552fd9 SHA256 (FreeBSD-10.1-RC4-i386.raw.xz) = cb023dc2422e7560cc7ca8b106902875acda25a01941d9647fd7bb3cf0f412ba SHA256 (FreeBSD-10.1-RC4-i386.vhd.xz) = 6bd10b38e0b88cbed916d8c64b2568ae8d3b2f398e9811aae66a97136f21150f SHA256 (FreeBSD-10.1-RC4-i386.vmdk.xz) = decac257700ccf6c5bb197ea59a86c9d017358a0f34085ac1d0156b9a84e76bb MD5 (FreeBSD-10.1-RC4-i386.qcow2.xz) = 95e7dc6429fac2d6ab14996266f75c28 MD5 (FreeBSD-10.1-RC4-i386.raw.xz) = a28a6a328e0e9b04cc59c7d372c40a8d MD5 (FreeBSD-10.1-RC4-i386.vhd.xz) = b2145d20d5c32fb758d47113f8f1e90a MD5 (FreeBSD-10.1-RC4-i386.vmdk.xz) = c3d8047313c2ddf22a198f0f3995cf34 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 iQIcBAEBCAAGBQJUVolwAAoJEAMUWKVHj+KT6zoQAJdvSDu5/L5R+tVYKn9hNX+Z V3iNQ8fiPj+Yz8/GEBYU69vRWNf9XZRiBtu5GZouZodCL+4sm+T6NHw2mhDQnwnB oicfPLkw5Sy2YzsVZurTsEtBUo1CpL/s863M9XhtvbAfNMqUDigg053CKIn3KM47 SsvXMFW0JY0YA9YAnNoXhoVIvuN4G6mBVVd9FdY/fRXsKnKivAlMCX9Z1t6TALxV mEYGK6kuVGwYYvnNPl736wiVVC1jhcMddiqRrR7sf2jzaKPsCfmAwb9tPFfVljWS 6JNFyKPz4y7swWw1qhJQLFEW/9O5oZaE6ftLxsDMDYFomN/vCN/0jbch6RgDxD8G dkCyhN36nxYuAFjbkzeUQyt3xRDb/gYCGmDoKIFDBxVzUOyaDv3exESfE+uVKTy/ kaiM82V5wmjWt5EnRRouQiqnQ4yvcIYiwxdQIgtia6LDe9TDQMspmPTVFhMuMy1T OawwVucUFbqIsWY3eDG1SDpq1fhen4cm0SIn9gIjrp0t9Vw5DVVDLNMsUutMM2tM OSmmorbJmr0DAg8IRSdALUqzUB5aNVBJf+e+8tFqQkEbT1OQ5zJOZVXaJjSBob9A 8/WlG1/5BzfHVLft7mvXRTROFMtdiCVIda2YiastzFInml/gIQyxU7O9fdAe4t3w 9C5jfa/K/9JQvdTYTutU =rmUT -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Nov 2 20:02:23 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 17B551C2 for ; Sun, 2 Nov 2014 20:02:23 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 0036AD4C for ; Sun, 2 Nov 2014 20:02:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id sA2K2MOL066836 for ; Sun, 2 Nov 2014 20:02:22 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id sA2K2MNU066835 for stable@FreeBSD.org; Sun, 2 Nov 2014 20:02:22 GMT (envelope-from bdrewery) Received: (qmail 5280 invoked from network); 2 Nov 2014 14:02:20 -0600 Received: from unknown (HELO blah) (freebsd@shatow.net@129.253.54.225) by sweb.xzibition.com with ESMTPA; 2 Nov 2014 14:02:20 -0600 Message-ID: <54568DA2.6030309@FreeBSD.org> Date: Sun, 02 Nov 2014 14:01:38 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-ports@FreeBSD.org Subject: SSP now default for ports/packages, ssp/new_xorg repository EOL Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 02 Nov 2014 20:08:04 +0000 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, 02 Nov 2014 20:02:23 -0000 Ports and Package users, Ports now have SSP enabled by default. The package repository will now build SSP by default as well. SSP is "Stack Smashing Protection" and can be read about at https://en.wikipedia.org/wiki/Buffer_overflow_protection. This only applies to the head (/latest) packages, not the Quarterly branch packages. This applies to the ports checkout that portsnap uses. WITHOUT_SSP can be defined in make.conf to not use this feature. SSP will be used to build ports (with -fstack-protector) on all amd64 releases and i386 releases which are 10.0 or newer. The "ssp" repository and "new_xorg" repositories will no longer be updated after 11/15 as they are no longer needed as both are default for ports now. Please update your repository configurations to now only track the /latest repository. This is the default from /etc/pkg/FreeBSD.conf. Remove any overrides from /usr/local/etc/pkg/repos/ for the "ssp" or "new_xorg" repositories. Regards, Bryan Drewery on behalf of portmgr From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 00:37:27 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 C2702196; Mon, 3 Nov 2014 00:37:27 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 873C1AD5; Mon, 3 Nov 2014 00:37:27 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so4263248iec.24 for ; Sun, 02 Nov 2014 16:37:27 -0800 (PST) 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=o3//0X8+xhUbsOiLWp+W/cD8IHtgl1/41rNn26dkcBU=; b=M3Zej1iJHGIpxUDTMqobPaGYvm1/Q66O94zpoCTmRgVy63Wy/7XIWEFnXA7cMDrlZs lCIyYgc+r50MAkfCcWa95DvamTz4offyJ3qApk5z9azKPRfq3V5Ezz/Tru07js8M82M1 WMn0hwvh1Hicqv10wqVaqAuLaIt4o4UoLJM31wBZRtXSomF8UoSr21fXHV4psrXm5Z9p pfp8F1MGmx1pWpVVWYSW14CCy8BU96uZK67QHowULVjOSiHx6HWEsVhN294i5x5VV1s3 E7EoAKktT1KzezwkJEHq7jiLw8gumWYUP/g4vU8C4k4WBbLzMROB3pn/8crS1sWKGDMp Uh7Q== MIME-Version: 1.0 X-Received: by 10.50.79.166 with SMTP id k6mr13085813igx.0.1414975046904; Sun, 02 Nov 2014 16:37:26 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.11.152 with HTTP; Sun, 2 Nov 2014 16:37:26 -0800 (PST) In-Reply-To: <20141102194344.GA21862@hub.FreeBSD.org> References: <20141102194344.GA21862@hub.FreeBSD.org> Date: Sun, 2 Nov 2014 16:37:26 -0800 X-Google-Sender-Auth: 7eBKcDiySeT3QLkajqA3qfdaQgg Message-ID: Subject: Re: FreeBSD 10.1-RC4 Now Available From: Kevin Oberman To: Glen Barber Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Release Engineering Team , 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: Mon, 03 Nov 2014 00:37:27 -0000 On Sun, Nov 2, 2014 at 11:43 AM, Glen Barber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > The fourth 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. > > This is anticipated to be the final RC build of the 10.1-RELEASE cycle. > I hit a problem right out at the start: # freebsd-update upgrade -r 10.1-RC4 Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.0-RC3 from update2.freebsd.org... done. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic src/src world/base world/doc world/games The following components of FreeBSD do not seem to be installed: world/lib32 Does this look reasonable (y/n)? n But I do have lib32 installed and have had since the initial installation.No prior upgrade failed. I have no time to look at how freebsd-update tests for components, but something went haywire. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 06:54:55 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 6F8F2317; Mon, 3 Nov 2014 06:54:55 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 CEF7389; Mon, 3 Nov 2014 06:54:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA36soKU081518; Mon, 3 Nov 2014 17:54:50 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 3 Nov 2014 17:54:50 +1100 (EST) From: Ian Smith To: Glen Barber Subject: Re: FreeBSD 10.1-RC4 Now Available In-Reply-To: <20141102194344.GA21862@hub.FreeBSD.org> Message-ID: <20141103174009.C52402@sola.nimnet.asn.au> References: <20141102194344.GA21862@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 03 Nov 2014 06:54:55 -0000 On Sun, 2 Nov 2014 19:43:44 +0000, Glen Barber wrote: [dropping re@] > 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. Where is this issue being discussed? I just browsed October -current@ archives, seeing no mention, and -sysinstall@ (dead since August, last real discussion in June, giving the last - terrifying! - list of PRs ..) I'm soon to find out if this issue affects 9.3 also, on a memstick made from the DVD. I reported similar problems re 10.0-R (to questions@ cc Devin) and what I thought _might_ be a fix, but heard nothing back. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 07:13:41 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 4DECA677; Mon, 3 Nov 2014 07:13:41 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 BB532252; Mon, 3 Nov 2014 07:13:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA37DaOc082302; Mon, 3 Nov 2014 18:13:36 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 3 Nov 2014 18:13:36 +1100 (EST) From: Ian Smith To: Warren Block Subject: Re: Small motd nit in 10.1 In-Reply-To: Message-ID: <20141103181034.K52402@sola.nimnet.asn.au> References: <8C81A636-D2B5-4EFB-9EA3-58E88E16CA94@spam.lifeforms.nl> <93E9657A-737E-4705-A0E5-01F9E9110261@gromit.dlib.vt.edu> <201410301554.03504.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, Walter Hop , John Baldwin 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, 03 Nov 2014 07:13:41 -0000 On Sun, 2 Nov 2014 12:23:31 -0700, Warren Block wrote: > On Thu, 30 Oct 2014, Warren Block wrote: > > > On Thu, 30 Oct 2014, Warren Block wrote: > > > > > There is room on that line to show both: > > > > > > Show details of the FreeBSD installation: uname -a ; freebsd-version > > > > > > Or some combination like that. > > > > Actually, I think the output from 'freebsd-version ; uname -a' is less > > ambiguous. > > Since nobody has complained about this, I'll update head now and plan to MFC > it. Hopefully it will be in time for 10.1-RELEASE. It should be obvious, I guess, that this doesn't apply to 9.x (tested :) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 07:42:07 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 2A2F0DC9; Mon, 3 Nov 2014 07:42:07 +0000 (UTC) Date: Mon, 3 Nov 2014 07:42:04 +0000 From: Glen Barber To: Ian Smith Subject: Re: FreeBSD 10.1-RC4 Now Available Message-ID: <20141103074204.GF4390@hub.FreeBSD.org> References: <20141102194344.GA21862@hub.FreeBSD.org> <20141103174009.C52402@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f61P+fpdnY2FZS1u" Content-Disposition: inline In-Reply-To: <20141103174009.C52402@sola.nimnet.asn.au> 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-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: Mon, 03 Nov 2014 07:42:07 -0000 --f61P+fpdnY2FZS1u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2014 at 05:54:50PM +1100, Ian Smith wrote: > On Sun, 2 Nov 2014 19:43:44 +0000, Glen Barber wrote: >=20 > > 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. >=20 > Where is this issue being discussed? I just browsed October -current@=20 > archives, seeing no mention, and -sysinstall@ (dead since August, last=20 > real discussion in June, giving the last - terrifying! - list of PRs ..) >=20 > I'm soon to find out if this issue affects 9.3 also, on a memstick made= =20 > from the DVD. I reported similar problems re 10.0-R (to questions@ cc=20 > Devin) and what I thought _might_ be a fix, but heard nothing back. >=20 It is not (currently actively) being discussed, but there has been prior discussion about the issues with bsdconfig(8) and pkg(8) integration in the past off-list. The issues affecting 10.1-RELEASE were not present in 9.3-RELEASE with the 9.3-RELEASE tagged ports tree. Glen --f61P+fpdnY2FZS1u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUVzHMAAoJEAMUWKVHj+KTW0kP/2L0m65DgJb6yd8knrAt/1Wx wpuHhbDmjmb+ofNTfoF/BaTkJVnnb0d0HnCHKHR8pzMot36+F1D/wEQmt3nwf9LI Eul4KEdmgDozyfO2Kf8fgxY87fhSJOTv1M2DErwUNAnmPswOvVQeD9g6ofMwFNHW 7ZWoxFOTDZHgU2dVKAmHPzxlzE5JCS+vSw9nbmVtRi+pbGeTswWg27BqUy6VsOgt MzNt0VymMSxNhamARZLlcFpG+beh23SwwxIQz+xY74F/KMFwMZHYGdElJhBZp+6I uieTt8MQuMHpMrURKXsheB/QMkdePjnYbSe3RIZ0ikkXkcUvNUPSxSYgWVjOrSxk 81LmU/ifugY8LpyLJf0MRttyTtwiuWecvQG/Xi9zkowTLyZa9v9KSB/fZCFu5ZUt nSoPckDJ39fQHUvLrmB60SK9n81zvUX9wrZefYpSKEltWWb9e/nLZJ56tTmyhs9S LxcgvpcYaBuDyWUZPmGi8O++2KjTiEJcfuGXtDwE86hvQhG/auZRj1ZsmuuvHMmQ GVtTBj8LjLFsR+MnBNzwmJTwcdX1lpDH0nI938vXJrJp4bdknt0szR3XWC4WLlIu QEilHFcE1/xZNc5gDjPCWIoqiibJDKM+SsL5ogbOpXdjv0nHBvElMAOaum7x4Gq0 Ik5DWQ1tiQArexwDh1qR =zGMY -----END PGP SIGNATURE----- --f61P+fpdnY2FZS1u-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 07:55:31 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 D2324338; Mon, 3 Nov 2014 07:55:31 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 4DE9487B; Mon, 3 Nov 2014 07:55:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA37tRSw083598; Mon, 3 Nov 2014 18:55:27 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 3 Nov 2014 18:55:27 +1100 (EST) From: Ian Smith To: Glen Barber Subject: Re: FreeBSD 10.1-RC4 Now Available In-Reply-To: <20141103074204.GF4390@hub.FreeBSD.org> Message-ID: <20141103184410.V52402@sola.nimnet.asn.au> References: <20141102194344.GA21862@hub.FreeBSD.org> <20141103174009.C52402@sola.nimnet.asn.au> <20141103074204.GF4390@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 03 Nov 2014 07:55:31 -0000 On Mon, 3 Nov 2014 07:42:04 +0000, Glen Barber wrote: > On Mon, Nov 03, 2014 at 05:54:50PM +1100, Ian Smith wrote: > > On Sun, 2 Nov 2014 19:43:44 +0000, Glen Barber wrote: > > > > > 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. > > > > Where is this issue being discussed? I just browsed October -current@ > > archives, seeing no mention, and -sysinstall@ (dead since August, last > > real discussion in June, giving the last - terrifying! - list of PRs ..) > > > > I'm soon to find out if this issue affects 9.3 also, on a memstick made > > from the DVD. I reported similar problems re 10.0-R (to questions@ cc > > Devin) and what I thought _might_ be a fix, but heard nothing back. > > > > It is not (currently actively) being discussed, but there has been prior > discussion about the issues with bsdconfig(8) and pkg(8) integration in > the past off-list. > > The issues affecting 10.1-RELEASE were not present in 9.3-RELEASE with > the 9.3-RELEASE tagged ports tree. Ok, thanks. I'll go ahead with my 9.3 testing, involving a small patch to bsdconfig while generating the memstick image; in outline, bsdconfig only looks for local packages if the install media type is _detected_ as a CD, where that needs to apply to a) memsticks and b) other media types like a local disk partition if they include a package set as on the DVD. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 08:23: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 C3501D5F for ; Mon, 3 Nov 2014 08:23:33 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ADE48B97 for ; Mon, 3 Nov 2014 08:23:33 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A0599AE2 for ; Mon, 3 Nov 2014 08:23:33 +0000 (UTC) Date: Mon, 3 Nov 2014 08:23:32 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-stable@freebsd.org Message-ID: <973625445.2.1415003013098.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <586694318.1.1414995401470.JavaMail.jenkins@jenkins-9.freebsd.org> References: <586694318.1.1414995401470.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #305 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image 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, 03 Nov 2014 08:23:33 -0000 See From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 08:32:16 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 54532297; Mon, 3 Nov 2014 08:32:16 +0000 (UTC) Date: Mon, 3 Nov 2014 08:32:14 +0000 From: Glen Barber To: Kevin Oberman Subject: Re: FreeBSD 10.1-RC4 Now Available Message-ID: <20141103083214.GG4390@hub.FreeBSD.org> References: <20141102194344.GA21862@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/i8j2F0k9BYX4qLc" Content-Disposition: inline In-Reply-To: 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 , 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: Mon, 03 Nov 2014 08:32:16 -0000 --/i8j2F0k9BYX4qLc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 02, 2014 at 04:37:26PM -0800, Kevin Oberman wrote: > On Sun, Nov 2, 2014 at 11:43 AM, Glen Barber wrote: > I hit a problem right out at the start: > # freebsd-update upgrade -r 10.1-RC4 > Looking up update.FreeBSD.org mirrors... 5 mirrors found. > Fetching metadata signature for 10.0-RC3 from update2.freebsd.org... > done. > Fetching metadata index... done. > Fetching 1 metadata patches. done. > Applying metadata patches... done. > Fetching 1 metadata files... done. > Inspecting system... done. >=20 > The following components of FreeBSD seem to be installed: > kernel/generic src/src world/base world/doc world/games >=20 > The following components of FreeBSD do not seem to be installed: > world/lib32 >=20 > Does this look reasonable (y/n)? n >=20 > But I do have lib32 installed and have had since the initial > installation.No prior upgrade failed. I have no time to look at how > freebsd-update tests for components, but something went haywire. I am unable to reproduce this, and prior to sending the 10.1-RC4 announcement email, did test the upgrade path from 10.1-RC2 and 10.1-RC3. I've just double-checked on a clean install of 10.1-RC3, and only see (as expected on this install) src/src component not installed locally. Glen --/i8j2F0k9BYX4qLc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUVz2OAAoJEAMUWKVHj+KT3MQP/RbDlzBe2+LXB8apZc01h0Uh Hi1Ax6lo1wbt266TJwy43I/udUbXTFMaKyjoUCX8ohD2kzPmGotXgPpAVTQyF8mS PKsvFD5DzGmWCKfuDrduvFxUylWzEOWBpi5E2qRdEjZhF17N89sVo9nLGFfuecaP Lwq/AbwPQWtNuyjKJf9MpLQeQ+eO95Fhrd51YnKknmusz1q02H6uP2wNcuZ11EWj x97mN3ty6l0Bg4gqBtyGp5WO4tA4dHy4yuSWbcPACXRHa3ue3HG5wbMvWx6X6BLc 5ml6uguHYFqKWtBaugWCvQXRvTlZlJx6Hs1vVRC52qY4I9ofk5/y4cUftcPFNKja m1a+15YX/Tv4J5yDjPhoMzrjSxc/OJSo5+HVusz3kyp2zAo6cfwqxfdTYUipaP0A xRh4X9v95uzZL935kZtYwUkhiF1C3DPlAvtO1/wVVqvQ9XbCoUFYE7nO+Bv1kBSA f6UjD3QlQNP4/hkppMeXaNcM1oisZR0P3olVXKAE16iz63qEJEw4xmWXXH2xxwwn TQn+A+bD4VxpVLUGvlXHzprv/NZitMTr63xgPCvDhrabb/PyadJr+e46KP8y1V0r r9L9wk1z9A5uMfLzt95AXePWG13SY7/QSPKpFT7VgulIDAIzYVU7DP6qatbmnw6F E3s/5kqwvcxcUOBc8tW/ =b3lW -----END PGP SIGNATURE----- --/i8j2F0k9BYX4qLc-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 11:27:03 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 07FD7AD4 for ; Mon, 3 Nov 2014 11:27:03 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 9858FB6 for ; Mon, 3 Nov 2014 11:27:02 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so12176069wgg.5 for ; Mon, 03 Nov 2014 03:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type; bh=APJD/uYm67VkXVNQu6VuqkOGscEUtKhILwdBs/VVgXQ=; b=QXavosqSyxk83zEpiqJI4gpDcpFJdv9hbm9h3TA+xSTiCTnrWUcCReT7DhtspHeC6/ c/hmbDFK0t9jC7NPQhUY0tyMrBonAOnCCfizbeehgtWWIv9rSU/oSjEkNm8GvkbpYJ00 SizDLv70Cqhk08jQMdjWF9GLUBzfv2Ol+lsewvfjF35cDyy8sz/m5Ca7M9zGo+pEhdX/ 36hB50S6ZpAu4VuMfgAVIa5+3Bp3hNwcwptwNjzMO/m/DXrDN15PxvcoFuIGTR484Mnx pcEpkRVzPsjvTNkAA2MMZ3RGKAufn0YK4fgF386WsasmCmpxBeC3fxfdBRdFn8U6nOkS zIXw== X-Received: by 10.180.73.244 with SMTP id o20mr15838998wiv.12.1415014020831; Mon, 03 Nov 2014 03:27:00 -0800 (PST) Received: from localhost (89-73-177-236.dynamic.chello.pl. [89.73.177.236]) by mx.google.com with ESMTPSA id p3sm21833691wjf.49.2014.11.03.03.26.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 03:26:59 -0800 (PST) From: Marek Rudnicki To: Subject: run_interrupt_driven_hooks problem, unable to type GELI password Date: Mon, 03 Nov 2014 12:26:55 +0100 Message-ID: <86y4rs7ce8.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain 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, 03 Nov 2014 11:27:03 -0000 Hi I started to have a problem after updating to 10.1-RC3 and 10.1-RC4. 10.1-RC2 was fine. While booting, I'm unable to type a GELI password using a USB keyboard. The system does not react to any typing and I can see the following message: run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config However, when I switch to PS/2 keyboard, then I can type the password without problems and boot normally. Could it be related to the update to RC3/RC4? How could I debug it? Cheers Marek From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 18:53: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 DBDAD90F; Mon, 3 Nov 2014 18:53:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B25FBA8E; Mon, 3 Nov 2014 18:53:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0DD52BC8; Mon, 3 Nov 2014 18:53:01 +0000 (UTC) Date: Mon, 3 Nov 2014 18:52:57 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, mav@FreeBSD.org Message-ID: <1044948769.4.1415040780368.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_8 #181 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_stable_8 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, 03 Nov 2014 18:53:03 -0000 See Changes: [mav] MFC r272059: Remake Linux' SOUND_MIXER_INFO IOCTL as a wrapper around new FreeBSD's one. Submitted by:=09Dmitry Luhtionov ------------------------------------------ [...truncated 86790 lines...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c gssd_xdr.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c gssd_clnt.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c kgss_if.c ld -d -warn-common -r -d -o kgssapi.ko.debug gss_accept_sec_context.o gss_= add_oid_set_member.o gss_acquire_cred.o gss_canonicalize_name.o gss_create_= empty_oid_set.o gss_delete_sec_context.o gss_display_status.o gss_export_na= me.o gss_get_mic.o gss_init_sec_context.o gss_impl.o gss_import_name.o gss_= names.o gss_pname_to_uid.o gss_release_buffer.o gss_release_cred.o gss_rele= ase_name.o gss_release_oid_set.o gss_set_cred_option.o gss_test_oid_set_mem= ber.o gss_unwrap.o gss_verify_mic.o gss_wrap.o gss_wrap_size_limit.o gssd_p= rot.o rpcsec_gss.o rpcsec_gss_conf.o rpcsec_gss_misc.o rpcsec_gss_prot.o sv= c_rpcsec_gss.o kgss_if.o gssd_xdr.o gssd_clnt.o :> export_syms awk -f kgssapi.ko.debug export_syms | xargs -J% objcopy % kgssap= i.ko.debug objcopy --only-keep-debug kgssapi.ko.debug kgssapi.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dkgssapi.ko.symbols kgssapi.ko.d= ebug kgssapi.ko =3D=3D=3D> kgssapi_krb5 (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o kgssapi_krb5.ko.debug krb5_mech.o kcrypto.o kc= rypto_des.o kcrypto_des3.o kcrypto_aes.o kcrypto_arcfour.o :> export_syms awk -f kgssapi_krb5.ko.debug export_syms | xargs -J% objcopy % k= gssapi_krb5.ko.debug objcopy --only-keep-debug kgssapi_krb5.ko.debug kgssapi_krb5.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dkgssapi_krb5.ko.symbols kgssapi= _krb5.ko.debug kgssapi_krb5.ko =3D=3D=3D> khelp (all) =3D=3D=3D> khelp/h_ertt (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o h_ertt.ko.debug h_ertt.o :> export_syms awk -f h_ertt.ko.debug export_syms | xargs -J% objcopy % h_ertt.= ko.debug objcopy --only-keep-debug h_ertt.ko.debug h_ertt.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dh_ertt.ko.symbols h_ertt.ko.deb= ug h_ertt.ko =3D=3D=3D> krpc (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o krpc.ko.debug auth_none.o auth_unix.o authunix= _prot.o clnt_dg.o clnt_rc.o clnt_vc.o getnetconfig.o rpc_callmsg.o rpc_gene= ric.o rpc_prot.o rpcb_clnt.o rpcb_prot.o replay.o svc.o svc_auth.o svc_auth= _unix.o svc_dg.o svc_generic.o svc_vc.o xdr.o xdr_array.o xdr_mbuf.o xdr_me= m.o xdr_reference.o xdr_sizeof.o :> export_syms awk -f krpc.ko.debug export_syms | xargs -J% objcopy % krpc.ko.d= ebug objcopy --only-keep-debug krpc.ko.debug krpc.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dkrpc.ko.symbols krpc.ko.debug k= rpc.ko =3D=3D=3D> ksyms (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o ksyms.ko.debug ksyms.o :> export_syms awk -f ksyms.ko.debug export_syms | xargs -J% objcopy % ksyms.ko= .debug objcopy --only-keep-debug ksyms.ko.debug ksyms.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dksyms.ko.symbols ksyms.ko.debug= ksyms.ko =3D=3D=3D> le (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o if_le.ko.debug am7990.o am79900.o if_le_pci.o = lance.o :> export_syms awk -f if_le.ko.debug export_syms | xargs -J% objcopy % if_le.ko= .debug objcopy --only-keep-debug if_le.ko.debug if_le.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dif_le.ko.symbols if_le.ko.debug= if_le.ko =3D=3D=3D> lge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o if_lge.ko.debug if_lge.o :> export_syms awk -f if_lge.ko.debug export_syms | xargs -J% objcopy % if_lge.= ko.debug objcopy --only-keep-debug if_lge.ko.debug if_lge.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dif_lge.ko.symbols if_lge.ko.deb= ug if_lge.ko =3D=3D=3D> libalias (all) =3D=3D=3D> libalias/libalias (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o libalias.ko.debug alias.o alias_db.o alias_pro= xy.o alias_util.o alias_mod.o alias_sctp.o :> export_syms awk -f libalias.ko.debug export_syms | xargs -J% objcopy % libal= ias.ko.debug objcopy --only-keep-debug libalias.ko.debug libalias.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dlibalias.ko.symbols libalias.ko= .debug libalias.ko =3D=3D=3D> libalias/modules (all) =3D=3D=3D> libalias/modules/cuseeme (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_cuseeme.ko.debug alias_cuseeme.o :> export_syms awk -f alias_cuseeme.ko.debug export_syms | xargs -J% objcopy % = alias_cuseeme.ko.debug objcopy --only-keep-debug alias_cuseeme.ko.debug alias_cuseeme.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_cuseeme.ko.symbols alias_= cuseeme.ko.debug alias_cuseeme.ko =3D=3D=3D> libalias/modules/dummy (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_dummy.ko.debug alias_dummy.o :> export_syms awk -f alias_dummy.ko.debug export_syms | xargs -J% objcopy % al= ias_dummy.ko.debug objcopy --only-keep-debug alias_dummy.ko.debug alias_dummy.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_dummy.ko.symbols alias_du= mmy.ko.debug alias_dummy.ko =3D=3D=3D> libalias/modules/ftp (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_ftp.ko.debug alias_ftp.o :> export_syms awk -f alias_ftp.ko.debug export_syms | xargs -J% objcopy % alia= s_ftp.ko.debug objcopy --only-keep-debug alias_ftp.ko.debug alias_ftp.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_ftp.ko.symbols alias_ftp.= ko.debug alias_ftp.ko =3D=3D=3D> libalias/modules/irc (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_irc.ko.debug alias_irc.o :> export_syms awk -f alias_irc.ko.debug export_syms | xargs -J% objcopy % alia= s_irc.ko.debug objcopy --only-keep-debug alias_irc.ko.debug alias_irc.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_irc.ko.symbols alias_irc.= ko.debug alias_irc.ko =3D=3D=3D> libalias/modules/nbt (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_nbt.ko.debug alias_nbt.o :> export_syms awk -f alias_nbt.ko.debug export_syms | xargs -J% objcopy % alia= s_nbt.ko.debug objcopy --only-keep-debug alias_nbt.ko.debug alias_nbt.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_nbt.ko.symbols alias_nbt.= ko.debug alias_nbt.ko =3D=3D=3D> libalias/modules/pptp (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_pptp.ko.debug alias_pptp.o :> export_syms awk -f alias_pptp.ko.debug export_syms | xargs -J% objcopy % ali= as_pptp.ko.debug objcopy --only-keep-debug alias_pptp.ko.debug alias_pptp.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_pptp.ko.symbols alias_ppt= p.ko.debug alias_pptp.ko =3D=3D=3D> libalias/modules/skinny (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_skinny.ko.debug alias_skinny.o :> export_syms awk -f alias_skinny.ko.debug export_syms | xargs -J% objcopy % a= lias_skinny.ko.debug objcopy --only-keep-debug alias_skinny.ko.debug alias_skinny.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_skinny.ko.symbols alias_s= kinny.ko.debug alias_skinny.ko =3D=3D=3D> libalias/modules/smedia (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o alias_smedia.ko.debug alias_smedia.o :> export_syms awk -f alias_smedia.ko.debug export_syms | xargs -J% objcopy % a= lias_smedia.ko.debug objcopy --only-keep-debug alias_smedia.ko.debug alias_smedia.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dalias_smedia.ko.symbols alias_s= media.ko.debug alias_smedia.ko =3D=3D=3D> libiconv (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c iconv_converter_if.c ld -d -warn-common -r -d -o libiconv.ko.debug iconv.o iconv_ucs.o iconv_xl= at.o iconv_xlat16.o iconv_converter_if.o echo iconv_add=09 iconv_open=09 iconv_close=09 iconv_conv=09 iconv_conv_cas= e=09 iconv_convchr=09 iconv_convchr_case=09 iconv_convstr=09 iconv_convmem= =09 iconv_vfs_refcount > export_syms awk -f libiconv.ko.debug export_syms | xargs -J% objcopy % libic= onv.ko.debug objcopy --only-keep-debug libiconv.ko.debug libiconv.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dlibiconv.ko.symbols libiconv.ko= .debug libiconv.ko =3D=3D=3D> libmbpool (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o libmbpool.ko.debug subr_mbpool.o echo mbp_create=09 mbp_destroy=09 mbp_alloc=09 mbp_free=09 mbp_ext_free=09 = mbp_card_free=09 mbp_count=09 mbp_get=09=09 mbp_get_keep=09 mbp_sync > expo= rt_syms awk -f libmbpool.ko.debug export_syms | xargs -J% objcopy % libm= bpool.ko.debug objcopy --only-keep-debug libmbpool.ko.debug libmbpool.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dlibmbpool.ko.symbols libmbpool.= ko.debug libmbpool.ko =3D=3D=3D> libmchain (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o libmchain.ko.debug subr_mchain.o echo mb_init=09=09 mb_initm=09 mb_done=09=09 mb_detach=09 mb_fixhdr=09 mb_r= eserve=09 mb_put_padbyte=09 mb_put_uint8=09 mb_put_uint16be=09 mb_put_uint1= 6le=09 mb_put_uint32be=09 mb_put_uint32le=09 mb_put_int64be=09 mb_put_int64= le=09 mb_put_mem=09 mb_put_mbuf=09 mb_put_uio=09 md_init=09=09 md_initm=09 = md_done=09=09 md_append_record md_next_record=09 md_get_uint8=09 md_get_ui= nt16=09 md_get_uint16le=09 md_get_uint16be=09 md_get_uint32=09 md_get_uint3= 2be=09 md_get_uint32le=09 md_get_int64=09 md_get_int64be=09 md_get_int64le= =09 md_get_mem=09 md_get_mbuf=09 md_get_uio > export_syms awk -f libmchain.ko.debug export_syms | xargs -J% objcopy % libm= chain.ko.debug objcopy --only-keep-debug libmchain.ko.debug libmchain.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dlibmchain.ko.symbols libmchain.= ko.debug libmchain.ko =3D=3D=3D> lindev (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/con= trib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param la= rge-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer -mno-omit= -leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D38= 7 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-async= hronous-unwind-tables -ffreestanding -fstack-protector -std=3Diso9899:1999 = -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn= o-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o lindev.ko.debug full.o lindev.o :> export_syms awk -f lindev.ko.debug export_syms | xargs -J% objcopy % lindev.= ko.debug objcopy --only-keep-debug lindev.ko.debug lindev.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dlindev.ko.symbols lindev.ko.deb= ug lindev.ko =3D=3D=3D> linprocfs (all) cc -O2 -pipe -DCOMPAT_LINUX32 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_= MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-common -g -fno-omit-frame-= pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zo= ne -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft= -float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -st= d=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-= qual -Wundef -Wno-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o linprocfs.ko.debug linprocfs.o :> export_syms awk -f linprocfs.ko.debug export_syms | xargs -J% objcopy % linp= rocfs.ko.debug objcopy --only-keep-debug linprocfs.ko.debug linprocfs.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dlinprocfs.ko.symbols linprocfs.= ko.debug linprocfs.ko =3D=3D=3D> linsysfs (all) cc -O2 -pipe -DCOMPAT_LINUX32 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_= MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-common -g -fno-omit-frame-= pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zo= ne -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft= -float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -st= d=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-= qual -Wundef -Wno-pointer-sign -fformat-extensions -c ld -d -warn-common -r -d -o linsysfs.ko.debug linsysfs.o :> export_syms awk -f linsysfs.ko.debug export_syms | xargs -J% objcopy % linsy= sfs.ko.debug objcopy --only-keep-debug linsysfs.ko.debug linsysfs.ko.symbols objcopy --strip-debug --add-gnu-debuglink=3Dlinsysfs.ko.symbols linsysfs.ko= .debug linsysfs.ko =3D=3D=3D> linux (all) cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing -Werr= or -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include= /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common = -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel= =3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-d= ecls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c= cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing -Werr= or -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include= /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common = -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel= =3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-d= ecls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c= cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing -Werr= or -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include= /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common = -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel= =3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-d= ecls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c= cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing -Werr= or -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include= /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common = -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel= =3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-d= ecls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c= cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing -Werr= or -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include= /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common = -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel= =3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-d= ecls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c= cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing -Werr= or -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include= /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common = -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel= =3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-d= ecls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c= cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing -Werr= or -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include= /usr/obj -I. -I@ -I@/contrib/altq -finline-limit=3D8000 --param= inline-unit-growth=3D100 --param large-function-growth=3D1000 -fno-common = -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj -mcmodel= =3Dkernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-m= mx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding = -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-d= ecls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c= cc1: warnings being treated as errors : In function 'linux_ioctl_sound': :1749: warning: implicit declaration o= f function 'sys_ioctl' :1749: warning: nested extern declarat= ion of 'sys_ioctl' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** [buildkernel] Error code 2 1 error Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Mon Nov 3 21:53: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 16F0ED93; Mon, 3 Nov 2014 21:53:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 05F7FF62; Mon, 3 Nov 2014 21:53:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0E13FC0E; Mon, 3 Nov 2014 21:53:01 +0000 (UTC) Date: Mon, 3 Nov 2014 21:53:00 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, mav@FreeBSD.org Message-ID: <1915784512.5.1415051581281.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1044948769.4.1415040780368.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1044948769.4.1415040780368.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_8 #182 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_8 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, 03 Nov 2014 21:53:02 -0000 See From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 06:29: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 02624AD3; Tue, 4 Nov 2014 06:29:53 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 BB01288B; Tue, 4 Nov 2014 06:29:52 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id v10so12850160pde.8 for ; Mon, 03 Nov 2014 22:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=JWH5EQ1my4Wz6RJXvJ721yy7b87WiYUpe2OSpn/3O4I=; b=fvevAymDOP+NgbmkIJaWuOwwZga9tjc+JvLwclazJbSJUBl/2pnfZ2AAWF5Ha+US/g Oq62ijOdnvsN0OD6l9GZkD3u9ZWZbblWKYJ6OjWyU1YwZpNPfllkuqOioVPuw45knyTK dmvrF/pcHg4FaN1oCesFrTtyxxEtUf6Xzv+5PWH7UcRr75JSemxflxJswYcgj/4LcnDp TmMiw1r6I4CbYVCrRVnvaeg5xmQbHuw+YhAWHAZ6oNGUv4F9KE3VyaOf28g/M8MhzVby nmnQ1NLB7OcyB/mzP3fXCwJPZKhC6QqWiELWn7lpOTt2Ddq8U4N4Rrf/I3UEuJjNZvey eChw== X-Received: by 10.68.232.226 with SMTP id tr2mr2050645pbc.89.1415082592274; Mon, 03 Nov 2014 22:29:52 -0800 (PST) Received: from [10.0.1.8] (50-0-30-197.dsl.dynamic.fusionbroadband.com. [50.0.30.197]) by mx.google.com with ESMTPSA id kc15sm3310624pbb.3.2014.11.03.22.29.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 22:29:51 -0800 (PST) From: George Kola Subject: ARC size limit Date: Mon, 3 Nov 2014 22:29:48 -0800 Message-Id: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: alc@FreeBSD.org, gibbs@FreeBSD.org, kib@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, 04 Nov 2014 06:29:53 -0000 Hi All, This is my first post to freebsd-stable fresh of Meet BSD = California 2014. We are switching our entire production to FreeBSD. Our = storage servers have 256 GB of RAM , 4 TB of SSD and 40 TB of spinning = disks. We are running ZFS root and the SSD is configured as L2ARC. We = are running FreeBSD 10.1 RC3 I am finding that on all our machines, ARC is somehow limited to = < 64 GB of memory and we have a huge inactive memory (180 G). The = surprising thing is that ARC seems to have almost the same limit (< 64 = GB) on all of our storage boxes and ARC is not growing even though L2ARC = hit shows that there is advantage in growing ARC. Any help/pointers is appreciated. What I am trying to do is to tune ZFS for our workload. We are = hoping that we get a high hit rate.=20 Thanks to Justin Gibbs and Allan Jude for initial pointers and = help. They suggested posting to the mailing list to get further help. I have pasted top output and zfs-stats output below and yes UMA = is enabled. Thanks, George =20 top last pid: 27458; load averages: 3.30, 5.42, 5.34 = = up 6+09:59:30 05:38:49 71 processes: 1 running, 70 sleeping CPU: 4.2% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.9% idle Mem: 11G Active, 181G Inact, 52G Wired, 1368M Cache, 4266M Free ARC: 47G Total, 1555M MFU, 41G MRU, 35M Anon, 3984M Header, 709M Other Swap: 64G Total, 2874M Used, 61G Free, 4% Inuse sysctl vfs.zfs.zio.use_uma vfs.zfs.zio.use_uma: 1 zfs-mon -a output ZFS real-time cache activity monitor Seconds elapsed: 62 Cache hits and misses: 1s 10s 60s tot ARC hits: 124 126 103 101 ARC misses: 35 46 29 28 ARC demand data hits: 55 90 61 61 ARC demand data misses: 20 32 18 17 ARC demand metadata hits: 69 36 42 40 ARC demand metadata misses: 9 13 10 9 ARC prefetch data hits: 0 0 0 0 ARC prefetch data misses: 6 1 1 1 ARC prefetch metadata hits: 0 0 0 0 ARC prefetch metadata misses: 0 0 0 0 L2ARC hits: 16 28 14 14 L2ARC misses: 19 18 15 14 ZFETCH hits: 592 2842 2098 2047 ZFETCH misses: 308 1326 507 494 Cache efficiency percentage: 10s 60s tot ARC: 73.26 78.03 78.29 ARC demand data: 73.77 77.22 78.21 ARC demand metadata: 73.47 80.77 81.63 ARC prefetch data: 0.00 0.00 0.00 ARC prefetch metadata: 0.00 0.00 0.00 L2ARC: 60.87 48.28 50.00 ZFETCH: 68.19 80.54 80.56 zfs-stats -a output ZFS real-time cache activity monitor Seconds elapsed: 62 Cache hits and misses: 1s 10s 60s tot ARC hits: 124 126 103 101 ARC misses: 35 46 29 28 ARC demand data hits: 55 90 61 61 ARC demand data misses: 20 32 18 17 ARC demand metadata hits: 69 36 42 40 ARC demand metadata misses: 9 13 10 9 ARC prefetch data hits: 0 0 0 0 ARC prefetch data misses: 6 1 1 1 ARC prefetch metadata hits: 0 0 0 0 ARC prefetch metadata misses: 0 0 0 0 L2ARC hits: 16 28 14 14 L2ARC misses: 19 18 15 14 ZFETCH hits: 592 2842 2098 2047 ZFETCH misses: 308 1326 507 494 Cache efficiency percentage: 10s 60s tot ARC: 73.26 78.03 78.29 ARC demand data: 73.77 77.22 78.21 ARC demand metadata: 73.47 80.77 81.63 ARC prefetch data: 0.00 0.00 0.00 ARC prefetch metadata: 0.00 0.00 0.00 L2ARC: 60.87 48.28 50.00 ZFETCH: 68.19 80.54 80.56 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 07:21:05 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 1BE9D474; Tue, 4 Nov 2014 07:21:05 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 D30A8CCD; Tue, 4 Nov 2014 07:21:04 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so6724977iec.26 for ; Mon, 03 Nov 2014 23:21:04 -0800 (PST) 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=f6CIK0KBAUJlK8NYAVB38hNCCWnWPHLpkEk9P/N+MF0=; b=jR86mKm2iAiQ/rhSysqau2kBSbr0PXbaZckvW31H4KnY5yHkJNDjW1B8+Fa8aaAMus fOycNIdVpEelvVklxq6vIiFjXwDgFfNfH7QcZSNGfgCJDJZd1oaKSNrMCpdcdQmL8E91 6oCIeYZ1rhpbup3tPcUGr3JRPRRSaP1+JAs0dRROF2X6J71/4IozLWFd+SjF1CsHV9NW MFfIROpyEfKrm8qWdEPoXXVTCZd7bDQQcGJdgyGV5hUWvEGX59av3B4v7GimN6FcoKku SB0S6xrPfx3HuGdP8a1p079td2aLeh6eam+Pvw8m8+Q7Xe8E4QaUrmpiZ92Pi4yM6nM3 PbuQ== MIME-Version: 1.0 X-Received: by 10.107.11.67 with SMTP id v64mr355003ioi.76.1415085664148; Mon, 03 Nov 2014 23:21:04 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.11.152 with HTTP; Mon, 3 Nov 2014 23:21:04 -0800 (PST) In-Reply-To: <20141103083214.GG4390@hub.FreeBSD.org> References: <20141102194344.GA21862@hub.FreeBSD.org> <20141103083214.GG4390@hub.FreeBSD.org> Date: Mon, 3 Nov 2014 23:21:04 -0800 X-Google-Sender-Auth: gm76fI4seHgOuQOrpYQ4PtMZaY8 Message-ID: Subject: Re: FreeBSD 10.1-RC4 Now Available From: Kevin Oberman To: Glen Barber Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Release Engineering Team , 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, 04 Nov 2014 07:21:05 -0000 On Mon, Nov 3, 2014 at 12:32 AM, Glen Barber wrote: > On Sun, Nov 02, 2014 at 04:37:26PM -0800, Kevin Oberman wrote: > > On Sun, Nov 2, 2014 at 11:43 AM, Glen Barber wrote: > > I hit a problem right out at the start: > > # freebsd-update upgrade -r 10.1-RC4 > > Looking up update.FreeBSD.org mirrors... 5 mirrors found. > > Fetching metadata signature for 10.0-RC3 from update2.freebsd.org... > > done. > > Fetching metadata index... done. > > Fetching 1 metadata patches. done. > > Applying metadata patches... done. > > Fetching 1 metadata files... done. > > Inspecting system... done. > > > > The following components of FreeBSD seem to be installed: > > kernel/generic src/src world/base world/doc world/games > > > > The following components of FreeBSD do not seem to be installed: > > world/lib32 > > > > Does this look reasonable (y/n)? n > > > > But I do have lib32 installed and have had since the initial > > installation.No prior upgrade failed. I have no time to look at how > > freebsd-update tests for components, but something went haywire. > > I am unable to reproduce this, and prior to sending the 10.1-RC4 > announcement email, did test the upgrade path from 10.1-RC2 and > 10.1-RC3. I've just double-checked on a clean install of 10.1-RC3, and > only see (as expected on this install) src/src component not installed > locally. > > Glen > Ahh. I found a rather nasty oops. It is NOT a problem with RC4. It was a typo when I intended to go to RC3. Seems I went to 10.0-RC3-p1. I may take me a while to clean up the mess! Any explanation of how this could have caused me to lose /usr/lib32 contents would be appreciated Sorry for the noise. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 07:53: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 4EBC2F25 for ; Tue, 4 Nov 2014 07:53:17 +0000 (UTC) Received: from nm33-vm2.bullet.mail.ne1.yahoo.com (nm33-vm2.bullet.mail.ne1.yahoo.com [98.138.229.66]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B0B7FED for ; Tue, 4 Nov 2014 07:53:16 +0000 (UTC) Received: from [127.0.0.1] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 04 Nov 2014 07:53:10 -0000 Received: from [98.138.100.118] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 04 Nov 2014 07:50:30 -0000 Received: from [98.138.226.166] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 04 Nov 2014 07:50:30 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 04 Nov 2014 07:50:30 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 87658.38097.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 2042 invoked by uid 60001); 4 Nov 2014 07:50:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1415087429; bh=NlbFl+/nC1FGgWYaohe0eJ59I4RMFzJNWX6hgSwRJgg=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=agivYnGOKVSE5ne/J7aKYJBaXMazBotIsrNRP46cRj+sHd5GDWNDHJbnJJJZ/D7T92rPsslTCfmoUzUbqzyli9httDVpP6eZDZEcyL6St2x1yqBoeP8UMJZ0VUepvDbzGANZrDoYHJbligl/MGfxE0O0+tX+zvkMe4cNU/hNg/c= X-YMail-OSG: yqgODCwVM1nx3s84Ebzj54N6TCDKA5BnSVZCAn2GIAgYlj5 VCeJ1E5L60OZiq6eHGGEz8vI1_RB0cFItPqCn6KOID1ZD_hFMPYdarxkqKE_ 33RZ.5CcRXDzGP2nuaIG_vWUlPPCw60gkiXhpsSqmz6bOrQDNMeWo.mzNVNH zZbEQEzWgmq7YDfeQm5Kw1oW6m4KkHPeskIDtdTgUJOYNO1Olid__WiWOCfd Cv6TrF05EgNc2EZfpRmcsol8mZEFSqDT52byet0qOUayeLA3y9K9We0V8QcP _nmFG7P9ZHWaqJJ8WRBEZ6gPHTMQcplWVFRYGEC3lD6ee6c3TM49Bnz8mxMq uPUz8HCDt0A7E6TyulhaatYMjquhkJBnxYkCQzclPG82R8Rufyok0GqYueqL rJRdtmrArkzSnNtPSzITH6hCZ1xot8uYsZlYDoPclHLZ5qxRQ7M0kNEiideg wDChL0mUi46YgM1KySgLEMGFTY81aQhohG0BrS1M6SguOCgweAUC1SoJlvZv xeLZFFsKPcafQ1WRgVt_rRcDEDfiX4FsFrmlBAdal4vOLujgmz4OO_Xu9lOO uy5pwr.fgPbVo8WHSekwneFWPMZ.TDyo72d9AbmhmMfZ.YYv4fsMmRCdY_jQ 8ijhfUPe7s3xHXTU37ItVB9pT1n.tW6fBiSuHnc7hENEDYD39ev6oER_RwL. BM8iUWTfMNkyVrPQVnXceeIpFZexMwA-- Received: from [166.172.57.181] by web126202.mail.ne1.yahoo.com via HTTP; Mon, 03 Nov 2014 23:50:29 PST X-Rocket-MIMEInfo: 002.001, U2VudCBmcm9tIFlhaG9vIE1haWwgb24gQW5kcm9pZAoKATABAQEB X-Mailer: YahooMailAndroidMobile/4.7.2 YahooMailWebService/0.8.203.733 Message-ID: <1415087429.64646.YahooMailAndroidMobile@web126202.mail.ne1.yahoo.com> Date: Mon, 3 Nov 2014 23:50:29 -0800 From: Chad Howard Subject: Your New Adult FriendFinder Login Information! To: "freebsd-stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, 04 Nov 2014 07:53:17 -0000 Sent from Yahoo Mail on Android From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 09:08: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 5078C3E3 for ; Tue, 4 Nov 2014 09:08:11 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 D88F2D02 for ; Tue, 4 Nov 2014 09:08:09 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id q5so8106481wiv.5 for ; Tue, 04 Nov 2014 01:08:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kK52DZT/U7LuqYu+9vDVASGU3BTtjZ9zEgM8jkvhlvQ=; b=N/8xcFfcUbkzGom7Kt1ROKE4gMF9HwEE1KGftEN8y/vPdVxWuCatgTPzIz18KULIHy 6uYsIK9017rWW58ndEsrxmbRlJCWPVVPKkaKO8ySJC+9oa4Id4cn484dXOfMXT2Kf4QY VlVst9BXOHzYnsW5bxepYcigIH3NJDPTSvMX6cG1jKTrf5n7XXTjOFedxBczePVNe1du wU8aicvGBq51FPuwrDJ3aWGNP3NVIm2O8OgovRuRLsrpMBiYD05+NeY/pITJvSRbfyk9 BtyJwHCwqbCC9zu6EasMDfrzCdHn3p9q798dPZZv/HsZgVXlDpkc6ddTREWP14W+a21O asrQ== X-Gm-Message-State: ALoCoQlHPAWpUk8ronUEiqtcKIr/zb02/agYkxFvrOdXViM2VNLrzQeMj7PNmKa+/xtUOejl3qa1 X-Received: by 10.194.200.129 with SMTP id js1mr15514671wjc.0.1415092087938; Tue, 04 Nov 2014 01:08:07 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id i3sm11552691wix.0.2014.11.04.01.08.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 01:08:06 -0800 (PST) Message-ID: <54589722.3080803@multiplay.co.uk> Date: Tue, 04 Nov 2014 09:06:42 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ARC size limit References: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> In-Reply-To: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> 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: Tue, 04 Nov 2014 09:08:11 -0000 You need https://svnweb.freebsd.org/base?view=revision&revision=272875 On 04/11/2014 06:29, George Kola wrote: > Hi All, > This is my first post to freebsd-stable fresh of Meet BSD California 2014. We are switching our entire production to FreeBSD. Our storage servers have 256 GB of RAM , 4 TB of SSD and 40 TB of spinning disks. We are running ZFS root and the SSD is configured as L2ARC. We are running FreeBSD 10.1 RC3 > I am finding that on all our machines, ARC is somehow limited to < 64 GB of memory and we have a huge inactive memory (180 G). The surprising thing is that ARC seems to have almost the same limit (< 64 GB) on all of our storage boxes and ARC is not growing even though L2ARC hit shows that there is advantage in growing ARC. > Any help/pointers is appreciated. > What I am trying to do is to tune ZFS for our workload. We are hoping that we get a high hit rate. > Thanks to Justin Gibbs and Allan Jude for initial pointers and help. They suggested posting to the mailing list to get further help. > > I have pasted top output and zfs-stats output below and yes UMA is enabled. > > Thanks, > George > > > > top > last pid: 27458; load averages: 3.30, 5.42, 5.34 up 6+09:59:30 05:38:49 > 71 processes: 1 running, 70 sleeping > CPU: 4.2% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.9% idle > Mem: 11G Active, 181G Inact, 52G Wired, 1368M Cache, 4266M Free > ARC: 47G Total, 1555M MFU, 41G MRU, 35M Anon, 3984M Header, 709M Other > Swap: 64G Total, 2874M Used, 61G Free, 4% Inuse > > > > sysctl vfs.zfs.zio.use_uma > vfs.zfs.zio.use_uma: 1 > > > > > zfs-mon -a output > > ZFS real-time cache activity monitor > Seconds elapsed: 62 > > Cache hits and misses: > 1s 10s 60s tot > ARC hits: 124 126 103 101 > ARC misses: 35 46 29 28 > ARC demand data hits: 55 90 61 61 > ARC demand data misses: 20 32 18 17 > ARC demand metadata hits: 69 36 42 40 > ARC demand metadata misses: 9 13 10 9 > ARC prefetch data hits: 0 0 0 0 > ARC prefetch data misses: 6 1 1 1 > ARC prefetch metadata hits: 0 0 0 0 > ARC prefetch metadata misses: 0 0 0 0 > L2ARC hits: 16 28 14 14 > L2ARC misses: 19 18 15 14 > ZFETCH hits: 592 2842 2098 2047 > ZFETCH misses: 308 1326 507 494 > > Cache efficiency percentage: > 10s 60s tot > ARC: 73.26 78.03 78.29 > ARC demand data: 73.77 77.22 78.21 > ARC demand metadata: 73.47 80.77 81.63 > ARC prefetch data: 0.00 0.00 0.00 > ARC prefetch metadata: 0.00 0.00 0.00 > L2ARC: 60.87 48.28 50.00 > ZFETCH: 68.19 80.54 80.56 > > > > > zfs-stats -a output > > ZFS real-time cache activity monitor > Seconds elapsed: 62 > > Cache hits and misses: > 1s 10s 60s tot > ARC hits: 124 126 103 101 > ARC misses: 35 46 29 28 > ARC demand data hits: 55 90 61 61 > ARC demand data misses: 20 32 18 17 > ARC demand metadata hits: 69 36 42 40 > ARC demand metadata misses: 9 13 10 9 > ARC prefetch data hits: 0 0 0 0 > ARC prefetch data misses: 6 1 1 1 > ARC prefetch metadata hits: 0 0 0 0 > ARC prefetch metadata misses: 0 0 0 0 > L2ARC hits: 16 28 14 14 > L2ARC misses: 19 18 15 14 > ZFETCH hits: 592 2842 2098 2047 > ZFETCH misses: 308 1326 507 494 > > Cache efficiency percentage: > 10s 60s tot > ARC: 73.26 78.03 78.29 > ARC demand data: 73.77 77.22 78.21 > ARC demand metadata: 73.47 80.77 81.63 > ARC prefetch data: 0.00 0.00 0.00 > ARC prefetch metadata: 0.00 0.00 0.00 > L2ARC: 60.87 48.28 50.00 > ZFETCH: 68.19 80.54 80.56 > > > > _______________________________________________ > 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 Tue Nov 4 09:28: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 BDCD6B54 for ; Tue, 4 Nov 2014 09:28:50 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80CABEF8 for ; Tue, 4 Nov 2014 09:28:50 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XlaPk-0007tN-F9 for freebsd-stable@freebsd.org; Tue, 04 Nov 2014 10:28:41 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: ARC size limit References: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> Date: Tue, 04 Nov 2014 10:28:35 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 2c7105051753a2a38a95e24053047c4e 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, 04 Nov 2014 09:28:50 -0000 On Tue, 04 Nov 2014 07:29:48 +0100, George Kola wrote: > Hi All, > This is my first post to freebsd-stable fresh of Meet BSD > California 2014. We are switching our entire production to FreeBSD. Our > storage servers have 256 GB of RAM , 4 TB of SSD and 40 TB of spinning > disks. We are running ZFS root and the SSD is configured as L2ARC. We > are running FreeBSD 10.1 RC3 > I am finding that on all our machines, ARC is somehow limited to > < 64 GB of memory and we have a huge inactive memory (180 G). The > surprising thing is that ARC seems to have almost the same limit (< 64 > GB) on all of our storage boxes and ARC is not growing even though L2ARC > hit shows that there is advantage in growing ARC. > Any help/pointers is appreciated. > What I am trying to do is to tune ZFS for our workload. We are > hoping that we get a high hit rate. > Thanks to Justin Gibbs and Allan Jude for initial pointers and > help. They suggested posting to the mailing list to get further help. > > I have pasted top output and zfs-stats output below and yes UMA > is enabled. > > Thanks, > George What is actually your problem? Do you just want higher numbers of ARC usage or is your system slower than expected? And what is your usage of these 40TB. Are all 40TB accessed a lot or is 64 GB of ARC equal to the working set of data. Ronald. > > > top > last pid: 27458; load averages: 3.30, 5.42, > 5.34 > up 6+09:59:30 05:38:49 > 71 processes: 1 running, 70 sleeping > CPU: 4.2% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.9% idle > Mem: 11G Active, 181G Inact, 52G Wired, 1368M Cache, 4266M Free > ARC: 47G Total, 1555M MFU, 41G MRU, 35M Anon, 3984M Header, 709M Other > Swap: 64G Total, 2874M Used, 61G Free, 4% Inuse > > > > sysctl vfs.zfs.zio.use_uma > vfs.zfs.zio.use_uma: 1 > > > > > zfs-mon -a output > > ZFS real-time cache activity monitor > Seconds elapsed: 62 > > Cache hits and misses: > 1s 10s 60s tot > ARC hits: 124 126 103 101 > ARC misses: 35 46 29 28 > ARC demand data hits: 55 90 61 61 > ARC demand data misses: 20 32 18 17 > ARC demand metadata hits: 69 36 42 40 > ARC demand metadata misses: 9 13 10 9 > ARC prefetch data hits: 0 0 0 0 > ARC prefetch data misses: 6 1 1 1 > ARC prefetch metadata hits: 0 0 0 0 > ARC prefetch metadata misses: 0 0 0 0 > L2ARC hits: 16 28 14 14 > L2ARC misses: 19 18 15 14 > ZFETCH hits: 592 2842 2098 2047 > ZFETCH misses: 308 1326 507 494 > > Cache efficiency percentage: > 10s 60s tot > ARC: 73.26 78.03 78.29 > ARC demand data: 73.77 77.22 78.21 > ARC demand metadata: 73.47 80.77 81.63 > ARC prefetch data: 0.00 0.00 0.00 > ARC prefetch metadata: 0.00 0.00 0.00 > L2ARC: 60.87 48.28 50.00 > ZFETCH: 68.19 80.54 80.56 > > > > > zfs-stats -a output > > ZFS real-time cache activity monitor > Seconds elapsed: 62 > > Cache hits and misses: > 1s 10s 60s tot > ARC hits: 124 126 103 101 > ARC misses: 35 46 29 28 > ARC demand data hits: 55 90 61 61 > ARC demand data misses: 20 32 18 17 > ARC demand metadata hits: 69 36 42 40 > ARC demand metadata misses: 9 13 10 9 > ARC prefetch data hits: 0 0 0 0 > ARC prefetch data misses: 6 1 1 1 > ARC prefetch metadata hits: 0 0 0 0 > ARC prefetch metadata misses: 0 0 0 0 > L2ARC hits: 16 28 14 14 > L2ARC misses: 19 18 15 14 > ZFETCH hits: 592 2842 2098 2047 > ZFETCH misses: 308 1326 507 494 > > Cache efficiency percentage: > 10s 60s tot > ARC: 73.26 78.03 78.29 > ARC demand data: 73.77 77.22 78.21 > ARC demand metadata: 73.47 80.77 81.63 > ARC prefetch data: 0.00 0.00 0.00 > ARC prefetch metadata: 0.00 0.00 0.00 > L2ARC: 60.87 48.28 50.00 > ZFETCH: 68.19 80.54 80.56 > > > > _______________________________________________ > 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 Tue Nov 4 09:35:14 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 C72E3DDE; Tue, 4 Nov 2014 09:35:13 +0000 (UTC) Date: Tue, 4 Nov 2014 09:35:11 +0000 From: Glen Barber To: Kevin Oberman Subject: Re: FreeBSD 10.1-RC4 Now Available Message-ID: <20141104093510.GA1226@hub.FreeBSD.org> References: <20141102194344.GA21862@hub.FreeBSD.org> <20141103083214.GG4390@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: 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 , 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, 04 Nov 2014 09:35:14 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 03, 2014 at 11:21:04PM -0800, Kevin Oberman wrote: > On Mon, Nov 3, 2014 at 12:32 AM, Glen Barber wrote: >=20 > > On Sun, Nov 02, 2014 at 04:37:26PM -0800, Kevin Oberman wrote: > > > On Sun, Nov 2, 2014 at 11:43 AM, Glen Barber wrote: > > > I hit a problem right out at the start: > > > # freebsd-update upgrade -r 10.1-RC4 > > > Looking up update.FreeBSD.org mirrors... 5 mirrors found. > > > Fetching metadata signature for 10.0-RC3 from update2.freebsd.org.= =2E. > > > done. > > > Fetching metadata index... done. > > > Fetching 1 metadata patches. done. > > > Applying metadata patches... done. > > > Fetching 1 metadata files... done. > > > Inspecting system... done. > > > > > > The following components of FreeBSD seem to be installed: > > > kernel/generic src/src world/base world/doc world/games > > > > > > The following components of FreeBSD do not seem to be installed: > > > world/lib32 > > > > > > Does this look reasonable (y/n)? n > > > > > > But I do have lib32 installed and have had since the initial > > > installation.No prior upgrade failed. I have no time to look at how > > > freebsd-update tests for components, but something went haywire. > > > > I am unable to reproduce this, and prior to sending the 10.1-RC4 > > announcement email, did test the upgrade path from 10.1-RC2 and > > 10.1-RC3. I've just double-checked on a clean install of 10.1-RC3, and > > only see (as expected on this install) src/src component not installed > > locally. > > >=20 > Ahh. I found a rather nasty oops. It is NOT a problem with RC4. It was a > typo when I intended to go to RC3. Seems I went to 10.0-RC3-p1. I may take > me a while to clean up the mess! Any explanation of how this could have > caused me to lose /usr/lib32 contents would be appreciated >=20 > Sorry for the noise. My suspicion is that 'freebsd-update install' was run twice without a reboot between. freebsd-update(8) uses uname(1) to determine the running userland and kernel to determine the upgrade path, specifically the current running version to the version intended to be run. It uses 'uname -r' for this, so if you do this, you can end up with a very interesting running userland after the reboot. # # fetch update bits for next RC # freebsd-update -r 10.1-RC4 upgrade # # install kernel for next RC(*) # freebsd-update install # # install userland for next RC # freebsd-update install (*) This is important. While you have technically installed the new kernel, it is not the *active* kernel, and freebsd-update(8) (nor any other utility using 'uname -r') cannot tell the difference without a reboot. For example, on my laptop: # uname -ri 11.0-CURRENT NUCLEUS # env UNAME_r=3D12.0-EVILBSD UNAME_i=3DNOTGENERIC uname -ri 12.0-EVILBSD NOTGENERIC While it is purely conjecture this is the situation in your case, "disappearing" /usr/lib32 is certainly an effect of this I have never personally seen before. Was /usr/lib32 in fact gone, or are you basing that on the output of freebsd-update(8)? Glen --5vNYLRcllDrimb99 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUWJ3OAAoJEAMUWKVHj+KTJTkP/3vWsLxuEZb9kFWWQJ7mwYYw S5In1mbH/HOFGPz39K/JlQThgJYTb6ht3sdzfQ/dO5KQ8hDj/aX9vdh/3ZIoSzXn U1EdT0BWOuCC7g0ysH5D/qzRPBUCBngZ2jtVNHQmjh7l78Uk4n4+84YEBni3EIqy +QhLxaKBKHwzpe6tIYsF/isakX90TibJWuNpAe5GLLPuMwVSIM4GfMTSPyb2Pn1g J/tyIrpgAsYMNSmgPpC8upPVnlBwXGARCRF8PNlS9tr67PCtLRR/SMl1qei54rYV 75pDTVNyWa4eE1u9iXOEX26S/ZQyo+jyebEmFWmhI2hWJgm69xQC97intz+T6fuX jo0/xw4rgeKfGpuChJJ09hkqrxRNFa87pP9VL4kZC2b4JZ2QvgWblfzztkgyQleq SZdcHBiYnJE5n3ZAwWE86EmYR4zokDs4/QhmVuBxyVo3lcrQacc3WBL5rUcV2KRh lUzh1tMcnw+8NBlBqmjYDPQswT4EVb15MMemdGYsqHxOi39dVpDGnW7Yg0ZaAQnW YUrLcC3wpixrycqjGvULRYqcZ2j+ODoMNB8VZ+hAjX/3DExzWQzgDH2OTJTk4UE0 EHYVjj2NAl+omHRcu2VpMcW7AnGr5Mid4ATeIBAh+GrJbNWkKnobl6xrf8LlMYH7 pU0/bT6Ss3M40f7a2dau =ZSlj -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 10:35:30 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 E05BA383 for ; Tue, 4 Nov 2014 10:35:30 +0000 (UTC) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id C04B7930 for ; Tue, 4 Nov 2014 10:35:30 +0000 (UTC) Received: from homiemail-a68.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by hapkido.dreamhost.com (Postfix) with ESMTP id 171A6838AA for ; Tue, 4 Nov 2014 02:35:24 -0800 (PST) Received: from homiemail-a68.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a68.g.dreamhost.com (Postfix) with ESMTP id 6EA1540112D2E for ; Tue, 4 Nov 2014 02:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=menhennitt.com.au; h= message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=menhennitt.com.au; bh=E/y+ThIs/DfH jtdZyFLa33J6QAs=; b=hXCIfqYUtbzg0XXodjNqiY6LtyCle0S8v/Fkp9cvt4Z5 3c67Xac5v5pnfWwutUoumc2nWp4mLCjH7mejLarfK4he+vIf/ezyQRubMiB0LZoX xVA7Qd+8DTeyG/mazS0wUjBF2kUGycqOyW7t4HK09lIOus2c4wQTBFt9ZYLovl0= Received: from [203.2.73.75] (c122-107-224-152.mckinn3.vic.optusnet.com.au [122.107.224.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: graham@menhennitt.com.au) by homiemail-a68.g.dreamhost.com (Postfix) with ESMTPSA id 06D7340112D2A for ; Tue, 4 Nov 2014 02:35:17 -0800 (PST) Message-ID: <5458ABE4.1010308@menhennitt.com.au> Date: Tue, 04 Nov 2014 21:35:16 +1100 From: Graham Menhennitt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD stable Subject: installer can't change partition sizes 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: Tue, 04 Nov 2014 10:35:31 -0000 I don't know if this is my mistake or a bug, but I can't change partition sizes when installing 10.1 RC3. This is both in the Guided and Manual partitioning. I'm doing this from memory so please forgive me if I get it wrong. I start the installer, select the keymap, and enter the hostname. I say that I want to use the whole disk for FreeBSD. It then gives the me the choice of partitioning methods: Guided, Manual, Shell, or ZFS on root. I choose Guided and it automatically defines 3 partitions -boot, -ufs, and -swap with various sizes. I'd like to have a separate /usr partition so I try to change the size of the -ufs partition. But I can't get the cursor to move into the size field. It moves between the Type field and the Ok, Options, and Cancel buttons. But it won't move to the Size field. I've tried arrows, tabs, enter. If I delete a partition and create a new one, the same things happens - the partition is made to take up the remainder of the disk space and I can't change it. The same thing happens in Manual mode. Am I doing something wrong? Thanks, Graham From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 15:57: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 11E59B9E for ; Tue, 4 Nov 2014 15:57:23 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id CB295753 for ; Tue, 4 Nov 2014 15:57:21 +0000 (UTC) Received: from [173.88.10.122] ([173.88.10.122:12942] helo=mail.laus.org) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 2C/58-15509-817F8545; Tue, 04 Nov 2014 15:56:08 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.14.9/8.14.9) with ESMTP id sA4Fu7IG038867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Nov 2014 10:56:08 -0500 (EST) (envelope-from lausts@acm.org) From: "Thomas Laus" Organization: ABB To: freebsd-stable@freebsd.org Date: Tue, 04 Nov 2014 10:56:03 -0500 Subject: FAILURE - zero length DMA transfer attempted setting up DMA failed Reply-to: lausts@acm.org Message-ID: <5458F713.18781.42E5DC@lausts.acm.org> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 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, 04 Nov 2014 15:57:23 -0000 I performed a source upgrade on my computer that is used to edit my vacation videos from FreeBSD 9-STABLE r273924 to FreeBSD 10.1-STABLE r274052 and had continuous errors on the system console after booting into multiuser mode. The errors went away when going back to single user mode. Nov 3 14:07:30 video kernel: FreeBSD 10.1-PRERELEASE #1 r274052: Mon Nov 3 13:48:05 EST 2014 Nov 3 14:07:30 video kernel: CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2999.72-MHz K8-class CPU) Nov 3 14:07:30 video kernel: Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Nov 3 14:07:30 video kernel: Features=0xbfebfbff Nov 3 14:07:30 video kernel: Features2=0x8e3fd Nov 3 14:07:30 video kernel: AMD Features=0x20000800 Nov 3 14:07:30 video kernel: AMD Features2=0x1 Nov 3 14:07:30 video kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 Nov 3 14:07:30 video kernel: ata0: at channel 0 on atapci0 Nov 3 14:07:30 video kernel: atapci1: port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb80f irq 19 at device 31.2 on pci0 Nov 3 14:07:30 video kernel: ata2: at channel 0 on atapci1 Nov 3 14:07:30 video kernel: ata3: at channel 1 on atapci1 Nov 3 14:07:30 video kernel: ada0 at ata2 bus 0 scbus1 target 0 lun 0 Nov 3 14:07:30 video kernel: ada0: ATA-8 SATA 3.x device Nov 3 14:07:30 video kernel: ada0: Serial Number P02312106355 Nov 3 14:07:30 video kernel: ada0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) Nov 3 14:07:30 video kernel: ada0: 244198MB (500118192 512 byte sectors: 16H 63S/T 16383C) Nov 3 14:07:30 video kernel: ada0: Previously was known as ad4 Nov 3 14:18:17 video kernel: ata0: FAILURE - zero length DMA transfer attempted Nov 3 14:18:17 video kernel: ata0: setting up DMA failed Nov 3 14:18:17 video kernel: ata0: FAILURE - zero length DMA transfer attempted Nov 3 14:18:17 video kernel: ata0: setting up DMA failed Nov 3 14:18:17 video kernel: ata3: FAILURE - zero length DMA transfer attempted Nov 3 14:18:17 video kernel: ata3: setting up DMA failed Nov 3 14:18:17 video kernel: ata3: FAILURE - zero length DMA transfer attempted Nov 3 14:18:17 video kernel: ata3: setting up DMA failed Nov 3 14:18:17 video kernel: ata3: FAILURE - zero length DMA transfer attempted Nov 3 14:18:17 video kernel: ata3: setting up DMA failed Nov 3 14:18:17 video kernel: ata3: FAILURE - zero length DMA transfer attempted Nov 3 14:18:49 video kernel: ata3: FAILURE - zero length DMA transfer attempted Nov 3 14:18:49 video kernel: ata3: setting up DMA failed Nov 3 14:18:49 video kernel: ata3: FAILURE - zero length DMA transfer attempted Nov 3 14:18:49 video kernel: ata3: setting up DMA failed I went back to FreeBSD 9-STABLE and had no further errors. This computer uses a Plextor SSD and works well on the FreeBSD 9 branch. This SSD has TRIM enabled and was setup like the Warren Block SSD Guide. It has partitions for root, var, usr and has a swapfile and tmpfs. Trim was enabled on the 3 disk partitions during the newfs operation. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 16:48: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 4056723D for ; Tue, 4 Nov 2014 16:48:19 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 1499ACCA for ; Tue, 4 Nov 2014 16:48:19 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so14740783pab.18 for ; Tue, 04 Nov 2014 08:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2eN9aOeQFENjceV4yXXJ92G64DdOScCS/kAjaNtz4PI=; b=zuKbw11dIuHOQTWwUQ7ugzNAeFreEEEYc7/95Rz65DKar6+Y07zB/sYp3GJp+EAnUm 1x15BOXKAmZBv4liDdLJCW3OMG38eLAB6PLzYK3KuypyJOLbU53XXB8xUUCTYg8tc+YD 5JepYUaGzDBW+edTGSght7eHlfR1B5jJu/TysGhNZZEOWJQcNC7kR7yE6yuky7iq5Bzb bmts8KnU+LbRC3nqvEcKOpmfd20x5oY+Pd3+JM3vJFsFmvR97As77FDrKT0DdcYv8cgu Ku+xPByxw1eoeZ6zt4/smXN0Lt5mZ7adn+TvmL8tqP/SDr7tQsibWuqF8DkH1UM+os0F DuLg== X-Received: by 10.68.195.68 with SMTP id ic4mr51878915pbc.44.1415119698488; Tue, 04 Nov 2014 08:48:18 -0800 (PST) Received: from [10.0.1.8] (50-0-30-197.dsl.dynamic.fusionbroadband.com. [50.0.30.197]) by mx.google.com with ESMTPSA id yr3sm922666pac.1.2014.11.04.08.48.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 08:48:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: ARC size limit From: George Kola In-Reply-To: <54589722.3080803@multiplay.co.uk> Date: Tue, 4 Nov 2014 08:48:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> <54589722.3080803@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1990.1) 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: Tue, 04 Nov 2014 16:48:19 -0000 Thanks Steven. We are running 10.1rc3. Is the best way to get this patch = to just compile 10-stable kernel ? We are new to running FreeBSD and = hence the newbie question. Thanks, George > On Nov 4, 2014, at 1:06 AM, Steven Hartland = wrote: >=20 > You need https://svnweb.freebsd.org/base?view=3Drevision&revision=3D2728= 75 > On 04/11/2014 06:29, George Kola wrote: >> Hi All, >> This is my first post to freebsd-stable fresh of Meet BSD = California 2014. We are switching our entire production to FreeBSD. Our = storage servers have 256 GB of RAM , 4 TB of SSD and 40 TB of spinning = disks. We are running ZFS root and the SSD is configured as L2ARC. We = are running FreeBSD 10.1 RC3 >> I am finding that on all our machines, ARC is somehow limited = to < 64 GB of memory and we have a huge inactive memory (180 G). The = surprising thing is that ARC seems to have almost the same limit (< 64 = GB) on all of our storage boxes and ARC is not growing even though L2ARC = hit shows that there is advantage in growing ARC. >> Any help/pointers is appreciated. >> What I am trying to do is to tune ZFS for our workload. We are = hoping that we get a high hit rate. >> Thanks to Justin Gibbs and Allan Jude for initial pointers and = help. They suggested posting to the mailing list to get further help. >>=20 >> I have pasted top output and zfs-stats output below and yes = UMA is enabled. >>=20 >> Thanks, >> George >> =20 >>=20 >> top >> last pid: 27458; load averages: 3.30, 5.42, 5.34 = = up 6+09:59:30 05:38:49 >> 71 processes: 1 running, 70 sleeping >> CPU: 4.2% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.9% = idle >> Mem: 11G Active, 181G Inact, 52G Wired, 1368M Cache, 4266M Free >> ARC: 47G Total, 1555M MFU, 41G MRU, 35M Anon, 3984M Header, 709M = Other >> Swap: 64G Total, 2874M Used, 61G Free, 4% Inuse >>=20 >>=20 >>=20 >> sysctl vfs.zfs.zio.use_uma >> vfs.zfs.zio.use_uma: 1 >>=20 >>=20 >>=20 >>=20 >> zfs-mon -a output >>=20 >> ZFS real-time cache activity monitor >> Seconds elapsed: 62 >>=20 >> Cache hits and misses: >> 1s 10s 60s tot >> ARC hits: 124 126 103 101 >> ARC misses: 35 46 29 28 >> ARC demand data hits: 55 90 61 61 >> ARC demand data misses: 20 32 18 17 >> ARC demand metadata hits: 69 36 42 40 >> ARC demand metadata misses: 9 13 10 9 >> ARC prefetch data hits: 0 0 0 0 >> ARC prefetch data misses: 6 1 1 1 >> ARC prefetch metadata hits: 0 0 0 0 >> ARC prefetch metadata misses: 0 0 0 0 >> L2ARC hits: 16 28 14 14 >> L2ARC misses: 19 18 15 14 >> ZFETCH hits: 592 2842 2098 2047 >> ZFETCH misses: 308 1326 507 494 >>=20 >> Cache efficiency percentage: >> 10s 60s tot >> ARC: 73.26 78.03 78.29 >> ARC demand data: 73.77 77.22 78.21 >> ARC demand metadata: 73.47 80.77 81.63 >> ARC prefetch data: 0.00 0.00 0.00 >> ARC prefetch metadata: 0.00 0.00 0.00 >> L2ARC: 60.87 48.28 50.00 >> ZFETCH: 68.19 80.54 80.56 >>=20 >>=20 >>=20 >>=20 >> zfs-stats -a output >>=20 >> ZFS real-time cache activity monitor >> Seconds elapsed: 62 >>=20 >> Cache hits and misses: >> 1s 10s 60s tot >> ARC hits: 124 126 103 101 >> ARC misses: 35 46 29 28 >> ARC demand data hits: 55 90 61 61 >> ARC demand data misses: 20 32 18 17 >> ARC demand metadata hits: 69 36 42 40 >> ARC demand metadata misses: 9 13 10 9 >> ARC prefetch data hits: 0 0 0 0 >> ARC prefetch data misses: 6 1 1 1 >> ARC prefetch metadata hits: 0 0 0 0 >> ARC prefetch metadata misses: 0 0 0 0 >> L2ARC hits: 16 28 14 14 >> L2ARC misses: 19 18 15 14 >> ZFETCH hits: 592 2842 2098 2047 >> ZFETCH misses: 308 1326 507 494 >>=20 >> Cache efficiency percentage: >> 10s 60s tot >> ARC: 73.26 78.03 78.29 >> ARC demand data: 73.77 77.22 78.21 >> ARC demand metadata: 73.47 80.77 81.63 >> ARC prefetch data: 0.00 0.00 0.00 >> ARC prefetch metadata: 0.00 0.00 0.00 >> L2ARC: 60.87 48.28 50.00 >> ZFETCH: 68.19 80.54 80.56 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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" >=20 > _______________________________________________ > 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 Tue Nov 4 16:53:40 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 C7783513 for ; Tue, 4 Nov 2014 16:53:40 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (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 9921CD87 for ; Tue, 4 Nov 2014 16:53:40 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id y13so13995323pdi.20 for ; Tue, 04 Nov 2014 08:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9ikyDh86KZYAbcNkOfa+F6Qr4o4o503baFI8GIzU7rs=; b=ESoN0ud3FIn7Hwb8l0pzApv3gfEAeEP2GXW6qmaBgbttzSXtKcuhEM7Ke/Bhky1Xwf NAtdXubtsJiYD/3SjYFHBzhG4ZrrVeFcxN19hgLsMUVClLio/WO44PiRZU+/Rvbcb8jl YPI4RxCIwckEMS5VdoPoHlo5rIxqFv26qvWeavUm+esNUah4QDr8+856O5k5elDoyFC0 KX3FXkAHelA5QEVkBg49Y8cyB3rO/i1T3RDoI9Z0bTbztfNE9bG59DeyCT5DDF7OuiaK YpDFSt7DOfWgQrDfrUPqrTyXv9nTuytCZRnEsfAUoBa4nidarcY6QlBHUM+Ddn+E6pTA LPmw== X-Received: by 10.68.239.71 with SMTP id vq7mr2834903pbc.155.1415120020033; Tue, 04 Nov 2014 08:53:40 -0800 (PST) Received: from [10.0.1.8] (50-0-30-197.dsl.dynamic.fusionbroadband.com. [50.0.30.197]) by mx.google.com with ESMTPSA id ms3sm901742pdb.19.2014.11.04.08.53.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 08:53:38 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: ARC size limit From: George Kola In-Reply-To: Date: Tue, 4 Nov 2014 08:53:36 -0800 Message-Id: <387D6A6C-EE3E-47E7-B32C-F760C40B8635@gmail.com> References: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> To: Ronald Klop X-Mailer: Apple Mail (2.1990.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Tue, 04 Nov 2014 16:53:40 -0000 > On Nov 4, 2014, at 1:28 AM, Ronald Klop wrote: >=20 > On Tue, 04 Nov 2014 07:29:48 +0100, George Kola > wrote: >=20 >> Hi All, >> This is my first post to freebsd-stable fresh of Meet BSD = California 2014. We are switching our entire production to FreeBSD. Our = storage servers have 256 GB of RAM , 4 TB of SSD and 40 TB of spinning = disks. We are running ZFS root and the SSD is configured as L2ARC. We = are running FreeBSD 10.1 RC3 >> I am finding that on all our machines, ARC is somehow limited = to < 64 GB of memory and we have a huge inactive memory (180 G). The = surprising thing is that ARC seems to have almost the same limit (< 64 = GB) on all of our storage boxes and ARC is not growing even though L2ARC = hit shows that there is advantage in growing ARC. >> Any help/pointers is appreciated. >> What I am trying to do is to tune ZFS for our workload. We are = hoping that we get a high hit rate. >> Thanks to Justin Gibbs and Allan Jude for initial pointers and = help. They suggested posting to the mailing list to get further help. >>=20 >> I have pasted top output and zfs-stats output below and yes UMA = is enabled. >>=20 >> Thanks, >> George >=20 > What is actually your problem? Do you just want higher numbers of ARC = usage or is your system slower than expected? > And what is your usage of these 40TB. Are all 40TB accessed a lot or = is 64 GB of ARC equal to the working set of data. >=20 > Ronald. >=20 The problem is system is slower than expected. We bumped up = the RAM from 96 GB on current illumos based production systems to 256 GB = on the new FreeBSD based system and expected higher hit rate in ARC and = lower disk access. Our rough initial calculation estimated that our = working would be between 96 - 128 GB Thanks, -George =20 =20 >=20 >=20 >>=20 >>=20 >> top >> last pid: 27458; load averages: 3.30, 5.42, 5.34 = = up 6+09:59:30 05:38:49 >> 71 processes: 1 running, 70 sleeping >> CPU: 4.2% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.9% = idle >> Mem: 11G Active, 181G Inact, 52G Wired, 1368M Cache, 4266M Free >> ARC: 47G Total, 1555M MFU, 41G MRU, 35M Anon, 3984M Header, 709M = Other >> Swap: 64G Total, 2874M Used, 61G Free, 4% Inuse >>=20 >>=20 >>=20 >> sysctl vfs.zfs.zio.use_uma >> vfs.zfs.zio.use_uma: 1 >>=20 >>=20 >>=20 >>=20 >> zfs-mon -a output >>=20 >> ZFS real-time cache activity monitor >> Seconds elapsed: 62 >>=20 >> Cache hits and misses: >> 1s 10s 60s tot >> ARC hits: 124 126 103 101 >> ARC misses: 35 46 29 28 >> ARC demand data hits: 55 90 61 61 >> ARC demand data misses: 20 32 18 17 >> ARC demand metadata hits: 69 36 42 40 >> ARC demand metadata misses: 9 13 10 9 >> ARC prefetch data hits: 0 0 0 0 >> ARC prefetch data misses: 6 1 1 1 >> ARC prefetch metadata hits: 0 0 0 0 >> ARC prefetch metadata misses: 0 0 0 0 >> L2ARC hits: 16 28 14 14 >> L2ARC misses: 19 18 15 14 >> ZFETCH hits: 592 2842 2098 2047 >> ZFETCH misses: 308 1326 507 494 >>=20 >> Cache efficiency percentage: >> 10s 60s tot >> ARC: 73.26 78.03 78.29 >> ARC demand data: 73.77 77.22 78.21 >> ARC demand metadata: 73.47 80.77 81.63 >> ARC prefetch data: 0.00 0.00 0.00 >> ARC prefetch metadata: 0.00 0.00 0.00 >> L2ARC: 60.87 48.28 50.00 >> ZFETCH: 68.19 80.54 80.56 >>=20 >>=20 >>=20 >>=20 >> zfs-stats -a output >>=20 >> ZFS real-time cache activity monitor >> Seconds elapsed: 62 >>=20 >> Cache hits and misses: >> 1s 10s 60s tot >> ARC hits: 124 126 103 101 >> ARC misses: 35 46 29 28 >> ARC demand data hits: 55 90 61 61 >> ARC demand data misses: 20 32 18 17 >> ARC demand metadata hits: 69 36 42 40 >> ARC demand metadata misses: 9 13 10 9 >> ARC prefetch data hits: 0 0 0 0 >> ARC prefetch data misses: 6 1 1 1 >> ARC prefetch metadata hits: 0 0 0 0 >> ARC prefetch metadata misses: 0 0 0 0 >> L2ARC hits: 16 28 14 14 >> L2ARC misses: 19 18 15 14 >> ZFETCH hits: 592 2842 2098 2047 >> ZFETCH misses: 308 1326 507 494 >>=20 >> Cache efficiency percentage: >> 10s 60s tot >> ARC: 73.26 78.03 78.29 >> ARC demand data: 73.77 77.22 78.21 >> ARC demand metadata: 73.47 80.77 81.63 >> ARC prefetch data: 0.00 0.00 0.00 >> ARC prefetch metadata: 0.00 0.00 0.00 >> L2ARC: 60.87 48.28 50.00 >> ZFETCH: 68.19 80.54 80.56 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 = " > _______________________________________________ > 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 Tue Nov 4 17:50: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 7CABBAB1 for ; Tue, 4 Nov 2014 17:50:28 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (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 F3AED3FD for ; Tue, 4 Nov 2014 17:50:26 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x13so14050320wgg.22 for ; Tue, 04 Nov 2014 09:50:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Q47jD5fcJiHLrcyxzN/FvBG6Ytj2QN63IBUuWMxCA8E=; b=GSFcgQDTuv3uEp0uXwSBf+NJDqXgc9PxEtKZ1gO7gU8qfw5wkVj9pLFiG9F8pGn6Wl y1Vs3m4A0/ZnyefkzZ3ffTXl0Ml4OB+0H+rmqgLb9kNyg+WCZ3rgKpOThIwKXzWqV7/y b/LP7GtF6ZfmYoEyDYBwiV0TCvlkP9WT9A3AcinJFvDB0xMKY7Z0TlNZ5CVu0p1+gGCp fcHlZ0Gw6LSzj5d51iPN/c5KQzG6tpAzQiB+mvBwD5jf5ht2tVEWeY+a+UJSR4V+UWSa eNdFRFUm840qCHjrBbOQC5q5M838lAPFV7qnlxw/RgDIVbnE7bCvaX3pqyXWczKB+wCO jfvg== X-Gm-Message-State: ALoCoQnAf/NFY/wNTwyKpQdHvrbBy1YT5zVfxycSOR5RoqUAgKLwjYyF78lxow2yPM0tW0fPuczh X-Received: by 10.194.206.36 with SMTP id ll4mr58443688wjc.21.1415123425067; Tue, 04 Nov 2014 09:50:25 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id mu4sm3213031wib.2.2014.11.04.09.50.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 09:50:24 -0800 (PST) Message-ID: <5459118B.7090904@multiplay.co.uk> Date: Tue, 04 Nov 2014 17:48:59 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: George Kola Subject: Re: ARC size limit References: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> <54589722.3080803@multiplay.co.uk> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040704030000030500010906" 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: Tue, 04 Nov 2014 17:50:28 -0000 This is a multi-part message in MIME format. --------------040704030000030500010906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Try the attached, its the patch we'll be using when we roll out 10.1. 1. Apply with: cd /usr/src && patch < zfs-arc-refactor.patch 2. Rebuild your kernel 3. Install the new kernel 4. Reboot Regards Steve On 04/11/2014 16:48, George Kola wrote: > Thanks Steven. We are running 10.1rc3. Is the best way to get this patch to just compile 10-stable kernel ? We are new to running FreeBSD and hence the newbie question. > > > Thanks, > George > > > >> On Nov 4, 2014, at 1:06 AM, Steven Hartland wrote: >> >> You need https://svnweb.freebsd.org/base?view=revision&revision=272875 >> On 04/11/2014 06:29, George Kola wrote: >>> Hi All, >>> This is my first post to freebsd-stable fresh of Meet BSD California 2014. We are switching our entire production to FreeBSD. Our storage servers have 256 GB of RAM , 4 TB of SSD and 40 TB of spinning disks. We are running ZFS root and the SSD is configured as L2ARC. We are running FreeBSD 10.1 RC3 >>> I am finding that on all our machines, ARC is somehow limited to < 64 GB of memory and we have a huge inactive memory (180 G). The surprising thing is that ARC seems to have almost the same limit (< 64 GB) on all of our storage boxes and ARC is not growing even though L2ARC hit shows that there is advantage in growing ARC. >>> Any help/pointers is appreciated. >>> What I am trying to do is to tune ZFS for our workload. We are hoping that we get a high hit rate. >>> Thanks to Justin Gibbs and Allan Jude for initial pointers and help. They suggested posting to the mailing list to get further help. >>> >>> I have pasted top output and zfs-stats output below and yes UMA is enabled. >>> >>> Thanks, >>> George >>> >>> >>> top >>> last pid: 27458; load averages: 3.30, 5.42, 5.34 up 6+09:59:30 05:38:49 >>> 71 processes: 1 running, 70 sleeping >>> CPU: 4.2% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.9% idle >>> Mem: 11G Active, 181G Inact, 52G Wired, 1368M Cache, 4266M Free >>> ARC: 47G Total, 1555M MFU, 41G MRU, 35M Anon, 3984M Header, 709M Other >>> Swap: 64G Total, 2874M Used, 61G Free, 4% Inuse >>> >>> >>> >>> sysctl vfs.zfs.zio.use_uma >>> vfs.zfs.zio.use_uma: 1 >>> >>> >>> >>> >>> zfs-mon -a output >>> >>> ZFS real-time cache activity monitor >>> Seconds elapsed: 62 >>> >>> Cache hits and misses: >>> 1s 10s 60s tot >>> ARC hits: 124 126 103 101 >>> ARC misses: 35 46 29 28 >>> ARC demand data hits: 55 90 61 61 >>> ARC demand data misses: 20 32 18 17 >>> ARC demand metadata hits: 69 36 42 40 >>> ARC demand metadata misses: 9 13 10 9 >>> ARC prefetch data hits: 0 0 0 0 >>> ARC prefetch data misses: 6 1 1 1 >>> ARC prefetch metadata hits: 0 0 0 0 >>> ARC prefetch metadata misses: 0 0 0 0 >>> L2ARC hits: 16 28 14 14 >>> L2ARC misses: 19 18 15 14 >>> ZFETCH hits: 592 2842 2098 2047 >>> ZFETCH misses: 308 1326 507 494 >>> >>> Cache efficiency percentage: >>> 10s 60s tot >>> ARC: 73.26 78.03 78.29 >>> ARC demand data: 73.77 77.22 78.21 >>> ARC demand metadata: 73.47 80.77 81.63 >>> ARC prefetch data: 0.00 0.00 0.00 >>> ARC prefetch metadata: 0.00 0.00 0.00 >>> L2ARC: 60.87 48.28 50.00 >>> ZFETCH: 68.19 80.54 80.56 >>> >>> >>> >>> >>> zfs-stats -a output >>> >>> ZFS real-time cache activity monitor >>> Seconds elapsed: 62 >>> >>> Cache hits and misses: >>> 1s 10s 60s tot >>> ARC hits: 124 126 103 101 >>> ARC misses: 35 46 29 28 >>> ARC demand data hits: 55 90 61 61 >>> ARC demand data misses: 20 32 18 17 >>> ARC demand metadata hits: 69 36 42 40 >>> ARC demand metadata misses: 9 13 10 9 >>> ARC prefetch data hits: 0 0 0 0 >>> ARC prefetch data misses: 6 1 1 1 >>> ARC prefetch metadata hits: 0 0 0 0 >>> ARC prefetch metadata misses: 0 0 0 0 >>> L2ARC hits: 16 28 14 14 >>> L2ARC misses: 19 18 15 14 >>> ZFETCH hits: 592 2842 2098 2047 >>> ZFETCH misses: 308 1326 507 494 >>> >>> Cache efficiency percentage: >>> 10s 60s tot >>> ARC: 73.26 78.03 78.29 >>> ARC demand data: 73.77 77.22 78.21 >>> ARC demand metadata: 73.47 80.77 81.63 >>> ARC prefetch data: 0.00 0.00 0.00 >>> ARC prefetch metadata: 0.00 0.00 0.00 >>> L2ARC: 60.87 48.28 50.00 >>> ZFETCH: 68.19 80.54 80.56 >>> >>> >>> >>> _______________________________________________ >>> 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" >> _______________________________________________ >> 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" --------------040704030000030500010906 Content-Type: text/plain; charset=windows-1252; name="zfs-arc-refactor.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfs-arc-refactor.patch" Index: sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c =================================================================== --- sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c (revision 274056) +++ sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c (working copy) @@ -133,13 +133,6 @@ kmem_size(void) return (kmem_size_val); } -uint64_t -kmem_used(void) -{ - - return (vmem_size(kmem_arena, VMEM_ALLOC)); -} - static int kmem_std_constructor(void *mem, int size __unused, void *private, int flags) { Index: sys/cddl/compat/opensolaris/sys/kmem.h =================================================================== --- sys/cddl/compat/opensolaris/sys/kmem.h (revision 274056) +++ sys/cddl/compat/opensolaris/sys/kmem.h (working copy) @@ -66,7 +66,6 @@ typedef struct kmem_cache { void *zfs_kmem_alloc(size_t size, int kmflags); void zfs_kmem_free(void *buf, size_t size); uint64_t kmem_size(void); -uint64_t kmem_used(void); kmem_cache_t *kmem_cache_create(char *name, size_t bufsize, size_t align, int (*constructor)(void *, void *, int), void (*destructor)(void *, void *), void (*reclaim)(void *) __unused, void *private, vmem_t *vmp, int cflags); @@ -78,6 +77,9 @@ void kmem_reap(void); int kmem_debugging(void); void *calloc(size_t n, size_t s); +#define freemem (cnt.v_free_count + cnt.v_cache_count) +#define minfree cnt.v_free_min +#define heap_arena kmem_arena #define kmem_alloc(size, kmflags) zfs_kmem_alloc((size), (kmflags)) #define kmem_zalloc(size, kmflags) zfs_kmem_alloc((size), (kmflags) | M_ZERO) #define kmem_free(buf, size) zfs_kmem_free((buf), (size)) Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (revision 274056) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (working copy) @@ -138,6 +138,7 @@ #include #include +#include #ifdef illumos #ifndef _KERNEL @@ -193,9 +194,6 @@ extern int zfs_prefetch_disable; */ static boolean_t arc_warm; -/* - * These tunables are for performance analysis. - */ uint64_t zfs_arc_max; uint64_t zfs_arc_min; uint64_t zfs_arc_meta_limit = 0; @@ -204,7 +202,20 @@ int zfs_arc_shrink_shift = 0; int zfs_arc_p_min_shift = 0; int zfs_disable_dup_eviction = 0; uint64_t zfs_arc_average_blocksize = 8 * 1024; /* 8KB */ +u_int zfs_arc_free_target = 0; +static int sysctl_vfs_zfs_arc_free_target(SYSCTL_HANDLER_ARGS); + +#ifdef _KERNEL +static void +arc_free_target_init(void *unused __unused) +{ + + zfs_arc_free_target = vm_pageout_wakeup_thresh; +} +SYSINIT(arc_free_target_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_ANY, + arc_free_target_init, NULL); + TUNABLE_QUAD("vfs.zfs.arc_max", &zfs_arc_max); TUNABLE_QUAD("vfs.zfs.arc_min", &zfs_arc_min); TUNABLE_QUAD("vfs.zfs.arc_meta_limit", &zfs_arc_meta_limit); @@ -217,7 +228,37 @@ SYSCTL_UQUAD(_vfs_zfs, OID_AUTO, arc_min, CTLFLAG_ SYSCTL_UQUAD(_vfs_zfs, OID_AUTO, arc_average_blocksize, CTLFLAG_RDTUN, &zfs_arc_average_blocksize, 0, "ARC average blocksize"); +/* + * We don't have a tunable for arc_free_target due to the dependency on + * pagedaemon initialisation. + */ +SYSCTL_PROC(_vfs_zfs, OID_AUTO, arc_free_target, + CTLTYPE_UINT | CTLFLAG_MPSAFE | CTLFLAG_RW, 0, sizeof(u_int), + sysctl_vfs_zfs_arc_free_target, "IU", + "Desired number of free pages below which ARC triggers reclaim"); +static int +sysctl_vfs_zfs_arc_free_target(SYSCTL_HANDLER_ARGS) +{ + u_int val; + int err; + + val = zfs_arc_free_target; + err = sysctl_handle_int(oidp, &val, 0, req); + if (err != 0 || req->newptr == NULL) + return (err); + + if (val < minfree) + return (EINVAL); + if (val > cnt.v_page_count) + return (EINVAL); + + zfs_arc_free_target = val; + + return (0); +} +#endif + /* * Note that buffers can be in one of 6 states: * ARC_anon - anonymous (discussed below) @@ -2421,9 +2462,12 @@ arc_flush(spa_t *spa) void arc_shrink(void) { + if (arc_c > arc_c_min) { uint64_t to_free; + DTRACE_PROBE4(arc__shrink, uint64_t, arc_c, uint64_t, + arc_c_min, uint64_t, arc_p, uint64_t, to_free); #ifdef _KERNEL to_free = arc_c >> arc_shrink_shift; #else @@ -2439,12 +2483,19 @@ arc_shrink(void) arc_c = MAX(arc_size, arc_c_min); if (arc_p > arc_c) arc_p = (arc_c >> 1); + + DTRACE_PROBE2(arc__shrunk, uint64_t, arc_c, uint64_t, + arc_p); + ASSERT(arc_c >= arc_c_min); ASSERT((int64_t)arc_p >= 0); } - if (arc_size > arc_c) + if (arc_size > arc_c) { + DTRACE_PROBE2(arc__shrink_adjust, uint64_t, arc_size, + uint64_t, arc_c); arc_adjust(); + } } static int needfree = 0; @@ -2455,15 +2506,20 @@ arc_reclaim_needed(void) #ifdef _KERNEL - if (needfree) + if (needfree) { + DTRACE_PROBE(arc__reclaim_needfree); return (1); + } /* * Cooperate with pagedaemon when it's time for it to scan * and reclaim some pages. */ - if (vm_paging_needed()) + if (freemem < zfs_arc_free_target) { + DTRACE_PROBE2(arc__reclaim_freemem, uint64_t, + freemem, uint64_t, zfs_arc_free_target); return (1); + } #ifdef sun /* @@ -2491,8 +2547,19 @@ arc_reclaim_needed(void) if (availrmem < swapfs_minfree + swapfs_reserve + extra) return (1); -#if defined(__i386) /* + * Check that we have enough availrmem that memory locking (e.g., via + * mlock(3C) or memcntl(2)) can still succeed. (pages_pp_maximum + * stores the number of pages that cannot be locked; when availrmem + * drops below pages_pp_maximum, page locking mechanisms such as + * page_pp_lock() will fail.) + */ + if (availrmem <= pages_pp_maximum) + return (1); + +#endif /* sun */ +#if defined(__i386) || !defined(UMA_MD_SMALL_ALLOC) + /* * If we're on an i386 platform, it's possible that we'll exhaust the * kernel heap space before we ever run out of available physical * memory. Most checks of the size of the heap_area compare against @@ -2503,19 +2570,35 @@ arc_reclaim_needed(void) * heap is allocated. (Or, in the calculation, if less than 1/4th is * free) */ - if (btop(vmem_size(heap_arena, VMEM_FREE)) < - (btop(vmem_size(heap_arena, VMEM_FREE | VMEM_ALLOC)) >> 2)) + if (vmem_size(heap_arena, VMEM_FREE) < + (vmem_size(heap_arena, VMEM_FREE | VMEM_ALLOC) >> 2)) { + DTRACE_PROBE2(arc__reclaim_used, uint64_t, + vmem_size(heap_arena, VMEM_FREE), uint64_t, + (vmem_size(heap_arena, VMEM_FREE | VMEM_ALLOC)) >> 2); return (1); + } #endif -#else /* !sun */ - if (kmem_used() > (kmem_size() * 3) / 4) +#ifdef sun + /* + * If zio data pages are being allocated out of a separate heap segment, + * then enforce that the size of available vmem for this arena remains + * above about 1/16th free. + * + * Note: The 1/16th arena free requirement was put in place + * to aggressively evict memory from the arc in order to avoid + * memory fragmentation issues. + */ + if (zio_arena != NULL && + vmem_size(zio_arena, VMEM_FREE) < + (vmem_size(zio_arena, VMEM_ALLOC) >> 4)) return (1); #endif /* sun */ - -#else +#else /* _KERNEL */ if (spa_get_random(100) == 0) return (1); -#endif +#endif /* _KERNEL */ + DTRACE_PROBE(arc__reclaim_no); + return (0); } @@ -2522,7 +2605,7 @@ arc_reclaim_needed(void) extern kmem_cache_t *zio_buf_cache[]; extern kmem_cache_t *zio_data_buf_cache[]; -static void +static void __noinline arc_kmem_reap_now(arc_reclaim_strategy_t strat) { size_t i; @@ -2529,6 +2612,7 @@ arc_kmem_reap_now(arc_reclaim_strategy_t strat) kmem_cache_t *prev_cache = NULL; kmem_cache_t *prev_data_cache = NULL; + DTRACE_PROBE(arc__kmem_reap_start); #ifdef _KERNEL if (arc_meta_used >= arc_meta_limit) { /* @@ -2564,6 +2648,16 @@ arc_kmem_reap_now(arc_reclaim_strategy_t strat) } kmem_cache_reap_now(buf_cache); kmem_cache_reap_now(hdr_cache); + +#ifdef sun + /* + * Ask the vmem arena to reclaim unused memory from its + * quantum caches. + */ + if (zio_arena != NULL && strat == ARC_RECLAIM_AGGR) + vmem_qcache_reap(zio_arena); +#endif + DTRACE_PROBE(arc__kmem_reap_end); } static void @@ -2581,6 +2675,7 @@ arc_reclaim_thread(void *dummy __unused) if (arc_no_grow) { if (last_reclaim == ARC_RECLAIM_CONS) { + DTRACE_PROBE(arc__reclaim_aggr_no_grow); last_reclaim = ARC_RECLAIM_AGGR; } else { last_reclaim = ARC_RECLAIM_CONS; @@ -2588,6 +2683,7 @@ arc_reclaim_thread(void *dummy __unused) } else { arc_no_grow = TRUE; last_reclaim = ARC_RECLAIM_AGGR; + DTRACE_PROBE(arc__reclaim_aggr); membar_producer(); } @@ -2692,6 +2788,7 @@ arc_adapt(int bytes, arc_state_t *state) * cache size, increment the target cache size */ if (arc_size > arc_c - (2ULL << SPA_MAXBLOCKSHIFT)) { + DTRACE_PROBE1(arc__inc_adapt, int, bytes); atomic_add_64(&arc_c, (int64_t)bytes); if (arc_c > arc_c_max) arc_c = arc_c_max; @@ -2713,20 +2810,6 @@ arc_evict_needed(arc_buf_contents_t type) if (type == ARC_BUFC_METADATA && arc_meta_used >= arc_meta_limit) return (1); -#ifdef sun -#ifdef _KERNEL - /* - * If zio data pages are being allocated out of a separate heap segment, - * then enforce that the size of available vmem for this area remains - * above about 1/32nd free. - */ - if (type == ARC_BUFC_DATA && zio_arena != NULL && - vmem_size(zio_arena, VMEM_FREE) < - (vmem_size(zio_arena, VMEM_ALLOC) >> 5)) - return (1); -#endif -#endif /* sun */ - if (arc_reclaim_needed()) return (1); @@ -3885,20 +3968,16 @@ static int arc_memory_throttle(uint64_t reserve, uint64_t txg) { #ifdef _KERNEL - uint64_t available_memory = - ptoa((uintmax_t)cnt.v_free_count + cnt.v_cache_count); + uint64_t available_memory = ptob(freemem); static uint64_t page_load = 0; static uint64_t last_txg = 0; -#ifdef sun -#if defined(__i386) +#if defined(__i386) || !defined(UMA_MD_SMALL_ALLOC) available_memory = - MIN(available_memory, vmem_size(heap_arena, VMEM_FREE)); + MIN(available_memory, ptob(vmem_size(heap_arena, VMEM_FREE))); #endif -#endif /* sun */ - if (cnt.v_free_count + cnt.v_cache_count > - (uint64_t)physmem * arc_lotsfree_percent / 100) + if (freemem > (uint64_t)physmem * arc_lotsfree_percent / 100) return (0); if (txg > last_txg) { @@ -3911,7 +3990,7 @@ arc_memory_throttle(uint64_t reserve, uint64_t txg * continue to let page writes occur as quickly as possible. */ if (curproc == pageproc) { - if (page_load > available_memory / 4) + if (page_load > MAX(ptob(minfree), available_memory) / 4) return (SET_ERROR(ERESTART)); /* Note: reserve is inflated, so we deflate */ page_load += reserve / 8; @@ -3939,8 +4018,10 @@ arc_tempreserve_space(uint64_t reserve, uint64_t t int error; uint64_t anon_size; - if (reserve > arc_c/4 && !arc_no_grow) + if (reserve > arc_c/4 && !arc_no_grow) { arc_c = MIN(arc_c_max, reserve * 4); + DTRACE_PROBE1(arc__set_reserve, uint64_t, arc_c); + } if (reserve > arc_c) return (SET_ERROR(ENOMEM)); @@ -3994,6 +4075,7 @@ arc_lowmem(void *arg __unused, int howto __unused) mutex_enter(&arc_lowmem_lock); mutex_enter(&arc_reclaim_thr_lock); needfree = 1; + DTRACE_PROBE(arc__needfree); cv_signal(&arc_reclaim_thr_cv); /* Index: sys/vm/vm_pageout.c =================================================================== --- sys/vm/vm_pageout.c (revision 274056) +++ sys/vm/vm_pageout.c (working copy) @@ -76,6 +76,7 @@ __FBSDID("$FreeBSD$"); #include "opt_vm.h" +#include "opt_kdtrace.h" #include #include #include @@ -89,6 +90,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -115,10 +117,14 @@ __FBSDID("$FreeBSD$"); /* the kernel process "vm_pageout"*/ static void vm_pageout(void); +static void vm_pageout_init(void); static int vm_pageout_clean(vm_page_t); static void vm_pageout_scan(struct vm_domain *vmd, int pass); static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass); +SYSINIT(pagedaemon_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, vm_pageout_init, + NULL); + struct proc *pageproc; static struct kproc_desc page_kp = { @@ -126,9 +132,13 @@ static struct kproc_desc page_kp = { vm_pageout, &pageproc }; -SYSINIT(pagedaemon, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, kproc_start, +SYSINIT(pagedaemon, SI_SUB_KTHREAD_PAGE, SI_ORDER_SECOND, kproc_start, &page_kp); +SDT_PROVIDER_DEFINE(vm); +SDT_PROBE_DEFINE(vm, , , vm__lowmem_cache); +SDT_PROBE_DEFINE(vm, , , vm__lowmem_scan); + #if !defined(NO_SWAPPING) /* the kernel process "vm_daemon"*/ static void vm_daemon(void); @@ -663,6 +673,7 @@ vm_pageout_grow_cache(int tries, vm_paddr_t low, v * may acquire locks and/or sleep, so they can only be invoked * when "tries" is greater than zero. */ + SDT_PROBE0(vm, , , vm__lowmem_cache); EVENTHANDLER_INVOKE(vm_lowmem, 0); /* @@ -925,6 +936,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) /* * Decrease registered cache sizes. */ + SDT_PROBE0(vm, , , vm__lowmem_scan); EVENTHANDLER_INVOKE(vm_lowmem, 0); /* * We do this explicitly after the caches have been @@ -1650,15 +1662,11 @@ vm_pageout_worker(void *arg) } /* - * vm_pageout is the high level pageout daemon. + * vm_pageout_init initialises basic pageout daemon settings. */ static void -vm_pageout(void) +vm_pageout_init(void) { -#if MAXMEMDOM > 1 - int error, i; -#endif - /* * Initialize some paging parameters. */ @@ -1704,7 +1712,18 @@ static void /* XXX does not really belong here */ if (vm_page_max_wired == 0) vm_page_max_wired = cnt.v_free_count / 3; +} +/* + * vm_pageout is the high level pageout daemon. + */ +static void +vm_pageout(void) +{ +#if MAXMEMDOM > 1 + int error, i; +#endif + swap_pager_swap_init(); #if MAXMEMDOM > 1 for (i = 1; i < vm_ndomains; i++) { Index: . =================================================================== --- . (revision 274056) +++ . (working copy) Property changes on: . ___________________________________________________________________ Modified: svn:mergeinfo Merged /head:r270759,270861,272483 Merged /stable/10:r272875 --------------040704030000030500010906-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 4 18:51:21 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 566821D2 for ; Tue, 4 Nov 2014 18:51:21 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (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 15A84CC9 for ; Tue, 4 Nov 2014 18:51:21 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id rp18so8128135iec.37 for ; Tue, 04 Nov 2014 10:51:20 -0800 (PST) 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=5xQ6J4LFon20gmW0ud9ezVjCBzNJBBh0x1S2uv/J124=; b=dcRCjWikaOMEooUuRJ6M2IoNuBNbbpzaxZ4kK6IPVN9J7cM+l2xkpBFUKVodtrGcgM JTr+8pHeDcMIYs35IJlLQpUT7Db6qRwcXNOTX61ncea+7nuvVf+ZYaC+wYqM+iziY9BX gTh258ug3Dwtp4YgJv0vj7JOSQI/z+BFG42D2ZnziWZMnPQfZCwpzfSp6JBVrUZC1U1q NMbtmQOF5TcgTu/X8BlVb3kl/W3halpBZCJGFFaO06VVpQAyJzUwlYFh8gcw4CKq1KVA Egf0u4Tt5V/cj+bGk6IryUMFYYvU9zTevhz1NI0vWOBoD0zolI8BGzAN/izSHSSXWsbE gugg== MIME-Version: 1.0 X-Received: by 10.50.164.194 with SMTP id ys2mr25831925igb.35.1415127080452; Tue, 04 Nov 2014 10:51:20 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.11.152 with HTTP; Tue, 4 Nov 2014 10:51:20 -0800 (PST) In-Reply-To: References: <7479DC25-4451-4940-AFE7-7C81D08206D4@csperkins.org> <64A14F51-E115-4929-8CE9-9F786A43C9A1@csperkins.org> Date: Tue, 4 Nov 2014 10:51:20 -0800 X-Google-Sender-Auth: hMvM7KyTz4YBzCuqZdcFGJssHsY Message-ID: Subject: Re: System hang on shutdown when running freebsd-update From: Kevin Oberman To: Colin Perkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Bjoern A. Zeeb" , 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, 04 Nov 2014 18:51:21 -0000 On Fri, Oct 17, 2014 at 10:23 AM, Kevin Oberman wrote: > On Fri, Oct 17, 2014 at 2:58 AM, Colin Perkins wrote: > >> On 16 Oct 2014, at 16:29, Bjoern A. Zeeb >> wrote: >> > On 15 Oct 2014, at 17:23 , Kevin Oberman wrote: >> > I have seen similar hangs on a ZFS-only system (even without >> freebsd-update I think). I have often not been patient enough to wait for >> the reboot to happen but I do remember that one time I walked away and came >> back and the system was still stuck, got distracted and by the time I got >> back again, it had rebooted. >> > >> > I wonder if anyone actually had been patient enough to wait an hour or >> two, just to see if the system moves forward all by itself? >> >> I gave up waiting after about an hour with my system that showed the >> problem. >> > > My server is production, so waiting is not an option, nor is using it for > testing. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > > I have now run several freebsd-update operations and have always done "shutdown now" to drop into single user, then waited about 30 seconds, issued a "sync", and then "reboot". In all cases including an upgrade from 10.0-RELEASE to 10.1-RC4 with no hangs. Really looking like something needs to flush before things are REALLY shutdown and does not have time before something is killed. Going to single user seems to allow it to finish up and all is well. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 02:31:50 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 9D217C07 for ; Wed, 5 Nov 2014 02:31:50 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 70C75C03 for ; Wed, 5 Nov 2014 02:31:50 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kq14so15603517pab.24 for ; Tue, 04 Nov 2014 18:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BJ4AydYoWBIuD4jewSaOaPUS+9tMsWjV8QRVot/6Vx8=; b=t2h/h1CYpy4e5Bqi2DdJIGUFiuoNjbwkpC8VczIcYnVZbqUh+UzPPaNWUW/1XwvHDY E+8UakxIJEyrIVtBehm8c6FN4Yvo9nBKPrT9zeWpidmnMIT9HPPAe362sghHjWX3VUNx 1g1h2ESLxNfFiKb3x05fbUV3duKkIMZg64KnG/imTZH9D57XfBzKN+rCeRWrMknccUbH GsT7SGs1gyblBOJld/6ttzYmsNMvgKdUQrYGk+SqMX6xMot2cTdca9dmSMuCongHDiSQ dTOg3bAuFVP/oBW5Tjy6Dwmw1/pKg9HhvsBqrIDWpNL3WPdEoBFkWzzyxfsZ+wBHH/tP aysg== X-Received: by 10.66.119.175 with SMTP id kv15mr2491388pab.30.1415154710021; Tue, 04 Nov 2014 18:31:50 -0800 (PST) Received: from [10.51.2.189] ([199.101.130.202]) by mx.google.com with ESMTPSA id je2sm1517727pbd.94.2014.11.04.18.31.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 18:31:48 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: ARC size limit From: George Kola In-Reply-To: <5459118B.7090904@multiplay.co.uk> Date: Tue, 4 Nov 2014 18:31:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <34588CE4-F44A-4D6D-BB38-28D55BE95D4C@gmail.com> References: <3B70EA0C-0976-49D6-8418-6B5D22ED7E65@gmail.com> <54589722.3080803@multiplay.co.uk> <5459118B.7090904@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1990.1) 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: Wed, 05 Nov 2014 02:31:50 -0000 Thanks for the patch Steven. We are now running it. Thanks, George > On Nov 4, 2014, at 9:48 AM, Steven Hartland = wrote: >=20 > Try the attached, its the patch we'll be using when we roll out 10.1. >=20 > 1. Apply with: cd /usr/src && patch < zfs-arc-refactor.patch > 2. Rebuild your kernel > 3. Install the new kernel > 4. Reboot >=20 > Regards > Steve > On 04/11/2014 16:48, George Kola wrote: >> Thanks Steven. We are running 10.1rc3. Is the best way to get this = patch to just compile 10-stable kernel ? We are new to running FreeBSD = and hence the newbie question. >>=20 >>=20 >> Thanks, >> George >>=20 >>=20 >>=20 >>> On Nov 4, 2014, at 1:06 AM, Steven Hartland = wrote: >>>=20 >>> You need = https://svnweb.freebsd.org/base?view=3Drevision&revision=3D272875 >>> On 04/11/2014 06:29, George Kola wrote: >>>> Hi All, >>>> This is my first post to freebsd-stable fresh of Meet BSD = California 2014. We are switching our entire production to FreeBSD. Our = storage servers have 256 GB of RAM , 4 TB of SSD and 40 TB of spinning = disks. We are running ZFS root and the SSD is configured as L2ARC. We = are running FreeBSD 10.1 RC3 >>>> I am finding that on all our machines, ARC is somehow = limited to < 64 GB of memory and we have a huge inactive memory (180 G). = The surprising thing is that ARC seems to have almost the same limit (< = 64 GB) on all of our storage boxes and ARC is not growing even though = L2ARC hit shows that there is advantage in growing ARC. >>>> Any help/pointers is appreciated. >>>> What I am trying to do is to tune ZFS for our workload. We = are hoping that we get a high hit rate. >>>> Thanks to Justin Gibbs and Allan Jude for initial pointers = and help. They suggested posting to the mailing list to get further = help. >>>>=20 >>>> I have pasted top output and zfs-stats output below and yes = UMA is enabled. >>>>=20 >>>> Thanks, >>>> George >>>> =20 >>>> top >>>> last pid: 27458; load averages: 3.30, 5.42, 5.34 = = up 6+09:59:30 05:38:49 >>>> 71 processes: 1 running, 70 sleeping >>>> CPU: 4.2% user, 0.0% nice, 4.6% system, 0.2% interrupt, 90.9% = idle >>>> Mem: 11G Active, 181G Inact, 52G Wired, 1368M Cache, 4266M Free >>>> ARC: 47G Total, 1555M MFU, 41G MRU, 35M Anon, 3984M Header, 709M = Other >>>> Swap: 64G Total, 2874M Used, 61G Free, 4% Inuse >>>>=20 >>>>=20 >>>>=20 >>>> sysctl vfs.zfs.zio.use_uma >>>> vfs.zfs.zio.use_uma: 1 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> zfs-mon -a output >>>>=20 >>>> ZFS real-time cache activity monitor >>>> Seconds elapsed: 62 >>>>=20 >>>> Cache hits and misses: >>>> 1s 10s 60s tot >>>> ARC hits: 124 126 103 101 >>>> ARC misses: 35 46 29 28 >>>> ARC demand data hits: 55 90 61 61 >>>> ARC demand data misses: 20 32 18 17 >>>> ARC demand metadata hits: 69 36 42 40 >>>> ARC demand metadata misses: 9 13 10 9 >>>> ARC prefetch data hits: 0 0 0 0 >>>> ARC prefetch data misses: 6 1 1 1 >>>> ARC prefetch metadata hits: 0 0 0 0 >>>> ARC prefetch metadata misses: 0 0 0 0 >>>> L2ARC hits: 16 28 14 14 >>>> L2ARC misses: 19 18 15 14 >>>> ZFETCH hits: 592 2842 2098 2047 >>>> ZFETCH misses: 308 1326 507 494 >>>>=20 >>>> Cache efficiency percentage: >>>> 10s 60s tot >>>> ARC: 73.26 78.03 78.29 >>>> ARC demand data: 73.77 77.22 78.21 >>>> ARC demand metadata: 73.47 80.77 81.63 >>>> ARC prefetch data: 0.00 0.00 0.00 >>>> ARC prefetch metadata: 0.00 0.00 0.00 >>>> L2ARC: 60.87 48.28 50.00 >>>> ZFETCH: 68.19 80.54 80.56 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> zfs-stats -a output >>>>=20 >>>> ZFS real-time cache activity monitor >>>> Seconds elapsed: 62 >>>>=20 >>>> Cache hits and misses: >>>> 1s 10s 60s tot >>>> ARC hits: 124 126 103 101 >>>> ARC misses: 35 46 29 28 >>>> ARC demand data hits: 55 90 61 61 >>>> ARC demand data misses: 20 32 18 17 >>>> ARC demand metadata hits: 69 36 42 40 >>>> ARC demand metadata misses: 9 13 10 9 >>>> ARC prefetch data hits: 0 0 0 0 >>>> ARC prefetch data misses: 6 1 1 1 >>>> ARC prefetch metadata hits: 0 0 0 0 >>>> ARC prefetch metadata misses: 0 0 0 0 >>>> L2ARC hits: 16 28 14 14 >>>> L2ARC misses: 19 18 15 14 >>>> ZFETCH hits: 592 2842 2098 2047 >>>> ZFETCH misses: 308 1326 507 494 >>>>=20 >>>> Cache efficiency percentage: >>>> 10s 60s tot >>>> ARC: 73.26 78.03 78.29 >>>> ARC demand data: 73.77 77.22 78.21 >>>> ARC demand metadata: 73.47 80.77 81.63 >>>> ARC prefetch data: 0.00 0.00 0.00 >>>> ARC prefetch metadata: 0.00 0.00 0.00 >>>> L2ARC: 60.87 48.28 50.00 >>>> ZFETCH: 68.19 80.54 80.56 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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" >>> _______________________________________________ >>> 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" >=20 > From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 02:34:31 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 C9039D15 for ; Wed, 5 Nov 2014 02:34:31 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 9EE11C35 for ; Wed, 5 Nov 2014 02:34:31 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kx10so15588890pab.6 for ; Tue, 04 Nov 2014 18:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=driCi5OP+QC8lf8oJvZHOJvFlqUFVBjRRwYoxc21TbM=; b=Abq/Ys93PtZybw7pFAmzrT+UxXIVMs6O/rZWSGxnC+meW1wPlN+FClHBQIRhLPL8e/ fyAvRC4UG/zl7eVkDCIw8afqsslxgdkshR8ZQA2Z4LeEK6fh+A7JMS/YyNjhJ32NFjUF mBGLTdHGhLV7XmV5MMo0Ol+uCGTFJT4LnRqGUUt0LoCgVTZLtpC0NQ0fNddWGrsHwlVe Bug3iwOKiXAHdDFu/2bvzIHRiIf8kanXtWXfg/Unvvd7nMGCqAfnu8WYQxTl3eKFhS90 THf/ipwC9vtINaAhleTilaEx7twJHHO/zSL/dYvky4YfvNtAnKKdUbLAti4IMLnTY1st /hWg== X-Received: by 10.68.213.8 with SMTP id no8mr30766590pbc.92.1415154871268; Tue, 04 Nov 2014 18:34:31 -0800 (PST) Received: from [10.51.2.189] ([199.101.130.202]) by mx.google.com with ESMTPSA id ub7sm1610983pbc.30.2014.11.04.18.34.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 18:34:30 -0800 (PST) From: George Kola Subject: Upgrade from 10.1RC3 to 10.1RC4 fails Message-Id: <143DE318-8A7B-4BEC-8B68-A66B7091C376@gmail.com> Date: Tue, 4 Nov 2014 18:34:28 -0800 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Wed, 05 Nov 2014 02:34:32 -0000 I am trying to upgrade a 10.1 RC3 box to 10.1RC4 and it fails as follows bsd01:~]$uname -r 10.1-RC3 [bsd01:~]$sudo freebsd-update upgrade -r 10.1-RC4 Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.1-RC3 from update5.freebsd.org... = done. Fetching metadata index... fetch: = http://update5.freebsd.org/10.1-RC3/amd64/t/c8fafcc79d7cc092c7782f4f1a29a7= 77d751294183c8f2cb9daf940ba0525d96: Not Found failed. Is there a work-around/fix for this ? Thanks, George From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 05:43:17 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 EF9A5A7D for ; Wed, 5 Nov 2014 05:43:16 +0000 (UTC) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.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 63CA779 for ; Wed, 5 Nov 2014 05:43:15 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id gq15so38682lab.15 for ; Tue, 04 Nov 2014 21:43:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=KIL3QoNcEB6eniCFIFeMVdbdAoiazMRhjuyZrCa2p9w=; b=aScuyXT3MfL5zDBuMAo5zDY5jR4ysIfmSiMU5yMH4ocV3rMkIdHrMvm/qcb6MK6npb 02EX780ZlQGvuqCVKkHNKxrz7UBv96yC65G8fGDfgUavHkmP7EuLk2MSeEjml5VDGd3B rqQEapciMvyPu3FdL1RnngPJs4yluyTXyo2EfWL/L97t/PhugrwBl57vzLwI9OPWAARK 3xiMDyfhRqZLjVYl/3Z99b/qtzV3DMf98VyLA9TQ4DFUFKAiYyy1iWv14mlUgPb+AU87 7A7fNs+vwMWGMrayvaQbltjv1a0HOjKnZPLlUh0PGv+iWv85j4Wi7C1YHrzOrR71jMou l6jA== X-Gm-Message-State: ALoCoQlfGLq+dRMPaP6z0rEfJ/WJnQ9I9m1hkwSCFTiJ1KsaDLzzwlSV5rcgOWX2+IVMxDJeR4di X-Received: by 10.152.234.227 with SMTP id uh3mr65099470lac.69.1415166188467; Tue, 04 Nov 2014 21:43:08 -0800 (PST) Received: from zealot.ksu.ru (zealot.hitv.ru. [83.151.8.230]) by mx.google.com with ESMTPSA id z4sm910086laz.39.2014.11.04.21.43.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 21:43:07 -0800 (PST) Message-ID: <5459B8E8.2000805@li.ru> Date: Wed, 05 Nov 2014 08:43:04 +0300 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Firefox/31.0 SeaMonkey/2.28 MIME-Version: 1.0 To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , freebsd-x11@freebsd.org, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: CFT: Update to xf86-video-ati 7.5.0 References: <544E0FC8.8090605@FreeBSD.org> In-Reply-To: <544E0FC8.8090605@FreeBSD.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030205050407050807010602" 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, 05 Nov 2014 05:43:17 -0000 This is a cryptographically signed message in MIME format. --------------ms030205050407050807010602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Jean-S=C3=A9bastien P=C3=A9dron wrote: > Hi! > > Before updating xf86-video-ati to 7.5.0, we would like some people to > try it out. The reason is that 7.4.0 was crashing for several users, so= > we want to be sure it's fixed in 7.5.0. > > Here's patch: > https://people.freebsd.org/~dumbbell/graphics/ports-xf86-video-ati-7.5.= 0.patch > > To apply it: > cd /usr/ports > patch -p1 < /path/to/ports-xf86-video-ati-7.5.0.patch > > Then update x11-drivers/xf86-video-ati with your method of choice. > > What we're especially looking for is report of successful or failed > startup of the X server. With 7.4.0, the server would crash during > startup. But with 7.5.0, none of us could reproduce the problem. > > When you're finished, you may restore your vanilla ports tree: > cd /usr/ports > patch -p1 -R < /path/to/ports-xf86-video-ati-7.5.0.patch > find x11-drivers/xf86-video-ati -name "*.orig" -delete > > Thank you for your help! > Strange problem. monitor doesn't wake up after all night sleep,=20 moreover, when I tried to connect my tv on hdmi I had 256 colors instead = of 16 million and no hardware acceleration at all. ports tree is as new=20 as yesterday. btw, Jean-Sebastien, xf86-video-ati-ums doesn't work at all, just blank=20 screen: [ 39.160] (II) AIGLX: Screen 0 is not DRI2 capable [ 39.160] drmOpenDevice: node name is /dev/dri/card0 [ 39.160] drmOpenDevice: open result is 12, (OK) [ 39.160] drmOpenByBusid: Searching for BusID pci:0000:01:00.0 [ 39.160] drmOpenDevice: node name is /dev/dri/card0 [ 39.161] drmOpenDevice: open result is 12, (OK) [ 39.161] drmOpenByBusid: drmOpenMinor returns 12 [ 39.161] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [ 39.161] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 [ 39.296] (EE) AIGLX error: r600 does not export required DRI extensio= n X.Org X Server 1.12.4 --=20 SY, Marat --------------ms030205050407050807010602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMaTCC Bi0wggUVoAMCAQICAwsAMzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDgyOTAwMTgzOVoXDTE1MDgzMDA1MTgxN1owTzEZMBcGA1UE DRMQOE9aclhtWFpRMzIwNEFuUzEVMBMGA1UEAwwMYW1hcmF0QGxpLnJ1MRswGQYJKoZIhvcN AQkBFgxhbWFyYXRAbGkucnUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3elxx SBZDrD0uhfNnw4YsVJ2PSjkAEzBye2Ng46BFsFwUmB0Ely0LJz3zAn2HwAN3uN4bHzZ1yvVO Q7exjoEfyFjadNq3UHMDw3z+LIhxQX4SNdT2H072yndfOLsyKuayOBHeM/CyxLkvsl9cIl7i 45dVhE1NEkEUr71xDyHETaULAwejcEIE281JH/LVRRtysA2hCC9mIfcu+l8swGONGcPr7Ywr l9YegN0RwZvGZl/EWyLMQQXfyU0gAYgT3Y7P+w2obeMeWpxXny+oEub4vYsx18meyKFgnz1G 336Z3J0a7mPBC/P4Qx4X63o6Orfvu2M38AhIKgibRuW7pBBvAgMBAAGjggLSMIICzjAJBgNV HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYD VR0OBBYEFOzBNZZDHLsTtz2ojwcM4rHQBZSeMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMBcGA1UdEQQQMA6BDGFtYXJhdEBsaS5ydTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGKPgpUPUgI65nQHxESjq9azfB4zS4Mz 1WP+l9/7VP4kiKBK9+lJmNwckKDD9gKvMxc75TZTFD1oNP9Q4izjBAKTx3EybLvjkW52kORJ go/3AUHE48patq/PQOJ4ti3nIMDqg/c6ikO4xKQcX+vGgszuSPjikQO9D/K+oGqtlhcE8CP6 M5qnVwIBwHWtk9ip/CH3dqu368CR5+zavJcd5N45LuDdEuaC0POX6znfUDmSo9Ydarzqunbf tS7T5RffXuMPA3VBsPQnbCXETlSBTZmUDrwqkLv6H6A2+v9keO1aDhnf1qlL7vEgjBF2BC59 8J7Qkmobp4FjebyGNEH0Ny8wggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKn u8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxah NvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//j diSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGt MIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYB BQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYI KwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBS MCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwEC ATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0G CSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY 1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7 Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQo CRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTi pgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQg WI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8 MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2N iy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhd GwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwsAMzAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMDUw NTQzMDRaMCMGCSqGSIb3DQEJBDEWBBTfde+sWHgQV+j2O43ksTGCtt6FWzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCwAzMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMLADMwDQYJKoZIhvcNAQEBBQAEggEAGiTSeR7A5VULB47PNsAqoispS+DGo8xcgGaKAR5B 7O/PsEu43q0zlAOSsFqeeeSy5kHaMr/mlnuFE2oJ28vebTP0FDNTfQ/SnEApY7HRSbiMApqL 5WTo5S3AfU8x26bJTcSXc/SjpI+30xjxx7TbSqGhobHvQrZ53en4bGj2sS9+PToRvu0XkBTi JvWYgOupW6W9VAv4fpaxqkw0my2P7XhkviVXLkFa78F3tEjumQe2VvEJWUTwLr7lhmK2xEYD Wn4cTSuHd/FQOycgMbbaCOzbihAj1Lh9N3SQxuwAyVA+1UGWLnn0GuXRm1HpRQG83lTF0D0B Po/itx8DvZkn5QAAAAAAAA== --------------ms030205050407050807010602-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 11:49:36 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 3039DF7E for ; Wed, 5 Nov 2014 11:49:36 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C8B8EBDA for ; Wed, 5 Nov 2014 11:49:35 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id sA5BnLxD007487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 5 Nov 2014 11:49:30 GMT (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk sA5BnLxD007487 Authentication-Results: smtp.infracaninophile.co.uk/sA5BnLxD007487; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <545A0EB4.4090404@freebsd.org> Date: Wed, 05 Nov 2014 11:49:08 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Varnish proxy goes catatonic under heavy load Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UfFkmOIO9brN0XPF6E1IRRTIJXEqhTMuH" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk 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, 05 Nov 2014 11:49:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UfFkmOIO9brN0XPF6E1IRRTIJXEqhTMuH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, We had an unfortunate set of circumstances which resulted in several million people all trying to download about 1.5MB worth of images from our servers over the course of a few hours. Or, at least, it would have been a few hours, except that our three varnish proxies just crumbled under the load within 10 minutes. Now, that's bad enough, but we could have just about coped if the proxies stopped serving requests for a few minutes. What actually happened was that all three servers went catatonic on the network *and stayed that way*: even when we shunted the traffic away from one, we still couldn't access it via ssh or any network protocol. And it stayed like that for sufficiently long time that we had no recourse other than to get the servers rebooted. Can anyone explain what was happening here? Not having the servers recover accessibility for an extended period even after the excess traffic was stopped is unacceptable. We're also struggling to recreate the effect in the lab: any clues about how to do so, and any suggestions about how to prevent the 'going catatonic' response would be greatly appreciated. Servers are amd64 running FreeBSD 9.1 or 9.2 and Varnish 3.0.5. Cheers, Matthew --UfFkmOIO9brN0XPF6E1IRRTIJXEqhTMuH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUWg7AXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnT6MP/iQ8borxlNTLRBbLouBz61FH YrBaK/EqaeTp3xSyx7QpVi4tGpfWgnliw27eXiifIX+GEFY5Pzige+uYtRdwdVHl L8iLDM/yx7mJVmqCv2d3BnU7T+RvPcN0BIsPRnIbbK6+dzxkJRELp4f2el1xHZFl ha3k1GxYHcpo3+4aRbJ4Q5J9BaM3uvhAY2kEbs/061L+1ov+J750t7qDALsNBUBR a7Wc79UndpRZhHQKErXlSZK/NiF4VwhuQfRaFISq1firiVPb5Rmhh+sVGj8kVNLo 2tTh/EnuHsazxi96KrJ2O2cnrv0fJy4ShQ3kuYvTeXV7KYIMIlG8PnyBpP/JkBJz VbQQIHBPg/VwMbCgOKTH7jiUqIcTjWUgKnnOlm3FBAID9WhGSSIRyWMvTg+Ft2bW FnlVFtdXrXpJTPC+M/4U72/oLDfAq5ZvPLkLGui5jMzmI43Jdu7eCqEB9WnjyjgB WIIRJW6vBuYKMoAYcdx42bh+qWQNB+QIcoQQ4RGsAfAr96RooZSUFU0VAS29qDKG 7DeTwc0bbWhAi0qlKCS8gDuxl13O/KMhnQyDJhVMM+tuns/vKDzuJmBzEtbszJOg pnVGKK+fBK1aWjkcuIlBmiI2kvUn7tDmA+9nSOQGYrbJAlC/UmQiWy7JuBVp5z4o L5Sr8OuhoYOYUW+A0Ryd =iwPP -----END PGP SIGNATURE----- --UfFkmOIO9brN0XPF6E1IRRTIJXEqhTMuH-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 12:02: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 77B44498 for ; Wed, 5 Nov 2014 12:02:32 +0000 (UTC) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 0DB21DA2 for ; Wed, 5 Nov 2014 12:02:31 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id h11so12162202wiw.15 for ; Wed, 05 Nov 2014 04:02:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZFpcK7GhXcB/6YDgyybSlv3r5lW3GC4OiLPbjqmOkHU=; b=WqEcptm6pP8HqmORiV+Jju1lDJdkq7XI2ZQj4Zxu/wkdp8sf+hrvDbJu9UVWmhq8NW bV3NTC8OqJafMAWGPyjqWAQzo4qqQ4QVocZYDj9BixaiJSnTlfa/f6+05kjp23Tc57eh 0pxQzG+aZVQhTyibiZxs1yv2T/7MNCPdIl6uiH+/7zX4YfBipuVi5nT15QGg8HHVBl6r p84eujTsBLJfJEmS5YBrzD1u0sX4pLENZ50xT8rgOzgucNJwMJE2KbT5iZBCmS316Pwt 5gcr59yDJJa1zk6ePDEw4ULFu8htNsWEoXT9RliB37/9RjWQg6ElxSJSMJwjMPbYqSLY /Lfg== X-Gm-Message-State: ALoCoQlumolzFcFTAAjyUurw9OJUvaVn6Cq475XA5kEdZnvi+Y9MU/SdcQWbXUVLszi2RZSlnMoF X-Received: by 10.194.236.200 with SMTP id uw8mr65661463wjc.50.1415188943890; Wed, 05 Nov 2014 04:02:23 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ht9sm15575513wib.8.2014.11.05.04.02.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 04:02:23 -0800 (PST) Message-ID: <545A117B.4080606@multiplay.co.uk> Date: Wed, 05 Nov 2014 12:00:59 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Matthew Seaman , freebsd-stable@freebsd.org Subject: Re: Varnish proxy goes catatonic under heavy load References: <545A0EB4.4090404@freebsd.org> In-Reply-To: <545A0EB4.4090404@freebsd.org> 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: Wed, 05 Nov 2014 12:02:32 -0000 As a guess you exhausted all mbufs, 10 has much better defaults for these so I'd recommend updating. If you can get in via IPMI or something similar you should be able to confirm. A trick I've used in the past to recover from such a issue is to hard bounce the nic ports on the switch which seemed to free enough to be able to ssh in. On 05/11/2014 11:49, Matthew Seaman wrote: > Dear all, > > We had an unfortunate set of circumstances which resulted in several > million people all trying to download about 1.5MB worth of images from > our servers over the course of a few hours. Or, at least, it would have > been a few hours, except that our three varnish proxies just crumbled > under the load within 10 minutes. > > Now, that's bad enough, but we could have just about coped if the > proxies stopped serving requests for a few minutes. What actually > happened was that all three servers went catatonic on the network *and > stayed that way*: even when we shunted the traffic away from one, we > still couldn't access it via ssh or any network protocol. And it stayed > like that for sufficiently long time that we had no recourse other than > to get the servers rebooted. > > Can anyone explain what was happening here? Not having the servers > recover accessibility for an extended period even after the excess > traffic was stopped is unacceptable. We're also struggling to recreate > the effect in the lab: any clues about how to do so, and any suggestions > about how to prevent the 'going catatonic' response would be greatly > appreciated. > > Servers are amd64 running FreeBSD 9.1 or 9.2 and Varnish 3.0.5. > > > Cheers, > > Matthew > > > From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 14:30: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 002C3F5E for ; Wed, 5 Nov 2014 14:30:39 +0000 (UTC) Received: from system.jails.se (unknown [IPv6:2001:16d8:cc1e:1::1]) (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 97D5E26C for ; Wed, 5 Nov 2014 14:30:39 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id 809F71B77C5 for ; Wed, 5 Nov 2014 15:30:35 +0100 (CET) Received: from nyx.uppmax.uu.se (nyx.uppmax.uu.se [130.238.137.40]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 878931B77C1 for ; Wed, 5 Nov 2014 15:30:34 +0100 (CET) Message-ID: <545A348A.4000908@pean.org> Date: Wed, 05 Nov 2014 15:30:34 +0100 From: =?UTF-8?B?UGV0ZXIgQW5rZXJzdMOlbA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: freebsd-udapte upgrade. Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050702050004030804020906" X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 5 15:30:35 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 545a348b64465990814513 X-DSPAM-Factors: 27, mail/freebsd+submit+cf+<<<<<<<, 0.40000, mail/freebsd+submit+cf+<<<<<<<, 0.40000, version+#+passwd+<<<<<<<+current, 0.40000, be+#+that+#+should, 0.40000, this+case+#+typed+q, 0.40000, submit+cf+#+current, 0.40000, submit+cf+#+current, 0.40000, "<<+#+crontab+<<<<<<<+current, 0.40000, current+#+mail/freebsd+cf, 0.40000, current+#+mail/freebsd+cf, 0.40000, <<<<<<<+#+version+mail/freebsd+submit, 0.40000, <<<<<<<+#+version+mail/freebsd+submit, 0.40000, right, 0.40000, explain+how+to+#+freebsd, 0.40000, of+the+files+has, 0.40000, current+#+group, 0.40000, <<<<<<<+#+#+ssh/sshd_config, 0.40000, <<<<<<<+#+#+ssh/sshd_config, 0.40000, Notice+#+a+#+of, 0.40000, mail/freebsd+submit+cf+<<<<<<<+current, 0.40000, mail/freebsd+submit+cf+<<<<<<<+current, 0.40000, and+look+for+%e2%80%9ccurrent, 0.40000, syslog+#+#+current, 0.40000, syslog+#+#+current, 0.40000, version+syslog+#+#+current, 0.40000, version+syslog+#+#+current, 0.40000, current+version+#+#+"<<, 0.40000 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, 05 Nov 2014 14:30:40 -0000 This is a cryptographically signed message in MIME format. --------------ms050702050004030804020906 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Could someone please explain how to use freebsd-update upgrade without=20 destroying all of your configuration files? I really don=E2=80=99t understand how to use the merge function.. In this= case i=20 typed :q for all files it asked about. :wq seem to do about the same thing. Notice that a few of the files has this shit in = multiple places. I can=E2=80=99t be right that I should edit every file m= anually=20 and look for =E2=80=9Ccurrent version=E2=80=9D and so on? # grep "<< current" * crontab:<<<<<<< current version dhclient.conf:<<<<<<< current version group:<<<<<<< current version hosts:<<<<<<< current version inetd.conf:<<<<<<< current version master.passwd:<<<<<<< current version motd:<<<<<<< current version ntp.conf:<<<<<<< current version passwd:<<<<<<< current version services:<<<<<<< current version shells:<<<<<<< current version snmpd.config:<<<<<<< current version syslog.conf:<<<<<<< current version syslog.conf:<<<<<<< current version ttys:<<<<<<< current version ttys:<<<<<<< current version # grep "<< current" */* mail/freebsd.cf:<<<<<<< current version mail/freebsd.cf:<<<<<<< current version mail/freebsd.cf:<<<<<<< current version mail/freebsd.submit.cf:<<<<<<< current version mail/freebsd.submit.cf:<<<<<<< current version mail/freebsd.submit.cf:<<<<<<< current version mail/sendmail.cf:<<<<<<< current version mail/sendmail.cf:<<<<<<< current version mail/sendmail.cf:<<<<<<< current version mail/submit.cf:<<<<<<< current version mail/submit.cf:<<<<<<< current version mail/submit.cf:<<<<<<< current version ssh/sshd_config:<<<<<<< current version ssh/sshd_config:<<<<<<< current version --------------ms050702050004030804020906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFHjCCBAagAwIBAgIRAMFvE3qCNYFbXz8lkfxnvZgwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw MTE3MDAwMDAwWhcNMTUwMTE3MjM1OTU5WjAfMR0wGwYJKoZIhvcNAQkBFg5wZXRlckBwZWFu Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtXJzxk2+Tt/OsnAPvgIK/M pmd1DFYdqWGl8+/y9YbJbRCDAsFC48xjvwMrO55WSg1j44h2NC7I1w7J/+Y4qYZEwC+P/0cb I2GQY4WzkB8Plpc0HrDpOS6SPKfIIgGuS+tAURMHcLHlDBivtrsWqYg+wJ6ypOcvMBikpFcT ASga4Rb3zMpnE8z198dwRnyDoOJKF9iGBVDZ93613CdC/Fp+H2qve2AA577abiO3xIlamMkb /3IM6MC976rcR7Pnf3sp2ompPGn7m7yhhkut5OxnC83LnrzUVEJM1f3J8mtAWQ0AL5hEPDln OTT6P1Opv6C8eDB9xYQ3zqz0v7PoNjMCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR7JyIkDGIYyCTbDgf48nC5UOPMRzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBkG A1UdEQQSMBCBDnBldGVyQHBlYW4ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQB0khzkZuMC8o9s 3xvoUbfr/4BcndibN6aDFbOIfwccWqIPMTOqmTakBjtc/N/bzYvFPlk2CmsjFbofuzuuVlKW G+bEjeq4xOsbjWKAmznV1Uw6DtyanWfs8YEU2sdKsHu657A5UZP8CCSpWxpnXAgFNdWszGSC jPw8uzcnKawBUbDHPT/ob/nAnNSYtGyLLqg5zb2qMbcerzHk4Gr1LZKApY122H0NguIPvQTi IF/+oeyhXl8KuBaPFU3kMr4UxIv9sX0KFp1iRjR6eOPAVTqC7TSttB1lhgRImKwU0tXNes1L XuWhgnB3Zr4atHizY+4kw9A0enFL8HNv2ampeTWEMYIEHDCCBBgCAQEwgakwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDBbxN6gjWBW18/JZH8Z72YMAkG BSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE0MTEwNTE0MzAzNFowIwYJKoZIhvcNAQkEMRYEFIQsw7+TPSF4oFgQtlVo/g/rHXVxMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIRAMFvE3qCNYFbXz8lkfxnvZgwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAwW8TeoI1gVtfPyWR/Ge9 mDANBgkqhkiG9w0BAQEFAASCAQCB4A9JtlP+v8acp16hb6h59kzfDUYg4iYufTT8c++4o+Fg OYdQNp3NCaIPxjFIKsq/8mmRhy+9jBFvU/uILe7WI4b78QWGKfCUqVgupnOSAMliz9nzuH7k gf64gNyhSR47BQM+YgckhzPTs2V2sb7icGLF1o1IHDy0Tp+5nD/SYyWuneE3wqTrBeZvZYZW KWHoXf3CPKB4nUnSQ2tG2d2ZclBxGB3IJAFW8pxvjj1pf4kweUis/ju2Rl/neji6v/FUbthw cIqf66xvIWXr22HJRplihge1Agf8hGo7+Ih5f4WQ0jlh2FwCizf3CZNw9njaX+59Kng6QMSs S7jeKDnHAAAAAAAA --------------ms050702050004030804020906-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 16:45:35 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 9179B2C5 for ; Wed, 5 Nov 2014 16:45:35 +0000 (UTC) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 06D9F785 for ; Wed, 5 Nov 2014 16:45:34 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id b6so1010599lbj.16 for ; Wed, 05 Nov 2014 08:45:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=bk2iQPD+FfPubrOFoXMYJHImxq1B/ECY/M/rBEE/lcA=; b=OOkqT9x3Dd5xW4V9TXUcYwKhZD4RmIpAK90siICNHdHNNGBJHWPuRbjNM6Jfb67egQ sVeq6PsUGWPL3ZNhrYF2NLnoUMbHLgbeULKFCZmY7a/tyO2kRZ7cyvWjbg5VCPiIY3Qh /MQhDTIIZDy6H1q79WlNoBGc/0szcOPpQIyr8Yah3nBzNqLqili5MTS0c3pGfofbfazU 5jYv5k9lgDzR0Weu73SII6mJlf/RW7QY3aYLYTSuPtQ74nlS7xh/01uFznbQ1fllVgbl zZ+iLqEhRj39rc8IpkhvWUAWgV8N+Lo2XWbKV0eM5Ltm4Jb9C8tFYtTHDF/iTQEPOQc9 /NGQ== X-Gm-Message-State: ALoCoQkR3M69SmILgeomJQPZOUUF2Dhj+o88ZSfQTjC5ndQ09EvPTNeNbPbRGD3J3DvzBGoSHbIO X-Received: by 10.152.8.100 with SMTP id q4mr67452052laa.48.1415205927252; Wed, 05 Nov 2014 08:45:27 -0800 (PST) Received: from zealot.ksu.ru (zealot.hitv.ru. [83.151.8.230]) by mx.google.com with ESMTPSA id q6sm1513541lag.12.2014.11.05.08.45.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 08:45:26 -0800 (PST) From: "Marat N.Afanasyev" X-Google-Original-From: "Marat N.Afanasyev" Message-ID: <545A5422.8000002@ksu.ru> Date: Wed, 05 Nov 2014 19:45:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Firefox/31.0 SeaMonkey/2.28 MIME-Version: 1.0 To: "Marat N.Afanasyev" , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqQ==?= =?UTF-8?B?ZHJvbg==?= , freebsd-x11@freebsd.org, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: CFT: Update to xf86-video-ati 7.5.0 References: <544E0FC8.8090605@FreeBSD.org> <5459B8E8.2000805@li.ru> In-Reply-To: <5459B8E8.2000805@li.ru> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080904070500090200050206" 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, 05 Nov 2014 16:45:35 -0000 This is a cryptographically signed message in MIME format. --------------ms080904070500090200050206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Marat N.Afanasyev wrote: > Jean-S=C3=A9bastien P=C3=A9dron wrote: >> Hi! >> >> Before updating xf86-video-ati to 7.5.0, we would like some people to >> try it out. The reason is that 7.4.0 was crashing for several users, s= o >> we want to be sure it's fixed in 7.5.0. >> >> Here's patch: >> https://people.freebsd.org/~dumbbell/graphics/ports-xf86-video-ati-7.5= =2E0.patch >> >> >> To apply it: >> cd /usr/ports >> patch -p1 < /path/to/ports-xf86-video-ati-7.5.0.patch >> >> Then update x11-drivers/xf86-video-ati with your method of choice. >> >> What we're especially looking for is report of successful or failed >> startup of the X server. With 7.4.0, the server would crash during >> startup. But with 7.5.0, none of us could reproduce the problem. >> >> When you're finished, you may restore your vanilla ports tree: >> cd /usr/ports >> patch -p1 -R < /path/to/ports-xf86-video-ati-7.5.0.patch >> find x11-drivers/xf86-video-ati -name "*.orig" -delete >> >> Thank you for your help! >> > > Strange problem. monitor doesn't wake up after all night sleep, > moreover, when I tried to connect my tv on hdmi I had 256 colors instea= d > of 16 million and no hardware acceleration at all. ports tree is as new= > as yesterday. > > btw, Jean-Sebastien, xf86-video-ati-ums doesn't work at all, just blank= > screen: > > [ 39.160] (II) AIGLX: Screen 0 is not DRI2 capable > [ 39.160] drmOpenDevice: node name is /dev/dri/card0 > [ 39.160] drmOpenDevice: open result is 12, (OK) > [ 39.160] drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > [ 39.160] drmOpenDevice: node name is /dev/dri/card0 > [ 39.161] drmOpenDevice: open result is 12, (OK) > [ 39.161] drmOpenByBusid: drmOpenMinor returns 12 > [ 39.161] drmOpenByBusid: Interface 1.4 failed, trying 1.1 > [ 39.161] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > [ 39.296] (EE) AIGLX error: r600 does not export required DRI extens= ion > > X.Org X Server 1.12.4 > 7.4.0 works fine yet, I'll try to wait for a night sleep and wakeup of=20 monitor --=20 SY, Marat --------------ms080904070500090200050206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMUTCC BhUwggT9oAMCAQICAwsANzANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDgyODE1NDYxM1oXDTE1MDgyOTIwNTgwNFowNjEWMBQGA1UE AwwNYW1hcmF0QGtzdS5ydTEcMBoGCSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6qVzpYpPJxcxcrrdFHsxZicFY2NfYqgI/hYVjc eZAl1el3J/tb/mBkyAGGTtr9uIjO4QweyodqjjCbxi92ahWgr0p5ONQNaadHsvbJ8A20LlOi ze5HIkX0RXpAZoc8kPKVjdt3cKlsWwirfipyP5RZHd6DdFMUWC0MTRqyRz9xPFcoXy6vWibk fxkPf7vniN2nUNLMZ1XIX8dN/f1f6qql3H7TDLqNKjAQa+yxSlJJr21UPCSt9Fyo90FsOl9O tNvsZr2QdqtPa2xy42IXzdMynzeUHjX5qkz7idh+x3EAWtRFdy0UKxCIsyN/yxjjhx7u946l ftlylVjo0blvj2sCAwEAAaOCAtMwggLPMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUHK9zcvRDk15RGgpRP5zofdCu bWEwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGAYDVR0RBBEwD4ENYW1hcmF0 QGtzdS5ydTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUF BwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB 6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0 aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5 IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1o dHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUH MAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNh LmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEL BQADggEBAAWb3Lh2zMPl/Wae1Z6Voj0VYQjY9fGUMrWdguo4woqmCD2bP7SHX0/reNykXqOn kPKRH1a5t6fSrS/A227l1mHqs8X9jboNGbbHfS7wQm7+Ii2MLy2Au7aWLlRDRgg5uadOWoCF dswjVeqEdtuIZTixQdgJwkBES9EGHGZt+uXDhSjdABLfflhWisfEI6IQtQGQryLX9UQ4+76M SzrfTRBHGRwuwThKim++krzuWrm8ga/TxYtV5XJZFG60ItAfW8yjNcL61P4Ha3lxqdtDgJcs vPoaAcF0xeMhzr38DQE+DOaDB2Bhs5sRBh5+6Ds9sp+xYLAJtHDCDdPcZvqIWoQwggY0MIIE HKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKD jKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3 ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYz oVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQ dcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN 2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgw FoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhto dHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKss Bly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI2 2zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbU FvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6 x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970M EeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zj dH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTp aprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRd J/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQg epbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMY u9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0ECAwsANzAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMDUxNjQ1MjJaMCMGCSqGSIb3DQEJBDEWBBSw vREb8PuMGti3lPuWqv1wVfnAKjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCwA3MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLADcwDQYJKoZIhvcNAQEBBQAEggEA qEbGzRsnbIwUQKvSvA6l+bue5X3yPg8BCbtIKlzZGkGIb3Sh18gvEZF8DlScdeLIq6p/dc5O Hy94WEwWIraKofilwJDx0qjuQKlCZqVfOIVeZ4AA2MaK31boff21DKuqV/GgXMpPb7En3ycJ 6Xi5C/HjGAFSJ7mVK8a0DO4sraanJYSKxOr3lRGWD2eEw/1K1gz04qQHp0/sBpjoyo2FJPKU nXv5hcYfeW6xTJ58Y2ex3OGRvnqNqYX//6mJlKbtNjFlXj5sb7OFmSrqHexkhBoyVykx5NTg 1i+wnVe3BJep3jmuAfxS7L42/FNbNEuu82SEPq2P5s34wbtN/XBpDwAAAAAAAA== --------------ms080904070500090200050206-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 18:23:35 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 91A7A2EF for ; Wed, 5 Nov 2014 18:23:35 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 5B524341 for ; Wed, 5 Nov 2014 18:23:35 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xm5Ex-000MAj-LD for stable@freebsd.org; Wed, 05 Nov 2014 18:23:32 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xm5Ex-0008RQ-Jm for stable@freebsd.org; Wed, 05 Nov 2014 18:23:31 +0000 To: stable@freebsd.org Subject: Advice on an odd networking problem Message-Id: From: Pete French Date: Wed, 05 Nov 2014 18:23:31 +0000 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, 05 Nov 2014 18:23:35 -0000 I have some ouzzling behaviour here - looks very much like I am running out of network resources of some kind, but I cant find out what, so am wondering if anyone has any ideas. All machines are running FreeBSD 9.2-STABLE r265427 - which is from the start of May (probbaly around heartbleed time!) We have 5 machines running webservers - apache24 serving cgi scripts, plyus nginx being used to drive uwsgi with some django/python based code. These are load balanced by pound on a machine which faces the internet. This all works as expected, except that if I modify the cgi-scripts running inside Apache so they make some https calls to the nginx server on 127.0.0.1 then what we see is that pound then stops being able to connect to Apache for a proportion of its calls - its returns 503's. The effect on the calls which fail are as if the webserver is not listening anymore. But this only applies to a fraction of the calls - most get through. If I disable the cuntionality which makes the intrenal call to 127.0.0.1 then the problem goes away. It looks to me like I am runing out of some network resource somwhow, but the load is very very low, and I cant see any obvious parameters hitting their limits. Nothing is looged out of the ordinary on the webservers, the only symptoom is the load balancer not being able to connect. Does anyone have any ideas where to look for a solution ? It is puzzling the hell out of me! -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 18:44: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 D77F37D6 for ; Wed, 5 Nov 2014 18:44:27 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 A44D478B for ; Wed, 5 Nov 2014 18:44:27 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id gq1so1062017obb.34 for ; Wed, 05 Nov 2014 10:44:26 -0800 (PST) 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=GHtIW+HxBUu6mzxlattDGTq4DDyMhFyRSmPrrGIQLZk=; b=wKUbCXmcicZcugcNZu9i34cxx8ZOaInRYUDeeGT7FLi+FtEG9sOxOInlzdv0UNxtY2 HXsS4CIFH0MSWZdlI7hWruFT8RT93NsuVcXEe7h2orGlz7Jjbo8Z+jnksDxcrrW++Kb7 8WFJcD3ayxbtC8vCZaRzbN2agcmh+9e7bg4sNqgZjIbe02N+C0Os9eZTBR82ei9ldbEW Hv/7+sgUGXeNeqnDpeuvGGwSDxVX28rBC8lFU9ZgVTeSQlDRDZ6PQ4DuMbQWpskuBTd0 eKtbbU04CgQqJAHyTMQx2d7v1GAZtYz/op8Pw5rx9G0BzOtMyNMktsrfWZETSBwuki3N fQVg== MIME-Version: 1.0 X-Received: by 10.202.97.198 with SMTP id v189mr24968700oib.55.1415213066809; Wed, 05 Nov 2014 10:44:26 -0800 (PST) Received: by 10.182.74.5 with HTTP; Wed, 5 Nov 2014 10:44:26 -0800 (PST) In-Reply-To: <143DE318-8A7B-4BEC-8B68-A66B7091C376@gmail.com> References: <143DE318-8A7B-4BEC-8B68-A66B7091C376@gmail.com> Date: Wed, 5 Nov 2014 22:44:26 +0400 Message-ID: Subject: Re: Upgrade from 10.1RC3 to 10.1RC4 fails From: Mikhail Tsatsenko To: George Kola Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org 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: Wed, 05 Nov 2014 18:44:27 -0000 Hi, Just faced the same issue. As far I can see http://update5.freebsd.org/10.1-RC3/amd64/t/ directory does not contain requested file, on other hand there is a file with another name. 2014-11-05 6:34 GMT+04:00 George Kola : > I am trying to upgrade a 10.1 RC3 box to 10.1RC4 and it fails as follows > > > bsd01:~]$uname -r > 10.1-RC3 > [bsd01:~]$sudo freebsd-update upgrade -r 10.1-RC4 > Looking up update.FreeBSD.org mirrors... 5 mirrors found. > Fetching metadata signature for 10.1-RC3 from update5.freebsd.org... done. > Fetching metadata index... fetch: http://update5.freebsd.org/10.1-RC3/amd64/t/c8fafcc79d7cc092c7782f4f1a29a777d751294183c8f2cb9daf940ba0525d96: Not Found > failed. > > > Is there a work-around/fix for this ? > > Thanks, > George > > _______________________________________________ > 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" -- Mikhail From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 18:53:09 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 075E398E for ; Wed, 5 Nov 2014 18:53:09 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (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 96381875 for ; Wed, 5 Nov 2014 18:53:08 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id b13so1658872wgh.12 for ; Wed, 05 Nov 2014 10:53:06 -0800 (PST) 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:content-transfer-encoding; bh=wdY74fOCkaDsxYnZ9KVFh7PZbHAizlTAXwlZr1phmTU=; b=Y3HmPSqiAY2ZXWLA+sX+drkqPYdOtMydVEG0Oqar63tuBitN1nPU6ZiKdLEMw/vUQM kir6BHC/KuKgtJ0sN8ZGvcvk4/Z4vyZwvBqxe+tDgc3gg+9BLojaIVP1kZMQYsHR7lYl QsIUnnBioU/Y5wUOCShkFuQo86EtL9C/cctoPxeqZOBwfUzJ9Rzh4q45q0BsV8reft8D ZXvQxp30uUelVzE4Rv5JHQjbTUpNqhFxB2YIuSLFWh4EOdHhs3jzj0nUmzvfpAfP41Uu ALm8PjpUR63lliwF+grlyKhg/5arAjJJrVgzPzQ6Wzy4Ef6T0P2SseP1TJQB/LkOh332 lSXQ== MIME-Version: 1.0 X-Received: by 10.180.188.41 with SMTP id fx9mr7884397wic.59.1415213586851; Wed, 05 Nov 2014 10:53:06 -0800 (PST) Received: by 10.27.46.14 with HTTP; Wed, 5 Nov 2014 10:53:06 -0800 (PST) In-Reply-To: <545A348A.4000908@pean.org> References: <545A348A.4000908@pean.org> Date: Wed, 5 Nov 2014 12:53:06 -0600 Message-ID: Subject: Re: freebsd-udapte upgrade. From: Scot Hetzel To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 05 Nov 2014 18:53:09 -0000 On Wed, Nov 5, 2014 at 8:30 AM, Peter Ankerst=E5l wrote: > Could someone please explain how to use freebsd-update upgrade without > destroying all of your configuration files? > > I really don't understand how to use the merge function.. In this case i > typed :q for all files it asked about. :wq seem to > do about the same thing. Notice that a few of the files has this shit in > multiple places. I can't be right that I should edit every file manually = and > look for "current version" and so on? > Most likely what happened is that when you used :wq it wrote the contents of the diff between your current version and the new version to your existing configuration files. If you had stuck to using :q, it should have left your existing configuration files alone. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 18:58: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 3505ABD7 for ; Wed, 5 Nov 2014 18:58:35 +0000 (UTC) Received: from system.jails.se (unknown [IPv6:2001:16d8:cc1e:1::1]) (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 C604C8C7 for ; Wed, 5 Nov 2014 18:58:34 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id B39261B5B67 for ; Wed, 5 Nov 2014 19:58:29 +0100 (CET) Received: from [10.28.15.177] (c-5eeaaa5b-74736162.cust.telenor.se [94.234.170.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id D10071B5B62; Wed, 5 Nov 2014 19:58:28 +0100 (CET) Content-Type: multipart/signed; boundary=Apple-Mail-90C9C476-989B-4838-892D-E86452C1FB3C; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) Subject: Re: freebsd-udapte upgrade. From: =?utf-8?Q?Peter_Ankerst=C3=A5l?= X-Mailer: iPhone Mail (12B411) In-Reply-To: Date: Wed, 5 Nov 2014 19:58:29 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <545A348A.4000908@pean.org> To: Scot Hetzel X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 5 19:58:29 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 545a735564468141515430 X-DSPAM-Factors: 27, manually+#+>>+look, 0.40000, current+#+and, 0.40000, it+#+#+#+contents, 0.40000, Scot+Hetzel+#+gmail+com>, 0.40000, Most+#+what+happened+is, 0.40000, only+I, 0.40000, wrote+#+#+On+Wed, 0.40000, Mime-Version*(1.0), 0.40000, AM+Peter, 0.40000, be+#+that+#+should, 0.40000, upgrade+#+>>, 0.40000, the+#+#+your+current, 0.40000, update+upgrade+#+>>, 0.40000, pean+org>+wrote+#+Could, 0.40000, right, 0.40000, 8+#+#+Peter+Ankerst%c3%a5l, 0.40000, >+>>+#+Wed+Nov, 0.40000, explain+how+to+#+freebsd, 0.40000, seem+to+#+#+about, 0.40000, had+#+to+#+q, 0.40000, of+the+files+has, 0.40000, >>+Could, 0.40000, it+#+have+left+your, 0.40000, can't+#+right+that, 0.40000, your+existing+configuration+#+If, 0.40000, stuck+#+#+#+>, 0.40000, Notice+#+a+#+of, 0.40000 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: Wed, 05 Nov 2014 18:58:35 -0000 --Apple-Mail-90C9C476-989B-4838-892D-E86452C1FB3C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 5 nov 2014, at 19:53, Scot Hetzel wrote: >=20 >> On Wed, Nov 5, 2014 at 8:30 AM, Peter Ankerst=C3=A5l wro= te: >> Could someone please explain how to use freebsd-update upgrade without >> destroying all of your configuration files? >>=20 >> I really don't understand how to use the merge function.. In this case i >> typed :q for all files it asked about. :wq seem to >> do about the same thing. Notice that a few of the files has this shit in >> multiple places. I can't be right that I should edit every file manually a= nd >> look for "current version" and so on? > Most likely what happened is that when you used :wq it wrote the > contents of the diff between your current version and the new version > to your existing configuration files. If you had stuck to using :q, > it should have left your existing configuration files alone. This was done with :q only. I dont get it.=20= --Apple-Mail-90C9C476-989B-4838-892D-E86452C1FB3C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGNzCCBjMw ggUboAMCAQICAwiyiDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE0MDEyMDA3NTIzOFoXDTE1MDEyMTA4NTkyMVowUzEZMBcGA1UEDRMQMWlGRkxHbTV3RmVT WjZ6OTEXMBUGA1UEAwwOcGV0ZXJAcGVhbi5vcmcxHTAbBgkqhkiG9w0BCQEWDnBldGVyQHBlYW4u b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzoKHiOE9vdQgax/GZyTaqtNvfjGI HwG1tsMOXZELs49KJY66oD//szW3yoIl8nQapUBn+hZqs3QT5PxqfElXxljYszYE6yk3kWR7EVtl IEfT7Pf24XlFw4uzoZzEjaxPJBt4+BWwb1MpqBmwTNZwZGYI9SO6JW23G9o+e+hPmlXFTovW9B36 J0M2Qu0+IE6MsDIG0y5CwuiXMqNz+vEBiIBvdef3CIidRn3/K7DQYBYn9gj/UNB1yf1GRhsNDO12 4T9+9bhlplov0srt7pqQjaSiiqVOCCWdpxvM/eF0LFBkEFATy45RKtl2vk9zM1wmI+sU29vodHoD Duf8t4bTtQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSAhVDjVwheLV39/7XFsz9rQP0sVDAfBgNVHSME GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5wZXRlckBwZWFuLm9yZzCCAUwG A1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFj Y29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3Rh cnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBp biBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5j bGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8w DQYJKoZIhvcNAQEFBQADggEBAFiVjpZEkQoHYAtb0E6MVJgzo1K6d6eEjLsCNbaw833a0jws4Rh0 KG/MjqjJzUwa2G6mVZb/JaodRK8VENnpxJ8WhjWqyQL8/lKnGa88XYMtl+i4ICur08IfQLG7zNFn yG/kOAiMNkgF4H6lZx/ezup9fowUOt0hxERXMcqo4p+RzPShx35EGRv+5gZNQ7XW4s2rzFzt9CHa Dar8SyAGHK3oFapKpHsVSUYik0QCLwnGcaHEHNUkCp1YMsjKwvmxVtQQs/2WfsqQlult8UYe0bTr nwDyLbgJDbvp9R5mZDrkUcXYlgP+mAmzTOrT1JhHbyYQjbbxJAmqkAIDcwVyDRAxggNvMIIDawIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIsogwCQYFKw4DAhoFAKCCAa8wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQxMTA1MTg1ODI5WjAjBgkq hkiG9w0BCQQxFgQUbmPIJs1tOgs6o8cDu97KBzVNvZMwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIsogwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwiyiDANBgkqhkiG9w0BAQEFAASCAQBpon0Y14AjfJss edjVc06PxMHyq/v0FrMqAiUc2xfv8iG5F+4BlBXwhLcYFsv3HnYGQv88gpBUdeEsyKWWr6LoNxvD 7qnLr5kkxs2QYUfnMxm1ptXkTwwGyLPDRcpUEcLU89T3u9niY7K1ARjHY9O+Xv6IAmc06SXJttk6 qXglR+yK7vn21gHvLc6NGMuGjIbpV3bg2zzH5mpgJFCB0x8JL10Pe/qag0oK+o9yUrOG4geVh+cQ QQ/q5cCwKLE7N60rz70fWfyrBatQHXyTjiTqEWxA/C9zZrP9Wnx7WfppeeEC5K4AemQaskh/+lYk /9yATz+WnHVukebH4mI/2aO0AAAAAAAA --Apple-Mail-90C9C476-989B-4838-892D-E86452C1FB3C-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 19:29:44 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 776174CA for ; Wed, 5 Nov 2014 19:29:44 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 45841BCE for ; Wed, 5 Nov 2014 19:29:44 +0000 (UTC) Received: from [172.31.120.59] (npc6520ffc.cns.vt.edu [198.82.15.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 288D4AC2; Wed, 5 Nov 2014 14:29:37 -0500 (EST) References: <545A348A.4000908@pean.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2B820BFF-8565-4A4D-B05E-3A66E8939A52@gromit.dlib.vt.edu> X-Mailer: iPad Mail (11D257) From: Paul Mather Subject: Re: freebsd-udapte upgrade. Date: Wed, 5 Nov 2014 14:29:36 -0500 To: =?utf-8?Q?Peter_Ankerst=C3=A5l?= Cc: Scot Hetzel , 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: Wed, 05 Nov 2014 19:29:44 -0000 > On Nov 5, 2014, at 1:58 PM, Peter Ankerst=C3=A5l wrote: >=20 >=20 >=20 >>> On 5 nov 2014, at 19:53, Scot Hetzel wrote: >>>=20 >>> On Wed, Nov 5, 2014 at 8:30 AM, Peter Ankerst=C3=A5l wr= ote: >>> Could someone please explain how to use freebsd-update upgrade without >>> destroying all of your configuration files? >>>=20 >>> I really don't understand how to use the merge function.. In this case i= >>> typed :q for all files it asked about. :wq seem to >>> do about the same thing. Notice that a few of the files has this shit in= >>> multiple places. I can't be right that I should edit every file manually= and >>> look for "current version" and so on? >> Most likely what happened is that when you used :wq it wrote the >> contents of the diff between your current version and the new version >> to your existing configuration files. If you had stuck to using :q, >> it should have left your existing configuration files alone. >=20 > This was done with :q only. I dont get it. When you upgrade using freebsd-update, it will try and update configuration f= iles automatically. If there are any configuration files whose differences c= an't be resolved automatically, it will present that file for editing with t= he merge conflicts in the file presented. You are then supposed to resolved= the conflicts manually. I've always resolved any conflicts, so I've not had any experience if you si= mply ":q" from the editor, thereby leaving in all the conflict markers. If f= reebsd-update doesn't check for unresolved conflicts and force you to edit t= he file again, I presume your configuration file will now basically be inval= id. Maybe this is what happened in your case? Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 21:34:05 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 7FB1E391; Wed, 5 Nov 2014 21:34:05 +0000 (UTC) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3EBE1B23; Wed, 5 Nov 2014 21:34:04 +0000 (UTC) Received: from filter.sfr.fr (localhost [93.8.4.165]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 69D9370000EB; Wed, 5 Nov 2014 22:25:49 +0100 (CET) Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=listjm@club-internet.fr Received: from [192.168.1.67] (165.4.8.93.rev.sfr.net [93.8.4.165]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 3B4F670000E9; Wed, 5 Nov 2014 22:25:49 +0100 (CET) X-SFR-UUID: 20141105212549243.3B4F670000E9@msfrf2208.sfr.fr Message-ID: <545A95DB.1060100@club-internet.fr> Date: Wed, 05 Nov 2014 22:25:47 +0100 From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor 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, freebsd-questions@freebsd.org Subject: Status of svnlite(1) in make.conf(5) Content-Type: text/plain; charset=ISO-8859-1; 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: Wed, 05 Nov 2014 21:34:05 -0000 Hi! Just curious about what it seems an inconsistency with svnlite(1). The initial commit (r251886) says that it was included for checking out and committing source and cites two make.conf(5) knobs: WITH_SVN (to get "svn" instead of "svnlite") and WITHOUT_SVNLITE (in reality, they are in src.conf(5)). Nevertheless, the make.conf man page says, in the SVN_UPDATE section, that no subversion client is included in the base system, and indeed 'make update' does not work by default. Should I open a PR or it is too much nitpicking? Best regards, Juan From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 21:54:44 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 1C1CE894; Wed, 5 Nov 2014 21:54:44 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 C732AD22; Wed, 5 Nov 2014 21:54:43 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sA5LuYKa003546; Wed, 5 Nov 2014 13:56:35 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, "Juan =?UTF-8?B?UmFtw7Nu?= Molina Menor" In-Reply-To: <545A95DB.1060100@club-internet.fr> References: <545A95DB.1060100@club-internet.fr> From: "Chris H" Subject: Re: Status of svnlite(1) in make.conf(5) Date: Wed, 05 Nov 2014 13:56:35 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <82353c164271e8ec77453393ddfa41b2@ultimatedns.net> Content-Transfer-Encoding: 8bit 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, 05 Nov 2014 21:54:44 -0000 On Wed, 05 Nov 2014 22:25:47 +0100 Juan Ramón Molina Menor wrote > Hi! > > Just curious about what it seems an inconsistency with svnlite(1). The > initial commit (r251886) says that it was included for checking out and > committing source and cites two make.conf(5) knobs: WITH_SVN (to get > "svn" instead of "svnlite") and WITHOUT_SVNLITE (in reality, they are in > src.conf(5)). Nevertheless, the make.conf man page says, in the > SVN_UPDATE section, that no subversion client is included in the base > system, and indeed 'make update' does not work by default. > > Should I open a PR or it is too much nitpicking? I think it would be a good idea. I can say for sure that svnlite(1) comes on, and is installed from the bootonly CD/DVD. I think it's also worth mentioning that the entries are actually targeted to the src.conf(5). You may also want to CC docs@. As I think Warren Block might also be interested. --Chris > > Best regards, > Juan > _______________________________________________ > 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 Wed Nov 5 22:09:13 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 280E9C23; Wed, 5 Nov 2014 22:09:13 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C1FE0E73; Wed, 5 Nov 2014 22:09:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sA5M90Qk077086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Nov 2014 15:09:01 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sA5M90U3077083; Wed, 5 Nov 2014 15:09:00 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 5 Nov 2014 15:09:00 -0700 (MST) From: Warren Block To: Chris H Subject: Re: Status of svnlite(1) in make.conf(5) In-Reply-To: <82353c164271e8ec77453393ddfa41b2@ultimatedns.net> Message-ID: References: <545A95DB.1060100@club-internet.fr> <82353c164271e8ec77453393ddfa41b2@ultimatedns.net> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 05 Nov 2014 15:09:01 -0700 (MST) Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, =?ISO-8859-15?Q?Juan_Ram=F3n_Molina_Menor?= 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, 05 Nov 2014 22:09:13 -0000 On Wed, 5 Nov 2014, Chris H wrote: > On Wed, 05 Nov 2014 22:25:47 +0100 Juan Ramón Molina Menor > wrote > >> Hi! >> >> Just curious about what it seems an inconsistency with svnlite(1). The >> initial commit (r251886) says that it was included for checking out and >> committing source and cites two make.conf(5) knobs: WITH_SVN (to get >> "svn" instead of "svnlite") and WITHOUT_SVNLITE (in reality, they are in >> src.conf(5)). Nevertheless, the make.conf man page says, in the >> SVN_UPDATE section, that no subversion client is included in the base >> system, and indeed 'make update' does not work by default. >> >> Should I open a PR or it is too much nitpicking? > I think it would be a good idea. I can say for sure that > svnlite(1) comes on, and is installed from the bootonly CD/DVD. > I think it's also worth mentioning that the entries are actually > targeted to the src.conf(5). > You may also want to CC docs@. As I think Warren Block might also > be interested. It's just "doc@", but I'm here also. And agreed, if the information in a man page is not correct, it needs to be fixed. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 22:41: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 7E012645 for ; Wed, 5 Nov 2014 22:41:02 +0000 (UTC) Received: from system.jails.se (system.jails.se [91.205.63.85]) (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 29D0A29A for ; Wed, 5 Nov 2014 22:41:00 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id 858BA1B9B68 for ; Wed, 5 Nov 2014 23:40:51 +0100 (CET) Received: from klein.pean.org (klein.pean.org [IPv6:2001:16d8:ff9f::60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 70F341B9B64; Wed, 5 Nov 2014 23:40:50 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_678FB9FF-7EFE-45B2-9668-EDFB8B0C2222"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: freebsd-udapte upgrade. From: =?utf-8?Q?Peter_Ankerst=C3=A5l?= In-Reply-To: <2B820BFF-8565-4A4D-B05E-3A66E8939A52@gromit.dlib.vt.edu> Date: Wed, 5 Nov 2014 23:40:42 +0100 Message-Id: <2DE7E247-63F1-4A3E-AE25-46E1207BB0A8@pean.org> References: <545A348A.4000908@pean.org> <2B820BFF-8565-4A4D-B05E-3A66E8939A52@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.1993) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 5 23:40:51 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 545aa77364467249211857 X-DSPAM-Factors: 27, freebsd+update+#+without+>>>>, 0.40000, Mime-Version*X+#+8.1, 0.40000, current+#+and, 0.40000, it+#+#+#+contents, 0.40000, Scot+Hetzel+#+gmail+com>, 0.40000, Most+#+what+happened+is, 0.40000, then+supposed+#+resolved+the, 0.40000, only+I, 0.40000, file+presented+You, 0.40000, in+>>>>+#+places+I, 0.40000, wrote+#+#+On+Wed, 0.40000, AM+Peter, 0.40000, so+#+not+had, 0.40000, presented, 0.40000, be+#+that+#+should, 0.40000, be+resolved+#+it, 0.40000, >>>>+#+someone+please, 0.40000, Paul+#+#+#+dlib, 0.40000, basically+be+invalid+>+>, 0.40000, supposed+#+#+the, 0.40000, >>>>+#+really+don't+understand, 0.40000, update+#+#+>>>>, 0.40000, the+#+#+your+current, 0.40000, pean+org>+wrote+#+Could, 0.40000, right, 0.40000, corrupt+your+setup+completely, 0.40000, 8+#+#+Peter+Ankerst%c3%a5l, 0.40000 Cc: Scot Hetzel , 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: Wed, 05 Nov 2014 22:41:02 -0000 --Apple-Mail=_678FB9FF-7EFE-45B2-9668-EDFB8B0C2222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 05 Nov 2014, at 20:29, Paul Mather wrote: >=20 >=20 >> On Nov 5, 2014, at 1:58 PM, Peter Ankerst=C3=A5l = wrote: >>=20 >>=20 >>=20 >>>> On 5 nov 2014, at 19:53, Scot Hetzel wrote: >>>>=20 >>>> On Wed, Nov 5, 2014 at 8:30 AM, Peter Ankerst=C3=A5l = wrote: >>>> Could someone please explain how to use freebsd-update upgrade = without >>>> destroying all of your configuration files? >>>>=20 >>>> I really don't understand how to use the merge function.. In this = case i >>>> typed :q for all files it asked about. :wq seem to >>>> do about the same thing. Notice that a few of the files has this = shit in >>>> multiple places. I can't be right that I should edit every file = manually and >>>> look for "current version" and so on? >>> Most likely what happened is that when you used :wq it wrote the >>> contents of the diff between your current version and the new = version >>> to your existing configuration files. If you had stuck to using :q, >>> it should have left your existing configuration files alone. >>=20 >> This was done with :q only. I dont get it. >=20 > When you upgrade using freebsd-update, it will try and update = configuration files automatically. If there are any configuration files = whose differences can't be resolved automatically, it will present that = file for editing with the merge conflicts in the file presented. You = are then supposed to resolved the conflicts manually. >=20 > I've always resolved any conflicts, so I've not had any experience if = you simply ":q" from the editor, thereby leaving in all the conflict = markers. If freebsd-update doesn't check for unresolved conflicts and = force you to edit the file again, I presume your configuration file will = now basically be invalid. >=20 > Maybe this is what happened in your case? >=20 > Cheers, >=20 > Paul. But its too easy to corrupt your setup completely. This is much worse = than mergemaster. And I haven=E2=80=99t seen any instructions on this in = the handbook. --Apple-Mail=_678FB9FF-7EFE-45B2-9668-EDFB8B0C2222 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMbzCCBjMw ggUboAMCAQICAwiyiDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE0MDEyMDA3NTIzOFoXDTE1MDEyMTA4NTkyMVowUzEZMBcGA1UEDRMQMWlGRkxHbTV3RmVT WjZ6OTEXMBUGA1UEAwwOcGV0ZXJAcGVhbi5vcmcxHTAbBgkqhkiG9w0BCQEWDnBldGVyQHBlYW4u b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzoKHiOE9vdQgax/GZyTaqtNvfjGI HwG1tsMOXZELs49KJY66oD//szW3yoIl8nQapUBn+hZqs3QT5PxqfElXxljYszYE6yk3kWR7EVtl IEfT7Pf24XlFw4uzoZzEjaxPJBt4+BWwb1MpqBmwTNZwZGYI9SO6JW23G9o+e+hPmlXFTovW9B36 J0M2Qu0+IE6MsDIG0y5CwuiXMqNz+vEBiIBvdef3CIidRn3/K7DQYBYn9gj/UNB1yf1GRhsNDO12 4T9+9bhlplov0srt7pqQjaSiiqVOCCWdpxvM/eF0LFBkEFATy45RKtl2vk9zM1wmI+sU29vodHoD Duf8t4bTtQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSAhVDjVwheLV39/7XFsz9rQP0sVDAfBgNVHSME GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5wZXRlckBwZWFuLm9yZzCCAUwG A1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFj Y29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3Rh cnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBp biBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5j bGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8w DQYJKoZIhvcNAQEFBQADggEBAFiVjpZEkQoHYAtb0E6MVJgzo1K6d6eEjLsCNbaw833a0jws4Rh0 KG/MjqjJzUwa2G6mVZb/JaodRK8VENnpxJ8WhjWqyQL8/lKnGa88XYMtl+i4ICur08IfQLG7zNFn yG/kOAiMNkgF4H6lZx/ezup9fowUOt0hxERXMcqo4p+RzPShx35EGRv+5gZNQ7XW4s2rzFzt9CHa Dar8SyAGHK3oFapKpHsVSUYik0QCLwnGcaHEHNUkCp1YMsjKwvmxVtQQs/2WfsqQlult8UYe0bTr nwDyLbgJDbvp9R5mZDrkUcXYlgP+mAmzTOrT1JhHbyYQjbbxJAmqkAIDcwVyDRAwggY0MIIEHKAD AgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEw MjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoU fE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9 f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxah NvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSy rrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAP BgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO 8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcG CCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xe rhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+G xhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk2 2BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0 y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBK M586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQ XPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0 ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6Tcv GbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhd GwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA28wggNrAgEBMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwiyiDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMDUyMjQwNDlaMCMGCSqGSIb3 DQEJBDEWBBSMloEY/FO17UGe8i8Bo3dFLT/TwjCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAwiyiDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDCLKIMA0GCSqGSIb3DQEBAQUABIIBAEqAn6yoBNijZPOU7nNh 4kZf3hwNwvGoqiB7d5eBedqxEFJYpJJLzgLAioDJS74z76I+EnAIyR+Nimi7Ub/R4H0Tsb0uoc1U e/zFPjqxOf7x5s3HrcOIotCQv6Je/K0FwJn1jDhplrEdS9lhOImkr79c1xI3mjP9cBH8rKJ1iNth nA1qCsgALQgLgFklZ4VDxLENKuPiT4ExbdsHC7RwQWWQrHKN5uwZMRWCyrmaVFqD6vy4FPKMZ5FH O1mpP8F+dK5fPicw7qrmEVuzyhuSaX06HFdmRYOyGvwe08K2nR232ncGEWwtqtYvK9Ik4DDpyMU3 wPgRLW6gBqgyNuMDMxQAAAAAAAA= --Apple-Mail=_678FB9FF-7EFE-45B2-9668-EDFB8B0C2222-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 22:51:37 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 708DDD6C; Wed, 5 Nov 2014 22:51:37 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D812405; Wed, 5 Nov 2014 22:51:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sA5MpXYD090514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Nov 2014 15:51:34 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sA5MpW0a090508; Wed, 5 Nov 2014 15:51:33 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 5 Nov 2014 15:51:32 -0700 (MST) From: Warren Block To: Ian Smith Subject: Re: Small motd nit in 10.1 In-Reply-To: <20141103181034.K52402@sola.nimnet.asn.au> Message-ID: References: <8C81A636-D2B5-4EFB-9EA3-58E88E16CA94@spam.lifeforms.nl> <93E9657A-737E-4705-A0E5-01F9E9110261@gromit.dlib.vt.edu> <201410301554.03504.jhb@freebsd.org> <20141103181034.K52402@sola.nimnet.asn.au> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 05 Nov 2014 15:51:34 -0700 (MST) Cc: freebsd-stable@freebsd.org, John Baldwin , Walter Hop 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, 05 Nov 2014 22:51:37 -0000 On Mon, 3 Nov 2014, Ian Smith wrote: > On Sun, 2 Nov 2014 12:23:31 -0700, Warren Block wrote: > > On Thu, 30 Oct 2014, Warren Block wrote: > > > > > On Thu, 30 Oct 2014, Warren Block wrote: > > > > > > > There is room on that line to show both: > > > > > > > > Show details of the FreeBSD installation: uname -a ; freebsd-version > > > > > > > > Or some combination like that. > > > > > > Actually, I think the output from 'freebsd-version ; uname -a' is less > > > ambiguous. > > > > Since nobody has complained about this, I'll update head now and plan to MFC > > it. Hopefully it will be in time for 10.1-RELEASE. > > It should be obvious, I guess, that this doesn't apply to 9.x (tested :) Right. MFCed from head to 10-stable, and good news: squeaking into releng/10.1 just under the wire, thanks to Glen Barber. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 23:07: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 60DE5544; Wed, 5 Nov 2014 23:07:54 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 0FB1F791; Wed, 5 Nov 2014 23:07:53 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sA5N9m9x012844; Wed, 5 Nov 2014 15:09:48 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Ian Smith , Warren Block In-Reply-To: References: <8C81A636-D2B5-4EFB-9EA3-58E88E16CA94@spam.lifeforms.nl> <93E9657A-737E-4705-A0E5-01F9E9110261@gromit.dlib.vt.edu> <201410301554.03504.jhb@freebsd.org> <20141103181034.K52402@sola.nimnet.asn.au>, From: "Chris H" Subject: Re: Small motd nit in 10.1 Date: Wed, 05 Nov 2014 15:09:48 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, Walter Hop , John Baldwin 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, 05 Nov 2014 23:07:54 -0000 On Wed, 5 Nov 2014 15:51:32 -0700 (MST) Warren Block wrote > On Mon, 3 Nov 2014, Ian Smith wrote: > > > On Sun, 2 Nov 2014 12:23:31 -0700, Warren Block wrote: > > > On Thu, 30 Oct 2014, Warren Block wrote: > > > > > > > On Thu, 30 Oct 2014, Warren Block wrote: > > > > > > > > > There is room on that line to show both: > > > > > > > > > > Show details of the FreeBSD installation: uname -a ; > > > freebsd-version > > > > > > > Or some combination like that. > > > > > > > > Actually, I think the output from 'freebsd-version ; uname -a' is less > > > > ambiguous. > > > > > > Since nobody has complained about this, I'll update head now and plan to > > > MFC it. Hopefully it will be in time for 10.1-RELEASE. > > > > It should be obvious, I guess, that this doesn't apply to 9.x (tested :) > > Right. MFCed from head to 10-stable, and good news: squeaking into > releng/10.1 just under the wire, thanks to Glen Barber. Right. I can confirm it made it in. I just performed a fresh install this AM. A custom kernel && build/install world confirms the new motd(5) change was applied. I really appreciate the change, looks good. Thanks! --Chris > _______________________________________________ > 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 Wed Nov 5 23:39:29 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 334E6E3B for ; Wed, 5 Nov 2014 23:39:29 +0000 (UTC) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (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 A6C57AB5 for ; Wed, 5 Nov 2014 23:39:28 +0000 (UTC) Received: (qmail 79440 invoked from network); 6 Nov 2014 00:32:42 +0100 Received: from smtp.free.de (HELO orwell) (k@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 6 Nov 2014 00:32:42 +0100 Date: Thu, 6 Nov 2014 00:32:40 +0100 From: Kai Gallasch To: freebsd-stable@freebsd.org Subject: 10.1 RC4 r273903 - zpool scrub on ssd mirror - ahci command timeout Message-ID: <20141106003240.344dedf6@orwell> Organization: FREE! X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/Cb+iQfmYOFK1M9cv+=7kz6I"; protocol="application/pgp-signature" 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, 05 Nov 2014 23:39:29 -0000 --Sig_/Cb+iQfmYOFK1M9cv+=7kz6I Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi. Not sure if this is 10.1 related or more a problem of the ssd model and/or ahci controller.. I am currently running 10.1 RC4 r273903 on a zfs on root server with two mirror pools. One of the pools is a mirror consisting of two Samsung SSD 850 PRO 512GB SSDs. When I start a zfs scrub on this pool the result of the scrub is: # zpool status -v ssdpool pool: ssdpool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-9P scan: scrub repaired 73K in 0h8m with 0 errors on Thu Nov 6 00:00:16 2014 config: NAME STATE READ WRITE CKSUM ssdpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/ssdpool0 ONLINE 0 0 17 gpt/ssdpool1 ONLINE 0 0 29 When I do a 'zpool clear' the pool status looks ok again. But when I again start a zpool scrub the same thing happens again and the above status "One or more devices has experienced an unrecoverable error" shows again. I find the following kernel message in the output of 'dmesg': (after running zpool scrub two times) ahcich2: Timeout on slot 15 port 0 ahcich2: is 00000000 cs 000f0000 ss 000f8000 rs 000f8000 tfd 40 serr 00000000 cmd 0024cf17 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 8b a6 1d 56 40 0d 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: Command timeout (ada2:ahcich2:0:0:0): Retrying command ahcich2: Timeout on slot 23 port 0 ahcich2: is 00000000 cs 0f000000 ss 0f800000 rs 0f800000 tfd 40 serr 00000000 cmd 0024d817 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 1b 23 81 bc 40 06 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: Command timeout (ada2:ahcich2:0:0:0): Retrying command ahcich2: Timeout on slot 3 port 0 ahcich2: is 00000000 cs 00000030 ss 00000038 rs 00000038 tfd 40 serr 00000000 cmd 0024c317 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 26 bd 18 8e 40 12 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: Command timeout (ada2:ahcich2:0:0:0): Retrying command Besides: smartctl shows no error on ada2. Here comes the output.. # smartctl -a -q noserial /dev/ada2 smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-RC4 amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D Device Model: Samsung SSD 850 PRO 512GB Firmware Version: EXM01B6Q User Capacity: 512,110,190,592 bytes [512 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Thu Nov 6 00:02:04 2014 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled =3D=3D=3D START OF READ SMART DATA SECTION =3D=3D=3D SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever=20 been run. Total time to complete Offline=20 data collection: ( 0) seconds. Offline data collection capabilities: (0x53) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. No Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine=20 recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 33) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 154 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 5 177 Wear_Leveling_Count 0x0013 100 100 000 Pre-fail Always - 0 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 070 068 000 Old_age Always - 30 195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 235 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 0 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 400466433 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 147 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. I wonder What is the possible reason for this. Both SSDs are new. Is this a common problem with zfs and SSDs (for example ahci timeouts because of high data rates for a bus ?) K. --=20 PGP-KeyID =3D 0xE401B671927D4A5C --Sig_/Cb+iQfmYOFK1M9cv+=7kz6I Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUWrOYAAoJEHBlTXxPsfWI+UIQAJ3E8zSy/71RdJ3XrEtTIVy3 Akz/LFvpJ6NFLu4meRXtpyNrX1PinNPIhMXM7c/ugXk0Absb4WZABR5fBiecHrTh xxfcKoVZ8l5AIm06DfUlXRkLdGSfpVEkPIr8t2qFc/ka04yrinZoQIbr3i7Rv3be ri7lKQBEOEjNYT0IdW9GTPOdzKDHnxu9I4zHiZ7x6DlMMUiGXPSkahCuo26ppo8T AMcZr5IUdG+5LwWWBwNy2we1BTrQt2C/L0AlRLa3I1iqFMprq33M8nesCNDbLV9P jjkUrUd0bPouFMUt1bEGwGrgZM4JLcywTuSeH2GpC9k3Jghz7yd3hxo4FEf2+zzl 4L5UyPZWTP8OGg2SG33TO/E2hORDfxJCyUdJy5nAFtxug/rm36d3qZBTltpjeq1K jI0c7bm6fXGa9WgdtmDbXOZV06h6ZxSiRRWG9cpZr82x0rfsW1N2ncQhSyjkU8gM i3L06SbiKLmEx8U6Swy11gCXnTW9QDyn9cj8NgFNKf3fMHgNdCZts7GD/kVAPmui k0ZYG13TP0eNgowyN5ByOQckvdNnQPPW4ghKWPtkC2UkCgM+QbNEThuil13x0OiV h/IE5/E6OooVUyMR/pTsTKLYK0yU08UOtjZSpnxPoXK7j5r6GrY7LoKpU6nnbyIx WfPMN+fDI1NLjWTx8z9X =aXKW -----END PGP SIGNATURE----- --Sig_/Cb+iQfmYOFK1M9cv+=7kz6I-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 5 23:45: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 C963E72 for ; Wed, 5 Nov 2014 23:45:42 +0000 (UTC) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 58E7DB88 for ; Wed, 5 Nov 2014 23:45:41 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id n3so13935713wiv.12 for ; Wed, 05 Nov 2014 15:45:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8l7i4hjv0+/9cWUjNmhbF/Fz9d6d6yC2PW6bzAah5jM=; b=hJCrY4pJfhp7+SE2+Qtg/ajNo1gFKewwtlX9TPgoiMD2Huxod+TqUjXPLaaqspqSw7 SUOKZrDlr/E1dHvYtWgaPA07/kDeCDEfVNMyszv3oqnZv3UPSRxQuRkBw0R57JfIrmyq 2KgwJiQ+XMKY6SVk976TxMQ8sUSaeqMl0zHYJzBgAokUEBILqZOBXgAE825G0mzjX73E Ix3Tru4mu+Teei12ATZco39cJDgY7WfrtRu4G/3S+hdNxVhPnQcQoPUxlHkUi3GflQw9 x+Hzu2bRd+Jknx2L4swFp14P3T6XoBtHkgS8mNpIxk42mwvhM5tmgTaLGX7zgh868l4x AZuA== X-Gm-Message-State: ALoCoQlIcvEdQ21z/Aa81lV8/g3M/brQW4t9mUuOKfZ//QYjsIYF4WfNyTAG/60EX3tgNCwkP4mk X-Received: by 10.194.191.136 with SMTP id gy8mr748408wjc.72.1415231139466; Wed, 05 Nov 2014 15:45:39 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id s10sm17455753wix.14.2014.11.05.15.45.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 15:45:38 -0800 (PST) Message-ID: <545AB64F.1060502@multiplay.co.uk> Date: Wed, 05 Nov 2014 23:44:15 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1 RC4 r273903 - zpool scrub on ssd mirror - ahci command timeout References: <20141106003240.344dedf6@orwell> In-Reply-To: <20141106003240.344dedf6@orwell> 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: Wed, 05 Nov 2014 23:45:42 -0000 Looks like a HW issue, how is it connected to the controller and what is the controller? On 05/11/2014 23:32, Kai Gallasch wrote: > Hi. > > Not sure if this is 10.1 related or more a problem of the ssd > model and/or ahci controller.. > > I am currently running 10.1 RC4 r273903 on a zfs on root server with two > mirror pools. One of the pools is a mirror consisting of two Samsung > SSD 850 PRO 512GB SSDs. > > When I start a zfs scrub on this pool the result of the scrub is: > > # zpool status -v ssdpool > pool: ssdpool > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://illumos.org/msg/ZFS-8000-9P > scan: scrub repaired 73K in 0h8m with 0 errors on Thu Nov 6 00:00:16 > 2014 config: > > NAME STATE READ WRITE CKSUM > ssdpool ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/ssdpool0 ONLINE 0 0 17 > gpt/ssdpool1 ONLINE 0 0 29 > > When I do a 'zpool clear' the pool status looks ok again. But when I > again start a zpool scrub the same thing happens again and the > above status "One or more devices has experienced an unrecoverable > error" shows again. > > > I find the following kernel message in the output of 'dmesg': (after > running zpool scrub two times) > > > ahcich2: Timeout on slot 15 port 0 > ahcich2: is 00000000 cs 000f0000 ss 000f8000 rs 000f8000 tfd 40 serr > 00000000 cmd 0024cf17 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 > 8b a6 1d 56 40 0d 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: > Command timeout (ada2:ahcich2:0:0:0): Retrying command > ahcich2: Timeout on slot 23 port 0 > ahcich2: is 00000000 cs 0f000000 ss 0f800000 rs 0f800000 tfd 40 serr > 00000000 cmd 0024d817 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 > 1b 23 81 bc 40 06 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: > Command timeout (ada2:ahcich2:0:0:0): Retrying command > ahcich2: Timeout on slot 3 port 0 > ahcich2: is 00000000 cs 00000030 ss 00000038 rs 00000038 tfd 40 serr > 00000000 cmd 0024c317 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 > 26 bd 18 8e 40 12 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: > Command timeout (ada2:ahcich2:0:0:0): Retrying command > > > Besides: smartctl shows no error on ada2. > Here comes the output.. > > # smartctl -a -q noserial /dev/ada2 > smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-RC4 amd64] (local build) > Copyright (C) 2002-14, Bruce Allen, Christian Franke, > www.smartmontools.org > > === START OF INFORMATION SECTION === > Device Model: Samsung SSD 850 PRO 512GB > Firmware Version: EXM01B6Q > User Capacity: 512,110,190,592 bytes [512 GB] > Sector Size: 512 bytes logical/physical > Rotation Rate: Solid State Device > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c > SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) > Local Time is: Thu Nov 6 00:02:04 2014 CET > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x00) Offline data collection > activity was never started. > Auto Offline Data Collection: > Disabled. Self-test execution status: ( 0) The previous > self-test routine completed without error or no self-test has ever > been run. > Total time to complete Offline > data collection: ( 0) seconds. > Offline data collection > capabilities: (0x53) SMART execute Offline > immediate. Auto Offline data collection on/off support. > Suspend Offline collection upon > new command. > No Offline surface scan > supported. Self-test supported. > No Conveyance Self-test > supported. Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before > entering power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging > supported. Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 33) minutes. > SCT capabilities: (0x003d) SCT Status supported. > SCT Error Recovery Control > supported. SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 1 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 > 100 010 Pre-fail Always - 0 9 Power_On_Hours > 0x0032 099 099 000 Old_age Always - 154 12 > Power_Cycle_Count 0x0032 099 099 000 Old_age > Always - 5 177 Wear_Leveling_Count 0x0013 100 100 > 000 Pre-fail Always - 0 179 Used_Rsvd_Blk_Cnt_Tot > 0x0013 100 100 010 Pre-fail Always - 0 181 > Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age > Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 > 010 Old_age Always - 0 183 Runtime_Bad_Block > 0x0013 100 100 010 Pre-fail Always - 0 187 > Reported_Uncorrect 0x0032 100 100 000 Old_age > Always - 0 190 Airflow_Temperature_Cel 0x0032 070 068 > 000 Old_age Always - 30 195 Hardware_ECC_Recovered > 0x001a 200 200 000 Old_age Always - 0 199 > UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age > Always - 0 235 Unknown_Attribute 0x0012 100 100 > 000 Old_age Always - 0 241 Total_LBAs_Written > 0x0032 099 099 000 Old_age Always - 400466433 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed > without error 00% 147 - > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute > delay. > > I wonder What is the possible reason for this. Both SSDs are new. > Is this a common problem with zfs and SSDs (for example ahci timeouts > because of high data rates for a bus ?) > > K. > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 00:27: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 7D5FD13A for ; Thu, 6 Nov 2014 00:27:45 +0000 (UTC) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (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 CDD4BFBF for ; Thu, 6 Nov 2014 00:27:44 +0000 (UTC) Received: (qmail 16722 invoked from network); 6 Nov 2014 01:27:42 +0100 Received: from smtp.free.de (HELO orwell) (k@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 6 Nov 2014 01:27:42 +0100 Date: Thu, 6 Nov 2014 01:27:39 +0100 From: Kai Gallasch To: freebsd-stable@freebsd.org Subject: Re: 10.1 RC4 r273903 - zpool scrub on ssd mirror - ahci command timeout Message-ID: <20141106012739.509b96b5@orwell> In-Reply-To: <545AB64F.1060502@multiplay.co.uk> References: <20141106003240.344dedf6@orwell> <545AB64F.1060502@multiplay.co.uk> Organization: FREE! X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/H3gB3vpPwbhWohn56fzs7vY"; protocol="application/pgp-signature" 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, 06 Nov 2014 00:27:45 -0000 --Sig_/H3gB3vpPwbhWohn56fzs7vY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 05 Nov 2014 23:44:15 +0000 schrieb Steven Hartland : > Looks like a HW issue, how is it connected to the controller and what > is the controller? It's a SUN X2270 M1 server with 4 SATA connected disks. The (2.5") SSD drives are inside SUN 3.5" disk carriers and are sitting on top of a 2.5" to 3.5" converter - like this one here http://goo.gl/yBfS1V dmesg.out: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-RC4 #0 r273903: Fri Oct 31 15:32:22 CET 2014 kgal@beltwaybandit.free.de:/usr/obj/usr/src/sys/X2270-10 amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (2266.80-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x106a5 Family =3D 0x6 Model =3D 0x1a= Stepping =3D 5 Features=3D0xbfebfbff Features2=3D0x9ce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID TSC: P-state invariant, performance statistics real memory =3D 51539607552 (49152 MB) avail memory =3D 50000900096 (47684 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <040910 APIC1030> FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 cpu4 (AP): APIC ID: 20 cpu5 (AP): APIC ID: 21 cpu6 (AP): APIC ID: 22 cpu7 (AP): APIC ID: 23 cpu8 (AP): APIC ID: 0 cpu9 (AP): APIC ID: 1 cpu10 (AP): APIC ID: 2 cpu11 (AP): APIC ID: 3 cpu12 (AP): APIC ID: 4 cpu13 (AP): APIC ID: 5 cpu14 (AP): APIC ID: 6 cpu15 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized module_register_init: MOD_LOAD (vesa, 0xffffffff8085c590, 0) error 19 kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: <040910 XSDT1030> on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 Event timer "HPET3" frequency 14318180 Hz quality 340 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci4: on pcib1 igb0: port 0xec00-0x= ec1f mem 0xfbee0000-0xfbefffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff = irq 40 at device 0.0 on pci4 igb0: Using MSIX interrupts with 5 vectors igb0: Ethernet address: 00:14:4f:ca:a9:00 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb1: port 0xe880-0x= e89f mem 0xfbe60000-0xfbe7ffff,0xfbe40000-0xfbe5ffff,0xfbe3c000-0xfbe3ffff = irq 28 at device 0.1 on pci4 igb1: Using MSIX interrupts with 5 vectors igb1: Ethernet address: 00:14:4f:ca:a9:01 igb1: Bound queue 0 to cpu 4 igb1: Bound queue 1 to cpu 5 igb1: Bound queue 2 to cpu 6 igb1: Bound queue 3 to cpu 7 pcib2: at device 3.0 on pci0 pci3: on pcib2 pcib3: at device 7.0 on pci0 pci2: on pcib3 pci0: at device 20.0 (no driver att= ached) pci0: at device 20.1 (no driver att= ached) pci0: at device 20.2 (no driver att= ached) pci0: at device 20.3 (no driver att= ached) uhci0: port 0xb800-0xb81f irq = 16 at device 26.0 on pci0 uhci0: LegSup =3D 0x2f00 usbus0 on uhci0 uhci1: port 0xb480-0xb49f irq = 21 at device 26.1 on pci0 uhci1: LegSup =3D 0x2f00 usbus1 on uhci1 uhci2: port 0xb400-0xb41f irq = 19 at device 26.2 on pci0 uhci2: LegSup =3D 0x2f00 usbus2 on uhci2 ehci0: mem 0xfbdf4000-0xfb= df43ff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 uhci3: port 0xc000-0xc01f irq = 23 at device 29.0 on pci0 uhci3: LegSup =3D 0x2f00 usbus4 on uhci3 uhci4: port 0xbc00-0xbc1f irq = 19 at device 29.1 on pci0 uhci4: LegSup =3D 0x2f00 usbus5 on uhci4 uhci5: port 0xb880-0xb89f irq = 18 at device 29.2 on pci0 uhci5: LegSup =3D 0x2f00 usbus6 on uhci5 ehci1: mem 0xfbdf6000-0xfb= df63ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib4: at device 30.0 on pci0 pci1: on pcib4 vgapci0: port 0xdc00-0xdc7f mem 0xfb000000-0xfb7ff= fff,0xfafe0000-0xfaffffff irq 16 at device 5.0 on pci1 vgapci0: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xcc00-0xcc07,0xc880-0xc883,= 0xc800-0xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfbdfa000-0xfbdfa7ff irq 19 = at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 acpi_button0: on acpi0 ipmi0: port 0xca2,0xca6 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi qpi0: on motherboard pcib5: pcibus 255 on qpi0 pci255: on pcib5 pcib6: pcibus 254 on qpi0 pci254: on pcib6 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0x= c9fff,0xca000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: CGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: at port 0x3f8-0x3ff irq = 4 on isa0 uart0: console (115200,n,8,1) coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 coretemp8: on cpu8 est8: on cpu8 p4tcc8: on cpu8 coretemp9: on cpu9 est9: on cpu9 p4tcc9: on cpu9 coretemp10: on cpu10 est10: on cpu10 p4tcc10: on cpu10 coretemp11: on cpu11 est11: on cpu11 p4tcc11: on cpu11 coretemp12: on cpu12 est12: on cpu12 p4tcc12: on cpu12 coretemp13: on cpu13 est13: on cpu13 p4tcc13: on cpu13 coretemp14: on cpu14 est14: on cpu14 p4tcc14: on cpu14 coretemp15: on cpu15 est15: on cpu15 p4tcc15: on cpu15 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ipmi0: IPMI device rev. 1, firmware rev. 3.00, version 2.0 uhub0: 2 ports with 2 removable, self powered ipmi0: Number of channels 5 ipmi0: Attached watchdog ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 uhub1: 2 ports with 2 removable, self powered ada0: ATA-7uhub2: 2 ports wi= th 2 removable, self powered SATA 2.x device ada0: Serial Number GTA460P6GWRUMF ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 uhub4: 2 ports with 2 removable, self powered ada1: ATA-7uhub5: 2 ports wi= th 2 removable, self powered SATA 2.x device ada1: Serial Number GTF402P6GS4H0F ada1: 300.000MB/s transfersuhub6: 2 ports with 2 removable, self powered (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA-9 SATA 3.x device ada2: Serial Number S1SXNSAFA06834H ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) ada2: Command Queueing enabled ada2: 488386MB (1000215216 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ATA-9 SATA 3.x device ada3: Serial Number S1SXNSAFA06835A ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) ada3: Command Queueing enabled ada3: 488386MB (1000215216 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device GEOM_MIRROR: Device mirror/swap launched (2/2). SMP: AP CPU #1 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #4 Launched! Timecounter "TSC-low" frequency 1133397512 Hz quality 1000 Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 usbus3 ugen3.2: at usbus3 usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) Root mount waiting for: usbus7 ugen7.2: at usbus7 umass0: o= n usbus7 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 scbus7 target 0 lun 0 da0: Removable Direct Access SCSI-4 device=20 da0: Serial Number 82L68FGM1BTVJHR0 da0: 40.000MB/s transfers da0: 3861MB (7907328 512 byte sectors: 255H 63S/T 492C) da0: quirks=3D0x12 ugen2.2: at usbus2 ukbd0: on usbus2 Trying to mount root from zfs:rpool/ROOT/r273903-10.1 []... kbd2 at ukbd0 ums0: on usbus2 ums0: 3 buttons and [XY] coordinates ID=3D0 ukbd1: on = usbus4 kbd3 at ukbd1 ums1: on u= sbus4 ums1: 5 buttons and [XYZ] coordinates ID=3D1 ugen4.2: at usbus4 (disconnected) ukbd1: at uhub4, port 2, addr 2 (disconnected) ums1: at uhub4, port 2, addr 2 (disconnected) ugen4.2: at usbus4 ukbd1: on = usbus4 kbd3 at ukbd1 ums1: on u= sbus4 ums1: 5 buttons and [XYZ] coordinates ID=3D1 --=20 PGP-KeyID =3D 0xE401B671927D4A5C --Sig_/H3gB3vpPwbhWohn56fzs7vY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUWsB7AAoJEHBlTXxPsfWIkdwQAKFeuy3paHObKkPFvtFy47+2 Hk4two2A9PB1Wl838GDw0z0td9hWBcrrtUtXccHKqWmou2CtHwJ+YOy5KsOAw6Nh s+LKXPHn5GopZ1vg0mh9n4u1oS7BVjI46lsbGq9bNvgOkDv/B0KHBDT1rRQ9TOWh 6EviAINN5Gf343O8HF9LLW5Ho5hs3+oH5CEW6CRrtUR9afQ7t7htKxEstQUYkBzG HDQ55iArv/cZBWsM5M99WkjTfZ+4eZ5foYw3r0rJxlrGzQr/L3KNYHhbQz5dl+FN 3/gZb94gjIlP/w2cQBEKO2+6CO/b9fRnk51yu/tLiK/ZHYNmrWHrpBqb2OFqlqfI 9x04pKU4xvI4alW/Rr7el/kyFHyE8EuqcPafbGMmwrEBSV3BfCHPIcDJ+VXw/wEI dwHmp6Ymp3Kyr5jBEtWo1YoiheYDx/Bqq8frFLCSuvc2mddN+p5ORAJVc5M0IYkR IEXw77KNQQS8w8bTbeIqO6lPGm8CKjSUqDqOK3PvC43Gf5QSYKazZXR2VpTj7P5l jFHmjhjLuWY3XeGhI2QyC4arEzVAZ/GaPqRqDISnwMLiChda3drbZFSE4OmdqfWf //kty7E1hZkvmSLWcRZXNh7V8Z35Op9d93vwcIdJx4XqQIxCqk3cv/A/A6s029hA TSqcQkUCz6c3+b0hR53r =eTfE -----END PGP SIGNATURE----- --Sig_/H3gB3vpPwbhWohn56fzs7vY-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 01:22: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 700E8E82 for ; Thu, 6 Nov 2014 01:22:19 +0000 (UTC) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 EED7E85B for ; Thu, 6 Nov 2014 01:22:18 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ex7so99801wid.14 for ; Wed, 05 Nov 2014 17:22:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MlXWvDaOD0OY7M8AFHD9Fnn5lCEaN3FFoix+msc9du0=; b=gFVeTjwGvThaf2Z+q5I+MDYJkuSg+Uku35NCK513tQ70QK//GViHrN3eZSFPHGdlwY +4mBoBWh5aHg2R/CD0ThZ7YIVWtkHOFEe6ZFNmL2e2Gd8s1M5hItGsycy0+thfc3vURY MV0SLVY1MSB2EcZoAcN451cd7ACNonpqu8EhyYV171GTna4lsFuqcXMSSPyA5Z99+BP0 wE4q9NefDKzKpHCZ4Zv+LnqECMd4Zq1kQpSeUyQXUS6flbUaPP4DG0wkfxViIa0KsArg Pyj/Je4NXcENMmgZN5gPLxyE0n/OxJiccq6SdmNqSZp6kfVnmX33D/GXVskKyKKxRro9 u17A== X-Gm-Message-State: ALoCoQnixntBkRnNvkwsvaRjMUuqDErbSxZhpmKD0Wz86DxP9AMaZUB71sfMDAw1XLzzI+pD+xuS X-Received: by 10.180.97.65 with SMTP id dy1mr24294814wib.76.1415236931466; Wed, 05 Nov 2014 17:22:11 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id p1sm5935211wjy.22.2014.11.05.17.22.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 17:22:10 -0800 (PST) Message-ID: <545ACCEF.5000300@multiplay.co.uk> Date: Thu, 06 Nov 2014 01:20:47 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1 RC4 r273903 - zpool scrub on ssd mirror - ahci command timeout References: <20141106003240.344dedf6@orwell> <545AB64F.1060502@multiplay.co.uk> <20141106012739.509b96b5@orwell> In-Reply-To: <20141106012739.509b96b5@orwell> 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: Thu, 06 Nov 2014 01:22:19 -0000 Try recabling and re-seating, if it still happens try to identify if its the disk or backplane by moving it in the chassis. We had a machine here recently where it was backplane issue and simply replacing it fixed the issue. On 06/11/2014 00:27, Kai Gallasch wrote: > Am Wed, 05 Nov 2014 23:44:15 +0000 > schrieb Steven Hartland : > >> Looks like a HW issue, how is it connected to the controller and what >> is the controller? > It's a SUN X2270 M1 server with 4 SATA connected disks. > > The (2.5") SSD drives are inside SUN 3.5" disk carriers and are sitting > on top of a 2.5" to 3.5" converter - like this one here > http://goo.gl/yBfS1V > > > dmesg.out: > > > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.1-RC4 #0 r273903: Fri Oct 31 15:32:22 CET 2014 > kgal@beltwaybandit.free.de:/usr/obj/usr/src/sys/X2270-10 amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (2266.80-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x106a5 Family = 0x6 Model = 0x1a Stepping = 5 > Features=0xbfebfbff > Features2=0x9ce3bd > AMD Features=0x28100800 > AMD Features2=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID > TSC: P-state invariant, performance statistics > real memory = 51539607552 (49152 MB) > avail memory = 50000900096 (47684 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: <040910 APIC1030> > FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads > cpu0 (BSP): APIC ID: 16 > cpu1 (AP): APIC ID: 17 > cpu2 (AP): APIC ID: 18 > cpu3 (AP): APIC ID: 19 > cpu4 (AP): APIC ID: 20 > cpu5 (AP): APIC ID: 21 > cpu6 (AP): APIC ID: 22 > cpu7 (AP): APIC ID: 23 > cpu8 (AP): APIC ID: 0 > cpu9 (AP): APIC ID: 1 > cpu10 (AP): APIC ID: 2 > cpu11 (AP): APIC ID: 3 > cpu12 (AP): APIC ID: 4 > cpu13 (AP): APIC ID: 5 > cpu14 (AP): APIC ID: 6 > cpu15 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > random: initialized > module_register_init: MOD_LOAD (vesa, 0xffffffff8085c590, 0) error 19 > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: <040910 XSDT1030> on motherboard > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bff00000 (3) failed > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > cpu8: on acpi0 > cpu9: on acpi0 > cpu10: on acpi0 > cpu11: on acpi0 > cpu12: on acpi0 > cpu13: on acpi0 > cpu14: on acpi0 > cpu15: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 350 > Event timer "HPET1" frequency 14318180 Hz quality 340 > Event timer "HPET2" frequency 14318180 Hz quality 340 > Event timer "HPET3" frequency 14318180 Hz quality 340 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci4: on pcib1 > igb0: port 0xec00-0xec1f mem 0xfbee0000-0xfbefffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff irq 40 at device 0.0 on pci4 > igb0: Using MSIX interrupts with 5 vectors > igb0: Ethernet address: 00:14:4f:ca:a9:00 > igb0: Bound queue 0 to cpu 0 > igb0: Bound queue 1 to cpu 1 > igb0: Bound queue 2 to cpu 2 > igb0: Bound queue 3 to cpu 3 > igb1: port 0xe880-0xe89f mem 0xfbe60000-0xfbe7ffff,0xfbe40000-0xfbe5ffff,0xfbe3c000-0xfbe3ffff irq 28 at device 0.1 on pci4 > igb1: Using MSIX interrupts with 5 vectors > igb1: Ethernet address: 00:14:4f:ca:a9:01 > igb1: Bound queue 0 to cpu 4 > igb1: Bound queue 1 to cpu 5 > igb1: Bound queue 2 to cpu 6 > igb1: Bound queue 3 to cpu 7 > pcib2: at device 3.0 on pci0 > pci3: on pcib2 > pcib3: at device 7.0 on pci0 > pci2: on pcib3 > pci0: at device 20.0 (no driver attached) > pci0: at device 20.1 (no driver attached) > pci0: at device 20.2 (no driver attached) > pci0: at device 20.3 (no driver attached) > uhci0: port 0xb800-0xb81f irq 16 at device 26.0 on pci0 > uhci0: LegSup = 0x2f00 > usbus0 on uhci0 > uhci1: port 0xb480-0xb49f irq 21 at device 26.1 on pci0 > uhci1: LegSup = 0x2f00 > usbus1 on uhci1 > uhci2: port 0xb400-0xb41f irq 19 at device 26.2 on pci0 > uhci2: LegSup = 0x2f00 > usbus2 on uhci2 > ehci0: mem 0xfbdf4000-0xfbdf43ff irq 18 at device 26.7 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci0 > uhci3: port 0xc000-0xc01f irq 23 at device 29.0 on pci0 > uhci3: LegSup = 0x2f00 > usbus4 on uhci3 > uhci4: port 0xbc00-0xbc1f irq 19 at device 29.1 on pci0 > uhci4: LegSup = 0x2f00 > usbus5 on uhci4 > uhci5: port 0xb880-0xb89f irq 18 at device 29.2 on pci0 > uhci5: LegSup = 0x2f00 > usbus6 on uhci5 > ehci1: mem 0xfbdf6000-0xfbdf63ff irq 23 at device 29.7 on pci0 > usbus7: EHCI version 1.0 > usbus7 on ehci1 > pcib4: at device 30.0 on pci0 > pci1: on pcib4 > vgapci0: port 0xdc00-0xdc7f mem 0xfb000000-0xfb7fffff,0xfafe0000-0xfaffffff irq 16 at device 5.0 on pci1 > vgapci0: Boot video device > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfbdfa000-0xfbdfa7ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich3: at channel 3 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > ahciem0: on ahci0 > acpi_button0: on acpi0 > ipmi0: port 0xca2,0xca6 on acpi0 > ipmi0: KCS mode found at io 0xca2 on acpi > qpi0: on motherboard > pcib5: pcibus 255 on qpi0 > pci255: on pcib5 > pcib6: pcibus 254 on qpi0 > pci254: on pcib6 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff on isa0 > sc0: at flags 0x100 on isa0 > sc0: CGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > uart0: at port 0x3f8-0x3ff irq 4 on isa0 > uart0: console (115200,n,8,1) > coretemp0: on cpu0 > est0: on cpu0 > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > p4tcc1: on cpu1 > coretemp2: on cpu2 > est2: on cpu2 > p4tcc2: on cpu2 > coretemp3: on cpu3 > est3: on cpu3 > p4tcc3: on cpu3 > coretemp4: on cpu4 > est4: on cpu4 > p4tcc4: on cpu4 > coretemp5: on cpu5 > est5: on cpu5 > p4tcc5: on cpu5 > coretemp6: on cpu6 > est6: on cpu6 > p4tcc6: on cpu6 > coretemp7: on cpu7 > est7: on cpu7 > p4tcc7: on cpu7 > coretemp8: on cpu8 > est8: on cpu8 > p4tcc8: on cpu8 > coretemp9: on cpu9 > est9: on cpu9 > p4tcc9: on cpu9 > coretemp10: on cpu10 > est10: on cpu10 > p4tcc10: on cpu10 > coretemp11: on cpu11 > est11: on cpu11 > p4tcc11: on cpu11 > coretemp12: on cpu12 > est12: on cpu12 > p4tcc12: on cpu12 > coretemp13: on cpu13 > est13: on cpu13 > p4tcc13: on cpu13 > coretemp14: on cpu14 > est14: on cpu14 > p4tcc14: on cpu14 > coretemp15: on cpu15 > est15: on cpu15 > p4tcc15: on cpu15 > random: unblocking device. > usbus0: 12Mbps Full Speed USB v1.0 > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > usbus1: 12Mbps Full Speed USB v1.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 480Mbps High Speed USB v2.0 > ugen6.1: at usbus6 > uhub6: on usbus6 > ugen7.1: at usbus7 > uhub7: on usbus7 > ipmi0: IPMI device rev. 1, firmware rev. 3.00, version 2.0 > uhub0: 2 ports with 2 removable, self powered > ipmi0: Number of channels 5 > ipmi0: Attached watchdog > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > uhub1: 2 ports with 2 removable, self powered > ada0: ATA-7uhub2: 2 ports with 2 removable, self powered > SATA 2.x device > ada0: Serial Number GTA460P6GWRUMF > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > uhub4: 2 ports with 2 removable, self powered > ada1: ATA-7uhub5: 2 ports with 2 removable, self powered > SATA 2.x device > ada1: Serial Number GTF402P6GS4H0F > ada1: 300.000MB/s transfersuhub6: 2 ports with 2 removable, self powered > (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 > ada2: ATA-9 SATA 3.x device > ada2: Serial Number S1SXNSAFA06834H > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) > ada2: Command Queueing enabled > ada2: 488386MB (1000215216 512 byte sectors: 16H 63S/T 16383C) > ada2: Previously was known as ad8 > ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 > ada3: ATA-9 SATA 3.x device > ada3: Serial Number S1SXNSAFA06835A > ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) > ada3: Command Queueing enabled > ada3: 488386MB (1000215216 512 byte sectors: 16H 63S/T 16383C) > ada3: Previously was known as ad10 > ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > GEOM_MIRROR: Device mirror/swap launched (2/2). > SMP: AP CPU #1 Launched! > SMP: AP CPU #8 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #9 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #14 Launched! > SMP: AP CPU #6 Launched! > SMP: AP CPU #10 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #13 Launched! > SMP: AP CPU #12 Launched! > SMP: AP CPU #15 Launched! > SMP: AP CPU #11 Launched! > SMP: AP CPU #4 Launched! > Timecounter "TSC-low" frequency 1133397512 Hz quality 1000 > Root mount waiting for: usbus7 usbus3 > Root mount waiting for: usbus7 usbus3 > uhub3: 6 ports with 6 removable, self powered > uhub7: 6 ports with 6 removable, self powered > Root mount waiting for: usbus7 usbus3 > ugen3.2: at usbus3 > usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) > Root mount waiting for: usbus7 > ugen7.2: at usbus7 > umass0: on usbus7 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:7:0:-1: Attached to scbus7 > da0 at umass-sim0 bus 0 scbus7 target 0 lun 0 > da0: Removable Direct Access SCSI-4 device > da0: Serial Number 82L68FGM1BTVJHR0 > da0: 40.000MB/s transfers > da0: 3861MB (7907328 512 byte sectors: 255H 63S/T 492C) > da0: quirks=0x12 > ugen2.2: at usbus2 > ukbd0: on usbus2 > Trying to mount root from zfs:rpool/ROOT/r273903-10.1 []... > kbd2 at ukbd0 > ums0: on usbus2 > ums0: 3 buttons and [XY] coordinates ID=0 > ukbd1: on usbus4 > kbd3 at ukbd1 > ums1: on usbus4 > ums1: 5 buttons and [XYZ] coordinates ID=1 > ugen4.2: at usbus4 (disconnected) > ukbd1: at uhub4, port 2, addr 2 (disconnected) > ums1: at uhub4, port 2, addr 2 (disconnected) > ugen4.2: at usbus4 > ukbd1: on usbus4 > kbd3 at ukbd1 > ums1: on usbus4 > ums1: 5 buttons and [XYZ] coordinates ID=1 > > > > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 02:16:31 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 46FBDBE9 for ; Thu, 6 Nov 2014 02:16:31 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 35DEDD54 for ; Thu, 6 Nov 2014 02:16:31 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 62DE7103 for ; Thu, 6 Nov 2014 02:16:31 +0000 (UTC) Date: Thu, 6 Nov 2014 02:16:30 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-stable@freebsd.org Message-ID: <1304263173.23.1415240190662.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1909480060.22.1415227407282.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1909480060.22.1415227407282.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #331 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image 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: Thu, 06 Nov 2014 02:16:31 -0000 See From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 07:11: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 9B4C1419 for ; Thu, 6 Nov 2014 07:11:53 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EBD25F3D for ; Thu, 6 Nov 2014 07:11:52 +0000 (UTC) Received: from seedling.local (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id sA67Bcjq019770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Nov 2014 07:11:40 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk sA67Bcjq019770 Authentication-Results: smtp.infracaninophile.co.uk/sA67Bcjq019770; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host seedling.black-earth.co.uk [81.2.117.99] claimed to be seedling.local Message-ID: <545B1F2A.5010203@FreeBSD.org> Date: Thu, 06 Nov 2014 07:11:38 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Hartland , freebsd-stable@freebsd.org Subject: Re: Varnish proxy goes catatonic under heavy load References: <545A0EB4.4090404@freebsd.org> <545A117B.4080606@multiplay.co.uk> In-Reply-To: <545A117B.4080606@multiplay.co.uk> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5JvcHa91nkfKeKqGlA07fUbPm4pl86ewF" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk 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, 06 Nov 2014 07:11:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5JvcHa91nkfKeKqGlA07fUbPm4pl86ewF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/11/2014 12:00, Steven Hartland wrote: > As a guess you exhausted all mbufs, 10 has much better defaults for > these so I'd recommend updating. >=20 > If you can get in via IPMI or something similar you should be able to > confirm. >=20 > A trick I've used in the past to recover from such a issue is to hard > bounce the nic ports on the switch which seemed to free enough to be > able to ssh in. Yes, you nailed it. We managed to recreate the effect in the lab, and 10.0 behaves much better under horrible overload. While horribly slow, we can still get to a shell prompt via ssh, and when we turn off the load, the system recovers straight away. We'll be upgrading to 10.x ASAP. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --5JvcHa91nkfKeKqGlA07fUbPm4pl86ewF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iQJ8BAEBCgBmBQJUWx8qXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATd1oP/3NSbCs+EyrvRuLRpV205Lmx 5FUZUbL0ogP9I3y1M4iY6F8CAPJ24Fo7tUDqy1IEYUoI2sI4p2TzLViMy4oolQty EMsHcxepFk/L4Fh3i/Aik+GliJB3+qyJtSIMIgp2FP4vatvPZcv9NTlkXniB52dW fymcZILshNjq/1t4mG+82unBmkibWUcUnplbTWqjT30qq6Ck+4/9/sfJE6JRZCQD cqsytCnmSJt5kq5ZwlBTFRcj3GoSom6Av3Jx+3N9hxZFE6fvQ1Fd07YIH0/E7o+2 i2Y9l6lom8A1ggGODhXAGJIiqG5QgHGW3+MzSKFsJnWhyDNhC+fTqgBsXSbsts7l rOAVrksnezAtP8Gji/63HK5tRSjUptsAEPvN+y4O2QuG4FczuRuMAfyLfzyGgnAz zH6a8BhSZAoip4dGVQ/na1okEkE+vNzyPSyAiR5YQPF3hgAnFJZv8mzqC0YTrUIQ PL/D5jJMhNyB8k8wmfv26gtZc+VeSIoGyBIEox71rtQViDnpmBILb+MeLKc00vp8 1hUtqD8Wyia4oyJzyjK7tBJ1vhBRIHhfQiA4VWbp2vk+wFcB6oDcgG/ujXbn490x itxMm+lS2G0ueEM8oARqxlH1f4/chBOZKIxYiWEUVuaIWNc48GAsN/og2iRCLPfa LZVXCIjOMblqiYtIrG8o =nVlN -----END PGP SIGNATURE----- --5JvcHa91nkfKeKqGlA07fUbPm4pl86ewF-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 08:20:50 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 F24BC144 for ; Thu, 6 Nov 2014 08:20:49 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 56392886 for ; Thu, 6 Nov 2014 08:20:48 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id sA68Kduv001900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Nov 2014 09:20:39 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id sA68KdSg001897; Thu, 6 Nov 2014 09:20:39 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 6 Nov 2014 09:20:38 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Kai Gallasch Subject: Re: 10.1 RC4 r273903 - zpool scrub on ssd mirror - ahci command timeout In-Reply-To: <20141106003240.344dedf6@orwell> Message-ID: References: <20141106003240.344dedf6@orwell> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-ID: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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, 06 Nov 2014 08:20:50 -0000 On Thu, 6 Nov 2014 00:32+0100, Kai Gallasch wrote: > > Hi. > > Not sure if this is 10.1 related or more a problem of the ssd > model and/or ahci controller.. > > I am currently running 10.1 RC4 r273903 on a zfs on root server with two > mirror pools. One of the pools is a mirror consisting of two Samsung > SSD 850 PRO 512GB SSDs. > > When I start a zfs scrub on this pool the result of the scrub is: > > # zpool status -v ssdpool > pool: ssdpool > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://illumos.org/msg/ZFS-8000-9P > scan: scrub repaired 73K in 0h8m with 0 errors on Thu Nov 6 00:00:16 > 2014 config: > > NAME STATE READ WRITE CKSUM > ssdpool ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/ssdpool0 ONLINE 0 0 17 > gpt/ssdpool1 ONLINE 0 0 29 > > When I do a 'zpool clear' the pool status looks ok again. But when I > again start a zpool scrub the same thing happens again and the > above status "One or more devices has experienced an unrecoverable > error" shows again. > > > I find the following kernel message in the output of 'dmesg': (after > running zpool scrub two times) > > > ahcich2: Timeout on slot 15 port 0 > ahcich2: is 00000000 cs 000f0000 ss 000f8000 rs 000f8000 tfd 40 serr > 00000000 cmd 0024cf17 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 > 8b a6 1d 56 40 0d 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: > Command timeout (ada2:ahcich2:0:0:0): Retrying command > ahcich2: Timeout on slot 23 port 0 > ahcich2: is 00000000 cs 0f000000 ss 0f800000 rs 0f800000 tfd 40 serr > 00000000 cmd 0024d817 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 > 1b 23 81 bc 40 06 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: > Command timeout (ada2:ahcich2:0:0:0): Retrying command > ahcich2: Timeout on slot 3 port 0 > ahcich2: is 00000000 cs 00000030 ss 00000038 rs 00000038 tfd 40 serr > 00000000 cmd 0024c317 (ada2:ahcich2:0:0:0): READ_FPDMA_QUEUED. ACB: 60 > 26 bd 18 8e 40 12 00 00 00 00 00 (ada2:ahcich2:0:0:0): CAM status: > Command timeout (ada2:ahcich2:0:0:0): Retrying command Incidently, I've recently seen similar messages in my base/head VMs running in VirtualBox on a Win7Pro host at home. These messages appeared after I upgraded VBox to 4.3.18 on both host and guests, and after upgrading base/head to roughly r273963, last Sunday. I haven't touched my base/head VMs since Sunday, but I may find time to investigate both base/head and base/stable/10 later this evening, and see if they all exhibit the same symptoms as yours. All my FreeBSD VMs uses VirtualBox' SATA controller, except stable/8 which only works correctly with VirtualBox' SCSI controller. > Besides: smartctl shows no error on ada2. > Here comes the output.. > > # smartctl -a -q noserial /dev/ada2 > smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-RC4 amd64] (local build) > Copyright (C) 2002-14, Bruce Allen, Christian Franke, > www.smartmontools.org > > === START OF INFORMATION SECTION === > Device Model: Samsung SSD 850 PRO 512GB > Firmware Version: EXM01B6Q > User Capacity: 512,110,190,592 bytes [512 GB] > Sector Size: 512 bytes logical/physical > Rotation Rate: Solid State Device > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c > SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) > Local Time is: Thu Nov 6 00:02:04 2014 CET > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x00) Offline data collection > activity was never started. > Auto Offline Data Collection: > Disabled. Self-test execution status: ( 0) The previous > self-test routine completed without error or no self-test has ever > been run. > Total time to complete Offline > data collection: ( 0) seconds. > Offline data collection > capabilities: (0x53) SMART execute Offline > immediate. Auto Offline data collection on/off support. > Suspend Offline collection upon > new command. > No Offline surface scan > supported. Self-test supported. > No Conveyance Self-test > supported. Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before > entering power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging > supported. Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 33) minutes. > SCT capabilities: (0x003d) SCT Status supported. > SCT Error Recovery Control > supported. SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 1 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 > 100 010 Pre-fail Always - 0 9 Power_On_Hours > 0x0032 099 099 000 Old_age Always - 154 12 > Power_Cycle_Count 0x0032 099 099 000 Old_age > Always - 5 177 Wear_Leveling_Count 0x0013 100 100 > 000 Pre-fail Always - 0 179 Used_Rsvd_Blk_Cnt_Tot > 0x0013 100 100 010 Pre-fail Always - 0 181 > Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age > Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 > 010 Old_age Always - 0 183 Runtime_Bad_Block > 0x0013 100 100 010 Pre-fail Always - 0 187 > Reported_Uncorrect 0x0032 100 100 000 Old_age > Always - 0 190 Airflow_Temperature_Cel 0x0032 070 068 > 000 Old_age Always - 30 195 Hardware_ECC_Recovered > 0x001a 200 200 000 Old_age Always - 0 199 > UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age > Always - 0 235 Unknown_Attribute 0x0012 100 100 > 000 Old_age Always - 0 241 Total_LBAs_Written > 0x0032 099 099 000 Old_age Always - 400466433 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed > without error 00% 147 - > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute > delay. > > I wonder What is the possible reason for this. Both SSDs are new. > Is this a common problem with zfs and SSDs (for example ahci timeouts > because of high data rates for a bus ?) > > K. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 08:31: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 874DB385; Thu, 6 Nov 2014 08:31: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 EE02B9A1; Thu, 6 Nov 2014 08:31: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 sA68VrFh035017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2014 10:31:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA68VrFh035017 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA68VrPu035016; Thu, 6 Nov 2014 10:31:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 6 Nov 2014 10:31:53 +0200 From: Konstantin Belousov To: Matthew Seaman Subject: Re: Varnish proxy goes catatonic under heavy load Message-ID: <20141106083153.GK53947@kib.kiev.ua> References: <545A0EB4.4090404@freebsd.org> <545A117B.4080606@multiplay.co.uk> <545B1F2A.5010203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545B1F2A.5010203@FreeBSD.org> 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 Cc: freebsd-stable@freebsd.org, Steven Hartland 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, 06 Nov 2014 08:31:59 -0000 On Thu, Nov 06, 2014 at 07:11:38AM +0000, Matthew Seaman wrote: > On 05/11/2014 12:00, Steven Hartland wrote: > > As a guess you exhausted all mbufs, 10 has much better defaults for > > these so I'd recommend updating. > > > > If you can get in via IPMI or something similar you should be able to > > confirm. > > > > A trick I've used in the past to recover from such a issue is to hard > > bounce the nic ports on the switch which seemed to free enough to be > > able to ssh in. > > Yes, you nailed it. We managed to recreate the effect in the lab, and > 10.0 behaves much better under horrible overload. While horribly slow, > we can still get to a shell prompt via ssh, and when we turn off the > load, the system recovers straight away. > > We'll be upgrading to 10.x ASAP. > I do not remember exact point in the stable/9 lifetime when the debug.vn_io_fault_enable was merged. If it is present in your system, frob its value to 1 and see. I highly suspect that if varnish is in 'mmap' mode (whatever it is called), and you use UFS, it may help. I am suggesting this before upgrading to 10 only because I want to know whether the vn_io_fault code helps in this situation. There are rumors that it does, but I never seen the confirmation. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 09:45:10 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 BD15D818 for ; Thu, 6 Nov 2014 09:45:10 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DE0018D for ; Thu, 6 Nov 2014 09:45:10 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id sA69itxr023094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Nov 2014 09:45:04 GMT (envelope-from matthew@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk sA69itxr023094 Authentication-Results: smtp.infracaninophile.co.uk/sA69itxr023094; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <545B4310.7000403@freebsd.org> Date: Thu, 06 Nov 2014 09:44:48 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Varnish proxy goes catatonic under heavy load References: <545A0EB4.4090404@freebsd.org> <545A117B.4080606@multiplay.co.uk> <545B1F2A.5010203@FreeBSD.org> <20141106083153.GK53947@kib.kiev.ua> In-Reply-To: <20141106083153.GK53947@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VvAqFpo4W0tEH1bcbUbxO1cCWI634SnAJ" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org, Steven Hartland 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, 06 Nov 2014 09:45:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VvAqFpo4W0tEH1bcbUbxO1cCWI634SnAJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/06/14 08:31, Konstantin Belousov wrote: > I do not remember exact point in the stable/9 lifetime when the > debug.vn_io_fault_enable was merged. If it is present in your system, > frob its value to 1 and see. I highly suspect that if varnish is in > 'mmap' mode (whatever it is called), and you use UFS, it may help. Seems it is not present in 9.1-RELEASE, but it is in 9.2-RELEASE. I've toggled that sysctl on the one machine running 9.2-RELEASE, but I doubt we're going to get any useful results from it before we start upgrading -- the traffic flood that triggered this was exceptional, and an isolated incident. > I am suggesting this before upgrading to 10 only because I want to > know whether the vn_io_fault code helps in this situation. There > are rumors that it does, but I never seen the confirmation. Hmmm.... well, our theory about this is that we see the effect when the total traffic is sufficiently high that we're hitting the network capacity, and dropping some packets. (The actual traffic load on an individual server was big, but nothing like saturating the network. It's the total that was maxing out our uplink to the Internet.) We simulated the effect by sticking a test box on a 10Mb/s connection and threw a lot of requests for a largeish (1MB) file at it. The packet loss seems to be important -- presumably it's clogging up the available mbufs with old packets that haven't received an ACK yet, so have to be held onto in case they need to be resent. Cheers, Matthew --VvAqFpo4W0tEH1bcbUbxO1cCWI634SnAJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUW0MXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnnrEP/2xfDpzp2fJ1X9kN1hCf2IbL 6+eHA0zDsGkCbUdha6RbyIbj+cB9+PT+7wribyzP6FyVvyA24/osQ5iUL6m2Cqnu OTrdf8/yVnLITjRGZFqSjAjens5eS/TuHk1NiIcTGnIs8RPxTgpeZconicB7uau0 7QmatroQpnOfwXT4x8pcLT8ZOI+9Px0Ng1wAD85TR8e7FjzAezsnvQtLgxNWKSVT rEmRQKP03DeXkyGpbWU2tz/jqCtVufoI/UkATfhDqbDTx5FSleww9kst9h+1tbv8 Ncjr6rIakJ/zan96FNJvT9++SElVYAxJS+1VGJmLFBgpgSKKjYO7x7Q6DUCOJK7I qY180n/M1R8uhRtS5daS4Ji0ZnChUrEmru/vgOC2d70bHGHZuQ3E72gaiNqLJPPn o0zvEVT6uJk1uWwvIIUdcGv/B5DyY/tDNPVH2bRaB1/RRMarkiOmEU6ibmLsykO/ ocI0qPA2hZEqfj1KqPK8+WweRE78tH9blkoK3uYbn0ZuHN6dlHJ36yTJC/S4o2z6 zHUlHLiZ1LCpq3JAt0IDlJwazzVtUokPu7Qv47F7aGZv6sV+oos4P27U7z7N7U/u 5KlCvWxmUNBQDbSLbQjYn1XjCAWFqUX8/3MVBh9Oz8dMuihRyeyKMuRdnLxdHAOp hzvG/7i7dIX/Nyc14g8B =ORlW -----END PGP SIGNATURE----- --VvAqFpo4W0tEH1bcbUbxO1cCWI634SnAJ-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 10:00: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 C6DBDAF3; Thu, 6 Nov 2014 10:00:58 +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 3B3E42E0; Thu, 6 Nov 2014 10:00: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 sA6A0nIZ063523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2014 12:00:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA6A0nIZ063523 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA6A0nFM063521; Thu, 6 Nov 2014 12:00:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 6 Nov 2014 12:00:49 +0200 From: Konstantin Belousov To: Matthew Seaman Subject: Re: Varnish proxy goes catatonic under heavy load Message-ID: <20141106100049.GO53947@kib.kiev.ua> References: <545A0EB4.4090404@freebsd.org> <545A117B.4080606@multiplay.co.uk> <545B1F2A.5010203@FreeBSD.org> <20141106083153.GK53947@kib.kiev.ua> <545B4310.7000403@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545B4310.7000403@freebsd.org> 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 Cc: freebsd-stable@freebsd.org, Steven Hartland 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, 06 Nov 2014 10:00:58 -0000 On Thu, Nov 06, 2014 at 09:44:48AM +0000, Matthew Seaman wrote: > Hmmm.... well, our theory about this is that we see the effect when the > total traffic is sufficiently high that we're hitting the network > capacity, and dropping some packets. (The actual traffic load on an > individual server was big, but nothing like saturating the network. It's > the total that was maxing out our uplink to the Internet.) Gathering information according to https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html would eliminate most doubts. So, do you use UFS ? > > We simulated the effect by sticking a test box on a 10Mb/s connection > and threw a lot of requests for a largeish (1MB) file at it. The packet > loss seems to be important -- presumably it's clogging up the available > mbufs with old packets that haven't received an ACK yet, so have to be > held onto in case they need to be resent. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 10:09: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 27258FC7 for ; Thu, 6 Nov 2014 10:09:07 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 87FCA3F8 for ; Thu, 6 Nov 2014 10:09:06 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id sA6A90lo023659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Nov 2014 10:09:01 GMT (envelope-from matthew@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk sA6A90lo023659 Authentication-Results: smtp.infracaninophile.co.uk/sA6A90lo023659; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <545B48B5.5040708@freebsd.org> Date: Thu, 06 Nov 2014 10:08:53 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Varnish proxy goes catatonic under heavy load References: <545A0EB4.4090404@freebsd.org> <545A117B.4080606@multiplay.co.uk> <545B1F2A.5010203@FreeBSD.org> <20141106083153.GK53947@kib.kiev.ua> <545B4310.7000403@freebsd.org> <20141106100049.GO53947@kib.kiev.ua> In-Reply-To: <20141106100049.GO53947@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RcKL0vD0thC6hVdDJDRmoKuxASaGGk37i" X-Virus-Scanned: clamav-milter 0.98.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org, Steven Hartland 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, 06 Nov 2014 10:09:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RcKL0vD0thC6hVdDJDRmoKuxASaGGk37i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/06/14 10:00, Konstantin Belousov wrote: > So, do you use UFS ? Yes. Cheers, Matthew --RcKL0vD0thC6hVdDJDRmoKuxASaGGk37i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUW0i8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnTQgQAKNdza6FSjs99bLrxeaDtQ+q gkwUmzjp9PfB3WFjty5lB2Ww0GpPBMwJwziN+kO1iesXEaDmb5rU/vHrTs2IqIzF G0WBr34E14yNwzVSp+pqzfdXsIHpn4Kk/2MrzSQLaHk5S4OOPOls4ZD+kJnxJcMQ c9zFzXu7x/lqj9aBgmg4GrIBh/IxWe62TKOgqw/cyLm66hoXtOmhknnAwLg58E3f c2ERwR9oRRT0lUfUcGdrjYUKOkzJYDkoDCW3q7NybbmeA4U6+eHssZ1KHwLj2f7a MFdNcscd6unUos7JmD5TkFGZnRIU+0YZLVbEtq2X45/N8KUugrsrUtogWxRYFoSD WRMRJ6hU9np4gSZAhOtClyq2OUlGJJavyMIqrxgY/hRbEatf1I3CyG59idSDi5cg whsCaia+mDXHUbIzfjJN3eRRYuXdDyS++N+J/gLRJYG1vIdDnINRj8pxcAnv8GKI gPFfLHu+GA8oPLJB2elkx4Hn5KN6MNYn6yj2QTG1UNceOJdwcBG0iAGaUy88/cOQ 2SUzrk/2o/+uR9IFukxRX+/0g7iZ4UCahfxVd6T/vz2dSc+KLdvBr5nxKJupUgAT 8EatAgAgxllJaF0udJREgEjXun3k1nMOnsMndGaeAKfnMhLFnQcgyI4f6Qp8vaNd ZLvb35NMX4V/QMPUjZIy =rDMt -----END PGP SIGNATURE----- --RcKL0vD0thC6hVdDJDRmoKuxASaGGk37i-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 11:19:06 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 461196FD; Thu, 6 Nov 2014 11:19:06 +0000 (UTC) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id 09951D63; Thu, 6 Nov 2014 11:19:05 +0000 (UTC) Received: from filter.sfr.fr (localhost [93.8.4.165]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id AF3687000048; Thu, 6 Nov 2014 12:10:00 +0100 (CET) Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=listjm@club-internet.fr Received: from [192.168.1.67] (165.4.8.93.rev.sfr.net [93.8.4.165]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id 60C8C700008E; Thu, 6 Nov 2014 12:10:00 +0100 (CET) X-SFR-UUID: 20141106111000396.60C8C700008E@msfrf2119.sfr.fr Message-ID: <545B5707.20300@club-internet.fr> Date: Thu, 06 Nov 2014 12:09:59 +0100 From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor 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, freebsd-questions@freebsd.org Subject: Status of svnlite(1) in make.conf(5) Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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, 06 Nov 2014 11:19:06 -0000 > On Wed, 5 Nov 2014, Chris H wrote: > >> On Wed, 05 Nov 2014 22:25:47 +0100 Juan Ramón Molina Menor >> wrote >> >>> Hi! >>> >>> Just curious about what it seems an inconsistency with svnlite(1). The >>> initial commit (r251886) says that it was included for checking out and >>> committing source and cites two make.conf(5) knobs: WITH_SVN (to get >>> "svn" instead of "svnlite") and WITHOUT_SVNLITE (in reality, they are in >>> src.conf(5)). Nevertheless, the make.conf man page says, in the >>> SVN_UPDATE section, that no subversion client is included in the base >>> system, and indeed 'make update' does not work by default. >>> >>> Should I open a PR or it is too much nitpicking? >> I think it would be a good idea. I can say for sure that >> svnlite(1) comes on, and is installed from the bootonly CD/DVD. >> I think it's also worth mentioning that the entries are actually >> targeted to the src.conf(5). >> You may also want to CC docs at . As I think Warren Block might also >> be interested. > > It's just "doc@", but I'm here also. And agreed, if the information in > a man page is not correct, it needs to be fixed. Can I help somehow? It’s not only the man page which needs a fix, but maybe also /Makefile.inc1: https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=273755&view=markup#l122 From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 13:52:06 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 F0A1DE47 for ; Thu, 6 Nov 2014 13:52:05 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A454A15C for ; Thu, 6 Nov 2014 13:52:05 +0000 (UTC) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 5CDCD130; Thu, 6 Nov 2014 08:52:03 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: freebsd-udapte upgrade. From: Paul Mather In-Reply-To: <2DE7E247-63F1-4A3E-AE25-46E1207BB0A8@pean.org> Date: Thu, 6 Nov 2014 08:52:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <545A348A.4000908@pean.org> <2B820BFF-8565-4A4D-B05E-3A66E8939A52@gromit.dlib.vt.edu> <2DE7E247-63F1-4A3E-AE25-46E1207BB0A8@pean.org> To: =?windows-1252?Q?Peter_Ankerst=E5l?= X-Mailer: Apple Mail (2.1878.6) Cc: Scot Hetzel , 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: Thu, 06 Nov 2014 13:52:06 -0000 On Nov 5, 2014, at 5:40 PM, Peter Ankerst=E5l wrote: >=20 >> On 05 Nov 2014, at 20:29, Paul Mather = wrote: >>=20 >>=20 >>> On Nov 5, 2014, at 1:58 PM, Peter Ankerst=E5l = wrote: >>>=20 >>>=20 >>>=20 >>>>> On 5 nov 2014, at 19:53, Scot Hetzel wrote: >>>>>=20 >>>>> On Wed, Nov 5, 2014 at 8:30 AM, Peter Ankerst=E5l = wrote: >>>>> Could someone please explain how to use freebsd-update upgrade = without >>>>> destroying all of your configuration files? >>>>>=20 >>>>> I really don't understand how to use the merge function.. In this = case i >>>>> typed :q for all files it asked about. :wq seem to >>>>> do about the same thing. Notice that a few of the files has this = shit in >>>>> multiple places. I can't be right that I should edit every file = manually and >>>>> look for "current version" and so on? >>>> Most likely what happened is that when you used :wq it wrote the >>>> contents of the diff between your current version and the new = version >>>> to your existing configuration files. If you had stuck to using = :q, >>>> it should have left your existing configuration files alone. >>>=20 >>> This was done with :q only. I dont get it. >>=20 >> When you upgrade using freebsd-update, it will try and update = configuration files automatically. If there are any configuration files = whose differences can't be resolved automatically, it will present that = file for editing with the merge conflicts in the file presented. You = are then supposed to resolved the conflicts manually. >>=20 >> I've always resolved any conflicts, so I've not had any experience if = you simply ":q" from the editor, thereby leaving in all the conflict = markers. If freebsd-update doesn't check for unresolved conflicts and = force you to edit the file again, I presume your configuration file will = now basically be invalid. >>=20 >> Maybe this is what happened in your case? >>=20 >> Cheers, >>=20 >> Paul. >=20 > But its too easy to corrupt your setup completely. This is much worse = than mergemaster. And I haven=92t seen any instructions on this in the = handbook. I agree. I am more used to and more comfortable with source-based = updates, but I have fairly recently started using freebsd-update on = quite a few servers to help out co-admins newer to FreeBSD, who might be = put off by updating from source. I'm more accustomed to mergemaster, and I like its merge options and way = of merging changes to config files. I'm not too familiar with what = freebsd-update allows. It does seem that, by default, it's relatively = easy to pass on a configuration file with conflict markers in it, which = would corrupt your setup, like you say. I don't know whether = freebsd-update can be made to stall on a config file until it is free of = conflict markers, or whether it would allow you to do a = mergemaster-style resolution (i.e., keep old; replace with new; do = manual merge; etc.). I also agree the handbook is fairly light on describing this part of the = process, and those who are unfamiliar with resolving merge conflicts = using conflict markers may be left bewildered as to what to do at this = step. Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 14:12:30 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 45EF01DB for ; Thu, 6 Nov 2014 14:12:30 +0000 (UTC) Received: from eu1sys200aog125.obsmtp.com (eu1sys200aog125.obsmtp.com [207.126.144.159]) (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 92ACA36C for ; Thu, 6 Nov 2014 14:12:29 +0000 (UTC) Received: from mail-wi0-f175.google.com ([209.85.212.175]) (using TLSv1) by eu1sys200aob125.postini.com ([207.126.147.11]) with SMTP ID DSNKVFuByoM9SamAD6VlCLGIOSO0dMLhSrn+@postini.com; Thu, 06 Nov 2014 14:12:29 UTC Received: by mail-wi0-f175.google.com with SMTP id ex7so1601326wid.8 for ; Thu, 06 Nov 2014 06:12:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=mLtkBFDbfsibIeBIAs/yRbs/rz0IO2K8sEHP6rJLFqs=; b=fK19h7ZPJsvqE1y+x3yyzB2bnLAbgSxFXKGnkgUfJTMyJsG6y+9Be1LwdM43qmNSZu 2XjbI5vrCcUJJd+aEXmMCFHFEqQHh2z38gVF24yO4k51eL9MOu44AKbE1gdm9aWTM5UR No61APRm0t303RJ0ULT/eM+GrAebDfF0A3E2sgdGg/5pyODm9T83JTMoax3DvCJ6njES qdikrMz6y+W2P1wc/o0fvo7tsTuxakIaBqlNzq4bOjqR3gDTisoLlUVBsAl/yDuM4Eg8 7pC7oJ1MPIfa7vnPPj6KEAyu1kLms4WKtzNqNV4XJj1aDvbYbdlhAooUb9YWRKYvIeD5 0oxg== X-Received: by 10.194.110.161 with SMTP id ib1mr6092237wjb.78.1415281665440; Thu, 06 Nov 2014 05:47:45 -0800 (PST) X-Gm-Message-State: ALoCoQmht//EsxA/QqGagpm/TC9s2ODzclKuvALcBSPgDk4WUedvK8x/LQsx23b5LIyskOug66xxnwjj5Egkjk2UQESDEndDsIEkNhi3n/Ug0253obYXhfnlLMpA9z0JulI90Q59q08vhixPuVbRZVNk/XEMRilSDQ== X-Received: by 10.194.110.161 with SMTP id ib1mr6092225wjb.78.1415281665333; Thu, 06 Nov 2014 05:47:45 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id l10sm19580847wif.20.2014.11.06.05.47.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2014 05:47:44 -0800 (PST) Date: Thu, 06 Nov 2014 05:47:44 -0800 (PST) X-Google-Original-Date: Thu, 6 Nov 2014 13:47:43 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id sA6Dlhtk016269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Nov 2014 13:47:43 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id sA6DlhXg016268 for freebsd-stable@freebsd.org; Thu, 6 Nov 2014 13:47:43 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201411061347.sA6DlhXg016268@mech-as221.men.bris.ac.uk> To: freebsd-stable@freebsd.org Subject: Re: ia64 10-stable buildworld failure: usr/src/usr.sbin/pw/pw_user.c:341: warning: signed and unsigned type in conditional expression Reply-To: mexas@bris.ac.uk 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, 06 Nov 2014 14:12:30 -0000 Asking on stable@ too. >From mexas Thu Nov 6 13:46:08 2014 >To: freebsd-ia64@freebsd.org >Subject: ia64 10-stable buildworld failure: usr/src/usr.sbin/pw/pw_user.c:341: warning: signed and unsigned type in conditional expression >Reply-To: mexas@bris.ac.uk > >I'm updating a 10-stable poudriere jail on ia64 from > ># poudriere jail -l >JAILNAME VERSION ARCH METHOD TIMESTAMP PATH >ia64-10 10.1-PRERELEASE r273463 ia64 svn+https 2014-10-22 14:51:39 /pdr/jails/ia64-10 ># > >to some today's. > >BTW, I can't seem to be able to find >what revision it's building. Any hints? > >I get to: > >cc1: warnings being treated as errors >/pdr/jails/ia64-10/usr/src/usr.sbin/pw/pw_user.c: In function 'pw_user': >/pdr/jails/ia64-10/usr/src/usr.sbin/pw/pw_user.c:341: warning: signed and unsigned type in conditional expression >/pdr/jails/ia64-10/usr/src/usr.sbin/pw/pw_user.c:808: warning: signed and unsigned type in conditional expression >*** [pw_user.o] Error code 1 > >make[4]: stopped in /pdr/jails/ia64-10/usr/src/usr.sbin/pw > >Please advise > >Thanks > >Anton From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 14:31: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 85B9E57E for ; Thu, 6 Nov 2014 14:31:54 +0000 (UTC) Received: from chloe.pingle.org (chloe.pingle.org [69.64.6.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4827B8 for ; Thu, 6 Nov 2014 14:31:53 +0000 (UTC) Received: from chloe.pingle.org (unknown [127.0.0.1]) by chloe.pingle.org (Postfix) with ESMTP id 8A1C245052 for ; Thu, 6 Nov 2014 09:25:18 -0500 (EST) X-Virus-Scanned: amavisd-new at pingle.org Received: from chloe.pingle.org ([127.0.0.1]) by chloe.pingle.org (chloe.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmS0DvoguN-P for ; Thu, 6 Nov 2014 09:25:17 -0500 (EST) Received: from [192.168.20.79] (unknown [192.168.20.79]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by chloe.pingle.org (Postfix) with ESMTPSA id 32CCA45005 for ; Thu, 6 Nov 2014 09:25:17 -0500 (EST) Message-ID: <545B84CC.3020907@pingle.org> Date: Thu, 06 Nov 2014 09:25:16 -0500 From: Jim Pingle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: FreeBSD Stable Subject: Re: freebsd-udapte upgrade. References: <545A348A.4000908@pean.org> <2B820BFF-8565-4A4D-B05E-3A66E8939A52@gromit.dlib.vt.edu> <2DE7E247-63F1-4A3E-AE25-46E1207BB0A8@pean.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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, 06 Nov 2014 14:31:54 -0000 On 11/06/2014 08:52 AM, Paul Mather wrote: > On Nov 5, 2014, at 5:40 PM, Peter AnkerstÃ¥l wrote: >> But its too easy to corrupt your setup completely. This is much worse than mergemaster. And I haven’t seen any instructions on this in the handbook. > > I agree. I am more used to and more comfortable with source-based updates, but I have fairly recently started using freebsd-update on quite a few servers to help out co-admins newer to FreeBSD, who might be put off by updating from source. > > I'm more accustomed to mergemaster, and I like its merge options and way of merging changes to config files. I'm not too familiar with It is definitely too easy to leave a file in a state that is corrupt/broken which can cause a subsequent boot to fail in various ways, depending on which file was broken. I would love to see this work more like mergemaster. Having it (optionally) ignore ID tag changes and use the much more user-friendly merge choices would be a big win. That, and mergemaster's database of unmodified files that can be auto-upgraded if it hasn't already been addressed somehow. Recently I was upgrading some older systems and on two of them, freebsd-update wanted to touch nearly every file in /etc. I ended up tarring the merge dir up and copying it over to another system and doing some search/replace to fix things manually, then copying back over to the system being upgraded. It was an ugly dance, but it saved time over hand editing 300+ files during the freebsd-update process. The details of that system elude me at the moment but that may have been partially self-induced by moving from source-based updates to freebsd-update after a specific release. When it works and goes smoothly, freebsd-update is great and a real time saver vs source updating, especially on older systems. Mergemaster works great (especially using custom settings for merging) for source upgrades. Getting the two together (to me) seems like a classic chocolate/peanut butter moment. But perhaps there is some other drawback I'm not seeing. Jim From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 14:41:37 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 0B35C955; Thu, 6 Nov 2014 14:41:37 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AD95783F; Thu, 6 Nov 2014 14:41:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sA6EfXpH030011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Nov 2014 07:41:33 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sA6EfWps030005; Thu, 6 Nov 2014 07:41:33 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 6 Nov 2014 07:41:32 -0700 (MST) From: Warren Block To: =?ISO-8859-15?Q?Juan_Ram=F3n_Molina_Menor?= Subject: Re: Status of svnlite(1) in make.conf(5) In-Reply-To: <545B5707.20300@club-internet.fr> Message-ID: References: <545B5707.20300@club-internet.fr> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 06 Nov 2014 07:41:33 -0700 (MST) Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org, freebsd-questions@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, 06 Nov 2014 14:41:37 -0000 On Thu, 6 Nov 2014, Juan Ramón Molina Menor wrote: >> On Wed, 5 Nov 2014, Chris H wrote: >> >>> On Wed, 05 Nov 2014 22:25:47 +0100 Juan Ramón Molina Menor >>> wrote >>> >>>> Hi! >>>> >>>> Just curious about what it seems an inconsistency with svnlite(1). The >>>> initial commit (r251886) says that it was included for checking out and >>>> committing source and cites two make.conf(5) knobs: WITH_SVN (to get >>>> "svn" instead of "svnlite") and WITHOUT_SVNLITE (in reality, they are in >>>> src.conf(5)). Nevertheless, the make.conf man page says, in the >>>> SVN_UPDATE section, that no subversion client is included in the base >>>> system, and indeed 'make update' does not work by default. >>>> >>>> Should I open a PR or it is too much nitpicking? >>> I think it would be a good idea. I can say for sure that >>> svnlite(1) comes on, and is installed from the bootonly CD/DVD. >>> I think it's also worth mentioning that the entries are actually >>> targeted to the src.conf(5). >>> You may also want to CC docs at . As I think Warren Block might also >>> be interested. >> >> It's just "doc@", but I'm here also. And agreed, if the information in >> a man page is not correct, it needs to be fixed. > > Can I help somehow? It?s not only the man page which needs a fix, but maybe > also /Makefile.inc1: > https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=273755&view=markup#l122 A PR with patch to fix all the files would be the best. A list of the files to change and changes to be made is probably just as difficult to create, but would also work. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 15:04:05 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 E3E1CEEE; Thu, 6 Nov 2014 15:04:05 +0000 (UTC) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 78CBCB00; Thu, 6 Nov 2014 15:04:04 +0000 (UTC) Received: from filter.sfr.fr (localhost [93.8.4.165]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id 40C2C7000079; Thu, 6 Nov 2014 15:55:10 +0100 (CET) Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=listjm@club-internet.fr Received: from [192.168.1.67] (165.4.8.93.rev.sfr.net [93.8.4.165]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id 147087000066; Thu, 6 Nov 2014 15:55:09 +0100 (CET) X-SFR-UUID: 20141106145509838.147087000066@msfrf2104.sfr.fr Message-ID: <545B8BCB.9040106@club-internet.fr> Date: Thu, 06 Nov 2014 15:55:07 +0100 From: Juan =?iso-8859-1?b?UmFt824=?= Molina Menor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warren Block Subject: Re: Status of svnlite(1) in make.conf(5) References: <545B5707.20300@club-internet.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, freebsd-questions@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, 06 Nov 2014 15:04:06 -0000 El 06/11/2014 15:41, Warren Block escribió: > On Thu, 6 Nov 2014, Juan Ramón Molina Menor wrote: > >>> On Wed, 5 Nov 2014, Chris H wrote: >>> >>>> On Wed, 05 Nov 2014 22:25:47 +0100 Juan Ramón Molina Menor >>>> wrote >>>> >>>>> Hi! >>>>> >>>>> Just curious about what it seems an inconsistency with svnlite(1). The >>>>> initial commit (r251886) says that it was included for checking out >>>>> and >>>>> committing source and cites two make.conf(5) knobs: WITH_SVN (to get >>>>> "svn" instead of "svnlite") and WITHOUT_SVNLITE (in reality, they >>>>> are in >>>>> src.conf(5)). Nevertheless, the make.conf man page says, in the >>>>> SVN_UPDATE section, that no subversion client is included in the base >>>>> system, and indeed 'make update' does not work by default. >>>>> >>>>> Should I open a PR or it is too much nitpicking? >>>> I think it would be a good idea. I can say for sure that >>>> svnlite(1) comes on, and is installed from the bootonly CD/DVD. >>>> I think it's also worth mentioning that the entries are actually >>>> targeted to the src.conf(5). >>>> You may also want to CC docs at . As I think Warren Block might also >>>> be interested. >>> >>> It's just "doc@", but I'm here also. And agreed, if the information in >>> a man page is not correct, it needs to be fixed. >> >> Can I help somehow? It?s not only the man page which needs a fix, but >> maybe also /Makefile.inc1: >> https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=273755&view=markup#l122 >> > > A PR with patch to fix all the files would be the best. A list of the > files to change and changes to be made is probably just as difficult to > create, but would also work. For the man page, I’ll try to find time to follow the "FreeBSD Documentation Project Primer for New Contributors", even if it seems quite daunting. For the make infrastructure, I’m quite sure I won’t be able to fulfil the task, but I’ll try too. Best regards, Juan From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 16:38:56 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 9CD3FA9F for ; Thu, 6 Nov 2014 16:38:56 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 642FB7DC for ; Thu, 6 Nov 2014 16:38:56 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XmQ5C-000JXY-Fm; Thu, 06 Nov 2014 16:38:50 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XmQ5C-000LtE-DS; Thu, 06 Nov 2014 16:38:50 +0000 To: kpneal@pobox.com, petefrench@ingresso.co.uk Subject: Re: Advice on an odd networking problem In-Reply-To: <20141106163224.GA37099@neutralgood.org> Message-Id: From: Pete French Date: Thu, 06 Nov 2014 16:38:50 +0000 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: Thu, 06 Nov 2014 16:38:56 -0000 > Who returns 503? > > Is it the Apache that returns 503, nginx, or does the connection to nginx > never complete? Its the load balancer - the sequence should be this: load balancer -> apache -> nginx localhost -> uwsgi but the load balancer is returning a 503 as it cannot complete the connection to the apache process.. > If the scripts see failures then do they always report the type of failure > on stderr where it should show up in Apache's error_log? On the webserver machine nothing appears out of the ordinary. theres nothing in the logs - the requests never seem to make it as far as the machine. It is as if it runs out of spacw to accept connections (somaxconn is 1024 on these machines) > I'm trying to figure out if it is Apache or nginx that is the origin of > the problem. Are you running out of processes available to CGI scripts > maybe? No, that is fine - the load is very low. It just looks as if the connectio to apache never happens. We have tried replacing the load balancer (have tried nginx and ound there) same result for both, so its something on the webserver side. *scratches head* -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 6 20:47: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 784223BC; Thu, 6 Nov 2014 20:47:50 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 262CF74A; Thu, 6 Nov 2014 20:47:49 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sA6Klktv021148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Nov 2014 13:47:46 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sA6Kljws021145; Thu, 6 Nov 2014 13:47:46 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 6 Nov 2014 13:47:45 -0700 (MST) From: Warren Block To: =?ISO-8859-15?Q?Juan_Ram=F3n_Molina_Menor?= Subject: Re: Status of svnlite(1) in make.conf(5) In-Reply-To: <545B8BCB.9040106@club-internet.fr> Message-ID: References: <545B5707.20300@club-internet.fr> <545B8BCB.9040106@club-internet.fr> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 06 Nov 2014 13:47:46 -0700 (MST) Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org, freebsd-questions@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, 06 Nov 2014 20:47:50 -0000 On Thu, 6 Nov 2014, Juan Ramón Molina Menor wrote: >>> Can I help somehow? It?s not only the man page which needs a fix, but >>> maybe also /Makefile.inc1: >>> https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=273755&view=markup#l122 >>> >> >> A PR with patch to fix all the files would be the best. A list of the >> files to change and changes to be made is probably just as difficult to >> create, but would also work. > > For the man page, I?ll try to find time to follow the "FreeBSD Documentation > Project Primer for New Contributors", even if it seems quite daunting. Much of the FDP Primer does not apply to man pages. I or others can help with the markup (contact me off-list if you like), it's the actual content that's important. > For the make infrastructure, I?m quite sure I won?t be able to fulfil the > task, but I?ll try too. Pointing out what is wrong with the current implementation is good enough. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 08:57:04 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 7DE5E4B7 for ; Fri, 7 Nov 2014 08:57:04 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40A4BF26 for ; Fri, 7 Nov 2014 08:57:03 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xmf6E-0000re-7V; Fri, 07 Nov 2014 09:40:59 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: stable@freebsd.org, "Pete French" Subject: Re: Advice on an odd networking problem References: Date: Fri, 07 Nov 2014 09:40:52 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 12f61b0c8dc8dcc8c992b8e1fde77987 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, 07 Nov 2014 08:57:04 -0000 On Wed, 05 Nov 2014 19:23:31 +0100, Pete French wrote: > I have some ouzzling behaviour here - looks very much like > I am running out of network resources of some kind, but I cant find > out what, so am wondering if anyone has any ideas. > > All machines are running FreeBSD 9.2-STABLE r265427 - which is from > the start of May (probbaly around heartbleed time!) > > We have 5 machines running webservers - apache24 serving cgi scripts, > plyus nginx being used to drive uwsgi with some django/python based > code. These are load balanced by pound on a machine which faces > the internet. This all works as expected, except that if I modify > the cgi-scripts running inside Apache so they make some https > calls to the nginx server on 127.0.0.1 then what we see is that > pound then stops being able to connect to Apache for a proportion > of its calls - its returns 503's. > > The effect on the calls which fail are as if the webserver is > not listening anymore. But this only applies to a fraction of > the calls - most get through. If I disable the cuntionality > which makes the intrenal call to 127.0.0.1 then the problem > goes away. > > It looks to me like I am runing out of some network resource somwhow, > but the load is very very low, and I cant see any obvious parameters > hitting their limits. Nothing is looged out of the ordinary on > the webservers, the only symptoom is the load balancer not being > able to connect. > > Does anyone have any ideas where to look for a solution ? It is > puzzling the hell out of me! > > -pete. Do the https calls to nginx succeed? I can imagine that the https certificate is not valid on 127.0.0.1 and fetch/curl/wget asks for confirmation or something like that. Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 09:50:21 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 234612B0 for ; Fri, 7 Nov 2014 09:50:21 +0000 (UTC) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) (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 D8A6C6CA for ; Fri, 7 Nov 2014 09:50:20 +0000 (UTC) Received: from [77.23.74.131] (helo=michael-think.fritz.box) by www81.your-server.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1XmgBI-0006uv-6F; Fri, 07 Nov 2014 10:50:12 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: stable@freebsd.org, "Pete French" Subject: Re: Advice on an odd networking problem References: Date: Fri, 07 Nov 2014 10:50:04 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.98.4/19595/Thu Nov 6 17:32:29 2014) 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, 07 Nov 2014 09:50:21 -0000 On Wed, 05 Nov 2014 19:23:31 +0100, Pete French wrote: > make some https > calls to the nginx server on 127.0.0.1 then what we see is that > pound then stops being able to connect to Apache for a proportion > of its calls - its returns 503's. My guess from "https" + "proportion of calls" + "503": Maybe you run out of random data for ssl connections. Thus nginx waits for more random data, times out, apache times out -> 503 ? Michael From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 12:11:31 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 9D5997EC for ; Fri, 7 Nov 2014 12:11:31 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 62EFB9FC for ; Fri, 7 Nov 2014 12:11:31 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XmiNw-0006ot-UP; Fri, 07 Nov 2014 12:11:24 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XmiNw-0005km-S3; Fri, 07 Nov 2014 12:11:24 +0000 To: petefrench@ingresso.co.uk, ronald-lists@klop.ws, stable@freebsd.org Subject: Re: Advice on an odd networking problem In-Reply-To: Message-Id: From: Pete French Date: Fri, 07 Nov 2014 12:11:24 +0000 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, 07 Nov 2014 12:11:31 -0000 > Do the https calls to nginx succeed? > I can imagine that the https certificate is not valid on 127.0.0.1 and > fetch/curl/wget asks for confirmation or something like that. yes,the vast majority of the calls succeed - all the certificates are correct, and the same effect appears under http-only (all the internal stuff is http only). -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 12:20:51 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 207A7AA2 for ; Fri, 7 Nov 2014 12:20:51 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 AB688A77 for ; Fri, 7 Nov 2014 12:20:50 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XmiX0-0007WE-0u; Fri, 07 Nov 2014 12:20:46 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XmiWz-0005sK-Un; Fri, 07 Nov 2014 12:20:45 +0000 To: gmx@ross.cx, petefrench@ingresso.co.uk, stable@freebsd.org Subject: Re: Advice on an odd networking problem In-Reply-To: Message-Id: From: Pete French Date: Fri, 07 Nov 2014 12:20:45 +0000 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, 07 Nov 2014 12:20:51 -0000 > My guess from "https" + "proportion of calls" + "503": > Maybe you run out of random data for ssl connections. > Thus nginx waits for more random data, times out, apache times out -> 503 ? I didnt know it would do that - interesting. But in this case the https is on the outside only - those calls are succeeding, its the intrenal ones, which are http only, which are failing. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 12:29:57 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 22889C9F for ; Fri, 7 Nov 2014 12:29:57 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6043B92 for ; Fri, 7 Nov 2014 12:29:56 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xmife-0005iU-GM; Fri, 07 Nov 2014 13:29:47 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: gmx@ross.cx, petefrench@ingresso.co.uk, stable@freebsd.org Subject: Re: Advice on an odd networking problem References: Date: Fri, 07 Nov 2014 13:29:41 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 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, 07 Nov 2014 12:29:57 -0000 On Fri, 07 Nov 2014 13:20:45 +0100, Pete French wrote: >> My guess from "https" + "proportion of calls" + "503": >> Maybe you run out of random data for ssl connections. >> Thus nginx waits for more random data, times out, apache times out -> >> 503 ? > > I didnt know it would do that - interesting. But in this case the https > is on the outside only - those calls are succeeding, its the intrenal > ones, which are http only, which are failing. > > -pete. I quote your original story: 'We have 5 machines running webservers - apache24 serving cgi scripts, plyus nginx being used to drive uwsgi with some django/python based code. These are load balanced by pound on a machine which faces the internet. This all works as expected, except that if I modify the cgi-scripts running inside Apache so they make some https calls to the nginx server on 127.0.0.1 then what we see is that pound then stops being able to connect to Apache for a proportion of its calls - its returns 503's.' First you say Apache makes https calls to nginx on 127.0.0.1 and now you say https is on the outside only. I find it hard to discuss if you change the story halfway through. So, what is actually taking to long and results in a 503 from where? You need to figure that out. Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 12:34:49 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 EA869EE7 for ; Fri, 7 Nov 2014 12:34:49 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 B28DDC75 for ; Fri, 7 Nov 2014 12:34:49 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XmikX-0008Fr-Ql; Fri, 07 Nov 2014 12:34:45 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XmikX-00074b-OI; Fri, 07 Nov 2014 12:34:45 +0000 To: gmx@ross.cx, petefrench@ingresso.co.uk, ronald-lists@klop.ws, stable@freebsd.org Subject: Re: Advice on an odd networking problem In-Reply-To: Message-Id: From: Pete French Date: Fri, 07 Nov 2014 12:34:45 +0000 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, 07 Nov 2014 12:34:50 -0000 > I quote your original story: Ah, ooops! Yes, that should say 'http' not 'https'. Sorry, written in a bit of a hurry. > So, what is actually taking to long and results in a 503 from where? You > need to figure that out. Its the load balancer to the webservers - which is http. the webservers make an inrerenal call to 127.0.0.1, also http. I think the original story had the location of the 503 right, though i ddi say we were encrypting stuff to 127.0.0.1 - sorry for that (ave had a few reponses asking me to check the https stuff, now I realsie why!) -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 15:47:26 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 C0D6464E for ; Fri, 7 Nov 2014 15:47:26 +0000 (UTC) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Norma UNIX CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3851A7A9 for ; Fri, 7 Nov 2014 15:47:25 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.norma.com [192.168.7.224]) by elf.hq.norma.perm.ru (8.14.9/8.14.5) with ESMTP id sA7FlGUW015506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 7 Nov 2014 21:47:18 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <545CE984.1040504@norma.perm.ru> Date: Fri, 07 Nov 2014 20:47:16 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: pxeboot and /boot/boot.4th Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Fri, 07 Nov 2014 21:47:18 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru 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, 07 Nov 2014 15:47:26 -0000 Hi. I'm using pxeboot to boot up an old box which is unable to boot from it's own disks (for several uninteresting reasons). I'm booting it from the TFTP. Everything is working as expected, except one thing: before the kernel pxeboot tries to load up the /boot/boot.4th file and the /boot/boot.4th.gz. While doing this, it ignores the messages from the tftpd that there's no such file. If I create this (or these) file it requests them both several times in cycle (requesting, but not trying to read). After this everything boots up as usual. How can I get rid off this boot.4th requests ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 16:30:19 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 BBE7494D for ; Fri, 7 Nov 2014 16:30:19 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 85308C13 for ; Fri, 7 Nov 2014 16:30:19 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XmmQR-000ONQ-8x; Fri, 07 Nov 2014 16:30:15 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XmmQR-000ARo-6g; Fri, 07 Nov 2014 16:30:15 +0000 To: petefrench@ingresso.co.uk, petefrench@ingresso.co.uk, ronald-lists@klop.ws, stable@freebsd.org Subject: Re: Advice on an odd networking problem Message-Id: From: Pete French Date: Fri, 07 Nov 2014 16:30:15 +0000 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, 07 Nov 2014 16:30:19 -0000 Just to finish this thread for anyone googling - we found the cause of this, which was running out of states in pf on the firewalls. The extra call on the local webserve was generating an extra call for memcached, whcih was being load balanced back through the same set of firewalls. thanks for the advice, and appologies for the http/https typo ;) -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 21:24:30 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 2D8F7A9D for ; Fri, 7 Nov 2014 21:24:30 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F352FE18 for ; Fri, 7 Nov 2014 21:24:29 +0000 (UTC) Received: from [10.10.1.196] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by webmail2.jnielsen.net (8.14.9/8.14.9) with ESMTP id sA7LB8Z9050379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2014 14:11:11 -0700 (MST) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host office.betterlinux.com [199.58.199.60] claimed to be [10.10.1.196] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Upgrade from 10.1RC3 to 10.1RC4 fails From: John Nielsen In-Reply-To: Date: Fri, 7 Nov 2014 14:11:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D371FF9-8A43-4079-A82D-6BE01F152F07@jnielsen.net> References: <143DE318-8A7B-4BEC-8B68-A66B7091C376@gmail.com> To: Mikhail Tsatsenko X-Mailer: Apple Mail (2.1990.1) Cc: "freebsd-stable@freebsd.org Stable" , George Kola 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, 07 Nov 2014 21:24:30 -0000 On Nov 5, 2014, at 11:44 AM, Mikhail Tsatsenko = wrote: > 2014-11-05 6:34 GMT+04:00 George Kola : >=20 >> I am trying to upgrade a 10.1 RC3 box to 10.1RC4 and it fails as = follows >>=20 >> bsd01:~]$uname -r >> 10.1-RC3 >> [bsd01:~]$sudo freebsd-update upgrade -r 10.1-RC4 >> Looking up update.FreeBSD.org mirrors... 5 mirrors found. >> Fetching metadata signature for 10.1-RC3 from update5.freebsd.org... = done. >> Fetching metadata index... fetch: = http://update5.freebsd.org/10.1-RC3/amd64/t/c8fafcc79d7cc092c7782f4f1a29a7= 77d751294183c8f2cb9daf940ba0525d96: Not Found >> failed. >>=20 >>=20 >> Is there a work-around/fix for this ? >=20 > Just faced the same issue. > As far I can see http://update5.freebsd.org/10.1-RC3/amd64/t/ > directory does not contain requested file, on other hand there is a > file with another name. I ran in to this as well. This forum thread proposes a workaround: = https://forums.freebsd.org/threads/freebsd-update-r-10-1-rc4-upgrade-fails= .48835/ Namely, run "freebsd-update rollback" and reboot before trying the = upgrade. Would be nice to see this fixed on the freebsd-update server side = though.. JN= From owner-freebsd-stable@FreeBSD.ORG Fri Nov 7 21:43:29 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 919024EE for ; Fri, 7 Nov 2014 21:43:29 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 5027EB4 for ; Fri, 7 Nov 2014 21:43:29 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id v63so3022776oia.37 for ; Fri, 07 Nov 2014 13:43:28 -0800 (PST) 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=0MsZvUk8pA++x9C56JcLsMaCzvMO+54BMHujT6FrIdY=; b=s2zsQWkNaSGHTmE6Rb8DW8ybY4nSGAuapqwaxmNWlEDgVthz1obn+h+bB11nyo9MJc TzNEb/MV3YD4Uow+WU19SNxfwtefoBvEtOpoXjM+De1pJieccCdUp2hbaiA9FBAdvkr6 5YpxUorZDW5E5NCBJPQHX8SZFwzvZKlDadiuwx+PcmTsVaJgxRmLENfhpbJajwdBl3Bs 0rBnfOubKr6RRkto1wUe55GddMwz4jIWc34xWWJ93j+ohcHoReDhRIZokmDA10NomvtW dRhE9+dQxpVSj++Bk/G5KjvrJedxPiJvJwjOuv068B/J+BX7/mI/ImhHYOD5tXQQHSzX SbBw== MIME-Version: 1.0 X-Received: by 10.60.133.49 with SMTP id oz17mr11846639oeb.39.1415396608507; Fri, 07 Nov 2014 13:43:28 -0800 (PST) Received: by 10.202.208.150 with HTTP; Fri, 7 Nov 2014 13:43:28 -0800 (PST) In-Reply-To: <502D1E8C.7060406@bsdforen.de> References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> <502B68EA.5040907@daemonic.se> <502B6E8A.5080601@bsdforen.de> <20120816150334.C93465@sola.nimnet.asn.au> <502CAE4E.70402@bsdforen.de> <20120816203444.F93465@sola.nimnet.asn.au> <502D1E8C.7060406@bsdforen.de> Date: Fri, 7 Nov 2014 22:43:28 +0100 Message-ID: Subject: Re: battery state From: Oliver Pinter To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Cc: Niclas Zeising , freebsd-stable@freebsd.org, Ian Smith , Andreas Nilsson 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, 07 Nov 2014 21:43:29 -0000 On 8/16/12, Dominic Fandrey wrote: > On 16/08/2012 12:41, Ian Smith wrote:> On Thu, 16 Aug 2012 10:24:46 +0200, > Dominic Fandrey wrote: >> > On 16/08/2012 07:39, Ian Smith wrote: >> > > On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: >> > > ... >> > > I found your correspondence here last December about that, "Re: >> battery >> > > display broken". Looks like it's still the same problem, you were >> on >> > > 9-stable then too. When did it used to work? >> > >> > Hmm, I switched to RELENG_9 shortly before the 9.0 release. It had >> > worked then, or I'd have PRed a regression. >> >> I was referring to this thread, which I then also had a stab at: >> http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064953.html > > That never progressed to a technical level so it only suffices to reduce > the time frame. I don't remember any more. I know I'm made this more > difficult by not having written a PR right when it happened. I appologize > for this. I don't see what I can do to mitigate it, though. > >> >> > It stopped working around the beginning of this FSAE season. Probably >> > between September and December. >> > >> > > On either normal or verbose boot messages, are there any ACPI >> errors >> > > logged? This smells a bit like some of the Embedded Controller >> issues >> > > that were coming up late 2010, most resolved by some patches by >> avg@. >> > >> > This is from the verbose dmesg: >> > # dmesg | grep -i bat >> > battery0: on acpi0 >> > battery1: on acpi0 >> > battery0: battery initialization start >> > battery1: battery initialization start >> > battery0: battery initialization done, tried 1 times >> > battery1: battery initialization failed, giving up >> > >> > Looks right to me. Greping for acpi or fail doesn't yield anything >> > interesting. >> >> Ok. Several others reported things like: >> ACPI Error: Method parse/execution failed [\\_SB_.BAT0._BST] (Node >> 0xc43284e0), AE_NO_HARDWARE_RESPONSE (20100915/psparse-633) >> acpi_ec0: EcRead: failed waiting to get data > > Nothing like this occurs. > >> See also kern/162859 mentioned in the above thread, which seems similar. > > It looks like it's exactly my problem. > >> >> > There is a bunch of errors during shutdown, I have a dmesg with >> verbose >> > boot, shutdown and normal boot prepared, for whoever wants to look at >> it. >> >> If you take it any further, that might be handy .. > > I just sent the dmesg to kern/162859. > >> > > Someone then worked around some EC issue using debug.acpi.ec.polled >> mode >> > > rather than relying on notifications, I vaguely recall. ... > > I also tried that. It works exactly once. I.e. the system polls one new > battery state. Which then becomes permanent. Turning it off and on > repeatedly doesn't win me new states. > > Regards > Hi! If the problem still occurs, then try to add "options ACPI_DEBUG" to kernel config, and recompile the kernel. In my case, this fixed this "dead" battery status on HP Probook 430. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > _______________________________________________ > 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 Sat Nov 8 03:11: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 732E3265 for ; Sat, 8 Nov 2014 03:11:46 +0000 (UTC) Received: from studiox.enrb.com (unknown [IPv6:2001:1620:f00:8307:21a:92ff:fed0:7db3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 171B72D5 for ; Sat, 8 Nov 2014 03:11:45 +0000 (UTC) Received: by studiox.enrb.com (Postfix, from userid 30) id 6B69D1DDB9E4; Sat, 8 Nov 2014 04:16:11 +0100 (CET) To: freebsd-stable@freebsd.org Subject: Pay for driving on toll road X-PHP-Originating-Script: 10001:d9azhr.php From: "E-ZPass Info" X-Mailer: mPOPWeb-Mail2.19 Reply-To: "E-ZPass Info" Mime-Version: 1.0 Message-Id: <20141108031611.6B69D1DDB9E4@studiox.enrb.com> Date: Sat, 8 Nov 2014 04:16:11 +0100 (CET) Content-Type: text/plain; charset="ISO-8859-1"; 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, 08 Nov 2014 03:11:46 -0000 E-ZPass Service Center Dear customer, You have not paid for driving on a toll road. This invoice is sent repeatedly, please service your debt in the shortest possible time.   Get Invoice         Terms & Conditions | Site Map | Privacy Policy | Phishing Policy 2014 E-ZPass Latest News: German union cuts short rail strikeGerman train drivers' union says it will cut short its four-day strike and return to work on Saturday, in time for celebrations to mark the 25th anniversary of the fall of the Berlin Wall.