From owner-freebsd-current@FreeBSD.ORG Sun Nov 17 21:27:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9171559E; Sun, 17 Nov 2013 21:27:27 +0000 (UTC) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E06B254B; Sun, 17 Nov 2013 21:27:26 +0000 (UTC) Received: from badger.tharned.org (badger.tharned.org [10.10.10.23]) (authenticated bits=0) by roadkill.tharned.org (8.14.7/8.14.7) with ESMTP id rAHLREoo010596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2013 15:27:15 -0600 (CST) (envelope-from gcr@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2013; t=1384723635; bh=udZ9wFQDXIG1MdzPJwuUjoRzzCqCX6vhScvPPVEYjAU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=4rMMVFWW2k7036uNOMg70aCbQAZbtQOlJYYwPcxeJ3JViuLh/+L1ShS+3slUHWhay 3OI7EplRuLlgtIjOT+xyDaHg5FYXK1Lyok5nZk7rG2Oot/1u4Q+weuVOXLKRCjuIxL gMWM7zHWavtDOgKYF2O2gCGfPSQFfeWk/b9suuyY= Date: Sun, 17 Nov 2013 15:27:14 -0600 (CST) From: Greg Rivers To: Erwin Lansing Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf In-Reply-To: <20131112111322.GV90670@droso.dk> Message-ID: References: <20131103220654.GU52889@FreeBSD.org> <6AA4A8E1-CBCE-4C87-A320-BB08EC76715F@lassitu.de> <20131104083443.GZ52889@FreeBSD.org> <2B21E123-23BA-4E07-B9DD-9DE1CDE40D08@FreeBSD.org> <20131104163457.GJ52889@FreeBSD.org> <868B00D6-101A-4B17-995F-A3E2AFE41908@lansing.dk> <20131112111322.GV90670@droso.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (roadkill.tharned.org [75.145.12.185]); Sun, 17 Nov 2013 15:27:15 -0600 (CST) X-Mailman-Approved-At: Sun, 17 Nov 2013 21:39:08 +0000 Cc: FreeBSD Stable , Stefan Bethke , FreeBSD Current , Gleb Smirnoff , FreeBSD Release Engineering Team , George Kontostanos , =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , =?ISO-8859-15?Q?=D6zkan_KIRIK?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 21:27:27 -0000 On Tue, 12 Nov 2013, Erwin Lansing wrote: > Sorry about the delay, but I did finally update all three dns/bind9* > ports today. > Thanks a lot for your work on this very important port. > I have dropped the complicated chroot, and related symlinking, logic > from the default rc script as I don't think that is the right place to > implement things. > I am somewhat astonished by this decision. FreeBSD has been running named chrooted for as long as I can remember. One of the really nice things about running BIND on FreeBSD has been that it came perfectly configured out of the box. I think a lot of people are going to be surprised by this. Maybe the rc script is the wrong place to set up the chroot, but shouldn't the port at least set it up at install time? Without this, there is going to be a lot of duplicated and error prone effort with everyone setting up their own chroot environment. > I would recommend users who want the extra security to use jail(8) > instead of a mere chroot. > Is it the consensus that running named chrooted doesn't really add additional security? If a jail is that much better, shouldn't the port set up an appropriately configured jail so that we once again have everything working out of the box? Maybe the Capsicum framework will supersede both chroots and jails for added BIND security, but until then, shouldn't the chroot feature be retained? -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Sun Nov 17 23:09:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADB3CC9B; Sun, 17 Nov 2013 23:09:12 +0000 (UTC) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDE892B56; Sun, 17 Nov 2013 23:09:11 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id f15so268946eak.25 for ; Sun, 17 Nov 2013 15:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=9JhQdvAs5+jD0Qs/gm3vGXoKD2I5ED1Rr63BFPP9G4Y=; b=jA+duaKysm+lYhos+xqy6q7TTtjxwWUNK27Tvv0L9z1x2oVrOqabcb7r9dvfFrtE/T 9pNAQsggWNMMzYyHtQ9wnnQtPjQRVSN4QNDNoYOD8SaUo2W0Ee9EADPNRwfgEyUmRbtg +I/v3XDUOiHvFdHmYNq58tdiwkIN9vlAJYLUTtdH2IyN+QE7lPv7buRn1sRibDmei8VA lGkkOnQ2liEFW9hvXI2RGChoKHWLCASs8t8s0BKD7Lbg41r+BoQ+mIUknIwWD1XEs9Q9 PoUjt7b+6yQ4QQnnxwfSSgA91s02wTaxRxm68QnfEUMVzGmtC5f/gqL9qe/KJOUuX3aW WQ4g== X-Received: by 10.15.65.11 with SMTP id p11mr345117eex.49.1384729749539; Sun, 17 Nov 2013 15:09:09 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id o47sm31544449eem.21.2013.11.17.15.09.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 15:09:08 -0800 (PST) Sender: Alexander Motin Message-ID: <52894C92.60905@FreeBSD.org> Date: Mon, 18 Nov 2013 01:09:06 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" Subject: UMA cache back pressure Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 23:09:12 -0000 Hi. I've created patch, based on earlier work of avg@, to add back pressure to UMA allocation caches. The problem of physical memory or KVA exhaustion existed there for many years and it is quite critical now for improving systems performance while keeping stability. Changes done in memory allocation last years improved situation. but haven't fixed completely. My patch solves remaining problems from two sides: a) reducing bucket sizes every time system detects low memory condition; and b) as last-resort mechanism for very low memory condition, it cycling over all CPUs to purge their per-CPU UMA caches. Benefit of this approach is in absence of any additional hard-coded limits on cache sizes -- they are self-tuned, based on load and memory pressure. With this change I believe it should be safe enough to enable UMA allocation caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for amd64). I did many tests on machine with 24 logical cores (and as result strong allocation cache effects), and can say that with 40GB RAM using UMA caches, allowed by this change, by two times increases results of SPEC NFS benchmark on ZFS pool of several SSDs. To test system stability I've run the same test with physical memory limited to just 2GB and system successfully survived that, and even showed results 1.5 times better then with just last resort measures of b). In both cases tools/umastat no longer shows unbound UMA cache growth, that makes me believe in viability of this approach for longer runs. I would like to hear some comments about that: http://people.freebsd.org/~mav/uma_pressure.patch Thank you. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 01:33:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C824CD0C for ; Mon, 18 Nov 2013 01:33:40 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8628123D5 for ; Mon, 18 Nov 2013 01:33:40 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id ht10so515059vcb.29 for ; Sun, 17 Nov 2013 17:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=Oy2pfJyyNeBBkS6XZlgEuJMPX6zaziWS71BPZbb2lVg=; b=dw9qZ3OGr2C38r7fd96Dyeo/39tN+95kHLzRi1f/TEtJCZWhVVuyPVlbol07jCmWwF gy9wnCPG7fn0dm8TZnkSXyqoTIAadC/wPCXM0pzJvnbb2Mms5V2lbnw/z2awA3Bl/UVP Orv59gDMx7Cvj4T/UDkZ0QjGqCGixoZPGBbig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Oy2pfJyyNeBBkS6XZlgEuJMPX6zaziWS71BPZbb2lVg=; b=i1gGGhbZgT/3PhO0kA0l2NPU3eepl6Yt4XBtosm628h3tzThbUJb7sk4Y1Ma2u2XJQ tTCXAp4q01y/Ktk2coGATX15KFLaDAH7givxeLggXkZAedklkUBBe1HiAnFJHMkozQU+ +xzQE6xe2NdTQpa747vIIKNZLyXTwOeClf+ScCeBjApRx2bTXGP2uQ3nxcEiEQ2vR/BS jy90CT3yR+pK8dBtzdRnxx9wioBNKZBINg+yEc/z8QpM6dXrf04SrvpwNz2iYQyRvnNZ 1xgSv4cT/7TMNYTFK6OqC29sr0vP5YLnnZQAcWGq5mi7fpOIK172bVwFcC3BUEj2N3p/ OU0g== X-Gm-Message-State: ALoCoQnxxGttz98OKg64umBoctmELBhyI9IKd+vcdSDW8hRaypBI6nZkf2aB8Hx6nMAbVujUQGof MIME-Version: 1.0 X-Received: by 10.52.33.44 with SMTP id o12mr10910870vdi.7.1384738419620; Sun, 17 Nov 2013 17:33:39 -0800 (PST) Received: by 10.220.167.74 with HTTP; Sun, 17 Nov 2013 17:33:39 -0800 (PST) Date: Sun, 17 Nov 2013 17:33:39 -0800 Message-ID: Subject: Fwd: FYI: svn commit: r258283 - in head: . include lib lib/libc lib/libc/iconv lib/libc_nonshared From: Peter Wemm To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 01:33:40 -0000 FYI, for folks not following commit messages.. There is a potential new-binaries-on-old-systems gotcha here. If you compile an iconv-using program on a system *after* this commit and try to run the binary on an *old* pre-commit system, you will get undefined symbols. Going forwards is fine - a buildworld on an established system is safe. Old binaries run on new systems. Most folks would never hit this, except perhaps: * you build a bunch of iconv-using binaries in /usr/local, then revert your /usr/src to and old rev and buildworld. * you try and copy/install binary packages build on a new system onto an old system. New binaries on old systems generally isn't supported. Particularly so on -current. ---------- Forwarded message ---------- From: Peter Wemm Date: Sun, Nov 17, 2013 at 2:52 PM Subject: svn commit: r258283 - in head: . include lib lib/libc lib/libc/iconv lib/libc_nonshared To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: peter Date: Sun Nov 17 22:52:17 2013 New Revision: 258283 URL: http://svnweb.freebsd.org/changeset/base/258283 Log: Attempt to move the POSIX iconv* symbols out of runtime linker space. FreeBSD systems usually implemented this as a third party module and our implementation hasn't played as nicely with the old way as it could have. To that end: * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix. * Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work. * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so. * Move the "iconv*" wrapper symbols to libc_nonshared.a This should solve the runtime ambiguity about which symbols resolve to where. If you compile against the iconv in libc, your runtime dependencies will be unambiguous. Old 9.x libraries and binaries will always resolve against their libiconv.so.3 like they did on 9.x. They won't resolve against libc. Old 10.x binaries will be satisified by the .symver helpers. This should allow ports to selectively compile against the libiconv port if needed and it should behave without ambiguity now. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 07:48:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D22B37C for ; Mon, 18 Nov 2013 07:48:02 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E74FA243B for ; Mon, 18 Nov 2013 07:48:01 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1ViJYo-0003iR-N6 for freebsd-current@freebsd.org; Sun, 17 Nov 2013 23:47:54 -0800 Date: Sun, 17 Nov 2013 23:47:54 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1384760874666-5861930.post@n5.nabble.com> Subject: zpool requires re-import on reboot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 07:48:02 -0000 I have root on zfs, which mounts fine on start. I have two other pools, which do not get mounted and must be imported each time. Boot falls to single-user mode because it cannot find the zfs-related mounts for the two pools in question. The zpool import does not require the "-f" flag to import, but does keep the pools in an exported state for some reason. FreeBSD 11.0-CURRENT #0 r257917 amd64 ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-tp5861930.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 07:57:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAF4A5DD for ; Mon, 18 Nov 2013 07:57:35 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97DFF24A7 for ; Mon, 18 Nov 2013 07:57:35 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i4so1081906oah.15 for ; Sun, 17 Nov 2013 23:57:35 -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=3S02ios8by1LwES2d6Mw8EZs/aifW5+qrTGAJW4hxew=; b=u6PQYREIvCCHsNUPsELRonTGBR6UFm38dTvE7auKWVeSr6vzrTdQ1enNHL34JnXgUM SwnNB+LDFRecQrAa0lf/w7aINuHnWgop04mzGZxR8uIf7mvoevATLGt0YznJOCUm+h+5 ZcPzkE5yXfYG5dckihens60op1o3sRfy0z0q3QmIE8hCh6WL3ZNqOIWF2DLs4uCX0fxj Vmsn3QlYtVTCcL0mdWYbURRxYw4mraSj2w1bDgr7gH3oVjzraKXlTapcqUIZHfwZHYzQ M2i3l2DtCVigjdBn+OYxivSYOpaoWf1UW0Ul+XjASthEkPyxKTvS9Fh3SDqdaOrV80BS GYGA== MIME-Version: 1.0 X-Received: by 10.182.34.194 with SMTP id b2mr1570033obj.41.1384761454981; Sun, 17 Nov 2013 23:57:34 -0800 (PST) Received: by 10.76.177.234 with HTTP; Sun, 17 Nov 2013 23:57:34 -0800 (PST) In-Reply-To: <1384760874666-5861930.post@n5.nabble.com> References: <1384760874666-5861930.post@n5.nabble.com> Date: Mon, 18 Nov 2013 08:57:34 +0100 Message-ID: Subject: Re: zpool requires re-import on reboot From: Andreas Nilsson To: Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 07:57:35 -0000 On Mon, Nov 18, 2013 at 8:47 AM, Beeblebrox wrote: > I have root on zfs, which mounts fine on start. I have two other pools, > which > do not get mounted and must be imported each time. Boot falls to > single-user > mode because it cannot find the zfs-related mounts for the two pools in > question. The zpool import does not require the "-f" flag to import, but > does keep the pools in an exported state for some reason. > > FreeBSD 11.0-CURRENT #0 r257917 amd64 > > > > Do you have a valid /boot/zfs/zpool.cache? Do have zfs_enable="YES" in rc.conf? Best regards Andreas From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 08:07:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49F2481F for ; Mon, 18 Nov 2013 08:07:52 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D0F4252C for ; Mon, 18 Nov 2013 08:07:51 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1ViJs7-0005pm-90 for freebsd-current@freebsd.org; Mon, 18 Nov 2013 00:07:51 -0800 Date: Mon, 18 Nov 2013 00:07:51 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1384762071271-5861933.post@n5.nabble.com> In-Reply-To: References: <1384760874666-5861930.post@n5.nabble.com> Subject: Re: zpool requires re-import on reboot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 08:07:52 -0000 >> Do have zfs_enable="YES" in rc.conf? Yes, and my ZFS root mounts without problem. Also in /boot/loader.conf: zfs_load="YES" opensolaris_load="YES" vfs.root.mountfrom="zfs:bsds" #--------- #_ZFS_PERFORMANCE #I have 4G of Ram vfs.zfs.prefetch_disable=0 #Ram 4GB => 512. Ram 8GB => value 1024 vfs.zfs.arc_min="512M" #Ram x 0.5 - 512 MB vfs.zfs.arc_max="1536M" #Ram x 2 => vm.kmem_size_max="16G" #Ram x 1.5 vm.kmem_size="6G" vfs.zfs.vdev_max_pending="1" #--------- ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-tp5861930p5861933.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 08:30:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B94EEEB for ; Mon, 18 Nov 2013 08:30:24 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 89BA0267B for ; Mon, 18 Nov 2013 08:30:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA09149; Mon, 18 Nov 2013 10:30:14 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ViKDl-000FpX-UP; Mon, 18 Nov 2013 10:30:13 +0200 Message-ID: <5289CFDD.9090708@FreeBSD.org> Date: Mon, 18 Nov 2013 10:29:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Beeblebrox , freebsd-current@FreeBSD.org Subject: Re: zpool requires re-import on reboot References: <1384760874666-5861930.post@n5.nabble.com> In-Reply-To: <1384760874666-5861930.post@n5.nabble.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 08:30:24 -0000 on 18/11/2013 09:47 Beeblebrox said the following: > I have root on zfs, which mounts fine on start. I have two other pools, which > do not get mounted and must be imported each time. Boot falls to single-user > mode because it cannot find the zfs-related mounts for the two pools in > question. The zpool import does not require the "-f" flag to import, but > does keep the pools in an exported state for some reason. > > FreeBSD 11.0-CURRENT #0 r257917 amd64 Is there anything "non-standard" about your configuration? All pools that are present in /boot/zfs/zpool.cache on a root filesystem of a root pool should be automatically imported. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 08:41:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E87C359F; Mon, 18 Nov 2013 08:41:49 +0000 (UTC) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C13E2719; Mon, 18 Nov 2013 08:41:49 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id x7so3878272qeu.14 for ; Mon, 18 Nov 2013 00:41:48 -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=G+T0OAuaFI/yyb4AkjROiIwYoZzdv9PevOuywYhjg+I=; b=f/wS6uq+Gr/7F3GSlqBFqzGBiHPw6JrwNTDOX2Hm2n2lVwEsTEFZPVON3B9JERZHJY vtI8sdfLATQreDpQTAQmq2G6g44oNezeACdLN89WV4QNJLSGByp121OXnUeVcN4THkuA tfdYnDsuk61qKwctA4Bn0Zy64OZZnhV7gZfLrM56nqRqF4XUClnsqIhIPV0L1H+AC3Wi /A9EzZuiEXQOB2l4j9yf476DXwTLEvtR8nFmo1hp3zoyibiPT1w3K6c/XnngZcEKd1Is qU83sCcJJcqvmaUZwh6elbJ1U4M/e4bxeSPHvnwpgmS6ZQbKFAD09k4qwETE4XKJ8yaG pTog== MIME-Version: 1.0 X-Received: by 10.224.64.200 with SMTP id f8mr32262534qai.55.1384764108825; Mon, 18 Nov 2013 00:41:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 18 Nov 2013 00:41:48 -0800 (PST) In-Reply-To: <52894C92.60905@FreeBSD.org> References: <52894C92.60905@FreeBSD.org> Date: Mon, 18 Nov 2013 00:41:48 -0800 X-Google-Sender-Auth: NbolgVcs7EvAmjwQ51Qzypcoosk Message-ID: Subject: Re: UMA cache back pressure From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 08:41:50 -0000 Hi! Your patch does three things: * adds a couple new buckets; * reduces some lock contention * does the aggressive backpressure. So, do you get any benefits from just the first one, or first two? -adrian On 17 November 2013 15:09, Alexander Motin wrote: > Hi. > > I've created patch, based on earlier work of avg@, to add back pressure to > UMA allocation caches. The problem of physical memory or KVA exhaustion > existed there for many years and it is quite critical now for improving > systems performance while keeping stability. Changes done in memory > allocation last years improved situation. but haven't fixed completely. My > patch solves remaining problems from two sides: a) reducing bucket sizes > every time system detects low memory condition; and b) as last-resort > mechanism for very low memory condition, it cycling over all CPUs to purge > their per-CPU UMA caches. Benefit of this approach is in absence of any > additional hard-coded limits on cache sizes -- they are self-tuned, based on > load and memory pressure. > > With this change I believe it should be safe enough to enable UMA allocation > caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for amd64). I did > many tests on machine with 24 logical cores (and as result strong allocation > cache effects), and can say that with 40GB RAM using UMA caches, allowed by > this change, by two times increases results of SPEC NFS benchmark on ZFS > pool of several SSDs. To test system stability I've run the same test with > physical memory limited to just 2GB and system successfully survived that, > and even showed results 1.5 times better then with just last resort measures > of b). In both cases tools/umastat no longer shows unbound UMA cache growth, > that makes me believe in viability of this approach for longer runs. > > I would like to hear some comments about that: > http://people.freebsd.org/~mav/uma_pressure.patch > > Thank you. > > -- > Alexander Motin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 08:51:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B62EEB24 for ; Mon, 18 Nov 2013 08:51:19 +0000 (UTC) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 762F027D2 for ; Mon, 18 Nov 2013 08:51:19 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id 1so3888209qee.9 for ; Mon, 18 Nov 2013 00:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+D5CXN4OWFGoO8wBWmeAPFox2t+0YKX8RImAPkI/JSc=; b=fOwyPuMo2bl/w9DaxBtCEU+E9v2jDM/4PILm5Vs73HbXsLGB8rbgm5tmSneaoTjCCs HLsNsWBPXFq3kIoddfjk0y3VurWsQ+2pCIXvssJkcKfNIhPW1Ib/advIggyieDxSKqGY ig3yLPNyn2fWOVgSQOeHK8/iUeRDojwfVqzfY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+D5CXN4OWFGoO8wBWmeAPFox2t+0YKX8RImAPkI/JSc=; b=VKyxOVJxKnK9uaaD6ZVtU4qlMKtfDtiKDjIoWdXSIe398yXoNasCxM3UP+bMU/gZ1L Hr3eYeMEq1xnenk1SZuvMb0AmisrXhsIaxYNKgN03rIy6oi7xpvtq8aBX097KiMJVt4n UHIRufg9LhIoG2XIkPGxdQ7lOZxOCIA4HSGXKHiAe286y5UXWm94f46jhOtfN5LXzozg j6EiEvmwjQTNd9wJ06NvueCKlzMbeNeAWIMZQaNlO+9dtU0HjfRRcbON7ANAi0PevpOH FH2fvoGJXF5KIITvlBJWtx5mX4ryF1tYrcdEb2xUAPAinQwx6iGrNsKuQQAjAJT7UYmh 5efA== X-Gm-Message-State: ALoCoQnBSAaGuZSM2W1s9l6ySlV/tgY4io9SKUWiiTPGEdEVS67IomeVOodELvLU8RGVakzxPmSp MIME-Version: 1.0 X-Received: by 10.49.15.5 with SMTP id t5mr32134351qec.38.1384764678535; Mon, 18 Nov 2013 00:51:18 -0800 (PST) Sender: rsb@berentweb.com Received: by 10.224.122.19 with HTTP; Mon, 18 Nov 2013 00:51:18 -0800 (PST) X-Originating-IP: [83.66.206.76] In-Reply-To: <5289CFDD.9090708@FreeBSD.org> References: <1384760874666-5861930.post@n5.nabble.com> <5289CFDD.9090708@FreeBSD.org> Date: Mon, 18 Nov 2013 10:51:18 +0200 X-Google-Sender-Auth: IpLHtkKsc8gMtvo8A1VXYWoI5uA Message-ID: Subject: Re: zpool requires re-import on reboot From: Beeblebrox To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: zaphod@berentweb.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 08:51:19 -0000 > Is there anything "non-standard" about your configuration? > All pools that are present in /boot/zfs/zpool.cache on a root filesystem of a > root pool should be automatically imported. Yes I know that, hence the reason I posted. ll /boot/zfs shows recently updated zpool.cache => -rw-r--r-- 1 root wheel 3736 Nov 18 10:03 zpool.cache * No special setting on pool or datasets of the pool * /etc/src.conf even has "LOADER_ZFS_SUPPORT= yes" * custom kernel has label disabled (#options GEOM_LABEL ). However, generic kernel shows same behavior. From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 08:54:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7D2AC5B for ; Mon, 18 Nov 2013 08:54:31 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id A312C27F0 for ; Mon, 18 Nov 2013 08:54:30 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8D0D825790 for ; Mon, 18 Nov 2013 08:54:24 +0000 (UTC) Message-ID: <5289D5C4.1020202@allanjude.com> Date: Mon, 18 Nov 2013 03:54:28 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zpool requires re-import on reboot References: <1384760874666-5861930.post@n5.nabble.com> <5289CFDD.9090708@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iSCrksdaamgTWgcGjw1tXv2KbxQ55GX8a" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 08:54:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iSCrksdaamgTWgcGjw1tXv2KbxQ55GX8a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-18 03:51, Beeblebrox wrote: >> Is there anything "non-standard" about your configuration? >> All pools that are present in /boot/zfs/zpool.cache on a root filesyst= em of a >> root pool should be automatically imported. > Yes I know that, hence the reason I posted. > > ll /boot/zfs shows recently updated zpool.cache =3D> > -rw-r--r-- 1 root wheel 3736 Nov 18 10:03 zpool.cache > > * No special setting on pool or datasets of the pool > * /etc/src.conf even has "LOADER_ZFS_SUPPORT=3D yes" > * custom kernel has label disabled (#options GEOM_LABEL ). > However, generic kernel shows same behavior. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" In /boot/loader.conf try adding: zpool_cache_load=3D"YES" zpool_cache_type=3D"/boot/zfs/zpool.cache" zpool_cache_name=3D"/boot/zfs/zpool.cache" This should make it read the zpool.cache file and mount all of the pools,= instead of only the one which contains your root file system --=20 Allan Jude --iSCrksdaamgTWgcGjw1tXv2KbxQ55GX8a 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.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSidXHAAoJEJrBFpNRJZKf16IP/2pSPC2F2ElJkc1ucymwA65Z i4uCkKWTFCY9iiCXGPpgqgOz6b+CqgCPB8mmBH4oqXE4R+CW2hquH1WSsa7R74e4 iY6BKrmDIXr5EbXakdombG91J8InggEXUu/fDbX52+MuKHglHyCN0xdqesgZoBO+ weOPqwoNH6a2a7EMKG8ApoSqhenwmCTXnfDCti1w/jnmmfPG6aJJcu+714uCiSM3 IYVwxMebWH5RMIdBMzoAx31mQ4Vr1ETYTDesBPjPfXuuREdw3rP3LrVD2OLXKbTg afICY14hoEEL61c2Pq2XLLqlzKqHtGYV6caEaG4EttQQDm6a7tjHhJjeYkeP6ydb sb9jSRML9JPnRZx4eate4WEPafE997Gk4uuywBuSw/pzpbjULtgpcXBSSkbLYPmo u/Sub4EN5LVPVIRfAhqMaQUWc6qKSyCEx4YsgZEG+W989rgjJ31JyJYdzESUa6QL B7wgyXgJYu8cFv+lGodyX/vtpS577BzqTFJ63k3ok7f0eCq++KbhYZvfNdqAzQIe SjrsD1QN+TKE+miGYCyZCn0wEehSDV0mGTHjYBGdD+sj+2O8MYC+zfGB6qwcOq9I /DL61iKkU2jBeFwnTE1b9KzoVtMlACX7b5G6Jc2jtBv7dYRGoGbuk4Jfgdkkv256 yBXBe8VZ3AfQVtBpld9I =cRIp -----END PGP SIGNATURE----- --iSCrksdaamgTWgcGjw1tXv2KbxQ55GX8a-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 09:00:45 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 089D8DE0 for ; Mon, 18 Nov 2013 09:00:45 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5722864 for ; Mon, 18 Nov 2013 09:00:43 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA09567; Mon, 18 Nov 2013 11:00:41 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ViKhF-000FsG-9H; Mon, 18 Nov 2013 11:00:41 +0200 Message-ID: <5289D715.6000908@FreeBSD.org> Date: Mon, 18 Nov 2013 11:00:05 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: zaphod@berentweb.com Subject: Re: zpool requires re-import on reboot References: <1384760874666-5861930.post@n5.nabble.com> <5289CFDD.9090708@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 09:00:45 -0000 on 18/11/2013 10:51 Beeblebrox said the following: >> Is there anything "non-standard" about your configuration? >> All pools that are present in /boot/zfs/zpool.cache on a root filesystem of a >> root pool should be automatically imported. > > Yes I know that, hence the reason I posted. > > ll /boot/zfs shows recently updated zpool.cache => > -rw-r--r-- 1 root wheel 3736 Nov 18 10:03 zpool.cache > > * No special setting on pool or datasets of the pool > * /etc/src.conf even has "LOADER_ZFS_SUPPORT= yes" > * custom kernel has label disabled (#options GEOM_LABEL ). > However, generic kernel shows same behavior. > What does zdb -C report? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 09:21:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1A43373; Mon, 18 Nov 2013 09:21:02 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DA4029A0; Mon, 18 Nov 2013 09:21:01 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id e49so2313646eek.21 for ; Mon, 18 Nov 2013 01:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WdHtD+khd2d/VfhXzRyplRr7wBb2XCgdBHz2xxlmbds=; b=ZGRKncfEbYrBaKzzzAZJBrXQ0K4IvvEJOSTHl0p/jFpte5nRQj9n2wd+67+nrfaEmG dIYa8F0Uu+jGthVNW8IUyza8LQ53isJkJRGd0ZViUACzV1Pmex4NQWkZmtUxODoKpDPB 3wP+WVd+Tnwe48dJolZrL40Ufa5oe81wINmYqlC2uIqoIvd6/GK0CIxYmYxyo7hEvDD1 qCMDIAo0rm5NCWMBdVm6RfXgsGMDAy1EmHF2sqNxw4bBbzOJ5+E9rFmrxHSenf9/tskw x0Esueh6EnGKWqWhj0j29mjn82NEbg2j4CPuxK3Dj26k/gSaKno98MPsXqRyYrFKes31 oMDA== X-Received: by 10.14.108.9 with SMTP id p9mr20316683eeg.8.1384766460341; Mon, 18 Nov 2013 01:21:00 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id s3sm35801312eeo.3.2013.11.18.01.20.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 01:20:59 -0800 (PST) Sender: Alexander Motin Message-ID: <5289DBF9.80004@FreeBSD.org> Date: Mon, 18 Nov 2013 11:20:57 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: UMA cache back pressure References: <52894C92.60905@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 09:21:02 -0000 On 18.11.2013 10:41, Adrian Chadd wrote: > Your patch does three things: > > * adds a couple new buckets; These new buckets make bucket size self-tuning more soft and precise. Without them there are buckets for 1, 5, 13, 29, ... items. While at bigger sizes difference about 2x is fine, at smallest ones it is 5x and 2.6x respectively. New buckets make that line look like 1, 3, 5, 9, 13, 29, reducing jumps between steps, making algorithm work softer, allocating and freeing memory in better fitting chunks. Otherwise there is quite a big gap between allocating 128K and 5x128K of RAM at once. > * reduces some lock contention More precisely patch adds check for congestion on free to grow bucket sizes same as on allocation. As consequence that indeed should reduce lock congestion, but I don't have specific numbers. All I see is that VM and UMA mutexes no longer appear in profiling top after all these changes. * does soft back pressure In this list you have missed mentioning small but major point of the patch -- we should prevent problems, not just solve them. As I have written in original email, this specific change shown me 1.5x performance improvement in low-memory condition. As I understand, that happened because VM no longer have to repeatedly allocate and free hugely oversized buckets of 10-15 * 128K. > * does the aggressive backpressure. After all above that is mostly just a safety belt. With 40GB RAM that code was triggered only couple times during full hour of testing with debug logging inserted there. On machine with 2GB RAM it is triggered quite regularly and probably that is unavoidable since even with lowest bucket size of one item 24 CPUs mean 48 cache buckets, i.e. up to 6MB of otherwise unreleasable memory for single 128K zone. > So, do you get any benefits from just the first one, or first two? I don't see much reason to handle that in pieces. As I have described above, each part has own goal, but they much better work together. > On 17 November 2013 15:09, Alexander Motin wrote: >> Hi. >> >> I've created patch, based on earlier work of avg@, to add back pressure to >> UMA allocation caches. The problem of physical memory or KVA exhaustion >> existed there for many years and it is quite critical now for improving >> systems performance while keeping stability. Changes done in memory >> allocation last years improved situation. but haven't fixed completely. My >> patch solves remaining problems from two sides: a) reducing bucket sizes >> every time system detects low memory condition; and b) as last-resort >> mechanism for very low memory condition, it cycling over all CPUs to purge >> their per-CPU UMA caches. Benefit of this approach is in absence of any >> additional hard-coded limits on cache sizes -- they are self-tuned, based on >> load and memory pressure. >> >> With this change I believe it should be safe enough to enable UMA allocation >> caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for amd64). I did >> many tests on machine with 24 logical cores (and as result strong allocation >> cache effects), and can say that with 40GB RAM using UMA caches, allowed by >> this change, by two times increases results of SPEC NFS benchmark on ZFS >> pool of several SSDs. To test system stability I've run the same test with >> physical memory limited to just 2GB and system successfully survived that, >> and even showed results 1.5 times better then with just last resort measures >> of b). In both cases tools/umastat no longer shows unbound UMA cache growth, >> that makes me believe in viability of this approach for longer runs. >> >> I would like to hear some comments about that: >> http://people.freebsd.org/~mav/uma_pressure.patch -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 09:45:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F35F2B8; Mon, 18 Nov 2013 09:45:29 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CB2C2B7D; Mon, 18 Nov 2013 09:45:28 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id ec20so4743519lab.1 for ; Mon, 18 Nov 2013 01:45:26 -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=eCr1wXnw9yFHqGiIQpqKOrsD8/+8sHIx1oscnisEvTI=; b=R3P2Hi5Xl8bVdMgLuPr8Xf+unH796luoQ+dzRZKlha/brDuzDT77i7Cc6BVHr9ulog QWVm1qZMFsMvxGEPSIytagRCJbAUUiMV8NlH5muOckXzcqBgdFnRTdX9kEUZXT6cg6V+ jUxSP5Ep8McBkk7EEyGtvRgS/WmSlFdYEPQiafgCHV60JQl1OjY5c/Xa1yper8C+lT8S mMwX7WWGF3pNHEtfBznSTMdNsKn0itMGKSc4Epn/msH+aL6KTnbCWZzPjsdu6AdV9wVi RnbwMyVTKn5nRHEhcsF4fPxd0EaRG28acaRZ7i4t4SkC5gvRrnnGjNQT8NRTYfNTpsh0 LVjg== MIME-Version: 1.0 X-Received: by 10.112.219.99 with SMTP id pn3mr1025787lbc.24.1384767926523; Mon, 18 Nov 2013 01:45:26 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.77.228 with HTTP; Mon, 18 Nov 2013 01:45:26 -0800 (PST) In-Reply-To: <5289DBF9.80004@FreeBSD.org> References: <52894C92.60905@FreeBSD.org> <5289DBF9.80004@FreeBSD.org> Date: Mon, 18 Nov 2013 10:45:26 +0100 X-Google-Sender-Auth: zAs_G8XSv3CVF7664Dac1teoEC8 Message-ID: Subject: Re: UMA cache back pressure From: Luigi Rizzo To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 09:45:29 -0000 On Mon, Nov 18, 2013 at 10:20 AM, Alexander Motin wrote: > On 18.11.2013 10:41, Adrian Chadd wrote: > >> Your patch does three things: >> >> * adds a couple new buckets; >> > > These new buckets make bucket size self-tuning more soft and precise. > Without them there are buckets for 1, 5, 13, 29, ... items. While at bigger > sizes difference about 2x is fine, at smallest ones it is 5x and 2.6x > respectively. New buckets make that line look like 1, 3, 5, 9, 13, 29, > reducing jumps between steps, making algorithm work softer, allocating and > freeing memory in better fitting chunks. Otherwise there is quite a big gap > between allocating 128K and 5x128K of RAM at once. > > just curious (and i do not understand whether the "1, 5 ..." are object sizes in bytes or what), would it make sense to add some instrumentation code (a small array of counters i presume) to track the actual number of requests for exact object sizes, and perhaps at runtime create buckets trying to reduce waste ? Following your reasoning there seems to be still a big gap between some of the numbers you quote in the sequence. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 09:59:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5DF97ED; Mon, 18 Nov 2013 09:59:41 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 109852C41; Mon, 18 Nov 2013 09:59:40 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b57so2361474eek.12 for ; Mon, 18 Nov 2013 01:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=z8SjCiJNVsJYQIQevLms4rBH10/eVvjRNnAsaPnx910=; b=gbBZO8svj8R5kM0wCmtYbbSwCgyU+Fad2BcKXXRq6WR9n8VeydpMOwcl8SlpK9RZYZ SPLelGk9dWsI3tJaLIg8/ImVC1YnNXcJ1vF8swI2RPAj0ZaIaLedPx7P/RTTQ8MpAf26 ePk7JtG8RGGCWpTtPg7L1FsIAN0+py9sHSa+dudQWyF/xnMwdBjoRHTtus94ZWZQV0iK Zqqow3pXsFaDe2LSTPZWkEFzgeAN1o7g1XbhXD3KprV9Y7x/Bk7ON2ilJPjxqUCWdqwQ T5QawgbeKYcLyU2pwuAlbuUMHLkipl0omokO9JxDb2frdazmVos9JuED7CX5QYJjtVzj bcUQ== X-Received: by 10.14.109.1 with SMTP id r1mr11909280eeg.32.1384768779114; Mon, 18 Nov 2013 01:59:39 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id o47sm36065475eem.21.2013.11.18.01.59.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 01:59:38 -0800 (PST) Sender: Alexander Motin Message-ID: <5289E506.2070207@FreeBSD.org> Date: Mon, 18 Nov 2013 11:59:34 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: UMA cache back pressure References: <52894C92.60905@FreeBSD.org> <5289DBF9.80004@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 09:59:41 -0000 On 18.11.2013 11:45, Luigi Rizzo wrote: > > > > On Mon, Nov 18, 2013 at 10:20 AM, Alexander Motin > wrote: > > On 18.11.2013 10:41, Adrian Chadd wrote: > > Your patch does three things: > > * adds a couple new buckets; > > > These new buckets make bucket size self-tuning more soft and > precise. Without them there are buckets for 1, 5, 13, 29, ... items. > While at bigger sizes difference about 2x is fine, at smallest ones > it is 5x and 2.6x respectively. New buckets make that line look like > 1, 3, 5, 9, 13, 29, reducing jumps between steps, making algorithm > work softer, allocating and freeing memory in better fitting chunks. > Otherwise there is quite a big gap between allocating 128K and > 5x128K of RAM at once. > > > just curious (and i do not understand whether the "1, 5 ..." are object > sizes in bytes or what), Buckets include header (~3 pointers), plus number of item pointers. So on amd64 1, 5, 13 mean 32, 64, 128 bytes per bucket. It is not really about saving memory on buckets themselves since they are very small, comparing to stored items. We could use bigger (like 16 items) bucket zone for allocating all smaller ones, overwriting just their items limit. But more zones potentially means also lower zone lock congestion there, so why not? > would it make sense to add some instrumentation > code (a small array of counters i presume) to track the actual number > of requests for exact object sizes, and perhaps at runtime create buckets > trying to reduce waste ? Since 10.0 buckets are also allocated from UMA cache zones, so all stats, garbage collection, etc. work by the same rules, which you can see in `vmstat -z`. > Following your reasoning there seems to be still a big gap between > some of the numbers you quote in the sequence. Big (2x) gaps between big numbers is less important since once we got there it means we have not so much memory pressure and should not be hurt by many extra frees. At lower numbers it may be more important. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 12:10:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37258F17; Mon, 18 Nov 2013 12:10:22 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD2962567; Mon, 18 Nov 2013 12:10:21 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id f11so1145119qae.6 for ; Mon, 18 Nov 2013 04:10: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=v5eD+yxyx4RXPz2/rlhOv350IlwQtIUrqZeXMtBJX+M=; b=hoim1jtWE5vY0rmrIH7vvklPIGGwUy5FP0dkfGP0a9H2TrM7rzzzzc1M7fTbsoGyWv IEdTmxnMLXV54aDdIoqkU3I0zPFviKXznZchnNpqQYq9TOQnqSafccoZFhxAc3FtumL9 tol6BelQOa/F6kfdqCC4nNsS720BbLG5PB7Q9ufJTfQej9K4moaS01IJvFcM/9DRFZPy W2Z3AEryFvSkEHYP0jpMzJalB7a3n+7XQVgkVDaJn2jmcTcNUR0lZjf9K0fmCdtFZfoD al1JCYap8/ucOrRJVZcOl3+vif/suFvhikdWvqPuKplnitKW0wb1UUBUoKWvy+oO6rBz Ddrw== MIME-Version: 1.0 X-Received: by 10.224.98.200 with SMTP id r8mr33352927qan.26.1384776619952; Mon, 18 Nov 2013 04:10:19 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 18 Nov 2013 04:10:19 -0800 (PST) In-Reply-To: <5289DBF9.80004@FreeBSD.org> References: <52894C92.60905@FreeBSD.org> <5289DBF9.80004@FreeBSD.org> Date: Mon, 18 Nov 2013 04:10:19 -0800 X-Google-Sender-Auth: FWiYWYHm8mpA44UH0srn0ozYp3g Message-ID: Subject: Re: UMA cache back pressure From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 12:10:22 -0000 On 18 November 2013 01:20, Alexander Motin wrote: > On 18.11.2013 10:41, Adrian Chadd wrote: >> >> Your patch does three things: >> >> * adds a couple new buckets; > > > These new buckets make bucket size self-tuning more soft and precise. > Without them there are buckets for 1, 5, 13, 29, ... items. While at bigger > sizes difference about 2x is fine, at smallest ones it is 5x and 2.6x > respectively. New buckets make that line look like 1, 3, 5, 9, 13, 29, > reducing jumps between steps, making algorithm work softer, allocating and > freeing memory in better fitting chunks. Otherwise there is quite a big gap > between allocating 128K and 5x128K of RAM at once. Right. That makes sense, but your initial email didn't say "oh, I'm adding more buckets." :-) > >> * reduces some lock contention > > > More precisely patch adds check for congestion on free to grow bucket sizes > same as on allocation. As consequence that indeed should reduce lock > congestion, but I don't have specific numbers. All I see is that VM and UMA > mutexes no longer appear in profiling top after all these changes. Sure. But again, you don't say that in your commit message. :) > * does soft back pressure > > In this list you have missed mentioning small but major point of the patch > -- we should prevent problems, not just solve them. As I have written in > original email, this specific change shown me 1.5x performance improvement > in low-memory condition. As I understand, that happened because VM no longer > have to repeatedly allocate and free hugely oversized buckets of 10-15 * > 128K. yup, sorry I missed this. It's a sneaky two lines. :) > >> * does the aggressive backpressure. > > > After all above that is mostly just a safety belt. With 40GB RAM that code > was triggered only couple times during full hour of testing with debug > logging inserted there. On machine with 2GB RAM it is triggered quite > regularly and probably that is unavoidable since even with lowest bucket > size of one item 24 CPUs mean 48 cache buckets, i.e. up to 6MB of otherwise > unreleasable memory for single 128K zone. > > >> So, do you get any benefits from just the first one, or first two? > > > I don't see much reason to handle that in pieces. As I have described above, > each part has own goal, but they much better work together. Well, with changes like this, having them broken up and committed in small pieces make it easier for people to do regression testing with. If you introduce some regression in a particular workload then the user or developer is only going to find that it's this patch and won't necessarily know how to break it down into pieces to see which piece actually introduced the regression in their specific workload. I totally agree that this should be done! It just does seem to be something that could be committed in smaller pieces quite easily so to make potential debugging later on down the road much easier. Each commit builds on the previous commit. So, something like (in order): * add two new buckets, here's why * fix locking, here's why * soft back pressure * aggressive backpressure Did you get profiling traces from the VM free paths? Is it because it's churning the physical pages through the VM physical allocator? or? -adrian From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 12:57:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2791286; Mon, 18 Nov 2013 12:57:09 +0000 (UTC) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3ED0B284D; Mon, 18 Nov 2013 12:57:09 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id t10so1216942eei.14 for ; Mon, 18 Nov 2013 04:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6yV6N5N0Giemz4fI7O2fKbBixJGKUz5MaPhHRdIz0Js=; b=Jym+V3dyXUgWsnLHNYMAQYfyDAHnsvxNBudPJV4AJLLL50idcHR9W3e3chPrlEBuKQ FYng6MJSNcipFMnyyu9k6hT8JxtD7aPUViAINPqk4u/4mTnmNaD72m4oFfkwbgoVjRsr ErZPLs4TVvcpo4XzwZJ688GzjUYyGNRF0m43VOq6ZOQFLMlHS0KH1dv6u7+qdNdhcVyp PndiFPs31T5ZtC/P9NlC0J0KNhC+6GZqsLsLvXscsDT/2OHNSaCobLIJEZnBkE685Vnl 4dCB+s3KjNap0HF/Xe2vVg2RGviq8kMJEm6pCiamcWedgEZzCNcZGzdTGRxPF58wNAz+ Jmww== X-Received: by 10.14.113.137 with SMTP id a9mr12600546eeh.3.1384779427676; Mon, 18 Nov 2013 04:57:07 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id 44sm37646908eek.5.2013.11.18.04.57.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 04:57:06 -0800 (PST) Sender: Alexander Motin Message-ID: <528A0EA0.3040408@FreeBSD.org> Date: Mon, 18 Nov 2013 14:57:04 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: UMA cache back pressure References: <52894C92.60905@FreeBSD.org> <5289DBF9.80004@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 12:57:10 -0000 On 18.11.2013 14:10, Adrian Chadd wrote: > On 18 November 2013 01:20, Alexander Motin wrote: >> On 18.11.2013 10:41, Adrian Chadd wrote: >>> So, do you get any benefits from just the first one, or first two? >> >> I don't see much reason to handle that in pieces. As I have described above, >> each part has own goal, but they much better work together. > > Well, with changes like this, having them broken up and committed in > small pieces make it easier for people to do regression testing with. > > If you introduce some regression in a particular workload then the > user or developer is only going to find that it's this patch and won't > necessarily know how to break it down into pieces to see which piece > actually introduced the regression in their specific workload. I can't argue here, but too many small pieces turning later merging into a headache. This patch is not that big to not be reviewable at one piece. What's about better commit message -- your hint accepted. :) > I totally agree that this should be done! It just does seem to be > something that could be committed in smaller pieces quite easily so to > make potential debugging later on down the road much easier. Each > commit builds on the previous commit. > > So, something like (in order): > > * add two new buckets, here's why > * fix locking, here's why > * soft back pressure > * aggressive backpressure I can do that it you insist, I would just take different order (3,1,4,2). 2 without 3 will make buckets grow faster, that may be bad without back pressure. > Did you get profiling traces from the VM free paths? Is it because > it's churning the physical pages through the VM physical allocator? > or? Yes. Without use_uma enabled I've seen up to 50% of CPU time burned on locks held around expensive VM magic such as TLB shutdown, etc. With use_uma enabled situation improved a lot, but I've seen periodical bursts, which I guess happened when system was getting low on memory and started aggressively purge gigabytes of oversized caches. With this patch I haven't noticed such behavior so far at all, though it may be subjective since test runs quite some time and load is not very stationary. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 19:15:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9235B814 for ; Mon, 18 Nov 2013 19:15:07 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C381207F for ; Mon, 18 Nov 2013 19:15:07 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id ma3so7089981pbc.40 for ; Mon, 18 Nov 2013 11:15:06 -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:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=Bu5VE7OEDP7NC5GovIKIn+lYk8jOjHUwIFfitNaW8Iw=; b=ZmbY5KHNDP6iv3JObfXGFrr0eBf70llKUcdpYEl69FylOvelPyCkXxpL2TzpmBGVuZ 1Qlo45qYRz2ttNx181Mv6sPR3gsPnSaHcRb05jH5zz3FMnwJQBSxMNTbG1q+akXOiR+r dfxmVGZKFh5aPHYLIDio/SCFtXsS79rpU6rJSntWQ4pYwgtzYjm8AZY9fisGT2H4MInt i97bQ89bF+SAKqvJ+4xAk5szHmR8CvtrI9sS8nw+uGFDm0zM8Ts2CIl85pWF6rj5pOog xwj9nCekm9mE0Iby9rxSQi1hM105XKDiYW+4UqrJpV9vH3jNGOda70kQEI+GdKkJEMYv KOXA== X-Gm-Message-State: ALoCoQlDFLD3GWkdf5/OQbWycMi7w0JRowgb2IOznK3sztcuimogGLeDRLH4P3eB2b1lKN8OHQIx X-Received: by 10.68.180.162 with SMTP id dp2mr22499630pbc.5.1384802106553; Mon, 18 Nov 2013 11:15:06 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPSA id gg10sm25139867pbc.46.2013.11.18.11.15.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Nov 2013 11:15:05 -0800 (PST) Date: Mon, 18 Nov 2013 09:11:10 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alexander Motin Subject: Re: UMA cache back pressure In-Reply-To: <52894C92.60905@FreeBSD.org> Message-ID: References: <52894C92.60905@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:15:07 -0000 On Mon, 18 Nov 2013, Alexander Motin wrote: > Hi. > > I've created patch, based on earlier work of avg@, to add back pressure to > UMA allocation caches. The problem of physical memory or KVA exhaustion > existed there for many years and it is quite critical now for improving > systems performance while keeping stability. Changes done in memory > allocation last years improved situation. but haven't fixed completely. My > patch solves remaining problems from two sides: a) reducing bucket sizes > every time system detects low memory condition; and b) as last-resort > mechanism for very low memory condition, it cycling over all CPUs to purge > their per-CPU UMA caches. Benefit of this approach is in absence of any > additional hard-coded limits on cache sizes -- they are self-tuned, based on > load and memory pressure. > > With this change I believe it should be safe enough to enable UMA allocation > caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for amd64). I did > many tests on machine with 24 logical cores (and as result strong allocation > cache effects), and can say that with 40GB RAM using UMA caches, allowed by > this change, by two times increases results of SPEC NFS benchmark on ZFS pool > of several SSDs. To test system stability I've run the same test with > physical memory limited to just 2GB and system successfully survived that, > and even showed results 1.5 times better then with just last resort measures > of b). In both cases tools/umastat no longer shows unbound UMA cache growth, > that makes me believe in viability of this approach for longer runs. > > I would like to hear some comments about that: > http://people.freebsd.org/~mav/uma_pressure.patch Hey Mav, This is a great start and great results. I think it could probably even go in as-is, but I have a few suggestions. First, let's test this with something that is really super allocator heavy and doesn't benefit much from bucket sizing. For example, a network forwarding test. Or maybe you could get someone like Netflix that is using it to push a lot of bits with less filesystem cost than zfs and spec. Second, the cpu binding is a very costly and very high-latency operation. It would make sense to do CPU_FOREACH and then ZONE_FOREACH. You're also biasing the first zones in the list. The low memory condition will more often clear after you check these first zones. So you might just check it once and equally penalize all zones. I'm concerned that doing CPU_FOREACH in every zone will slow the pagedaemon more. We also have been working towards per-domain pagedaemons so perhaps we should have a uma-reclaim taskqueue that we wake up to do the work? Third, using vm_page_count_min() will only trigger when the pageout daemon can't keep up with the free target. Typically this should only happen with a lot of dirty mmap'd pages or incredibly high system load coupled with frequent allocations. So there may be many cases where reclaiming the extra UMA memory is helpful but the pagedaemon can still keep up while pushing out file pages that we'd prefer to keep. I think the perfect heuristic would have some idea of how likely the UMA pages are to be re-used immediately so we can more effectively tradeoff between file pages and kernel memory cache. As it is now we limit the uma_reclaim() calls to every 10 seconds when there is memory pressure. Perhaps we could keep a timestamp for when the last slab was allocated to a zone and do the more expensive reclaim on zones who have timestamps that exceed some threshold? Then have a lower threshold for reclaiming at all? Again, it doesn't need to be perfect, but I believe we can catch a wider set of cases by carefully scheduling this. Thanks, Jeff > > Thank you. > > -- > Alexander Motin > From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 19:55:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99D13167; Mon, 18 Nov 2013 19:55:19 +0000 (UTC) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F24A82364; Mon, 18 Nov 2013 19:55:18 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id r15so2667889ead.10 for ; Mon, 18 Nov 2013 11:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=k6Xz+6WHeny21iheK79VQT8uRr9JgaXrrJ13RPuulnA=; b=rS/J3wBsZDiqJsRAE8+wIIsD1dwHp+Fw+3fQG49zL+U+voHnP4vuQSk6aDkrxbC5Br IU7jK6+XoliJeJQg83hP1EmyngaoIx/7bVWQhDiCwN/uuKIaDKww9+uMggocALWK/zyo 5TDAJx3Ov8puayeTNvySX2rdQuZLhkGy3sY28v+UW/3U+fxLY/ZFVzMgBPNJk2CUiGE4 AI0hFBArQ32lX/l/FS0n3Z+FrRVoyTcdCih813FFhJ4lfyq3sF03IfUWcrOEFNwH8LjL qYOKLnQLCpWdcpM0BX146ZKpXZIDax8bucmT766qkkkha8EQ920wHVTccXb5mzA4lnhd k0kQ== X-Received: by 10.14.0.72 with SMTP id 48mr5414158eea.50.1384804517422; Mon, 18 Nov 2013 11:55:17 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id w6sm41027683eeo.12.2013.11.18.11.55.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 11:55:16 -0800 (PST) Sender: Alexander Motin Message-ID: <528A70A2.4010308@FreeBSD.org> Date: Mon, 18 Nov 2013 21:55:14 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Jeff Roberson Subject: Re: UMA cache back pressure References: <52894C92.60905@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:55:19 -0000 On 18.11.2013 21:11, Jeff Roberson wrote: > On Mon, 18 Nov 2013, Alexander Motin wrote: >> I've created patch, based on earlier work of avg@, to add back >> pressure to UMA allocation caches. The problem of physical memory or >> KVA exhaustion existed there for many years and it is quite critical >> now for improving systems performance while keeping stability. Changes >> done in memory allocation last years improved situation. but haven't >> fixed completely. My patch solves remaining problems from two sides: >> a) reducing bucket sizes every time system detects low memory >> condition; and b) as last-resort mechanism for very low memory >> condition, it cycling over all CPUs to purge their per-CPU UMA caches. >> Benefit of this approach is in absence of any additional hard-coded >> limits on cache sizes -- they are self-tuned, based on load and memory >> pressure. >> >> With this change I believe it should be safe enough to enable UMA >> allocation caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for >> amd64). I did many tests on machine with 24 logical cores (and as >> result strong allocation cache effects), and can say that with 40GB >> RAM using UMA caches, allowed by this change, by two times increases >> results of SPEC NFS benchmark on ZFS pool of several SSDs. To test >> system stability I've run the same test with physical memory limited >> to just 2GB and system successfully survived that, and even showed >> results 1.5 times better then with just last resort measures of b). In >> both cases tools/umastat no longer shows unbound UMA cache growth, >> that makes me believe in viability of this approach for longer runs. >> >> I would like to hear some comments about that: >> http://people.freebsd.org/~mav/uma_pressure.patch > > Hey Mav, > > This is a great start and great results. I think it could probably even > go in as-is, but I have a few suggestions. Hey! Thanks for your review. I appreciate. > First, let's test this with something that is really super allocator > heavy and doesn't benefit much from bucket sizing. For example, a > network forwarding test. Or maybe you could get someone like Netflix > that is using it to push a lot of bits with less filesystem cost than > zfs and spec. I am not sure what simple forwarding may show in this case. Even on my workload with ZFS creating strong memory pressure I still have mbuf* zones buckets almost (some totally) maxed out. Without other major (or even any) pressure in system they just can't become bigger then maximum. But if you can propose some interesting test case with pressure that I can reproduce -- I am all ears. > Second, the cpu binding is a very costly and very high-latency > operation. It would make sense to do CPU_FOREACH and then ZONE_FOREACH. > You're also biasing the first zones in the list. The low memory > condition will more often clear after you check these first zones. So > you might just check it once and equally penalize all zones. I'm > concerned that doing CPU_FOREACH in every zone will slow the pagedaemon > more. I completely agree with all you said here. This part of code I just took as-is from earlier work. It definitely can be improved. I'll take a look on that. But as I have mentioned in one of earlier responses that code used in _very_ rare cases, unless system is heavily overloaded on memory, like doing ZFS on box with 24 cores and 2GB RAM. During reasonable operation it is enough to have soft back pressure to keep on caches in shape and never call that. > We also have been working towards per-domain pagedaemons so > perhaps we should have a uma-reclaim taskqueue that we wake up to do the > work? VM is not my area so far, so please propose "the right way". I took this task now only because I have to due to huge performance bottleneck this problem causes and years it remains unsolved. > Third, using vm_page_count_min() will only trigger when the pageout > daemon can't keep up with the free target. Typically this should only > happen with a lot of dirty mmap'd pages or incredibly high system load > coupled with frequent allocations. So there may be many cases where > reclaiming the extra UMA memory is helpful but the pagedaemon can still > keep up while pushing out file pages that we'd prefer to keep. As I have told that is indeed last resort. It does not need to be done often. Per-CPU caches just should not grow without real need to the point when they have to be cleaned. > I think the perfect heuristic would have some idea of how likely the UMA > pages are to be re-used immediately so we can more effectively tradeoff > between file pages and kernel memory cache. As it is now we limit the > uma_reclaim() calls to every 10 seconds when there is memory pressure. > Perhaps we could keep a timestamp for when the last slab was allocated > to a zone and do the more expensive reclaim on zones who have timestamps > that exceed some threshold? Then have a lower threshold for reclaiming > at all? Again, it doesn't need to be perfect, but I believe we can catch > a wider set of cases by carefully scheduling this. I was thinking about that too. But I think timestamps should be set not on slab, but on bucket. The fact that zone is not allocating new slabs does not mean it does not use its already allocated buckets. If we put time of the last refill into each bucket, then we should be able to purge all buckets, unused for specified period of time. Additionally we could put timestamp on zone and update it every time zone runs out of its cache. If zone does not run out of cache for some time -- probably it has unused buckets. So when we need some RAM we should take a first look on zones that had stale timestamp. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 20:12:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9997E9E1; Mon, 18 Nov 2013 20:12:19 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A4D5246A; Mon, 18 Nov 2013 20:12:19 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id e16so2209772qcx.25 for ; Mon, 18 Nov 2013 12:12:18 -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=HqgiATGrJ/ODsDXBEhSOw2BEkJggcTDFe3Y+u3r8XaI=; b=h9blKoVL7Rtp3CsyIz17NF/++7F9nW8bKhDu1mlvf3SGX3ImW1PpVg/QQ2F3H24TSw ndOpDd7ddtDE4ep50g7o5Xu6C5FH1DqJvrkjq2Q9D1lR9AYX7MVWOiqwOmLbaSp8NHRw OVDJEOYnXmvMEqKlFwGsTpKsgHLFf+dqE6WfPrwoTTOL+/bvc5B/HgICi9Vaj1TWYzzA oRgLUABk2ApiQP8AwnftpPMlLvyYr0AJf9iBcqtOrpebHNLqYm3wUSRR+HReFOpPr4Iq 5FMTB28tAc+egTVHaQ3lWNBFjGyCWV1dHxYrbDDH3EuQmjqepw32We4cZMN2s3bKfOPW P9Jw== MIME-Version: 1.0 X-Received: by 10.49.71.207 with SMTP id x15mr37164431qeu.49.1384805538000; Mon, 18 Nov 2013 12:12:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 18 Nov 2013 12:12:17 -0800 (PST) In-Reply-To: <528A70A2.4010308@FreeBSD.org> References: <52894C92.60905@FreeBSD.org> <528A70A2.4010308@FreeBSD.org> Date: Mon, 18 Nov 2013 12:12:17 -0800 X-Google-Sender-Auth: -bRyyF1NPA-IgriJgTBwA18SvkM Message-ID: Subject: Re: UMA cache back pressure From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" , Jeff Roberson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 20:12:19 -0000 Remember that for Netflix, we have a mostly non-cachable workload (with some very specific exceptions!) and thus we churn through VM pages at a presitidigious rate. 20gbit sec, or ~ 2.4 gigabytes a second, or ~ 680,000 4 kilobyte pages a second. It's quite frightening and it's only likely to increase. There's a lot of pressure from all over the place so IIRC pools tend to not stay very large for very long. That's why I'm interested in your specific situations. Doing an all CPU TLB shootdown with 24 cores is costly. But after we killed some incorrect KVA mapping flags for sendfile, we (netflix) totally stopped seeing the TLB shootdown and IPIs in any of the performance traces. Now, doing 24 cores worth of ZFS when you let the pools grow to the size you do is understandable, but I'd like to just make sure that you aren't breaking performance for people doing different workloads on less cores. I'm a bit busy at work with other things so I can't spin up your patch on a cache for another week or two. But I'll certainly get around to it as I'd like to see this stuff catch on. What I _can_ do in a reasonably immediate timeframe is update vm0.freebsd.org to the latest -HEAD and stress test your patch out. I'm using vm0.freebsd.org to stress test -HEAD with ZFS doing concurrent poudriere builds so it gets very crowded on that box. The box currently survives a couple days before I hit some races to do with vnode exhaustion and a lack of handling there, and ZFS deadlocks. I'll just run this up to see if anything unexpected happens that causes it to blow up in a different way. Thanks, -adrian On 18 November 2013 11:55, Alexander Motin wrote: > On 18.11.2013 21:11, Jeff Roberson wrote: >> >> On Mon, 18 Nov 2013, Alexander Motin wrote: >>> >>> I've created patch, based on earlier work of avg@, to add back >>> pressure to UMA allocation caches. The problem of physical memory or >>> KVA exhaustion existed there for many years and it is quite critical >>> now for improving systems performance while keeping stability. Changes >>> done in memory allocation last years improved situation. but haven't >>> fixed completely. My patch solves remaining problems from two sides: >>> a) reducing bucket sizes every time system detects low memory >>> condition; and b) as last-resort mechanism for very low memory >>> condition, it cycling over all CPUs to purge their per-CPU UMA caches. >>> Benefit of this approach is in absence of any additional hard-coded >>> limits on cache sizes -- they are self-tuned, based on load and memory >>> pressure. >>> >>> With this change I believe it should be safe enough to enable UMA >>> allocation caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for >>> amd64). I did many tests on machine with 24 logical cores (and as >>> result strong allocation cache effects), and can say that with 40GB >>> RAM using UMA caches, allowed by this change, by two times increases >>> results of SPEC NFS benchmark on ZFS pool of several SSDs. To test >>> system stability I've run the same test with physical memory limited >>> to just 2GB and system successfully survived that, and even showed >>> results 1.5 times better then with just last resort measures of b). In >>> both cases tools/umastat no longer shows unbound UMA cache growth, >>> that makes me believe in viability of this approach for longer runs. >>> >>> I would like to hear some comments about that: >>> http://people.freebsd.org/~mav/uma_pressure.patch >> >> >> Hey Mav, >> >> This is a great start and great results. I think it could probably even >> go in as-is, but I have a few suggestions. > > > Hey! Thanks for your review. I appreciate. > > >> First, let's test this with something that is really super allocator >> heavy and doesn't benefit much from bucket sizing. For example, a >> network forwarding test. Or maybe you could get someone like Netflix >> that is using it to push a lot of bits with less filesystem cost than >> zfs and spec. > > > I am not sure what simple forwarding may show in this case. Even on my > workload with ZFS creating strong memory pressure I still have mbuf* zones > buckets almost (some totally) maxed out. Without other major (or even any) > pressure in system they just can't become bigger then maximum. But if you > can propose some interesting test case with pressure that I can reproduce -- > I am all ears. > > >> Second, the cpu binding is a very costly and very high-latency >> operation. It would make sense to do CPU_FOREACH and then ZONE_FOREACH. >> You're also biasing the first zones in the list. The low memory >> condition will more often clear after you check these first zones. So >> you might just check it once and equally penalize all zones. I'm >> concerned that doing CPU_FOREACH in every zone will slow the pagedaemon >> more. > > > I completely agree with all you said here. This part of code I just took > as-is from earlier work. It definitely can be improved. I'll take a look on > that. But as I have mentioned in one of earlier responses that code used in > _very_ rare cases, unless system is heavily overloaded on memory, like doing > ZFS on box with 24 cores and 2GB RAM. During reasonable operation it is > enough to have soft back pressure to keep on caches in shape and never call > that. > > >> We also have been working towards per-domain pagedaemons so >> perhaps we should have a uma-reclaim taskqueue that we wake up to do the >> work? > > > VM is not my area so far, so please propose "the right way". I took this > task now only because I have to due to huge performance bottleneck this > problem causes and years it remains unsolved. > > >> Third, using vm_page_count_min() will only trigger when the pageout >> daemon can't keep up with the free target. Typically this should only >> happen with a lot of dirty mmap'd pages or incredibly high system load >> coupled with frequent allocations. So there may be many cases where >> reclaiming the extra UMA memory is helpful but the pagedaemon can still >> keep up while pushing out file pages that we'd prefer to keep. > > > As I have told that is indeed last resort. It does not need to be done > often. Per-CPU caches just should not grow without real need to the point > when they have to be cleaned. > > >> I think the perfect heuristic would have some idea of how likely the UMA >> pages are to be re-used immediately so we can more effectively tradeoff >> between file pages and kernel memory cache. As it is now we limit the >> uma_reclaim() calls to every 10 seconds when there is memory pressure. >> Perhaps we could keep a timestamp for when the last slab was allocated >> to a zone and do the more expensive reclaim on zones who have timestamps >> that exceed some threshold? Then have a lower threshold for reclaiming >> at all? Again, it doesn't need to be perfect, but I believe we can catch >> a wider set of cases by carefully scheduling this. > > > I was thinking about that too. But I think timestamps should be set not on > slab, but on bucket. The fact that zone is not allocating new slabs does not > mean it does not use its already allocated buckets. If we put time of the > last refill into each bucket, then we should be able to purge all buckets, > unused for specified period of time. Additionally we could put timestamp on > zone and update it every time zone runs out of its cache. If zone does not > run out of cache for some time -- probably it has unused buckets. So when we > need some RAM we should take a first look on zones that had stale timestamp. > > > -- > Alexander Motin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 22:01:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77D64293 for ; Mon, 18 Nov 2013 22:01:13 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8CD62A1C for ; Mon, 18 Nov 2013 22:01:12 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id rAIM0tso048583; Mon, 18 Nov 2013 23:01:09 +0100 (CET) (envelope-from andreast@FreeBSD.org) Message-ID: <528A8E17.5090307@FreeBSD.org> Date: Mon, 18 Nov 2013 23:00:55 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: WEAK_REFERENCE? References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> <5283ECA3.4080502@FreeBSD.org> <20131114060026.GH59496@kib.kiev.ua> In-Reply-To: <20131114060026.GH59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 22:01:13 -0000 On 14.11.13 07:00, Konstantin Belousov wrote: > On Wed, Nov 13, 2013 at 10:18:27PM +0100, Andreas Tobler wrote: >> On 11.11.13 08:47, Konstantin Belousov wrote: >>> On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote: >>>> Hi all, >>>> >>>> anyone interested in this patch to remove the WEAK_ALIAS and introduce >>>> the WEAK_REFERENCE? >>>> >>>> http://people.freebsd.org/~andreast/weak_ref.amd64.diff >>>> >>>> I have this running since months on amd64 and I have no issues with. >>>> >>>> I remember having had a communication with bde@ that he is in favour in >>>> doing that but I lacked the time to complete. >>>> A similar thing is pending for i386 and sparc64. The ppc stuff is >>>> already committed since a longer time. >>>> >>>> If no one is interested, I'm happy to clean up my tree and skip this. >>> >>> I am not sure why do you include the changes to END() in the same patch. >>> Did you looked over the all END() usages on amd64, is it always paired >>> with ENTRY() ? The CNAME() for ELF is the pedantism anyway. >>> >>> Other than the somewhat questionable inclusion of the END() change, which >>> should be committed separately, if ever, I think the change is fine. >> >> Am I correct, without this line in sys/amd64/include/asm.h? >> >> #define END(name) .size CNAME(name), . - CNAME(name) > Yes. If committing it, please make separate commit. Ok, thanks! >> If so, I just need a usable dot.emacs file to match the formatting >> expectations from bde. Sounds easy, but I didn't succeed so far. > Nah, cannot be. Emacs source code has too many inconsistencies, the > code does not follow its own style. I doubt Bruce would use it. :) I asked and learned, (n)vi(m).... it is much simpler than I thought. Keep it simple.... I prepared two patches, see below. The amd64 one is reviewed by bde@ and the i386 is compile tested by me (runtime is theoretically also done, but I'm not sure since I do not have 32-bit apps on my amd64). The amd64 is compile and runtime tested. The tools, nm, shows that we have the weak_references as before. If you agree I'd like to commit both within a few days to -CURRENT. If someone steps up and confirms that the i386 part also runs, would be great, but I expect it to work. If I'm correct, there is some similar work to be done on arm, mips and sparc64, I'm happy to do this if the people like to have it done. But I do not own either of them to test in native config. Except sparc64..... Here I have blech ;) Here the two patches amd64: http://people.freebsd.org/~andreast/weak_ref_amd64.diff i386: http://people.freebsd.org/~andreast/weak_ref_i386.diff Thanks for feedback. Andreas From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 22:56:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65C598DD; Mon, 18 Nov 2013 22:56:10 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 196EB2E3C; Mon, 18 Nov 2013 22:56:10 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id f11so1669910qae.12 for ; Mon, 18 Nov 2013 14:56:09 -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=qFfRUATFkSOoPsXZk9+V+lDSDfy+iIaLEw9531Vnco0=; b=lBCDuKHzBABcEylXAhsR9dtBBkfss+fQOHrG/gOEbmfx/XViLAkvwLh6U5HCGgEl4p o8JUt7/WflAWRLjN1gLDQmF4Rt7UeTbxvq3h7h1n1Vn3gHXc0xaG2ISrCOD4dV9dmUDX lJKFxL4+RL/aRoJ0GR4GEdwJvqBGc+MJZ/frn56ZnDLHnb7E2G8pcpVFCU3pade0oMxj bc4XcLKtUa26f1BZO08e3XQFw6IOGLaho+bXBWrDQu/mDJ0w1n1rHSNSlSuI8YdXSaJC fbcj1sUApfRxqXOiy6bzRcfYl5tTVPeocrYSTwA6NM/AK4EAp2OtqCL1C1lcczEMM4/n UoNA== MIME-Version: 1.0 X-Received: by 10.224.64.200 with SMTP id f8mr38609654qai.55.1384815369214; Mon, 18 Nov 2013 14:56:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 18 Nov 2013 14:56:09 -0800 (PST) In-Reply-To: <528A8E17.5090307@FreeBSD.org> References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> <5283ECA3.4080502@FreeBSD.org> <20131114060026.GH59496@kib.kiev.ua> <528A8E17.5090307@FreeBSD.org> Date: Mon, 18 Nov 2013 14:56:09 -0800 X-Google-Sender-Auth: rRcPP1StX00T7fK3gAxL2-n3aaI Message-ID: Subject: Re: WEAK_REFERENCE? From: Adrian Chadd To: Andreas Tobler Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Current , Bruce Evans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 22:56:10 -0000 [snip] wiki.freebsd.org/FreeBSD/mips has links to the MIPS emulator setups. There's no excuse to avoid testing on MIPS. :-) -adrian From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 23:16:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9797B6F0; Mon, 18 Nov 2013 23:16:13 +0000 (UTC) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD90217A; Mon, 18 Nov 2013 23:16:12 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 947E184F25C6; Mon, 18 Nov 2013 19:29:10 +0100 (CET) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id 8zFy7vEC72Mu; Mon, 18 Nov 2013 19:29:08 +0100 (CET) Received: from workstation.local (p579D2B3C.dip0.t-ipconnect.de [87.157.43.60]) by mail.s1.d2ux.org (Postfix) with ESMTPSA id 75F8584F25C0; Mon, 18 Nov 2013 19:29:08 +0100 (CET) Message-ID: <528A5BC2.70601@petermann-it.de> Date: Mon, 18 Nov 2013 19:26:10 +0100 From: Matthias Petermann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-java@freebsd.org, freebsd-ports@freebsd.org Subject: Is there already staging support within /ports/Mk/bsd.java.mk? X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 23:16:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, while updating my SweetHome3D port I'd like to enable staging support. The build process is using bsd.java.mk to build via ant. After removing NO_STAGE and adding ${STAGEDIR} to the respective directories, I get the following message at *make stage*: ===> Building for sweethome3d-4.2 Buildfile: /usr/ports/cad/sweethome3d/work/SweetHome3D-4.2-src/build.xml BUILD FAILED Target "DESTDIR=/usr/ports/cad/sweethome3d/work/stage" does not exist in the project "SweetHome3D". Appears like the DESTDIR is passed as a target to ant. I will definitely do more investigation here, but before I do I'd like to know if the bsd.java.mk already supports staging, or if this is a case for staying with NO_STAGE temporarely? Best regards, Matthias - -- Matthias Petermann | www.petermann-it.de GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSilvCAAoJEHsdo8NcPm11GisP/iFvpDpftI5TPZa1Q8qnPaLO l26qjcnMeUH7pgQE5d3jIV8PHi/qGZSkr89H8irO3DqWJM9Su+pK7Tt2yHepd6UF V2NjQS8eSeP6a5Tj4D1Cv/a9/mbBgsJ+kxNLdlBriXp7NPYTKK4XqUMliZP2cDjB KkDv66yxq9chGEtQtALfdAQNvnFeCNVp9lyF4+rFPmQsed36TmJfkaU//fFMFvIv 0G3XL4cayEYQAgxEX5iw1GXXta4gp4Po0/YmvjJJo6MUA/tXsK9deRFL4Eks/9FW jOSNuXevZy1HN+pDKgc7qyDZDzJzh6x/ak+YVNUWZiPgqQL2+mBlYEryBIgCUyjT 4jNzEI2G0he4vALm1Zr+UUw2ajpULQa0S9yE40Z6S4H1rHPoq8YfrbQxE5YyX26S FU8mskQy7uNP4VTwZ2uwn80rSJF8ICBTliqTtqY15SdADyr3jx2NvtcwYI8oc6vc +ZvfS2HmhgQhO03d1UsxFsmeTUlWSr4tG6nJiktZp6qqsIJK3mA7IFtLk3B0v2AR F4h9NS9dwyIUAqKtwJV+wOHt55t7P2WXN5UNcFrQw1bx/F/bURBIV3y0/UW8K3vA VSEZODNW/ZpevpsSdUUTTrya7kFZ4noQVO2awOVyZfxxH3IfHS3Ppv/PBzc/ZvAR ZLnzaU9gSGtT12MAQHGa =w+hC -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 23:20:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3C6B951; Mon, 18 Nov 2013 23:20:24 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 387DE21F1; Mon, 18 Nov 2013 23:20:23 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id rAINKFSP015840; Tue, 19 Nov 2013 00:20:19 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <528AA0AF.1000400@fgznet.ch> Date: Tue, 19 Nov 2013 00:20:15 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , Andreas Tobler Subject: Re: WEAK_REFERENCE? References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> <5283ECA3.4080502@FreeBSD.org> <20131114060026.GH59496@kib.kiev.ua> <528A8E17.5090307@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Konstantin Belousov , Current , Bruce Evans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 23:20:24 -0000 On 18.11.13 23:56, Adrian Chadd wrote: > [snip] > > wiki.freebsd.org/FreeBSD/mips has links to the MIPS emulator setups. > > There's no excuse to avoid testing on MIPS. :-) Np, wasn't aware of that...... :) And I do not shy the work..... Thanks, Andreas From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 00:22:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2701F488 for ; Tue, 19 Nov 2013 00:22:37 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E29E7251D for ; Tue, 19 Nov 2013 00:22:36 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 383E3DC6 for ; Tue, 19 Nov 2013 01:22:34 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: current@freebsd.org Subject: random_harvestq eats much on geode-lx alix2c3 Date: Tue, 19 Nov 2013 01:22:33 +0100 Message-ID: <4041856.BpQXZdSKfK@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0ricer-09579-g049ffa8; KDE/4.11.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Mailman-Approved-At: Tue, 19 Nov 2013 02:13:06 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 00:22:37 -0000 Hey, random_harvestq eats much, much CPU on alix2c3: CPU: Geode(TM) Integrated Processor by AMD PCS (498.06-MHz 586-class CPU) glxsb0: mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 Could you please add a sysctl/loader knob for it, or a way to throttle collection? Here's top output: 14 root 1 -16 - 0K 8K - 6:12 15.97% rand_harvestq cheers, -sh -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 03:54:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA9A5C3B for ; Tue, 19 Nov 2013 03:54:59 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1F632048 for ; Tue, 19 Nov 2013 03:54:59 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id rq2so5607952pbb.2 for ; Mon, 18 Nov 2013 19:54:53 -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:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=HMXfPC5MgeeZiW4Xl2FDvu4fohfBX8Z/xq8+r8X8A1g=; b=Fztoha1ENtVrD9meWIUUmyG6ixjiEdZMG/+vg3tFNjPl/6qFhb3ly9FhBuoYqF6vMJ HTg0Oyjgz8CstgLtzy/2eyS7ZXJ1aimafc/hQ5/ED47nRbuYpVPojf29/GsCnLMCE/2s MCvmpjrAwfm0ytboaA9StqvWKp5I8mct2HgYN4vqiR05ndra1BpVjYp9AXqlVpYL2u52 Us0SxZsP/O3L0GyxIAAEv+u2xM31+3cPjyKYjjs7vcfBLdL/IMBTL9iFyp4oO08369Sz ZT8SmWw2wYzg8mHx+LlZiWqkhtLyVK7iWxBJmNlxJn/4B+p4OYEBj0+p58uIG0IeKo/y H2XA== X-Gm-Message-State: ALoCoQm3f6hvj51x1sfWikZ5sLiSCnuCOiTYV5y2vIVtTaE303jxAGKPI9PAD4mOcz7qkn8aSPJN X-Received: by 10.68.218.3 with SMTP id pc3mr16807146pbc.71.1384833293474; Mon, 18 Nov 2013 19:54:53 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPSA id gg10sm26972304pbc.46.2013.11.18.19.54.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Nov 2013 19:54:52 -0800 (PST) Date: Mon, 18 Nov 2013 17:50:54 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alexander Motin Subject: Re: UMA cache back pressure In-Reply-To: <528A70A2.4010308@FreeBSD.org> Message-ID: References: <52894C92.60905@FreeBSD.org> <528A70A2.4010308@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 03:54:59 -0000 On Mon, 18 Nov 2013, Alexander Motin wrote: > On 18.11.2013 21:11, Jeff Roberson wrote: >> On Mon, 18 Nov 2013, Alexander Motin wrote: >>> I've created patch, based on earlier work of avg@, to add back >>> pressure to UMA allocation caches. The problem of physical memory or >>> KVA exhaustion existed there for many years and it is quite critical >>> now for improving systems performance while keeping stability. Changes >>> done in memory allocation last years improved situation. but haven't >>> fixed completely. My patch solves remaining problems from two sides: >>> a) reducing bucket sizes every time system detects low memory >>> condition; and b) as last-resort mechanism for very low memory >>> condition, it cycling over all CPUs to purge their per-CPU UMA caches. >>> Benefit of this approach is in absence of any additional hard-coded >>> limits on cache sizes -- they are self-tuned, based on load and memory >>> pressure. >>> >>> With this change I believe it should be safe enough to enable UMA >>> allocation caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for >>> amd64). I did many tests on machine with 24 logical cores (and as >>> result strong allocation cache effects), and can say that with 40GB >>> RAM using UMA caches, allowed by this change, by two times increases >>> results of SPEC NFS benchmark on ZFS pool of several SSDs. To test >>> system stability I've run the same test with physical memory limited >>> to just 2GB and system successfully survived that, and even showed >>> results 1.5 times better then with just last resort measures of b). In >>> both cases tools/umastat no longer shows unbound UMA cache growth, >>> that makes me believe in viability of this approach for longer runs. >>> >>> I would like to hear some comments about that: >>> http://people.freebsd.org/~mav/uma_pressure.patch >> >> Hey Mav, >> >> This is a great start and great results. I think it could probably even >> go in as-is, but I have a few suggestions. > > Hey! Thanks for your review. I appreciate. And I appreciate more people being interested in working on the allocator. > >> First, let's test this with something that is really super allocator >> heavy and doesn't benefit much from bucket sizing. For example, a >> network forwarding test. Or maybe you could get someone like Netflix >> that is using it to push a lot of bits with less filesystem cost than >> zfs and spec. > > I am not sure what simple forwarding may show in this case. Even on my > workload with ZFS creating strong memory pressure I still have mbuf* zones > buckets almost (some totally) maxed out. Without other major (or even any) > pressure in system they just can't become bigger then maximum. But if you can > propose some interesting test case with pressure that I can reproduce -- I am > all ears. I think part of that is also because you're using min free pages right now as your threshold. It should probably be triggering slightly more often. > >> Second, the cpu binding is a very costly and very high-latency >> operation. It would make sense to do CPU_FOREACH and then ZONE_FOREACH. >> You're also biasing the first zones in the list. The low memory >> condition will more often clear after you check these first zones. So >> you might just check it once and equally penalize all zones. I'm >> concerned that doing CPU_FOREACH in every zone will slow the pagedaemon >> more. > > I completely agree with all you said here. This part of code I just took > as-is from earlier work. It definitely can be improved. I'll take a look on > that. But as I have mentioned in one of earlier responses that code used in > _very_ rare cases, unless system is heavily overloaded on memory, like doing > ZFS on box with 24 cores and 2GB RAM. During reasonable operation it is > enough to have soft back pressure to keep on caches in shape and never call > that. > >> We also have been working towards per-domain pagedaemons so >> perhaps we should have a uma-reclaim taskqueue that we wake up to do the >> work? > > VM is not my area so far, so please propose "the right way". I took this task > now only because I have to due to huge performance bottleneck this problem > causes and years it remains unsolved. Well it's probably fine to keep abusing the first domain's pageout daemon for now but we won't want to in the future, especially if we want to keep each domain's page daemon on the socket that it's managing. > >> Third, using vm_page_count_min() will only trigger when the pageout >> daemon can't keep up with the free target. Typically this should only >> happen with a lot of dirty mmap'd pages or incredibly high system load >> coupled with frequent allocations. So there may be many cases where >> reclaiming the extra UMA memory is helpful but the pagedaemon can still >> keep up while pushing out file pages that we'd prefer to keep. > > As I have told that is indeed last resort. It does not need to be done often. > Per-CPU caches just should not grow without real need to the point when they > have to be cleaned. Let me explain it differently. Right now you're handling cases of overloaded CPU, if we run this code under different conditions we could handle overloaded memory better as well. Imagine a system which has oversized buckets and lots of wasted memory but a pageout daemon which is still meeting targets by evicting page cache pages. Perhaps there was a temporary use of some very large zones which is no longer necessary. Since we meet the paging target quickly enough we will never discover this other memory that we can evict. Look at the vm page targets. The target is very far from the min. So typically the thread just wakes up and evicts clean pages very quickly to accommodate this. ZFS is particularly affected because its pages can't be evicted by the page daemon, so you're more likely to run out, but other systems would benefit from this and they do have pages which could be evicted where you'd like to preserve them by trimming the uma cache. Does that make sense? > >> I think the perfect heuristic would have some idea of how likely the UMA >> pages are to be re-used immediately so we can more effectively tradeoff >> between file pages and kernel memory cache. As it is now we limit the >> uma_reclaim() calls to every 10 seconds when there is memory pressure. >> Perhaps we could keep a timestamp for when the last slab was allocated >> to a zone and do the more expensive reclaim on zones who have timestamps >> that exceed some threshold? Then have a lower threshold for reclaiming >> at all? Again, it doesn't need to be perfect, but I believe we can catch >> a wider set of cases by carefully scheduling this. > > I was thinking about that too. But I think timestamps should be set not on > slab, but on bucket. The fact that zone is not allocating new slabs does not > mean it does not use its already allocated buckets. If we put time of the > last refill into each bucket, then we should be able to purge all buckets, > unused for specified period of time. Additionally we could put timestamp on > zone and update it every time zone runs out of its cache. If zone does not > run out of cache for some time -- probably it has unused buckets. So when we > need some RAM we should take a first look on zones that had stale timestamp. Many healthy flow control algorithms maintain a relatively steady state by periodically testing the edges. I would prefer to maintain the timestamp on a per-zone basis and not per-bucket anyway as it saves some space and we'd have to resize all the buckets if we take up another pointers space. Anyway, I'm not too dogmatic about it. There are probably several convenient ways to write it and no perfect one. May I suggest that you make the change to only FOREACH_CPU once and then commit with your current heuristic. Then we can try to take it one step further? Thanks, Jeff > > -- > Alexander Motin > From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 04:03:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA7D7EC9 for ; Tue, 19 Nov 2013 04:03:49 +0000 (UTC) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 81FD820D8 for ; Tue, 19 Nov 2013 04:03:49 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id fb1so7809289pad.10 for ; Mon, 18 Nov 2013 20:03:43 -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:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=6VF9TAgBSajXXWBrk0LFqIW0eS5I0BGL9U8kzpTXeFk=; b=Cj3yqfl9zhETNtoYtDw04v3MONIQdsbqpuJORBipURhkQIyKV8nDV0w+nNzvsNPHop SeFTwBXAqdsxT79EXLHnv92NZlbblm/bXpzH8hi0URnBfaTiaDVVk52G98kB0RLzCemq NIH4CYE291P48jt4bebkqY+qyU8w/PDkBcSda/oPSjtVR4AobhZ2pOn6oUAuEk3w2glI rR8hEqVeTDKjeNs8166nJYb+JYTIm88jLepZ76pAMyeGsINkd6mDq9pNOn7i3F2cRuyE rSrkje/PX4vaHHNQycO6O3G1AwICb7qZ016zlePvbU+heDnK7xVU8ED0LVytQ+J5SquJ s64A== X-Gm-Message-State: ALoCoQlGL9Dpq9+o7/LDJYcotx3bMprDXkNJ/p1HZtXD68fCVQKE+Wn04jJdwOHgVrsZuI/yE9Z1 X-Received: by 10.69.11.130 with SMTP id ei2mr6017490pbd.144.1384833417886; Mon, 18 Nov 2013 19:56:57 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPSA id g8sm13723486pbe.37.2013.11.18.19.56.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Nov 2013 19:56:57 -0800 (PST) Date: Mon, 18 Nov 2013 17:52:59 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Adrian Chadd Subject: Re: UMA cache back pressure In-Reply-To: Message-ID: References: <52894C92.60905@FreeBSD.org> <528A70A2.4010308@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 04:03:49 -0000 On Mon, 18 Nov 2013, Adrian Chadd wrote: > Remember that for Netflix, we have a mostly non-cachable workload > (with some very specific exceptions!) and thus we churn through VM > pages at a presitidigious rate. 20gbit sec, or ~ 2.4 gigabytes a > second, or ~ 680,000 4 kilobyte pages a second. It's quite frightening > and it's only likely to increase. > > There's a lot of pressure from all over the place so IIRC pools tend > to not stay very large for very long. I think the combination of a lot of cache pressure, a lot of allocator use, and no ZFS makes you an interesting candidate. > > That's why I'm interested in your specific situations. Doing an all > CPU TLB shootdown with 24 cores is costly. But after we killed some > incorrect KVA mapping flags for sendfile, we (netflix) totally stopped Do you have any information on what this change was? > seeing the TLB shootdown and IPIs in any of the performance traces. > Now, doing 24 cores worth of ZFS when you let the pools grow to the > size you do is understandable, but I'd like to just make sure that you > aren't breaking performance for people doing different workloads on > less cores. We also have opportunities now with vmem to cache KVA backed pages and release them together in bulk when necessary. However, remember most UMA memory won't need an IPI since it comes from the direct map. Only the few zones which use very large allocations will. Jeff > > I'm a bit busy at work with other things so I can't spin up your patch > on a cache for another week or two. But I'll certainly get around to > it as I'd like to see this stuff catch on. > > What I _can_ do in a reasonably immediate timeframe is update > vm0.freebsd.org to the latest -HEAD and stress test your patch out. > I'm using vm0.freebsd.org to stress test -HEAD with ZFS doing > concurrent poudriere builds so it gets very crowded on that box. The > box currently survives a couple days before I hit some races to do > with vnode exhaustion and a lack of handling there, and ZFS deadlocks. > I'll just run this up to see if anything unexpected happens that > causes it to blow up in a different way. > > Thanks, > > > > -adrian > > > On 18 November 2013 11:55, Alexander Motin wrote: >> On 18.11.2013 21:11, Jeff Roberson wrote: >>> >>> On Mon, 18 Nov 2013, Alexander Motin wrote: >>>> >>>> I've created patch, based on earlier work of avg@, to add back >>>> pressure to UMA allocation caches. The problem of physical memory or >>>> KVA exhaustion existed there for many years and it is quite critical >>>> now for improving systems performance while keeping stability. Changes >>>> done in memory allocation last years improved situation. but haven't >>>> fixed completely. My patch solves remaining problems from two sides: >>>> a) reducing bucket sizes every time system detects low memory >>>> condition; and b) as last-resort mechanism for very low memory >>>> condition, it cycling over all CPUs to purge their per-CPU UMA caches. >>>> Benefit of this approach is in absence of any additional hard-coded >>>> limits on cache sizes -- they are self-tuned, based on load and memory >>>> pressure. >>>> >>>> With this change I believe it should be safe enough to enable UMA >>>> allocation caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for >>>> amd64). I did many tests on machine with 24 logical cores (and as >>>> result strong allocation cache effects), and can say that with 40GB >>>> RAM using UMA caches, allowed by this change, by two times increases >>>> results of SPEC NFS benchmark on ZFS pool of several SSDs. To test >>>> system stability I've run the same test with physical memory limited >>>> to just 2GB and system successfully survived that, and even showed >>>> results 1.5 times better then with just last resort measures of b). In >>>> both cases tools/umastat no longer shows unbound UMA cache growth, >>>> that makes me believe in viability of this approach for longer runs. >>>> >>>> I would like to hear some comments about that: >>>> http://people.freebsd.org/~mav/uma_pressure.patch >>> >>> >>> Hey Mav, >>> >>> This is a great start and great results. I think it could probably even >>> go in as-is, but I have a few suggestions. >> >> >> Hey! Thanks for your review. I appreciate. >> >> >>> First, let's test this with something that is really super allocator >>> heavy and doesn't benefit much from bucket sizing. For example, a >>> network forwarding test. Or maybe you could get someone like Netflix >>> that is using it to push a lot of bits with less filesystem cost than >>> zfs and spec. >> >> >> I am not sure what simple forwarding may show in this case. Even on my >> workload with ZFS creating strong memory pressure I still have mbuf* zones >> buckets almost (some totally) maxed out. Without other major (or even any) >> pressure in system they just can't become bigger then maximum. But if you >> can propose some interesting test case with pressure that I can reproduce -- >> I am all ears. >> >> >>> Second, the cpu binding is a very costly and very high-latency >>> operation. It would make sense to do CPU_FOREACH and then ZONE_FOREACH. >>> You're also biasing the first zones in the list. The low memory >>> condition will more often clear after you check these first zones. So >>> you might just check it once and equally penalize all zones. I'm >>> concerned that doing CPU_FOREACH in every zone will slow the pagedaemon >>> more. >> >> >> I completely agree with all you said here. This part of code I just took >> as-is from earlier work. It definitely can be improved. I'll take a look on >> that. But as I have mentioned in one of earlier responses that code used in >> _very_ rare cases, unless system is heavily overloaded on memory, like doing >> ZFS on box with 24 cores and 2GB RAM. During reasonable operation it is >> enough to have soft back pressure to keep on caches in shape and never call >> that. >> >> >>> We also have been working towards per-domain pagedaemons so >>> perhaps we should have a uma-reclaim taskqueue that we wake up to do the >>> work? >> >> >> VM is not my area so far, so please propose "the right way". I took this >> task now only because I have to due to huge performance bottleneck this >> problem causes and years it remains unsolved. >> >> >>> Third, using vm_page_count_min() will only trigger when the pageout >>> daemon can't keep up with the free target. Typically this should only >>> happen with a lot of dirty mmap'd pages or incredibly high system load >>> coupled with frequent allocations. So there may be many cases where >>> reclaiming the extra UMA memory is helpful but the pagedaemon can still >>> keep up while pushing out file pages that we'd prefer to keep. >> >> >> As I have told that is indeed last resort. It does not need to be done >> often. Per-CPU caches just should not grow without real need to the point >> when they have to be cleaned. >> >> >>> I think the perfect heuristic would have some idea of how likely the UMA >>> pages are to be re-used immediately so we can more effectively tradeoff >>> between file pages and kernel memory cache. As it is now we limit the >>> uma_reclaim() calls to every 10 seconds when there is memory pressure. >>> Perhaps we could keep a timestamp for when the last slab was allocated >>> to a zone and do the more expensive reclaim on zones who have timestamps >>> that exceed some threshold? Then have a lower threshold for reclaiming >>> at all? Again, it doesn't need to be perfect, but I believe we can catch >>> a wider set of cases by carefully scheduling this. >> >> >> I was thinking about that too. But I think timestamps should be set not on >> slab, but on bucket. The fact that zone is not allocating new slabs does not >> mean it does not use its already allocated buckets. If we put time of the >> last refill into each bucket, then we should be able to purge all buckets, >> unused for specified period of time. Additionally we could put timestamp on >> zone and update it every time zone runs out of its cache. If zone does not >> run out of cache for some time -- probably it has unused buckets. So when we >> need some RAM we should take a first look on zones that had stale timestamp. >> >> >> -- >> Alexander Motin >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 07:23:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11B90518; Tue, 19 Nov 2013 07:23:24 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9201C293F; Tue, 19 Nov 2013 07:23:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAJ7ND5b026349; Tue, 19 Nov 2013 09:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAJ7ND5b026349 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAJ7NDiY026348; Tue, 19 Nov 2013 09:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 19 Nov 2013 09:23:12 +0200 From: Konstantin Belousov To: Andreas Tobler Subject: Re: WEAK_REFERENCE? Message-ID: <20131119072312.GW59496@kib.kiev.ua> References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> <5283ECA3.4080502@FreeBSD.org> <20131114060026.GH59496@kib.kiev.ua> <528A8E17.5090307@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gkqX2/sFY1Elt32G" Content-Disposition: inline In-Reply-To: <528A8E17.5090307@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 07:23:24 -0000 --gkqX2/sFY1Elt32G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 11:00:55PM +0100, Andreas Tobler wrote: > I prepared two patches, see below. The amd64 one is reviewed by bde@ and > the i386 is compile tested by me (runtime is theoretically also done, > but I'm not sure since I do not have 32-bit apps on my amd64). Use cc -m32. >=20 > The amd64 is compile and runtime tested. The tools, nm, shows that we > have the weak_references as before. >=20 > If you agree I'd like to commit both within a few days to -CURRENT. If > someone steps up and confirms that the i386 part also runs, would be > great, but I expect it to work. >=20 > If I'm correct, there is some similar work to be done on arm, mips and > sparc64, I'm happy to do this if the people like to have it done. But I > do not own either of them to test in native config. Except sparc64..... > Here I have blech ;) >=20 >=20 > Here the two patches > amd64: > http://people.freebsd.org/~andreast/weak_ref_amd64.diff > i386: > http://people.freebsd.org/~andreast/weak_ref_i386.diff Amd64 patch is fine. For i386, I do not see a definition of the WEAK_REFERENCE in the patch, and quick search of the pre-existing definition in sys/i386 or lib/libc/i386 does not reveal anything. --gkqX2/sFY1Elt32G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSixHgAAoJEJDCuSvBvK1B0KoP/1Gt5Keoc++RgWcdQTdH8G3q /tDeV+w7eANs8TP6yPaWq4zrF1U4qjqJN7rDgoQfRaEgyPSX/k1SF9HDJu7zT9JJ 28a+jwxQC1NtfLN7fzSjG4t46GTzQKQiDceyRabgxm+ABkwr2rsjfXiigrVWwePS OUGoYJyYz3x+I6i+FmOmPX3AudNee81JDYC5E0vzxLo8wSzeEIC5l9EhobqoKF21 ht2vyhvXRgPVSSA/dWXxm9qsUf0BqBqPZbdfiA0sqG7EUVbWcLsDaTlHjc3mx1zh rQm3VKzBTwhEZktc+rg1Soz302JPOAKokwb4KFBwnBqWOQcvVPmy8V08dY+nr0xM nQE6x0VaUcYBRPehtbF0J5o6yaUnRMI0Rxos5zJJzWj5cVK172xSP2YYPj1xf51a ib/RFCGgJhq+GbAmrepat9aiW50cQR9SkYujz2Rbg6HBx2/Qo1ccGsNyVjSACKp0 Pl99u2kSL4mi+hw0GdSALA7PmIJs/5o0NrOAagYnDveSvXB6hkYqEWr/3i/PaeNH Igsl9aKjIUNO2/KYFsyxCilkwZmsAHy65oEDcih6hxi9DBQh3fteEOz9E1mgz3os ALUanAHkQ5p86wgnx0+FnaxxX8O1pHqrQUsS1VelGMho802ogJ60QIxcK1sZfMIx bempidnvv213rcPoXGvh =FVvc -----END PGP SIGNATURE----- --gkqX2/sFY1Elt32G-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 16:22:10 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DC7DE7A; Tue, 19 Nov 2013 16:22:10 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 268E62B34; Tue, 19 Nov 2013 16:22:09 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 6C369157E3; Tue, 19 Nov 2013 16:22:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 6C369157E3 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 19 Nov 2013 11:22:05 -0500 From: Glen Barber To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: 10.0-RELEASE cycle status update Message-ID: <20131119162205.GW1643@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PjLo8P/CG6vpADRe" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:22:10 -0000 --PjLo8P/CG6vpADRe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As some may have noticed, the 10.0-RELEASE cycle has slipped a bit behind schedule. Here is where we stand at the moment: - The iconv issues mentioned in a previous status update email[1] are being looked at extensively. There are a number of iconv(3) fixes that have been committed to head/, which are pending MFC to stable/10 following the default 3-day merge period. Those tracking -CURRENT are encouraged to update their systems and report back (on -current@) any issues. Those awaiting the next 10.0 builds, please be patient. We will have the next round of builds for the 10.0-RELEASE cycle started as soon as possible. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075658.html Glen --PjLo8P/CG6vpADRe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSi5AtAAoJELls3eqvi17QjpoP/1E2hCA9AGkyegvw8Z+H6XIc tcYlvHniUGrnnScxmExMA7mjM1/Lkm4ok/a2bpiv4OqlfxQS8QQcC+IJFkbn5YCy 5UqW8ZBfoZjw1qZmDAOPoaoEkyzoJlyYvVw5XzcupIahFrkrVFc2DIb88lAZVbnh y4as5y/w8t3sN/2/rqPrNonPhc5Q8Ysz4EKjULHWz4Dy6vI+Nn4bnckCTe2lrswD qWwMtdq2F3Dhc+K6tPN6ZQ2fXCdtDoAdMQ1QMzbkNpc9q1i6yPcROsH/FEREebDA ceGW9iE/r/1S1K+A4W+yCI4La97qpZcyl5x2ABO3mZHXpGgEofC55eamCtP4n5y9 nCgkBA9h10uIH1noiFPHadMzh4L2LL/+JU49P5b4IKG0m6wZ+MKQSqbZbHtZUrj3 agS98ryAHgzdZdIIPB13nUdx9vDPu+rb8BC+WorEBVFVdWxkNjv8KYG93FWJtfJN tb2qhTtYyb3OFRKQT7RvM0gTiSq16YQYTkwX8XW/qkOUllEJ00lBlRDMtMKbkfd7 +u97V1zCe3F9DAQaGLRQdZPCcmipr8Sk5KJI/o+A2dX6GFAYPAFZl+sNFTNO0M3v pDB8yS1J3WIVz6mn8M1sQuDHN8lZ3W7oHteZ892avtK9JfRxv4qrjWNS1wCri07j XvK4CoY8rhJQEz8YKQ/H =+cSj -----END PGP SIGNATURE----- --PjLo8P/CG6vpADRe-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 17:51:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E65FA46E for ; Tue, 19 Nov 2013 17:51:05 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7CE172FFD for ; Tue, 19 Nov 2013 17:51:04 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id rAJHouLo050570; Tue, 19 Nov 2013 18:51:00 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <528BA500.4050203@fgznet.ch> Date: Tue, 19 Nov 2013 18:50:56 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: WEAK_REFERENCE? References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> <5283ECA3.4080502@FreeBSD.org> <20131114060026.GH59496@kib.kiev.ua> <528A8E17.5090307@FreeBSD.org> <20131119072312.GW59496@kib.kiev.ua> In-Reply-To: <20131119072312.GW59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 17:51:06 -0000 On 19.11.13 08:23, Konstantin Belousov wrote: > On Mon, Nov 18, 2013 at 11:00:55PM +0100, Andreas Tobler wrote: >> I prepared two patches, see below. The amd64 one is reviewed by bde@ and >> the i386 is compile tested by me (runtime is theoretically also done, >> but I'm not sure since I do not have 32-bit apps on my amd64). > Use cc -m32. > >> >> The amd64 is compile and runtime tested. The tools, nm, shows that we >> have the weak_references as before. >> >> If you agree I'd like to commit both within a few days to -CURRENT. If >> someone steps up and confirms that the i386 part also runs, would be >> great, but I expect it to work. >> >> If I'm correct, there is some similar work to be done on arm, mips and >> sparc64, I'm happy to do this if the people like to have it done. But I >> do not own either of them to test in native config. Except sparc64..... >> Here I have blech ;) >> >> >> Here the two patches >> amd64: >> http://people.freebsd.org/~andreast/weak_ref_amd64.diff >> i386: >> http://people.freebsd.org/~andreast/weak_ref_i386.diff > > Amd64 patch is fine. For i386, I do not see a definition of the > WEAK_REFERENCE in the patch, and quick search of the pre-existing > definition in sys/i386 or lib/libc/i386 does not reveal anything. It's there now. Updated the diff. Thanks, Andreas From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 18:50:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3164ECE6; Tue, 19 Nov 2013 18:50:27 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1C30023F4; Tue, 19 Nov 2013 18:50:25 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA10663; Tue, 19 Nov 2013 20:50:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ViqNT-000KrX-Fy; Tue, 19 Nov 2013 20:50:23 +0200 Message-ID: <528BB2B7.8060908@FreeBSD.org> Date: Tue, 19 Nov 2013 20:49:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, FreeBSD Current Subject: provide fast versions of ffsl and flsl for i386; ffsll and flsll for amd64 X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 18:50:27 -0000 These are just trivial wrappers based on the fact that int and long on i386 have the same "bit layout" and likewise for long and long long on amd64. For your reviewing pleasure :-) Thanks! commit fdc1228b113f8b4c9dbda2b0323cb087c6b6df9d Author: Andriy Gapon Date: Thu Nov 7 19:13:00 2013 +0200 provide fast versions of ffsl and flsl for i386; ffsll and flsll for amd64 diff --git a/sys/amd64/include/cpufunc.h b/sys/amd64/include/cpufunc.h index 5f8197b..7464739 100644 --- a/sys/amd64/include/cpufunc.h +++ b/sys/amd64/include/cpufunc.h @@ -154,6 +154,14 @@ ffsl(long mask) return (mask == 0 ? mask : (int)bsfq((u_long)mask) + 1); } +#define HAVE_INLINE_FFSLL + +static __inline int +ffsll(long long mask) +{ + return (ffsl((long)mask)); +} + #define HAVE_INLINE_FLS static __inline int @@ -170,6 +178,14 @@ flsl(long mask) return (mask == 0 ? mask : (int)bsrq((u_long)mask) + 1); } +#define HAVE_INLINE_FLSLL + +static __inline int +flsll(long long mask) +{ + return (flsl((long)mask)); +} + #endif /* _KERNEL */ static __inline void diff --git a/sys/conf/files b/sys/conf/files index d41b9d2..8077bfc 100644 --- a/sys/conf/files +++ b/sys/conf/files @@ -3029,7 +3029,6 @@ libkern/arc4random.c standard libkern/bcd.c standard libkern/bsearch.c standard libkern/crc32.c standard -libkern/flsll.c standard libkern/fnmatch.c standard libkern/iconv.c optional libiconv libkern/iconv_converter_if.m optional libiconv diff --git a/sys/conf/files.arm b/sys/conf/files.arm index 603fb2d..d15f014 100644 --- a/sys/conf/files.arm +++ b/sys/conf/files.arm @@ -87,6 +87,7 @@ libkern/divdi3.c standard libkern/ffsl.c standard libkern/fls.c standard libkern/flsl.c standard +libkern/flsll.c standard libkern/lshrdi3.c standard libkern/moddi3.c standard libkern/qdivrem.c standard diff --git a/sys/conf/files.i386 b/sys/conf/files.i386 index 23e03a3..030dbe1 100644 --- a/sys/conf/files.i386 +++ b/sys/conf/files.i386 @@ -524,8 +524,7 @@ kern/kern_clocksource.c standard kern/imgact_aout.c optional compat_aout kern/imgact_gzip.c optional gzip libkern/divdi3.c standard -libkern/ffsl.c standard -libkern/flsl.c standard +libkern/flsll.c standard libkern/memmove.c standard libkern/memset.c standard libkern/moddi3.c standard diff --git a/sys/conf/files.ia64 b/sys/conf/files.ia64 index 6719c98..e85c35d 100644 --- a/sys/conf/files.ia64 +++ b/sys/conf/files.ia64 @@ -120,6 +120,7 @@ libkern/bcmp.c standard libkern/ffsl.c standard libkern/fls.c standard libkern/flsl.c standard +libkern/flsll.c standard libkern/ia64/__divdi3.S standard libkern/ia64/__divsi3.S standard libkern/ia64/__moddi3.S standard diff --git a/sys/conf/files.mips b/sys/conf/files.mips index 82d9a69..6522bb2 100644 --- a/sys/conf/files.mips +++ b/sys/conf/files.mips @@ -56,6 +56,7 @@ kern/subr_dummy_vdso_tc.c standard libkern/ffsl.c standard libkern/fls.c standard libkern/flsl.c standard +libkern/flsll.c standard libkern/memmove.c standard libkern/cmpdi2.c optional mips | mipsel libkern/ucmpdi2.c optional mips | mipsel diff --git a/sys/conf/files.pc98 b/sys/conf/files.pc98 index fd3ad4a..c95d956 100644 --- a/sys/conf/files.pc98 +++ b/sys/conf/files.pc98 @@ -210,6 +210,7 @@ kern/imgact_gzip.c optional gzip libkern/divdi3.c standard libkern/ffsl.c standard libkern/flsl.c standard +libkern/flsll.c standard libkern/memmove.c standard libkern/memset.c standard libkern/moddi3.c standard diff --git a/sys/conf/files.powerpc b/sys/conf/files.powerpc index 6d90fc7..98b3da0 100644 --- a/sys/conf/files.powerpc +++ b/sys/conf/files.powerpc @@ -79,6 +79,7 @@ libkern/ffs.c standard libkern/ffsl.c standard libkern/fls.c standard libkern/flsl.c standard +libkern/flsll.c standard libkern/lshrdi3.c optional powerpc libkern/memmove.c standard libkern/memset.c standard diff --git a/sys/conf/files.sparc64 b/sys/conf/files.sparc64 index 5c00350..ccee247 100644 --- a/sys/conf/files.sparc64 +++ b/sys/conf/files.sparc64 @@ -68,6 +68,7 @@ libkern/ffs.c standard libkern/ffsl.c standard libkern/fls.c standard libkern/flsl.c standard +libkern/flsll.c standard libkern/memmove.c standard sparc64/central/central.c optional central sparc64/ebus/ebus.c optional ebus diff --git a/sys/i386/include/cpufunc.h b/sys/i386/include/cpufunc.h index 7cd3663..98f82f2 100644 --- a/sys/i386/include/cpufunc.h +++ b/sys/i386/include/cpufunc.h @@ -184,6 +184,14 @@ ffs(int mask) return (mask == 0 ? mask : (int)bsfl((u_int)mask) + 1); } +#define HAVE_INLINE_FFSL + +static __inline int +ffsl(long mask) +{ + return (ffs((int)mask)); +} + #define HAVE_INLINE_FLS static __inline int @@ -192,6 +200,14 @@ fls(int mask) return (mask == 0 ? mask : (int)bsrl((u_int)mask) + 1); } +#define HAVE_INLINE_FLSL + +static __inline int +flsl(long mask) +{ + return (fls((int)mask)); +} + #endif /* _KERNEL */ static __inline void -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 23:01:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8746871B; Tue, 19 Nov 2013 23:01:49 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF052445; Tue, 19 Nov 2013 23:01:49 +0000 (UTC) Received: from [2001:470:9174:1:2889:e288:7bda:7aab] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1ViuIh-000Fjd-TB; Tue, 19 Nov 2013 23:01:46 +0000 Subject: Re: random_harvestq eats much on geode-lx alix2c3 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1164B259-0D04-4D63-A73E-63B41B57DC4D"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <4041856.BpQXZdSKfK@aurora> Date: Tue, 19 Nov 2013 23:01:37 +0000 Message-Id: References: <4041856.BpQXZdSKfK@aurora> To: =?utf-8?Q?Stanis=C5=82aw_Halik?= X-Mailer: Apple Mail (2.1822) X-SA-Score: -1.0 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:01:49 -0000 --Apple-Mail=_1164B259-0D04-4D63-A73E-63B41B57DC4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 19 Nov 2013, at 00:22, Stanis=C5=82aw Halik = wrote: > Hey, >=20 > random_harvestq eats much, much CPU on alix2c3: >=20 > CPU: Geode(TM) Integrated Processor by AMD PCS (498.06-MHz 586-class = CPU) > glxsb0: mem=20 > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 >=20 > Could you please add a sysctl/loader knob for it, or a way to throttle=20= > collection? >=20 > Here's top output: >=20 > 14 root 1 -16 - 0K 8K - 6:12 15.97% = rand_harvestq Take a look at random(4) - sysctls to turn off harvesting are documented = there. That is quite a busy harvestq - could you please give me some more = details of what that box is and what it was doing at the time (numbers = would be good!) Thanks! M --=20 Mark R V Murray --Apple-Mail=_1164B259-0D04-4D63-A73E-63B41B57DC4D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUovt1d58vKOKE6LNAQreBQP9FD46iCOXTt6SXwuCH5NKPYuqevu0kWy4 kT0IeQbbvdGh89Yq84RxyerQiqXlW4TFhiixs0ApVbjCuj29LGMEZn655Q7vn1QG ZqtHUNNJ9JhEisVdtohpIeSBlPxu0ss78ozVgN5+808NYA6ckSxjaoPTivIHbMae xxWKwuQnHAg= =5BqU -----END PGP SIGNATURE----- --Apple-Mail=_1164B259-0D04-4D63-A73E-63B41B57DC4D-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 23:03:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8FCE877 for ; Tue, 19 Nov 2013 23:03:58 +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 A32F3247A for ; Tue, 19 Nov 2013 23:03:58 +0000 (UTC) Received: from [96.28.178.143] ([96.28.178.143:34121] helo=localhost) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id C6/07-29861-C5EEB825; Tue, 19 Nov 2013 23:03:57 +0000 Date: Tue, 19 Nov 2013 23:03:56 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: 10.0-RELEASE cycle status update References: <20131119162205.GW1643@glenbarber.us> X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Cc: Glen Barber X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:03:58 -0000 As some may have noticed, the 10.0-RELEASE cycle has slipped a bit behind schedule. > Here is where we stand at the moment: > - The iconv issues mentioned in a previous status update email[1] are > being looked at extensively. There are a number of iconv(3) fixes > that have been committed to head/, which are pending MFC to stable/10 > following the default 3-day merge period. Those tracking -CURRENT > are encouraged to update their systems and report back (on -current@) > any issues. Those awaiting the next 10.0 builds, please be patient. > We will have the next round of builds for the 10.0-RELEASE cycle > started as soon as possible. > [1] http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075658.html > Glen What are the symptoms I might look for on FreeBSD-current? Release engineering estimated dates ought to be updated on the website. Better to wait for a solid 10.0-RELEASE than rush to a buggy release. I am also concerned about the bug in re(4) driver. Tom From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 23:13:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E240C1B; Tue, 19 Nov 2013 23:13:35 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 05F182520; Tue, 19 Nov 2013 23:13:34 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 10A35155EB; Tue, 19 Nov 2013 23:13:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 10A35155EB Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 19 Nov 2013 18:13:25 -0500 From: Glen Barber To: Thomas Mueller Subject: Re: 10.0-RELEASE cycle status update Message-ID: <20131119231325.GA1527@glenbarber.us> References: <20131119162205.GW1643@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:13:35 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2013 at 11:03:56PM +0000, Thomas Mueller wrote: > What are the symptoms I might look for on FreeBSD-current? >=20 Software crashes because of incorrect/missing character encodings are one symptom in particular. > Release engineering estimated dates ought to be updated on the website. >=20 Once -BETA4 is out, the remaining dates will be updated accordingly. I do not want to update the schedule page for the -RCs and -RELEASE until somewhat confident they can be met. > Better to wait for a solid 10.0-RELEASE than rush to a buggy release. >=20 > I am also concerned about the bug in re(4) driver. >=20 Is it fixed in head/? Glen --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSi/CVAAoJELls3eqvi17QJgkP/iKO+7G6QobeicGyACnTdyVk 3V1fBm7y+aTpNgGdZp7NcI0xBXJXDzjJDONr+r11wuL7V33LURR3SEEm/aMcAshx c4dfBFE+HE0SY+XdQhp55/RR6VlVVpCJFQ4Yiu6z+hmSmlQqiB8zqCWtT3i8fLyy zFpXnBfkqNzHfBNQpEpn2XatZprNQ12wpB6tCBL40ELPCBASwy4dQB7yuzReb7g8 T+OMTS7r0bjcAXI08JqJrLGJPq0ItBKr8v+wgUP4kTDUdjttQahXWJTsG7Y9Bqg8 VW9xxW+MXZFlbTrLOsA4CscKjyeyRdkbCVvLqODIW98+sYZi0Sn0VLzq8lWVrIYM VKxUaFIVTf6vvzFnxl20ArD7LHKfzNBiyg2ncyCOltTXT7vSTeKsY+maexe2tVXL 3SUg+hMxNAUdvGZUUBiKTYi4t69HNlt7S9ZXA8NQP5qs9SEJtC48XBOxPdx5717g 9fbhrv2z08BRAEEyt5Ep5Ggo2010qzdHDlCC6sUEKH0s8UzeKv/l8LA572z1EcY3 ezCZy6skWeqBI7kU5DhxYVknBTuwCiI9dsDqdEhKA4553dQrgW28JnZV74D+VZtU Cz4Uy+nsM73aYX3fqoM+dEJHG/uWF8jXdZmsgzsqhUbdY+Etbm0vcUEJzSZAFxyP chN+SHC7y2rRSN6JLksN =Zb1T -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 23:17:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AE5BD62; Tue, 19 Nov 2013 23:17:12 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 521EF2548; Tue, 19 Nov 2013 23:17:11 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q59so6305007wes.38 for ; Tue, 19 Nov 2013 15:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9HmMoXqSZQeFcfcxXhfoYpHc17+5NfLik6Gzh+3Ad5Y=; b=UQuvx7ysslmEihtaTrABzM1f0MBQhX96Sy5W1U6zbBlCoTmr4xsZjsBd2F9PMqr/ik xh1bRBtn0XEPz822hQfrzR27sYcNICGxqpsDgrH8HESlIRt4+BAACcnTcg4IDQYIY3N3 kQZ0uuR0qQx/C9cZBjdbuYbtvHMNaA8wxmnvClWZdvMs1d4TjbWPFKQwytQgrVijHN4O 2zsx8mGuliEn/J9KlLPpi825uAHxt0BmNnVRhacq12gilHCSjc15xR9MCANnyY3HKKGi sBph9F+X/WZnzGgaarjqULlECPxxNwS7gqsq5LNlW07v+yELA+AjiDqftQ9oYzV/bPqd qj9g== X-Received: by 10.180.215.3 with SMTP id oe3mr4275583wic.35.1384903029584; Tue, 19 Nov 2013 15:17:09 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id bs15sm10265432wib.10.2013.11.19.15.17.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Nov 2013 15:17:08 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 20 Nov 2013 00:17:04 +0100 From: Baptiste Daroussin To: Matthias Petermann Subject: Re: Is there already staging support within /ports/Mk/bsd.java.mk? Message-ID: <20131119231704.GW12196@ithaqua.etoilebsd.net> References: <528A5BC2.70601@petermann-it.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zqkt5x/gGOIVPcL0" Content-Disposition: inline In-Reply-To: <528A5BC2.70601@petermann-it.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org, freebsd-java@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:17:12 -0000 --Zqkt5x/gGOIVPcL0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 07:26:10PM +0100, Matthias Petermann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hello, >=20 > while updating my SweetHome3D port I'd like to enable staging support. > The build process is using bsd.java.mk to build via ant. >=20 > After removing NO_STAGE and adding ${STAGEDIR} to the respective > directories, I get the following message at *make stage*: >=20 >=20 > =3D=3D=3D> Building for sweethome3d-4.2 > Buildfile: /usr/ports/cad/sweethome3d/work/SweetHome3D-4.2-src/build.xml >=20 > BUILD FAILED > Target "DESTDIR=3D/usr/ports/cad/sweethome3d/work/stage" does not exist > in the project "SweetHome3D". >=20 >=20 > Appears like the DESTDIR is passed as a target to ant. I will > definitely do more investigation here, but before I do I'd like to > know if the bsd.java.mk already supports staging, or if this is a case > for staying with NO_STAGE temporarely? >=20 > Best regards, > Matthias >=20 This should be fixed now, update your ports tree, I fixed it a couple of we= eks ago iirc. regards, Bapt --Zqkt5x/gGOIVPcL0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEUEARECAAYFAlKL8XAACgkQ8kTtMUmk6ExAJQCXTEhEnV4ju88W9X0aBFa30OiN hgCgwyURUJtVnOzhF+/7SDRLpegyWrA= =AmAO -----END PGP SIGNATURE----- --Zqkt5x/gGOIVPcL0-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 19 23:25:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A208B130 for ; Tue, 19 Nov 2013 23:25:22 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60CA925CC for ; Tue, 19 Nov 2013 23:25:22 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ViufR-0001jK-TQ for freebsd-current@freebsd.org; Wed, 20 Nov 2013 00:25:13 +0100 Received: from cpc3-walt15-2-0-cust148.13-2.cable.virginm.net ([86.21.186.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Nov 2013 00:25:13 +0100 Received: from walterhurry by cpc3-walt15-2-0-cust148.13-2.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Nov 2013 00:25:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Walter Hurry Subject: Re: 10.0-RELEASE cycle status update Date: Tue, 19 Nov 2013 23:24:52 +0000 (UTC) Lines: 7 Message-ID: References: <20131119162205.GW1643@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-walt15-2-0-cust148.13-2.cable.virginm.net User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:25:22 -0000 On Tue, 19 Nov 2013 11:22:05 -0500, Glen Barber wrote: > As some may have noticed, the 10.0-RELEASE cycle has slipped a bit > behind schedule. No worries; release it when it's ready. Many thanks to all concerned for their efforts. From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 01:49:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86F2DD71; Wed, 20 Nov 2013 01:49:04 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F9E32CC4; Wed, 20 Nov 2013 01:49:03 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 9DD10DA1; Wed, 20 Nov 2013 02:48:55 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: Mark Robert Vaughan Murray Subject: Re: random_harvestq eats much on geode-lx alix2c3 Date: Wed, 20 Nov 2013 02:48:54 +0100 Message-ID: <1995425.XJjfe8p5PP@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10590-gdec8e46; KDE/4.11.3; x86_64; ; ) In-Reply-To: References: <4041856.BpQXZdSKfK@aurora> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 01:49:04 -0000 On Tue November 19 2013 23:01:37 Mark Robert Vaughan Murray wrote: > > rand_harvestq > Take a look at random(4) - sysctls to turn off harvesting are documented > there. Thanks! Turning off software interrupt collection brings the cpu usage next to nothing. > That is quite a busy harvestq - could you please give me some more details > of what that box is and what it was doing at the time (numbers would be > good!) The box is a home firewall with pf/altq. HZ=1000, despite poor hardware. It's alix2c3. Uses polling and a long, bloated pf.conf. Also, scrubs packets a bit. I'd be glad to attach more detail, but what do you ask for? Also, can text attachments be put here? For posterity's sake, better not to link to them. cheers, -sh -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 01:56:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77D0DEE5 for ; Wed, 20 Nov 2013 01:56:01 +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 36DEF2D24 for ; Wed, 20 Nov 2013 01:56:00 +0000 (UTC) Received: from [96.28.178.143] ([96.28.178.143:28014] helo=localhost) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 35/00-29861-FA61C825; Wed, 20 Nov 2013 01:56:00 +0000 Date: Wed, 20 Nov 2013 01:55:59 +0000 Message-ID: <35.00.29861.FA61C825@cdptpa-oedge02> From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: 10.0-RELEASE cycle status update References: <20131119162205.GW1643@glenbarber.us> <20131119231325.GA1527@glenbarber.us> X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Cc: Glen Barber , freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 01:56:01 -0000 from Glen Barber and my previous message: > Software crashes because of incorrect/missing character encodings are > one symptom in particular. > > Release engineering estimated dates ought to be updated on the website. > Once -BETA4 is out, the remaining dates will be updated accordingly. > I do not want to update the schedule page for the -RCs and -RELEASE > until somewhat confident they can be met. > > Better to wait for a solid 10.0-RELEASE than rush to a buggy release. > > I am also concerned about the bug in re(4) driver. > Is it fixed in head/? > Glen re(4) driver bug seems to have not been fixed in head. Since I last tried, there has been no further update as of about two days ago. I use subversion built from pkgsrc on a USB-stick installation of NetBSD-current amd64, and then check relevant dates for re(4)-related files. NetBSD-current source tree and pkgsrc tree are in separate directories on the FreeBSD-current amd64 partition. Having directories /netbsd-HEAD and /pkgsrc apparently does not bother FreeBSD. Tom From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 07:49:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AC663F6 for ; Wed, 20 Nov 2013 07:49:22 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D7A423C3 for ; Wed, 20 Nov 2013 07:49:21 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Vj2XD-0004m4-GA for freebsd-current@freebsd.org; Tue, 19 Nov 2013 23:49:15 -0800 Date: Tue, 19 Nov 2013 23:49:15 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1384933755467-5862442.post@n5.nabble.com> In-Reply-To: <5289D5C4.1020202@allanjude.com> References: <1384760874666-5861930.post@n5.nabble.com> <5289CFDD.9090708@FreeBSD.org> <5289D5C4.1020202@allanjude.com> Subject: Re: zpool requires re-import on reboot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:49:22 -0000 Alan: This corrects the "zpool import" problem (thanks for that): zpool_cache_type="/boot/zfs/zpool.cache" zpool_cache_name="/boot/zfs/zpool.cache" But boot still drops to single user and needs "zfs mount -a" to locate the fstab entries. Some datasets have canmount=noauto (but have a corresponding fstab entry). However, the primary dataset of the zpool (where dataset name = zpoll name) for both pools has canmount=on. One other "non-standard" property I have is that the dataset name is different than mountpoint (zfs set mountpoint=/some other folder) Nothing else out of the ordinary that I can think of. Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-tp5861930p5862442.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 07:56:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3990F6BF for ; Wed, 20 Nov 2013 07:56:50 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F9952453 for ; Wed, 20 Nov 2013 07:56:49 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAK7uWCd094307; Wed, 20 Nov 2013 09:56:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAK7uWCd094307 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAK7uUUN094306; Wed, 20 Nov 2013 09:56:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Nov 2013 09:56:30 +0200 From: Konstantin Belousov To: Andreas Tobler Subject: Re: WEAK_REFERENCE? Message-ID: <20131120075630.GF59496@kib.kiev.ua> References: <527EB428.6070104@FreeBSD.org> <20131111074706.GK59496@kib.kiev.ua> <5283ECA3.4080502@FreeBSD.org> <20131114060026.GH59496@kib.kiev.ua> <528A8E17.5090307@FreeBSD.org> <20131119072312.GW59496@kib.kiev.ua> <528BA500.4050203@fgznet.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I6TLfviLsKOBuB85" Content-Disposition: inline In-Reply-To: <528BA500.4050203@fgznet.ch> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Current , brde@optusnet.com.au X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:56:50 -0000 --I6TLfviLsKOBuB85 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2013 at 06:50:56PM +0100, Andreas Tobler wrote: > On 19.11.13 08:23, Konstantin Belousov wrote: > > On Mon, Nov 18, 2013 at 11:00:55PM +0100, Andreas Tobler wrote: > >> Here the two patches > >> amd64: > >> http://people.freebsd.org/~andreast/weak_ref_amd64.diff > >> i386: > >> http://people.freebsd.org/~andreast/weak_ref_i386.diff > >=20 > > Amd64 patch is fine. For i386, I do not see a definition of the > > WEAK_REFERENCE in the patch, and quick search of the pre-existing > > definition in sys/i386 or lib/libc/i386 does not reveal anything. >=20 > It's there now. Updated the diff. i386 patch looks fine. --I6TLfviLsKOBuB85 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSjGstAAoJEJDCuSvBvK1BE+MQAItz4w0y2MkrYoM3OPIm96UF aAmxp2a8OqTokrUxnXMAmqkrpfmFhghJpGEqW7LHyEMYbLTCGRRDICrsg8ahTAtT LOuPieIr1pDjnYG95Z+iCmQ/mE+vQaEsaYW50Kt3RoUAU82qe2vLdILB17A5riho 2dktSHdOfFIO47DizJ/jGQjO/fIROp/ecoEjoDAkO/UIuffHu+vLHGdu4sA5zLcw uGDv6tVw60PisugwsrInzpwjiPOqQ9kcw2Qhgdroc1UKKMKvfj/HnkdWRE7UW4bs rMtj8Ct4TvG7ek5ya21SYT3z7FNKGHpWXU+QIZR/dq2cr04VaMRHuZTe7U/4dYLZ 9yPS6NZvkVpRHmwquvXt5t86VWifG1sPDVQim0cUV89tExO5FSVWyWX+MSkOyCa4 iGAH/gLduYiGBrTM8SJuZEfIVzkxD/8qVhuk8g2T893fOphTrmuIRPRpMzDdUHi0 lA2Y9yKp5kF2cNMm9g9H0BmPwrOr4AcGe3242YUzSRmZhyNUWL+2r/wnzyCkMaRX h2LSKv4JNXk762+Vl1oj8JtO/wbyHTMP21P+VuCHRy3fNJFkTLG6HGom+lxgCgCd vJ/2kRkFX4TaLlp2nahoKoS1SfIKKjZXDEBW7UUEWjFXO8FK17iwOgZnVnKGp5XD jr5uGqCbmjYipD4knDfL =w3CP -----END PGP SIGNATURE----- --I6TLfviLsKOBuB85-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 08:55:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A977FFB for ; Wed, 20 Nov 2013 08:55:15 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CDD592821 for ; Wed, 20 Nov 2013 08:55:14 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6688727DEC for ; Wed, 20 Nov 2013 08:55:07 +0000 (UTC) Message-ID: <528C78E6.3080303@allanjude.com> Date: Wed, 20 Nov 2013 03:55:02 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zpool requires re-import on reboot References: <1384760874666-5861930.post@n5.nabble.com> <5289CFDD.9090708@FreeBSD.org> <5289D5C4.1020202@allanjude.com> <1384933755467-5862442.post@n5.nabble.com> In-Reply-To: <1384933755467-5862442.post@n5.nabble.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xI2ICr3w9wVFauhV4jEbqHWpRxGn89VmS" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:55:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xI2ICr3w9wVFauhV4jEbqHWpRxGn89VmS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-11-20 02:49, Beeblebrox wrote: > Alan: This corrects the "zpool import" problem (thanks for that): > zpool_cache_type=3D"/boot/zfs/zpool.cache" > zpool_cache_name=3D"/boot/zfs/zpool.cache"=20 > > But boot still drops to single user and needs "zfs mount -a" to locate = the > fstab entries. > Some datasets have canmount=3Dnoauto (but have a corresponding fstab en= try). > However, the primary dataset of the zpool (where dataset name =3D zpoll= name) > for both pools has canmount=3Don. > One other "non-standard" property I have is that the dataset name is > different than mountpoint (zfs set mountpoint=3D/some other folder) > Nothing else out of the ordinary that I can think of. > > Regards. > > > > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/zpoo= l-requires-re-import-on-reboot-tp5861930p5862442.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" having zfs_enable=3D"YES" in /etc/rc.conf should automatically run 'zfs mount -a' during boot, and you shouldn't have this problem What does the output of this command look like: zfs get -r -t filesystem canmount,mountpoint $poolname in the zfsboot script, some datasets have canmount=3Doff on purpose, /usr= has it so that /usr/bin goes in the root dataset, but the dataset is required to create a separate /usr/local dataset --=20 Allan Jude --xI2ICr3w9wVFauhV4jEbqHWpRxGn89VmS 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.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSjHjqAAoJEJrBFpNRJZKf/ssP/2d0BB26nBQiIx+Ad6mtTDG0 mpzMvxXAUp8Sycc+1+Noqmqy9wdcmgCmrFGuD/nbnYLIgG+1h2NvOQJlXhPP6NWZ 9zUFfwl+J7ogV91pbF58tqZ7Dk1/6h/PvoZ/w3w6tsc+y67l8aeiS6iLgMO+DFrn TE8nqzcJw4GJAfd6/2RIooammx5kZhRiLGGKFSLWVfbl5aHZPcPUPe6bLGmet7Zt CmeaJ5BpNiHAOTlI2Yp5mu4UcJwpc95zsMAooT2waj/u+sEzgKypZs53t0z7k0zN lPXsPH82O8HQLc8PSC7Gjh15nAjns2SBU3pUOGqx6ep9DGEY86lZ1HJ6axsmuwY4 UBocpo9aHVPgu4dyKXJpe2NIQlZZsSp5Smx6SobdZcKDvMo4UJgO4TzEBvwp5ZV5 M6204cWMbIY3R6ilWKjXzOg4e4duUg/5rdb95V8WyiH17qyM207wDlaqA9y6wZGm pGjIsAF/tRP/hy54eL9EzuvBC2Il8A5VQ0Ita/zfon4RfkgLODk/Uz6H2PMFe0/1 3qbpdAkJBiFFKjlRA01Pz/EvSQ5V6qdORb4sRpfrF6A7p5Y9roWZRI+pr9wcgS7J GXbE1y4R/7vS7GaZlb8qQvp7TUa5uMm7E56SDWOGTyOVDHOY5VFv01V9Z9zHPJuo 8DJ9Cst+lL5Pp4kLcfFQ =l6Jn -----END PGP SIGNATURE----- --xI2ICr3w9wVFauhV4jEbqHWpRxGn89VmS-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 09:43:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FFCFD4A for ; Wed, 20 Nov 2013 09:43:00 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 719ED2B8D for ; Wed, 20 Nov 2013 09:42:59 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Vj4JG-00071x-3j for freebsd-current@freebsd.org; Wed, 20 Nov 2013 01:42:58 -0800 Date: Wed, 20 Nov 2013 01:42:58 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1384940578101-5862468.post@n5.nabble.com> In-Reply-To: <528C78E6.3080303@allanjude.com> References: <1384760874666-5861930.post@n5.nabble.com> <5289CFDD.9090708@FreeBSD.org> <5289D5C4.1020202@allanjude.com> <1384933755467-5862442.post@n5.nabble.com> <528C78E6.3080303@allanjude.com> Subject: Re: zpool requires re-import on reboot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 09:43:00 -0000 My apologies, please disregard last message - problem was an error on my part. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-tp5861930p5862468.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 10:23:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C35AECB for ; Wed, 20 Nov 2013 10:23:03 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C85852E85 for ; Wed, 20 Nov 2013 10:23:02 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 65313DA1 for ; Wed, 20 Nov 2013 11:23:01 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: current@freebsd.org Subject: Re: Please compile ports-mgmt/pkg for i486 Date: Wed, 20 Nov 2013 11:23 +0100 Message-ID: <69258460.p46Yxb2vsh@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10590-gdec8e46; KDE/4.11.3; x86_64; ; ) In-Reply-To: References: <22068029.qGT93JWspe@aurora> <2547821.FcDGDbTo6p@aurora> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:23:03 -0000 On Wed November 20 2013 11:16:03 you wrote: > Ah yes, we did attempt to fix those long nops on Geode once and for all, > can you please confirm that pkg built with recent clang does not cause > SIGILL for you? Not unless -march=geode :( Please see: http://llvm.org/bugs/show_bug.cgi?id=11212 http://llvm.org/bugs/show_bug.cgi?id=17792 Got bitten by that with -march=i486... -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 11:57:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A98FED8 for ; Wed, 20 Nov 2013 11:57:53 +0000 (UTC) Received: from web1.unixengines.com (web1.unixengines.com [88.198.32.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5D324A5 for ; Wed, 20 Nov 2013 11:57:52 +0000 (UTC) Received: from [109.102.136.123] (helo=MacMac.local) by web1.unixengines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Vj2iD-0006oh-IA for current@freebsd.org; Wed, 20 Nov 2013 10:00:37 +0200 Message-ID: <528C95D4.4090806@freebsdonline.com> Date: Wed, 20 Nov 2013 12:58:28 +0200 From: freebsdonline User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22 MIME-Version: 1.0 Subject: Re: random_harvestq eats much on geode-lx alix2c3 References: <4041856.BpQXZdSKfK@aurora> <1995425.XJjfe8p5PP@aurora> In-Reply-To: <1995425.XJjfe8p5PP@aurora> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 11:57:53 -0000 Stanisław Halik wrote: > but what do you ask for? Also, can text > attachments be put here? For posterity's sake, better not to link to them. It is poor hardware as you said but FreeBSD should run well on it. I also have Alix boards running FreeBSD as router, and cpu load is almost 0. last pid: 2799; load averages: 0.00, 0.00, 0.00 up 0+11:29:10 11:29:53 14 processes: 1 running, 13 sleeping CPU: 1.1% user, 0.0% nice, 0.0% system, 0.0% interrupt, 98.9% idle Mem: 8376K Active, 6752K Inact, 23M Wired, 620K Cache, 21M Buf, 195M Free Swap: uname -a FreeBSD firewall 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Sun Mar 20 01:51:47 EET 2011 root@firewall:/usr/obj/nanobsd.custom/usr/src/sys/FIREWALL i386 I did not deployed yet 10.x (I'm waiting for nanobsd.sh to correct problems with pkgng) for now I am running it on VirtualBox, but I hope it will also run well on Alix hardware. Your problems were on 10.x or 11.x? From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 12:07:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D663411C; Wed, 20 Nov 2013 12:07:03 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F4D3252D; Wed, 20 Nov 2013 12:07:03 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 2A61CDA1; Wed, 20 Nov 2013 13:07:00 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: freebsd-current@freebsd.org Subject: Re: random_harvestq eats much on geode-lx alix2c3 Date: Wed, 20 Nov 2013 13:06:59 +0100 Message-ID: <39581288.qTPxYfYbi1@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10590-gdec8e46; KDE/4.11.3; x86_64; ; ) In-Reply-To: <528C95D4.4090806@freebsdonline.com> References: <4041856.BpQXZdSKfK@aurora> <1995425.XJjfe8p5PP@aurora> <528C95D4.4090806@freebsdonline.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: current@freebsd.org, freebsdonline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:07:03 -0000 On Wed November 20 2013 12:58:28 freebsdonline wrote: > I did not deployed yet 10.x (I'm waiting for nanobsd.sh to correct > problems with pkgng) for now I am running it on VirtualBox, but I hope > it will also run well on Alix hardware. Your problems were on 10.x or 11.x? 10.x. It's a new issue, works fine with 9.x. xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 12:20:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 827153C7 for ; Wed, 20 Nov 2013 12:20:42 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 505F42615 for ; Wed, 20 Nov 2013 12:20:42 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id gq1so5015602obb.4 for ; Wed, 20 Nov 2013 04:20:41 -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=wxc6Q8NtFaaMyRYIdstaTqnc9HbnJNZXqOsW54WZh4Y=; b=TtXLhSY74Co+Bt7+JBvRdWayRDRETF0JzBO0dsjAHaJth5taS0VMrmoGl/R78EfNNb m92Fg4CTMDmDivHAQRVkLw/rPp9c7IdrTO/VJP3/IhNowY7gBmS1YXFRyY02z89eRxx3 bRO/f9QXeH2yElZrUFFEGRKayDnKyyAiLNOJ9zBZWYj42AkXfMJyM+GOxF3VpaA7aLSY x0KWSB56ForHzL9CelrvNh01JJliQ3rAZgbWTObf5XPqrMbbLHnzkSr+dRv7hXG5mhMi mDg2ccX4QSTzqZjCtbcVVexVHug69Mzafag7q1YW7wTL+GMGga68sbIImtngq9dKCVpO pZPw== MIME-Version: 1.0 X-Received: by 10.60.145.241 with SMTP id sx17mr246768oeb.57.1384950041583; Wed, 20 Nov 2013 04:20:41 -0800 (PST) Received: by 10.76.177.234 with HTTP; Wed, 20 Nov 2013 04:20:41 -0800 (PST) In-Reply-To: <528C95D4.4090806@freebsdonline.com> References: <4041856.BpQXZdSKfK@aurora> <1995425.XJjfe8p5PP@aurora> <528C95D4.4090806@freebsdonline.com> Date: Wed, 20 Nov 2013 13:20:41 +0100 Message-ID: Subject: Re: random_harvestq eats much on geode-lx alix2c3 From: Andreas Nilsson To: freebsdonline Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:20:42 -0000 > I did not deployed yet 10.x (I'm waiting for nanobsd.sh to correct > problems with pkgng) for now I am running it on VirtualBox, but I hope it > will also run well on Alix hardware. Your problems were on 10.x or 11.x? > > I just wanted to chip in concerning nanobsd: the whole point with it is that it is easy to overide methods you don't like. Without to much patching I have nanobsd working on zfs with pkgng. If you use the official pkgng repo it is almost trivial: define cust_pkg() in your config file, something like cust_pkg() { pkg -c ${NANO_WORLDDIR} install $packages pkg -c ${NANO_WORLDDIR} clean } You might also have to temporarily place a working resolv.conf in ${NANO_WORLDDIR}/etc If you have your own repo just add export PACKAGESITE="proto://path/to/repo" to the config file as well. Given that thats all it takes, why wait for an "official" fix? Best regards Andreas From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 19:15:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00CBBCD3 for ; Wed, 20 Nov 2013 19:15:51 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B54152287 for ; Wed, 20 Nov 2013 19:15:51 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::e950:5ca5:a7b2:7db9] (unknown [IPv6:2001:7b8:3a7:0:e950:5ca5:a7b2:7db9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C3E755C43; Wed, 20 Nov 2013 20:15:47 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_505BD339-D8CD-4FD2-9DFD-E519A204D27E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Please compile ports-mgmt/pkg for i486 From: Dimitry Andric In-Reply-To: <16115298.kblWN6Ztd8@aurora> Date: Wed, 20 Nov 2013 20:15:34 +0100 Message-Id: <4B4541CC-36A2-4805-8F7A-239E9DE87ABC@FreeBSD.org> References: <22068029.qGT93JWspe@aurora> <2547821.FcDGDbTo6p@aurora> <16115298.kblWN6Ztd8@aurora> To: =?utf-8?Q?Stanis=C5=82aw_Halik?= X-Mailer: Apple Mail (2.1822) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:15:52 -0000 --Apple-Mail=_505BD339-D8CD-4FD2-9DFD-E519A204D27E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 20 Nov 2013, at 11:22, Stanis=C5=82aw Halik = wrote: > On Wed November 20 2013 11:16:03 you wrote: >> Ah yes, we did attempt to fix those long nops on Geode once and for = all, >> can you please confirm that pkg built with recent clang does not = cause >> SIGILL for you? >=20 > Not unless -march=3Dgeode :( >=20 > Please see: >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D11212 > http://llvm.org/bugs/show_bug.cgi?id=3D17792 >=20 > Got bitten by that with -march=3Di486... Those bugs are about other CPU's, not specifically the Geode, or i486.=20= The version of clang in head, stable/10 and stable/9 produces regular nops for -march=3Di486, which is the default setting if you don't pass = any arch. So how did you get bitten, then? Were you using 9.1-RELEASE, by any chance? -Dimitry --Apple-Mail=_505BD339-D8CD-4FD2-9DFD-E519A204D27E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKNCmEACgkQsF6jCi4glqOo+ACg+awKCeIgVG8PXe7WfDkwtdC9 HzcAn1kJLAYo/t0oYDrlDOFxhSXYRg7Y =VNjr -----END PGP SIGNATURE----- --Apple-Mail=_505BD339-D8CD-4FD2-9DFD-E519A204D27E-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 20:27:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 737F19FB for ; Wed, 20 Nov 2013 20:27:32 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 150232733 for ; Wed, 20 Nov 2013 20:27:31 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id n12so9485889wgh.3 for ; Wed, 20 Nov 2013 12:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=v0u8ww2FEo8tkhNbb2vj/fEw3Jnn2YEcGNi41fCag5w=; b=e+oqzwEWL1owA/0N7ny1QukTbkvrgmzpmBiMMHl9kOUlehrQAFUoVxhKYgT8SCNBm6 2rBGGwumER/j6uFyYUC//cB22bQwlKhXRRdcsP9+EgiRXBVYxLUThn8RShOGVQniXYPJ GNTMfciFaQTJbmbtEc3zRVQUnx+c7/tgAOs7Y6HDGVmd36tnzlp7sY3DromLlHE2V1m3 iCy1EJ0j5euFYhI3Zjojvn+pflhusU8LgHN933Ho0zEKbDu0EG6GuClMRiuprm8Wb71d h5U+VxCA0O2oa0pgX9h+rn4vOfYP3Bi8Hj2wbOyCaDwWxu0u1uSKPFeb0UZIFCZxqOlc RslQ== MIME-Version: 1.0 X-Received: by 10.194.235.138 with SMTP id um10mr2454158wjc.30.1384979250516; Wed, 20 Nov 2013 12:27:30 -0800 (PST) Received: by 10.217.141.3 with HTTP; Wed, 20 Nov 2013 12:27:30 -0800 (PST) Date: Wed, 20 Nov 2013 21:27:30 +0100 Message-ID: Subject: FreeBSD-10 microdrive seagate ST1AT 4GB (VIA mbo) problem From: Berislav Purgar To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:27:32 -0000 Hello .. I have problem with microdrive and some CF cards on IGEL 3/4 compact thin client ( http://www.parkytowers.me.uk/thin/Igel/3210/index.shtml ). Problem is that FreeBSD cannot find microdrive or CF card to mount sytem / on (but kernel is found and loaded from microdrive or CF card). I have one CF card (sandisk ultra II) which boots but with some timeouts before. Here are links to pictures of this problem. (aprobe:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 http://s24.postimg.org/al2k6qfzp/WP_20131120_003_1.jpg http://s17.postimg.org/wm0s58kzz/WP_20131120_007_1.jpg http://s23.postimg.org/5sp2k4trf/WP_20131120_006_1.jpg i tried same configuration on openbsd5.3 and everething si Ok .. Any suggestions ? Tnx sorry for my English .. From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 20:45:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D943B2 for ; Wed, 20 Nov 2013 20:45:36 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88B4D287B for ; Wed, 20 Nov 2013 20:45:36 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hm6so1178346wib.4 for ; Wed, 20 Nov 2013 12:45:34 -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 :content-type; bh=9/xlqhKtzKJ5UdEe+2vqTbCNnOI7iP6UEikGLXXUepQ=; b=UB3Lnx6FEoaz5V1HXPx6sWRhh5/0BOhySlj62DwXgiJnXLwf3tAUQ+w5vcbMVD9Kjw noH6SWCXKDdinWsWxCMGE2+mdgTWlbb6whlygyoBOuqFgx50IhBxv+33XvszmzCf3gGd +ZLSAN/HS2HCAlc3Kz3V8YZLrAZGDn7qaXYVBNzOkxP9MQOaJIfE6w7x5ss+3AYeLopL u8dcnEOrfO19yvt5arGrd4+nrCIbuMhIWGWjkZfBGwNhssz7EIf0eA4UxVqCxp7NrfhI NWLajAX6dFCdU6Yv2UTc9jZVv++/JdqV5xu38rxGHP6Nmst8JqDBUzR2QCsqKj6UpVsB JkZw== MIME-Version: 1.0 X-Received: by 10.181.12.75 with SMTP id eo11mr2084333wid.37.1384980334904; Wed, 20 Nov 2013 12:45:34 -0800 (PST) Received: by 10.217.141.3 with HTTP; Wed, 20 Nov 2013 12:45:34 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 21:45:34 +0100 Message-ID: Subject: Re: FreeBSD-10 microdrive seagate ST1AT 4GB (VIA mbo) problem From: Berislav Purgar To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:45:37 -0000 On Wed, Nov 20, 2013 at 9:27 PM, Berislav Purgar wrote: > Hello .. > > I have problem with microdrive and some CF cards on IGEL 3/4 compact thin > client ( http://www.parkytowers.me.uk/thin/Igel/3210/index.shtml ). > Problem is that FreeBSD cannot find microdrive or CF card to mount sytem / > on (but kernel is found and loaded from microdrive or CF card). I have one > CF card (sandisk ultra II) which boots but with some timeouts before. Here > are links to pictures of this problem. > > (aprobe:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 > > > http://s24.postimg.org/al2k6qfzp/WP_20131120_003_1.jpg > http://s17.postimg.org/wm0s58kzz/WP_20131120_007_1.jpg > http://s23.postimg.org/5sp2k4trf/WP_20131120_006_1.jpg > > i tried same configuration on openbsd5.3 and everething si Ok .. Any > suggestions ? > > Tnx > sorry for my English .. > > > > > i forgot to tell that ata chipset is VIA VT8237R .. atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe800-0xe80f at device 15.0 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 20:51:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E6FE555 for ; Wed, 20 Nov 2013 20:51:13 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A187528CC for ; Wed, 20 Nov 2013 20:51:12 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hi5so2877265wib.14 for ; Wed, 20 Nov 2013 12:51:11 -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 :content-type; bh=2zexU6BfrmE3/u31r0q+SzYf9VNEazzWAVJNsH+RQLA=; b=IOdK7bvtkfbSLWbLF2hQbJ+HTlmnd19LF/14OCUt332qxh05xUFWDbQE4SD2R9xSzi pibb97eM/29O0jrttrlh7Ww4exZsjUEu6XZlCOBj5x7tkybjJ8YyOOdclGBj45QOR7bz Fm2oU89LHzeCdjnn9x/P1L/c/AQVKR/iJCVFDoH9NXlODJVNgEnvIBp3K/M9ToyViag6 QnNgaGHv2H+dpjcxKEYL9ROuQkUdpFGkiOtW0elSODJliU4PXDXl5PnFGuvHmkgOIb08 OZYjBB10+bT7goQzyuTemjxyTWg9npZI3PwyMojvlelZjOEXQ1aWj4ZOJBTK91G+fheg R6zg== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr2290518wic.26.1384980671166; Wed, 20 Nov 2013 12:51:11 -0800 (PST) Received: by 10.217.141.3 with HTTP; Wed, 20 Nov 2013 12:51:11 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 21:51:11 +0100 Message-ID: Subject: Re: FreeBSD-10 microdrive seagate ST1AT 4GB (VIA mbo) problem From: Berislav Purgar To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:51:13 -0000 On Wed, Nov 20, 2013 at 9:45 PM, Berislav Purgar wrote: > > > > On Wed, Nov 20, 2013 at 9:27 PM, Berislav Purgar wrote: > >> Hello .. >> >> I have problem with microdrive and some CF cards on IGEL 3/4 compact thin >> client ( http://www.parkytowers.me.uk/thin/Igel/3210/index.shtml ). >> Problem is that FreeBSD cannot find microdrive or CF card to mount sytem / >> on (but kernel is found and loaded from microdrive or CF card). I have one >> CF card (sandisk ultra II) which boots but with some timeouts before. Here >> are links to pictures of this problem. >> >> (aprobe:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 >> 00 >> >> >> http://s24.postimg.org/al2k6qfzp/WP_20131120_003_1.jpg >> http://s17.postimg.org/wm0s58kzz/WP_20131120_007_1.jpg >> http://s23.postimg.org/5sp2k4trf/WP_20131120_006_1.jpg >> >> i tried same configuration on openbsd5.3 and everething si Ok .. Any >> suggestions ? >> >> Tnx >> sorry for my English .. >> >> >> >> >> i forgot to tell that ata chipset is VIA VT8237R .. > > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe800-0xe80f at device 15.0 on pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > > > > and how openbsd identify same controler : http://s12.postimg.org/bztc7w1zx/WP_20131120_001_1.jpg Beri From owner-freebsd-current@FreeBSD.ORG Wed Nov 20 23:00:22 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF1AC9BC for ; Wed, 20 Nov 2013 23:00:22 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 931302FCE for ; Wed, 20 Nov 2013 23:00:22 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VjGHZ-0004Rr-9U; Wed, 20 Nov 2013 22:30:01 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAKMTwUj081445; Wed, 20 Nov 2013 15:29:58 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/AyuZSNAY5lyMTocbVocS/ Subject: Re: FreeBSD-10 microdrive seagate ST1AT 4GB (VIA mbo) problem From: Ian Lepore To: Berislav Purgar In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 2013 15:29:58 -0700 Message-ID: <1384986598.31172.522.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 23:00:22 -0000 On Wed, 2013-11-20 at 21:27 +0100, Berislav Purgar wrote: > Hello .. > > I have problem with microdrive and some CF cards on IGEL 3/4 compact thin > client ( http://www.parkytowers.me.uk/thin/Igel/3210/index.shtml ). Problem > is that FreeBSD cannot find microdrive or CF card to mount sytem / on (but > kernel is found and loaded from microdrive or CF card). I have one CF card > (sandisk ultra II) which boots but with some timeouts before. Here are > links to pictures of this problem. > > (aprobe:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 > > > http://s24.postimg.org/al2k6qfzp/WP_20131120_003_1.jpg > http://s17.postimg.org/wm0s58kzz/WP_20131120_007_1.jpg > http://s23.postimg.org/5sp2k4trf/WP_20131120_006_1.jpg > > i tried same configuration on openbsd5.3 and everething si Ok .. Any > suggestions ? > > Tnx > sorry for my English .. Try adding hw.ata.ata_dma=0 to your /boot/loader.conf. I don't know why the bios can do DMA on a CF and freebsd can't, but we've needed to add that at $work for years (going back to freebsd 4.x at least). Of course, you pay a huge performance penalty for running in PIO mode. -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 03:09:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D8D3BA4 for ; Thu, 21 Nov 2013 03:09:37 +0000 (UTC) Received: from keus02.synserver.de (www.socialrevolutionworldwide.net [212.40.171.22]) by mx1.freebsd.org (Postfix) with ESMTP id 5536D2CA1 for ; Thu, 21 Nov 2013 03:09:36 +0000 (UTC) Received: by keus02.synserver.de (Postfix, from userid 1000) id 308535429F; Thu, 21 Nov 2013 04:09:21 +0100 (CET) Resent-From: Thomas Keusch Resent-Date: Thu, 21 Nov 2013 04:09:18 +0100 Resent-Message-ID: <20131121030918.GA16298@vs2.gothschlampen.com> Resent-To: freebsd-current@freebsd.org Date: Thu, 21 Nov 2013 04:04:04 +0100 From: "Thomas K." To: Volodymyr Kostyrko Subject: Re: cron(8) improvement Message-ID: <20131121030403.GA11468@vs2.gothschlampen.com> References: <52792B60.1030309@allanjude.com> <52792CF3.9050104@mail.lifanov.com> <1383675687.8053.43379365.3F5A71FC@webmail.messagingengine.com> <527A0468.7020600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527A0468.7020600@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 03:09:37 -0000 On Wed, Nov 06, 2013 at 10:57:12AM +0200, Volodymyr Kostyrko wrote: > >> > >>Shouldn't we encourage packages to use periodic(8) when possible? > >> > > > >Yes but our default periodic configuration in /etc/crontab is only > >configured to be as granular as daily. If this is something that should > >run hourly or at very strange intervals then cron is a better choice. > > So why we shouldn't add something like: > > 0 * * * * root periodic hourly > @reboot root periodic reboot > > I already do this on some machines to take hourly and boot snapshots > with zfSnap. And I think periodic is much better place for such > tasks. While this is the way it has always been done, I'd find it somewhat lacking in the flexibility department, also you might be in for some nasty surprises First, the resolution is limited to hourly, and second, if I'm not mistaken, the jobs are run strictly sequentially. The last point be suboptimal, as the interval may vary wildly. Also, what happens when all jobs' runtime adds up to more than one hour? It's an equivalent of /etc/cron.hourly.d, but going this way we still don't have something like /etc/crond.d. Best regards Thomas From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 08:45:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 406FFA5E; Thu, 21 Nov 2013 08:45:07 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09EF6210F; Thu, 21 Nov 2013 08:45:07 +0000 (UTC) Received: from [2001:470:9174:1:905e:886e:eefc:105a] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VjPsl-000Kak-8F; Thu, 21 Nov 2013 08:45:04 +0000 Content-Type: multipart/signed; boundary="Apple-Mail=_63CA50BB-349E-4E8B-8295-A3BFFDDA07B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Duplicated WITH_*/WITHOUT_* options From: Mark Robert Vaughan Murray In-Reply-To: <35.00.29861.FA61C825@cdptpa-oedge02> Date: Thu, 21 Nov 2013 08:44:56 +0000 Message-Id: References: <20131119162205.GW1643@glenbarber.us> <20131119231325.GA1527@glenbarber.us> <35.00.29861.FA61C825@cdptpa-oedge02> To: FreeBSD CURRENT X-Mailer: Apple Mail (2.1822) X-SA-Score: -0.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 08:45:07 -0000 --Apple-Mail=_63CA50BB-349E-4E8B-8295-A3BFFDDA07B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi I noticed we have some duplicated WITH_*/WITHOUT_* options; presumably = this is an oversight? [graveyard] /usr/src/tools/build/options 08:37 am # for i in WITH_* ; do = if [ -e WITHOUT_${i##WITH_} ] ; then echo WITHOUT_${i##WITH_} ${i} ; fi; = done WITHOUT_CLANG WITH_CLANG WITHOUT_CLANG_FULL WITH_CLANG_FULL WITHOUT_CLANG_IS_CC WITH_CLANG_IS_CC WITHOUT_FDT WITH_FDT WITHOUT_GCC WITH_GCC WITHOUT_GNUCXX WITH_GNUCXX WITHOUT_LIBCPLUSPLUS WITH_LIBCPLUSPLUS WITHOUT_NAND WITH_NAND WITHOUT_TESTS WITH_TESTS As its not all that obvious which one =93wins=94, can this be cleaned = up? I don=92t mind doing the work if there is a somewhat foolproof way = of doing so. M --=20 Mark R V Murray --Apple-Mail=_63CA50BB-349E-4E8B-8295-A3BFFDDA07B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUo3IDd58vKOKE6LNAQqibAQApZT0INNnfnNC0YvRJhU6GvBG5RNXgAFP Fowx3lXWhTsPLn17EsJpV2OD5ozraUx70IwPFO7Kvlaz1G0JbFkXVuhohZr0blEa SAtzezE7S39SWUd58KDBorYzUywq3NDiaMjPE6/W7ulgA2jst1RCu/DsXro8mU/s aLypM9ITauE= =UMIV -----END PGP SIGNATURE----- --Apple-Mail=_63CA50BB-349E-4E8B-8295-A3BFFDDA07B3-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 08:50:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B693FC1; Thu, 21 Nov 2013 08:50:54 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE23321B7; Thu, 21 Nov 2013 08:50:53 +0000 (UTC) Received: from [2001:470:9174:1:905e:886e:eefc:105a] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VjPyL-000KbT-IE; Thu, 21 Nov 2013 08:50:52 +0000 Subject: Re: random_harvestq eats much on geode-lx alix2c3 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5B16EB49-595C-4F22-9974-D9F60FD43B4C"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <528C95D4.4090806@freebsdonline.com> Date: Thu, 21 Nov 2013 08:50:47 +0000 Message-Id: References: <4041856.BpQXZdSKfK@aurora> <1995425.XJjfe8p5PP@aurora> <528C95D4.4090806@freebsdonline.com> To: freebsdonline X-Mailer: Apple Mail (2.1822) X-SA-Score: -1.0 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 08:50:54 -0000 --Apple-Mail=_5B16EB49-595C-4F22-9974-D9F60FD43B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 20 Nov 2013, at 10:58, freebsdonline = wrote: > Stanis=C5=82aw Halik wrote: >> but what do you ask for? Also, can text >> attachments be put here? For posterity's sake, better not to link to = them. > It is poor hardware as you said but FreeBSD should run well on it. I = also have Alix boards running FreeBSD as router, and cpu load is almost = 0. The entropy-harvesting stuff needs to be adaptable to slow and fast. On = an old box, one which would work well as a small gateway/firewall, = aggressive harvesting may (does!) slow down the OS. On a multiple-CPU = grunt-grade server, that may not be enough, and we may be scrambling for = more. M --=20 Mark R V Murray --Apple-Mail=_5B16EB49-595C-4F22-9974-D9F60FD43B4C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUo3JZ958vKOKE6LNAQp/QQQAhtmQKBxEakalIOucsWLWKRdpQ9A9iJAa Tajxaoa3xCRZSIBY9I+QmpqLWVzyul0KColg1J8FJWN4NBp7aGWsirjG7ehSoAUs cAuHcAeKPRw7aCBuBN8+u9ufx20F95LslHOxW9UDlIHsN0f54CNg08rzFC9/XHlG Q/MnhsvU05U= =soBa -----END PGP SIGNATURE----- --Apple-Mail=_5B16EB49-595C-4F22-9974-D9F60FD43B4C-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 09:35:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57651814; Thu, 21 Nov 2013 09:35:55 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B61FD2559; Thu, 21 Nov 2013 09:35:54 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so743254wid.0 for ; Thu, 21 Nov 2013 01:35:53 -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=OyKZV0QeQiV/Ve82wz9bWVDj0+U+eBTfEVTYvefZ6Lw=; b=KfbaWrZQMaSLuiikRJG7eNPgSVzurcYZVxm7KrGf17FipbIJZ1pRRCsqZ5UQ/xHVgt 8G44YJ261KpbBWZhel+oJBAUXgpIfIXLBGWO28RCmXprVLj+D06OhArv1qMaGWHtRaEe /3U9Xy0wJ6Du51P6UiHtQLCbAvasWYCTi/5RrGTZn4KiCAdEk51zObEznDN93OT8B+fj yBehisbmlyWnUql2zkonEoOZLcn9OHZrxO8UhufQDq0iRPzLQEZHNx28BTtw9URJzVS1 oF9M8jCOcMAE8q9nUOnGMzeVhunrlRzZicxpLbj2Gp04pvDZ5xQgUH6nRKxNg1BOVWGI LYXQ== MIME-Version: 1.0 X-Received: by 10.194.57.243 with SMTP id l19mr563555wjq.54.1385026553139; Thu, 21 Nov 2013 01:35:53 -0800 (PST) Received: by 10.217.141.3 with HTTP; Thu, 21 Nov 2013 01:35:53 -0800 (PST) In-Reply-To: <1384986598.31172.522.camel@revolution.hippie.lan> References: <1384986598.31172.522.camel@revolution.hippie.lan> Date: Thu, 21 Nov 2013 10:35:53 +0100 Message-ID: Subject: Re: FreeBSD-10 microdrive seagate ST1AT 4GB (VIA mbo) problem From: Berislav Purgar To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 09:35:55 -0000 On Wed, Nov 20, 2013 at 11:29 PM, Ian Lepore wrote: > On Wed, 2013-11-20 at 21:27 +0100, Berislav Purgar wrote: > > Hello .. > > > > I have problem with microdrive and some CF cards on IGEL 3/4 compact thin > > client ( http://www.parkytowers.me.uk/thin/Igel/3210/index.shtml ). > Problem > > is that FreeBSD cannot find microdrive or CF card to mount sytem / on > (but > > kernel is found and loaded from microdrive or CF card). I have one CF > card > > (sandisk ultra II) which boots but with some timeouts before. Here are > > links to pictures of this problem. > > > > (aprobe:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 > 00 > > > > > > http://s24.postimg.org/al2k6qfzp/WP_20131120_003_1.jpg > > http://s17.postimg.org/wm0s58kzz/WP_20131120_007_1.jpg > > http://s23.postimg.org/5sp2k4trf/WP_20131120_006_1.jpg > > > > i tried same configuration on openbsd5.3 and everething si Ok .. Any > > suggestions ? > > > > Tnx > > sorry for my English .. > > Try adding hw.ata.ata_dma=0 to your /boot/loader.conf. I don't know why > the bios can do DMA on a CF and freebsd can't, but we've needed to add > that at $work for years (going back to freebsd 4.x at least). Of > course, you pay a huge performance penalty for running in PIO mode. > > -- Ian > > Hi Ian i try this but does not help. for better debuging i use gateworks GW2345 board and found some interestingly ... if i destroy all partitions and partitions schemes on microdrive freebsd founds microdrive at boot and display info for it.. Timecounters tick every 10.000 msec ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-0 device ada0: 16.700MB/s transfers (PIO4, PIO 8192bytes) ada0: 3906MB (7999488 512 byte sectors: 16H 63S/T 7936C) ada0: Previously was known as ad0 full dmesg is here : http://pastebin.com/eWJ4XGyN but if i create MBR (or GPT) on microdrive and check as before on avila board i got timeouts and microdrive not found ?! ata_avila0: on ixp0 ata0: on ata_avila0 led_avila0: on ixp0 gpio_avila0: on ixp0 gpioc0: on gpio_avila0 gpiobus0: on gpio_avila0 Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000 Timecounters tick every 10.000 msec (aprobe0:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata0:0:0:0): CAM status: Command timeout (aprobe0:ata0:0:0:0): Error 5, Retry was blocked full dmesg is here : http://pastebin.com/wPEexXKz i don't think that this is dma problem !? Beri From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 09:39:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48179AD0; Thu, 21 Nov 2013 09:39:40 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A2D7A25A7; Thu, 21 Nov 2013 09:39:39 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id x55so6544485wes.26 for ; Thu, 21 Nov 2013 01:39:38 -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=eRvvhsjtu6eFndz6DbOPi4UfHFn5ULAcamrdsbAAdo0=; b=tPZvJfcnYhTdOFBRxetM7nginC3qSXLhxN4pCJdA6uqdlpA+P6XNhJaPAWyTKAJ2pA WYrCu9pjqAKR1FVgbVzJZxCjwLc8OAIvNzAgxE4htE6qSy+pFFNcf6FfJYnuCsCP71Al 6wcqzzj0ywR7N/rPg05hc71n/3/RQpXwqTt1wCw/Z+OF+FSyZADXM0ZWpyzHvRxrW/B3 +nwTWLFuuQyG1sqlSqDlI4GkDQAjxoQKy0wU8emezh4mP9DqxA2EfEQuDFhND8aGdE8I tQuIVdaLdjxFjlX/YrYLp7V/sBW4BN259rGHM57NRlRVjaqRS5MNRjhJd+PkdcLPHt6J J3rQ== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr4367245wic.26.1385026777388; Thu, 21 Nov 2013 01:39:37 -0800 (PST) Received: by 10.217.141.3 with HTTP; Thu, 21 Nov 2013 01:39:37 -0800 (PST) In-Reply-To: References: <1384986598.31172.522.camel@revolution.hippie.lan> Date: Thu, 21 Nov 2013 10:39:37 +0100 Message-ID: Subject: Re: FreeBSD-10 microdrive seagate ST1AT 4GB (VIA mbo) problem From: Berislav Purgar To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 09:39:40 -0000 On Thu, Nov 21, 2013 at 10:35 AM, Berislav Purgar wrote: > > > > On Wed, Nov 20, 2013 at 11:29 PM, Ian Lepore wrote: > >> On Wed, 2013-11-20 at 21:27 +0100, Berislav Purgar wrote: >> > Hello .. >> > >> > I have problem with microdrive and some CF cards on IGEL 3/4 compact >> thin >> > client ( http://www.parkytowers.me.uk/thin/Igel/3210/index.shtml ). >> Problem >> > is that FreeBSD cannot find microdrive or CF card to mount sytem / on >> (but >> > kernel is found and loaded from microdrive or CF card). I have one CF >> card >> > (sandisk ultra II) which boots but with some timeouts before. Here are >> > links to pictures of this problem. >> > >> > (aprobe:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 >> 00 00 >> > >> > >> > http://s24.postimg.org/al2k6qfzp/WP_20131120_003_1.jpg >> > http://s17.postimg.org/wm0s58kzz/WP_20131120_007_1.jpg >> > http://s23.postimg.org/5sp2k4trf/WP_20131120_006_1.jpg >> > >> > i tried same configuration on openbsd5.3 and everething si Ok .. Any >> > suggestions ? >> > >> > Tnx >> > sorry for my English .. >> >> Try adding hw.ata.ata_dma=0 to your /boot/loader.conf. I don't know why >> the bios can do DMA on a CF and freebsd can't, but we've needed to add >> that at $work for years (going back to freebsd 4.x at least). Of >> course, you pay a huge performance penalty for running in PIO mode. >> >> -- Ian >> >> > Hi Ian > > i try this but does not help. for better debuging i use gateworks GW2345 > board and found some interestingly ... if i destroy all partitions and > partitions schemes on microdrive freebsd founds microdrive at boot and > display info for it.. > > Timecounters tick every 10.000 msec > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: CFA-0 device > ada0: 16.700MB/s transfers (PIO4, PIO 8192bytes) > ada0: 3906MB (7999488 512 byte sectors: 16H 63S/T 7936C) > ada0: Previously was known as ad0 > > full dmesg is here : > http://pastebin.com/eWJ4XGyN > > but if i create MBR (or GPT) on microdrive and check as before on avila > board i got timeouts and microdrive not found ?! > > ata_avila0: on ixp0 > ata0: on ata_avila0 > led_avila0: on ixp0 > gpio_avila0: on ixp0 > gpioc0: on gpio_avila0 > gpiobus0: on gpio_avila0 > Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000 > Timecounters tick every 10.000 msec > (aprobe0:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 > 00 > (aprobe0:ata0:0:0:0): CAM status: Command timeout > (aprobe0:ata0:0:0:0): Error 5, Retry was blocked > > full dmesg is here : > http://pastebin.com/wPEexXKz > > i don't think that this is dma problem !? > > Beri > > > > > i forget to paste this link ... this is procedure how i create partition schema on microdrive to test it .. http://pastebin.com/x5MinNQz Beri From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 12:11:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A283183; Thu, 21 Nov 2013 12:11:50 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCFC922B6; Thu, 21 Nov 2013 12:11:49 +0000 (UTC) Received: from [192.168.2.2] (unknown [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C6FB95C43; Thu, 21 Nov 2013 13:11:45 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_4225750B-D051-4013-BCB4-986C82579E93"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Duplicated WITH_*/WITHOUT_* options From: Dimitry Andric In-Reply-To: Date: Thu, 21 Nov 2013 13:11:30 +0100 Message-Id: <9A9B2AFC-A96D-4B63-9ABD-40E4BAA8FD3E@FreeBSD.org> References: <20131119162205.GW1643@glenbarber.us> <20131119231325.GA1527@glenbarber.us> <35.00.29861.FA61C825@cdptpa-oedge02> To: Mark Robert Vaughan Murray X-Mailer: Apple Mail (2.1822) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 12:11:50 -0000 --Apple-Mail=_4225750B-D051-4013-BCB4-986C82579E93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Nov 2013, at 09:44, Mark Robert Vaughan Murray = wrote: > I noticed we have some duplicated WITH_*/WITHOUT_* options; presumably = this is an oversight? >=20 > [graveyard] /usr/src/tools/build/options 08:37 am # for i in WITH_* ; = do if [ -e WITHOUT_${i##WITH_} ] ; then echo WITHOUT_${i##WITH_} ${i} ; = fi; done >=20 > WITHOUT_CLANG WITH_CLANG > WITHOUT_CLANG_FULL WITH_CLANG_FULL > WITHOUT_CLANG_IS_CC WITH_CLANG_IS_CC > WITHOUT_FDT WITH_FDT > WITHOUT_GCC WITH_GCC > WITHOUT_GNUCXX WITH_GNUCXX > WITHOUT_LIBCPLUSPLUS WITH_LIBCPLUSPLUS > WITHOUT_NAND WITH_NAND > WITHOUT_TESTS WITH_TESTS >=20 > As its not all that obvious which one =93wins=94, can this be cleaned = up? I don=92t mind doing the work if there is a somewhat foolproof way = of doing so. These duplicated settings are not oversights, just artifacts of how bsd.own.mk works. The defaults are simply different for different arches, e.g. WITH_CLANG is the default for x86, powerpc and LE arm, but WITHOUT_CLANG is the default for other arches. Similar for the other settings. -Dimitry --Apple-Mail=_4225750B-D051-4013-BCB4-986C82579E93 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKN+HsACgkQsF6jCi4glqPLygCeNC4vP5FEt7hMCQm3pMzWy2Wr UOYAnRPVW/hJerf03CsJbY9ob7C0noaQ =pTrf -----END PGP SIGNATURE----- --Apple-Mail=_4225750B-D051-4013-BCB4-986C82579E93-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 12:47:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15A62C5; Thu, 21 Nov 2013 12:47:50 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D124A252C; Thu, 21 Nov 2013 12:47:49 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 199CFCC2; Thu, 21 Nov 2013 13:47:42 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: Dimitry Andric Subject: Re: Please compile ports-mgmt/pkg for i486 Date: Thu, 21 Nov 2013 13:47:40 +0100 Message-ID: <5711056.E2x60nIvQE@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10590-gdec8e46; KDE/4.11.3; x86_64; ; ) In-Reply-To: <4B4541CC-36A2-4805-8F7A-239E9DE87ABC@FreeBSD.org> References: <22068029.qGT93JWspe@aurora> <16115298.kblWN6Ztd8@aurora> <4B4541CC-36A2-4805-8F7A-239E9DE87ABC@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 12:47:50 -0000 On Wed November 20 2013 20:15:34 Dimitry Andric wrote: > > http://llvm.org/bugs/show_bug.cgi?id=11212 > > http://llvm.org/bugs/show_bug.cgi?id=17792 > > Got bitten by that with -march=i486... > Those bugs are about other CPU's, not specifically the Geode, or i486. > The version of clang in head, stable/10 and stable/9 produces regular > nops for -march=i486, which is the default setting if you don't pass any > arch. So how did you get bitten, then? Were you using 9.1-RELEASE, by > any chance? It might be PEBKAC wrt the samba and cups ports - updating geode by putting CF into a VM with USB passhtrough... Perhaps switched to -march=native by accident. Was using RELENG_9 from Feb 2013, after update, Nov 18 2013 RELENG_10. -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 14:39:07 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 998D949A for ; Thu, 21 Nov 2013 14:39:07 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 711BB2BB9 for ; Thu, 21 Nov 2013 14:39:07 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VjVPO-000OYS-7D; Thu, 21 Nov 2013 14:39:06 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rALEd36M082581; Thu, 21 Nov 2013 07:39:03 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+lCQcCgwROgPolbJitxQZ9 Subject: Re: FreeBSD-10 microdrive seagate ST1AT 4GB (VIA mbo) problem From: Ian Lepore To: Berislav Purgar In-Reply-To: References: <1384986598.31172.522.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2013 07:39:03 -0700 Message-ID: <1385044743.31172.546.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 14:39:07 -0000 On Thu, 2013-11-21 at 10:35 +0100, Berislav Purgar wrote: > On Wed, Nov 20, 2013 at 11:29 PM, Ian Lepore wrote: > > > On Wed, 2013-11-20 at 21:27 +0100, Berislav Purgar wrote: > > > Hello .. > > > > > > I have problem with microdrive and some CF cards on IGEL 3/4 compact thin > > > client ( http://www.parkytowers.me.uk/thin/Igel/3210/index.shtml ). > > Problem > > > is that FreeBSD cannot find microdrive or CF card to mount sytem / on > > (but > > > kernel is found and loaded from microdrive or CF card). I have one CF > > card > > > (sandisk ultra II) which boots but with some timeouts before. Here are > > > links to pictures of this problem. > > > > > > (aprobe:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 > > 00 > > > > > > > > > http://s24.postimg.org/al2k6qfzp/WP_20131120_003_1.jpg > > > http://s17.postimg.org/wm0s58kzz/WP_20131120_007_1.jpg > > > http://s23.postimg.org/5sp2k4trf/WP_20131120_006_1.jpg > > > > > > i tried same configuration on openbsd5.3 and everething si Ok .. Any > > > suggestions ? > > > > > > Tnx > > > sorry for my English .. > > > > Try adding hw.ata.ata_dma=0 to your /boot/loader.conf. I don't know why > > the bios can do DMA on a CF and freebsd can't, but we've needed to add > > that at $work for years (going back to freebsd 4.x at least). Of > > course, you pay a huge performance penalty for running in PIO mode. > > > > -- Ian > > > > > Hi Ian > > i try this but does not help. for better debuging i use gateworks GW2345 > board and found some interestingly ... if i destroy all partitions and > partitions schemes on microdrive freebsd founds microdrive at boot and > display info for it.. > > Timecounters tick every 10.000 msec > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: CFA-0 device > ada0: 16.700MB/s transfers (PIO4, PIO 8192bytes) > ada0: 3906MB (7999488 512 byte sectors: 16H 63S/T 7936C) > ada0: Previously was known as ad0 > > full dmesg is here : > http://pastebin.com/eWJ4XGyN > > but if i create MBR (or GPT) on microdrive and check as before on avila > board i got timeouts and microdrive not found ?! > > ata_avila0: on ixp0 > ata0: on ata_avila0 > led_avila0: on ixp0 > gpio_avila0: on ixp0 > gpioc0: on gpio_avila0 > gpiobus0: on gpio_avila0 > Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000 > Timecounters tick every 10.000 msec > (aprobe0:ata0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 > (aprobe0:ata0:0:0:0): CAM status: Command timeout > (aprobe0:ata0:0:0:0): Error 5, Retry was blocked > > full dmesg is here : > http://pastebin.com/wPEexXKz > > i don't think that this is dma problem !? Hmm, yes, that does seem to be a different problem. -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 17:42:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92F5BDBD for ; Thu, 21 Nov 2013 17:42:44 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5665226D3 for ; Thu, 21 Nov 2013 17:42:44 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id v2so50227qcr.25 for ; Thu, 21 Nov 2013 09:42:43 -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=WbRt2ZU1tAZizIsUfKt1Gd+u+oBFLXhBE66RciVpXno=; b=WnoZRPaDR8eCZN2DnmdV0REVcB+rMx7s3kBnjLjZ0CinYK9Q2E9qbfNeBS9TMZK1Yt l+j9g+7h1HkBSyi6iK045/wWjeNtolWNHAKLiHcs6p0DaWFz+jZ80Pl/6SFeoeklnYgJ Qu+/sYvBu4Hn24wE37N6OF0X5eFBGCCCUhbt9c5wuzBngxua64r1LUOE0PgLu6q2IxmH JScHKY409xjJWEkfKbxXynxmsbMD+uiLT7Yqr0wBxhrMwOpdW+Q/dWq2NqZBmumN4cC4 G+dF0ucIqXJycnYDJMNXO11ky5jQ3Oy/rAGgLaU25FRRey8d1NPg7QQG6lGqpedzXHDn syJA== MIME-Version: 1.0 X-Received: by 10.49.30.162 with SMTP id t2mr13387857qeh.37.1385055763409; Thu, 21 Nov 2013 09:42:43 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.224.87.135 with HTTP; Thu, 21 Nov 2013 09:42:43 -0800 (PST) In-Reply-To: References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> <528786C9.9070409@allanjude.com> <5287BB44.4020104@jrv.org> <5287D632.4010802@allanjude.com> Date: Thu, 21 Nov 2013 12:42:43 -0500 X-Google-Sender-Auth: fzOyXMpY6exHsax1_l4gyWwNmhs Message-ID: Subject: Re: Slow boot with 256GB of RAM? From: Ed Maste To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 17:42:44 -0000 On 16 November 2013 17:49, Eitan Adler wrote: > On Sat, Nov 16, 2013 at 4:12 PM, Zach Crum wrote: >> This setting is not listed in /boot/defaults/loader.conf. Is it supposed to >> be singular or plural? > > Plural. > > I will commit the patch. The FAQ update patch looks fine. > Does any know of cases where this memory test actually catches errors? > How important is it? The boot time test is primarily of historical significance, and doesn't really provide value on contemporary systems. It's mainly a workaround for ancient broken BIOSes that might return bogus memory map data. I intend to commit the patch below that disables it by default. The variable name is "hw.memtest.tests" as it's intended to be extended to a bitmap of tests to run at boot, with other bits representing more comprehensive tests. -Ed commit 58f501f70427ce2aeb9c8b18d2b7bec543818dae Author: Ed Maste Date: Thu Nov 21 12:31:06 2013 -0500 Disable amd64 boot time memory test by default The page presence memory test takes a long time on large memory systems and has little value on contemporary amd64 hardware. diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 7f05d58..df03e55 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -1476,13 +1476,15 @@ getmemsize(caddr_t kmdp, u_int64_t first) Maxmem = atop(physmem_tunable); /* - * By default enable the memory test on real hardware, and disable - * it if we appear to be running in a VM. This avoids touching all - * pages unnecessarily, which doesn't matter on real hardware but is - * bad for shared VM hosts. Use a general name so that - * one could eventually do more with the code than just disable it. + * The boot memory test is disabled by default, as it takes a + * significant amount of time on large-memory systems, and is + * unfriendly to virtual machines as it unnecessarily touches all + * pages. + * + * A general name is used as the code may be extended to support + * additional tests beyond the current "page present" test. */ - memtest = (vm_guest > VM_GUEST_NO) ? 0 : 1; + memtest = 0; TUNABLE_ULONG_FETCH("hw.memtest.tests", &memtest); /* From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 19:06:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AC9E3B3 for ; Thu, 21 Nov 2013 19:06:46 +0000 (UTC) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE05B2D8C for ; Thu, 21 Nov 2013 19:06:45 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id 2so149782qeb.16 for ; Thu, 21 Nov 2013 11:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qvsp2IluUVkFyLQ1iQS3W596koAHaOsh5XYG4Ps1qZU=; b=nZYzJccPFNFo03CJNN+odahc7Y7JMGW2xqNzJr33zmEvWBy6xTK6C+wIcFhxS0OLyB PBhYwKavw7D5Cnr/5aupJGR08Ukav9zyHeeWAjf4BpFu9pf1uiWXggrVNgnFjh/1bQXv Fs1iObVGbQFu2mVbNHNX+GVGyjbZ99kAgBfy8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qvsp2IluUVkFyLQ1iQS3W596koAHaOsh5XYG4Ps1qZU=; b=lg838rcJqRboXE27ZAcXaLAsemMRpkM4KJeKOklRD0hyIG/vtVXLj/79u37fbAo2HK oLIYBPJR23KMZ7N6YzqhemrcVPn/38N+q32SjLGOCy3SNj8a5WPGqlhcRmbZcJHGA3M4 JqVMGzPdzm7/WGqEjRmJUxs1AB8XgN2PYgX+gohW+umZvsg51czhKhq8+hHaFHenoMrY XeJImc4MizWoBR1KKOO9djCSsAAfMtK9v8txCGmO7yeWzJblNbZRKuXADIaJGAaVZY9o LtWEW28pTevWXPHlzGlmcuLrE1I8+pK0EkeOAuD9M/iWmDYOj+9P9JnHpQei4e+UkhvF vMYw== X-Gm-Message-State: ALoCoQngs+zjunTH3atKuujrMrrdRurIPHSpP+EMHhY1xO+PHNugEt1QPD202ZU1EchLwzIa0jra X-Received: by 10.49.99.98 with SMTP id ep2mr14313136qeb.9.1385060804870; Thu, 21 Nov 2013 11:06:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Thu, 21 Nov 2013 11:06:14 -0800 (PST) In-Reply-To: References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> <528786C9.9070409@allanjude.com> <5287BB44.4020104@jrv.org> <5287D632.4010802@allanjude.com> From: Eitan Adler Date: Thu, 21 Nov 2013 14:06:14 -0500 Message-ID: Subject: Re: Slow boot with 256GB of RAM? To: Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:06:46 -0000 On Thu, Nov 21, 2013 at 12:42 PM, Ed Maste wrote: > The variable name is "hw.memtest.tests" as it's intended to be > extended to a bitmap of tests to run at boot, with other bits > representing more comprehensive tests. > > -Ed > > commit 58f501f70427ce2aeb9c8b18d2b7bec543818dae > Author: Ed Maste > Date: Thu Nov 21 12:31:06 2013 -0500 > > Disable amd64 boot time memory test by default > > The page presence memory test takes a long time on large memory systems > and has little value on contemporary amd64 hardware. This patch looks good to me. Please commit it. :) From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 19:27:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87DDECF5; Thu, 21 Nov 2013 19:27:47 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F4052EDE; Thu, 21 Nov 2013 19:27:47 +0000 (UTC) Received: from [2001:470:9174:1:d46f:47f:734f:1850] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VjZui-000MPj-F2; Thu, 21 Nov 2013 19:27:45 +0000 Subject: Re: Duplicated WITH_*/WITHOUT_* options Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5E306495-28E4-49DD-9B19-FDE06B1A2C69"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <9A9B2AFC-A96D-4B63-9ABD-40E4BAA8FD3E@FreeBSD.org> Date: Thu, 21 Nov 2013 19:27:36 +0000 Message-Id: <78EB6232-9540-48DE-8D3B-4B599696E918@FreeBSD.org> References: <20131119162205.GW1643@glenbarber.us> <20131119231325.GA1527@glenbarber.us> <35.00.29861.FA61C825@cdptpa-oedge02> <9A9B2AFC-A96D-4B63-9ABD-40E4BAA8FD3E@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1822) X-SA-Score: -1.0 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:27:47 -0000 --Apple-Mail=_5E306495-28E4-49DD-9B19-FDE06B1A2C69 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 21 Nov 2013, at 12:11, Dimitry Andric wrote: > These duplicated settings are not oversights, just artifacts of how > bsd.own.mk works. The defaults are simply different for different > arches, e.g. WITH_CLANG is the default for x86, powerpc and LE arm, but > WITHOUT_CLANG is the default for other arches. Similar for the other > settings. That makes sense, thanks! M -- Mark R V Murray --Apple-Mail=_5E306495-28E4-49DD-9B19-FDE06B1A2C69 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUo5ert58vKOKE6LNAQo2pwP9Gcxk9vsjidBqjLT8Z6Y752jA+05EduaJ kvlm1jxi+iS0b+zpb2rQ2oevypcvIdWLGAjhRy/hYlz8WAUYcnosZ2IedtJo0y9Q 8/I87H/PJ/MM6nCsfCjZ0SGyM0dwkM/AP3ezR8vbFJIAfGO2f15AvWPHf0RPlwZI 6AFQOXPeddY= =DtDu -----END PGP SIGNATURE----- --Apple-Mail=_5E306495-28E4-49DD-9B19-FDE06B1A2C69-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 22:34:08 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0478BC7B for ; Thu, 21 Nov 2013 22:34:08 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE0142C44 for ; Thu, 21 Nov 2013 22:34:07 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rALMY0bN009437 for ; Thu, 21 Nov 2013 14:34:04 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311212234.rALMY0bN009437@gw.catspoiler.org> Date: Thu, 21 Nov 2013 14:34:00 -0800 (PST) From: Don Lewis Subject: panic: uma_zalloc_arg: Returning an empty bucket. To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 22:34:08 -0000 I just got this panic on my 11.0-CURRENT machine while building ports: panic: uma_zalloc_arg: Returning an empty bucket. cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c113330c,2,10000000,ee3fd850,ee3fd848,...) at db_trace_self_wrapper+0x2d/frame 0xee3fd810 kdb_backtrace(c12f131f,0,c116b406,ee3fd8e4,c116b406,...) at kdb_backtrace+0x30/frame 0xee3fd878 vpanic(c1410ab8,100,c116b406,ee3fd8e4,ee3fd8e4,...) at vpanic+0x11f/frame 0xee3fd8b4 kassert_panic(c116b406,0,c116b3eb,883,1,...) at kassert_panic+0xea/frame 0xee3fd8d8 uma_zalloc_arg(c26d58c0,0,101,0,0,...) at uma_zalloc_arg+0x4bd/frame 0xee3fd918 vm_radix_insert(d25b6780,c403c194,c116d974,3c7,716,...) at vm_radix_insert+0xfa/frame 0xee3fd960 vm_page_insert_after(6348,0,c403c150,637,0,...) at vm_page_insert_after+0xc1/frame 0xee3fd98c vm_page_alloc(d25b6750,6348,0,40,ee3fdacc,...) at vm_page_alloc+0x4fe/frame 0xee3fd9b8 vm_fault_hold(c99b7000,8e9f1000,2,0,0,...) at vm_fault_hold+0x3cb/frame 0xee3fdb18 vm_fault(c99b7000,8e9f1000,2,0,c99b7000,...) at vm_fault+0x82/frame 0xee3fdb40 trap_pfault(8e9f1000,ee3fdd08,0,c9252620,c141e780,...) at trap_pfault+0x198/frame 0xee3fdbb8 trap(ee3fdd08) at trap+0x5e2/frame 0xee3fdcfc calltrap() at calltrap+0x6/frame 0xee3fdcfc --- trap 0xc, eip = 0x88607643, esp = 0xbfbfce98, ebp = 0xbfbfced8 --- KDB: enter: panic FreeBSD scratch.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #60 r258423M: Thu Nov 21 02:27:29 PST 2013 dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 22:34:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F83AD8C; Thu, 21 Nov 2013 22:34:22 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D53B32C52; Thu, 21 Nov 2013 22:34:21 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1VjcpB-002JKI-OM>; Thu, 21 Nov 2013 23:34:13 +0100 Received: from e179038123.adsl.alicedsl.de ([85.179.38.123] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1VjcpB-0017Hh-LD>; Thu, 21 Nov 2013 23:34:13 +0100 Date: Thu, 21 Nov 2013 23:34:08 +0100 From: "O. Hartmann" To: freebsd-hardware@freebsd.org, FreeBSD CURRENT Subject: VIA Sprinboard: Alternative to Raspberry Pi - working with FBSD CURRENT? Message-ID: <20131121233408.480ceced@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/FM79a=DZ+oGXZbfhGKhDSFQ"; protocol="application/pgp-signature" X-Originating-IP: 85.179.38.123 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 22:34:22 -0000 --Sig_/FM79a=DZ+oGXZbfhGKhDSFQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recently, I stumbled into this board, which looks promising: http://www.viaspringboard.com/products.html Does anybody know whether the offered hardware (chipse, CPU, WiFi chipset) is supported by FreeBSD? --Sig_/FM79a=DZ+oGXZbfhGKhDSFQ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJSjoplAAoJEOgBcD7A/5N8cxUIAI4cwVEv3t3LSj8hcVP/z7BM InwDXB2NuvMEiCTRECmdhYjrvnyoNADtNF1UNGY/HaALgCvm0D9AL3vKZ33SXaoF ekXWTrrAsDGkl2Vd3saOEzT0e0sx5aEHE1v0d45NQn7SLvaWg0CQwATQ7iC4CeAn zagHwG5ma2JxQ54AMXCuNFgxGKGBXp3CzD4r17IqvxMMduCNOf7lAZiy4HJzILyy acI4f3DDumaUSpZ4CUUq4CQ1/KTggr5ZmbZWGMqaJq0Z5nbGmXh2JEmyXW3hNNIK KhOpk8weRG0gw7lvUCrrt7qN9PcoEBnJL2/UWvyJAaPqr1nSY4mpnZg9x7/G/DA= =Nc1W -----END PGP SIGNATURE----- --Sig_/FM79a=DZ+oGXZbfhGKhDSFQ-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 21 22:55:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 850FA721; Thu, 21 Nov 2013 22:55:56 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39F702DCB; Thu, 21 Nov 2013 22:55:52 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VjdA2-000BPZ-GR; Thu, 21 Nov 2013 22:55:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rALMtihw083012; Thu, 21 Nov 2013 15:55:44 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18T0S/9mhXW51fxIC0JtScA Subject: Re: VIA Sprinboard: Alternative to Raspberry Pi - working with FBSD CURRENT? From: Ian Lepore To: "O. Hartmann" In-Reply-To: <20131121233408.480ceced@thor.walstatt.dyndns.org> References: <20131121233408.480ceced@thor.walstatt.dyndns.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2013 15:55:44 -0700 Message-ID: <1385074544.31172.560.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD CURRENT , freebsd-hardware@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 22:55:56 -0000 On Thu, 2013-11-21 at 23:34 +0100, O. Hartmann wrote: > Recently, > I stumbled into this board, which looks promising: > > http://www.viaspringboard.com/products.html > > Does anybody know whether the offered hardware (chipse, CPU, WiFi > chipset) is supported by FreeBSD? It's not currently supported, and apparently documentation for the SoC isn't available (the "support" tab on the WonderMedia site isn't selectable, never a good sign). Boards that are comparable in price and processing power that are supported by FreeSBD to varying degrees include the BeagleBone, the Wandboard, and to a lesser degree, the Cubieboard (which has sketchy documentation, but a good bit of reverse engineering has been done to support it). -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 01:01:01 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 599F1C7E; Fri, 22 Nov 2013 01:01:01 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18BF7275B; Fri, 22 Nov 2013 01:01:00 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1Vjf7D-002xYQ-EN>; Fri, 22 Nov 2013 02:00:59 +0100 Received: from e179038123.adsl.alicedsl.de ([85.179.38.123] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1Vjf7D-001GdW-B5>; Fri, 22 Nov 2013 02:00:59 +0100 Date: Fri, 22 Nov 2013 02:00:53 +0100 From: "O. Hartmann" To: Ian Lepore Subject: Re: VIA Sprinboard: Alternative to Raspberry Pi - working with FBSD CURRENT? Message-ID: <20131122020053.1e9ffc24@thor.walstatt.dyndns.org> In-Reply-To: <1385074544.31172.560.camel@revolution.hippie.lan> References: <20131121233408.480ceced@thor.walstatt.dyndns.org> <1385074544.31172.560.camel@revolution.hippie.lan> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/vGe2Igvb/nsKp7oBdK4=W5H"; protocol="application/pgp-signature" X-Originating-IP: 85.179.38.123 Cc: FreeBSD CURRENT , freebsd-hardware@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 01:01:01 -0000 --Sig_/vGe2Igvb/nsKp7oBdK4=W5H Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 21 Nov 2013 15:55:44 -0700 Ian Lepore wrote: > On Thu, 2013-11-21 at 23:34 +0100, O. Hartmann wrote: > > Recently, > > I stumbled into this board, which looks promising: > >=20 > > http://www.viaspringboard.com/products.html > >=20 > > Does anybody know whether the offered hardware (chipse, CPU, WiFi > > chipset) is supported by FreeBSD? >=20 > It's not currently supported, and apparently documentation for the SoC > isn't available (the "support" tab on the WonderMedia site isn't > selectable, never a good sign). >=20 > Boards that are comparable in price and processing power that are > supported by FreeSBD to varying degrees include the BeagleBone, the > Wandboard, and to a lesser degree, the Cubieboard (which has sketchy > documentation, but a good bit of reverse engineering has been done to > support it). >=20 > -- Ian Thank you very much. Oliver --Sig_/vGe2Igvb/nsKp7oBdK4=W5H Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJSjqzKAAoJEOgBcD7A/5N8Sk4H/jyUIepkZNUqWR9+lw9aiyx1 bNwfq6Au1nbpYctz03C+KynKWmfqgNJ7mNiXxvo4nGXVc4XFZTCyg9KDojU+pnE5 FP7/vG+hmW/qa4Oc2NJR80L3v5wDFJCq2QBVQlQwayNgeX76ytbOnU2b3Z979ALr IKxzGF2/N/SyGAKT0aB6xxwVto0sjzkiNVS7HipWs2PlnqvcOn59U7PDJHLvul2+ Buc/9NWFcd+3aVPvckR4C11z+W016K5EL9h48YEAjnxiIqKxty0uofjD8MHnNXNg 6lhb1/j61VmSKIG4lIZIwLjZoAeukKKvcZ2QUrxwT1iWI1JNwqOIyTLoMRqPxtI= =Qz97 -----END PGP SIGNATURE----- --Sig_/vGe2Igvb/nsKp7oBdK4=W5H-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 01:58:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C7EC4B7 for ; Fri, 22 Nov 2013 01:58:33 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F188C2BAE for ; Fri, 22 Nov 2013 01:58:32 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 21151CC2 for ; Fri, 22 Nov 2013 02:58:31 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: current@freebsd.org Subject: pkg(1) ipv6 address not listening Date: Fri, 22 Nov 2013 02:58:28 +0100 Message-ID: <2045609.xWoXWBLPTu@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10928-g527d151; KDE/4.11.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 01:58:33 -0000 Hey, pkg(1) doesn't like ipv6 from two different subnets: | ^C15720: connect(6,{ AF_INET6 [2001:41c8:112:8300::50:1]:80 },28) ERR#4 'Interrupted system call' It's up fine, just not listening. Could you fix it, please? -sh -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 03:23:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36185E26 for ; Fri, 22 Nov 2013 03:23:46 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2AD822F0 for ; Fri, 22 Nov 2013 03:23:45 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id w7so182033qcr.39 for ; Thu, 21 Nov 2013 19:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Vu33Xu6GouQ4/SPH9V1W/KS/V9lJ/dEbWdeRSWE4p4k=; b=Qkjx3UcHPPavl4YAiMrPHwjegFDoVHq+8N/6IWo/rP9WqkzvWFwHnRtVyyl1llBUwF nx3pIRPBHnhdHP6rvD1BXx88nDImzryz2Hs+ec6dviM9N+9LMCN3g9PrfWG5qVGNM+EM jRY5lrAhF9NV1/rCQ+biANNhU5pW6hc18yMavlyitz6tKrdrgfG/SBPKvV0RQlzGBpxo wi5cM7gBOEim0rjPRCqSW6rEpWPaGul3ecFc8l2Im8ZxZbK/fyPPoRpW9yI6GxV2O371 2KFeKRwLSng6FGpuy5umZmM0oZ9L7TNfLwCQiQIHrDJU0NDDWe+wmbKng0t3DJEavfSW B0Vw== MIME-Version: 1.0 X-Received: by 10.224.67.200 with SMTP id s8mr17427391qai.75.1385090625148; Thu, 21 Nov 2013 19:23:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 21 Nov 2013 19:23:45 -0800 (PST) Date: Thu, 21 Nov 2013 19:23:45 -0800 X-Google-Sender-Auth: XNC7y69asjvIiIii2Qs9ehiapfc Message-ID: Subject: i386 update to latest -HEAD broke things From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 03:23:46 -0000 hi, I just updated a laptop from a month old -HEAD to the latest -HEAD. Things .. didn't work. * No processes ran - they'd complain about being out of anonymous memory * /rescue/sh works fine, but /rescue/dhclient seems to be doing the wrong thing with regards to which dhclient-script it calls * .. and /rescue/dhclient-script also references things in /, which doesn't work. Grr. Anyway: * copying over a replacement ld.so from an i386 image from the 11th restored basic binaries, but things like fsck would randomly crap out * copying over the conents of /lib let things get further, but ssh died (jemalloc arena complaints, so I'm guessing maybe there's something odd going on here..) * copying over the contents of /usr/lib didn't improve things; * copying over the contents of /usr/lib/private fixed things enough to get ssh up so I can svn update to an earlier version. I'm currently rebuilding r258446 (one before the first weak reference change) to make sure that this userland is stable. If it works out, I'll try subsequent versions. Just be careful. :-0 -adrian From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 07:15:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0BA5BB5 for ; Fri, 22 Nov 2013 07:15:25 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68AC52DA2 for ; Fri, 22 Nov 2013 07:15:25 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id rAM7FB00057084 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 07:15:19 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk rAM7FB00057084 Authentication-Results: smtp.infracaninophile.co.uk/rAM7FB00057084; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <528F0474.90802@FreeBSD.org> Date: Fri, 22 Nov 2013 07:15:00 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?UTF-8?B?U3RhbmlzxYJhdyBIYWxpaw==?= , current@freebsd.org Subject: Re: pkg(1) ipv6 address not listening References: <2045609.xWoXWBLPTu@aurora> In-Reply-To: <2045609.xWoXWBLPTu@aurora> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IOf558rRbkH2rs5vi9P7tojccSetnK1i5" X-Virus-Scanned: clamav-milter 0.98 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 07:15:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IOf558rRbkH2rs5vi9P7tojccSetnK1i5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22/11/2013 01:58, Stanis=C5=82aw Halik wrote: > Hey, >=20 > pkg(1) doesn't like ipv6 from two different subnets: >=20 > | ^C15720: connect(6,{ AF_INET6 [2001:41c8:112:8300::50:1]:80 },28) ERR= #4=20 > 'Interrupted system call' >=20 > It's up fine, just not listening. Could you fix it, please? pkg(8) works fine over IPv6 for me. It also does not have any sort of network listener internally. Acts as a client accessing external servers only. Please explain clearly exactly what you're doing in order to see this error. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --IOf558rRbkH2rs5vi9P7tojccSetnK1i5 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) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSjwR9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkAT3kwP/20x5N4hJnbr/Z+vMTYQvpF6 rHezeJK3OjWPlpjV9l76tkMoewZyCIUp00W6wS8iANrXWCAySSylv4O/evDQ3XRd pnLPsKlbhEWPk5QmJX06FuUVTzewk41ShUDgjIZRjU6wP4q1hJhQBTgKUDOwDUzO xisYF64WaA5BAL1OGu7B9ndlHLmPOjCJ3e2vtMbo15sVkqTTz8VZWvYvyXshYDX9 MJPxpDmI7Ldy3y66PpVLt6Qy2zf9c+KD94+x89Bc4oCsSmeWf7MzHv9TObkQZPcd 0+pET6IhiaYbA9Hgva3tqPjvIwiaQvvkAQXG5lk0lLVW0Z1Ifa6daZ9YHL8zNR6d 95zY8BCOPTQnkbI39cTSys23twmcOK7SVnh4A+6xyLTgofQc21Gn8MV5biaIvesv OKfxmzCTyNATGY2JccycjQGW3suDAyELzzDisYN04jOcMCcD9TAai1dmXdqYxeWV PtKizZceTQ9nJ9OwPEKI6bpcNjCOmA8HGl5BKpA3Yi8fKvRSrSN+kIdLV2Mq6sYx Be5F5gY4+YzGqUAUNrkCE4mJWqrNdAeIUa2swaYQ7h1WNHbonoRZVPbeO7hgpFtX gdeOe6/dA74h3SVhj5aaJhuOChlqTvyySGccR2PqHOucud1KdwiFrEqEIfUdm+KD VNa4QRpPnBit1yv6fW9/ =evUW -----END PGP SIGNATURE----- --IOf558rRbkH2rs5vi9P7tojccSetnK1i5-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 07:19:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B97DDC; Fri, 22 Nov 2013 07:19:47 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CD9F2DE5; Fri, 22 Nov 2013 07:19:47 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 9B614CC2; Fri, 22 Nov 2013 08:19:45 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: Matthew Seaman Subject: Re: pkg(1) ipv6 address not listening Date: Fri, 22 Nov 2013 08:19:43 +0100 Message-ID: <4048504.G3354ttriA@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10928-g527d151; KDE/4.11.3; x86_64; ; ) In-Reply-To: <528F0474.90802@FreeBSD.org> References: <2045609.xWoXWBLPTu@aurora> <528F0474.90802@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 07:19:47 -0000 Hey, On Fri November 22 2013 07:15:00 Matthew Seaman wrote: > > pkg(1) doesn't like ipv6 from two different subnets: > > | ^C15720: connect(6,{ AF_INET6 [2001:41c8:112:8300::50:1]:80 },28) ERR#4 > > pkg(8) works fine over IPv6 for me. Failing command is: % pkg update using default repo configuration. The above line was producted by: % truss -f pkg update Unable to access pkg.freebsd.org IPv6 server over two subnets. Tested with `nc -v' 2001:470:600d:dead:beae:c5ff:fee1:4407/48 2a01:4f8:192:50e3::/64 1001 ~ % ssh ananke.laggy.pk cat /etc/pkg/FreeBSD.conf FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", mirror_type: "srv", enabled: "yes" } cheers, -sh -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 07:30:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76C37138 for ; Fri, 22 Nov 2013 07:30:08 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2BEE2E61 for ; Fri, 22 Nov 2013 07:30:07 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id rAM7U2gQ057397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 07:30:02 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk rAM7U2gQ057397 Authentication-Results: smtp.infracaninophile.co.uk/rAM7U2gQ057397; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <528F07FA.2000804@FreeBSD.org> Date: Fri, 22 Nov 2013 07:30:02 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?UTF-8?B?U3RhbmlzxYJhdyBIYWxpaw==?= Subject: Re: pkg(1) ipv6 address not listening References: <2045609.xWoXWBLPTu@aurora> <528F0474.90802@FreeBSD.org> <4048504.G3354ttriA@aurora> In-Reply-To: <4048504.G3354ttriA@aurora> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cIMQ1T2vjeoIrk8Mj03DiH7IoSurwaQw1" X-Virus-Scanned: clamav-milter 0.98 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 07:30:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cIMQ1T2vjeoIrk8Mj03DiH7IoSurwaQw1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22/11/2013 07:19, Stanis=C5=82aw Halik wrote: > Hey, >=20 > On Fri November 22 2013 07:15:00 Matthew Seaman wrote: >>> pkg(1) doesn't like ipv6 from two different subnets: >>> | ^C15720: connect(6,{ AF_INET6 [2001:41c8:112:8300::50:1]:80 },28) E= RR#4 >> >> pkg(8) works fine over IPv6 for me. >=20 > Failing command is: >=20 > % pkg update >=20 > using default repo configuration. The above line was producted by: >=20 > % truss -f pkg update >=20 > Unable to access pkg.freebsd.org IPv6 server over two subnets. > Tested with `nc -v' >=20 > 2001:470:600d:dead:beae:c5ff:fee1:4407/48 > 2a01:4f8:192:50e3::/64 >=20 > 1001 ~ % ssh ananke.laggy.pk cat /etc/pkg/FreeBSD.conf > FreeBSD: { > url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", > mirror_type: "srv", > enabled: "yes" > } Are you running the ports-mgmt/pkg-devel port or did you install from GitHub sources? (I deduce this because the config format with curly braces does not work with pkg-1.1.4...) Can't reproduce with 1.1.4: xenophobe:/usr/local/etc:# pkg -vv Version: 1.1.4 PACKAGESITE: PKG_DBDIR: /var/db/pkg PKG_CACHEDIR: /var/cache/pkg PORTSDIR: /usr/ports PUBKEY: HANDLE_RC_SCRIPTS: no ASSUME_ALWAYS_YES: no REPOS_DIR: /usr/local/etc/pkg/repos/ PLIST_KEYWORDS_DIR: SYSLOG: yes AUTODEPS: no ABI: freebsd:9:x86:64 DEVELOPER_MODE: no PORTAUDIT_SITE: http://portaudit.FreeBSD.org/auditfile.tbz VULNXML_SITE: http://www.vuxml.org/freebsd/vuln.xml.bz2 MIRROR_TYPE: SRV FETCH_RETRY: 3 PKG_PLUGINS_DIR: /usr/local/lib/pkg/ PKG_ENABLE_PLUGINS: yes PLUGINS: DEBUG_SCRIPTS: no PLUGINS_CONF_DIR: /usr/local/etc/pkg/ PERMISSIVE: no REPO_AUTOUPDATE: yes NAMESERVER: EVENT_PIPE: FETCH_TIMEOUT: 30 UNSET_TIMESTAMP: no SSH_RESTRICT_DIR: PKG_ENV: DISABLE_MTREE: no Repositories: pkg-test: url: pkg+http://pkg.freebsd.org/freebsd:9:x86:64/latest key: enabled: yes mirror_type: SRV xenophobe:/usr/local/etc:# pkg update -f Updating repository catalogue digests.txz 100% 996KB 996.1KB/s 996.1KB/s 00:01 packagesite.txz 100% 5555KB 1.4MB/s 1.1MB/s 00:04 Incremental update completed, 0 packages processed: 0 packages updated, 0 removed and 0 added. This is using an IPv6-only jail: xenophobe:/usr/local/etc:# ifconfig em0 em0: flags=3D8843 metric 0 mtu 15= 00 options=3D4219b ether 68:05:ca:0b:3d:42 inet6 2001:8b0:151:1:54f9:9484:e8b0:12d1 prefixlen 128 nd6 options=3D21 media: Ethernet autoselect (100baseTX ) status: active Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --cIMQ1T2vjeoIrk8Mj03DiH7IoSurwaQw1 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) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSjwf6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATjWUP/2LXb8YDAuOGWjWrzAK0va/t nASxmH9cXpeaElDLafexxRwNa82+ul4ALzHqn5gMxVPFmXYvTqWeaYNz2xc5z7aj H7dZEGUSw49wIbLvyA+pscqc546g1SiRwohsAMbaJD+D0hr4ZRV6p9lMcG4tYzR4 f7qy19F5zk2SeQnYxdX7w3FcTkf8zCqSA+zKbxA5pdwARUaAuhbnXV0NivNExTqg PymxE+W6I8nzyKN4f0m559Q07iYu3aRLp/pmI76TlnyhgSXy2SZv/LgH3wBlUH96 kHMgo0+UshrvjP2sqWbeohoLsYdi48w8JF9mcxq9/4UZX8wfSoREbY5OE28nOvIS UaR81aBKrz36uBymPtke6Bj6c89iAvf/PXY0eBE2FWzh/WSZ5qk280tF7bvXxiw+ To/qig7ZIY97VfLmouhx5LZxfBuO0LCMbfXBI5+uxfjBTTxAjHX5ibJexvTkPMak kjruNksFTzCUaKEhyBMIID3Xj3AleRJUZyJST+Nxd9FbMeVljbQD+YAWhfNk67LV Z2rrb5wABPLcoWO/pxepDmRtxmVanW4ydvDk7zDB5MaztHwK9GcrpGwMuTdi1VvF H+DNjGNaoBa4NCS0d+aneifLBD6ItKCh7ZK7mIFnoixiDXLhJH2xJeFTXSF10Wg1 q9Puf2DrCJexPsBWjdJy =sNz/ -----END PGP SIGNATURE----- --cIMQ1T2vjeoIrk8Mj03DiH7IoSurwaQw1-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 07:44:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E499F8C9; Fri, 22 Nov 2013 07:44:31 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD7B52F5C; Fri, 22 Nov 2013 07:44:31 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 208B8CC2; Fri, 22 Nov 2013 08:44:30 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: Matthew Seaman Subject: Re: pkg(1) ipv6 address not listening Date: Fri, 22 Nov 2013 08:44:29 +0100 Message-ID: <1783583.lPMmx6yJk3@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10928-g527d151; KDE/4.11.3; x86_64; ; ) In-Reply-To: <528F07FA.2000804@FreeBSD.org> References: <2045609.xWoXWBLPTu@aurora> <4048504.G3354ttriA@aurora> <528F07FA.2000804@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 07:44:32 -0000 On Fri November 22 2013 07:30:02 Matthew Seaman wrote: > Are you running the ports-mgmt/pkg-devel port or did you install from > GitHub sources? (I deduce this because the config format with curly > braces does not work with pkg-1.1.4...) Using pkg as bundled with RELENG_10. # uname -sr FreeBSD 10.0-BETA3 > Can't reproduce with 1.1.4 [..] Is geolocated DNS in use? Note that the following server IP fails: 9273: connect(6,{ AF_INET6 [2001:41c8:112:8300::50:1]:80 },28) ERR#4 'Interrupted system call' That is, pkg0.bme.freebsd.org Interesting... It works from Hurricane Electric... Apologies for misinformation. It doesn't work from hetzner.de native IP: 07:43:30.110332 IP6 (flowlabel 0x8c886, hlim 64, next-header TCP (6) payload length: 40) 2a01:4f8:192:50e3::.36954 > 2001:41c8:112:8300::50:1.80: Flags [S], cksum 0x67c9 (incorrect -> 0x98d3), seq 914261876, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 14546988 ecr 0], length 0 The checksum bit is probably due to offload... cheers, -sh -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 07:46:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED9ADA34; Fri, 22 Nov 2013 07:46:49 +0000 (UTC) Received: from sandbox.adsolutions.pl (sandbox.adsolutions.pl [62.212.85.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4D2C2F7D; Fri, 22 Nov 2013 07:46:49 +0000 (UTC) Received: from aurora.misaki.pl (d140-207.icpnet.pl [109.173.140.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandbox.adsolutions.pl (Postfix) with ESMTPSA id 48F2ACC2; Fri, 22 Nov 2013 08:46:48 +0100 (CET) From: =?utf-8?B?U3RhbmlzxYJhdw==?= Halik To: freebsd-current@freebsd.org Subject: Re: pkg(1) ipv6 address not listening Date: Fri, 22 Nov 2013 08:46:47 +0100 Message-ID: <2166379.DtXyXkc7Qb@aurora> User-Agent: KMail/4.11.3 (Linux/3.12.0-ricer-10928-g527d151; KDE/4.11.3; x86_64; ; ) In-Reply-To: <528F07FA.2000804@FreeBSD.org> References: <2045609.xWoXWBLPTu@aurora> <4048504.G3354ttriA@aurora> <528F07FA.2000804@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: Matthew Seaman , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 07:46:50 -0000 good Sir, Apologies! It of course works as it should, wrong `route-to' applied, causing SYN packets to get stuck. Apologies once again for wasting your valuable time. cheers, -sh -- xmpp:sthalik@jabster.pl sip:sthalik@misaki.pl From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 09:04:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9A23252 for ; Fri, 22 Nov 2013 09:04:57 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F8002393 for ; Fri, 22 Nov 2013 09:04:57 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id f11so281189qae.5 for ; Fri, 22 Nov 2013 01:04:56 -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:content-type; bh=c9Ki1h2K1bjHLiFbdowrXDyEar0J+ikr58DBDnTkhyo=; b=vDqjKrVq8LXlVAr8D5tQfI+9ltoP3aX8hezOmSJB/dVZvI1LGJC3dKxWrfuRGxXKOC Bu/kWsFbSUhPpQc5+spObw0CVCIvJ8efwFPFl5sz5OEiEQsOfuuWRScBGlvKSl6AikTW AZHGmcREjbR5919BnkGOwsrR3G1b3PmhIxkEojdRCB1iOaU6m90/7qKUC25UE9HnHqce 1eVpXvVrVP8M+Z07U2Fo2JqmBPFc4ZNdip+qOFdfZPez8zi48GbG7uu1VhdAIzWsoK3O tNDCw8Q3IKD68hBna136w+qh53i++flHghLTBD9ui8RG4iYm7pmlYQwkFnCWwQxP4E4z wgZA== MIME-Version: 1.0 X-Received: by 10.229.13.69 with SMTP id b5mr19439656qca.13.1385111096518; Fri, 22 Nov 2013 01:04:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 22 Nov 2013 01:04:56 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Nov 2013 01:04:56 -0800 X-Google-Sender-Auth: yy_0hSetAxyDAU3jbFIUEAWa5tg Message-ID: Subject: Re: i386 update to latest -HEAD broke things From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:04:57 -0000 r258446 built, installed and booted fine. I'll try a more recent i386 in a chroot soon. Would someone please double-check -HEAD on i386 and see if it's ok? Thanks, -adrian On 21 November 2013 19:23, Adrian Chadd wrote: > hi, > > I just updated a laptop from a month old -HEAD to the latest -HEAD. > Things .. didn't work. > > * No processes ran - they'd complain about being out of anonymous memory > * /rescue/sh works fine, but /rescue/dhclient seems to be doing the > wrong thing with regards to which dhclient-script it calls > * .. and /rescue/dhclient-script also references things in /, which > doesn't work. Grr. > > Anyway: > > * copying over a replacement ld.so from an i386 image from the 11th > restored basic binaries, but things like fsck would randomly crap out > * copying over the conents of /lib let things get further, but ssh > died (jemalloc arena complaints, so I'm guessing maybe there's > something odd going on here..) > * copying over the contents of /usr/lib didn't improve things; > * copying over the contents of /usr/lib/private fixed things enough to > get ssh up so I can svn update to an earlier version. > > I'm currently rebuilding r258446 (one before the first weak reference > change) to make sure that this userland is stable. If it works out, > I'll try subsequent versions. > > Just be careful. :-0 > > > > -adrian From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 09:11:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80E29550; Fri, 22 Nov 2013 09:11:11 +0000 (UTC) Received: from mx1.flashcable.ch (mx1.flashcable.ch [81.92.96.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F292B240A; Fri, 22 Nov 2013 09:11:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.flashcable.ch (8.13.8/8.13.8/Submit_local) with ESMTP id rAM9B1E1094602; Fri, 22 Nov 2013 10:11:01 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Received: from phpmailer (borderline21.nexus-ag.com [212.203.104.226]) by localhost with HTTPS (UebiMiau); Fri, 22 Nov 2013 10:11:01 +0100 Date: Fri, 22 Nov 2013 10:11:01 +0100 To: AdrianChadd , freebsd-current From: Andreas Tobler Subject: Re: i386 update to latest -HEAD broke things Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Andreas Tobler List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:11:11 -0000 --------- Original Message -------- From: Adrian Chadd To: freebsd-current Subject: Re: i386 update to latest -HEAD broke things Date: 22/11/13 10:05 > r258446 built, installed and booted fine. I'll try a more recent i386 > in a chroot soon. > > Would someone please double-check -HEAD on i386 and see if it's ok? Rebuild on i386 is in progress. Native, will take some time. Andreas From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 09:40:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27188C00 for ; Fri, 22 Nov 2013 09:40:52 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E119525A0 for ; Fri, 22 Nov 2013 09:40:51 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id ii20so302993qab.9 for ; Fri, 22 Nov 2013 01:40:51 -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=z0PFAtc5PUdrZa0bwYS/TOyA+fyTvU/p4rGpjXlPQKU=; b=gMd9k768+RRqextru268c7Xui7hvNXAjMQ0mPkbCjsVAH87dcDIVXulOaMgEWSFJEt tfLPrhrioDYZnhOGD7iw6Jb6UBzfj8QnFvhylLb8BVuIMO1WEeVXMTYjN3tAPF+oukGE /cKCTqrx1jQl/fQRKoRTLLNwaT0ciWdW/2oIJ1NHaxPDM+5V2je8Zv+BSdjAP2s2V04V 33hy9ywIwhuKr0kxxn+zFdmoBYFINJpAhm/m6tCS1LJFJfWHgo9I3zPzaGOYkYKWtYlR ByuE1swQCgPP0/Zf2yS1uDMq1WS2ZDQ5FnQIrtHRDoFnroUPfyHVFKYoOL8DewG6Z1QX pi2g== MIME-Version: 1.0 X-Received: by 10.224.111.197 with SMTP id t5mr19749486qap.49.1385113251107; Fri, 22 Nov 2013 01:40:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 22 Nov 2013 01:40:51 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Nov 2013 01:40:51 -0800 X-Google-Sender-Auth: 34UUUtlbmo17-qoL9wyed1rqKFg Message-ID: Subject: Re: i386 update to latest -HEAD broke things From: Adrian Chadd To: Andreas Tobler Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:40:52 -0000 On 22 November 2013 01:11, Andreas Tobler wrote: > --------- Original Message -------- > From: Adrian Chadd > To: freebsd-current > Subject: Re: i386 update to latest -HEAD broke things > Date: 22/11/13 10:05 > >> r258446 built, installed and booted fine. I'll try a more recent i386 >> in a chroot soon. >> >> Would someone please double-check -HEAD on i386 and see if it's ok? > > Rebuild on i386 is in progress. Native, will take some time. I suggest installing it in a chroot rather than over the live system. :) -adrian From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 09:52:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70171D4 for ; Fri, 22 Nov 2013 09:52:19 +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 39B47263E for ; Fri, 22 Nov 2013 09:52:18 +0000 (UTC) Received: from [96.28.178.143] ([96.28.178.143:23643] helo=localhost) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 9A/DA-31125-2592F825; Fri, 22 Nov 2013 09:52:18 +0000 Date: Fri, 22 Nov 2013 09:52:18 +0000 Message-ID: <9A.DA.31125.2592F825@cdptpa-oedge03> From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20131121233408.480ceced@thor.walstatt.dyndns.org> Subject: Re: VIA Sprinboard: Alternative to Raspberry Pi - working with FBSD CURRENT? X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Cc: "O. Hartmann" , freebsd-hardware@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:52:19 -0000 from O. Hartmann: > Recently, > I stumbled into this board, which looks promising: > http://www.viaspringboard.com/products.html > Does anybody know whether the offered hardware (chipse, CPU, WiFi > chipset) is supported by FreeBSD? I went to that URL and noticed that the WiFi chip was Atheros AR9271, same as one I have and not currently supported by FreeBSD but maybe supported in NetBSD-current and Linux. I couldn't tell on my own whether the rest of the system could run FreeBSD or NetBSD, but from Ian Lepore's response, it doesn't look good. Better off with Raspberry Pi? Tom From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 10:03:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DA25581 for ; Fri, 22 Nov 2013 10:03:31 +0000 (UTC) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 198D026E9 for ; Fri, 22 Nov 2013 10:03:30 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c13so480688eek.2 for ; Fri, 22 Nov 2013 02:03:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wKke+WfZJqeDc/WH25FcK9O/f83KkGN4MaqDUpnCrDU=; b=N32EoF2ix9y71wUkTwSg1y7m///xMxhwp/nShGKXYB7cVs4dfRmisxIAN8gopzIWOL kC9STXeFVOFXyrGK8YUDqElQk+v0jLWcijPZ3exKGaVrdYQX4TgVxGve2DHLit8mufy7 qqSsl1Jt1ZJrjQaull+0kHDZXsNSsXrFE9ZfoOS3A8QvCW+dRVJ0NSeEyTIu2KOhWIKb q68xiycHL0tDQyREck/nES4h1cRS33f4MbN6BpBzVPFDelC7DEFwe54x3JcikNalDq/k PiduTZy9j8Co6N/SKS+LSweMAzWRVdtKT68Z+rN9FUC0aL95oXb+aFcXNem9tUQPF9SD tJKA== X-Gm-Message-State: ALoCoQkr07BIUF9CnXqCUROyhEYPRGglc9YLZm1cWqo5cgq3mGC9bKSrCfCt04PKrO5jdsDjgezs MIME-Version: 1.0 X-Received: by 10.15.36.197 with SMTP id i45mr15539872eev.31.1385114608999; Fri, 22 Nov 2013 02:03:28 -0800 (PST) Received: by 10.14.100.135 with HTTP; Fri, 22 Nov 2013 02:03:28 -0800 (PST) In-Reply-To: <20131114102950.Horde.uCQ5LSTB66L6bzvi29QHlw1@ssl.eumx.net> References: <20131114102950.Horde.uCQ5LSTB66L6bzvi29QHlw1@ssl.eumx.net> Date: Fri, 22 Nov 2013 11:03:28 +0100 Message-ID: Subject: Re: bind9 remnants From: Olivier Smedts To: "Herbert J. Skuhra" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: "freebsd-current@freebsd.org" , glebius@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 10:03:31 -0000 Hello, 2013/11/14 Herbert J. Skuhra > > to. 14. nov. 2013 kl. 11.02 +0100 skrev Olivier Smedts: > > > Hello, >> >> cc'ing glebius since he committed r257694 ("Remove remnants of BIND from >> /etc, since there is no BIND in base now.") which removed remnants of BIND >> from /etc but not from /usr/src/etc. >> >> Can we please remove bind9 references from etc/mtree/BSD.usr.dist ? >> /usr/share/doc/bind9, /usr/share/doc/bind9/arm and >> /usr/share/doc/bind9/misc are constantly re-created during a "make >> installworld" or "make hierarchy" and are then removed by "make >> delete-old". I'm using stable/10 right now, where r257694 has been MFCed >> as >> r258121. >> > > It's already in HEAD: > > http://svnweb.freebsd.org/base?view=revision&revision=256769 > Is there a reason (other than ENOTIME) why it has not been MFCed to stable/10 yet ? It's not critical but would make a cleaner 10.0-RELEASE. Thanks -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 10:49:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93F7841A; Fri, 22 Nov 2013 10:49:27 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50EF02985; Fri, 22 Nov 2013 10:49:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::495f:21b3:4ac4:accc] (unknown [IPv6:2001:7b8:3a7:0:495f:21b3:4ac4:accc]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BE4075C43; Fri, 22 Nov 2013 11:49:16 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_EF96DE20-B6C7-4600-B340-AAD8A67A0DFC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: i386 update to latest -HEAD broke things From: Dimitry Andric In-Reply-To: Date: Fri, 22 Nov 2013 11:49:04 +0100 Message-Id: <7F77CAD4-3C04-4285-B6CF-DCEA35DC2390@FreeBSD.org> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1822) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 10:49:27 -0000 --Apple-Mail=_EF96DE20-B6C7-4600-B340-AAD8A67A0DFC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 22 Nov 2013, at 04:23, Adrian Chadd wrote: > I just updated a laptop from a month old -HEAD to the latest -HEAD. > Things .. didn't work. > > * No processes ran - they'd complain about being out of anonymous memory > * /rescue/sh works fine, but /rescue/dhclient seems to be doing the > wrong thing with regards to which dhclient-script it calls > * .. and /rescue/dhclient-script also references things in /, which > doesn't work. Grr. > > Anyway: > > * copying over a replacement ld.so from an i386 image from the 11th > restored basic binaries, but things like fsck would randomly crap out > * copying over the conents of /lib let things get further, but ssh > died (jemalloc arena complaints, so I'm guessing maybe there's > something odd going on here..) > * copying over the contents of /usr/lib didn't improve things; > * copying over the contents of /usr/lib/private fixed things enough to > get ssh up so I can svn update to an earlier version. > > I'm currently rebuilding r258446 (one before the first weak reference > change) to make sure that this userland is stable. If it works out, > I'll try subsequent versions. I think the fix for llvm PR 15086 (done in r258455) is causing these problems, since upstream apparently reported miscompilations with it (which I haven't seen, but maybe I was just lucky). I will revert that tonight after $WORK, but if you can test reverting it locally, please do. -Dimitry --Apple-Mail=_EF96DE20-B6C7-4600-B340-AAD8A67A0DFC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKPNqQACgkQsF6jCi4glqPN2gCgt8vFkVzzoE7NGQsV9o7bB/UJ tuUAoIMEjoAuF+H02/DR01f80jjz2Qqn =bYGb -----END PGP SIGNATURE----- --Apple-Mail=_EF96DE20-B6C7-4600-B340-AAD8A67A0DFC-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 17:38:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B8E5FE3; Fri, 22 Nov 2013 17:38:40 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 998C222F6; Fri, 22 Nov 2013 17:38:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="scan'208";a="74846237" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 22 Nov 2013 17:38:36 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Fri, 22 Nov 2013 12:38:35 -0500 Message-ID: <528F9699.4060307@citrix.com> Date: Fri, 22 Nov 2013 18:38:33 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "freebsd-xen@freebsd.org" Subject: Re: FreeBSD PVH guest support References: <526E6807.9030005@citrix.com> <527BD793.8010606@citrix.com> <527E24D8.4010403@citrix.com> <52864749.1020308@citrix.com> In-Reply-To: <52864749.1020308@citrix.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: peter@FreeBSD.org, alc@FreeBSD.org, xen-devel , freebsd-current@freebsd.org, Konstantin Belousov , "Justin T. Gibbs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 17:38:40 -0000 Hello, I've updated the branch one more time in order to cope with the recent HEAD changes regarding SMAP parsing, as usual the branch can be found at: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v5 Also, I've created a wiki page that describes how to set up a FreeBSD PVH guest: http://wiki.xen.org/wiki/FreeBSD_PVH In case anyone wants to give it a try :) Thanks. From owner-freebsd-current@FreeBSD.ORG Fri Nov 22 19:10:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51335FF2; Fri, 22 Nov 2013 19:10:30 +0000 (UTC) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.157]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 14A772843; Fri, 22 Nov 2013 19:10:29 +0000 (UTC) Date: Fri, 22 Nov 2013 19:51:51 +0100 From: vermaden Subject: FreeBSD 10-BETA3 - zfs clone of zvol snapshot is not created To: freebsd-questions@freebsd.org, freebsd-stable@FreeBSD.org, freebsd-current@freebsd.org X-Mailer: interia.pl/pf09 X-Originating-IP: 93.154.205.68 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1385146311; bh=GAbPRoYHY771Bo7BXTXTC+7W14Ex4KA0ilJhUn6IQA0=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=a8Fy4+x7g1lqnrO4tOj0xSmsKLqzYR+NAer/xG4eG/XMlCFJ309bgSPiFsHM1gKCr K0yc5gK4enKh0QIvpVA5hTfu+vfCb2yuf4MxZu1vFqK6yBaleT9iBokbEMfrwqdruu 6Q5kRKLuE+weLQOQWZVViAYokw08CH7/2XgZrnKs= X-Mailman-Approved-At: Fri, 22 Nov 2013 20:12:06 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:10:30 -0000 Hi, am I doing something wrong, ZFS does not support that or there is a bug that zvol clone does not show up under /dev/zvol after creating it from other zvol snapshot? # zfs list -t all | grep local local 136G 76.8G 144K none local/home 117G 76.8G 117G /home local/vm 18.4G 76.8G 144K none local/vm/vbox_pcbsd_10 5.35G 76.8G 5.35G - local/vm/vbox_windows_7 10.8G 76.8G 9.86G - local/vm/vbox_windows_7@clean 940M - 8.12G - local/vm/vbox_windows_xp 2.27G 76.8G 2.16G - local/vm/vbox_windows_xp@clean 109M - 1.07G - # zfs clone local/vm/vbox_windows_7@clean local/vm/vbox_windows_7_personal # zfs list -t all | grep local local 136G 76.8G 144K none local/home 117G 76.8G 117G /home local/vm 18.4G 76.8G 144K none local/vm/vbox_pcbsd_10 5.35G 76.8G 5.35G - local/vm/vbox_windows_7 10.8G 76.8G 9.86G - local/vm/vbox_windows_7@clean 940M - 8.12G - local/vm/vbox_windows_7_personal 8K 76.8G 8.12G - local/vm/vbox_windows_xp 2.27G 76.8G 2.16G - local/vm/vbox_windows_xp@clean 109M - 1.07G - # find /dev/zvol /dev/zvol /dev/zvol/local /dev/zvol/local/vm /dev/zvol/local/vm/vbox_pcbsd_10 /dev/zvol/local/vm/vbox_windows_7 /dev/zvol/local/vm/vbox_windows_7@clean /dev/zvol/local/vm/vbox_windows_xp /dev/zvol/local/vm/vbox_windows_xp@clean /dev/zvol/local/vm/vbox_pcbsd_10p1 /dev/zvol/local/vm/vbox_pcbsd_10p2 /dev/zvol/local/vm/vbox_windows_7@cleans1 /dev/zvol/local/vm/vbox_windows_xps1 /dev/zvol/local/vm/vbox_windows_xp@cleans1 ... the missing clone: /dev/zvol/local/vm/vbox_windows_7_personal Regards, vermaden From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 08:12:41 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C4A5768; Sat, 23 Nov 2013 08:12:41 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 191DF2B63; Sat, 23 Nov 2013 08:12:40 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rAN8CRDk093079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Nov 2013 12:12:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rAN8CRk0093078; Sat, 23 Nov 2013 12:12:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 23 Nov 2013 12:12:27 +0400 From: Gleb Smirnoff To: Andrey Chernov Subject: Re: ipfw build error with WITHOUT_PF (pfvar.h) Message-ID: <20131123081227.GD90895@glebius.int.ru> References: <52906247.4030504@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52906247.4030504@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 08:12:41 -0000 Andrey, On Sat, Nov 23, 2013 at 12:07:35PM +0400, Andrey Chernov wrote: A> There is a problem in recent -current to build ipfw with WITHOUT_PF A> option, introduced in r257215. altq.c file produce error due to included A> have following includes A> A> #include A> #include A> #include A> A> and netpfil/pf directory is empty in A> /usr/src/include/Makefile with WITHOUT_PF option. The quick solution would be to make ipfw lose some functionality if PF is cut away from system. The proper solution would be to make ALTQ configurable w/o pfctl. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 08:15:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D796888 for ; Sat, 23 Nov 2013 08:15:28 +0000 (UTC) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE3582B87 for ; Sat, 23 Nov 2013 08:15:27 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id n7so1580586lam.35 for ; Sat, 23 Nov 2013 00:15:20 -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:content-type:content-transfer-encoding; bh=2byKGMcRdMo56Q65N8uOX5I2K7x5jG7WHlbW5z00CKc=; b=gTusZyHQ6OdHbjnVZ54YSoAtCzqqFd8nOMpjFYHePZ/EeLI97BuZ97w5gXVC3Vxk+X 1cUXiwzB1ckxtbVj75Fj18T8lPpB1PeUhG/VOOW9+j8ZhX0L5qin84XdzggFdivoYC4r D9UckJk95NcEVU9VbluRp3h9jS5r9KTxdxpDJeWi7s6i11UlBYjI7xhvAtMew4CkFf+n fk/DXwYwXRR9EmxXqM4dSjZ+Mtsck3iQJEgVX1MHy43n4L5uRiKXZ6vbitiZdK8htEmu E9MWy/rtsd36T5teF1P42CCp2POmZWL6f7Y8gni+c+rRS2KzexCkGl0IjrKz7BbUn77X ErNw== X-Gm-Message-State: ALoCoQlbGFmR4BawkgeQdCPb7uitqOUZMDBDkqYp6xx64kztRCN3h/8fdBuUBtbAPbVmYWGzlJbb X-Received: by 10.112.200.100 with SMTP id jr4mr87253lbc.36.1385194056289; Sat, 23 Nov 2013 00:07:36 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id h11sm3632412lbg.8.2013.11.23.00.07.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 00:07:35 -0800 (PST) Message-ID: <52906247.4030504@freebsd.org> Date: Sat, 23 Nov 2013 12:07:35 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: current@FreeBSD.org Subject: ipfw build error with WITHOUT_PF (pfvar.h) X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: glebius@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 08:15:28 -0000 Hi. There is a problem in recent -current to build ipfw with WITHOUT_PF option, introduced in r257215. altq.c file produce error due to included have following includes #include #include #include and netpfil/pf directory is empty in /usr/src/include/Makefile with WITHOUT_PF option. From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 08:20:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26B91A18 for ; Sat, 23 Nov 2013 08:20:52 +0000 (UTC) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A64132BD2 for ; Sat, 23 Nov 2013 08:20:51 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id er20so1567518lab.22 for ; Sat, 23 Nov 2013 00:20:40 -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 :content-transfer-encoding; bh=b4Ic84DRZ/aA0XIqkrMbiPlAm7i+tGHn3Z114i1fDYM=; b=KLQs7PvXCLIdQF3MrPmWfog1nz/ITukqI+8M10dh1AjsFHnN75tQDxyt69c5FdY7M4 UkHkh2qRUByb0CjM6DWttasMwYLIHDjloj8Tf2b9U4z12MCtxhjVx2FFgoKIZaMFVPFu tSS6d6N1niowMRaM5LH+/qGmpg1EC/Zy9E8GWx8jsrdsvxFM4qxXNf+k0xyNFAVdSBM1 uNG7EyrWTvvPoJtWSmMsH7OQOzeWXkaogi/lcUVxZ7fHy3X/N1cE24pAXX1qSN6zzE8A SFwrJ3lXV4BJLIGnHSFITDYDd3+IMp4HWRVQ2B10etDGFXs4m7Us/qjeLLUIQt2Xe63y 2Evg== X-Gm-Message-State: ALoCoQlceKi05lj3cfErnZ+E/WKFBrAf7gS2pIBix9AI2Kk1nmdXvLzXhhEwuOcGNU/V1kXJPlSS X-Received: by 10.152.26.131 with SMTP id l3mr175619lag.29.1385194840265; Sat, 23 Nov 2013 00:20:40 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id sd11sm31397649lab.2.2013.11.23.00.20.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 00:20:39 -0800 (PST) Message-ID: <52906558.2010604@freebsd.org> Date: Sat, 23 Nov 2013 12:20:40 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: ipfw build error with WITHOUT_PF (pfvar.h) References: <52906247.4030504@freebsd.org> <20131123081227.GD90895@glebius.int.ru> In-Reply-To: <20131123081227.GD90895@glebius.int.ru> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 08:20:52 -0000 On 23.11.2013 12:12, Gleb Smirnoff wrote: > Andrey, > > On Sat, Nov 23, 2013 at 12:07:35PM +0400, Andrey Chernov wrote: > A> There is a problem in recent -current to build ipfw with WITHOUT_PF > A> option, introduced in r257215. altq.c file produce error due to included > A> have following includes > A> > A> #include > A> #include > A> #include > A> > A> and netpfil/pf directory is empty in > A> /usr/src/include/Makefile with WITHOUT_PF option. > > The quick solution would be to make ipfw lose some functionality if > PF is cut away from system. > > The proper solution would be to make ALTQ configurable w/o pfctl. > How it was handled previously? F.e. ipfw in -stable 9 builds normally with WITHOUT_PF and have pfvar.h included too, but old pfvar.h have only which is available with WITHOUT_PF. By a first glance, alternative altq.c file with the same functions declared, but does nothing will be solution, replacing original when MK_PF is no. From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 08:30:05 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3379AC13; Sat, 23 Nov 2013 08:30:05 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B54702C46; Sat, 23 Nov 2013 08:30:04 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rAN8U2XQ093163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Nov 2013 12:30:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rAN8U2bo093162; Sat, 23 Nov 2013 12:30:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 23 Nov 2013 12:30:02 +0400 From: Gleb Smirnoff To: Andrey Chernov Subject: Re: ipfw build error with WITHOUT_PF (pfvar.h) Message-ID: <20131123083002.GF90895@glebius.int.ru> References: <52906247.4030504@freebsd.org> <20131123081227.GD90895@glebius.int.ru> <52906558.2010604@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52906558.2010604@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 08:30:05 -0000 On Sat, Nov 23, 2013 at 12:20:40PM +0400, Andrey Chernov wrote: A> > On Sat, Nov 23, 2013 at 12:07:35PM +0400, Andrey Chernov wrote: A> > A> There is a problem in recent -current to build ipfw with WITHOUT_PF A> > A> option, introduced in r257215. altq.c file produce error due to included A> > A> have following includes A> > A> A> > A> #include A> > A> #include A> > A> #include A> > A> A> > A> and netpfil/pf directory is empty in A> > A> /usr/src/include/Makefile with WITHOUT_PF option. A> > A> > The quick solution would be to make ipfw lose some functionality if A> > PF is cut away from system. A> > A> > The proper solution would be to make ALTQ configurable w/o pfctl. A> > A> A> How it was handled previously? F.e. ipfw in -stable 9 builds normally A> with WITHOUT_PF and have pfvar.h included too, but old pfvar.h have only A> which is available with WITHOUT_PF. In 11 we are splitting the includes, but this isn't actually the cause of problem. This is unrelated. The cause is that in stable/9 header installation ignores WITHOUT_PF and installs headers always. Userland programs (except core pf utilities) are also compiled with pf support. So, in 11 WITHOUT_PF is more clean, but as you found, some consequences arise. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 09:43:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51B4C6B1; Sat, 23 Nov 2013 09:43:15 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C02E2F1E; Sat, 23 Nov 2013 09:43:15 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Vk9k8-0000ks-6x; Sat, 23 Nov 2013 09:43:13 +0000 From: Mark Robert Vaughan Murray Content-Type: multipart/signed; boundary="Apple-Mail=_3E396EFD-0597-4C31-BFEA-2FD250B7A1EE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sat, 23 Nov 2013 09:43:05 +0000 Subject: Anyone else seeing uma_zalloc_arg panics? To: FreeBSD CURRENT Message-Id: <6527E3D8-55D8-45B9-80F1-3AC83250F02A@FreeBSD.org> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-SA-Score: -1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 09:43:15 -0000 --Apple-Mail=_3E396EFD-0597-4C31-BFEA-2FD250B7A1EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi * Anyone else seeing panics like this? This is CURRENT, amd64, 2 CPUs, source synced on Thursday 21st Nov = evening GMT sometime. +panic: uma_zalloc_arg: Returning an empty bucket. +cpuid =3D 1 +KDB: stack backtrace: +db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe003c7dd820 +kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe003c7dd8d0 +vpanic() at vpanic+0x126/frame 0xfffffe003c7dd910 +kassert_panic() at kassert_panic+0x136/frame 0xfffffe003c7dd980 +uma_zalloc_arg() at uma_zalloc_arg+0x49a/frame 0xfffffe003c7dd9f0 +bucket_alloc() at bucket_alloc+0x8b/frame 0xfffffe003c7dda10 +uma_zfree_arg() at uma_zfree_arg+0x2a1/frame 0xfffffe003c7dda70 +bucket_cache_drain() at bucket_cache_drain+0x1b/frame = 0xfffffe003c7ddaa0 +zone_drain_wait() at zone_drain_wait+0xd1/frame 0xfffffe003c7ddb00 +uma_reclaim() at uma_reclaim+0x42d/frame 0xfffffe003c7ddb30 +vm_pageout() at vm_pageout+0x3bc/frame 0xfffffe003c7ddbb0 +fork_exit() at fork_exit+0x84/frame 0xfffffe003c7ddbf0 +fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe003c7ddbf0 +--- trap 0, rip =3D 0, rsp =3D 0xfffffe003c7ddcb0, rbp =3D 0 --- +KDB: enter: panic M --=20 Mark R V Murray --Apple-Mail=_3E396EFD-0597-4C31-BFEA-2FD250B7A1EE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUpB4rt58vKOKE6LNAQoS9QP/XxKyUavWzrqcBz8FHhdyTxVZOkqXelIP gfNEQpuPN8nrERhPBKkaFdR2hcHRm3kE0EaasPQZkpSY/6cPXeBM00/Rl93QUiUg fDR2WGV91VzV3awYwimwIwNv3Dv8z7HzXqu0Euk+Y7i5zXW8cYlLq1p5lc8kIKts gKav3dF/cGs= =1I9u -----END PGP SIGNATURE----- --Apple-Mail=_3E396EFD-0597-4C31-BFEA-2FD250B7A1EE-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 10:25:01 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19768FA9; Sat, 23 Nov 2013 10:25:01 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1E7E20C6; Sat, 23 Nov 2013 10:25:00 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rANAOiVS023613; Sat, 23 Nov 2013 02:24:48 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311231024.rANAOiVS023613@gw.catspoiler.org> Date: Sat, 23 Nov 2013 02:24:44 -0800 (PST) From: Don Lewis Subject: Re: Anyone else seeing uma_zalloc_arg panics? To: markm@FreeBSD.org In-Reply-To: <6527E3D8-55D8-45B9-80F1-3AC83250F02A@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 10:25:01 -0000 On 23 Nov, Mark Robert Vaughan Murray wrote: > Hi * > > Anyone else seeing panics like this? > > This is CURRENT, amd64, 2 CPUs, source synced on Thursday 21st Nov evening GMT sometime. > > +panic: uma_zalloc_arg: Returning an empty bucket. > +cpuid = 1 > +KDB: stack backtrace: > +db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe003c7dd820 > +kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe003c7dd8d0 > +vpanic() at vpanic+0x126/frame 0xfffffe003c7dd910 > +kassert_panic() at kassert_panic+0x136/frame 0xfffffe003c7dd980 > +uma_zalloc_arg() at uma_zalloc_arg+0x49a/frame 0xfffffe003c7dd9f0 > +bucket_alloc() at bucket_alloc+0x8b/frame 0xfffffe003c7dda10 > +uma_zfree_arg() at uma_zfree_arg+0x2a1/frame 0xfffffe003c7dda70 > +bucket_cache_drain() at bucket_cache_drain+0x1b/frame 0xfffffe003c7ddaa0 > +zone_drain_wait() at zone_drain_wait+0xd1/frame 0xfffffe003c7ddb00 > +uma_reclaim() at uma_reclaim+0x42d/frame 0xfffffe003c7ddb30 > +vm_pageout() at vm_pageout+0x3bc/frame 0xfffffe003c7ddbb0 > +fork_exit() at fork_exit+0x84/frame 0xfffffe003c7ddbf0 > +fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe003c7ddbf0 > +--- trap 0, rip = 0, rsp = 0xfffffe003c7ddcb0, rbp = 0 --- > +KDB: enter: panic > > M Yes, I got one of these a couple days ago: Just curious ... are you running i386 or amd64? My test machine is i386, but I suspect that most people running head are running amd64. From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 10:31:33 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50B24545; Sat, 23 Nov 2013 10:31:33 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19A09212C; Sat, 23 Nov 2013 10:31:33 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VkAUs-0000qC-7v; Sat, 23 Nov 2013 10:31:31 +0000 Subject: Re: Anyone else seeing uma_zalloc_arg panics? Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5E29773C-0891-4F7A-9F91-B667E4D72FA2"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <201311231024.rANAOiVS023613@gw.catspoiler.org> Date: Sat, 23 Nov 2013 10:31:24 +0000 Message-Id: References: <201311231024.rANAOiVS023613@gw.catspoiler.org> To: Don Lewis X-Mailer: Apple Mail (2.1822) X-SA-Score: -1.0 Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 10:31:33 -0000 --Apple-Mail=_5E29773C-0891-4F7A-9F91-B667E4D72FA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Nov 2013, at 10:24, Don Lewis wrote: > On 23 Nov, Mark Robert Vaughan Murray wrote: >> Hi * >>=20 >> Anyone else seeing panics like this? >>=20 >> This is CURRENT, amd64, 2 CPUs, source synced on Thursday 21st Nov = evening GMT sometime. >>=20 >> +panic: uma_zalloc_arg: Returning an empty bucket. >> +cpuid =3D 1 >> +KDB: stack backtrace: >> +db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe003c7dd820 >> +kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe003c7dd8d0 >> +vpanic() at vpanic+0x126/frame 0xfffffe003c7dd910 >> +kassert_panic() at kassert_panic+0x136/frame 0xfffffe003c7dd980 >> +uma_zalloc_arg() at uma_zalloc_arg+0x49a/frame 0xfffffe003c7dd9f0 >> +bucket_alloc() at bucket_alloc+0x8b/frame 0xfffffe003c7dda10 >> +uma_zfree_arg() at uma_zfree_arg+0x2a1/frame 0xfffffe003c7dda70 >> +bucket_cache_drain() at bucket_cache_drain+0x1b/frame = 0xfffffe003c7ddaa0 >> +zone_drain_wait() at zone_drain_wait+0xd1/frame 0xfffffe003c7ddb00 >> +uma_reclaim() at uma_reclaim+0x42d/frame 0xfffffe003c7ddb30 >> +vm_pageout() at vm_pageout+0x3bc/frame 0xfffffe003c7ddbb0 >> +fork_exit() at fork_exit+0x84/frame 0xfffffe003c7ddbf0 >> +fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe003c7ddbf0 >> +--- trap 0, rip =3D 0, rsp =3D 0xfffffe003c7ddcb0, rbp =3D 0 --- >> +KDB: enter: panic >>=20 >> M >=20 > Yes, I got one of these a couple days ago: > >=20 > Just curious ... are you running i386 or amd64? My test machine is > i386, but I suspect that most people running head are running amd64. Er, amd64, as I said ;-) M --=20 Mark R V Murray --Apple-Mail=_5E29773C-0891-4F7A-9F91-B667E4D72FA2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUpCEAN58vKOKE6LNAQr4hgP+KgUabjNfPhdgJgpYIrD1q0uS2nU33LJN WrfeyRizY/wBmhrNHKzvvCJLwZJtq5a1b0bxt/chvc3lqYdlu1eJz+Xpfj/mKeoP dsrgXqVMdyMiPaPQv25hSi8NctZHnPtSlbu1ijXvZqOLpP5Wq46VLKPljgVUUvwr w8XRH3J6f18= =bKKE -----END PGP SIGNATURE----- --Apple-Mail=_5E29773C-0891-4F7A-9F91-B667E4D72FA2-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 23 12:48:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FAC550A for ; Sat, 23 Nov 2013 12:48:31 +0000 (UTC) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35C6B2694 for ; Sat, 23 Nov 2013 12:48:31 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id a11so1899552qen.5 for ; Sat, 23 Nov 2013 04:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=iVbb4KaHAJuxWCP/eK15BkFbuYkWhUKhTELF05cTQ7E=; b=KvX7ouidGA6KHXr0m8Z3RuuS7hTB077+SytffzEPtQPnnYe4mXylsSK2oEw9dr9k3C IibvKIzTcbFbSBFEknwKv5Apv6OFwjK3SMac1cXGuH/Twz9Edgl9Wvyi5PCes/fFGpBo 6+HfXEQBD1FR6V5gfQb2eUHb5Zp3ENql+u5tr1QU5oYzVaVgYaGPA8FHD7ic/Kyqr1pM 4yxbTmDxeJalKXRDxRnd3H+G78UVtql8IlqNduy7F/tcW6Fbgrhqz28HsR8d1UPs3q1K tDjdCp32FzyUHol5eryZKaPDJDd82cZx1TnI3IsRJK/w7dXDXAcuaNfoMGBI/L/m56NI MZZA== X-Received: by 10.49.118.40 with SMTP id kj8mr29883099qeb.73.1385210910339; Sat, 23 Nov 2013 04:48:30 -0800 (PST) Received: from lumiwa.farms.net (pool-70-105-224-61.port.east.myfairpoint.net. [70.105.224.61]) by mx.google.com with ESMTPSA id h2sm55698227qaf.10.2013.11.23.04.48.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Nov 2013 04:48:29 -0800 (PST) From: Ajtim To: freebsd-current@freebsd.org Subject: problems Date: Sat, 23 Nov 2013 07:48:28 -0500 Message-ID: <7076908.jUUDNzHvnc@lumiwa.farms.net> User-Agent: KMail/4.11.3 (FreeBSD/10.0-BETA3; KDE/4.11.3; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 12:48:31 -0000 Hi! I tried to build some programs on FreeBSD 10.0-BETA3 and as they told me there is not a problem to build on FreeBSD 9.2 for example (amd64) but on my system doesn't work: math/sage k3b-kde4 multimedia/vlc audio/last.fm There are more but the above four I like to have. What is your experience, please? Thank you. -- Mitja ------- http://www.redbubble.com/people.lumiwa