From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 00:21:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 32D161065673 for ; Sun, 4 Dec 2011 00:21:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8F2A215573F; Sun, 4 Dec 2011 00:20:58 +0000 (UTC) Message-ID: <4EDABCEA.4000601@FreeBSD.org> Date: Sat, 03 Dec 2011 16:20:58 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sthaug@nethelp.no References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> In-Reply-To: <20111203.140334.74707074.sthaug@nethelp.no> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 00:21:25 -0000 On 12/3/2011 5:03 AM, sthaug@nethelp.no wrote: >>> The fact that we have so many people who are radically >>> change-averse, no matter how rational the change; is a bug, not a >>> feature. >>> >>> This particular bug is complicated dramatically by the fact that >>> the majority view seems to lean heavily towards "If I use it, it >>> must be the default and/or in the base" rather than seeing ports >>> as part of the overall operating SYSTEM. > > I don't think of myself as change-averse. I've been using FreeBSD > since 1996, and there have been lots of changes since that time. But > two of the most important reasons I still use FreeBSD are: > > - Stability: Both in the sense of "stays up basically forever", and > in the sense of "changes to interfaces and commands are carefully > thought through and not applied indiscriminately". For instance, I > like very much the fact that the ifconfig command can configure VLANs > etc - while Linux has introduced new commands to do this. Agreed. > - The base system is a *system* and comes with most of what I need, > for instance tcpdump and BIND. For me the fact that I don't need to > install lots of packages to have a usable system is a *good* thing. So 2 things here that I really wish people would think about. 1. If you're using *any* ports/packages then you're already participating in the larger operating *system* that I described, so installing a few more won't hurt. (Seriously, it won't.) 2. In (the very few) areas where integration of 3rd party apps into the base makes sense, no problem. But at this point the fact that a lot of 3rd party stuff is changing more rapidly than it used to, and often in incompatible ways and/or at incompatible schedules with our release process, means that we have to re-think how we do this. You mentioned BIND, which is a great example of 2. above. I'll have more to say about this soon, but my plan is to remove it from the base for 10.x because the current situation is unmanageable. The FOSS world has changed a lot in the last 20 years, and decisions that were made in the early days, while appropriate at the time, need to be reexamined. > I use CVS (or rather csup) to keep the base system up to date. The point has been made before, but you do realize that cvs and csup are 2 completely different things, and that noone is recommending removal of csup from the base, right? Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 00:25:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 88D4F1065675 for ; Sun, 4 Dec 2011 00:25:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6438A1A86DF; Sun, 4 Dec 2011 00:25:12 +0000 (UTC) Message-ID: <4EDABDE8.9060406@FreeBSD.org> Date: Sat, 03 Dec 2011 16:25:12 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Roman Kurakin References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> In-Reply-To: <4ED9EA27.8090206@inse.ru> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 00:25:12 -0000 On 12/3/2011 1:21 AM, Roman Kurakin wrote: > Doug Barton wrote: >> [...] The fact that we have so many people who are radically >> change-averse, no matter how rational the change; is a bug, not a >> feature. >> >> This particular bug is complicated dramatically by the fact that >> the majority view seems to lean heavily towards "If I use it, it >> must be the default and/or in the base" rather than seeing ports as >> part of the overall operating SYSTEM. >> > You are right in general, except one small factor. We are talking > about bootstrap. You realize that you just 100% demonstrated the truth of what I wrote above, right? :) > CVS is used by many as the one of the ways to get > the sources to the freshly installed system to recompile to the last > available source. It will become inconvenient to do it through the > process of installing some ports for that. Especially if > corresponding ports would require some other ports as dependences. I want to ask some serious questions here, because I genuinely want to understand your thought process. 1. Do you install *any* ports/packages on a new system before you update the source? 2. If so, why is installing one more unthinkable? 3. Why is it a problem if the port/package you need to install in the early stages has dependencies? Thanks, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 02:32:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E380106564A for ; Sun, 4 Dec 2011 02:32:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 233FC8FC13 for ; Sun, 4 Dec 2011 02:32:14 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so5096380vbb.13 for ; Sat, 03 Dec 2011 18:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kqE7vlyVG/63b5wPDOQicZqIOE4CxXMwN7NKXQ53Aio=; b=n7P57VqszXas8JCoMyjwXHq9FhXnwYyiQfTZwQS56dBHxNYq8uijPLkb8UW8YKJzFK +E+2siHzbot86zyxR9IPL8PVuBhOPWhvFnLmGIco9bXFBZa9GlkNClwPQUIVT+zIMf4f 4euwrW27Hm2CbTO4IE7qaQD35hZvEscpN3fzs= MIME-Version: 1.0 Received: by 10.52.94.227 with SMTP id df3mr2349103vdb.51.1322965934147; Sat, 03 Dec 2011 18:32:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Sat, 3 Dec 2011 18:32:14 -0800 (PST) In-Reply-To: <30c6076d340bdb3546054609939139c6.squirrel@eternamente.info> References: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> <30c6076d340bdb3546054609939139c6.squirrel@eternamente.info> Date: Sun, 4 Dec 2011 10:32:14 +0800 X-Google-Sender-Auth: 6pe6lz9drrIZR2aNY5dp-3gbGAs Message-ID: From: Adrian Chadd To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 02:32:15 -0000 Why not just run FreeNAS? Adrian From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 02:40:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B6B106566B; Sun, 4 Dec 2011 02:40:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E10C8FC0C; Sun, 4 Dec 2011 02:40:24 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so5099184vbb.13 for ; Sat, 03 Dec 2011 18:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+QSMFw8uh5vX5GrOZa+8WVcjAfMp9Cy1wl4dSNAVPvw=; b=jaki1EL2mO0f0h2PU94KrchHeX5QEH6CYowKfgu08stKKbtrAls01zJZMn6SOKiUK5 aKX9yjAiUJxBHUUW2WqyVS1AJoMMfG2EmpplL1243wsakWdPe0+H1m66l5cSSEHXX1m1 yVZUNhFkyC+Aq8kDikO+8lJOQETP1Bx1YwF7g= MIME-Version: 1.0 Received: by 10.52.66.35 with SMTP id c3mr2404426vdt.17.1322966424632; Sat, 03 Dec 2011 18:40:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Sat, 3 Dec 2011 18:40:24 -0800 (PST) In-Reply-To: <4EDABDE8.9060406@FreeBSD.org> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> Date: Sun, 4 Dec 2011 10:40:24 +0800 X-Google-Sender-Auth: XaLENdAKVNUQ27iOn89sQRaEa58 Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: Roman Kurakin , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 02:40:25 -0000 The problem I have with all of this is pretty simple. With the CVS in base, it's treated like the (mostly) rest of the system in a stable release - ie, people don't simply keep updating it to the latest and greatest without some testing. If there are any critical bugs or security flaws, they're backported. The port isn't upgraded unless it has to be, and then if it's a major update, there are plenty of eyeballs to review it. It's in /src, after all. But with ports, the ports tree only has the "latest" version or two; sometimes a few major versions to choose from (eg apache), but we don't maintain the same kind of package versions that Linux operating system packages do. So it's entirely possible the "CVS" port maintainer updates the port to the latest and greatest, which works for him - and it breaks someone's older CVS repository somehow. I'd be happier with the idea of things moving into ports if the ports tree did have stable snapshots which had incremental patches for bug/security fixes, rather than "upgrade to whatever the port maintainer chooses." I'm all for change, but it seems those pushing forward change seem to be far exceeding the comfortable level of more conservative people; or those with real needs. Those who have relied on FreeBSD's stable release source tree being that - stable - whilst ports moves along with the latest and greatest as needed. It doesn't matter that you may do a fantastic job with a stable CVS port - what matters is how people perceive what you're doing. It just takes one perceived screwup here for the view to shift that "freebsd is going the way of linux". And then we lose a whole lot of what public "good" opinion FreeBSD has. ;-) 2c, Adrian From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 02:47:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7462106564A for ; Sun, 4 Dec 2011 02:47:00 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id BFB0E8FC08 for ; Sun, 4 Dec 2011 02:47:00 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 8A2BD1CC6C; Sat, 3 Dec 2011 23:46:51 -0300 (BRT) Received: from 187.64.97.160 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sun, 4 Dec 2011 00:46:51 -0200 Message-ID: <9eb3377e660857aeec7f640fc5a41221.squirrel@eternamente.info> In-Reply-To: References: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> <30c6076d340bdb3546054609939139c6.squirrel@eternamente.info> Date: Sun, 4 Dec 2011 00:46:51 -0200 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 02:47:01 -0000 On Sun, December 4, 2011 00:32, Adrian Chadd wrote: > Why not just run FreeNAS? thanks for the tip on FreeNAS, as others said too. will it run some other services, as http server for some stuff (wiki for example), edonkey and torrent clients, and some other stuff ? (I will visit the FreeNAS site and try to figure out) although it would solve the problem on configuring the box, I still have the doubts on the port multiplier being usefull on it, as FreeNAS will end on FreeBSD :) this port multiplier will work ok ? On Sil3124 and which others ? the tip on FreeNAS was great, but my main concern here is the sata hardware compatibility. I'd like to buy it knowing it will work :) thanks, matheus -- Vítima da Oi entre 2007 e 2011. We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 03:21:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92B2D106564A for ; Sun, 4 Dec 2011 03:21:54 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 696C18FC0A for ; Sun, 4 Dec 2011 03:21:54 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 14C7B1CC6C; Sun, 4 Dec 2011 00:21:53 -0300 (BRT) Received: from 187.64.97.160 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sun, 4 Dec 2011 01:21:53 -0200 Message-ID: <82bf04273014b38fc02a7c4068fb572d.squirrel@eternamente.info> In-Reply-To: <9eb3377e660857aeec7f640fc5a41221.squirrel@eternamente.info> References: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> <30c6076d340bdb3546054609939139c6.squirrel@eternamente.info> <9eb3377e660857aeec7f640fc5a41221.squirrel@eternamente.info> Date: Sun, 4 Dec 2011 01:21:53 -0200 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 03:21:54 -0000 On Sun, December 4, 2011 00:46, Nenhum_de_Nos wrote: > > On Sun, December 4, 2011 00:32, Adrian Chadd wrote: >> Why not just run FreeNAS? > > thanks for the tip on FreeNAS, as others said too. > > will it run some other services, as http server for some stuff (wiki for example), edonkey and > torrent clients, and some other stuff ? (I will visit the FreeNAS site and try to figure out) > > although it would solve the problem on configuring the box, I still have the doubts on the port > multiplier being usefull on it, as FreeNAS will end on FreeBSD :) > > this port multiplier will work ok ? On Sil3124 and which others ? > > the tip on FreeNAS was great, but my main concern here is the sata hardware compatibility. I'd > like to buy it knowing it will work :) > > thanks, > > matheus http://www.freenas.org/category/version-comparison unfortunately FreeNAS 8 won't be happy with less than 4GB RAM (I have 2GB on both hardware), and version 8 won't have http and torrent :( so far, I'll do as today and run FreeBSD 9 on its original form :) still looking for the port multiplier case, though. thanks, matheus > -- > Vítima da Oi entre 2007 e 2011. > > We will call you cygnus, > The God of balance you shall be > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > http://en.wikipedia.org/wiki/Posting_style > _______________________________________________ > 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" > -- Vítima da Oi entre 2007 e 2011. We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 03:59:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DEFE1065670; Sun, 4 Dec 2011 03:59:16 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DBEFF8FC14; Sun, 4 Dec 2011 03:59:15 +0000 (UTC) Received: by iafi7 with SMTP id i7so1512248iaf.13 for ; Sat, 03 Dec 2011 19:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XDcgOD6bGctXtz5uxjVRy486rQlFV5zgWQsfs3KWZ5w=; b=ubmjYUvLx1uPb+eHNE55du03BzOb4wH/r+mOir11XPY0uww35zSp2gJpuuzNocUAi/ hBo4rJQILT2DfzdlCSHqGjR0NkUGUUgaaMcrhpQUOItDloMRks7RD2HpcjW9HPD67JN4 jC1zLIuv/tmBJT41HcZ+gUWj1t/mmSM0n2ZNQ= MIME-Version: 1.0 Received: by 10.43.50.67 with SMTP id vd3mr4744923icb.10.1322971155208; Sat, 03 Dec 2011 19:59:15 -0800 (PST) Received: by 10.42.48.7 with HTTP; Sat, 3 Dec 2011 19:59:14 -0800 (PST) In-Reply-To: References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> Date: Sat, 3 Dec 2011 22:59:14 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , Roman Kurakin , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 03:59:16 -0000 On Sat, Dec 3, 2011 at 9:40 PM, Adrian Chadd wrote: > The problem I have with all of this is pretty simple. > > With the CVS in base, it's treated like the (mostly) rest of the > system in a stable release - ie, people don't simply keep updating it > to the latest and greatest without some testing. If there are any > critical bugs or security flaws, they're backported. The port isn't > upgraded unless it has to be, and then if it's a major update, there > are plenty of eyeballs to review it. It's in /src, after all. > > But with ports, the ports tree only has the "latest" version or two; > sometimes a few major versions to choose from (eg apache), but we > don't maintain the same kind of package versions that Linux operating > system packages do. > > So it's entirely possible the "CVS" port maintainer updates the port > to the latest and greatest, which works for him - and it breaks > someone's older CVS repository somehow. > > I'd be happier with the idea of things moving into ports if the ports > tree did have stable snapshots which had incremental patches for > bug/security fixes, rather than "upgrade to whatever the port > maintainer chooses." > > I'm all for change, but it seems those pushing forward change seem to > be far exceeding the comfortable level of more conservative people; or > those with real needs. Those who have relied on FreeBSD's stable > release source tree being that - stable - whilst ports moves along > with the latest and greatest as needed. It doesn't matter that you may > do a fantastic job with a stable CVS port - what matters is how > people perceive what you're doing. It just takes one perceived screwup > here for the view to shift that "freebsd is going the way of linux". > And then we lose a whole lot of what public "good" opinion FreeBSD > has. ;-) > > 2c, > > Adrian > Over the years , by installing and studying many operating system distributions , my opinions for FreeBSD has been converged toward the following : Supplying only a console-mode FreeBSD as a release is making FreeBSD unusable for peoples who they are not computing experts . To allow less experienced people to use FreeBSD easily , it is necessary to include a selected ports/packages into release distributions , therefore into so-called BASE as a /ports or /packages part . When a new FreeBSD release will be installed , it is becoming necessary to install many packages additionally , and setting many parameters in the *.conf , etc. , files to make it usable . One unfortunate situation is that some packages are NOT working at the release moment . In the packages tree , it seems that there is no any regular update policy for a specific release . It is possible to "make port_name" , but this is NOT so much usable also : For a specific package , which is installing within less than 30 minutes by pkg_add , required more than eighteen hours by "make ..." . Reason was that MAKE is an extremely STUPID system ( without BRAIN ) because , it is NOT able to remember that it has completed making a package part a few seconds before , and it is starting the same steps to apply up to the point that it is not necessary to make it once more ( after applying many steps which was applied before ) . One immediate reaction to such an idea is to mention PC-BSD . If the PC-BSD is the solution , what is the reason of maintaining a large FreeBSD ports tree and consuming a huge amount of efforts to manage a so large repository ? Another possibility is FreeBSD/Debian combination . When compared to Linux/Debian , it is unusable also , because , I do NOT know the reason , it is VERY slow . I am NOT suggesting to include as many packages as possible : Just an "OPTIMUM" number of packages to allow the users to have a working installation "out of the box" . It is possible to obtain an idea if there is a statistics set about downloaded packages by pkg_add . After setting a percentage to satisfy user needs , it will be easy to make a list of packages to include . Even myself I am NOT using FreeBSD , because I am NOT able to use it : For example , 9.0 RC2 : There is NO KDE4 at this moment , KDE3 is NOT working , GNOME2 is NOT working , the others I am NOT using because they are not capable as much as KDE or GNOME . If such a selected packages maintained within BASE /ports , or /packages , there will NOT be such difficulties to use the FreeBSD ( difficulty is transferred from the user to FreeBSD teams ) . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 04:06:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC8B1065675; Sun, 4 Dec 2011 04:06:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27A9E8FC08; Sun, 4 Dec 2011 04:06:53 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so5129475vbb.13 for ; Sat, 03 Dec 2011 20:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6VjbAqTLdwBz1N03ETVOnKAfhBz9Sdh5ZO7ER9etUxo=; b=lkBvgJ+y419w8glRxehBIoxqAbqPmsLYYT3J4ScQO7u9UJonF6JAfXz+s5rVvJudnA vbtcjUI/4ieXp3dUAv14S982b6VkHNBfnq30tsf+rDhYwdZ36207qgBPiBhG1Ywh3TiG jbMOr9CAzVfYbQUnWGiDSEJBdHqyIvSwQ/5mQ= MIME-Version: 1.0 Received: by 10.52.20.35 with SMTP id k3mr2466526vde.34.1322971613461; Sat, 03 Dec 2011 20:06:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Sat, 3 Dec 2011 20:06:53 -0800 (PST) In-Reply-To: References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> Date: Sun, 4 Dec 2011 12:06:53 +0800 X-Google-Sender-Auth: WMiVr8TbLljxO7e6Qmf3bOO6fOI Message-ID: From: Adrian Chadd To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , Roman Kurakin , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 04:06:54 -0000 On 4 December 2011 11:59, Mehmet Erol Sanliturk wrote: > Supplying only a console-mode FreeBSD as a release is making FreeBSD > unusable for > peoples who they are not computing experts . And the PCBSD crowd have stepped up to fill this gap. So we're free to concentrate on doing what we're good at, those who are good at polish and gui stuff can concentrate on what they're good at, and we just communicate well :) Thus, I don't even see this as a problem. I'm even using pcbsd 9, because guis are easy for doing desktop/VM development. ;) Adrian From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 22:53:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4A621065670 for ; Sat, 3 Dec 2011 22:53:27 +0000 (UTC) (envelope-from freebsd@beardz.net) Received: from svr06-mx.btshosting.co.uk (mx-2.btshosting.co.uk [178.63.196.248]) by mx1.freebsd.org (Postfix) with ESMTP id 799238FC08 for ; Sat, 3 Dec 2011 22:53:27 +0000 (UTC) Received: from [192.168.1.65] (027ecff8.bb.sky.com [2.126.207.248]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by svr06-mx.btshosting.co.uk (Postfix) with ESMTPSA id 57A0A4115A; Sat, 3 Dec 2011 22:53:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=beardz.net; s=default; t=1322952805; bh=3OxOetC8PCA1pVHrJuezcCY0rKfs2ha2vlkxGtxeXxQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EJlcUhyi5lbbktu6hVmqc8750Do8KH2HX7FQmzczAa9aWvqidc8p5nKDiM2ob6Qpt rgUb89Q8RshI2fnQnpGxzUNW0RxEjHqo+JXJjjONCiGBeKCuceP6+joGL/fc25SoX6 +X+uEk+YKE07RgGHP3sQ4+uRDuLK9Kk4WJHgbhM8= Message-ID: <4EDAA85F.7000104@beardz.net> Date: Sat, 03 Dec 2011 22:53:19 +0000 From: Jase Thew User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Roman Kurakin References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4ED9EAD0.3050207@beardz.net> <4EDA36C0.7090109@inse.ru> In-Reply-To: <4EDA36C0.7090109@inse.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 04 Dec 2011 04:19:43 +0000 Cc: freebsd-current , Peter Jeremy , Max Khon Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 22:53:27 -0000 On 03/12/2011 14:48, Roman Kurakin wrote: > Jase Thew wrote: >> On 03/12/2011 09:21, Roman Kurakin wrote: >>>> [SNIP] >>> You are right in general, except one small factor. We are talking about >>> bootstrap. >>> CVS is used by many as the one of the ways to get the sources to the >>> freshly >>> installed system to recompile to the last available source. It will >>> become inconvenient >>> to do it through the process of installing some ports for that. >>> Especially if corresponding >>> ports would require some other ports as dependences. >> >> As has been pointed out elsewhere in this thread, CVS doesn't cover >> csup, a utility in base which allows you to obtain the source >> trivially for the scenario you provide above. (Explicity ignoring >> cvsup which requires a port). > Does csup allows to checkout a random version from local cvs mirror? > So better to say csup(cvsup) does not cover cvs. Not quite sure what you are referring to by "random version". But csup certainly allows you to obtain the source as described in your scenario above ("last available source", even source at a particular point in time). Also, when I said CVS doesn't cover csup, I meant any removal of CVS from base would still leave csup available for obtaining source. Regards, Jase. From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 07:35:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5044E106566B for ; Sun, 4 Dec 2011 07:35:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D67F8FC13 for ; Sun, 4 Dec 2011 07:35:15 +0000 (UTC) Received: by mail-gx0-f182.google.com with SMTP id p1so1874439ggn.13 for ; Sat, 03 Dec 2011 23:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NmQCqBkTqn8J+XB6SP0fLEVov66j363PvhxICQ4iwBk=; b=kowJ3/Q7pEGoHWT+Mkj0eIApbpfcuvymQ1ZIjsr8d+LHrlw6cIWXq5SgOUs/9BosUY EF3Izv4+9MLDKnSYcx8jt0k9puZ3eRS8B7NS3BS8tCs5qle3/ozVonrIUIW0pew4s9O2 Y2ISepJc+MQW+DBcJgHPl5Z91pHM3IAmvypPw= MIME-Version: 1.0 Received: by 10.182.149.33 with SMTP id tx1mr878541obb.62.1322984115782; Sat, 03 Dec 2011 23:35:15 -0800 (PST) Received: by 10.182.62.227 with HTTP; Sat, 3 Dec 2011 23:35:15 -0800 (PST) In-Reply-To: <82bf04273014b38fc02a7c4068fb572d.squirrel@eternamente.info> References: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> <30c6076d340bdb3546054609939139c6.squirrel@eternamente.info> <9eb3377e660857aeec7f640fc5a41221.squirrel@eternamente.info> <82bf04273014b38fc02a7c4068fb572d.squirrel@eternamente.info> Date: Sat, 3 Dec 2011 23:35:15 -0800 Message-ID: From: Garrett Cooper To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 07:35:16 -0000 On Sat, Dec 3, 2011 at 7:21 PM, Nenhum_de_Nos wrote: > > On Sun, December 4, 2011 00:46, Nenhum_de_Nos wrote: >> >> On Sun, December 4, 2011 00:32, Adrian Chadd wrote: >>> Why not just run FreeNAS? >> >> thanks for the tip on FreeNAS, as others said too. >> >> will it run some other services, as http server for some stuff (wiki for example), edonkey and >> torrent clients, and some other stuff ? (I will visit the FreeNAS site and try to figure out) >> >> although it would solve the problem on configuring the box, I still have the doubts on the port >> multiplier being usefull on it, as FreeNAS will end on FreeBSD :) >> >> this port multiplier will work ok ? On Sil3124 and which others ? >> >> the tip on FreeNAS was great, but my main concern here is the sata hardware compatibility. I'd >> like to buy it knowing it will work :) >> >> thanks, >> >> matheus > > http://www.freenas.org/category/version-comparison > > unfortunately FreeNAS 8 won't be happy with less than 4GB RAM (I have 2GB on both hardware), and > version 8 won't have http and torrent :( Torrenting is available in the FreeNAS base, just not from the GUI. I can give you more tips about this if need be offline. > so far, I'll do as today and run FreeBSD 9 on its original form :) > > still looking for the port multiplier case, though. >From ye great Wikipedia (http://en.wikipedia.org/wiki/Port_multiplier): "This also hampers the use of Native Command Queuing (NCQ). This means that the full bandwidth of the link will most likely not be used. This kind of switching is therefore used when capacity is the major concern, and not performance." Sounds like port multipliers make the bus count = 1 (i.e. cable or controller fails and your entire storage array is toast) with less benefit than using a traditional HBA or hardware RAID controller >_>... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 09:03:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28D6106566B for ; Sun, 4 Dec 2011 09:03:27 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 448E28FC08 for ; Sun, 4 Dec 2011 09:03:26 +0000 (UTC) Received: by lahv2 with SMTP id v2so2540438lah.13 for ; Sun, 04 Dec 2011 01:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OZwCTucD8DI/G7VJ0eAp48cy34sH/dz69O3Pc1HNG6A=; b=N+GTZI88GHBHP9Vzw7RF3t5EedlsZtr3m7v6yALNFX7yKHBovsuT+bFjOtzUxVp6j3 tDOJLJQy7T94A4MyIr8vCCRT0MRE0uiWIGbgSzl3+NFOd/yNeTWIWpyr5pBByEQ8md3j FV5j243+cpaAUxya2Br+caltuwNUufzGcaRMs= MIME-Version: 1.0 Received: by 10.152.132.39 with SMTP id or7mr3090278lab.14.1322987720641; Sun, 04 Dec 2011 00:35:20 -0800 (PST) Received: by 10.152.18.169 with HTTP; Sun, 4 Dec 2011 00:35:20 -0800 (PST) In-Reply-To: <9eb3377e660857aeec7f640fc5a41221.squirrel@eternamente.info> References: <44b3c0f48d1cf64cc9237881c43c2be4.squirrel@eternamente.info> <30c6076d340bdb3546054609939139c6.squirrel@eternamente.info> <9eb3377e660857aeec7f640fc5a41221.squirrel@eternamente.info> Date: Sun, 4 Dec 2011 02:35:20 -0600 Message-ID: From: Scot Hetzel To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 09:03:27 -0000 On Sat, Dec 3, 2011 at 8:46 PM, Nenhum_de_Nos wrote: > > On Sun, December 4, 2011 00:32, Adrian Chadd wrote: >> Why not just run FreeNAS? > > thanks for the tip on FreeNAS, as others said too. > > will it run some other services, as http server for some stuff (wiki for example), edonkey and > torrent clients, and some other stuff ? (I will visit the FreeNAS site and try to figure out) > > although it would solve the problem on configuring the box, I still have the doubts on the port > multiplier being usefull on it, as FreeNAS will end on FreeBSD :) > > this port multiplier will work ok ? On Sil3124 and which others ? > According to this web site, it should work with the Sil3124: http://www.addonics.com/products/ad5sapm.php Scot From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 09:08:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F55106564A for ; Sun, 4 Dec 2011 09:08:29 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 4B13B8FC0A for ; Sun, 4 Dec 2011 09:08:27 +0000 (UTC) Received: (qmail 84279 invoked from network); 4 Dec 2011 09:08:26 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Dec 2011 09:08:26 -0000 Date: Sun, 04 Dec 2011 10:08:26 +0100 (CET) Message-Id: <20111204.100826.74672472.sthaug@nethelp.no> To: freebsd-current@freebsd.org From: sthaug@nethelp.no In-Reply-To: <4EDABDE8.9060406@FreeBSD.org> References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 09:08:29 -0000 > I want to ask some serious questions here, because I genuinely want to > understand your thought process. > > 1. Do you install *any* ports/packages on a new system before you update > the source? Answering just for myself here... Going back a bit, in many cases I didn't need to install any packages. Nowadays as a minimum I install Perl. > 2. If so, why is installing one more unthinkable? It's not unthinkable. However, IMHO we're then gradually edging closer to various Linux distros that need lots of packages installed to do anything useful. And that, of course, brings up the question - why not just use Linux in the first place? For me, having FreeBSD as a "self contained" system with lots of useful functionality in the base system is one of the main reasons why I use FreeBSD. > 3. Why is it a problem if the port/package you need to install in the > early stages has dependencies? For me the dependency on other ports/packages, in itself, is not really a problem. I am much more worried about the fact that a FreeBSD release corresponds to one particular point in time, while the ports collection moves on - and that we'll end up with a FreeBSD release which is broken with the existing ports collection (but works with an earlier version). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 10:30:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 646611065672 for ; Sun, 4 Dec 2011 10:30:59 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost03.isp.att.net (fmailhost03.isp.att.net [204.127.217.103]) by mx1.freebsd.org (Postfix) with ESMTP id 52AB68FC19 for ; Sun, 4 Dec 2011 10:30:59 +0000 (UTC) Date: Sun, 4 Dec 2011 10:25:33 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-130-165.sdf.bellsouth.net[68.210.130.165]) by isp.att.net (frfwmhc03) with SMTP id <20111204102533H03005riore>; Sun, 4 Dec 2011 10:25:33 +0000 X-Originating-IP: [68.210.130.165] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: Message-Id: <20111204103059.646611065672@hub.freebsd.org> Cc: Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 10:30:59 -0000 >From Mehmet Erol Sanliturk : > Supplying only a console-mode FreeBSD as a release is making FreeBSD > unusable for > peoples who they are not computing experts . > To allow less experienced people to use FreeBSD easily , it is necessary to > include a > selected ports/packages into release distributions , therefore into > so-called BASE as a > /ports or /packages part . > When a new FreeBSD release will be installed , it is becoming necessary to > install many packages additionally , and setting many parameters in the > *.conf , etc. , files to make it usable . One unfortunate situation is that > some packages are NOT working at the release moment . In the packages tree > , it seems that there is no any regular update policy for a specific > release . It is possible to "make port_name" , but this is NOT so much > usable also : For a specific package , which is installing within less > than 30 minutes by pkg_add , required more than eighteen hours by "make > ..." . Reason was that MAKE is an extremely STUPID system ( without BRAIN ) > because , it is NOT able to remember that it has completed making a package > part a few seconds before , and it is starting the same steps to apply up > to the point that it is not necessary to make it once more ( after applying > many steps which was applied before ) . On an old computer with 256 MB RAM, or less, building some of the bigger ports can take many hours. I never dared attempt to build KDE or GNOME! But I don't think PC-BSD runs with 256 MB RAM. In the recent past, FreeBSD releases offered extra iso images with packages, sysinstall even offered to install packages. I tried that once, with FreeBSD 7.0, or was it 7.1 or 6.2, and didn't really get a workable system. GNOME and KDE didn't work. When I tried portupgrading, I messed everything, went back to Linux (Slackware), and when FreeBSD 8.0 was released, cleaned out my old installation, and installed FreeBSD 8.0 fresh. Now, on a new computer, I still use icewm, haven't attempted KDE or GNOME yet. Tom From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 12:31:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 365B71065670 for ; Sun, 4 Dec 2011 12:31:49 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id BE18D8FC12 for ; Sun, 4 Dec 2011 12:31:48 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 54C91E6630; Sun, 4 Dec 2011 12:31:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=5ORxx4/hVP6K tW7yycA0yMeKuTM=; b=zGiGxKQKt6KtRG6rqOTp6FDAQsHVIfr8Sfp+kg5iT4/L bLlIjwhHqot2OzsrLs2KBJDqP5HP+3kjj1mx8mm3yZovgPBuMDDg04L6nmsRYYRk u/vqbFNZyvCAsnhnfJ9JFQYcTYejZMUZICl0tepJgffpWpnYAiQIuATHR86nvck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=G99goY HIxHctBANK6K5D7PSBm0ZkiEt2C5/Eyu+3+AjixyMD+u5HOiwhOZOjfadPnH+xii 4jI8DgYOGehPu/5oQxU8sPLnbtqQBUOWRJYbGnvR1kIRkWtVEOA0DsDweAkHhWZc gE4c9ww8H+kCiRJnA7uRq/5h9+e2Irs2K0yis= Received: from [192.168.1.120] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 27C81E65F8; Sun, 4 Dec 2011 12:31:47 +0000 (GMT) Message-ID: <4EDB6832.3040700@cran.org.uk> Date: Sun, 04 Dec 2011 12:31:46 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sthaug@nethelp.no References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <20111204.100826.74672472.sthaug@nethelp.no> In-Reply-To: <20111204.100826.74672472.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 12:31:49 -0000 On 04/12/2011 09:08, sthaug@nethelp.no wrote: > It's not unthinkable. However, IMHO we're then gradually edging closer > to various Linux distros that need lots of packages installed to do > anything useful. And that, of course, brings up the question - why not > just use Linux in the first place? For me, having FreeBSD as a "self > contained" system with lots of useful functionality in the base system > is one of the main reasons why I use FreeBSD. +1 -- Bruce From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 12:58:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B411B1065672; Sun, 4 Dec 2011 12:58:34 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id EF9518FC19; Sun, 4 Dec 2011 12:58:32 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id 11B8E5D084; Sun, 4 Dec 2011 13:58:59 +0000 (UTC) Message-ID: <4EDB7054.3020203@inse.ru> Date: Sun, 04 Dec 2011 17:06:28 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Doug Barton References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> In-Reply-To: <4EDABDE8.9060406@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 12:58:34 -0000 Doug Barton wrote: > On 12/3/2011 1:21 AM, Roman Kurakin wrote: > >> Doug Barton wrote: >> >>> [...] The fact that we have so many people who are radically >>> change-averse, no matter how rational the change; is a bug, not a >>> feature. >>> >>> This particular bug is complicated dramatically by the fact that >>> the majority view seems to lean heavily towards "If I use it, it >>> must be the default and/or in the base" rather than seeing ports as >>> part of the overall operating SYSTEM. >>> >>> >> You are right in general, except one small factor. We are talking >> about bootstrap. >> > You realize that you just 100% demonstrated the truth of what I wrote > above, right? :) > Don't you really think that one would protect smth that he/she not using? I hope no ;-) People (and me one of them) just try to protect smth they like in a system and they use. If you are ready to provide alternative the number of people against this change will decrease to smaller list that don't like change habits or use smth in much wider area. >> CVS is used by many as the one of the ways to get >> the sources to the freshly installed system to recompile to the last >> available source. It will become inconvenient to do it through the >> process of installing some ports for that. Especially if >> corresponding ports would require some other ports as dependences. >> > > I want to ask some serious questions here, because I genuinely want to > understand your thought process. > > 1. Do you install *any* ports/packages on a new system before you update > the source? > No. Usually base system is updated in a first turn. I even do not install pkgs usually. > 2. If so, why is installing one more unthinkable? > Sorry, but the previous answer was opposite. But despite of that, I do not like additional packages. I've started to use jails more often not only from a security issue, but also cause of the problems with upgrade. The more packages you have in the system - the harder to upgrade them if the last upgrade was not done recently. But this is the other story. > 3. Why is it a problem if the port/package you need to install in the > early stages has dependencies? > The amount of time you need to get and compile all the stuff. The first packages I usually install is the 'bash' and 'portupgrade'. I didn't ever count dependences for just two packages I need, but it is about 15-20 of them. I can do working system solving the most of needed task without both of them. And I do my job while they are installing (or better to say their dependences). If I need to fix some detached from the internet systems, I do not need to keep the set of packages for set of branches and for set of dependences just only sources, base system, my hands and my head. rik > > Thanks, > > Doug > > From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 13:09:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FE96106564A for ; Sun, 4 Dec 2011 13:09:39 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id D2C0B8FC08 for ; Sun, 4 Dec 2011 13:09:38 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id C0FD65D536; Sun, 4 Dec 2011 14:10:00 +0000 (UTC) Message-ID: <4EDB72EA.4040205@inse.ru> Date: Sun, 04 Dec 2011 17:17:30 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Jase Thew References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4ED9EAD0.3050207@beardz.net> <4EDA36C0.7090109@inse.ru> <4EDAA85F.7000104@beardz.net> In-Reply-To: <4EDAA85F.7000104@beardz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current , Peter Jeremy , Max Khon Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 13:09:39 -0000 Jase Thew wrote: > On 03/12/2011 14:48, Roman Kurakin wrote: >> Jase Thew wrote: >>> On 03/12/2011 09:21, Roman Kurakin wrote: > >>>> [SNIP] >>>> You are right in general, except one small factor. We are talking >>>> about >>>> bootstrap. >>>> CVS is used by many as the one of the ways to get the sources to the >>>> freshly >>>> installed system to recompile to the last available source. It will >>>> become inconvenient >>>> to do it through the process of installing some ports for that. >>>> Especially if corresponding >>>> ports would require some other ports as dependences. >>> >>> As has been pointed out elsewhere in this thread, CVS doesn't cover >>> csup, a utility in base which allows you to obtain the source >>> trivially for the scenario you provide above. (Explicity ignoring >>> cvsup which requires a port). >> Does csup allows to checkout a random version from local cvs mirror? >> So better to say csup(cvsup) does not cover cvs. > > Not quite sure what you are referring to by "random version". But csup > certainly allows you to obtain the source as described in your > scenario above ("last available source", even source at a particular > point in time). By random version I mean any exact version I need, not only head of branch or tag. rik > Also, when I said CVS doesn't cover csup, I meant any removal of CVS > from base would still leave csup available for obtaining source. > > Regards, > > Jase. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 15:03:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD4D1065675 for ; Sun, 4 Dec 2011 15:03:21 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [IPv6:2a01:4f8:101:4201::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id 79ADA8FC13 for ; Sun, 4 Dec 2011 15:03:20 +0000 (UTC) Received: from talaxian.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 5ACAA5C3B for ; Sun, 4 Dec 2011 16:03:18 +0100 (CET) Message-ID: <4EDB8BB5.50607@borderworlds.dk> Date: Sun, 04 Dec 2011 16:03:17 +0100 From: Christian Laursen Organization: The Border Worlds User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> In-Reply-To: <4EDABDE8.9060406@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 15:03:21 -0000 On 12/04/11 01:25, Doug Barton wrote: [snip] Replying to a somewhat random mail in this thread. Has anyone considerede that the people actually using CVS for getting the source might be somewhat overrepresented on freebsd-current? If I had to guess, the average user is using either freebsd-update or csup (or even cvsup) to update a freshly installed system. Those that need the added flexibility provided by using CVS directly should be fully able to install it using pkg_add. Personally I pkg_add screen on new systems before doing anything else. I have never considered that a problem. I use CVS myself from time to time, but I see no need for it to be in base for that reason. BTW. I think the bikeshed should be painted blue. -- Christian Laursen From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 15:33:36 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4B3F1065670 for ; Sun, 4 Dec 2011 15:33:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 651978FC1C for ; Sun, 4 Dec 2011 15:33:35 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so5660318wgb.31 for ; Sun, 04 Dec 2011 07:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/urauwDICYlCzIIxUPswW4Fi3WcvcN33fDAajBe3k9M=; b=Xbe0to0TVrg7GsnbH7/TbG/UcryFbAFcdcpOidXRlr7EjseckQCClFK0IjAIkJRL1a It2SRdo/8F2XyXM1MTGKVk9FVrwaSA1Wh/wxCEaR8pTovXRrk+W1j7Gk8pzN3Q/R3CjP f4itMd1yYEa6Se89sSmFQiU6RYybWLM6Lam3M= Received: by 10.216.14.37 with SMTP id c37mr1435502wec.86.1323012815280; Sun, 04 Dec 2011 07:33:35 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id fw16sm22809951wbb.13.2011.12.04.07.33.33 (version=SSLv3 cipher=OTHER); Sun, 04 Dec 2011 07:33:34 -0800 (PST) Sender: Alexander Motin Message-ID: <4EDB92CC.5020800@FreeBSD.org> Date: Sun, 04 Dec 2011 17:33:32 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Nenhum_de_Nos References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 15:33:36 -0000 On 04.12.2011 04:46, Nenhum_de_Nos wrote: > this port multiplier will work ok ? On Sil3124 and which others ? > > the tip on FreeNAS was great, but my main concern here is the sata hardware compatibility. I'd > like to buy it knowing it will work :) Port multipliers supported by all siis(4) hardware and many mvs(4) and ahci(4). In case of mvs(4) and ahci(4) support and effectiveness depends on controller model. SiI3124 is known to be a good option. If performance is not the first priority (150MB/s should be enough for home NAS) -- SiI3132 and SiI3531 are also fine. 6Gbps Marvell 88SE91xx in _non-RAID_ versions also good on tests, but there are not so many reports about them yet. I can't say for sure about ICH7 and NM10, but many Intel chipset controllers support port multipliers when AHCI is enabled. I have feeling that all of them support it in hardware (at least since ICH8), but it is blocked by BIOS. At least I had motherboard that had and lost port multipliers support after some BIOS update. You may see that info in ahci(4) boot messages. Unluckily now Intel supports only command-based switching, that allows only one device beyond port multiplier execute commands at a time and significantly limits performance. Controller support for more effective FIS-based switching reported by ahci(4) and mvs(4) drivers during boot. All siis(4) controllers support FIS-based switching. Also note that not all controller BIOSes support detecting and booting from devices on port multiplier, except one on the first port. Consider that when choosing controller and partitioning disks if you are going to boot from them. Port multipliers themselves are quite simple from driver point of view, so all of them should be supported if they follow standards. At least I haven't seen reports yet that some one is not supported. What's about reliability comparison -- I have no info. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 15:34:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9357F1065679 for ; Sun, 4 Dec 2011 15:34:41 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E85C8FC18 for ; Sun, 4 Dec 2011 15:34:40 +0000 (UTC) Received: by ywp17 with SMTP id 17so5531529ywp.13 for ; Sun, 04 Dec 2011 07:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sD7iv+7MT84izHc0AJIh/9Wn6StQU3SvulZFYT9G3tY=; b=lDyaBJ0EyCxAFRZE7H9FAoQtaTGBm8SnARpy4jfs9vhZ5/VZ2w+L0Wtb4hhaXMDYEH JdZolxdT5iPH97kU/9ueB6oWyojigeQ5Wgi7CeK+XXzRaUpfn1MI0IZrdilyAQXr+jXn V5pHlekMejigYTxd7MPLA9oHeSIVkdUX405Hw= MIME-Version: 1.0 Received: by 10.236.189.97 with SMTP id b61mr6898764yhn.116.1323012880346; Sun, 04 Dec 2011 07:34:40 -0800 (PST) Received: by 10.150.184.17 with HTTP; Sun, 4 Dec 2011 07:34:40 -0800 (PST) In-Reply-To: <4EDB8BB5.50607@borderworlds.dk> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDB8BB5.50607@borderworlds.dk> Date: Sun, 4 Dec 2011 17:34:40 +0200 Message-ID: From: Alexander Yerenkow To: Christian Laursen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 15:34:41 -0000 I understand that this is not my business at all :) But anyway, IMHO, you should take GPL-free effort as an example. When you visit http://wiki.freebsd.org/GPLinBase you easily can see what going to be dumped, why, and with what it's going to be replaced. What I mean exactly - throw emails to mail list like this, telling that we need to specify software list for removal, provide page in wiki, with each software listed, propose something in exchange, collect not opinions, but real usage examples, and some stats, like "feature A is used by approx 100 peoples". Or "Feature B is used by 3 peoples, but there's no replace ATM". If you think it's time to move from CVS, create page in wiki, find most frequent use cases, think about replacing them with other tools, collaborate with peoples, create simple pro/con table with free editing. I'm sure that very few peoples, or even no one know _every_ usage of FreeBSD base, so deep investigating on each item is would be necessary. That's only my 2c. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 16:38:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3E3C106566B for ; Sun, 4 Dec 2011 16:38:12 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id 52CE48FC0C for ; Sun, 4 Dec 2011 16:38:12 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id EE3AB5CE1E; Sun, 4 Dec 2011 17:38:30 +0000 (UTC) Message-ID: <4EDBA3C9.7050904@inse.ru> Date: Sun, 04 Dec 2011 20:46:01 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Christian Laursen References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDB8BB5.50607@borderworlds.dk> In-Reply-To: <4EDB8BB5.50607@borderworlds.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 16:38:12 -0000 Christian Laursen wrote: > On 12/04/11 01:25, Doug Barton wrote: > > [snip] > > Replying to a somewhat random mail in this thread. > > Has anyone considerede that the people actually using CVS for getting > the source might be somewhat overrepresented on freebsd-current? Probably you are right. I guess I would never use CVS if I wouldn't be a software developer and was not able to fix smth by my self. But as a developer I like to see the tool I got accustomed out of the box as it was to for many years. Especially after I've started to help to friends working in companies with restricted Internet access or detached systems. I've started to hate most of linux distributions since they do not have almost any tool for digging and solving problems. But with FreeBSD I even can solve the problem from my seat just giving instructions by phone or skype. rik > If I had to guess, the average user is using either freebsd-update or > csup (or even cvsup) to update a freshly installed system. Those that > need the added flexibility provided by using CVS directly should be > fully able to install it using pkg_add. > > Personally I pkg_add screen on new systems before doing anything else. > I have never considered that a problem. > > I use CVS myself from time to time, but I see no need for it to be in > base for that reason. > > BTW. I think the bikeshed should be painted blue. > From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 16:49:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ED121065680 for ; Sun, 4 Dec 2011 16:49:52 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 09F188FC08 for ; Sun, 4 Dec 2011 16:49:51 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id CA4C91CC6C; Sun, 4 Dec 2011 13:49:48 -0300 (BRT) Received: from 187.64.96.140 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sun, 4 Dec 2011 14:49:48 -0200 Message-ID: <9b7059121aa0602802bab30619f04e02.squirrel@eternamente.info> In-Reply-To: <4EDB92CC.5020800@FreeBSD.org> References: <4EDB92CC.5020800@FreeBSD.org> Date: Sun, 4 Dec 2011 14:49:48 -0200 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Sil3124 + Sil4726 PortMultipier and FreeBSD9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 16:49:52 -0000 On Sun, December 4, 2011 13:33, Alexander Motin wrote: > On 04.12.2011 04:46, Nenhum_de_Nos wrote: >> this port multiplier will work ok ? On Sil3124 and which others ? >> >> the tip on FreeNAS was great, but my main concern here is the sata hardware compatibility. I'd >> like to buy it knowing it will work :) > > Port multipliers supported by all siis(4) hardware and many mvs(4) and > ahci(4). In case of mvs(4) and ahci(4) support and effectiveness depends > on controller model. SiI3124 is known to be a good option. If > performance is not the first priority (150MB/s should be enough for home > NAS) -- SiI3132 and SiI3531 are also fine. 6Gbps Marvell 88SE91xx in > _non-RAID_ versions also good on tests, but there are not so many > reports about them yet. thanks for the info. I plan on not using hardware raid. will be Geom_(mirror/stripe) - as is now - or ZFS. I have sil3124 on PCI so far, and an older version that is being used on current file server: atapci1@pci0:0:9:0: class=0x010400 card=0x61141095 chip=0x31141095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SATALink/SATARaid Controller (Sil 3114)' class = mass storage subclass = RAID two years, always on and no issues so far. > I can't say for sure about ICH7 and NM10, but many Intel chipset > controllers support port multipliers when AHCI is enabled. I have > feeling that all of them support it in hardware (at least since ICH8), > but it is blocked by BIOS. At least I had motherboard that had and lost > port multipliers support after some BIOS update. You may see that info > in ahci(4) boot messages. Unluckily now Intel supports only > command-based switching, that allows only one device beyond port > multiplier execute commands at a time and significantly limits > performance. Controller support for more effective FIS-based switching > reported by ahci(4) and mvs(4) drivers during boot. All siis(4) > controllers support FIS-based switching. great info, I found some PCI-X and PCIe based sil3124 card that report FIS-compatible, but I can't find on my PCI version. By your saying, I get great news then :) I'll buy FIS-enabled PM :) I Plan on buying if needed a PCIe version of it, and if I find port multiplier for SATA 6Gbs, I will plan on one also. > Also note that not all controller BIOSes support detecting and booting > from devices on port multiplier, except one on the first port. Consider > that when choosing controller and partitioning disks if you are going to > boot from them. thanks again, but I plan on booting from onboard controller. The PM is intended on expanding capacity, and as is home file server, speed won't be a huge issue. If I can stream a high definition video twice, its ok. > Port multipliers themselves are quite simple from driver point of view, > so all of them should be supported if they follow standards. At least I > haven't seen reports yet that some one is not supported. What's about > reliability comparison -- I have no info. ok, I will do some testing when I receive it and plan to tell here results. thanks for all, matheus > -- > Alexander Motin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Vítima da Oi entre 2007 e 2011. We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 17:08:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BE0A106566C for ; Sun, 4 Dec 2011 17:08:31 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id F2C368FC0C for ; Sun, 4 Dec 2011 17:08:30 +0000 (UTC) Received: from [IPv6:2001:470:28:140:707e:9d49:9947:3ad0] ([IPv6:2001:470:28:140:707e:9d49:9947:3ad0]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id pB4H8QKI047920 for ; Sun, 4 Dec 2011 19:08:26 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4EDBA903.20006@ukr.net> Date: Sun, 04 Dec 2011 19:08:19 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Sun, 04 Dec 2011 19:08:26 +0200 (EET) X-Spam-Status: No, score=-94.3 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL, TO_NO_BRKTS_DIRECT, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Cc: Subject: 9.0-RC2 & make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 17:08:31 -0000 core# uname -a FreeBSD core.domain.com 9.0-RC2 FreeBSD 9.0-RC2 #0: Sat Nov 12 18:35:25 UTC 2011 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # /usr/bin/make /usr/obj/usr/src/make.amd64/make: Permission denied *** Error code 126 Stop in /usr/src. wtf? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 17:13:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B71106566B for ; Sun, 4 Dec 2011 17:13:55 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id E9E818FC0C for ; Sun, 4 Dec 2011 17:13:54 +0000 (UTC) Received: from [IPv6:2001:470:28:140:707e:9d49:9947:3ad0] ([IPv6:2001:470:28:140:707e:9d49:9947:3ad0]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id pB4HDoCA048719 for ; Sun, 4 Dec 2011 19:13:51 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4EDBAA47.2070000@ukr.net> Date: Sun, 04 Dec 2011 19:13:43 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EDBA903.20006@ukr.net> In-Reply-To: <4EDBA903.20006@ukr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Sun, 04 Dec 2011 19:13:51 +0200 (EET) X-Spam-Status: No, score=-97.7 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Subject: Re: 9.0-RC2 & make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 17:13:55 -0000 04.12.2011 19:08, Vladislav V. Prodan wrote: > # /usr/bin/make > /usr/obj/usr/src/make.amd64/make: Permission denied > *** Error code 126 > > Stop in /usr/src. > Sorry. It's my fault, I put: -o setuid=off $poolname/usr/obj -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 17:53:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8120B106566B for ; Sun, 4 Dec 2011 17:53:19 +0000 (UTC) (envelope-from rik@inse.ru) Received: from ns.rikbsd.org (ns.rikbsd.org [95.143.215.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3150E8FC0C for ; Sun, 4 Dec 2011 17:53:19 +0000 (UTC) Received: from [127.0.0.1] (wn.rikbsd.org [192.168.1.254]) by ns.rikbsd.org (Postfix) with ESMTPA id 093FC5CEC2; Sun, 4 Dec 2011 18:53:45 +0000 (UTC) Message-ID: <4EDBB56B.9020308@inse.ru> Date: Sun, 04 Dec 2011 22:01:15 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.24 (X11/20110906) MIME-Version: 1.0 To: Christian Laursen References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDB8BB5.50607@borderworlds.dk> In-Reply-To: <4EDB8BB5.50607@borderworlds.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 17:53:19 -0000 Christian Laursen wrote: > [...] > I use CVS myself from time to time, but I see no need for it to be in > base for that reason. By the way, since there is no way to count +/- I guess the rule "do not brake that is working or provide a way to do the same" should work. If there is a number of users of smth it should not be broken. csup/cvsup does not provide the same. rik > > BTW. I think the bikeshed should be painted blue. > From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 18:07:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BD09106582E for ; Sun, 4 Dec 2011 18:07:48 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50FDC8FC1A for ; Sun, 4 Dec 2011 18:07:48 +0000 (UTC) Received: by ggnp1 with SMTP id p1so2138129ggn.13 for ; Sun, 04 Dec 2011 10:07:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.2.136 with SMTP id 8mr1123423obu.71.1323022067565; Sun, 04 Dec 2011 10:07:47 -0800 (PST) Received: by 10.182.187.8 with HTTP; Sun, 4 Dec 2011 10:07:47 -0800 (PST) X-Originating-IP: [93.221.182.86] In-Reply-To: <4EDBB56B.9020308@inse.ru> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDB8BB5.50607@borderworlds.dk> <4EDBB56B.9020308@inse.ru> Date: Sun, 4 Dec 2011 19:07:47 +0100 Message-ID: From: "C. P. Ghost" To: Roman Kurakin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 18:07:48 -0000 On Sun, Dec 4, 2011 at 7:01 PM, Roman Kurakin wrote: > Christian Laursen wrote: >> >> [...] >> >> I use CVS myself from time to time, but I see no need for it to be in base >> for that reason. > > By the way, since there is no way to count +/- I guess the rule "do not > brake that is working > or provide a way to do the same" should work. If there is a number of users > of smth it should > not be broken. csup/cvsup does not provide the same. Actually, a whole lot of stuff that was still perfectly useable has been deprecated over the years. I'm thinking of net/freebsd-uucp for example. Instead of moving all this functionality into ports, and therefore into a rather unstable moving target (how sure are we that the corresponding distfiles will stay available as long as /usr/src?), I'd have preferred that it be moved into a dedicated part of the base tree, e.g. /usr/old (or /usr/deprecated, or /usr/historic, /usr/vintage, whatever). Therefore, we could simply add /usr/old/bin to PATH, and link against /usr/old/lib, use headers from /usr/old/include, have the source in /usr/old/src, and so on. If you don't want to build the system with that, just add a knob in /usr/src.conf to exclude /usr/old. That's the kind of stable system I'd wish for FreeBSD instead of the current model or slowly eroding functionality and mysteriously disappearing utilities _and_ source code. > rik -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 19:23:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F105E1065673; Sun, 4 Dec 2011 19:23:25 +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 A53708FC0A; Sun, 4 Dec 2011 19:23:25 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pB4JNOMU056739; Sun, 4 Dec 2011 14:23:24 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sun, 04 Dec 2011 14:23:24 -0500 (EST) Date: Sun, 4 Dec 2011 14:23:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Doug Barton In-Reply-To: <4EDABCEA.4000601@FreeBSD.org> Message-ID: References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> <4EDABCEA.4000601@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, sthaug@nethelp.no Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 19:23:26 -0000 On Sat, 3 Dec 2011, Doug Barton wrote: > On 12/3/2011 5:03 AM, sthaug@nethelp.no wrote: >>>> The fact that we have so many people who are radically >>>> change-averse, no matter how rational the change; is a bug, not a >>>> feature. >>>> >>>> This particular bug is complicated dramatically by the fact that >>>> the majority view seems to lean heavily towards "If I use it, it >>>> must be the default and/or in the base" rather than seeing ports >>>> as part of the overall operating SYSTEM. >> >> I don't think of myself as change-averse. I've been using FreeBSD >> since 1996, and there have been lots of changes since that time. But >> two of the most important reasons I still use FreeBSD are: >> >> - Stability: Both in the sense of "stays up basically forever", and >> in the sense of "changes to interfaces and commands are carefully >> thought through and not applied indiscriminately". For instance, I >> like very much the fact that the ifconfig command can configure VLANs >> etc - while Linux has introduced new commands to do this. > > Agreed. > >> - The base system is a *system* and comes with most of what I need, >> for instance tcpdump and BIND. For me the fact that I don't need to >> install lots of packages to have a usable system is a *good* thing. > > So 2 things here that I really wish people would think about. > > 1. If you're using *any* ports/packages then you're already > participating in the larger operating *system* that I described, so > installing a few more won't hurt. (Seriously, it won't.) > > 2. In (the very few) areas where integration of 3rd party apps into the > base makes sense, no problem. But at this point the fact that a lot of > 3rd party stuff is changing more rapidly than it used to, and often in > incompatible ways and/or at incompatible schedules with our release > process, means that we have to re-think how we do this. > > You mentioned BIND, which is a great example of 2. above. I'll have more > to say about this soon, but my plan is to remove it from the base for > 10.x because the current situation is unmanageable. In my mind, your "2. above" is an example to keep BIND in the base. When I build FreeBSD from sources, I know that everything in src/ works together. I can update my system and be reasonably assured of that. However, updating ports is not at all like that. There is much more work involved in updating ports - you really need an extra test box to make sure that everything works together before updating the deployed system. One might argue that you need an extra test box even for updating src/ only, but in my experience it's not been nearly as necessary as updating ports. We don't have @ports resources for it, but in a perfect world there would be a ports branch for each supported FreeBSD branch. I would like security updates and bug fixes for ports, but not latest and greatest stuff. I like BIND in base (I won't argue against removing it, just stating my preference), and I would also like to see LDAP (at least client) in base. IMHO, FreeBSD base should include everything necessary to work in a networked environment. -- DE From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 19:51:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60788106566B for ; Sun, 4 Dec 2011 19:51:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF7A8FC0C for ; Sun, 4 Dec 2011 19:51:22 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pB4JpLoN091157 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 4 Dec 2011 11:51:22 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EDBCF47.9000301@freebsd.org> Date: Sun, 04 Dec 2011 11:51:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Third party apps in base [was CVS removal...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 19:51:23 -0000 On 12/3/11 11:02 AM, grarpamp wrote: > Hi. I have many dependencies on CVS that I 'need' 'out of the box'. > Yet at the same time, I would not mind at all if it went to ports. > In fact, and from a general position regarding all third party apps, > I encourage it. > > Mostly because they are not authored or maintained by FreeBSD. Yet > they are integrated, often in ways that need work to remove and/or > manage separately. Such as when the upstream drops a feature version > and FreeBSD only drops security/stability patches. > > If a lighter method than ports is desired, all the third party apps > have binary packages (/pub/FreeBSD/ports/packages/All). And even > pkg_add can be skipped if that's too heavy. The bit of extra work > at install time isn't much, especially when your install already > does a bunch of scripted localization. I have advocated for some time that there be different classes of packages. "Primary" packages, which are guaranteed to be with the release or at most very near by, and secondary packages which are fetched separately. Primary packages would be maintained by the ports team, but would be tested and included by the release engineers as if they were part of the base system. There may even by room for other classes. > And as an aside, with what to this writer seems to be the majority > of the world moving to git... I think it should now properly become > user/admin choice as to which to install from ports/packages/source. > Rather than say, being equally agnostic/fair in the other direction > by including them all to satisfy all whims. > > The only justified exception I see would be to include whichever > one is used by the master repository itself, which today is SVN. > And as a topic for another thread, I think even that should be > switched to git within the next couple years. > > And as another topic for another thread... the same goes for the > various current methods of source (and other) distribution of the > FreeBSD project. I'd be quite happy to see rsync become authoritative > and even replace all of them. > > Lastly, regarding baking and planning... making more use of the > wiki to document the FreeBSD timeline would be interesting. While > distant dates my not be known, features and dependancies usually are. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 19:54:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C98106564A for ; Sun, 4 Dec 2011 19:54:32 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 155118FC12 for ; Sun, 4 Dec 2011 19:54:32 +0000 (UTC) Received: from maka.home.yamagi.org (g231182021.adsl.alicedsl.de [92.231.182.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 5CCDC1666333; Sun, 4 Dec 2011 20:54:28 +0100 (CET) Date: Sun, 4 Dec 2011 20:54:27 +0100 From: Yamagi Burmeister To: kostikbel@gmail.com Message-Id: <20111204205427.f0989300.lists@yamagi.org> In-Reply-To: <20100702184426.GW13238@deviant.kiev.zoral.com.ua> References: <4C2E2BFD.1030204@elischer.org> <20100702184426.GW13238@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__4_Dec_2011_20_54_27_+0100_aeM58VjxTMJ7ni0n" Cc: freebsd-current@freebsd.org, julian@elischer.org Subject: Re: running old binaries on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 19:54:32 -0000 --Signature=_Sun__4_Dec_2011_20_54_27_+0100_aeM58VjxTMJ7ni0n Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2 Jul 2010 21:44:26 +0300 Kostik Belousov wrote: > On Fri, Jul 02, 2010 at 11:12:13AM -0700, Julian Elischer wrote: > > every now and then, for fun I run up a chroot of freebsd 1.1. or 1.0=20 > > under a chroot. Usually hillarity ensues with teh 15 second kernel=20 > > compile and the 4 minute make world. > >=20 > > in -current I can't do that any more.. any binary just exits with 'Abor= t'. > >=20 > > I think I last tried it in 7.0 or there abouts. > >=20 > > I have options COMPAT_AOUT and COMPAT_FREEBSD4 through COMPAT_FREEBSD7 > >=20 > > does anyone else have any ideas as to what may be needed? > >=20 > > I vaguely remember another option but I am not seeing it at the moment. > >=20 > > For those of you who do not remember, 1.0 had a.out static binaries onl= y. > >=20 >=20 > Can you ktrace/kdump the run attempt, I suspect that abort is > sent by image activator. >=20 > Also, please put some static binary somewhere to download. Hi, digging around I found one of the first programs ever written. It's an static aout binary from 1994 or so, running it on FreeBSD 8.2 shows exactly this problem. Some more extensive tests narrowed this problem down to FreeBSD 1.x binaries, they're all broken. FreeBSD 2 aout binaries are still working.=20 Since Google found this rather old thread I decided to provide the data your requested, but I do not insist on a fix. I guess that nobody will try to run FreeBSD 1.x binaries these day... So if you want to spend some work on this I'll test patches but if you decide to do nothing it's okay. This is the /bin/sh of FreeBSD 1.0 (taken from the official installation cd image f=FCr i386): % file sh sh: VAX demand paged pure executable % ./sh Abort The ktrace / kdump: 1065 ktrace RET ktrace 0 1065 ktrace CALL execve(0xbfbfee1b,0xbfbfecf8,0xbfbfed00) 1065 ktrace NAMI "./sh" I've uploaded the binary to: http://deponie.yamagi.org/freebsd/tmp/sh_freebsd1 Thanks, Yamagi --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Sun__4_Dec_2011_20_54_27_+0100_aeM58VjxTMJ7ni0n Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7bz/gACgkQWTjlg++8y8seswCeMEdxBzGv0IQiLHBHos0SFLtx 5LAAnj9DRPeG+lf4WH3g/FU3mJbkJ5f9 =BHto -----END PGP SIGNATURE----- --Signature=_Sun__4_Dec_2011_20_54_27_+0100_aeM58VjxTMJ7ni0n-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 20:19:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6604106566B; Sun, 4 Dec 2011 20:19:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE998FC16; Sun, 4 Dec 2011 20:19:47 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pB4KJj1h091290 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 4 Dec 2011 12:19:46 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EDBD5EF.9070207@freebsd.org> Date: Sun, 04 Dec 2011 12:19:59 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Adrian Chadd References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , Roman Kurakin , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 20:19:47 -0000 On 12/3/11 6:40 PM, Adrian Chadd wrote: > The problem I have with all of this is pretty simple. > > With the CVS in base, it's treated like the (mostly) rest of the > system in a stable release - ie, people don't simply keep updating it > to the latest and greatest without some testing. If there are any > critical bugs or security flaws, they're backported. The port isn't > upgraded unless it has to be, and then if it's a major update, there > are plenty of eyeballs to review it. It's in /src, after all. > > But with ports, the ports tree only has the "latest" version or two; > sometimes a few major versions to choose from (eg apache), but we > don't maintain the same kind of package versions that Linux operating > system packages do. > > So it's entirely possible the "CVS" port maintainer updates the port > to the latest and greatest, which works for him - and it breaks > someone's older CVS repository somehow. > > I'd be happier with the idea of things moving into ports if the ports > tree did have stable snapshots which had incremental patches for > bug/security fixes, rather than "upgrade to whatever the port > maintainer chooses." > > I'm all for change, but it seems those pushing forward change seem to > be far exceeding the comfortable level of more conservative people; or > those with real needs. Those who have relied on FreeBSD's stable > release source tree being that - stable - whilst ports moves along > with the latest and greatest as needed. It doesn't matter that you may > do a fantastic job with a stable CVS port - what matters is how > people perceive what you're doing. It just takes one perceived screwup > here for the view to shift that "freebsd is going the way of linux". > And then we lose a whole lot of what public "good" opinion FreeBSD > has. ;-) I propose we create a companion directory to src in SVN and cal it "sysports" it uses the ports infrastructure in organization (though may be more hierarchical) but is populated with items that have come out of the 'src' tree. it is shipped along with src and revisioned WITH src. basically a privileged set of "primary" packages. both ports and src maintainers have access to them and they are tested as part of the release engineering process. > 2c, > > 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" > From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 20:25:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B642106566B for ; Sun, 4 Dec 2011 20:25:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AD4E18FC0C for ; Sun, 4 Dec 2011 20:25:31 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pB4KPJvs056102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Dec 2011 22:25:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pB4KPJBt099456; Sun, 4 Dec 2011 22:25:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pB4KPJwU099455; Sun, 4 Dec 2011 22:25:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Dec 2011 22:25:19 +0200 From: Kostik Belousov To: Yamagi Burmeister Message-ID: <20111204202519.GL50300@deviant.kiev.zoral.com.ua> References: <4C2E2BFD.1030204@elischer.org> <20100702184426.GW13238@deviant.kiev.zoral.com.ua> <20111204205427.f0989300.lists@yamagi.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ob1se4syEfB7Ey0C" Content-Disposition: inline In-Reply-To: <20111204205427.f0989300.lists@yamagi.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, julian@elischer.org Subject: Re: running old binaries on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 20:25:32 -0000 --Ob1se4syEfB7Ey0C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 04, 2011 at 08:54:27PM +0100, Yamagi Burmeister wrote: > On Fri, 2 Jul 2010 21:44:26 +0300 > Kostik Belousov wrote: >=20 > > On Fri, Jul 02, 2010 at 11:12:13AM -0700, Julian Elischer wrote: > > > every now and then, for fun I run up a chroot of freebsd 1.1. or 1.0= =20 > > > under a chroot. Usually hillarity ensues with teh 15 second kernel= =20 > > > compile and the 4 minute make world. > > >=20 > > > in -current I can't do that any more.. any binary just exits with 'Ab= ort'. > > >=20 > > > I think I last tried it in 7.0 or there abouts. > > >=20 > > > I have options COMPAT_AOUT and COMPAT_FREEBSD4 through COMPAT_FREEBSD7 > > >=20 > > > does anyone else have any ideas as to what may be needed? > > >=20 > > > I vaguely remember another option but I am not seeing it at the momen= t. > > >=20 > > > For those of you who do not remember, 1.0 had a.out static binaries o= nly. > > >=20 > >=20 > > Can you ktrace/kdump the run attempt, I suspect that abort is > > sent by image activator. > >=20 > > Also, please put some static binary somewhere to download. >=20 > Hi, > digging around I found one of the first programs ever written. It's an > static aout binary from 1994 or so, running it on FreeBSD 8.2 shows > exactly this problem. Some more extensive tests narrowed this problem > down to FreeBSD 1.x binaries, they're all broken. FreeBSD 2 aout > binaries are still working.=20 > Since Google found this rather old thread I decided to provide the data > your requested, but I do not insist on a fix. I guess that nobody will > try to run FreeBSD 1.x binaries these day... So if you want to spend > some work on this I'll test patches but if you decide to do nothing > it's okay. >=20 > This is the /bin/sh of FreeBSD 1.0 (taken from the official > installation cd image f?r i386): >=20 > % file sh > sh: VAX demand paged pure executable >=20 > % ./sh > Abort >=20 > The ktrace / kdump: > 1065 ktrace RET ktrace 0 > 1065 ktrace CALL execve(0xbfbfee1b,0xbfbfecf8,0xbfbfed00) > 1065 ktrace NAMI "./sh" >=20 > I've uploaded the binary to: > http://deponie.yamagi.org/freebsd/tmp/sh_freebsd1 Try to set sysctl security.bsd.map_at_zero to 1. --Ob1se4syEfB7Ey0C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7b1y8ACgkQC3+MBN1Mb4ilFACfZFf4LqqRqcI08qX8bGWNXtaD 3swAoK18yYuQh5Ut8gqJU+pYnPr6uhYZ =MNsE -----END PGP SIGNATURE----- --Ob1se4syEfB7Ey0C-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 20:30:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FB45106579C for ; Sun, 4 Dec 2011 20:30:20 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 5255B8FC13 for ; Sun, 4 Dec 2011 20:30:20 +0000 (UTC) Received: from maka.home.yamagi.org (g231182021.adsl.alicedsl.de [92.231.182.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 1A05B1666333; Sun, 4 Dec 2011 21:30:17 +0100 (CET) Date: Sun, 4 Dec 2011 21:30:04 +0100 From: Yamagi Burmeister To: kostikbel@gmail.com Message-Id: <20111204213004.c61d5542.lists@yamagi.org> In-Reply-To: <20111204202519.GL50300@deviant.kiev.zoral.com.ua> References: <4C2E2BFD.1030204@elischer.org> <20100702184426.GW13238@deviant.kiev.zoral.com.ua> <20111204205427.f0989300.lists@yamagi.org> <20111204202519.GL50300@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__4_Dec_2011_21_30_04_+0100_6VlsQiePbV/vGHMi" Cc: freebsd-current@freebsd.org, julian@elischer.org Subject: Re: running old binaries on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 20:30:20 -0000 --Signature=_Sun__4_Dec_2011_21_30_04_+0100_6VlsQiePbV/vGHMi Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 4 Dec 2011 22:25:19 +0200 Kostik Belousov wrote: > Try to set sysctl security.bsd.map_at_zero to 1. I didn't even think of that. It helped, thanks :) --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Sun__4_Dec_2011_21_30_04_+0100_6VlsQiePbV/vGHMi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7b2F0ACgkQWTjlg++8y8ufxwCbBiR/a+0gC2sKZtRx1b9mf2I8 3E4An13Em1FsETDoOPbKtVuFanx/n6u0 =A965 -----END PGP SIGNATURE----- --Signature=_Sun__4_Dec_2011_21_30_04_+0100_6VlsQiePbV/vGHMi-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 21:22:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7D497106566B; Sun, 4 Dec 2011 21:22:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id ED31914E573; Sun, 4 Dec 2011 21:22:43 +0000 (UTC) Message-ID: <4EDBE4A3.6010602@FreeBSD.org> Date: Sun, 04 Dec 2011 13:22:43 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Julian Elischer References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> In-Reply-To: <4EDBD5EF.9070207@freebsd.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Roman Kurakin , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 21:22:44 -0000 On 12/4/2011 12:19 PM, Julian Elischer wrote: > I propose we create a companion directory to src in SVN and cal it > "sysports" > it uses the ports infrastructure in organization (though may be more > hierarchical) > but is populated with items that have come out of the 'src' tree. > it is shipped along with src and revisioned WITH src. > > basically a privileged set of "primary" packages. > both ports and src maintainers have access to them and they > are tested as part of the release engineering process. Julian, You've proposed this before, and the more I've thought about it the more I like it. :) In fact, the other day a bunch of us in #bsdports were kicking it around and the idea was generally well received. (I think we slightly preferred the category "system," but that's an implementation detail.) My (personal) plan is to start pushing for this after the 9.0-RELEASE, and after the ports repo svn conversion. That's one of the reasons that I want to start socializing the idea now. In regards to having this new category be supported as part of the release process, we've already received tentative support from the release engineering team for the idea of having a small number of critical packages on the install medium and offered to the user as options at install time. So the seeds have been planted for this idea, and I'm hoping to see it grow in the coming months. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 22:11:42 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C85106566B; Sun, 4 Dec 2011 22:11:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 26EE88FC08; Sun, 4 Dec 2011 22:11:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00568; Mon, 05 Dec 2011 00:11:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXKHb-000I7o-E0; Mon, 05 Dec 2011 00:11:39 +0200 Message-ID: <4EDBF01B.8000802@FreeBSD.org> Date: Mon, 05 Dec 2011 00:11:39 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, John Baldwin Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 22:11:42 -0000 on 02/12/2011 17:30 mdf@FreeBSD.org said the following: > On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote: >> on 02/12/2011 06:36 John Baldwin said the following: >>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was >>> active). But I think these two changes should cover critical_exit() ok. >>> >> >> I attempted to start a discussion about this a few times already :-) >> Should we treat kdb context the same as SCHEDULER_STOPPED context (in the >> current definition) ? That is, skip all locks in the same fashion? >> There are pros and contras. > > Does kdb pause all CPUs with an interrupt (NMI or regular interrupt, I > can no longer remember...) when it enters? If so, then I'd say > whether it enters via sysctl or panic doesn't matter. It's in a > special environment where nothing else is running, which is what is > needed for proper exploration of the machine (via breakpoint, for > debugging a hang, etc). > > Maybe the question is, why wouldn't SCHEDULER_STOPPED be true > regardless of how kdb is entered? I think that the discussion that followed has clarified this point a bit. SCHEDULER_STOPPED perhaps needs a better name :-) Currently it, the name, reflects the state of the scheduler, but not why the scheduler is stopped and not the greater state of the system ("in panic"), nor how we should handle that state ("bypass locking"). So I'd love something like BYPASS_LOCKING_BECAUSE _SCHEDULER_IS_STOPPED_IN_PANIC haven't it be so unwieldy :) When the kdb_active is true the scheduler is stopped, true. But it is a different kind of system state from which we potentially may want to continue normal operation. So a lot more care is needed and simply bypassing locks is probably not a solution. I guess that some day in the distant future we might decide that a built-in debugger is for critical/abnormal situations only... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 22:16:00 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76A2F106572D; Sun, 4 Dec 2011 22:16:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 542588FC08; Sun, 4 Dec 2011 22:15:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00644; Mon, 05 Dec 2011 00:15:57 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXKLl-000I86-Cd; Mon, 05 Dec 2011 00:15:57 +0200 Message-ID: <4EDBF11D.6030401@FreeBSD.org> Date: Mon, 05 Dec 2011 00:15:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171638.03208.jhb@freebsd.org> <4EC6D544.5040803@FreeBSD.org> <201111211132.42119.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@FreeBSD.org, John Baldwin Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 22:16:00 -0000 on 21/11/2011 18:58 Attilio Rao said the following: > I would be very in favor about having a 'thread trampoline for KDB', > thus that it can use locks. I keep hearing the suggestion to add this trampoline, but I admit that I do not understand its technical meaning in this context. And also how it helps with the locking. So I will appreciate an explanation! Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 22:26:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E21E5106566B; Sun, 4 Dec 2011 22:26:07 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F86F8FC0C; Sun, 4 Dec 2011 22:26:07 +0000 (UTC) Received: by iafi7 with SMTP id i7so2881518iaf.13 for ; Sun, 04 Dec 2011 14:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=80xKIMyZJ3kRWBmU2AwgzgGZeMYH5i8N6E/EC1eR3QM=; b=dwGHkC8CBibf+wd4jF8DWZHOYz8gWTzcN0EOlk6rfIHgNur4la6p9418EpQsTGm7BO vQUkiUP5DoMbbHAQussqDW7WS4hWKJ9RPFUgP6pAKx3a7S5o0gY5d12ZyZhu3lAVbhw6 xYUa/ZaazDdfw2vjPVqbig1CEvqlhmC3cn4XM= MIME-Version: 1.0 Received: by 10.43.50.197 with SMTP id vf5mr7289186icb.38.1323037566891; Sun, 04 Dec 2011 14:26:06 -0800 (PST) Received: by 10.231.171.82 with HTTP; Sun, 4 Dec 2011 14:26:06 -0800 (PST) In-Reply-To: <4EDBE4A3.6010602@FreeBSD.org> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> Date: Sun, 4 Dec 2011 14:26:06 -0800 Message-ID: From: Kevin Oberman To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , Roman Kurakin , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 22:26:08 -0000 On Sun, Dec 4, 2011 at 1:22 PM, Doug Barton wrote: > On 12/4/2011 12:19 PM, Julian Elischer wrote: > >> I propose we create a companion directory to src in SVN and cal it >> "sysports" >> it uses the ports infrastructure in organization (though may be more >> hierarchical) >> but is populated with items that have come out of the 'src' tree. >> it is shipped along with src and revisioned WITH src. >> >> basically a privileged set of "primary" packages. >> both ports and src maintainers have access to them and they >> are tested as part of the release engineering process. > > Julian, > > You've proposed this before, and the more I've thought about it the more > I like it. :) =A0In fact, the other day a bunch of us in #bsdports were > kicking it around and the idea was generally well received. (I think we > slightly preferred the category "system," but that's an implementation > detail.) > > My (personal) plan is to start pushing for this after the 9.0-RELEASE, > and after the ports repo svn conversion. That's one of the reasons that > I want to start socializing the idea now. > > In regards to having this new category be supported as part of the > release process, we've already received tentative support from the > release engineering team for the idea of having a small number of > critical packages on the install medium and offered to the user as > options at install time. So the seeds have been planted for this idea, > and I'm hoping to see it grow in the coming months. > > > Doug This seems too reasonable a suggestion, but, as always, the devil is in the details. There will be long. painful discussions (and arguments) about what to remove from the base to the new structure and what things currently NOT in the base should be promoted. As to what to name the new area, I vote for burnt orange with blue trim. Go Broncos! (American football for those out of the Estados Unidos.) --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 22:32:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC5E1065673; Sun, 4 Dec 2011 22:32:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 04FAD8FC16; Sun, 4 Dec 2011 22:31:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00821; Mon, 05 Dec 2011 00:31:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXKbF-000I8R-SP; Mon, 05 Dec 2011 00:31:57 +0200 Message-ID: <4EDBF4DD.3030001@FreeBSD.org> Date: Mon, 05 Dec 2011 00:31:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Konstantin Belousov , John Baldwin Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 22:32:01 -0000 on 02/12/2011 19:18 Attilio Rao said the following: > BTW, I'm waiting for the details to settle (including the patch we > have been discussing internally about binding to CPU0 during ACPI > shutdown) I do not see strong interdependency between that patch and the panic patch. BTW, I think that your patch is good to go. > before to read the whole thread and start a proper review, > would it be possible to have an almost-final version of the patch? It is still the same patch that Kostik posted a few weeks ago. I think that it is long overdue to be committed. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 23:05:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17B92106566C for ; Sun, 4 Dec 2011 23:05:50 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 985608FC0A for ; Sun, 4 Dec 2011 23:05:49 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D530525D3A00; Sun, 4 Dec 2011 23:05:47 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 97BE3BD64EA; Sun, 4 Dec 2011 23:05:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id pRsJWnK11AKA; Sun, 4 Dec 2011 23:05:45 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C9702BD64E9; Sun, 4 Dec 2011 23:05:44 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Sun, 4 Dec 2011 23:05:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <730334BA-BC68-40CB-8BF2-4517B066ADE7@lists.zabbadoz.net> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDB8BB5.50607@borderworlds.dk> <4EDBB56B.9020308@inse.ru> To: C. P. Ghost X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Current mailing list Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 23:05:50 -0000 On 4. Dec 2011, at 18:07 , C. P. Ghost wrote: > On Sun, Dec 4, 2011 at 7:01 PM, Roman Kurakin wrote: >> Christian Laursen wrote: >>>=20 >>> [...] >>>=20 >>> I use CVS myself from time to time, but I see no need for it to be = in base >>> for that reason. >>=20 >> By the way, since there is no way to count +/- I guess the rule "do = not >> brake that is working >> or provide a way to do the same" should work. If there is a number of = users >> of smth it should >> not be broken. csup/cvsup does not provide the same. >=20 > Actually, a whole lot of stuff that was still perfectly useable has > been deprecated over the years. I'm thinking of net/freebsd-uucp > for example. Which is a good example as - to my memory - it needs cvs to build. = Moving our CVS (and yes the base CVS has quite some modifications still I = think) into ports would probably mean taking the CVS history and run into a chicken and egg problem;-) We'll need "our" CVS probably for another 2-3 years I think as some = non-significant infrastructure will still depend on it even after docs and ports moved = away from it. Some others have suggested things like "lpd" however which could = probably go to ports as well as it's anther conflict these days for most people = using cups or similar anyway. I can think of more but we shouldn't be overly eager either or we'll end up with a README in src/ saying "please install the following ports;-)" /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!= From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 23:36:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF6531065673 for ; Sun, 4 Dec 2011 23:36:54 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8B08FC0A for ; Sun, 4 Dec 2011 23:36:54 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RXLc5-000PQt-FG; Sun, 04 Dec 2011 23:36:53 +0000 Date: Mon, 05 Dec 2011 08:36:51 +0900 Message-ID: From: Randy Bush To: Kevin Oberman In-Reply-To: References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 23:36:54 -0000 > This seems too reasonable a suggestion, but, as always, the devil > is in the details. There will be long. painful discussions (and > arguments) about what to remove from the base to the new structure > and what things currently NOT in the base should be promoted. as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is tempting. but, as you hint, is this not just doubling the number of borders over which we can argue? but let's get concrete here. i suspect that my install pattern is similar to others o custom install so i can split filesystems the way i prefer, enabling net & ssh o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer if it does not have emacs) o hack /etc/ssh/sshd_conf to allow root with password o rsync over ~root o hack /etc/ssh/sshd_conf to allow root only without-password o rsync over my standard /etc/foo (incl make.conf and src.conf) and other gunk o csup releng_X kernel, world, doc, ports o build and install kernel and world and then do whatever is special for this particular system. anything which would lessen/simplify the above would be much appreciated. anything not totally obiously wonderful which would increase/complicate the above would not be appreciated. randy From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 00:41:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74E2B1065670 for ; Mon, 5 Dec 2011 00:41:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE4F8FC0C for ; Mon, 5 Dec 2011 00:41:53 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pB50foic092195 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 4 Dec 2011 16:41:51 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EDC135C.5000400@freebsd.org> Date: Sun, 04 Dec 2011 16:42:04 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Randy Bush References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 00:41:53 -0000 On 12/4/11 3:36 PM, Randy Bush wrote: >> This seems too reasonable a suggestion, but, as always, the devil >> is in the details. There will be long. painful discussions (and >> arguments) about what to remove from the base to the new structure >> and what things currently NOT in the base should be promoted. > as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is > tempting. but, as you hint, is this not just doubling the number of > borders over which we can argue? > > but let's get concrete here. > > i suspect that my install pattern is similar to others > o custom install so i can split filesystems the way i prefer, > enabling net& ssh > o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer > if it does not have emacs) > o hack /etc/ssh/sshd_conf to allow root with password > o rsync over ~root > o hack /etc/ssh/sshd_conf to allow root only without-password > o rsync over my standard /etc/foo (incl make.conf and src.conf) > and other gunk > o csup releng_X kernel, world, doc, ports > o build and install kernel and world > > and then do whatever is special for this particular system. > > anything which would lessen/simplify the above would be much > appreciated. anything not totally obiously wonderful which would > increase/complicate the above would not be appreciated. my suggestion is that the 'sysports' or 'foundation ports' or 'basic ports', (or whatever you want to call them) in their package form come with the standard install in fact I'd suggest that they get installed into some directory by default so that 'enabling' them ata later time doesn't even have to fetch them to do the pkg_add. They have pre-installed entries in /etc/defaults/rc.conf. and only their rc,d files need to beinstalled into /etc along with their program files. They are as close to being as they are now with the exception of being installed in the final step instead of at the same time as the rest of the stuff, and it allows them to easily be 'deinstalled' and replaced by newer versions. Some of them would come from the current system sources and some of them would be what are currently 'normal' ports but we consider them to be 'basic' and 'extra supported' Examples of the first type would be bind, sendmail, cvs, and examples of the second type would be perl, bash, maybe python, and possibly a very minimal set of the X11 packages. These are things we talk about having extra support for in the installer anyhow. I also suggest that said packages include a "plugin" for sysinstall/bsdinstall. so that it can ask its own quesitons during install. > randy > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 01:25:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D336106566B for ; Mon, 5 Dec 2011 01:25:02 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id E90908FC0A for ; Mon, 5 Dec 2011 01:25:01 +0000 (UTC) Received: (qmail 20616 invoked by uid 89); 5 Dec 2011 01:12:03 -0000 Received: by simscan 1.4.0 ppid: 20611, pid: 20613, t: 0.0494s scanners: attach: 1.4.0 clamav: 0.97.1/m:54/d:14072 Received: from unknown (HELO ?192.168.1.201?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 5 Dec 2011 01:12:03 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Rainer Duffner In-Reply-To: Date: Mon, 5 Dec 2011 02:12:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99EFA66E-75A6-4E13-BDD0-9A65F0042DAA@ultra-secure.de> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> To: freebsd-current X-Mailer: Apple Mail (2.1251.1) Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 01:25:02 -0000 Am 05.12.2011 um 00:36 schrieb Randy Bush: >> This seems too reasonable a suggestion, but, as always, the devil >> is in the details. There will be long. painful discussions (and >> arguments) about what to remove from the base to the new structure >> and what things currently NOT in the base should be promoted. >=20 > as one with a long list of WITHOUT_foo=3DYES in /etc/src.conf, this is > tempting. but, as you hint, is this not just doubling the number of > borders over which we can argue? >=20 > but let's get concrete here. >=20 > i suspect that my install pattern is similar to others [....] > and then do whatever is special for this particular system. >=20 > anything which would lessen/simplify the above would be much > appreciated. anything not totally obiously wonderful which would > increase/complicate the above would not be appreciated. Most of that stuff should be solved by a configuration-management system = - or (partly) by an automated installation. BTW: Does anybody have a link to some documentation how that = (PXE-install etc.) is supposed to be done in 9.0? Personally, I don't think cvs should be removed any time soon: - it's AFAIK stable, doesn't change a lot - doesn't introduce vulnerabilities every other month - will be needed for some time for historic reasons BIND OTOH is something different. But even on the couple of servers we = actually use BIND, we like to have a version that is supported over the = lifetime of the FreeBSD system it's installed on. As has been said, FreeBSD (as of 8.2 - haven't had the chance to look = into 9.0 a lot) is a nice system with a lot of functionality without = installing lot's of packages. Just FYI: we use rubygem-chef for configuration-management, but we don't = think it would be a good idea to have ruby in the base-system, even = though we need it on every system anyway... From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 02:00:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BE33106566B for ; Mon, 5 Dec 2011 02:00:16 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3874C8FC13 for ; Mon, 5 Dec 2011 02:00:16 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RXNqp-00009p-Bt; Mon, 05 Dec 2011 02:00:15 +0000 Date: Mon, 05 Dec 2011 11:00:15 +0900 Message-ID: From: Randy Bush To: Rainer Duffner In-Reply-To: <99EFA66E-75A6-4E13-BDD0-9A65F0042DAA@ultra-secure.de> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <99EFA66E-75A6-4E13-BDD0-9A65F0042DAA@ultra-secure.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 02:00:18 -0000 > BIND OTOH is something different. what's bind? :) randy From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 02:21:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D9361065676; Mon, 5 Dec 2011 02:21:37 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 26D788FC0A; Mon, 5 Dec 2011 02:21:36 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C9B64B852; Sun, 4 Dec 2011 18:04:44 -0800 (PST) To: Julian Elischer In-reply-to: Your message of "Sun, 04 Dec 2011 16:42:04 PST." <4EDC135C.5000400@freebsd.org> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <4EDC135C.5000400@freebsd.org> Comments: In-reply-to Julian Elischer message dated "Sun, 04 Dec 2011 16:42:04 -0800." Date: Sun, 04 Dec 2011 18:04:44 -0800 From: Bakul Shah Message-Id: <20111205020444.C9B64B852@mail.bitblocks.com> Cc: Randy Bush , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 02:21:37 -0000 On Sun, 04 Dec 2011 16:42:04 PST Julian Elischer wrote: > On 12/4/11 3:36 PM, Randy Bush wrote: > > > > i suspect that my install pattern is similar to others > > o custom install so i can split filesystems the way i prefer, > > enabling net& ssh > > o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer > > if it does not have emacs) > > o hack /etc/ssh/sshd_conf to allow root with password > > o rsync over ~root > > o hack /etc/ssh/sshd_conf to allow root only without-password > > o rsync over my standard /etc/foo (incl make.conf and src.conf) > > and other gunk > > o csup releng_X kernel, world, doc, ports > > o build and install kernel and world > > > > and then do whatever is special for this particular system. > > > > anything which would lessen/simplify the above would be much > > appreciated. anything not totally obiously wonderful which would > > increase/complicate the above would not be appreciated. > > my suggestion is that the 'sysports' or 'foundation ports' or > 'basic ports', (or whatever you want to call them) in their package > form come with the standard install in fact I'd suggest that they > get installed into some directory by default so that 'enabling' them > ata later time doesn't even have to fetch them to do the pkg_add. > > They have pre-installed entries in /etc/defaults/rc.conf. and only > their rc,d > files need to beinstalled into /etc along with their program files. > They are as close to being as they are now with the exception of > being installed in the final step instead of at the same time as the > rest of the stuff, > and it allows them to easily be 'deinstalled' and replaced by newer > versions. > > Some of them would come from the current system sources and some of > them would be > what are currently 'normal' ports but we consider them to be 'basic' > and 'extra supported' > > Examples of the first type would be bind, sendmail, cvs, and examples > of the second type would be perl, bash, maybe python, and possibly a > very minimal set of the > X11 packages. > > These are things we talk about having extra support for in the > installer anyhow. > I also suggest that said packages include a "plugin" for > sysinstall/bsdinstall. so that it can ask its own > quesitons during install. A while back I had toyed with a config based approach. The idea is you install a minimal system and then use one of the predefined system configs to bring the system upto a desired state. The same config will use your local script of the same name if one exists, to allow for local modifications. The same config (or an updated version) can be rerun after an update. Basically the idea is that you are dealing with a system as a _whole_ for the purpose of install/update/convert/replicate. You are capturing the "personality" or "metadata" of a system a single file (it in turn relies on a small set of small text files). This can be used for other purposes as well. A config is essentially names of packages to install, variable names, names of any pre/post external scripts to run, and other included configs. But no executable logic here! If this is used, a new release would also contain a repo for every predefined script -- this makes it easy to see what changed and deal with it. Benefits: - people can consistently customize their setup and keep it so after an upgrade - what is included in the "base system" becomes largely irrelevant - you can check/fix system personality at any time - you can generate a local config easily - can exactly replicate the same config on multiple machines - can systematically change the personality of your system - you can integrate this in sysinstall (and provide more flexibility) - you can define your own specialized configs for whatever purpose. To give you an idea: syscfg install # install foo on a new installation syscfg set # change existing (unconfigured) system to foo syscfg convert # change existing (configured) system to bar syscfg diff # compare local system against foo syscfg [-f] check # check and optionally fix syscfg update You would need to tell it where to get its data (either a released ISO or a site). Lot of details would have to be worked out. Unfortunately I don't get to use FreeBSD much these days @ work and my home setup doesn't change much. From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 04:12:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98F35106566C for ; Mon, 5 Dec 2011 04:12:13 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from sout.laposte.net (sout2.laposte.net [193.253.67.236]) by mx1.freebsd.org (Postfix) with ESMTP id 316B38FC18 for ; Mon, 5 Dec 2011 04:12:12 +0000 (UTC) Received: from [192.168.0.133] ([84.99.64.107]) by mwinf8506-out with ME id 5Fi61i0042JqUHQ03Fi7es; Mon, 05 Dec 2011 04:42:08 +0100 Message-ID: <4EDC3DEC.6000206@laposte.net> Date: Mon, 05 Dec 2011 04:43:40 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Randy Bush References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <99EFA66E-75A6-4E13-BDD0-9A65F0042DAA@ultra-secure.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , Rainer Duffner Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 04:12:13 -0000 Le 05/12/2011 03:00, Randy Bush a =E9crit : >> BIND OTOH is something different. > > what's bind? :) http://www.isc.org/software/bind Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 04:16:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CCBA106566C for ; Mon, 5 Dec 2011 04:16:14 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 56C7B8FC0A for ; Mon, 5 Dec 2011 04:16:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RXPyO-0000NX-Ek; Mon, 05 Dec 2011 04:16:13 +0000 Date: Mon, 05 Dec 2011 13:16:11 +0900 Message-ID: From: Randy Bush To: Cyrille Lefevre In-Reply-To: <4EDC3DEC.6000206@laposte.net> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <99EFA66E-75A6-4E13-BDD0-9A65F0042DAA@ultra-secure.de> <4EDC3DEC.6000206@laposte.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 04:16:14 -0000 >>> BIND OTOH is something different. >> what's bind? :) > http://www.isc.org/software/bind see the smily? bind is not in my install set. if i need an on-system cache, i use unbound. randy From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 05:44:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C211065708; Mon, 5 Dec 2011 05:44:14 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3BC4A8FC0C; Mon, 5 Dec 2011 05:44:07 +0000 (UTC) Received: from [10.0.0.52] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pB55LcX6052250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Dec 2011 00:21:38 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Mon, 05 Dec 2011 00:21:38 -0500 (EST) References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <4EDC135C.5000400@freebsd.org> In-Reply-To: <4EDC135C.5000400@freebsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <029322CC-FFF0-4DE2-8ABE-2AF2F2345906@vigrid.com> X-Mailer: iPhone Mail (9A405) From: Daniel Eischen Date: Mon, 5 Dec 2011 00:21:37 -0500 To: Julian Elischer Cc: Randy Bush , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 05:44:14 -0000 On Dec 4, 2011, at 7:42 PM, Julian Elischer wrote: > On 12/4/11 3:36 PM, Randy Bush wrote: >>> This seems too reasonable a suggestion, but, as always, the devil >>> is in the details. There will be long. painful discussions (and >>> arguments) about what to remove from the base to the new structure >>> and what things currently NOT in the base should be promoted. >> as one with a long list of WITHOUT_foo=3DYES in /etc/src.conf, this is >> tempting. but, as you hint, is this not just doubling the number of >> borders over which we can argue? >>=20 >> but let's get concrete here. >>=20 >> i suspect that my install pattern is similar to others >> o custom install so i can split filesystems the way i prefer, >> enabling net& ssh >> o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer >> if it does not have emacs) >> o hack /etc/ssh/sshd_conf to allow root with password >> o rsync over ~root >> o hack /etc/ssh/sshd_conf to allow root only without-password >> o rsync over my standard /etc/foo (incl make.conf and src.conf) >> and other gunk >> o csup releng_X kernel, world, doc, ports >> o build and install kernel and world >>=20 >> and then do whatever is special for this particular system. >>=20 >> anything which would lessen/simplify the above would be much >> appreciated. anything not totally obiously wonderful which would >> increase/complicate the above would not be appreciated. >=20 > my suggestion is that the 'sysports' or 'foundation ports' or > 'basic ports', (or whatever you want to call them) in their package > form come with the standard install in fact I'd suggest that they > get installed into some directory by default so that 'enabling' them > ata later time doesn't even have to fetch them to do the pkg_add. >=20 > They have pre-installed entries in /etc/defaults/rc.conf. and only their r= c,d > files need to beinstalled into /etc along with their program files. > They are as close to being as they are now with the exception of > being installed in the final step instead of at the same time as the rest o= f the stuff, > and it allows them to easily be 'deinstalled' and replaced by newer versio= ns. I really don't understand how this is much different than having them exist i= n base. We have WITHOU_foo (I don't really care if that were to become WITH= _foo if we want to default to a more minimum system), so one can always use p= orts if they want some different version of foo. And it's not just releases= we care about, we want a stable foo (BIND for example) with security and bu= g fixes throughout all updates to -stable, not just at releases. I want to do one buildworld and have a complete and integrated system. I do= n't see how having a separate repo for sysports helps; it is yet another thi= ng I have to track. And are ports in sysports going to default to being ins= talled in / or /usr/local? -- DE= From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 08:29:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68921106566B for ; Mon, 5 Dec 2011 08:29:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED7B8FC13 for ; Mon, 5 Dec 2011 08:29:56 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pB58Tqxe093386 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 00:29:54 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EDC810F.8060902@freebsd.org> Date: Mon, 05 Dec 2011 00:30:07 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Daniel Eischen References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <4EDC135C.5000400@freebsd.org> <029322CC-FFF0-4DE2-8ABE-2AF2F2345906@vigrid.com> In-Reply-To: <029322CC-FFF0-4DE2-8ABE-2AF2F2345906@vigrid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randy Bush , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 08:29:56 -0000 On 12/4/11 9:21 PM, Daniel Eischen wrote: > On Dec 4, 2011, at 7:42 PM, Julian Elischer wrote: > >> On 12/4/11 3:36 PM, Randy Bush wrote: >>>> This seems too reasonable a suggestion, but, as always, the devil >>>> is in the details. There will be long. painful discussions (and >>>> arguments) about what to remove from the base to the new structure >>>> and what things currently NOT in the base should be promoted. >>> as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is >>> tempting. but, as you hint, is this not just doubling the number of >>> borders over which we can argue? >>> >>> but let's get concrete here. >>> >>> i suspect that my install pattern is similar to others >>> o custom install so i can split filesystems the way i prefer, >>> enabling net& ssh >>> o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer >>> if it does not have emacs) >>> o hack /etc/ssh/sshd_conf to allow root with password >>> o rsync over ~root >>> o hack /etc/ssh/sshd_conf to allow root only without-password >>> o rsync over my standard /etc/foo (incl make.conf and src.conf) >>> and other gunk >>> o csup releng_X kernel, world, doc, ports >>> o build and install kernel and world >>> >>> and then do whatever is special for this particular system. >>> >>> anything which would lessen/simplify the above would be much >>> appreciated. anything not totally obiously wonderful which would >>> increase/complicate the above would not be appreciated. >> my suggestion is that the 'sysports' or 'foundation ports' or >> 'basic ports', (or whatever you want to call them) in their package >> form come with the standard install in fact I'd suggest that they >> get installed into some directory by default so that 'enabling' them >> ata later time doesn't even have to fetch them to do the pkg_add. >> >> They have pre-installed entries in /etc/defaults/rc.conf. and only their rc,d >> files need to beinstalled into /etc along with their program files. >> They are as close to being as they are now with the exception of >> being installed in the final step instead of at the same time as the rest of the stuff, >> and it allows them to easily be 'deinstalled' and replaced by newer versions. > I really don't understand how this is much different than having them exist in base. We have WITHOU_foo (I don't really care if that were to become WITH_foo if we want to default to a more minimum system), so one can always use ports if they want some different version of foo. And it's not just releases we care about, we want a stable foo (BIND for example) with security and bug fixes throughout all updates to -stable, not just at releases. > > I want to do one buildworld and have a complete and integrated system. I don't see how having a separate repo for sysports helps; it is yet another thing I have to track. And are ports in sysports going to default to being installed in / or /usr/local? I think there are several differences.. 1/ The ability to UNINSTALL it and replace it completely with a differnet version 2/ allow easy leave-out feature.. leaving it out is less risky.. 3/ probably the most important.. allowing both ports and src developers to work on the packages. 4/ allowing us to promote some of the commonly used packages to a more supported level without actually bringing them into the base system. > -- > DE > From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 08:48:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF39D106566B; Mon, 5 Dec 2011 08:48:30 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2488FC15; Mon, 5 Dec 2011 08:48:30 +0000 (UTC) Received: from happy.home.yamagi.org (unknown [IPv6:2001:5c0:150f:8700:16da:e9ff:fe0f:8071]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id CED3F1666333; Mon, 5 Dec 2011 09:48:27 +0100 (CET) Date: Mon, 5 Dec 2011 09:48:20 +0100 From: Yamagi Burmeister To: julian@freebsd.org Message-Id: <20111205094820.d5851c8c.lists@yamagi.org> In-Reply-To: <4EDBEC7B.1070403@freebsd.org> References: <4C2E2BFD.1030204@elischer.org> <20100702184426.GW13238@deviant.kiev.zoral.com.ua> <20111204205427.f0989300.lists@yamagi.org> <20111204202519.GL50300@deviant.kiev.zoral.com.ua> <20111204213004.c61d5542.lists@yamagi.org> <4EDBEC7B.1070403@freebsd.org> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__5_Dec_2011_09_48_20_+0100_i=EuVfQGlNMUKHC3" Cc: freebsd-current@freebsd.org, julian@elischer.org Subject: Re: [maybe spam] Re: running old binaries on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 08:48:31 -0000 --Signature=_Mon__5_Dec_2011_09_48_20_+0100_i=EuVfQGlNMUKHC3 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 04 Dec 2011 13:56:11 -0800 Julian Elischer wrote: > On 12/4/11 12:30 PM, Yamagi Burmeister wrote: > > On Sun, 4 Dec 2011 22:25:19 +0200 > > Kostik Belousov wrote: > > > >> Try to set sysctl security.bsd.map_at_zero to 1. > > I didn't even think of that. It helped, thanks :) > > > do you have a full 1.0 iso image somewhere? (or a copy of hte release?) > I had a 1.1 cd but I can not find it now. For some time now iso images of those acient releases and even some development snapshots can be found in the ftp archiv: ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/ISO-IMA= GES My iso images were taken direcly from cds found in the library of the department for computer science at the local university. The file size is the same as of those in the ftp archive. --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Mon__5_Dec_2011_09_48_20_+0100_i=EuVfQGlNMUKHC3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7chVoACgkQWTjlg++8y8s4rQCfQdoP1U8mRGSB4qhH4l2UoX4s ncsAoL2NLrQfVFOQHCWdkZrlOMsS01Gj =Azk6 -----END PGP SIGNATURE----- --Signature=_Mon__5_Dec_2011_09_48_20_+0100_i=EuVfQGlNMUKHC3-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 12:57:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B9B1106566B; Mon, 5 Dec 2011 12:57:16 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 894378FC0A; Mon, 5 Dec 2011 12:57:15 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 07EAC0; Mon, 5 Dec 2011 13:57:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 05 Dec 2011 13:57:15 +0100 From: Bernhard Froehlich To: Bernhard Froehlich In-Reply-To: <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> <4ED6AEFE.4010106@FreeBSD.org> <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> Message-ID: <7c3c9505867f4528af276a571077b9ce@bluelife.at> X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B020D.4EDCBFAA.015B,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Gleb Kurtsou , Alan Cox , Gapon , freebsd-emulation@freebsd.org, FreeBSD current , Andriy, Jung-uk Kim Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 12:57:16 -0000 On 02.12.2011 12:55, Bernhard Froehlich wrote: > On 01.12.2011 09:37, Bernhard Froehlich wrote: >> On 01.12.2011 00:07, Jung-uk Kim wrote: >>> On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: >>>> on 26/11/2011 18:33 Gleb Kurtsou said the following: >>>> > Using new vm_page_alloc_contig() may be a better option here. >>>> > Can't help with patch, stuck with pre Nov 15 CURRENT myself. >>>> >>>> on 27/11/2011 19:09 Alan Cox said the following: >>>> > vm_page_alloc_contig() should be used instead. >>>> >>>> My take on the patch: >>>> http://people.freebsd.org/~avg/vbox-10.patch >>>> This is for head only, no check for FreeBSD version. >>> >>> Actually, I did the same thing last night: >>> >>> >>> http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c >>> >>> This is a drop-in replacement for the patch. The only practical >>> difference I see from yours is I used VM_ALLOC_INTERRUPT instead of >>> VM_ALLOC_NORMAL. I believe this function may be used in interrupt >>> context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. >> >> Thanks a lot for both patches! Could you please as usual reply and >> tell >> me if it is okay to send this patch upstream under MIT license? >> >> Once there is some positive feedback I will commit both patches to >> the ports tree. > > Patch has been send upstream: > > > https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html Patches have been committed upstream. Thanks a lot guys! https://www.virtualbox.org/changeset/39521 -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 13:06:20 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE17106566B; Mon, 5 Dec 2011 13:06:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C7ACA8FC1C; Mon, 5 Dec 2011 13:06:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA12453; Mon, 05 Dec 2011 15:06:16 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXYFM-000Kyh-L7; Mon, 05 Dec 2011 15:06:16 +0200 Message-ID: <4EDCC1C6.3040109@FreeBSD.org> Date: Mon, 05 Dec 2011 15:06:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Bernhard Froehlich References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> <4ED6AEFE.4010106@FreeBSD.org> <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> In-Reply-To: <7c3c9505867f4528af276a571077b9ce@bluelife.at> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current , Gleb Kurtsou , Jung-uk Kim Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 13:06:20 -0000 on 05/12/2011 14:57 Bernhard Froehlich said the following: > On 02.12.2011 12:55, Bernhard Froehlich wrote: >> Patch has been send upstream: >> >> >> https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html > > Patches have been committed upstream. Thanks a lot guys! > > https://www.virtualbox.org/changeset/39521 > BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that we pass to vm_phys_alloc_contig. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 13:12:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5816C106566C for ; Mon, 5 Dec 2011 13:12:00 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id CA57E8FC14 for ; Mon, 5 Dec 2011 13:11:59 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so6217160vcb.13 for ; Mon, 05 Dec 2011 05:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=az3HYZNA1952hlnZzkgYW6YgPVi3Ko5ItESXCIxk2NA=; b=nOIcsa0bWmG9/PI4ENKWqYdHtiMW15j+7gQbbO26ZspZmf+s34bMZ55S7DSylFN8yX Z5/CD2r2zab1G4smOaI6VYABkNCKndnKuabEegakoJnphs8Iu6hzVe3xb8b/FpjOKFDS WEv5B6GElHuNJQ3yqN1z9CJnOjdZ1ZPhTmzLQ= MIME-Version: 1.0 Received: by 10.52.186.225 with SMTP id fn1mr4484345vdc.32.1323089344666; Mon, 05 Dec 2011 04:49:04 -0800 (PST) Received: by 10.52.172.240 with HTTP; Mon, 5 Dec 2011 04:49:04 -0800 (PST) In-Reply-To: References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> Date: Mon, 5 Dec 2011 12:49:04 +0000 Message-ID: From: Tom Evans To: Max Khon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, sthaug@nethelp.no Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 13:12:00 -0000 On Sat, Dec 3, 2011 at 3:24 PM, Max Khon wrote: > CVS != csup. > > I wonder how many people will express their sentiments about CVS when > they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. In my mind, a first step would be to move ports to subversion, initially using svn->cvs bridge. Once done, the next step would be to change all infrastructure scripts so that they can build from/be driven by subversion. After that, nothing in base would use cvs for any purpose, and at that point I would be happy for it to be dropped from base - but only if it was replaced by subversion. I think it is important that with a base install of FreeBSD you can check out and update the source and rebuild itself. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 13:15:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9CB7106566B; Mon, 5 Dec 2011 13:15:01 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2D55E8FC08; Mon, 5 Dec 2011 13:15:01 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 3D2457; Mon, 5 Dec 2011 14:15:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 05 Dec 2011 14:15:00 +0100 From: Bernhard Froehlich To: Andriy Gapon In-Reply-To: <4EDCC1C6.3040109@FreeBSD.org> References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> Message-ID: X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B020D.4EDCC3D4.0062,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Gleb Kurtsou , Alan Cox , Jung-uk, freebsd-emulation@freebsd.org, FreeBSD current , Bernhard Froehlich , Kim Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 13:15:01 -0000 On 05.12.2011 14:06, Andriy Gapon wrote: > on 05/12/2011 14:57 Bernhard Froehlich said the following: >> On 02.12.2011 12:55, Bernhard Froehlich wrote: >>> Patch has been send upstream: >>> >>> >>> >>> https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html >> >> Patches have been committed upstream. Thanks a lot guys! >> >> https://www.virtualbox.org/changeset/39521 >> > > BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that > we pass to vm_phys_alloc_contig. What's the difference of this? BTW you reported about the GCC 4.5 header stuff and it was also already fixed: http://lists.freebsd.org/pipermail/freebsd-emulation/2011-December/009312.html -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 13:36:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 946891065679 for ; Mon, 5 Dec 2011 13:36:40 +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 601858FC08 for ; Mon, 5 Dec 2011 13:36:40 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pB5Dadho056033; Mon, 5 Dec 2011 08:36:39 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Mon, 05 Dec 2011 08:36:39 -0500 (EST) Date: Mon, 5 Dec 2011 08:36:39 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <4EDC810F.8060902@freebsd.org> Message-ID: References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <4EDC135C.5000400@freebsd.org> <029322CC-FFF0-4DE2-8ABE-2AF2F2345906@vigrid.com> <4EDC810F.8060902@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 13:36:40 -0000 On Mon, 5 Dec 2011, Julian Elischer wrote: > On 12/4/11 9:21 PM, Daniel Eischen wrote: >> On Dec 4, 2011, at 7:42 PM, Julian Elischer wrote: >> >>> On 12/4/11 3:36 PM, Randy Bush wrote: >>>>> This seems too reasonable a suggestion, but, as always, the devil >>>>> is in the details. There will be long. painful discussions (and >>>>> arguments) about what to remove from the base to the new structure >>>>> and what things currently NOT in the base should be promoted. >>>> as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is >>>> tempting. but, as you hint, is this not just doubling the number of >>>> borders over which we can argue? >>>> >>>> but let's get concrete here. >>>> >>>> i suspect that my install pattern is similar to others >>>> o custom install so i can split filesystems the way i prefer, >>>> enabling net& ssh >>>> o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer >>>> if it does not have emacs) >>>> o hack /etc/ssh/sshd_conf to allow root with password >>>> o rsync over ~root >>>> o hack /etc/ssh/sshd_conf to allow root only without-password >>>> o rsync over my standard /etc/foo (incl make.conf and src.conf) >>>> and other gunk >>>> o csup releng_X kernel, world, doc, ports >>>> o build and install kernel and world >>>> >>>> and then do whatever is special for this particular system. >>>> >>>> anything which would lessen/simplify the above would be much >>>> appreciated. anything not totally obiously wonderful which would >>>> increase/complicate the above would not be appreciated. >>> my suggestion is that the 'sysports' or 'foundation ports' or >>> 'basic ports', (or whatever you want to call them) in their package >>> form come with the standard install in fact I'd suggest that they >>> get installed into some directory by default so that 'enabling' them >>> ata later time doesn't even have to fetch them to do the pkg_add. >>> >>> They have pre-installed entries in /etc/defaults/rc.conf. and only their >>> rc,d >>> files need to beinstalled into /etc along with their program files. >>> They are as close to being as they are now with the exception of >>> being installed in the final step instead of at the same time as the rest >>> of the stuff, >>> and it allows them to easily be 'deinstalled' and replaced by newer >>> versions. >> I really don't understand how this is much different than having them exist >> in base. We have WITHOU_foo (I don't really care if that were to become >> WITH_foo if we want to default to a more minimum system), so one can always >> use ports if they want some different version of foo. And it's not just >> releases we care about, we want a stable foo (BIND for example) with >> security and bug fixes throughout all updates to -stable, not just at >> releases. >> >> I want to do one buildworld and have a complete and integrated system. I >> don't see how having a separate repo for sysports helps; it is yet another >> thing I have to track. And are ports in sysports going to default to being >> installed in / or /usr/local? > > I think there are several differences.. > 1/ The ability to UNINSTALL it and replace it completely with a differnet > version If we go to a complete pkg-based system, then there is no difference here, so why not do that? > 2/ allow easy leave-out feature.. leaving it out is less risky.. WITH_FOO/WITHOUT_FOO vs pkg_delete, not sure there is much of a difference. The advantage of WITH/WITHOUT is that the system is built as a whole and integrated. src/ developers are suppose to not break src/; they may not be so inclined to worry about sysports. Will emphasis be put on src/ developers to include sysports in their "buildworld" and will tinderboxes also include sysports? > 3/ probably the most important.. allowing both ports and src developers to > work on the packages. Give ports maintainers that maintain BIND, FOO, access to src/ (which they probably have already). > 4/ allowing us to promote some of the commonly used packages to a more > supported level without actually bringing them into the base system. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 13:56:53 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF509106566C; Mon, 5 Dec 2011 13:56:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 657678FC12; Mon, 5 Dec 2011 13:56:52 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13124; Mon, 05 Dec 2011 15:56:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDCCDA2.5070006@FreeBSD.org> Date: Mon, 05 Dec 2011 15:56:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Bernhard Froehlich References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current , Gleb Kurtsou , Jung-uk Kim Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 13:56:54 -0000 on 05/12/2011 15:15 Bernhard Froehlich said the following: > On 05.12.2011 14:06, Andriy Gapon wrote: >> on 05/12/2011 14:57 Bernhard Froehlich said the following: >>> On 02.12.2011 12:55, Bernhard Froehlich wrote: >>>> Patch has been send upstream: >>>> >>>> >>>> >>>> https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html >>> >>> Patches have been committed upstream. Thanks a lot guys! >>> >>> https://www.virtualbox.org/changeset/39521 >>> >> >> BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that >> we pass to vm_phys_alloc_contig. > > What's the difference of this? Pages should be marked busy only for some special occasions, wired pages are not normally busy; the correct explanation is quite a bit longer than this, the comment in the code explains VPO_BUSY as "page is in transit". Right now this flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some parts of code that are incorrect now are re-implemented properly: http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 > BTW you reported about the GCC 4.5 header stuff and it was also already fixed: > > http://lists.freebsd.org/pipermail/freebsd-emulation/2011-December/009312.html > Thank you! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 14:04:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B5571065670 for ; Mon, 5 Dec 2011 14:04:48 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1A608FC08 for ; Mon, 5 Dec 2011 14:04:47 +0000 (UTC) Received: by yenm2 with SMTP id m2so2402516yen.13 for ; Mon, 05 Dec 2011 06:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=F/DrX8/tKcnCbx9cHlB+GTxNap5GLcqiYcPI1MPGf3s=; b=jF+vAHZ2nwD6JPnOfSlMcVt1gfAoMYbjI0hv7slY5mlWFPwndcjcqJQTYaVjNtQwYy mr0LAn/e8V9jxsOkJCBzT7rzwE4KMWeOrRG0h9sYzhzcz7QGhMBmQK1E0gnwBKLSP4eA 3CqkpdboyZmbQ0F1IH8HOkvY9VdR/KDXlEbnM= MIME-Version: 1.0 Received: by 10.236.185.35 with SMTP id t23mr11284262yhm.99.1323093886848; Mon, 05 Dec 2011 06:04:46 -0800 (PST) Received: by 10.150.184.17 with HTTP; Mon, 5 Dec 2011 06:04:46 -0800 (PST) Date: Mon, 5 Dec 2011 16:04:46 +0200 Message-ID: From: Alexander Yerenkow To: freebsd-current Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem building current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:04:48 -0000 Hello. I think I have some problem building current on my system (which is not current). # uname -a FreeBSD 9.0-RC1 FreeBSD 9.0-RC1 #0: Tue Oct 18 18:51:43 UTC 2011 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # pwd /zpool0/testenv/sources/10-kms/lib/libc # svn info Path: . Working Copy Root Path: /zpool0/testenv/sources/10-kms URL: http://svn.freebsd.org/base/head/lib/libc Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 228276 Node Kind: directory Schedule: normal Last Changed Author: jilles Last Changed Rev: 228269 Last Changed Date: 2011-12-05 02:00:47 +0200 (=D0=CE, 05 =C4=C5=CB 2011) # make -DNO_CCACHE cc -O2 -pipe -I/zpool0/testenv/sources/10-kms/lib/libc/include -I/zpool0/testenv/sources/10-kms/lib/libc/../../include -I/zpool0/testenv/sources/10-kms/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/zpool0/testenv/sources/10-kms/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/zpool0/testenv/sources/10-kms/lib/libc -I/zpool0/testenv/sources/10-kms/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/zpool0/testenv/sources/10-kms/lib/libc/../../contrib/tzcode/stdtime -I/zpool0/testenv/sources/10-kms/lib/libc/stdtime -I/zpool0/testenv/sources/10-kms/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/zpool0/testenv/sources/10-kms/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /zpool0/testenv/sources/10-kms/lib/libc/net/sctp_sys_calls.c /zpool0/testenv/sources/10-kms/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info': /zpool0/testenv/sources/10-kms/lib/libc/net/sctp_sys_calls.c:416: error: 'SCTP_REMOTE_UDP_ENCAPS_PORT' undeclared (first use in this function) /zpool0/testenv/sources/10-kms/lib/libc/net/sctp_sys_calls.c:416: error: (Each undeclared identifier is reported only once /zpool0/testenv/sources/10-kms/lib/libc/net/sctp_sys_calls.c:416: error: for each function it appears in.) /zpool0/testenv/sources/10-kms/lib/libc/net/sctp_sys_calls.c:417: error: dereferencing pointer to incomplete type *** Error code 1 I'm getting this error when I'm trying to buildworld from svn checkouted sources (e.g. I'm using plain "make buildworld", without NO_CLEAN or some else). Any ideas why it is happening? --=20 Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 14:53:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EADD7106566C for ; Mon, 5 Dec 2011 14:53:25 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by mx1.freebsd.org (Postfix) with ESMTP id 687E58FC17 for ; Mon, 5 Dec 2011 14:53:24 +0000 (UTC) Received: from localhost ([90.55.41.34]) by mwinf5d47 with ME id 5SPL1i00K0kDMoA03SPL1z; Mon, 05 Dec 2011 15:23:21 +0100 Message-ID: <4EDCD3D7.4040501@orange.fr> Date: Mon, 05 Dec 2011 15:23:19 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.24) Gecko/20111114 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:53:26 -0000 Replying to a "random" message in this thread On 12/05/2011 13:49, Tom Evans wrote: > On Sat, Dec 3, 2011 at 3:24 PM, Max Khon wrote: >> CVS != csup. >> >> I wonder how many people will express their sentiments about CVS when >> they really mean cvsup/csup. > > I wasn't going to jump onto this bikeshed, as CVS will not be going > anywhere any time soon, I am sure. > > I use cvs, rather than csup. I use cvsup to fetch CVS archives to > /home/ncvs, and check out ports from there, as described in > development(7). > > If ports were no longer delivered via CVS, you may have had a point > about removing CVS from base - but they are not. > > In my mind, a first step would be to move ports to subversion, > initially using svn->cvs bridge. > Once done, the next step would be to change all infrastructure scripts > so that they can build from/be driven by subversion. > > After that, nothing in base would use cvs for any purpose, and at that > point I would be happy for it to be dropped from base - but only if it > was replaced by subversion. I think it is important that with a base > install of FreeBSD you can check out and update the source and rebuild > itself. > > Cheers > > Tom 1. I wonder why nobody has raised the point of the existence of numerous cvs/cvsup mirrors for FreeBSD. Do you want all of them to migrate to subversion ? have you asked their opinion about it ? are you prepared to an increased load on fewer servers if they do not migrate ? or are you thinking that this is a non problem because the declining number of users as FreeBSD become a system "for the developpers by the developpers and only the developpers" ? 2. All these talks about moving things from base to ports / spliting base / creating a new kind of ports miss the point that things must be maintained on an increasing number of branches: with the new 9.0 release there will be 3 stable branches (7.X, 8.X, 9.X), and with the foolish rush to create new major releases this will be ever increasing. But perhaps the real intent is to drop support of some parts of the system before officially stopping the support of a base branch ? 3. Some months ago dougb@ sent a message on a list with the lietmotiv "change is difficult". I wonder if he thought about the fact that could be the main reason why people stick to FreeBSD instead of migrating to another more fashionable system. Ordinary users also are volunteers, and in my work experience, using FreeBSD may be a day by day political fight. 4. Do not piss users off by making changes for the sake of it. Do not use your energy to destroy things rather that making things work (but it is easier to destroy that to build). Do not try to impose your view about the use of the system (someone wrote "FreeBSD is about tools and not about policies" and that must be preserved). I stop here, this message becoming too long and off topic. But I needed to write it in view of the current (sad) evolution of this system /community. Claude Buisson FreeBSD user since 1995 From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 15:00:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B89C1065673 for ; Mon, 5 Dec 2011 15:00:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE738FC1E for ; Mon, 5 Dec 2011 15:00:20 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so6359888vcb.13 for ; Mon, 05 Dec 2011 07:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pJagLiwyUrgDKbas4VzBqK1Wl84xxEqAMYK3nr8Wd3A=; b=Dhf/1NPh+RKQJqQuoTtw/iP84TML4PL6NWGyMqZrzQRFEBKBF7i2XxaBkCp96Qnd0Z LfK2dpPlPVQi21Fw4W0Y+GPtlG/hBXO4iq4ToWs/2GI6a4uwJa72Cs7/GFMwkbgBpCtd 1neZq86X8bJF8Igq8B/ya4AmcSxUw1PnTG/H0= MIME-Version: 1.0 Received: by 10.220.6.12 with SMTP id 12mr1051392vcx.35.1323097220349; Mon, 05 Dec 2011 07:00:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Mon, 5 Dec 2011 07:00:20 -0800 (PST) In-Reply-To: <4EDCD3D7.4040501@orange.fr> References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> <4EDCD3D7.4040501@orange.fr> Date: Mon, 5 Dec 2011 23:00:20 +0800 X-Google-Sender-Auth: _-fMUHZEDvNy4onLzOJsPbYk6Es Message-ID: From: Adrian Chadd To: Claude Buisson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 15:00:21 -0000 .. they'll work the same way things w/ src work at the moment, which I believe is: * stuff is in svn; * svn2cvs runs; * cvsup mirrors the cvs repository; * users use cvsup against that. So this is a non-issue. :) Adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 15:28:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD85106564A for ; Mon, 5 Dec 2011 15:28:15 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 014EC8FC0A for ; Mon, 5 Dec 2011 15:28:14 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so6395943vbb.13 for ; Mon, 05 Dec 2011 07:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EtCRuvIXmLe16sdaowOW2+jewPy74YPyJcxh+vsd6MY=; b=ILWSfvlB0n/2+KdMzKbIOmvH91yaAzq4ivpofGG4NZyYDmJsVp/q5bLXZP2YKgA6eB T2vlSY7mPi4TZH047/HDsBisxQIQJLtBGzkbHLyRhx80NyqojPAC927BmY8lv03PEHZF L5ghH5PYqn6YTeWCUurr7FAJGoEDrb4jxbfl8= MIME-Version: 1.0 Received: by 10.52.117.65 with SMTP id kc1mr4942153vdb.66.1323098894108; Mon, 05 Dec 2011 07:28:14 -0800 (PST) Received: by 10.52.172.240 with HTTP; Mon, 5 Dec 2011 07:28:14 -0800 (PST) In-Reply-To: <441usj6oi0.fsf@be-well.ilk.org> References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> <441usj6oi0.fsf@be-well.ilk.org> Date: Mon, 5 Dec 2011 15:28:14 +0000 Message-ID: From: Tom Evans To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 15:28:15 -0000 On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert wrote: > Tom Evans writes: > >> On Sat, Dec 3, 2011 at 3:24 PM, Max Khon wrote: >>> CVS != csup. >>> >>> I wonder how many people will express their sentiments about CVS when >>> they really mean cvsup/csup. >> >> I wasn't going to jump onto this bikeshed, as CVS will not be going >> anywhere any time soon, I am sure. >> >> I use cvs, rather than csup. I use cvsup to fetch CVS archives to >> /home/ncvs, and check out ports from there, as described in >> development(7). >> >> If ports were no longer delivered via CVS, you may have had a point >> about removing CVS from base - but they are not. > > Max Khon was the one who posted the original message in the thread. > That message explicitly stated that moving ports and doc away from CVS > was a prerequisite for removing CVS from base. As far as I've noticed, > no one has challenged that. > > I'm trying to think of a way to fit the previous paragraph into the > bikeshed metaphor, but I'm coming up with nothing. > The bikeshed is discussing about how cvs will eventually be removed from base when there are known, unsolved, issues that block that happening. Removing CVS will be an emotive issue, there is no need to discuss it until appropriate, as every one (like me) will wade in saying that "x is good and must stay" and "x is bad and must die", and every colour of bike shed in between. Just look at the number of replies to this topic. It would be much better to concentrate on the other issues rather than animated discussion of something that cannot realistically happen for quite some time yet. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 15:42:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6B9A106566B for ; Mon, 5 Dec 2011 15:42:16 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by mx1.freebsd.org (Postfix) with ESMTP id 710928FC12 for ; Mon, 5 Dec 2011 15:42:16 +0000 (UTC) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.42]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 92B05A70220 for ; Mon, 5 Dec 2011 10:12:57 -0500 (EST) Received: (qmail 252 invoked from network); 5 Dec 2011 15:12:56 -0000 Received: by simscan 1.4.0 ppid: 5054, pid: 19893, t: 0.1645s scanners: clamav: 0.88.2/m:52/d:10739 Received: from unknown (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Dec 2011 15:12:56 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id E39AB5645F; Mon, 5 Dec 2011 10:12:55 -0500 (EST) From: Lowell Gilbert To: freebsd-current@freebsd.org References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> Date: Mon, 05 Dec 2011 10:12:55 -0500 In-Reply-To: (Tom Evans's message of "Mon, 5 Dec 2011 12:49:04 +0000") Message-ID: <441usj6oi0.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Tom Evans Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 15:42:16 -0000 Tom Evans writes: > On Sat, Dec 3, 2011 at 3:24 PM, Max Khon wrote: >> CVS != csup. >> >> I wonder how many people will express their sentiments about CVS when >> they really mean cvsup/csup. > > I wasn't going to jump onto this bikeshed, as CVS will not be going > anywhere any time soon, I am sure. > > I use cvs, rather than csup. I use cvsup to fetch CVS archives to > /home/ncvs, and check out ports from there, as described in > development(7). > > If ports were no longer delivered via CVS, you may have had a point > about removing CVS from base - but they are not. Max Khon was the one who posted the original message in the thread. That message explicitly stated that moving ports and doc away from CVS was a prerequisite for removing CVS from base. As far as I've noticed, no one has challenged that. I'm trying to think of a way to fit the previous paragraph into the bikeshed metaphor, but I'm coming up with nothing. From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 15:57:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EEB9106566B for ; Mon, 5 Dec 2011 15:57:54 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) by mx1.freebsd.org (Postfix) with ESMTP id 0C82C8FC08 for ; Mon, 5 Dec 2011 15:57:53 +0000 (UTC) Received: from localhost ([90.55.41.34]) by mwinf5d20 with ME id 5Txq1i00N0kDMoA03Txqt4; Mon, 05 Dec 2011 16:57:52 +0100 Message-ID: <4EDCE9FE.6080205@orange.fr> Date: Mon, 05 Dec 2011 16:57:50 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.24) Gecko/20111114 Thunderbird/3.1.16 MIME-Version: 1.0 To: Tom Evans References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> <441usj6oi0.fsf@be-well.ilk.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 15:57:54 -0000 On 12/05/2011 16:28, Tom Evans wrote: > On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert > wrote: >> Tom Evans writes: >> >>> On Sat, Dec 3, 2011 at 3:24 PM, Max Khon wrote: >>>> CVS != csup. >>>> >>>> I wonder how many people will express their sentiments about CVS when >>>> they really mean cvsup/csup. >>> >>> I wasn't going to jump onto this bikeshed, as CVS will not be going >>> anywhere any time soon, I am sure. >>> >>> I use cvs, rather than csup. I use cvsup to fetch CVS archives to >>> /home/ncvs, and check out ports from there, as described in >>> development(7). >>> >>> If ports were no longer delivered via CVS, you may have had a point >>> about removing CVS from base - but they are not. >> >> Max Khon was the one who posted the original message in the thread. >> That message explicitly stated that moving ports and doc away from CVS >> was a prerequisite for removing CVS from base. As far as I've noticed, >> no one has challenged that. >> >> I'm trying to think of a way to fit the previous paragraph into the >> bikeshed metaphor, but I'm coming up with nothing. >> > > The bikeshed is discussing about how cvs will eventually be removed > from base when there are known, unsolved, issues that block that > happening. > > Removing CVS will be an emotive issue, there is no need to discuss it > until appropriate, as every one (like me) will wade in saying that "x > is good and must stay" and "x is bad and must die", and every colour > of bike shed in between. Just look at the number of replies to this > topic. > > It would be much better to concentrate on the other issues rather than > animated discussion of something that cannot realistically happen for > quite some time yet. > This could have been more clear, and the bikeshed could be stopped soooner, if it had been written before in an authoritative form, and by those who are at the start of this "unrealistic proposal". > Cheers > > Tom Claude Buisson From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 16:43:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EB93106564A for ; Mon, 5 Dec 2011 16:43:17 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id AB1708FC20 for ; Mon, 5 Dec 2011 16:43:16 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3SxsN35BTYzGMld for ; Mon, 5 Dec 2011 17:43:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:user-agent:date:date:subject:subject:organization :from:from:received:received:received:vbr-info; s=jakla2; t= 1323103394; x=1325695395; bh=Bzt/xk/euXGq+hNJ2cuiHWs4EMbmoOxAMjX xD3Sed1s=; b=TBUgGE69pUUjVx76xKRpRFbwVhuDstqE7Dha8fkuGgJomdYPGJ1 Fk683MeRwBKu+CpLoC/J/dZkNB7sWDWenUxLOfAbTqBofJUJKyJbSf7slNs+OotT VZTlpb5+3dXyecejmQHbjGvU4znLiZb75ZQTnNmW+v5Afe50BrsoZ8Z4= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id gwhQke0mzpVX for ; Mon, 5 Dec 2011 17:43:14 +0100 (CET) Received: from rozamunda.ijs.si (unknown [IPv6:2001:1470:ff80:0:225:90ff:fe11:b090]) by mail.ijs.si (Postfix) with ESMTP for ; Mon, 5 Dec 2011 17:43:14 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rozamunda.ijs.si (Postfix) with ESMTPSA id 8B0D2211244 for ; Mon, 5 Dec 2011 17:43:14 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-current@freebsd.org Date: Mon, 5 Dec 2011 17:43:13 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201112051743.13483.Mark.Martinec+freebsd@ijs.si> Subject: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:43:17 -0000 Using a guided partitioning install of 9.0-RC2 on a 64GB (virtual) disk (from a 9.0-RC2 ISO image) results in the following GPT partitioning: # gpart show /dev/ada0 => 34 134217661 ada0 GPT (64G) 34 128 1 freebsd-boot (64k) 162 125828992 2 freebsd-ufs (60G) 125829154 6709248 3 freebsd-swap (3.2G) 132538402 1679293 - free - (820M) This is most unfortunate for installations using 4kB sectored disks or SSD disks, especially as the guided partitioning tool is "recommended for beginners" - who may not be aware of performance issues of using unaligned partitions on 4k sectored disk, or may not be aware they are using such disks, or may not dare to venture into manual partitioning. Neither the freebsd-ufs partition, nor the freebsd-swap partition are aligned on a 4k boundary - quite unnecessarily so. At the expense of making the boot partition larger by 2 kB or shrinking it by 2 kB, the rest would align just fine. I see no ill effect for 512 B disks, but obvious benefit for 4k disks. Btw (unrelated), tried the same with a 2 TB (virtual) disk, the guided partitioning suggested 64k boot, 2TB ufs, and 4GB swap, but then fails with "No free space left on device". Didn't investigate, looks like a bug. Mark From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 16:47:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875BE106566C for ; Mon, 5 Dec 2011 16:47:54 +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 32FDF8FC08 for ; Mon, 5 Dec 2011 16:47:54 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 587BF5DD7; Mon, 5 Dec 2011 16:47:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pB5GlreM057042; Mon, 5 Dec 2011 16:47:53 GMT (envelope-from phk@phk.freebsd.dk) To: Mark Martinec From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 Dec 2011 17:43:13 +0100." <201112051743.13483.Mark.Martinec+freebsd@ijs.si> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 05 Dec 2011 16:47:53 +0000 Message-ID: <57041.1323103673@critter.freebsd.dk> Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:47:54 -0000 In message <201112051743.13483.Mark.Martinec+freebsd@ijs.si>, Mark Martinec wri tes: >Using a guided partitioning install of 9.0-RC2 on a 64GB (virtual) disk >(from a 9.0-RC2 ISO image) results in the following GPT partitioning: > ># gpart show /dev/ada0 >=> 34 134217661 ada0 GPT (64G) > 34 128 1 freebsd-boot (64k) > 162 125828992 2 freebsd-ufs (60G) > 125829154 6709248 3 freebsd-swap (3.2G) > 132538402 1679293 - free - (820M) > >This is most unfortunate for installations using 4kB sectored disks >or SSD disks, [...] This is not a new problem, you face the same issue with RAID5 devices. GEOM defines two provider properties for handling all these cases correctly: stripesize + stripeoffset. If the disk-driver has a 4k drive, or suspects it has a 4k drive ( these properties are advisory only), it should announce that with the stripe* properties on its GEOM provider. GEOM classes are responsible for passing these properties up with whatever adjustments are necessary (for instance modifying the stripeoffset for partitions). The partitioning tools, (All of them!) should examine these two properties and prod the user towards not doing something silly. -- 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-current@FreeBSD.ORG Mon Dec 5 16:49:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31BB91065677 for ; Mon, 5 Dec 2011 16:49:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id B3AB08FC0A for ; Mon, 5 Dec 2011 16:49:52 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 212682648; Mon, 05 Dec 2011 17:49:50 +0100 From: Hans Petter Selasky To: Robert Huff Date: Mon, 5 Dec 2011 17:47:14 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20188.51628.200426.786517@jerusalem.litteratus.org> In-Reply-To: <20188.51628.200426.786517@jerusalem.litteratus.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201112051747.14285.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: problem compiling cuse4bsd-kmod X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:49:53 -0000 Hi current users, Regarding the MK_CTF=XXX changes, did you check that code is still compliant for external ports? --HPS On Monday 05 December 2011 14:39:56 Robert Huff wrote: > Hello: > When trying to update I get: > > ===> Building for cuse4bsd-kmod-0.1.21_2 > make -f > /data/port-work/usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1. > 21/Makefile.lib HAVE_DEBUG=YES all Warning: Object directory not changed > from original > /data/port-work/usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1. > 21 make -f > /data/port-work/usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1. > 21/Makefile.kmod all "/sys/conf/kmod.mk", line 204: Malformed conditional > (${MK_CTF} != "no") "/sys/conf/kmod.mk", line 206: if-less endif > make: fatal errors encountered -- cannot continue > *** Error code 1 --HPS From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 16:53:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7097106566C for ; Mon, 5 Dec 2011 16:53:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7378FC12 for ; Mon, 5 Dec 2011 16:53:07 +0000 (UTC) Received: by ywp17 with SMTP id 17so6369835ywp.13 for ; Mon, 05 Dec 2011 08:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=G+9eUiOcvk0D00voh+rqD4cIe3F6u/LX2U14H94Aj9I=; b=T5XSYl5QjKMBUdYcXulBQ9lZTIRTH6okDXZgBfCdhc84u2ioJoVNmq9p0SI2yuUEI9 93ZRVTifkv9Ar+NQ+OcGY9+PnlRNERBFkpi/NP/1ma1FWOelIgUt//wVvQLlNDWI64Ht X2oJlX/0COO8DxId60dUvS6p07D+50hm4P09c= Received: by 10.50.169.71 with SMTP id ac7mr10964100igc.18.1323103986715; Mon, 05 Dec 2011 08:53:06 -0800 (PST) Received: from [192.168.20.56] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id wo4sm43611710igc.5.2011.12.05.08.53.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Dec 2011 08:53:04 -0800 (PST) References: <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <20111203.140334.74707074.sthaug@nethelp.no> <441usj6oi0.fsf@be-well.ilk.org> <4EDCE9FE.6080205@orange.fr> In-Reply-To: <4EDCE9FE.6080205@orange.fr> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <06D594A4-2667-4E30-9D99-7072BC7BAFBE@gmail.com> X-Mailer: iPhone Mail (9A405) From: Garrett Cooper Date: Mon, 5 Dec 2011 08:53:02 -0800 To: Claude Buisson Cc: Tom Evans , "freebsd-current@freebsd.org" Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:53:07 -0000 On Dec 5, 2011, at 7:57 AM, Claude Buisson wrote: > On 12/05/2011 16:28, Tom Evans wrote: >> On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert >> wrote: >>> Tom Evans writes: >>>=20 >>>> On Sat, Dec 3, 2011 at 3:24 PM, Max Khon wrote: >>>>> CVS !=3D csup. >>>>>=20 >>>>> I wonder how many people will express their sentiments about CVS when >>>>> they really mean cvsup/csup. >>>>=20 >>>> I wasn't going to jump onto this bikeshed, as CVS will not be going >>>> anywhere any time soon, I am sure. >>>>=20 >>>> I use cvs, rather than csup. I use cvsup to fetch CVS archives to >>>> /home/ncvs, and check out ports from there, as described in >>>> development(7). >>>>=20 >>>> If ports were no longer delivered via CVS, you may have had a point >>>> about removing CVS from base - but they are not. >>>=20 >>> Max Khon was the one who posted the original message in the thread. >>> That message explicitly stated that moving ports and doc away from CVS >>> was a prerequisite for removing CVS from base. As far as I've noticed, >>> no one has challenged that. >>>=20 >>> I'm trying to think of a way to fit the previous paragraph into the >>> bikeshed metaphor, but I'm coming up with nothing. >>>=20 >>=20 >> The bikeshed is discussing about how cvs will eventually be removed >> from base when there are known, unsolved, issues that block that >> happening. >>=20 >> Removing CVS will be an emotive issue, there is no need to discuss it >> until appropriate, as every one (like me) will wade in saying that "x >> is good and must stay" and "x is bad and must die", and every colour >> of bike shed in between. Just look at the number of replies to this >> topic. >>=20 >> It would be much better to concentrate on the other issues rather than >> animated discussion of something that cannot realistically happen for >> quite some time yet. >>=20 >=20 > This could have been more clear, and the bikeshed could be stopped soooner= , if > it had been written before in an authoritative form, and by those who are a= t the > start of this "unrealistic proposal". This proposal might have been better for arch for a first pass. I know there= are active efforts in progress by the community to move docs and ports over= to svn, but I'm not sure what the progress is. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 17:00:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 281E9106564A for ; Mon, 5 Dec 2011 17:00:58 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id F04FF8FC1B for ; Mon, 5 Dec 2011 17:00:57 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 41C185DF03 for ; Mon, 5 Dec 2011 12:00:57 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-mHmxCs1-pI for ; Mon, 5 Dec 2011 12:00:57 -0500 (EST) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mail.egr.msu.edu (Postfix) with ESMTPSA id 1845D5DEFD for ; Mon, 5 Dec 2011 12:00:57 -0500 (EST) Message-ID: <4EDCF8C9.3030805@egr.msu.edu> Date: Mon, 05 Dec 2011 12:00:57 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4ECD4584.6040905@egr.msu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Trouble getting serial support for "Live CD" in 9 installer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:00:58 -0000 On 11/23/11 15:03, Garrett Cooper wrote: > On Wed, Nov 23, 2011 at 11:12 AM, Adam McDougall wrote: >> I often use the serial console on my servers through ILOM remote console >> access to install FreeBSD because it lets me cut and paste commands into a >> live shell from install media. Back with FreeBSD 8.x and previous, the >> console worked as a dual console between the redirected VGA/keyboard console >> and serial, all I had to do was drop to the loader prompt at the boot loader >> menu to enter: >> >> set console=comconsole >> set boot_serial=yes >> boot >> >> From then on, the VGA console was ignored until I rebooted. But in 9.x >> (currently trying 9.0-RC2 from the usb image), I have to interrupt an >> earlier loader to use -h or -D to enable serial(dual) console support at >> all. I then enter the two variables above as I usually do, then specify my >> terminal type (xterm), then choose "Live CD" which prints: >> Updating motd: /etc/motd is not writable, update failed. >> Configuring syscons: blanktime. >> Starting cron. >> Starting background file system checks in 60 seconds. >> >> Wed Nov 23 19:03:02 UTC 2011 >> >> but then it prints the FreeBSD banner and spawns the login: prompt on the >> VGA console instead. >> >> Is there something else I can set during the boot process to make this work? >> I could try modifying the configuration on the usb image to suit my site >> but this is more modification than I required in the past and surprisingly >> different. Please let me know if I can provide more information or help in >> some way. Thanks. >> >> If I don't hear back in a few days or so, I'll make a PR. > > You'll need to change your device.hints and /etc/ttys. > -Garrett > _______________________________________________ > 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" Thanks. This lead me to an even easier solution with no editing that should work with booting from CD and with previous versions: 1. Boot completely normally 2. Use the installer to drop to Live CD shell 3. execute: /usr/libexec/getty std.9600 ttyu0 This spawns a login prompt on the serial port ttyu0 which is essentially all I need. I didn't seem to need to alter the device hints at all for my situation, and on a USB key I can mount -u -o rw / to edit one or more of /etc/ttys, /boot/loader.conf, /boot.config if I want to make it permanent for next time. From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 17:10:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 806B7106566B for ; Mon, 5 Dec 2011 17:10:47 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 451D48FC12 for ; Mon, 5 Dec 2011 17:10:47 +0000 (UTC) Received: by qadb17 with SMTP id b17so1881548qad.13 for ; Mon, 05 Dec 2011 09:10:46 -0800 (PST) Received: by 10.224.31.66 with SMTP id x2mr8873099qac.27.1323105046302; Mon, 05 Dec 2011 09:10:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.216.15 with HTTP; Mon, 5 Dec 2011 09:10:12 -0800 (PST) In-Reply-To: <57041.1323103673@critter.freebsd.dk> References: <201112051743.13483.Mark.Martinec+freebsd@ijs.si> <57041.1323103673@critter.freebsd.dk> From: Maxim Khitrov Date: Mon, 5 Dec 2011 12:10:12 -0500 Message-ID: To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-current@freebsd.org Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:10:47 -0000 On Mon, Dec 5, 2011 at 11:47 AM, Poul-Henning Kamp wro= te: > In message <201112051743.13483.Mark.Martinec+freebsd@ijs.si>, Mark Martin= ec wri > tes: >>Using a guided partitioning install of 9.0-RC2 on a 64GB (virtual) disk >>(from a 9.0-RC2 ISO image) results in the following GPT partitioning: >> >># gpart show /dev/ada0 >>=3D> =C2=A0 =C2=A0 =C2=A0 34 =C2=A0134217661 =C2=A0ada0 =C2=A0GPT =C2=A0(= 64G) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 34 =C2=A0 =C2=A0 =C2=A0 =C2=A0128 =C2=A0 =C2= =A0 1 =C2=A0freebsd-boot =C2=A0(64k) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0162 =C2=A0125828992 =C2=A0 =C2=A0 2 =C2=A0fre= ebsd-ufs =C2=A0(60G) >> =C2=A0125829154 =C2=A0 =C2=A06709248 =C2=A0 =C2=A0 3 =C2=A0freebsd-swap = =C2=A0(3.2G) >> =C2=A0132538402 =C2=A0 =C2=A01679293 =C2=A0 =C2=A0 =C2=A0 =C2=A0- free -= =C2=A0(820M) >> >>This is most unfortunate for installations using 4kB sectored disks >>or SSD disks, [...] > > This is not a new problem, you face the same issue with RAID5 devices. > > > GEOM defines two provider properties for handling all these cases > correctly: stripesize + stripeoffset. > > If the disk-driver has a 4k drive, or suspects it has a 4k drive ( > these properties are advisory only), it should announce that with > the stripe* properties on its GEOM provider. > > GEOM classes are responsible for passing these properties up with > whatever adjustments are necessary (for instance modifying the > stripeoffset for partitions). > > The partitioning tools, (All of them!) should examine these two > properties and prod the user towards not doing something silly. Interesting... But I think 4k alignment by default would be a good thing even for 512 drives. First, because some 4k drives fake 512 byte sectors, and I'm not sure that the partitioning tools would be able to correctly detect this in all cases. Second, someone may want to copy the partition table and dump/restore data to another drive, which could be using 4k sectors. Same problem could arise if you're using some disk imaging software. Since the industry is heading in that direction, I think the safer thing to do is to set the minimum alignment to 4k and increase that when the underlying hardware (e.g. RAID) requests it. Personally, I partition my servers manually by creating a 512 kB boot partition aligned to 512 kB, and align all remaining partitions to 1 MB. - Max From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 17:22:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EF421065675 for ; Mon, 5 Dec 2011 17:22:35 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id B380E8FC15 for ; Mon, 5 Dec 2011 17:22:34 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3SxtFQ0pYLzGMpW for ; Mon, 5 Dec 2011 18:22:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1323105753; x=1325697754; bh=i59 4IPg/uBQaAjMsnuTPBffOStvdMzXxyzkzADzLSlc=; b=ObjCOL6JYZ/rcDzTXjA y9ZN2cY1U2QBsV3e4zqHp2Va2qRMO7Q4KbK92I8NfoAibXeHs6QOnIN47PEFcEBA 91qFTSFmI01p4qBMJTF16Ey4aAL4diihqH0SZEEjpwU0kHkp+hBHTp05d8b3t4NN kGPpcPgnQJ72b2Z1cICGQ1pY= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id l9l0w-oif4MD for ; Mon, 5 Dec 2011 18:22:33 +0100 (CET) Received: from rozamunda.ijs.si (unknown [IPv6:2001:1470:ff80:0:225:90ff:fe11:b090]) by mail.ijs.si (Postfix) with ESMTP for ; Mon, 5 Dec 2011 18:22:33 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rozamunda.ijs.si (Postfix) with ESMTPSA id E6928211288 for ; Mon, 5 Dec 2011 18:22:32 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-current@freebsd.org Date: Mon, 5 Dec 2011 18:22:30 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) References: <201112051743.13483.Mark.Martinec+freebsd@ijs.si> In-Reply-To: <201112051743.13483.Mark.Martinec+freebsd@ijs.si> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201112051822.31028.Mark.Martinec+freebsd@ijs.si> Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:22:35 -0000 > Btw (unrelated), tried the same with a 2 TB (virtual) disk, the > guided partitioning suggested 64k boot, 2TB ufs, and 4GB swap, > but then fails with "No free space left on device". > Didn't investigate, looks like a bug. Sorry, my mistake, please disregard this claim. I chose "create" instead of "finish". The rest of my posting (4k alignment) stands. Mark From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 17:32:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A05D51065740 for ; Mon, 5 Dec 2011 17:32:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7428E8FC1D for ; Mon, 5 Dec 2011 17:32:15 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LVQ00F00RDQEA00@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 05 Dec 2011 11:32:14 -0600 (CST) Received: from wanderer.tachypleus.net (i3-user-nat.icecube.wisc.edu [128.104.255.12]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LVQ004DYRDP3840@smtpauth3.wiscmail.wisc.edu>; Mon, 05 Dec 2011 11:32:13 -0600 (CST) Date: Mon, 05 Dec 2011 11:32:13 -0600 From: Nathan Whitehorn In-reply-to: <57041.1323103673@critter.freebsd.dk> To: Poul-Henning Kamp Message-id: <4EDD001D.1030702@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.255.12 X-Spam-PmxInfo: Server=avs-11, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.5.172116, SenderIP=128.104.255.12 X-Enigmail-Version: 1.0.1 References: <57041.1323103673@critter.freebsd.dk> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110928 Thunderbird/7.0 Cc: Mark Martinec , freebsd-current@freebsd.org Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:32:15 -0000 On 12/05/11 10:47, Poul-Henning Kamp wrote: > In message <201112051743.13483.Mark.Martinec+freebsd@ijs.si>, Mark Martinec wri > tes: >> Using a guided partitioning install of 9.0-RC2 on a 64GB (virtual) disk >> (from a 9.0-RC2 ISO image) results in the following GPT partitioning: >> >> # gpart show /dev/ada0 >> => 34 134217661 ada0 GPT (64G) >> 34 128 1 freebsd-boot (64k) >> 162 125828992 2 freebsd-ufs (60G) >> 125829154 6709248 3 freebsd-swap (3.2G) >> 132538402 1679293 - free - (820M) >> >> This is most unfortunate for installations using 4kB sectored disks >> or SSD disks, [...] > > This is not a new problem, you face the same issue with RAID5 devices. > > > GEOM defines two provider properties for handling all these cases > correctly: stripesize + stripeoffset. > > If the disk-driver has a 4k drive, or suspects it has a 4k drive ( > these properties are advisory only), it should announce that with > the stripe* properties on its GEOM provider. > > GEOM classes are responsible for passing these properties up with > whatever adjustments are necessary (for instance modifying the > stripeoffset for partitions). > > The partitioning tools, (All of them!) should examine these two > properties and prod the user towards not doing something silly. > The installer will align all partitions to the GEOM stripesize/offset. We could make it do min(4KB, stripesize), but in general I think this is better done at the GEOM level. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 17:38:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6924E1065673 for ; Mon, 5 Dec 2011 17:38:11 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 19A568FC14 for ; Mon, 5 Dec 2011 17:38:11 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3SxtbQ3RCCzGMXQ for ; Mon, 5 Dec 2011 18:38:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1323106689; x=1325698690; bh=lk6 DcndQ0Kw2KnNisEljmyVBp2jA5xGlT47tHoIMFqQ=; b=S0wVDMmPJ/5Mu4+4+fu dqFC8fmXgVHj2t2CnxbOyPjAVG2hfInRlSIf+ECRdPvHCOuDEDHSDVKDJfss2FU0 lImkr8xzLIfr1RPecxLRQ5FraepW6kEZB5sjjMWCtMIAZRbTqFDnnz+yRWic/Jcl hn/uBVoorhs9lBEuQOXsyTEQ= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id N9OjjrtIDjQa for ; Mon, 5 Dec 2011 18:38:09 +0100 (CET) Received: from rozamunda.ijs.si (unknown [IPv6:2001:1470:ff80:0:225:90ff:fe11:b090]) by mail.ijs.si (Postfix) with ESMTP for ; Mon, 5 Dec 2011 18:38:09 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rozamunda.ijs.si (Postfix) with ESMTPSA id 0E2E8211620 for ; Mon, 5 Dec 2011 18:38:09 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-current@freebsd.org Date: Mon, 5 Dec 2011 18:38:08 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) References: <57041.1323103673@critter.freebsd.dk> <4EDD001D.1030702@freebsd.org> In-Reply-To: <4EDD001D.1030702@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201112051838.08327.Mark.Martinec+freebsd@ijs.si> Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:38:11 -0000 Nathan wrote: > The installer will align all partitions to the GEOM stripesize/offset. > We could make it do min(4KB, stripesize), but in general I think this is > better done at the GEOM level. I doubt any SSD device on the market will want to admit its internal structure, they all claim 512 sectors AFAICT. Seems to me the min(4KB,stripesize) would be a safe bet. Mark From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 17:40:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FF4C106567A for ; Mon, 5 Dec 2011 17:40:14 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7BB8FC13 for ; Mon, 5 Dec 2011 17:40:14 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3Sxtdn4WjRzGMXQ for ; Mon, 5 Dec 2011 18:40:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1323106812; x=1325698813; bh=zR/ Ope5YQe9ndYbew5GH6Qdy7AbOyQyl17YzwuaoABA=; b=jd7zR4QDj6+ijtT2Wfe nADhP3d3Q8bshwrU0XRHVKCPpuTVimx/m1pMVBxuvsyykw36KJ36fW8QgPbWTkQe wBu3Lp1rSUs4GmRfMFE8XHcOeQINC0IrCTc/J2I8fBGsO7QV9cTrxKFZxsp9Ax7R emLE7tBJ8EallXq4anxNW0oM= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id qGM-y9mwkden for ; Mon, 5 Dec 2011 18:40:12 +0100 (CET) Received: from rozamunda.ijs.si (unknown [IPv6:2001:1470:ff80:0:225:90ff:fe11:b090]) by mail.ijs.si (Postfix) with ESMTP for ; Mon, 5 Dec 2011 18:40:12 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rozamunda.ijs.si (Postfix) with ESMTPSA id 8C180211620 for ; Mon, 5 Dec 2011 18:40:12 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-current@freebsd.org Date: Mon, 5 Dec 2011 18:40:12 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) References: <57041.1323103673@critter.freebsd.dk> <4EDD001D.1030702@freebsd.org> <201112051838.08327.Mark.Martinec+freebsd@ijs.si> In-Reply-To: <201112051838.08327.Mark.Martinec+freebsd@ijs.si> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201112051840.12172.Mark.Martinec+freebsd@ijs.si> Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:40:14 -0000 > Seems to me the min(4KB,stripesize) would be a safe bet. s/min/max/ Mark From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 17:58:31 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFA961065679; Mon, 5 Dec 2011 17:58:31 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 647128FC15; Mon, 5 Dec 2011 17:58:30 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id C003F290F3C; Mon, 5 Dec 2011 11:58:29 -0600 (CST) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id A4461290F0D; Mon, 5 Dec 2011 11:58:29 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id Y5pCaGg0g6us; Mon, 5 Dec 2011 11:58:29 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id DB9AD290F2E; Mon, 5 Dec 2011 11:58:28 -0600 (CST) Message-ID: <4EDD0644.5030902@rice.edu> Date: Mon, 05 Dec 2011 11:58:28 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> In-Reply-To: <4EDCCDA2.5070006@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Kurtsou , Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current , Bernhard Froehlich , Jung-uk Kim Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:58:31 -0000 On 12/05/2011 07:56, Andriy Gapon wrote: > on 05/12/2011 15:15 Bernhard Froehlich said the following: >> On 05.12.2011 14:06, Andriy Gapon wrote: >>> on 05/12/2011 14:57 Bernhard Froehlich said the following: >>>> On 02.12.2011 12:55, Bernhard Froehlich wrote: >>>>> Patch has been send upstream: >>>>> >>>>> >>>>> >>>>> https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html >>>> Patches have been committed upstream. Thanks a lot guys! >>>> >>>> https://www.virtualbox.org/changeset/39521 >>>> >>> BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that >>> we pass to vm_phys_alloc_contig. >> What's the difference of this? > Pages should be marked busy only for some special occasions, wired pages are not > normally busy; the correct explanation is quite a bit longer than this, the > comment in the code explains VPO_BUSY as "page is in transit". Right now this > flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some > parts of code that are incorrect now are re-implemented properly: > http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): * VM_ALLOC_NOOBJ page is not associated with an object and * should not have the flag VPO_BUSY set With regard to the message that the above link points to, I suspect that the introduction of vm_page_alloc_contig() can be used to address the first problem that you point out. Specifically, one or more OBJT_PHYS vm objects could be created and passed to vm_map_find() and then vm_page_alloc_contig() could be used to fill these vm objects with memory. Alan From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 18:19:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9319106566B for ; Mon, 5 Dec 2011 18:19:33 +0000 (UTC) (envelope-from curtis.ruck@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5FC8FC14 for ; Mon, 5 Dec 2011 18:19:33 +0000 (UTC) Received: by eaai12 with SMTP id i12so6118141eaa.13 for ; Mon, 05 Dec 2011 10:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Nqr2ra/6jotDQD+g2apQ6qrdJVkWzM2t+Erey/rvjv0=; b=VFFBMGs/1BqsAdhfSWxV2Eeh13W8t87WqYNmxAktMVGmx3aHxjPwGr8uezFrJL/f+K BUxTlHpsJR+95dhqVj1v+eUA2RIuQGCPQ7uhYZANm6P/WmFFcveF0zYMKLD2R2MhfJlO sgV+FR9KDqX9NucMHfNwsUARnXSaH753Z33UM= Received: by 10.213.113.198 with SMTP id b6mr1212312ebq.140.1323107422211; Mon, 05 Dec 2011 09:50:22 -0800 (PST) MIME-Version: 1.0 Sender: curtis.ruck@gmail.com Received: by 10.213.29.12 with HTTP; Mon, 5 Dec 2011 09:49:51 -0800 (PST) In-Reply-To: <201112051840.12172.Mark.Martinec+freebsd@ijs.si> References: <57041.1323103673@critter.freebsd.dk> <4EDD001D.1030702@freebsd.org> <201112051838.08327.Mark.Martinec+freebsd@ijs.si> <201112051840.12172.Mark.Martinec+freebsd@ijs.si> From: Curtis Ruck Date: Mon, 5 Dec 2011 12:49:51 -0500 X-Google-Sender-Auth: LrluA5NTwjJ1lG3emkfh3sw40qk Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Mark Martinec Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:19:33 -0000 Defaulting alignment to 4kb would also help drastically in most virtualization environments due to the underlying (and its essentially invisible to the guest os) shared storage that is likely being used. -- Curtis Ruck Anytime: 347-542-7825 On Mon, Dec 5, 2011 at 12:40, Mark Martinec wrote: > > Seems to me the min(4KB,stripesize) would be a safe bet. > > s/min/max/ > > Mark > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 18:24:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84848106566B for ; Mon, 5 Dec 2011 18:24:15 +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 444C08FC12 for ; Mon, 5 Dec 2011 18:24:15 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1354E5C39; Mon, 5 Dec 2011 18:24:14 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pB5IOCBi057320; Mon, 5 Dec 2011 18:24:13 GMT (envelope-from phk@phk.freebsd.dk) To: Maxim Khitrov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 Dec 2011 12:10:12 EST." Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 05 Dec 2011 18:24:12 +0000 Message-ID: <57319.1323109452@critter.freebsd.dk> Cc: Mark Martinec , freebsd-current@freebsd.org Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:24:16 -0000 In message , Maxim Khitrov writes: >Interesting... But [...] A "But" which I read to mean "Nahh, too hard, lets just hack it..." I don't agree with that, we should do it right. -- 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-current@FreeBSD.ORG Mon Dec 5 19:10:59 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C605106566C for ; Mon, 5 Dec 2011 19:10:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A77D98FC13 for ; Mon, 5 Dec 2011 19:10:58 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 951627300A; Mon, 5 Dec 2011 20:27:03 +0100 (CET) Date: Mon, 5 Dec 2011 20:27:03 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20111205192703.GA49118@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:10:59 -0000 Hi, I am trying to establish the baseline performance for 10G throughput over TCP, and would like to collect some data points. As a testing program i am using nuttcp from ports (as good as anything, i guess -- it is reasonably flexible, and if you use it in TCP with relatively large writes, the overhead for syscalls and gettimeofday() shouldn't kill you). I'd be very grateful if you could do the following test: - have two machines connected by a 10G link - on one run "nuttcp -S" - on the other one run "nuttcp -t -T 5 -w 128 -v the.other.ip" and send me a dump of the output, such as the one(s) at the end of the message. I am mostly interested in two configurations: - one over loopback, which should tell how fast is the CPU+memory As an example, one of my machines does about 15 Gbit/s, and one of the faster ones does about 44 Gbit/s - one over the wire using 1500 byte mss. Here it really matters how good is the handling of small MTUs. As a data point, on my machines i get 2..3.5 Gbit/s on the "slow" machine with a 1500 byte mtu and default card setting. Clearing the interrupt mitigation register (so no mitigation) brings the rate to 5-6 Gbit/s. Same hardware with linux does about 8 Gbit/s. HEAD seems 10-20% slower than RELENG_8 though i am not sure who is at fault. The receive side is particularly critical - on FreeBSD the receiver is woken up every two packets (do the math below, between the number of rx calls and throughput and mss), resulting in almost 200K activations per second, and despite the fact that interrupt mitigation is set to a much lower value (so incoming packets should be batched). On linux, i see much fewer reads, presumably the process is woken up only at the end of a burst. cheers luigi ------------ EXAMPLES OF OUTPUT ---------------------- > nuttcp -t -T 5 -w 128 -v 10.0.1.2 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.0.1.2 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.0.1.2 with mss=1460, RTT=0.103 ms nuttcp-t: send window size = 131400, receive window size = 65700 nuttcp-t: 3095.0982 MB in 5.00 real seconds = 633785.85 KB/sec = 5191.9737 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 49522 I/O calls, msec/call = 0.10, calls/sec = 9902.99 nuttcp-t: 0.0user 2.7sys 0:05real 54% 100i+2639d 752maxrss 0+3pf 258876+6csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.0.1.4 nuttcp-r: send window size = 33580, receive window size = 131400 nuttcp-r: 3095.0982 MB in 5.17 real seconds = 613526.42 KB/sec = 5026.0084 Mbps nuttcp-r: 1114794 I/O calls, msec/call = 0.00, calls/sec = 215801.03 nuttcp-r: 0.1user 3.5sys 0:05real 69% 112i+1104d 626maxrss 0+15pf 507653+188csw > > nuttcp -t -T 5 -w 128 -v localhost nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.051 ms nuttcp-t: send window size = 143360, receive window size = 71680 nuttcp-t: 26963.4375 MB in 5.00 real seconds = 5521440.59 KB/sec = 45231.6413 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 431415 I/O calls, msec/call = 0.01, calls/sec = 86272.51 nuttcp-t: 0.0user 4.6sys 0:05real 93% 102i+2681d 774maxrss 0+3pf 2510+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 127.0.0.1 nuttcp-r: send window size = 43008, receive window size = 143360 nuttcp-r: 26963.4375 MB in 5.20 real seconds = 5313135.74 KB/sec = 43525.2080 Mbps nuttcp-r: 767807 I/O calls, msec/call = 0.01, calls/sec = 147750.09 nuttcp-r: 0.1user 3.9sys 0:05real 79% 98i+2570d 772maxrss 0+16pf 311014+8csw on the server, run " From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 19:21:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C52106566B for ; Mon, 5 Dec 2011 19:21:58 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 131538FC0A for ; Mon, 5 Dec 2011 19:21:58 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3Sxwv93DsMzGMpY for ; Mon, 5 Dec 2011 20:21:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1323112916; x=1325704917; bh=B3N PH7LDXnKt9J41GOFETJOab+8Rz8ycAS8RLxFvJUY=; b=d+mI9CtasC28fphZb7h 3QxF+9mOkplnxjBS0HDjb0FV5xAaLOG5rycWclONOWjZK57b9ErCB0LjQpeFrwDk pXBvbAAncJaQ/3b9p3IhX+udnBC+XkhHOdneyzsUjOez8Z/0lYT0VbRrTcAhh2YT hhFLO3jOwrk9KwWVEGt6DDJU= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id PIK8bZpDUzLJ for ; Mon, 5 Dec 2011 20:21:56 +0100 (CET) Received: from rozamunda.ijs.si (unknown [IPv6:2001:1470:ff80:0:225:90ff:fe11:b090]) by mail.ijs.si (Postfix) with ESMTP for ; Mon, 5 Dec 2011 20:21:56 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rozamunda.ijs.si (Postfix) with ESMTPSA id 67463211679 for ; Mon, 5 Dec 2011 20:21:56 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-current@freebsd.org Date: Mon, 5 Dec 2011 20:21:56 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) References: <201111240126.21470.Mark.Martinec+freebsd@ijs.si> <4ED415CD.1080005@delphij.net> In-Reply-To: <4ED415CD.1080005@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201112052021.56138.Mark.Martinec+freebsd@ijs.si> Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:21:58 -0000 Xin LI wrote: > Try procstat -kk to find the calling stack, as a start? > This could be very useful when tracking down problems. > Also the 'D' flag from ps(1) output in most times are not quite useful > and ps -o wchan would tell you what exactly it was waiting for, just FYI. Posted both a few days ago, you must have missed it. Ivan Voras wrote: > You should probably ask at the freebsd-scsi@ mailing list. From looking > at the code it looks like "ffp" is used for LUN scan timeout. Done, posted to freebsd-scsi@ mailing list. Thanks for the suggestion. Mark From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 19:30:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4A2106566C for ; Mon, 5 Dec 2011 19:30:38 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E84D48FC15 for ; Mon, 5 Dec 2011 19:30:37 +0000 (UTC) Received: by qcse13 with SMTP id e13so2416182qcs.13 for ; Mon, 05 Dec 2011 11:30:37 -0800 (PST) Received: by 10.224.211.66 with SMTP id gn2mr9245017qab.14.1323113437251; Mon, 05 Dec 2011 11:30:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.216.15 with HTTP; Mon, 5 Dec 2011 11:30:05 -0800 (PST) In-Reply-To: <57319.1323109452@critter.freebsd.dk> References: <57319.1323109452@critter.freebsd.dk> From: Maxim Khitrov Date: Mon, 5 Dec 2011 14:30:05 -0500 Message-ID: To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: Mark Martinec , freebsd-current@freebsd.org Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:30:38 -0000 On Mon, Dec 5, 2011 at 1:24 PM, Poul-Henning Kamp wrote: > In message > , Maxim Khitrov writes: > >>Interesting... But [...] > > A "But" which I read to mean "Nahh, too hard, lets just hack it..." > > I don't agree with that, we should do it right. How do you get around the hardware claiming to use 512-byte sectors when it actually uses 4 kB internally? Same problem with virtual machines, as Curtis pointed out. IMHO, this is just a matter of using safe default values in bsdinstall. - Max From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 19:37:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61468106566B for ; Mon, 5 Dec 2011 19:37: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 1EE9A8FC18 for ; Mon, 5 Dec 2011 19:37:41 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D10D25C34; Mon, 5 Dec 2011 19:37:40 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pB5JbedE058007; Mon, 5 Dec 2011 19:37:40 GMT (envelope-from phk@phk.freebsd.dk) To: Maxim Khitrov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 Dec 2011 14:30:05 EST." Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 05 Dec 2011 19:37:40 +0000 Message-ID: <58006.1323113860@critter.freebsd.dk> Cc: Mark Martinec , freebsd-current@freebsd.org Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:37:42 -0000 In message , Maxim Khitrov writes: >How do you get around the hardware claiming to use 512-byte sectors >when it actually uses 4 kB internally? Did you read what I wrote ? ] If the disk-driver has a 4k drive, or suspects it has a 4k drive ( ] these properties are advisory only), it should announce that with ] the stripe* properties on its GEOM provider. notice "suspects" ? It would be entirely reasonable for the driver to suspect all drives larger than some N GB to be 4k drives. But the information has to flow up from the driver, so that intermediate GEOM classes can adjust the two stripe-properties according to what they do. -- 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-current@FreeBSD.ORG Mon Dec 5 21:34:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 593D71065673 for ; Mon, 5 Dec 2011 21:34:54 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 74D158FC0A for ; Mon, 5 Dec 2011 21:34:53 +0000 (UTC) Received: from [192.168.100.133] (varna2.digsys.bg [193.68.0.70]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pB5LF9rQ040892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Dec 2011 23:15:15 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Daniel Kalchev In-Reply-To: <20111205192703.GA49118@onelab2.iet.unipi.it> Date: Mon, 5 Dec 2011 23:15:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> References: <20111205192703.GA49118@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1251.1) Cc: current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:34:54 -0000 On Dec 5, 2011, at 9:27 PM, Luigi Rizzo wrote: > - have two machines connected by a 10G link > - on one run "nuttcp -S" > - on the other one run "nuttcp -t -T 5 -w 128 -v the.other.ip" > Any particular tuning of FreeBSD? Daniel From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 21:35:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 716A21065678 for ; Mon, 5 Dec 2011 21:35:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 44DB48FC19 for ; Mon, 5 Dec 2011 21:35:48 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pB5LZifn097802 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 13:35:47 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EDD393F.1080204@freebsd.org> Date: Mon, 05 Dec 2011 13:35:59 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Mark Martinec References: <57041.1323103673@critter.freebsd.dk> <4EDD001D.1030702@freebsd.org> <201112051838.08327.Mark.Martinec+freebsd@ijs.si> In-Reply-To: <201112051838.08327.Mark.Martinec+freebsd@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:35:48 -0000 On 12/5/11 9:38 AM, Mark Martinec wrote: > Nathan wrote: >> The installer will align all partitions to the GEOM stripesize/offset. >> We could make it do min(4KB, stripesize), but in general I think this is >> better done at the GEOM level. > I doubt any SSD device on the market will want to admit its > internal structure, they all claim 512 sectors AFAICT. > Seems to me the min(4KB,stripesize) would be a safe bet. we (fusion-IO) certainly export our native blocksize.. whether it's 512 or 520 or 4000 or 4096.. you feed it in as a format parameter and we'll actually do what you ask for. (512 and 4096 are the most used values of course) > Mark > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 22:02:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC2B1065672; Mon, 5 Dec 2011 22:02:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E47F18FC16; Mon, 5 Dec 2011 22:02:19 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA19597; Tue, 06 Dec 2011 00:02:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXgbx-000LKX-Dt; Tue, 06 Dec 2011 00:02:09 +0200 Message-ID: <4EDD3F60.8050601@FreeBSD.org> Date: Tue, 06 Dec 2011 00:02:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Cox References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> In-Reply-To: <4EDD0644.5030902@rice.edu> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:02:21 -0000 on 05/12/2011 19:58 Alan Cox said the following: > On 12/05/2011 07:56, Andriy Gapon wrote: >> Pages should be marked busy only for some special occasions, wired pages are not >> normally busy; the correct explanation is quite a bit longer than this, the >> comment in the code explains VPO_BUSY as "page is in transit". Right now this >> flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some >> parts of code that are incorrect now are re-implemented properly: >> http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 > > VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From > the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): > > * VM_ALLOC_NOOBJ page is not associated with an object and > * should not have the flag VPO_BUSY set Ah, oops, forgot about this. > With regard to the message that the above link points to, I suspect that the > introduction of vm_page_alloc_contig() can be used to address the first problem > that you point out. Specifically, one or more OBJT_PHYS vm objects could be > created and passed to vm_map_find() and then vm_page_alloc_contig() could be > used to fill these vm objects with memory. That's exactly what I was trying to do when I encountered a need for VM_ALLOC_NOOBJ - my object was not NULL. Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a user map (or a few of them) at the same time? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 22:12:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 963E81065670 for ; Mon, 5 Dec 2011 22:12:29 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 596C98FC08 for ; Mon, 5 Dec 2011 22:12:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B59397300A; Mon, 5 Dec 2011 23:28:34 +0100 (CET) Date: Mon, 5 Dec 2011 23:28:34 +0100 From: Luigi Rizzo To: Daniel Kalchev Message-ID: <20111205222834.GA50285@onelab2.iet.unipi.it> References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:12:29 -0000 On Mon, Dec 05, 2011 at 11:15:09PM +0200, Daniel Kalchev wrote: > > On Dec 5, 2011, at 9:27 PM, Luigi Rizzo wrote: > > > - have two machines connected by a 10G link > > - on one run "nuttcp -S" > > - on the other one run "nuttcp -t -T 5 -w 128 -v the.other.ip" > > > > Any particular tuning of FreeBSD? actually my point is first to see how good or bad are the defaults. I have noticed that setting hw.ixgbe.max_interrupt_rate=0 (it is a tunable, you need to do it before loading the module) improves the throughput by a fair amount (but still way below line rate with 1500 byte packets). other things (larger windows) don't seem to help much. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 22:15:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 616261065672 for ; Mon, 5 Dec 2011 22:15:39 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BAE518FC1A for ; Mon, 5 Dec 2011 22:15:38 +0000 (UTC) Received: by bkat2 with SMTP id t2so8862215bka.13 for ; Mon, 05 Dec 2011 14:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=3aw9gP+inVNT3Tushf4zu3hzvuqUt3/yFA7szWbdK20=; b=vZGWSTZ4VLJ+CvG8d8+ndRgcWQ6Dvki5wlZuVIMSokXrpwGmR54IuT+HWmzbdVMkQF tJc5gTdnfaaJPTjrXKmIW/ervjImxCkwoJs5ld6M5XvGMEY6C9n69PuLhU/W5hOE81JM 2VPCyRjDcbe4VTRRnPoIvsi4Mvcuk0l6uFdvw= MIME-Version: 1.0 Received: by 10.216.1.68 with SMTP id 46mr1034517wec.23.1323123337562; Mon, 05 Dec 2011 14:15:37 -0800 (PST) Received: by 10.180.94.2 with HTTP; Mon, 5 Dec 2011 14:15:37 -0800 (PST) Date: Mon, 5 Dec 2011 17:15:37 -0500 Message-ID: From: Arnaud Lacombe To: FreeBSD-Current , re@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: PAE broken on -current, likely broken on stable/9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:15:39 -0000 Hi, The kernel tree is utterly broken when PAE is enabled, it chokes [non-exclusively] on the following: dev/dpt/dpt_scsi.c:279: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev/dpt/dpt_scsi.c:279: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev/dpt/dpt_scsi.c:964: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dev/ida/ida.c:145: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dev/ida/ida.c:145: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dev/ida/ida.c:154: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dev/ida/ida.c:154: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev/ida/ida_eisa.c:105: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dev/ida/ida_eisa.c:106: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type [-Woverflow] dev/malo/if_malo_pci.c:232: warning: large integer implicitly truncated to unsigned type [-Woverflow] dev/mwl/if_mwl_pci.c:210: warning: large integer implicitly truncated to unsigned type [-Woverflow] dev/mwl/if_mwl_pci.c:210: warning: large integer implicitly truncated to unsigned type [-Woverflow] dev/sym/sym_hipd.c:7922: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dev/trm/trm.c:648: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dev/hptmv/entry.c:2635: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev/hptmv/entry.c:2765: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev/hptmv/entry.c:2970: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Could re@ please includes, proudly (or not), in its future announces, that PAE is no longer supported ? Thanks, - Arnaud ps: this is just a report, I'm not really expecting anything, any longer, from the FreebSD "community". From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 22:23:12 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A447A1065670; Mon, 5 Dec 2011 22:23:12 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 6775C8FC0A; Mon, 5 Dec 2011 22:23:12 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id F0952290FC5; Mon, 5 Dec 2011 16:23:10 -0600 (CST) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 14C15290F40; Mon, 5 Dec 2011 16:23:10 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id j8MDXWYX3H-u; Mon, 5 Dec 2011 16:23:09 -0600 (CST) Received: from [10.74.20.46] (staff-74-dun20-046.rice.edu [10.74.20.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id C0D88290FE3; Mon, 5 Dec 2011 16:23:04 -0600 (CST) Message-ID: <4EDD442C.9030406@rice.edu> Date: Mon, 05 Dec 2011 16:22:36 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> In-Reply-To: <4EDD3F60.8050601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:23:12 -0000 On 12/5/2011 4:02 PM, Andriy Gapon wrote: > on 05/12/2011 19:58 Alan Cox said the following: >> On 12/05/2011 07:56, Andriy Gapon wrote: >>> Pages should be marked busy only for some special occasions, wired pages are not >>> normally busy; the correct explanation is quite a bit longer than this, the >>> comment in the code explains VPO_BUSY as "page is in transit". Right now this >>> flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some >>> parts of code that are incorrect now are re-implemented properly: >>> http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 >> VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From >> the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): >> >> * VM_ALLOC_NOOBJ page is not associated with an object and >> * should not have the flag VPO_BUSY set > Ah, oops, forgot about this. > >> With regard to the message that the above link points to, I suspect that the >> introduction of vm_page_alloc_contig() can be used to address the first problem >> that you point out. Specifically, one or more OBJT_PHYS vm objects could be >> created and passed to vm_map_find() and then vm_page_alloc_contig() could be >> used to fill these vm objects with memory. > That's exactly what I was trying to do when I encountered a need for > VM_ALLOC_NOOBJ - my object was not NULL. > Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a > user map (or a few of them) at the same time? > Yes, it is. Alan From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 22:38:26 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13356106566C; Mon, 5 Dec 2011 22:38:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E7FBB8FC08; Mon, 5 Dec 2011 22:38:24 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA19986; Tue, 06 Dec 2011 00:38:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXhAr-000LM2-0D; Tue, 06 Dec 2011 00:38:13 +0200 Message-ID: <4EDD47D3.5010803@FreeBSD.org> Date: Tue, 06 Dec 2011 00:38:11 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Cox References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> In-Reply-To: <4EDD442C.9030406@rice.edu> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:38:26 -0000 on 06/12/2011 00:22 Alan Cox said the following: > On 12/5/2011 4:02 PM, Andriy Gapon wrote: >> on 05/12/2011 19:58 Alan Cox said the following: >>> On 12/05/2011 07:56, Andriy Gapon wrote: >>>> Pages should be marked busy only for some special occasions, wired pages are >>>> not >>>> normally busy; the correct explanation is quite a bit longer than this, the >>>> comment in the code explains VPO_BUSY as "page is in transit". Right now this >>>> flag doesn't seem tom affect vboxdrv code but it may lead to surprises when >>>> some >>>> parts of code that are incorrect now are re-implemented properly: >>>> http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 >>> VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From >>> the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): >>> >>> * VM_ALLOC_NOOBJ page is not associated with an object and >>> * should not have the flag VPO_BUSY set >> Ah, oops, forgot about this. >> >>> With regard to the message that the above link points to, I suspect that the >>> introduction of vm_page_alloc_contig() can be used to address the first problem >>> that you point out. Specifically, one or more OBJT_PHYS vm objects could be >>> created and passed to vm_map_find() and then vm_page_alloc_contig() could be >>> used to fill these vm objects with memory. >> That's exactly what I was trying to do when I encountered a need for >> VM_ALLOC_NOOBJ - my object was not NULL. >> Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a >> user map (or a few of them) at the same time? >> > > Yes, it is. Thank you! And another question - what would you recommend as a substitute for vm_page_alloc_contig in FreeBSD versions that do not have it? All I can think of is essentially replicating kmem_alloc_contig + contigmapping and allowing a user-specified object to be used in place of kernel_object. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 22:46:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD7CD1065672; Mon, 5 Dec 2011 22:46:43 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id B2C488FC16; Mon, 5 Dec 2011 22:46:43 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6E5C43BF6; Mon, 5 Dec 2011 14:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1323125203; bh=XPdmb8jCvpMVEuQ0k+xJ4ZqTMiTk1R4pY2eIH1HQD7I=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ouiigY06GPDks/Vrz/PJxDxlIA+j4BpEYXXAq55tJEek6wBKDNxP0zfnsDpeBZexu UZ/VViODZOf7M/cLTk3k0yti1mIY1myENX78vWKN+jzNTnNF4PZu4dLM8lTFC0apJe nBjAU4Y46URTASefWdNZWyRY+0pW8lomZ758BkWY= Message-ID: <4EDD49D2.7080603@delphij.net> Date: Mon, 05 Dec 2011 14:46:42 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: d@delphij.net, FreeBSD-Current , re@freebsd.org Subject: Re: PAE broken on -current, likely broken on stable/9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:46:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/11 14:15, Arnaud Lacombe wrote: > Hi, > > The kernel tree is utterly broken when PAE is enabled, it chokes > [non-exclusively] on the following: > > dev/dpt/dpt_scsi.c:279: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] [snip] [delphij@build] /usr/src/sys/i386/conf> grep dpt PAE nodevice dpt It seems you have added 'option PAE' in your own custom kernel configuration? Not all drivers works with PAE so these has to be removed. If PAE is a requirement, consider using the stock 'PAE' kernel configuration if you don't want to configure it the hard way. > Could re@ please includes, proudly (or not), in its future > announces, that PAE is no longer supported ? > > Thanks, - Arnaud > > ps: this is just a report, I'm not really expecting anything, any > longer, from the FreebSD "community". > _______________________________________________ > 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" - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dSdIACgkQOfuToMruuMAT/wCggYzwl1LSt8rYqaRaRjwAWXtO 8fsAn1d5rctjsdMSY15cVG/eAM3rdPnB =n6sn -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 23:14:57 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 684D41065676 for ; Mon, 5 Dec 2011 23:14:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2445F8FC14 for ; Mon, 5 Dec 2011 23:14:56 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 569C97300A; Tue, 6 Dec 2011 00:31:01 +0100 (CET) Date: Tue, 6 Dec 2011 00:31:01 +0100 From: Luigi Rizzo To: Jack Vogel Message-ID: <20111205233101.GB50697@onelab2.iet.unipi.it> References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, Daniel Kalchev Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:14:57 -0000 On Mon, Dec 05, 2011 at 03:08:54PM -0800, Jack Vogel wrote: > You can't get line rate with ixgbe, in what configuration/hardware? > We surely do get line rate in validation here, but its sensitive to > your hardware and config. sources from HEAD as of a week or so, default parameter setting, 82599 on an Intel dual port 10G card, Intel i7-870 CPU (4 cores) at 2.93 GHz, on asus MB and the card on a PCIe-x16 slot, MTU=1500 bytes. Same hardware, same defaults and nuttcp on linux does 8.5 Gbit/s. I can do line rate with a single flow if i use MTU=9000 and set max_interrupt_rate=0 (even reducing the CPU speed to 1.2 GHz). I can saturate the link with multiple flows (say nuttcp -N 8). cheers luigi > Jack > > > On Mon, Dec 5, 2011 at 2:28 PM, Luigi Rizzo wrote: > > > On Mon, Dec 05, 2011 at 11:15:09PM +0200, Daniel Kalchev wrote: > > > > > > On Dec 5, 2011, at 9:27 PM, Luigi Rizzo wrote: > > > > > > > - have two machines connected by a 10G link > > > > - on one run "nuttcp -S" > > > > - on the other one run "nuttcp -t -T 5 -w 128 -v the.other.ip" > > > > > > > > > > Any particular tuning of FreeBSD? > > > > actually my point is first to see how good or bad are the defaults. > > > > I have noticed that setting hw.ixgbe.max_interrupt_rate=0 > > (it is a tunable, you need to do it before loading the module) > > improves the throughput by a fair amount (but still way below > > line rate with 1500 byte packets). > > > > other things (larger windows) don't seem to help much. > > > > cheers > > luigi > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 23:39:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF3B5106564A for ; Mon, 5 Dec 2011 23:39:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 669798FC0A for ; Mon, 5 Dec 2011 23:39:18 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so7026967vbb.13 for ; Mon, 05 Dec 2011 15:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=szAWm4Jgua4tczI/FOExzBn/SooBDPZn/XChmyNWHAg=; b=PXv3C1aUdp0FhcC0j9IVa2y+ImV2cvhdmNS2JE3WFTCdKommh6Ust6CvvZzuRkgoLG SnOzJhC43h4evF4X0S/pTQQWj1aw7TVAgfz5P5eTJ5qavDJNUFEVBAS3iNduw8XV5cj2 +AXrVQWTnlpyBhtzcy9qdsOPYJAnsSBZJzprM= MIME-Version: 1.0 Received: by 10.52.99.161 with SMTP id er1mr6340456vdb.50.1323126534436; Mon, 05 Dec 2011 15:08:54 -0800 (PST) Received: by 10.220.224.197 with HTTP; Mon, 5 Dec 2011 15:08:54 -0800 (PST) In-Reply-To: <20111205222834.GA50285@onelab2.iet.unipi.it> References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> Date: Mon, 5 Dec 2011 15:08:54 -0800 Message-ID: From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org, Daniel Kalchev Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:39:18 -0000 You can't get line rate with ixgbe, in what configuration/hardware? We surely do get line rate in validation here, but its sensitive to your hardware and config. Jack On Mon, Dec 5, 2011 at 2:28 PM, Luigi Rizzo wrote: > On Mon, Dec 05, 2011 at 11:15:09PM +0200, Daniel Kalchev wrote: > > > > On Dec 5, 2011, at 9:27 PM, Luigi Rizzo wrote: > > > > > - have two machines connected by a 10G link > > > - on one run "nuttcp -S" > > > - on the other one run "nuttcp -t -T 5 -w 128 -v the.other.ip" > > > > > > > Any particular tuning of FreeBSD? > > actually my point is first to see how good or bad are the defaults. > > I have noticed that setting hw.ixgbe.max_interrupt_rate=0 > (it is a tunable, you need to do it before loading the module) > improves the throughput by a fair amount (but still way below > line rate with 1500 byte packets). > > other things (larger windows) don't seem to help much. > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 00:08:38 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7208C106566B; Tue, 6 Dec 2011 00:08:38 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh4.mail.rice.edu (mh4.mail.rice.edu [128.42.199.11]) by mx1.freebsd.org (Postfix) with ESMTP id 344118FC14; Tue, 6 Dec 2011 00:08:38 +0000 (UTC) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 6BF6A291A37; Mon, 5 Dec 2011 18:08:37 -0600 (CST) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 4FDBD2975CD; Mon, 5 Dec 2011 18:08:37 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh4.mail.rice.edu, auth channel Received: from mh4.mail.rice.edu ([127.0.0.1]) by mh4.mail.rice.edu (mh4.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id ZoiKUXfB7LFa; Mon, 5 Dec 2011 18:08:37 -0600 (CST) Received: from [10.74.20.46] (staff-74-dun20-046.rice.edu [10.74.20.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh4.mail.rice.edu (Postfix) with ESMTPSA id D3F1D291A32; Mon, 5 Dec 2011 18:08:36 -0600 (CST) Message-ID: <4EDD5CEB.1020502@rice.edu> Date: Mon, 05 Dec 2011 18:08:11 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> In-Reply-To: <4EDD47D3.5010803@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 00:08:38 -0000 On 12/5/2011 4:38 PM, Andriy Gapon wrote: > on 06/12/2011 00:22 Alan Cox said the following: >> On 12/5/2011 4:02 PM, Andriy Gapon wrote: >>> on 05/12/2011 19:58 Alan Cox said the following: >>>> On 12/05/2011 07:56, Andriy Gapon wrote: >>>>> Pages should be marked busy only for some special occasions, wired pages are >>>>> not >>>>> normally busy; the correct explanation is quite a bit longer than this, the >>>>> comment in the code explains VPO_BUSY as "page is in transit". Right now this >>>>> flag doesn't seem tom affect vboxdrv code but it may lead to surprises when >>>>> some >>>>> parts of code that are incorrect now are re-implemented properly: >>>>> http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297 >>>> VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From >>>> the comment at the head of both vm_page_alloc() and vm_page_alloc_contig(): >>>> >>>> * VM_ALLOC_NOOBJ page is not associated with an object and >>>> * should not have the flag VPO_BUSY set >>> Ah, oops, forgot about this. >>> >>>> With regard to the message that the above link points to, I suspect that the >>>> introduction of vm_page_alloc_contig() can be used to address the first problem >>>> that you point out. Specifically, one or more OBJT_PHYS vm objects could be >>>> created and passed to vm_map_find() and then vm_page_alloc_contig() could be >>>> used to fill these vm objects with memory. >>> That's exactly what I was trying to do when I encountered a need for >>> VM_ALLOC_NOOBJ - my object was not NULL. >>> Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a >>> user map (or a few of them) at the same time? >>> >> Yes, it is. > Thank you! And another question - what would you recommend as a substitute for > vm_page_alloc_contig in FreeBSD versions that do not have it? All I can think > of is essentially replicating kmem_alloc_contig + contigmapping and allowing a > user-specified object to be used in place of kernel_object. > The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that hard to merge it. Alan From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 01:36:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BEC106566B; Tue, 6 Dec 2011 01:36:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 705AE8FC0A; Tue, 6 Dec 2011 01:36:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEABtx3U6DaFvO/2dsb2JhbABEFoRvpkSBcgEBAQMBAQEBIAQnIAsbGBEZAgQlAQkmBggHBAEcBIdmCKMIkX+KC4EWBIgthWGELYIhiRCJJg X-IronPort-AV: E=Sophos;i="4.71,302,1320642000"; d="scan'208";a="146907470" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Dec 2011 20:36:28 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 49612B3FBD; Mon, 5 Dec 2011 20:36:28 -0500 (EST) Date: Mon, 5 Dec 2011 20:36:28 -0500 (EST) From: Rick Macklem To: John Message-ID: <1318843827.953380.1323135388258.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110825203151.GA61776@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_953379_5444943.1323135388257" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: F_RDLCK lock to FreeBSD NFS server fails to R/O target file [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 01:36:30 -0000 ------=_Part_953379_5444943.1323135388257 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit John wrote: > After pondering the best way to allow the VOP_ACCESS() call to > only query for the permissions really needed, I've come up with > a patch that minimally adds one parameter to the nlm_get_vfs_state() > function call with the lock type from the original argp. > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.accmode.patch > > I'd appreciate a review and seeing what might be required to commit > this prior to 9 release. > > Thanks, > John > > ----- John's Original Message ----- > > Hi Fellow NFS'ers, > > > > I believe I have found the problem we've been having with read > > locks > > while attaching to a FreeBSD NFS server. > > > > In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there > > is a call > > to VOP_ACCESS() as follows: > > > > /* > > * Check cred. > > */ > > NLM_DEBUG(3, "nlm_get_vfs_state(): Calling > > VOP_ACCESS(VWRITE) with cred->cr_uid=%d\n",cred->cr_uid); > > error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread); > > if (error) { > > NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s > > VOP_ACCESS() returns %d\n", > > host->nh_caller_name, error); > > goto out; > > } > > > > The file being accessed is read only to the user, and open()ed > > with > > O_RDONLY. The lock being requested is for a read. > > > > fd = open(filename, O_RDONLY, 0); > > ... > > > > lblk.l_type = F_RDLCK; > > lblk.l_start = 0; > > lblk.l_whence= SEEK_SET; > > lblk.l_len = 0; > > lblk.l_pid = 0; > > rc = fcntl(fd, F_SETLK, &lblk); > > > > Running the above from a remote system, the lock call fails with > > errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is > > my uid on the remote system. Since the file is R/O to me, and the > > VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES, > > Permission denied. > > > > The above operations work correctly to some of our other > > favorite big-name nfs vendors :-) > > > > Opinions on the "correct" way to fix this? > > > > 1. Since we're only asking for a read lock, why do we need to ask > > for VWRITE? I may not understand an underlying requirement for > > the VWRITE so please feel free to educate me if needed. > > > > Something like: request == F_RDLCK ? VREAD : VWRITE > > (need to figure out where to get the request from in this > > context). > > > > 2. Attempt VWRITE, fallback to VREAD... seems off to me though. > > I think I prefer this approach because it will never fail unless it would fail without the patch. For the case where the client uid has write but not read permission and attempts an F_RDLCK, I believe your patch would fail the request whereas it will succeed without your patch. (Although I'll admit I didn't actually test this.;-) Doing VOP_ACCESS(..VWRITE..) first and only doing a VOP_ACCESS(..VREAD..) if the VOP_ACCESS(..VWRITE..) fails will preserve current behaviour fot the non-failing case, but allow an F_RDLCK for uids with read-only access. I've attached a patch that does this variant. John, could you test this patch? And does anyone have an opinion w.r.t. which variant of the patch is more appropriate? Thanks in advance for your help, rick > > 3. Other? > > > > I appreciate any thoughts on this. > > > > Thanks, > > John > > > > While they might not follow style(9) completely, I've uploaded > > my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added. > > I'd appreciate it if someone would consider committing them so > > who ever debugs this file next will have them available. > > > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" ------=_Part_953379_5444943.1323135388257 Content-Type: text/x-patch; name=nlmrlock.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nlmrlock.patch LS0tIG5sbS9ubG1fcHJvdF9pbXBsLmMuc2F2CTIwMTEtMTItMDUgMTA6NTk6MDAuMDAwMDAwMDAw IC0wNTAwCisrKyBubG0vbmxtX3Byb3RfaW1wbC5jCTIwMTEtMTItMDUgMjA6MDk6MDMuMDAwMDAw MDAwIC0wNTAwCkBAIC0xNzc0LDcgKzE3NzQsNyBAQCBzdHJ1Y3QgdmZzX3N0YXRlIHsKIAogc3Rh dGljIGludAogbmxtX2dldF92ZnNfc3RhdGUoc3RydWN0IG5sbV9ob3N0ICpob3N0LCBzdHJ1Y3Qg c3ZjX3JlcSAqcnFzdHAsCi0gICAgZmhhbmRsZV90ICpmaHAsIHN0cnVjdCB2ZnNfc3RhdGUgKnZz KQorICAgIGZoYW5kbGVfdCAqZmhwLCBzdHJ1Y3QgdmZzX3N0YXRlICp2cywgYm9vbF90IGV4Y2x1 c2l2ZSkKIHsKIAlpbnQgZXJyb3IsIGV4ZmxhZ3M7CiAJc3RydWN0IHVjcmVkICpjcmVkID0gTlVM TCwgKmNyZWRhbm9uOwpAQCAtMTgxNiw2ICsxODE2LDggQEAgbmxtX2dldF92ZnNfc3RhdGUoc3Ry dWN0IG5sbV9ob3N0ICpob3N0LAogCSAqIENoZWNrIGNyZWQuCiAJICovCiAJZXJyb3IgPSBWT1Bf QUNDRVNTKHZzLT52c192cCwgVldSSVRFLCBjcmVkLCBjdXJ0aHJlYWQpOworCWlmIChlcnJvciAh PSAwICYmICFleGNsdXNpdmUpCisJCWVycm9yID0gVk9QX0FDQ0VTUyh2cy0+dnNfdnAsIFZSRUFE LCBjcmVkLCBjdXJ0aHJlYWQpOwogCWlmIChlcnJvcikKIAkJZ290byBvdXQ7CiAKQEAgLTE4OTYs NyArMTg5OCw3IEBAIG5sbV9kb190ZXN0KG5sbTRfdGVzdGFyZ3MgKmFyZ3AsIG5sbTRfdGUKIAkJ Z290byBvdXQ7CiAJfQogCi0JZXJyb3IgPSBubG1fZ2V0X3Zmc19zdGF0ZShob3N0LCBycXN0cCwg JmZoLCAmdnMpOworCWVycm9yID0gbmxtX2dldF92ZnNfc3RhdGUoaG9zdCwgcnFzdHAsICZmaCwg JnZzLCBhcmdwLT5leGNsdXNpdmUpOwogCWlmIChlcnJvcikgewogCQlyZXN1bHQtPnN0YXQuc3Rh dCA9IG5sbV9jb252ZXJ0X2Vycm9yKGVycm9yKTsKIAkJZ290byBvdXQ7CkBAIC0yMDAxLDcgKzIw MDMsNyBAQCBubG1fZG9fbG9jayhubG00X2xvY2thcmdzICphcmdwLCBubG00X3JlCiAJCWdvdG8g b3V0OwogCX0KIAotCWVycm9yID0gbmxtX2dldF92ZnNfc3RhdGUoaG9zdCwgcnFzdHAsICZmaCwg JnZzKTsKKwllcnJvciA9IG5sbV9nZXRfdmZzX3N0YXRlKGhvc3QsIHJxc3RwLCAmZmgsICZ2cywg YXJncC0+ZXhjbHVzaXZlKTsKIAlpZiAoZXJyb3IpIHsKIAkJcmVzdWx0LT5zdGF0LnN0YXQgPSBu bG1fY29udmVydF9lcnJvcihlcnJvcik7CiAJCWdvdG8gb3V0OwpAQCAtMjE4MCw3ICsyMTgyLDcg QEAgbmxtX2RvX2NhbmNlbChubG00X2NhbmNhcmdzICphcmdwLCBubG00XwogCQlnb3RvIG91dDsK IAl9CiAKLQllcnJvciA9IG5sbV9nZXRfdmZzX3N0YXRlKGhvc3QsIHJxc3RwLCAmZmgsICZ2cyk7 CisJZXJyb3IgPSBubG1fZ2V0X3Zmc19zdGF0ZShob3N0LCBycXN0cCwgJmZoLCAmdnMsIGFyZ3At PmV4Y2x1c2l2ZSk7CiAJaWYgKGVycm9yKSB7CiAJCXJlc3VsdC0+c3RhdC5zdGF0ID0gbmxtX2Nv bnZlcnRfZXJyb3IoZXJyb3IpOwogCQlnb3RvIG91dDsKQEAgLTIyNjksNyArMjI3MSwxMSBAQCBu bG1fZG9fdW5sb2NrKG5sbTRfdW5sb2NrYXJncyAqYXJncCwgbmxtCiAJCWdvdG8gb3V0OwogCX0K IAotCWVycm9yID0gbmxtX2dldF92ZnNfc3RhdGUoaG9zdCwgcnFzdHAsICZmaCwgJnZzKTsKKwkv KgorCSAqIFNwZWNpZnkgRkFMU0Ugc28gdGhhdCBpdCB3aWxsIHRyeSB0aGUgY2FzZSB3aGVyZSB0 aGVyZSBpcworCSAqIFZSRUFEIGFjY2Vzcywgd2hlbiBWV1JJVEUgYWNjZXNzIGlzIGRlbmllZC4K KwkgKi8KKwllcnJvciA9IG5sbV9nZXRfdmZzX3N0YXRlKGhvc3QsIHJxc3RwLCAmZmgsICZ2cywg RkFMU0UpOwogCWlmIChlcnJvcikgewogCQlyZXN1bHQtPnN0YXQuc3RhdCA9IG5sbV9jb252ZXJ0 X2Vycm9yKGVycm9yKTsKIAkJZ290byBvdXQ7Cg== ------=_Part_953379_5444943.1323135388257-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 02:41:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B921065672; Tue, 6 Dec 2011 02:41:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3519A8FC1B; Tue, 6 Dec 2011 02:41:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAF2A3U6DaFvO/2dsb2JhbAA8CBaEb6ZFgXIBAQEDAQEBASAEJyALBRYYAgINGQIpAQkmBggHBAEcBIdmCKJ8kgSBMoZAghyBFgSILYoQgiGJEoko X-IronPort-AV: E=Sophos;i="4.71,302,1320642000"; d="scan'208";a="146912902" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Dec 2011 21:41:19 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 20411B3F09; Mon, 5 Dec 2011 21:41:19 -0500 (EST) Date: Mon, 5 Dec 2011 21:41:19 -0500 (EST) From: Rick Macklem To: John Message-ID: <904229020.955656.1323139279117.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110825203151.GA61776@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: F_RDLCK lock to FreeBSD NFS server fails to R/O target file (nasty little bug) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 02:41:20 -0000 John wrote: > After pondering the best way to allow the VOP_ACCESS() call to > only query for the permissions really needed, I've come up with > a patch that minimally adds one parameter to the nlm_get_vfs_state() > function call with the lock type from the original argp. > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.accmode.patch > > I'd appreciate a review and seeing what might be required to commit > this prior to 9 release. > Doing a little testing with your patch, I came across this nasty little bug. I have a little program that does the following: - opens a file read/write - waits for user input - does read and write locks (non overlapping byte ranges) - does an unlock of all bytes covered by the above locks I ran it as follows: - had a file on the NFSv3 mount point (which is using the NLM) not owned by the user running the above program, with file mode 0666 - the program opens the file read/write and waits for user input --> on the server, I did a "chmod 622 " - gave it user input, so it then did the above locks (with your patch, the read lock fails although the read lock works for the unpatched NLM and my variant of the patch) - it also does the unlock and doesn't complain of a failure. ---> The ugly bug is that, for your patch, the unlock has failed silently. If you subsequently try and write lock a byte range overlapping the write lock byte range above, the attempt fails, since it is still locked by the client. ---> I don't know of an easy way to get rid of that lock!!! (It persists after the client unmounts the NFS file system.) Cute, eh:-) Btw, I suspect you can get the unpatched code to fail the same way if you did a "chmod 600 " after the write lock, but before the unlock. I'm almost thinking that an unlock shouldn't do a VOP_ACCESS() of any kind, but since that isn't current behaviour??? rick > Thanks, > John > > ----- John's Original Message ----- > > Hi Fellow NFS'ers, > > > > I believe I have found the problem we've been having with read > > locks > > while attaching to a FreeBSD NFS server. > > > > In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there > > is a call > > to VOP_ACCESS() as follows: > > > > /* > > * Check cred. > > */ > > NLM_DEBUG(3, "nlm_get_vfs_state(): Calling > > VOP_ACCESS(VWRITE) with cred->cr_uid=%d\n",cred->cr_uid); > > error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread); > > if (error) { > > NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s > > VOP_ACCESS() returns %d\n", > > host->nh_caller_name, error); > > goto out; > > } > > > > The file being accessed is read only to the user, and open()ed > > with > > O_RDONLY. The lock being requested is for a read. > > > > fd = open(filename, O_RDONLY, 0); > > ... > > > > lblk.l_type = F_RDLCK; > > lblk.l_start = 0; > > lblk.l_whence= SEEK_SET; > > lblk.l_len = 0; > > lblk.l_pid = 0; > > rc = fcntl(fd, F_SETLK, &lblk); > > > > Running the above from a remote system, the lock call fails with > > errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is > > my uid on the remote system. Since the file is R/O to me, and the > > VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES, > > Permission denied. > > > > The above operations work correctly to some of our other > > favorite big-name nfs vendors :-) > > > > Opinions on the "correct" way to fix this? > > > > 1. Since we're only asking for a read lock, why do we need to ask > > for VWRITE? I may not understand an underlying requirement for > > the VWRITE so please feel free to educate me if needed. > > > > Something like: request == F_RDLCK ? VREAD : VWRITE > > (need to figure out where to get the request from in this > > context). > > > > 2. Attempt VWRITE, fallback to VREAD... seems off to me though. > > > > 3. Other? > > > > I appreciate any thoughts on this. > > > > Thanks, > > John > > > > While they might not follow style(9) completely, I've uploaded > > my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added. > > I'd appreciate it if someone would consider committing them so > > who ever debugs this file next will have them available. > > > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 04:12:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A78EF106566B; Tue, 6 Dec 2011 04:12:31 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 00D5A8FC12; Tue, 6 Dec 2011 04:12:30 +0000 (UTC) Received: by bkat2 with SMTP id t2so9397806bka.13 for ; Mon, 05 Dec 2011 20:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=cT2v6WNm72kU+spJw/SN63MbV0a3iuDPWWk0qNxuVqI=; b=AcCaLFrFtRYO5SB+ws+thf4pi+xSEHrOqv+PXvXz/gq29L5Hq4rqhtwYdGLvzezl0L Bxdy+keiy/ohU2TDLZN/0rfDJwwd9UWcglfecvKmVQhDvuDt+cbilY105LhTznh0NcJA I28JHvMN/SCVu6MgNoMRomgkiFbKB41HFP1+M= MIME-Version: 1.0 Received: by 10.180.108.114 with SMTP id hj18mr16270070wib.2.1323144749589; Mon, 05 Dec 2011 20:12:29 -0800 (PST) Received: by 10.180.94.2 with HTTP; Mon, 5 Dec 2011 20:12:29 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Dec 2011 23:12:29 -0500 Message-ID: From: Arnaud Lacombe To: FreeBSD-Current , re@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: PAE broken on -current, likely broken on stable/9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 04:12:31 -0000 Hi *, [I could have renamed the subject 1001 fancy ways to crash FreeBSD, but I'll avoid :)] On Mon, Dec 5, 2011 at 5:15 PM, Arnaud Lacombe wrote: > Hi, > > The kernel tree is utterly broken when PAE is enabled, it chokes > [non-exclusively] on the following: > After finally having been able to complete a build, the resulting kernel miserably panics on: real memory: 25769803776 (24576 MB) panic: kmem_suballoc: bad status return of 3 This was with the default value of `vm.kmem_size' and `vm.kmem_size_max'. I cannot find a good value for either of them. With 2GB of RAM and 9.0RC2 (the release kernel), 700MB of kmem boots fine. The same and 750MB of kmem chokes, when bringing up userland, on: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xbfc00000 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0d4baca stack pointer =3D 0x28:0xc520f9dc frame pointer =3D 0x28:0xc520fa14 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, IOPL =3D 0 current process =3D 1 (kernel) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0xc0a4b027 at kdb_backtrace+0x47 #1 0xc0a185f7 at panic+0x117 #2 0xc0d48a03 at trap_fatal+0x323 #3 0xc0d48abd at trap_pfault+0xad #4 0xc0d49845 at trap+0x465 #5 0xc0d3279c at calltrap+0x6 #6 0xc09e57a0 at exec_map_first_page+0x430 #7 0xc09e61fc at kern_execve+0x58c #8 0xc09e75bc at sys_execve+0x4c #9 0xc09cb372 at start_init+0x292 #10 0xc09ea8d7 at fork_exit+0x97 #11 0xc0d32814 at fork_trampoline+0x8 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort With 12GB of RAM and 700MB of kmem, chokes early on: CPU: QEMU Virtual CPU version 0.14.50 (2660.71-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x633 Family =3D 6 Model =3D 3 Stepp= ing =3D 3 Features=3D0x781abf9 Features2=3D0x80800001 real memory =3D 12884901888 (12288 MB) panic: kmem_suballoc: bad status return of 3 cpuid =3D 0 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 0 td 0xc068edb0 kdb_enter(c0603b0a,c0603b0a,c061fbb4,c08f6cbc,0,...) at kdb_enter+0x3a panic(c061fbb4,3,0,0,c06c3a54,...) at panic+0x134 kmem_suballoc(c0ba6000,c06c3a54,c06c3a58,90f8000,1,...) at kmem_suballoc+0x= 85 vm_ksubmap_init(c06c3a4c,0,3,3000,0,...) at vm_ksubmap_init+0xbc cpu_startup(0,8f0020,8f0020,8f0000,8fb000,...) at cpu_startup+0x27c mi_startup() at mi_startup+0xac begin() at begin+0x2c db> Reverting to the default value for `vm.kmem_size' and `vm.kmem_size_max', 4GB (and 6GB) of RAM, with a PAE-enabled -current kernel triggers an infinite loop of: CPU: QEMU Virtual CPU version 0.14.50 (2660.40-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x633 Family =3D 6 Model =3D 3 Stepp= ing =3D 3 Features=3D0x781abf9 Features2=3D0x80800001 real memory =3D 6442450944 (6144 MB) kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled [...] kernel trap 12 with interrupts disabled At this point, even FreeBSD 7.1 is better, as it goes at least up until: Copyright (c) 1992-2009 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 7.1-RELEASE-p13 #0: Mon Nov 21 17:23:05 UTC 2011 root@build:/freebsd/conf/PAE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: QEMU Virtual CPU version 0.14.50 (2660.26-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x633 Stepping =3D 3 Features=3D0x781abf9 Features2=3D0x80800001> real memory =3D 16642998272 (15872 MB) avail memory =3D 15784312832 (15053 MB) It hanged there for a while, I'm not sure if it's because the system is running on a VM with a disk-backed memory or another issue. I killed qemu at this point. 6GB was "fine" too. Coming back to -current, but now with `vm.kmem_size' and `vm.kmem_size_max' set to 512M, a 12G system boots: CPU: QEMU Virtual CPU version 0.14.50 (2660.39-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x633 Family =3D 6 Model =3D 3 Stepp= ing =3D 3 Features=3D0x781abf9 Features2=3D0x80800001 real memory =3D 12884901888 (12288 MB) avail memory =3D 12621688832 (12036 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard [...] up until right before multi-user, where it just directly reboot, without triggering any message: ada0: Previously was known as ad0 pass1 at ata1 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) Timecounter "TSC" frequency 2660388588 Hz quality 800 /boot/kernel/kernel data=3D0xc3e4ec+0xbda74 syms=3D[0x4+0xaff70+0x4+0xf1cd8= ] - ______ ____ _____ _____ | ____| | _ \ / ____| __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____) | |__| | | | | | | | || | | | |_| |_| \___|\___||____/|_____/|_____/ s` `.....---.......--.``` -/ Welcome to FreeBSD=CD=BB +o .--` /y:` +. yo`:. :o `+- 1. Boot [ENTER] y/ -/` -o/ 2. [Esc]ape to loader prompt .- ::/sy+:. 3. Reboot / `-- / The same kernel, build with KDB_TRACE, INVARIANTS, WITNESS and WITNESS_SKIPSPIN doesn't reboot: pass1 at ata1 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) Timecounter "TSC" frequency 2660386172 Hz quality 800 WARNING: WITNESS option enabled, expect reduced performance. Swap zone entries reduced from 121574 to 24014. Trying to mount root from ufs:/dev/ada0s1a [rw]... but spins there, certainly potentially again because of the disk-backed mem= ory. 4GB of RAM, with the same `vm.kmem_size' and `vm.kmem_size_max', triggers the same `kernel trap 12 with interrupts disabled' as previously described with the default value. 6GB of RAM self-reboot, even with the INVARIANTS/WITNESS kernel. 8GB and 10GB boots up until trying to mount root and spins. 14GB fails as described originally: CPU: QEMU Virtual CPU version 0.14.50 (2660.41-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x633 Family =3D 6 Model =3D 3 Stepp= ing =3D 3 Features=3D0x781abf9 Features2=3D0x80800001 real memory =3D 15032385536 (14336 MB) panic: kmem_suballoc: bad status return of 3 cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c060a019,59c,c0af6c5c,c03c6173,c0da605c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c063e31e,0,c062df08,c0af6cbc,0,...) at kdb_backtrace+0x2a panic(c062df08,3,0,0,c0af6d0c,...) at panic+0x117 kmem_suballoc(c0da6000,c0af6d0c,c0af6d08,10080c0,0,...) at kmem_suballoc+0x= 85 vm_ksubmap_init(c0830ccc,80000000,3,3800,0,...) at vm_ksubmap_init+0x17d cpu_startup(0,af0020,af0020,af0000,afb000,...) at cpu_startup+0x27c mi_startup() at mi_startup+0xac begin() at begin+0x2c - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 05:19:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E321065670 for ; Tue, 6 Dec 2011 05:19:25 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4B48FC14 for ; Tue, 6 Dec 2011 05:19:25 +0000 (UTC) Received: by faak28 with SMTP id k28so5435076faa.13 for ; Mon, 05 Dec 2011 21:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5udT9Ty9WkYb0rNnmrTTi1dp2hOG4epUSlvhdtRlmag=; b=iYQEHjPkq0qqnyJQsZqejES6J+bYeN7mhfo9PfB4oiMOMJCybe0dpo/8zGcDFF/tPF cpkrI43ApRNY8NhXGdAqMXquNdj7Zmlq29vznA3DOqzXhJjkdxqOtDnK+6w+lTrbKzCy lTgu+vztspGtp5DSgaEretQwmVztDH6yezpbU= MIME-Version: 1.0 Received: by 10.227.59.203 with SMTP id m11mr10114275wbh.18.1323148764207; Mon, 05 Dec 2011 21:19:24 -0800 (PST) Received: by 10.180.94.2 with HTTP; Mon, 5 Dec 2011 21:19:24 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Dec 2011 00:19:24 -0500 Message-ID: From: Arnaud Lacombe To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: PAE broken on -current, likely broken on stable/9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 05:19:26 -0000 Hi, On Mon, Dec 5, 2011 at 11:12 PM, Arnaud Lacombe wrote: > On Mon, Dec 5, 2011 at 5:15 PM, Arnaud Lacombe wrote: >> Hi, >> >> The kernel tree is utterly broken when PAE is enabled, it chokes >> [non-exclusively] on the following: >> > After finally having been able to complete a build, the resulting > kernel miserably panics on: > > real memory: 25769803776 (24576 MB) > panic: kmem_suballoc: bad status return of 3 > Just for the fun, after having fought for 8h for nearly nothing with FreeBSD, I thought it would be fair to give it a try with Linux, say the latest -rc, that is 3.2-rc3, with a snapshot of the upcoming openwrt. The result: root@OpenWrt:/# free total used free shared buffers Mem: 16628216 14864 16613352 0 236 -/+ buffers: 14628 16613588 Swap: 0 0 0 total time spent to get to userland: about 30 min. too easy... Let's give it a try with a system with 32GB of RAM: root@OpenWrt:/# free total used free shared buffers Mem: 33274356 17124 33257232 0 252 -/+ buffers: 16872 33257484 Swap: 0 0 0 d'oh! ok, I'm not entirely honest, tmpfs chocked: tmpfs: Bad value '1.70365e+10' for mount option 'size'. Let's give it a try with 60GB now: root@OpenWrt:/# free total used free shared buffers Mem: 62405104 17116 62387988 0 256 -/+ buffers: 16860 62388244 Swap: 0 0 0 damn... Linux' no fun... :-( - Arnaud ps: the kernel actually panic with the full 64GB of RAM, while mounting the filesystem. From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 06:43:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18595106566B for ; Tue, 6 Dec 2011 06:43:38 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id EBEFF8FC0A for ; Tue, 6 Dec 2011 06:43:37 +0000 (UTC) Received: by dakp5 with SMTP id p5so2476478dak.13 for ; Mon, 05 Dec 2011 22:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=nBGYUhOPQ39p+HyE0trL4dK9MdGKt/nMIdpPLC1oc4Y=; b=LWY5qE2Fg/YLf7DAKj3q2oLQo5/Z23ekVEzAsBOfSgNarX3ua7q+BiAx+Bqr9HRKKV SIGmZ2L8NlWRp4JsRjdSwlcRVvbzzQlVkl63VtwkVOszEfyLO5NdFy7HFCxQT/mRb+6S WE/PrxdFuJ1VxY9Rv8lmZRKd+vmV1iWZ1cIl0= MIME-Version: 1.0 Received: by 10.68.28.169 with SMTP id c9mr12476126pbh.30.1323152061631; Mon, 05 Dec 2011 22:14:21 -0800 (PST) Received: by 10.68.62.71 with HTTP; Mon, 5 Dec 2011 22:14:21 -0800 (PST) Date: Tue, 6 Dec 2011 09:14:21 +0300 Message-ID: From: KOT MATPOCKuH To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ZFS: i/o error all block copies unavailable Invalid format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 06:43:38 -0000 Hello all! On 24 nov I updated sources via csup to RELENG_9 (9.0-PRERELEASE). After make installboot I successfully booted to single user. But after make installworld system was fail to boot with message: ZFS: i/o error all block copies unavailable Invalid format status command shows status of all polls properly. root filesystem is not compressed. # zfsboottest /dev/gpt/rootdisk /dev/gpt/rootmirr pool: sunway config: NAME STATE sunway ONLINE mirror ONLINE gpt/rootdisk ONLINE gpt/rootmirr ONLINE Restore of old /boot/zfsloader was solved issue. Before I successfully updated 4 another systems with same sources level without any problems. My sys/boot/zfs/zfsimpl.c's version: 1.17.2.2 2011/11/19 10:49:03 Where may a root cause of problem? And how I can debug this problem? -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 07:20:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEBBD106566B for ; Tue, 6 Dec 2011 07:20:46 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5168FC14 for ; Tue, 6 Dec 2011 07:20:46 +0000 (UTC) Received: by bkat2 with SMTP id t2so9738330bka.13 for ; Mon, 05 Dec 2011 23:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=iGmIWswyEVLqiF+z2MC5lttC3JFVv0BunZpBzPmX3+A=; b=LCvP/srBE8bzQLPjHtVzqES9HAkvNbhwxLhKjre/ALkA53N+R1/n2+5G12JADaPDbR 94JC8zyn+MXucv4xELeSJYgbBiIiRofxsDVwLXqf9xFLl+DtKUDrunRsurUQdTyqi2PU Ez25EErW6YUuQSRc3436IPiMasuATJar4tGCw= Received: by 10.216.132.224 with SMTP id o74mr2499284wei.53.1323156045154; Mon, 05 Dec 2011 23:20:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.70.196 with HTTP; Mon, 5 Dec 2011 23:20:14 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Tue, 6 Dec 2011 02:20:14 -0500 Message-ID: To: "list, mailing" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Looking to start Testing 10-current on Vbox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 07:20:46 -0000 On Thu, Dec 1, 2011 at 1:01 PM, list, mailing wrote: > I'm looking to start testing 10 on my own. > > I went to: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ > Last update was 201107 Strange. > > Where do I get the Current snapshot of 10. =C2=A0(Or do I upgrade from 9.= 0-RC2)? You need up build from source. Information for doing so is available here: http://www.freebsd.org/doc/handbook/makeworld.html Sorry for my short email - but I should be asleep now ;) --=20 Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 07:25:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF744106564A for ; Tue, 6 Dec 2011 07:25:08 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B9DF48FC08 for ; Tue, 6 Dec 2011 07:25:08 +0000 (UTC) Received: by iafi7 with SMTP id i7so6354360iaf.13 for ; Mon, 05 Dec 2011 23:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x1e7BbMi157jFXfYTCPrZbQhbi99+IqCy78wNGaFOOU=; b=jt6/q6BRPrLZ+/KC7Boyi0TukCK8yI5sTmhxFk9BcQe87spTrtB/iA8h+AwXv5S9ma IkIfyqlQaENKGr7T/Ya1VCue4Do/Y8/y2CE2frbQi8Ffajv9adLT8/e/qTDER8uzUz5D k7hXOwXkEyVgp3xlp2U+Bof0tbnn/j0Yg+crI= MIME-Version: 1.0 Received: by 10.43.43.130 with SMTP id uc2mr13082866icb.35.1323156305933; Mon, 05 Dec 2011 23:25:05 -0800 (PST) Received: by 10.42.18.9 with HTTP; Mon, 5 Dec 2011 23:25:05 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Dec 2011 02:25:05 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Eitan Adler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "list, mailing" , freebsd-current@freebsd.org Subject: Re: Looking to start Testing 10-current on Vbox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 07:25:09 -0000 On Tue, Dec 6, 2011 at 2:20 AM, Eitan Adler wrote: > On Thu, Dec 1, 2011 at 1:01 PM, list, mailing wrote: > > I'm looking to start testing 10 on my own. > > > > I went to: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ > > Last update was 201107 > > Strange. > > > > > Where do I get the Current snapshot of 10. (Or do I upgrade from > 9.0-RC2)? > > You need up build from source. Information for doing so is available > here: http://www.freebsd.org/doc/handbook/makeworld.html > Sorry for my short email - but I should be asleep now ;) > > -- > Eitan Adler > http://pub.allbsd.org/FreeBSD-snapshots/ Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 07:36:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56C1A106564A for ; Tue, 6 Dec 2011 07:36:55 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE1A8FC13 for ; Tue, 6 Dec 2011 07:36:54 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2oX8drk2nmtZ6Ei2mfD X-RZG-CLASS-ID: mo05 Received: from [192.168.179.42] (hmbg-5f77cf11.pool.mediaWays.net [95.119.207.17]) by smtp.strato.de (cohen mo41) (RZmta 26.10 AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i053aenB673MU8 for ; Tue, 6 Dec 2011 08:36:48 +0100 (MET) Message-ID: <4EDDC60E.9060106@brockmann-consult.de> Date: Tue, 06 Dec 2011 08:36:46 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS: i/o error all block copies unavailable Invalid format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 07:36:55 -0000 Am 06.12.2011 07:14, schrieb KOT MATPOCKuH: > Hello all! > > On 24 nov I updated sources via csup to RELENG_9 (9.0-PRERELEASE). > After make installboot I successfully booted to single user. > But after make installworld system was fail to boot with message: > ZFS: i/o error all block copies unavailable > Invalid format > > status command shows status of all polls properly. > root filesystem is not compressed. > > # zfsboottest /dev/gpt/rootdisk /dev/gpt/rootmirr > pool: sunway > config: > > NAME STATE > sunway ONLINE > mirror ONLINE > gpt/rootdisk ONLINE > gpt/rootmirr ONLINE > > Restore of old /boot/zfsloader was solved issue. > Before I successfully updated 4 another systems with same sources > level without any problems. > > My sys/boot/zfs/zfsimpl.c's version: 1.17.2.2 2011/11/19 10:49:03 > > Where may a root cause of problem? And how I can debug this problem? > "Invalid format" sounds like the software doesn't understand the disks. Check your pool (software) version with: # zpool upgrade -v Check your pool (on disk) version with (I forget the exact command): # zpool get version sunway My guess is that you installed the latest zfs on the pool, but left the old version of the bootloader. ------------- To fix an unbootable zfs root where the disks are working fine or degrade, this is the general procedure. I don't know if it applies to your particular problem, but I am optimistic. In this example, I copied a usb disk called zrootusb to one called zrootusbcopy. Import the pool using altroot and cachefile. # zpool import -o altroot=/z -o cachefile=/tmp/zpool.cache zrootusbcopy Set mount points (/ is fine, don't need legacy... legacy is a hassle, needing to set it to / and back after umount every time you repair things) Since altroot is /z, the root will be at /z/; do not prepend /z in mountpoint. # zfs list | grep zrootusbcopy # zfs set mountpoint=/ zrootusbcopy (if you were copying a disk and wanted it to be bootable, this is the point when you would snapshot and zfs send, where the above is the newly created bootable copy) Make sure bootfs is set. zfs get bootfs zrootusbcopy zfs set bootfs=zrootusbcopy zrootusbcopy **Copy the cache file to the new pool's /boot/zfs cp /tmp/zpool.cache /z/boot/zfs/zpool.cache Verify that the /boot/loader.conf is correct (pool name), and zfs_load is there. vfs.root.mountfrom="zfs:zrootusbcopy" zfs_load="YES" If this is your only zfs: # zfs umount -a otherwise one at a time: # zfs umount zrootusbcopy/var/empty # zfs umount zrootusbcopy/usr/ ... or a script (bash, untested): #begin script for name in $(zfs list -H -o name | grep -E "^zrootusbcopy/"); do zfs umount $name done zfs umount zrootusbcopy #end script install bootloader (possibly the only step you actually needed). 1. Figure out what disks and partition number to put it on... I use: gpart show 2. Install. If it is a mirror, do 2 of these commands with different devices. gpart bootcode -b /z/boot/pmbr -p /z/boot/gptzfsboot -i Then do not export. Then reboot; try to boot your previously unbootable zfs root system. Here is a thread where I suggested this method to someone and it worked for him, although his error message was different. http://forums.freebsd.org/showthread.php?t=26789 From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 09:08:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC84106564A; Tue, 6 Dec 2011 09:08:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 92CB88FC13; Tue, 6 Dec 2011 09:08:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA29283; Tue, 06 Dec 2011 11:08:12 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXr0W-000O4u-Dg; Tue, 06 Dec 2011 11:08:12 +0200 Message-ID: <4EDDDB7A.4050604@FreeBSD.org> Date: Tue, 06 Dec 2011 11:08:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Cox References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> In-Reply-To: <4EDD5CEB.1020502@rice.edu> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 09:08:21 -0000 on 06/12/2011 02:08 Alan Cox said the following: > The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that > hard to merge it. Ah, but we want to be able to run virtualbox on the past releases too. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 09:40:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7F2106566B; Tue, 6 Dec 2011 09:40:37 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 37D5C8FC16; Tue, 6 Dec 2011 09:40:36 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 300627; Tue, 6 Dec 2011 10:40:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 06 Dec 2011 10:40:36 +0100 From: Bernhard Froehlich To: Andriy Gapon In-Reply-To: <4EDDDB7A.4050604@FreeBSD.org> References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> "<7c3c9505867f4528af276a571077b9ce@bluelife.at>" <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> <4EDDDB7A.4050604@FreeBSD.org> Message-ID: X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0202.4EDDE313.010B,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Alan Cox , freebsd-emulation@freebsd.org, FreeBSD current , Alan Cox Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 09:40:37 -0000 On 06.12.2011 10:08, Andriy Gapon wrote: > on 06/12/2011 02:08 Alan Cox said the following: >> The right thing to do is to MFC vm_page_alloc_contig(). It >> shouldn't be that >> hard to merge it. > > Ah, but we want to be able to run virtualbox on the past releases > too. Which releases are we talking about here? VirtualBox was always deprecating older FreeBSD releases much faster than our Security EOL so if we focus on latest 8.x and >= 9.0 I think it should be okay. We have already deprecated 7.x because of some other problems with the userland bits so we can forget about 7.x completely. What is left is 8.1 and 8.2 and both are EOL until mid 2012. So if is possible to get it merged in time for 8.3 and 9.1 (if needed) we should be fine. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 11:00:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A0B7106564A; Tue, 6 Dec 2011 11:00:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 194BF8FC14; Tue, 6 Dec 2011 11:00:42 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA02674; Tue, 06 Dec 2011 13:00:41 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXslN-000O91-6B; Tue, 06 Dec 2011 13:00:41 +0200 Message-ID: <4EDDF5D7.3080508@FreeBSD.org> Date: Tue, 06 Dec 2011 13:00:39 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Bernhard Froehlich References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> "<7c3c9505867f4528af276a571077b9ce@bluelife.at>" <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> <4EDDDB7A.4050604@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 11:00:44 -0000 on 06/12/2011 11:40 Bernhard Froehlich said the following: > On 06.12.2011 10:08, Andriy Gapon wrote: >> on 06/12/2011 02:08 Alan Cox said the following: >>> The right thing to do is to MFC vm_page_alloc_contig(). It shouldn't be that >>> hard to merge it. >> >> Ah, but we want to be able to run virtualbox on the past releases too. > > Which releases are we talking about here? VirtualBox was always deprecating > older FreeBSD releases much faster than our Security EOL so if we focus on latest > 8.x and >= 9.0 I think it should be okay. > > We have already deprecated 7.x because of some other problems with the userland > bits so we can forget about 7.x completely. What is left is 8.1 and 8.2 and both > are EOL until mid 2012. So if is possible to get it merged in time for 8.3 and > 9.1 (if needed) we should be fine. So we would just say "screw you" to people who stick to e.g. 8.2 at the moment? :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 11:06:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A91106564A for ; Tue, 6 Dec 2011 11:06:27 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 075C48FC08 for ; Tue, 6 Dec 2011 11:06:26 +0000 (UTC) Received: by ggnp1 with SMTP id p1so4509551ggn.13 for ; Tue, 06 Dec 2011 03:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jRFJTYZmoDB+Tv6JxkxD/NtqLnnGQriSe3WKJVNI8Ow=; b=xpjBn5CV7Dy3Sd0P9oK/jgrCMNUyAZfepULE1C0yYh1bU0oM685fbdOjKTAgKnzBeg PxNGJJem1plSjll6Gs8y9BwUcn+6yspDg2XK6lKh3luUFGdze3ENIX2K5aiycTQ9dpKu TbeunCnE34JRXYv64b6ZUlJpn6wvcFrlEAz+0= MIME-Version: 1.0 Received: by 10.68.28.169 with SMTP id c9mr14389116pbh.30.1323169586088; Tue, 06 Dec 2011 03:06:26 -0800 (PST) Received: by 10.68.62.71 with HTTP; Tue, 6 Dec 2011 03:06:25 -0800 (PST) In-Reply-To: <4EDDC60E.9060106@brockmann-consult.de> References: <4EDDC60E.9060106@brockmann-consult.de> Date: Tue, 6 Dec 2011 14:06:25 +0300 Message-ID: From: KOT MATPOCKuH To: Peter Maloney Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ZFS: i/o error all block copies unavailable Invalid format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 11:06:27 -0000 Hello! 2011/12/6 Peter Maloney : > "Invalid format" sounds like the software doesn't understand the disks. > Check your pool (software) version with: > # zpool upgrade -v zpool upgrade -v does not show pools, available for upgrade :) # zpool upgrade This system is currently running ZFS pool version 28. All pools are formatted using this version. > Check your pool (on disk) version with (I forget the exact command): > # zpool get version sunway NAME PROPERTY VALUE SOURCE sunway version 28 default It's latest pool's version for RELENG_9. > My guess is that you installed the latest zfs on the pool, but left the > old version of the bootloader. You mean gptzfsboot ? Old gptzfsboot must fail with message like this: ZFS: unsupported ZFS version %u (should be %u) And why problem solved by copying previous zfsloader? Without any another changes... -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 11:16:04 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABCA11065670; Tue, 6 Dec 2011 11:16:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EE8548FC08; Tue, 6 Dec 2011 11:16:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03006; Tue, 06 Dec 2011 13:14:40 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXsyu-000O9c-J2; Tue, 06 Dec 2011 13:14:40 +0200 Message-ID: <4EDDF91F.10308@FreeBSD.org> Date: Tue, 06 Dec 2011 13:14:39 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Cox , Bernhard Froehlich References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> <4EDDDB7A.4050604@FreeBSD.org> In-Reply-To: <4EDDDB7A.4050604@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , Konstantin Belousov , freebsd-emulation@FreeBSD.org, FreeBSD current , vbox@FreeBSD.org Subject: virtualbox r0 memory management update [Was: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 11:16:04 -0000 Meanwhile, here is the code that I came up with: http://people.freebsd.org/~avg/vbox/ For your convenience I have uploaded both the new file and its diff against svn head. I am testing this on FreeBSD head (r228017), so far no breakage observed. I would appreciate reviews and testing of this code. Especially testing with earlier FreeBSD releases. Thank you! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 11:18:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D7A106566B for ; Tue, 6 Dec 2011 11:18:27 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id F3CBA8FC13 for ; Tue, 6 Dec 2011 11:18:26 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pB6BICl1043842 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Dec 2011 13:18:18 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EDDF9F4.9070508@digsys.bg> Date: Tue, 06 Dec 2011 13:18:12 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> In-Reply-To: <20111205222834.GA50285@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 11:18:27 -0000 Here is what I get, with an existing install, no tuning other than kern.ipc.nmbclusters=512000 Pair of Supermicro blades: FreeBSD 8.2-STABLE #0: Wed Sep 28 11:23:59 EEST 2011 CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2403.58-MHz K8-class CPU) real memory = 51539607552 (49152 MB) [...] ix0: port 0xdc00-0xdc1f mem 0xfbc00000-0xfbdfffff,0xfbbfc000-0xfbbfffff irq 16 at device 0.0 on pci3 ix0: Using MSIX interrupts with 9 vectors ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: xx:xx:xx:xx:xx:xx ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ix1: port 0xd880-0xd89f mem 0xfb800000-0xfb9fffff,0xfbbf8000-0xfbbfbfff irq 17 at device 0.1 on pci3 ix1: Using MSIX interrupts with 9 vectors ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: Ethernet address: xx:xx:xx:xx:xx:xx ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 blade 1: # nuttcp -S # nuttcp -t -T 5 -w 128 -v localhost nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.044 ms nuttcp-t: send window size = 143360, receive window size = 71680 nuttcp-t: 8959.8750 MB in 5.02 real seconds = 1827635.67 KB/sec = 14971.9914 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 143358 I/O calls, msec/call = 0.04, calls/sec = 28556.81 nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 602maxrss 0+5pf 16+46csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 127.0.0.1 nuttcp-r: send window size = 43008, receive window size = 143360 nuttcp-r: 8959.8750 MB in 5.17 real seconds = 1773171.07 KB/sec = 14525.8174 Mbps nuttcp-r: 219708 I/O calls, msec/call = 0.02, calls/sec = 42461.43 nuttcp-r: 0.0user 3.8sys 0:05real 76% 105i+1407d 614maxrss 1+17pf 95059+22csw blade 2: # nuttcp -t -T 5 -w 128 -v 10.2.101.12 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.12 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.12 with mss=1448, RTT=0.059 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1340.6469 MB in 5.02 real seconds = 273449.90 KB/sec = 2240.1016 Mbps nuttcp-t: host-retrans = 171 nuttcp-t: 21451 I/O calls, msec/call = 0.24, calls/sec = 4272.78 nuttcp-t: 0.0user 1.9sys 0:05real 39% 120i+1610d 600maxrss 2+3pf 75658+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.11 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1340.6469 MB in 5.17 real seconds = 265292.92 KB/sec = 2173.2796 Mbps nuttcp-r: 408764 I/O calls, msec/call = 0.01, calls/sec = 78992.15 nuttcp-r: 0.0user 3.3sys 0:05real 64% 105i+1413d 620maxrss 0+15pf 105104+102csw Another pari of blades: FreeBSD 8.2-STABLE #0: Tue Aug 9 12:37:55 EEST 2011 CPU: AMD Opteron(tm) Processor 6134 (2300.04-MHz K8-class CPU) real memory = 68719476736 (65536 MB) [...] ix0: port 0xe400-0xe41f mem 0xfe600000-0xfe7fffff,0xfe4fc000-0xfe4fffff irq 19 at device 0.0 on pci3 ix0: Using MSIX interrupts with 9 vectors ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: xx:xx:xx:xx:xx:xx ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ix1: port 0xe800-0xe81f mem 0xfea00000-0xfebfffff,0xfe8fc000-0xfe8fffff irq 16 at device 0.1 on pci3 ix1: Using MSIX interrupts with 9 vectors ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: Ethernet address: xx:xx:xx:xx:xx:xx ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 first blade: # nuttcp -S # nuttcp -t -T 5 -w 128 -v localhost nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.090 ms nuttcp-t: send window size = 143360, receive window size = 71680 nuttcp-t: 2695.0625 MB in 5.00 real seconds = 551756.90 KB/sec = 4519.9925 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 43121 I/O calls, msec/call = 0.12, calls/sec = 8621.20 nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+4pf 2+71csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 127.0.0.1 nuttcp-r: send window size = 43008, receive window size = 143360 nuttcp-r: 2695.0625 MB in 5.14 real seconds = 536509.66 KB/sec = 4395.0871 Mbps nuttcp-r: 43126 I/O calls, msec/call = 0.12, calls/sec = 8383.94 nuttcp-r: 0.0user 3.1sys 0:05real 61% 94i+1264d 624maxrss 1+16pf 43019+0csw second blade: # nuttcp -t -T 5 -w 128 -v 10.2.101.13 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.13 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.13 with mss=1448, RTT=0.164 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1290.3750 MB in 5.00 real seconds = 264173.96 KB/sec = 2164.1131 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 20646 I/O calls, msec/call = 0.25, calls/sec = 4127.72 nuttcp-t: 0.0user 3.8sys 0:05real 77% 96i+1299d 616maxrss 0+3pf 27389+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.14 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1290.3750 MB in 5.14 real seconds = 256835.92 KB/sec = 2103.9998 Mbps nuttcp-r: 85668 I/O calls, msec/call = 0.06, calls/sec = 16651.70 nuttcp-r: 0.0user 4.8sys 0:05real 94% 107i+1437d 624maxrss 0+15pf 11848+0csw Not impresive... I am rebuilding now to -stable. Daniel From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 11:28:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F1F106566C for ; Tue, 6 Dec 2011 11:28:46 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7F28FC16 for ; Tue, 6 Dec 2011 11:28:44 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pB6BSXRa043914 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Dec 2011 13:28:39 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EDDFC61.5050400@digsys.bg> Date: Tue, 06 Dec 2011 13:28:33 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> In-Reply-To: <4EDDF9F4.9070508@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 11:28:46 -0000 On 06.12.11 13:18, Daniel Kalchev wrote: > [...] > second blade: > > # nuttcp -t -T 5 -w 128 -v 10.2.101.13 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.13 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.13 with mss=1448, RTT=0.164 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1290.3750 MB in 5.00 real seconds = 264173.96 KB/sec = > 2164.1131 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 20646 I/O calls, msec/call = 0.25, calls/sec = 4127.72 > nuttcp-t: 0.0user 3.8sys 0:05real 77% 96i+1299d 616maxrss 0+3pf > 27389+0csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.14 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1290.3750 MB in 5.14 real seconds = 256835.92 KB/sec = > 2103.9998 Mbps > nuttcp-r: 85668 I/O calls, msec/call = 0.06, calls/sec = 16651.70 > nuttcp-r: 0.0user 4.8sys 0:05real 94% 107i+1437d 624maxrss 0+15pf > 11848+0csw > > > Not impresive... I am rebuilding now to -stable. > > Daniel I also noticed interrupt storms happening while this was running on the second pair of blades: interrupt storm detected on "irq272:"; throttling interrupt source interrupt storm detected on "irq272:"; throttling interrupt source interrupt storm detected on "irq272:"; throttling interrupt source interrupt storm detected on "irq270:"; throttling interrupt source interrupt storm detected on "irq270:"; throttling interrupt source interrupt storm detected on "irq270:"; throttling interrupt source some stats # sysctl -a dev.ix.1 dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.3.10 dev.ix.1.%driver: ix dev.ix.1.%location: slot=0 function=1 dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fc subvendor=0xffff subdevice=0xffff class=0x020000 dev.ix.1.%parent: pci3 dev.ix.1.flow_control: 3 dev.ix.1.advertise_gig: 0 dev.ix.1.enable_aim: 1 dev.ix.1.rx_processing_limit: 128 dev.ix.1.dropped: 0 dev.ix.1.mbuf_defrag_failed: 0 dev.ix.1.no_tx_dma_setup: 0 dev.ix.1.watchdog_events: 0 dev.ix.1.tso_tx: 1193460 dev.ix.1.link_irq: 1 dev.ix.1.queue0.interrupt_rate: 1000000 dev.ix.1.queue0.txd_head: 45 dev.ix.1.queue0.txd_tail: 45 dev.ix.1.queue0.no_desc_avail: 0 dev.ix.1.queue0.tx_packets: 23 dev.ix.1.queue0.rxd_head: 16 dev.ix.1.queue0.rxd_tail: 15 dev.ix.1.queue0.rx_packets: 16 dev.ix.1.queue0.rx_bytes: 2029 dev.ix.1.queue0.lro_queued: 0 dev.ix.1.queue0.lro_flushed: 0 dev.ix.1.queue1.interrupt_rate: 62500 dev.ix.1.queue1.txd_head: 0 dev.ix.1.queue1.txd_tail: 0 dev.ix.1.queue1.no_desc_avail: 0 dev.ix.1.queue1.tx_packets: 0 dev.ix.1.queue1.rxd_head: 0 dev.ix.1.queue1.rxd_tail: 2047 dev.ix.1.queue1.rx_packets: 0 dev.ix.1.queue1.rx_bytes: 0 dev.ix.1.queue1.lro_queued: 0 dev.ix.1.queue1.lro_flushed: 0 dev.ix.1.queue2.interrupt_rate: 200000 dev.ix.1.queue2.txd_head: 545 dev.ix.1.queue2.txd_tail: 545 dev.ix.1.queue2.no_desc_avail: 0 dev.ix.1.queue2.tx_packets: 331690 dev.ix.1.queue2.rxd_head: 1099 dev.ix.1.queue2.rxd_tail: 1098 dev.ix.1.queue2.rx_packets: 498763 dev.ix.1.queue2.rx_bytes: 32954702 dev.ix.1.queue2.lro_queued: 0 dev.ix.1.queue2.lro_flushed: 0 dev.ix.1.queue3.interrupt_rate: 62500 dev.ix.1.queue3.txd_head: 0 dev.ix.1.queue3.txd_tail: 0 dev.ix.1.queue3.no_desc_avail: 0 dev.ix.1.queue3.tx_packets: 0 dev.ix.1.queue3.rxd_head: 0 dev.ix.1.queue3.rxd_tail: 2047 dev.ix.1.queue3.rx_packets: 0 dev.ix.1.queue3.rx_bytes: 0 dev.ix.1.queue3.lro_queued: 0 dev.ix.1.queue3.lro_flushed: 0 dev.ix.1.queue4.interrupt_rate: 1000000 dev.ix.1.queue4.txd_head: 13 dev.ix.1.queue4.txd_tail: 13 dev.ix.1.queue4.no_desc_avail: 0 dev.ix.1.queue4.tx_packets: 6 dev.ix.1.queue4.rxd_head: 6 dev.ix.1.queue4.rxd_tail: 5 dev.ix.1.queue4.rx_packets: 6 dev.ix.1.queue4.rx_bytes: 899 dev.ix.1.queue4.lro_queued: 0 dev.ix.1.queue4.lro_flushed: 0 dev.ix.1.queue5.interrupt_rate: 200000 dev.ix.1.queue5.txd_head: 982 dev.ix.1.queue5.txd_tail: 982 dev.ix.1.queue5.no_desc_avail: 0 dev.ix.1.queue5.tx_packets: 302592 dev.ix.1.queue5.rxd_head: 956 dev.ix.1.queue5.rxd_tail: 955 dev.ix.1.queue5.rx_packets: 474044 dev.ix.1.queue5.rx_bytes: 31319840 dev.ix.1.queue5.lro_queued: 0 dev.ix.1.queue5.lro_flushed: 0 dev.ix.1.queue6.interrupt_rate: 200000 dev.ix.1.queue6.txd_head: 1902 dev.ix.1.queue6.txd_tail: 1902 dev.ix.1.queue6.no_desc_avail: 0 dev.ix.1.queue6.tx_packets: 184922 dev.ix.1.queue6.rxd_head: 1410 dev.ix.1.queue6.rxd_tail: 1409 dev.ix.1.queue6.rx_packets: 402818 dev.ix.1.queue6.rx_bytes: 27759640 dev.ix.1.queue6.lro_queued: 0 dev.ix.1.queue6.lro_flushed: 0 dev.ix.1.queue7.interrupt_rate: 200000 dev.ix.1.queue7.txd_head: 660 dev.ix.1.queue7.txd_tail: 660 dev.ix.1.queue7.no_desc_avail: 0 dev.ix.1.queue7.tx_packets: 378078 dev.ix.1.queue7.rxd_head: 885 dev.ix.1.queue7.rxd_tail: 884 dev.ix.1.queue7.rx_packets: 705397 dev.ix.1.queue7.rx_bytes: 46572290 dev.ix.1.queue7.lro_queued: 0 dev.ix.1.queue7.lro_flushed: 0 dev.ix.1.mac_stats.crc_errs: 0 dev.ix.1.mac_stats.ill_errs: 0 dev.ix.1.mac_stats.byte_errs: 0 dev.ix.1.mac_stats.short_discards: 0 dev.ix.1.mac_stats.local_faults: 3 dev.ix.1.mac_stats.remote_faults: 1 dev.ix.1.mac_stats.rec_len_errs: 0 dev.ix.1.mac_stats.link_xon_txd: 0 dev.ix.1.mac_stats.link_xon_rcvd: 0 dev.ix.1.mac_stats.link_xoff_txd: 0 dev.ix.1.mac_stats.link_xoff_rcvd: 0 dev.ix.1.mac_stats.total_octets_rcvd: 146983578 dev.ix.1.mac_stats.good_octets_rcvd: 146933576 dev.ix.1.mac_stats.total_pkts_rcvd: 2081451 dev.ix.1.mac_stats.good_pkts_rcvd: 2081044 dev.ix.1.mac_stats.mcast_pkts_rcvd: 0 dev.ix.1.mac_stats.bcast_pkts_rcvd: 2 dev.ix.1.mac_stats.rx_frames_64: 4 dev.ix.1.mac_stats.rx_frames_65_127: 2081036 dev.ix.1.mac_stats.rx_frames_128_255: 0 dev.ix.1.mac_stats.rx_frames_256_511: 0 dev.ix.1.mac_stats.rx_frames_512_1023: 4 dev.ix.1.mac_stats.rx_frames_1024_1522: 0 dev.ix.1.mac_stats.recv_undersized: 0 dev.ix.1.mac_stats.recv_fragmented: 0 dev.ix.1.mac_stats.recv_oversized: 0 dev.ix.1.mac_stats.recv_jabberd: 0 dev.ix.1.mac_stats.management_pkts_rcvd: 0 dev.ix.1.mac_stats.management_pkts_drpd: 0 dev.ix.1.mac_stats.checksum_errs: 0 dev.ix.1.mac_stats.good_octets_txd: 4752616248 dev.ix.1.mac_stats.total_pkts_txd: 3302683 dev.ix.1.mac_stats.good_pkts_txd: 3302683 dev.ix.1.mac_stats.bcast_pkts_txd: 3 dev.ix.1.mac_stats.mcast_pkts_txd: 0 dev.ix.1.mac_stats.management_pkts_txd: 0 dev.ix.1.mac_stats.tx_frames_64: 3 dev.ix.1.mac_stats.tx_frames_65_127: 9203 dev.ix.1.mac_stats.tx_frames_128_255: 31588 dev.ix.1.mac_stats.tx_frames_256_511: 50179 dev.ix.1.mac_stats.tx_frames_512_1023: 153285 dev.ix.1.mac_stats.tx_frames_1024_1522: 3058425 dev.ix.1.mac_stats.fc_crc: 0 dev.ix.1.mac_stats.fc_last: 0 dev.ix.1.mac_stats.fc_drpd: 0 dev.ix.1.mac_stats.fc_pkts_rcvd: 0 dev.ix.1.mac_stats.fc_pkts_txd: 0 dev.ix.1.mac_stats.fc_dword_rcvd: 0 dev.ix.1.mac_stats.fc_dword_txd: 0 Maybe this controller needs some tuning? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 12:41:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7866106566C for ; Tue, 6 Dec 2011 12:41:49 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 238758FC0C for ; Tue, 6 Dec 2011 12:41:48 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LqrbD-1QuBsV0M0x-00egXp; Tue, 06 Dec 2011 13:41:48 +0100 Message-ID: <4EDE0D8B.6020201@brockmann-consult.de> Date: Tue, 06 Dec 2011 13:41:47 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EDDC60E.9060106@brockmann-consult.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:p1wWc5L+WgdH2saRnM6FWDcq/n+zfZr0ddISV6K2ooJ r++6eOdhCcyOXXJxGVdKl6fUZkupe9qqwPjLc47au9fLsMn/WD SuT4m3CVMy1ZT7EBCqq750Dz0kF4gB7L1zSjvjQOvWHzt1jPhG XFOCaakujN4AqyBXqriFPOpPBzJMOaYH530+eBhUlnqkQI9AI0 QRf5rq8fTexaEkn1tx3LYibwvfRHQFgVgro9ZFedIEUOQBC+0i LYZhD6iH7iYImzKNd5G2WU2wrI8mcHIMyi4jFYgkw/uBM7Ml2j i+hhHJTS/Hy2HON0Jbvx/1aJeLOEqBrVToY4F78Ix9xPgGrrNc 6ywY245Il3wObvF2LuhtqFozwLMkLjAHifYARA9Ra Subject: Re: ZFS: i/o error all block copies unavailable Invalid format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 12:41:49 -0000 On 12/06/2011 12:06 PM, KOT MATPOCKuH wrote: > Hello! > > 2011/12/6 Peter Maloney : > >> "Invalid format" sounds like the software doesn't understand the disks. >> Check your pool (software) version with: >> # zpool upgrade -v > zpool upgrade -v does not show pools, available for upgrade :) > > # zpool upgrade > This system is currently running ZFS pool version 28. > > All pools are formatted using this version. > >> Check your pool (on disk) version with (I forget the exact command): >> # zpool get version sunway > NAME PROPERTY VALUE SOURCE > sunway version 28 default > > It's latest pool's version for RELENG_9. > >> My guess is that you installed the latest zfs on the pool, but left the >> old version of the bootloader. > You mean gptzfsboot ? Yes. > Old gptzfsboot must fail with message like this: > ZFS: unsupported ZFS version %u (should be %u) > > And why problem solved by copying previous zfsloader? > Without any another changes... > previous zfsloader? Oh how interesting. I missed that in your last message. When you updated the other 4 systems "with same sources" did you mean the same cvsup file, or the exact copy of the source? I often see people posting about some mirrors updating later than others [I forget if this applies to current or stable or both], so I wouldn't trust them to have the same download each time, or a consistent download given a date unless it is a distant date. And just out of curiosity, how did you find the old bootloader? I probably wouldn't think to back it up if the new one compiled without error. Did you also try copying the bootloader (with dd maybe) from one of the working updated systems? Or comparing checksums of the bootloaders? -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 12:51:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B77F5106567D; Tue, 6 Dec 2011 12:51:50 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 3EDB48FC17; Tue, 6 Dec 2011 12:51:50 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 240689; Tue, 6 Dec 2011 13:52:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 06 Dec 2011 13:51:49 +0100 From: Bernhard Froehlich To: Andriy Gapon In-Reply-To: <4EDDF5D7.3080508@FreeBSD.org> References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> "<7c3c9505867f4528af276a571077b9ce@bluelife.at>" "<4EDCC1C6.3040109@FreeBSD.org>" <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> "<4EDDDB7A.4050604@FreeBSD.org>" <4EDDF5D7.3080508@FreeBSD.org> Message-ID: X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B020B.4EDE0FE4.021F,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: freebsd-emulation@freebsd.org, FreeBSD current , Bernhard Froehlich Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 12:51:50 -0000 On 06.12.2011 12:00, Andriy Gapon wrote: > on 06/12/2011 11:40 Bernhard Froehlich said the following: >> On 06.12.2011 10:08, Andriy Gapon wrote: >>> on 06/12/2011 02:08 Alan Cox said the following: >>>> The right thing to do is to MFC vm_page_alloc_contig(). It >>>> shouldn't be that >>>> hard to merge it. >>> >>> Ah, but we want to be able to run virtualbox on the past releases >>> too. >> >> Which releases are we talking about here? VirtualBox was always >> deprecating >> older FreeBSD releases much faster than our Security EOL so if we >> focus on latest >> 8.x and >= 9.0 I think it should be okay. >> >> We have already deprecated 7.x because of some other problems with >> the userland >> bits so we can forget about 7.x completely. What is left is 8.1 and >> 8.2 and both >> are EOL until mid 2012. So if is possible to get it merged in time >> for 8.3 and >> 9.1 (if needed) we should be fine. > > So we would just say "screw you" to people who stick to e.g. 8.2 at > the moment? :) No. We currently have the last 2 virtualbox major versions in the ports tree so if we decide to do such an incompatible change we always have the older version around for 8.2 users for about the next year. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 12:59:58 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B2FB1065670; Tue, 6 Dec 2011 12:59:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ECE2B8FC0A; Tue, 6 Dec 2011 12:59:56 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA05009; Tue, 06 Dec 2011 14:59:55 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXuck-000ODE-RU; Tue, 06 Dec 2011 14:59:54 +0200 Message-ID: <4EDE11C7.7030504@FreeBSD.org> Date: Tue, 06 Dec 2011 14:59:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Bernhard Froehlich References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> "<7c3c9505867f4528af276a571077b9ce@bluelife.at>" "<4EDCC1C6.3040109@FreeBSD.org>" <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> "<4EDDDB7A.4050604@FreeBSD.org>" <4EDDF5D7.3080508@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, FreeBSD current Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 12:59:58 -0000 on 06/12/2011 14:51 Bernhard Froehlich said the following: > > No. We currently have the last 2 virtualbox major versions in the ports tree so > if we decide to do such an incompatible change we always have the older version > around for 8.2 users for about the next year. Oh, I missed the fact that we have port versions for virtualbox ports. Sorry for the noise, then. Anyway, in patch I tried to cover different FreeBSD versions. One greater discrepancy between stable/8 and later version is the changes in page locking that have never been MFC-ed. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 13:41:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E57106564A for ; Tue, 6 Dec 2011 13:41:03 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id A957D8FC13 for ; Tue, 6 Dec 2011 13:41:03 +0000 (UTC) Received: by dakp5 with SMTP id p5so2940311dak.13 for ; Tue, 06 Dec 2011 05:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QP2P/JN/lssrqPzsXeGJsF5BGO8Vjb5mnSAFf7gUgnQ=; b=St4kMdwdl7phpXh9+Ibl/HpvonGmGYeubtxBAheuNx56aIrFmXbNuWYgetHQ2yPdve rXVJ353c5bLvbnBP4z/7xaU/n5O7JgybDPFYes/ooj4uRUlSwVwTV1hyiCq1iCxcmzme ZyHWZpeWzv0vd1yxQCo2K5CrfYawRosKhQ65w= MIME-Version: 1.0 Received: by 10.68.34.72 with SMTP id x8mr13303122pbi.81.1323178863093; Tue, 06 Dec 2011 05:41:03 -0800 (PST) Received: by 10.68.62.71 with HTTP; Tue, 6 Dec 2011 05:41:03 -0800 (PST) In-Reply-To: <4EDE0D8B.6020201@brockmann-consult.de> References: <4EDDC60E.9060106@brockmann-consult.de> <4EDE0D8B.6020201@brockmann-consult.de> Date: Tue, 6 Dec 2011 16:41:03 +0300 Message-ID: From: KOT MATPOCKuH To: Peter Maloney Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ZFS: i/o error all block copies unavailable Invalid format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 13:41:03 -0000 2011/12/6 Peter Maloney : >>> "Invalid format" sounds like the software doesn't understand the disks. >>> Check your pool (software) version with: >>> # zpool upgrade -v >> zpool upgrade -v does not show pools, available for upgrade :) >> >> # zpool upgrade >> This system is currently running ZFS pool version 28. >> >> All pools are formatted using this version. >> >>> Check your pool (on disk) version with (I forget the exact command): >>> # zpool get version sunway >> NAME =A0 =A0PROPERTY =A0VALUE =A0 =A0SOURCE >> sunway =A0version =A0 28 =A0 =A0 =A0 default >> >> It's latest pool's version for RELENG_9. >> >>> My guess is that you installed the latest zfs on the pool, but left the >>> old version of the bootloader. >> You mean gptzfsboot ? > Yes. >> Old gptzfsboot must fail with message like this: >> ZFS: unsupported ZFS version %u (should be %u) >> >> And why problem solved by copying previous zfsloader? >> Without any another changes... >> > previous zfsloader? Oh how interesting. I missed that in your last messag= e. > > When you updated the other 4 systems "with same sources" did you mean > the same cvsup file, or the exact copy of the source? I used same cvsup file from same cvsup mirror at same time... sys/boot/zfs/zfsimpl.c have same version. Only one difference for this system - it uses SAS drives, another systems have IDE and SATA. > And just out of curiosity, how did you find the old bootloader? I copied zfsloader from system, which has not been updated. Also I get zfsloader from weekly ZFS's snapshot. > Did you also try copying the bootloader (with dd maybe) from one of the > working updated systems? Or comparing checksums of the bootloaders? All checksums are different... If possible, I will try to boot the system with all available zfsloaders: - old from this system - again new from this system - old from another system - new from another system --=20 MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 14:24:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E863C106564A for ; Tue, 6 Dec 2011 14:24:43 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD7A8FC08 for ; Tue, 6 Dec 2011 14:24:42 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pB6EORTn045343 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Dec 2011 16:24:33 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EDE259B.4010502@digsys.bg> Date: Tue, 06 Dec 2011 16:24:27 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> In-Reply-To: <4EDDF9F4.9070508@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 14:24:44 -0000 Some tests with updated FreeBSD to 8-stable as of today, compared with the previous run On 06.12.11 13:18, Daniel Kalchev wrote: > > FreeBSD 8.2-STABLE #0: Wed Sep 28 11:23:59 EEST 2011 > CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2403.58-MHz > K8-class CPU) > real memory = 51539607552 (49152 MB) > blade 1: > > # nuttcp -S > # nuttcp -t -T 5 -w 128 -v localhost > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.044 ms > nuttcp-t: send window size = 143360, receive window size = 71680 > nuttcp-t: 8959.8750 MB in 5.02 real seconds = 1827635.67 KB/sec = > 14971.9914 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 143358 I/O calls, msec/call = 0.04, calls/sec = 28556.81 > nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 602maxrss 0+5pf 16+46csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 127.0.0.1 > nuttcp-r: send window size = 43008, receive window size = 143360 > nuttcp-r: 8959.8750 MB in 5.17 real seconds = 1773171.07 KB/sec = > 14525.8174 Mbps > nuttcp-r: 219708 I/O calls, msec/call = 0.02, calls/sec = 42461.43 > nuttcp-r: 0.0user 3.8sys 0:05real 76% 105i+1407d 614maxrss 1+17pf > 95059+22csw New results: FreeBSD 8.2-STABLE #1: Tue Dec 6 13:51:01 EET 2011 # nuttcp -t -T 5 -w 128 -v localhost nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.030 ms nuttcp-t: send window size = 143360, receive window size = 71680 nuttcp-t: 12748.0625 MB in 5.02 real seconds = 2599947.38 KB/sec = 21298.7689 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 203969 I/O calls, msec/call = 0.03, calls/sec = 40624.18 nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+2pf 1+82csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 127.0.0.1 nuttcp-r: send window size = 43008, receive window size = 143360 nuttcp-r: 12748.0625 MB in 5.15 real seconds = 2536511.81 KB/sec = 20779.1048 Mbps nuttcp-r: 297000 I/O calls, msec/call = 0.02, calls/sec = 57709.75 nuttcp-r: 0.1user 4.0sys 0:05real 81% 109i+1469d 626maxrss 0+15pf 121136+34csw Noticeable improvement. > > blade 2: > > # nuttcp -t -T 5 -w 128 -v 10.2.101.12 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.12 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.12 with mss=1448, RTT=0.059 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1340.6469 MB in 5.02 real seconds = 273449.90 KB/sec = > 2240.1016 Mbps > nuttcp-t: host-retrans = 171 > nuttcp-t: 21451 I/O calls, msec/call = 0.24, calls/sec = 4272.78 > nuttcp-t: 0.0user 1.9sys 0:05real 39% 120i+1610d 600maxrss 2+3pf > 75658+0csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.11 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1340.6469 MB in 5.17 real seconds = 265292.92 KB/sec = > 2173.2796 Mbps > nuttcp-r: 408764 I/O calls, msec/call = 0.01, calls/sec = 78992.15 > nuttcp-r: 0.0user 3.3sys 0:05real 64% 105i+1413d 620maxrss 0+15pf > 105104+102csw # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.055 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1964.8640 MB in 5.02 real seconds = 400757.59 KB/sec = 3283.0062 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 31438 I/O calls, msec/call = 0.16, calls/sec = 6261.87 nuttcp-t: 0.0user 2.7sys 0:05real 55% 112i+1501d 1124maxrss 1+2pf 111165+112csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1964.8640 MB in 5.15 real seconds = 390972.20 KB/sec = 3202.8442 Mbps nuttcp-r: 560718 I/O calls, msec/call = 0.01, calls/sec = 108957.70 nuttcp-r: 0.1user 4.2sys 0:05real 84% 111i+1494d 626maxrss 0+15pf 151930+16csw Again, improvement. > > > Another pari of blades: > > FreeBSD 8.2-STABLE #0: Tue Aug 9 12:37:55 EEST 2011 > CPU: AMD Opteron(tm) Processor 6134 (2300.04-MHz K8-class CPU) > real memory = 68719476736 (65536 MB) > > first blade: > > # nuttcp -S > # nuttcp -t -T 5 -w 128 -v localhost > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.090 ms > nuttcp-t: send window size = 143360, receive window size = 71680 > nuttcp-t: 2695.0625 MB in 5.00 real seconds = 551756.90 KB/sec = > 4519.9925 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 43121 I/O calls, msec/call = 0.12, calls/sec = 8621.20 > nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+4pf 2+71csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 127.0.0.1 > nuttcp-r: send window size = 43008, receive window size = 143360 > nuttcp-r: 2695.0625 MB in 5.14 real seconds = 536509.66 KB/sec = > 4395.0871 Mbps > nuttcp-r: 43126 I/O calls, msec/call = 0.12, calls/sec = 8383.94 > nuttcp-r: 0.0user 3.1sys 0:05real 61% 94i+1264d 624maxrss 1+16pf > 43019+0csw New result: FreeBSD 8.2-STABLE #1: Tue Dec 6 15:06:22 EET 2011 # nuttcp -t -T 5 -w 128 -v localhost nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.094 ms nuttcp-t: send window size = 143360, receive window size = 71680 nuttcp-t: 2659.1250 MB in 5.00 real seconds = 544493.51 KB/sec = 4460.4909 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 42546 I/O calls, msec/call = 0.12, calls/sec = 8507.71 nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 614maxrss 0+3pf 1+71csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 127.0.0.1 nuttcp-r: send window size = 43008, receive window size = 143360 nuttcp-r: 2659.1250 MB in 5.14 real seconds = 529484.10 KB/sec = 4337.5338 Mbps nuttcp-r: 42560 I/O calls, msec/call = 0.12, calls/sec = 8275.91 nuttcp-r: 0.0user 3.1sys 0:05real 62% 103i+1391d 618maxrss 0+16pf 42454+0csw Same result.. something is wrong with this Opteron system. > > second blade: > > # nuttcp -t -T 5 -w 128 -v 10.2.101.13 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.13 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.13 with mss=1448, RTT=0.164 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1290.3750 MB in 5.00 real seconds = 264173.96 KB/sec = > 2164.1131 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 20646 I/O calls, msec/call = 0.25, calls/sec = 4127.72 > nuttcp-t: 0.0user 3.8sys 0:05real 77% 96i+1299d 616maxrss 0+3pf > 27389+0csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.14 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1290.3750 MB in 5.14 real seconds = 256835.92 KB/sec = > 2103.9998 Mbps > nuttcp-r: 85668 I/O calls, msec/call = 0.06, calls/sec = 16651.70 > nuttcp-r: 0.0user 4.8sys 0:05real 94% 107i+1437d 624maxrss 0+15pf > 11848+0csw > # nuttcp -t -T 5 -w 128 -v 10.2.101.13 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.13 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.13 with mss=1448, RTT=0.130 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1317.6875 MB in 5.00 real seconds = 269767.01 KB/sec = 2209.9313 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 21083 I/O calls, msec/call = 0.24, calls/sec = 4215.11 nuttcp-t: 0.0user 3.7sys 0:05real 75% 105i+1409d 616maxrss 0+3pf 39629+11csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.14 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1317.6875 MB in 5.14 real seconds = 262306.61 KB/sec = 2148.8157 Mbps nuttcp-r: 85980 I/O calls, msec/call = 0.06, calls/sec = 16714.53 nuttcp-r: 0.0user 4.8sys 0:05real 94% 107i+1446d 618maxrss 0+15pf 10783+0csw Same,but.. again interrupt storm: interrupt storm detected on "irq269:"; throttling interrupt source Also interesting, Intel (server) - AMD (client) # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.087 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1301.1125 MB in 5.00 real seconds = 266388.35 KB/sec = 2182.2534 Mbps nuttcp-t: host-retrans = 1 nuttcp-t: 20818 I/O calls, msec/call = 0.25, calls/sec = 4162.36 nuttcp-t: 0.0user 4.3sys 0:05real 87% 106i+1430d 612maxrss 0+3pf 88509+11csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.13 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1301.1125 MB in 5.14 real seconds = 259062.19 KB/sec = 2122.2374 Mbps nuttcp-r: 537176 I/O calls, msec/call = 0.01, calls/sec = 104449.37 nuttcp-r: 0.0user 3.2sys 0:05real 64% 122i+1643d 626maxrss 0+15pf 222593+0csw AMD (server) - Intel (client) # nuttcp -t -T 5 -w 128 -v 10.2.101.14 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.14 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.14 with mss=1448, RTT=0.099 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 750.8897 MB in 5.02 real seconds = 153161.09 KB/sec = 1254.6957 Mbps nuttcp-t: host-retrans = 25 nuttcp-t: 12015 I/O calls, msec/call = 0.43, calls/sec = 2393.29 nuttcp-t: 0.0user 0.9sys 0:05real 19% 112i+1507d 618maxrss 0+2pf 97668+4csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.11 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 750.8897 MB in 5.15 real seconds = 149424.38 KB/sec = 1224.0845 Mbps nuttcp-r: 213009 I/O calls, msec/call = 0.02, calls/sec = 41394.56 nuttcp-r: 0.0user 4.6sys 0:05real 91% 107i+1445d 618maxrss 0+16pf 18273+0csw It seems performance measurements are more dependent on the server (nuttcp -S) machine. We will have to rule out the interrupt storms first of course, any advice? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 15:21:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FA61106566C; Tue, 6 Dec 2011 15:21:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7898FC08; Tue, 6 Dec 2011 15:21:48 +0000 (UTC) Received: by bkat2 with SMTP id t2so10523569bka.13 for ; Tue, 06 Dec 2011 07:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZgZ8VtqjmroMOuyFckueuHH4N+UZw9BFdAT/cJBbppY=; b=rFIYGBrHDuW6CUOte6NxcPC2WgxtFCu4qAbhZiyXAWsjLZNyILF6z9GjK4FAyZUROq dbdweAId0u0Y1dG7gIwfzzvNuEyHw199SuF+uuB7cW7nPyt98lkC2jF0ko9X+KH+fxMB 3pEScKhqKV7p0SsR6MY+o0u98u2L7xALEdkvg= MIME-Version: 1.0 Received: by 10.216.180.209 with SMTP id j59mr2888555wem.1.1323184907201; Tue, 06 Dec 2011 07:21:47 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.47.211 with HTTP; Tue, 6 Dec 2011 07:21:47 -0800 (PST) In-Reply-To: <4ED951E0.9000000@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> <4ED91B8D.2080808@FreeBSD.org> <4ED951E0.9000000@FreeBSD.org> Date: Tue, 6 Dec 2011 16:21:47 +0100 X-Google-Sender-Auth: nLm1gsjnDcIyTODJxGymg3KFrJs Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Konstantin Belousov Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:21:49 -0000 2011/12/2 Andriy Gapon : > on 02/12/2011 20:40 John Baldwin said the following: >> On 12/2/11 12:18 PM, Attilio Rao wrote: >>> 2011/12/2 John Baldwin: >>>> On 12/2/11 5:05 AM, Andriy Gapon wrote: >>>>> >>>>> on 02/12/2011 06:36 John Baldwin said the following: >>>>>> >>>>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true = when >>>>>> kdb was >>>>>> active). =C2=A0But I think these two changes should cover critical_e= xit() ok. >>>>>> >>>>> >>>>> I attempted to start a discussion about this a few times already :-) >>>>> Should we treat kdb context the same as SCHEDULER_STOPPED context (in= the >>>>> current definition) ? =C2=A0That is, skip all locks in the same fashi= on? >>>>> There are pros and contras. >>>> >>>> >>>> kdb should not block on locks, no. =C2=A0Most debugger commands should= not go >>>> near locks anyway unless they are intended to carefully modify the exi= sting >>>> system in a safe manner (such as the 'kill' command which should only = be >>>> using try locks and fail if it cannot safely post the signal). >>> >>> The biggest problem to KDB as the same as panic is that doing proper >>> 'continue' is impossible. >>> One of the features of the 'skip-locking' path is that it doesn't take >>> into account fast locking paths, where sometimes the lock can succeed >>> and other fails and you don't know about them. Also the restarted CPUs >>> can find corrupted datas (as they can be arbitrarely updated), I'm >>> sure it is too much panic prone. >> >> Yes, my thought is that kdb commands, etc. should be using dedicated rou= tines >> that do not use locks whenever possible. =C2=A0The problem of a user >> calling an arbitrary routine is not solvable (so I don't think we should= try to >> solve that, you use 'call' at your own risk), but built-in commands shou= ld >> explicitly either 1) not use locking, or 2) only use try locks and fail = out >> cleanly (including dropping any try locks acquired) if a try fails. =C2= =A0Now, that's >> an ideal view, I don't know how close we are to that in practice or if i= t is a >> realistically attainable goal. >> > > > I agree with what Attilio and you say. =C2=A0Initially it was tempting fo= r me to > apply the same SCHEDULER_STOPPED stopped medicine to the kdb_active conte= xt, but > after trying to deal with kdb_active x SCHEDULER_STOPPED x ukbd situation= I > really changed my mind. > > > I would classify the code that can be called in kdb_active context as fol= lows: > o debugger code proper (kdb, ddb, gdb stub, etc) - this obviously must no= t > (doesn't have to) use any locking > > o code that can be invoked via 'call' command - this is essentially any c= ode and > I don't think that it can/should do anything special for the kdb_active c= ontext [*] > > o debugger helper routines - those that do something trivial should not a= cquire > any locks; those that access shared resources should try the relevant loc= ks and > bail out if a resource can be in inconsistent state, or should be equippe= d to > deal correctly with such a state; this is the same as what you say above > > o common code that the debuggers have to use - most obviously this is con= sole > code and drivers that serve a particular console; on one hand those drive= rs can > have a non-trivial state that must be lock protected during normal operat= ion, on > the other hand the debugger must disregard those locks and grab its conso= le; > this is the most complex case in my opinion. Thanks for summarizing this up. However, please note that code in 2 and 4 entries may have the same issues or being the same thing, in practice. Anyway, I'm thinking now that if we really want to stop CPUs when entering KDB (and I think we do) functions at 2 and 4 should basically just be totally lockless or in general being totally re-entrant because when we restart CPUs we don't really want them finding datas to be corrupted. Also, skipping locking, is totally broken for this very specific reason. Functions at point 2 and 4 should be totally lockless then and possibly just work on read mode. For point 2, specifically, I think we need an explicit KPI to define functions within the subsystem themselves (something like DB_SHOW_COMMAND()) which marks undoublty functions to be called within ddb (the only KDB backend we implement right now) and likely for functions at point 4 we need to find a way to stress their belonging to the KDB area. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 15:26:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AE00106566B; Tue, 6 Dec 2011 15:26:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38B138FC08; Tue, 6 Dec 2011 15:26:29 +0000 (UTC) Received: by bkat2 with SMTP id t2so10532049bka.13 for ; Tue, 06 Dec 2011 07:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/ez1W1oBbxSPUGwoGFPnAa6V4YvM0c2Zz5Moaf1Flsw=; b=M10rq5FfDku+eigZZ1JYsif0+Gdl60Jn80whhUIH40TCsdNnz5a0p4o2juWsn+4r9X kkHzF/57MFJg8rh3/rSkzUt550a9AOuMS5YhccC3Q/OmqTLjQIeHHZoGTQxI8/JyXbIR fvk+P1sow7A0PmBG1A8IKKnqtl0XQyqD+VxdQ= MIME-Version: 1.0 Received: by 10.180.74.211 with SMTP id w19mr7667899wiv.7.1323185188858; Tue, 06 Dec 2011 07:26:28 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.47.211 with HTTP; Tue, 6 Dec 2011 07:26:28 -0800 (PST) In-Reply-To: <4EDBF11D.6030401@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171638.03208.jhb@freebsd.org> <4EC6D544.5040803@FreeBSD.org> <201111211132.42119.jhb@freebsd.org> <4EDBF11D.6030401@FreeBSD.org> Date: Tue, 6 Dec 2011 16:26:28 +0100 X-Google-Sender-Auth: OzYaNYzDIvAiSV43HfP7oqQ_2VI Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:26:31 -0000 2011/12/4 Andriy Gapon : > on 21/11/2011 18:58 Attilio Rao said the following: >> I would be very in favor about having a 'thread trampoline for KDB', >> thus that it can use locks. > > I keep hearing the suggestion to add this trampoline, but I admit that I = do not > understand its technical meaning in this context. =C2=A0And also how it h= elps with > the locking. =C2=A0So I will appreciate an explanation! =C2=A0Thanks! kdb_trap() now runs in interrupt context, my suggestion was to just to give KDB its own context (a new kernel thread) and yield its execution when KDB needs to be entered, this way it is possible to use locking and avoid functions duplications. In theory, this avoids constructing complicate algorithms to be lockless when implementing primitives KDB should use. However, I now realize a problem: if we want to stop CPUs we don't really want to acquire locks anyway because of CPU restart. Likely, the KDB trampoline is not a good option for this reason and we should work instead on getting KDB functions to be totally lockless. Another thing I'm considering is, however, the entrypoint for KDB. When I looked into it months ago I thought there is a mismatch between kdb_enter() (which should disable CPUs) and other ways to enter KDB (maybe some paths calling directly kdb_trap()?). We must offer an unified policy and entrypoint, being likely to disable CPUs when entering it. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 15:27:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5B9106566C; Tue, 6 Dec 2011 15:27:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0193F8FC18; Tue, 6 Dec 2011 15:27:05 +0000 (UTC) Received: by wgbds13 with SMTP id ds13so5881742wgb.1 for ; Tue, 06 Dec 2011 07:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v8Vf0ZDG+OTyjtI9CAjK1t4jSVQJKijL4hH/4II2O+w=; b=wObrDuGB63FQVoXWfJh0d2fov/5klqTfxxNj3Yp46S0XC+xDsiYH25g7jVinavg+wV BHsdXpaHcBONmGIT3aogI1Fn5gxeda1Qiy+l57YYr4/hHNd8m96oT2RN2bxGRlr6V4sO rkoDbPfRe70nOfPCSXjjlHR5MeHuOasyqPF8s= MIME-Version: 1.0 Received: by 10.216.180.209 with SMTP id j59mr2892813wem.1.1323185224827; Tue, 06 Dec 2011 07:27:04 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.47.211 with HTTP; Tue, 6 Dec 2011 07:27:04 -0800 (PST) In-Reply-To: <4EDBF4DD.3030001@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> <4EDBF4DD.3030001@FreeBSD.org> Date: Tue, 6 Dec 2011 16:27:04 +0100 X-Google-Sender-Auth: XPfB8gt9QgnlnQXfRS0BubqRjgU Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Konstantin Belousov Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:27:07 -0000 2011/12/4 Andriy Gapon : > on 02/12/2011 19:18 Attilio Rao said the following: >> BTW, I'm waiting for the details to settle (including the patch we >> have been discussing internally about binding to CPU0 during ACPI >> shutdown) > > I do not see strong interdependency between that patch and the panic patch. > BTW, I think that your patch is good to go. I agree, we can get back to this once the stop_scheduler patch is in. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 16:48:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFC4C1065673; Tue, 6 Dec 2011 16:48:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DBC558FC1B; Tue, 6 Dec 2011 16:48:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07691; Tue, 06 Dec 2011 18:48:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDE474C.8090600@FreeBSD.org> Date: Tue, 06 Dec 2011 18:48:12 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: FreeBSD Ports , FreeBSD current X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: binutils-2.22: ld and --copy-dt-needed-entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:48:15 -0000 Just for your information. It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-entries behavior, and so explicit --copy-dt-needed-entries is now needed where the previous default behavior is relied upon. A short excerpt from the man page for your convenience: > This option also has an effect on the resolution of symbols in > dynamic libraries. With --copy-dt-needed-entries dynamic libraries > mentioned on the command line will be recursively searched, > following their DT_NEEDED tags to other libraries, in order to > resolve symbols required by the output binary. With the default > setting however the searching of dynamic libraries that follow it > will stop with the dynamic library itself. No DT_NEEDED links will > be traversed to resolve symbols. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 17:21:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D83EF1065679 for ; Tue, 6 Dec 2011 17:21:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA608FC0A for ; Tue, 6 Dec 2011 17:21:23 +0000 (UTC) Received: by bkat2 with SMTP id t2so10710076bka.13 for ; Tue, 06 Dec 2011 09:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yeol3ZCbvz5xPTwSKeJ1sq5h2XzKhVBI1beHWUv+Yg8=; b=QJOGy0cwzp5N5ucQSL6ukF/hIGM6RaD9fZyuG/uIw73Hkb3X4WuesKFJ/V937Zkc2K fvmKVVGlXrmBwa0MtkwhIpejx64jf3zEPwLTwFIgYLjVGGN6tz/rfxSfe/p++xZ6ImVy wZ+eefDD1qveyjsOR2O4+5avxaEBhkrwHgymQ= MIME-Version: 1.0 Received: by 10.180.106.70 with SMTP id gs6mr18586448wib.41.1323192082906; Tue, 06 Dec 2011 09:21:22 -0800 (PST) Received: by 10.180.24.1 with HTTP; Tue, 6 Dec 2011 09:21:22 -0800 (PST) In-Reply-To: <4EDE259B.4010502@digsys.bg> References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> Date: Tue, 6 Dec 2011 09:21:22 -0800 Message-ID: From: Jack Vogel To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 17:21:24 -0000 Set the storm threshold to 0, that will disable it, its going to throttle your performance when it happens. Jack On Tue, Dec 6, 2011 at 6:24 AM, Daniel Kalchev wrote: > Some tests with updated FreeBSD to 8-stable as of today, compared with the > previous run > > > > On 06.12.11 13:18, Daniel Kalchev wrote: > >> >> FreeBSD 8.2-STABLE #0: Wed Sep 28 11:23:59 EEST 2011 >> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2403.58-MHz >> K8-class CPU) >> real memory = 51539607552 (49152 MB) >> blade 1: >> >> # nuttcp -S >> # nuttcp -t -T 5 -w 128 -v localhost >> nuttcp-t: v6.1.2: socket >> nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost >> nuttcp-t: time limit = 5.00 seconds >> nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.044 ms >> nuttcp-t: send window size = 143360, receive window size = 71680 >> nuttcp-t: 8959.8750 MB in 5.02 real seconds = 1827635.67 KB/sec = >> 14971.9914 Mbps >> nuttcp-t: host-retrans = 0 >> nuttcp-t: 143358 I/O calls, msec/call = 0.04, calls/sec = 28556.81 >> nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 602maxrss 0+5pf 16+46csw >> >> nuttcp-r: v6.1.2: socket >> nuttcp-r: buflen=65536, nstream=1, port=5001 tcp >> nuttcp-r: accept from 127.0.0.1 >> nuttcp-r: send window size = 43008, receive window size = 143360 >> nuttcp-r: 8959.8750 MB in 5.17 real seconds = 1773171.07 KB/sec = >> 14525.8174 Mbps >> nuttcp-r: 219708 I/O calls, msec/call = 0.02, calls/sec = 42461.43 >> nuttcp-r: 0.0user 3.8sys 0:05real 76% 105i+1407d 614maxrss 1+17pf >> 95059+22csw >> > > New results: > > FreeBSD 8.2-STABLE #1: Tue Dec 6 13:51:01 EET 2011 > > > > # nuttcp -t -T 5 -w 128 -v localhost > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.030 ms > > nuttcp-t: send window size = 143360, receive window size = 71680 > nuttcp-t: 12748.0625 MB in 5.02 real seconds = 2599947.38 KB/sec = > 21298.7689 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 203969 I/O calls, msec/call = 0.03, calls/sec = 40624.18 > nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+2pf 1+82csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 127.0.0.1 > nuttcp-r: send window size = 43008, receive window size = 143360 > nuttcp-r: 12748.0625 MB in 5.15 real seconds = 2536511.81 KB/sec = > 20779.1048 Mbps > nuttcp-r: 297000 I/O calls, msec/call = 0.02, calls/sec = 57709.75 > nuttcp-r: 0.1user 4.0sys 0:05real 81% 109i+1469d 626maxrss 0+15pf > 121136+34csw > > Noticeable improvement. > > > > >> blade 2: >> >> # nuttcp -t -T 5 -w 128 -v 10.2.101.12 >> nuttcp-t: v6.1.2: socket >> nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.12 >> nuttcp-t: time limit = 5.00 seconds >> nuttcp-t: connect to 10.2.101.12 with mss=1448, RTT=0.059 ms >> nuttcp-t: send window size = 131768, receive window size = 66608 >> nuttcp-t: 1340.6469 MB in 5.02 real seconds = 273449.90 KB/sec = >> 2240.1016 Mbps >> nuttcp-t: host-retrans = 171 >> nuttcp-t: 21451 I/O calls, msec/call = 0.24, calls/sec = 4272.78 >> nuttcp-t: 0.0user 1.9sys 0:05real 39% 120i+1610d 600maxrss 2+3pf >> 75658+0csw >> >> nuttcp-r: v6.1.2: socket >> nuttcp-r: buflen=65536, nstream=1, port=5001 tcp >> nuttcp-r: accept from 10.2.101.11 >> nuttcp-r: send window size = 33304, receive window size = 131768 >> nuttcp-r: 1340.6469 MB in 5.17 real seconds = 265292.92 KB/sec = >> 2173.2796 Mbps >> nuttcp-r: 408764 I/O calls, msec/call = 0.01, calls/sec = 78992.15 >> nuttcp-r: 0.0user 3.3sys 0:05real 64% 105i+1413d 620maxrss 0+15pf >> 105104+102csw >> > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.055 ms > > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1964.8640 MB in 5.02 real seconds = 400757.59 KB/sec = 3283.0062 > Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 31438 I/O calls, msec/call = 0.16, calls/sec = 6261.87 > nuttcp-t: 0.0user 2.7sys 0:05real 55% 112i+1501d 1124maxrss 1+2pf > 111165+112csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1964.8640 MB in 5.15 real seconds = 390972.20 KB/sec = 3202.8442 > Mbps > nuttcp-r: 560718 I/O calls, msec/call = 0.01, calls/sec = 108957.70 > nuttcp-r: 0.1user 4.2sys 0:05real 84% 111i+1494d 626maxrss 0+15pf > 151930+16csw > > Again, improvement. > > > >> >> Another pari of blades: >> >> FreeBSD 8.2-STABLE #0: Tue Aug 9 12:37:55 EEST 2011 >> CPU: AMD Opteron(tm) Processor 6134 (2300.04-MHz K8-class CPU) >> real memory = 68719476736 (65536 MB) >> >> first blade: >> >> # nuttcp -S >> # nuttcp -t -T 5 -w 128 -v localhost >> nuttcp-t: v6.1.2: socket >> nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost >> nuttcp-t: time limit = 5.00 seconds >> nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.090 ms >> nuttcp-t: send window size = 143360, receive window size = 71680 >> nuttcp-t: 2695.0625 MB in 5.00 real seconds = 551756.90 KB/sec = >> 4519.9925 Mbps >> nuttcp-t: host-retrans = 0 >> nuttcp-t: 43121 I/O calls, msec/call = 0.12, calls/sec = 8621.20 >> nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+4pf 2+71csw >> >> nuttcp-r: v6.1.2: socket >> nuttcp-r: buflen=65536, nstream=1, port=5001 tcp >> nuttcp-r: accept from 127.0.0.1 >> nuttcp-r: send window size = 43008, receive window size = 143360 >> nuttcp-r: 2695.0625 MB in 5.14 real seconds = 536509.66 KB/sec = >> 4395.0871 Mbps >> nuttcp-r: 43126 I/O calls, msec/call = 0.12, calls/sec = 8383.94 >> nuttcp-r: 0.0user 3.1sys 0:05real 61% 94i+1264d 624maxrss 1+16pf >> 43019+0csw >> > > New result: > > FreeBSD 8.2-STABLE #1: Tue Dec 6 15:06:22 EET 2011 > > > > # nuttcp -t -T 5 -w 128 -v localhost > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.094 ms > > nuttcp-t: send window size = 143360, receive window size = 71680 > nuttcp-t: 2659.1250 MB in 5.00 real seconds = 544493.51 KB/sec = 4460.4909 > Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 42546 I/O calls, msec/call = 0.12, calls/sec = 8507.71 > nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 614maxrss 0+3pf 1+71csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 127.0.0.1 > nuttcp-r: send window size = 43008, receive window size = 143360 > nuttcp-r: 2659.1250 MB in 5.14 real seconds = 529484.10 KB/sec = 4337.5338 > Mbps > nuttcp-r: 42560 I/O calls, msec/call = 0.12, calls/sec = 8275.91 > nuttcp-r: 0.0user 3.1sys 0:05real 62% 103i+1391d 618maxrss 0+16pf > 42454+0csw > > Same result.. something is wrong with this Opteron system. > > > >> second blade: >> >> # nuttcp -t -T 5 -w 128 -v 10.2.101.13 >> nuttcp-t: v6.1.2: socket >> nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.13 >> nuttcp-t: time limit = 5.00 seconds >> nuttcp-t: connect to 10.2.101.13 with mss=1448, RTT=0.164 ms >> nuttcp-t: send window size = 131768, receive window size = 66608 >> nuttcp-t: 1290.3750 MB in 5.00 real seconds = 264173.96 KB/sec = >> 2164.1131 Mbps >> nuttcp-t: host-retrans = 0 >> nuttcp-t: 20646 I/O calls, msec/call = 0.25, calls/sec = 4127.72 >> nuttcp-t: 0.0user 3.8sys 0:05real 77% 96i+1299d 616maxrss 0+3pf 27389+0csw >> >> nuttcp-r: v6.1.2: socket >> nuttcp-r: buflen=65536, nstream=1, port=5001 tcp >> nuttcp-r: accept from 10.2.101.14 >> nuttcp-r: send window size = 33304, receive window size = 131768 >> nuttcp-r: 1290.3750 MB in 5.14 real seconds = 256835.92 KB/sec = >> 2103.9998 Mbps >> nuttcp-r: 85668 I/O calls, msec/call = 0.06, calls/sec = 16651.70 >> nuttcp-r: 0.0user 4.8sys 0:05real 94% 107i+1437d 624maxrss 0+15pf >> 11848+0csw >> >> > # nuttcp -t -T 5 -w 128 -v 10.2.101.13 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.13 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.13 with mss=1448, RTT=0.130 ms > > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1317.6875 MB in 5.00 real seconds = 269767.01 KB/sec = 2209.9313 > Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 21083 I/O calls, msec/call = 0.24, calls/sec = 4215.11 > nuttcp-t: 0.0user 3.7sys 0:05real 75% 105i+1409d 616maxrss 0+3pf > 39629+11csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.14 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1317.6875 MB in 5.14 real seconds = 262306.61 KB/sec = 2148.8157 > Mbps > nuttcp-r: 85980 I/O calls, msec/call = 0.06, calls/sec = 16714.53 > nuttcp-r: 0.0user 4.8sys 0:05real 94% 107i+1446d 618maxrss 0+15pf > 10783+0csw > > Same,but.. again interrupt storm: > > interrupt storm detected on "irq269:"; throttling interrupt source > > Also interesting, Intel (server) - AMD (client) > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.087 ms > > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1301.1125 MB in 5.00 real seconds = 266388.35 KB/sec = 2182.2534 > Mbps > nuttcp-t: host-retrans = 1 > nuttcp-t: 20818 I/O calls, msec/call = 0.25, calls/sec = 4162.36 > nuttcp-t: 0.0user 4.3sys 0:05real 87% 106i+1430d 612maxrss 0+3pf > 88509+11csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.13 > > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1301.1125 MB in 5.14 real seconds = 259062.19 KB/sec = 2122.2374 > Mbps > nuttcp-r: 537176 I/O calls, msec/call = 0.01, calls/sec = 104449.37 > nuttcp-r: 0.0user 3.2sys 0:05real 64% 122i+1643d 626maxrss 0+15pf > 222593+0csw > > AMD (server) - Intel (client) > > # nuttcp -t -T 5 -w 128 -v 10.2.101.14 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.14 > > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.14 with mss=1448, RTT=0.099 ms > > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 750.8897 MB in 5.02 real seconds = 153161.09 KB/sec = 1254.6957 > Mbps > nuttcp-t: host-retrans = 25 > nuttcp-t: 12015 I/O calls, msec/call = 0.43, calls/sec = 2393.29 > nuttcp-t: 0.0user 0.9sys 0:05real 19% 112i+1507d 618maxrss 0+2pf 97668+4csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.11 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 750.8897 MB in 5.15 real seconds = 149424.38 KB/sec = 1224.0845 > Mbps > nuttcp-r: 213009 I/O calls, msec/call = 0.02, calls/sec = 41394.56 > nuttcp-r: 0.0user 4.6sys 0:05real 91% 107i+1445d 618maxrss 0+16pf > 18273+0csw > > It seems performance measurements are more dependent on the server (nuttcp > -S) machine. > We will have to rule out the interrupt storms first of course, any advice? > > > Daniel > > ______________________________**_________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@** > freebsd.org " > From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 17:40:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1474106566C for ; Tue, 6 Dec 2011 17:40:30 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7306A8FC12 for ; Tue, 6 Dec 2011 17:40:29 +0000 (UTC) Received: from [192.92.129.101] ([192.92.129.101]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pB6HeKEW049345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Dec 2011 19:40:25 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Daniel Kalchev In-Reply-To: Date: Tue, 6 Dec 2011 19:40:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> To: Jack Vogel X-Mailer: Apple Mail (2.1251.1) Cc: Luigi Rizzo , current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 17:40:31 -0000 I see significant difference between number of interrupts on the Intel = and the AMD blades. When performing a test between the Intel and AMD = blades, the Intel blade generates 20,000-35,000 interrupts, while the = AMD blade generates under 1,000 interrupts. There is no longer throttling, but the performance does not improve..=20 I set it via=20 sysctl hw.intr_storm_threshold=3D0 Should this go to /boot/loader.conf instead. Daniel On Dec 6, 2011, at 7:21 PM, Jack Vogel wrote: > Set the storm threshold to 0, that will disable it, its going to = throttle your performance > when it happens. >=20 > Jack >=20 From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 17:52:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C7B1065670 for ; Tue, 6 Dec 2011 17:52:57 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9828FC19 for ; Tue, 6 Dec 2011 17:52:55 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pB6HqaEQ073157 for ; Tue, 6 Dec 2011 09:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1323193956; bh=nHLAKu2/UreyhfrOvK9buBWx7sNkD8nvc47FzfN7l3U=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=XuUkXe9f71NRnA1x1DO9D68o06L9R4wzdv+4UI3PdfqGsn/qwvPTeqp/CbchgYPXf lsSm4nQ3ZIgyKICwQVQzN4I0N2JZhvSKbk9vKTYJp4UkcvDCSKTxxn/XQMLblUc9Na 2MidLJtRh6omoTRyWg5K/bSj6Q0MxQJQWT1sANQc= From: Sean Bruno To: FreeBSD-Current Content-Type: text/plain Date: Tue, 06 Dec 2011 09:52:36 -0800 Message-ID: <1323193956.19452.10.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: Is there a FreeBSD 9+ version of this? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 17:52:57 -0000 http://www.freebsd.org/doc/handbook/geom-mirror.html From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 18:04:35 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C31891065672 for ; Tue, 6 Dec 2011 18:04:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6608FC0A for ; Tue, 6 Dec 2011 18:04:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA08510; Tue, 06 Dec 2011 20:04:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDE592F.4020102@FreeBSD.org> Date: Tue, 06 Dec 2011 20:04:31 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: KOT MATPOCKuH References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS: i/o error all block copies unavailable Invalid format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 18:04:35 -0000 on 06/12/2011 08:14 KOT MATPOCKuH said the following: > Hello all! > > On 24 nov I updated sources via csup to RELENG_9 (9.0-PRERELEASE). > After make installboot I successfully booted to single user. > But after make installworld system was fail to boot with message: > ZFS: i/o error all block copies unavailable > Invalid format > > status command shows status of all polls properly. > root filesystem is not compressed. > > # zfsboottest /dev/gpt/rootdisk /dev/gpt/rootmirr > pool: sunway > config: > > NAME STATE > sunway ONLINE > mirror ONLINE > gpt/rootdisk ONLINE > gpt/rootmirr ONLINE > > Restore of old /boot/zfsloader was solved issue. > Before I successfully updated 4 another systems with same sources > level without any problems. > > My sys/boot/zfs/zfsimpl.c's version: 1.17.2.2 2011/11/19 10:49:03 > > Where may a root cause of problem? And how I can debug this problem? 1. Inability of the boot code to handle your pool or root filesystem for some reason. 2. Try using zfsboottest.sh next time your reproduce the problem (or see what the script does and try to examine some files instead of doing an empty run). If it fails, then please try to narrow the problem to a particular file, run zfsboottest under debugger, collect interesting information about the failure and get back to us with it. The problem may have been masked by the fact that you touched /boot directory when restoring your previous loader. Alternatively, the problem could be in the newer zfs boot code. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 18:06:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D3A01065675 for ; Tue, 6 Dec 2011 18:06:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D99868FC0C for ; Tue, 6 Dec 2011 18:06:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA08536; Tue, 06 Dec 2011 20:06:41 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDE59B0.1000206@FreeBSD.org> Date: Tue, 06 Dec 2011 20:06:40 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Peter Maloney References: <4EDDC60E.9060106@brockmann-consult.de> <4EDE0D8B.6020201@brockmann-consult.de> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: KOT MATPOCKuH , freebsd-current@FreeBSD.org Subject: Re: ZFS: i/o error all block copies unavailable Invalid format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 18:06:45 -0000 on 06/12/2011 15:41 KOT MATPOCKuH said the following: > 2011/12/6 Peter Maloney : >> And just out of curiosity, how did you find the old bootloader? > I copied zfsloader from system, which has not been updated. > Also I get zfsloader from weekly ZFS's snapshot. Additionally, installworld preserves previous loader (and zfsloader) as .old file. Not sure about other means of updating /boot files. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 18:54:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3455B10656A3; Tue, 6 Dec 2011 18:54:32 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id A9BB78FC0C; Tue, 6 Dec 2011 18:54:31 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 18E536; Tue, 6 Dec 2011 19:54:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 06 Dec 2011 19:54:31 +0100 From: Bernhard Froehlich To: Andriy Gapon In-Reply-To: <4EDDF91F.10308@FreeBSD.org> References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> "<7c3c9505867f4528af276a571077b9ce@bluelife.at>" <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> <4EDDDB7A.4050604@FreeBSD.org> <4EDDF91F.10308@FreeBSD.org> Message-ID: <5ca321038ae3f35c630aa29f5031d1d5@bluelife.at> X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.6 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B020D.4EDE64E5.0193,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Alan Cox , Alan Cox , vbox@freebsd.org, freebsd-emulation@freebsd.org, FreeBSD current , Konstantin Belousov , Bernhard Froehlich Subject: Re: virtualbox r0 memory management update [Was: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 18:54:32 -0000 On 06.12.2011 12:14, Andriy Gapon wrote: > Meanwhile, here is the code that I came up with: > http://people.freebsd.org/~avg/vbox/ > For your convenience I have uploaded both the new file and its diff > against svn > head. I am testing this on FreeBSD head (r228017), so far no > breakage observed. > > I would appreciate reviews and testing of this code. Especially > testing with > earlier FreeBSD releases. VirtualBox 4.1.6 on FreeBSD 9.0-RC2/amd64 gave me: cc -O2 -pipe -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -Iinclude -I. -Ir0drv -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c: In function 'FreeBSDContigPhysAllocHelper': /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:212: error: incompatible types in initialization *** Error code 1 Stop in /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv. *** Error code 1 -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 19:01:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4361F1065670; Tue, 6 Dec 2011 19:01:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id A39018FC0A; Tue, 6 Dec 2011 19:01:09 +0000 (UTC) Received: by wgbds13 with SMTP id ds13so94111wgb.1 for ; Tue, 06 Dec 2011 11:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xeuEQttgLjz0YONR9uWPoXB3CVT+fIrlAz4OtjnW7tM=; b=E7t+PidNs0Vv+R49xRGpMgS2Jae8VSYj2IuLQtQvlGZcWgV9nKR/RhnSUeNVG4S+X6 K3eKf5Seryo/ZzbeJeRCB0WxAolR5WLS38UCn7XyvrWcVJsI5Pk+9f8ODERcbTg7G1fI t5+nyP2QIOpDXwlv5vK/i4MMHFkrCNkw8QP2c= MIME-Version: 1.0 Received: by 10.216.179.142 with SMTP id h14mr2977070wem.1.1323196452675; Tue, 06 Dec 2011 10:34:12 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.47.211 with HTTP; Tue, 6 Dec 2011 10:34:12 -0800 (PST) In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> Date: Tue, 6 Dec 2011 19:34:12 +0100 X-Google-Sender-Auth: wdrMNeKdc6IEYFluySEBMXlRiVI Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, current@freebsd.org, avg@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 19:01:10 -0000 2011/11/13 Kostik Belousov : > I was tricked into finishing the work by Andrey Gapon, who developed > the patch to reliably stop other processors on panic. =C2=A0The patch > greatly improves the chances of getting dump on panic on SMP host. > Several people already saw the patchset, and I remember that Andrey > posted it to some lists. > > The change stops other (*) processors early upon the panic. =C2=A0This wa= y, > no parallel manipulation of the kernel memory is performed by CPUs. > In particular, the kernel memory map is static. =C2=A0Patch prevents the > panic thread from blocking and switching out. > > * - in the context of the description, other means not current. > > Since other threads are not run anymore, lock owner cannot release a > lock which is required by panic thread. =C2=A0Due to this, we need to fak= e > a lock acquisition after the panic, which adds minimal overhead to the > locking cost. The patch tries to not add any overhead on the fast path > of the lock acquire. =C2=A0The check for the after-panic condition was > reduced to single memory access, done only when the quick cas lock > attempt failed, and braced with __unlikely compiler hint. > > For now, the new mode of operation is disabled by default, since some > further USB changes are needed to make USB keyboard usable in that > environment. > > With the patch, getting a dump from the machine without debugger > compiled in is much more realistic. =C2=A0Please comment, I will commit t= he > change in 2 weeks unless strong reasons not to are given. > > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch Below are reported my notes on the patch: - Just by looking at kern_mutex.c chunk I see that you have added SCHEDULER_STOPPED() checks on very specific places, usually after sanity checks by WITNESS (and similar) and sometimes in odd places (as the chunk involving _mtx_lock_spin_flags). I think that we should just skip all the checks along with the hard locking operation. Ideall we should also skip the fast path, IMHO, but it is impossible (without polluting it), but at least skip the vast majority of operations for the hard one, so that we get, for example: %svn diff -x -p kern/kern_mutex.c | less Index: kern/kern_mutex.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- kern/kern_mutex.c (revision 228308) +++ kern/kern_mutex.c (working copy) @@ -232,6 +232,8 @@ void _mtx_lock_spin_flags(struct mtx *m, int opts, const char *file, int line) { + if (SCHEDULER_STOPPED()) + return; MPASS(curthread !=3D NULL); KASSERT(m->mtx_lock !=3D MTX_DESTROYED, ("mtx_lock_spin() of destroyed mutex @ %s:%d", file, line)); In this optic I'd patch directly the hard functions rather than waiting them to hit the smallest possible common point (which are _mtx_lock_sleep() and _mtx_lock_spin()). That will make the patch more verbose but more precise and more correct too. - This chunk is unneeded now: @@ -577,6 +589,7 @@ retry: m->mtx_recurse++; break; } + lock_profile_obtain_lock_failed(&m->lock_object, &contested, &waittime); /* Give interrupts a chance while we spin. */ - I'm not entirely sure, why we want to disable interrupts at this moment (before to stop other CPUs)?: @@ -547,13 +555,18 @@ panic(const char *fmt, ...) { #ifdef SMP static volatile u_int panic_cpu =3D NOCPU; + cpuset_t other_cpus; #endif struct thread *td =3D curthread; int bootopt, newpanic; va_list ap; static char buf[256]; - critical_enter(); + if (stop_scheduler_on_panic) + spinlock_enter(); + else + critical_enter(); + - In this chunk I don't entirely understand the kdb_active check: @@ -566,11 +579,18 @@ panic(const char *fmt, ...) PCPU_GET(cpuid)) =3D=3D 0) while (panic_cpu !=3D NOCPU) ; /* nothing */ + if (stop_scheduler_on_panic) { + if (panicstr =3D=3D NULL && !kdb_active) { + other_cpus =3D all_cpus; + CPU_CLR(PCPU_GET(cpuid), &other_cpus); + stop_cpus_hard(other_cpus); + } + } #endif bootopt =3D RB_AUTOBOOT; newpanic =3D 0; - if (panicstr) + if (panicstr !=3D NULL) bootopt |=3D RB_NOSYNC; else { bootopt |=3D RB_DUMP; Is it for avoiding to pass an empty mask to stop_cpus() in kdb_trap() (I saw you changed the policy there)? Maybe we can find a better integration among the two. I'd also move the setting of stop_scheduler variable in the "if", it seems a bug to me to have it set otherwise. - The same reservations expressed about the hard path on mutex also applies to rwlock and sxlock. - I'm not sure I like to change the policies on cpu stopping for KDB with this patchset. I think we should discuss this furthermore, in particular in terms of reviewing what accesses points KDB has and if they are all covered. If someone can summary this up (and has already made the analysis) and would please share his findings I'd be happy about it, otherwise we should not commit the stop_cpu approach in kdb_trap() IMHO. Thanks, Attilio From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 19:07:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1E5F1065670 for ; Tue, 6 Dec 2011 19:07:11 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 828118FC15 for ; Tue, 6 Dec 2011 19:07:11 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id pB6IkhpM010189; Tue, 6 Dec 2011 11:46:43 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id pB6IkgkS010186; Tue, 6 Dec 2011 11:46:42 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 6 Dec 2011 11:46:42 -0700 (MST) From: Warren Block To: Sean Bruno In-Reply-To: <1323193956.19452.10.camel@hitfishpass-lx.corp.yahoo.com> Message-ID: References: <1323193956.19452.10.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 06 Dec 2011 11:46:43 -0700 (MST) Cc: FreeBSD-Current Subject: Re: Is there a FreeBSD 9+ version of this? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 19:07:11 -0000 On Tue, 6 Dec 2011, Sean Bruno wrote: > http://www.freebsd.org/doc/handbook/geom-mirror.html Not in the Handbook. To make gmirror work with GPT, create GPT partitions and mirror those. I wrote an article on that using multiple partitions: http://www.wonkity.com/~wblock/docs/html/gmirror.html However, it's since been pointed out that rebuilding the mirror could suffer from head contention. Using a single GPT partition over the whole drive should not have that problem, but I haven't tested either way. From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 20:22:22 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B7B61065673; Tue, 6 Dec 2011 20:22:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 979C58FC08; Tue, 6 Dec 2011 20:22:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA09804; Tue, 06 Dec 2011 22:22:18 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RY1Ws-000OUw-9Y; Tue, 06 Dec 2011 22:22:18 +0200 Message-ID: <4EDE7977.7010800@FreeBSD.org> Date: Tue, 06 Dec 2011 22:22:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Bernhard Froehlich References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> "<7c3c9505867f4528af276a571077b9ce@bluelife.at>" <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> <4EDDDB7A.4050604@FreeBSD.org> <4EDDF91F.10308@FreeBSD.org> <5ca321038ae3f35c630aa29f5031d1d5@bluelife.at> In-Reply-To: <5ca321038ae3f35c630aa29f5031d1d5@bluelife.at> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, FreeBSD current , vbox@FreeBSD.org Subject: Re: virtualbox r0 memory management update [Was: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:22:22 -0000 on 06/12/2011 20:54 Bernhard Froehlich said the following: > On 06.12.2011 12:14, Andriy Gapon wrote: >> Meanwhile, here is the code that I came up with: >> http://people.freebsd.org/~avg/vbox/ >> For your convenience I have uploaded both the new file and its diff >> against svn >> head. I am testing this on FreeBSD head (r228017), so far no >> breakage observed. >> >> I would appreciate reviews and testing of this code. Especially testing with >> earlier FreeBSD releases. > > VirtualBox 4.1.6 on FreeBSD 9.0-RC2/amd64 gave me: > > cc -O2 -pipe -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 -DIN_SUP_R0 -DVBOX > -DRT_WITH_VBOX -w -DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS > -DRT_ARCH_AMD64 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc > -Iinclude -I. -Ir0drv -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -c > /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c > > /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c: > In function 'FreeBSDContigPhysAllocHelper': > /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:212: > error: incompatible types in initialization > *** Error code 1 > > Stop in > /usr/home/decke/rpvbox/emulators/virtualbox-ose-kmod/work/VirtualBox-4.1.6_OSE/out/freebsd.amd64/release/bin/src/vboxdrv. > > *** Error code 1 > Could you please change that line as follows? vm_page_t pPage = pPages +iPage; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 20:50:20 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 799CC1065670 for ; Tue, 6 Dec 2011 20:50:20 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 36CB88FC17 for ; Tue, 6 Dec 2011 20:50:19 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B75367300A; Tue, 6 Dec 2011 22:06:25 +0100 (CET) Date: Tue, 6 Dec 2011 22:06:25 +0100 From: Luigi Rizzo To: Daniel Kalchev Message-ID: <20111206210625.GB62605@onelab2.iet.unipi.it> References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Jack Vogel , current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:50:20 -0000 On Tue, Dec 06, 2011 at 07:40:21PM +0200, Daniel Kalchev wrote: > I see significant difference between number of interrupts on the Intel and the AMD blades. When performing a test between the Intel and AMD blades, the Intel blade generates 20,000-35,000 interrupts, while the AMD blade generates under 1,000 interrupts. > Even in my experiments there is a lot of instability in the results. I don't know exactly where the problem is, but the high number of read syscalls, and the huge impact of setting interrupt_rate=0 (defaults at 16us on the ixgbe) makes me think that there is something that needs investigation in the protocol stack. Of course we don't want to optimize specifically for the one-flow-at-10G case, but devising something that makes the system less affected by short timing variations, and can pass upstream interrupt mitigation delays would help. I don't have a solution yet.. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 21:24:40 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 013A51065673; Tue, 6 Dec 2011 21:24:40 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 91EFC8FC0A; Tue, 6 Dec 2011 21:24:39 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id C3227118C5; Tue, 6 Dec 2011 22:24:38 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id DFWhZRdIvbuj; Tue, 6 Dec 2011 22:24:36 +0100 (CET) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id A3BAC118B7; Tue, 6 Dec 2011 22:24:36 +0100 (CET) Message-ID: <4EDE8816.7030505@FreeBSD.org> Date: Tue, 06 Dec 2011 22:24:38 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4EDE474C.8090600@FreeBSD.org> In-Reply-To: <4EDE474C.8090600@FreeBSD.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , FreeBSD Ports Subject: Re: binutils-2.22: ld and --copy-dt-needed-entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 21:24:40 -0000 On 6.12.2011 17:48, Andriy Gapon wrote: > Just for your information. > It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-entries > behavior, and so explicit --copy-dt-needed-entries is now needed where the > previous default behavior is relied upon. > > A short excerpt from the man page for your convenience: > >> This option also has an effect on the resolution of symbols in >> dynamic libraries. With --copy-dt-needed-entries dynamic libraries >> mentioned on the command line will be recursively searched, >> following their DT_NEEDED tags to other libraries, in order to >> resolve symbols required by the output binary. With the default >> setting however the searching of dynamic libraries that follow it >> will stop with the dynamic library itself. No DT_NEEDED links will >> be traversed to resolve symbols. What do we do with this? We can go back, patch to behave as before or to continue. Are there any serious complaints? -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 21:29:27 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D62106566C; Tue, 6 Dec 2011 21:29:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 89D068FC14; Tue, 6 Dec 2011 21:29:26 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA10427; Tue, 06 Dec 2011 23:29:24 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RY2Zo-000OXZ-H7; Tue, 06 Dec 2011 23:29:24 +0200 Message-ID: <4EDE8931.1080506@FreeBSD.org> Date: Tue, 06 Dec 2011 23:29:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 21:29:27 -0000 on 06/12/2011 20:34 Attilio Rao said the following: [snip] > - I'm not entirely sure, why we want to disable interrupts at this > moment (before to stop other CPUs)?: Because I believe that stop_cpus_hard() should run in a context with interrupts and preemption disabled. Also, I believe that the whole panic handling code should run in the same context. So it was only natural for me to enter that context at this point. > @@ -547,13 +555,18 @@ panic(const char *fmt, ...) > { > #ifdef SMP > static volatile u_int panic_cpu = NOCPU; > + cpuset_t other_cpus; > #endif > struct thread *td = curthread; > int bootopt, newpanic; > va_list ap; > static char buf[256]; > > - critical_enter(); > + if (stop_scheduler_on_panic) > + spinlock_enter(); > + else > + critical_enter(); > + > > - In this chunk I don't entirely understand the kdb_active check: > @@ -566,11 +579,18 @@ panic(const char *fmt, ...) > PCPU_GET(cpuid)) == 0) > while (panic_cpu != NOCPU) > ; /* nothing */ > + if (stop_scheduler_on_panic) { > + if (panicstr == NULL && !kdb_active) { > + other_cpus = all_cpus; > + CPU_CLR(PCPU_GET(cpuid), &other_cpus); > + stop_cpus_hard(other_cpus); > + } > + } > #endif > > bootopt = RB_AUTOBOOT; > newpanic = 0; > - if (panicstr) > + if (panicstr != NULL) > bootopt |= RB_NOSYNC; > else { > bootopt |= RB_DUMP; > > Is it for avoiding to pass an empty mask to stop_cpus() in kdb_trap() > (I saw you changed the policy there)? Yes. You know my position about elimination of the cpuset parameter to stop_cpus_* and my intention to do so. This is related to that. Right now that check is not strictly necessary, but it doesn't do any harm either. We know that all other CPUs are already stopped when kdb_active (ditto for panicstr != NULL). > Maybe we can find a better integration among the two. What kind of integration? Right now I have simple model - both stop all other CPUs. > I'd also move the setting of stop_scheduler variable in the "if", it > seems a bug to me to have it set otherwise. Can you please explain what bug do you suspect here? I do not see any. [snip] > - I'm not sure I like to change the policies on cpu stopping for KDB > with this patchset. I am not sure what exactly you mean by change in policies. I do not see any such change, entering kdb always stops all other CPUs, with or without the patch. > I think we should discuss this furthermore, in > particular in terms of reviewing what accesses points KDB has and if > they are all covered. Please review the code and see if anything is left to discuss :-) My review shows that all access points are covered. Essentially there is only one access point - kdb_trap. It's called either directly from a known trap context or indirectly (via a debug trap) using kdb_enter. > If someone can summary this up (and has already made the analysis) and > would please share his findings I'd be happy about it, otherwise we > should not commit the stop_cpu approach in kdb_trap() IMHO. I hope that the above answers somewhat clear your concerns. Just in case, if you can point out any clear specific problems with this approach, then that can block me from committing. A fuzzy feeling that something might be wrong won't do that :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 21:41:38 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92B121065670; Tue, 6 Dec 2011 21:41:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 79BF78FC13; Tue, 6 Dec 2011 21:41:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA10577; Tue, 06 Dec 2011 23:41:36 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RY2lb-000OY6-Pe; Tue, 06 Dec 2011 23:41:35 +0200 Message-ID: <4EDE8C0E.7050806@FreeBSD.org> Date: Tue, 06 Dec 2011 23:41:34 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Matuska References: <4EDE474C.8090600@FreeBSD.org> <4EDE8816.7030505@FreeBSD.org> In-Reply-To: <4EDE8816.7030505@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , FreeBSD Ports Subject: Re: binutils-2.22: ld and --copy-dt-needed-entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 21:41:38 -0000 on 06/12/2011 23:24 Martin Matuska said the following: > On 6.12.2011 17:48, Andriy Gapon wrote: >> Just for your information. >> It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-entries >> behavior, and so explicit --copy-dt-needed-entries is now needed where the >> previous default behavior is relied upon. >> >> A short excerpt from the man page for your convenience: >> >>> This option also has an effect on the resolution of symbols in >>> dynamic libraries. With --copy-dt-needed-entries dynamic libraries >>> mentioned on the command line will be recursively searched, >>> following their DT_NEEDED tags to other libraries, in order to >>> resolve symbols required by the output binary. With the default >>> setting however the searching of dynamic libraries that follow it >>> will stop with the dynamic library itself. No DT_NEEDED links will >>> be traversed to resolve symbols. > What do we do with this? > We can go back, patch to behave as before or to continue. > Are there any serious complaints? I am not sure. Eventually all upstreams of our ports will have to deal with this. So far I've encountered only one problematic port (gegl) that links a binary with -lglib-2.0 expecting that a required -liconv dependency would be automatically picked up via DT_NEEDED. libglib-2.0.so indeed has a DT_NEEDED entry for libiconv.so. But this dependency is not explicitly advertised via pkg-config metadata: $ fgrep -i Libs /usr/local/libdata/pkgconfig/glib-2.0.pc Libs: -L${libdir} -lglib-2.0 Libs.private: -liconv So there could be other issues related to this in the future. Perhaps this is actually an issue with glib, maybe it should have -liconv in Libs. I am not really knowledgeable about his stuff. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 21:51:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80FD3106566C; Tue, 6 Dec 2011 21:51:26 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 31AA78FC15; Tue, 6 Dec 2011 21:51:25 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pB6Lp5hD054908; Tue, 6 Dec 2011 13:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1323208266; bh=x8o1UuVstYXHmafZWmeYGMAZEAZwhtDNbQ1p5iS//oU=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version; b=j8FSCVEhZAoUGZj+9zYdUSL6ISYtUnYWvnqyU7+FGSevFgdXD64sjhs+rwV23omqq nAJrnX55HAUeFy8z4N7OkwM093+BHiK+pXv/iNxvUPhV6CR82ELI2OKAZjAPRe0XRW KxhKH2ee5uq2TqErsnfUGvJr4TMTerY8fbPFCjSU= From: Sean Bruno To: FreeBSD-Current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-cGPSJjL6CFH5/pHVht2A" Date: Tue, 06 Dec 2011 13:51:05 -0800 Message-ID: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Subject: Dog Food X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 21:51:26 -0000 --=-cGPSJjL6CFH5/pHVht2A Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Was trying to use gmirror(4) or zfs(4) today to get a machine in the cluster setup with s/w raid and was completely flummoxed by the intricacies of manual setup. Chances are, I just am not smart enough to wind my way though the various how tos and wiki pages that I've been browsing to get the job done. If someone wants to work on modifying bsdinstaller to do s/w raid via one of these mechanisms, clusteradm@ can provide you a two disk SATA machine that can be used for this purpose. Sean --=-cGPSJjL6CFH5/pHVht2A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAABAgAGBQJO3o5EAAoJEL2UHwafTLtO4xoIALfOHQZJHYpxpH/43Yx/OTbN /2xVpRDgfysvHpO9M5H3/u5e3hMy2nbKzZDBJq22+fM/OnrLl/tcyD3u2YBEWaOc GOZGhRFr2aGa0SWWkYTYSuRLqZkIf8UHqvc3zAXJ2bqXz4ZYp3id5PL2MEEmKKWU 9ltfRaUIplntt4q/lo8aCaDkcQQESMyQd4Glbhw1rvo6Wb5nWBBY71xPeJLlnyP+ OxDflgynMFD6IAzGEzXlZoEbBMKG+gJL5oPZS6mUfoO8f+L9gM1tAtJN4vBkgR8z oVm4WqOl1EuTl27X3K9bQrn6LU8au+mTjwxfyddsaYZ56t6/InXDJwgmUyjgF6o= =3oqE -----END PGP SIGNATURE----- --=-cGPSJjL6CFH5/pHVht2A-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 22:06:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D9A6106566C for ; Tue, 6 Dec 2011 22:06:44 +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 4CAF98FC12 for ; Tue, 6 Dec 2011 22:06:41 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-37-19.lns20.adl2.internode.on.net [118.210.37.19]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id pB6LRZmn090026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Dec 2011 07:57:41 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4EDE259B.4010502@digsys.bg> Date: Wed, 7 Dec 2011 07:57:35 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <48609D4C-44A7-45BB-8179-692185E8F80F@gsoft.com.au> References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> To: Daniel Kalchev X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 2.16 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 22:06:44 -0000 On 07/12/2011, at 24:54, Daniel Kalchev wrote: > It seems performance measurements are more dependent on the server = (nuttcp -S) machine. > We will have to rule out the interrupt storms first of course, any = advice? You can control the storm threshold by setting the = hw.intr_storm_threshold sysctl. -- 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 From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 22:11:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DD2A1065670; Tue, 6 Dec 2011 22:11:03 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 480288FC17; Tue, 6 Dec 2011 22:11:02 +0000 (UTC) Received: by lagv3 with SMTP id v3so1472487lag.13 for ; Tue, 06 Dec 2011 14:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mUmXWc+9NHugaaQqyaDh8vjvQTujtts/I1tR4xkS9kI=; b=WQn49LamWh3nUSt3HvCqIk9M0j3CvbZmoKTFIjkSgz0E59aPndUqBUw/p2HTq0xocW bnYe0w3mOU1LReW7TsN6ZsRCEL6IKe8TP7Vqgizmrzwfkg5XmzHSxi1uOQmq01pJaY6z 6BZRe1Pp2dHxAh/y8FT6b/U6Ir954IpfrXRzQ= MIME-Version: 1.0 Received: by 10.152.104.236 with SMTP id gh12mr10236562lab.49.1323209461166; Tue, 06 Dec 2011 14:11:01 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.152.21.104 with HTTP; Tue, 6 Dec 2011 14:11:01 -0800 (PST) In-Reply-To: <4EDE8931.1080506@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EDE8931.1080506@FreeBSD.org> Date: Tue, 6 Dec 2011 23:11:01 +0100 X-Google-Sender-Auth: Qw9LDTbXrPdH4Vh3LLWZ4o-7gio Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , arch@freebsd.org, current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 22:11:03 -0000 2011/12/6 Andriy Gapon : > on 06/12/2011 20:34 Attilio Rao said the following: > [snip] >> - I'm not entirely sure, why we want to disable interrupts at this >> moment (before to stop other CPUs)?: > > Because I believe that stop_cpus_hard() should run in a context with inte= rrupts > and preemption disabled. =C2=A0Also, I believe that the whole panic handl= ing =C2=A0code > should run in the same context. =C2=A0So it was only natural for me to en= ter that > context at this point. I'm not against that, I don't see anything wrong with having interrupts disabled at that point. >> @@ -547,13 +555,18 @@ panic(const char *fmt, ...) >> =C2=A0{ >> =C2=A0#ifdef SMP >> =C2=A0 =C2=A0 =C2=A0 static volatile u_int panic_cpu =3D NOCPU; >> + =C2=A0 =C2=A0 cpuset_t other_cpus; >> =C2=A0#endif >> =C2=A0 =C2=A0 =C2=A0 struct thread *td =3D curthread; >> =C2=A0 =C2=A0 =C2=A0 int bootopt, newpanic; >> =C2=A0 =C2=A0 =C2=A0 va_list ap; >> =C2=A0 =C2=A0 =C2=A0 static char buf[256]; >> >> - =C2=A0 =C2=A0 critical_enter(); >> + =C2=A0 =C2=A0 if (stop_scheduler_on_panic) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spinlock_enter(); >> + =C2=A0 =C2=A0 else >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 critical_enter(); >> + >> >> - In this chunk I don't entirely understand the kdb_active check: >> @@ -566,11 +579,18 @@ panic(const char *fmt, ...) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PCPU_GET(= cpuid)) =3D=3D 0) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 while (panic_cpu !=3D NOCPU) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; /* nothing */ >> + =C2=A0 =C2=A0 if (stop_scheduler_on_panic) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (panicstr =3D=3D NULL && = !kdb_active) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = other_cpus =3D all_cpus; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = CPU_CLR(PCPU_GET(cpuid), &other_cpus); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = stop_cpus_hard(other_cpus); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } >> + =C2=A0 =C2=A0 } >> =C2=A0#endif >> >> =C2=A0 =C2=A0 =C2=A0 bootopt =3D RB_AUTOBOOT; >> =C2=A0 =C2=A0 =C2=A0 newpanic =3D 0; >> - =C2=A0 =C2=A0 if (panicstr) >> + =C2=A0 =C2=A0 if (panicstr !=3D NULL) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bootopt |=3D RB_NOSYNC; >> =C2=A0 =C2=A0 =C2=A0 else { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bootopt |=3D RB_DUMP; >> >> Is it for avoiding to pass an empty mask to stop_cpus() in kdb_trap() >> (I saw you changed the policy there)? > > Yes. =C2=A0You know my position about elimination of the cpuset parameter= to > stop_cpus_* and my intention to do so. =C2=A0This is related to that. =C2= =A0Right now that > check is not strictly necessary, =C2=A0but it doesn't do any harm either.= =C2=A0We know > that all other CPUs are already stopped when kdb_active (ditto for panics= tr !=3D > NULL). I see there could be races with disabiling interrupts and having 2 different stopping mechanisms that want to stop cpus, even using stop_cpus_hard(), on architectures that don't use a privileged channel (NMI) as mostly of our !x86. They are mostly very rare races (requiring kdb_trap() and panic() to happen in parallel on different CPUs). >> Maybe we can find a better integration among the two. > > What kind of integration? > Right now I have simple model - both stop all other CPUs. Well, there is no synchronization atm between panic stopping cpus and the kdb_trap(). When kdb_trap() stop cpus it has interrupts disabled and if panic already started they will both deadlock because IPI_STOP won't be properly delivered. However, I see all this as a problem with other arches not having/not implementing a real dedicated channel for cpu_stop_hard(), so we should not think about it now. I think we may need some sort of control as panic already does with panic_cpu before to disable interrupts, but don't worry about it now. >> I'd also move the setting of stop_scheduler variable in the "if", it >> seems a bug to me to have it set otherwise. > > Can you please explain what bug do you suspect here? > I do not see any. I just see more natural to move it within the above if (panicstr =3D=3D NULL ...) condition. > [snip] >> - I'm not sure I like to change the policies on cpu stopping for KDB >> with this patchset. > > I am not sure what exactly you mean by change in policies. =C2=A0I do not= see any > such change, entering kdb always stops all other CPUs, with or without th= e patch. Yes, I was confused by older code did just stopped CPUs before kdb_trap() manually, I think what kdb_trap() does now is ok (and you just retain it). I'd just change this check on panicstr: @@ -606,9 +603,13 @@ kdb_trap(int type, int code, struct trapframe *tf) intr =3D intr_disable(); #ifdef SMP - other_cpus =3D all_cpus; - CPU_CLR(PCPU_GET(cpuid), &other_cpus); - stop_cpus_hard(other_cpus); + if (panicstr =3D=3D NULL) { + other_cpus =3D all_cpus; + CPU_CLR(PCPU_GET(cpuid), &other_cpus); + stop_cpus_hard(other_cpus); + did_stop_cpus =3D 1; + } else + did_stop_cpus =3D 0; to be SCHEDULER_STOPPED(). If you agree I can fix the kern_mutex, kern_sx and kern_rwlock parts and it should be done. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 23:26:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9BA6106564A; Tue, 6 Dec 2011 23:26:23 +0000 (UTC) (envelope-from andrew.w.nosenko@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AACD88FC0A; Tue, 6 Dec 2011 23:26:22 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so7517740wgb.31 for ; Tue, 06 Dec 2011 15:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YUWRSI2uetlwVZo3nckElsgGbVYeL/ZXcQ08olGiAKg=; b=r4/lR72VQHpU2FC0x6+Fpd6XaxGUVPITmKdXhQd/xiZ0JGfsgiFtkcuuOBJDyFsWoH ucDrNT7oJDXxMeZvEi6KChFuNHU6ugZOxcG+jhMo6eaULejwFuumIBZuhRmPg8MpZZ7f tw0FbC5DeLeNtaWZ8HjJRGzEropOmYftCysCc= MIME-Version: 1.0 Received: by 10.227.206.6 with SMTP id fs6mr3436748wbb.20.1323212337084; Tue, 06 Dec 2011 14:58:57 -0800 (PST) Received: by 10.227.181.74 with HTTP; Tue, 6 Dec 2011 14:58:57 -0800 (PST) In-Reply-To: <4EDE8C0E.7050806@FreeBSD.org> References: <4EDE474C.8090600@FreeBSD.org> <4EDE8816.7030505@FreeBSD.org> <4EDE8C0E.7050806@FreeBSD.org> Date: Wed, 7 Dec 2011 00:58:57 +0200 Message-ID: From: "Andrew W. Nosenko" To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 07 Dec 2011 02:01:24 +0000 Cc: FreeBSD current , Martin Matuska , FreeBSD Ports Subject: Re: binutils-2.22: ld and --copy-dt-needed-entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 23:26:23 -0000 On Tue, Dec 6, 2011 at 23:41, Andriy Gapon wrote: > on 06/12/2011 23:24 Martin Matuska said the following: >> On 6.12.2011 17:48, Andriy Gapon wrote: >>> Just for your information. >>> It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-= entries >>> behavior, and so explicit --copy-dt-needed-entries is now needed where = the >>> previous default behavior is relied upon. >>> >>> A short excerpt from the man page for your convenience: >>> >>>> This option also has an effect on the resolution of symbols in >>>> dynamic libraries. =A0With --copy-dt-needed-entries dynamic libraries >>>> mentioned on the command line will be recursively searched, >>>> following their DT_NEEDED tags to other libraries, in order to >>>> resolve symbols required by the output binary. =A0With the default >>>> setting however the searching of dynamic libraries that follow it >>>> will stop with the dynamic library itself. =A0No DT_NEEDED links will >>>> be traversed to resolve symbols. >> What do we do with this? >> We can go back, patch to behave as before or to continue. >> Are there any serious complaints? > > I am not sure. =A0Eventually all upstreams of our ports will have to deal= with > this. =A0So far I've encountered only one problematic port (gegl) that li= nks a > binary with -lglib-2.0 expecting that a required -liconv dependency would= be > automatically picked up via DT_NEEDED. =A0libglib-2.0.so indeed has a DT_= NEEDED > entry for libiconv.so. =A0But this dependency is not explicitly advertise= d via > pkg-config metadata: > $ fgrep -i Libs /usr/local/libdata/pkgconfig/glib-2.0.pc > Libs: -L${libdir} -lglib-2.0 > Libs.private: -liconv > > So there could be other issues related to this in the future. > Perhaps this is actually an issue with glib, maybe it should have -liconv= in > Libs. =A0I am not really knowledgeable about his stuff. As far, as I understand the http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html , https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition , http://old.nabble.com/Make-no-copy-dt-needed-default--td32272377.html , correctly 1. upstreams (e.g. Glib) had a pretty much time for test this change. 2. If I just use Glib (for example), then all Glib's iconv-related stuffs will continue to work, I don't need to explicitly add -liconv. All that fail if I use iconv_open() (for example) directly and (bypassing Glib) and rely on Glib to load libiconv as side-effect. Of courcse, it would be quite wrong from my side because existence of libconv as an Glib charset conversion engine is an implementation detail that may change at the some day or just because of different configuration options. Just like GnuTLS swtiched from libgcrypt to libnettle. 3. Of course, something may fail, but I would not to expect a big amount of failures (due to the fact that major Linux distros already there) --=20 Andrew W. Nosenko From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 04:56:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB79D106566C; Wed, 7 Dec 2011 04:56:33 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 632DC8FC15; Wed, 7 Dec 2011 04:56:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RY9YW-0006zF-IB>; Wed, 07 Dec 2011 05:56:32 +0100 Received: from e178014173.adsl.alicedsl.de ([85.178.14.173] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RY9YW-0006nA-BG>; Wed, 07 Dec 2011 05:56:32 +0100 Message-ID: <4EDEF1FF.5020307@zedat.fu-berlin.de> Date: Wed, 07 Dec 2011 05:56:31 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org, Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA91E2862F7ED83A63FB7335F" X-Originating-IP: 85.178.14.173 Cc: Subject: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 04:56:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA91E2862F7ED83A63FB7335F Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello. On FreeBSD 10.0-CURRENT/amd64 I run into the error shown below when updating the installation of the gcc46 compiler suite. The OS has been compiled via CLANG, binutils 2.22 are installed and has been installed either with the UNAME_r settings and WITH_FBSD10_FIX set in /etc/make.conf. I was wondering whether others would also see this on CURRENT. On all FreeBSD 9.0 boxes gcc46 compiles well. Regards, Oliver =3D=3D=3D=3D Configuring stage 1 in ./gcc clang -O3 -fno-strict-aliasing -pipe -march=3Dnative -I/usr/local/include= -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a echo timestamp > full-stamp gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/build-x86_64-portbld-freebsd9.9/fixincl= udes' gmake[3]: Entering directory `/usr/ports/lang/gcc46/work/build/libcpp' clang -I.././../gcc-4.6-20111202/libcpp -I. -I.././../gcc-4.6-20111202/libcpp/../include -I.././../gcc-4.6-20111202/libcpp/include -g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -I.././../gcc-4.6-20111202/libcpp -I. -I.././../gcc-4.6-20111202/libcpp/../include -I.././../gcc-4.6-20111202/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo .././../gcc-4.6-20111202/libcpp/charset.c =2E././../gcc-4.6-20111202/libcpp/charset.c:1371:1: error: conflicting types for 'cpp_interpret_string' cpp_interpret_string (cpp_reader *pfile, const cpp_string *from, size_t count, ^ =2E././../gcc-4.6-20111202/libcpp/include/cpplib.h:742:13: note: previous= declaration is here extern bool cpp_interpret_string (cpp_reader *, ^ =2E././../gcc-4.6-20111202/libcpp/charset.c:1452:1: error: conflicting types for 'cpp_interpret_string_notranslate' cpp_interpret_string_notranslate (cpp_reader *pfile, const cpp_string *fr= om, ^ =2E././../gcc-4.6-20111202/libcpp/include/cpplib.h:745:13: note: previous= declaration is here extern bool cpp_interpret_string_notranslate (cpp_reader *, ^ 2 errors generated. gmake[3]: *** [charset.o] Error 1 gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/libcpp' gmake[2]: *** [all-stage1-libcpp] Error 2 gmake[2]: *** Waiting for unfinished jobs.... configure: creating cache ./config.cache checking build system type... x86_64-portbld-freebsd9.9 checking host system type... x86_64-portbld-freebsd9.9 checking target system type... x86_64-portbld-freebsd9.9 checking LIBRARY_PATH variable... ok checking GCC_EXEC_PREFIX variable... ok [...] checking linker *_sol2 emulation support... no checking linker --sysroot support... yes checking __stack_chk_fail in target C library... checking for __stack_chk_fail... yes yes checking dl_iterate_phdr in target C library... unknown Using ggc-page for garbage collection. checking whether to enable maintainer-specific portions of Makefiles... n= o Links are now set up to build a native compiler for x86_64-portbld-freebsd9.9. checking for exported symbols... yes checking for -rdynamic... yes checking for library containing dlopen... none required checking for -fPIC -shared... yes configure: updating cache ./config.cache configure: creating ./config.status config.status: creating as config.status: creating collect-ld config.status: creating nm config.status: creating Makefile config.status: creating ada/gcc-interface/Makefile config.status: creating ada/Makefile config.status: creating auto-host.h config.status: executing default commands gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 1 Stop in /usr/ports/lang/gcc46. *** Error code 1 Stop in /usr/ports/lang/gcc46. =3D=3D=3D>>> make failed for lang/gcc46 =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Update for lang/gcc46 failed =3D=3D=3D>>> Aborting update =3D=3D=3D>>> You can restart from the point of failure with this command = line: portmaster lang/gcc46 --------------enigA91E2862F7ED83A63FB7335F 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 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO3vH/AAoJEOgBcD7A/5N8Rl4H/1uFfc1HYxrwdE+XiQWBluBr duLk2cispRveqzaKv94n+1pPNz3X8qc5tw08l1uL71n4OkaUPme/ZQ8jqbtTIJ7c ZeKvoqtabw50hjQqOhskg7Icyy7IJnu7s/C2bKA3nR/Pb/4xMyqTnrX9JMnqG9Jt W4eQ4jNQSc55F9RWEUyFdTNmDsoLCf9XC6UhktMGKKjey+LXZLtr0mNYCii5MlEK 3HVAZUuPAAsHU6ER1KlGE98Z8vwyR+285TXtAiAg4Ifzfz4rEWqJEnQCN1yLLmJC tsAuWUMgNSK1tpAVcdvVstGpeV/INNkb4hFBh2tYmNH90yyvFBk4b/2MBAQ5xgY= =nxqp -----END PGP SIGNATURE----- --------------enigA91E2862F7ED83A63FB7335F-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 06:11:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814D2106564A; Wed, 7 Dec 2011 06:11:38 +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 62BB88FC12; Wed, 7 Dec 2011 06:11:38 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pB76BbSA038927; Tue, 6 Dec 2011 22:11:37 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pB76Bbne038926; Tue, 6 Dec 2011 22:11:37 -0800 (PST) (envelope-from sgk) Date: Tue, 6 Dec 2011 22:11:37 -0800 From: Steve Kargl To: "O. Hartmann" Message-ID: <20111207061137.GA38900@troutmask.apl.washington.edu> References: <4EDEF1FF.5020307@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EDEF1FF.5020307@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 06:11:38 -0000 On Wed, Dec 07, 2011 at 05:56:31AM +0100, O. Hartmann wrote: > config.status: creating ada/Makefile > config.status: creating auto-host.h > config.status: executing default commands > gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' > gmake[1]: *** [stage1-bubble] Error 2 > gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' > gmake: *** [bootstrap-lean] Error 2 > *** Error code 1 > > Stop in /usr/ports/lang/gcc46. > *** Error code 1 > > Stop in /usr/ports/lang/gcc46. > > ===>>> make failed for lang/gcc46 > ===>>> Aborting update > See if setting DISABLE_MAKE_JOBSi helps. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 07:41:37 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 467951065673; Wed, 7 Dec 2011 07:41:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 302918FC0A; Wed, 7 Dec 2011 07:41:35 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA19088; Wed, 07 Dec 2011 09:41:33 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RYC8D-0001FM-IM; Wed, 07 Dec 2011 09:41:33 +0200 Message-ID: <4EDF18AA.2070509@FreeBSD.org> Date: Wed, 07 Dec 2011 09:41:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EDE8931.1080506@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 07:41:37 -0000 on 07/12/2011 00:11 Attilio Rao said the following: > I'd just change this check on panicstr: > @@ -606,9 +603,13 @@ kdb_trap(int type, int code, struct trapframe *tf) > intr = intr_disable(); > > #ifdef SMP > - other_cpus = all_cpus; > - CPU_CLR(PCPU_GET(cpuid), &other_cpus); > - stop_cpus_hard(other_cpus); > + if (panicstr == NULL) { > + other_cpus = all_cpus; > + CPU_CLR(PCPU_GET(cpuid), &other_cpus); > + stop_cpus_hard(other_cpus); > + did_stop_cpus = 1; > + } else > + did_stop_cpus = 0; > > to be SCHEDULER_STOPPED(). Makes sense. I will do this. > If you agree I can fix the kern_mutex, kern_sx and kern_rwlock parts > and it should be done. Since I am not very familiar with the details of that code, I can not be against such a proposal :-) What Kostik did seemed quite reasonable to me, but if that can be further improved, then I am all for it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 08:32:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC02A1065672; Wed, 7 Dec 2011 08:32:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7F18FC12; Wed, 7 Dec 2011 08:32:25 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8945:f03a:980c:c72] (unknown [IPv6:2001:7b8:3a7:0:8945:f03a:980c:c72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B1CBA5C37; Wed, 7 Dec 2011 09:32:24 +0100 (CET) Message-ID: <4EDF249B.8030104@FreeBSD.org> Date: Wed, 07 Dec 2011 09:32:27 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111130 Thunderbird/9.0 MIME-Version: 1.0 To: "O. Hartmann" References: <4EDEF1FF.5020307@zedat.fu-berlin.de> In-Reply-To: <4EDEF1FF.5020307@zedat.fu-berlin.de> Content-Type: multipart/mixed; boundary="------------020204010301000803080705" Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 08:32:25 -0000 This is a multi-part message in MIME format. --------------020204010301000803080705 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit On 2011-12-07 05:56, O. Hartmann wrote: > On FreeBSD 10.0-CURRENT/amd64 I run into the error shown below when > updating the installation of the gcc46 compiler suite. If you report port compilation errors, always use DISABLE_MAKE_JOBS, otherwise the actual error message will drown in multithreaded spam. :) (And even if you would save and post the full build log, it is sometimes still impossible to see which exact command failed and why.) That said, you are most likely running into an issue with the fix for FreeBSD 10-CURRENT in bsd.port.mk, causing the lto-plugin stage configure script to fail. This is because the gcc ports unpack their source code into ${WRKDIR}/gcc-${VERSIONSTRING}, and then override WRKSRC to ${WRKDIR}/build. Since bsd.port.mk only applies the run-autotools-fixup to ${WRKSRC}, the gcc source itself is not properly fixed up. You can try the attached patch, which fixes this (and fixes it for all other ports that override WKRSRC). --------------020204010301000803080705 Content-Type: text/x-diff; name="ports-fbsd10-wrkdir-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ports-fbsd10-wrkdir-1.diff" Index: Mk/bsd.port.mk =================================================================== RCS file: /home/mirror/ncvs/ports/Mk/bsd.port.mk,v retrieving revision 1.699 diff -u -r1.699 bsd.port.mk --- Mk/bsd.port.mk 9 Nov 2011 08:53:12 -0000 1.699 +++ Mk/bsd.port.mk 7 Dec 2011 08:16:56 -0000 @@ -3663,7 +3663,7 @@ run-autotools-fixup: # Work around an issue where FreeBSD 10.0 is detected as FreeBSD 1.x. .if ${OSVERSION} >= 1000000 && !defined(WITHOUT_FBSD10_FIX) - -@for f in `${FIND} ${WRKSRC} -type f \( -name config.libpath -o \ + -@for f in `${FIND} ${WRKDIR} -type f \( -name config.libpath -o \ -name config.rpath -o -name configure -o -name libtool.m4 -o \ -name ltconfig -o -name libtool -o -name aclocal.m4 -o \ -name acinclude.m4 \)` ; do \ --------------020204010301000803080705-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 09:02:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBD851065670 for ; Wed, 7 Dec 2011 09:02:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm10-vm0.bullet.mail.sp2.yahoo.com (nm10-vm0.bullet.mail.sp2.yahoo.com [98.139.91.198]) by mx1.freebsd.org (Postfix) with SMTP id 9B61C8FC0C for ; Wed, 7 Dec 2011 09:02:48 +0000 (UTC) Received: from [98.139.91.62] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 07 Dec 2011 09:02:48 -0000 Received: from [208.71.42.194] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 07 Dec 2011 09:02:48 -0000 Received: from [127.0.0.1] by smtp205.mail.gq1.yahoo.com with NNFMP; 07 Dec 2011 09:02:48 -0000 X-Yahoo-Newman-Id: 290288.94684.bm@smtp205.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Exw3uqgVM1mJvCr85C2jz6Tv.LhtoserMtf.6W9suziasSz IGP_6STaYlidq.ducYc1o6BgsOa4C_yszrD6OY5q_gNqC2xhaC9HRf4fqH1L Fu3IkuwLE5fWBuGRfoFq1tKsY4tvUTsqq28Bmo4EYgDYwmRnchrb7f6ARTRq ACbscY4EBztt_9_PA5T4yXvhTdyyi4ndKLtxDxrtx1TEdrqoV2DlQ7uSlqcm IZoZs5TsoBrdTaT0jkGz_TvC2ThIshYx6GBqJgnqzRDxMihlR7RU_nSdRToE .4SdxJx7WUzp5bYk.wWYxeAkrWL_rahjBnbW1zzxixj5xFmMmN1hGfJ3v.Fe Xq5vwu4UCL3BVzz5RfXt4LsVfoGvdcY6UYzIe9.mbn2reCndCGBrrnPcxGjB 9.1LqBQ3ys6Jn4j6f13P99OchxxPryO664HEO5j1nR8r24hqjVgcU4jCEBVt zkirm X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.150.195 with plain) by smtp205.mail.gq1.yahoo.com with SMTP; 07 Dec 2011 01:02:48 -0800 PST Message-ID: <4EDF2BB5.10602@freebsd.org> Date: Wed, 07 Dec 2011 10:02:45 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dim@FreeBSD.org References: <4EDEF1FF.5020307@zedat.fu-berlin.de> <4EDF249B.8030104@FreeBSD.org> In-Reply-To: <4EDF249B.8030104@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Extend search range of FreeBSD-10 libtools/configure fixup (was: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 09:02:48 -0000 Am 07.12.2011 09:32, schrieb Dimitry Andric: > That said, you are most likely running into an issue with the fix for > FreeBSD 10-CURRENT in bsd.port.mk, causing the lto-plugin stage > configure script to fail. > > This is because the gcc ports unpack their source code into > ${WRKDIR}/gcc-${VERSIONSTRING}, and then override WRKSRC to > ${WRKDIR}/build. Since bsd.port.mk only applies the run-autotools-fixup > to ${WRKSRC}, the gcc source itself is not properly fixed up. > > You can try the attached patch, which fixes this (and fixes it for all > other ports that override WKRSRC). I had solved a similar problem for BDB a few weeks back and made the same modification (start searching in WRKDIR instead of in WRKSRC). This leads to (minimally) higher run time for the fixup, but it should make a number of ports currently broken on FBSD10 automagically build again ... And the pattern for libtool/configure type files should sufficiently prevent patching of files not touched by the current invocation of "find". SO I'd vote to get that patch into SVN ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 09:30:10 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74E3F106564A for ; Wed, 7 Dec 2011 09:30:10 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 1B24C8FC17 for ; Wed, 7 Dec 2011 09:30:09 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 8537D3CF; Wed, 7 Dec 2011 10:30:06 +0100 (CET) Date: Wed, 7 Dec 2011 10:29:07 +0100 From: Pawel Jakub Dawidek To: d@delphij.net Message-ID: <20111207092907.GA1645@garage.freebsd.pl> References: <4E0A5689.2020302@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <4E0A5689.2020302@delphij.net> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current Subject: Re: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 09:30:10 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 28, 2011 at 03:32:41PM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi, >=20 > I'd like to request for comments on the attached driver, which supports > watchdogs on several Winbond super I/O chip models and have been tested > on a few of recent Supermicro motherboards. Is there any reason this is not yet committed? Please commit, pretty please. One minor problem I found is described below. Other than that it works for me, thanks! [...] > +static void > +winbondwd_event(void *arg, unsigned int cmd, int *error) > +{ > + struct winbondwd_softc *sc =3D arg; > + unsigned char rtimeout; > + uint64_t timeout; > + > + if (cmd =3D=3D 0) > + winbondwd_set_timeout(sc, 0); > + else { > + timeout =3D (uint64_t)1 << (cmd & WD_INTERVAL); > + if (timeout < (uint64_t)0xff * 1000 * 1000 * 1000) { > + rtimeout =3D timeout / (1000 * 1000 * 1000); > + if (rtimeout =3D=3D 0) > + rtimeout =3D 0xff; > + winbondwd_set_timeout(sc, rtimeout); > + } else { > + device_printf(sc->device, > + "Value %u too big, disabling\n", cmd & WD_INTERVAL); > + /* Proposed timeout can not be satisified */ > + winbondwd_set_timeout(sc, 0); > + } You should add '*error =3D 0;' right here. Without it we return some random error, in my case watchdgod is able to arm the watchdog but exits when trying to pat it, as it gets an error, which leads to a reset short aferwards. > + } > +} --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk7fMeMACgkQForvXbEpPzTg4ACg6n5LNqN3cNW4yBiWZ0vTVDeB JCMAniBz2kXsKcfpyxe96ifN/roR6eHN =CqVQ -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 10:17:11 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A04661065670; Wed, 7 Dec 2011 10:17:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 32A0F8FC18; Wed, 7 Dec 2011 10:17:11 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F30C625D3811; Wed, 7 Dec 2011 10:17:09 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id D0E6ABD67AF; Wed, 7 Dec 2011 10:17:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 2Qfii2vtRg8j; Wed, 7 Dec 2011 10:17:07 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 85A1DBD67AE; Wed, 7 Dec 2011 10:17:07 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20111207092907.GA1645@garage.freebsd.pl> Date: Wed, 7 Dec 2011 10:17:06 +0000 Content-Transfer-Encoding: 7bit Message-Id: <7BD6CA15-3329-4684-8127-665CDC171B22@lists.zabbadoz.net> References: <4E0A5689.2020302@delphij.net> <20111207092907.GA1645@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Current , d@delphij.net Subject: Re: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 10:17:11 -0000 On 7. Dec 2011, at 09:29 , Pawel Jakub Dawidek wrote: > On Tue, Jun 28, 2011 at 03:32:41PM -0700, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi, >> >> I'd like to request for comments on the attached driver, which supports >> watchdogs on several Winbond super I/O chip models and have been tested >> on a few of recent Supermicro motherboards. > > Is there any reason this is not yet committed? Please commit, pretty > please. Yes we have 2+ of them and are trying to merge. The other one sits here and allows you even longer timeouts as well as time setting the timeout independent of watchdogd in case you have two watchdogs and want to do tricks like NMI/reset with the other one... but is lacking the man page yet. I have added another one or two IC revisions I think that I had found and tested privately. http://people.freebsd.org/~bz/patch-20110710-03-wbwd.diff /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 10:56:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F079E1065673 for ; Wed, 7 Dec 2011 10:56:08 +0000 (UTC) (envelope-from jbeich@tormail.net) Received: from server2.hudsonvalleyhost.com (server2.hudsonvalleyhost.com [66.7.195.77]) by mx1.freebsd.org (Postfix) with ESMTP id BCCFB8FC0C for ; Wed, 7 Dec 2011 10:56:08 +0000 (UTC) Received: from raskin.torservers.net ([74.120.15.150]:33271 helo=internal.tormail.net) by server2.hudsonvalleyhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RYFAU-003aDw-3y; Wed, 07 Dec 2011 05:56:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.net; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:Date:References:In-Reply-To:Subject:Cc:To:From; bh=Es7Dxtivu0jgOVidPfIaUcrSgMwZQxb7Egtw5OUehcM=; b=QJQ7m/dhMJtrfU6Sx+gvmJuRSGiMfomoyYI5/Fh91BUQ/qwTVRdqHGabhvaiiA19SnvYJNHYDVgaorF7guXwLHNaG2F5JXD53bRDFAW3E02wkIH9cQ8hXB4M7vyqEg7uwjmeLo9zXKbqmwH6Qeg7MdB82IJtsGhJYnc8/0WrBHk=; Received: from jbeich by internal.tormail.net with local (Exim 4.63) (envelope-from ) id 1RYF8c-000FNm-KW; Wed, 07 Dec 2011 10:54:24 +0000 From: Jan Beich To: "O. Hartmann" In-Reply-To: <4EDEF1FF.5020307@zedat.fu-berlin.de> (O. Hartmann's message of "Wed, 07 Dec 2011 05:56:31 +0100") References: <4EDEF1FF.5020307@zedat.fu-berlin.de> Date: Wed, 07 Dec 2011 07:52:00 -0300 MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1RYF8c-000FNm-KW@internal.tormail.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.hudsonvalleyhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 10:56:09 -0000 "O. Hartmann" writes: > .././../gcc-4.6-20111202/libcpp/charset.c:1371:1: error: conflicting > types for 'cpp_interpret_string' > cpp_interpret_string (cpp_reader *pfile, const cpp_string *from, size_t > count, > ^ > .././../gcc-4.6-20111202/libcpp/include/cpplib.h:742:13: note: previous > declaration is here > extern bool cpp_interpret_string (cpp_reader *, > ^ Have you built world WITH_ICONV= ? Try the 2nd patch in ports/161417. ports/163103 confirms the issue is not related to clang, nor 10-CURRENT. From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 11:26:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1B0106566B for ; Wed, 7 Dec 2011 11:26:23 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 63F358FC1E for ; Wed, 7 Dec 2011 11:26:22 +0000 (UTC) Received: (qmail 66075 invoked from network); 7 Dec 2011 09:30:27 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Dec 2011 09:30:27 -0000 Message-ID: <4EDF471F.1030202@freebsd.org> Date: Wed, 07 Dec 2011 11:59:43 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> In-Reply-To: <20111206210625.GB62605@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Jack Vogel , Daniel Kalchev Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 11:26:23 -0000 On 06.12.2011 22:06, Luigi Rizzo wrote: > On Tue, Dec 06, 2011 at 07:40:21PM +0200, Daniel Kalchev wrote: >> I see significant difference between number of interrupts on the Intel and the AMD blades. When performing a test between the Intel and AMD blades, the Intel blade generates 20,000-35,000 interrupts, while the AMD blade generates under 1,000 interrupts. >> > > Even in my experiments there is a lot of instability in the results. > I don't know exactly where the problem is, but the high number of > read syscalls, and the huge impact of setting interrupt_rate=0 > (defaults at 16us on the ixgbe) makes me think that there is something > that needs investigation in the protocol stack. > > Of course we don't want to optimize specifically for the one-flow-at-10G > case, but devising something that makes the system less affected > by short timing variations, and can pass upstream interrupt mitigation > delays would help. I'm not sure the variance is only coming from the network card and driver side of things. The TCP processing and interactions with scheduler and locking probably play a big role as well. There have been many changes to TCP recently and maybe an inefficiency that affects high-speed single sessions throughput has crept in. That's difficult to debug though. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 12:44:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C1ED106564A; Wed, 7 Dec 2011 12:44:00 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3B68FC0A; Wed, 7 Dec 2011 12:43:59 +0000 (UTC) Received: by bkbzv15 with SMTP id zv15so252415bkb.13 for ; Wed, 07 Dec 2011 04:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=7RMiK1p5E2VQWRfxNXAIQhKkfJqpeco1HSDM1ooCbww=; b=aci/GJt9UxU+jstjs2USDnPRu3W5PkzaEMLeZZjxbTHUto+2LbrPbLshjMEXiaD8+I m9xnwlsuFUAmp4EyWsVHj6aKKx3UB4zf4GS+AmzJcjJMMc0UTgsp6VMb4ha+Pv4YiSKJ yOVACA3ssxrXfJ2QJMjfz6qpOwGdTkfNvedz4= MIME-Version: 1.0 Received: by 10.180.94.195 with SMTP id de3mr17616259wib.14.1323261838214; Wed, 07 Dec 2011 04:43:58 -0800 (PST) Received: by 10.180.94.131 with HTTP; Wed, 7 Dec 2011 04:43:58 -0800 (PST) Date: Wed, 7 Dec 2011 12:43:58 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org, Stefan Esser , miwi@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Extend search range of FreeBSD-10 libtools/configure fixup (was: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 12:44:01 -0000 > Am 07.12.2011 09:32, schrieb Dimitry Andric: > > That said, you are most likely running into an issue with the fix for > > FreeBSD 10-CURRENT in bsd.port.mk, causing the lto-plugin stage > > configure script to fail. > > > > This is because the gcc ports unpack their source code into > > ${WRKDIR}/gcc-${VERSIONSTRING}, and then override WRKSRC to > > ${WRKDIR}/build. Since bsd.port.mk only applies the run-autotools-fixup > > to ${WRKSRC}, the gcc source itself is not properly fixed up. > > > > You can try the attached patch, which fixes this (and fixes it for all > > other ports that override WKRSRC). > > I had solved a similar problem for BDB a few weeks back and made the > same modification (start searching in WRKDIR instead of in WRKSRC). > > This leads to (minimally) higher run time for the fixup, but it should > make a number of ports currently broken on FBSD10 automagically build > again ... > > And the pattern for libtool/configure type files should sufficiently > prevent patching of files not touched by the current invocation of "find". > > SO I'd vote to get that patch into SVN ... We've had a patch to do this, and make a few other related changes, for about a month now. I'm not sure why it hasn't gone into bsd.port.mk yet -- perhaps Martin had some other work to do -- but I think that it will appear soon. b. From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 16:27:09 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC51E1065670; Wed, 7 Dec 2011 16:27:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2128FC0C; Wed, 7 Dec 2011 16:27:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA00337; Wed, 07 Dec 2011 18:27:06 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDF93DA.3060301@FreeBSD.org> Date: Wed, 07 Dec 2011 18:27:06 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Bernhard Froehlich References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> "<7c3c9505867f4528af276a571077b9ce@bluelife.at>" <4EDCC1C6.3040109@FreeBSD.org> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org> <4EDD5CEB.1020502@rice.edu> <4EDDDB7A.4050604@FreeBSD.org> <4EDDF91F.10308@FreeBSD.org> <5ca321038ae3f35c630aa29f5031d1d5@bluelife.at> <4EDE7977.7010800@FreeBSD.org> In-Reply-To: <4EDE7977.7010800@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@FreeBSD.org, FreeBSD current , vbox@FreeBSD.org Subject: Re: virtualbox r0 memory management update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:27:10 -0000 on 06/12/2011 22:22 Andriy Gapon said the following: > > Could you please change that line as follows? > vm_page_t pPage = pPages +iPage; > Additionally the patch has another bug. Here is a patch on top of the previous patch: --- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig2 2011-12-07 18:15:48.695189924 +0200 +++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2011-12-07 18:17:35.359192030 +0200 @@ -251,7 +251,7 @@ static int FreeBSDPhysAllocHelper(vm_obj vm_page_free(pPage); vm_page_unlock_queues(); } - VM_OBJECT_LOCK(pObject); + VM_OBJECT_UNLOCK(pObject); return VERR_NO_MEMORY; } } -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 16:50:39 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C3FE106564A; Wed, 7 Dec 2011 16:50:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 586478FC13; Wed, 7 Dec 2011 16:50:36 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA00766; Wed, 07 Dec 2011 18:50:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDF995B.9000407@FreeBSD.org> Date: Wed, 07 Dec 2011 18:50:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:50:39 -0000 (kgdb) bt #0 doadump (textdump=1) at pcpu.h:224 #1 0xffffffff804f6d3b in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff804f63e9 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:635 #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 #4 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, cnp=0xffffff82393b3708, nameiop=0, cr=0xfffffe0042e88100, td=0xfffffe000fdfa480, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 #5 0xffffffff81a91570 in zfs_freebsd_lookup (ap=0xffffff82393b32c0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858 #6 0xffffffff8073f054 in VOP_CACHEDLOOKUP_APV (vop=0xffffffff81b05a20, a=0xffffff82393b32c0) at vnode_if.c:187 #7 0xffffffff80586bf4 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at vnode_if.h:80 #8 0xffffffff80740a5c in VOP_LOOKUP_APV (vop=0xffffffff81b05a20, a=0xffffff82393b33a0) at vnode_if.c:123 #9 0xffffffff8058e42c in lookup (ndp=0xffffff82393b36a0) at vnode_if.h:54 #10 0xffffffff8058f17e in namei (ndp=0xffffff82393b36a0) at /usr/src/sys/kern/vfs_lookup.c:312 #11 0xffffffff805a890d in vn_open_cred (ndp=0xffffff82393b36a0, flagp=0xffffff82393b3918, cmode=0, vn_open_flags=Variable "vn_open_flags" is not available. ) at /usr/src/sys/kern/vfs_vnops.c:195 #12 0xffffffff80589e7e in vop_stdvptocnp (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_default.c:774 #13 0xffffffff8073b012 in VOP_VPTOCNP_APV (vop=0xffffffff80a99140, a=0xffffff82393b39b0) at vnode_if.c:3479 #14 0xffffffff80584665 in vn_vptocnp_locked (vp=0xffffff82393b3a50, cred=0xfffffe0042e88100, buf=0xfffffe000ca06000 "������������������������������������������������������������������������������������������������������������������������������������������������������"..., buflen=0xffffff82393b3a4c) at vnode_if.h:1564 #15 0xffffffff80584bab in vn_fullpath1 (td=0xfffffe000fdfa480, vp=0xfffffe003d4763c0, rdir=0xfffffe000cd4d000, buf=0xfffffe000ca06000 "������������������������������������������������������������������������������������������������������������������������������������������������������"..., retbuf=0xffffff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218 #16 0xffffffff8058526a in kern___getcwd (td=0xfffffe000fdfa480, buf=0x80880a000
, bufseg=UIO_USERSPACE, buflen=1024) at /usr/src/sys/kern/vfs_cache.c:960 #17 0xffffffff805853f4 in sys___getcwd (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_cache.c:934 #18 0xffffffff806d2069 in amd64_syscall (td=0xfffffe000fdfa480, traced=0) at subr_syscall.c:131 #19 0xffffffff806bb4e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #20 0x00000008031adb2c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 3 #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 726 KASSERT(vp == NULL || vp->v_type == VDIR, (kgdb) list 721 if (dvp->v_cache_dd != NULL) { 722 CACHE_WUNLOCK(); 723 cache_free(ncp); 724 return; 725 } 726 KASSERT(vp == NULL || vp->v_type == VDIR, 727 ("wrong vnode type %p", vp)); 728 dvp->v_cache_dd = ncp; 729 } 730 (kgdb) p *vp $1 = {v_type = VREG, v_tag = 0xffffffff81afe449 "zfs", v_op = 0xffffffff81b05a20, v_data = 0xfffffe020d9a8320, v_mount = 0xfffffe001a283600, v_nmntvnodes = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = { lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfffffe003dfcf690, tqh_last = 0xfffffe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0xffffffff81afe449 "zfs", lo_flags = 91947008, lo_data = 0, lo_witness = 0xffffff800066e380}, lk_lock = 18446741874952610944, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = {lo_name = 0xffffffff807e610a "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff8000665600}, mtx_lock = 4}, v_vnlock = 0xfffffe0142517098, v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe02110d3e30}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff807efdfa "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff800066c300}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517140}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517160}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80a95ec0, bo_bsize = 131072, bo_object = 0xfffffe01fccb5620, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffffe0142517000, __bo_vnode = 0xfffffe0142517000}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 17:04:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EBAA1065673; Wed, 7 Dec 2011 17:04:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 48A588FC0A; Wed, 7 Dec 2011 17:04:25 +0000 (UTC) Received: by lagv3 with SMTP id v3so435897lag.13 for ; Wed, 07 Dec 2011 09:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E9zrRUEp5DEeTTKf4PwUo6guthOx1ZReH1BD2rtV28k=; b=vQgNUOR1JND5tB8XE/75W1evH/3nYu9EC5o7YYjXZbU9SyfIdJ/RxQpB9mFqyhbpxL 4uzUqas1L6Y09bsFo4E0vioQjETKmTys5BO2rhrZQnfQ7kZCgtF3q/KwAeMHnk975MLE UP2DlmxR1ymO3GX4VEQnjo/dvJnZ12rGsjaE0= MIME-Version: 1.0 Received: by 10.152.146.100 with SMTP id tb4mr12404786lab.0.1323277464964; Wed, 07 Dec 2011 09:04:24 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.152.21.104 with HTTP; Wed, 7 Dec 2011 09:04:23 -0800 (PST) In-Reply-To: <4EDF18AA.2070509@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EDE8931.1080506@FreeBSD.org> <4EDF18AA.2070509@FreeBSD.org> Date: Wed, 7 Dec 2011 18:04:23 +0100 X-Google-Sender-Auth: 3VTSG5NIDt_2dVxzKFjRWiATR7w Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , arch@freebsd.org, current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:04:27 -0000 2011/12/7 Andriy Gapon : > on 07/12/2011 00:11 Attilio Rao said the following: >> I'd just change this check on panicstr: >> @@ -606,9 +603,13 @@ kdb_trap(int type, int code, struct trapframe *tf) >> =C2=A0 =C2=A0 =C2=A0 intr =3D intr_disable(); >> >> =C2=A0#ifdef SMP >> - =C2=A0 =C2=A0 other_cpus =3D all_cpus; >> - =C2=A0 =C2=A0 CPU_CLR(PCPU_GET(cpuid), &other_cpus); >> - =C2=A0 =C2=A0 stop_cpus_hard(other_cpus); >> + =C2=A0 =C2=A0 if (panicstr =3D=3D NULL) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other_cpus =3D all_cpus; >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CPU_CLR(PCPU_GET(cpuid), &ot= her_cpus); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stop_cpus_hard(other_cpus); >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 did_stop_cpus =3D 1; >> + =C2=A0 =C2=A0 } else >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 did_stop_cpus =3D 0; >> >> to be SCHEDULER_STOPPED(). > > Makes sense. =C2=A0I will do this. > >> If you agree I can fix the kern_mutex, kern_sx and kern_rwlock parts >> and it should be done. > > Since I am not very familiar with the details of that code, I can not be = against > such a proposal :-) =C2=A0What Kostik did seemed quite reasonable to me, = but if that > can be further improved, then I am all for it. The following patch is a further add-on on Kostik's: http://www.freebsd.org/~attilio/scheduler_stopped.patch - Rework of mutex, rwlock and sxlock for a correct dealing of hard and fast paths - Protection of LOCK_PROFILING bits (missed also in my review) - Protection of WITNESS_SAVE/RESTORE because of Giant handling (missed also in my review) - Removal of gratuitous whitelines - Usage of SCHEDULER_STOPPED() in kdb check What do you think about it? I just test-compiled it with several combinations of LOCK_PROFILING and LOCK_DEBUG, but I didn't change the bulk of it thus it should be perfectly fine. If you like it I'd say to go for the commit asap. I wonder if someone tried to simulate a livelock and panic and thus verify that stoppcbs is correctly populated as expected (to be honest, this is one of the best features I'm interested into for this patch). Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 17:21:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F29DC1065677 for ; Wed, 7 Dec 2011 17:21:41 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 943FF8FC12 for ; Wed, 7 Dec 2011 17:21:41 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 30960740063 for ; Wed, 7 Dec 2011 18:04:54 +0100 (CET) From: Fabien Thomas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Dec 2011 18:05:44 +0100 Message-Id: <7816AB07-1FCC-451C-9194-9E7DFFFAC563@netasq.com> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [RFC] VIA south bridge watchdog support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:21:42 -0000 Hi, If someone want to look at I've added support for VIA south bridge watchdog. It has been tested on VX900 but should works with VX800, VX855, CX700. http://people.freebsd.org/~fabient/patch-watchdog-via-rev1 Fabien From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 17:33:12 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B948106564A; Wed, 7 Dec 2011 17:33:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6907A8FC14; Wed, 7 Dec 2011 17:33:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA01373; Wed, 07 Dec 2011 19:33:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDFA354.60909@FreeBSD.org> Date: Wed, 07 Dec 2011 19:33:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4EDF995B.9000407@FreeBSD.org> In-Reply-To: <4EDF995B.9000407@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:33:12 -0000 A detail that may or may not be useful. It seems that the panic happened when tried to resume a vim process. The process was suspended, its current directory and a file being edited/viewed may have been already removed. on 07/12/2011 18:50 Andriy Gapon said the following: > > (kgdb) bt > #0 doadump (textdump=1) at pcpu.h:224 > #1 0xffffffff804f6d3b in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff804f63e9 in panic (fmt=0x104
) at > /usr/src/sys/kern/kern_shutdown.c:635 > #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, > vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 > #4 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, > nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, cnp=0xffffff82393b3708, > nameiop=0, cr=0xfffffe0042e88100, td=0xfffffe000fdfa480, > flags=0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 > #5 0xffffffff81a91570 in zfs_freebsd_lookup (ap=0xffffff82393b32c0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858 > #6 0xffffffff8073f054 in VOP_CACHEDLOOKUP_APV (vop=0xffffffff81b05a20, > a=0xffffff82393b32c0) at vnode_if.c:187 > #7 0xffffffff80586bf4 in vfs_cache_lookup (ap=Variable "ap" is not available. > ) at vnode_if.h:80 > #8 0xffffffff80740a5c in VOP_LOOKUP_APV (vop=0xffffffff81b05a20, > a=0xffffff82393b33a0) at vnode_if.c:123 > #9 0xffffffff8058e42c in lookup (ndp=0xffffff82393b36a0) at vnode_if.h:54 > #10 0xffffffff8058f17e in namei (ndp=0xffffff82393b36a0) at > /usr/src/sys/kern/vfs_lookup.c:312 > #11 0xffffffff805a890d in vn_open_cred (ndp=0xffffff82393b36a0, > flagp=0xffffff82393b3918, cmode=0, vn_open_flags=Variable "vn_open_flags" is not > available. > ) at /usr/src/sys/kern/vfs_vnops.c:195 > #12 0xffffffff80589e7e in vop_stdvptocnp (ap=Variable "ap" is not available. > ) at /usr/src/sys/kern/vfs_default.c:774 > #13 0xffffffff8073b012 in VOP_VPTOCNP_APV (vop=0xffffffff80a99140, > a=0xffffff82393b39b0) at vnode_if.c:3479 > #14 0xffffffff80584665 in vn_vptocnp_locked (vp=0xffffff82393b3a50, > cred=0xfffffe0042e88100, > buf=0xfffffe000ca06000 > "������������������������������������������������������������������������������������������������������������������������������������������������������"..., > buflen=0xffffff82393b3a4c) at vnode_if.h:1564 > #15 0xffffffff80584bab in vn_fullpath1 (td=0xfffffe000fdfa480, > vp=0xfffffe003d4763c0, rdir=0xfffffe000cd4d000, > buf=0xfffffe000ca06000 > "������������������������������������������������������������������������������������������������������������������������������������������������������"..., > retbuf=0xffffff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218 > #16 0xffffffff8058526a in kern___getcwd (td=0xfffffe000fdfa480, buf=0x80880a000 >
, bufseg=UIO_USERSPACE, buflen=1024) at > /usr/src/sys/kern/vfs_cache.c:960 > #17 0xffffffff805853f4 in sys___getcwd (td=Variable "td" is not available. > ) at /usr/src/sys/kern/vfs_cache.c:934 > #18 0xffffffff806d2069 in amd64_syscall (td=0xfffffe000fdfa480, traced=0) at > subr_syscall.c:131 > #19 0xffffffff806bb4e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 > #20 0x00000008031adb2c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) fr 3 > #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, > vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 > 726 KASSERT(vp == NULL || vp->v_type == VDIR, > (kgdb) list > 721 if (dvp->v_cache_dd != NULL) { > 722 CACHE_WUNLOCK(); > 723 cache_free(ncp); > 724 return; > 725 } > 726 KASSERT(vp == NULL || vp->v_type == VDIR, > 727 ("wrong vnode type %p", vp)); > 728 dvp->v_cache_dd = ncp; > 729 } > 730 > (kgdb) p *vp > $1 = {v_type = VREG, v_tag = 0xffffffff81afe449 "zfs", v_op = 0xffffffff81b05a20, > v_data = 0xfffffe020d9a8320, v_mount = 0xfffffe001a283600, v_nmntvnodes = > {tqe_next = 0xfffffe00347c6d20, > tqe_prev = 0xfffffe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, > vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, > v_hash = 0, v_cache_src = { > lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfffffe003dfcf690, tqh_last = > 0xfffffe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, > v_clen = 0, v_lock = {lock_object = { > lo_name = 0xffffffff81afe449 "zfs", lo_flags = 91947008, lo_data = 0, > lo_witness = 0xffffff800066e380}, lk_lock = 18446741874952610944, lk_exslpfail = > 0, lk_timo = 51, lk_pri = 96}, > v_interlock = {lock_object = {lo_name = 0xffffffff807e610a "vnode interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff8000665600}, mtx_lock = 4}, > v_vnlock = 0xfffffe0142517098, > v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, > v_freelist = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe02110d3e30}, > v_bufobj = {bo_mtx = {lock_object = { > lo_name = 0xffffffff807efdfa "bufobj interlock", lo_flags = 16973824, > lo_data = 0, lo_witness = 0xffffff800066c300}, mtx_lock = 4}, bo_clean = {bv_hd = > {tqh_first = 0x0, > tqh_last = 0xfffffe0142517140}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = > {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517160}, bv_root = 0x0, bv_cnt = > 0}, bo_numoutput = 0, bo_flag = 0, > bo_ops = 0xffffffff80a95ec0, bo_bsize = 131072, bo_object = > 0xfffffe01fccb5620, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = > 0xfffffe0142517000, __bo_vnode = 0xfffffe0142517000}, > v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} > (kgdb) > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 17:51:59 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC76C1065677 for ; Wed, 7 Dec 2011 17:51:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 59F6E8FC15 for ; Wed, 7 Dec 2011 17:51:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 8F8757300A; Wed, 7 Dec 2011 19:08:07 +0100 (CET) Date: Wed, 7 Dec 2011 19:08:07 +0100 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20111207180807.GA71878@onelab2.iet.unipi.it> References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EDF471F.1030202@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, Jack Vogel , Daniel Kalchev Subject: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:51:59 -0000 On Wed, Dec 07, 2011 at 11:59:43AM +0100, Andre Oppermann wrote: > On 06.12.2011 22:06, Luigi Rizzo wrote: ... > >Even in my experiments there is a lot of instability in the results. > >I don't know exactly where the problem is, but the high number of > >read syscalls, and the huge impact of setting interrupt_rate=0 > >(defaults at 16us on the ixgbe) makes me think that there is something > >that needs investigation in the protocol stack. > > > >Of course we don't want to optimize specifically for the one-flow-at-10G > >case, but devising something that makes the system less affected > >by short timing variations, and can pass upstream interrupt mitigation > >delays would help. > > I'm not sure the variance is only coming from the network card and > driver side of things. The TCP processing and interactions with > scheduler and locking probably play a big role as well. There have > been many changes to TCP recently and maybe an inefficiency that > affects high-speed single sessions throughput has crept in. That's > difficult to debug though. I ran a bunch of tests on the ixgbe (82599) using RELENG_8 (which seems slightly faster than HEAD) using MTU=1500 and various combinations of card capabilities (hwcsum,tso,lro), different window sizes and interrupt mitigation configurations. default latency is 16us, l=0 means no interrupt mitigation. lro is the software implementation of lro (tcp_lro.c) hwlro is the hardware one (on 82599). Using a window of 100 Kbytes seems to give the best results. Summary: - with default interrupt mitigation, the fastest configuration is with checksums enabled on both sender and receiver, lro enabled on the receiver. This gets about 8.0 Gbit/s - lro is especially good because it packs data packets together, passing mitigation upstream and removing duplicate work in the ip and tcp stack. - disabling LRO on the receiver brings performance to 6.5 Gbit/s. Also it increases the CPU load (also in userspace). - disabling checksums on the sender reduces transmit speed to 5.5 Gbit/s - checksums disabled on both sides (and no LRO on the receiver) go down to 4.8 Gbit/s - I could not try the receive side without checksum but with lro - with default interrupt mitigation, setting both HWCSUM and TSO on the sender is really disruptive. Depending on lro settings on the receiver i get 1.5 to 3.2 Gbit/s and huge variance - Using both hwcsum and tso seems to work fine if you disable interrupt mitigation (reaching a peak of 9.4 Gbit/s). - enabling software lro on the transmit side actually slows down the throughput (4-5Gbit/s instead of 8.0). I am not sure why (perhaps acks are delayed too much) ? Adding a couple of lines in tcp_lro to reject pure acks seems to have much better effect. The tcp_lro patch below might actually be useful also for other cards. --- tcp_lro.c (revision 228284) +++ tcp_lro.c (working copy) @@ -245,6 +250,8 @@ ip_len = ntohs(ip->ip_len); tcp_data_len = ip_len - (tcp->th_off << 2) - sizeof (*ip); + if (tcp_data_len == 0) + return -1; /* not on ack */ /* cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 18:09:30 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD3701065672; Wed, 7 Dec 2011 18:09:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 036378FC08; Wed, 7 Dec 2011 18:09:29 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA01823; Wed, 07 Dec 2011 20:09:28 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDFABD7.20301@FreeBSD.org> Date: Wed, 07 Dec 2011 20:09:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4EDF995B.9000407@FreeBSD.org> <4EDFA354.60909@FreeBSD.org> In-Reply-To: <4EDFA354.60909@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 18:09:30 -0000 on 07/12/2011 19:33 Andriy Gapon said the following: > > A detail that may or may not be useful. > It seems that the panic happened when tried to resume a vim process. The process > was suspended, its current directory and a file being edited/viewed may have been > already removed. And another data point: (kgdb) p ((znode_t *)dvp->v_data)->z_unlinked Perhaps lookup in unlinked directories should just fail? I am not sufficiently familiar with VFS, so just guessing. > on 07/12/2011 18:50 Andriy Gapon said the following: >> >> (kgdb) bt >> #0 doadump (textdump=1) at pcpu.h:224 >> #1 0xffffffff804f6d3b in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:447 >> #2 0xffffffff804f63e9 in panic (fmt=0x104
) at >> /usr/src/sys/kern/kern_shutdown.c:635 >> #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, >> vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 >> #4 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, >> nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, cnp=0xffffff82393b3708, >> nameiop=0, cr=0xfffffe0042e88100, td=0xfffffe000fdfa480, >> flags=0) at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 >> #5 0xffffffff81a91570 in zfs_freebsd_lookup (ap=0xffffff82393b32c0) at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858 >> #6 0xffffffff8073f054 in VOP_CACHEDLOOKUP_APV (vop=0xffffffff81b05a20, >> a=0xffffff82393b32c0) at vnode_if.c:187 >> #7 0xffffffff80586bf4 in vfs_cache_lookup (ap=Variable "ap" is not available. >> ) at vnode_if.h:80 >> #8 0xffffffff80740a5c in VOP_LOOKUP_APV (vop=0xffffffff81b05a20, >> a=0xffffff82393b33a0) at vnode_if.c:123 >> #9 0xffffffff8058e42c in lookup (ndp=0xffffff82393b36a0) at vnode_if.h:54 >> #10 0xffffffff8058f17e in namei (ndp=0xffffff82393b36a0) at >> /usr/src/sys/kern/vfs_lookup.c:312 >> #11 0xffffffff805a890d in vn_open_cred (ndp=0xffffff82393b36a0, >> flagp=0xffffff82393b3918, cmode=0, vn_open_flags=Variable "vn_open_flags" is not >> available. >> ) at /usr/src/sys/kern/vfs_vnops.c:195 >> #12 0xffffffff80589e7e in vop_stdvptocnp (ap=Variable "ap" is not available. >> ) at /usr/src/sys/kern/vfs_default.c:774 >> #13 0xffffffff8073b012 in VOP_VPTOCNP_APV (vop=0xffffffff80a99140, >> a=0xffffff82393b39b0) at vnode_if.c:3479 >> #14 0xffffffff80584665 in vn_vptocnp_locked (vp=0xffffff82393b3a50, >> cred=0xfffffe0042e88100, >> buf=0xfffffe000ca06000 >> "������������������������������������������������������������������������������������������������������������������������������������������������������"..., >> buflen=0xffffff82393b3a4c) at vnode_if.h:1564 >> #15 0xffffffff80584bab in vn_fullpath1 (td=0xfffffe000fdfa480, >> vp=0xfffffe003d4763c0, rdir=0xfffffe000cd4d000, >> buf=0xfffffe000ca06000 >> "������������������������������������������������������������������������������������������������������������������������������������������������������"..., >> retbuf=0xffffff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218 >> #16 0xffffffff8058526a in kern___getcwd (td=0xfffffe000fdfa480, buf=0x80880a000 >>
, bufseg=UIO_USERSPACE, buflen=1024) at >> /usr/src/sys/kern/vfs_cache.c:960 >> #17 0xffffffff805853f4 in sys___getcwd (td=Variable "td" is not available. >> ) at /usr/src/sys/kern/vfs_cache.c:934 >> #18 0xffffffff806d2069 in amd64_syscall (td=0xfffffe000fdfa480, traced=0) at >> subr_syscall.c:131 >> #19 0xffffffff806bb4e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 >> #20 0x00000008031adb2c in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) fr 3 >> #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, >> vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 >> 726 KASSERT(vp == NULL || vp->v_type == VDIR, >> (kgdb) list >> 721 if (dvp->v_cache_dd != NULL) { >> 722 CACHE_WUNLOCK(); >> 723 cache_free(ncp); >> 724 return; >> 725 } >> 726 KASSERT(vp == NULL || vp->v_type == VDIR, >> 727 ("wrong vnode type %p", vp)); >> 728 dvp->v_cache_dd = ncp; >> 729 } >> 730 >> (kgdb) p *vp >> $1 = {v_type = VREG, v_tag = 0xffffffff81afe449 "zfs", v_op = 0xffffffff81b05a20, >> v_data = 0xfffffe020d9a8320, v_mount = 0xfffffe001a283600, v_nmntvnodes = >> {tqe_next = 0xfffffe00347c6d20, >> tqe_prev = 0xfffffe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, >> vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, >> v_hash = 0, v_cache_src = { >> lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfffffe003dfcf690, tqh_last = >> 0xfffffe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, >> v_clen = 0, v_lock = {lock_object = { >> lo_name = 0xffffffff81afe449 "zfs", lo_flags = 91947008, lo_data = 0, >> lo_witness = 0xffffff800066e380}, lk_lock = 18446741874952610944, lk_exslpfail = >> 0, lk_timo = 51, lk_pri = 96}, >> v_interlock = {lock_object = {lo_name = 0xffffffff807e610a "vnode interlock", >> lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff8000665600}, mtx_lock = 4}, >> v_vnlock = 0xfffffe0142517098, >> v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, >> v_freelist = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe02110d3e30}, >> v_bufobj = {bo_mtx = {lock_object = { >> lo_name = 0xffffffff807efdfa "bufobj interlock", lo_flags = 16973824, >> lo_data = 0, lo_witness = 0xffffff800066c300}, mtx_lock = 4}, bo_clean = {bv_hd = >> {tqh_first = 0x0, >> tqh_last = 0xfffffe0142517140}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = >> {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517160}, bv_root = 0x0, bv_cnt = >> 0}, bo_numoutput = 0, bo_flag = 0, >> bo_ops = 0xffffffff80a95ec0, bo_bsize = 131072, bo_object = >> 0xfffffe01fccb5620, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = >> 0xfffffe0142517000, __bo_vnode = 0xfffffe0142517000}, >> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} >> (kgdb) >> > > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 19:58:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0764106564A for ; Wed, 7 Dec 2011 19:58:49 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6308FC15 for ; Wed, 7 Dec 2011 19:58:48 +0000 (UTC) Received: from [192.92.129.101] ([192.92.129.101]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pB7JwVts057027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Dec 2011 21:58:39 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Daniel Kalchev In-Reply-To: <20111207180807.GA71878@onelab2.iet.unipi.it> Date: Wed, 7 Dec 2011 21:58:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1251.1) Cc: Andre Oppermann , Jack Vogel , current@freebsd.org Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 19:58:49 -0000 On Dec 7, 2011, at 8:08 PM, Luigi Rizzo wrote: > Summary: >=20 > - with default interrupt mitigation, the fastest configuration > is with checksums enabled on both sender and receiver, lro > enabled on the receiver. This gets about 8.0 Gbit/s I do not observe this. With defaults: # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=3D65536, nstream=3D1, port=3D5001 tcp -> 10.2.101.11 nuttcp-t: time limit =3D 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=3D1448, RTT=3D0.053 ms nuttcp-t: send window size =3D 131768, receive window size =3D 66608 nuttcp-t: 1857.4978 MB in 5.02 real seconds =3D 378856.02 KB/sec =3D = 3103.5885 Mbps nuttcp-t: host-retrans =3D 0 nuttcp-t: 29720 I/O calls, msec/call =3D 0.17, calls/sec =3D 5919.63 nuttcp-t: 0.0user 2.5sys 0:05real 52% 115i+1544d 630maxrss 0+2pf = 107264+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=3D65536, nstream=3D1, port=3D5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size =3D 33304, receive window size =3D 131768 nuttcp-r: 1857.4978 MB in 5.15 real seconds =3D 369617.39 KB/sec =3D = 3027.9057 Mbps nuttcp-r: 543991 I/O calls, msec/call =3D 0.01, calls/sec =3D 105709.95 nuttcp-r: 0.1user 4.1sys 0:05real 83% 110i+1482d 618maxrss 0+15pf = 158432+0csw On receiver: ifconfig ix1 lro # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=3D65536, nstream=3D1, port=3D5001 tcp -> 10.2.101.11 nuttcp-t: time limit =3D 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=3D1448, RTT=3D0.068 ms nuttcp-t: send window size =3D 131768, receive window size =3D 66608 nuttcp-t: 1673.3125 MB in 5.02 real seconds =3D 341312.36 KB/sec =3D = 2796.0308 Mbps nuttcp-t: host-retrans =3D 1 nuttcp-t: 26773 I/O calls, msec/call =3D 0.19, calls/sec =3D 5333.01 nuttcp-t: 0.0user 1.0sys 0:05real 21% 113i+1518d 630maxrss 0+2pf = 12772+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=3D65536, nstream=3D1, port=3D5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size =3D 33304, receive window size =3D 131768 nuttcp-r: 1673.3125 MB in 5.15 real seconds =3D 332975.19 KB/sec =3D = 2727.7327 Mbps nuttcp-r: 106268 I/O calls, msec/call =3D 0.05, calls/sec =3D 20650.82 nuttcp-r: 0.0user 1.3sys 0:05real 28% 101i+1354d 618maxrss 0+15pf = 64567+0csw On sender: ifconfig ix1 lro (now both receiver and sender have LRO enabled) # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=3D65536, nstream=3D1, port=3D5001 tcp -> 10.2.101.11 nuttcp-t: time limit =3D 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=3D1448, RTT=3D0.063 ms nuttcp-t: send window size =3D 131768, receive window size =3D 66608 nuttcp-t: 1611.7805 MB in 5.02 real seconds =3D 328716.18 KB/sec =3D = 2692.8430 Mbps nuttcp-t: host-retrans =3D 1 nuttcp-t: 25789 I/O calls, msec/call =3D 0.20, calls/sec =3D 5136.29 nuttcp-t: 0.0user 1.0sys 0:05real 21% 109i+1465d 630maxrss 0+2pf = 12697+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=3D65536, nstream=3D1, port=3D5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size =3D 33304, receive window size =3D 131768 nuttcp-r: 1611.7805 MB in 5.15 real seconds =3D 320694.82 KB/sec =3D = 2627.1319 Mbps nuttcp-r: 104346 I/O calls, msec/call =3D 0.05, calls/sec =3D 20275.05 nuttcp-r: 0.0user 1.3sys 0:05real 27% 113i+1516d 618maxrss 0+15pf = 63510+0csw remove LRO from receiver (only sender has LRO): # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=3D65536, nstream=3D1, port=3D5001 tcp -> 10.2.101.11 nuttcp-t: time limit =3D 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=3D1448, RTT=3D0.065 ms nuttcp-t: send window size =3D 131768, receive window size =3D 66608 nuttcp-t: 1884.8702 MB in 5.02 real seconds =3D 384464.57 KB/sec =3D = 3149.5338 Mbps nuttcp-t: host-retrans =3D 0 nuttcp-t: 30158 I/O calls, msec/call =3D 0.17, calls/sec =3D 6007.27 nuttcp-t: 0.0user 2.7sys 0:05real 55% 104i+1403d 630maxrss 0+2pf = 106046+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=3D65536, nstream=3D1, port=3D5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size =3D 33304, receive window size =3D 131768 nuttcp-r: 1884.8702 MB in 5.15 real seconds =3D 375093.52 KB/sec =3D = 3072.7661 Mbps nuttcp-r: 540237 I/O calls, msec/call =3D 0.01, calls/sec =3D 104988.68 nuttcp-r: 0.1user 4.2sys 0:05real 84% 110i+1483d 618maxrss 0+15pf = 156340+0csw Strange enough, setting hw.ixgbe.max_interrupt_rate=3D0 does not have = any effect.. Daniel From owner-freebsd-current@FreeBSD.ORG Wed Dec 7 20:07:35 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 116991065670; Wed, 7 Dec 2011 20:07:35 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 88A2A8FC15; Wed, 7 Dec 2011 20:07:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B9FCE7300A; Wed, 7 Dec 2011 21:23:41 +0100 (CET) Date: Wed, 7 Dec 2011 21:23:41 +0100 From: Luigi Rizzo To: Daniel Kalchev Message-ID: <20111207202341.GA72820@onelab2.iet.unipi.it> References: <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Andre Oppermann , Jack Vogel , current@freebsd.org Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 20:07:35 -0000 On Wed, Dec 07, 2011 at 09:58:31PM +0200, Daniel Kalchev wrote: > > On Dec 7, 2011, at 8:08 PM, Luigi Rizzo wrote: > > > Summary: > > > > - with default interrupt mitigation, the fastest configuration > > is with checksums enabled on both sender and receiver, lro > > enabled on the receiver. This gets about 8.0 Gbit/s > > I do not observe this. With defaults: > ... Sorry, forgot to mention that the above is with TSO DISABLED (which is not the default). TSO seems to have a very bad interaction with HWCSUM and non-zero mitigation. also remember that hw.ixgbe.max_interrupt_rate has only effect at module load -- i.e. you set it with the bootloader, or with kenv before loading the module. Please retry the measurements disabling tso (on both sides, but it really matters only on the sender). Also, LRO requires HWCSUM. cheers luigi > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.053 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1857.4978 MB in 5.02 real seconds = 378856.02 KB/sec = 3103.5885 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 29720 I/O calls, msec/call = 0.17, calls/sec = 5919.63 > nuttcp-t: 0.0user 2.5sys 0:05real 52% 115i+1544d 630maxrss 0+2pf 107264+1csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1857.4978 MB in 5.15 real seconds = 369617.39 KB/sec = 3027.9057 Mbps > nuttcp-r: 543991 I/O calls, msec/call = 0.01, calls/sec = 105709.95 > nuttcp-r: 0.1user 4.1sys 0:05real 83% 110i+1482d 618maxrss 0+15pf 158432+0csw > > On receiver: > > ifconfig ix1 lro > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.068 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1673.3125 MB in 5.02 real seconds = 341312.36 KB/sec = 2796.0308 Mbps > nuttcp-t: host-retrans = 1 > nuttcp-t: 26773 I/O calls, msec/call = 0.19, calls/sec = 5333.01 > nuttcp-t: 0.0user 1.0sys 0:05real 21% 113i+1518d 630maxrss 0+2pf 12772+1csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1673.3125 MB in 5.15 real seconds = 332975.19 KB/sec = 2727.7327 Mbps > nuttcp-r: 106268 I/O calls, msec/call = 0.05, calls/sec = 20650.82 > nuttcp-r: 0.0user 1.3sys 0:05real 28% 101i+1354d 618maxrss 0+15pf 64567+0csw > > On sender: > > ifconfig ix1 lro > > (now both receiver and sender have LRO enabled) > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.063 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1611.7805 MB in 5.02 real seconds = 328716.18 KB/sec = 2692.8430 Mbps > nuttcp-t: host-retrans = 1 > nuttcp-t: 25789 I/O calls, msec/call = 0.20, calls/sec = 5136.29 > nuttcp-t: 0.0user 1.0sys 0:05real 21% 109i+1465d 630maxrss 0+2pf 12697+0csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1611.7805 MB in 5.15 real seconds = 320694.82 KB/sec = 2627.1319 Mbps > nuttcp-r: 104346 I/O calls, msec/call = 0.05, calls/sec = 20275.05 > nuttcp-r: 0.0user 1.3sys 0:05real 27% 113i+1516d 618maxrss 0+15pf 63510+0csw > > remove LRO from receiver (only sender has LRO): > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.065 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1884.8702 MB in 5.02 real seconds = 384464.57 KB/sec = 3149.5338 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 30158 I/O calls, msec/call = 0.17, calls/sec = 6007.27 > nuttcp-t: 0.0user 2.7sys 0:05real 55% 104i+1403d 630maxrss 0+2pf 106046+0csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1884.8702 MB in 5.15 real seconds = 375093.52 KB/sec = 3072.7661 Mbps > nuttcp-r: 540237 I/O calls, msec/call = 0.01, calls/sec = 104988.68 > nuttcp-r: 0.1user 4.2sys 0:05real 84% 110i+1483d 618maxrss 0+15pf 156340+0csw > > Strange enough, setting hw.ixgbe.max_interrupt_rate=0 does not have any effect.. > > Daniel > From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 00:25:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87261106566B for ; Thu, 8 Dec 2011 00:25:49 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost02.isp.att.net (fmailhost02.isp.att.net [207.115.11.52]) by mx1.freebsd.org (Postfix) with ESMTP id 777DF8FC12 for ; Thu, 8 Dec 2011 00:25:49 +0000 (UTC) Date: Thu, 8 Dec 2011 00:25:48 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-130-165.sdf.bellsouth.net[68.210.130.165]) by isp.att.net (frfwmhc02) with SMTP id <20111208002548H02007rl94e>; Thu, 8 Dec 2011 00:25:48 +0000 X-Originating-IP: [68.210.130.165] From: "Thomas Mueller" To: freebsd-current@freebsd.org Message-Id: <20111208002549.87261106566B@hub.freebsd.org> Subject: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 00:25:49 -0000 I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, and now I see RC3 is available. I tried "options ATA_CAM" in kernel config, removing "device atapicam", but still readcd -scanbus or cdrecord -scanbus refuses to work, running as root. "camcontrol devlist" shows my DVD drive, and I am able to mount and read /dev/cd0. Is cdrtools buggy, or maybe the FreeBSD port is buggy? I see from the Makefile that sysutils/cdrdao is broken on FreeBSD 9.x, does not link. I downloaded cdrkit-1.1.11.tar.gz so as to extract and have a look at it, and possibly build it on my own, outside the ports system. I see the version in ports system is 1.1.9, maybe 1.1.11 could do better? Maybe the FreeBSD developers were too hasty to deprecate burncd? Tom From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 01:19:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FF6B1065675 for ; Thu, 8 Dec 2011 01:19:52 +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 8A5648FC0C for ; Thu, 8 Dec 2011 01:19:51 +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 pB81Jdk5025209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Dec 2011 11:49:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20111208002549.87261106566B@hub.freebsd.org> Date: Thu, 8 Dec 2011 11:49:39 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCB63CC-183F-4A7A-964A-EBBD70705C54@gsoft.com.au> References: <20111208002549.87261106566B@hub.freebsd.org> To: Thomas Mueller X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: -4.523 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 01:19:52 -0000 On 08/12/2011, at 10:55, Thomas Mueller wrote: > I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, = and now I see RC3 is available. >=20 > I tried "options ATA_CAM" in kernel config, removing "device = atapicam", but still=20 > readcd -scanbus or > cdrecord -scanbus > refuses to work, running as root. Define "refuses to work".. I have an oldish 9.0-CURRENT which works with cdrecord.. [titus 1:16] ~ >cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright = (C) 1995-2010 J?rg Schilling Using libscg version 'schily-0.9'. scsibus1: 1,0,0 100) 'PIONEER ' 'DVD-RW DVR-112D' '1.09' Removable = CD-ROM 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * I have a newer system but it doesn't have a DVD drive in it, however = cdrecord does seem to work (it sees the AHCI connected disks).. mdtest:~>cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright = (C) 1995-2010 J?rg Schilling Using libscg version 'schily-0.9'. scsibus0: 0,0,0 0) '' '' '' NON CCS Disk 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * mdtest:~>camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) -- 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 From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 01:21:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E6D106568D for ; Thu, 8 Dec 2011 01:21:24 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C7B998FC1F for ; Thu, 8 Dec 2011 01:21:23 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so2311180wgb.31 for ; Wed, 07 Dec 2011 17:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=6iMcvNeYKlA3IMrE3w3qAB0bw3Rx9rXS2BjQw1FHZ0E=; b=bVE0iUc6I1VKG+fL6nBzh/hDkMOZLfj9J5CX3UkUxkkEjnQ50rrBISdM6O6EFwwKdm zKoSUSo3OE55JTvIfJUIBrtAqHs9+iEqDy2mafhZEdE10IJ2O991Pd8ryJmjDsgpjMky mIEKWfPmj6+UkNsySKmb2qzAzdwI87oSK0fBo= MIME-Version: 1.0 Received: by 10.180.106.104 with SMTP id gt8mr1187959wib.6.1323307282597; Wed, 07 Dec 2011 17:21:22 -0800 (PST) Received: by 10.180.86.105 with HTTP; Wed, 7 Dec 2011 17:21:22 -0800 (PST) Date: Wed, 7 Dec 2011 20:21:22 -0500 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 08 Dec 2011 02:24:35 +0000 Subject: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 01:21:24 -0000 In the past, I've used the ftp cdrtools pkg (made from the port of course) and it failed to work. It's a popular tool so my machine was probably out of sync. Same with burncd. However, compiling the current cdrtools source worked fine. So I'd try that first, compare, and send up a bug if need be. Try to skip the scan by specifying the BTL or devpath on the command line. The scan is a big part of the port and might have breakage, at least for the app below. Also, if you're doing audio, someone over on ports has said they're doing an update to cdparanoia. It's minor, but useful for that crowd. makefs and burncd are part of the base, at least on RELENG_8. And makefs is used in the official releases. So they should just work. Good luck. From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 03:44:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04719106564A for ; Thu, 8 Dec 2011 03:44:03 +0000 (UTC) (envelope-from sean@coreitpro.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id BF2318FC17 for ; Thu, 8 Dec 2011 03:44:02 +0000 (UTC) Received: from Uller.local (c-76-124-116-189.hsd1.pa.comcast.net [76.124.116.189]) (authenticated bits=0) by masakari.coreitpro.com (8.14.4/8.14.4) with ESMTP id pB83iEnf019918 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 7 Dec 2011 22:44:14 -0500 (EST) (envelope-from sean@coreitpro.com) Message-ID: <4EE0327C.8080802@coreitpro.com> Date: Wed, 07 Dec 2011 22:43:56 -0500 From: "Sean M. Collins" Organization: Core IT Pro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EDA4E82.9040901@coreitpro.com> <4EDA807B.4080202@boland.org> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 03:44:03 -0000 On 12/3/11 5:45 PM, Garrett Cooper wrote: > Just to back up that point: until CVS is completely unused by > releng (docs, ports are still done via CVS), Ah - I am indeed mistaken. Not all that surprising. > it really shouldn't be > removed from base (no matter how broken or undeveloped it is). I agree. Please forgive the noise coming from my (grey) bikeshed. -- Sean M. Collins From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 08:14:05 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DBD71065673; Thu, 8 Dec 2011 08:14:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id D6B508FC14; Thu, 8 Dec 2011 08:14:04 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 064DA784; Thu, 8 Dec 2011 09:14:04 +0100 (CET) Date: Thu, 8 Dec 2011 09:13:04 +0100 From: Pawel Jakub Dawidek To: Andriy Gapon Message-ID: <20111208081304.GE1678@garage.freebsd.pl> References: <4EDF995B.9000407@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: <4EDF995B.9000407@FreeBSD.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:14:05 -0000 --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 07, 2011 at 06:50:35PM +0200, Andriy Gapon wrote: > (kgdb) bt > #0 doadump (textdump=3D1) at pcpu.h:224 > #1 0xffffffff804f6d3b in kern_reboot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff804f63e9 in panic (fmt=3D0x104
) at > /usr/src/sys/kern/kern_shutdown.c:635 > #3 0xffffffff80585f46 in cache_enter (dvp=3D0xfffffe003d4763c0, > vp=3D0xfffffe0142517000, cnp=3D0xffffff82393b3708) at /usr/src/sys/kern/v= fs_cache.c:726 > #4 0xffffffff81a90900 in zfs_lookup (dvp=3D0xfffffe003d4763c0, > nm=3D0xffffff82393b3140 "..", vpp=3D0xffffff82393b36e0, cnp=3D0xffffff823= 93b3708, > nameiop=3D0, cr=3D0xfffffe0042e88100, td=3D0xfffffe000fdfa480, > flags=3D0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zfs_vnops.c:1470 Which FreeBSD version is it? Because lines doesn't seem to match neither to HEAD nor to stable/8. It would be best of you could send me few lines around zfs_vnops.c:1470 and vfs_cache.c:726. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk7gcZAACgkQForvXbEpPzT2BwCdHa1bkovzE8qspjSQPQtLtSJr tMQAoLC5VMIG5qMZSB7cWY8fLucu30j/ =Svjs -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 08:35:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B622106564A for ; Thu, 8 Dec 2011 08:35:43 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 222B58FC25 for ; Thu, 8 Dec 2011 08:35:41 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 2DA778EBBC for ; Thu, 8 Dec 2011 09:35:41 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id bhK-VIarQoRv for ; Thu, 8 Dec 2011 09:35:39 +0100 (CET) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id 1448D8EBB1 for ; Thu, 8 Dec 2011 09:35:39 +0100 (CET) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id pB88ZcJK015727; Thu, 8 Dec 2011 09:35:38 +0100 (CET) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 Dec 2011 09:35:38 +0100 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> References: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> Message-ID: X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.4 Subject: Re: Dog Food X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:35:43 -0000 On Tue, 06 Dec 2011 13:51:05 -0800, Sean Bruno wrote: > Was trying to use gmirror(4) or zfs(4) today to get a machine in the > cluster setup with s/w raid and was completely flummoxed by the > intricacies of manual setup. Chances are, I just am not smart enough > to > wind my way though the various how tos and wiki pages that I've been > browsing to get the job done. Why using gmirror under zfs, when zfs itself supports software raid? > If someone wants to work on modifying bsdinstaller to do s/w raid via > one of these mechanisms, clusteradm@ can provide you a two disk SATA > machine that can be used for this purpose. > > Sean -- Kind regards Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 09:23:51 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C5B106566B; Thu, 8 Dec 2011 09:23:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0138FC1D; Thu, 8 Dec 2011 09:23:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA15187; Thu, 08 Dec 2011 11:23:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RYaCh-0004cJ-Di; Thu, 08 Dec 2011 11:23:47 +0200 Message-ID: <4EE08220.3010908@FreeBSD.org> Date: Thu, 08 Dec 2011 11:23:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4EDF995B.9000407@FreeBSD.org> <20111208081304.GE1678@garage.freebsd.pl> In-Reply-To: <20111208081304.GE1678@garage.freebsd.pl> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 09:23:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 08/12/2011 10:13 Pawel Jakub Dawidek said the following: > On Wed, Dec 07, 2011 at 06:50:35PM +0200, Andriy Gapon wrote: >> (kgdb) bt #0 doadump (textdump=1) at pcpu.h:224 #1 0xffffffff804f6d3b >> in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 >> 0xffffffff804f63e9 in panic (fmt=0x104
) at >> /usr/src/sys/kern/kern_shutdown.c:635 #3 0xffffffff80585f46 in >> cache_enter (dvp=0xfffffe003d4763c0, vp=0xfffffe0142517000, >> cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 #4 >> 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, >> nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, >> cnp=0xffffff82393b3708, nameiop=0, cr=0xfffffe0042e88100, >> td=0xfffffe000fdfa480, flags=0) at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 > >> > Which FreeBSD version is it? Because lines doesn't seem to match neither to > HEAD nor to stable/8. It would be best of you could send me few lines > around zfs_vnops.c:1470 and vfs_cache.c:726. > It's recent svn head, r228017, just with some local unrelated modifications. 1458 #ifdef FREEBSD_NAMECACHE 1459 /* 1460 * Insert name into cache (as non-existent) if appropriate. 1461 */ 1462 if (error == ENOENT && (cnp->cn_flags & MAKEENTRY) && nameiop != CREATE) 1463 cache_enter(dvp, *vpp, cnp); 1464 /* 1465 * Insert name into cache if appropriate. 1466 */ 1467 if (error == 0 && (cnp->cn_flags & MAKEENTRY)) { 1468 if (!(cnp->cn_flags & ISLASTCN) || 1469 (nameiop != DELETE && nameiop != RENAME)) { 1470 cache_enter(dvp, *vpp, cnp); 1471 } 1472 } 1473 #endif ================ 716 if (flag == NCF_ISDOTDOT) { 717 /* 718 * See if we are trying to add .. entry, but some other lookup 719 * has populated v_cache_dd pointer already. 720 */ 721 if (dvp->v_cache_dd != NULL) { 722 CACHE_WUNLOCK(); 723 cache_free(ncp); 724 return; 725 } 726 KASSERT(vp == NULL || vp->v_type == VDIR, 727 ("wrong vnode type %p", vp)); 728 dvp->v_cache_dd = ncp; 729 } - -- Andriy Gapon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO4IIgAAoJEHSlLSemUf4v5v0H/RqN3RagBBleHYZTY+39gxj3 I2urnYxB+1vi2b9o/B4KRQXi5gByAY3sukDnKrABxXK3ycOOJjQ5o8Xz0NMqcwHY r6oMnh/4NLpZi+Cwx0LQKycRZuPMsKzYJpMrofE/Q9Nl1EgUjz6Er2fOaEiu1xUO DAWKrJdgFNE3Kwjy64oqftcC9Aw9g0+lcyVp+Pzw9HRHzw1h8wokH+EvslfFqtJ0 YFCabxTxNQrqpCgv8PEEAAyNiqB7S9X43f5RKNuMFOiwGp8GsP7O6j9AFDUoM9os +KkkN0hE28jB4daQ0HJpPr9Kz3Mkr91yMT+nxMv1lPH9BmGYWwbx3Jck0c7o+OY= =8Y/W -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 10:06:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8897A106564A; Thu, 8 Dec 2011 10:06:42 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id E2E8F8FC08; Thu, 8 Dec 2011 10:06:41 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pB8A6RU9060574 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Dec 2011 12:06:32 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <4EE08C22.2040500@digsys.bg> Date: Thu, 08 Dec 2011 12:06:26 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> <20111207202341.GA72820@onelab2.iet.unipi.it> In-Reply-To: <20111207202341.GA72820@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Oppermann , Jack Vogel , current@freebsd.org Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 10:06:42 -0000 On 07.12.11 22:23, Luigi Rizzo wrote: > > Sorry, forgot to mention that the above is with TSO DISABLED > (which is not the default). TSO seems to have a very bad > interaction with HWCSUM and non-zero mitigation. I have this on both sender and receiver # ifconfig ix1 ix1: flags=8843 metric 0 mtu 1500 options=4bb ether 00:25:90:35:22:f1 inet 10.2.101.11 netmask 0xffffff00 broadcast 10.2.101.255 media: Ethernet autoselect (autoselect ) status: active without LRO on either end # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.051 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 1802.4049 MB in 5.06 real seconds = 365077.76 KB/sec = 2990.7170 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 28839 I/O calls, msec/call = 0.18, calls/sec = 5704.44 nuttcp-t: 0.0user 4.5sys 0:05real 90% 108i+1459d 630maxrss 0+2pf 87706+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 1802.4049 MB in 5.18 real seconds = 356247.49 KB/sec = 2918.3794 Mbps nuttcp-r: 529295 I/O calls, msec/call = 0.01, calls/sec = 102163.86 nuttcp-r: 0.1user 3.7sys 0:05real 73% 116i+1567d 618maxrss 0+15pf 230404+0csw with LRO on receiver # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.067 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 2420.5000 MB in 5.02 real seconds = 493701.04 KB/sec = 4044.3989 Mbps nuttcp-t: host-retrans = 2 nuttcp-t: 38728 I/O calls, msec/call = 0.13, calls/sec = 7714.08 nuttcp-t: 0.0user 4.1sys 0:05real 83% 107i+1436d 630maxrss 0+2pf 4896+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 2420.5000 MB in 5.15 real seconds = 481679.37 KB/sec = 3945.9174 Mbps nuttcp-r: 242266 I/O calls, msec/call = 0.02, calls/sec = 47080.98 nuttcp-r: 0.0user 2.4sys 0:05real 49% 112i+1502d 618maxrss 0+15pf 156333+0csw About 1/4 improvement... With LRO on both sender and receiver # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.049 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 2585.7500 MB in 5.02 real seconds = 527402.83 KB/sec = 4320.4840 Mbps nuttcp-t: host-retrans = 1 nuttcp-t: 41372 I/O calls, msec/call = 0.12, calls/sec = 8240.67 nuttcp-t: 0.0user 4.6sys 0:05real 93% 106i+1421d 630maxrss 0+2pf 4286+0csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 2585.7500 MB in 5.15 real seconds = 514585.31 KB/sec = 4215.4829 Mbps nuttcp-r: 282820 I/O calls, msec/call = 0.02, calls/sec = 54964.34 nuttcp-r: 0.0user 2.7sys 0:05real 55% 114i+1540d 618maxrss 0+15pf 188794+147csw Even better... With LRO on sender only: # nuttcp -t -T 5 -w 128 -v 10.2.101.11 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.054 ms nuttcp-t: send window size = 131768, receive window size = 66608 nuttcp-t: 2077.5437 MB in 5.02 real seconds = 423740.81 KB/sec = 3471.2847 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 33241 I/O calls, msec/call = 0.15, calls/sec = 6621.01 nuttcp-t: 0.0user 4.5sys 0:05real 92% 109i+1468d 630maxrss 0+2pf 49532+25csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.2.101.12 nuttcp-r: send window size = 33304, receive window size = 131768 nuttcp-r: 2077.5437 MB in 5.15 real seconds = 413415.33 KB/sec = 3386.6984 Mbps nuttcp-r: 531979 I/O calls, msec/call = 0.01, calls/sec = 103378.67 nuttcp-r: 0.0user 4.5sys 0:05real 88% 110i+1474d 618maxrss 0+15pf 117367+0csw > also remember that hw.ixgbe.max_interrupt_rate has only > effect at module load -- i.e. you set it with the bootloader, > or with kenv before loading the module. I have this in /boot/loader.conf kern.ipc.nmbclusters=512000 hw.ixgbe.max_interrupt_rate=0 on both sender and receiver. > Please retry the measurements disabling tso (on both sides, but > it really matters only on the sender). Also, LRO requires HWCSUM. How do I set HWCSUM? Is this different from RXCSUM/TXCSUM? Still I get nowhere near what you get on my hardware... Here is what pciconf -vlbc has to say ix0@pci0:3:0:0: class=0x020000 card=0xffffffff chip=0x10fc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfbc00000, size 2097152, enabled bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled bar [20] = type Memory, range 64, base 0xfbbfc000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) cap 03[e0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 002590ffff363f80 ecap 000e[150] = unknown 1 ecap 0010[160] = unknown 1 ix1@pci0:3:0:1: class=0x020000 card=0xffffffff chip=0x10fc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfb800000, size 2097152, enabled bar [18] = type I/O Port, range 32, base 0xd880, size 32, enabled bar [20] = type Memory, range 64, base 0xfbbf8000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) cap 03[e0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 002590ffff363f80 ecap 000e[150] = unknown 1 ecap 0010[160] = unknown 1 I am using ix1, as the blade enclosure has only one 10G switch and it happens to be on the 'second' position. Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 10:08:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44A3E106564A for ; Thu, 8 Dec 2011 10:08:43 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id D13A08FC1A for ; Thu, 8 Dec 2011 10:08:42 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MBWuQ-1RRTcl2g2I-00AypO; Thu, 08 Dec 2011 11:08:41 +0100 Message-ID: <4EE08CA8.1060506@brockmann-consult.de> Date: Thu, 08 Dec 2011 11:08:40 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:uxbSM/CZwMYGSIMn4EqBAAyYOC/16cJJJE+E/BjMAOh v9JAyEPQ+Wq8f/Y8OTbvEuLW/vhQj3LzF/548CWVsjVUCTJvVJ sV6uYJN5fA74ku1hUluwa/JmYgG/o81xMrvr+zh72OXWFeEpUi /kg9Ozd6fIBlGLVQAcvM4kTBhYCstzH+ikxDNQdEYErX7GPWsz QzcqN85P9bFywxcd/RWh4T+YBskALf6cDr9seQ3QdK7zMgEE4I UeIG+LQSYuj801I+c2NQTgyOxu6LXkcFYycVbys9QpCacaXvaT AHTFwJIHmHzaZhR6Qx7AwUTW2UM3w0w23bxrOJ4rWprSCFc8bI itHhiow+/0nzoUoU6zh8KdgBF6p5LjGeIfnJWqVXM Subject: Re: Dog Food X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 10:08:43 -0000 On 12/08/2011 09:35 AM, Daniel Gerzo wrote: > On Tue, 06 Dec 2011 13:51:05 -0800, Sean Bruno wrote: >> Was trying to use gmirror(4) or zfs(4) today to get a machine in the >> cluster setup with s/w raid and was completely flummoxed by the >> intricacies of manual setup. Chances are, I just am not smart enough to >> wind my way though the various how tos and wiki pages that I've been >> browsing to get the job done. > > Why using gmirror under zfs, when zfs itself supports software raid? > >> If someone wants to work on modifying bsdinstaller to do s/w raid via >> one of these mechanisms, clusteradm@ can provide you a two disk SATA >> machine that can be used for this purpose. >> >> Sean > And what problems did you run into? This guide worked for me: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror (but the "zfs create ..." part was too much typing, so I did it with a script that I added to the CD) -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 10:34:43 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D8D3106566B; Thu, 8 Dec 2011 10:34:43 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B3B728FC13; Thu, 8 Dec 2011 10:34:42 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D13CA7300A; Thu, 8 Dec 2011 11:50:51 +0100 (CET) Date: Thu, 8 Dec 2011 11:50:51 +0100 From: Luigi Rizzo To: Daniel Kalchev Message-ID: <20111208105051.GA79731@onelab2.iet.unipi.it> References: <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> <20111207202341.GA72820@onelab2.iet.unipi.it> <4EE08C22.2040500@digsys.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EE08C22.2040500@digsys.bg> User-Agent: Mutt/1.4.2.3i Cc: Andre Oppermann , Jack Vogel , current@freebsd.org Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 10:34:43 -0000 On Thu, Dec 08, 2011 at 12:06:26PM +0200, Daniel Kalchev wrote: > > > On 07.12.11 22:23, Luigi Rizzo wrote: > > > >Sorry, forgot to mention that the above is with TSO DISABLED > >(which is not the default). TSO seems to have a very bad > >interaction with HWCSUM and non-zero mitigation. > > I have this on both sender and receiver > > # ifconfig ix1 > ix1: flags=8843 metric 0 mtu 1500 > > options=4bb > ether 00:25:90:35:22:f1 > inet 10.2.101.11 netmask 0xffffff00 broadcast 10.2.101.255 > media: Ethernet autoselect (autoselect ) > status: active > > without LRO on either end > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.051 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1802.4049 MB in 5.06 real seconds = 365077.76 KB/sec = > 2990.7170 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 28839 I/O calls, msec/call = 0.18, calls/sec = 5704.44 > nuttcp-t: 0.0user 4.5sys 0:05real 90% 108i+1459d 630maxrss 0+2pf 87706+1csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1802.4049 MB in 5.18 real seconds = 356247.49 KB/sec = > 2918.3794 Mbps > nuttcp-r: 529295 I/O calls, msec/call = 0.01, calls/sec = 102163.86 > nuttcp-r: 0.1user 3.7sys 0:05real 73% 116i+1567d 618maxrss 0+15pf > 230404+0csw > > with LRO on receiver > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.067 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 2420.5000 MB in 5.02 real seconds = 493701.04 KB/sec = > 4044.3989 Mbps > nuttcp-t: host-retrans = 2 > nuttcp-t: 38728 I/O calls, msec/call = 0.13, calls/sec = 7714.08 > nuttcp-t: 0.0user 4.1sys 0:05real 83% 107i+1436d 630maxrss 0+2pf 4896+0csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 2420.5000 MB in 5.15 real seconds = 481679.37 KB/sec = > 3945.9174 Mbps > nuttcp-r: 242266 I/O calls, msec/call = 0.02, calls/sec = 47080.98 > nuttcp-r: 0.0user 2.4sys 0:05real 49% 112i+1502d 618maxrss 0+15pf > 156333+0csw > > About 1/4 improvement... > > With LRO on both sender and receiver > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.049 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 2585.7500 MB in 5.02 real seconds = 527402.83 KB/sec = > 4320.4840 Mbps > nuttcp-t: host-retrans = 1 > nuttcp-t: 41372 I/O calls, msec/call = 0.12, calls/sec = 8240.67 > nuttcp-t: 0.0user 4.6sys 0:05real 93% 106i+1421d 630maxrss 0+2pf 4286+0csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 2585.7500 MB in 5.15 real seconds = 514585.31 KB/sec = > 4215.4829 Mbps > nuttcp-r: 282820 I/O calls, msec/call = 0.02, calls/sec = 54964.34 > nuttcp-r: 0.0user 2.7sys 0:05real 55% 114i+1540d 618maxrss 0+15pf > 188794+147csw > > Even better... > > With LRO on sender only: > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.054 ms > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 2077.5437 MB in 5.02 real seconds = 423740.81 KB/sec = > 3471.2847 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 33241 I/O calls, msec/call = 0.15, calls/sec = 6621.01 > nuttcp-t: 0.0user 4.5sys 0:05real 92% 109i+1468d 630maxrss 0+2pf 49532+25csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 2077.5437 MB in 5.15 real seconds = 413415.33 KB/sec = > 3386.6984 Mbps > nuttcp-r: 531979 I/O calls, msec/call = 0.01, calls/sec = 103378.67 > nuttcp-r: 0.0user 4.5sys 0:05real 88% 110i+1474d 618maxrss 0+15pf > 117367+0csw > > > >also remember that hw.ixgbe.max_interrupt_rate has only > >effect at module load -- i.e. you set it with the bootloader, > >or with kenv before loading the module. > > I have this in /boot/loader.conf > > kern.ipc.nmbclusters=512000 > hw.ixgbe.max_interrupt_rate=0 > > on both sender and receiver. > > >Please retry the measurements disabling tso (on both sides, but > >it really matters only on the sender). Also, LRO requires HWCSUM. > > How do I set HWCSUM? Is this different from RXCSUM/TXCSUM? by HWCSUM i mean either rxcsum or txcsum. On ixgbe, you set one, and the other one is also set. Same for resetting. I don't remember what happens if you set lro, judging from the code it might automatically set rxcsum. As you see in your experiment, it's the sender that is starving, and setting hw.ixgbe.max_interrupt_rate=0 is not terribly helpful for lro. In my case, best conditions are: with hw.ixgbe.max_interrupt_rate=0: sender: ifconfig ix0 txcsum tso -lro receiver: ifconfig ix0 rxcsum lro txcsum and tso reduce the load on the sender, but lro is less effective on the receiver with no interrupt mitigation with hw.ixgbe.max_interrupt_rate > 0 sender: ifconfig ix0 txcsum -tso -lro <-- note the -tso receiver: ifconfig ix0 rxcsum lro It seems that txcsum and tso together trigger some problem in the sender so i have to give up one. A larger mitigation interval reduces the load on the receiver (you'll see fewer read call) Of course your blade might be slower than my test mchine so i wouldn't expect to see the same numbers, but i do expect to see a similar improvement/reduction when playing with the various parameters. for raw hw speed you should check how much you get over the loopback interface. I have about 15 Gbit/s on one, 44 Gbit/s on another (but the latter does not have an ixgbe card in it so i cannot test more). cheers luigi > Still I get nowhere near what you get on my hardware... Here is what > pciconf -vlbc has to say > > ix0@pci0:3:0:0: class=0x020000 card=0xffffffff chip=0x10fc8086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xfbc00000, size 2097152, > enabled > bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled > bar [20] = type Memory, range 64, base 0xfbbfc000, size 16384, > enabled > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > cap 03[e0] = VPD > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected > ecap 0003[140] = Serial 1 002590ffff363f80 > ecap 000e[150] = unknown 1 > ecap 0010[160] = unknown 1 > ix1@pci0:3:0:1: class=0x020000 card=0xffffffff chip=0x10fc8086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xfb800000, size 2097152, > enabled > bar [18] = type I/O Port, range 32, base 0xd880, size 32, enabled > bar [20] = type Memory, range 64, base 0xfbbf8000, size 16384, > enabled > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > cap 03[e0] = VPD > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected > ecap 0003[140] = Serial 1 002590ffff363f80 > ecap 000e[150] = unknown 1 > ecap 0010[160] = unknown 1 > > I am using ix1, as the blade enclosure has only one 10G switch and it > happens to be on the 'second' position. > > Daniel From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 11:00:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06EC3106566B for ; Thu, 8 Dec 2011 11:00:41 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost02.isp.att.net (fmailhost02.isp.att.net [204.127.217.102]) by mx1.freebsd.org (Postfix) with ESMTP id E8E548FC08 for ; Thu, 8 Dec 2011 11:00:40 +0000 (UTC) Date: Thu, 8 Dec 2011 11:00:40 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-18-68-26.sdf.bellsouth.net[68.18.68.26]) by isp.att.net (frfwmhc02) with SMTP id <20111208110039H02007r3b4e>; Thu, 8 Dec 2011 11:00:40 +0000 X-Originating-IP: [68.18.68.26] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <5DCB63CC-183F-4A7A-964A-EBBD70705C54@gsoft.com.au> Message-Id: <20111208110041.06EC3106566B@hub.freebsd.org> Cc: Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 11:00:41 -0000 from my last message: I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, and now I see RC3 is available. I tried "options ATA_CAM" in kernel config, removing "device atapicam", but still readcd -scanbus or cdrecord -scanbus refuses to work, running as root. "camcontrol devlist" shows my DVD drive, and I am able to mount and read /dev/cd0. Is cdrtools buggy, or maybe the FreeBSD port is buggy? "Daniel O'Connor" responded: > Define "refuses to work".. > I have an oldish 9.0-CURRENT which works with cdrecord.. > [titus 1:16] ~ >cdrecord -scanbus > Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 J?rg Schilling > Using libscg version 'schily-0.9'. > scsibus1: > 1,0,0 100) 'PIONEER ' 'DVD-RW DVR-112D' '1.09' Removable CD-ROM > 1,1,0 101) * > 1,2,0 102) * > 1,3,0 103) * > 1,4,0 104) * > 1,5,0 105) * > 1,6,0 106) * > 1,7,0 107) * cdrecord -scanbus produces cdrecord: Inappropriate ioctl for device. CAMIOCOMMAND ioctl failed. Cannot open or use SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Jörg Schilling About the same with readcd, and cdrecord dev=help is no help. from grarpamp : > In the past, I've used the ftp cdrtools pkg (made from the > port of course) and it failed to work. It's a popular tool so my > machine was probably out of sync. Same with burncd. However, > compiling the current cdrtools source worked fine. So I'd try > that first, compare, and send up a bug if need be. > Try to skip the scan by specifying the BTL or devpath on the > command line. The scan is a big part of the port and might > have breakage, at least for the app below. > Also, if you're doing audio, someone over on ports has said > they're doing an update to cdparanoia. It's minor, but useful > for that crowd. > makefs and burncd are part of the base, at least on RELENG_8. > And makefs is used in the official releases. So they should just work. > Good luck. You mean build cdrtools, or possibly cdrkit, directly from the source outside the FreeBSD ports collection. I could then see if I could make that into my own port, or else install to prefix /usr/local2. If there is a conflict between cdrkit and cdrtools, maybe install the other to prefix /usr/local3? Then I could spawn a subshell with /usr/local2/bin or /usr/local3/bin added to the PATH. If I get something to work, I could report back to this ports emailing list, share the benefits with others. Tom From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 13:30:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA920106564A; Thu, 8 Dec 2011 13:30:51 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 449838FC14; Thu, 8 Dec 2011 13:30:51 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id E413D7E824; Fri, 9 Dec 2011 00:11:50 +1100 (EST) Message-ID: <4EE0B796.3050800@freebsd.org> Date: Fri, 09 Dec 2011 00:11:50 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111016 Thunderbird/7.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> In-Reply-To: <20111207180807.GA71878@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Daniel Kalchev , Andre Oppermann , current@freebsd.org, Jack Vogel Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 13:30:52 -0000 On 12/08/11 05:08, Luigi Rizzo wrote: > On Wed, Dec 07, 2011 at 11:59:43AM +0100, Andre Oppermann wrote: >> On 06.12.2011 22:06, Luigi Rizzo wrote: > ... >>> Even in my experiments there is a lot of instability in the results. >>> I don't know exactly where the problem is, but the high number of >>> read syscalls, and the huge impact of setting interrupt_rate=0 >>> (defaults at 16us on the ixgbe) makes me think that there is something >>> that needs investigation in the protocol stack. >>> >>> Of course we don't want to optimize specifically for the one-flow-at-10G >>> case, but devising something that makes the system less affected >>> by short timing variations, and can pass upstream interrupt mitigation >>> delays would help. >> >> I'm not sure the variance is only coming from the network card and >> driver side of things. The TCP processing and interactions with >> scheduler and locking probably play a big role as well. There have >> been many changes to TCP recently and maybe an inefficiency that >> affects high-speed single sessions throughput has crept in. That's >> difficult to debug though. > > I ran a bunch of tests on the ixgbe (82599) using RELENG_8 (which > seems slightly faster than HEAD) using MTU=1500 and various > combinations of card capabilities (hwcsum,tso,lro), different window > sizes and interrupt mitigation configurations. > > default latency is 16us, l=0 means no interrupt mitigation. > lro is the software implementation of lro (tcp_lro.c) > hwlro is the hardware one (on 82599). Using a window of 100 Kbytes > seems to give the best results. > > Summary: [snip] > - enabling software lro on the transmit side actually slows > down the throughput (4-5Gbit/s instead of 8.0). > I am not sure why (perhaps acks are delayed too much) ? > Adding a couple of lines in tcp_lro to reject > pure acks seems to have much better effect. > > The tcp_lro patch below might actually be useful also for > other cards. > > --- tcp_lro.c (revision 228284) > +++ tcp_lro.c (working copy) > @@ -245,6 +250,8 @@ > > ip_len = ntohs(ip->ip_len); > tcp_data_len = ip_len - (tcp->th_off<< 2) - sizeof (*ip); > + if (tcp_data_len == 0) > + return -1; /* not on ack */ > > > /* There is a bug with our LRO implementation (first noticed by Jeff Roberson) that I started fixing some time back but dropped the ball on. The crux of the problem is that we currently only send an ACK for the entire LRO chunk instead of all the segments contained therein. Given that most stacks rely on the ACK clock to keep things ticking over, the current behaviour kills performance. It may well be the cause of the performance loss you have observed. WIP patch is at: http://people.freebsd.org/~lstewart/patches/misctcp/tcplro_multiack_9.x.r219723.patch Jeff tested the WIP patch and it *doesn't* fix the issue. I don't have LRO capable hardware setup locally to figure out what I've missed. Most of the machines in my lab are running em(4) NICs which don't support LRO, but I'll see if I can find something which does and perhaps resurrect this patch. If anyone has any ideas what I'm missing in the patch to make it work, please let me know. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 13:47:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21FB4106564A for ; Thu, 8 Dec 2011 13:47:51 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id B44738FC0A for ; Thu, 8 Dec 2011 13:47:50 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id EE07D740064 for ; Thu, 8 Dec 2011 14:46:57 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Fabien Thomas In-Reply-To: <7816AB07-1FCC-451C-9194-9E7DFFFAC563@netasq.com> Date: Thu, 8 Dec 2011 14:47:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <89F05833-18D7-4DCB-BDD1-1D8FA4C01D54@netasq.com> References: <7816AB07-1FCC-451C-9194-9E7DFFFAC563@netasq.com> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1084) Subject: Re: [RFC] VIA south bridge watchdog support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 13:47:51 -0000 > Hi, >=20 > If someone want to look at I've added support for VIA south bridge = watchdog. > It has been tested on VX900 but should works with VX800, VX855, CX700. >=20 > http://people.freebsd.org/~fabient/patch-watchdog-via-rev1 >=20 Posted rev2 : http://people.freebsd.org/~fabient/patch-watchdog-via-rev2 - add / test VT8251 - man page update - reset FIRED bit when detected Maybe other south bridge supported but feedback is needed. Fabien= From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 14:02:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6275B106564A for ; Thu, 8 Dec 2011 14:02:35 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.freebsd.org (Postfix) with ESMTP id EC5528FC08 for ; Thu, 8 Dec 2011 14:02:34 +0000 (UTC) Received: from charlemagne.boland.org (59-36-215.ftth.xms.internl.net [82.215.36.59]) (authenticated bits=0) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id pB8DnO2m093186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 8 Dec 2011 14:49:25 +0100 (CET) (envelope-from boland37@xs4all.nl) Message-ID: <4EE0C064.8080902@xs4all.nl> Date: Thu, 08 Dec 2011 14:49:24 +0100 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20111110 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20111208002549.87261106566B@hub.freebsd.org> In-Reply-To: <20111208002549.87261106566B@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 14:02:35 -0000 On 12/08/2011 01:25, Thomas Mueller wrote: > I can't get cdrtools (cdrecord or readcd) to work on FreeBSD 9.0-RC2, and now I see RC3 is available. > > I tried "options ATA_CAM" in kernel config, removing "device atapicam", but still > readcd -scanbus or > cdrecord -scanbus > refuses to work, running as root. > > "camcontrol devlist" shows my DVD drive, and I am able to mount and read /dev/cd0. > > Is cdrtools buggy, or maybe the FreeBSD port is buggy? > > I see from the Makefile that sysutils/cdrdao is broken on FreeBSD 9.x, does not link. > > I downloaded cdrkit-1.1.11.tar.gz so as to extract and have a look at it, and possibly build it on my own, outside the ports system. > > I see the version in ports system is 1.1.9, maybe 1.1.11 could do better? > > Maybe the FreeBSD developers were too hasty to deprecate burncd? Recompile the port; the CAM ioctl numbers have changed. Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 14:22:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228851065670 for ; Thu, 8 Dec 2011 14:22:44 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC798FC0A for ; Thu, 8 Dec 2011 14:22:43 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1RYeax-000F52-0B for freebsd-current@freebsd.org; Thu, 08 Dec 2011 18:05:07 +0400 Date: Thu, 8 Dec 2011 18:05:06 +0400 From: Slawa Olhovchenkov To: freebsd-current@freebsd.org Message-ID: <20111208140506.GA51886@zxy.spb.ru> References: <20111205192703.GA49118@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111205192703.GA49118@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Subject: Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 14:22:44 -0000 On Mon, Dec 05, 2011 at 08:27:03PM +0100, Luigi Rizzo wrote: > Hi, > I am trying to establish the baseline performance for 10G throughput > over TCP, and would like to collect some data points. As a testing > program i am using nuttcp from ports (as good as anything, i > guess -- it is reasonably flexible, and if you use it in > TCP with relatively large writes, the overhead for syscalls > and gettimeofday() shouldn't kill you). > > I'd be very grateful if you could do the following test: > > - have two machines connected by a 10G link > - on one run "nuttcp -S" > - on the other one run "nuttcp -t -T 5 -w 128 -v the.other.ip" > > and send me a dump of the output, such as the one(s) at the end of > the message. > > I am mostly interested in two configurations: > - one over loopback, which should tell how fast is the CPU+memory > As an example, one of my machines does about 15 Gbit/s, and > one of the faster ones does about 44 Gbit/s > > - one over the wire using 1500 byte mss. Here it really matters > how good is the handling of small MTUs. > > As a data point, on my machines i get 2..3.5 Gbit/s on the > "slow" machine with a 1500 byte mtu and default card setting. > Clearing the interrupt mitigation register (so no mitigation) > brings the rate to 5-6 Gbit/s. Same hardware with linux does > about 8 Gbit/s. HEAD seems 10-20% slower than RELENG_8 though i > am not sure who is at fault. > > The receive side is particularly critical - on FreeBSD > the receiver is woken up every two packets (do the math > below, between the number of rx calls and throughput and mss), > resulting in almost 200K activations per second, and despite > the fact that interrupt mitigation is set to a much lower > value (so incoming packets should be batched). > On linux, i see much fewer reads, presumably the process is > woken up only at the end of a burst. About relative performance FreeBSD and Linux I wrote in -performance@ at Jan'11 (Interrupt performance) > > ------------ EXAMPLES OF OUTPUT ---------------------- > > > nuttcp -t -T 5 -w 128 -v 10.0.1.2 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.0.1.2 > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.0.1.2 with mss=1460, RTT=0.103 ms > nuttcp-t: send window size = 131400, receive window size = 65700 > nuttcp-t: 3095.0982 MB in 5.00 real seconds = 633785.85 KB/sec = 5191.9737 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 49522 I/O calls, msec/call = 0.10, calls/sec = 9902.99 > nuttcp-t: 0.0user 2.7sys 0:05real 54% 100i+2639d 752maxrss 0+3pf 258876+6csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.0.1.4 > nuttcp-r: send window size = 33580, receive window size = 131400 > nuttcp-r: 3095.0982 MB in 5.17 real seconds = 613526.42 KB/sec = 5026.0084 Mbps > nuttcp-r: 1114794 I/O calls, msec/call = 0.00, calls/sec = 215801.03 > nuttcp-r: 0.1user 3.5sys 0:05real 69% 112i+1104d 626maxrss 0+15pf 507653+188csw > > > > > nuttcp -t -T 5 -w 128 -v localhost > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.051 ms > nuttcp-t: send window size = 143360, receive window size = 71680 > nuttcp-t: 26963.4375 MB in 5.00 real seconds = 5521440.59 KB/sec = 45231.6413 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 431415 I/O calls, msec/call = 0.01, calls/sec = 86272.51 > nuttcp-t: 0.0user 4.6sys 0:05real 93% 102i+2681d 774maxrss 0+3pf 2510+1csw > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 127.0.0.1 > nuttcp-r: send window size = 43008, receive window size = 143360 > nuttcp-r: 26963.4375 MB in 5.20 real seconds = 5313135.74 KB/sec = 43525.2080 Mbps > nuttcp-r: 767807 I/O calls, msec/call = 0.01, calls/sec = 147750.09 > nuttcp-r: 0.1user 3.9sys 0:05real 79% 98i+2570d 772maxrss 0+16pf 311014+8csw > > > on the server, run " > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 15:18:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA745106564A; Thu, 8 Dec 2011 15:18:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0BD8FC08; Thu, 8 Dec 2011 15:18:46 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E62A97300A; Thu, 8 Dec 2011 16:34:54 +0100 (CET) Date: Thu, 8 Dec 2011 16:34:54 +0100 From: Luigi Rizzo To: Lawrence Stewart Message-ID: <20111208153454.GA80979@onelab2.iet.unipi.it> References: <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> <4EE0B796.3050800@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EE0B796.3050800@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Daniel Kalchev , Jack Vogel , Andre Oppermann , current@freebsd.org, np@freebsd.org Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:18:46 -0000 On Fri, Dec 09, 2011 at 12:11:50AM +1100, Lawrence Stewart wrote: > On 12/08/11 05:08, Luigi Rizzo wrote: ... > >I ran a bunch of tests on the ixgbe (82599) using RELENG_8 (which > >seems slightly faster than HEAD) using MTU=1500 and various > >combinations of card capabilities (hwcsum,tso,lro), different window > >sizes and interrupt mitigation configurations. > > > >default latency is 16us, l=0 means no interrupt mitigation. > >lro is the software implementation of lro (tcp_lro.c) > >hwlro is the hardware one (on 82599). Using a window of 100 Kbytes > >seems to give the best results. > > > >Summary: > > [snip] > > >- enabling software lro on the transmit side actually slows > > down the throughput (4-5Gbit/s instead of 8.0). > > I am not sure why (perhaps acks are delayed too much) ? > > Adding a couple of lines in tcp_lro to reject > > pure acks seems to have much better effect. > > > >The tcp_lro patch below might actually be useful also for > >other cards. > > > >--- tcp_lro.c (revision 228284) > >+++ tcp_lro.c (working copy) > >@@ -245,6 +250,8 @@ > > > > ip_len = ntohs(ip->ip_len); > > tcp_data_len = ip_len - (tcp->th_off<< 2) - sizeof (*ip); > >+ if (tcp_data_len == 0) > >+ return -1; /* not on ack */ > > > > > > /* > > There is a bug with our LRO implementation (first noticed by Jeff > Roberson) that I started fixing some time back but dropped the ball on. > The crux of the problem is that we currently only send an ACK for the > entire LRO chunk instead of all the segments contained therein. Given > that most stacks rely on the ACK clock to keep things ticking over, the > current behaviour kills performance. It may well be the cause of the > performance loss you have observed. I should clarify better. First of all, i tested two different LRO implementations: our "Software LRO" (tcp_lro.c), and the "Hardware LRO" which is implemented by the 82599 (called RSC or receive-side-coalescing in the 82599 data sheets). Jack Vogel and Navdeep Parhar (both in Cc) can probably comment on the logic of both. In my tests, either SW or HW LRO on the receive side HELPED A LOT, not just in terms of raw throughput but also in terms of system load on the receiver. On the receive side, LRO packs multiple data segments into one that is passed up the stack. As you mentioned this also reduces the number of acks generated, but not dramatically (consider, the LRO is bounded by the number of segments received in the mitigation interval). In my tests the number of reads() on the receiver was reduced by approx a factor of 3 compared to the !LRO case, meaning 4-5 segment merged by LRO. Navdeep reported some numbers for cxgbe with similar numbers. Using Hardware LRO on the transmit side had no ill effect. Being done in hardware i have no idea how it is implemented. Using Software LRO on the transmit side did give a significant throughput reduction. I can't explain the exact cause, though it is possible that between reducing the number of segments to the receiver and collapsing ACKs that it generates, the sender starves. But it could well be that it is the extra delay on passing up the ACKs that limits performance. Either way, since the HW LRO did a fine job, i was trying to figure out whether avoiding LRO on pure acks could help, and the two-line patch above did help. Note, my patch was just a proof-of-concept, and may cause reordering if a data segment is followed by a pure ack. But this can be fixed easily, handling a pure ack as an out-of-sequence packet in tcp_lro_rx(). > WIP patch is at: > http://people.freebsd.org/~lstewart/patches/misctcp/tcplro_multiack_9.x.r219723.patch > > Jeff tested the WIP patch and it *doesn't* fix the issue. I don't have > LRO capable hardware setup locally to figure out what I've missed. Most > of the machines in my lab are running em(4) NICs which don't support > LRO, but I'll see if I can find something which does and perhaps > resurrect this patch. a few comments: 1. i don't think it makes sense to send multiple acks on coalesced segments (and the 82599 does not seem to do that). First of all, the acks would get out with minimal spacing (ideally less than 100ns) so chances are that the remote end will see them in a single burst anyways. Secondly, the remote end can easily tell that a single ACK is reporting multiple MSS and behave as if an equivalent number of acks had arrived. 2. i am a big fan of LRO (and similar solutions), because it can save a lot of repeated work when passing packets up the stack, and the mechanism becomes more and more effective as the system load increases, which is a wonderful property in terms of system stability. For this reason, i think it would be useful to add support for software LRO in the generic code (sys/net/if.c) so that drivers can directly use the software implementation even without hardware support. 3. similar to LRO, it would make sense to implement a "software TSO" mechanism where the TCP sender pushes a large segment down to ether_output, and having code in if_ethersubr.c do the segmentation and checksum computation. This would save multiple traversals of the various layers on the stack recomputing essentially the same information on all segments. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 15:40:19 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E17106564A; Thu, 8 Dec 2011 15:40:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B9FCB8FC15; Thu, 8 Dec 2011 15:40:19 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 7106046B0D; Thu, 8 Dec 2011 10:40:19 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E6348B93A; Thu, 8 Dec 2011 10:40:18 -0500 (EST) Message-ID: <4EE0DA63.8000305@FreeBSD.org> Date: Thu, 08 Dec 2011 10:40:19 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4EDBF01B.8000802@FreeBSD.org> In-Reply-To: <4EDBF01B.8000802@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 08 Dec 2011 10:40:19 -0500 (EST) Cc: mdf@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:40:20 -0000 On 12/4/11 5:11 PM, Andriy Gapon wrote: > on 02/12/2011 17:30 mdf@FreeBSD.org said the following: >> On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote: >>> on 02/12/2011 06:36 John Baldwin said the following: >>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was >>>> active). But I think these two changes should cover critical_exit() ok. >>>> >>> >>> I attempted to start a discussion about this a few times already :-) >>> Should we treat kdb context the same as SCHEDULER_STOPPED context (in the >>> current definition) ? That is, skip all locks in the same fashion? >>> There are pros and contras. >> >> Does kdb pause all CPUs with an interrupt (NMI or regular interrupt, I >> can no longer remember...) when it enters? If so, then I'd say >> whether it enters via sysctl or panic doesn't matter. It's in a >> special environment where nothing else is running, which is what is >> needed for proper exploration of the machine (via breakpoint, for >> debugging a hang, etc). >> >> Maybe the question is, why wouldn't SCHEDULER_STOPPED be true >> regardless of how kdb is entered? > > I think that the discussion that followed has clarified this point a bit. > SCHEDULER_STOPPED perhaps needs a better name :-) Currently it, the name, > reflects the state of the scheduler, but not why the scheduler is stopped and > not the greater state of the system ("in panic"), nor how we should handle that > state ("bypass locking"). So I'd love something like BYPASS_LOCKING_BECAUSE > _SCHEDULER_IS_STOPPED_IN_PANIC haven't it be so unwieldy :) Oh, hmm. Yes, being in the debugger should not potentially corrupt lock state, so in that sense it is a weaker stop. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 15:56:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 055FE1065676 for ; Thu, 8 Dec 2011 15:56:21 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id C09118FC1E for ; Thu, 8 Dec 2011 15:56:20 +0000 (UTC) Received: from [127.0.0.1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pB8FtksV012633; Thu, 8 Dec 2011 07:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1323359748; bh=O8Eps2P4/ZkugMN4rWx+A4+Es1CDzXoKlnscHZcCRlk=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=MIXBd045XhQhctSuYdJeEA+yjC9n/VS1RGVmAScVDtHAsaLTR2cmxMwr0mBPwzvmC UnWEDNGO6WC5ZO/MkmotA1ib12Jy1qNUNbQnJ555pwnm60VIKVa9S52wXQ2J2pe3HT swQK/SRTtzwEocb4FGzZK51GYWCBPBaraBS25bgY= From: Sean Bruno To: Peter Maloney In-Reply-To: <4EE08CA8.1060506@brockmann-consult.de> References: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> <4EE08CA8.1060506@brockmann-consult.de> Content-Type: text/plain; charset="UTF-8" Date: Thu, 08 Dec 2011 07:55:46 -0800 Message-ID: <1323359746.2710.7.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: Dog Food X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:56:21 -0000 On Thu, 2011-12-08 at 02:08 -0800, Peter Maloney wrote: > And what problems did you run into? > More or less, trying to do gmirror(4) style mirroring on GPT partitions doesn't work. See http://www.freebsd.org/doc/handbook/geom-mirror.html for the BIG RED WARNING that says why. > This guide worked for me: > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror That, along with a lot of how to's, is out of date in the FreeBSD 9 world. I would suspect that my experience of attempting to setup a mirrored volume won't be unique. BSDInstaller and its predecessor Sysinstall don't have any code to create or destroy zfs(4) or geom(4) volumes. So, the amount of exposure to real users is approaching 0 in comparison to the number of people who really do use FreeBSD. I have my hands full with other projects at the moment, but I'm more than happy to grant access to a two disk SATA server if someone wants to enhance BSDInstall with zfs(4) or geom(4) volume management features. At a minimum, you *should* be able to take 2 disks and make a mirrored volume with either tool. Sean From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 16:07:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B36271065670 for ; Thu, 8 Dec 2011 16:07:45 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 680538FC22 for ; Thu, 8 Dec 2011 16:07:45 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2620844vbb.13 for ; Thu, 08 Dec 2011 08:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I5Q/ElNiphQZQTD9IjgegB11DvkTV/sks1Hnas1tbmI=; b=qTYQRab6WUeWzDjle6XwqO11JJVrlneizQ+KIB3SQwcEdjQYyY3isqyfrPtTPt5KOz urMdkhbysc5q5aAx32QDkDkruFiqzR06/xe7R/l7abJ0DLpKv2QmFn9bI7oZIYoNRu2N Kh685GrUlr3q9/4cHLt54WAno7tMVS0l7qqSQ= MIME-Version: 1.0 Received: by 10.52.33.239 with SMTP id u15mr2036645vdi.49.1323360464601; Thu, 08 Dec 2011 08:07:44 -0800 (PST) Received: by 10.52.172.240 with HTTP; Thu, 8 Dec 2011 08:07:44 -0800 (PST) In-Reply-To: <1323359746.2710.7.camel@hitfishpass-lx.corp.yahoo.com> References: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> <4EE08CA8.1060506@brockmann-consult.de> <1323359746.2710.7.camel@hitfishpass-lx.corp.yahoo.com> Date: Thu, 8 Dec 2011 16:07:44 +0000 Message-ID: From: Tom Evans To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" , Peter Maloney Subject: Re: Dog Food X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 16:07:45 -0000 On Thu, Dec 8, 2011 at 3:55 PM, Sean Bruno wrote: > On Thu, 2011-12-08 at 02:08 -0800, Peter Maloney wrote: >> And what problems did you run into? >> > > More or less, trying to do gmirror(4) style mirroring on GPT partitions > doesn't work. =C2=A0See http://www.freebsd.org/doc/handbook/geom-mirror.h= tml > for the BIG RED WARNING that says why. > Er, gmirroring GPT _partitions_ works just fine. It is when you try to gmirror an entire disk that is partitioned with GPT that you have issues, as gmirror trashes the secondary GPT table at the end of the disk. You do not have that issue with individual GPT partitions. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 17:31:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C73561065672 for ; Thu, 8 Dec 2011 17:31:01 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD448FC0C for ; Thu, 8 Dec 2011 17:31:00 +0000 (UTC) Received: by eekc50 with SMTP id c50so1394676eek.13 for ; Thu, 08 Dec 2011 09:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=O0BEbII4EieN1lX8jH8U8Y5Jrz0g9ZOv2fKpCXuAKQw=; b=ZUazu7zrI8KKAtzPTkvzPZ2fjWj1H5ocQ7iJxkFQ8h2APz4e83SdIbVfXciHDdHygT ZoCYLa7QlewGKyS4YJZrRJ9BALXFXKTknyi56NOeHeXuXkTXIWMmS1DZTFJz0pYbszWf 1dIaI+60zU2ahj7wdHDAidCmrNOyhug7PH6vw= Received: by 10.14.34.5 with SMTP id r5mr305314eea.132.1323365460185; Thu, 08 Dec 2011 09:31:00 -0800 (PST) Received: from [192.168.1.11] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id 53sm20095598eef.2.2011.12.08.09.30.58 (version=SSLv3 cipher=OTHER); Thu, 08 Dec 2011 09:30:59 -0800 (PST) Message-ID: <4EE0F44F.4080503@gmail.com> Date: Thu, 08 Dec 2011 18:30:55 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sean Bruno , freebsd-current@freebsd.org References: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> <4EE08CA8.1060506@brockmann-consult.de> <1323359746.2710.7.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1323359746.2710.7.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Dog Food X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 17:31:01 -0000 Sean Bruno schreef: > On Thu, 2011-12-08 at 02:08 -0800, Peter Maloney wrote: >> And what problems did you run into? >> > More or less, trying to do gmirror(4) style mirroring on GPT partitions > doesn't work. See http://www.freebsd.org/doc/handbook/geom-mirror.html > for the BIG RED WARNING that says why. > >> This guide worked for me: >> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror > That, along with a lot of how to's, is out of date in the FreeBSD 9 > world. I would suspect that my experience of attempting to setup a > mirrored volume won't be unique. > > BSDInstaller and its predecessor Sysinstall don't have any code to > create or destroy zfs(4) or geom(4) volumes. So, the amount of exposure > to real users is approaching 0 in comparison to the number of people who > really do use FreeBSD. > > I have my hands full with other projects at the moment, but I'm more > than happy to grant access to a two disk SATA server if someone wants to > enhance BSDInstall with zfs(4) or geom(4) volume management features. > > At a minimum, you *should* be able to take 2 disks and make a mirrored > volume with either tool. > > Sean also a good guide is here. http://unix-heaven.org/node/24 And gmirror GPT partitions is no problem, only with whole disks is where problems arise. regards Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Thu Dec 8 18:20:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0E1106566B for ; Thu, 8 Dec 2011 18:20:25 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C49608FC16 for ; Thu, 8 Dec 2011 18:20:24 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A5D8AE6643; Thu, 8 Dec 2011 18:20:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=sfYFHZmUUO50 Vy0CpTBiv8Z1myQ=; b=LEaF8QWo+DEEc2eG5BiWw+ochkbxcFLLCWJ0Ox5sLMW8 3GgJVuS+l9SdXxXO9ZUAjkDcJH9gj3qrMs7I+dcFkRVnfuURlsf/Dv466esup1fK OLuVPzk83omKDXJDvKmRpTLT45guZHNa7pl83vOxU2sHU/RLneVC5h84IiA9vd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=bW3KK5 ArwTWQQa+nlnO0MVvFaYYzftTXphp1IVWI7thErvGPB+3P0CNW2I8nMByMzDa1Qs Y5oD/gDydAfErHUWJK5Mb9QFcyFfSRDSZCAIFT/O5D98bkB+w2WseH5Wvz9VPHhN 8O0XV6VV6ybssKcnyqIlJKL3HobjC9CH/5LR4= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 7C88AE6642; Thu, 8 Dec 2011 18:20:23 +0000 (GMT) Message-ID: <4EE0FFE2.2030504@cran.org.uk> Date: Thu, 08 Dec 2011 18:20:18 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sean Bruno References: <1323208265.19452.15.camel@hitfishpass-lx.corp.yahoo.com> <4EE08CA8.1060506@brockmann-consult.de> <1323359746.2710.7.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1323359746.2710.7.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , Peter Maloney Subject: Re: Dog Food X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:20:25 -0000 On 08/12/2011 15:55, Sean Bruno wrote: > BSDInstaller and its predecessor Sysinstall don't have any code to > create or destroy zfs(4) or geom(4) volumes. So, the amount of exposure > to real users is approaching 0 in comparison to the number of people who > really do use FreeBSD. > > I have my hands full with other projects at the moment, but I'm more > than happy to grant access to a two disk SATA server if someone wants to > enhance BSDInstall with zfs(4) or geom(4) volume management features. I don't know if it supports RAID, but the geom-aware rewrite of sade(4) supports zfs: http://butcher.heavennet.ru/sade/ Unfortunately it was never completed because of the difficulties of using ncurses/dialog. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 00:10:37 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CAFB106566B for ; Fri, 9 Dec 2011 00:10:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 056598FC0C for ; Fri, 9 Dec 2011 00:10:36 +0000 (UTC) Received: (qmail 74525 invoked from network); 8 Dec 2011 22:41:06 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Dec 2011 22:41:06 -0000 Message-ID: <4EE151F6.20604@freebsd.org> Date: Fri, 09 Dec 2011 01:10:30 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Lawrence Stewart References: <20111205192703.GA49118@onelab2.iet.unipi.it> <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> <4EE0B796.3050800@freebsd.org> In-Reply-To: <4EE0B796.3050800@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Kalchev , Luigi Rizzo , current@freebsd.org, Jack Vogel Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 00:10:37 -0000 On 08.12.2011 14:11, Lawrence Stewart wrote: > On 12/08/11 05:08, Luigi Rizzo wrote: >> On Wed, Dec 07, 2011 at 11:59:43AM +0100, Andre Oppermann wrote: >>> On 06.12.2011 22:06, Luigi Rizzo wrote: >> ... >>>> Even in my experiments there is a lot of instability in the results. >>>> I don't know exactly where the problem is, but the high number of >>>> read syscalls, and the huge impact of setting interrupt_rate=0 >>>> (defaults at 16us on the ixgbe) makes me think that there is something >>>> that needs investigation in the protocol stack. >>>> >>>> Of course we don't want to optimize specifically for the one-flow-at-10G >>>> case, but devising something that makes the system less affected >>>> by short timing variations, and can pass upstream interrupt mitigation >>>> delays would help. >>> >>> I'm not sure the variance is only coming from the network card and >>> driver side of things. The TCP processing and interactions with >>> scheduler and locking probably play a big role as well. There have >>> been many changes to TCP recently and maybe an inefficiency that >>> affects high-speed single sessions throughput has crept in. That's >>> difficult to debug though. >> >> I ran a bunch of tests on the ixgbe (82599) using RELENG_8 (which >> seems slightly faster than HEAD) using MTU=1500 and various >> combinations of card capabilities (hwcsum,tso,lro), different window >> sizes and interrupt mitigation configurations. >> >> default latency is 16us, l=0 means no interrupt mitigation. >> lro is the software implementation of lro (tcp_lro.c) >> hwlro is the hardware one (on 82599). Using a window of 100 Kbytes >> seems to give the best results. >> >> Summary: > > [snip] > >> - enabling software lro on the transmit side actually slows >> down the throughput (4-5Gbit/s instead of 8.0). >> I am not sure why (perhaps acks are delayed too much) ? >> Adding a couple of lines in tcp_lro to reject >> pure acks seems to have much better effect. >> >> The tcp_lro patch below might actually be useful also for >> other cards. >> >> --- tcp_lro.c (revision 228284) >> +++ tcp_lro.c (working copy) >> @@ -245,6 +250,8 @@ >> >> ip_len = ntohs(ip->ip_len); >> tcp_data_len = ip_len - (tcp->th_off<< 2) - sizeof (*ip); >> + if (tcp_data_len == 0) >> + return -1; /* not on ack */ >> >> >> /* > > There is a bug with our LRO implementation (first noticed by Jeff Roberson) that I started fixing > some time back but dropped the ball on. The crux of the problem is that we currently only send an > ACK for the entire LRO chunk instead of all the segments contained therein. Given that most stacks > rely on the ACK clock to keep things ticking over, the current behaviour kills performance. It may > well be the cause of the performance loss you have observed. WIP patch is at: > > http://people.freebsd.org/~lstewart/patches/misctcp/tcplro_multiack_9.x.r219723.patch > > Jeff tested the WIP patch and it *doesn't* fix the issue. I don't have LRO capable hardware setup > locally to figure out what I've missed. Most of the machines in my lab are running em(4) NICs which > don't support LRO, but I'll see if I can find something which does and perhaps resurrect this patch. > > If anyone has any ideas what I'm missing in the patch to make it work, please let me know. On low RTT's the accumulated ACKing probably doesn't make any difference. The congestion window will grow very fast anyway. On longer RTT's it sure will make a difference. Unless you have a 10Gig path with > 50ms or so it's difficult to empirically test though. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 00:33:11 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 459E51065676 for ; Fri, 9 Dec 2011 00:33:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 85B0B8FC12 for ; Fri, 9 Dec 2011 00:33:10 +0000 (UTC) Received: (qmail 74621 invoked from network); 8 Dec 2011 23:03:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Dec 2011 23:03:39 -0000 Message-ID: <4EE15740.9030505@freebsd.org> Date: Fri, 09 Dec 2011 01:33:04 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <2D87D847-A2B7-4E77-B6C1-61D73C9F582F@digsys.bg> <20111205222834.GA50285@onelab2.iet.unipi.it> <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> <4EE0B796.3050800@freebsd.org> <20111208153454.GA80979@onelab2.iet.unipi.it> In-Reply-To: <20111208153454.GA80979@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , Daniel Kalchev , Jack Vogel , current@freebsd.org, np@freebsd.org Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 00:33:11 -0000 On 08.12.2011 16:34, Luigi Rizzo wrote: > On Fri, Dec 09, 2011 at 12:11:50AM +1100, Lawrence Stewart wrote: >> On 12/08/11 05:08, Luigi Rizzo wrote: > ... >>> I ran a bunch of tests on the ixgbe (82599) using RELENG_8 (which >>> seems slightly faster than HEAD) using MTU=1500 and various >>> combinations of card capabilities (hwcsum,tso,lro), different window >>> sizes and interrupt mitigation configurations. >>> >>> default latency is 16us, l=0 means no interrupt mitigation. >>> lro is the software implementation of lro (tcp_lro.c) >>> hwlro is the hardware one (on 82599). Using a window of 100 Kbytes >>> seems to give the best results. >>> >>> Summary: >> >> [snip] >> >>> - enabling software lro on the transmit side actually slows >>> down the throughput (4-5Gbit/s instead of 8.0). >>> I am not sure why (perhaps acks are delayed too much) ? >>> Adding a couple of lines in tcp_lro to reject >>> pure acks seems to have much better effect. >>> >>> The tcp_lro patch below might actually be useful also for >>> other cards. >>> >>> --- tcp_lro.c (revision 228284) >>> +++ tcp_lro.c (working copy) >>> @@ -245,6 +250,8 @@ >>> >>> ip_len = ntohs(ip->ip_len); >>> tcp_data_len = ip_len - (tcp->th_off<< 2) - sizeof (*ip); >>> + if (tcp_data_len == 0) >>> + return -1; /* not on ack */ >>> >>> >>> /* >> >> There is a bug with our LRO implementation (first noticed by Jeff >> Roberson) that I started fixing some time back but dropped the ball on. >> The crux of the problem is that we currently only send an ACK for the >> entire LRO chunk instead of all the segments contained therein. Given >> that most stacks rely on the ACK clock to keep things ticking over, the >> current behaviour kills performance. It may well be the cause of the >> performance loss you have observed. > > I should clarify better. > First of all, i tested two different LRO implementations: our > "Software LRO" (tcp_lro.c), and the "Hardware LRO" which is implemented > by the 82599 (called RSC or receive-side-coalescing in the 82599 > data sheets). Jack Vogel and Navdeep Parhar (both in Cc) can > probably comment on the logic of both. > > In my tests, either SW or HW LRO on the receive side HELPED A LOT, > not just in terms of raw throughput but also in terms of system > load on the receiver. On the receive side, LRO packs multiple data > segments into one that is passed up the stack. > > As you mentioned this also reduces the number of acks generated, > but not dramatically (consider, the LRO is bounded by the number > of segments received in the mitigation interval). > In my tests the number of reads() on the receiver was reduced by > approx a factor of 3 compared to the !LRO case, meaning 4-5 segment > merged by LRO. Navdeep reported some numbers for cxgbe with similar > numbers. > > Using Hardware LRO on the transmit side had no ill effect. > Being done in hardware i have no idea how it is implemented. > > Using Software LRO on the transmit side did give a significant > throughput reduction. I can't explain the exact cause, though it > is possible that between reducing the number of segments to the > receiver and collapsing ACKs that it generates, the sender starves. > But it could well be that it is the extra delay on passing up the ACKs > that limits performance. > Either way, since the HW LRO did a fine job, i was trying to figure > out whether avoiding LRO on pure acks could help, and the two-line > patch above did help. > > Note, my patch was just a proof-of-concept, and may cause > reordering if a data segment is followed by a pure ack. > But this can be fixed easily, handling a pure ack as > an out-of-sequence packet in tcp_lro_rx(). > >> WIP patch is at: >> http://people.freebsd.org/~lstewart/patches/misctcp/tcplro_multiack_9.x.r219723.patch >> >> Jeff tested the WIP patch and it *doesn't* fix the issue. I don't have >> LRO capable hardware setup locally to figure out what I've missed. Most >> of the machines in my lab are running em(4) NICs which don't support >> LRO, but I'll see if I can find something which does and perhaps >> resurrect this patch. LRO can always be done in software. You can do it at driver, ether_input or ip_input level. > a few comments: > 1. i don't think it makes sense to send multiple acks on > coalesced segments (and the 82599 does not seem to do that). > First of all, the acks would get out with minimal spacing (ideally > less than 100ns) so chances are that the remote end will see > them in a single burst anyways. Secondly, the remote end can > easily tell that a single ACK is reporting multiple MSS and > behave as if an equivalent number of acks had arrived. ABC (appropriate byte counting) gets in the way though. > 2. i am a big fan of LRO (and similar solutions), because it can save > a lot of repeated work when passing packets up the stack, and the > mechanism becomes more and more effective as the system load increases, > which is a wonderful property in terms of system stability. > > For this reason, i think it would be useful to add support for software > LRO in the generic code (sys/net/if.c) so that drivers can directly use > the software implementation even without hardware support. It hurts on higher RTT links in the general case. For LAN RTT's it's good. > 3. similar to LRO, it would make sense to implement a "software TSO" > mechanism where the TCP sender pushes a large segment down to > ether_output, and having code in if_ethersubr.c do the segmentation > and checksum computation. This would save multiple traversals of > the various layers on the stack recomputing essentially the same > information on all segments. All modern NIC's support hardware TSO. There's little benefit in having a parallel software implementation. And then you run into the mbuf chain copying issue further down the layer. The win won't be much. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 00:37:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA0CE1065670; Fri, 9 Dec 2011 00:37:00 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id F14E58FC08; Fri, 9 Dec 2011 00:36:59 +0000 (UTC) Received: by ggnp1 with SMTP id p1so3669628ggn.13 for ; Thu, 08 Dec 2011 16:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Poo/dpGbokGuY7IaQqIis95T+lisaPQdOGzdw78OGvE=; b=wSxSN4TRaU5RJ0q+6Hr4vZeDdlWy8uIM/YuHo8OrqmaDaHI6h8EG2j3QyZEzjphm+D YFHUeF3qImM/ceqI880oqKpScvj84MXs6UG3l8zsJoG/dJBRFeG7YWaLXFQx58xPc9iS RG/M++R3kc7yv9QjwT2wpzV4+l8vluN76rXAw= MIME-Version: 1.0 Received: by 10.182.37.71 with SMTP id w7mr9obj.41.1323391019048; Thu, 08 Dec 2011 16:36:59 -0800 (PST) Received: by 10.182.74.198 with HTTP; Thu, 8 Dec 2011 16:36:58 -0800 (PST) Date: Thu, 8 Dec 2011 16:36:58 -0800 Message-ID: From: Matthew Fleming To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 09 Dec 2011 00:42:36 +0000 Cc: jfv@freebsd.org, Zack Kirsch Subject: Adding bool, true, and false to the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 00:37:00 -0000 Hello -current! Recently on -arch@, we discussed adding the C99 keywords bool, true, and false to the kernel. I now have patches to do this as well as fix up some build issues. The original thread was here: http://lists.freebsd.org/pipermail/freebsd-arch/2011-November/011937.html I split the patches in three: http://people.freebsd.org/~mdf/0001-e1000-ixgbe-fix-code-to-not-define-bool-true-false-w.patch fixes up the e1000 and ixgbe code. Jack, can you please let me know if there are any issues. This should work to build whether or not sys/types.h has the new defines; I am testing make universe right now. http://people.freebsd.org/~mdf/0002-Fix-code-to-not-define-bool-true-false-when-already-.patch fixes the other code in the sys/ directory that gives build conflicts. Since I wasn't sure of the origin of the drivers, I conservatively left all their defines alone to allow the same driver code to build on both CURRENT and 9.0. If some of the drivers are wholly-owned by FreeBSD (unlike e1000 and ixgbe) and are not expected to be built on older releases, then the use of the old defines can be removed. If anyone knows the provenance of these files, please advise. http://people.freebsd.org/~mdf/0003-Define-bool-true-and-false-in-types.h-for-_KERNEL-co.patch actually defines bool, true, and false, and adds some extra paranoia in for anyone who has hacked their local build system and project repo to include in a kernel file. I also bumped __FreeBSD_version, though this is probably not necessary since __bool_true_false_are_defined is a better check than the __FreeBSD_version. This code should be MFC-able to stable/9 after 9.0 is released. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 00:42:50 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CCF1065686 for ; Fri, 9 Dec 2011 00:42:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCAD08FC12 for ; Fri, 9 Dec 2011 00:42:49 +0000 (UTC) Received: by ghbg20 with SMTP id g20so2499840ghb.13 for ; Thu, 08 Dec 2011 16:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=fm14AdDYb2dK4JcsRq/dSIDOYZ3v/pt+6zYC1468Meg=; b=I9sQpFOYfZKdeZ6keTYbi3TKJgczh65FxbQu+XPaHxomghtfGHkSbuReGw1xx3bC2r mQgOOxhK13ELRpb7sLrghGhMMXiHJgUNsqHcMMjBUau9wCnj4fkKLCjn90l7BSkujhje lJUbHNyuaiXIMA1aHlBao35Lty+Yk0z+nmryk= MIME-Version: 1.0 Received: by 10.101.143.4 with SMTP id v4mr1312146ann.146.1323391369125; Thu, 08 Dec 2011 16:42:49 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.100.93.8 with HTTP; Thu, 8 Dec 2011 16:42:49 -0800 (PST) Date: Thu, 8 Dec 2011 16:42:49 -0800 X-Google-Sender-Auth: GkOiCkgNE61R8G8LUN90g6j6ygU Message-ID: From: Maksim Yevmenkin To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: maxio is not exported by mps(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 00:42:50 -0000 Dear -hackers, can someone please enlighten me as to why maxio is not set by mps(4), and, what would be a reasonable number to set it to if i felt inclined to do so? default DFLTPHYS of 64K seems a bit low to me. thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 00:59:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 118ED1065672; Fri, 9 Dec 2011 00:59:36 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id BC4DA8FC14; Fri, 9 Dec 2011 00:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:References:In-Reply-To:Subject:To:From:Date:Content-Type:Mime-Version; bh=gEUvcysFavXLfmhWaue+juKdwbyhssRoJWgWTUq0WCw=; b=JSFf+ecIq0PdIMC95Aj5ysgfE4n9qUS7XrjKbaBh/stZmDmSVq5E+CiUlIRvNDaf+T9mcpKNufw4KPrqcZ96n+eSJVcYq7hnCSva+9pdFJsAun+C7xaNXP/yKqNKoCkO; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RYooH-0002su-JL; Thu, 08 Dec 2011 18:59:34 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1323392367-1863-1862/5/11; Fri, 9 Dec 2011 00:59:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Thu, 8 Dec 2011 18:59:27 -0600 From: Mark Felder To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <20111126104840.GA8794@garage.freebsd.pl> References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> <20111126104840.GA8794@garage.freebsd.pl> Message-Id: X-Sender: feld@feld.me User-Agent: Roundcube Webmail/0.6 X-SA-Score: -1.0 Cc: Subject: Re: zfs i/o hangs on 9-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 00:59:36 -0000 Hi all, Just wanted to report back that I found time to do more diagnostics. ZFS/FreeBSD/etc are not to blame. ZFS / FreeBSD never reported any I/O errors and scrubs always came up clean because one of the disks was failing and had issues reading the disk but would eventually return accurate data. It was sort of like having a RAIDZ with one disk that had 30s latency sometimes! Seatools confirmed this disk was failing and after replacing the disk all issues went away. From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 02:15:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997261065672; Fri, 9 Dec 2011 02:15:30 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmaila.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6A84B8FC0C; Fri, 9 Dec 2011 02:15:30 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 92D59CAD1; Thu, 8 Dec 2011 20:57:33 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id C1CD2CAD9; Thu, 8 Dec 2011 20:57:31 -0500 (EST) Received: from smtp3.acsu.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id AD455CAD1; Thu, 8 Dec 2011 20:57:31 -0500 (EST) Received: from [192.168.1.101] (cpe-72-231-248-9.buffalo.res.rr.com [72.231.248.9]) (Authenticated sender: kensmith@buffalo.edu) by smtp3.acsu.buffalo.edu (Postfix) with ESMTPSA id D9E7C49700; Thu, 8 Dec 2011 20:57:22 -0500 (EST) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-f6tWzedDIv0ABJnKFczJ" Organization: U. Buffalo Date: Thu, 08 Dec 2011 20:57:18 -0500 Message-ID: <1323395838.61446.20.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 27% Cc: Subject: FreeBSD 9.0-RC3 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 02:15:30 -0000 --=-f6tWzedDIv0ABJnKFczJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The third and what should be final Release Candidate build for the 9.0-RELEASE release cycle is now available. Since this is the beginning of a brand new branch (stable/9) I cross-post the announcements to both -current and -stable. But just so you know most of the developers active in head and stable/9 pay more attention to the -current mailing list. If you notice problems you can report them through the normal Gnats PR system or on the -current mailing list. This should be the last of the test builds. We hope to begin the final release builds in about a week. The 9.0-RELEASE cycle will be tracked here: http://wiki.freebsd.org/Releng/9.0TODO The location of the FTP install tree and ISOs is the same as it has been for BETA2/BETA3/RC1/RC2. The layout to a large degree is being dictated by the new build infrastructure and installer. But it's not particularly well suited to humans so I've added a shorter pathway to the ISOs. Unless there are lots of complaints about the layout we'll stick with this for the release. ISO images for amd64, i386, ia64, powerpc, powerpc64, and sparc64 are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ That directory is a set of symbolic links to the ISO images for all of the supported architectures, and checksum files (for example there is a symlink named CHECKSUM.MD5-amd64 that points to the CHECKSUM.MD5 file for the amd64 architecture). MD5/SHA256 checksums are tacked on below. If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is now "RELENG_9_0", if you use "." (head) you will get 10-CURRENT. If you would like to access the source tree via SVN it is "svn://svn.freebsd.org/base/releng/9.0/". We still have the nit that the creation of a new SVN branch winds up causing what looks like a check-in of the entire tree in CVS (a side-effect of the svn2cvs exporter) so "mergemaster -F" is your friend if you are using csup/cvsup. FreeBSD Update -------------- The freebsd-update(8) utility supports binary upgrades of i386 and amd64 sy= stems running earlier FreeBSD releases. Systems running 7.[34]-RELEASE, 8.[12]-RELEASE, 9.0-BETA[123], or 9.0-RC[1,2] can upgrade as follows: First, a minor change must be made to the freebsd-update code in order for it to accept file names appearing in FreeBSD 9.0 which contain the '%' and '@' characters; without this change, freebsd-update will error out with the message "The update metadata is correctly signed, but failed an integrity check". # sed -i '' -e 's/=3D_/=3D%@_/' /usr/sbin/freebsd-update Now freebsd-update can fetch bits belonging to 9.0-RC3. During this proces= s freebsd-update will ask for help in merging configuration files. # freebsd-update upgrade -r 9.0-RC3 Due to changes in the way that FreeBSD is packaged on the release media, tw= o complications may arise in this process if upgrading from FreeBSD 7.x or 8.= x: 1. The FreeBSD kernel, which previously could appear in either /boot/kernel or /boot/GENERIC, now only appears as /boot/kernel. As a result, any kerne= l appearing in /boot/GENERIC will be deleted. Please carefully read the outp= ut printed by freebsd-update and confirm that an updated kernel will be placed into /boot/kernel before proceeding beyond this point. 2. The FreeBSD source tree in /usr/src (if present) will be deleted. (Norm= ally freebsd-update will update a source tree, but in this case the changes in release packaging result in freebsd-update not recognizing that the source = tree from the old release and the source tree from the new release correspond to= the same part of FreeBSD.) # freebsd-update install The system must now be rebooted with the newly installed kernel before the non-kernel components are updated. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.2-RELEASE or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 9.0-RC3: Checksums: MD5 (FreeBSD-9.0-RC3-amd64-bootonly.iso) =3D 53f2bc5a3d18124769bfb066e92155= 9a MD5 (FreeBSD-9.0-RC3-amd64-disc1.iso) =3D b88eca54341523713712b184c6a7fc9a MD5 (FreeBSD-9.0-RC3-amd64-memstick.img) =3D a9b58348736d4a7a179941e818d339= 86 MD5 (FreeBSD-9.0-RC3-i386-bootonly.iso) =3D 86f0410ffb1c55fcb8faf33814e6e95= b MD5 (FreeBSD-9.0-RC3-i386-disc1.iso) =3D 3585047256b1b8f72319aa55ffa3c3ad MD5 (FreeBSD-9.0-RC3-i386-memstick.img) =3D 8be95b49c498e666f87957a8c10997c= e MD5 (FreeBSD-9.0-RC3-ia64-bootonly.iso) =3D 7a8e99a61d21ae8a5f6be9fb7f878b1= 1 MD5 (FreeBSD-9.0-RC3-ia64-memstick) =3D 5484765d3373c59372cdb53bbea2ab2d MD5 (FreeBSD-9.0-RC3-ia64-release.iso) =3D 7791f810dbe7d1ee7cf30510f0981424 MD5 (FreeBSD-9.0-RC3-powerpc-bootonly.iso) =3D 97a947ccd413371e24cfc83971bf= d83a MD5 (FreeBSD-9.0-RC3-powerpc-memstick) =3D 2ebbdb2379d1f0e1a24a5ac31f22cf6f MD5 (FreeBSD-9.0-RC3-powerpc-release.iso) =3D e6c38096826b015eaa63a8109b809= 250 MD5 (FreeBSD-9.0-RC3-powerpc64-bootonly.iso) =3D 360383e1d7fca3d93be73f5aa8= ce085c MD5 (FreeBSD-9.0-RC3-powerpc64-memstick) =3D 4b74c2d73b56f5f38590b0da2cf640= 54 MD5 (FreeBSD-9.0-RC3-powerpc64-release.iso) =3D 3e6e9519b3debb61047491ee700= f683b MD5 (FreeBSD-9.0-RC3-sparc64-bootonly.iso) =3D 8f352714c2c4228623239491aee8= 8e6a MD5 (FreeBSD-9.0-RC3-sparc64-disc1.iso) =3D b51648c80862f54d230cf13b4a34604= b SHA256 (FreeBSD-9.0-RC3-amd64-bootonly.iso) =3D 06d609bb0d927b64221f1207542= 794870b56538fd3983355c9013d1f17fe7382 SHA256 (FreeBSD-9.0-RC3-amd64-disc1.iso) =3D 16792eb1e90070b8c5d1ea8df55b29= 0534efba1543fb37950f8c7acd61839208 SHA256 (FreeBSD-9.0-RC3-amd64-memstick.img) =3D ae533e43e2390c5992c83acebfe= e35636baaa0694b7f1bae973fd4547a4e97ee SHA256 (FreeBSD-9.0-RC3-i386-bootonly.iso) =3D 88f417817eec36e183fdb8327206= 64956486ac169fb5528e93423e4ccd52ba61 SHA256 (FreeBSD-9.0-RC3-i386-disc1.iso) =3D cdbf1ce5668444c88ea141bfaec0bd4= 14c09b39969076915d2d9257c9f0802f2 SHA256 (FreeBSD-9.0-RC3-i386-memstick.img) =3D ea6e4ce993bc534a05d247bd65cc= f2a41e5e12cd36c75ca2a2dfdf0d77e996b5 SHA256 (FreeBSD-9.0-RC3-ia64-bootonly.iso) =3D cebb6bacde53bc4bc69f90484471= 07c38f69d6c655fcc5a7778dcae8c7387dc1 SHA256 (FreeBSD-9.0-RC3-ia64-memstick) =3D 46960b6567e3dcfea65dbeef107573f5= 147f2ec74d555d0aae19a81629cb2434 SHA256 (FreeBSD-9.0-RC3-ia64-release.iso) =3D a484ac6ac87e9a9c524cde453838a= 15aebffcc6b5811dbaf85b3b37691cea149 SHA256 (FreeBSD-9.0-RC3-powerpc-bootonly.iso) =3D a2a98542d9668b18ef10b85d0= e10026e15e9c6991bc09d9fa070e6eed34a93bb SHA256 (FreeBSD-9.0-RC3-powerpc-memstick) =3D 0320db4828122ef851e1a26f28bd1= eccf1b4e45d476fe23ec627c2daa559220b SHA256 (FreeBSD-9.0-RC3-powerpc-release.iso) =3D ee480650db05998560f26016bf= cf2c392da8a3eae94bec49a162f9f655aaa3f9 SHA256 (FreeBSD-9.0-RC3-powerpc64-bootonly.iso) =3D 7bd60e65929fd70133a21f8= 517715b22d992a45a29c2677e4c7a66a226bc492a SHA256 (FreeBSD-9.0-RC3-powerpc64-memstick) =3D 3fab51275ddf71016d9422c6bfb= 0806c51b0243d79f9f5011f9f2f78a631a607 SHA256 (FreeBSD-9.0-RC3-powerpc64-release.iso) =3D d48ec66421b9f74b8c11212a= 6b9d5240b20629e0685e0ee3485233e28eb3cfcd SHA256 (FreeBSD-9.0-RC3-sparc64-bootonly.iso) =3D 739a9430198b91cac1d625bcd= e202447fc47addc92430a72080dce224c3b5c67 SHA256 (FreeBSD-9.0-RC3-sparc64-disc1.iso) =3D 18a63e0cb420694172f49f7ad5a2= 09d40f348b19d3c96e8ecaeef8517b52cc22 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-f6tWzedDIv0ABJnKFczJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk7havYACgkQ/G14VSmup/YengCeLcsB2YHtbg+M/n+wzkLcgJKS +uUAnRqD4196B2tsHGjtlojlAJGNXVRY =IFqa -----END PGP SIGNATURE----- --=-f6tWzedDIv0ABJnKFczJ-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 02:33:01 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E00491065698; Fri, 9 Dec 2011 02:33:01 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7D18FC0C; Fri, 9 Dec 2011 02:33:01 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A08D27300A; Fri, 9 Dec 2011 03:49:11 +0100 (CET) Date: Fri, 9 Dec 2011 03:49:11 +0100 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20111209024911.GB86313@onelab2.iet.unipi.it> References: <4EDDF9F4.9070508@digsys.bg> <4EDE259B.4010502@digsys.bg> <20111206210625.GB62605@onelab2.iet.unipi.it> <4EDF471F.1030202@freebsd.org> <20111207180807.GA71878@onelab2.iet.unipi.it> <4EE0B796.3050800@freebsd.org> <20111208153454.GA80979@onelab2.iet.unipi.it> <4EE15740.9030505@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EE15740.9030505@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Lawrence Stewart , Daniel Kalchev , Jack Vogel , current@freebsd.org, np@freebsd.org Subject: Re: quick summary results with ixgbe (was Re: datapoints on 10G throughput with TCP ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 02:33:02 -0000 On Fri, Dec 09, 2011 at 01:33:04AM +0100, Andre Oppermann wrote: > On 08.12.2011 16:34, Luigi Rizzo wrote: > >On Fri, Dec 09, 2011 at 12:11:50AM +1100, Lawrence Stewart wrote: ... > >>Jeff tested the WIP patch and it *doesn't* fix the issue. I don't have > >>LRO capable hardware setup locally to figure out what I've missed. Most > >>of the machines in my lab are running em(4) NICs which don't support > >>LRO, but I'll see if I can find something which does and perhaps > >>resurrect this patch. > > LRO can always be done in software. You can do it at driver, ether_input > or ip_input level. storing LRO state at the driver (as it is done now) is very convenient, because it is trivial to flush the pending segments at the end of an rx interrupt. If you want to do LRO in ether_input() or ip_input(), you need to add another call to flush the LRO state stored there. > >a few comments: > >1. i don't think it makes sense to send multiple acks on > > coalesced segments (and the 82599 does not seem to do that). > > First of all, the acks would get out with minimal spacing (ideally > > less than 100ns) so chances are that the remote end will see > > them in a single burst anyways. Secondly, the remote end can > > easily tell that a single ACK is reporting multiple MSS and > > behave as if an equivalent number of acks had arrived. > > ABC (appropriate byte counting) gets in the way though. right, during slow start the current ABC specification (RFC3465) sets a prettly low limit on how much the window can be expanded on each ACK. On the other hand... > >2. i am a big fan of LRO (and similar solutions), because it can save > > a lot of repeated work when passing packets up the stack, and the > > mechanism becomes more and more effective as the system load increases, > > which is a wonderful property in terms of system stability. > > > > For this reason, i think it would be useful to add support for software > > LRO in the generic code (sys/net/if.c) so that drivers can directly use > > the software implementation even without hardware support. > > It hurts on higher RTT links in the general case. For LAN RTT's > it's good. ... on the other hand remember that LRO coalescing is limited to the number of segments that arrive during a mitigation interval, so even on a 10G interface is't only a handful of packets. I better run some simulations to see how long it takes to get full rate on a 10..50ms path when using LRO. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 08:57:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA21106564A for ; Fri, 9 Dec 2011 08:57:58 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD498FC12 for ; Fri, 9 Dec 2011 08:57:57 +0000 (UTC) Received: by bkbzv15 with SMTP id zv15so3343467bkb.13 for ; Fri, 09 Dec 2011 00:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nhFc/SHX4N+OTshjCgcI3ub8Q6dSTbpKjx2rPwJVaoQ=; b=rP/WH/v7Ql78Rhutu4LEyTC6Jv8x4vfYDcpD/ty70QoRiPQOiRamL9S8fDcsyipHYk J2XmsWxKETwQBKkpJkZGAlkXhQ7ax1SG5VDpnBmR1a/Y7MR/tu/xOL8/zVnP9iyUXBnE brOgmvBxl+yCM+c0qXgbTg+pBI/1NkV1Tthho= MIME-Version: 1.0 Received: by 10.204.154.25 with SMTP id m25mr3114096bkw.140.1323421076759; Fri, 09 Dec 2011 00:57:56 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.204.37.141 with HTTP; Fri, 9 Dec 2011 00:57:56 -0800 (PST) In-Reply-To: <4EE0C064.8080902@xs4all.nl> References: <20111208002549.87261106566B@hub.freebsd.org> <4EE0C064.8080902@xs4all.nl> Date: Fri, 9 Dec 2011 00:57:56 -0800 X-Google-Sender-Auth: JXXS5bUzimkwfCsYEJ_Ri_2LwDo Message-ID: From: Craig Rodrigues To: Michiel Boland Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 08:57:58 -0000 On Thu, Dec 8, 2011 at 5:49 AM, Michiel Boland wrote: > > > Recompile the port; the CAM ioctl numbers have changed. > > Cheers > Michiel Hi, Is there an entry to describe this remedy in /usr/src/UPDATING? This issue has been coming up a lot in 9.0, so it would be good to have something to point people to. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 09:11:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9158106564A for ; Fri, 9 Dec 2011 09:11:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 48BAC8FC0C for ; Fri, 9 Dec 2011 09:11:33 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pB99BTKO037216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Dec 2011 11:11:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pB99BTjj019123; Fri, 9 Dec 2011 11:11:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pB99BT43019122; Fri, 9 Dec 2011 11:11:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 9 Dec 2011 11:11:29 +0200 From: Kostik Belousov To: Matthew Fleming Message-ID: <20111209091129.GO50300@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gLMprwfEHfJ4Te3l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jfv@freebsd.org, Zack Kirsch , freebsd-current@freebsd.org Subject: Re: Adding bool, true, and false to the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 09:11:34 -0000 --gLMprwfEHfJ4Te3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Dec 08, 2011 at 04:36:58PM -0800, Matthew Fleming wrote: > This code should be MFC-able to stable/9 after 9.0 is released. Yes, please make sure to merge it to stable/9. --gLMprwfEHfJ4Te3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7h0MEACgkQC3+MBN1Mb4gR2wCfZ/yNVP1kupNbL9cZvD1nNOMc iJcAoMGcmfQS1wEOERpJMsS3fKem+UgW =xGv9 -----END PGP SIGNATURE----- --gLMprwfEHfJ4Te3l-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 09:23:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC5BA106566B for ; Fri, 9 Dec 2011 09:23:59 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost06.isp.att.net (fmailhost06.isp.att.net [204.127.217.106]) by mx1.freebsd.org (Postfix) with ESMTP id CC1168FC0C for ; Fri, 9 Dec 2011 09:23:59 +0000 (UTC) Date: Fri, 9 Dec 2011 09:23:58 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-72-147-182-39.sdf.bellsouth.net[72.147.182.39]) by isp.att.net (frfwmhc06) with SMTP id <20111209092358H0600a780ie>; Fri, 9 Dec 2011 09:23:58 +0000 X-Originating-IP: [72.147.182.39] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <4EE0C064.8080902@xs4all.nl> Message-Id: <20111209092359.DC5BA106566B@hub.freebsd.org> Cc: Michiel Boland Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 09:23:59 -0000 > Recompile the port; the CAM ioctl numbers have changed. > Cheers > Michiel When did these CAM ioctl numbers change? Was it before or after I built and installed cdrtools? Running ls -rtl /var/db/pkg/cdrtools-3.00_1 produces total 48 -rw-r--r-- 1 root wheel 17550 Sep 26 09:20 +MTREE_DIRS -rw-r--r-- 1 root wheel 470 Sep 26 09:20 +DISPLAY -rw-r--r-- 1 root wheel 1009 Sep 26 09:20 +DESC -rw-r--r-- 1 root wheel 11102 Sep 26 09:20 +CONTENTS -rw-r--r-- 1 root wheel 63 Sep 26 09:20 +COMMENT -rw-r--r-- 1 root wheel 17 Dec 7 15:44 +REQUIRED_BY So it might have been on FreeBSD 9.0-BETA2. I might still want to try building cdrtools and cdrkit on my own, meaning without using the port. I could possibly try to make into a port of my own, if I can follow the Porter's Handbook. Tom From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 10:10:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C6B0106566B for ; Fri, 9 Dec 2011 10:10:27 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A32658FC0C for ; Fri, 9 Dec 2011 10:10:26 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:8815:eaa9:15e8:6eb3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 7B95B4AC1C for ; Fri, 9 Dec 2011 14:10:23 +0400 (MSK) Date: Fri, 9 Dec 2011 14:10:18 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <76373418.20111209141018@serebryakov.spb.ru> To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD/amd64 on machine without ACPI BIOS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 10:10:27 -0000 Hello, Freebsd-current. Soekris ("famous" developer of small x86-compatible appliance-like hardware) released net6501 some time ago, which is based on Atom (E6xx) CPU. It seems, that 64-bit version of Linux could run on it without problems. But FreeBSD/amd64 can not. It stops after kernel detect some devices without any errors or panics. This box has one big difference from billions other Intel-based boxes on market: it has very special BIOS without ACPI at all. Someone says, that it could be reason why FreeBSD/amd64 could not be boot on this box. Is it true? Is it possible to have FreeBSD/amd64 without ACPI? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 11:32:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5327D106564A for ; Fri, 9 Dec 2011 11:32:30 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 19C0F8FC13 for ; Fri, 9 Dec 2011 11:32:29 +0000 (UTC) Received: from [10.0.0.82] (unknown [217.157.7.210]) by csmtp3.one.com (Postfix) with ESMTPA id 0565B24026BE for ; Fri, 9 Dec 2011 11:16:40 +0000 (UTC) From: Erik Cederstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Dec 2011 12:16:39 +0100 Message-Id: To: FreeBSD Current Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Deterministic builds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 11:32:30 -0000 Hi all, I've been working on a project to make it possible to produce = deterministic builds with FreeBSD. By this I mean building a FreeBSD = distribution twice from the same code base and having all files in the = two distributions match by md5 sum. Currently, this is not the case. My main goal for this project is to be able to see exactly which files = are affected between two revision, in terms of actual functionality. There are different ways of defining deterministic builds. My first = attempt works when the SVN revision and SRCDIR is the same, but build = timestamp, OBJDIR and DESTDIR are different. Here is a patch for current = (r228312): http://217.157.7.216/deterministic.diff. This is my first = attempt at a patch for the build infrastructure, so be warned :-) To try the patch, you must be running 9.0 or later, since the build = relies on the '-D' flag being available in ar(1) and ranlib(1) (ar is = not a build dependency). I have only tested this with GCC, not Clang. To build deterministically, you need to put WITH_DETERMINISTIC=3D"YES" = in both make.conf and from the command-line. I can't work out why both = are necessary. Main features of the patch: * Change ARFLAGS to add '-D' where ARFLAGS are hard-coded * Adds a RANLIBFLAGS variable * Remove '-g' from C/C++ debug clags where it is hard-coded * Strips binaries for debug info which contains file paths * Adds -frandom-seed to CXXFLAGS so the random seed in C++ binaries is = constant * Changes sendmail config file headers to be generic * Changes newvers.sh to create a generic vers.c file Currently missing and untested is building with different user logins, = different hostnames, different revisions (where e.g. only a comment is = changed), different SRCDIRs and probably other things I haven't thought = of. Also, I have only done rudimentary runtime testing. Here is the script I have used to build and test: = http://217.157.7.216/build_md.sh I'd be very grateful for any comments on the approach and the patch. Thanks, Erik= From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 11:37:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 070B91065670 for ; Fri, 9 Dec 2011 11:37:09 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9397F8FC13 for ; Fri, 9 Dec 2011 11:37:08 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id pB9BBWid034011; Fri, 9 Dec 2011 12:11:33 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id pB9BBWca034010; Fri, 9 Dec 2011 12:11:32 +0100 (CET) (envelope-from marius) Date: Fri, 9 Dec 2011 12:11:32 +0100 From: Marius Strobl To: Thomas Mueller Message-ID: <20111209111132.GA33937@alchemy.franken.de> References: <4EE0C064.8080902@xs4all.nl> <20111209092359.DC5BA106566B@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111209092359.DC5BA106566B@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Michiel Boland , freebsd-current@freebsd.org Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 11:37:09 -0000 On Fri, Dec 09, 2011 at 09:23:58AM +0000, Thomas Mueller wrote: > > Recompile the port; the CAM ioctl numbers have changed. > > > Cheers > > Michiel > > When did these CAM ioctl numbers change? Was it before or after I built and installed cdrtools? > > Running ls -rtl /var/db/pkg/cdrtools-3.00_1 produces > > > total 48 > -rw-r--r-- 1 root wheel 17550 Sep 26 09:20 +MTREE_DIRS > -rw-r--r-- 1 root wheel 470 Sep 26 09:20 +DISPLAY > -rw-r--r-- 1 root wheel 1009 Sep 26 09:20 +DESC > -rw-r--r-- 1 root wheel 11102 Sep 26 09:20 +CONTENTS > -rw-r--r-- 1 root wheel 63 Sep 26 09:20 +COMMENT > -rw-r--r-- 1 root wheel 17 Dec 7 15:44 +REQUIRED_BY > > > So it might have been on FreeBSD 9.0-BETA2. > I'm not sure what CAM IOCTL number change others are referring to but you certainly need to rebuild libcam consumers after r225950, which was merged to stable/9 in r226067 on October 6 2011. Marius From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 09:56:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2844E106564A; Fri, 9 Dec 2011 09:56:23 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (ipv6.irc.int.ru [IPv6:2a02:28:1:2::1b:2]) by mx1.freebsd.org (Postfix) with ESMTP id A34B88FC0C; Fri, 9 Dec 2011 09:56:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.5/8.14.5) with ESMTP id pB99uKwu078309; Fri, 9 Dec 2011 13:56:20 +0400 (MSK) (envelope-from maxim.konovalov@gmail.com) Date: Fri, 9 Dec 2011 13:56:20 +0400 (MSK) From: Maxim Konovalov To: Kostik Belousov In-Reply-To: Message-ID: References: <20111122124410.GP50300@deviant.kiev.zoral.com.ua> <20111122154357.GI95664@mdounin.ru> <20111122154935.GR50300@deviant.kiev.zoral.com.ua> <20111124202945.GR50300@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 09 Dec 2011 12:16:54 +0000 Cc: arch@freebsd.org, Maxim Dounin , current@freebsd.org, igor@sysoev.ru Subject: Re: RLIMIT_DATA and malloc(3) use of mmap(2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 09:56:23 -0000 Hi Kostik, I understand that you are busy with the release. But is there a plan to commit this code somewhere in the near future? On Fri, 25 Nov 2011, 22:21+0400, Maxim Konovalov wrote: > [...] > > Fixed patch is available at > > http://people.freebsd.org/~kib/misc/map_datalimit.2.patch > > > Works as expected without any glitches. > > -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 10:11:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA25B106567B for ; Fri, 9 Dec 2011 10:11:53 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-bw0-f48.google.com (mail-bw0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0578FC1B for ; Fri, 9 Dec 2011 10:11:53 +0000 (UTC) Received: by bkas6 with SMTP id s6so2755599bka.7 for ; Fri, 09 Dec 2011 02:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=U52Rg0k/JaxFPNZn7rW7ZMtGhzOOH0Dp4pWl/Rhn0Q4=; b=k3GVtaKMFE04BajO79K6/ocVFvJXUQqGYLeApDxhVwr8az5XR2LhJDkezdCftLv9ml cgugxDszEUJxBLojSr4kYJLKG4M3L0HlETJKT78pVdwGUiRtRX9rP2BN1XULxGi9poKo o+TlfMV9xa96DqhpDi+UecuAinc3aOPzirqI0= Received: by 10.204.152.4 with SMTP id e4mr3178714bkw.56.1323424083885; Fri, 09 Dec 2011 01:48:03 -0800 (PST) Received: from admin.informalians.local (informalians.com.ua. [193.104.178.111]) by mx.google.com with ESMTPS id cc2sm8422002bkb.8.2011.12.09.01.48.02 (version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 01:48:03 -0800 (PST) Message-ID: <4EE1D951.2030509@gmail.com> Date: Fri, 09 Dec 2011 11:48:01 +0200 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org. Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 09 Dec 2011 12:17:16 +0000 Cc: Subject: Bug in Perl script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 10:11:54 -0000 I have a script that runs command tail with open descriptor. After 30 seconds, I close descriptor. But descriptor not closed. When script is closed tail is present in ps aux. $log_file =3D path_to_log; eval { local $SIG{ALRM} =3D sub { die; }; alarm (30); open (LOG, "tail -F $log_file|") || die "=F3an`t open logfile=20 \"$log_file\""; while () { *** } alarm (0); }; close (LOG); print ("Ok\n"); exit(0); This code is good working in FreeBSD 8.2, but in FreeBSD 9.0 not working.= -- Best Regards Alexander From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 13:21:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F62E1065670 for ; Fri, 9 Dec 2011 13:21:44 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98B718FC08 for ; Fri, 9 Dec 2011 13:21:43 +0000 (UTC) Received: by eaai12 with SMTP id i12so2115268eaa.13 for ; Fri, 09 Dec 2011 05:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=5cyPyDHIfRlQ75glfS21AQdmOnqCx+tBToisBRxXXaM=; b=ZisGguQokQgXCd3silpjqGEYgPrsPASU+2x1dfvRhRfhC1wnZ/kyaimBlhDydDbM4m 2s/IABG6bHkXVD2Lc+4+S8oVVwIcyh5UjBvx2bjESde0J1n6/SCY5GqHmruzmD3KTJ6B L/PJkvvfZVgmQp+fSJAGhd7xJpDJVXB9qXqLs= Received: by 10.213.35.198 with SMTP id q6mr185631ebd.39.1323436902316; Fri, 09 Dec 2011 05:21:42 -0800 (PST) Received: from ernst.jennejohn.org (p578E129B.dip.t-dialin.net. [87.142.18.155]) by mx.google.com with ESMTPS id z43sm18812114eef.7.2011.12.09.05.21.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Dec 2011 05:21:41 -0800 (PST) Date: Fri, 9 Dec 2011 14:21:39 +0100 From: Gary Jennejohn To: lev@FreeBSD.org Message-ID: <20111209142139.04a20504@ernst.jennejohn.org> In-Reply-To: <76373418.20111209141018@serebryakov.spb.ru> References: <76373418.20111209141018@serebryakov.spb.ru> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD/amd64 on machine without ACPI BIOS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 13:21:44 -0000 On Fri, 9 Dec 2011 14:10:18 +0400 Lev Serebryakov wrote: > Hello, Freebsd-current. > > Soekris ("famous" developer of small x86-compatible appliance-like > hardware) released net6501 some time ago, which is based on Atom (E6xx) > CPU. > It seems, that 64-bit version of Linux could run on it without > problems. > But FreeBSD/amd64 can not. It stops after kernel detect some > devices without any errors or panics. > This box has one big difference from billions other Intel-based > boxes on market: it has very special BIOS without ACPI at all. Someone > says, that it could be reason why FreeBSD/amd64 could not be boot on > this box. > Is it true? Is it possible to have FreeBSD/amd64 without ACPI? > Have you disabled device acpi in the kernel configuration and made sure that there is no acpi module installed? AFAICT there's /sys/amd64/legacy.c which appears to provide support for systems without ACPI. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 13:31:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from lo0.su (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by hub.freebsd.org (Postfix) with ESMTP id 703AD106566B; Fri, 9 Dec 2011 13:31:33 +0000 (UTC) (envelope-from ru@FreeBSD.org) Date: Fri, 9 Dec 2011 17:37:23 +0400 From: Ruslan Ermilov To: Erik Cederstrand Message-ID: <20111209133722.GC91429@lo0.su> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: FreeBSD Current Subject: Re: Deterministic builds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 13:31:34 -0000 On Fri, Dec 09, 2011 at 12:16:39PM +0100, Erik Cederstrand wrote: > I've been working on a project to make it possible to produce deterministic > builds with FreeBSD. By this I mean building a FreeBSD distribution twice > from the same code base and having all files in the two distributions match > by md5 sum. Currently, this is not the case. [...] > I'd be very grateful for any comments on the approach and the patch. The idea is not new. Setting CROSS_BUILD_TESTING during the buildworld addressed similar issues at a time I wrote it, to compare cross builds to native ones, with several exceptions. I haven't tested it for years, so things might have changed, but it's still a good idea to give it a try. From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 14:21:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88EAD106566B for ; Fri, 9 Dec 2011 14:21:03 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 0FBF78FC18 for ; Fri, 9 Dec 2011 14:21:03 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3T0G261vFBzGN11 for ; Fri, 9 Dec 2011 15:21:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1323440461; x=1326032462; bh=qiy Rzf+i7L6Xgz1RghnZ9o8QYMx1aG2M/4AGt843t1Y=; b=bWSClRLaj10EkoJO0vf WYm9/GQUo3fsbF2+kdZ/YVJIdm+2sev1w4fGjf0WVXPAfI9Piz2g76SAwv8eigYH hIWMkmX7vhZw2FfhgAkIBC7RczXKUAz9HdXzA5TAzBPNlO587ap/hrJYknDZFH4r TDB0lxZYuYh8dRiC/LeVvhV0= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id Dz2l_8mvIuDh for ; Fri, 9 Dec 2011 15:21:01 +0100 (CET) Received: from rozamunda.ijs.si (unknown [IPv6:2001:1470:ff80:0:225:90ff:fe11:b090]) by mail.ijs.si (Postfix) with ESMTP for ; Fri, 9 Dec 2011 15:21:01 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rozamunda.ijs.si (Postfix) with ESMTPSA id F26BB21148C for ; Fri, 9 Dec 2011 15:21:00 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-current@freebsd.org Date: Fri, 9 Dec 2011 15:21:00 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) References: <4EE1D951.2030509@gmail.com> In-Reply-To: <4EE1D951.2030509@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201112091521.00680.Mark.Martinec+freebsd@ijs.si> Subject: Re: Bug in Perl script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:21:03 -0000 Alexander, > I have a script that runs command tail with open descriptor. > After 30 seconds, I close descriptor. But descriptor not closed. > When script is closed tail is present in ps aux. >=20 > $log_file =3D path_to_log; > eval { > local $SIG{ALRM} =3D sub { die; }; > alarm (30); > open (LOG, "tail -F $log_file|") || die "=D0=A1an`t open logfile > \"$log_file\""; > while () { > *** > } > alarm (0); > }; > close (LOG); > print ("Ok\n"); > exit(0); >=20 > This code is good working in FreeBSD 8.2, but in FreeBSD 9.0 not working. I don't see any difference in this respect between 8.2 and 9.0. Even in 8.2 the spawned tail process stays alive until the moment when it tries to write its next line to a pipe - only then it aborts with 'Broken pipe'. On a busy log file this happens soon, on an idling log file this may take forever. You should abort the forked process when you no longer need it: my $log_file =3D '/var/log/mail.log'; my $pid; eval { local $SIG{ALRM} =3D sub { die "Time is up" }; alarm(10); $pid =3D open(LOG, "tail -F $log_file|"); $pid or die "Can't open logfile \"$log_file\": $!"; while () { print "HERE: $_"; } alarm (0); 1; } or do { alarm (0); print "Bail out: $@"; }; if ($pid) { print "Terminating process [$pid]\n"; kill('TERM',$pid); } close(LOG); print "Ok\n"; Mark From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 14:25:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7C1B1065670 for ; Fri, 9 Dec 2011 14:25:42 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id A3BCF8FC17 for ; Fri, 9 Dec 2011 14:25:42 +0000 (UTC) Received: from [10.0.0.82] (unknown [217.157.7.210]) by csmtp2.one.com (Postfix) with ESMTPA id D40103018615; Fri, 9 Dec 2011 14:25:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Erik Cederstrand In-Reply-To: <20111209133722.GC91429@lo0.su> Date: Fri, 9 Dec 2011 15:25:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EFFCC14-944D-48A5-BB5A-CC667159F8BD@cederstrand.dk> References: <20111209133722.GC91429@lo0.su> To: Ruslan Ermilov X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Current Subject: Re: Deterministic builds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:25:43 -0000 Hi Ruslan, Den 09/12/2011 kl. 14.37 skrev Ruslan Ermilov: > On Fri, Dec 09, 2011 at 12:16:39PM +0100, Erik Cederstrand wrote: >> I've been working on a project to make it possible to produce = deterministic >> builds with FreeBSD. By this I mean building a FreeBSD distribution = twice >> from the same code base and having all files in the two distributions = match >> by md5 sum. Currently, this is not the case. > [...] >> I'd be very grateful for any comments on the approach and the patch. >=20 > The idea is not new. Setting CROSS_BUILD_TESTING during the = buildworld > addressed similar issues at a time I wrote it, to compare cross builds > to native ones, with several exceptions. I haven't tested it for = years, > so things might have changed, but it's still a good idea to give it a > try. I can't see that CROSS_BUILD_TESTING does anything in current other than = adding TARGET and TARGET_ARCH to OBJTREE in src/Makefile.inc1? Kind regards, Erik= From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 15:36:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from lo0.su (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by hub.freebsd.org (Postfix) with ESMTP id 8A2A9106566B; Fri, 9 Dec 2011 15:36:27 +0000 (UTC) (envelope-from ru@freebsd.org) Date: Fri, 9 Dec 2011 19:42:17 +0400 From: Ruslan Ermilov To: Erik Cederstrand Message-ID: <20111209154217.GD91429@lo0.su> References: <20111209133722.GC91429@lo0.su> <4EFFCC14-944D-48A5-BB5A-CC667159F8BD@cederstrand.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EFFCC14-944D-48A5-BB5A-CC667159F8BD@cederstrand.dk> Cc: FreeBSD Current Subject: Re: Deterministic builds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 15:36:28 -0000 On Fri, Dec 09, 2011 at 03:25:40PM +0100, Erik Cederstrand wrote: > Den 09/12/2011 kl. 14.37 skrev Ruslan Ermilov: > > > On Fri, Dec 09, 2011 at 12:16:39PM +0100, Erik Cederstrand wrote: > >> I've been working on a project to make it possible to produce deterministic > >> builds with FreeBSD. By this I mean building a FreeBSD distribution twice > >> from the same code base and having all files in the two distributions match > >> by md5 sum. Currently, this is not the case. > > [...] > >> I'd be very grateful for any comments on the approach and the patch. > > > > The idea is not new. Setting CROSS_BUILD_TESTING during the buildworld > > addressed similar issues at a time I wrote it, to compare cross builds > > to native ones, with several exceptions. I haven't tested it for years, > > so things might have changed, but it's still a good idea to give it a > > try. > > I can't see that CROSS_BUILD_TESTING does anything in current other > than adding TARGET and TARGET_ARCH to OBJTREE in src/Makefile.inc1? Take a look at src/tools/build/Makefile. Last time I checked (July 19, 2005) there were only the following diffs when verifying cross-builds (verifying included doing a native build and binary comparing it with a cross-build made on i386/amd64): : *: : /usr/lib/libsupc++.a:vec.o symbols with generated names : /usr/lib/libobjc.a:NXConstStr.o : /usr/lib/libobjc.a:Object.o : /usr/lib/libobjc.a:Protocol.o : : i386 <- amd64 : /usr/sbin/isdn* timestamp (__TIME__) (i386 only) : : sparc64 <-> amd64 : /usr/share/misc/magic*.mgc mkmagic not endianness clean -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 18:10:18 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B274C10656E4 for ; Fri, 9 Dec 2011 18:10:18 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail938c35.nsolutionszone.com (mail938c35.nsolutionszone.com [209.235.152.128]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBD68FC17 for ; Fri, 9 Dec 2011 18:10:17 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (99-194-23-158.dyn.centurytel.net [99.194.23.158]) by mail938c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id pB9EGDlX005268 for ; Fri, 9 Dec 2011 14:16:14 GMT Date: Fri, 9 Dec 2011 09:16:13 -0500 From: Derek Tattersall To: current@FreeBSD.org Message-ID: <20111209141613.GA36585@oriental.arm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-CSC: 0 X-CHA: v=1.1 cv=4Mk23DudRstXNS+b9MIC7uh8WWl9floe1XGHGzgQi+I= c=1 sm=1 a=z1TLwsU0kBEA:10 a=P2oOn6vrs4wA:10 a=GPr01A5e9VcA:10 a=kj9zAlcOel0A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:17 a=6I5d2MoRAAAA:8 a=xwPayol1AAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=ryseQaLj5Yc7nRqoq3sA:9 a=CjuIK1q_8ugA:10 a=0Ob1RWNGeVAA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=5FSmvsqyZ8dLHOg+TByL6Q==:117 Cc: Subject: Problem with pkg_add X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 18:10:18 -0000 After installing 9.0-RC2 or RC3, pkg_add -r fails in trying to access ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/package-9-current as the terminal directory is acually packages-9-stable. It is a one line change in the source for pkg_add. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 20:58:17 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDCCC106566B for ; Fri, 9 Dec 2011 20:58:17 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id A26B58FC12 for ; Fri, 9 Dec 2011 20:58:17 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 77E5456173; Fri, 9 Dec 2011 14:41:09 -0600 (CST) Date: Fri, 9 Dec 2011 14:41:09 -0600 From: Mark Linimon To: Derek Tattersall Message-ID: <20111209204109.GC8142@lonesome.com> References: <20111209141613.GA36585@oriental.arm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111209141613.GA36585@oriental.arm.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@FreeBSD.org Subject: Re: Problem with pkg_add X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:58:17 -0000 On Fri, Dec 09, 2011 at 09:16:13AM -0500, Derek Tattersall wrote: > After installing 9.0-RC2 or RC3, pkg_add -r fails in trying to access > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/package-9-current as the > terminal directory is acually packages-9-stable. It is a one line > change in the source for pkg_add. For the moment, I've provided compatibility symlinks on ftp-master. Expect it to propogate shortly. mcl From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 23:51:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C2E01065672 for ; Fri, 9 Dec 2011 23:51:53 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0C2B8FC0C for ; Fri, 9 Dec 2011 23:51:52 +0000 (UTC) Received: by yenl9 with SMTP id l9so3432647yen.13 for ; Fri, 09 Dec 2011 15:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=/ho4q5Ct2WyYLhNtj+iVlBkKjY9HdhnhA+UVYf5+/xE=; b=D7ZkEDSZP2K89K9lVStIVqbspVmQPqqo4i0a/I4C0lsBYEcBIbi7oPKv+QwthrX3sl 7/2zoeObJYKrWCIRWoMbsex4zTgrkExRzmlJN8b/Z5kIepm0uvn9bRRKJY3CdQjIV9x/ k0JEQGg10DeBU3Tjo+40yrpdGwBZfPpXOBxEg= Received: by 10.236.185.9 with SMTP id t9mr15763158yhm.50.1323473349487; Fri, 09 Dec 2011 15:29:09 -0800 (PST) Received: from freebeast.localnet (c-98-230-64-224.hsd1.al.comcast.net. [98.230.64.224]) by mx.google.com with ESMTPS id u47sm17610977yhl.0.2011.12.09.15.29.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Dec 2011 15:29:08 -0800 (PST) From: Chuck Burns To: current@freebsd.org Date: Fri, 9 Dec 2011 17:29:07 -0600 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.7.3; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201112091729.07146.break19@gmail.com> Cc: Subject: devel/google-perftools fails to build on 10-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 23:51:53 -0000 I recently source-up'd to 10-current, and began the slow process of rebuilding all my installed ports, devel/google-perftools fails with an undeclared "__isthreaded" The following should be more than enough information. Thanks, Chuck Burns ---- root@freebeast /usr/src % svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 228349 Node Kind: directory Schedule: normal Last Changed Author: rmh Last Changed Rev: 228349 Last Changed Date: 2011-12-08 06:31:47 -0600 (Thu, 08 Dec 2011) ---- if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-maybe_threads.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo" -c -o libtcmalloc_minimal_internal_la-maybe_threads.lo `test -f 'src/maybe_threads.cc' || echo './'`src/maybe_threads.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo" ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- maybe_threads.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- maybe_threads.Tpo -c src/maybe_threads.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-maybe_threads.o src/maybe_threads.cc: In function 'int perftools_pthread_once(pthread_once_t*, void (*)())': src/maybe_threads.cc:118: error: '__isthreaded' was not declared in this scope *** Error code 1 Stop in /usr/ports/devel/google-perftools/work/google-perftools-1.8.3. *** Error code 1 Stop in /usr/ports/devel/google-perftools. ---- The -full- build log follows. root@freebeast ~ % cd /usr/ports/devel/google-perftools root@freebeast /usr/ports/devel/google-perftools % ls Makefile distinfo files/ pkg-descr pkg-plist work/ root@freebeast /usr/ports/devel/google-perftools % make clean ===> Cleaning for google-perftools-1.8.3 root@freebeast /usr/ports/devel/google-perftools % ls Makefile distinfo files/ pkg-descr pkg-plist root@freebeast /usr/ports/devel/google-perftools % make ===> Vulnerability check disabled, database not found ===> License BSD accepted by the user ===> Extracting for google-perftools-1.8.3 => SHA256 Checksum OK for google-perftools-1.8.3.tar.gz. ===> Patching for google-perftools-1.8.3 ===> Applying FreeBSD patches for google-perftools-1.8.3 ===> Configuring for google-perftools-1.8.3 checking build system type... amd64-portbld-freebsd10.0 checking host system type... amd64-portbld-freebsd10.0 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking how to run the C preprocessor... cpp checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking whether cc understands -c and -o together... yes checking for objcopy... objcopy checking if objcopy supports -W... yes checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... (cached) 262144 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from cc object... ok checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking whether we are using the GNU C++ compiler... (cached) yes checking whether c++ accepts -g... (cached) yes checking dependency style of c++... (cached) gcc3 checking how to run the C++ preprocessor... c++ -E checking for objdir... .libs checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC -DPIC checking if cc PIC flag -fPIC -DPIC works... yes checking if cc static flag -static works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.o... (cached) yes checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... freebsd10.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for ld used by c++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking for c++ option to produce PIC... -fPIC -DPIC checking if c++ PIC flag -fPIC -DPIC works... yes checking if c++ static flag -static works... yes checking if c++ supports -c -o file.o... yes checking if c++ supports -c -o file.o... (cached) yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd10.0 ld.so checking how to hardcode library paths into programs... immediate checking for inline... inline checking for __attribute__... yes checking for ANSI C header files... (cached) yes checking for __int64... no checking for struct mallinfo... no checking for Elf32_Versym... yes checking for sbrk... yes checking for geteuid... yes checking features.h usability... no checking features.h presence... no checking for features.h... no checking malloc.h usability... no checking malloc.h presence... no checking for malloc.h... no checking sys/malloc.h usability... yes checking sys/malloc.h presence... yes checking for sys/malloc.h... yes checking malloc/malloc.h usability... no checking malloc/malloc.h presence... no checking for malloc/malloc.h... no checking glob.h usability... yes checking glob.h presence... yes checking for glob.h... yes checking execinfo.h usability... no checking execinfo.h presence... no checking for execinfo.h... no checking libunwind.h usability... no checking libunwind.h presence... no checking for libunwind.h... no checking unwind.h usability... no checking unwind.h presence... no checking for unwind.h... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking conflict-signal.h usability... no checking conflict-signal.h presence... no checking for conflict-signal.h... no checking sys/prctl.h usability... no checking sys/prctl.h presence... no checking for sys/prctl.h... no checking linux/ptrace.h usability... no checking linux/ptrace.h presence... no checking for linux/ptrace.h... no checking sys/syscall.h usability... yes checking sys/syscall.h presence... yes checking for sys/syscall.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking valgrind.h usability... no checking valgrind.h presence... no checking for valgrind.h... no checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking for features.h... (cached) no checking whether cfree is declared... no checking whether posix_memalign is declared... no checking whether memalign is declared... no checking whether valloc is declared... no checking whether pvalloc is declared... no checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/param.h... yes checking for getpagesize... yes checking for working mmap... yes checking if int32_t is the same type as intptr_t... no checking ucontext.h usability... yes checking ucontext.h presence... yes checking for ucontext.h... yes checking sys/ucontext.h usability... yes checking sys/ucontext.h presence... yes checking for sys/ucontext.h... yes checking cygwin/signal.h usability... no checking cygwin/signal.h presence... no checking for cygwin/signal.h... no checking how to access the program counter from a struct ucontext... uc_mcontext.mc_rip checking for backtrace in -lunwind... no checking if the compiler supports -Wno-unused-result... no checking printf format code for printing a size_t and ssize_t... l checking for __builtin_stack_pointer()... no checking for __environ... no checking for __thread... yes checking if __malloc_hook is declared volatile... no checking if nanosleep requires any libraries... no checking whether uname is declared... yes checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... -D_THREAD_SAFE checking whether to check for GCC pthread/shared inconsistencies... yes checking whether -pthread is sufficient with -shared... yes checking whether what we have so far is sufficient with -nostdlib... no checking whether -pthread saves the day... no configure: WARNING: Impossible to determine how to use pthreads with shared libraries and -nostdlib checking whether the compiler implements namespaces... yes checking what namespace STL code is in... std checking for program_invocation_name... no configure: creating ./config.status config.status: creating Makefile config.status: creating src/google/tcmalloc.h config.status: creating src/windows/google/tcmalloc.h config.status: creating src/config.h config.status: executing depfiles commands config.status: executing libtool commands ===> Building for google-perftools-1.8.3 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -D_THREAD_SAFE -pthread -DNDEBUG - Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin- malloc -fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno- builtin-cfree -fno-builtin-memalign -fno-builtin-posix_memalign -fno- builtin-valloc -fno-builtin-pvalloc -fno-omit-frame-pointer -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_la-tcmalloc.lo -MD -MP -MF ".deps/libtcmalloc_minimal_la-tcmalloc.Tpo" -c -o libtcmalloc_minimal_la-tcmalloc.lo `test -f 'src/tcmalloc.cc' || echo './'`src/tcmalloc.cc; then mv -f ".deps/libtcmalloc_minimal_la-tcmalloc.Tpo" ".deps/libtcmalloc_minimal_la-tcmalloc.Plo"; else rm -f ".deps/libtcmalloc_minimal_la-tcmalloc.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -D_THREAD_SAFE -pthread -DNDEBUG -Wall -Wwrite-strings - Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc -fno-builtin-free - fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree -fno-builtin- memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame-pointer -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_la-tcmalloc.lo -MD -MP -MF .deps/libtcmalloc_minimal_la- tcmalloc.Tpo -c src/tcmalloc.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_la- tcmalloc.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -D_THREAD_SAFE -pthread -DNDEBUG -Wall -Wwrite-strings - Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc -fno-builtin-free - fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree -fno-builtin- memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame-pointer -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_la-tcmalloc.lo -MD -MP -MF .deps/libtcmalloc_minimal_la- tcmalloc.Tpo -c src/tcmalloc.cc -o libtcmalloc_minimal_la-tcmalloc.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-common.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-common.Tpo" -c -o libtcmalloc_minimal_internal_la-common.lo `test -f 'src/common.cc' || echo './'`src/common.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la- common.Tpo" ".deps/libtcmalloc_minimal_internal_la-common.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-common.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- common.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-common.Tpo -c src/common.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-common.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- common.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-common.Tpo -c src/common.cc -o libtcmalloc_minimal_internal_la-common.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-internal_logging.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-internal_logging.Tpo" -c -o libtcmalloc_minimal_internal_la-internal_logging.lo `test -f 'src/internal_logging.cc' || echo './'`src/internal_logging.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-internal_logging.Tpo" ".deps/libtcmalloc_minimal_internal_la-internal_logging.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-internal_logging.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- internal_logging.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- internal_logging.Tpo -c src/internal_logging.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-internal_logging.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- internal_logging.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- internal_logging.Tpo -c src/internal_logging.cc -o libtcmalloc_minimal_internal_la-internal_logging.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-system-alloc.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo" -c -o libtcmalloc_minimal_internal_la-system-alloc.lo `test -f 'src/system-alloc.cc' || echo './'`src/system-alloc.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo" ".deps/libtcmalloc_minimal_internal_la-system-alloc.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-system- alloc.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo -c src/system-alloc.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la- system-alloc.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-system- alloc.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-system-alloc.Tpo -c src/system-alloc.cc -o libtcmalloc_minimal_internal_la-system-alloc.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-memfs_malloc.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-memfs_malloc.Tpo" -c -o libtcmalloc_minimal_internal_la-memfs_malloc.lo `test -f 'src/memfs_malloc.cc' || echo './'`src/memfs_malloc.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-memfs_malloc.Tpo" ".deps/libtcmalloc_minimal_internal_la-memfs_malloc.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-memfs_malloc.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- memfs_malloc.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- memfs_malloc.Tpo -c src/memfs_malloc.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-memfs_malloc.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- memfs_malloc.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- memfs_malloc.Tpo -c src/memfs_malloc.cc -o libtcmalloc_minimal_internal_la- memfs_malloc.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-central_freelist.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-central_freelist.Tpo" -c -o libtcmalloc_minimal_internal_la-central_freelist.lo `test -f 'src/central_freelist.cc' || echo './'`src/central_freelist.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-central_freelist.Tpo" ".deps/libtcmalloc_minimal_internal_la-central_freelist.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-central_freelist.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- central_freelist.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- central_freelist.Tpo -c src/central_freelist.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-central_freelist.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- central_freelist.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- central_freelist.Tpo -c src/central_freelist.cc -o libtcmalloc_minimal_internal_la-central_freelist.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-page_heap.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-page_heap.Tpo" -c -o libtcmalloc_minimal_internal_la-page_heap.lo `test -f 'src/page_heap.cc' || echo './'`src/page_heap.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-page_heap.Tpo" ".deps/libtcmalloc_minimal_internal_la-page_heap.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-page_heap.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- page_heap.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-page_heap.Tpo - c src/page_heap.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la- page_heap.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- page_heap.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-page_heap.Tpo - c src/page_heap.cc -o libtcmalloc_minimal_internal_la-page_heap.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-sampler.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-sampler.Tpo" -c -o libtcmalloc_minimal_internal_la-sampler.lo `test -f 'src/sampler.cc' || echo './'`src/sampler.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la- sampler.Tpo" ".deps/libtcmalloc_minimal_internal_la-sampler.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-sampler.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- sampler.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-sampler.Tpo -c src/sampler.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-sampler.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- sampler.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-sampler.Tpo -c src/sampler.cc -o libtcmalloc_minimal_internal_la-sampler.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-span.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-span.Tpo" -c -o libtcmalloc_minimal_internal_la-span.lo `test -f 'src/span.cc' || echo './'`src/span.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-span.Tpo" ".deps/libtcmalloc_minimal_internal_la-span.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-span.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-span.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-span.Tpo -c src/span.cc - fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-span.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-span.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-span.Tpo -c src/span.cc -o libtcmalloc_minimal_internal_la-span.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-stack_trace_table.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-stack_trace_table.Tpo" -c -o libtcmalloc_minimal_internal_la-stack_trace_table.lo `test -f 'src/stack_trace_table.cc' || echo './'`src/stack_trace_table.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-stack_trace_table.Tpo" ".deps/libtcmalloc_minimal_internal_la-stack_trace_table.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-stack_trace_table.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- stack_trace_table.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- stack_trace_table.Tpo -c src/stack_trace_table.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-stack_trace_table.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- stack_trace_table.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- stack_trace_table.Tpo -c src/stack_trace_table.cc -o libtcmalloc_minimal_internal_la-stack_trace_table.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-static_vars.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-static_vars.Tpo" -c -o libtcmalloc_minimal_internal_la-static_vars.lo `test -f 'src/static_vars.cc' || echo './'`src/static_vars.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-static_vars.Tpo" ".deps/libtcmalloc_minimal_internal_la-static_vars.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-static_vars.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- static_vars.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- static_vars.Tpo -c src/static_vars.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-static_vars.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- static_vars.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- static_vars.Tpo -c src/static_vars.cc -o libtcmalloc_minimal_internal_la- static_vars.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-symbolize.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-symbolize.Tpo" -c -o libtcmalloc_minimal_internal_la-symbolize.lo `test -f 'src/symbolize.cc' || echo './'`src/symbolize.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-symbolize.Tpo" ".deps/libtcmalloc_minimal_internal_la-symbolize.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-symbolize.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- symbolize.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-symbolize.Tpo - c src/symbolize.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la- symbolize.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- symbolize.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la-symbolize.Tpo - c src/symbolize.cc -o libtcmalloc_minimal_internal_la-symbolize.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-thread_cache.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-thread_cache.Tpo" -c -o libtcmalloc_minimal_internal_la-thread_cache.lo `test -f 'src/thread_cache.cc' || echo './'`src/thread_cache.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-thread_cache.Tpo" ".deps/libtcmalloc_minimal_internal_la-thread_cache.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-thread_cache.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- thread_cache.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- thread_cache.Tpo -c src/thread_cache.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-thread_cache.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- thread_cache.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- thread_cache.Tpo -c src/thread_cache.cc -o libtcmalloc_minimal_internal_la- thread_cache.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-malloc_hook.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-malloc_hook.Tpo" -c -o libtcmalloc_minimal_internal_la-malloc_hook.lo `test -f 'src/malloc_hook.cc' || echo './'`src/malloc_hook.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-malloc_hook.Tpo" ".deps/libtcmalloc_minimal_internal_la-malloc_hook.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-malloc_hook.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- malloc_hook.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- malloc_hook.Tpo -c src/malloc_hook.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-malloc_hook.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- malloc_hook.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- malloc_hook.Tpo -c src/malloc_hook.cc -o libtcmalloc_minimal_internal_la- malloc_hook.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-malloc_extension.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-malloc_extension.Tpo" -c -o libtcmalloc_minimal_internal_la-malloc_extension.lo `test -f 'src/malloc_extension.cc' || echo './'`src/malloc_extension.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-malloc_extension.Tpo" ".deps/libtcmalloc_minimal_internal_la-malloc_extension.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-malloc_extension.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- malloc_extension.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- malloc_extension.Tpo -c src/malloc_extension.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-malloc_extension.o libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- malloc_extension.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- malloc_extension.Tpo -c src/malloc_extension.cc -o libtcmalloc_minimal_internal_la-malloc_extension.o >/dev/null 2>&1 if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-maybe_threads.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo" -c -o libtcmalloc_minimal_internal_la-maybe_threads.lo `test -f 'src/maybe_threads.cc' || echo './'`src/maybe_threads.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo" ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- maybe_threads.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- maybe_threads.Tpo -c src/maybe_threads.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-maybe_threads.o src/maybe_threads.cc: In function 'int perftools_pthread_once(pthread_once_t*, void (*)())': src/maybe_threads.cc:118: error: '__isthreaded' was not declared in this scope *** Error code 1 Stop in /usr/ports/devel/google-perftools/work/google-perftools-1.8.3. *** Error code 1 Stop in /usr/ports/devel/google-perftools. From owner-freebsd-current@FreeBSD.ORG Fri Dec 9 23:54:13 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 08A92106566B for ; Fri, 9 Dec 2011 23:54:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B96F214E89D; Fri, 9 Dec 2011 23:54:12 +0000 (UTC) Message-ID: <4EE29FA4.4090901@FreeBSD.org> Date: Fri, 09 Dec 2011 15:54:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Chuck Burns References: <201112091729.07146.break19@gmail.com> In-Reply-To: <201112091729.07146.break19@gmail.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: devel/google-perftools fails to build on 10-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 23:54:13 -0000 On 12/09/2011 15:29, Chuck Burns wrote: > I recently source-up'd to 10-current, and began the slow process of rebuilding > all my installed ports, devel/google-perftools fails with an undeclared > "__isthreaded" For ports questions it's customary to start on freebsd-ports@ and cc the maintainer. FYI, Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 01:57:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8376D106564A; Sat, 10 Dec 2011 01:57:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 567998FC13; Sat, 10 Dec 2011 01:57:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBA1v7mL039642; Fri, 9 Dec 2011 20:57:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBA1v7ND039640; Sat, 10 Dec 2011 01:57:07 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Dec 2011 01:57:07 GMT Message-Id: <201112100157.pBA1v7ND039640@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 01:57:08 -0000 TB --- 2011-12-10 01:00:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-10 01:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-10 01:00:00 - cleaning the object tree TB --- 2011-12-10 01:00:48 - cvsupping the source tree TB --- 2011-12-10 01:00:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-10 01:01:01 - building world TB --- 2011-12-10 01:01:01 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 01:01:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 01:01:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 01:01:01 - SRCCONF=/dev/null TB --- 2011-12-10 01:01:01 - TARGET=i386 TB --- 2011-12-10 01:01:01 - TARGET_ARCH=i386 TB --- 2011-12-10 01:01:01 - TZ=UTC TB --- 2011-12-10 01:01:01 - __MAKE_CONF=/dev/null TB --- 2011-12-10 01:01:01 - cd /src TB --- 2011-12-10 01:01:01 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 10 01:01:01 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDeclAttr.cpp c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDeclCXX.cpp /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDeclCXX.cpp: In member function 'void clang::Sema::DefineImplicitCopyAssignment(clang::SourceLocation, clang::CXXMethodDecl*)': /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDeclCXX.cpp:7582: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libclangsema. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-10 01:57:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-10 01:57:06 - ERROR: failed to build world TB --- 2011-12-10 01:57:06 - 2685.36 user 525.70 system 3426.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 09:59:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C8A4106564A for ; Sat, 10 Dec 2011 09:59:48 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 07B178FC0C for ; Sat, 10 Dec 2011 09:59:47 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1RZJic-00082I-SZ>; Sat, 10 Dec 2011 10:59:46 +0100 Received: from e178029011.adsl.alicedsl.de ([85.178.29.11] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RZJic-0008P1-Np>; Sat, 10 Dec 2011 10:59:46 +0100 Message-ID: <4EE32D8D.2080308@zedat.fu-berlin.de> Date: Sat, 10 Dec 2011 10:59:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0B350317EC18DC404A01E75" X-Originating-IP: 85.178.29.11 Subject: How to update /usr/src/ using SVN and "make update"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 09:59:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0B350317EC18DC404A01E75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Taking the instruction from manpage make.conf(5) and setting variable SVN_UPDATE to YES, typing "make update" in /usr/src fails due to svn can not be found. make.conf(5) also contains a variable "SUP" containing the path for cvsup or cvsup and I'm desperately missing a similar variable for subversion. Since subversion is a port, it might be so that setting a variable in make.conf(5) conflicts with the BSD policy and logic, but then I'd appreciate a hint like "you need to set the propper environment variable for finding svn in the search path ...blablabla". Using "make update" ends up in "svn not found". Typing manually "svn -r HEAD" in /usr/src as it is shown when the make update fails works well, since the shell's environment PATH variable knows /usr/local/bin to look for. I also file a PR not letting this getting forgotten, please close it, if it is obsolete. Regards, O. Hartmann --------------enigC0B350317EC18DC404A01E75 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 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO4y2SAAoJEOgBcD7A/5N8mgMIANPKnKvjDway/qGdomb3wt00 JNSn0h6yFAkm4wUaqabyI3DPxhAqNfMJDXzm9hx7jYppl4hFbAuZWZviDwaG+ni8 Lm+hxSyUJY21opNuOVEDayi8b9AsmFLJIDuYEVKPniWMipg6Zwkgm4jmpW0nBxgX bAaObxJSB/PXrDti9gi1k6J529y3ZmuXaMfYRH6mpZarElkFGGKorhvVaauTeqIC ZhQrYig4P0vE8q7d1M1/hBRJNK3Ng8GImQU9bv5ZiqRkMfxwIY7PMwjGBOfiysS9 eY15TLocQp/K4r94n/1ZHgRc2yR2mfdieuzYGsTba0ebFZNfZnM3Ii6bw89e+os= =Jayi -----END PGP SIGNATURE----- --------------enigC0B350317EC18DC404A01E75-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 10:09:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25FDE106566B; Sat, 10 Dec 2011 10:09:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EB0F88FC08; Sat, 10 Dec 2011 10:09:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBAA9PEn096311; Sat, 10 Dec 2011 05:09:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBAA9Kbs094956; Sat, 10 Dec 2011 10:09:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Dec 2011 10:09:20 GMT Message-Id: <201112101009.pBAA9Kbs094956@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 10:09:28 -0000 TB --- 2011-12-10 08:40:32 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-10 08:40:32 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-12-10 08:40:32 - cleaning the object tree TB --- 2011-12-10 08:40:48 - cvsupping the source tree TB --- 2011-12-10 08:40:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-12-10 08:41:01 - building world TB --- 2011-12-10 08:41:01 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 08:41:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 08:41:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 08:41:01 - SRCCONF=/dev/null TB --- 2011-12-10 08:41:01 - TARGET=ia64 TB --- 2011-12-10 08:41:01 - TARGET_ARCH=ia64 TB --- 2011-12-10 08:41:01 - TZ=UTC TB --- 2011-12-10 08:41:01 - __MAKE_CONF=/dev/null TB --- 2011-12-10 08:41:01 - cd /src TB --- 2011-12-10 08:41:01 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 10 08:41:02 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Dec 10 10:05:41 UTC 2011 TB --- 2011-12-10 10:05:41 - generating LINT kernel config TB --- 2011-12-10 10:05:41 - cd /src/sys/ia64/conf TB --- 2011-12-10 10:05:41 - /usr/bin/make -B LINT TB --- 2011-12-10 10:05:41 - cd /src/sys/ia64/conf TB --- 2011-12-10 10:05:41 - /usr/sbin/config -m GENERIC TB --- 2011-12-10 10:05:41 - building GENERIC kernel TB --- 2011-12-10 10:05:41 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 10:05:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 10:05:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 10:05:41 - SRCCONF=/dev/null TB --- 2011-12-10 10:05:41 - TARGET=ia64 TB --- 2011-12-10 10:05:41 - TARGET_ARCH=ia64 TB --- 2011-12-10 10:05:41 - TZ=UTC TB --- 2011-12-10 10:05:41 - __MAKE_CONF=/dev/null TB --- 2011-12-10 10:05:41 - cd /src TB --- 2011-12-10 10:05:41 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Dec 10 10:05:41 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c: In function 'em_ioctl': /src/sys/dev/e1000/if_em.c:1152: error: 'struct e1000_phy_info' has no member named 'reset_disable' /src/sys/dev/e1000/if_em.c: In function 'em_init_locked': /src/sys/dev/e1000/if_em.c:1408: error: 'struct e1000_phy_info' has no member named 'reset_disable' cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_enable_wakeup': /src/sys/dev/e1000/if_em.c:4924: warning: implicit declaration of function 'e1000_disable_gig_wol_ich8lan' /src/sys/dev/e1000/if_em.c:4924: warning: nested extern declaration of 'e1000_disable_gig_wol_ich8lan' [-Wnested-externs] *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-10 10:09:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-10 10:09:20 - ERROR: failed to build GENERIC kernel TB --- 2011-12-10 10:09:20 - 4133.28 user 836.41 system 5328.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 10:40:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1EE91065673 for ; Sat, 10 Dec 2011 10:40:15 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from nm22.access.bullet.mail.sp2.yahoo.com (nm22.access.bullet.mail.sp2.yahoo.com [98.139.44.149]) by mx1.freebsd.org (Postfix) with SMTP id 9A51D8FC13 for ; Sat, 10 Dec 2011 10:40:15 +0000 (UTC) Received: from [98.139.44.98] by nm22.access.bullet.mail.sp2.yahoo.com with NNFMP; 10 Dec 2011 10:27:23 -0000 Received: from [98.139.44.93] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 10 Dec 2011 10:27:23 -0000 Received: from [127.0.0.1] by omp1030.access.mail.sp2.yahoo.com with NNFMP; 10 Dec 2011 10:27:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 222674.83863.bm@omp1030.access.mail.sp2.yahoo.com Received: (qmail 32286 invoked by uid 60001); 10 Dec 2011 10:27:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1323512842; bh=MumLGswrZMYyw4vxoakZJhQpHq1yTIDc5H92ObqDrCQ=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HqiBYUZ6GA0sIkuq+4KVvOptAnGOKLVcR55K8HCl0rQ5vdDHfbmCzQrNMDBUIG5CyL6ht508+axzDtFPzsMTI9Dp6mwVeIcXz9B3ccAUMBgeB98/KhO1zWTvbvC6Uo27AJTXvEygsw7neSlKvVMXP4+4NDeAxE165TVO1k+E4Q4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=bellsouth.net; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=s7U/y4AfoiUvGPN0eh8bf4qsf3ju2Fpc0MP7ht/9uYTCDn2iTwBZ35A+ETKwaodyCvOQdfWp9JXSz8rSkFg07jfWP3RMCSe+g9p5WvyAbZuu3Xll3h6UdP0Q+cgQLVoEWrHG3QK5R+Pl8umu2YG28VEhDUe92uxWjOWi2PdlvK8=; X-YMail-OSG: GyA6.pgVM1lUPnkQnC9PF_.7kYVStkQqyTl6yPHVLLONek7 Ttc4hUUfIA5hw5IYuyXPCJ7b258MNKgWZq367Hk71fT7fGC09Gm6aPs53Irh u.jodYKfVWRYc0ydKET9XLumiEekWP8PtIFKcv8.Hy7toGpfVuD1hshnhPjz jXmK9o30BNGd4Ua8NeT7ybT5Mm5IaRWLDHbqXAn9R9ngdnsX4NypKVojdyNX oqilr_RbtKncaK0DIcSQQzmSo0XMLGBfoNSLicDKSliI2l6eKVo_fWpDOJXF qUAxwXSNnodtEog9kgFxKsakrwO2cnwPtt.axDXWOtOFFqaWwk_Fw.IvrVEb EOgVCyULJiaf6EW.YGqkpfIWQOYJxdS_ly1gNv7NR32tDS.HFgw.k7wmTWiH QJ3fj3ICe_jvNCR4wsMk9NVms Received: from [74.132.96.16] by web180204.mail.gq1.yahoo.com via HTTP; Sat, 10 Dec 2011 02:27:22 PST X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698 Message-ID: <1323512842.24422.YahooMailClassic@web180204.mail.gq1.yahoo.com> Date: Sat, 10 Dec 2011 02:27:22 -0800 (PST) From: Thomas Mueller To: Marius Strobl In-Reply-To: <20111209111132.GA33937@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michiel Boland , freebsd-current@freebsd.org Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 10:40:15 -0000 --- On Fri, 12/9/11, Marius Strobl wrote: > +0000, Thomas Mueller wrote: > > > Recompile the port; the CAM ioctl numbers have > changed. > Cheers > > > Michiel =20 > > When did these CAM ioctl numbers change?=A0 Was it > before or after I built and installed cdrtools? =20 > > Running ls -rtl /var/db/pkg/cdrtools-3.00_1 produces =20 > > total 48 > > -rw-r--r--=A0 1 root=A0 wheel=A0 17550 Sep 26 > 09:20 +MTREE_DIRS > > -rw-r--r--=A0 1 root=A0 wheel=A0 =A0 470 > Sep 26 09:20 +DISPLAY > > -rw-r--r--=A0 1 root=A0 > wheel=A0=A0=A01009 Sep 26 09:20 +DESC > > -rw-r--r--=A0 1 root=A0 wheel=A0 11102 Sep 26 > 09:20 +CONTENTS > > -rw-r--r--=A0 1 root=A0 wheel=A0 > =A0=A0=A063 Sep 26 09:20 +COMMENT > > -rw-r--r--=A0 1 root=A0 wheel=A0 > =A0=A0=A017 Dec=A0 7 15:44 +REQUIRED_BY =20 =20 > > So it might have been on FreeBSD 9.0-BETA2. =20 > I'm not sure what CAM IOCTL number change others are > referring to but > you certainly need to rebuild libcam consumers after > r225950, which > was merged to stable/9 in r226067 on October 6 2011. > Marius =20 Thanks for response. I'm at the older computer now, but will need to check= /usr/src/UPDATING, and portupgrade or portmaster cdrtools after source-upg= rading FreeBSD 9.0-RC2 to RC3.=20 Tom From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 10:48:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E1841065672 for ; Sat, 10 Dec 2011 10:48:27 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id DC68F8FC17 for ; Sat, 10 Dec 2011 10:48:26 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id pBAAmMUb038697; Sat, 10 Dec 2011 11:48:23 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id pBAAmMQV038696; Sat, 10 Dec 2011 11:48:22 +0100 (CET) (envelope-from marius) Date: Sat, 10 Dec 2011 11:48:22 +0100 From: Marius Strobl To: Thomas Mueller Message-ID: <20111210104822.GA36635@alchemy.franken.de> References: <20111209111132.GA33937@alchemy.franken.de> <1323512842.24422.YahooMailClassic@web180204.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1323512842.24422.YahooMailClassic@web180204.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: Michiel Boland , freebsd-current@freebsd.org Subject: Re: Burning CDs and DVDs on SATA drive in FreeBSD 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 10:48:27 -0000 On Sat, Dec 10, 2011 at 02:27:22AM -0800, Thomas Mueller wrote: > > --- On Fri, 12/9/11, Marius Strobl wrote: > > > +0000, Thomas Mueller wrote: > > > > Recompile the port; the CAM ioctl numbers have > > changed. > > Cheers > > > > Michiel > > > > When did these CAM ioctl numbers change?? Was it > > before or after I built and installed cdrtools? > > > > Running ls -rtl /var/db/pkg/cdrtools-3.00_1 produces > > > > total 48 > > > -rw-r--r--? 1 root? wheel? 17550 Sep 26 > > 09:20 +MTREE_DIRS > > > -rw-r--r--? 1 root? wheel? ? 470 > > Sep 26 09:20 +DISPLAY > > > -rw-r--r--? 1 root? > > wheel???1009 Sep 26 09:20 +DESC > > > -rw-r--r--? 1 root? wheel? 11102 Sep 26 > > 09:20 +CONTENTS > > > -rw-r--r--? 1 root? wheel? > > ???63 Sep 26 09:20 +COMMENT > > > -rw-r--r--? 1 root? wheel? > > ???17 Dec? 7 15:44 +REQUIRED_BY > > > > > So it might have been on FreeBSD 9.0-BETA2. > > > > I'm not sure what CAM IOCTL number change others are > > referring to but > > you certainly need to rebuild libcam consumers after > > r225950, which > > was merged to stable/9 in r226067 on October 6 2011. > > > Marius > > Thanks for response. I'm at the older computer now, but will need to check /usr/src/UPDATING, and portupgrade or portmaster cdrtools after source-upgrading FreeBSD 9.0-RC2 to RC3. > There's no corresponding entry in UPDATING. Marius From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 12:35:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EC0F106564A; Sat, 10 Dec 2011 12:35:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 356B78FC12; Sat, 10 Dec 2011 12:35:12 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RZM91-0006e9-0D>; Sat, 10 Dec 2011 13:35:11 +0100 Received: from e178029011.adsl.alicedsl.de ([85.178.29.11] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RZM90-0007Gw-Rb>; Sat, 10 Dec 2011 13:35:10 +0100 Message-ID: <4EE351FE.5070807@zedat.fu-berlin.de> Date: Sat, 10 Dec 2011 13:35:10 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Steve Kargl References: <4EDEF1FF.5020307@zedat.fu-berlin.de> <20111207061137.GA38900@troutmask.apl.washington.edu> In-Reply-To: <20111207061137.GA38900@troutmask.apl.washington.edu> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig607FD8DB30C9DAC44998FE79" X-Originating-IP: 85.178.29.11 Cc: Current FreeBSD , freebsd-questions@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 12:35:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig607FD8DB30C9DAC44998FE79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/07/11 07:11, Steve Kargl wrote: > On Wed, Dec 07, 2011 at 05:56:31AM +0100, O. Hartmann wrote: >> config.status: creating ada/Makefile >> config.status: creating auto-host.h >> config.status: executing default commands >> gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' >> gmake[1]: *** [stage1-bubble] Error 2 >> gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' >> gmake: *** [bootstrap-lean] Error 2 >> *** Error code 1 >> >> Stop in /usr/ports/lang/gcc46. >> *** Error code 1 >> >> Stop in /usr/ports/lang/gcc46. >> >> =3D=3D=3D>>> make failed for lang/gcc46 >> =3D=3D=3D>>> Aborting update >> >=20 > See if setting DISABLE_MAKE_JOBSi helps. >=20 This doesn't work, either. In /etc/src.conf, I use WITH_ICONV=3DYES and _WITH_BSD_GREP=3DYES. Switch= ing off WITH_ICONV seems to solve the problem on FreeBSD 10.0-CURRENT/amd64. I do not know whether OS versions below 10.0 do support the WITH_ICONV kn= ob. This maybe is a hint to the problem. Regards, Oliver --------------enig607FD8DB30C9DAC44998FE79 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 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO41H+AAoJEOgBcD7A/5N8EQwIALWpCCd4tPdsXV/x4ko50M/d JY2wSnv8v34QgyokOkakq0lsSMrp0O7o8gFTvr44n5+Kwl1HNyq6XFAcyxizFAFn hz9nJVsFAG5BPJSid7Y2nmoI90UxpGxFR6rG5d7Rgvy3wnbaT6FkYnoIqcE8yvWd Cc8CmaBYMtNRDZzh75isq8uieBkTCQAiTOfuSBMkvb+TqlrExy5wtu3USFugIm4/ ReiaJC3INDV2z35vZtl5wb66rkKh/Vh8N/fgi9NMmCN5KSIcBf8RE4gmqoj8eV27 7FAujc+xsfhtfqo3337dlx6QPxPEDQFua29gfL6aXF2JRdP9kIKxMi8CJMFTUws= =mSbM -----END PGP SIGNATURE----- --------------enig607FD8DB30C9DAC44998FE79-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 13:26:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A39F1065670 for ; Sat, 10 Dec 2011 13:26:25 +0000 (UTC) (envelope-from hskuhra@fastmail.fm) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCCE8FC0C for ; Sat, 10 Dec 2011 13:26:24 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B8EAA20AF9 for ; Sat, 10 Dec 2011 08:07:52 -0500 (EST) Received: from web2.nyi.mail.srv.osa ([10.202.2.212]) by compute3.internal (MEProxy); Sat, 10 Dec 2011 08:07:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=mesmtp; bh= oHbv59S626L92IW+gBspO8UgcqM=; b=lm00fDuSGB82LmaAw42AJMtNzyG1JV5a Oa78ACD+cY8PSGn3uozbI06XQzdMxsuLzowpR69yvj3ghPwc7lo9w5CLLiGUBJRc SrxyM24zykWbO9+96iw81rPh5LaquQq/NhOQFZm70FE5dTX1pV7HGcAy9bC68z+u P761ePU1WKw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:references:subject :in-reply-to:date; s=smtpout; bh=oHbv59S626L92IW+gBspO8UgcqM=; b= usBFfm7v+Kv1/MswHcum5jDmR4m8msqLcbMtN/xitDNKihpcuoI/5MX/TMOBG+Kp fnOa7psBukFX2mGMxuY/wEYxSddR0YlBk0Rgjd+/FhaRM7cy8PS7um9pFC9/ZD6x JLReqtFr8bbNZpAIVbNZWn83VH4oWn5oqLHzb1Sz1+s= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id 907C75C3D67; Sat, 10 Dec 2011 08:07:52 -0500 (EST) Message-Id: <1323522472.7801.140661009894937@webmail.messagingengine.com> X-Sasl-Enc: wbrN+JsjseakVMbZa9XXIB2nuPmmur389GqjJyYvgHlK 1323522472 From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <4EE32D8D.2080308@zedat.fu-berlin.de> In-Reply-To: <4EE32D8D.2080308@zedat.fu-berlin.de> Date: Sat, 10 Dec 2011 14:07:52 +0100 Subject: Re: How to update /usr/src/ using SVN and "make update"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 13:26:25 -0000 On Sat, Dec 10, 2011, at 10:59, O. Hartmann wrote: > Taking the instruction from manpage make.conf(5) and setting variable > SVN_UPDATE to YES, typing "make update" in /usr/src fails due to svn > can not be found. make.conf(5) also contains a variable "SUP" containing > the path for cvsup or cvsup and I'm desperately missing a similar > variable for subversion. Adding SVN="/usr/local/bin/svn" to /etc/make.conf works. -------------------------------------------------------------- >>> Updating /usr/src using Subversion -------------------------------------------------------------- /usr/local/bin/svn update Updating '.': At revision 228392. -- Herbert From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 13:35:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C273106564A for ; Sat, 10 Dec 2011 13:35:30 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 278918FC08 for ; Sat, 10 Dec 2011 13:35:29 +0000 (UTC) Received: by yenl9 with SMTP id l9so3730415yen.13 for ; Sat, 10 Dec 2011 05:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:message-id; bh=kp0mK33Rdcsl7ZRRo8PB2r7l5NmMCgkMnEtZILnv1DI=; b=EI2P7dhrLcw5VLS2MnVtTMdU4+Riqdw9O6y5C1n4sHISfitOE9q1XN+qSmL6vL9PPk wHXCcEoO5rbkTtnPaLOEsDJk0UEm0TxfNhZSW342vjJxRiVotseRUypq3K99/xDqGN58 igdybN7mudCnTHqXtmaV7Mzt8YxnK3miaDrb8= Received: by 10.236.201.137 with SMTP id b9mr17059160yho.124.1323524129571; Sat, 10 Dec 2011 05:35:29 -0800 (PST) Received: from freebeast.localnet (c-98-230-64-224.hsd1.al.comcast.net. [98.230.64.224]) by mx.google.com with ESMTPS id n5sm20496191yhk.1.2011.12.10.05.35.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Dec 2011 05:35:29 -0800 (PST) From: Chuck Burns To: freebsd-current@freebsd.org Date: Sat, 10 Dec 2011 07:35:27 -0600 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.7.3; amd64; ; ) References: <4EE32D8D.2080308@zedat.fu-berlin.de> In-Reply-To: <4EE32D8D.2080308@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_fA24Okh8RQVWStY" Message-Id: <201112100735.27683.break19@gmail.com> Subject: Re: How to update /usr/src/ using SVN and "make update"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 13:35:30 -0000 --Boundary-00=_fA24Okh8RQVWStY Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit On Saturday, December 10, 2011 3:59:41 AM O. Hartmann wrote: > Taking the instruction from manpage make.conf(5) and setting variable > SVN_UPDATE to YES, typing "make update" in /usr/src fails due to svn > can not be found. make.conf(5) also contains a variable "SUP" containing > the path for cvsup or cvsup and I'm desperately missing a similar > variable for subversion. Since subversion is a port, it might be so that > setting a variable in make.conf(5) conflicts with the BSD policy and > logic, but then I'd appreciate a hint like "you need to set the propper > environment variable for finding svn in the search path ...blablabla". > Using "make update" ends up in "svn not found". Typing manually "svn -r > HEAD" in /usr/src as it is shown when the make update fails works well, > since the shell's environment PATH variable knows /usr/local/bin to look > for. > I also file a PR not letting this getting forgotten, please close it, if > it is obsolete. > > Regards, > O. Hartmann Here is quick, hackish patch to allow your make update to work, it appears that the Makefile.inc1 does not include the full path to svn, while it does include the full path to cvs and other tools, this makes me think that the user path is ignored (which is a good thing) -- Chuck Burns The Southern Libertarian http://www.thesouthernlibertarian.com/ --Boundary-00=_fA24Okh8RQVWStY Content-Type: text/x-patch; charset="ISO-8859-1"; name="Makefile.inc1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Makefile.inc1.patch" Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 228349) +++ Makefile.inc1 (working copy) @@ -106,7 +106,7 @@ CVS?= cvs CVSFLAGS?= -A -P -d -I! -SVN?= svn +SVN?= /usr/local/bin/svn SVNFLAGS?= -r HEAD SUP?= /usr/bin/csup SUPFLAGS?= -g -L 2 --Boundary-00=_fA24Okh8RQVWStY-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 13:51:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B1AF106566B for ; Sat, 10 Dec 2011 13:51:38 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8898FC15 for ; Sat, 10 Dec 2011 13:51:38 +0000 (UTC) Received: by yenl9 with SMTP id l9so3737393yen.13 for ; Sat, 10 Dec 2011 05:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=UYmXpNnDfCEXAaC2A8KmT8V8Q1uCRF/Z+fIhOT5O+eA=; b=GWZ9zxqDTLmdCvC16p8FBjp+ZL5qZDibneDhvMcOneRYQWHCnkCrZZ6BT5/cjruIua pc4iCCTNOHDzjkycol/H+di0j3S5A+MSeHfxew9USFlbznpI3PuyN+KgJru9wVZMsFmc yF2tE3I9ZIdm6FFgO6j1vJeCEL1SV3+jzie3c= Received: by 10.236.183.52 with SMTP id p40mr17634092yhm.19.1323525097801; Sat, 10 Dec 2011 05:51:37 -0800 (PST) Received: from freebeast.localnet (c-98-230-64-224.hsd1.al.comcast.net. [98.230.64.224]) by mx.google.com with ESMTPS id i50sm20514869yhk.11.2011.12.10.05.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Dec 2011 05:51:36 -0800 (PST) From: Chuck Burns To: freebsd-current@freebsd.org Date: Sat, 10 Dec 2011 07:51:28 -0600 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.7.3; amd64; ; ) References: <4EE32D8D.2080308@zedat.fu-berlin.de> <201112100735.27683.break19@gmail.com> In-Reply-To: <201112100735.27683.break19@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112100751.28788.break19@gmail.com> Subject: Re: How to update /usr/src/ using SVN and "make update"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 13:51:38 -0000 On Saturday, December 10, 2011 7:35:27 AM Chuck Burns wrote: > Here is quick, hackish patch to allow your make update to work, it appears > that the Makefile.inc1 does not include the full path to svn, while it does > include the full path to cvs and other tools, this makes me think that the > user path is ignored (which is a good thing) > Heh, I am notorious for overthinking things. My bad.. yes, just add SVN=/usr/local/bin/svn to your /etc/make.conf file -- Chuck Burns The Southern Libertarian http://www.thesouthernlibertarian.com/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 15:03:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A464B1065670; Sat, 10 Dec 2011 15:03:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 702748FC14; Sat, 10 Dec 2011 15:03:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBAF3SRh079617; Sat, 10 Dec 2011 10:03:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBAF3SPv079584; Sat, 10 Dec 2011 15:03:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Dec 2011 15:03:28 GMT Message-Id: <201112101503.pBAF3SPv079584@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 15:03:29 -0000 TB --- 2011-12-10 12:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-10 12:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-10 12:50:00 - cleaning the object tree TB --- 2011-12-10 12:51:04 - cvsupping the source tree TB --- 2011-12-10 12:51:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-10 12:51:16 - building world TB --- 2011-12-10 12:51:16 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 12:51:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 12:51:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 12:51:16 - SRCCONF=/dev/null TB --- 2011-12-10 12:51:16 - TARGET=i386 TB --- 2011-12-10 12:51:16 - TARGET_ARCH=i386 TB --- 2011-12-10 12:51:16 - TZ=UTC TB --- 2011-12-10 12:51:16 - __MAKE_CONF=/dev/null TB --- 2011-12-10 12:51:16 - cd /src TB --- 2011-12-10 12:51:16 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 10 12:51:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Dec 10 14:56:22 UTC 2011 TB --- 2011-12-10 14:56:22 - generating LINT kernel config TB --- 2011-12-10 14:56:22 - cd /src/sys/i386/conf TB --- 2011-12-10 14:56:22 - /usr/bin/make -B LINT TB --- 2011-12-10 14:56:23 - cd /src/sys/i386/conf TB --- 2011-12-10 14:56:23 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-10 14:56:23 - building LINT-NOINET kernel TB --- 2011-12-10 14:56:23 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 14:56:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 14:56:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 14:56:23 - SRCCONF=/dev/null TB --- 2011-12-10 14:56:23 - TARGET=i386 TB --- 2011-12-10 14:56:23 - TARGET_ARCH=i386 TB --- 2011-12-10 14:56:23 - TZ=UTC TB --- 2011-12-10 14:56:23 - __MAKE_CONF=/dev/null TB --- 2011-12-10 14:56:23 - cd /src TB --- 2011-12-10 14:56:23 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Dec 10 14:56:23 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c: In function 'em_ioctl': /src/sys/dev/e1000/if_em.c:1047: warning: unused variable 'ifa' [-Wunused-variable] /src/sys/dev/e1000/if_em.c: In function 'em_setup_receive_ring': /src/sys/dev/e1000/if_em.c:4103: error: 'j' undeclared (first use in this function) /src/sys/dev/e1000/if_em.c:4103: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_em.c:4103: error: for each function it appears in.) /src/sys/dev/e1000/if_em.c:4103: warning: left-hand operand of comma expression has no effect /src/sys/dev/e1000/if_em.c:4103: warning: value computed is not used *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-10 15:03:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-10 15:03:27 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-12-10 15:03:28 - 6347.93 user 1152.63 system 8007.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 15:33:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 089AA106566B; Sat, 10 Dec 2011 15:33:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D101E8FC0A; Sat, 10 Dec 2011 15:33:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBAFXXra055410; Sat, 10 Dec 2011 10:33:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBAFXWej055399; Sat, 10 Dec 2011 15:33:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Dec 2011 15:33:33 GMT Message-Id: <201112101533.pBAFXWej055399@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 15:33:34 -0000 TB --- 2011-12-10 12:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-10 12:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-10 12:50:00 - cleaning the object tree TB --- 2011-12-10 12:51:03 - cvsupping the source tree TB --- 2011-12-10 12:51:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-10 12:51:15 - building world TB --- 2011-12-10 12:51:15 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 12:51:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 12:51:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 12:51:15 - SRCCONF=/dev/null TB --- 2011-12-10 12:51:15 - TARGET=amd64 TB --- 2011-12-10 12:51:15 - TARGET_ARCH=amd64 TB --- 2011-12-10 12:51:15 - TZ=UTC TB --- 2011-12-10 12:51:15 - __MAKE_CONF=/dev/null TB --- 2011-12-10 12:51:15 - cd /src TB --- 2011-12-10 12:51:15 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 10 12:51:16 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Dec 10 15:26:48 UTC 2011 TB --- 2011-12-10 15:26:49 - generating LINT kernel config TB --- 2011-12-10 15:26:49 - cd /src/sys/amd64/conf TB --- 2011-12-10 15:26:49 - /usr/bin/make -B LINT TB --- 2011-12-10 15:26:49 - cd /src/sys/amd64/conf TB --- 2011-12-10 15:26:49 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-10 15:26:49 - building LINT-NOINET kernel TB --- 2011-12-10 15:26:49 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 15:26:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 15:26:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 15:26:49 - SRCCONF=/dev/null TB --- 2011-12-10 15:26:49 - TARGET=amd64 TB --- 2011-12-10 15:26:49 - TARGET_ARCH=amd64 TB --- 2011-12-10 15:26:49 - TZ=UTC TB --- 2011-12-10 15:26:49 - __MAKE_CONF=/dev/null TB --- 2011-12-10 15:26:49 - cd /src TB --- 2011-12-10 15:26:49 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Dec 10 15:26:49 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c: In function 'em_ioctl': /src/sys/dev/e1000/if_em.c:1047: warning: unused variable 'ifa' [-Wunused-variable] /src/sys/dev/e1000/if_em.c: In function 'em_setup_receive_ring': /src/sys/dev/e1000/if_em.c:4103: error: 'j' undeclared (first use in this function) /src/sys/dev/e1000/if_em.c:4103: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_em.c:4103: error: for each function it appears in.) /src/sys/dev/e1000/if_em.c:4103: warning: left-hand operand of comma expression has no effect /src/sys/dev/e1000/if_em.c:4103: warning: value computed is not used *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-10 15:33:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-10 15:33:32 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-12-10 15:33:32 - 7643.27 user 1523.17 system 9811.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 20:33:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C4811065673; Sat, 10 Dec 2011 20:33:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id ECD3E8FC18; Sat, 10 Dec 2011 20:33:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBAKX81u047874; Sat, 10 Dec 2011 15:33:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBAKX85x047863; Sat, 10 Dec 2011 20:33:08 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Dec 2011 20:33:08 GMT Message-Id: <201112102033.pBAKX85x047863@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 20:33:10 -0000 TB --- 2011-12-10 18:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-10 18:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-12-10 18:20:00 - cleaning the object tree TB --- 2011-12-10 18:20:27 - cvsupping the source tree TB --- 2011-12-10 18:20:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-12-10 18:21:19 - building world TB --- 2011-12-10 18:21:19 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 18:21:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 18:21:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 18:21:19 - SRCCONF=/dev/null TB --- 2011-12-10 18:21:19 - TARGET=i386 TB --- 2011-12-10 18:21:19 - TARGET_ARCH=i386 TB --- 2011-12-10 18:21:19 - TZ=UTC TB --- 2011-12-10 18:21:19 - __MAKE_CONF=/dev/null TB --- 2011-12-10 18:21:19 - cd /src TB --- 2011-12-10 18:21:19 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 10 18:21:20 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Dec 10 20:26:12 UTC 2011 TB --- 2011-12-10 20:26:12 - generating LINT kernel config TB --- 2011-12-10 20:26:12 - cd /src/sys/i386/conf TB --- 2011-12-10 20:26:12 - /usr/bin/make -B LINT TB --- 2011-12-10 20:26:12 - cd /src/sys/i386/conf TB --- 2011-12-10 20:26:12 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-10 20:26:12 - building LINT-NOINET kernel TB --- 2011-12-10 20:26:12 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 20:26:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 20:26:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 20:26:12 - SRCCONF=/dev/null TB --- 2011-12-10 20:26:12 - TARGET=i386 TB --- 2011-12-10 20:26:12 - TARGET_ARCH=i386 TB --- 2011-12-10 20:26:12 - TZ=UTC TB --- 2011-12-10 20:26:12 - __MAKE_CONF=/dev/null TB --- 2011-12-10 20:26:12 - cd /src TB --- 2011-12-10 20:26:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Dec 10 20:26:12 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c: In function 'em_ioctl': /src/sys/dev/e1000/if_em.c:1047: warning: unused variable 'ifa' [-Wunused-variable] /src/sys/dev/e1000/if_em.c: In function 'em_setup_receive_ring': /src/sys/dev/e1000/if_em.c:4103: error: 'j' undeclared (first use in this function) /src/sys/dev/e1000/if_em.c:4103: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_em.c:4103: error: for each function it appears in.) /src/sys/dev/e1000/if_em.c:4103: warning: left-hand operand of comma expression has no effect /src/sys/dev/e1000/if_em.c:4103: warning: value computed is not used *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-10 20:33:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-10 20:33:08 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-12-10 20:33:08 - 6333.11 user 1123.80 system 7987.51 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 21:00:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7040B106564A for ; Sat, 10 Dec 2011 21:00:38 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 28A218FC12 for ; Sat, 10 Dec 2011 21:00:37 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RZU29-0002MK-5m>; Sat, 10 Dec 2011 22:00:37 +0100 Received: from e178020136.adsl.alicedsl.de ([85.178.20.136] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RZU29-0004iM-1F>; Sat, 10 Dec 2011 22:00:37 +0100 Message-ID: <4EE3C86F.6020101@zedat.fu-berlin.de> Date: Sat, 10 Dec 2011 22:00:31 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Chuck Burns References: <4EE32D8D.2080308@zedat.fu-berlin.de> <201112100735.27683.break19@gmail.com> <201112100751.28788.break19@gmail.com> In-Reply-To: <201112100751.28788.break19@gmail.com> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA9E1B0D666FD6EFFA5FA23FF" X-Originating-IP: 85.178.20.136 Cc: freebsd-current@freebsd.org Subject: Re: How to update /usr/src/ using SVN and "make update"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 21:00:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA9E1B0D666FD6EFFA5FA23FF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 12/10/11 14:51, Chuck Burns wrote: > On Saturday, December 10, 2011 7:35:27 AM Chuck Burns wrote: >> Here is quick, hackish patch to allow your make update to work, it app= ears >> that the Makefile.inc1 does not include the full path to svn, while it= does >> include the full path to cvs and other tools, this makes me think that= the >> user path is ignored (which is a good thing) >> >=20 > Heh, I am notorious for overthinking things. My bad.. yes, just add > SVN=3D/usr/local/bin/svn > to your /etc/make.conf file >=20 > -- > Chuck Burns Hello. I did this already, since it looked logical to me. It isn't simply about "please add ..." hakish things. If there would be no objection, it is a nice move to have the SVN variable setting mentioned in the man page for make.conf. If it isn't opportune to have the user-path in the system's search path, then a note should be droped into the manpage to inform the admin or user to set the SVN variable properly. Oliver --------------enigA9E1B0D666FD6EFFA5FA23FF 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 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO48h0AAoJEOgBcD7A/5N8TngIAKtfU2jv6dK98+py3j53+N+w NoCRZH4MYm8YxuA1U9fCS1b6/EiGJxzZi6EzCXjNU9f5uMbCgP01v5I/jNk45HKJ 6Jb70eVwdmF4E2o9fj8TMwOiyGfmuv5pnFSrYX/xjp3wBtTJcVlOB2nV7RWZNyXo JIccjeIC39kAVsOBFSNS9tILB+DvKpjDP2VtQoC1TjuUWwFuILgjlSXPtirIB9DS ZyaN5OmPZBgIXV2OO2gvwE/red+/C5Q0DPb+MO0pbyCIpS6KY/lXh+UwAIxm95Bv 3Kp61YEg/5bqEuy2a4Fe3jt39348ETOxmZDK2GPw7bSKQK6WrPNzwIe01J2DtSw= =uWAm -----END PGP SIGNATURE----- --------------enigA9E1B0D666FD6EFFA5FA23FF-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 21:08:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B34106564A; Sat, 10 Dec 2011 21:08:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 865758FC12; Sat, 10 Dec 2011 21:08:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pBAL8V59083302; Sat, 10 Dec 2011 16:08:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pBAL8VsB083265; Sat, 10 Dec 2011 21:08:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 10 Dec 2011 21:08:31 GMT Message-Id: <201112102108.pBAL8VsB083265@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 21:08:33 -0000 TB --- 2011-12-10 18:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-10 18:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-12-10 18:20:00 - cleaning the object tree TB --- 2011-12-10 18:20:31 - cvsupping the source tree TB --- 2011-12-10 18:20:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-12-10 18:25:56 - building world TB --- 2011-12-10 18:25:56 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 18:25:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 18:25:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 18:25:56 - SRCCONF=/dev/null TB --- 2011-12-10 18:25:56 - TARGET=amd64 TB --- 2011-12-10 18:25:56 - TARGET_ARCH=amd64 TB --- 2011-12-10 18:25:56 - TZ=UTC TB --- 2011-12-10 18:25:56 - __MAKE_CONF=/dev/null TB --- 2011-12-10 18:25:56 - cd /src TB --- 2011-12-10 18:25:56 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 10 18:25:57 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Dec 10 21:01:44 UTC 2011 TB --- 2011-12-10 21:01:45 - generating LINT kernel config TB --- 2011-12-10 21:01:45 - cd /src/sys/amd64/conf TB --- 2011-12-10 21:01:45 - /usr/bin/make -B LINT TB --- 2011-12-10 21:01:45 - cd /src/sys/amd64/conf TB --- 2011-12-10 21:01:45 - /usr/sbin/config -m LINT-NOINET TB --- 2011-12-10 21:01:45 - building LINT-NOINET kernel TB --- 2011-12-10 21:01:45 - CROSS_BUILD_TESTING=YES TB --- 2011-12-10 21:01:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-10 21:01:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-10 21:01:45 - SRCCONF=/dev/null TB --- 2011-12-10 21:01:45 - TARGET=amd64 TB --- 2011-12-10 21:01:45 - TARGET_ARCH=amd64 TB --- 2011-12-10 21:01:45 - TZ=UTC TB --- 2011-12-10 21:01:45 - __MAKE_CONF=/dev/null TB --- 2011-12-10 21:01:45 - cd /src TB --- 2011-12-10 21:01:45 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Dec 10 21:01:45 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/e1000/if_em.c: In function 'em_ioctl': /src/sys/dev/e1000/if_em.c:1047: warning: unused variable 'ifa' [-Wunused-variable] /src/sys/dev/e1000/if_em.c: In function 'em_setup_receive_ring': /src/sys/dev/e1000/if_em.c:4103: error: 'j' undeclared (first use in this function) /src/sys/dev/e1000/if_em.c:4103: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_em.c:4103: error: for each function it appears in.) /src/sys/dev/e1000/if_em.c:4103: warning: left-hand operand of comma expression has no effect /src/sys/dev/e1000/if_em.c:4103: warning: value computed is not used *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-10 21:08:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-10 21:08:31 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-12-10 21:08:31 - 7646.43 user 1495.12 system 10110.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 10 23:51:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 765C6106564A for ; Sat, 10 Dec 2011 23:51:03 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id E20358FC13 for ; Sat, 10 Dec 2011 23:51:02 +0000 (UTC) X-AuditID: 12074424-b7ef76d0000008dc-10-4ee3f0669c8c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 6D.7D.02268.660F3EE4; Sat, 10 Dec 2011 18:51:02 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id pBANp1BX014618; Sat, 10 Dec 2011 18:51:02 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pBANowCf029959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Dec 2011 18:50:59 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pBANov4B027352; Sat, 10 Dec 2011 18:50:57 -0500 (EST) Date: Sat, 10 Dec 2011 18:50:57 -0500 (EST) From: Benjamin Kaduk To: "O. Hartmann" In-Reply-To: <4EE351FE.5070807@zedat.fu-berlin.de> Message-ID: References: <4EDEF1FF.5020307@zedat.fu-berlin.de> <20111207061137.GA38900@troutmask.apl.washington.edu> <4EE351FE.5070807@zedat.fu-berlin.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrJv24bGfwYv3vBZz3nxgsnj5dROL xbJHG9ks/s76w+TA4jHj03wWj1PbDzIGMEVx2aSk5mSWpRbp2yVwZUya+o+xYCNvxY8fV1ga GJ9ydTFyckgImEj82NbCDmGLSVy4t54NxBYS2McoMemmaxcjF5C9gVFi5tV2JgjnAJNEx6y1 rBBOA6PEibUrgTIcHCwC2hInZ4NNYhNQkZj5ZiPYJBEBfYlzTafBbGYBF4lj7XvAaoQFvCQ+ /XzFDGJzChhJPFm+AizOK2AvsXP2MkaI+b2MEj8m7mQCSYgK6Eis3j+FBaJIUOLkzCcsEEMt Jf6t/cU6gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3MYLC l91FZQdj8yGlQ4wCHIxKPLwH7z/2E2JNLCuuzD3EKMnBpCTKO+c9UIgvKT+lMiOxOCO+qDQn tfgQowQHs5II7+lOoBxvSmJlVWpRPkxKmoNFSZy3YddDPyGB9MSS1OzU1ILUIpisDAeHkgTv XZChgkWp6akVaZk5JQhpJg5OkOE8QMPBFvMWFyTmFmemQ+RPMSpKifOuBkkIgCQySvPgemHp 5RWjONArwrxLQKp4gKkJrvsV0GAmoMFfsh+ADC5JREhJNTCuY1645wDX9tDOggzeSc9i8zy/ pnNzVrrd8VH+ous/dwdb+fdkh+VMqj9lrs2/uTUjVPCoUPObbfb8pZE+Ncs6LTbP4toUw3rl WZr7XvmNvLbOuw5ltPXd1hW8Hqrx+sKv+7vPLAnT5ndeq/F/T8ukL3X9kwtyHSNeNXs9OPtF 6vb6E4u+rRdVYinOSDTUYi4qTgQA6GY9XAoDAAA= Cc: Current FreeBSD , gabor@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 23:51:03 -0000 [-questions to bcc] On Sat, 10 Dec 2011, O. Hartmann wrote: > On 12/07/11 07:11, Steve Kargl wrote: >> On Wed, Dec 07, 2011 at 05:56:31AM +0100, O. Hartmann wrote: >>> config.status: creating ada/Makefile >>> config.status: creating auto-host.h >>> config.status: executing default commands >>> gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' >>> gmake[1]: *** [stage1-bubble] Error 2 >>> gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' >>> gmake: *** [bootstrap-lean] Error 2 >>> *** Error code 1 >>> >>> Stop in /usr/ports/lang/gcc46. >>> *** Error code 1 >>> >>> Stop in /usr/ports/lang/gcc46. >>> >>> ===>>> make failed for lang/gcc46 >>> ===>>> Aborting update >>> >> >> See if setting DISABLE_MAKE_JOBSi helps. >> > > This doesn't work, either. The end of the build log from that case should be more enlightening than the one you originally posted, as it is more likely to actually contain the actual error (which is not present in the snippet above). > > In /etc/src.conf, I use WITH_ICONV=YES and _WITH_BSD_GREP=YES. Switching > off WITH_ICONV seems to solve the problem on FreeBSD 10.0-CURRENT/amd64. > > I do not know whether OS versions below 10.0 do support the WITH_ICONV knob. > > This maybe is a hint to the problem. iconv was only added to base in r219019 | gabor | 2011-02-24 19:04:39 -0500 (Thu, 24 Feb 2011) so it will first appear in the imminent 9.0 release. Assuming that the error remains reproducible with an up-to-date tree, the end of the build log from the DISABLE_MAKE_JOBS case would be useful to see. I've added gabor as a cc, since he seems to be doing most of the iconv work. -Ben Kaduk