From owner-freebsd-stable@FreeBSD.ORG Sun Mar 24 03:17:41 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B551B1D9 for ; Sun, 24 Mar 2013 03:17:41 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9FF975 for ; Sun, 24 Mar 2013 03:17:41 +0000 (UTC) Received: from latitude.home.vangyzen.net (173-17-250-12.client.mchsi.com [173.17.250.12]) by smtp.vangyzen.net (Postfix) with ESMTP id 2843D56400 for ; Sat, 23 Mar 2013 22:11:21 -0500 (CDT) Message-ID: <514E6ED8.9040305@vangyzen.net> Date: Sat, 23 Mar 2013 22:11:20 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: stable@FreeBSD.org Subject: [patch] IPMI KCS can drop the lock while servicing a request Content-Type: multipart/mixed; boundary="------------090905000705080902010300" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Mar 2013 03:17:41 -0000 This is a multi-part message in MIME format. --------------090905000705080902010300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At work, we discovered that our application's IPMI thread would often use a lot of CPU time. The KCS thread uses DELAY to wait for the BMC, so it can run without sleeping for a "long" time with a slow BMC. It also holds the ipmi_softc.ipmi_lock during this time. When using adaptive mutexes, an application thread that wants to operate on the ipmi_pending_requests list will also spin during this same time. We see no reason that the KCS thread needs to hold the lock while servicing a request. We've been running with the attached patch for a few months, with no ill effects. Eric --------------090905000705080902010300 Content-Type: text/x-patch; name="ipmi_kcs.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipmi_kcs.c.patch" diff --git a/sys/dev/ipmi/ipmi_kcs.c b/sys/dev/ipmi/ipmi_kcs.c index 1ca3298..868570d 100644 --- a/sys/dev/ipmi/ipmi_kcs.c +++ b/sys/dev/ipmi/ipmi_kcs.c @@ -456,9 +456,11 @@ kcs_loop(void *arg) IPMI_LOCK(sc); while ((req = ipmi_dequeue_request(sc)) != NULL) { + IPMI_UNLOCK(sc); ok = 0; for (i = 0; i < 3 && !ok; i++) ok = kcs_polled_request(sc, req); + IPMI_LOCK(sc); if (ok) req->ir_error = 0; else --------------090905000705080902010300-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 24 03:56:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 880C67FC for ; Sun, 24 Mar 2013 03:56:55 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 25FEBA88 for ; Sun, 24 Mar 2013 03:56:55 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id d10so3608eaj.11 for ; Sat, 23 Mar 2013 20:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A46bnJZioqv6EQxldE2b1S+YMD0DEeAZGSh+mx0XoWU=; b=XlE/0klmMHAEmk06nxmE9HtOXBGj53UPJMoYi8a2dgfbseG8oLADB29Xlenh925FCP tCXW1fMlWqMcTjRoT836EuebswP84MdqtEGz0Y9oPOQiKiRBl8Smr9Edq3D9f4ANq9Dq fVRmcyMQvxTHNcn+JDnn6UI9k/yAbENgYTV7fpENJ7oflqq51dmGMroh7pXH9yusBdGD xx9pmDU+beOSDgwbg5R7kwWDdaaKlYhbTfsLIRVpXOvv3W+l39NY59yP4Nu9L8awqjfz tqLVPgJChAkXnf1XaTt3Omxj5O/rr2L9UYYewEdiFDgCjUq8EnslVgasILhaIYhcGI9+ kEbw== X-Received: by 10.15.22.76 with SMTP id e52mr11254407eeu.7.1364097414334; Sat, 23 Mar 2013 20:56:54 -0700 (PDT) Received: from mkushnir.zapto.org (61-50-132-95.pool.ukrtel.net. [95.132.50.61]) by mx.google.com with ESMTPS id r4sm11374553eeo.12.2013.03.23.20.56.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 20:56:53 -0700 (PDT) Message-ID: <514E7927.2010901@gmail.com> Date: Sun, 24 Mar 2013 05:55:19 +0200 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <513E2DA5.70200@mac.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Mar 2013 03:56:55 -0000 Hello John, Tested svnup for a while, and I can say it does its job well, and works basically as I would expect, so thanks for your initiative. Although it appears to be quite resource greedy. Most of the time it showed something like: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% a.out I looked at the source code, and found that it uses svn commands that are known as the "main command set". The program is implemented around get-dir and get-file. I think there is significant room for resource and performance improvement. Have you considered an approach to use what svn folks call the editor command set? I mean acting as a trivial svn client: we might ask the server to drive our checking out or updating. The server will be telling us only diffs. Checking out a full tree would be just another diff, although bigger than usually. We would also benefit from compression on the wire. Another advantage would be to always have consistent repo more-or-less guaranteed by the svn server. I've done some proof of concept recently, and the results look encouraging to me. For example, a do-nothing update really does nothing. A two-or-three revisions update takes a couple of seconds. And a full checkout of the base/stable/9 takes ~7m30s at 530kB/s to me. -- Markiyan. On 14.03.2013 04:30, John Mehr wrote: > > > > On Wed, 13 Mar 2013 14:50:43 -0400 > "David Magda" wrote: >> On Tue, March 12, 2013 19:32, John Mehr wrote: >>> This sounds good to me, and as long as there's some sort >>> of a consensus that we're not breaking the principle of >>> least surprise, I'm all for it. The one default that may >>> be unexpected is the defaulting to the stable branch -- >>> people who track the security branches will be left out. >>> So maybe something like: >>> >>> svnup --ports >>> svnup --stable >>> svnup --security (or --release) >>> >>> Thoughts? >> >> If svnup will eventually going to be used to update a variety of >> repositories, on a plethora of operating systems, then hard coding the >> above may not be appropriate. Something akin to "svnup --repo={ports, >> stable, security, release}" may be better, and then have a configuration >> file with the settings. > > Hello, > > You're absolutely correct. It looks like someone has already forked the > code on github which seems like pretty solid evidence for taking as > flexible an approach as possible and minimizing the amount of hard coded > data. > _______________________________________________ > 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 Sun Mar 24 22:38:52 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1E31ADC0 for ; Sun, 24 Mar 2013 22:38:52 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id D9A95975 for ; Sun, 24 Mar 2013 22:38:51 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UJtcI-0005uF-9u; Mon, 25 Mar 2013 02:42:18 +0400 Message-ID: <514F8061.7070206@FreeBSD.org> Date: Mon, 25 Mar 2013 02:38:25 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Eric van Gyzen Subject: Re: [patch] IPMI KCS can drop the lock while servicing a request References: <514E6ED8.9040305@vangyzen.net> In-Reply-To: <514E6ED8.9040305@vangyzen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Mar 2013 22:38:52 -0000 On 24.03.2013 07:11, Eric van Gyzen wrote: > At work, we discovered that our application's IPMI thread would often > use a lot of CPU time. The KCS thread uses DELAY to wait for the BMC, so > it can run without sleeping for a "long" time with a slow BMC. It also > holds the ipmi_softc.ipmi_lock during this time. When using adaptive > mutexes, an application thread that wants to operate on the > ipmi_pending_requests list will also spin during this same time. We suffer from the same problem, too. > > We see no reason that the KCS thread needs to hold the lock while > servicing a request. We've been running with the attached patch for a Well, this seems to be true. I'll try to commit something like this patch in several days. > few months, with no ill effects. > > Eric > > > _______________________________________________ > 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 Mar 25 01:55:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01ED48AA for ; Mon, 25 Mar 2013 01:55:13 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback3.g2host.com [208.42.184.243]) by mx1.freebsd.org (Postfix) with ESMTP id B50FA15B for ; Mon, 25 Mar 2013 01:55:11 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback3.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 11318703 for freebsd-stable@freebsd.org; Sun, 24 Mar 2013 19:55:05 -0500 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Sun, 24 Mar 2013 19:55:05 -0500 Message-ID: In-Reply-To: <514E7927.2010901@gmail.com> References: <513E2DA5.70200@mac.com> <514E7927.2010901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 01:55:13 -0000 On Sun, 24 Mar 2013 05:55:19 +0200  Markiyan Kushnir wrote: > Hello John, > > Tested svnup for a while, and I can say it does its job >well, and works basically as I would expect, so thanks >for your initiative. Although it appears to be quite >resource greedy. Most of the time it showed something >like: > >  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C >  TIME   WCPU COMMAND > 22270 mkushnir      1 102    0 44944K 31804K CPU0    1 >  6:22 97.56% a.out > > > I looked at the source code, and found that it uses svn >commands that are known as the "main command set". The >program is implemented around get-dir and get-file. I >think there is significant room for resource and >performance improvement. > > Have you considered an approach to use what svn folks >call the editor command set? I mean acting as a trivial >svn client: we might ask the server to drive our checking >out or updating. The server will be telling us only >diffs. Checking out a full tree would be just another >diff, although bigger than usually. We would also benefit >from compression on the wire. > > Another advantage would be to always have consistent >repo more-or-less guaranteed by the svn server. > > I've done some proof of concept recently, and the >results look encouraging to me. For example, a do-nothing >update really does nothing. A two-or-three revisions >update takes a couple of seconds. And a full checkout of >the base/stable/9 takes ~7m30s at 530kB/s to me. Hello, The results I was getting from testing out the svn protocol's editor command set were unpleasant enough to put it into the "come back to this later" category while I worked on implementing the http/https side.  The good news it that the http side is *much* easier to work with in this respect and getting a report with filenames and MD5/SHA-1 signatures for all of the files in the repository can be obtained all at once.  I should have a new and improved version ready to go this weekend or early next week at the latest. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 07:44:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6209943C for ; Mon, 25 Mar 2013 07:44:59 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 0520C213 for ; Mon, 25 Mar 2013 07:44:58 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hr17so2569457wib.17 for ; Mon, 25 Mar 2013 00:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=zSnsDr2wvYUCGRRzJFVHIMDgmt3LnbQTcF9+H84AaFk=; b=EiRp8nmIgjfAurOT7if2BpjKms0j0s+Yu1hC82Po6rjIFSGP/jzPPzIod3B1P4+swm vxUNr3UpnQ88QbBNhZR2avpg/1enuN/s2pKruCF1Ac8sZWyj0u4uoBuMl9WbWtsTaFs1 1/efiMco0HMP+zfw9VHw4GdOyfRp4YXgwdN0HY0RoRkib8QKNcxVuljwyDSzr+e5Hw2M USf476EqOH2Hg88zQBvjrigs/r0IO3kQBeiQh8PLtCcNXaGHq3lr48FtJQqHgG/cg+q4 Dqj8nKCkCaPRaWzfxi3wwT99X7hxaZnFQ5zcKqIggYffHNDRmVsGetV+1X0wLGgNrv5l zeaA== MIME-Version: 1.0 X-Received: by 10.180.87.193 with SMTP id ba1mr5550779wib.10.1364197498160; Mon, 25 Mar 2013 00:44:58 -0700 (PDT) Received: by 10.194.86.167 with HTTP; Mon, 25 Mar 2013 00:44:57 -0700 (PDT) Date: Mon, 25 Mar 2013 11:44:57 +0400 Message-ID: Subject: invalid statistics for 80211node malloc type From: Sergey Kandaurov To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 07:44:59 -0000 Hi, After upgrading from 8-stable to 9-stable I noticed the error in malloc(9) type 80211node counter. From vmstat -m: Type InUse MemUse HighUse Requests Size(s) 80211node 18446744073709551605 18014398509481852K - 0 18446744073709551605/18014398509481852 1024.00000 18446744073709551605/2^64 .99999 2^64-18446744073709551605 11 Looks like it goes (u_long)negative or some such. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 09:02:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B87AB28 for ; Mon, 25 Mar 2013 09:02:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id A3282891 for ; Mon, 25 Mar 2013 09:02:11 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id c10so1757875wiw.4 for ; Mon, 25 Mar 2013 02:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KEH7utMk/Uapn8Yf9XxAcRStU/Lmxc45Jae+POTRMMw=; b=m8fFRLVorHfAUnirQJJ5ACqbPNGlRwIqDILn+Z2ZchmZ0RXmSQHp06uaIORgM8EkyG eNKBOR6XzyTd4g1ULijuJd+8uvgpZt5H0nygoh6ZGKAf9XPmhtX6by6ai+v2Gxrh237K jf5ZjkNHBZ5m2zQoeo0QlZ069GLwT5icoH98qIbnp6HSp4shhRyZtibpPp7Jr+XUj5Fl 2wMNLUHDxcqEZ0LQkvstdzVjqynDMYUJyp47qULkb3r/xGlqENJb9RpXMAbPpXIfRGH1 vz1OKP7EbW/4nK8f1sX6ODjAMM4sS3h2NSx/vSFty9isiiJlRcTRakHaqKjISbxX9Fz2 OFRA== MIME-Version: 1.0 X-Received: by 10.180.79.6 with SMTP id f6mr23874801wix.26.1364202130899; Mon, 25 Mar 2013 02:02:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 02:02:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 02:02:10 -0700 X-Google-Sender-Auth: FfBeLlBpI6tkRltALTdYrm1hV8k Message-ID: Subject: Re: invalid statistics for 80211node malloc type From: Adrian Chadd To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 09:02:12 -0000 ... ? Never noticed this before. Is something double-freeing? Adrian On 25 March 2013 00:44, Sergey Kandaurov wrote: > Hi, > > After upgrading from 8-stable to 9-stable I noticed the > error in malloc(9) type 80211node counter. From vmstat -m: > Type InUse MemUse HighUse Requests Size(s) > 80211node 18446744073709551605 18014398509481852K - 0 > > 18446744073709551605/18014398509481852 > 1024.00000 > > 18446744073709551605/2^64 > .99999 > > 2^64-18446744073709551605 > 11 > > Looks like it goes (u_long)negative or some such. > > -- > wbr, > pluknet > _______________________________________________ > 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 Mar 25 09:02:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FF6EB35 for ; Mon, 25 Mar 2013 09:02:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id D27B4893 for ; Mon, 25 Mar 2013 09:02:20 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id c10so1757799wiw.2 for ; Mon, 25 Mar 2013 02:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BNxram4i3OWe1yDHzx2KJyZ9D8sszpZ1SIZZEByUoBE=; b=gtv4SZWQcPq6z4WefCI9+jtAidpn3pmkQv8RtFshG7Il2k0F2PA+EhgfGd560/Qcvl Ap5IKCsn+xOw/k2tCWyn9B7rJJPoL/qMVSqi6JTN/KQ3VdB5ID5TPQY0NAFMo8woCzxb lbvsTF3tMhdKp0N7YYxjYlZgMFIXeCMK7n7AFH7rlwRYewzOv3oQS3KtLtx1wnCeXBFY oTy9yXatjUaWsZb46NebS+F9OA3kVi+fbcwN22QMS9zLEGT/K78p+dKzGKcg/s6o43d8 WhSowOAfMPZxZY+UgcT5WZmIbGiYx4lZLSXUTcFuP37hACmCqxoOzS8dZk+ukCBuz5cQ VaAQ== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr16300238wjc.0.1364202140078; Mon, 25 Mar 2013 02:02:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 02:02:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 02:02:19 -0700 X-Google-Sender-Auth: uCfZaL02BPW4mSmrGo4rQB4qBtA Message-ID: Subject: Re: invalid statistics for 80211node malloc type From: Adrian Chadd To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 09:02:21 -0000 .. please file a PR! Adrian On 25 March 2013 02:02, Adrian Chadd wrote: > ... ? Never noticed this before. Is something double-freeing? > > > > Adrian > > On 25 March 2013 00:44, Sergey Kandaurov wrote: >> Hi, >> >> After upgrading from 8-stable to 9-stable I noticed the >> error in malloc(9) type 80211node counter. From vmstat -m: >> Type InUse MemUse HighUse Requests Size(s) >> 80211node 18446744073709551605 18014398509481852K - 0 >> >> 18446744073709551605/18014398509481852 >> 1024.00000 >> >> 18446744073709551605/2^64 >> .99999 >> >> 2^64-18446744073709551605 >> 11 >> >> Looks like it goes (u_long)negative or some such. >> >> -- >> wbr, >> pluknet >> _______________________________________________ >> 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 Mar 25 09:33:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1676426; Mon, 25 Mar 2013 09:33:03 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5C8A05; Mon, 25 Mar 2013 09:33:03 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hn17so3700513wib.0 for ; Mon, 25 Mar 2013 02:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=B8kCxrSiq5NUU8zKxFTWppuLlzW2qGtOtHPvNB5sJuA=; b=ZqZIlVeAt0MGZLPYU8HoFehs9sVNaVL1e7iOl6mKWCsUWdJ3sAFLUTzNHaW9dZaKtw FisyW44sRJ3pI75fB55IPos1l+Y0RmxjlNc34HaS5W+YxRZPGli9dWVG02FixD+tm27s StfWyyDZcl0sE7kO1pi5iHop/jyBv964+p9cTJDYSulR0FQ2spieZRZeP2qgjGUphshM QEvx+zkugJq1XY5+CPelhoQpg8oHFXL+qKeAE87UnBK7PpX7eUxEqg8JTQ5llAZG0KEi kRjPHMJXHP6LSPV+n7wdGoO7cFeF8iNpFNc7EpHOKJa9N4DPGdtI0IrrhDZ0XqWeCjEX /bMw== MIME-Version: 1.0 X-Received: by 10.194.123.103 with SMTP id lz7mr16540105wjb.10.1364203982570; Mon, 25 Mar 2013 02:33:02 -0700 (PDT) Received: by 10.194.86.167 with HTTP; Mon, 25 Mar 2013 02:33:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 13:33:02 +0400 Message-ID: Subject: Re: invalid statistics for 80211node malloc type From: Sergey Kandaurov To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 09:33:04 -0000 On 25 March 2013 13:02, Adrian Chadd wrote: > .. please file a PR! > kern/177366 > > > Adrian > > On 25 March 2013 02:02, Adrian Chadd wrote: >> ... ? Never noticed this before. Is something double-freeing? >> I'd rather say it tries to free never allocated memory? Look at mts_numallocs. (kgdb) p ((struct malloc_type_internal *)M_80211_NODE->ks_handle)->mti_stats[0] $20 = {mts_memalloced = 0, mts_memfreed = 61440, mts_numallocs = 0, mts_numfrees = 5, mts_size = 0, _mts_reserved1 = 0, _mts_reserved2 = 0, _mts_reserved3 = 0} (kgdb) p ((struct malloc_type_internal *)M_80211_NODE->ks_handle)->mti_stats[1] $21 = {mts_memalloced = 0, mts_memfreed = 73728, mts_numallocs = 0, mts_numfrees = 6, mts_size = 0, _mts_reserved1 = 0, _mts_reserved2 = 0, _mts_reserved3 = 0} -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 10:12:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E92D1F7E for ; Mon, 25 Mar 2013 10:12:27 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE7DCF5 for ; Mon, 25 Mar 2013 10:12:27 +0000 (UTC) Received: (qmail 64862 invoked from network); 25 Mar 2013 11:05:45 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 25 Mar 2013 11:05:45 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems From: Kai Gallasch In-Reply-To: Date: Mon, 25 Mar 2013 11:05:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-stable X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 10:12:28 -0000 Am 22.01.2013 um 11:19 schrieb Kai Gallasch: > Hi. >=20 > (Im am sending this to the "stable" list, because it maybe kernel = related.. ) >=20 > On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. >=20 > The slapd runs for some days and then hangs, consuming high amounts of = CPU. > In this state slapd can only be restarted by SIGKILL. short update: I tried all I could to isolate the problem. What I am certain of is that the problem lies in the BDB backend for = openldap itself, or how slapd interacts with it. My knowledge is not sufficient to debug BDB itself, it appears to be = quite a complex gearbox. Also - as a sidenote - I had to learn that the new owner of BDB (orcle) = does not give a toss about keeping old links to BDB documentation intact = (for example informattion you'd need to tune your BDB - "DB_CONFIG" - or = understand it better.) In the end I decided to drop the BDB backend for my running slapd = installations and switch over to MDB[1,2] as backend and since then the = problems disappeared. So if you are plagued by the same slapd lockups and rely on your ldap = directory, switching backends will give you some peace of mind. Thanks to all who have replied! And thanks to sleepycat for all the = fish. Kai Gallasch. [1] http://manpages.ubuntu.com/manpages/precise/man5/slapd-mdb.5.html [2] http://www.openldap.org/doc/admin24/backends.html= From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 10:51:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E658EBB5 for ; Mon, 25 Mar 2013 10:51:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 827C5EFB for ; Mon, 25 Mar 2013 10:51:13 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id p43so4922179wea.26 for ; Mon, 25 Mar 2013 03:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AJexeSDk5RSNzkQEGBbUvNZxbG++b6IgDz2Vzx7lcHQ=; b=bYYjKmVZwDFwAYoxKKxHdDwUMp0k/cp/uY2DCXLbRPbatQU1jTWJqmfSUvjL8RTKsX wteHu2554H1fjXZA+nMMZxDcp1YuGCyFZjZryon5rParf1IlgkyP9VrwrbbLubqcjf+W 0HSVFc4vQ+EMT19t+u295GeEk7XbCllwerW7fB8qVEDULw7j/pGlyA2BtD0icSreQfFt q0xXHPC44yfJN01lAWDJBlBFXhEYUUG/1ZKdE+exFjKX+VMpThOmZrACs/P5OPTtimLK JLml0d3sIZt2QL13GxEAfXk8Xt4Bjz5jn3tJFjd+Uy0wbLKW5bbALcN4K7i9wLOTxqQS 8zFw== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr17086866wje.5.1364208672786; Mon, 25 Mar 2013 03:51:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 03:51:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 03:51:12 -0700 X-Google-Sender-Auth: imRKYnXdY1zRiixoxd7U8BHT4-k Message-ID: Subject: Re: invalid statistics for 80211node malloc type From: Adrian Chadd To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 10:51:14 -0000 Can you please find out _where_ that's being called when mts_numallocs is zero? Thanks, Adrian On 25 March 2013 02:33, Sergey Kandaurov wrote: > On 25 March 2013 13:02, Adrian Chadd wrote: >> .. please file a PR! >> > kern/177366 > >> >> >> Adrian >> >> On 25 March 2013 02:02, Adrian Chadd wrote: >>> ... ? Never noticed this before. Is something double-freeing? >>> > > I'd rather say it tries to free never allocated memory? Look at mts_numallocs. > > (kgdb) p ((struct malloc_type_internal *)M_80211_NODE->ks_handle)->mti_stats[0] > $20 = {mts_memalloced = 0, mts_memfreed = 61440, mts_numallocs = 0, > mts_numfrees = 5, mts_size = 0, _mts_reserved1 = 0, _mts_reserved2 = > 0, > _mts_reserved3 = 0} > (kgdb) p ((struct malloc_type_internal *)M_80211_NODE->ks_handle)->mti_stats[1] > $21 = {mts_memalloced = 0, mts_memfreed = 73728, mts_numallocs = 0, > mts_numfrees = 6, mts_size = 0, _mts_reserved1 = 0, _mts_reserved2 = > 0, > _mts_reserved3 = 0} > > -- > wbr, > pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 11:52:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E7A3D92 for ; Mon, 25 Mar 2013 11:52:06 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id EA2447A0 for ; Mon, 25 Mar 2013 11:52:05 +0000 (UTC) Received: (qmail 37481 invoked from network); 25 Mar 2013 12:52:04 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 25 Mar 2013 12:52:04 +0100 From: Kai Gallasch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: gptzfsboot: error 4 lba 30 Date: Mon, 25 Mar 2013 12:52:04 +0100 Message-Id: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> To: freebsd-stable Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 11:52:06 -0000 Hi. On one of my fresh installed servers I am seeing the following output = during boot: gptzfsboot: error 4 lba 30 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 30 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 (Not shortened, exactly those lines) The server then manages to boot from a mirrored zpool. What is the cause of error 4 lba 30/31 ? - controller is a hp/compaq p400 (ciss) - da0 - da7 are raid0 volumes (controller not jbod capable) - freebsd 9.1 REL (same error message with 9-STABLE from 2013-03-24) - server is zfs-only # diskinfo -v da0 da0 512 # sectorsize 146778685440 # mediasize in bytes (136G) 286677120 # mediasize in sectors 0 # stripesize 0 # stripeoffset 35132 # Cylinders according to firmware. 255 # Heads according to firmware. 32 # Sectors according to firmware. P61620D9SUP9ZS # Disk ident. # gpart show =3D> 34 286677053 da0 GPT (136G) 34 256 1 freebsd-boot (128k) 290 286676797 2 freebsd-zfs (136G) =3D> 34 286677053 da1 GPT (136G) 34 256 1 freebsd-boot (128k) 290 286676797 2 freebsd-zfs (136G) Could this be drive geometry releated? (The hp/compaq raid0 drive is = just presented to the O/S and is not identical to the raw device, = because of raidcontroller on-disk meta information) If I remember = correctly the the hp raid configuration tool also offers the possibility = to create raid0 drives with 63 sector geometry. Regards, Kai. --- dmesg --- Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Quad-Core AMD Opteron(tm) Processor 2389 (2900.17-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x100f42 Family =3D 10 Model =3D 4 = Stepping =3D 2 = Features=3D0x178bfbff Features2=3D0x802009 AMD = Features=3D0xee500800 AMD = Features2=3D0x37ff TSC: P-state invariant real memory =3D 30064771072 (28672 MB) avail memory =3D 28952248320 (27611 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 pcib0: on acpi0 pcib0: Length mismatch for 4 range: 918 vs 917 pci0: on pcib0 vgapci0: port 0x1000-0x10ff mem = 0xe8000000-0xefffffff,0xf7ff0000-0xf7ffffff irq 44 at device 3.0 on pci0 pci0: at device 4.0 (no driver attached) pci0: at device 4.2 (no driver attached) uhci0: port 0x1800-0x181f irq 45 at = device 4.4 on pci0 usbus0 on uhci0 pci0: at device 4.6 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 177,0x376,0x500-0x50f at device 6.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 isab0: at device 6.2 on pci0 isa0: on isab0 ohci0: port 0x1c00-0x1cff mem = 0xf7ee0000-0xf7ee0fff irq 5 at device 7.0 on pci0 usbus1 on ohci0 ohci1: port 0x3000-0x30ff mem = 0xf7ed0000-0xf7ed0fff irq 5 at device 7.1 on pci0 usbus2 on ohci1 ehci0: port 0x3400-0x34ff mem = 0xf7ec0000-0xf7ec0fff irq 5 at device 7.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib3: irq 42 at device 15.0 on pci0 pci5: on pcib3 pcib4: irq 38 at device 16.0 on pci0 pci8: on pcib4 pcib5: irq 39 at device 17.0 on pci0 pci14: on pcib5 pcib6: irq 40 at device 18.0 on pci0 pci11: on pcib6 pcib7: irq 41 at device 19.0 on pci0 pci3: on pcib7 pcib8: at device 0.0 on pci3 pci4: on pcib8 bce0: mem = 0xf8000000-0xf9ffffff irq 41 at device 0.0 on pci4 bce0: /usr/src/sys/dev/bce/if_bce.c(1258): Management firmware enabled = but not running! miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: Ethernet address: 00:1b:78:38:dd:02 bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C = (1.9.6); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NOT RUNNING!) Coal (RX:6,6,18,18; TX:20,20,80,80) pcib9: on acpi0 pci64: on pcib9 pcib10: irq 36 at device 15.0 on pci64 pci67: on pcib10 pcib11: irq 32 at device 16.0 on pci64 pci70: on pcib11 0000-0xfdef0fff irq 32 at device 0.0 on pci70 ciss0: PERFORMANT Transport pcib12: irq 33 at device 17.0 on pci64 pci73: on pcib12 pcib13: irq 34 at device 18.0 on pci64 pci65: on pcib13 pcib14: at device 0.0 on pci65 pci66: on pcib14 bce1: mem = 0xfa000000-0xfbffffff irq 34 at device 0.0 on pci66 bce1: /usr/src/sys/dev/bce/if_bce.c(1258): Management firmware enabled = but not running! miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce1: Ethernet address: 00:1b:78:38:dd:00 bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C = (1.9.6); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NOT RUNNING!) Coal (RX:6,6,18,18; TX:20,20,80,80) pcib15: irq 35 at device 19.0 on pci64 pci74: on pcib15 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) orm0: at iomem = 0xc0000-0xcafff,0xcb000-0xcefff,0xe5000-0xe6fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 ppc0: cannot reserve I/O port range uart1: at port 0x2f8-0x2ff = irq 3 on isa0 ctl: CAM Target Layer loaded hwpstate0: on cpu0 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: <0x103c> at usbus0 uhub0: <0x103c UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on = usbus0 ugen1.1: <0x1166> at usbus1 uhub1: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on = usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen2.1: <0x1166> at usbus2 uhub2: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on = usbus2 ugen3.1: <0x1166> at usbus3 uhub3: <0x1166 EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on = usbus3 uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered bce0: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state = =3D 0x00000006) bce1: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state = =3D 0x00000006) ugen0.2: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 ums0: on usbus0 ums0: 3 buttons and [XY] coordinates ID=3D0 uhub3: 4 ports with 4 removable, self powered ugen3.2: at usbus3 uhub4: = on usbus3 uhub4: MTT enabled (probe0:ciss0:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe0:ciss0:0:0:0): CAM status: SCSI Status Error (probe0:ciss0:0:0:0): SCSI status: Check Condition (probe0:ciss0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe0:ciss0:0:0:0): Error 22, Unretryable error (probe1:ciss0:0:1:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe1:ciss0:0:1:0): CAM status: SCSI Status Error (probe1:ciss0:0:1:0): SCSI status: Check Condition (probe1:ciss0:0:1:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe1:ciss0:0:1:0): Error 22, Unretryable error (probe2:ciss0:0:2:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe2:ciss0:0:2:0): CAM status: SCSI Status Error (probe2:ciss0:0:2:0): SCSI status: Check Condition (probe2:ciss0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe2:ciss0:0:2:0): Error 22, Unretryable error (probe3:ciss0:0:3:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe3:ciss0:0:3:0): CAM status: SCSI Status Error (probe3:ciss0:0:3:0): SCSI status: Check Condition (probe3:ciss0:0:3:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe3:ciss0:0:3:0): Error 22, Unretryable error (probe4:ciss0:0:4:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe4:ciss0:0:4:0): CAM status: SCSI Status Error (probe4:ciss0:0:4:0): SCSI status: Check Condition (probe4:ciss0:0:4:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe4:ciss0:0:4:0): Error 22, Unretryable error (probe5:ciss0:0:5:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe5:ciss0:0:5:0): CAM status: SCSI Status Error (probe5:ciss0:0:5:0): SCSI status: Check Condition (probe5:ciss0:0:5:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe5:ciss0:0:5:0): Error 22, Unretryable error (probe6:ciss0:0:6:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe6:ciss0:0:6:0): CAM status: SCSI Status Error (probe6:ciss0:0:6:0): SCSI status: Check Condition (probe6:ciss0:0:6:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe6:ciss0:0:6:0): Error 22, Unretryable error (probe7:ciss0:0:7:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0=20 (probe7:ciss0:0:7:0): CAM status: SCSI Status Error (probe7:ciss0:0:7:0): SCSI status: Check Condition (probe7:ciss0:0:7:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid = command operation code) (probe7:ciss0:0:7:0): Error 22, Unretryable error uhub4: 4 ports with 4 removable, self powered da0 at ciss0 bus 0 scbus2 target 0 lun 0 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present = - tray closed da0: Fixed Direct Access SCSI-5 device=20 da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) da1 at ciss0 bus 0 scbus2 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device=20 da1: 135.168MB/s transfers da1: Command Queueing enabled da1: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) da2 at ciss0 bus 0 scbus2 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device=20 da2: 135.168MB/s transfers da2: Command Queueing enabled da2: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) da3 at ciss0 bus 0 scbus2 target 3 lun 0 da3: Fixed Direct Access SCSI-5 device=20 da3: 135.168MB/s transfers da3: Command Queueing enabled da3: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) da4 at ciss0 bus 0 scbus2 target 4 lun 0 da4: Fixed Direct Access SCSI-5 device=20 da4: 135.168MB/s transfers da4: Command Queueing enabled da4: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) da5 at ciss0 bus 0 scbus2 target 5 lun 0 da5: Fixed Direct Access SCSI-5 device=20 da5: 135.168MB/s transfers da5: Command Queueing enabled da5: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) da6 at ciss0 bus 0 scbus2 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device=20 da6: 135.168MB/s transfers da6: Command Queueing enabled da6: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) da7 at ciss0 bus 0 scbus2 target 7 lun 0 da7: Fixed Direct Access SCSI-5 device=20 da7: 135.168MB/s transfers da7: Command Queueing enabled da7: 139979MB (286677120 512 byte sectors: 255H 32S/T 35132C) SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 11328785 Hz quality 800 Root mount waiting for: usbus3 ugen3.3: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:5:0:-1: Attached to scbus5 da8 at umass-sim0 bus 0 scbus5 target 0 lun 0 da8: Removable Direct Access SCSI-4 device=20= da8: 40.000MB/s transfers da8: 3861MB (7907328 512 byte sectors: 255H 63S/T 492C) GEOM: da8: geometry does not match label (64h,33s !=3D 255h,63s). GEOM: da8: media size does not match label. Trying to mount root from zfs:rpool/ROOT/default []... bce0: Gigabit link up!= From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 12:02:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D70873BD for ; Mon, 25 Mar 2013 12:02:02 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id A7BDA89B for ; Mon, 25 Mar 2013 12:02:02 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id wd20so5770512obb.23 for ; Mon, 25 Mar 2013 05:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zT5iev4jk72AfTsmEjD/MegqHw8s5x3U2QD+M/pogdQ=; b=XFzGzZrIAoffSShoo/YP6BrVLviZty2kknYNET3jLPBlXC2bNpYVKFxAzXrC0zJneP CtV9tlU2UevMpeLYfcta2OfHcE6SDkyBY6kRH83R3c/fR/7Z+yYmvnL+ElV4AxdMbQqq TqlM8aIlrQibWfdN2Bk9XjGnjYkTN1ynU18hBvWyDm8Dua7B1D1nECTx1hsejo6dv33J myjT2+B55kfJg4nHmtMDTLhYpd4ikVyweQqrX2jjK653QYt9KJZgjmdYT37gm1/UHksP bU0LWkPqf8UY24AaW3qwQj1MjIZ1WsaOJ09pXZc81qP7Vp7qEgzxAAy/HVawvc7XiHph ZLRA== MIME-Version: 1.0 X-Received: by 10.60.25.138 with SMTP id c10mr11089197oeg.12.1364212922250; Mon, 25 Mar 2013 05:02:02 -0700 (PDT) Received: by 10.76.122.81 with HTTP; Mon, 25 Mar 2013 05:02:02 -0700 (PDT) In-Reply-To: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> References: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> Date: Mon, 25 Mar 2013 13:02:02 +0100 Message-ID: Subject: Re: gptzfsboot: error 4 lba 30 From: Andreas Nilsson To: Kai Gallasch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 12:02:02 -0000 On Mon, Mar 25, 2013 at 12:52 PM, Kai Gallasch wrote: > Hi. > > On one of my fresh installed servers I am seeing the following output > during boot: > > gptzfsboot: error 4 lba 30 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 30 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > > (Not shortened, exactly those lines) > > The server then manages to boot from a mirrored zpool. > What is the cause of error 4 lba 30/31 ? > > - controller is a hp/compaq p400 (ciss) > - da0 - da7 are raid0 volumes (controller not jbod capable) > - freebsd 9.1 REL (same error message with 9-STABLE from 2013-03-24) > - server is zfs-only > *snip* Normally one gets ( there were some mails about this just the other day ) > gptzfsboot: error 1 lba 32 > gptzfsboot: error 1 lba 1 on hp-machines with p410i disk controller. I think there is work ongoing to fix it, and for at least the p410i adding a simple printf in the right place in zfsboot.c allows it to boot. --- sys/boot/i386/zfsboot/zfsboot.c (revision 245604) +++ sys/boot/i386/zfsboot/zfsboot.c (working copy) @@ -453,6 +453,7 @@ heap_end = (char *) PTOV(bios_basemem); } + printf("\n"); dsk = malloc(sizeof(struct dsk)); dsk->drive = *(uint8_t *)PTOV(ARGS); dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD; works fine on a dl360g7, as well as a dl360g5. Best regards Andreas Nilsson From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 14:31:42 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7D3A95C for ; Mon, 25 Mar 2013 14:31:42 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 793732EC for ; Mon, 25 Mar 2013 14:31:42 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UK8UO-000E55-VA; Mon, 25 Mar 2013 18:35:09 +0400 Message-ID: <51505FC0.3040709@FreeBSD.org> Date: Mon, 25 Mar 2013 18:31:28 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eric van Gyzen Subject: Re: [patch] IPMI KCS can drop the lock while servicing a request References: <514E6ED8.9040305@vangyzen.net> <514F8061.7070206@FreeBSD.org> In-Reply-To: <514F8061.7070206@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 14:31:42 -0000 On 25.03.2013 02:38, Alexander V. Chernikov wrote: > On 24.03.2013 07:11, Eric van Gyzen wrote: >> At work, we discovered that our application's IPMI thread would often >> use a lot of CPU time. The KCS thread uses DELAY to wait for the BMC, so >> it can run without sleeping for a "long" time with a slow BMC. It also >> holds the ipmi_softc.ipmi_lock during this time. When using adaptive >> mutexes, an application thread that wants to operate on the >> ipmi_pending_requests list will also spin during this same time. > We suffer from the same problem, too. >> >> We see no reason that the KCS thread needs to hold the lock while >> servicing a request. We've been running with the attached patch for a > Well, this seems to be true. I'll try to commit something like this > patch in several days. Done in r248705. > >> few months, with no ill effects. >> >> Eric >> >> >> _______________________________________________ >> 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" > -- WBR, Alexander From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 17:49:18 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66D947F0 for ; Mon, 25 Mar 2013 17:49:18 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) by mx1.freebsd.org (Postfix) with ESMTP id 33D166E1 for ; Mon, 25 Mar 2013 17:49:17 +0000 (UTC) Received: from [10.10.1.32] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id r2PHknHM054332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Mar 2013 13:46:50 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Virtio and GEOM labels From: John Nielsen In-Reply-To: Date: Mon, 25 Mar 2013 11:46:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <44809413-C1A4-4A0E-8598-B88651A16A8F@jnielsen.net> References: To: Paul Mather X-Mailer: Apple Mail (2.1503) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1117; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.5 at ns1.jnielsen.net X-Virus-Status: Clean Cc: "stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 17:49:18 -0000 On Mar 22, 2013, at 8:14 AM, Paul Mather = wrote: > I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM = virtualisation. I have networking and storage in the FreeBSD guest = using the Virtio drivers (with the virtual disk set to "Virtio" in the = definition on the host). Everything is working nicely: I have a vtnet = network adapter and see vtbd devices for my virtual disks in FreeBSD. = Performance is much better compared with an emulated IDE device. I've had the same experience. > The odd thing is that I don't see GEOM labels reflected in /dev. For = example, I have GPT labels defined in the guest, but I don't see them = show up under /dev/gpt. Similarly, my UFS labels don't show up under = /dev/ufs. I *do* see a /dev/gptid. That appears to be the only label = that shows up. I have not encountered this issue. I use virtio block devices and GPT = labels exclusively in multiple FreeBSD 9.1 guests and all mount/function = without issue. How are you referring to your filesystems in /etc/fstab? = IIRC GEOM makes not-in-use labels disappear when a device is in use = (e.g. mounted). If you take a new device, put a labeled GPT partition on = it and a labeled UFS partition on that but don't mount anything, what = happens? > Is there something special I need to do to get GPT and UFS labels to = appear when using Virtio? It seems to me that Virtio block devices = appear to be somewhat unusual. Unlike regular ATA and SCSI devices, my = vtbd devices don't appear in the boot dmesg (although a vtblk device = does), and "camcontrol devlist" does not list them. It's not clear to = me how I am supposed to interact with them other than via basic device = I/O through /dev/vtbdX. I thought that the virtio_scsi module might = make them appear as "da" devices and able to interacted with via = camcontrol, but this doesn't seem to be the case. Virtio block devices and virtio SCSI devices are not the same. If you = want to use the virtio_scsi module in FreeBSD you should expose a virtio = SCSI device from the host. JN From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 18:55:42 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A58F06BE for ; Mon, 25 Mar 2013 18:55:42 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF03A38 for ; Mon, 25 Mar 2013 18:55:42 +0000 (UTC) Received: from steiner.cc.vt.edu (steiner.cc.vt.edu [198.82.163.51]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r2PIgHel020822; Mon, 25 Mar 2013 14:55:04 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by steiner.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id WCJ05853; Mon, 25 Mar 2013 14:55:03 -0400 (EDT) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id r2PIt2XU024603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 14:55:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Virtio and GEOM labels From: Paul Mather In-Reply-To: <44809413-C1A4-4A0E-8598-B88651A16A8F@jnielsen.net> Date: Mon, 25 Mar 2013 14:55:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44809413-C1A4-4A0E-8598-B88651A16A8F@jnielsen.net> To: John Nielsen X-Mailer: Apple Mail (2.1503) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=steiner.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020204.51509D88.01BB,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: "stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 18:55:42 -0000 On Mar 25, 2013, at 1:46 PM, John Nielsen wrote: > On Mar 22, 2013, at 8:14 AM, Paul Mather = wrote: >=20 >> I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM = virtualisation. I have networking and storage in the FreeBSD guest = using the Virtio drivers (with the virtual disk set to "Virtio" in the = definition on the host). Everything is working nicely: I have a vtnet = network adapter and see vtbd devices for my virtual disks in FreeBSD. = Performance is much better compared with an emulated IDE device. >=20 > I've had the same experience. >=20 >> The odd thing is that I don't see GEOM labels reflected in /dev. For = example, I have GPT labels defined in the guest, but I don't see them = show up under /dev/gpt. Similarly, my UFS labels don't show up under = /dev/ufs. I *do* see a /dev/gptid. That appears to be the only label = that shows up. >=20 > I have not encountered this issue. I use virtio block devices and GPT = labels exclusively in multiple FreeBSD 9.1 guests and all mount/function = without issue. How are you referring to your filesystems in /etc/fstab? = IIRC GEOM makes not-in-use labels disappear when a device is in use = (e.g. mounted). If you take a new device, put a labeled GPT partition on = it and a labeled UFS partition on that but don't mount anything, what = happens? Thanks for the reply. My apologies: this is a case of pilot error on my part. I was mounting = the devices as /dev/vtbd... I hadn't realised that the = present-but-unused labels were being suppressed when the device was = mounted. Has this always been the case? For some reason I had a = distinct recollection stuck in my mind that all labels showed up in = /dev. Anyway, many thanks for pointing the way to the solution. I now have = GPT- and UFS-labelled devices mounted in my FreeBSD guest system. >=20 >> Is there something special I need to do to get GPT and UFS labels to = appear when using Virtio? It seems to me that Virtio block devices = appear to be somewhat unusual. Unlike regular ATA and SCSI devices, my = vtbd devices don't appear in the boot dmesg (although a vtblk device = does), and "camcontrol devlist" does not list them. It's not clear to = me how I am supposed to interact with them other than via basic device = I/O through /dev/vtbdX. I thought that the virtio_scsi module might = make them appear as "da" devices and able to interacted with via = camcontrol, but this doesn't seem to be the case. >=20 > Virtio block devices and virtio SCSI devices are not the same. If you = want to use the virtio_scsi module in FreeBSD you should expose a virtio = SCSI device from the host. Thank you for the explanation. I've been using virt-manager up to now = for setting up KVM guests and it seems that virtio-scsi isn't exposed = through that interface---only through the command line. I'll have to = investigate... Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 25 19:27:00 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F042AF14 for ; Mon, 25 Mar 2013 19:27:00 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (ip-static-94-242-209-234.as5577.net [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 85DF9BF8 for ; Mon, 25 Mar 2013 19:27:00 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id A75CD42C25D9; Mon, 25 Mar 2013 20:27:06 +0100 (CET) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 25 Mar 2013 14:26:35 -0500 (CDT) From: Bryan Venteicher To: Paul Mather Message-ID: <23542574.359.1364239595731.JavaMail.root@daemoninthecloset.org> In-Reply-To: References: <44809413-C1A4-4A0E-8598-B88651A16A8F@jnielsen.net> Subject: Re: Virtio and GEOM labels MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.14] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC25 (Mac)/8.0.2_GA_5569) Thread-Topic: Virtio and GEOM labels Thread-Index: x+Ccm2iLLkobM/fRxteTFquWkPin1w== Cc: "stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Mar 2013 19:27:01 -0000 ----- Original Message ----- > On Mar 25, 2013, at 1:46 PM, John Nielsen wrote: > > > On Mar 22, 2013, at 8:14 AM, Paul Mather wrote: > > > >> I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM virtualisation. > >> I have networking and storage in the FreeBSD guest using the Virtio > >> drivers (with the virtual disk set to "Virtio" in the definition on the > >> host). Everything is working nicely: I have a vtnet network adapter and > >> see vtbd devices for my virtual disks in FreeBSD. Performance is much > >> better compared with an emulated IDE device. > > > > I've had the same experience. > > > >> The odd thing is that I don't see GEOM labels reflected in /dev. For > >> example, I have GPT labels defined in the guest, but I don't see them > >> show up under /dev/gpt. Similarly, my UFS labels don't show up under > >> /dev/ufs. I *do* see a /dev/gptid. That appears to be the only label > >> that shows up. > > > > I have not encountered this issue. I use virtio block devices and GPT > > labels exclusively in multiple FreeBSD 9.1 guests and all mount/function > > without issue. How are you referring to your filesystems in /etc/fstab? > > IIRC GEOM makes not-in-use labels disappear when a device is in use (e.g. > > mounted). If you take a new device, put a labeled GPT partition on it and > > a labeled UFS partition on that but don't mount anything, what happens? > > > Thanks for the reply. > > My apologies: this is a case of pilot error on my part. I was mounting the > devices as /dev/vtbd... I hadn't realised that the present-but-unused > labels were being suppressed when the device was mounted. Has this always > been the case? For some reason I had a distinct recollection stuck in my > mind that all labels showed up in /dev. > > Anyway, many thanks for pointing the way to the solution. I now have GPT- > and UFS-labelled devices mounted in my FreeBSD guest system. > > > > > >> Is there something special I need to do to get GPT and UFS labels to > >> appear when using Virtio? It seems to me that Virtio block devices > >> appear to be somewhat unusual. Unlike regular ATA and SCSI devices, my > >> vtbd devices don't appear in the boot dmesg (although a vtblk device > >> does), and "camcontrol devlist" does not list them. It's not clear to me > >> how I am supposed to interact with them other than via basic device I/O > >> through /dev/vtbdX. I thought that the virtio_scsi module might make > >> them appear as "da" devices and able to interacted with via camcontrol, > >> but this doesn't seem to be the case. > > > > Virtio block devices and virtio SCSI devices are not the same. If you want > > to use the virtio_scsi module in FreeBSD you should expose a virtio SCSI > > device from the host. > If you are doing a verbose boot, you'll get a 'GEOM: new disk vtbdX' announcing new disks. With vtbdX devices, there is no SCSI (or really any other higher level) protocol involved (on the guest side) so tools like camcontrol do not make sense. Reads, writes, etc are just translated into commands defined in the VirtIO spec. > > Thank you for the explanation. I've been using virt-manager up to now for > setting up KVM guests and it seems that virtio-scsi isn't exposed through > that interface---only through the command line. I'll have to investigate... > There are examples for editing the guest's XML config with virsh on Redhat's site. > Cheers, > > Paul. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Mar 26 18:38:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBBE010B for ; Tue, 26 Mar 2013 18:38:17 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from nm31-vm5.bullet.mail.bf1.yahoo.com (nm31-vm5.bullet.mail.bf1.yahoo.com [72.30.239.13]) by mx1.freebsd.org (Postfix) with ESMTP id A9D99615 for ; Tue, 26 Mar 2013 18:38:16 +0000 (UTC) Received: from [98.139.212.145] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 18:35:02 -0000 Received: from [98.139.212.249] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 18:35:02 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 26 Mar 2013 18:35:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 327516.30324.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 16055 invoked by uid 60001); 26 Mar 2013 18:35:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364322902; bh=sonl9nfMrEeDFiO0KWyFf39s3/F8IOSwSirA96jToUg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=lQ6hdyn1d4QYlYZZ6dXBIS1XWUv8ffCG4lOlhp45nsEWkGuyqZJfc5lfak1JLjEx2oi+UMAUU2LIBRh9y7DxEZhhc9tC2ePoB0HX2qTZ095c1sbOzXqeXOtM/Q9X0gPwsC3ysjO5W9JSvwSFza4iZbPkrUgwIcFCgCl3J/psKlE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=WAFOQvPJNGIQMAW5+vfkOMJuRz6pwWg3OleYYPvk50arLwPX6IW3uw3gF4emwlKC7bckz8VtbFqULyWAz+dAExGGksdY5DrtZCf5LrfIrihNhqK2bYV1YBgfL49uP5kPPpFfiOeL8gkzbItKO45I8dpYCuLncix0w9GEYceEVYw=; X-YMail-OSG: h9X14x0VM1nmNZRMYorNEjeKtDtbo1OWKOz51k.tYKa.1ty YffcuyL6Zud6ZluKZAzR_zM1X.Q8XELStgo6dUQEsvBN_ILKrdHDRTH6zM7F QCmRmW2GuwphqQi9.uNQ._MBVmZJ.l4qKhNQkiSIosSuMVeX3MArP.TqJPQ4 3hIhBnlxE6Sb0P5B8fZvNg5KxR7eYEknYz0_n0XAuB5N9IxL4BzvCJU.iyoX qt41sMNBu1B27alFeg8Rue.G9UC5KiaeLCz75X0d_2fEn5PaP2klX0H1pYvJ cEK6rEQRO9ODwxVUOxpJJo1CWInyGNVE_wMst2EKHH.Y6NLHM0XZv00DicgX nw.4DTIXpowzXLmUNX0.eXhfiMewa3jo4oluqbsRkA41Nmg4j1ySgoCwTq0L g_XBoS5jOX0v3d0oMcp3CljXDQsbECOX1PK4K1odZuyusEh0YjUI7PpM.vse 1ztsxz7MFX5clHk7rPVcDEhrF0KZ0NoMxKKGjiG.6Eqz0LpezIR3zAA-- Received: from [124.43.67.188] by web161904.mail.bf1.yahoo.com via HTTP; Tue, 26 Mar 2013 11:35:02 PDT X-Rocket-MIMEInfo: 002.001, SGkgYWxsCgoKSSBoYXZlIGEgaGVhdmlseSB0aHJlYWRlZCBDIGFwcGxpY2F0aW9uLCBkZXZlbG9wZWQgb24gYW4gSW50ZWwgQ29yZSBpNSBsYXB0b3AgKDIgY29yZXMpIHJ1bm5pbmcgRnJlZUJTRCA4LjEtUkVMRUFTRS4KCldoZW4gdGhpcyBhcHBsaWNhdGlvbiBjb21waWxlIGFuZCBydW4gb24gYW5vdGhlciBJbnRlbCBDb3JlIGk3IGxhcHRvcCAoNCBjb3JlcykgcnVubmluZyBGcmVlQlNEIDkuMS1SRUxFQVNFLCB0aGlzIGFwcGxpY2F0aW9uIGltbWVkaWF0ZWx5IHN0YXJ0cyBncmFiYmluZyBtZW1vcnkgYnkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 Message-ID: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> Date: Tue, 26 Mar 2013 11:35:02 -0700 (PDT) From: Unga Subject: FreeBSD 9.1 excessive memory allocations To: "freebsd-stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Unga List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 18:38:18 -0000 Hi all I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. Both laptops having 4GB RAM. All malloc and free are mutex locked. Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. Appreciate any feedback to identify and fix this issue. Best regards Unga From owner-freebsd-stable@FreeBSD.ORG Tue Mar 26 19:54:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BA7AD19 for ; Tue, 26 Mar 2013 19:54:43 +0000 (UTC) (envelope-from tony.li@tony.li) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by mx1.freebsd.org (Postfix) with ESMTP id 62725A3A for ; Tue, 26 Mar 2013 19:54:43 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta15.emeryville.ca.mail.comcast.net with comcast id GJcb1l0040x6nqcAFKujQM; Tue, 26 Mar 2013 19:54:43 +0000 Received: from [10.66.230.184] ([64.236.139.254]) by omta12.emeryville.ca.mail.comcast.net with comcast id GKsY1l0095VXD0o8YKsaMs; Tue, 26 Mar 2013 19:52:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: FreeBSD 9.1 excessive memory allocations From: Tony Li In-Reply-To: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> Date: Tue, 26 Mar 2013 12:52:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <175E75EE-8E85-49A4-838B-D79CE96CC3C4@tony.li> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> To: Unga X-Mailer: Apple Mail (2.1503) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364327683; bh=oO1qmB+6jX+ZX00qturPBpvoo1kTo2luVB2WLhvXftU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=DuJdBUYH5MP69NAqLGkBq8DNsP1eQl/D3GPUisjlYGpRZEDPUcjjD4lQCFP2Db0Jm BZGEpD2avkwMEesRIepN9WP5V+dp1OzUeQMzOkDntP7xcmx+dJHwiAhFEUOe8Ir68P mytMunR0XH7TDrbrdtV08TSePpR/HEswVinCSVMk28iG/M7RLljJmYIwrrOT+86lrc kXDc5HV6KJC8csyp2nCPi8rM4Lf+KpvGRX6alFyw1afl1NsYtkt/t1NdYI3x6pHoIF OVLBZa6vTBaCDQN2DTfLxjAKISLudFN+GTKMWJth8ZBr0NPaNwaG6dilwZuy1J5SjR Q6x0l6A6Me4QA== Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 19:54:43 -0000 > I have a heavily threaded C application, developed on an Intel Core i5 = laptop (2 cores) running FreeBSD 8.1-RELEASE. >=20 > When this application compile and run on another Intel Core i7 laptop = (4 cores) running FreeBSD 9.1-RELEASE, this application immediately = starts grabbing memory by over 100MB per second and soon exit with not = enough RAM. >=20 >=20 > Both laptops having 4GB RAM. >=20 > All malloc and free are mutex locked. >=20 > Very rarely this problem happens on the i5 (2 cores) laptop too, but = on the i7 laptop, it happens every time. >=20 > Appreciate any feedback to identify and fix this issue. How is this anything except an application issue? Tony From owner-freebsd-stable@FreeBSD.ORG Tue Mar 26 20:08:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A524508 for ; Tue, 26 Mar 2013 20:08:34 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 38BCFB18 for ; Tue, 26 Mar 2013 20:08:34 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id wp1so1796820pac.19 for ; Tue, 26 Mar 2013 13:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BxqM9uiEh8eyFzTHaJwBlx94dynAZaBfxrEn3qyKBGc=; b=HaXiFl9JJsh4fFBZMW/0bnCRTMZdOPwp/XYbZwt076kWIMEndTFQWiwI/2fH1Xctry oUpTtRhIhW8DFjFELnoYXgP5GrxNaC0ds7YupAqK9swkLt3HaH2lJ24JYYDFI1GDMXb8 Ub5ZX7QmHFQo95bDCgwe9osbqsyvfiT+x2uCW0/dw+BIxxYbfete6S3Mv+toPVbgn8uP DqrSr2mJzoYmuEZtHa7+V84FlSwX3YRihar54LsLo+c/80DqdN4Xp3AtXJYraNMoMew2 70lazZzbH47B1/lEhcmRv93aChBgWeUxmRHYWY8IoJZX9N+fPhFguzyNpUX81TAOSMWP p4Hw== MIME-Version: 1.0 X-Received: by 10.66.192.129 with SMTP id hg1mr134738pac.34.1364328513721; Tue, 26 Mar 2013 13:08:33 -0700 (PDT) Received: by 10.68.36.69 with HTTP; Tue, 26 Mar 2013 13:08:33 -0700 (PDT) In-Reply-To: <175E75EE-8E85-49A4-838B-D79CE96CC3C4@tony.li> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <175E75EE-8E85-49A4-838B-D79CE96CC3C4@tony.li> Date: Tue, 26 Mar 2013 22:08:33 +0200 Message-ID: Subject: Re: FreeBSD 9.1 excessive memory allocations From: Alexander Yerenkow To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Unga , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Mar 2013 20:08:34 -0000 2013/3/26 Tony Li > > > I have a heavily threaded C application, developed on an Intel Core i5 > laptop (2 cores) running FreeBSD 8.1-RELEASE. > > > > When this application compile and run on another Intel Core i7 laptop (4 > cores) running FreeBSD 9.1-RELEASE, this application immediately starts > grabbing memory by over 100MB per second and soon exit with not enough RAM. > Sorry, can't remember exactly, but you could search current- or stable- for something like you got. This related IIRC with changes in thread subsystem, so basically each thread will consume now more mem. Search for details, your description is ringing some bell :) > > > > > > Both laptops having 4GB RAM. > > > > All malloc and free are mutex locked. > > > > Very rarely this problem happens on the i5 (2 cores) laptop too, but on > the i7 laptop, it happens every time. > > > > Appreciate any feedback to identify and fix this issue. > > > How is this anything except an application issue? > > Tony > > _______________________________________________ > 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" > -- Regards, Alexander Yerenkow From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 01:26:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF6F93BB for ; Wed, 27 Mar 2013 01:26:03 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail3.transactionware.com [202.68.173.211]) by mx1.freebsd.org (Postfix) with SMTP id 498C5349 for ; Wed, 27 Mar 2013 01:26:02 +0000 (UTC) Received: (qmail 71457 invoked by uid 907); 27 Mar 2013 01:19:20 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (202.68.173.218) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Wed, 27 Mar 2013 12:19:20 +1100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: FreeBSD 9.1 excessive memory allocations From: Jan Mikkelsen In-Reply-To: Date: Wed, 27 Mar 2013 12:19:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <175E75EE-8E85-49A4-838B-D79CE96CC3C4@tony.li> To: Alexander Yerenkow X-Mailer: Apple Mail (2.1503) Cc: Tony Li , "freebsd-stable@freebsd.org" , Unga X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 01:26:03 -0000 On 27/03/2013, at 7:08 AM, Alexander Yerenkow = wrote: > 2013/3/26 Tony Li >=20 >>=20 >>> I have a heavily threaded C application, developed on an Intel Core = i5 >> laptop (2 cores) running FreeBSD 8.1-RELEASE. >>>=20 >>> When this application compile and run on another Intel Core i7 = laptop (4 >> cores) running FreeBSD 9.1-RELEASE, this application immediately = starts >> grabbing memory by over 100MB per second and soon exit with not = enough RAM. >>=20 >=20 > Sorry, can't remember exactly, but you could search current- or = stable- > for something like you got. > This related IIRC with changes in thread subsystem, so basically each > thread will consume now more mem. > Search for details, your description is ringing some bell :) Yes, I remember that too. I think that was linking with libc_r so there = was only one kernel thread in the earlier version, but linked with = -pthread only in 9-whatever leading to an explosion in the number of = kernel threads. Unga: Have you changed linker options? If so, you may have increased the = number of kernel threads, increasing memory requirements. You could = experiment with -lkse instead of -lc_r, and calling = pthread_set_concurrency(). To manage the number of kernel threads. I = haven't tried it, so best of luck. Regards, Jan. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 08:13:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9D45AB3 for ; Wed, 27 Mar 2013 08:13:25 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 7A26DCEF for ; Wed, 27 Mar 2013 08:13:25 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id t11so4972062wey.20 for ; Wed, 27 Mar 2013 01:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=lAm4QDbU7aVV0gxxgeS2GmhCvJ3bBmWg17TykVM9ugI=; b=LLtaPIkIr7HElND57IlL2pLAWqQ4bQwxhMDUe49RqkhXlJTlx1O4r8iqrqJiCAiQT3 TYOr+M2LTdl+LT1AEJP1gGkOyfMMznbco5+xsN/8Bzse1zzdN/qfmb8TIEUjWsnjqakI kWU0zYfKRYzwNTZhmfn13TztTF5wl3IgUldLYUT94F85XXO7eqErXYZU2jWyY8h+YmKX 2bAosm9Q9Gl7mkyDef0XQE5YRC6VJZ1oN9Vpw7fH/ESVr3n2+1fS3930OJsXNUQquGSG LP/f36jaCHEYfzptW15bOPNdmYKaCLop24ixCxJlBMU+fnxAXdTww3tywqIvTO7LRHaI L9vg== MIME-Version: 1.0 X-Received: by 10.180.78.168 with SMTP id c8mr7857320wix.27.1364372004713; Wed, 27 Mar 2013 01:13:24 -0700 (PDT) Received: by 10.194.60.147 with HTTP; Wed, 27 Mar 2013 01:13:24 -0700 (PDT) Date: Wed, 27 Mar 2013 09:13:24 +0100 Message-ID: Subject: SU+J hard recovery failure From: David Demelier To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 08:13:25 -0000 Hello folks, Yesterday I had a panic on my laptop. Unfortunately the SU+J was not able to recovery the file system, the error was something like : Unknown error: Help! Could not find directory 9854215 And it went to the single user mode, I needed to fsck_ufs manually to recover the disk. What afraid me is what if happens on a headless machine? It will be hard to recover. Regards, -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 12:01:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B27DB2DE for ; Wed, 27 Mar 2013 12:01:01 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE2B374 for ; Wed, 27 Mar 2013 12:01:01 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UKp2K-00062m-UV for freebsd-stable@freebsd.org; Wed, 27 Mar 2013 05:01:00 -0700 Date: Wed, 27 Mar 2013 05:01:00 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1364385660939-5799353.post@n5.nabble.com> Subject: libstdc++ not found by clang and base ld on 9-STABLE when building cmake c++ project MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 12:01:01 -0000 Hello, I'm not sure if this is right list, but has anything recently changed which could explain why cmake c++ project (http://sourceforge.net/projects/gemrb/) started to fail upon linking stage (looking like libstdc++ is not included /usr/include/c++/4.2/)? It works normally if passed gcc48 as compiler which subsequently uses (ld) binutils from ports and relevant libstdc++. I have in src.conf- WITH_CLANG_IS_CC=true WITHOUT_GCC=true WITHOUT_CLANG_FULL=true This project was routinely building with clang for me just fine earlier (as well as with gcc47 if told so). I even checked some ancient git tags and I'm positive it's some change in system, as they failed in the same way (no libstdc++ when linking). -- View this message in context: http://freebsd.1045724.n5.nabble.com/libstdc-not-found-by-clang-and-base-ld-on-9-STABLE-when-building-cmake-c-project-tp5799353.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 12:05:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93DAD4E3 for ; Wed, 27 Mar 2013 12:05:24 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC563ED for ; Wed, 27 Mar 2013 12:05:24 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UKp6a-0007uw-3C for freebsd-stable@freebsd.org; Wed, 27 Mar 2013 05:05:24 -0700 Date: Wed, 27 Mar 2013 05:05:24 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1364385924091-5799355.post@n5.nabble.com> In-Reply-To: <1364385660939-5799353.post@n5.nabble.com> References: <1364385660939-5799353.post@n5.nabble.com> Subject: Re: libstdc++ not found by clang and base ld on 9-STABLE when building cmake c++ project MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 12:05:24 -0000 Apart from it, clang looks _very_ c++ capable, as in building boost and rebuilding os (itself) normally, so it doesn't look broken from this point. Just after some rebuild of OS (1-2 weeks ago?) This on git project started to fail upon linking. -- View this message in context: http://freebsd.1045724.n5.nabble.com/libstdc-not-found-by-clang-and-base-ld-on-9-STABLE-when-building-cmake-c-project-tp5799353p5799355.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 14:06:14 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 327EDF99 for ; Wed, 27 Mar 2013 14:06:14 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 0E18D86 for ; Wed, 27 Mar 2013 14:06:14 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UKqzV-000P5T-AQ; Wed, 27 Mar 2013 14:06:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r2RE6A2A011604; Wed, 27 Mar 2013 08:06:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+RnTjTJH0xxX4Y4O9nAf1O Subject: Re: FreeBSD 9.1 excessive memory allocations From: Ian Lepore To: Unga In-Reply-To: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 2013 08:06:10 -0600 Message-ID: <1364393170.36972.49.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 14:06:14 -0000 On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: > Hi all > > > I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. > > When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. > > > Both laptops having 4GB RAM. > > All malloc and free are mutex locked. > > Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. > > Appreciate any feedback to identify and fix this issue. > > Best regards > Unga > Too many moving parts, you need to partition the problem. Is it the change in OS (and especially libraries) that causes the problem, or the change in the number of cores (more concurrent threads) is exposing some sort of application-side race condition? Given the fact that it does occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely an application problem. Perhaps you could use a tool such as valgrind to help track down the runaway allocations? Another way to expose thread race problems is to force more thread context switches. A blunt tool for doing so is to set hz=5000 or even higher in /boot/loader.conf. I've never done that on a desktop or laptop system, only on embedded systems, but it should still work okay. If changing the application code is easier, you can get a similar effect by creating a thread whose only job is to preempt other threads, by using rtprio_thread() to set it to real time priority, then just have it sleep for short random intervals (microseconds), all it does is wakes up and goes right back to sleep. Also, FYI, there's no need to use a mutex in your application to protect allocations. The memory allocator in libc is thread-safe, and in fact is particularly designed for efficient multi-threaded allocation. -- Ian From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 14:15:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BF654F6 for ; Wed, 27 Mar 2013 14:15:16 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id 0F7B8170 for ; Wed, 27 Mar 2013 14:15:16 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Gdga1l0041vN32cACeFF8N; Wed, 27 Mar 2013 14:15:15 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id GeFF1l0011t3BNj8ieFFfq; Wed, 27 Mar 2013 14:15:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DD0E173A1C; Wed, 27 Mar 2013 07:15:14 -0700 (PDT) Date: Wed, 27 Mar 2013 07:15:14 -0700 From: Jeremy Chadwick To: Ian Lepore Subject: Re: FreeBSD 9.1 excessive memory allocations Message-ID: <20130327141514.GA9855@icarus.home.lan> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1364393170.36972.49.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364393715; bh=cpOE2woHnXDN1ebgI0J7SrA59dF0F0Ogkr8rPEy6yrU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=ciLILPknRafy4hO3nZqjhA1XShRh0vtjon3frEqSHft6Vc/tCWuE2exahiNBRF3Ur AIlaIS9TRZq9oDsoowAnSUNdNVsZSsyZzlMruljD0w54dIhecv/ry/T1WejpezUvg0 wJBp+gUsO5c46HzFnIW8g5bJ9an1xxfThm/u2kX0PjHWLN7XpPD0Yu4xKpXxigrbax 7NgOlPl7CgqkbsBdqQhn9/5cXiMSrk2C2499Hta9jvnYP8FH9KNx/bbDjgOLRCLfZD swf45SXYXNtQplvLxsaYeftQMF5/6R69BN2GIPE9uVaBCdUW+Kz6AuetZdaXD1Wq8P SSumMhVVuRsJA== Cc: Unga , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 14:15:16 -0000 On Wed, Mar 27, 2013 at 08:06:10AM -0600, Ian Lepore wrote: > On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: > > Hi all > > > > > > I have a heavily threaded C application, developed on an Intel Core i5 laptop (2 cores) running FreeBSD 8.1-RELEASE. > > > > When this application compile and run on another Intel Core i7 laptop (4 cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing memory by over 100MB per second and soon exit with not enough RAM. > > > > > > Both laptops having 4GB RAM. > > > > All malloc and free are mutex locked. > > > > Very rarely this problem happens on the i5 (2 cores) laptop too, but on the i7 laptop, it happens every time. > > > > Appreciate any feedback to identify and fix this issue. > > > > Best regards > > Unga > > > > Too many moving parts, you need to partition the problem. Is it the > change in OS (and especially libraries) that causes the problem, or the > change in the number of cores (more concurrent threads) is exposing some > sort of application-side race condition? Given the fact that it does > occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely > an application problem. > > Perhaps you could use a tool such as valgrind to help track down the > runaway allocations? > > Another way to expose thread race problems is to force more thread > context switches. A blunt tool for doing so is to set hz=5000 or even > higher in /boot/loader.conf. I've never done that on a desktop or > laptop system, only on embedded systems, but it should still work okay. > If changing the application code is easier, you can get a similar effect > by creating a thread whose only job is to preempt other threads, by > using rtprio_thread() to set it to real time priority, then just have it > sleep for short random intervals (microseconds), all it does is wakes up > and goes right back to sleep. > > Also, FYI, there's no need to use a mutex in your application to protect > allocations. The memory allocator in libc is thread-safe, and in fact > is particularly designed for efficient multi-threaded allocation. Thank you Ian -- you've covered nearly all of the points I wanted to mention in a reply, but opted to not send it (one of those "after I read it I had second thoughts" situations). For the OP: I *strongly* recommend ports/devel/valgrind as mentioned. It can be a little bit daunting getting started with it ("okay, wow, what am I doing with this thing?"), but it's very useful for situations exactly like this. There's lots of random tidbits of info on it on the web too. If the issue turns out to be something in userland (library-wise) or the kernel, there are FreeBSD.org people who can help with those (I can think of 4 off the top of my head right now). They can be CC'd if things get to that point, but exhaust other avenues first. It would also be wise, at that time, if you could make the source to the application available, that would probably help folks narrow down what's happening -- otherwise they'll be forced to rely entirely on claims like "it *should* be behaving like this", which isn't necessarily the same thing as how the underlying code bits actually behave. My impression as of this writing, is that the problem is in the application. If FreeBSD 9.1 had major problems with memory leaks in userland threaded apps, I'd expect it would have been discovered by now; that said, there is always the chance there is a bug somewhere outside of your application code, it just seems slim. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 18:33:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 101DC5FB for ; Wed, 27 Mar 2013 18:33:53 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by mx1.freebsd.org (Postfix) with SMTP id B74095EA for ; Wed, 27 Mar 2013 18:33:52 +0000 (UTC) Received: from [98.139.215.142] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 18:33:46 -0000 Received: from [98.139.212.251] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 18:33:46 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 18:33:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 792227.67692.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 52094 invoked by uid 60001); 27 Mar 2013 18:33:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364409226; bh=WFtnnDSfjN3M4t9fQfAMEFjNeVjDkELGMnZ52zao7EE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kClBp80Hdl029DgefobTxu0S+0+Sk0QUVSJ8GvpofZYGG0E4q+FiEDcffRiTJanN9j1hIwWEprVHDKVL/9oj+Kb1eEbbvidfaG7LXy+vLDz/eZNiql0tMN2INFe44b/WiN4CrW1TAsATJ0MG77TT+K6ylNeuavv6r/bQmEdFAEo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vApUcNamtqfzwWzomxpCgMYXd4aouVVR5lxigLZGQVKu/b5mE4I7J1mLcvI2JUcAj7ok+5SRPeVKGXArFU6xh3YNNKRMCrRdJHlqB+OYGQusZL1Rm/ctGOfOJxQfxk9b2CPVraG201MwXcvaYkWs/5W8vTSJFrXFwi+n7Mi3LPg=; X-YMail-OSG: rkwxvyEVM1nuJi1Q.yhWDKULqzxFa4rXo6czW0efGe7cU.f kC9.e__oIwDlov2zFIo1_0k573CqLEJ_I9E3FZGEIDfOlPLSPJFOJHhzHNCw 4WPnFPKY3k2WCUneYwWzIRF1D5dCTeY_LE06uToMz4T8301_ib__e08JOA25 rQ_v6KbOtTQTfZUE7EQNhKWX9ZH9eMEmbGFIcdSHnPSkwu.UmyQ4SpQ4qzXk Hf_b1OXZnKXPTfRCtqpk.A8Joc42LninBqr5.p2PDSjLvn2shyWhr.dXxlw0 V5JigUPuxpsnhPdsaoCJSMXqiYJRX.POZZ50k9mqGe8ziKrH2lwhaiW_TmFU P79MzhH.3bQSPVsyj164yNKYtBagATe0a7d6pSwI2z6EoTbNGbf1g1BJeRNs bOk024Sy.7CFweZeY8AjacJ2SHd_INoxepaDVOrZDHY.WKRczpYrx1T69C_8 wufpvoBtFQW.29w2tGwM8PDL7KM9BJ8jiwIMeCZX_ClVIaYvNyQ7pG_MKxFg nOeEDZ1Di6RA.mg8CXA-- Received: from [112.134.135.82] by web161906.mail.bf1.yahoo.com via HTTP; Wed, 27 Mar 2013 11:33:46 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCgo.IEZyb206IElhbiBMZXBvcmUgPGlhbkBGcmVlQlNELm9yZz4KPiBUbzogVW5nYSA8dW5nYTg4OEB5YWhvby5jb20.Cj4gQ2M6ICJmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyIgPGZyZWVic2Qtc3RhYmxlQEZyZWVCU0Qub3JnPgo.IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjcsIDIwMTMgMjowNiBQTQo.IFN1YmplY3Q6IFJlOiBGcmVlQlNEIDkuMSBleGNlc3NpdmUgbWVtb3J5IGFsbG9jYXRpb25zCj4gCj4gT24gVHVlLCAyMDEzLTAzLTI2IGF0IDEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> Message-ID: <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Wed, 27 Mar 2013 11:33:46 -0700 (PDT) From: Unga Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] To: Ian Lepore In-Reply-To: <1364393170.36972.49.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Unga List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:33:53 -0000 =0A=0A----- Original Message -----=0A=0A> From: Ian Lepore =0A> To: Unga =0A> Cc: "freebsd-stable@freebsd.org" =0A> Sent: Wednesday, March 27, 2013 2:06 PM=0A> S= ubject: Re: FreeBSD 9.1 excessive memory allocations=0A> =0A> On Tue, 2013-= 03-26 at 11:35 -0700, Unga wrote:=0A>> Hi all=0A>> =0A>> =0A>> I have a h= eavily threaded C application, developed on an Intel Core i5 =0A> laptop (2= cores) running FreeBSD 8.1-RELEASE.=0A>> =0A>> When this application comp= ile and run on another Intel Core i7 laptop (4 =0A> cores) running FreeBSD = 9.1-RELEASE, this application immediately starts grabbing =0A> memory by ov= er 100MB per second and soon exit with not enough RAM.=0A>> =0A>> =0A>> Bo= th laptops having 4GB RAM.=0A>> =0A>> All malloc and free are mutex locked= .=0A>> =0A>> Very rarely this problem happens on the i5 (2 cores) laptop t= oo, but on the =0A> i7 laptop, it happens every time.=0A>> =0A>> Appreciat= e any feedback to identify and fix this issue.=0A>> =0A>> Best regards=0A>= > Unga=0A>> =0A> =0A> Too many moving parts, you need to partition the pro= blem.=A0 Is it the=0A> change in OS (and especially libraries) that causes = the problem, or the=0A> change in the number of cores (more concurrent thre= ads) is exposing some=0A> sort of application-side race condition?=A0 Given= the fact that it does=0A> occur on 2 cores + freebsd 8.1, even if more rar= ely, it's almost surely=0A> an application problem.=A0 =0A> =0A> Perhaps yo= u could use a tool such as valgrind to help track down the=0A> runaway allo= cations?=0A> =0A> Another way to expose thread race problems is to force mo= re thread=0A> context switches.=A0 A blunt tool for doing so is to set hz= =3D5000 or even=0A> higher in /boot/loader.conf.=A0 I've never done that on= a desktop or=0A> laptop system, only on embedded systems, but it should st= ill work okay.=0A> If changing the application code is easier, you can get = a similar effect=0A> by creating a thread whose only job is to preempt othe= r threads, by=0A> using rtprio_thread() to set it to real time priority, th= en just have it=0A> sleep for short random intervals (microseconds), all it= does is wakes up=0A> and goes right back to sleep.=0A> =0A> Also, FYI, the= re's no need to use a mutex in your application to protect=0A> allocations.= =A0 The memory allocator in libc is thread-safe, and in fact=0A> is particu= larly designed for efficient multi-threaded allocation.=0A> =0A> -- Ian=0A>= =0A=0ADear Tony, Alexander, Jan, Ian and Jeremy=0A=0AThank you very much fo= r your very valuable comments.=0A=0AProblem seems to be solved. But require= more testing.=0A=0A1. Fixed an application-level crucial bug. This is near= ly a 7000 lines C app. It was really hard to see as the application is desi= gned with 8 dedicated threads.=0A=0A2. At run-time, this application shoots= up to about 400 dynamic threads on the i7 machine, whereas on the i5 machi= ne, it only shoots up 57 dynamic threads. It was bit scaring, therefore, ma= de a hard limit on total number of threads to 64.=0A=0ARegarding mutex lock= s on allocations, as per the malloc(3), it says small and medium size alloc= ations are done from per thread caches, therefore, thread-safe. My allocati= ons are large in nature, about 5-7MB.=0A=0ABest regards=0AUnga From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 18:53:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 13A9FBE4; Wed, 27 Mar 2013 18:53:56 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id 7780071D; Wed, 27 Mar 2013 18:53:55 +0000 (UTC) Received: from cpsps-ews16.kpnxchange.com ([10.94.84.197]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 27 Mar 2013 19:52:47 +0100 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews16.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 27 Mar 2013 19:52:47 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 27 Mar 2013 19:52:45 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id A42D541; Wed, 27 Mar 2013 19:52:45 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Ian Lepore" , Unga Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Wed, 27 Mar 2013 19:52:45 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> User-Agent: Opera Mail/12.14 (FreeBSD) X-OriginalArrivalTime: 27 Mar 2013 18:52:45.0550 (UTC) FILETIME=[44E8A8E0:01CE2B1C] X-RcptDomain: freebsd.org Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 18:53:56 -0000 On Wed, 27 Mar 2013 19:33:46 +0100, Unga wrote: > > > ----- Original Message ----- > >> From: Ian Lepore >> To: Unga >> Cc: "freebsd-stable@freebsd.org" >> Sent: Wednesday, March 27, 2013 2:06 PM >> Subject: Re: FreeBSD 9.1 excessive memory allocations >> >> On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: >>> Hi all >>> >>> >>> I have a heavily threaded C application, developed on an Intel Core i5 >> laptop (2 cores) running FreeBSD 8.1-RELEASE. >>> >>> When this application compile and run on another Intel Core i7 laptop >>> (4 >> cores) running FreeBSD 9.1-RELEASE, this application immediately starts >> grabbing >> memory by over 100MB per second and soon exit with not enough RAM. >>> >>> >>> Both laptops having 4GB RAM. >>> >>> All malloc and free are mutex locked. >>> >>> Very rarely this problem happens on the i5 (2 cores) laptop too, but >>> on the >> i7 laptop, it happens every time. >>> >>> Appreciate any feedback to identify and fix this issue. >>> >>> Best regards >>> Unga >>> >> >> Too many moving parts, you need to partition the problem. Is it the >> change in OS (and especially libraries) that causes the problem, or the >> change in the number of cores (more concurrent threads) is exposing some >> sort of application-side race condition? Given the fact that it does >> occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely >> an application problem. >> Perhaps you could use a tool such as valgrind to help track down the >> runaway allocations? >> >> Another way to expose thread race problems is to force more thread >> context switches. A blunt tool for doing so is to set hz=5000 or even >> higher in /boot/loader.conf. I've never done that on a desktop or >> laptop system, only on embedded systems, but it should still work okay. >> If changing the application code is easier, you can get a similar effect >> by creating a thread whose only job is to preempt other threads, by >> using rtprio_thread() to set it to real time priority, then just have it >> sleep for short random intervals (microseconds), all it does is wakes up >> and goes right back to sleep. >> >> Also, FYI, there's no need to use a mutex in your application to protect >> allocations. The memory allocator in libc is thread-safe, and in fact >> is particularly designed for efficient multi-threaded allocation. >> >> -- Ian >> > > Dear Tony, Alexander, Jan, Ian and Jeremy > > Thank you very much for your very valuable comments. > > Problem seems to be solved. But require more testing. > > 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C > app. It was really hard to see as the application is designed with 8 > dedicated threads. > > 2. At run-time, this application shoots up to about 400 dynamic threads > on the i7 machine, whereas on the i5 machine, it only shoots up 57 > dynamic threads. It was bit scaring, therefore, made a hard limit on > total number of threads to 64. > > Regarding mutex locks on allocations, as per the malloc(3), it says > small and medium size allocations are done from per thread caches, > therefore, thread-safe. My allocations are large in nature, about 5-7MB. The per thread caches are for speed. Not for thread-safety. Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 19:02:06 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9CB2D144 for ; Wed, 27 Mar 2013 19:02:06 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 754C37C9 for ; Wed, 27 Mar 2013 19:02:06 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UKvbp-000KwX-KU; Wed, 27 Mar 2013 19:02:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r2RJ23cS011895; Wed, 27 Mar 2013 13:02:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+7hAWijS6JeHCKOoCk77Ln Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] From: Ian Lepore To: Unga In-Reply-To: <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 2013 13:02:03 -0600 Message-ID: <1364410923.36972.67.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 19:02:06 -0000 On Wed, 2013-03-27 at 11:33 -0700, Unga wrote: > > ----- Original Message ----- > > > From: Ian Lepore > > To: Unga > > Cc: "freebsd-stable@freebsd.org" > > Sent: Wednesday, March 27, 2013 2:06 PM > > Subject: Re: FreeBSD 9.1 excessive memory allocations > > > > On Tue, 2013-03-26 at 11:35 -0700, Unga wrote: > >> Hi all > >> > >> > >> I have a heavily threaded C application, developed on an Intel Core i5 > > laptop (2 cores) running FreeBSD 8.1-RELEASE. > >> > >> When this application compile and run on another Intel Core i7 laptop (4 > > cores) running FreeBSD 9.1-RELEASE, this application immediately starts grabbing > > memory by over 100MB per second and soon exit with not enough RAM. > >> > >> > >> Both laptops having 4GB RAM. > >> > >> All malloc and free are mutex locked. > >> > >> Very rarely this problem happens on the i5 (2 cores) laptop too, but on the > > i7 laptop, it happens every time. > >> > >> Appreciate any feedback to identify and fix this issue. > >> > >> Best regards > >> Unga > >> > > > > Too many moving parts, you need to partition the problem. Is it the > > change in OS (and especially libraries) that causes the problem, or the > > change in the number of cores (more concurrent threads) is exposing some > > sort of application-side race condition? Given the fact that it does > > occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely > > an application problem. > > > > Perhaps you could use a tool such as valgrind to help track down the > > runaway allocations? > > > > Another way to expose thread race problems is to force more thread > > context switches. A blunt tool for doing so is to set hz=5000 or even > > higher in /boot/loader.conf. I've never done that on a desktop or > > laptop system, only on embedded systems, but it should still work okay. > > If changing the application code is easier, you can get a similar effect > > by creating a thread whose only job is to preempt other threads, by > > using rtprio_thread() to set it to real time priority, then just have it > > sleep for short random intervals (microseconds), all it does is wakes up > > and goes right back to sleep. > > > > Also, FYI, there's no need to use a mutex in your application to protect > > allocations. The memory allocator in libc is thread-safe, and in fact > > is particularly designed for efficient multi-threaded allocation. > > > > -- Ian > > > > Dear Tony, Alexander, Jan, Ian and Jeremy > > Thank you very much for your very valuable comments. > > Problem seems to be solved. But require more testing. > > 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C app. It was really hard to see as the application is designed with 8 dedicated threads. > > 2. At run-time, this application shoots up to about 400 dynamic threads on the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic threads. It was bit scaring, therefore, made a hard limit on total number of threads to 64. > > Regarding mutex locks on allocations, as per the malloc(3), it says small and medium size allocations are done from per thread caches, therefore, thread-safe. My allocations are large in nature, about 5-7MB. > > Best regards > Unga I think you may be reading too much into the malloc manpage. When it mentions the use of per-thread small-object caches to avoid locking it's talking about performance, not thread safety. Allocations of all sizes are thread-safe, the library just assumes that huge allocations are rare enough that it doesn't use extra per-thread resources to avoid locking for them, it just uses locking for huge blocks. -- Ian From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 21:22:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C0442CA; Wed, 27 Mar 2013 21:22:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 02D281AF; Wed, 27 Mar 2013 21:22:18 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id r16so942618ead.34 for ; Wed, 27 Mar 2013 14:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=MTlu+UZE3yX57RtzoQ2geUxJlRwzGO2jEHD+sFXp0OY=; b=WJCxkl2Jk4UBSYzIVxhX9x/4MJ2+k8TtI9W8oacE/6YedYwpMwBf5hZvSRSAG0BXxu BJ/30KU6kqSbwK3v95AuzkrRYPxxIx+RAAceLdkLUMYyM+q0vS9IQzAPgqK55RI4QkDo jUatO4FOhNZKrH3fkV/8jlUmOy8lExQWVGBIqv8khlw09upONUw2Djt2h9k9p17ZZdB7 q/YPmb4HHhMxtWR0YRY3vuq+7tl51FDQQ0pvL5TpZs/pGmLlTt79Xq+yQUTZNeUR60rx OsC3c5bYH+1M4t6ssOIlZdGS2AM9cc2nDT4hwWUVHPvnypa6++RuHyCoiSMzpyshRChh gg1g== X-Received: by 10.15.36.135 with SMTP id i7mr39357547eev.34.1364419338167; Wed, 27 Mar 2013 14:22:18 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id h5sm33867550eem.1.2013.03.27.14.22.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 14:22:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <51536306.5030907@FreeBSD.org> Date: Wed, 27 Mar 2013 23:22:14 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Any objections/comments on axing out old ATA stack? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 21:22:19 -0000 Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 21:32:48 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A1C0ACC; Wed, 27 Mar 2013 21:32:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC99274; Wed, 27 Mar 2013 21:32:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2RLWgZ5067899; Wed, 27 Mar 2013 14:32:42 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2RLWgDb067898; Wed, 27 Mar 2013 14:32:42 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Mar 2013 14:32:42 -0700 From: Steve Kargl To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130327213242.GA67876@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51536306.5030907@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 21:32:48 -0000 On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Yes, I use the legacy ATA stack. > Does anybody have good ideas why we should not drop > it now? Because it works? -- Steve From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 21:35:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F16FD02; Wed, 27 Mar 2013 21:35:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 874162B0; Wed, 27 Mar 2013 21:35:39 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id q14so1277741eaj.36 for ; Wed, 27 Mar 2013 14:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5Pjf4xUI6LXyQJOAE3BPcpHJpsONYfX76qISjUgI0go=; b=jAig+KYkeWbaa5aIkgoSeiC5/1EzomU0KTBnAiUPELIksc4ylMvF+ITbt9rEXnsBE+ n8SneM8hNBPJsNB7jNkohYRBjkxG8B7Vi8LWtgj86UXxCSj5T1ojXNtEupSolH9/pRRg HoayXc7Yl0cpN0/YDsifRKIGeRtSuPe3++0ukYkVLH3d9129SfsYukCxtn1hZhjVu5CS B2tT9iOUeSJcgiQes/XzJ2fdw1I5zKHM017xk8ickm4Ay5SNNHl8bmGLGApQqG2G8cYg 4sOxyQpjrsjGY9wOQNJLH566bNXWa/iEkptD8L0YUtfW8BBxXO3S/jbK1wuMVuG3GfCo 5OpA== X-Received: by 10.15.23.193 with SMTP id h41mr60107376eeu.17.1364420138641; Wed, 27 Mar 2013 14:35:38 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id d47sm33895142eem.9.2013.03.27.14.35.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 14:35:37 -0700 (PDT) Sender: Alexander Motin Message-ID: <51536627.7090005@FreeBSD.org> Date: Wed, 27 Mar 2013 23:35:35 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> In-Reply-To: <20130327213242.GA67876@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 21:35:40 -0000 On 27.03.2013 23:32, Steve Kargl wrote: > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >> Hi. >> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >> stack, using only some controller drivers of old ata(4) by having >> `options ATA_CAM` enabled in all kernels by default. I have a wish to >> drop non-ATA_CAM ata(4) code, unused since that time from the head >> branch to allow further ATA code cleanup. >> >> Does any one here still uses legacy ATA stack (kernel explicitly built >> without `options ATA_CAM`) for some reason, for example as workaround >> for some regression? > > Yes, I use the legacy ATA stack. On 9.x or HEAD where new one is default? >> Does anybody have good ideas why we should not drop >> it now? > > Because it works? Any problems with new one? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 21:38:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 34E14F2E; Wed, 27 Mar 2013 21:38:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id CB9052E6; Wed, 27 Mar 2013 21:38:05 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id d10so3246411qca.9 for ; Wed, 27 Mar 2013 14:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8l2hnzsiGPYkT/lBsqaD4YPEoz/05Lntri6kz1olZN0=; b=ECvu2JCx1phA0VTOZrC8PfeOGkUkU2DTt1wkjToWE0MdyqfsFpemnvCkxj+/ETmI2c dgu8Oi2SPd/EzjXhMnJ0Lhl1ZwKkq802BWRDVdMZHJTOx2ZnEMI3UpmMeA/SKXhDDUFJ 6B90OC+Q/L1GU6ckT2zIQaB1llYVrP1olvSXkbzKjgsCNkC078KawhXy50AEw8iimnHU mSGg4MA0aeaREbjeBKGmm+vJEIxLnoKUxh6f0TZwiZndK2+MTbyhTHOkqpg9LDWcVUxn qNOUQUPTP9qZsMgbedWohsCG4kctVMfxwcE+ay2Bb9WH80oZ6ZGAXsLIdMlXs/eRdsPI e2OA== MIME-Version: 1.0 X-Received: by 10.49.118.137 with SMTP id km9mr17683224qeb.34.1364420285394; Wed, 27 Mar 2013 14:38:05 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Wed, 27 Mar 2013 14:38:05 -0700 (PDT) In-Reply-To: <20130327213242.GA67876@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> Date: Wed, 27 Mar 2013 14:38:05 -0700 Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Freddie Cash To: Steve Kargl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Motin , FreeBSD-Current , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 21:38:06 -0000 On Wed, Mar 27, 2013 at 2:32 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > > Hi. > > > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > > stack, using only some controller drivers of old ata(4) by having > > `options ATA_CAM` enabled in all kernels by default. I have a wish to > > drop non-ATA_CAM ata(4) code, unused since that time from the head > > branch to allow further ATA code cleanup. > > > > Does any one here still uses legacy ATA stack (kernel explicitly built > > without `options ATA_CAM`) for some reason, for example as workaround > > for some regression? > > Yes, I use the legacy ATA stack. > > You're missing the reason for why you're running the old ATA stack. Do you have hardware that doesn't work with ATA_CAM? Have you not tried ATA_CAM on that box? Some other reason? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 22:05:14 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D638A7CA; Wed, 27 Mar 2013 22:05:14 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id A2357634; Wed, 27 Mar 2013 22:05:14 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2RM5ETw068095; Wed, 27 Mar 2013 15:05:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2RM5Eov068094; Wed, 27 Mar 2013 15:05:14 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Mar 2013 15:05:14 -0700 From: Steve Kargl To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130327220514.GA68064@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> <51536627.7090005@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51536627.7090005@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 22:05:14 -0000 On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote: > On 27.03.2013 23:32, Steve Kargl wrote: > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? > > > > Yes, I use the legacy ATA stack. > > On 9.x or HEAD where new one is default? Head. > >> Does anybody have good ideas why we should not drop > >> it now? > > > > Because it works? > > Any problems with new one? > Last time I tested the new one, and this was several months ago, the system (a Dell Latitude D530 laptop) would not boot. -- Steve From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 22:22:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 814C3D4E; Wed, 27 Mar 2013 22:22:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id E84FA70C; Wed, 27 Mar 2013 22:22:20 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id h10so3727313eaj.35 for ; Wed, 27 Mar 2013 15:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n0ILBAJEmYbSebiH5E2NvzEIyIZJLagZ2UlCP0JUtPQ=; b=bE/qe0cuopf6flXjvatl/TZSxCGIBzdnQkqxz3D4pEBfSM7SuXkaMKTLhFKi9yxWpT mq6I2VASwx2bLuWWtoysndKVrX1uroYMhbPBakq2y4QNrjO6EaPwHFsX4BXXsrvNGESW W7BclSdwcUbjUKLRozzEJNpoeD2cogBV9ROgpE7tV0PONRJqmFCR3WitOVYykJngeDtO ZktGt0nkGQx4/QBWzFZf2E5KVu4InNRYYUEuQgvB1qmOgJ8xzlNQgSu+CP4mhy08ktc6 FR7kpiHNfLt2DARyLxJmaw3SJOjSt10AK9uBV0JO32y64vUQ9EECuaHV4ItjNT5fMsqB xs4w== X-Received: by 10.14.179.5 with SMTP id g5mr60308104eem.41.1364422939559; Wed, 27 Mar 2013 15:22:19 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id t4sm34133642eel.0.2013.03.27.15.22.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 15:22:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <51537113.6080406@FreeBSD.org> Date: Thu, 28 Mar 2013 00:22:11 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> <51536627.7090005@FreeBSD.org> <20130327220514.GA68064@troutmask.apl.washington.edu> In-Reply-To: <20130327220514.GA68064@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 22:22:21 -0000 On 28.03.2013 00:05, Steve Kargl wrote: > On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote: >> On 27.03.2013 23:32, Steve Kargl wrote: >>> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >>>> Hi. >>>> >>>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >>>> stack, using only some controller drivers of old ata(4) by having >>>> `options ATA_CAM` enabled in all kernels by default. I have a wish to >>>> drop non-ATA_CAM ata(4) code, unused since that time from the head >>>> branch to allow further ATA code cleanup. >>>> >>>> Does any one here still uses legacy ATA stack (kernel explicitly built >>>> without `options ATA_CAM`) for some reason, for example as workaround >>>> for some regression? >>> >>> Yes, I use the legacy ATA stack. >> >> On 9.x or HEAD where new one is default? > > Head. > >>>> Does anybody have good ideas why we should not drop >>>> it now? >>> >>> Because it works? >> >> Any problems with new one? >> > > Last time I tested the new one, and this was several months > ago, the system (a Dell Latitude D530 laptop) would not boot. Probably we should just fix that. Any more info? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 27 22:43:07 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6227C2DC; Wed, 27 Mar 2013 22:43:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4566A800; Wed, 27 Mar 2013 22:43:07 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2RMh6G1068345; Wed, 27 Mar 2013 15:43:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2RMh6uF068344; Wed, 27 Mar 2013 15:43:06 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Mar 2013 15:43:06 -0700 From: Steve Kargl To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130327224306.GA68321@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> <51536627.7090005@FreeBSD.org> <20130327220514.GA68064@troutmask.apl.washington.edu> <51537113.6080406@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51537113.6080406@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Mar 2013 22:43:07 -0000 On Thu, Mar 28, 2013 at 12:22:11AM +0200, Alexander Motin wrote: > On 28.03.2013 00:05, Steve Kargl wrote: > > > > Last time I tested the new one, and this was several months > > ago, the system (a Dell Latitude D530 laptop) would not boot. > > Probably we should just fix that. Any more info? > I can't remember all the details. I intended to try again as work was being done on the new code at the time. I never got around to it as my laptop worked fine with the old code and unfortunately I got busy with work and family. Reading the freebsd-current mailing lists suggests that now is not the time to be a hero. -- Steve From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 00:36:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6AEDC861 for ; Thu, 28 Mar 2013 00:36:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C292ECB9 for ; Thu, 28 Mar 2013 00:36:21 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.55]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2S0ZxoE094946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Mar 2013 11:06:04 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Content-Type: multipart/signed; boundary="Apple-Mail=_E31A0EDE-A1E8-4A37-B7B3-6540134ED15E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: SU+J hard recovery failure From: "Daniel O'Connor" In-Reply-To: Date: Thu, 28 Mar 2013 11:05:58 +1030 Message-Id: References: To: David Demelier X-Mailer: Apple Mail (2.1503) X-Spam-Score: -3.051 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 00:36:22 -0000 --Apple-Mail=_E31A0EDE-A1E8-4A37-B7B3-6540134ED15E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27/03/2013, at 18:43, David Demelier = wrote: > Yesterday I had a panic on my laptop. Unfortunately the SU+J was not > able to recovery the file system, the error was something like : >=20 > Unknown error: Help! > Could not find directory 9854215 >=20 > And it went to the single user mode, I needed to fsck_ufs manually to > recover the disk. What afraid me is what if happens on a headless > machine? It will be hard to recover. For headless remote systems I use fsck_y_enable=3D"YES". In my experience 'fsck -y' almost invariably recovers the disk to a = point where it can boot and then I can login remotely. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_E31A0EDE-A1E8-4A37-B7B3-6540134ED15E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINWTCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHHTCCBgWg AwIBAgIDBHnoMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwNzA1MDIyMTI5WhcNMTMwNzA2MTU1NDQ5WjBhMRkwFwYDVQQNExBtdW11Rmk0OXh3cGRrUWh3 MR4wHAYDVQQDDBVkb2Nvbm5vckBnc29mdC5jb20uYXUxJDAiBgkqhkiG9w0BCQEWFWRvY29ubm9y QGdzb2Z0LmNvbS5hdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANLhGSNBVp7lteWC Kgmh5gw0Z7wnwJqESu3IYZ885kbCP4lMpZwQv9GOVDCqPuuVUzY+K3kwaf91g/kz2oRcU+bw1bpY iOvwMzwPD1V3hZ7r8NNToUdT/VKQRTVcAP9/Cr4NYekyVTehQZ7GGF7cyqXKvMpOHriW7KzNq7R0 p6eJ2uadOL5VPY+uTsVjmizQlFMl+My34vgkQ1Wo765MRjzHzwvpmWiqHrgjpvJL33bmgHB2ZtbG KcQ55Ze2T2ysAsa+SoDBwYC+8uBhuFtdSl0/Nm2q1eZBFNamCmGzpEjVDQPlAxhOwjde15WMsJPB mTibsOer4LN8cN0XfeBqKrMCAwEAAaOCA7AwggOsMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUGrouPvtucJ95hJDEw/MyVdgH 2JowHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIAYDVR0RBBkwF4EVZG9jb25ub3JA Z3NvZnQuY29tLmF1MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYB BQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcW IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRl IHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1l bnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRl bmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlv bnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJM ZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQv MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t LzANBgkqhkiG9w0BAQUFAAOCAQEAgT50PcSRWSCNYUsBvFh33Iku7Us501FqkCqN2YcnwULjz1z1 9f9BXQd6EpyUpAGjpoclBh8NCwaezXIXbp6qMktLBvoRNiH+dd1HtefqPQ7b4rt5LrS3vrptaVWa Qiqmxg/sFdQ20uNGpXYlUDoIHRoD4DT7oa9n45eLjE3S8Jw2RZO2y0Ve3HZvwpQOkTbYsESBHZmh szYsOHd5kZH1S573LlMffbH1IztIBtx8ozlyT4io3T5e4GJBro1jSepC3oIaqpwnDOzQqdnoPNHd QUxlI0YlhAaYUC9bNNfHJtQo7jyYhQcTK/MGYeJ6NJa5A+6BQWrZhHl7v/OOlaxwyjGCA28wggNr AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwR56DAJBgUrDgMCGgUAoIIBrzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMjgwMDM1NTlaMCMG CSqGSIb3DQEJBDEWBBRUqJFEaMAcR4Cu4ThI8o6TsOG/bTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwR56DCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBHnoMA0GCSqGSIb3DQEBAQUABIIBAFncKG/zoTMX 8+IhdursLRYXyXtFUO36WN1tyL7zFU9mfY/TQEKKufLRDDgwq0AkX1lpLhKUTc9eKLqNN+JBJnl4 kBLLfGFsN/Tm4HcOC8zL6c1bPCapK3GqebHHZFSRsyfSPVn2xxLNQQzb6GOW3fc2nJ0ri/8zTMm6 ttHcAQ0q2LUr+TUHK/T1F8lhjGz530Wu49ZD+Ba/Kxyx/EdiWs5OCt/2waoenzZ+HI9imYEUpGjY innunSsRYQ3ArZu3m9nqwbBAFU4PuPxQP9P+T+4DaQ28SvXI5M/8CcfnB1J7cZGTIQjVPXzddoQN FXZ/Dou+EpupW6WMWBhZqq8wFAUAAAAAAAA= --Apple-Mail=_E31A0EDE-A1E8-4A37-B7B3-6540134ED15E-- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 00:43:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3AD7CAD7; Thu, 28 Mar 2013 00:43:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF7AD0E; Thu, 28 Mar 2013 00:43:08 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so2922217wib.3 for ; Wed, 27 Mar 2013 17:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ivtuaT2yM1fc6t7KWtfse8XM2dZ63RCxv6d7jOoPtT4=; b=Hln6Zgx3FTz1+hXq18bR8jQHlO80dauPPLSVQnj9kUcLiV4a31JYM6HsiloSnS6s6h TaykxWochrB6BK+SWWfGfs+VwsnEEHrMq+1KqYEzdWtZSi9+XWD9zHBNO7ZlUyvlqUhm siNNSHH49Dkdz3A43LMJUBwJTYq6gh1alWwtxCvFSfbcfymOsdHSSaqpUuRI7bxCpZpO 9H0Qbv7cvaI02/etPDzigZ6y9I+fWbEp15YEPBOU4sRm4cbUPrJzvuq2r713kbGwxhs1 9So08Q/g+WvmQO5zjoATzpwijq7lxXzVgFHenBfZRz/vZ7t1pksw2eKJ7I5YyCDxquWC dp1A== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr13092100wic.29.1364431387607; Wed, 27 Mar 2013 17:43:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 27 Mar 2013 17:43:07 -0700 (PDT) In-Reply-To: <51536306.5030907@FreeBSD.org> References: <51536306.5030907@FreeBSD.org> Date: Wed, 27 Mar 2013 17:43:07 -0700 X-Google-Sender-Auth: 2YHBwHaFP9ql5MKmHWlQbxxp-io Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 00:43:09 -0000 My main concern with the new stuff is that it requires CAM and that's reasonably big compared to the standalone ATA code. It'd be nice if we could slim down the CAM stack a bit first; it makes embedding it on the smaller devices really freaking painful. Thanks, adrian From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 03:30:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 50D08E22 for ; Thu, 28 Mar 2013 03:30:29 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCD45E3 for ; Thu, 28 Mar 2013 03:30:28 +0000 (UTC) Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail05.adl6.internode.on.net with ESMTP; 28 Mar 2013 13:59:51 +1030 Message-ID: <5153B91C.8050105@ShaneWare.Biz> Date: Thu, 28 Mar 2013 13:59:32 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: Request for heimdal update to stable/releng Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 03:30:29 -0000 While looking into an issue with security/heimdal I found that v1.5.2 of heimdal has been in HEAD for 11 months and has had 2 small fixes in that time. Now that I look at it these two fixes should probably be duplicated to the port as well. This update has yet to be copied down to stable or releng branches, leaving releng with v1.1 which is over 5 years old. The issue I found in the ports version (pr/177397) appears to still exist in HEAD - while the hcrypto lib included is not used the man pages are still installed. Some of these man pages have the same names as openssl man pages. As openssl is used the hcrypto man pages don't need to be installed. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 05:39:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFE79501 for ; Thu, 28 Mar 2013 05:39:22 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from nm4-vm0.bullet.mail.bf1.yahoo.com (nm4-vm0.bullet.mail.bf1.yahoo.com [98.139.213.129]) by mx1.freebsd.org (Postfix) with SMTP id 93C6F957 for ; Thu, 28 Mar 2013 05:39:22 +0000 (UTC) Received: from [98.139.215.141] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 28 Mar 2013 05:39:16 -0000 Received: from [98.139.212.207] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 28 Mar 2013 05:39:16 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 28 Mar 2013 05:39:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 583399.47248.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 50897 invoked by uid 60001); 28 Mar 2013 05:39:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364449156; bh=W1lL8/UaPbZI72IbCdyDxdAMMyy7sDTQMM2FIiAP4BU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6k03cRnMA00nxDcRWeELQ8+gwhLTgQWjC35eiALfhRdOmWIezfL8GFZK1bg7OHP3AGwmMguQAIv8XTHMNtlvA6Q0iWXrFwH+mr1n43BJRWXMMdVvsHUCyksqeagZNh6tyE5Im53zNqnpbqOctIxgHCjwDVajwYmxNPj4tysfF0k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4+xlLlXuv+X6SsQI8lnnRdi5HMaI9tta9gZd4i+cyON9fvUrIqTsaNZYKsTxfgVis2NMHJxLG09BPGLG3/ZSbMEOo61NhMr9uvPE4aeioYX0SJ+j+JNcCa4CyXcx5dEUXpGhIPBFEcv0pB+zIz4xoQrpB2sFXRwfU6Vs6k2ENTU=; X-YMail-OSG: Fef0m90VM1mDEx5TiNlgpYiWVL6Myr9BcoxyphM6iDpTCTj JVL4Fot3VdP30jwWX91HXK8ZNWp2_cQ66hAYrpDs_8WbVkJ7ehACWEEHU4FD EmeLCH6cqalzPgYOSnJ.gjCbkKBkJjG9cELtATQfhH142Y8XOwySanoz_dq0 gg42qp1jrI8xfcCIJnxI30XIuro2dZnIa2kLXJeCEapP_r2._3eH3siZyJcS z1U2xsrLc7ZOIB3BHDv.gfcEkLk2Fb3CZIGLJIPgGH0MapnSfhBTxjteeZPq .kCQTlTguJMDzpNSfnga7Iv5dt8sFSN_Hovcn42mFQV19ticZIye8vZpK5o_ 834xzPkJlEpW6STfLDjsGcIXaZw.BE4hTewCS9ql1E90tKLLOpTTgKXLqIhQ OCvMmqWfNWFRORC8UkBvv47m75dC3XM0WVyi1dh_bAlGsUkRCtuD5M2eUYp. MTI84b1XQDPiZOQqUMOGdfXPKvqSo3cJ08_ZwvpvYAU.9t7Gy37k21JqZRzv dWJfCbB0Vcy7IPAxO5kI- Received: from [112.134.200.112] by web161906.mail.bf1.yahoo.com via HTTP; Wed, 27 Mar 2013 22:39:16 PDT X-Rocket-MIMEInfo: 002.001, Cgo.IAoKPiBJIHRoaW5rIHlvdSBtYXkgYmUgcmVhZGluZyB0b28gbXVjaCBpbnRvIHRoZSBtYWxsb2MgbWFucGFnZS7CoCBXaGVuIGl0Cj4gbWVudGlvbnMgdGhlIHVzZSBvZiBwZXItdGhyZWFkIHNtYWxsLW9iamVjdCBjYWNoZXMgdG8gYXZvaWQgbG9ja2luZyBpdCdzCj4gdGFsa2luZyBhYm91dCBwZXJmb3JtYW5jZSwgbm90IHRocmVhZCBzYWZldHkuwqAgQWxsb2NhdGlvbnMgb2YgYWxsIHNpemVzCj4gYXJlIHRocmVhZC1zYWZlLCB0aGUgbGlicmFyeSBqdXN0IGFzc3VtZXMgdGhhdCBodWdlIGFsbG9jYXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> <1364410923.36972.67.camel@revolution.hippie.lan> Message-ID: <1364449156.30979.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Wed, 27 Mar 2013 22:39:16 -0700 (PDT) From: Unga Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] To: "freebsd-stable@FreeBSD.org" In-Reply-To: <1364410923.36972.67.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Unga List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 05:39:23 -0000 =0A=0A> =0A=0A> I think you may be reading too much into the malloc manpage= .=A0 When it=0A> mentions the use of per-thread small-object caches to avoi= d locking it's=0A> talking about performance, not thread safety.=A0 Allocat= ions of all sizes=0A> are thread-safe, the library just assumes that huge a= llocations are rare=0A> enough that it doesn't use extra per-thread resourc= es to avoid locking=0A> for them, it just uses locking for huge blocks.=0A>= =0A> -- Ian=0A>=0A=0AGood to note all allocations are thread safe in FreeB= SD. Is it by some standard that malloc should be thread safe regardless the= OS (BSDs, Linux, Windows, Android, etc)?=0A=0AUnga=0A From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 06:52:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2A7FB9F for ; Thu, 28 Mar 2013 06:52:08 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 90727FD9 for ; Thu, 28 Mar 2013 06:52:08 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-173-252-28.range86-173.btcentralplus.com [86.173.252.28]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id C005F45046; Thu, 28 Mar 2013 06:42:23 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.7.4 isis.morrow.me.uk C005F45046 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1364452944; bh=40EKzLwhhrzSHhxzaoWfmqTIABYhpIb5VQUMnIhgQaY=; h=Date:From:To:Subject:References:In-Reply-To; b=09Zillg14Mp/QyiF6D1oQSOcuke2QYTH9ldtRedmeFN8IByoPqunF9dsLXGiY0VK1 G8AEewcsgw7Cg3+Cc9dFIsYwLgInGMjXNKdEchchwVuZPWyESEEVSU2tKecKOXreeX pmaTtYnInlkSgWFRgDyrC1N3xsxcCaXz1sXR3OtY= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 761CBA298; Thu, 28 Mar 2013 06:42:20 +0000 (GMT) Date: Thu, 28 Mar 2013 06:42:20 +0000 From: Ben Morrow To: unga888@yahoo.com, freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] Message-ID: <20130328064216.GA30925@anubis.morrow.me.uk> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> <1364410923.36972.67.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1364449156.30979.YahooMailNeo@web161906.mail.bf1.yahoo.com> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 06:52:08 -0000 Quoth Unga : > > > I think you may be reading too much into the malloc manpage.  When it > > mentions the use of per-thread small-object caches to avoid locking it's > > talking about performance, not thread safety.  Allocations of all sizes > > are thread-safe, the library just assumes that huge allocations are rare > > enough that it doesn't use extra per-thread resources to avoid locking > > for them, it just uses locking for huge blocks. > > Good to note all allocations are thread safe in FreeBSD. Is it by some > standard that malloc should be thread safe regardless the OS (BSDs, > Linux, Windows, Android, etc)? POSIX (well, SUSv4 at least) says that malloc and free must be threadsafe. Note that Windows is not a POSIX system, though I belive malloc is also always threadsafe on Windows. Ben From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 07:04:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 735A8401 for ; Thu, 28 Mar 2013 07:04:23 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id 5690CE0 for ; Thu, 28 Mar 2013 07:04:23 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id GuyY1l0071vN32cA7v4PPq; Thu, 28 Mar 2013 07:04:23 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id Gv4N1l0041t3BNj8iv4Ny2; Thu, 28 Mar 2013 07:04:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3208373A1C; Thu, 28 Mar 2013 00:04:22 -0700 (PDT) Date: Thu, 28 Mar 2013 00:04:22 -0700 From: Jeremy Chadwick To: Unga Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] Message-ID: <20130328070422.GA26584@icarus.home.lan> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> <1364410923.36972.67.camel@revolution.hippie.lan> <1364449156.30979.YahooMailNeo@web161906.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1364449156.30979.YahooMailNeo@web161906.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364454263; bh=oWhQOTL521xAmP2bNkNz3WRf/9tyeuRVTBNMCZVdscM=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=jhDBuWh4tvWASlSeUHwtbA1j+JwsI+32ZFkHpifDL83rv9P2UKIGam+2ZwBPlEhjg pjMGir5vg5SCl4dFMBpxzC3SUK2yNI7XNJwxs2WqU3Sxvwpjjmu2e0QThla51q77Oc FCIKY3yNbMIPoWzXNB9KKZMGafWVDUJRdWbl8538sXXbpD0YjsLr1hf9+M5M/MiTKx AdS8cnOTp9QA3gHmS64jDrgaJFmUjmArXlY1fsx/ix74VmSQBHKOTCZiXa1V3+8fZ1 sSFAfe6bKKHa3cAycjwDJZtGvNT6uR1/XQR8Jzw0RGl/3u9+5EqTAGbaqiafCY+oWS e/t5OFG16V1/Q== Cc: "freebsd-stable@FreeBSD.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 07:04:23 -0000 On Wed, Mar 27, 2013 at 10:39:16PM -0700, Unga wrote: > > I think you may be reading too much into the malloc manpage.? When it > > mentions the use of per-thread small-object caches to avoid locking it's > > talking about performance, not thread safety.? Allocations of all sizes > > are thread-safe, the library just assumes that huge allocations are rare > > enough that it doesn't use extra per-thread resources to avoid locking > > for them, it just uses locking for huge blocks. > > > > -- Ian > > Good to note all allocations are thread safe in FreeBSD. Is it by some > standard that malloc should be thread safe regardless the OS (BSDs, > Linux, Windows, Android, etc)? The Internet is sometimes a useful resource. http://stackoverflow.com/questions/855763/malloc-thread-safe http://stackoverflow.com/questions/987444/about-thread-safety-in-malloc-and-free http://msdn.microsoft.com/en-us/library/ms235505.aspx http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx On the BSDs, with gcc -pthread you should be fine. Don't ask me about Clang/LLVM. On Linux, glibc's routines are apparently thread-safe barring if the software was built with -DNO_THREADS (which seems very unlikely given the risks). Android is Linux. On Windows, assuming you're using CRT libraries, the routines are thread-safe. I get the impression the threaded library versions are also thread-safe for their *alloc equivalents. I believe HeapAlloc is thread-safe, and am pretty sure Global* is thread-safe (barring very very old Wine environments). Solaris's routines are also thread-safe, barring you're using standard malloc and not mtmalloc or ptmalloc or libumem (try searching the web for things like "Solaris mtmalloc" and read). All these OSes in some way or another have support for multi-threaded malloc implementations for increased performance (this is separate from locking/lock contention) where, AFAIK, you get to do the locking yourself. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 07:17:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 649EE672; Thu, 28 Mar 2013 07:17:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 9DEE0144; Thu, 28 Mar 2013 07:17:29 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id a15so3697879eae.15 for ; Thu, 28 Mar 2013 00:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KcmKTCcAzgq9u2w8+sbUQZoVLFSXWg9DkzxmO5V22a4=; b=IaBz7Zkw++sJimL0ahuUpQPHgW/k+RSBYn5WDGz3C2zKwfHbnhZ9lORWGd6Gg9hZcG L1LeLfrNwEjlfF5x8nhZJsbddI5MLBUvfOmzvErRKtZUxw54iHNtYR3zEgaMHMuc9hgO JUZI5UOG3MASuPdRCe8EM2gq3jHBjS8rw71mWeMPrLqaecIBKmdvKVaIxhlE4OKqtdZi 9wypwLZ1gr7aWRGkXnsynv9HXTAsvF03UjpRbe0F09Tcq4VMWRU7teJm+x2HJYs1K6v+ 3ym0zEl1NTYTygeMUevR1bdRFrHg2jN9xUrvCZ2QeR3FtqYaaoT5y62d3Nw/O2pvboeY +x1A== X-Received: by 10.14.183.198 with SMTP id q46mr55684955eem.1.1364455048826; Thu, 28 Mar 2013 00:17:28 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id bc1sm24376334eeb.11.2013.03.28.00.17.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 00:17:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <5153EE86.8000801@FreeBSD.org> Date: Thu, 28 Mar 2013 09:17:26 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 07:17:30 -0000 On 28.03.2013 02:43, Adrian Chadd wrote: > My main concern with the new stuff is that it requires CAM and that's > reasonably big compared to the standalone ATA code. > > It'd be nice if we could slim down the CAM stack a bit first; it makes > embedding it on the smaller devices really freaking painful. Are there many boards now with ATA, but without USB? But I agree, it should be checked. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 07:29:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B4F996F; Thu, 28 Mar 2013 07:29:49 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 29B4B1C8; Thu, 28 Mar 2013 07:29:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r2S7ThTb078636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Mar 2013 00:29:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r2S7Thma078635; Thu, 28 Mar 2013 00:29:43 -0700 (PDT) (envelope-from jmg) Date: Thu, 28 Mar 2013 00:29:43 -0700 From: John-Mark Gurney To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130328072943.GC76354@funkthat.com> Mail-Followup-To: Alexander Motin , Adrian Chadd , freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5153EE86.8000801@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 28 Mar 2013 00:29:43 -0700 (PDT) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 07:29:49 -0000 Alexander Motin wrote this message on Thu, Mar 28, 2013 at 09:17 +0200: > On 28.03.2013 02:43, Adrian Chadd wrote: > >My main concern with the new stuff is that it requires CAM and that's > >reasonably big compared to the standalone ATA code. > > > >It'd be nice if we could slim down the CAM stack a bit first; it makes > >embedding it on the smaller devices really freaking painful. > > Are there many boards now with ATA, but without USB? But I agree, it > should be checked. The net4501 board has ATA but no USB.. Also, depending upon use, you might choose to not include USB, but use ATA, or not use umass, but the rest of USB... Someone on a list was talking about trying to get FreeBSD down on a really small system, 16MB ram... /me thinks of the old wd driver. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 07:30:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BCBFBB81 for ; Thu, 28 Mar 2013 07:30:55 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 537B21F3 for ; Thu, 28 Mar 2013 07:30:55 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id c10so3045147wiw.8 for ; Thu, 28 Mar 2013 00:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=eiGSjZ/bUgzIjLEIOWrAhoBD2lBRWEiOP4r6A/D57i8=; b=XCNwQZMbeKGSHz7YOD7P42UOA3XHx7AZBMupxFKIINdTUUyvh4SbaaDK8Ktu3A//HZ QImoMVhLG9tg1SRZHjv8odpjIZGINEvqx+nkmM8GySheYuZU0f/HM1b1sIHNPlkpWmyK SH8Q8YwX666VxrR3e5v3L6POgP2XU0bpjX+7hmNbvdpJQLekn9ebRSsJ78agXYs7tMoI IvR4Cb/62iRyoaL9W/od7oeoVhVLtmWD847yChMMYfHRSvLT4baGKYM8nZi6SChHG6KU 7Qhb2R7yFCQ6DSpNm1Z4MCR4lhTA2QUWh2rsDRXXMC9ugKljqYN6JrofzyNuFkBAdJDM koYQ== X-Received: by 10.180.73.6 with SMTP id h6mr14150127wiv.27.1364455854420; Thu, 28 Mar 2013 00:30:54 -0700 (PDT) Received: from melon.localnet (wifi-osiris-sec-183-54.u-strasbg.fr. [130.79.183.54]) by mx.google.com with ESMTPS id t7sm12589823wij.2.2013.03.28.00.30.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Mar 2013 00:30:53 -0700 (PDT) From: David Demelier To: Daniel O'Connor Subject: Re: SU+J hard recovery failure Date: Thu, 28 Mar 2013 08:30:42 +0100 Message-ID: <2354019.aWBefE3QfC@melon> User-Agent: KMail/4.9.5 (FreeBSD/9.1-RELEASE-p1; KDE/4.9.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 07:30:55 -0000 Le jeudi 28 mars 2013 11:05:58 Daniel O'Connor a =E9crit : > On 27/03/2013, at 18:43, David Demelier wr= ote: > > Yesterday I had a panic on my laptop. Unfortunately the SU+J was no= t > > able to recovery the file system, the error was something like : > >=20 > > Unknown error: Help! > > Could not find directory 9854215 > >=20 > > And it went to the single user mode, I needed to fsck_ufs manually = to > > recover the disk. What afraid me is what if happens on a headless > > machine? It will be hard to recover. >=20 > For headless remote systems I use fsck_y_enable=3D"YES". >=20 > In my experience 'fsck -y' almost invariably recovers the disk to a p= oint > where it can boot and then I can login remotely. >=20 When the problem appeared, I could not use fsck -y because it will asks= "Use=20 journal?" and if journal is used the error above reappears and you can = not=20 clean the file system.. I needed to do a full fsck without any journal at all. > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C Regards, --=20 David Demelier From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 14:00:56 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3738671; Thu, 28 Mar 2013 14:00:56 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7D04E9B8; Thu, 28 Mar 2013 14:00:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ULDNv-0004sI-MW; Thu, 28 Mar 2013 14:00:55 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r2SE0rsD012965; Thu, 28 Mar 2013 08:00:53 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+xGW/8y2pQO9Q/fZJPv2OI Subject: Re: Any objections/comments on axing out old ATA stack? From: Ian Lepore To: Alexander Motin In-Reply-To: <5153EE86.8000801@FreeBSD.org> References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Mar 2013 08:00:53 -0600 Message-ID: <1364479253.36972.77.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 14:00:56 -0000 On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: > On 28.03.2013 02:43, Adrian Chadd wrote: > > My main concern with the new stuff is that it requires CAM and that's > > reasonably big compared to the standalone ATA code. > > > > It'd be nice if we could slim down the CAM stack a bit first; it makes > > embedding it on the smaller devices really freaking painful. > > Are there many boards now with ATA, but without USB? But I agree, it > should be checked. > It's not necessarily what the boards have but how they're used. We use industrial SBCs at work that have ata compact flash sockets on the board which we do use, and usb interfaces which we don't use. I've never tested the new ata+cam stuff on some of these boards, most based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata code works, but not always very well -- for example, we usually have to set hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure out except that if we leave it enabled we get DMA errors and panics on some CF cards and not on others. I have no idea whether to expect such things to be better, worse, or no different by changing to the ata+cam way of doing things (but I don't really have time to do extensive testing right now either). -- Ian From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 14:09:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D6DD0928; Thu, 28 Mar 2013 14:09:01 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 92B1EA27; Thu, 28 Mar 2013 14:09:01 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 375B0C4947; Thu, 28 Mar 2013 16:08:54 +0200 (EET) Date: Thu, 28 Mar 2013 16:09:53 +0200 From: Aleksandr Rybalko To: Adrian Chadd Subject: Re: Any objections/comments on axing out old ATA stack? Message-Id: <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> In-Reply-To: References: <51536306.5030907@FreeBSD.org> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 14:09:01 -0000 On Wed, 27 Mar 2013 17:43:07 -0700 Adrian Chadd wrote: > My main concern with the new stuff is that it requires CAM and that's > reasonably big compared to the standalone ATA code. > > It'd be nice if we could slim down the CAM stack a bit first; it makes > embedding it on the smaller devices really freaking painful. /me never seen embedded devices with ATA/SATA and less than 64MB of RAM. (i386/i486 old machines does not count :) ) I'm missing something? > > Thanks, > > > > adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Aleksandr Rybalko From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 15:29:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC47AE3A; Thu, 28 Mar 2013 15:29:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8A858EA4; Thu, 28 Mar 2013 15:29:26 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2SFTOXL046107; Thu, 28 Mar 2013 09:29:24 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: Date: Thu, 28 Mar 2013 09:29:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <969B2F75-EBBF-40F3-B805-323E1BFAD7F9@samsco.org> References: <51536306.5030907@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 15:29:27 -0000 On Mar 27, 2013, at 6:43 PM, Adrian Chadd wrote: > My main concern with the new stuff is that it requires CAM and that's > reasonably big compared to the standalone ATA code. >=20 =46rom a code execution standpoint? No, it's not. > It'd be nice if we could slim down the CAM stack a bit first; it makes > embedding it on the smaller devices really freaking painful. >=20 =46rom a code segment size standpoint, there's definitely some stuff = that should be made modular and optional. Scott From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 15:31:28 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9048147; Thu, 28 Mar 2013 15:31:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA41EDC; Thu, 28 Mar 2013 15:31:28 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2SFVQhk046128; Thu, 28 Mar 2013 09:31:26 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: <1364479253.36972.77.camel@revolution.hippie.lan> Date: Thu, 28 Mar 2013 09:31:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> <1364479253.36972.77.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Adrian Chadd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 15:31:28 -0000 On Mar 28, 2013, at 8:00 AM, Ian Lepore wrote: > On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: >> On 28.03.2013 02:43, Adrian Chadd wrote: >>> My main concern with the new stuff is that it requires CAM and = that's >>> reasonably big compared to the standalone ATA code. >>>=20 >>> It'd be nice if we could slim down the CAM stack a bit first; it = makes >>> embedding it on the smaller devices really freaking painful. >>=20 >> Are there many boards now with ATA, but without USB? But I agree, it=20= >> should be checked. >>=20 >=20 > It's not necessarily what the boards have but how they're used. We = use > industrial SBCs at work that have ata compact flash sockets on the = board > which we do use, and usb interfaces which we don't use. >=20 > I've never tested the new ata+cam stuff on some of these boards, most > based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata = code > works, but not always very well -- for example, we usually have to set > hw.ata.ata_dma=3D0 for absolutely no reason we've ever been able to = figure > out except that if we leave it enabled we get DMA errors and panics on > some CF cards and not on others. I have no idea whether to expect = such > things to be better, worse, or no different by changing to the ata+cam > way of doing things (but I don't really have time to do extensive > testing right now either). >=20 The legacy ATA code was hard to maintain, very buggy (as you point out), = and is essentially unmaintained. Also, IIRC, the legacy stack simply cannot = support NCQ tagged queueing. I think that Alexander has done a superb job with both developing and = supporting the CAM_ATA stack. Scott From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 16:05:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6554811C; Thu, 28 Mar 2013 16:05:14 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1B3191; Thu, 28 Mar 2013 16:05:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:cd63:a817:556f:dff2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id ED9064AC58; Thu, 28 Mar 2013 20:05:11 +0400 (MSK) Date: Thu, 28 Mar 2013 20:05:09 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <853249275.20130328200509@serebryakov.spb.ru> To: Aleksandr Rybalko Subject: Re: Any objections/comments on axing out old ATA stack? In-Reply-To: <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:05:14 -0000 Hello, Aleksandr. You wrote 28 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2013 =D0=B3., 18:09:53: >> It'd be nice if we could slim down the CAM stack a bit first; it makes >> embedding it on the smaller devices really freaking painful. AR> /me never seen embedded devices with ATA/SATA and less than 64MB of RAM. AR> (i386/i486 old machines does not count :) ) AR> I'm missing something? Yes: USB UMASS. It uses CAM too, and useful for very small systems, like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and all, should be packed to 4MiB). Please note, Adrian speaks about CAM, not only CAM + ATA. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 17:24:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06039227; Thu, 28 Mar 2013 17:24:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 1D286793; Thu, 28 Mar 2013 17:24:26 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id k14so5453034wer.13 for ; Thu, 28 Mar 2013 10:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MKzBdXfu9ezhnoI7zwkiT1qAsSY7jayRLZvpO+clr6M=; b=Q1mtXwEbYFpr1c5lrkx0vY9TR7fGpeJpndKRPcjCym+UmA8VygjIoNg5DSWxal69R/ AubMmnG6U1xByWGk7JqjfA6NWmvXB3GZ6bJThbw1qcvDi1PwlMvB+zD7wF+uk1PuxA1n VL9i/9yAWGa9EDJwerzw70l0695/BbukwqHvcNR2dh2K9NoIBe40fMCA9EepZ2ajuiPb HaeKbL2ztbhWo4Z3YRKYEnCtFMPUzrxVLTu4E9I8Egkznkwa50PulFZ+4u6/X0VsAx23 HA9yeNMaz5cjKoQAbwz51Wjb8ZUnB6RNu3m4CYOBJp4TCfJWdDDpx6o4szSn9uQasojW aMGA== MIME-Version: 1.0 X-Received: by 10.180.89.105 with SMTP id bn9mr13516194wib.26.1364491466232; Thu, 28 Mar 2013 10:24:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 10:24:26 -0700 (PDT) In-Reply-To: <853249275.20130328200509@serebryakov.spb.ru> References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> Date: Thu, 28 Mar 2013 10:24:26 -0700 X-Google-Sender-Auth: pCA09woODXOpCKaYKIfIYyu3I7k Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 17:24:28 -0000 On 28 March 2013 09:05, Lev Serebryakov wrote: > Yes: USB UMASS. It uses CAM too, and useful for very small systems, > like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and > all, should be packed to 4MiB). > > Please note, Adrian speaks about CAM, not only CAM + ATA. And I'm not at all saying we should keep the old ATA driver around. I'm just pointing out a set of use cases that most FreeBSD developers aren't involved with and I'd like to find a way to squeeze it more efficiently into embedded platforms. I've never had any noticable performance issues with CAM on my embedded MIPS boards because it's typically pushing packets. It's just the resultant binary size of the whole stack that's a problem. adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | grep scsi text data bss dec hex filename 49372 10672 80 60124 eadc scsi_all.o 21200 2576 16 23792 5cf0 scsi_da.o 23288 1488 16 24792 60d8 scsi_xpt.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | grep cam text data bss dec hex filename 3824 96 16 3936 f60 cam.o 13552 144 16 13712 3590 cam_periph.o 2344 144 0 2488 9b8 cam_queue.o 640 48 0 688 2b0 cam_sim.o 40684 752 192 41628 a29c cam_xpt.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | grep umass text data bss dec hex filename 22592 1072 16 23680 5c80 umass.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep '(cam_|umass|scsi_)' 13552 144 16 13712 3590 cam_periph.o 2344 144 0 2488 9b8 cam_queue.o 640 48 0 688 2b0 cam_sim.o 40684 752 192 41628 a29c cam_xpt.o 49372 10672 80 60124 eadc scsi_all.o 21200 2576 16 23792 5cf0 scsi_da.o 23288 1488 16 24792 60d8 scsi_xpt.o 22592 1072 16 23680 5c80 umass.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep '(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}' 190904 It doesn't seem like a lot, but it does add up.. Adrian From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 17:24:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E7AD42E; Thu, 28 Mar 2013 17:24:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id A0A8E7B8; Thu, 28 Mar 2013 17:24:58 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so3546277wib.10 for ; Thu, 28 Mar 2013 10:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=98jEQamiPMg+p7d2M5/FhWw74woD4ryfp8l0mhqour8=; b=w7DO6rY9tv90kuATIu4NHMMiG54McPXNGxy2SCDHJTDkC3S9KFkO4DYpRms+uZxxvR 3o2K7580JWxIToP0eA5vn7fGaf8zbZ5pk6eRvuVR0vLehcKnYLf+XqT7nXdA1osC8+mv re5N7nynfdTkU/HZjxAXv6YSkvXkXadvrqumfa2yN/A4PQvyK/d3qZq3YTQHJwMGVgIa JjY9yI73tR52EQ9fpv8tdprOoutOEzb3tUB40todBUEUe3ExFDuXGuGN+e3KDW+KmcFz odS2JjWxKa6KT4nJ+a8dAgMUD+6rliGIa06jQmwwTROJ6WMEer3qrq4BwoTN+0UrfBXJ 4edQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr39942536wjb.24.1364491494172; Thu, 28 Mar 2013 10:24:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 10:24:54 -0700 (PDT) In-Reply-To: References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> Date: Thu, 28 Mar 2013 10:24:54 -0700 X-Google-Sender-Auth: aCU-DnBzMgbP1FHmtf6rpj-LYSw Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 17:24:59 -0000 .. and before you ask - yes, there are embedded boards with limited RAM that also have ATA ports. :-) Adrian From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 17:32:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3DF108F0; Thu, 28 Mar 2013 17:32:42 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0161C821; Thu, 28 Mar 2013 17:32:41 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DF28A89FBE; Thu, 28 Mar 2013 17:26:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r2SHQo4c006396; Thu, 28 Mar 2013 17:26:50 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: Any objections/comments on axing out old ATA stack? In-reply-to: From: "Poul-Henning Kamp" References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 28 Mar 2013 17:26:50 +0000 Message-ID: <6395.1364491610@critter.freebsd.dk> Cc: Aleksandr Rybalko , lev@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin , freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 17:32:42 -0000 In message , Adrian Chadd wri tes: >On 28 March 2013 09:05, Lev Serebryakov wrote: >adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep >'(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}' >190904 > >It doesn't seem like a lot, but it does add up.. Isn't there some kernel compile-time option to eliminate the huge tables used for errormessages etc ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 17:39:27 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D4AEC40; Thu, 28 Mar 2013 17:39:27 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id E3779883; Thu, 28 Mar 2013 17:39:26 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r2SHdKvW021287; Thu, 28 Mar 2013 13:39:20 -0400 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.1 (mail.netplex.net [204.213.176.10]); Thu, 28 Mar 2013 13:39:20 -0400 (EDT) Date: Thu, 28 Mar 2013 13:39:20 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ian Lepore Subject: Re: Any objections/comments on axing out old ATA stack? In-Reply-To: <1364479253.36972.77.camel@revolution.hippie.lan> Message-ID: References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> <1364479253.36972.77.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Motin , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Adrian Chadd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:39:27 -0000 On Thu, 28 Mar 2013, Ian Lepore wrote: > On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: >> On 28.03.2013 02:43, Adrian Chadd wrote: >>> My main concern with the new stuff is that it requires CAM and that's >>> reasonably big compared to the standalone ATA code. >>> >>> It'd be nice if we could slim down the CAM stack a bit first; it makes >>> embedding it on the smaller devices really freaking painful. >> >> Are there many boards now with ATA, but without USB? But I agree, it >> should be checked. >> > > It's not necessarily what the boards have but how they're used. We use > industrial SBCs at work that have ata compact flash sockets on the board > which we do use, and usb interfaces which we don't use. > > I've never tested the new ata+cam stuff on some of these boards, most > based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata code > works, but not always very well -- for example, we usually have to set > hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure > out except that if we leave it enabled we get DMA errors and panics on > some CF cards and not on others. I have no idea whether to expect such > things to be better, worse, or no different by changing to the ata+cam > way of doing things (but I don't really have time to do extensive > testing right now either). Woa, I have to set hw.ata.ata_dma=0 also in order to get FreeBSD to boot on a PC104 board. I think ours is a Cyrix or Via also. -- DE From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 17:48:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 635F3ED0; Thu, 28 Mar 2013 17:48:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 794908E6; Thu, 28 Mar 2013 17:48:16 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so1807342wgg.12 for ; Thu, 28 Mar 2013 10:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yMLu6MAfA964fV69chAgT+r57PcTyNSHI6zjgRUR6R8=; b=mUT+rIfPr9NPqMrfvlfbqT8RX352NjA3WmhzlqRfCx/mbjZgCKBfLZ0dXhMmJRVONu k4hQl3ZS2YOUIHp8q6j9RF96ehPcDYQ/T3r7GDo9Yes2LIxX8PjzCy3b61xXY/6/aa8+ wzwFAqJNAS3fHhMT714LofEtUjJO35wI2fv0vL4N/uxZ5Ug49OMjaV8ZRHd1CsJ45FGi ETxLY7ous93izSr4SEPSd+G+IZx/fB2p3I6ynBcKgrbu5Cru8IxFYxqEtv+/hvM7cv7F 78xcAyPpC3SIAryLKJLPsxro+u1KairCaCdRMolpv8IsU9uV0VlDg0D+lIgAE93x7hh6 KS1w== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr18160916wic.29.1364492895286; Thu, 28 Mar 2013 10:48:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 10:48:15 -0700 (PDT) In-Reply-To: <6395.1364491610@critter.freebsd.dk> References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> <6395.1364491610@critter.freebsd.dk> Date: Thu, 28 Mar 2013 10:48:15 -0700 X-Google-Sender-Auth: n7GNo6aGgx06mNT2G1hIQnD_k6U Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , lev@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin , freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Mar 2013 17:48:18 -0000 On 28 March 2013 10:26, Poul-Henning Kamp wrote: > Isn't there some kernel compile-time option to eliminate the huge > tables used for errormessages etc ? Yup. It doesn't save all that much in the grand scheme of things. Doubly so since my secondary size constraint is an 896k partition that I lzma compress the kernel to fit into. Those strings don't add much to the final lzma image size. Adrian From owner-freebsd-stable@FreeBSD.ORG Fri Mar 29 18:19:53 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1837318A for ; Fri, 29 Mar 2013 18:19:53 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id BAFAC290 for ; Fri, 29 Mar 2013 18:19:52 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=EehKsYaC c=1 sm=0 a=fEl05wXzeJCkBz9gs2itqQ==:17 a=FtuzIWGT4-YA:10 a=2KMPMXqnonIA:10 a=YNqtyO0l_hcA:10 a=LaogzpLLAAAA:8 a=YDosoCDu0MMA:10 a=kqInehigDGRn8pZ9jrsA:9 a=QEXdDO2ut3YA:10 a=RdatWQ088fg4aZLYEhgA:9 a=_W_S_7VecoQA:10 a=g2B_iAzQUjWKgafg:21 a=fEl05wXzeJCkBz9gs2itqQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=mi+thun@aldan.algebra.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=mi+thun@aldan.algebra.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=anat; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.63.29 is neither permitted nor denied by domain of aldan.algebra.com) Received: from [209.6.63.29] ([209.6.63.29:10315] helo=utka.zajac) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTPA id C9/7B-28841-74BD5515; Fri, 29 Mar 2013 14:19:51 -0400 Message-ID: <5155DB46.3030601@aldan.algebra.com> Date: Fri, 29 Mar 2013 14:19:50 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130325 Thunderbird/17.0.4 MIME-Version: 1.0 To: stable@FreeBSD.org Subject: smbfus: panic on the second attempt to reach unavailable server Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?UTF-8?B?0JHQvtGA0LjRgSDQn9C+0L/QvtCy?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Mar 2013 18:19:53 -0000 Hello! I have my FreeBSD-server dump nightly backups onto an entertainment device running embedded Linux. The device has no NFS-server, but does run Samba (3.0.30). It allows access to its internal hard-drive, which my server mounts as: //dune/hdd750_..._32 /dune smbfs rw,noauto,-N,-Ekoi8-u:utf-8 There are two nightly cronjob using dump(8), xz(1), and ccrypt(1) to dump two "important" filesystems (/var/spool/imap and /home). The imap one kicks off at 3:11am and the home -- at 3:31am. This normally works perfectly fine every night, except when somebody accidentally sits on top of the remote-control of the entertainment device in the living room -- or somehow else managed to turn the box off. When this happens, the first dump simply fails, as one would expect: cannot create /dune/backups/narawntapu.imap.1.Tuesday.dump.xz.cpt: No such file or directory DUMP: Date of this level 1 dump: Tue Mar 12 03:11:07 2013 DUMP: Date of last level 0 dump: Wed Mar 6 01:31:07 2013 DUMP: Dumping snapshot of /dev/da0a (/var/spool/imap) to standard output DUMP: mapping (Pass I) [regular files] DUMP: Cache 16 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 169895 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: Broken pipe DUMP: The ENTIRE dump is aborted. However, when the second job tries to do the same twenty minutes later, the machine panics. This morning I was able to get a kernel coredump: ... #6 0xffffffff80750f2f in calltrap () at /cache/src/sys/amd64/amd64/exception.S:228 No locals. #7 0xffffffff805a46ca in turnstile_broadcast (ts=0x0, queue=0) at /cache/src/sys/kern/subr_turnstile.c:838 _tid = ts1 = td = #8 0xffffffff80550e52 in _mtx_unlock_sleep (m=0xfffffe0105ecd8f0, opts=, file=, line=) at /cache/src/sys/kern/kern_mutex.c:715 ts = (struct turnstile *) 0x0 #9 0xffffffff8101a0cd in smb_iod_invrq (iod=) at /cache/src/sys/modules/smbfs/../../netsmb/smb_iod.c:91 rqp = (struct smb_rq *) 0xfffffe0105ecd800 #10 0xffffffff8101b172 in smb_iod_addrq (rqp=0xfffffe0105ecd800) at /cache/src/sys/modules/smbfs/../../netsmb/smb_iod.c:418 vcp = iod = (struct smbiod *) 0xfffffe009483b800 error = __func__ = "uЪ", '\220' #11 0xffffffff81017da2 in smb_rq_simple (rqp=0xfffffe0105ecd800) at /cache/src/sys/modules/smbfs/../../netsmb/smb_rq.c:168 vcp = (struct smb_vc *) 0xfffffe011f957000 error = i = 0 #12 0xffffffff81016202 in smb_smb_treeconnect (ssp=0xfffffe015f069200, scred=0xfffffe009483b868) at /cache/src/sys/modules/smbfs/../../netsmb/smb_smb.c:574 vcp = (struct smb_vc *) 0xfffffe011f957000 rq = {sr_state = 1720810032, sr_vc = 0xfffffe0002a8c490, sr_share = 0xffffff8366917a90, sr_mid = 40352, sr_seqno = 4294967295, sr_rseqno = 1720810112, sr_rq = {mb_top = 0xffffffff80574fea, mb_cur = 0x100000001, mb_mleft = 1458488464, mb_count = -512, mb_copy = 0xffffff8366917a80, mb_udata = 0xffffffff80755149}, sr_rqflags = 0 '\0', sr_rqflags2 = 0, sr_wcount = 0x0, sr_bcount = 0xffffff8366917ac0, sr_rp = {md_top = 0xffffffff8057546d, md_cur = 0x0, md_pos = 0xfffffe0056eec490 "\2005л\200ЪЪЪЪ"}, sr_rpgen = -1803307004, sr_rplast = -512, sr_flags = 1458488464, sr_rpsize = -512, sr_cred = 0xfffffe009483b804, sr_timo = 1458488464, sr_rexmit = -512, sr_sendcnt = 1720810208, sr_timesent = {tv_sec = 582, tv_nsec = -2196531595260}, sr_lerror = 0, sr_rqsig = 0xffffff8366917b10 "\200{\221f\203ЪЪЪ\206â•šV\200ЪЪЪЪ\200{\221f\203ЪЪЪ\035Ñ”\001\201п\a", sr_rqtid = 0xffffffff805a0e97, sr_rquid = 0xffffff8366917b10, sr_errclass = 1 '\001', sr_serror = 0, sr_error = 0, sr_rpflags = 208 'п', sr_rpflags2 = 0, sr_rptid = 0, sr_rppid = 0, sr_rpuid = 0, sr_rpmid = 0, sr_slock = {lock_object = {lo_name = 0xffffff8366917b80 "Ю{\221f\203ЪЪЪ\032Ò‘\001\201ЪЪЪЪП{\221f\203ЪЪЪ\230╦\203\224", lo_flags = 2153163654, lo_data = 4294967295, lo_witness = 0xffffff8366917b80}, mtx_lock = 8592098960413}, sr_t2 = 0xffffffff8102517c, sr_link = {tqe_next = 0x9483b820, tqe_prev = 0x0}} rqp = (struct smb_rq *) 0xfffffe0105ecd800 mbp = (struct mbchain *) 0xfffffe0105ecd828 pp = pbuf = 0x0 encpass = 0x0 error = plen = 1 upper = 0 #13 0xffffffff8101ad1a in smb_iod_thread (arg=) at /cache/src/sys/modules/smbfs/../../netsmb/smb_iod.c:206 iod = (struct smbiod *) 0xfffffe009483b800 #14 0xffffffff805365df in fork_exit (callout=0xffffffff8101aa83 , arg=0xfffffe009483b800, frame=0xffffff8366917c40) at /cache/src/sys/kern/kern_fork.c:992 p = (struct proc *) 0xfffffe0181104000 td = (struct thread *) 0xfffffe0056eec490 #15 0xffffffff8075145e in fork_trampoline () at /cache/src/sys/amd64/amd64/exception.S:602 Looking inside the smb_iod_invrq (smb_iod.c:91), I'm wondering, if an attempt is made to invalidate/release something twice (causing the turnstile_broadcast() to be invoked with ts being NULL the second time)? That would explain, why the first attempt to use the absent server errors-out as normal, and only the second attempt panics. My kernel is 9.1-PRERELEASE as of Dec 19. Any ideas? Thanks! Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 18:48:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57D61CB5 for ; Sat, 30 Mar 2013 18:48:22 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id E912875C for ; Sat, 30 Mar 2013 18:48:21 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so1219442wgg.4 for ; Sat, 30 Mar 2013 11:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=5Dg4vkFSPhitJy8hKA8Cj1iipW+0gkgatFH2kqf+VQU=; b=f3P5xE74eEFedUizhKGuXUdsSb75SacqZeXTN+7gxEvXD0BqPfbOC15YLGV0E9ZHQu TxH5bz1gnj9LTA/eAlMii1sdxYtsioo8CJobpxynvhxy60Qz8g+UbO0htqsjG7jc1M83 LW+UmQD4o9hWzVNE0zEt2yNADTmEtP0p+mefn1GSA8Q1BtFlEFgl/Yz94BeqH8yFdx8l 39fCdXhsCRbcc5Riombiu2cmL8nWnrVaq9aK9i2grh4+SUPKIcoGuJTJ8jV3F5A116zl S3EbZ7LKMPOh/f5LeRiHIawlLGGOrjpz3PR5J19ORpf30Dwp2dQfpnT17ZCKPV1wA52C vttw== MIME-Version: 1.0 X-Received: by 10.180.14.129 with SMTP id p1mr3435268wic.1.1364669300600; Sat, 30 Mar 2013 11:48:20 -0700 (PDT) Received: by 10.194.158.164 with HTTP; Sat, 30 Mar 2013 11:48:20 -0700 (PDT) Date: Sat, 30 Mar 2013 13:48:20 -0500 Message-ID: Subject: problem building world on 9.1 stable after changing 100% to svn From: "Edwin L. Culp W." To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 18:48:22 -0000 I am currently tying to use the new tools that replace cvsup and then recompile. Ports are working as expected but buildworld has been giving me a headache . I'm manually trying # svn up /usr/src Updating '.': At revision 248935. # cd /usr/src # make buildworld It then chugs right along util it generates tha e following error: cc -O2 -pipe -I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -I/usr/src/usr.bin/xinstall/../../lib/libmd -std=gnu99 -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 -Wno-pointer-sign -c /usr/src/usr.bin/xinstall/xinstall.c cc1: warnings being treated as errors /usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log': /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaration of function 'strsvis' /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern declaration of 'strsvis' *** [xinstall.o] Error code 1 Stop in /usr/src/usr.bin/xinstall. *** [all] Error code 1 Stop in /usr/src/usr.bin. *** [usr.bin.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. I've probably missed something obvious because I can't find it and I've been building world for years with no real problems. Thanks for your help, ed uname follows: # uname -a FreeBSD home.encontacto.net 9.1-STABLE FreeBSD 9.1-STABLE #444 r248654M: Wed Mar 27 05:43:15 CST 2013 root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 19:48:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 101D9617 for ; Sat, 30 Mar 2013 19:48:02 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id E9E6D8E9 for ; Sat, 30 Mar 2013 19:48:01 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Hupk1l0040x6nqcA1vo0Eo; Sat, 30 Mar 2013 19:48:00 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id Hvnz1l00H1t3BNj8Yvnz36; Sat, 30 Mar 2013 19:48:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8CF2273A1C; Sat, 30 Mar 2013 12:47:59 -0700 (PDT) Date: Sat, 30 Mar 2013 12:47:59 -0700 From: Jeremy Chadwick To: "Edwin L. Culp W." Subject: Re: problem building world on 9.1 stable after changing 100% to svn Message-ID: <20130330194759.GA69749@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364672880; bh=wEmrNf4CAumjoPnpsNU9aAvCk6iiAT8bAsXHG/4gS8o=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=G3Krag1APvpmv36mflAEuldWCi+AqOHeZaEyt88Sdha0OPEqP7V4za/74ykyOcgi8 xI5SzYobQXLQQaPS5fUIXNTrOjTOyDwMuKbwIRLc+PAF8T+1FlnBemXBH6/fLqJJ0e YMB8FmltXpVPCudmw6IQgao5Q4lm7CZ6aH32fAiGtsvyZu10+ewPqbw22W7pqSTcIv R5UsW9idzr/so2/FXWpO5CTx2SLC2CyJO6ny/SBZzI0Posm+8B3RTkjv3LQzFwOE0i TTFpUhcTSreIzO1eNoWj+FMTTp2m/+glqmRLeWet+Ow6s99mE2lPg3iwuRbaWdlj7G NNaJkTzQHXXQg== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 19:48:02 -0000 On Sat, Mar 30, 2013 at 01:48:20PM -0500, Edwin L. Culp W. wrote: > I am currently tying to use the new tools that replace cvsup and then > recompile. Ports are working as expected but buildworld has been giving me > a headache . > I'm manually trying > > > # svn up /usr/src > > Updating '.': > At revision 248935. > > # cd /usr/src > # make buildworld > > It then chugs right along util it generates tha e following error: > > cc -O2 -pipe -I/usr/src/usr.bin/xinstall/../../contrib/mtree > -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd > -I/usr/src/usr.bin/xinstall/../../lib/libmd -std=gnu99 -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 -Wno-pointer-sign -c > /usr/src/usr.bin/xinstall/xinstall.c > cc1: warnings being treated as errors > /usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log': > /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaration of > function 'strsvis' > /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern > declaration of 'strsvis' > *** [xinstall.o] Error code 1 > > Stop in /usr/src/usr.bin/xinstall. > *** [all] Error code 1 > > Stop in /usr/src/usr.bin. > *** [usr.bin.all__D] Error code 1 > > Stop in /usr/src. > *** [everything] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > I've probably missed something obvious because I can't find it and I've > been building world for years with no real problems. > > Thanks for your help, > > ed > > uname follows: > > # uname -a > FreeBSD home.encontacto.net 9.1-STABLE FreeBSD 9.1-STABLE #444 r248654M: > Wed Mar 27 05:43:15 CST 2013 > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO > amd64 The most likely culprit here is "old cruft" in /usr/obj, but I make no promises. rm -fr /usr/obj/* and restart your build. The recent MFC of an update install/xinstall pulls in reliance on strsvis(3), which is part of contrib/libc-vis/vis.c, so my theory is that you have old cruft in /usr/obj that the build environment is referring to which lacks strsvis. If that results in the same build failure, I recommend CC'ing brooks@freebsd.org and bring this to his attention, as it may be more fallout from the recent MFC. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 20:23:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7094AC3A for ; Sat, 30 Mar 2013 20:23:37 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 47FD2A2B for ; Sat, 30 Mar 2013 20:23:37 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 0500633C68; Sat, 30 Mar 2013 16:23:31 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id D025839829; Sat, 30 Mar 2013 16:23:28 -0400 (EDT) From: Lowell Gilbert To: "Edwin L. Culp W." Subject: Re: problem building world on 9.1 stable after changing 100% to svn References: Date: Sat, 30 Mar 2013 16:23:28 -0400 In-Reply-To: (Edwin L. Culp W.'s message of "Sat, 30 Mar 2013 13:48:20 -0500") Message-ID: <44li94vdq7.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 20:23:37 -0000 "Edwin L. Culp W." writes: > I am currently tying to use the new tools that replace cvsup and then > recompile. Ports are working as expected but buildworld has been giving me > a headache . > I'm manually trying > > > # svn up /usr/src > > Updating '.': > At revision 248935. > > # cd /usr/src > # make buildworld > > It then chugs right along util it generates tha e following error: > > cc -O2 -pipe -I/usr/src/usr.bin/xinstall/../../contrib/mtree > -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd > -I/usr/src/usr.bin/xinstall/../../lib/libmd -std=gnu99 -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 -Wno-pointer-sign -c > /usr/src/usr.bin/xinstall/xinstall.c > cc1: warnings being treated as errors > /usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log': > /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaration of > function 'strsvis' > /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern > declaration of 'strsvis' > *** [xinstall.o] Error code 1 > > Stop in /usr/src/usr.bin/xinstall. > *** [all] Error code 1 > > Stop in /usr/src/usr.bin. > *** [usr.bin.all__D] Error code 1 > > Stop in /usr/src. > *** [everything] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > I've probably missed something obvious because I can't find it and I've > been building world for years with no real problems. This looks like a real compile problem, so the issue is unlikely to be related to how you got the sources (i.e., the svn conversion is probably a red herring. My first guess was that some developer had broken the build entirely, but I've now done a successful buildworld (with the same revision you have), so the problem appears to be local to your system. It's possible you're building with the wrong set of headers, but every case I can think of would have given you an error earlier than this. Do you get any output from: # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c by any chance? What command did you use for your initial source checkout from SubVersion? From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 20:37:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2EE6F07 for ; Sat, 30 Mar 2013 20:37:46 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB0BAF1 for ; Sat, 30 Mar 2013 20:37:46 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so686745wib.10 for ; Sat, 30 Mar 2013 13:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iLMC9YhUB/nJLjMSukBoQ0BeHcVeEHkhScgkQX084PI=; b=k8gyBMU9pRy5KSrzhU2y6B7NaAfnaD6tF2SLLS+6megFNiPiRAanjctyUrVOmZTRIV PNFd8cE1m+plm0HjwlCagGtlAF/KvRNAQImutL5+hJ0Zi3OBQS0YIb90mYFWu9MLZA6E sED8tYAXd3JIg4MpcDZLPE1/F+9f0xu72JDtOfwpuEcxxnouBPTUa7PCkqrcgD4mekfj KhnT6+QL0SFzUop31hGR7NuwmAZ5NirxyT9PdPPIqFlQSG2Fr+pweNVuWExVtEZz666B E2kgctsx1BpoFSV3Uvk4aoiOGI36ba5rEFlplDypfiC1MxQPCp3ZdaKcuEU/WwX/HiSB iJiw== MIME-Version: 1.0 X-Received: by 10.194.176.34 with SMTP id cf2mr9044817wjc.59.1364675865647; Sat, 30 Mar 2013 13:37:45 -0700 (PDT) Received: by 10.194.158.164 with HTTP; Sat, 30 Mar 2013 13:37:45 -0700 (PDT) In-Reply-To: <44li94vdq7.fsf@lowell-desk.lan> References: <44li94vdq7.fsf@lowell-desk.lan> Date: Sat, 30 Mar 2013 15:37:45 -0500 Message-ID: Subject: Re: problem building world on 9.1 stable after changing 100% to svn From: "Edwin L. Culp W." To: Lowell Gilbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 20:37:47 -0000 On Sat, Mar 30, 2013 at 3:23 PM, Lowell Gilbert < freebsd-stable-local@be-well.ilk.org> wrote: > "Edwin L. Culp W." writes: > > > I am currently tying to use the new tools that replace cvsup and then > > recompile. Ports are working as expected but buildworld has been givin= g > me > > a headache . > > I'm manually trying > > > > > > # svn up /usr/src > > > > Updating '.': > > At revision 248935. > > > > # cd /usr/src > > # make buildworld > > > > It then chugs right along util it generates tha e following error: > > > > cc -O2 -pipe -I/usr/src/usr.bin/xinstall/../../contrib/mtree > > -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd > > -I/usr/src/usr.bin/xinstall/../../lib/libmd -std=3Dgnu99 -fstack-protec= tor > > -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 -Wno-pointer-sign -c > > /usr/src/usr.bin/xinstall/xinstall.c > > cc1: warnings being treated as errors > > /usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log': > > /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaratio= n > of > > function 'strsvis' > > /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern > > declaration of 'strsvis' > > *** [xinstall.o] Error code 1 > > > > Stop in /usr/src/usr.bin/xinstall. > > *** [all] Error code 1 > > > > Stop in /usr/src/usr.bin. > > *** [usr.bin.all__D] Error code 1 > > > > Stop in /usr/src. > > *** [everything] Error code 1 > > > > Stop in /usr/src. > > *** [buildworld] Error code 1 > > > > Stop in /usr/src. > > > > I've probably missed something obvious because I can't find it and I've > > been building world for years with no real problems. > > This looks like a real compile problem, so the issue is unlikely to be > related to how you got the sources (i.e., the svn conversion is probably > a red herring. My first guess was that some developer had broken the > build entirely, but I've now done a successful buildworld (with the same > revision you have), so the problem appears to be local to your system. > > It's possible you're building with the wrong set of headers, but every > case I can think of would have given you an error earlier than this. > Do you get any output from: > # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c > by any chance? > > What command did you use for your initial source checkout from SubVersion= ? > I did it twice. # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c M xinstall.c # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c M xinstall.c Hopefully you will find something there. Thanks ed --=20 Bienes Ra=EDces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/1= 02249989850215?sk=3Dphotos_albums From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 20:47:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C21D0351 for ; Sat, 30 Mar 2013 20:47:49 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE11B6D for ; Sat, 30 Mar 2013 20:47:49 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id DED2C33C6E; Sat, 30 Mar 2013 16:47:43 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id ADC3D39829; Sat, 30 Mar 2013 16:47:42 -0400 (EDT) From: Lowell Gilbert To: "Edwin L. Culp W." Subject: Re: problem building world on 9.1 stable after changing 100% to svn References: <44li94vdq7.fsf@lowell-desk.lan> Date: Sat, 30 Mar 2013 16:47:42 -0400 In-Reply-To: (Edwin L. Culp W.'s message of "Sat, 30 Mar 2013 15:37:45 -0500") Message-ID: <44hajsvclt.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:47:49 -0000 "Edwin L. Culp W." writes: > On Sat, Mar 30, 2013 at 3:23 PM, Lowell Gilbert < > freebsd-stable-local@be-well.ilk.org> wrote: >> It's possible you're building with the wrong set of headers, but every >> case I can think of would have given you an error earlier than this. >> Do you get any output from: >> # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c >> by any chance? >> >> What command did you use for your initial source checkout from SubVersion? >> > > I did it twice. > > # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c > M xinstall.c > # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c > M xinstall.c > > Hopefully you will find something there. Yup, that's clearly wrong. For the moment I'll assume you did the initial checkout correctly. Or at least in some wrong way that doesn't require you to remove the whole tree and check it out again (which definitely is what you should have done the first time, by the way). I'm guessing the revert part is what you really need, but go to the /usr/src directory and try: # svn cleanup or # svn revert -R * and if you're still lost, # svn status . will tell you what is in your tree that is different from a pristine one. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 21:10:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38BCA800 for ; Sat, 30 Mar 2013 21:10:15 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx1.freebsd.org (Postfix) with ESMTP id C85E6CCB for ; Sat, 30 Mar 2013 21:10:14 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b12so1192696wgh.6 for ; Sat, 30 Mar 2013 14:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=gjpIDfi3hzxzTpf07PYk8Uh/xIhLhdcr6qUE2pZagZ4=; b=PbfiGUMG537W4tbcAUPn/ovteiCJoy9JOn+Q64SYCYivj6pxPgyplWvdIbUyPrOCSt iLthnCXXM/2mbMHwW2s4a41xE1DH2Q+X/0JKvfc2EqjN1Jh0j3GKtORp6XOjkVZb5sVX M9LOzD/uurNVQDLxCwC+EuKkWaweZreOMVnMIlTr+EJkZii4qA0aWCzTLh6cOn2bxRSR QbBPY9OnHwYWb3kLKMCfW48I1DIbeQPcOMT1HEgE3juVX+2Ymsi18A0Tc219omCvpJdx buAT1o7Ls4v27blZswl/jNHBDH4zhbSNoqCLOZvBQ6+wkF3Svn+uSGZUi3/Ho5vY4dyi uKCw== MIME-Version: 1.0 X-Received: by 10.180.14.129 with SMTP id p1mr3766571wic.1.1364677807311; Sat, 30 Mar 2013 14:10:07 -0700 (PDT) Received: by 10.194.158.164 with HTTP; Sat, 30 Mar 2013 14:10:07 -0700 (PDT) In-Reply-To: <44hajsvclt.fsf@lowell-desk.lan> References: <44li94vdq7.fsf@lowell-desk.lan> <44hajsvclt.fsf@lowell-desk.lan> Date: Sat, 30 Mar 2013 16:10:07 -0500 Message-ID: Subject: Re: problem building world on 9.1 stable after changing 100% to svn From: "Edwin L. Culp W." To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 21:10:15 -0000 On Sat, Mar 30, 2013 at 3:47 PM, Lowell Gilbert < freebsd-stable-local@be-well.ilk.org> wrote: > "Edwin L. Culp W." writes: > > > On Sat, Mar 30, 2013 at 3:23 PM, Lowell Gilbert < > > freebsd-stable-local@be-well.ilk.org> wrote: > >> It's possible you're building with the wrong set of headers, but every > >> case I can think of would have given you an error earlier than this. > >> Do you get any output from: > >> # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c > >> by any chance? > >> > >> What command did you use for your initial source checkout from > SubVersion? > >> > > > > I did it twice. > > > > # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c > > M xinstall.c > > # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c > > M xinstall.c > > > > Hopefully you will find something there. > > Yup, that's clearly wrong. For the moment I'll assume you did the > initial checkout correctly. Or at least in some wrong way that doesn't > require you to remove the whole tree and check it out again (which > definitely is what you should have done the first time, by the way). > If the below instructions don't solve it, I'll remover the tree. It is the same tree that I was updating with cvsup daily for years. It could be causing the problem. > I'm guessing the revert part is what you really need, but go to the > /usr/src directory and try: > # svn cleanup > or > # svn revert -R * > > and if you're still lost, > # svn status . > will tell you what is in your tree that is different from a pristine one. > Thanks a lot, This will keep me busy and should solve the problem, if not erase and restart ;) I'm sure that will do it. Enjoy what is left of Easter if you live where it is celebrated. ed From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 23:29:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id D3A8999C; Sat, 30 Mar 2013 23:29:57 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 5424B23CEDF; Sun, 31 Mar 2013 00:29:55 +0100 (CET) Message-ID: <5157756F.4040908@FreeBSD.org> Date: Sun, 31 Mar 2013 00:29:51 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> In-Reply-To: <51536306.5030907@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig338DC6674EB2008BF0825764" Cc: Alexander Motin , freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 23:29:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig338DC6674EB2008BF0825764 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 27.03.2013 22:22, schrieb Alexander Motin: > Hi. >=20 > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. >=20 > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Does anybody have good ideas why we should not dro= p > it now? Alexander, The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/15739= 7 where the SATA NCQ slots stall for some Samsung drives in the new stack, and consequently hang the computer for prolonged episodes where it is in the NCQ error handling, disallows removal of the old driver. (Last checked with 9.1-RELEASE at current patchlevel.) Chances are that limiting the open queue slots to 31 might help, but that is hearsay from what Linux would be doing. Unless we get a fix, if you want to drop the old driver, you'll need to add features so that 1. the new driver to lets users (down-)configure the max. number of tagged openings 2. the new driver allows disabling NCQ altogether for individual drives 3. list the relevant Samsung drives in some quirks data base so that we avoid the stalls while permitting users to "open it up to 32 NCQ slots". So unless these are all addressed, I'd veto removal of the old ATA driver - sorry! Best regards Matthias --------------enig338DC6674EB2008BF0825764 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFXdW8ACgkQvmGDOQUufZVJ2ACg0eUnW4Xe5nVJo3zLTaYjUARG KcgAniDIIJ8oveV3YB5GV7sNTYc1+ar8 =2f7y -----END PGP SIGNATURE----- --------------enig338DC6674EB2008BF0825764-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 30 23:33:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id AC64CBF2 for ; Sat, 30 Mar 2013 23:33:33 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 717ED23CEDF for ; Sun, 31 Mar 2013 00:33:31 +0100 (CET) Message-ID: <5157764A.7010106@FreeBSD.org> Date: Sun, 31 Mar 2013 00:33:30 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> <1364479253.36972.77.camel@revolution.hippie.lan> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7B7EFE9BC7265771E3F3A6D8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Mar 2013 23:33:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B7EFE9BC7265771E3F3A6D8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 28.03.2013 16:31, schrieb Scott Long: >=20 > On Mar 28, 2013, at 8:00 AM, Ian Lepore wrote: >=20 >> On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: >>> On 28.03.2013 02:43, Adrian Chadd wrote: >>>> My main concern with the new stuff is that it requires CAM and that'= s >>>> reasonably big compared to the standalone ATA code. >>>> >>>> It'd be nice if we could slim down the CAM stack a bit first; it mak= es >>>> embedding it on the smaller devices really freaking painful. >>> >>> Are there many boards now with ATA, but without USB? But I agree, it = >>> should be checked. >>> >> >> It's not necessarily what the boards have but how they're used. We us= e >> industrial SBCs at work that have ata compact flash sockets on the boa= rd >> which we do use, and usb interfaces which we don't use. >> >> I've never tested the new ata+cam stuff on some of these boards, most >> based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata cod= e >> works, but not always very well -- for example, we usually have to set= >> hw.ata.ata_dma=3D0 for absolutely no reason we've ever been able to fi= gure >> out except that if we leave it enabled we get DMA errors and panics on= >> some CF cards and not on others. I have no idea whether to expect suc= h >> things to be better, worse, or no different by changing to the ata+cam= >> way of doing things (but I don't really have time to do extensive >> testing right now either). >> >=20 >=20 > The legacy ATA code was hard to maintain, very buggy (as you point out)= , and > is essentially unmaintained. Also, IIRC, the legacy stack simply canno= t support > NCQ tagged queueing. =2E..which is exactly why it currently is the only way to get certain Samsung drives to cooperate reliably, without stalling the kernel for prolonged times (minutes) making the computer essentially unusable once it gets under I/O load (such as "make -C /usr/src -j4 buildworld") - as the new ahci+ata+cam+... would. Details including PR reference in my other message in this thread. --------------enig7B7EFE9BC7265771E3F3A6D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFXdkoACgkQvmGDOQUufZUe1wCgxo8Z7qss5JWRjr4Uqou89vLH faoAoIR/piaEP+X6umVJ9NpFnbsZBiYA =DJRN -----END PGP SIGNATURE----- --------------enig7B7EFE9BC7265771E3F3A6D8--