From owner-freebsd-stable@FreeBSD.ORG Sun Feb 15 01:57:59 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CC93480 for ; Sun, 15 Feb 2015 01:57:59 +0000 (UTC) Received: from mail.uugrn.org (mail.uugrn.org [IPv6:2a03:2500:1:6:b::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E38741E5 for ; Sun, 15 Feb 2015 01:57:58 +0000 (UTC) Received: from rabe.uugrn.org (root@rabe.uugrn.lan [10.253.1.25]) by mail.uugrn.org (8.14.5/8.14.5) with ESMTP id t1F1vjTZ049761 for ; Sun, 15 Feb 2015 02:57:55 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from rabox.fritz.box (rabe@rabe.uugrn.lan [10.253.1.25]) by rabe.uugrn.org (8.14.5/8.14.5) with ESMTP id t1F1vjgo049757 for ; Sun, 15 Feb 2015 02:57:45 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from rabox.fritz.box (localhost [127.0.0.1]) by rabox.fritz.box (8.14.4/8.14.4/Debian-7) with ESMTP id t1F1viEc001737 for ; Sun, 15 Feb 2015 02:57:44 +0100 Received: (from rabe@localhost) by rabox.fritz.box (8.14.4/8.14.4/Submit) id t1F1vhKK001735 for freebsd-stable@freebsd.org; Sun, 15 Feb 2015 02:57:43 +0100 X-Authentication-Warning: rabox.fritz.box: rabe set sender to rabe@uugrn.org using -f Date: Sun, 15 Feb 2015 02:57:43 +0100 From: Raphael Eiselstein To: freebsd-stable@freebsd.org Subject: Re: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default Message-ID: <20150215015743.GB31170@lan.sigsys.de> References: <20150208113656.GE3395@lan.sigsys.de> <20150208123531.GA15549@vps.markoturk.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: <20150208123531.GA15549@vps.markoturk.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 01:57:59 -0000 --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 08, 2015 at 01:35:31PM +0100, Marko Turk wrote: > > As I wanted to move zroot/usr/home to zroot/home I noticed that > > everything from /usr and /var is in the "/" mount (zroot/ROOT/default) > >=20 > > The "mountpoint" property of zroot/var and zroot/usr seems correct but > > in fact it is not mounted there. > >=20 > > See http://sigsys.de/files/freebsd_101_zfs_root_fail_screenshot.jpg > > (sorry, had no networking at this moment, so just a regular screenshot) > what is the output of > zfs get canmount zroot/usr root@srv01:~ # zfs get mountpoint,canmount zroot/usr NAME PROPERTY VALUE SOURCE zroot/usr mountpoint /usr local zroot/usr canmount off local Yes, it has a mountpoint but is not mounted there. It's just to get mountpoint inherited to lets say zroot/usr/ports As we found out this is an (mostly undocumented) feature, not a bug. Regards Raphael --=20 Raphael Eiselstein =20 PGP 4E63 5307 6F6A 036D 518D 3C4F 75EE EA14 F625 DB4E =2E........|.........|.........|.........|.........|.........|.........|.. --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU3/0XAAoJEHXu6hT2JdtOX94P/1ws1q5NvIxk6gQz9RQBcIqH 9vxHgHWLuTdbewPdZWNJ855rRY70dQOGGGxYdKcBuFj+4rSvfbUVo+VUpEzEn92y n7xCWmbs37NX+thl2X/hPWjuydGTin1QIObs1hPygUhlRudbi4KNUWvc+jZIkw3M J8xO3Lt/g+bmMb/TGTgd8eAvFgc6VqOwPlMx3NWb42agBYYbhJlkiZYSRbtBUk7B SwHPr+rma0FFTmJOLGpfUTYu+dO4wjQml9iswqUvCpjTwCcJgsbVbX306yt5PPqK ts+PDvPTKNaQDkHkDHIQS9xpbYfsBXI2eJnjbh5FX5M6PAifplesMDaZrP9v4Swd POQqBHCI43WWr969q6yngWGIEZSktvBmw1zGNb8Yi9nE+/r4Eg6Hk5aA0IoidY1O M92gITn8AnpMU28l+bsBF8ktUL+/X8tyFGrsKyn4dIvKS5Hxjia1xcpiiC3rMRFG 7YYsh2D7r0za9jUqDgeMZwXBSoFA68X3dWUatqk6VlV59MhTybjhmjOedGduxtkZ hJPhdR8eCg3OviDwLsKK+Jq5nL0wyP4bX6G+fJym8p1/gCUwuT+gk3z8XCuq6Y/T FxROXZXW82DsrlYLpdz/5lF5izR6wTOcgSABmxdHho1ntTSp5rVuNIfR2Fsx0aGZ ytaEyfjDSa2rXddbORCl =HDyQ -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 15 03:42:22 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F990AEF; Sun, 15 Feb 2015 03:42:22 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id F0B6FFD0; Sun, 15 Feb 2015 03:42:21 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 420C4887; Sun, 15 Feb 2015 03:42:19 +0000 (UTC) Date: Sun, 15 Feb 2015 03:42:02 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, luigi@FreeBSD.org, dim@FreeBSD.org, loos@FreeBSD.org, hrs@FreeBSD.org Message-ID: <1676106513.0.1423971737290.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <625594216.61.1423954959749.JavaMail.jenkins@jenkins-9.freebsd.org> References: <625594216.61.1423954959749.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #1214 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 03:42:22 -0000 See From owner-freebsd-stable@FreeBSD.ORG Mon Feb 16 00:30:51 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70456FCC for ; Mon, 16 Feb 2015 00:30:51 +0000 (UTC) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id 35A82CDE for ; Mon, 16 Feb 2015 00:30:50 +0000 (UTC) Received: from [192.168.5.21] (5418287B.cm-5-1a.dynamic.ziggo.nl [84.24.40.123]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id 826461E8C1F for ; Mon, 16 Feb 2015 00:23:40 +0000 (UTC) Message-ID: <54E1388C.3060602@searchy.net> Date: Mon, 16 Feb 2015 01:23:40 +0100 From: "Frank de Bot (lists)" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: ZFS L2arc 16.0E size Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 00:30:51 -0000 Hello, I have a FreeBSD 10.1 system with a raidz2 zfs configuration with 2ssd's for l2arc . It is running '10.1-STABLE FreeBSD 10.1-STABLE #0 r278805' Currently I'm running tests before it can go to production, but I have the following issue. After a while the l2arc devices indicate 16.0E free space and it starts 'consuming' more than it can hold cache - - - - - - gpt/l2arc1 107G 16.0E 0 2 0 92.7K gpt/l2arc2 68.3G 16.0E 0 1 0 60.8K It ran good for a while, where data was removed from cache so it could be filled with newer data. (Free space was always around 200/300Mbytes). I've read about similar issues, which should be fixed in different commits, but I'm running the latest stable 10.1 kernel right now. (One of the last similar issue is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197164 ) Another similar issue reported at FreeNAS https://bugs.freenas.org/issues/5347 suggested it would be a hardware issue, but I have 2 servers which experience the same problem. One has a Crucial M500 drive and the other a M550. Both have a 64G partition voor l2arc. What is really going on here? Regards, Frank de Bot From owner-freebsd-stable@FreeBSD.ORG Mon Feb 16 00:52:34 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62BC0442 for ; Mon, 16 Feb 2015 00:52:34 +0000 (UTC) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB04FEAF for ; Mon, 16 Feb 2015 00:52:33 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id l18so23496117wgh.7 for ; Sun, 15 Feb 2015 16:52:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WZmbhOYTux7FSLVsYS3MSCZ/DYVqNvBlmAT+5hrlhhY=; b=jn0Ua/AsBSaCwrDDTHAKU5NUzYhtzWXgmWkCNE10O/18ZBvEZLfJEUM0bSfEwTlTPn 9LQzz5JOMSJqCRQECEiS8W7isvB9Z0LfHJf7qormnf3UonysUZxswLmblftv7hkN+jQG NBHGFhjyx1tKKY+1pGC34wTrRao4SJsGWW1Z2pRGxqqVQ4YedA46yyLMaDSfkZvVCFUb n6jNU5m5spbwftm1ikNRAIaSdBBxzcnam5jNNTA65mQ1RG5C+YP47vQVvBVQrSCup4g7 llnDoWXkbnZk6QCchZJ8LdxQYBD0boBqzAu4ZTI45eS22oPW67tNE0PXv/3h5v/+55su 0xVA== X-Gm-Message-State: ALoCoQlA0xWnN1VMxDQg2IKe/SqiuVdExsGSrcY8nSQwqsz0rrArn/z3LTHx33Fk8pN0E+zlDHbe X-Received: by 10.194.77.133 with SMTP id s5mr45400965wjw.71.1424047945091; Sun, 15 Feb 2015 16:52:25 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id hg7sm20376623wjb.44.2015.02.15.16.52.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Feb 2015 16:52:24 -0800 (PST) Message-ID: <54E13F41.7000703@multiplay.co.uk> Date: Mon, 16 Feb 2015 00:52:17 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ZFS L2arc 16.0E size References: <54E1388C.3060602@searchy.net> In-Reply-To: <54E1388C.3060602@searchy.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 00:52:34 -0000 IIRC this was fixed by r273060, if your remove your cache device and then add it back I think you should be good. On 16/02/2015 00:23, Frank de Bot (lists) wrote: > Hello, > > I have a FreeBSD 10.1 system with a raidz2 zfs configuration with 2ssd's > for l2arc . It is running '10.1-STABLE FreeBSD 10.1-STABLE #0 r278805' > Currently I'm running tests before it can go to production, but I have > the following issue. After a while the l2arc devices indicate 16.0E free > space and it starts 'consuming' more than it can hold > > cache - - - - - - > gpt/l2arc1 107G 16.0E 0 2 0 92.7K > gpt/l2arc2 68.3G 16.0E 0 1 0 60.8K > > It ran good for a while, where data was removed from cache so it could > be filled with newer data. (Free space was always around 200/300Mbytes). > > I've read about similar issues, which should be fixed in different > commits, but I'm running the latest stable 10.1 kernel right now. (One > of the last similar issue is: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197164 ) > Another similar issue reported at FreeNAS > https://bugs.freenas.org/issues/5347 suggested it would be a hardware > issue, but I have 2 servers which experience the same problem. One has a > Crucial M500 drive and the other a M550. Both have a 64G partition voor > l2arc. > > What is really going on here? > > > Regards, > > > Frank de Bot > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Feb 16 04:18:56 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64860634 for ; Mon, 16 Feb 2015 04:18:56 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E52F9652 for ; Mon, 16 Feb 2015 04:18:55 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id l15so22766806wiw.3 for ; Sun, 15 Feb 2015 20:18:54 -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=2c8Nko7bBew0pbRjeCjfX/zETww7TjfJgP3pLQl6XaE=; b=qsGIgkM3Z2FCRUkuFmp9F1puuv7eIJqrXX0ls6qD3aWZjHMhe4YxeCL5tMzeOtlRgx l3RMc5Z+wATnQzMvyDIbi0brQ6G6vO/82LUeBk/+NAOslFOKokCyPjSvdALpqTpVURot rhb6B+mHW3A5vX25EcTxpcCeS3c6ybLhzfRRyckF+l6pBaZDY5Kl3Z7cWg23U3umtS23 9kl9NEPYhVgePH4YTF1EhJdH9dTOu5ZfifO4DdxdrBskyMpDM1duRAwqHctdeeZg0j0Y T36q2sLtkW1sFGQPRqtl4k7VuU3TwZW00yT6UsMlsUbPLyBMiHDNVkKI17IfdA9wcrZj oKBg== MIME-Version: 1.0 X-Received: by 10.194.172.35 with SMTP id az3mr46679308wjc.43.1424060334337; Sun, 15 Feb 2015 20:18:54 -0800 (PST) Received: by 10.216.234.74 with HTTP; Sun, 15 Feb 2015 20:18:54 -0800 (PST) In-Reply-To: <20150216035636.GA80472@neutralgood.org> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212043321.GD840@rancor.immure.com> <20150212052058.GB77578@neutralgood.org> <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> <20150213035002.GA68549@neutralgood.org> <20150216035636.GA80472@neutralgood.org> Date: Sun, 15 Feb 2015 23:18:54 -0500 Message-ID: Subject: Re: top, fixed buffer length in utils.c From: Brandon Allbery To: kpneal@pobox.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 04:18:56 -0000 On Sun, Feb 15, 2015 at 10:56 PM, wrote: > There > will _never_ be a compiler of anything resembling popularity for any > established FreeBSD host that has int as anything other than 32 bits in > size. > This is optimistic beyond sanity, based on history. I was making a point as well.... Really. People claimed this in the 16-bit days, because the idea of something using 32 bits was obviously going to break things and be too difficult to cope with. So where are we now? There will be 64-bit CPUs, as opposed to 32-bit CPUs with 64-bit extensions, in the future. Be certain of this. (Heck, there's already been one, albeit not popular: DEC Alpha.) And eventually (unlike the Alpha) the native word size will be used as the default word size because people --- specifically, developers --- will want that. Which means (int) will change. The only constant in the world is change. You can choose to change with it, or to pretend that it doesn't/didn't happen. The latter just means you'll be left in the dust wondering why the world isn't paying any attention to you any more. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Mon Feb 16 08:58:26 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 233FBEC7 for ; Mon, 16 Feb 2015 08:58:26 +0000 (UTC) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id DBD89682 for ; Mon, 16 Feb 2015 08:58:25 +0000 (UTC) Received: from [10.134.3.102] (unknown [213.197.27.22]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id EF5451E8C1F for ; Mon, 16 Feb 2015 08:58:22 +0000 (UTC) Message-ID: <54E1B12E.9070809@searchy.net> Date: Mon, 16 Feb 2015 09:58:22 +0100 From: Frank de Bot User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ZFS L2arc 16.0E size References: <54E1388C.3060602@searchy.net> <54E13F41.7000703@multiplay.co.uk> In-Reply-To: <54E13F41.7000703@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 08:58:26 -0000 I did remove and added devices again, with: 'zpool remove tank gpt/l2arc1 gpt/l2arc2' and then 'zpool add tank cache gpt/l2arc1 gpt/l2arc2' I left it running overnight and the same situation occured. cache - - - - - - gpt/l2arc1 175G 16.0E 11 106 55.5K 9.75M gpt/l2arc2 167G 16.0E 14 107 68.8K 9.81M For faster filling of the l2arc I also had 2 systcl's set: vfs.zfs.l2arc_write_max: 33554432 vfs.zfs.l2arc_write_boost: 33554432 I do not plan to use this for production, only in testing. Regards, Frank de Bot Steven Hartland wrote: > IIRC this was fixed by r273060, if your remove your cache device and > then add it back I think you should be good. > > On 16/02/2015 00:23, Frank de Bot (lists) wrote: >> Hello, >> >> I have a FreeBSD 10.1 system with a raidz2 zfs configuration with 2ssd's >> for l2arc . It is running '10.1-STABLE FreeBSD 10.1-STABLE #0 r278805' >> Currently I'm running tests before it can go to production, but I have >> the following issue. After a while the l2arc devices indicate 16.0E free >> space and it starts 'consuming' more than it can hold >> >> cache - - - - - - >> gpt/l2arc1 107G 16.0E 0 2 0 92.7K >> gpt/l2arc2 68.3G 16.0E 0 1 0 60.8K >> >> It ran good for a while, where data was removed from cache so it could >> be filled with newer data. (Free space was always around 200/300Mbytes). >> >> I've read about similar issues, which should be fixed in different >> commits, but I'm running the latest stable 10.1 kernel right now. (One >> of the last similar issue is: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197164 ) >> Another similar issue reported at FreeNAS >> https://bugs.freenas.org/issues/5347 suggested it would be a hardware >> issue, but I have 2 servers which experience the same problem. One has a >> Crucial M500 drive and the other a M550. Both have a 64G partition voor >> l2arc. >> >> What is really going on here? >> >> >> Regards, >> >> >> Frank de Bot >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 16 17:03:24 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5B7F909 for ; Mon, 16 Feb 2015 17:03:24 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C53723D for ; Mon, 16 Feb 2015 17:03:24 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YNP4q-00070i-Ok; Mon, 16 Feb 2015 17:03:20 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YNP4q-0008rH-Jw; Mon, 16 Feb 2015 17:03:20 +0000 To: david@catwhisker.org, petefrench@ingresso.co.uk Subject: Re: Unable to read manpages (even after installing groff) In-Reply-To: <20150214154024.GW1256@albert.catwhisker.org> Message-Id: From: Pete French Date: Mon, 16 Feb 2015 17:03:20 +0000 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 17:03:24 -0000 > Fixed by r278693; ref. > . Aha, thanks. svn update and now all working again... -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 17 09:10:53 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C67C4BAE for ; Tue, 17 Feb 2015 09:10:53 +0000 (UTC) Received: from nmsh4.e.nsc.no (nmsh4.e.nsc.no [193.213.121.75]) by mx1.freebsd.org (Postfix) with ESMTP id 0D28E230 for ; Tue, 17 Feb 2015 09:10:52 +0000 (UTC) Received: from terraplane.org (ti0027a400-0301.bb.online.no [85.164.8.49]) by nmsh4.nsc.no (8.14.7/8.14.7) with ESMTP id t1H8jL0h023362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Feb 2015 09:45:22 +0100 (MET) Received: from terraplane.org (localhost [127.0.0.1]) by terraplane.org (8.14.5/8.14.5) with ESMTP id t1H8ww1d091936 for ; Tue, 17 Feb 2015 09:58:58 +0100 (CET) (envelope-from rumrunner@terraplane.org) Received: (from rumrunner@localhost) by terraplane.org (8.14.5/8.13.8/Submit) id t1H8wwiG091935 for freebsd-stable@freebsd.org; Tue, 17 Feb 2015 09:58:58 +0100 (CET) (envelope-from rumrunner) Date: Tue, 17 Feb 2015 09:58:58 +0100 From: Eivind Evensen To: freebsd-stable@freebsd.org Subject: Cross build error Message-ID: <20150217085857.GA87703@klump.hjerdalen.lokalnett> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 09:10:53 -0000 Hello. Using https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD as a reference, I've tried building for i386 on an amd64 machine. It stops in rescue/rescue with: (cd /home/rumrunner/midlertidig/krysskomp/rescue/rescue/../../usr.sbin/chown && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ chown.o) cc -O2 -pipe -DRESCUE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c /home/rumrunner/midlertidig/krysskomp/usr.sbin/chown/chown.c MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/krysskomp/rescue/rescue make -f rescue.mk exe cc -O2 -pipe -c rescue.c rescue.c:59:2: warning: implicit declaration of function 'crunched_usage' is invalid in C99 [-Wimplicit-function-declaration] crunched_usage(); ^ 1 warning generated. echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >cat_stub.c cc -O2 -pipe -c cat_stub.c cat_stub.c:1:67: warning: implicit declaration of function 'main' is invalid in C99 [-Wimplicit-function-declaration] ...argc, char **argv, char **envp){return main(argc,argv,envp);} ^ 1 warning generated. cc -O2 -pipe -c /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.c ld -dc -r -o cat.lo cat_stub.o /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.o ld: /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.o: No such file: No such file or directory *** Error code 1 Stop. make[5]: stopped in /home/rumrunner/midlertidig/krysskomp/rescue/rescue *** Error code 1 Stop. make[4]: stopped in /home/rumrunner/midlertidig/krysskomp/rescue/rescue *** Error code 1 Stop. make[3]: stopped in /home/rumrunner/midlertidig/krysskomp/rescue *** Error code 1 Stop. make[2]: stopped in /home/rumrunner/midlertidig/krysskomp *** Error code 1 Stop. make[1]: stopped in /home/rumrunner/midlertidig/krysskomp *** Error code 1 Stop. make: stopped in /home/rumrunner/midlertidig/krysskomp make.conf is empty and I don't have a src.conf. I started the build using $ make buildworld TARGET=i386 TARGET_ARCH=i386 \ MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/kryssobj which is how I interpreted the doc. Did I miss anything, or is this a real problem? -- Eivind From owner-freebsd-stable@FreeBSD.ORG Tue Feb 17 11:46:32 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C812C748 for ; Tue, 17 Feb 2015 11:46:32 +0000 (UTC) Received: from ghost.grese.net (ghost.grese.net [IPv6:2a02:2880:3::b]) by mx1.freebsd.org (Postfix) with ESMTP id 892F87DE for ; Tue, 17 Feb 2015 11:46:32 +0000 (UTC) Received: from sugar.optron.lv ([217.28.48.254]:52167 helo=andris) by ghost.grese.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1YNgbk-000MPO-6h for freebsd-stable@freebsd.org; Tue, 17 Feb 2015 13:46:28 +0200 From: "Andris" To: Subject: 10GbE with jumbo networking problems Date: Tue, 17 Feb 2015 13:46:28 +0200 Message-ID: <005501d04aa7$5d78dc20$186a9460$@grese.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBGBOKupWo9TK1ZS02litG5TjhoqA== Content-Language: ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 11:46:32 -0000 Hi, Is there any progress regarding this bug? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183390 hardware and setup is similar to discussed in PR, except instead of NFS = iSCSI (ctl) is used. OS - FreeBSD 10.1-STABLE r278064. WBR, Andris From owner-freebsd-stable@FreeBSD.ORG Tue Feb 17 11:49:39 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A8F694E for ; Tue, 17 Feb 2015 11:49:39 +0000 (UTC) Received: from oslo.ath.cx (oslo.ath.cx [IPv6:2a01:4f8:200:42e4::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oslo.ath.cx", Issuer "oslo.ath.cx" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D62E9810 for ; Tue, 17 Feb 2015 11:49:38 +0000 (UTC) Received: by oslo.ath.cx (OpenSMTPD) with ESMTP id 247d45a6; Tue, 17 Feb 2015 12:49:35 +0100 (CET) Date: Tue, 17 Feb 2015 12:49:35 +0100 From: "Herbert J. Skuhra" To: Eivind Evensen Subject: Re: Cross build error Message-ID: <20150217114935.GA51320@oslo.ath.cx> References: <20150217085857.GA87703@klump.hjerdalen.lokalnett> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150217085857.GA87703@klump.hjerdalen.lokalnett> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 11:49:39 -0000 On Tue, Feb 17, 2015 at 09:58:58AM +0100, Eivind Evensen wrote: > Hello. > > Using https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD > as a reference, I've tried building for i386 on an amd64 machine. > > It stops in rescue/rescue with: > > (cd /home/rumrunner/midlertidig/krysskomp/rescue/rescue/../../usr.sbin/chown && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ chown.o) > cc -O2 -pipe -DRESCUE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c /home/rumrunner/midlertidig/krysskomp/usr.sbin/chown/chown.c > MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/krysskomp/rescue/rescue make -f rescue.mk exe > cc -O2 -pipe -c rescue.c > rescue.c:59:2: warning: implicit declaration of function > 'crunched_usage' is invalid in C99 > [-Wimplicit-function-declaration] > crunched_usage(); > ^ > 1 warning generated. > echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >cat_stub.c > cc -O2 -pipe -c cat_stub.c > cat_stub.c:1:67: warning: implicit declaration of function 'main' is > invalid in C99 [-Wimplicit-function-declaration] > ...argc, char **argv, char **envp){return main(argc,argv,envp);} > ^ > 1 warning generated. > cc -O2 -pipe -c /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.c > ld -dc -r -o cat.lo cat_stub.o /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.o > ld: /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.o: No such file: No such file or directory > *** Error code 1 [...] > make.conf is empty and I don't have a src.conf. I started the build > using > $ make buildworld TARGET=i386 TARGET_ARCH=i386 \ > MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/kryssobj > > > which is how I interpreted the doc. Did I miss anything, or is this a > real problem? Have you tried without MAKEOBJDIRPREFIX? Or: % export MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/kryssobj % make buildworld TARGET=i386 TARGET_ARCH=i386 Have you tried with setting SRCCONF and __MAKE_CONF to /dev/null? What version are you running (uname -a) and what version are you trying to build? -- Herbert From owner-freebsd-stable@FreeBSD.ORG Tue Feb 17 14:10:20 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4606D7F5 for ; Tue, 17 Feb 2015 14:10:20 +0000 (UTC) Received: from nmsh1.e.nsc.no (nmsh1.e.nsc.no [193.213.121.72]) by mx1.freebsd.org (Postfix) with ESMTP id 87F1CA7C for ; Tue, 17 Feb 2015 14:10:18 +0000 (UTC) Received: from terraplane.org (ti0027a400-0301.bb.online.no [85.164.8.49]) by nmsh1.nsc.no (8.14.7/8.14.7) with ESMTP id t1HDQU8X004262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2015 14:26:30 +0100 (MET) Received: from terraplane.org (localhost [127.0.0.1]) by terraplane.org (8.14.5/8.14.5) with ESMTP id t1HDe7ea093056; Tue, 17 Feb 2015 14:40:07 +0100 (CET) (envelope-from rumrunner@terraplane.org) Received: (from rumrunner@localhost) by terraplane.org (8.14.5/8.13.8/Submit) id t1HDe7ZD093055; Tue, 17 Feb 2015 14:40:07 +0100 (CET) (envelope-from rumrunner) Date: Tue, 17 Feb 2015 14:40:07 +0100 From: Eivind Evensen To: "Herbert J. Skuhra" Subject: Re: Cross build error Message-ID: <20150217134007.GB87703@klump.hjerdalen.lokalnett> References: <20150217085857.GA87703@klump.hjerdalen.lokalnett> <20150217114935.GA51320@oslo.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150217114935.GA51320@oslo.ath.cx> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:10:20 -0000 On Tue, Feb 17, 2015 at 12:49:35PM +0100, Herbert J. Skuhra wrote: > On Tue, Feb 17, 2015 at 09:58:58AM +0100, Eivind Evensen wrote: > > Hello. > > > > Using https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD > > as a reference, I've tried building for i386 on an amd64 machine. > > > > It stops in rescue/rescue with: > > > > (cd /home/rumrunner/midlertidig/krysskomp/rescue/rescue/../../usr.sbin/chown && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ chown.o) > > cc -O2 -pipe -DRESCUE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c /home/rumrunner/midlertidig/krysskomp/usr.sbin/chown/chown.c > > MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/krysskomp/rescue/rescue make -f rescue.mk exe > > cc -O2 -pipe -c rescue.c > > rescue.c:59:2: warning: implicit declaration of function > > 'crunched_usage' is invalid in C99 > > [-Wimplicit-function-declaration] > > crunched_usage(); > > ^ > > 1 warning generated. > > echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return main(argc,argv,envp);}" >cat_stub.c > > cc -O2 -pipe -c cat_stub.c > > cat_stub.c:1:67: warning: implicit declaration of function 'main' is > > invalid in C99 [-Wimplicit-function-declaration] > > ...argc, char **argv, char **envp){return main(argc,argv,envp);} > > ^ > > 1 warning generated. > > cc -O2 -pipe -c /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.c > > ld -dc -r -o cat.lo cat_stub.o /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.o > > ld: /home/rumrunner/midlertidig/krysskomp/bin/cat/cat.o: No such file: No such file or directory > > *** Error code 1 > > [...] > > > make.conf is empty and I don't have a src.conf. I started the build > > using > > $ make buildworld TARGET=i386 TARGET_ARCH=i386 \ > > MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/kryssobj > > > > > > which is how I interpreted the doc. Did I miss anything, or is this a > > real problem? > > Have you tried without MAKEOBJDIRPREFIX? Or: > > % export MAKEOBJDIRPREFIX=/home/rumrunner/midlertidig/kryssobj > % make buildworld TARGET=i386 TARGET_ARCH=i386 > > Have you tried with setting SRCCONF and __MAKE_CONF to /dev/null? > > What version are you running (uname -a) and what version are you trying > to build? > Herbert I forgot to mention the version. This is 10.1-stable. Just tried setting MAKEOBJDIRPREFIX in the environment as you suggested and that worked. Thanks -- Eivind From owner-freebsd-stable@FreeBSD.ORG Tue Feb 17 22:39:39 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF09EAC0 for ; Tue, 17 Feb 2015 22:39:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9607EF3A for ; Tue, 17 Feb 2015 22:39:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A3320B91F; Tue, 17 Feb 2015 17:39:37 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: top, fixed buffer length in utils.c Date: Tue, 17 Feb 2015 16:52:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150212163945.36aa9971@B85M-HD3-0.alogt.com> <20150212202245.GE1953@funkthat.com> In-Reply-To: <20150212202245.GE1953@funkthat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201502171652.21779.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Feb 2015 17:39:37 -0500 (EST) Cc: John-Mark Gurney , Erich Dollansky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 22:39:39 -0000 On Thursday, February 12, 2015 3:22:45 pm John-Mark Gurney wrote: > Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 16:39 +0800: > > Hi, > > > > On Wed, 11 Feb 2015 19:39:24 -0800 > > John-Mark Gurney wrote: > > > > > Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 09:13 > > > +0800: > > > > On Tue, 10 Feb 2015 17:14:41 -0600 > > > > Bob Willcox wrote: > > > > > > > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > > > > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 > > > > > > +0800: > > > > > > > > > > > > I guess adding: > > > > > > CTASSERT(sizeof(int) <= 4); > > > > > > > > > Feel free to submit a patch eliminating the size assumption... I'll > > > review and commit it if/when you do... > > > > > did you add > > > > CTASSERT(sizeof(int) <= 4); > > > > already? > > > > This would do as a message will popup when the problem finally arises. > > Similar... > > https://svnweb.freebsd.org/changeset/base/278560 Why not use sizeof(int) to size the array instead of adding the assert if you want it to really be future proof? Each byte will generate at most 3 decimal chars, so char buf[sizeof(int) * 3 + 1]; or some such (yes, this overestimates a bit). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 17 22:39:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC0FFB9F for ; Tue, 17 Feb 2015 22:39:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C46B4F3B for ; Tue, 17 Feb 2015 22:39:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BAB5BB939; Tue, 17 Feb 2015 17:39:43 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: top, fixed buffer length in utils.c Date: Tue, 17 Feb 2015 16:57:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150216035636.GA80472@neutralgood.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201502171657.07538.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Feb 2015 17:39:43 -0500 (EST) Cc: Brandon Allbery , kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 22:39:45 -0000 On Sunday, February 15, 2015 11:18:54 pm Brandon Allbery wrote: > On Sun, Feb 15, 2015 at 10:56 PM, wrote: > > > There > > will _never_ be a compiler of anything resembling popularity for any > > established FreeBSD host that has int as anything other than 32 bits in > > size. > > > > This is optimistic beyond sanity, based on history. I was making a point as > well.... Really. People claimed this in the 16-bit days, because the idea > of something using 32 bits was obviously going to break things and be too > difficult to cope with. So where are we now? > > There will be 64-bit CPUs, as opposed to 32-bit CPUs with 64-bit > extensions, in the future. Be certain of this. (Heck, there's already been > one, albeit not popular: DEC Alpha.) And eventually (unlike the Alpha) the > native word size will be used as the default word size because people --- > specifically, developers --- will want that. Which means (int) will change. > > The only constant in the world is change. You can choose to change with it, > or to pretend that it doesn't/didn't happen. The latter just means you'll > be left in the dust wondering why the world isn't paying any attention to > you any more. I'm not advocating that ints will forever be 64-bits, but I think it will probably be quite a while. If anything, the trend on 64-bit platforms is the opposite due to 64-bits being too wasteful for longs and pointers (see x32 for x86 and mipsn32). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 18 02:18:47 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5381E2D for ; Wed, 18 Feb 2015 02:18:47 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3BEA12 for ; Wed, 18 Feb 2015 02:18:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ALBQDs9eNU/95baINbg1haBIJ/v0YKhSdKAoFhAQEBAQEBfIQMAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIgGCA25AZdwAQEBAQEBBAEBAQEBAQEBARmBIYluhB0BARs0B4JogUIFijqIVYNBgzc4hSCMHSKEDCAxAQaBBDl/AQEB X-IronPort-AV: E=Sophos;i="5.09,595,1418101200"; d="scan'208";a="193204163" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 17 Feb 2015 21:18:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A75DCB3F94; Tue, 17 Feb 2015 21:18:45 -0500 (EST) Date: Tue, 17 Feb 2015 21:18:45 -0500 (EST) From: Rick Macklem To: Andris Message-ID: <518452225.5232520.1424225925671.JavaMail.root@uoguelph.ca> In-Reply-To: <005501d04aa7$5d78dc20$186a9460$@grese.net> Subject: Re: 10GbE with jumbo networking problems MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 02:18:47 -0000 Andris wrote: > Hi, > > Is there any progress regarding this bug? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183390 > > hardware and setup is similar to discussed in PR, except instead of > NFS iSCSI (ctl) is used. > OS - FreeBSD 10.1-STABLE r278064. > Well, the workaround fix mentioned by adrian as the last comment on that bug report should be in 10.1. As such, all that should be happening is that the ix driver does a lot of m_defrag() calls. Overhead, but it should work without "file too big" (EFBIG) errors. If you are seeing EFBIG errors, something else is broken. I believe lagg and vlan were both fixed to pass up the reduced value for if_hw_tsomax that avoids the EFBIG errors. Are you using anything else that might be sitting between TCP and the ix driver? (If tcp_output() doesn't see the reduced size of if_hw_tsomax, then the EFBIG errors will occur.) Also, hselasky@ has committed r271946 that added additional fields to "struct ifnet", so that drivers can specify how many transmit segments they can support for a TSO segment and how big each of these transmit segments (read data mbuf in the chain) can be. Unfortunately, the device driver authors haven't yet filled these in. I recently posted a request for this to freebsd-net@, so hopefully this will start happening soon. Finally, if disabling TSO doesn't make the problem go away, then it is some other issue that I don't believe has been isolated. (One responder in the above bug report does mention that disabling TSO didn't fix the problem, but I don't know why.) rick > WBR, > Andris > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 18 02:22:41 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3FEDF5C for ; Wed, 18 Feb 2015 02:22:41 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 998BCAD3 for ; Wed, 18 Feb 2015 02:22:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ALBQCc9uNU/95baINbg1haBIJ/v0YKhSdKAoFhAQEBAQEBfIQMAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIgGCA25AZdwAQEBAQEBAQECAQEBAQEBAQEBAQEXgSGJboQdAQEbNAeCaIFCBYo6iFWDQYM3OI1/gz4ihAwgMQEGgQQ5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,595,1418101200"; d="scan'208";a="191491249" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 17 Feb 2015 21:22:35 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EB4D9B3F21; Tue, 17 Feb 2015 21:22:34 -0500 (EST) Date: Tue, 17 Feb 2015 21:22:34 -0500 (EST) From: Rick Macklem To: Andris Message-ID: <2038489979.5233865.1424226154952.JavaMail.root@uoguelph.ca> In-Reply-To: <005501d04aa7$5d78dc20$186a9460$@grese.net> Subject: Re: 10GbE with jumbo networking problems MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 02:22:41 -0000 Andris wrote: > Hi, > > Is there any progress regarding this bug? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183390 > > hardware and setup is similar to discussed in PR, except instead of > NFS iSCSI (ctl) is used. > OS - FreeBSD 10.1-STABLE r278064. > Oh, I just noticed you mention "jumbo" in your subject line. The above bug report is an issue related to TSO segments. I have no idea if there is a separate problem w.r.t. the driver handling jumbo packets. (I believe that all using a jumbo packet would imply is that the TSO segment would be broken into fewer mtu sized packets by the hardware, so enabling jumbo packets shouldn't affect this.) rick > WBR, > Andris > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 18 06:26:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D37E1DD; Wed, 18 Feb 2015 06:26:21 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0363C35B; Wed, 18 Feb 2015 06:26:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Ehjn0bytsZqna+nMezNb9oSvdGif9O269oIpOHXMNxE=; b=MdtkMynl9oediw/2fooI4HZLp2MEjPlCj7VATuK52GktMOTsqWA3S8s1SbKoyHPmZojOQR4sMjeFpCWSB9xg+C/CvOkysyHplgpnTO6Z/dnI3KfPueo7qGP9q+1fjoYXaxg9kQQPMedj1TJHlY6GUR7GsFneBceDY0AxrjyvZpc=; Received: from [114.124.38.101] (port=61521 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YNy5N-000rrz-2k; Tue, 17 Feb 2015 23:26:14 -0700 Date: Wed, 18 Feb 2015 14:26:05 +0800 From: Erich Dollansky To: kpneal@pobox.com Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150218142605.28e2eafb@B85M-HD3-0.alogt.com> In-Reply-To: <20150218025100.GA49517@neutralgood.org> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150216035636.GA80472@neutralgood.org> <201502171657.07538.jhb@freebsd.org> <20150218025100.GA49517@neutralgood.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable@freebsd.org, Brandon Allbery , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 06:26:21 -0000 Hi, On Tue, 17 Feb 2015 21:51:00 -0500 kpneal@pobox.com wrote: > TL;DR: we shouldn't go littering our source tree with portability crap > just to handle a case (64 bit ints) that is probably many, many years > in the future. > an interesting attitude ... Erich From owner-freebsd-stable@FreeBSD.ORG Wed Feb 18 15:11:47 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD65BCC0 for ; Wed, 18 Feb 2015 15:11:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84C7C613 for ; Wed, 18 Feb 2015 15:11:47 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 444D6B953; Wed, 18 Feb 2015 10:11:46 -0500 (EST) From: John Baldwin To: kpneal@pobox.com Subject: Re: top, fixed buffer length in utils.c Date: Wed, 18 Feb 2015 08:35:24 -0500 Message-ID: <3448299.k0XuYIUFXB@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150218025100.GA49517@neutralgood.org> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <201502171657.07538.jhb@freebsd.org> <20150218025100.GA49517@neutralgood.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Feb 2015 10:11:46 -0500 (EST) Cc: freebsd-stable@freebsd.org, Brandon Allbery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:11:47 -0000 On Tuesday, February 17, 2015 09:51:00 PM kpneal@pobox.com wrote: > TL;DR: we shouldn't go littering our source tree with portability crap > just to handle a case (64 bit ints) that is probably many, many years in > the future. Yeah, but I think char buf[sizeof(int) * 3 + 1] is actually less crappy than char buf[10] despite it being more portable. It is more obvious to the reader what is happening. Magic numbers are the least obvious thing to read and require more work for the reader to understand (hence needing a mult-line block comment to explain in this case). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 19 22:14:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E133E4AA for ; Thu, 19 Feb 2015 22:14:21 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7DA88BE7 for ; Thu, 19 Feb 2015 22:14:20 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t1JM3grA035873 for ; Thu, 19 Feb 2015 16:03:42 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id 71C95187E50 for ; Thu, 19 Feb 2015 16:03:31 -0600 (CST) Message-ID: <54E65E05.2040101@shrew.net> Date: Thu, 19 Feb 2015 16:04:53 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: pthread leaky with resources? Content-Type: multipart/mixed; boundary="------------010708070805010203040003" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Thu, 19 Feb 2015 16:03:42 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 22:14:22 -0000 This is a multi-part message in MIME format. --------------010708070805010203040003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, I have a multi-threaded program that runs on 10.1-RELEASE-p5. It starts out with a reasonable footprint but there is obviously a resource leak as the program uses substantially more memory over time ... PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 51560 rdj 3 20 0 46676K 7500K select 1 0:00 0.00% dialyd ... 24h later ... PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 51560 rdj 3 20 0 131M 27064K select 3 1:45 0.00% dialyd After a bit of debugging, I determined that it only happens when threads are created and then later destroyed. Valgrind thinks that the resources are being leaked from libthr itself ... First I tried joining the threads, then I tried detaching them using either pthread_detach or pthread_attr_setdetachstate. Whatever method I use, I still see resources leaked. I wrote a simple test program to demonstrate this ( attached ). Ten threads show 16,472 bytes leaked where 250 threads show 275,672 bytes. Here is an example of the valgrind output ... ==69449== 254,000 bytes in 250 blocks are still reachable in loss record 12 of 12 ==69449== at 0x1007221: calloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==69449== by 0x16F8BD9: ??? (in /lib/libthr.so.3) ==69449== by 0x16F0E3D: pthread_create (in /lib/libthr.so.3) ==69449== by 0x4012B4: main (in /usr/home/mgrooms/threads/threads) ... and example of the summary shown for each run of the test program ... valgrind --leak-check=full ./threads 10 ==69310== Memcheck, a memory error detector ==69310== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==69310== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==69310== Command: ./threads 10 ==69310== main: waiting for condition to be signaled ... thread 5: signaling condition main: condition signaled, exiting ==69310== ==69310== HEAP SUMMARY: ==69310== in use at exit: 16,472 bytes in 30 blocks ==69310== total heap usage: 44 allocs, 14 frees, 17,368 bytes allocated ==69310== ==69310== LEAK SUMMARY: ==69310== definitely lost: 0 bytes in 0 blocks ==69310== indirectly lost: 0 bytes in 0 blocks ==69310== possibly lost: 0 bytes in 0 blocks ==69310== still reachable: 16,472 bytes in 30 blocks ==69310== suppressed: 0 bytes in 0 blocks ==69310== Reachable blocks (those to which a pointer was found) are not shown. ==69310== To see them, rerun with: --leak-check=full --show-reachable=yes ==69310== ==69310== For counts of detected and suppressed errors, rerun with: -v ==69310== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) valgrind --leak-check=full ./threads 100 ==69311== Memcheck, a memory error detector ==69311== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==69311== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==69311== Command: ./threads 100 ==69311== main: waiting for condition to be signaled ... thread 99: signaling condition main: condition signaled, exiting ==69311== ==69311== HEAP SUMMARY: ==69311== in use at exit: 113,672 bytes in 210 blocks ==69311== total heap usage: 314 allocs, 104 frees, 121,048 bytes allocated ==69311== ==69311== LEAK SUMMARY: ==69311== definitely lost: 0 bytes in 0 blocks ==69311== indirectly lost: 0 bytes in 0 blocks ==69311== possibly lost: 0 bytes in 0 blocks ==69311== still reachable: 113,672 bytes in 210 blocks ==69311== suppressed: 0 bytes in 0 blocks ==69311== Reachable blocks (those to which a pointer was found) are not shown. ==69311== To see them, rerun with: --leak-check=full --show-reachable=yes ==69311== ==69311== For counts of detected and suppressed errors, rerun with: -v ==69311== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) valgrind --leak-check=full ./threads 250 ==69315== Memcheck, a memory error detector ==69315== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==69315== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==69315== Command: ./threads 250 ==69315== main: waiting for condition to be signaled ... thread 241: signaling condition main: condition signaled, exiting ==69315== ==69315== HEAP SUMMARY: ==69315== in use at exit: 275,672 bytes in 510 blocks ==69315== total heap usage: 764 allocs, 254 frees, 293,848 bytes allocated ==69315== ==69315== LEAK SUMMARY: ==69315== definitely lost: 0 bytes in 0 blocks ==69315== indirectly lost: 0 bytes in 0 blocks ==69315== possibly lost: 0 bytes in 0 blocks ==69315== still reachable: 275,672 bytes in 510 blocks ==69315== suppressed: 0 bytes in 0 blocks ==69315== Reachable blocks (those to which a pointer was found) are not shown. ==69315== To see them, rerun with: --leak-check=full --show-reachable=yes ==69315== ==69315== For counts of detected and suppressed errors, rerun with: -v ==69315== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) This doesn't seem right to me. Anyone have any ideas? Thanks, -Matthew --------------010708070805010203040003 Content-Type: text/plain; charset=windows-1252; name="threads.cpp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="threads.cpp" Ly8NCi8vCW1haW4uY3BwOiB0aHJlYWQgdGVzdA0KLy8NCg0KI2luY2x1ZGUgPGVycm5vLmg+ DQojaW5jbHVkZSA8dW5pc3RkLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxz dGRsaWIuaD4NCiNpbmNsdWRlIDxwdGhyZWFkLmg+DQojaW5jbHVkZSA8bWFjaGluZS9hdG9t aWMuaD4NCg0KZW51bSBUSFJFQURfVFlQRQ0Kew0KCVRIUkVBRF9UWVBFX0pPSU5FRCA9IDAs DQoJVEhSRUFEX1RZUEVfREVUQUNIRUQsDQoJVEhSRUFEX1RZUEVfREVUQUNIRURfQVRUUklC DQoNCn07DQoNCmludCB0aHJlYWRfaW5kZXggPSAwOw0KDQpwdGhyZWFkX211dGV4X3QgbXV0 ZXg7DQpwdGhyZWFkX2NvbmRfdCBjb25kaXRpb247DQoNCnZvaWQgcHRocmVhZF9lcnJvcigg Y29uc3QgY2hhciAqIG5hbWUsIGludCByZXN1bHQgKQ0Kew0KCXN3aXRjaCggcmVzdWx0ICkN Cgl7DQoJCWNhc2UgMDoNCgkJCXJldHVybjsNCg0KCQljYXNlIEVBR0FJTjoNCgkJCXByaW50 ZiggIiVzIGZhaWxlZCAoIEVBR0FJTjogUmVzb3VyY2UgdGVtcG9yYXJpbHkgdW5hdmFpbGFi bGUgKVxuIiwgbmFtZSApOw0KCQkJYnJlYWs7DQoJCWNhc2UgRVBFUk06DQoJCQlwcmludGYo ICIlcyBmYWlsZWQgKCBFUEVSTTogT3BlcmF0aW9uIG5vdCBwZXJtaXR0ZWQgKVxuIiwgbmFt ZSApOw0KCQkJYnJlYWs7DQoJCWNhc2UgRUlOVkFMOg0KCQkJcHJpbnRmKCAiJXMgZmFpbGVk ICggRUlOVkFMOiBJbnZhbGlkIGFyZ3VtZW50IClcbiIsIG5hbWUgKTsNCgkJCWJyZWFrOw0K CQljYXNlIEVOT01FTToNCgkJCXByaW50ZiggIiVzIGZhaWxlZCAoIEVOT01FTTogQ2Fubm90 IGFsbG9jYXRlIG1lbW9yeSApXG4iLCBuYW1lICk7DQoJCQlicmVhazsNCgkJY2FzZSBFREVB RExLOg0KCQkJcHJpbnRmKCAiJXMgZmFpbGVkICggRURFQURMSzogUmVzb3VyY2UgZGVhZGxv Y2sgYXZvaWRlZCApXG4iLCBuYW1lICk7DQoJCQlicmVhazsNCgkJZGVmYXVsdDoNCgkJCXBy aW50ZiggIiVzIGZhaWxlZCggdW5rbm93biBlcnJvciApXG4iLCBuYW1lICk7DQoJfQ0KDQoJ ZXhpdCggMSApOw0KfQ0KDQp2b2lkICogdGhyZWFkX3Byb2MoIHZvaWQgKiBhcmcgKQ0Kew0K CS8vDQoJLy8gaW5jcmVtZW50IHRoZSB0aHJlYWQgaW5kZXggdW5kZXIgbXV0ZXggcHJvdGVj dGlvbg0KCS8vDQoNCglpbnQgcmVzdWx0ID0gcHRocmVhZF9tdXRleF9sb2NrKCAmbXV0ZXgg KTsNCglpZiggcmVzdWx0ICE9IDAgKQ0KCQlwdGhyZWFkX2Vycm9yKCAidGhyZWFkOiBwdGhy ZWFkX211dGV4X2xvY2siLCByZXN1bHQgKTsNCg0KCWludCBsb2NhbF9pbmRleCA9IHRocmVh ZF9pbmRleCsrOw0KCXByaW50ZiggInRocmVhZCAlaTogY3JlYXRlZFxuIiwgbG9jYWxfaW5k ZXggKTsNCg0KCXJlc3VsdCA9IHB0aHJlYWRfbXV0ZXhfdW5sb2NrKCAmbXV0ZXggKTsNCglp ZiggcmVzdWx0ICE9IDAgKQ0KCQlwdGhyZWFkX2Vycm9yKCAidGhyZWFkOiBwdGhyZWFkX211 dGV4X3VubG9jayIsIHJlc3VsdCApOw0KDQoJLy8NCgkvLyBzbGVlcCBmb3IgYSBiaXQNCgkv Lw0KDQoJc2xlZXAoIDMgKTsNCg0KCS8vDQoJLy8gZGVjcmVtZW50IHRoZSB0aHJlYWQgaW5k ZXggdW5kZXIgbXV0ZXggcHJvdGVjdGlvbg0KCS8vIGFuZCBzaWduYWwgdGhlIGNvbmRpdGlv biBpZiB0aGUgdGhyZWFkIGluZGV4IGhhcw0KCS8vIHJlYWNoZWQgemVybw0KCS8vDQoNCgly ZXN1bHQgPSBwdGhyZWFkX211dGV4X2xvY2soICZtdXRleCApOw0KCWlmKCByZXN1bHQgIT0g MCApDQoJCXB0aHJlYWRfZXJyb3IoICJ0aHJlYWQ6IHB0aHJlYWRfbXV0ZXhfbG9jayIsIHJl c3VsdCApOw0KDQoJcHJpbnRmKCAidGhyZWFkICVpOiBleGl0aW5nXG4iLCBsb2NhbF9pbmRl eCApOw0KCWlmKCAtLXRocmVhZF9pbmRleCA9PSAwICkNCgl7DQoJCXByaW50ZiggInRocmVh ZCAlaTogc2lnbmFsaW5nIGNvbmRpdGlvblxuIiwgbG9jYWxfaW5kZXggKTsNCgkJcmVzdWx0 ID0gcHRocmVhZF9jb25kX3NpZ25hbCggJmNvbmRpdGlvbiApOw0KCQlpZiggcmVzdWx0ID09 IDAgKQ0KCQkJcHRocmVhZF9lcnJvciggInRocmVhZDogcHRocmVhZF9jb25kX3NpZ25hbCIs IHJlc3VsdCApOw0KCX0NCg0KCXJlc3VsdCA9IHB0aHJlYWRfbXV0ZXhfdW5sb2NrKCAmbXV0 ZXggKTsNCglpZiggcmVzdWx0ICE9IDAgKQ0KCQlwdGhyZWFkX2Vycm9yKCAidGhyZWFkOiBw dGhyZWFkX211dGV4X3VubG9jayIsIHJlc3VsdCApOw0KDQoJcmV0dXJuIE5VTEw7DQp9DQoN CmludCBtYWluKCBpbnQgYXJnYywgY2hhciAqIGFyZ3ZbXSApDQp7DQoJLy8NCgkvLyB0eXBl IG9mIHRocmVhZCBjbGVhbnVwDQoJLy8NCgkvLyBUSFJFQURfVFlQRV9KT0lORUQ6IHRocmVh ZCB3aWxsIGJlIGpvaW5lZCB3aXRoIHB0aHJlYWRfam9pbg0KCS8vIFRIUkVBRF9UWVBFX0RF VEFDSEVEOiB0aHJlYWQgd2lsbCBiZSBkZXRhY2hlZCB1c2luZyBwdGhyZWFkX2RldGFjaA0K CS8vIFRIUkVBRF9UWVBFX0RFVEFDSEVEX0FUVFJJQjogdGhyZWFkIHdpbGwgYmUgZGV0YWNo ZWQgdXNpbmcgcHRocmVhZF9hdHRyX3NldGRldGFjaHN0YXRlDQoJLy8NCg0KCVRIUkVBRF9U WVBFIHRocmVhZF90eXBlID0gVEhSRUFEX1RZUEVfREVUQUNIRUQ7DQoNCgkvLw0KCS8vIHJl YWQgdGhyZWFkIGNvdW50DQoJLy8NCg0KCWludCB0aHJlYWRfY291bnQgPSAxMDsNCglpZigg YXJnYyA9PSAyICkNCgkJdGhyZWFkX2NvdW50ID0gYXRvaSggYXJndlsxXSApOw0KDQoJaWYo IHRocmVhZF9jb3VudCA8IDEgKQ0KCXsNCgkJcHJpbnRmKCAidXNhZ2U6IHRocmVhZHMgW3Ro cmVhZGNvdW50XVxuIiApOw0KCQlleGl0KCAyICk7DQoJfQ0KDQoJLy8NCgkvLyBjcmVhdGUg b3VyIHB0aHJlYWQgbXV0ZXgNCgkvLw0KDQoJaW50IHJlc3VsdCA9IHB0aHJlYWRfbXV0ZXhf aW5pdCggJm11dGV4LCBOVUxMICk7DQoJaWYoIHJlc3VsdCAhPSAwICkNCgkJcHRocmVhZF9l cnJvciggIm1haW46IHB0aHJlYWRfbXV0ZXhfaW5pdCIsIHJlc3VsdCApOw0KDQoJLy8NCgkv LyBjcmVhdGUgb3VyIHB0aHJlYWQgY29uZGl0aW9uDQoJLy8NCg0KCXJlc3VsdCA9IHB0aHJl YWRfY29uZF9pbml0KCAmY29uZGl0aW9uLCBOVUxMICk7DQoJaWYoIHJlc3VsdCAhPSAwICkN CgkJcHRocmVhZF9lcnJvciggIm1haW46IHB0aHJlYWRfY29uZF9pbml0IiwgcmVzdWx0ICk7 DQoNCgkvLw0KCS8vIGFsb2NhdGUgc3RvcmFnZSBmb3Igb3VyIHB0aHJlYWQgaGFuZGxlcw0K CS8vDQoNCglwdGhyZWFkX3QgKiBwdGhyZWFkcyA9IG5ldyBwdGhyZWFkX3RbIHRocmVhZF9j b3VudCBdOw0KCWlmKCBwdGhyZWFkcyA9PSBOVUxMICkNCgl7DQoJCXByaW50ZiggImZhaWxl ZCB0byBhbGxvY2F0ZSB0aHJlYWQgaGFuZGxlIHN0b3JhZ2VcbiIgKTsNCgkJcmV0dXJuIC0x Ow0KCX0NCg0KCS8vDQoJLy8gbG9vcCBmb3IgbnVtYmVyIG9mIHRocmVhZHMgcmVxdWVzdGVk DQoJLy8NCg0KCWZvciggaW50IGluZGV4ID0gMDsgaW5kZXggPCB0aHJlYWRfY291bnQ7IGlu ZGV4KysgKQ0KCXsNCgkJLy8NCgkJLy8gaW5pdGlhbGl6ZSBkZWZhdWx0IHRocmVhZCBhdHRy aWJ1dGVzDQoJCS8vDQoNCgkJcHRocmVhZF9hdHRyX3QgYXR0cjsNCgkJcmVzdWx0ID0gcHRo cmVhZF9hdHRyX2luaXQoICZhdHRyICk7DQoNCgkJLy8NCgkJLy8gc2V0IGRldGFjaCB0aHJl YWQgYXR0cmlidXRlIGlmIG5lY2Nlc3NhcnkNCgkJLy8NCg0KCQlpZiggdGhyZWFkX3R5cGUg PT0gVEhSRUFEX1RZUEVfREVUQUNIRURfQVRUUklCICkNCgkJCXJlc3VsdCA9IHB0aHJlYWRf YXR0cl9zZXRkZXRhY2hzdGF0ZSggJmF0dHIsIFBUSFJFQURfQ1JFQVRFX0RFVEFDSEVEICk7 DQoNCgkJLy8NCgkJLy8gY3JlYXRlIGEgbmV3IHRocmVhZA0KCQkvLw0KDQoJCXJlc3VsdCA9 IHB0aHJlYWRfY3JlYXRlKCAmcHRocmVhZHNbIGluZGV4IF0sICZhdHRyLCAmdGhyZWFkX3By b2MsIE5VTEwgKTsNCgkJaWYoIHJlc3VsdCAhPSAwICkNCgkJCXB0aHJlYWRfZXJyb3IoICJt YWluOiBwdGhyZWFkX2NyZWF0ZSIsIHJlc3VsdCApOw0KDQoJCS8vDQoJCS8vIGNsZWFuIHVw IHRocmVhZCBhdHRyaWJ1dGVzDQoJCS8vDQoNCgkJcHRocmVhZF9hdHRyX2Rlc3Ryb3koICZh dHRyICk7DQoNCgkJLy8NCgkJLy8gZXhwbGljaXRseSBkZXRhY2ggdGhlIHRocmVhZCBpZiBu ZWNjZXNzYXJ5DQoJCS8vDQoNCgkJaWYoIHRocmVhZF90eXBlID09IFRIUkVBRF9UWVBFX0RF VEFDSEVEICkNCgkJew0KCQkJcmVzdWx0ID0gcHRocmVhZF9kZXRhY2goIHB0aHJlYWRzWyBp bmRleCBdICk7DQoJCQlpZiggcmVzdWx0ICE9IDAgKQ0KCQkJCXB0aHJlYWRfZXJyb3IoICJt YWluOiBwdGhyZWFkX2RldGFjaCIsIHJlc3VsdCApOw0KCQl9DQoJfQ0KDQoJLy8NCgkvLyB3 YWl0IGZvciBvdXIgY29uZGl0aW9uIHRvIGJlIHNpZ25hbGVkDQoJLy8NCg0KCXByaW50Zigg Im1haW46IHdhaXRpbmcgZm9yIGNvbmRpdGlvbiB0byBiZSBzaWduYWxlZCAuLi5cbiIgKTsN Cg0KCXJlc3VsdCA9IHB0aHJlYWRfbXV0ZXhfbG9jayggJm11dGV4ICk7DQoJaWYoIHJlc3Vs dCAhPSAwICkNCgkJcHRocmVhZF9lcnJvciggIm1haW46IHB0aHJlYWRfbXV0ZXhfbG9jayIs IHJlc3VsdCApOw0KDQoJcmVzdWx0ID0gcHRocmVhZF9jb25kX3dhaXQoICZjb25kaXRpb24s ICZtdXRleCApOw0KCWlmKCByZXN1bHQgIT0gMCApDQoJCXB0aHJlYWRfZXJyb3IoICJtYWlu OiBwdGhyZWFkX2NvbmRfd2FpdCIsIHJlc3VsdCApOw0KDQoJcHJpbnRmKCAibWFpbjogY29u ZGl0aW9uIHNpZ25hbGVkLCBleGl0aW5nXG4iICk7DQoNCglyZXN1bHQgPSBwdGhyZWFkX211 dGV4X3VubG9jayggJm11dGV4ICk7DQoJaWYoIHJlc3VsdCAhPSAwICkNCgkJcHRocmVhZF9l cnJvciggIm1haW46IHB0aHJlYWRfbXV0ZXhfdW5sb2NrIiwgcmVzdWx0ICk7DQoNCgkvLw0K CS8vIGpvaW4gYWxsIHRocmVhZHMgaWYgbmVjY2Vzc2FyeQ0KCS8vDQoNCglpZiggdGhyZWFk X3R5cGUgPT0gVEhSRUFEX1RZUEVfSk9JTkVEICkNCgl7DQoJCWZvciggaW50IGluZGV4ID0g MDsgaW5kZXggPCB0aHJlYWRfY291bnQ7IGluZGV4KysgKQ0KCQl7DQoJCQlyZXN1bHQgPSBw dGhyZWFkX2pvaW4oIHB0aHJlYWRzWyBpbmRleCBdLCBOVUxMICk7DQoJCQlpZiggcmVzdWx0 ICE9IDAgKQ0KCQkJCXB0aHJlYWRfZXJyb3IoICJtYWluOiBwdGhyZWFkX2pvaW4iLCByZXN1 bHQgKTsNCgkJfQ0KDQoJCXByaW50ZiggImFsbCB0aHJlYWRzIGpvaW5lZFxuIiApOw0KCX0N Cg0KCS8vDQoJLy8gY2xlYW4gdXANCgkvLw0KDQoJZGVsZXRlIFtdIHB0aHJlYWRzOw0KDQoJ cHRocmVhZF9jb25kX2Rlc3Ryb3koICZjb25kaXRpb24gKTsNCglwdGhyZWFkX211dGV4X2Rl c3Ryb3koICZtdXRleCApOw0KDQoJcmV0dXJuIDA7DQp9DQo= --------------010708070805010203040003-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 06:02:07 2015 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCB075CC; Fri, 20 Feb 2015 06:02:07 +0000 (UTC) Received: from pmta1.delivery4.ore.mailhop.org (pmta1.delivery4.ore.mailhop.org [54.191.151.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1155E4; Fri, 20 Feb 2015 06:02:07 +0000 (UTC) Received: from smtp5.ore.mailhop.org (172.31.18.134) by pmta1.delivery1.ore.mailhop.org id hsr6sm20r84f; Fri, 20 Feb 2015 05:31:29 +0000 (envelope-from ) Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp5.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YOgBp-0006Nk-4H; Fri, 20 Feb 2015 05:31:49 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t1K5VmfS058023; Thu, 19 Feb 2015 22:31:48 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+INDFgLCNYg/4j0ZZ2PM0c Message-ID: <1424410308.1108.56.camel@freebsd.org> Subject: Re: building an 8.4-STABLE i386 poudriere jail on an 10.0-STABLE amd64 host From: Ian Lepore To: Don Lewis Date: Thu, 19 Feb 2015 22:31:48 -0700 In-Reply-To: <201408300043.s7U0hIXf073387@gw.catspoiler.org> References: <201408300043.s7U0hIXf073387@gw.catspoiler.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: gjb@FreeBSD.org, stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 06:02:07 -0000 On Fri, 2014-08-29 at 17:43 -0700, Don Lewis wrote: > On 29 Aug, Don Lewis wrote: > > > With the patch below, I get further, but now lint is core getting > > SIGBUS. > > > > ===> usr.bin/xlint/llib (all) > > lint -cghapbx -Cposix /var/poudriere/jails/84STABLEi386/usr/src/usr.bin/xlint/llib/llib-lposix > > llib-lposix: > > lint: /usr/obj/i386/var/poudriere/jails/84STABLEi386/usr/src/tmp/usr/libexec/lint1 got signal 10 > > *** Error code 1 > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > *** [buildworld] Error code 2 > > 1 error > > ====>> Error: Failed to 'make buildworld' > > I simplified things a bit and am now just doing normal crossbuilds. I'm > still seeing core dumps, even on amd64 -> amd64 crossbuilds. I'm not > seeing a reason, though ... > > # gdb /usr/obj/tmp/stable8/tmp/usr/libexec/lint1 /usr/obj/tmp/stable8/usr.bin/xlint/llib/lint1.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `lint1'. > Program terminated with signal 10, Bus error. > #0 0x000000000040b061 in getcnode (tp=0x800c1f400, v=0x800c08160) > at /tmp/stable8/usr.bin/xlint/lint1/tree.c:260 > 260 n->tn_val->v_u = v->v_u; > (gdb) list > 255 n->tn_op = CON; > 256 n->tn_type = tp; > 257 n->tn_val = tgetblk(sizeof (val_t)); > 258 n->tn_val->v_tspec = tp->t_tspec; > 259 n->tn_val->v_ansiu = v->v_ansiu; > 260 n->tn_val->v_u = v->v_u; > 261 free(v); > 262 return (n); > 263 } > 264 > (gdb) print n > $1 = (tnode_t *) 0x80068f000 > (gdb) print v > $2 = (val_t *) 0x800c08160 > (gdb) print *n > $3 = {tn_op = CON, tn_type = 0x800c1f400, tn_lvalue = 0, tn_cast = 0, > tn_parn = 0, tn_u = {tn_s = {_tn_left = 0x80068f028, _tn_right = 0x0}, > _tn_sym = 0x80068f028, _tn_val = 0x80068f028, _tn_strg = 0x80068f028}} > (gdb) print *v > $4 = {v_tspec = INT, v_ansiu = 0, v_u = {_v_quad = 128, > _v_ldbl = 4.6658554008095674912363595950328574e-4949}} > (gdb) print *n->tn_u._tn_val > $5 = {v_tspec = INT, v_ansiu = 0, v_u = {_v_quad = 0, _v_ldbl = 0}} > (gdb) print v->v_u > $6 = {_v_quad = 128, _v_ldbl = 4.6658554008095674912363595950328574e-4949} > (gdb) print n->tn_u._tn_val->v_u > $7 = {_v_quad = 0, _v_ldbl = 0} > > > > Looks like all the pointers are OK, so why the SIGBUS? A late late followup on this... I committed changes to 8-stable so that as of r279041 it can be built on a 10 or later build host, modulo this problem with lint1, which is baffling. The followup is because I stumbled across a workaround for it: just add LINT=/usr/bin/lint to your make command line. That allows the buildworld of 8-stable to complete on my 10-stable machine (amd64 non-cross build). It would be nice to figure out the lint thing, but at least I've finally accomplished what I set out to do this morning that I thought would be easy: build an 8-stable world to test running an 8-stable jail on this 10-stable machine. -- Ian From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 10:04:53 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E2AF813 for ; Fri, 20 Feb 2015 10:04:53 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6E5012A for ; Fri, 20 Feb 2015 10:04:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1KA4ls9069306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2015 12:04:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1KA4ls9069306 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1KA4lii069305; Fri, 20 Feb 2015 12:04:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 Feb 2015 12:04:47 +0200 From: Konstantin Belousov To: Matthew Grooms Subject: Re: pthread leaky with resources? Message-ID: <20150220100446.GL34251@kib.kiev.ua> References: <54E65E05.2040101@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E65E05.2040101@shrew.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 10:04:53 -0000 On Thu, Feb 19, 2015 at 04:04:53PM -0600, Matthew Grooms wrote: > All, > > I have a multi-threaded program that runs on 10.1-RELEASE-p5. It starts > out with a reasonable footprint but there is obviously a resource leak > as the program uses substantially more memory over time ... > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 51560 rdj 3 20 0 46676K 7500K select 1 0:00 0.00% dialyd > > ... 24h later ... > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 51560 rdj 3 20 0 131M 27064K select 3 1:45 0.00% dialyd > > After a bit of debugging, I determined that it only happens when threads > are created and then later destroyed. Valgrind thinks that the resources > are being leaked from libthr itself ... Threading library caches thread structures and some related objects. This is needed to correctly handle kernel notifications about threads exit and to avoid thread id reuse, besides usual argument for using cache to improve creation speed. Also, the thread stacks are cached, each stack being 2MB probably accounts for most of the memory usage columns in the top output above. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 10:42:07 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A031F86 for ; Fri, 20 Feb 2015 10:42:07 +0000 (UTC) Received: from babel.karthauser.co.uk (212-13-197-151.karthauser.co.uk [212.13.197.151]) by mx1.freebsd.org (Postfix) with ESMTP id 61C5174F for ; Fri, 20 Feb 2015 10:42:06 +0000 (UTC) Received: from unnamed-72.karthauser.co.uk (unnamed-72.karthauser.co.uk [90.155.77.72]) (Authenticated sender: joemail@tao.org.uk) by babel.karthauser.co.uk (Postfix) with ESMTPSA id D14AFBBF; Fri, 20 Feb 2015 10:34:45 +0000 (UTC) From: Dr Josef Karthauser Date: Fri, 20 Feb 2015 10:34:44 +0000 Subject: ada drives keep timing out! To: stable@freebsd.org Message-Id: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 10:42:07 -0000 Hi there, I reported this last year, but I=E2=80=99d like to revisit it as it must = have a software remedy. I know that I=E2=80=99m not the only one to have = reported the problem. I have a ZFS pool with a number of western digital drives in it (WDC = WD1000FYPS-01ZKB0 02.01B01). Periodically a drive times out with this error: (ada2:ahcich2:0:0:0): Periph destroyed (aprobe0:ahcich2:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00 (aprobe0:ahcich2:0:0:0): CAM status: ATA Status Error (aprobe0:ahcich2:0:0:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 = (ABRT ) (aprobe0:ahcich2:0:0:0): RES: d1 04 ff ff ff ff ff ff ff ff ff (aprobe0:ahcich2:0:0:0): Error 5, Retries exhausted and drops out of the pool. I have to reset the bus to get it to reattach: camcontrol scan 2 camcontrol rescan 2 I have four drives and recently they detached with this frequency: Jan 12 13:25:23 server kernel: (ada3:ahcich3:0:0:0): Periph = destroyed Jan 22 22:07:57 server kernel: (ada0:ahcich0:0:0:0): Periph = destroyed Jan 29 08:12:28 server kernel: (ada1:ahcich1:0:0:0): Periph = destroyed Jan 30 02:16:45 server kernel: (ada3:ahcich3:0:0:0): Periph = destroyed Feb 8 20:07:39 server kernel: (ada1:ahcich1:0:0:0): Periph = destroyed Feb 19 02:27:18 server kernel: (ada0:ahcich0:0:0:0): Periph = destroyed Feb 20 08:24:40 server kernel: (ada2:ahcich2:0:0:0): Periph = destroyed The box is a: FreeBSD server 9.2-STABLE FreeBSD 9.2-STABLE #1 r253253M: Mon Mar = 10 22:53:08 GMT 2014 Is this likely to have been address in a more recent FreeBSD or is it = still an issue today and can I work with someone to find a remedy? Many thanks Joe= From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 11:17:51 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ABDE340 for ; Fri, 20 Feb 2015 11:17:51 +0000 (UTC) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09357A02 for ; Fri, 20 Feb 2015 11:17:50 +0000 (UTC) Received: from [194.32.164.24] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id t1KBEQ05036480; Fri, 20 Feb 2015 11:14:26 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: ada drives keep timing out! From: Bob Bishop In-Reply-To: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> Date: Fri, 20 Feb 2015 11:14:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <938BC03E-2C47-4381-9D21-5849E9E6E126@gid.co.uk> References: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> To: Dr Josef Karthauser X-Mailer: Apple Mail (2.2070.6) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:17:51 -0000 Hi, > On 20 Feb 2015, at 10:34, Dr Josef Karthauser wrote: >=20 > Hi there, >=20 > I reported this last year, but I=E2=80=99d like to revisit it as it = must have a software remedy. I know that I=E2=80=99m not the only one to = have reported the problem. >=20 > I have a ZFS pool with a number of western digital drives in it (WDC = WD1000FYPS-01ZKB0 02.01B01). WD Green Power drives. I've had similar problems, sometimes they take a = looooong time to come ready; the controller times out waiting for drive = ready and the rest you know. Depending on the controller there may be nothing you can do. Maybe it's = possible to turn off the drives's green features. I replaced the drives = with something that works.=20 > Periodically a drive times out with this error: >=20 > (ada2:ahcich2:0:0:0): Periph destroyed > (aprobe0:ahcich2:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00 > (aprobe0:ahcich2:0:0:0): CAM status: ATA Status Error > (aprobe0:ahcich2:0:0:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 = (ABRT ) > (aprobe0:ahcich2:0:0:0): RES: d1 04 ff ff ff ff ff ff ff ff ff > (aprobe0:ahcich2:0:0:0): Error 5, Retries exhausted >=20 > and drops out of the pool. >=20 > I have to reset the bus to get it to reattach: >=20 > camcontrol scan 2 > camcontrol rescan 2 >=20 > I have four drives and recently they detached with this frequency: >=20 > Jan 12 13:25:23 server kernel: (ada3:ahcich3:0:0:0): Periph = destroyed > Jan 22 22:07:57 server kernel: (ada0:ahcich0:0:0:0): Periph = destroyed > Jan 29 08:12:28 server kernel: (ada1:ahcich1:0:0:0): Periph = destroyed > Jan 30 02:16:45 server kernel: (ada3:ahcich3:0:0:0): Periph = destroyed > Feb 8 20:07:39 server kernel: (ada1:ahcich1:0:0:0): Periph = destroyed > Feb 19 02:27:18 server kernel: (ada0:ahcich0:0:0:0): Periph = destroyed > Feb 20 08:24:40 server kernel: (ada2:ahcich2:0:0:0): Periph = destroyed >=20 > The box is a: >=20 > FreeBSD server 9.2-STABLE FreeBSD 9.2-STABLE #1 r253253M: Mon Mar = 10 22:53:08 GMT 2014 >=20 > Is this likely to have been address in a more recent FreeBSD or is it = still an issue today and can I work with someone to find a remedy? >=20 > Many thanks > Joe > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 11:21:37 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC637447 for ; Fri, 20 Feb 2015 11:21:37 +0000 (UTC) Received: from babel.karthauser.co.uk (212-13-197-151.karthauser.co.uk [212.13.197.151]) by mx1.freebsd.org (Postfix) with ESMTP id A57A7A24 for ; Fri, 20 Feb 2015 11:21:37 +0000 (UTC) Received: from unnamed-72.karthauser.co.uk (unnamed-72.karthauser.co.uk [90.155.77.72]) (Authenticated sender: joemail@tao.org.uk) by babel.karthauser.co.uk (Postfix) with ESMTPSA id 93C7DC85; Fri, 20 Feb 2015 11:21:36 +0000 (UTC) Subject: Re: ada drives keep timing out! Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Dr Josef Karthauser In-Reply-To: <938BC03E-2C47-4381-9D21-5849E9E6E126@gid.co.uk> Date: Fri, 20 Feb 2015 11:21:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> References: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> <938BC03E-2C47-4381-9D21-5849E9E6E126@gid.co.uk> To: Bob Bishop X-Mailer: Apple Mail (2.2070.6) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:21:37 -0000 > On 20 Feb 2015, at 11:14, Bob Bishop wrote: >=20 > Hi, >=20 >> On 20 Feb 2015, at 10:34, Dr Josef Karthauser wrote: >>=20 >> Hi there, >>=20 >> I reported this last year, but I=E2=80=99d like to revisit it as it = must have a software remedy. I know that I=E2=80=99m not the only one to = have reported the problem. >>=20 >> I have a ZFS pool with a number of western digital drives in it (WDC = WD1000FYPS-01ZKB0 02.01B01). >=20 > WD Green Power drives. I've had similar problems, sometimes they take = a looooong time to come ready; the controller times out waiting for = drive ready and the rest you know. >=20 > Depending on the controller there may be nothing you can do. Maybe = it's possible to turn off the drives's green features. I replaced the = drives with something that works.=20 >=20 Hi Bob, In this case other report no such issues on the same hardware running = Linux, so it seems to me to be an internal timeout issue within FreeBSD, = or maybe Linux retries more than FreeBSD and so doesn=E2=80=99t = experience the issue that we do. It=E2=80=99s clear that FreeBSD is = proactively disconnecting the drive when the timeout occurs. So, maybe = there=E2=80=99s something that can be done there. Joe= From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 11:38:49 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCA3498D for ; Fri, 20 Feb 2015 11:38:49 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 823C4C53 for ; Fri, 20 Feb 2015 11:38:49 +0000 (UTC) Received: by iecar1 with SMTP id ar1so7190285iec.0 for ; Fri, 20 Feb 2015 03:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SaI7+gMsFPWlJZOZCwkluXtW0nQUbDOHJgPuofjqL6k=; b=CkNcvo/ZWSIBYxGFj6+D0I7fg+8gY5OIuHyH+A6PM6782oQmePvI8yoT7WwxhbMmLO jY7OnPkl7tX8cqdaNoAcKyM92ARlL2IN7Rm3757U8WxUEMjkKiWAA12HocelKz4qnUqk KFKZaYOZQ4+mqyZt6BKTlx+wB3XGbCQmzXMYDdsH3mLHh0T1gTk9NtrKUmam+VoxL7Yx XlhgTuBgF6ts5Wd+lhXwFC160/s/HzBqnlusvxccPLT25lS0S5ALXYzHDOZqEc5OQgDb YFeUVLAP4++dGR4A78v+gFXb6V2k2EkePJoItWvFlzLjBogiLvDA36pHbHG3cKeDoLQQ ydOA== MIME-Version: 1.0 X-Received: by 10.43.74.201 with SMTP id yx9mr11328714icb.96.1424432328836; Fri, 20 Feb 2015 03:38:48 -0800 (PST) Received: by 10.107.0.8 with HTTP; Fri, 20 Feb 2015 03:38:48 -0800 (PST) In-Reply-To: <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> References: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> <938BC03E-2C47-4381-9D21-5849E9E6E126@gid.co.uk> <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> Date: Fri, 20 Feb 2015 11:38:48 +0000 Message-ID: Subject: Re: ada drives keep timing out! From: Tom Evans To: Dr Josef Karthauser Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:38:49 -0000 On Fri, Feb 20, 2015 at 11:21 AM, Dr Josef Karthauser wrot= e: > In this case other report no such issues on the same hardware running Lin= ux, so it seems to me to be an internal timeout issue within FreeBSD, or ma= ybe Linux retries more than FreeBSD and so doesn=E2=80=99t experience the i= ssue that we do. It=E2=80=99s clear that FreeBSD is proactively disconnecti= ng the drive when the timeout occurs. So, maybe there=E2=80=99s something t= hat can be done there. Linux has more automatic quirks for troublesome hardware, it may also have a longer default timeout. FreeBSD's WD green drives are green, they spin down frequently if idle. If you then try and use them, they can take considerably longer than the timeout to spin back up and be ready, and the kernel gives up. You can make the WD green drives less green by using a dos tool, wdidle3.exe. Google will tell you more (and show that WD green drives cause people problems on all OS when they use them in RAID). The continual parking/unparking considerably reduces the life of disk. You can tell BSD to wait longer with a higher "kern.cam.ada.default_timeout= ". Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 11:40:45 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76A05A86 for ; Fri, 20 Feb 2015 11:40:45 +0000 (UTC) Received: from smtp206.alice.it (smtp206.alice.it [82.57.200.102]) by mx1.freebsd.org (Postfix) with ESMTP id 09EE9C66 for ; Fri, 20 Feb 2015 11:40:44 +0000 (UTC) Received: from soth.ventu (87.3.58.151) by smtp206.alice.it (8.6.060.28) (authenticated as acanedi@alice.it) id 547D8AFA0EAC545C; Fri, 20 Feb 2015 12:35:11 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.15.1/8.14.9) with ESMTP id t1KBYPjV019477; Fri, 20 Feb 2015 12:34:25 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <54E71BD1.90009@netfence.it> Date: Fri, 20 Feb 2015 12:34:41 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, joe@tao.org.uk Subject: Re: ada drives keep timing out! References: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> <938BC03E-2C47-4381-9D21-5849E9E6E126@gid.co.uk> <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> In-Reply-To: <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:40:45 -0000 On 02/20/15 12:21, Dr Josef Karthauser wrote: > In this case other report no such issues on the same hardware running Linux, so it seems to me to be an internal timeout issue within FreeBSD, or maybe Linux retries more than FreeBSD and so doesn’t experience the issue that we do. It’s clear that FreeBSD is proactively disconnecting the drive when the timeout occurs. So, maybe there’s something that can be done there. Hello. While I cannot disagree with this last sentence, I've had my share of troubles with WD Green drives too. I had to replace them more than once during their warranty period, and was almost happy when they finally broke after the warranty was over. Leaving that aside, these drives will power down if not used for a while, but there is a DOS utility which can disable this feature. Not only this will avoid an even shorter lifespan, but it's an essential procedure if you want to use them with FreeBSD. If you haven't done this, then do it. After doing that, I was able to use them with some controllers, but not others, so YMMV. Finally, upgrading from 7.x to 8.x and then 9.x helped a lot, but in your case I don't know if there is any improvement after 9.2. HTH. bye av. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 11:40:56 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29924B6C for ; Fri, 20 Feb 2015 11:40:56 +0000 (UTC) Received: from babel.karthauser.co.uk (212-13-197-151.karthauser.co.uk [212.13.197.151]) by mx1.freebsd.org (Postfix) with ESMTP id E60FCC6C for ; Fri, 20 Feb 2015 11:40:55 +0000 (UTC) Received: from unnamed-72.karthauser.co.uk (unnamed-72.karthauser.co.uk [90.155.77.72]) (Authenticated sender: joemail@tao.org.uk) by babel.karthauser.co.uk (Postfix) with ESMTPSA id C3CD7CE2; Fri, 20 Feb 2015 11:40:54 +0000 (UTC) Subject: Re: ada drives keep timing out! Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Dr Josef Karthauser In-Reply-To: Date: Fri, 20 Feb 2015 11:40:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> <938BC03E-2C47-4381-9D21-5849E9E6E126@gid.co.uk> <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> To: Tom Evans X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:40:56 -0000 > On 20 Feb 2015, at 11:38, Tom Evans wrote: >=20 > You can tell BSD to wait longer with a higher = "kern.cam.ada.default_timeout=E2=80=9D. There we go, that=E2=80=99s the answer I was looking for :). Mine is currently set to: kern.cam.ada.default_timeout: 30 by default. I=E2=80=99ll try putting it up significantly and see what = happens :). Many thanks, Joe= From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 11:53:13 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCA30EAB for ; Fri, 20 Feb 2015 11:53:13 +0000 (UTC) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4914BDF9 for ; Fri, 20 Feb 2015 11:53:12 +0000 (UTC) Received: from [194.32.164.24] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id t1KBrBea048918; Fri, 20 Feb 2015 11:53:11 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: ada drives keep timing out! From: Bob Bishop In-Reply-To: <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> Date: Fri, 20 Feb 2015 11:53:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> <938BC03E-2C47-4381-9D21-5849E9E6E126@gid.co.uk> <1BFD18FF-D3A7-4230-9425-CEDC7DC94181@tao.org.uk> To: Dr Josef Karthauser X-Mailer: Apple Mail (2.2070.6) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:53:13 -0000 Hi, > On 20 Feb 2015, at 11:21, Dr Josef Karthauser wrote: >=20 >=20 >> On 20 Feb 2015, at 11:14, Bob Bishop wrote: >>=20 >> Hi, >>=20 >>> On 20 Feb 2015, at 10:34, Dr Josef Karthauser = wrote: >>>=20 >>> Hi there, >>>=20 >>> I reported this last year, but I=E2=80=99d like to revisit it as it = must have a software remedy. I know that I=E2=80=99m not the only one to = have reported the problem. >>>=20 >>> I have a ZFS pool with a number of western digital drives in it (WDC = WD1000FYPS-01ZKB0 02.01B01). >>=20 >> WD Green Power drives. I've had similar problems, sometimes they take = a looooong time to come ready; the controller times out waiting for = drive ready and the rest you know. >>=20 >> Depending on the controller there may be nothing you can do. Maybe = it's possible to turn off the drives's green features. I replaced the = drives with something that works.=20 >>=20 >=20 > Hi Bob, >=20 > In this case other report no such issues on the same hardware running = Linux, so it seems to me to be an internal timeout issue within FreeBSD, = or maybe Linux retries more than FreeBSD and so doesn=E2=80=99t = experience the issue that we do. It=E2=80=99s clear that FreeBSD is = proactively disconnecting the drive when the timeout occurs. So, maybe = there=E2=80=99s something that can be done there. It depends on the disk controller hardware/firmware (not the drive = electronics), not necessarily the driver. =46rom the drive datasheet = http://www.wdc.com/en/library/sata/2879-701236.pdf?wdc_lang=3Den "WD GreenPower drives monitor work load and automatically invoke idle = mode whenever possible to further reduce unnecessary power consumption. = Drive recovery time from idle mode is less than one second, [etc]" What happens is that the drive decides to idle and the controller has no = way of telling. So when the controller issues its next command, the = drive takes the best part of a second (if you are unlucky) to come out = of idle, execute the command and return to ready. The controller times = this out at a very low level and assumes that the drive has gone away. Maybe Linux does the equivalent of a bus rescan to work around this. I = had the problem using a dumb RAID 1 controller, once a drive dropped out = the mirror was broken so it was a big deal. > Joe -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 13:17:52 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D01F11E for ; Fri, 20 Feb 2015 13:17:52 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C286F906 for ; Fri, 20 Feb 2015 13:17:51 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t1KDHl8f060974; Fri, 20 Feb 2015 14:17:47 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3F26767D; Fri, 20 Feb 2015 14:17:47 +0100 (CET) Message-ID: <54E733FA.1020208@omnilan.de> Date: Fri, 20 Feb 2015 14:17:46 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jack Vogel Subject: Re: igb(4) watchdog timeout, lagg(4) fails References: <54ACC6A2.1050400@omnilan.de> <54AE565D.50208@omnilan.de> <54AE5A6B.7040601@omnilan.de> <54AFA784.6020102@omnilan.de> <54B10432.8050909@omnilan.de> <54DB8975.2030001@omnilan.de> <54DBB1F5.1090601@omnilan.de> In-Reply-To: <54DBB1F5.1090601@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA6D2712F92354F24355F32F5" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 20 Feb 2015 14:17:47 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 13:17:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA6D2712F92354F24355F32F5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Harald Schmalzbauer's Nachricht vom 11.02.2015 20:48 (localtime): > Bez=FCglich Jack Vogel's Nachricht vom 11.02.2015 18:31 (localtime): >> tdh and tdt mean the head and tail indices of the ring, and these >> values are >> obviously severely borked :) >> >> I'm buried with some other issues, but I'll try and find some time to = look >> at this a bit more. > Highly appreciated, thanks in advance! > > For the records: Rebooting the machine (ESXi guest-only!) brought the > stalled igb1 back to operation. > The guest has 2 igb (kawela) ports, one from a NIC(Intel ET Dual Port > 82576)@CPU-PCIe and the second port from an identical NIC, but connecte= d > via PCH-PCIe. > The watchdog timeout problem only occurs with the port from the > PCH-PCIe-connected NIC (falisfied)! > After the reboot the suspicious "dev.igb.1.link_irq=3D848" turned into:= > dev.igb.0.link_irq: 3 > dev.igb.1.link_irq: 4 Jack, I'd like to let you know that "dev.igb.1.link_irq" again shows garbage after the watchdog timeout problem occured again: dev.igb.1.link_irq: 1458 I can imagine that resetting goes wrong and ends in loss of link_irq. I now have to reboot the guest to get igb1 back to a working state, then the link_irq will show "4" again, but I can't tell you what was first, the timeour-reset or the "link_irq" jam. I guess the latter can't be the case, but I have no idea about the code=85 Thanks -Harry --------------enigA6D2712F92354F24355F32F5 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.18 (FreeBSD) iEYEARECAAYFAlTnM/oACgkQLDqVQ9VXb8gxYACfaIWOMi+x15dJew4Xec3nRU5k 4/8AoMidWB9EewqQpElLnLsxxmlWL+e9 =duXv -----END PGP SIGNATURE----- --------------enigA6D2712F92354F24355F32F5-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 15:03:48 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A84B8701 for ; Fri, 20 Feb 2015 15:03:48 +0000 (UTC) Received: from nm34-vm3.bullet.mail.gq1.yahoo.com (nm34-vm3.bullet.mail.gq1.yahoo.com [98.136.216.142]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7350086C for ; Fri, 20 Feb 2015 15:03:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424444490; bh=u5HQHK0bdcLhyg+kQphQNpmcawjZXxqCbPGRnw9XaX8=; h=Date:From:Reply-To:To:Subject:From:Subject; b=LQGVX/rai5/301rjLEY1lliMbZk3uM0WJc+dtyqpgeJs37Foww/Ue5jRI5Wy/3AOM3opH2sDiePwFh55ZWOmPLJTHu6bXj6BfX2E2D9QErMLTsuUR65+u3hHACy65n7V6mlw4/hx7Ur0H5xiwq/gv2PsOKqTfaticgbn+CppoQdPVuxRxoS4lm/laJUS8IW6r5d62X4mIjabgE3AUYFB/Q5Af0Rd1TdR6Og1fCBhsg/seN2Bw+Q3A1kzZktB/WSUHy6xFStLccY4ZFcQiVHpmAQhmdPmaIGbGOvYXCRl1nv9S2q7jbEOZ4toeFLCQ5ERLLf0JdHt0Pmq3y4M3Ximzw== Received: from [127.0.0.1] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 15:01:30 -0000 Received: from [216.39.60.183] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 14:58:35 -0000 Received: from [66.196.81.171] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2015 14:58:35 -0000 Received: from [98.139.212.221] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 14:58:35 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 20 Feb 2015 14:58:35 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 414886.32618.bm@omp1030.mail.bf1.yahoo.com X-YMail-OSG: zMmPQxgVM1lk61WktxRp8.A.iThltKdifFv8MAGKBjHFS7rPUqZILvEKCbiUmLZ fem0FO53aveSplpCF6oyIP4VXk7JQ80oaj.K1fkCEU7VYLZYFi_TqkEeVvZBi1o4jzevasRXniiN iEF1hlmje4WjvKRIGNBWRVcH8EHU3Qz58hl4ZR4xTUENx1ZkMJDZWRWcq8JLrusRGln0JfBll_F2 jzHbLMFlJ5KVTwOTGHdrKH4PX8y8x3qnn1e70OOCHMauCFY.wfDA6RJ8CqCNNo4sfCvoLo2Uci6Y M15y8agcYFhtKnsLjqoXeYsHysZOVAQoKZ1uTaAdrEFZ7_KYQ1Y1HjDFDB7bAQuAI5i.SdgXLVda cabs231CbAczofVOSFmSCemh0zZ2LtAxVZFf.EIHpLgNqJURUE2kSzeN3AYuSty.Q8PbOAh2h0AX z_2y2yyK08EzMzCABKuLcuo2i7RjQfCLG2HW2eioyCsDQDmwdnwktpy9OLDrJEz_NaLLna.EqL0z 3slsgd9jbMaYHSCHVf5f_ Received: by 76.13.26.107; Fri, 20 Feb 2015 14:58:34 +0000 Date: Fri, 20 Feb 2015 14:58:34 +0000 (UTC) From: Filippo Moretti Reply-To: Filippo Moretti To: "stable@freebsd.org" Message-ID: <1650525677.4644144.1424444314572.JavaMail.yahoo@mail.yahoo.com> Subject: Problem compiling openoffice MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:03:48 -0000 filippo sting ~ 03:53:10$ uname -aFreeBSD sting 10.1-STABLE FreeBSD 10.1-ST= ABLE #13 r278792: Sun Feb 15 13:36:52 CET 2015 filippo@sting:/usr/obj/usr/s= rc/sys/STING_VT i386I have the following problem while compiling openoffice= :=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 file:///usr/ports/editors/openo= ffice-4/work/aoo-4.1.1/main/i18npool/source/localedata/data/../../../unxfbs= di.pro/misc/saxparser.rdb /usr/ports/editors/openoffice-4/work/aoo-4.1.1/ma= in/solver/411/unxfbsdi.pro/bin/types.rdb \ Warning: LongDateYearSeparator is empty. Usually this is not the case and m= ay lead to concatenated display names like "Wednesday, 2007May 9". Warning: QuotationStart equals QuotationEnd. Not necessarily an error, but = unusual. Warning: DoubleQuotationStart equals DoubleQuotationEnd. Not necessarily an= error, but unusual. Warning: QuotationStart may be wrong: U+2019 =C3=A2 Warning: DoubleQuotationStart may be wrong: U+201D =C3=A2 Warning: DoubleQuotationStart may be wrong: U+201D =C3=A2Then the xterm cra= shes and no longer accept inputFilippo From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 15:05:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F124826 for ; Fri, 20 Feb 2015 15:05:04 +0000 (UTC) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14DFF88B for ; Fri, 20 Feb 2015 15:05:03 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id t1KF3Z76018307 for ; Fri, 20 Feb 2015 09:03:35 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-177-96-36.austin.res.rr.com [72.177.96.36]) by mail.shrew.net (Postfix) with ESMTPSA id 721FC18A86A for ; Fri, 20 Feb 2015 09:03:30 -0600 (CST) Message-ID: <54E74D17.6020209@shrew.net> Date: Fri, 20 Feb 2015 09:04:55 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: pthread leaky with resources? References: <54E65E05.2040101@shrew.net> <20150220100446.GL34251@kib.kiev.ua> In-Reply-To: <20150220100446.GL34251@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Fri, 20 Feb 2015 09:03:35 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:05:04 -0000 On 2/20/2015 4:04 AM, Konstantin Belousov wrote: > On Thu, Feb 19, 2015 at 04:04:53PM -0600, Matthew Grooms wrote: >> All, >> >> I have a multi-threaded program that runs on 10.1-RELEASE-p5. It starts >> out with a reasonable footprint but there is obviously a resource leak >> as the program uses substantially more memory over time ... >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 51560 rdj 3 20 0 46676K 7500K select 1 0:00 0.00% dialyd >> >> ... 24h later ... >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 51560 rdj 3 20 0 131M 27064K select 3 1:45 0.00% dialyd >> >> After a bit of debugging, I determined that it only happens when threads >> are created and then later destroyed. Valgrind thinks that the resources >> are being leaked from libthr itself ... > Threading library caches thread structures and some related objects. > This is needed to correctly handle kernel notifications about threads > exit and to avoid thread id reuse, besides usual argument for using cache > to improve creation speed. > > Also, the thread stacks are cached, each stack being 2MB probably accounts > for most of the memory usage columns in the top output above. Konstantin, Thanks for the reply. That seems reasonable. But surely these resources need to be reclaimed at some point after a thread gracefully exits. Otherwise any software that creates short lived threads will eventually run out of system resources and periodically require a restart. The test program I included does nothing but create threads that gracefully exit. Do you have another explanation as to why a program would indefinitely grow in size that way? Thanks, -Matthew From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 15:15:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F608B14 for ; Fri, 20 Feb 2015 15:15:44 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E776D99C for ; Fri, 20 Feb 2015 15:15:43 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id t1KFFfFs061751; Fri, 20 Feb 2015 10:15:41 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Fri, 20 Feb 2015 10:15:41 -0500 (EST) Date: Fri, 20 Feb 2015 10:15:41 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Matthew Grooms Subject: Re: pthread leaky with resources? In-Reply-To: <54E74D17.6020209@shrew.net> Message-ID: References: <54E65E05.2040101@shrew.net> <20150220100446.GL34251@kib.kiev.ua> <54E74D17.6020209@shrew.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:15:44 -0000 On Fri, 20 Feb 2015, Matthew Grooms wrote: > On 2/20/2015 4:04 AM, Konstantin Belousov wrote: >> Threading library caches thread structures and some related objects. >> This is needed to correctly handle kernel notifications about threads >> exit and to avoid thread id reuse, besides usual argument for using cache >> to improve creation speed. >> >> Also, the thread stacks are cached, each stack being 2MB probably accounts >> for most of the memory usage columns in the top output above. > > Konstantin, > > Thanks for the reply. That seems reasonable. But surely these resources need > to be reclaimed at some point after a thread gracefully exits. Otherwise any > software that creates short lived threads will eventually run out of system > resources and periodically require a restart. The test program I included > does nothing but create threads that gracefully exit. Do you have another > explanation as to why a program would indefinitely grow in size that way? When a thread is created, it will first try to reuse cached resources before allocating new resources. If you are creating 200 threads, for instance, try destroying those 200 threads, then create 200 new threads. You shouldn't see much change in resources, as libpthread should use the cached resources. If you see a double in the amount of resources used, then that would seem like a bug. -- DE From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 15:19:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8743DCF5 for ; Fri, 20 Feb 2015 15:19:44 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BA4A9E4 for ; Fri, 20 Feb 2015 15:19:43 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t1KFILDT043556 for ; Fri, 20 Feb 2015 09:18:21 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-177-96-36.austin.res.rr.com [72.177.96.36]) by mail.shrew.net (Postfix) with ESMTPSA id 5D448189DDC for ; Fri, 20 Feb 2015 09:18:10 -0600 (CST) Message-ID: <54E75087.7080100@shrew.net> Date: Fri, 20 Feb 2015 09:19:35 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: pthread leaky with resources? References: <54E65E05.2040101@shrew.net> <20150220100446.GL34251@kib.kiev.ua> <54E74D17.6020209@shrew.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Fri, 20 Feb 2015 09:18:21 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:19:44 -0000 On 2/20/2015 9:15 AM, Daniel Eischen wrote: > On Fri, 20 Feb 2015, Matthew Grooms wrote: > >> On 2/20/2015 4:04 AM, Konstantin Belousov wrote: >>> Threading library caches thread structures and some related objects. >>> This is needed to correctly handle kernel notifications about threads >>> exit and to avoid thread id reuse, besides usual argument for using >>> cache >>> to improve creation speed. >>> >>> Also, the thread stacks are cached, each stack being 2MB probably >>> accounts >>> for most of the memory usage columns in the top output above. >> >> Konstantin, >> >> Thanks for the reply. That seems reasonable. But surely these >> resources need to be reclaimed at some point after a thread >> gracefully exits. Otherwise any software that creates short lived >> threads will eventually run out of system resources and periodically >> require a restart. The test program I included does nothing but >> create threads that gracefully exit. Do you have another explanation >> as to why a program would indefinitely grow in size that way? > > When a thread is created, it will first try to reuse cached resources > before allocating new resources. > > If you are creating 200 threads, for instance, try destroying those 200 > threads, then create 200 new threads. You shouldn't see much change in > resources, as libpthread should use the cached resources. If you see > a double in the amount of resources used, then that would seem like a > bug. > Daniel, Thanks for the response. Let me do some more testing. I know that OS developer time is a precious resource. If I can find more evidence of the problem I will present it. Thanks, -Matthew From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 20:54:17 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF43C333 for ; Fri, 20 Feb 2015 20:54:17 +0000 (UTC) Received: from gw.zefyris.com (sabik.zefyris.com [IPv6:2001:7a8:3c67:2::254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 829528AF for ; Fri, 20 Feb 2015 20:54:17 +0000 (UTC) Received: from sekishi.zefyris.com (sekishi.zefyris.com [IPv6:2001:7a8:3c67:2::12]) by gw.zefyris.com (8.14.5/8.14.5) with ESMTP id t1KKs8rk697997; Fri, 20 Feb 2015 21:54:08 +0100 (CET) Date: Fri, 20 Feb 2015 21:54:08 +0100 From: Francois Tigeot To: Dr Josef Karthauser Subject: Re: ada drives keep timing out! Message-ID: <20150220205408.GB58299@sekishi.zefyris.com> References: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <064CF905-DF19-40A7-8CE8-D9FFE17913EE@tao.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gw.zefyris.com [IPv6:2001:7a8:3c67:2::254]); Fri, 20 Feb 2015 21:54:10 +0100 (CET) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 20:54:18 -0000 Hi, On Fri, Feb 20, 2015 at 10:34:44AM +0000, Dr Josef Karthauser wrote: > > I reported this last year, but I’d like to revisit it as it must have a software remedy. I know that I’m not the only one to have reported the problem. > > I have a ZFS pool with a number of western digital drives in it (WDC WD1000FYPS-01ZKB0 02.01B01). > > Periodically a drive times out with this error: > > (ada2:ahcich2:0:0:0): Periph destroyed > (aprobe0:ahcich2:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00 > (aprobe0:ahcich2:0:0:0): CAM status: ATA Status Error > (aprobe0:ahcich2:0:0:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 (ABRT ) > (aprobe0:ahcich2:0:0:0): RES: d1 04 ff ff ff ff ff ff ff ff ff > (aprobe0:ahcich2:0:0:0): Error 5, Retries exhausted Even though these are "green" drives, they are server models and shouldn't timeout. It's more than likely they have a buggy firmware. It happened to me with a bad batch of RE-GPs a few years ago. They were in a ZFS pool and kept being removed after I/O timeout errors. Your nearest WD support person should be able to provide you with a fixed firmware and the tools to flash them. -- Francois Tigeot From owner-freebsd-stable@FreeBSD.ORG Sat Feb 21 00:35:03 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A454451A for ; Sat, 21 Feb 2015 00:35:03 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B4432A9 for ; Sat, 21 Feb 2015 00:35:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=M1XZz5Xza1oGGXO/gcVIRUw3OiPndXhCwjFW23hl0l4=; b=qiPcNKjD3CH7AYm63x80Kv6HbIvEaID26vTypMK23/VQw6ojkVVqkGXAe9OgWKgxFxOTm5DOEciz3xCb1vEphFsl8gioWWz5DXrYhF5xkD7yem2zC4sEZ9xE+Ke1JZXbU7vGl3JjFCfQC/WgnlDMEg8YImrXDLBovYGPQKqZqlU=; Received: from [114.124.24.228] (port=62440 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YOy24-0022Ee-JW for freebsd-stable@freebsd.org; Fri, 20 Feb 2015 17:34:57 -0700 Date: Sat, 21 Feb 2015 08:34:44 +0800 From: Erich Dollansky To: freebsd-stable@freebsd.org Subject: Re: pthread leaky with resources? Message-ID: <20150221083444.5759b1d8@B85M-HD3-0.alogt.com> In-Reply-To: <54E75087.7080100@shrew.net> References: <54E65E05.2040101@shrew.net> <20150220100446.GL34251@kib.kiev.ua> <54E74D17.6020209@shrew.net> <54E75087.7080100@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 00:35:03 -0000 Hi, On Fri, 20 Feb 2015 09:19:35 -0600 Matthew Grooms wrote: > > When a thread is created, it will first try to reuse cached > > resources before allocating new resources. > > > > If you are creating 200 threads, for instance, try destroying those > > 200 threads, then create 200 new threads. You shouldn't see much > > change in resources, as libpthread should use the cached > > resources. If you see a double in the amount of resources used, > > then that would seem like a bug. > > > Thanks for the response. Let me do some more testing. I know that OS > developer time is a precious resource. If I can find more evidence of > the problem I will present it. > I am currently also working on a multi threaded program and have had also a problem like this. I thought it was an error 100% on my side. As I also did at the same time an upgrade to 10.1-STABLE FreeBSD 10.1-STABLE #2 r276328 it could be that there was really some problem in a library. Some of the threads just return while others are cancelled. If you have cancelled threads, do you use pthread_cleanup_push and pthread_cleanup_pop? Erich From owner-freebsd-stable@FreeBSD.ORG Sat Feb 21 19:58:05 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 024D5C5D for ; Sat, 21 Feb 2015 19:58:05 +0000 (UTC) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id 8483CEE3 for ; Sat, 21 Feb 2015 19:58:03 +0000 (UTC) Received: from [192.168.5.21] (5418287B.cm-5-1a.dynamic.ziggo.nl [84.24.40.123]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id 8E4871E8C08 for ; Sat, 21 Feb 2015 19:57:55 +0000 (UTC) Message-ID: <54E8E343.10600@searchy.net> Date: Sat, 21 Feb 2015 20:57:55 +0100 From: "Frank de Bot (lists)" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ZFS L2arc 16.0E size References: <54E1388C.3060602@searchy.net> <54E13F41.7000703@multiplay.co.uk> <54E1B12E.9070809@searchy.net> In-Reply-To: <54E1B12E.9070809@searchy.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 19:58:05 -0000 I've done some extra tests: I used a different ssd (samsung 840 pro), same result. I checkout the commitpoint '273060' and build another kernel, uname now says: 'FreeBSD nas 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #1 r273060: Sat Feb 21 18:42:08 UTC 2015 user@nas:/usr/obj/usr/src/sys/GENERIC amd64 Still same result. cache - - - - - - gpt/l2arc1 68.0G 16.0E 4 165 23.2K 19.3M gpt/l2arc2 68.0G 16.0E 5 162 24.8K 18.6M This already occures after 1 tot 2 hours when transferring a lot of data via rsync to the dataset. Is it worth to try hooking up the ssd to another controller (current on a LSI MegaRAID SAS 9211-4i) Regards, Frank de Bot Frank de Bot wrote: > I did remove and added devices again, with: > > 'zpool remove tank gpt/l2arc1 gpt/l2arc2' > and then > 'zpool add tank cache gpt/l2arc1 gpt/l2arc2' > > I left it running overnight and the same situation occured. > > cache - - - - - - > gpt/l2arc1 175G 16.0E 11 106 55.5K 9.75M > gpt/l2arc2 167G 16.0E 14 107 68.8K 9.81M > > For faster filling of the l2arc I also had 2 systcl's set: > > vfs.zfs.l2arc_write_max: 33554432 > vfs.zfs.l2arc_write_boost: 33554432 > > I do not plan to use this for production, only in testing. > > > Regards, > > Frank de Bot > Steven Hartland wrote: >> IIRC this was fixed by r273060, if your remove your cache device and >> then add it back I think you should be good. >> >> On 16/02/2015 00:23, Frank de Bot (lists) wrote: >>> Hello, >>> >>> I have a FreeBSD 10.1 system with a raidz2 zfs configuration with 2ssd's >>> for l2arc . It is running '10.1-STABLE FreeBSD 10.1-STABLE #0 r278805' >>> Currently I'm running tests before it can go to production, but I have >>> the following issue. After a while the l2arc devices indicate 16.0E free >>> space and it starts 'consuming' more than it can hold >>> >>> cache - - - - - - >>> gpt/l2arc1 107G 16.0E 0 2 0 92.7K >>> gpt/l2arc2 68.3G 16.0E 0 1 0 60.8K >>> >>> It ran good for a while, where data was removed from cache so it could >>> be filled with newer data. (Free space was always around 200/300Mbytes). >>> >>> I've read about similar issues, which should be fixed in different >>> commits, but I'm running the latest stable 10.1 kernel right now. (One >>> of the last similar issue is: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197164 ) >>> Another similar issue reported at FreeNAS >>> https://bugs.freenas.org/issues/5347 suggested it would be a hardware >>> issue, but I have 2 servers which experience the same problem. One has a >>> Crucial M500 drive and the other a M550. Both have a 64G partition voor >>> l2arc. >>> >>> What is really going on here? >>> >>> >>> Regards, >>> >>> >>> Frank de Bot >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 21 21:37:33 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77EEF7BF for ; Sat, 21 Feb 2015 21:37:33 +0000 (UTC) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 459F8AD3 for ; Sat, 21 Feb 2015 21:37:32 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id t1LLZx4S026108 for ; Sat, 21 Feb 2015 15:35:59 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-177-96-36.austin.res.rr.com [72.177.96.36]) by mail.shrew.net (Postfix) with ESMTPSA id CB0E8187E5D for ; Sat, 21 Feb 2015 15:35:53 -0600 (CST) Message-ID: <54E8FA90.8080102@shrew.net> Date: Sat, 21 Feb 2015 15:37:20 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: pthread leaky with resources? References: <54E65E05.2040101@shrew.net> <20150220100446.GL34251@kib.kiev.ua> <54E74D17.6020209@shrew.net> <54E75087.7080100@shrew.net> <20150221083444.5759b1d8@B85M-HD3-0.alogt.com> In-Reply-To: <20150221083444.5759b1d8@B85M-HD3-0.alogt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Sat, 21 Feb 2015 15:35:59 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 21:37:33 -0000 On 2/20/2015 6:34 PM, Erich Dollansky wrote: > Hi, > > On Fri, 20 Feb 2015 09:19:35 -0600 > Matthew Grooms wrote: > >>> When a thread is created, it will first try to reuse cached >>> resources before allocating new resources. >>> >>> If you are creating 200 threads, for instance, try destroying those >>> 200 threads, then create 200 new threads. You shouldn't see much >>> change in resources, as libpthread should use the cached >>> resources. If you see a double in the amount of resources used, >>> then that would seem like a bug. >>> >> Thanks for the response. Let me do some more testing. I know that OS >> developer time is a precious resource. If I can find more evidence of >> the problem I will present it. >> > I am currently also working on a multi threaded program and have had > also a problem like this. I thought it was an error 100% on my side. As > I also did at the same time an upgrade to > > 10.1-STABLE FreeBSD 10.1-STABLE #2 r276328 > > it could be that there was really some problem in a library. > > Some of the threads just return while others are cancelled. If you have > cancelled threads, do you use pthread_cleanup_push and > pthread_cleanup_pop? > Hi Erich, Thanks for the response. I don't use pthread_cancel. The threads I'm creating either join or are detached at creation time. After reading the explanation from Daniel, things make a lot more sense with respect to what I was seeing with the resource utilization in my test program. After spending another day looking at the code, I found the resource leak. Some of the threads were not being detached properly which lead to the increased memory utilization. Everything appears to be fine now after running for about 16 hours. Thanks to everyone for the useful feedback. Since I'm rambling on in public about pthreads on FreeBSD, I think it would be useful for the pthread_join manual page to be a bit more clear about the following statement ... A thread that has exited but remains unjoined counts against [_POSIX_THREAD_THREADS_MAX]. ... I assume that's only true if a thread is left in a joinable state. Thanks, -Matthew From owner-freebsd-stable@FreeBSD.ORG Sat Feb 21 22:44:37 2015 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DD9DCF5 for ; Sat, 21 Feb 2015 22:44:37 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA87E1D2 for ; Sat, 21 Feb 2015 22:44:36 +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 t1LMiQ5M021470; Sat, 21 Feb 2015 14:44:30 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201502212244.t1LMiQ5M021470@gw.catspoiler.org> Date: Sat, 21 Feb 2015 14:44:26 -0800 (PST) From: Don Lewis Subject: Re: Problem compiling openoffice To: filippomore@yahoo.com In-Reply-To: <1650525677.4644144.1424444314572.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 22:44:37 -0000 On 20 Feb, Filippo Moretti via freebsd-stable wrote: > filippo sting ~ 03:53:10$ uname -aFreeBSD sting 10.1-STABLE FreeBSD > 10.1-STABLE #13 r278792: Sun Feb 15 13:36:52 CET 2015 > filippo@sting:/usr/obj/usr/src/sys/STING_VT i386I have the following > problem while compiling openoffice:        > file:///usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/i18npool/source/localedata/data/../../../unxfbsdi.pro/misc/saxparser.rdb /usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/solver/411/unxfbsdi.pro/bin/types.rdb \ > Warning: LongDateYearSeparator is empty. Usually this is not the case > and may lead to concatenated display names like "Wednesday, 2007May > 9". Warning: QuotationStart equals QuotationEnd. Not necessarily an > error, but unusual. Warning: DoubleQuotationStart equals > DoubleQuotationEnd. Not necessarily an error, but unusual. Warning: > QuotationStart may be wrong: U+2019 â Warning: DoubleQuotationStart > may be wrong: U+201D â Warning: DoubleQuotationStart may be wrong: > U+201D âThen the xterm crashes and no longer accept inputFilippo > I haven't seen that problem before. I'm guessing that it is something having to do with language or locale. Are you trying to build a version of openoffice for a language other than the default, or do you have any non-default language or locale environment variable settings?