From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 07:38:02 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FA221065672 for ; Mon, 24 May 2010 07:38:02 +0000 (UTC) (envelope-from bfiedler@asu.edu) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 63B188FC19 for ; Mon, 24 May 2010 07:38:01 +0000 (UTC) Received: by pvh11 with SMTP id 11so330212pvh.13 for ; Mon, 24 May 2010 00:38:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.106.21 with SMTP id i21mr3720049rvm.40.1274684910403; Mon, 24 May 2010 00:08:30 -0700 (PDT) Received: by 10.141.32.9 with HTTP; Mon, 24 May 2010 00:08:30 -0700 (PDT) Date: Mon, 24 May 2010 00:08:30 -0700 Message-ID: From: Ben Fiedler To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 07:38:02 -0000 I'll be working on replacing groff with mdocml (mandoc) in the system base (and yes, I am aware of Gordon's work on a man replacement). In addition, I will be creating or (more likely) porting BSD-ish licensed feature-complete replacements for: diff, sort, sdiff, diff3, also moving them into the base (and yes, I know of the bsddiff and bsdsort ports). Finally, I will perform some benchmark comparisons between these new tools and their GNU counterparts. More info is available at my project page: http://wiki.freebsd.org/SOC2010BenFiedler Any feedback or questions are most welcome. Thanks, -Ben From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 12:26:44 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B2C1065676 for ; Mon, 24 May 2010 12:26:44 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8A93A8FC16 for ; Mon, 24 May 2010 12:26:43 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o4OCNi6Z087267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 14:23:44 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1274703824; bh=huAtfdO1daumywruh1XYmZ82T0wNar8k4rZUbD6YglI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=cvC5b8xyHC5UNs7zGB0Z3pCmWykwmi7EgeusrNZ0i2gjpReOVvxsPXGgo2RcR4kWo Apgt9uSOItp1WemXDzt5svTG7fBZDJxxrVqpKqB90QwVkj57ZSSc5DCXwcvT3jT/gt gTPunK3ruSWNkpKjwHj/s1dbQZ5gYJ1glzM2BqWI= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o4OCNi9A087266; Mon, 24 May 2010 14:23:44 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 24 May 2010 14:23:44 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Ben Fiedler Message-ID: <20100524122343.GB85712@acme.spoerlein.net> Mail-Followup-To: Ben Fiedler , hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 12:26:44 -0000 On Mon, 24.05.2010 at 00:08:30 -0700, Ben Fiedler wrote: > I'll be working on replacing groff with mdocml (mandoc) in the system base > (and yes, I am aware of Gordon's work on a man > replacement). > In addition, I will be creating or (more likely) porting BSD-ish licensed > feature-complete replacements for: diff, sort, sdiff, diff3, also moving > them into the base (and yes, I know of the bsddiff and bsdsort ports). > Finally, I will perform some benchmark comparisons between these new tools > and their GNU counterparts. > > More info is available at my project page: > http://wiki.freebsd.org/SOC2010BenFiedler > > Any feedback or questions are most welcome. Please contact me regarding mdocml/mandoc work, as I already have a tree set up for the mdocml inclusion and have been working with Kristaps and Ruslan to get this all in good shape for an eventual import. thx, Uli From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 19:13:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1677106564A for ; Mon, 24 May 2010 19:13:11 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4888FC12 for ; Mon, 24 May 2010 19:13:10 +0000 (UTC) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta10.westchester.pa.mail.comcast.net with comcast id MUtZ1e00A0ldTLk5AXDBbt; Mon, 24 May 2010 19:13:11 +0000 Received: from comcast.net ([98.203.142.76]) by omta04.westchester.pa.mail.comcast.net with comcast id MXD91e0021f6R9u3QXD9v5; Mon, 24 May 2010 19:13:11 +0000 Received: by comcast.net (sSMTP sendmail emulation); Mon, 24 May 2010 12:13:07 -0700 Date: Mon, 24 May 2010 12:13:07 -0700 From: Charlie Kester To: freebsd-hackers@freebsd.org Message-ID: <20100524191307.GE216@comcast.net> Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Mailer: Mutt 1.5.20 X-Composer: Vim 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 19:13:11 -0000 On Mon 24 May 2010 at 00:08:30 PDT Ben Fiedler wrote: >I'll be working on replacing groff with mdocml (mandoc) in the system base >(and yes, I am aware of Gordon's work on a man >replacement). >In addition, I will be creating or (more likely) porting BSD-ish licensed >feature-complete replacements for: diff, sort, sdiff, diff3, also moving >them into the base (and yes, I know of the bsddiff and bsdsort ports). >Finally, I will perform some benchmark comparisons between these new tools >and their GNU counterparts. > >More info is available at my project page: >http://wiki.freebsd.org/SOC2010BenFiedler > >Any feedback or questions are most welcome. I welcome this change, but groff is used for much more than manpages. What happens to pic, tbl, and the other troff-related "little languages"? How can you say mdocml is "completely replacing" groff if it doesn't support those kinds of things? Is the thinking that groff has only been in base to support manpages? If so, this project makes sense. But even so, some clarification of the intent is needed. From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 19:19:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B1281065676 for ; Mon, 24 May 2010 19:19:17 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.sonnenberger.org [92.79.50.50]) by mx1.freebsd.org (Postfix) with ESMTP id F154A8FC1E for ; Mon, 24 May 2010 19:19:16 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 313BA667BA for ; Mon, 24 May 2010 21:19:14 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 85D4C1508C; Mon, 24 May 2010 21:17:01 +0200 (CEST) Date: Mon, 24 May 2010 21:17:01 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20100524191701.GA29256@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20100524191307.GE216@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100524191307.GE216@comcast.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 19:19:17 -0000 On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: > I welcome this change, but groff is used for much more than manpages. > What happens to pic, tbl, and the other troff-related "little > languages"? How can you say mdocml is "completely replacing" groff if > it doesn't support those kinds of things? tbl(1) is going to be supported fully at some point in the future. It is work-in-progress. I am not sure if pic(1) is actually used beyond the groff documentation, at least I don't remember anything in NetBSD where I checked. Similiar usage is found for eqn(1). > Is the thinking that groff has only been in base to support manpages? > If so, this project makes sense. But even so, some clarification of the > intent is needed. The use of (g)roff for anything but man pages is practically non-existent. If you want to use it for typesetting, you can always install it. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 19:37:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAAA010656C9 for ; Mon, 24 May 2010 19:37:16 +0000 (UTC) (envelope-from corky1951@comcast.net) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id A11878FC1C for ; Mon, 24 May 2010 19:37:16 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta04.emeryville.ca.mail.comcast.net with comcast id MSEa1e0021smiN4A4XdHMH; Mon, 24 May 2010 19:37:17 +0000 Received: from comcast.net ([98.203.142.76]) by omta20.emeryville.ca.mail.comcast.net with comcast id MXdG1e0081f6R9u8gXdGx8; Mon, 24 May 2010 19:37:17 +0000 Received: by comcast.net (sSMTP sendmail emulation); Mon, 24 May 2010 12:37:14 -0700 Date: Mon, 24 May 2010 12:37:14 -0700 From: Charlie Kester To: freebsd-hackers@freebsd.org Message-ID: <20100524193714.GF216@comcast.net> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20100524191307.GE216@comcast.net> <20100524191701.GA29256@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20100524191701.GA29256@britannica.bec.de> X-Mailer: Mutt 1.5.20 X-Composer: Vim 7.2 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 19:37:16 -0000 On Mon 24 May 2010 at 12:17:01 PDT Joerg Sonnenberger wrote: >On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: >> I welcome this change, but groff is used for much more than manpages. >> What happens to pic, tbl, and the other troff-related "little >> languages"? How can you say mdocml is "completely replacing" groff if >> it doesn't support those kinds of things? > >tbl(1) is going to be supported fully at some point in the future. >It is work-in-progress. I am not sure if pic(1) is actually used beyond >the groff documentation, at least I don't remember anything in NetBSD >where I checked. Similiar usage is found for eqn(1). > >> Is the thinking that groff has only been in base to support manpages? >> If so, this project makes sense. But even so, some clarification of the >> intent is needed. > >The use of (g)roff for anything but man pages is practically >non-existent. If you want to use it for typesetting, you can always >install it. Yes, I understand that troff-style typesetting has mostly been abandoned in favor of WYSIWYG editing. And I don't have a problem with groff moving over to ports, for those who still want or need it. I just think announcements related to this project should try to avoid creating the misimpression that it's intended to replace ALL of groff's functionality. Saying it "completely replaces" groff is misleading when what was really meant is that it replaces groff *for our purposes*. From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 19:43:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFBB6106566B for ; Mon, 24 May 2010 19:43:41 +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 267308FC1F for ; Mon, 24 May 2010 19:43:40 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4OJhoxP092026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 May 2010 22:43:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4OJhbUM033723 for ; Mon, 24 May 2010 22:43:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4OJhbF8033722 for freebsd-hackers@freebsd.org; Mon, 24 May 2010 22:43:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 24 May 2010 22:43:37 +0300 From: Kostik Belousov To: freebsd-hackers@freebsd.org Message-ID: <20100524194337.GN83316@deviant.kiev.zoral.com.ua> References: <20100524191307.GE216@comcast.net> <20100524191701.GA29256@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZgGs4xYo94cs2XY/" Content-Disposition: inline In-Reply-To: <20100524191701.GA29256@britannica.bec.de> 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=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 19:43:41 -0000 --ZgGs4xYo94cs2XY/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 24, 2010 at 09:17:01PM +0200, Joerg Sonnenberger wrote: > On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: > > I welcome this change, but groff is used for much more than manpages. > > What happens to pic, tbl, and the other troff-related "little > > languages"? How can you say mdocml is "completely replacing" groff if > > it doesn't support those kinds of things? >=20 > tbl(1) is going to be supported fully at some point in the future. > It is work-in-progress. I am not sure if pic(1) is actually used beyond > the groff documentation, at least I don't remember anything in NetBSD > where I checked. Similiar usage is found for eqn(1). >=20 > > Is the thinking that groff has only been in base to support manpages? > > If so, this project makes sense. But even so, some clarification of the > > intent is needed. >=20 > The use of (g)roff for anything but man pages is practically non-existent. > If you want to use it for typesetting, you can always install it. Would it support ps/dvi output ? --ZgGs4xYo94cs2XY/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkv61uYACgkQC3+MBN1Mb4jmOQCeNLmQOvpmNl2wNtGxkHKFaQPZ r+MAn3AbL6/8lTxHiYuj8BlXDDupjlvr =FIWE -----END PGP SIGNATURE----- --ZgGs4xYo94cs2XY/-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 20:32:49 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF671065677 for ; Mon, 24 May 2010 20:32:49 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.sonnenberger.org [92.79.50.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7938FC0C for ; Mon, 24 May 2010 20:32:49 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 165BF6674D for ; Mon, 24 May 2010 22:32:47 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 8CF0F1508C; Mon, 24 May 2010 22:30:34 +0200 (CEST) Date: Mon, 24 May 2010 22:30:34 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20100524203034.GA45@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20100524191307.GE216@comcast.net> <20100524191701.GA29256@britannica.bec.de> <20100524194337.GN83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100524194337.GN83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 20:32:49 -0000 On Mon, May 24, 2010 at 10:43:37PM +0300, Kostik Belousov wrote: > Would it support ps/dvi output ? Postscript output is the major goal of a GSoC project. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon May 24 22:27:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31785106566B for ; Mon, 24 May 2010 22:27:46 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id EB35D8FC08 for ; Mon, 24 May 2010 22:27:45 +0000 (UTC) Received: from [10.72.184.164] (hitfishpass-lx.corp.yahoo.com [10.72.184.164]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o4OMQEte033890 for ; Mon, 24 May 2010 15:26:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:content-type:date:message-id: mime-version:x-mailer; b=xs5FO+vgtMTuhgc5I9FGenlfClDJ4nFqJQygBvX1AJb+wSJmIW/hxlTegDnm9IC4 From: Sean Bruno To: freebsd-hackers Content-Type: multipart/mixed; boundary="=-j4QQ/FoprjniytAV16+J" Date: Mon, 24 May 2010 15:26:13 -0700 Message-ID: <1274739973.31299.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Subject: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 22:27:46 -0000 --=-j4QQ/FoprjniytAV16+J Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Find attached a patch against -CURRENT. This update exposes a counter that indicates the number of times that we sleep when attempting to allocate a slab from the keg. In other words, the number of times we BLOCK and wait, which is bad. This allows differentiation between times when we failed to allocate and it was ok and times where we were forced to sleep. The current FAIL counter does not make this distinction. Exposes this information via uma_zone_t->uz_sleeps. Add a new sysctl to retrieve this information. Enhance vmstat -z to retrieve this information. We've found this *extremely* useful here at Yahoo in the past and would like to commit this if it is acceptable. Tested on 32bit and 64bit architectures on 6/7/CURRENT. --=-j4QQ/FoprjniytAV16+J Content-Disposition: attachment; filename="sleep_stat.diff" Content-Type: text/x-patch; name="sleep_stat.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit Index: usr.bin/vmstat/vmstat.c =================================================================== --- usr.bin/vmstat/vmstat.c (revision 208460) +++ usr.bin/vmstat/vmstat.c (working copy) @@ -1294,16 +1294,17 @@ memstat_strerror(error)); } } - printf("%-20s %8s %8s %8s %8s %8s %8s\n\n", "ITEM", "SIZE", - "LIMIT", "USED", "FREE", "REQUESTS", "FAILURES"); + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", + "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP"); for (mtp = memstat_mtl_first(mtlp); mtp != NULL; mtp = memstat_mtl_next(mtp)) { strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME); strcat(name, ":"); - printf("%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n", name, + printf("%-20s %6llu, %6llu,%8llu,%8llu,%8llu,%4llu,%4llu\n",name, memstat_get_size(mtp), memstat_get_countlimit(mtp), memstat_get_count(mtp), memstat_get_free(mtp), - memstat_get_numallocs(mtp), memstat_get_failures(mtp)); + memstat_get_numallocs(mtp), memstat_get_failures(mtp), + memstat_get_sleeps(mtp)); } memstat_mtl_free(mtlp); printf("\n"); Index: lib/libmemstat/memstat.h =================================================================== --- lib/libmemstat/memstat.h (revision 208460) +++ lib/libmemstat/memstat.h (working copy) @@ -139,6 +139,7 @@ uint64_t memstat_get_count(const struct memory_type *mtp); uint64_t memstat_get_free(const struct memory_type *mtp); uint64_t memstat_get_failures(const struct memory_type *mtp); +uint64_t memstat_get_sleeps(const struct memory_type *mtp); void *memstat_get_caller_pointer(const struct memory_type *mtp, int index); void memstat_set_caller_pointer(struct memory_type *mtp, Index: lib/libmemstat/memstat.c =================================================================== --- lib/libmemstat/memstat.c (revision 208460) +++ lib/libmemstat/memstat.c (working copy) @@ -188,6 +188,7 @@ mtp->mt_count = 0; mtp->mt_free = 0; mtp->mt_failures = 0; + mtp->mt_sleeps = 0; mtp->mt_zonefree = 0; mtp->mt_kegfree = 0; @@ -304,6 +305,13 @@ return (mtp->mt_failures); } +uint64_t +memstat_get_sleeps(const struct memory_type *mtp) +{ + + return (mtp->mt_sleeps); +} + void * memstat_get_caller_pointer(const struct memory_type *mtp, int index) { Index: lib/libmemstat/memstat_internal.h =================================================================== --- lib/libmemstat/memstat_internal.h (revision 208460) +++ lib/libmemstat/memstat_internal.h (working copy) @@ -65,6 +65,7 @@ uint64_t mt_count; /* Number of current allocations. */ uint64_t mt_free; /* Number of cached free items. */ uint64_t mt_failures; /* Number of allocation failures. */ + uint64_t mt_sleeps; /* Number of allocation sleeps. */ /* * Caller-owned memory. Index: lib/libmemstat/memstat_uma.c =================================================================== --- lib/libmemstat/memstat_uma.c (revision 208460) +++ lib/libmemstat/memstat_uma.c (working copy) @@ -208,6 +208,7 @@ mtp->mt_numallocs = uthp->uth_allocs; mtp->mt_numfrees = uthp->uth_frees; mtp->mt_failures = uthp->uth_fails; + mtp->mt_sleeps = uthp->uth_sleeps; for (j = 0; j < maxcpus; j++) { upsp = (struct uma_percpu_stat *)p; @@ -402,6 +403,7 @@ mtp->mt_numallocs = uz.uz_allocs; mtp->mt_numfrees = uz.uz_frees; mtp->mt_failures = uz.uz_fails; + mtp->mt_sleeps = uz.uz_sleeps; if (kz.uk_flags & UMA_ZFLAG_INTERNAL) goto skip_percpu; for (i = 0; i < mp_maxid + 1; i++) { Index: sys/vm/uma_int.h =================================================================== --- sys/vm/uma_int.h (revision 208460) +++ sys/vm/uma_int.h (working copy) @@ -327,6 +327,7 @@ u_int64_t uz_allocs UMA_ALIGN; /* Total number of allocations */ u_int64_t uz_frees; /* Total number of frees */ u_int64_t uz_fails; /* Total number of alloc failures */ + u_int64_t uz_sleeps; /* Total number of alloc sleeps */ uint16_t uz_fills; /* Outstanding bucket fills */ uint16_t uz_count; /* Highest value ub_ptr can have */ Index: sys/vm/uma.h =================================================================== --- sys/vm/uma.h (revision 208460) +++ sys/vm/uma.h (working copy) @@ -600,7 +600,8 @@ u_int64_t uth_allocs; /* Zone: number of allocations. */ u_int64_t uth_frees; /* Zone: number of frees. */ u_int64_t uth_fails; /* Zone: number of alloc failures. */ - u_int64_t _uth_reserved1[3]; /* Reserved. */ + u_int64_t _uth_reserved1[2]; /* Reserved. */ + u_int64_t uth_sleeps; /* Zone: number of alloc sleeps. */ }; struct uma_percpu_stat { Index: sys/vm/uma_core.c =================================================================== --- sys/vm/uma_core.c (revision 208460) +++ sys/vm/uma_core.c (working copy) @@ -249,11 +249,15 @@ void uma_print_zone(uma_zone_t); void uma_print_stats(void); +static int sysctl_vm_zone(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_stats(SYSCTL_HANDLER_ARGS); SYSINIT(uma_startup3, SI_SUB_VM_CONF, SI_ORDER_SECOND, uma_startup3, NULL); +SYSCTL_OID(_vm, OID_AUTO, zone, CTLTYPE_STRING|CTLFLAG_RD, + NULL, 0, sysctl_vm_zone, "A", "Zone Info"); + SYSCTL_PROC(_vm, OID_AUTO, zone_count, CTLFLAG_RD|CTLTYPE_INT, 0, 0, sysctl_vm_zone_count, "I", "Number of UMA zones"); @@ -1398,6 +1402,7 @@ zone->uz_allocs = 0; zone->uz_frees = 0; zone->uz_fails = 0; + zone->uz_sleeps = 0; zone->uz_fills = zone->uz_count = 0; zone->uz_flags = 0; keg = arg->keg; @@ -2285,6 +2290,7 @@ */ if (full && !empty) { zone->uz_flags |= UMA_ZFLAG_FULL; + zone->uz_sleeps++; msleep(zone, zone->uz_lock, PVM, "zonelimit", hz/100); zone->uz_flags &= ~UMA_ZFLAG_FULL; continue; @@ -3084,7 +3090,6 @@ } } -#ifdef DDB /* * Generate statistics across both the zone and its per-cpu cache's. Return * desired statistics if the pointer is non-NULL for that statistic. @@ -3126,9 +3131,87 @@ if (freesp != NULL) *freesp = frees; } -#endif /* DDB */ +/* + * Sysctl handler for vm.zone + * + * stolen from vm_zone.c + */ static int +sysctl_vm_zone(SYSCTL_HANDLER_ARGS) +{ + int error, len, cnt; + const int linesize = 128; /* conservative */ + int totalfree; + char *tmpbuf, *offset; + uma_zone_t z; + uma_keg_t zk; + char *p; + int cachefree; + uma_bucket_t bucket; + u_int64_t allocs, frees; + + cnt = 0; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) + cnt++; + } + mtx_unlock(&uma_mtx); + MALLOC(tmpbuf, char *, (cnt == 0 ? 1 : cnt) * linesize, + M_TEMP, M_WAITOK); + len = snprintf(tmpbuf, linesize, + "\nITEM SIZE LIMIT USED FREE REQ FAIL SLEEP\n\n"); + if (cnt == 0) + tmpbuf[len - 1] = '\0'; + error = SYSCTL_OUT(req, tmpbuf, cnt == 0 ? len-1 : len); + if (error || cnt == 0) + goto out; + offset = tmpbuf; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) { + if (cnt == 0) /* list may have changed size */ + break; + ZONE_LOCK(z); + cachefree = 0; + if (!(zk->uk_flags & UMA_ZFLAG_INTERNAL)) { + uma_zone_sumstat(z, &cachefree, &allocs, &frees); + } else { + allocs = z->uz_allocs; + frees = z->uz_frees; + } + + LIST_FOREACH(bucket, &z->uz_full_bucket, ub_link) { + cachefree += bucket->ub_cnt; + } + totalfree = zk->uk_free + cachefree; + len = snprintf(offset, linesize, + "%-12.12s %6.6u, %6.6u, %6.6u, %6.6u, %8.8llu, %4.4lu, %4.4lu\n", + /*ITEM*/z->uz_name, /*SIZE*/zk->uk_size, + /*LIMIT*/zk->uk_maxpages * zk->uk_ipers, + /*USED*/(zk->uk_ipers * (zk->uk_pages / zk->uk_ppera)) - totalfree, + /*FREE*/totalfree, + /*REQ*/(unsigned long long)allocs, + /*FAIL*/z->uz_fails, + /*SLEEP*/z->uz_sleeps); + ZONE_UNLOCK(z); + for (p = offset + 12; p > offset && *p == ' '; --p) + /* nothing */ ; + p[1] = ':'; + cnt--; + offset += len; + } + } + mtx_unlock(&uma_mtx); + *offset++ = '\0'; + error = SYSCTL_OUT(req, tmpbuf, offset - tmpbuf); +out: + FREE(tmpbuf, M_TEMP); + return (error); +} + +static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS) { uma_keg_t kz; @@ -3232,6 +3315,7 @@ uth.uth_allocs = z->uz_allocs; uth.uth_frees = z->uz_frees; uth.uth_fails = z->uz_fails; + uth.uth_sleeps = z->uz_sleeps; if (sbuf_bcat(&sbuf, &uth, sizeof(uth)) < 0) { ZONE_UNLOCK(z); mtx_unlock(&uma_mtx); --=-j4QQ/FoprjniytAV16+J-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 09:02:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2C741065675 for ; Tue, 25 May 2010 09:02:36 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 77A9D8FC1A for ; Tue, 25 May 2010 09:02:36 +0000 (UTC) Received: by ewy1 with SMTP id 1so394104ewy.13 for ; Tue, 25 May 2010 02:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=bSttJH/j0gqezCeD74ti1BgRxEjZ9Tdeqr3CUl1nxko=; b=EUOMnZ/ZVBbJl4OPeqhaLyD84YHAVLMP9MGBnVmmKyZVjynQNlc0wecGAkuEPAWiP4 D3dUlto6pH9E20N9Ks/ll8Z9Iz9zgpPg7RyfX3Kt12Q+sEQKcz+T/IXASrbFvMk7dSks LRf1anGOLW5nnM1vPYaMjk/C/0dLK+N9OBNGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=E1sEqLRhZrvZqliFga5sU50sUy1SSyUoNV+Ah/drC+3C8chQV4h0nlXIa9OBZwyqq6 MDqSmObCYaxJUPCJL+WAY9jLwz8p1+bdnTcYjqsZVglzzNtWaQQFRp+oFQLU5fS4wXFC 4WjKCJErnFw7AU6PdQ4sEbzLQtUFeuZNs/LO4= MIME-Version: 1.0 Received: by 10.213.19.14 with SMTP id y14mr332783eba.29.1274778155298; Tue, 25 May 2010 02:02:35 -0700 (PDT) Received: by 10.213.11.2 with HTTP; Tue, 25 May 2010 02:02:35 -0700 (PDT) Date: Tue, 25 May 2010 13:02:35 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: select/poll for sockets in kernel space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 09:02:37 -0000 Hello Hackers! I'm developing a module for FreeBSD-8 and encountered the problem with polling sockets. I know that FreeBSD-8 kernel provides 3 interfaces for polling (kern/sys_generic.c): 1) kern_select 2) poll 3) selsocket I cannot use first two interfaces because I have an array of sockets (struct socket) created using socreate, i.e. I don't have file descriptors. I also cannot use selsocket because it doesn't tell me which events fired and takes only one socket (but I have an array of sockets). The problem is that the module I'm developing should work on unmodified FreeBSD-8 kernel. So I cannot just add new functionality suitable for my task in kern/sys_generic.c. I also cannot implement such functionality in the module itself because select/poll implementation is hidden and only limited number of interfaces is available to the rest of the kernel (which is generally good, but not in my case :)). Is it possible to solve my problem using existing kernel functionality? Any suggestions are welcome! Thanks in advance! P.S. I know about kqueue, but I have to use select/poll is this task. -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 11:29:20 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F407F1065672 for ; Tue, 25 May 2010 11:29:19 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 669C08FC15 for ; Tue, 25 May 2010 11:29:18 +0000 (UTC) Received: from park.js.berklix.net (p549A37B2.dip.t-dialin.net [84.154.55.178]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4PBTEUg094743 for ; Tue, 25 May 2010 11:29:17 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4PBTDlB050777 for ; Tue, 25 May 2010 13:29:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4PBSsLS049798 for ; Tue, 25 May 2010 13:29:11 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005251129.o4PBSsLS049798@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Tue, 25 May 2010 13:28:54 +0200 Sender: jhs@berklix.com Cc: Subject: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 11:29:20 -0000 Hi Hackers@ Problem: /usr/src/usr.bin/fmt/fmt.c is not 8 bit clean. (ie French or German etc text with accents in gets broken) Alternate Solutions: Solution 1: Discard "& 0x7f checks. Allow pretty much all 8 bit as a printable. This would need some patching. It might freak out some from the English speaking world ? ( We should also consider whether other tools like cat sed awk grep etc are 8 bit clean ? ) Solution 2: Apply my patches. They work for English German & French German for 9 years, French added yesterday (maybe I missed an accent ?). If we extended for more languages, would we regret not choosing Solution 1 ? http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/fmt/ Links for all releases from 4.10 to 8.0, reduce to just 4 files: Jul 26 2001 ./fmt.1.REL=ALL.diff Nov 9 2004 ./fmt.c.tail.diff.REL=4.10-RELEASE.diff May 25 00:20 ./fmt.c.tail.diff.REL=5.3-RELEASE.diff May 25 02:35 ./fmt.c.top.diff.REL=ALL.diff Solution 3: Import a single Locale ? Inadequate, Would fail to support multiple font sets simunltaneously. Example: Pasting notes into an xterm, clauses from http://seafrance.com in English then French original & German, to get the feel of what an unclear English translation really meant on booking amendment fees) Solution 4: Support Multiple Fonts simultaneously How ? Solution 1 or 2 ? or use wchar ? Isocode ? ... Or ? A non native English speaker, best to do this I guess. Not me: I am English; My patches work for me. I don't want to work more to support fonts I dislike (Before FreeBSD started I already listed 3 different incompatible German umlaut representations, & had developed Russian fonts for SCO, & now with BSD use groff & HTML font escapes, & for decades I've experienced regular change of German & English & American keyboards eg at customer sites, when all I (English) want is Ascii & BIOS conformant American), national accent fonts etc I don't enjoy) PS I'll be off line soon, won't see replies for a while, please discuss/ improve/ send-pr/ commit/ whatever in my absence :-). Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 12:30:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE5161065674 for ; Tue, 25 May 2010 12:30:03 +0000 (UTC) (envelope-from rpaulo@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 790388FC1F for ; Tue, 25 May 2010 12:30:03 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 4FB3811B8F2; Tue, 25 May 2010 06:57:11 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id NFCY2LTT3GHW; Tue, 25 May 2010 06:57:11 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=hPnx6B4FB3xO8OkeUlvg8IKAYa+3vztxJEcTKE4O4ZsGy5hMGBEJHOw9+qfGkZoJ0zdssedS7kVRJWcufAH3czUr7TLyUYHlz1FaV/NBZ5wyutOxJD7H9/xh/xxxYrvMX82AxBdwDd8LzXaCQYZ4T/yFIC0NSlt8c6GkPxTJdqE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4BF7CDC3.8050908@bsdforen.de> Date: Tue, 25 May 2010 12:57:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95EA8683-E0AD-48DF-9148-8DE3E368F26C@lavabit.com> References: <4BF7C455.6040806@bsdforen.de> <4BF7CDC3.8050908@bsdforen.de> To: Dominic Fandrey X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Tue, 25 May 2010 13:03:10 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Activate PCIe slot deactivated by BIOS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 12:30:04 -0000 On 22 May 2010, at 13:27, Dominic Fandrey wrote: > On 22/05/2010 13:47, Dominic Fandrey wrote: >> Today the card arrived and the BIOS complains (HP 6510b): >> 104-Unsupported wireless network device detected. >> System halted. Remove device and restart. >>=20 >> The system boots if I turn off the wireless device in BIOS, but >> this means I cannot use it. >>=20 >> Now, I could just get a BIOS image and exchange the device IDs >> there. But I wonder, wouldn't it be easier to just reactivate the >> PCIe slot through the OS? >=20 > This e-mail is written through the ath wireless I got: >=20 > # ifconfig > ath0: flags=3D8843 metric 0 = mtu 2290 > ether 00:24:2c:1d:f0:2f > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ... > wlan0: flags=3D8843 metric 0 = mtu 1500 > ether 00:24:2c:1d:f0:2f > inet 192.168.178.41 netmask 0xffffff00 broadcast 192.168.178.255 > media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g > status: associated > ssid "Obi-Wan Kenobi" channel 7 (2442 MHz 11g) bssid = 00:15:0c:d5:37:a0 > regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON > deftxkey UNDEF AES-CCM 2:128-bit txpower 20 bmiss 7 scanvalid = 450 > bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 > protmode CTS wme burst roaming MANUAL >=20 > I achieved this by passing the BIOS check with the intel wireless and > hot-swapping it with the atheros card afterwards. This is impractical > and evil, so I'm still searching for a solution. >=20 > But at least I know that the device works. HP laptops really dislike the fact that your card isn't part of the = Centrino brand, so they halt if they find an Atheros. Your best option = is to change the Atheros card EEPROM to match the device and vendor id = of your wpi card. Then you also need to change the ath driver to attach = to that device id. It's evil, but it's better than hot-swapping. The other option is to buy a iwn card which works better in FreeBSD than = wpi. Regards, -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 14:01:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03B97106564A for ; Tue, 25 May 2010 14:01:41 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id A31898FC14 for ; Tue, 25 May 2010 14:01:40 +0000 (UTC) Received: by qyk11 with SMTP id 11so7712081qyk.13 for ; Tue, 25 May 2010 07:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type; bh=W0ny1aL99FV0KW4NR6ONLBAkGrZgN1xXHMFgGmAaioY=; b=iJVaSPKNcNHSBWRMT22pqzvsO6BpAzcz+hrI9YqyRh2c58I9GF06ebejEhn+7HMn4d oOgKPhJfeMM/c495QOehAKL1ZA1//HZaCfOhAZaKGIfCuVKpLZjnRvn3JuxrFnMugFs3 bjuEfIEKCRbAyBbLVNLP6bMIpovsu0j4EJ6UQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type; b=UBNd3QMro6ZPna3sYWuCoiz9sHzSXVfJZtTBg/r3BYi2OBKV1GOPa1tWwWhXSYSwc5 D5sLE+VmzqPo4tQuBK9o9KH/FsuyCVWbFhcvUibfqxY4uHH9qiLzBrFsV941nTaUkoq8 ltTWQqL3jUcAyuM8FzINfIwhXN64SnaRbuiP4= Received: by 10.224.44.210 with SMTP id b18mr3866162qaf.351.1274796092538; Tue, 25 May 2010 07:01:32 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-40-41.dsl.klmzmi.sbcglobal.net [99.19.40.41]) by mx.google.com with ESMTPS id x34sm1243052qce.3.2010.05.25.07.01.29 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 07:01:29 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BFBD838.40208@dataix.net> Date: Tue, 25 May 2010 10:01:28 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: sbruno@freebsd.org References: <1274739973.31299.23.camel@localhost.localdomain> In-Reply-To: <1274739973.31299.23.camel@localhost.localdomain> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: multipart/mixed; boundary="------------070908020201070608080903" Cc: freebsd-hackers , Sean Bruno Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 14:01:41 -0000 This is a multi-part message in MIME format. --------------070908020201070608080903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/24/2010 18:26, Sean Bruno wrote: > Find attached a patch against -CURRENT. > > This update exposes a counter that indicates the number of times that we > sleep when attempting to allocate a slab from the keg. In other words, > the number of times we BLOCK and wait, which is bad. > > This allows differentiation between times when we failed to allocate and > it was ok and times where we were forced to sleep. The current FAIL > counter does not make this distinction. > > Exposes this information via uma_zone_t->uz_sleeps. > > Add a new sysctl to retrieve this information. > Enhance vmstat -z to retrieve this information. > > We've found this *extremely* useful here at Yahoo in the past and would > like to commit this if it is acceptable. > > Tested on 32bit and 64bit architectures on 6/7/CURRENT. > Hi Sean, Nice work on this. I applied this to stable/8 r208530 and I am in the process of compiling the kernel right now. Everything else has built & runs as expected "i386". Attached is the adjusted patch which was one modification to the line number for uz_sleeps in sys/vm/uma_int.h. 8 files changed, 106 insertions(+), 7 deletions(-) For those wishing to apply this patch and test for them self: cd /usr/src patch mt_count = 0; mtp->mt_free = 0; mtp->mt_failures = 0; + mtp->mt_sleeps = 0; mtp->mt_zonefree = 0; mtp->mt_kegfree = 0; @@ -304,6 +305,13 @@ return (mtp->mt_failures); } +uint64_t +memstat_get_sleeps(const struct memory_type *mtp) +{ + + return (mtp->mt_sleeps); +} + void * memstat_get_caller_pointer(const struct memory_type *mtp, int index) { Index: lib/libmemstat/memstat_internal.h =================================================================== --- lib/libmemstat/memstat_internal.h (revision 208530) +++ lib/libmemstat/memstat_internal.h (working copy) @@ -65,6 +65,7 @@ uint64_t mt_count; /* Number of current allocations. */ uint64_t mt_free; /* Number of cached free items. */ uint64_t mt_failures; /* Number of allocation failures. */ + uint64_t mt_sleeps; /* Number of allocation sleeps. */ /* * Caller-owned memory. Index: lib/libmemstat/memstat_uma.c =================================================================== --- lib/libmemstat/memstat_uma.c (revision 208530) +++ lib/libmemstat/memstat_uma.c (working copy) @@ -208,6 +208,7 @@ mtp->mt_numallocs = uthp->uth_allocs; mtp->mt_numfrees = uthp->uth_frees; mtp->mt_failures = uthp->uth_fails; + mtp->mt_sleeps = uthp->uth_sleeps; for (j = 0; j < maxcpus; j++) { upsp = (struct uma_percpu_stat *)p; @@ -402,6 +403,7 @@ mtp->mt_numallocs = uz.uz_allocs; mtp->mt_numfrees = uz.uz_frees; mtp->mt_failures = uz.uz_fails; + mtp->mt_sleeps = uz.uz_sleeps; if (kz.uk_flags & UMA_ZFLAG_INTERNAL) goto skip_percpu; for (i = 0; i < mp_maxid + 1; i++) { Index: sys/vm/uma_int.h =================================================================== --- sys/vm/uma_int.h (revision 208530) +++ sys/vm/uma_int.h (working copy) @@ -315,6 +315,7 @@ u_int64_t uz_allocs; /* Total number of allocations */ u_int64_t uz_frees; /* Total number of frees */ u_int64_t uz_fails; /* Total number of alloc failures */ + u_int64_t uz_sleeps; /* Total number of alloc sleeps */ u_int32_t uz_flags; /* Flags inherited from kegs */ u_int32_t uz_size; /* Size inherited from kegs */ uint16_t uz_fills; /* Outstanding bucket fills */ Index: sys/vm/uma.h =================================================================== --- sys/vm/uma.h (revision 208530) +++ sys/vm/uma.h (working copy) @@ -600,7 +600,8 @@ u_int64_t uth_allocs; /* Zone: number of allocations. */ u_int64_t uth_frees; /* Zone: number of frees. */ u_int64_t uth_fails; /* Zone: number of alloc failures. */ - u_int64_t _uth_reserved1[3]; /* Reserved. */ + u_int64_t _uth_reserved1[2]; /* Reserved. */ + u_int64_t uth_sleeps; /* Zone: number of alloc sleeps. */ }; struct uma_percpu_stat { Index: sys/vm/uma_core.c =================================================================== --- sys/vm/uma_core.c (revision 208530) +++ sys/vm/uma_core.c (working copy) @@ -249,11 +249,15 @@ void uma_print_zone(uma_zone_t); void uma_print_stats(void); +static int sysctl_vm_zone(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_stats(SYSCTL_HANDLER_ARGS); SYSINIT(uma_startup3, SI_SUB_VM_CONF, SI_ORDER_SECOND, uma_startup3, NULL); +SYSCTL_OID(_vm, OID_AUTO, zone, CTLTYPE_STRING|CTLFLAG_RD, + NULL, 0, sysctl_vm_zone, "A", "Zone Info"); + SYSCTL_PROC(_vm, OID_AUTO, zone_count, CTLFLAG_RD|CTLTYPE_INT, 0, 0, sysctl_vm_zone_count, "I", "Number of UMA zones"); @@ -1400,6 +1404,7 @@ zone->uz_allocs = 0; zone->uz_frees = 0; zone->uz_fails = 0; + zone->uz_sleeps = 0; zone->uz_fills = zone->uz_count = 0; zone->uz_flags = 0; keg = arg->keg; @@ -2287,6 +2292,7 @@ */ if (full && !empty) { zone->uz_flags |= UMA_ZFLAG_FULL; + zone->uz_sleeps++; msleep(zone, zone->uz_lock, PVM, "zonelimit", hz/100); zone->uz_flags &= ~UMA_ZFLAG_FULL; continue; @@ -3088,7 +3094,6 @@ } } -#ifdef DDB /* * Generate statistics across both the zone and its per-cpu cache's. Return * desired statistics if the pointer is non-NULL for that statistic. @@ -3130,7 +3135,85 @@ if (freesp != NULL) *freesp = frees; } -#endif /* DDB */ + +/* + * Sysctl handler for vm.zone + * + * stolen from vm_zone.c + */ +static int +sysctl_vm_zone(SYSCTL_HANDLER_ARGS) +{ + int error, len, cnt; + const int linesize = 128; /* conservative */ + int totalfree; + char *tmpbuf, *offset; + uma_zone_t z; + uma_keg_t zk; + char *p; + int cachefree; + uma_bucket_t bucket; + u_int64_t allocs, frees; + + cnt = 0; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) + cnt++; + } + mtx_unlock(&uma_mtx); + MALLOC(tmpbuf, char *, (cnt == 0 ? 1 : cnt) * linesize, + M_TEMP, M_WAITOK); + len = snprintf(tmpbuf, linesize, + "\nITEM SIZE LIMIT USED FREE REQ FAIL SLEEP\n\n"); + if (cnt == 0) + tmpbuf[len - 1] = '\0'; + error = SYSCTL_OUT(req, tmpbuf, cnt == 0 ? len-1 : len); + if (error || cnt == 0) + goto out; + offset = tmpbuf; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) { + if (cnt == 0) /* list may have changed size */ + break; + ZONE_LOCK(z); + cachefree = 0; + if (!(zk->uk_flags & UMA_ZFLAG_INTERNAL)) { + uma_zone_sumstat(z, &cachefree, &allocs, &frees); + } else { + allocs = z->uz_allocs; + frees = z->uz_frees; + } + + LIST_FOREACH(bucket, &z->uz_full_bucket, ub_link) { + cachefree += bucket->ub_cnt; + } + totalfree = zk->uk_free + cachefree; + len = snprintf(offset, linesize, + "%-12.12s %6.6u, %6.6u, %6.6u, %6.6u, %8.8llu, %4.4lu, %4.4lu\n", + /*ITEM*/z->uz_name, /*SIZE*/zk->uk_size, + /*LIMIT*/zk->uk_maxpages * zk->uk_ipers, + /*USED*/(zk->uk_ipers * (zk->uk_pages / zk->uk_ppera)) - totalfree, + /*FREE*/totalfree, + /*REQ*/(unsigned long long)allocs, + /*FAIL*/z->uz_fails, + /*SLEEP*/z->uz_sleeps); + ZONE_UNLOCK(z); + for (p = offset + 12; p > offset && *p == ' '; --p) + /* nothing */ ; + p[1] = ':'; + cnt--; + offset += len; + } + } + mtx_unlock(&uma_mtx); + *offset++ = '\0'; + error = SYSCTL_OUT(req, tmpbuf, offset - tmpbuf); +out: + FREE(tmpbuf, M_TEMP); + return (error); +} static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS) @@ -3236,6 +3319,7 @@ uth.uth_allocs = z->uz_allocs; uth.uth_frees = z->uz_frees; uth.uth_fails = z->uz_fails; + uth.uth_sleeps = z->uz_sleeps; if (sbuf_bcat(&sbuf, &uth, sizeof(uth)) < 0) { ZONE_UNLOCK(z); mtx_unlock(&uma_mtx); --------------070908020201070608080903 Content-Type: application/octet-stream; name="sleep_stat_stable8_r208530.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sleep_stat_stable8_r208530.diff.sig" iQEcBAABAgAGBQJL+9g3AAoJEJBXh4mJ2FR+2F8H/R5OVSvxtO1aaGF4aZ5775Jb8SA1VaII h814V8oTMbvzhHx2rr5z5aPWFPes6OHL8WwZuY9BY4kwQ+KTyijJQRGpgm7keRlMBoJNcsAF QIWHkbKFxgRTpBcEwXcfagnltEPXsdkdIB0pktIQTZkKBbxfXPLIQuv91b8ij+rssv63VyFb yherZQmC6bEnkwtZ8+6q1x6S+RgzqSr/wXCyQVWhejCAhX320nCgtiScMfon+fDF4+tzawZq fw5Fi+NUx8yyFRAMTWvwu0PSPUyyK60b6F6DhKG1hcYOrTk+qFvkSNXeBrQcVBXIlgJKUh8m 9jjBz3CDTOKDdrZSmapDs54= --------------070908020201070608080903-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 14:50:19 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2747106566C for ; Tue, 25 May 2010 14:50:19 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9118FC14 for ; Tue, 25 May 2010 14:50:18 +0000 (UTC) Received: from park.js.berklix.net (p549A37B2.dip.t-dialin.net [84.154.55.178]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4PEoEne097402; Tue, 25 May 2010 14:50:15 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4PEoJbu071241; Tue, 25 May 2010 16:50:19 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4PEo9tF099503; Tue, 25 May 2010 16:50:14 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005251450.o4PEo9tF099503@fire.js.berklix.net> To: Ben Fiedler From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 24 May 2010 00:08:30 PDT." Date: Tue, 25 May 2010 16:50:09 +0200 Sender: jhs@berklix.com Cc: hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 14:50:19 -0000 > I'll be working on replacing groff with mdocml (mandoc) in the system base No. Do not remove groff or associated tools from /usr/src ! Roff has been in Unix /usr/src since '77 or earlier. A lot of people use tools from that descendancy as production tools. However if you just mean "I'll be working on getting man to call XYZ rather than groff" then I have no comment. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 15:07:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C44C3106564A for ; Tue, 25 May 2010 15:07:03 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5AC8FC15 for ; Tue, 25 May 2010 15:07:02 +0000 (UTC) Received: from park.js.berklix.net (p549A37B2.dip.t-dialin.net [84.154.55.178]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4PF6xSA097547 for ; Tue, 25 May 2010 15:07:00 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4PF73nA071299 for ; Tue, 25 May 2010 17:07:03 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4PF6wLX099679 for ; Tue, 25 May 2010 17:07:03 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005251507.o4PF6wLX099679@fire.js.berklix.net> To: freebsd-hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 24 May 2010 21:17:01 +0200." <20100524191701.GA29256@britannica.bec.de> Date: Tue, 25 May 2010 17:06:58 +0200 Sender: jhs@berklix.com Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:07:03 -0000 Joerg Sonnenberger wrote: > The use of (g)roff for anything but man pages is practically non-existent. False. Its a production tool used here. http://berklix.com./associates/ http://www.berklix.com/~jhs/cv/#card ( Try .PS card back X3 size All business letters, bills, business cards, ID cards, cdrom labels here use groff. There's guys recently wrote me from Germany developing groff macros for .de iso standard business letters to the new standard. Charlie Kester wrote > Yes, I understand that troff-style typesetting has mostly been abandoned > in favor of WYSIWYG editing. My patches for FreeBSD groff, ghostview etc, with wysiwyg published on the web & running fine for maybe 10 years. Share & enjoy. Each time I hit :w in my xterm editing [groff], the adjacent ghostview (or chimera) redisplays http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/wysiwyg.shar.asc Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 15:18:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ADCF106567D for ; Tue, 25 May 2010 15:18:41 +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 6C16F8FC13 for ; Tue, 25 May 2010 15:18:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0A0D446B92; Tue, 25 May 2010 11:18:41 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 810008A01F; Tue, 25 May 2010 11:18:39 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 25 May 2010 08:55:57 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005250855.57770.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 25 May 2010 11:18:39 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dmitry Krivenok Subject: Re: select/poll for sockets in kernel space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:18:41 -0000 On Tuesday 25 May 2010 5:02:35 am Dmitry Krivenok wrote: > Hello Hackers! > > I'm developing a module for FreeBSD-8 and encountered the problem with > polling sockets. > I know that FreeBSD-8 kernel provides 3 interfaces for polling > (kern/sys_generic.c): > 1) kern_select > 2) poll > 3) selsocket > > I cannot use first two interfaces because I have an array of sockets > (struct socket) created using socreate, i.e. I don't have file > descriptors. > I also cannot use selsocket because it doesn't tell me which events > fired and takes only one socket (but I have an array of sockets). > > The problem is that the module I'm developing should work on > unmodified FreeBSD-8 kernel. > So I cannot just add new functionality suitable for my task in > kern/sys_generic.c. > I also cannot implement such functionality in the module itself > because select/poll implementation is hidden and only limited number > of interfaces is available to the rest > of the kernel (which is generally good, but not in my case :)). > > Is it possible to solve my problem using existing kernel functionality? > Any suggestions are welcome! > > Thanks in advance! > > P.S. > I know about kqueue, but I have to use select/poll is this task. Why do you have to use select/poll? If these are dedicated sockets that you create internally, then the right thing to do is probably to install your own upcalls that get called when data for a socket arrives. This is what the in- kernel NFS client does to handle incoming data. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 15:26:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C7251065670 for ; Tue, 25 May 2010 15:26:09 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.sonnenberger.org [92.79.50.50]) by mx1.freebsd.org (Postfix) with ESMTP id BFF878FC16 for ; Tue, 25 May 2010 15:26:08 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 30B876674D for ; Tue, 25 May 2010 17:26:06 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 3B7BB1506D; Tue, 25 May 2010 17:23:56 +0200 (CEST) Date: Tue, 25 May 2010 17:23:56 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20100525152356.GA1466@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20100524191701.GA29256@britannica.bec.de> <201005251507.o4PF6wLX099679@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005251507.o4PF6wLX099679@fire.js.berklix.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:26:09 -0000 On Tue, May 25, 2010 at 05:06:58PM +0200, Julian H. Stacey wrote: > Joerg Sonnenberger wrote: > > > The use of (g)roff for anything but man pages is practically non-existent. > > False. Its a production tool used here. > http://berklix.com./associates/ > http://www.berklix.com/~jhs/cv/#card ( Try .PS card back X3 size > All business letters, bills, business cards, ID cards, > cdrom labels here use groff. > > There's guys recently wrote me from Germany developing groff macros > for .de iso standard business letters to the new standard. ...and this are located in the source tree where exactly? Noone prevents you from installing groff or heirloom troff and using it. Pointing to the odd case of users (still) depending on it for typical needs is IMO more a confirmation of what I said and not really in disagreement. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 15:33:39 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 373171065673 for ; Tue, 25 May 2010 15:33:39 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CF24D8FC13 for ; Tue, 25 May 2010 15:33:38 +0000 (UTC) Received: by iwn5 with SMTP id 5so5402286iwn.13 for ; Tue, 25 May 2010 08:33:37 -0700 (PDT) Received: by 10.231.174.130 with SMTP id t2mr6801111ibz.50.1274801617296; Tue, 25 May 2010 08:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.148.136 with HTTP; Tue, 25 May 2010 08:33:17 -0700 (PDT) In-Reply-To: <201005251450.o4PEo9tF099503@fire.js.berklix.net> References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> From: Eitan Adler Date: Tue, 25 May 2010 18:33:17 +0300 Message-ID: To: "Julian H. Stacey" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ben Fiedler , hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:33:39 -0000 > No. Do not remove groff or associated tools from /usr/src ! > Roff has been in Unix /usr/src since '77 or earlier. > A lot of people use tools from that descendancy as production tools. So? If it isn't a very commonly used tool and isn't necessary for 99% of cases I don't seem the harm of removing it from base and making it a port? > > However if you just mean > =C2=A0 =C2=A0 =C2=A0 =C2=A0"I'll be working on getting man to call XYZ ra= ther than groff" > then I have no comment. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 14:51:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20E42106566C; Tue, 25 May 2010 14:51:35 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 08A708FC08; Tue, 25 May 2010 14:51:34 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4PEpDW0069509; Tue, 25 May 2010 07:51:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=CntE1C3e5/4YaGmk1Nd7Begv1We7wtKytnsJjrjKJjm+rASs+PETBrUWxUsF84W6 From: Sean Bruno To: jhell In-Reply-To: <4BFBD838.40208@dataix.net> References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 25 May 2010 07:47:32 -0700 Message-ID: <1274798852.4715.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 25 May 2010 15:52:24 +0000 Cc: freebsd-hackers , "sbruno@freebsd.org" Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 14:51:35 -0000 > Hi Sean, > > Nice work on this. I applied this to stable/8 r208530 and I am in the > process of compiling the kernel right now. Everything else has built & > runs as expected "i386". Attached is the adjusted patch which was one > modification to the line number for uz_sleeps in sys/vm/uma_int.h. > > 8 files changed, 106 insertions(+), 7 deletions(-) > > For those wishing to apply this patch and test for them self: > > cd /usr/src > patch cd /usr/src/include > make obj && make depend && make includes && make install > cd /usr/src/lib/libmemstat > make obj && make depend && make includes && make install > cd /usr/src/usr.bin/vmstat > make obj && make depend && make install > cd /usr/src > make kernel KERNCONF=YOUR_KERN_CONF > reboot > > Can't wait to see some results from this & I will report back with > either negative results of the build & run or positive results from the > stats collected. > > If there is anything needed feel free to let me know and I will do what > is possible ASAP. > > Thanks again, > > - -- > > jhell Excellent. Please check the output of vmstat -z and the appropriate sysctl. I changed the display a bit to keep it from wrapping on a standard terminal. Sean P.S. My intention it to MFC this to all releases. From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 16:41:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D8F91065674; Tue, 25 May 2010 16:41:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outj.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6138FC15; Tue, 25 May 2010 16:41:07 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o4PGf5NL007196; Tue, 25 May 2010 09:41:05 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id CDAFB2D6012; Tue, 25 May 2010 09:41:04 -0700 (PDT) Message-ID: <4BFBFDAB.9000106@elischer.org> Date: Tue, 25 May 2010 09:41:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dmitry Krivenok References: <201005250855.57770.jhb@freebsd.org> In-Reply-To: <201005250855.57770.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org Subject: Re: select/poll for sockets in kernel space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 16:41:07 -0000 On 5/25/10 5:55 AM, John Baldwin wrote: > On Tuesday 25 May 2010 5:02:35 am Dmitry Krivenok wrote: >> Hello Hackers! >> >> I'm developing a module for FreeBSD-8 and encountered the problem with >> polling sockets. [...] >> >> Thanks in advance! >> >> P.S. >> I know about kqueue, but I have to use select/poll is this task. > > Why do you have to use select/poll? If these are dedicated sockets that you > create internally, then the right thing to do is probably to install your own > upcalls that get called when data for a socket arrives. This is what the in- > kernel NFS client does to handle incoming data. It's also what netgraph does. An incoming packet is sent to the ksocket node and immediately passed to whatever node is attached to the ksocket node. If your project is of high throughput requirement, then you might look ad duplicating what it does (in /sys/netgraph/ng_ksocket.c), or alternatively, if your project is of medium throughput, (or lower) you might consider simply implementing it as a netgraph node and make use of the configuration framework etc. that already exists, and actually use a netgraph ksocket node to do the work for you. > From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 16:45:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35DEA106567D for ; Tue, 25 May 2010 16:45:32 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 96CA58FC08 for ; Tue, 25 May 2010 16:45:31 +0000 (UTC) Received: from park.js.berklix.net (p549A37B2.dip.t-dialin.net [84.154.55.178]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4PGjTYp098795 for ; Tue, 25 May 2010 16:45:30 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4PGjZIE077628 for ; Tue, 25 May 2010 18:45:35 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4PGjUlf001807 for ; Tue, 25 May 2010 18:45:35 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005251645.o4PGjUlf001807@fire.js.berklix.net> To: freebsd-hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 25 May 2010 17:23:56 +0200." <20100525152356.GA1466@britannica.bec.de> Date: Tue, 25 May 2010 18:45:30 +0200 Sender: jhs@berklix.com Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 16:45:32 -0000 Re. half baked proposal to delete groff: If you want to play, play with Linux, which has no tradition of what to expect. BSD by contrast is real Unix, those who've been in Unix business a few decades you know what real Unix is. More than just the toolchain to support make world. Look at Bell blue & yellow book & see a few tools there. Remember "least suprise". There's businesses use BSD as Unix, & like the Unix stability, If they wanted to play with trendy changing functionality they'd run Linux. Business users dont always monitor these lists though to protest every half baked idea though before its implemented. so for some ideas, there may be more young keen developers, who don't value stability, compared to the user base. Just because more may speak for an idea on list than against, doesn't mean it sensible. Dont ignore the user base, wider than the developer base, it creates users & BSD jobs too. Typicaly, it's not cost effective for me to argue more, maybe some who would delete groff have copious idle time, but I have to rush to travel to write & file a computer company annual report. ie Yes I've been in the business a few decades, & know what to expect of Unix. It includes not only [g]roff but other tools I would also not propose to chuck out, even if neither you nor I used them. PS For lateral business thinking, look up the history of Mr Beaching & how he continualy pruned the ends of British railway lines that were little used, till he killed good lines in the end. Now think of station groff on the end of a line, & you propose to close it, & tell users: Trans ship to the ports canal. Sigh ! Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 16:52:31 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FBB6106564A for ; Tue, 25 May 2010 16:52:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outj.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id E2F2D8FC0A for ; Tue, 25 May 2010 16:52:30 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o4PGqLEC007480; Tue, 25 May 2010 09:52:21 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 368D42D6018; Tue, 25 May 2010 09:52:20 -0700 (PDT) Message-ID: <4BFC004F.1090101@elischer.org> Date: Tue, 25 May 2010 09:52:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eitan Adler References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Ben Fiedler , "Julian H. Stacey" , hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 16:52:31 -0000 On 5/25/10 8:33 AM, Eitan Adler wrote: >> No. Do not remove groff or associated tools from /usr/src ! >> Roff has been in Unix /usr/src since '77 or earlier. >> A lot of people use tools from that descendancy as production tools. > > So? If it isn't a very commonly used tool and isn't necessary for 99% > of cases I don't seem the harm of removing it from base and making it > a port? BSD has always been ab;e to produce it's documentation as part of its build Please keep this true. > >> >> However if you just mean >> "I'll be working on getting man to call XYZ rather than groff" >> then I have no comment. > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 16:55:19 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AEC610656F3 for ; Tue, 25 May 2010 16:55:19 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 02F248FC17 for ; Tue, 25 May 2010 16:55:18 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o4PGt7DJ070816 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 May 2010 09:55:18 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BFC00E7.1060307@feral.com> Date: Tue, 25 May 2010 09:55:03 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> <4BFC004F.1090101@elischer.org> In-Reply-To: <4BFC004F.1090101@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Tue, 25 May 2010 09:55:18 -0700 (PDT) Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 16:55:19 -0000 On 5/25/2010 9:52 AM, Julian Elischer wrote: > On 5/25/10 8:33 AM, Eitan Adler wrote: >>> No. Do not remove groff or associated tools from /usr/src ! >>> Roff has been in Unix /usr/src since '77 or earlier. >>> A lot of people use tools from that descendancy as production tools. >> >> So? If it isn't a very commonly used tool and isn't necessary for 99% >> of cases I don't seem the harm of removing it from base and making it >> a port? > > BSD has always been ab;e to produce it's documentation as part of its > build > > Please keep this true. Absolutely. There are tons of documents out there still in -ms or -mm format. From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 18:26:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 898AC1065672; Tue, 25 May 2010 18:26:44 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 205A98FC19; Tue, 25 May 2010 18:26:43 +0000 (UTC) Received: by qyk11 with SMTP id 11so8096554qyk.13 for ; Tue, 25 May 2010 11:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type; bh=fepPYhOB8YoGmeNfLUE8XSLbTlwjSfnyR6ASOnnUFyI=; b=DuJ7mR+8WbcZErYRRtkkOnUq2yfbDHUtK0R8ZCdxONG1Rfcyb3QAGtJJ3vvFCKb9M1 BFKAKM7Ff7ygEMjO78nvBwUC4UWh14M2o7ygv2/BzLk4iKoiJLvOrOcNR6MTIMDnESR3 ktpxRF3qZG6mJoeoeHbz98B8s3YaKCjTtge1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type; b=nLRoJeT9IYagsnJdO05gSuJq8wDY0Gi0Ef5EiikCKebEr4f+Koks+o6ZJRgd2wE8MF XKQ8ZMgxnjijnecvig8NXiQyp6du1YJCrUNsQlGz6cFmDtoE6zQEpAFYRXCcOlETRymq QHhOg9WaRsQN2OK6c5B3tmloRm58Bvsf+Cx0o= Received: by 10.224.63.77 with SMTP id a13mr4264705qai.267.1274812003331; Tue, 25 May 2010 11:26:43 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-40-41.dsl.klmzmi.sbcglobal.net [99.19.40.41]) by mx.google.com with ESMTPS id i10sm1350545qcb.17.2010.05.25.11.26.41 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 11:26:42 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BFC1660.1000405@dataix.net> Date: Tue, 25 May 2010 14:26:40 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: sbruno@freebsd.org References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> In-Reply-To: <4BFBD838.40208@dataix.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: multipart/mixed; boundary="------------000005030701090009030206" Cc: freebsd-hackers , Sean Bruno Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 18:26:44 -0000 This is a multi-part message in MIME format. --------------000005030701090009030206 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/25/2010 10:01, jhell wrote: > On 05/24/2010 18:26, Sean Bruno wrote: >> Find attached a patch against -CURRENT. > >> This update exposes a counter that indicates the number of times that we >> sleep when attempting to allocate a slab from the keg. In other words, >> the number of times we BLOCK and wait, which is bad. > >> This allows differentiation between times when we failed to allocate and >> it was ok and times where we were forced to sleep. The current FAIL >> counter does not make this distinction. > >> Exposes this information via uma_zone_t->uz_sleeps. > >> Add a new sysctl to retrieve this information. >> Enhance vmstat -z to retrieve this information. > >> We've found this *extremely* useful here at Yahoo in the past and would >> like to commit this if it is acceptable. > >> Tested on 32bit and 64bit architectures on 6/7/CURRENT. > > > Hi Sean, > > Nice work on this. I applied this to stable/8 r208530 and I am in the > process of compiling the kernel right now. Everything else has built & > runs as expected "i386". Attached is the adjusted patch which was one > modification to the line number for uz_sleeps in sys/vm/uma_int.h. > > 8 files changed, 106 insertions(+), 7 deletions(-) > > For those wishing to apply this patch and test for them self: > > cd /usr/src > patch cd /usr/src/include > make obj && make depend && make includes && make install > cd /usr/src/lib/libmemstat > make obj && make depend && make includes && make install > cd /usr/src/usr.bin/vmstat > make obj && make depend && make install > cd /usr/src > make kernel KERNCONF=YOUR_KERN_CONF > reboot > > Can't wait to see some results from this & I will report back with > either negative results of the build & run or positive results from the > stats collected. > > If there is anything needed feel free to let me know and I will do what > is possible ASAP. > > Thanks again, > This patch instead pardon the early.post but there was a problem with the last patch that I attached for stable/8 r208530 with arguments 10 & 11 to function sysctl_vm_zone where it wanted a long unsigned integer rather than u_int64_t. This patch satisfies that. Whether its correct is left to the reader but compiles cleanly & runs smoothly. Regards, - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJL/BZfAAoJEJBXh4mJ2FR+AqkH/2feS63nkRTGvYBNWUXMl/5t th4JJWXF0nvN5KjcLlP79mSI06Enc3W3+EFooPZyZugOKUHhM/ex14nGYjQUzA8f S3JPpLmF4Mqga1kiK55NQd+OiGtfn74qrRE8MeDR8ravcUpQjN3rbbZtoPYIMe0G lX7JVXVvmKEL5YvWULEEaU7ckVCb+fAR44t1JOEmFYI7xew7bbvdEno728ZHxO8V gt291dC+MNUqIDsj52LgEPZ4zet/CuU6MeQ7D0SJ5YUDzQ1GH8qlCJ/8jxg0c3/a IIXEmRRH494YHMQrVsrOZgho6YRs1x1B6x2Tqm8mlAqpDDAEKETlJ2CCtXvGt5M= =fd+F -----END PGP SIGNATURE----- --------------000005030701090009030206 Content-Type: text/x-patch; name="sleep_stat_stable8_r208530.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sleep_stat_stable8_r208530.diff" M usr.bin/vmstat/vmstat.c M lib/libmemstat/memstat.h M lib/libmemstat/memstat.c M lib/libmemstat/memstat_internal.h M lib/libmemstat/memstat_uma.c M sys/vm/uma_int.h M sys/vm/uma.h M sys/vm/uma_core.c Index: usr.bin/vmstat/vmstat.c =================================================================== --- usr.bin/vmstat/vmstat.c (revision 208530) +++ usr.bin/vmstat/vmstat.c (working copy) @@ -1286,16 +1286,17 @@ memstat_strerror(error)); } } - printf("%-20s %8s %8s %8s %8s %8s %8s\n\n", "ITEM", "SIZE", - "LIMIT", "USED", "FREE", "REQUESTS", "FAILURES"); + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", + "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP"); for (mtp = memstat_mtl_first(mtlp); mtp != NULL; mtp = memstat_mtl_next(mtp)) { strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME); strcat(name, ":"); - printf("%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n", name, + printf("%-20s %6llu, %6llu,%8llu,%8llu,%8llu,%4llu,%4llu\n",name, memstat_get_size(mtp), memstat_get_countlimit(mtp), memstat_get_count(mtp), memstat_get_free(mtp), - memstat_get_numallocs(mtp), memstat_get_failures(mtp)); + memstat_get_numallocs(mtp), memstat_get_failures(mtp), + memstat_get_sleeps(mtp)); } memstat_mtl_free(mtlp); printf("\n"); Index: lib/libmemstat/memstat.h =================================================================== --- lib/libmemstat/memstat.h (revision 208530) +++ lib/libmemstat/memstat.h (working copy) @@ -139,6 +139,7 @@ uint64_t memstat_get_count(const struct memory_type *mtp); uint64_t memstat_get_free(const struct memory_type *mtp); uint64_t memstat_get_failures(const struct memory_type *mtp); +uint64_t memstat_get_sleeps(const struct memory_type *mtp); void *memstat_get_caller_pointer(const struct memory_type *mtp, int index); void memstat_set_caller_pointer(struct memory_type *mtp, Index: lib/libmemstat/memstat.c =================================================================== --- lib/libmemstat/memstat.c (revision 208530) +++ lib/libmemstat/memstat.c (working copy) @@ -188,6 +188,7 @@ mtp->mt_count = 0; mtp->mt_free = 0; mtp->mt_failures = 0; + mtp->mt_sleeps = 0; mtp->mt_zonefree = 0; mtp->mt_kegfree = 0; @@ -304,6 +305,13 @@ return (mtp->mt_failures); } +uint64_t +memstat_get_sleeps(const struct memory_type *mtp) +{ + + return (mtp->mt_sleeps); +} + void * memstat_get_caller_pointer(const struct memory_type *mtp, int index) { Index: lib/libmemstat/memstat_internal.h =================================================================== --- lib/libmemstat/memstat_internal.h (revision 208530) +++ lib/libmemstat/memstat_internal.h (working copy) @@ -65,6 +65,7 @@ uint64_t mt_count; /* Number of current allocations. */ uint64_t mt_free; /* Number of cached free items. */ uint64_t mt_failures; /* Number of allocation failures. */ + uint64_t mt_sleeps; /* Number of allocation sleeps. */ /* * Caller-owned memory. Index: lib/libmemstat/memstat_uma.c =================================================================== --- lib/libmemstat/memstat_uma.c (revision 208530) +++ lib/libmemstat/memstat_uma.c (working copy) @@ -208,6 +208,7 @@ mtp->mt_numallocs = uthp->uth_allocs; mtp->mt_numfrees = uthp->uth_frees; mtp->mt_failures = uthp->uth_fails; + mtp->mt_sleeps = uthp->uth_sleeps; for (j = 0; j < maxcpus; j++) { upsp = (struct uma_percpu_stat *)p; @@ -402,6 +403,7 @@ mtp->mt_numallocs = uz.uz_allocs; mtp->mt_numfrees = uz.uz_frees; mtp->mt_failures = uz.uz_fails; + mtp->mt_sleeps = uz.uz_sleeps; if (kz.uk_flags & UMA_ZFLAG_INTERNAL) goto skip_percpu; for (i = 0; i < mp_maxid + 1; i++) { Index: sys/vm/uma_int.h =================================================================== --- sys/vm/uma_int.h (revision 208530) +++ sys/vm/uma_int.h (working copy) @@ -314,7 +314,8 @@ u_int64_t uz_allocs; /* Total number of allocations */ u_int64_t uz_frees; /* Total number of frees */ - u_int64_t uz_fails; /* Total number of alloc failures */ + long unsigned int uz_fails; /* Total number of alloc failures */ + long unsigned int uz_sleeps; /* Total number of alloc sleeps */ u_int32_t uz_flags; /* Flags inherited from kegs */ u_int32_t uz_size; /* Size inherited from kegs */ uint16_t uz_fills; /* Outstanding bucket fills */ Index: sys/vm/uma.h =================================================================== --- sys/vm/uma.h (revision 208530) +++ sys/vm/uma.h (working copy) @@ -600,7 +600,8 @@ u_int64_t uth_allocs; /* Zone: number of allocations. */ u_int64_t uth_frees; /* Zone: number of frees. */ u_int64_t uth_fails; /* Zone: number of alloc failures. */ - u_int64_t _uth_reserved1[3]; /* Reserved. */ + u_int64_t _uth_reserved1[2]; /* Reserved. */ + u_int64_t uth_sleeps; /* Zone: number of alloc sleeps. */ }; struct uma_percpu_stat { Index: sys/vm/uma_core.c =================================================================== --- sys/vm/uma_core.c (revision 208530) +++ sys/vm/uma_core.c (working copy) @@ -249,11 +249,15 @@ void uma_print_zone(uma_zone_t); void uma_print_stats(void); +static int sysctl_vm_zone(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_stats(SYSCTL_HANDLER_ARGS); SYSINIT(uma_startup3, SI_SUB_VM_CONF, SI_ORDER_SECOND, uma_startup3, NULL); +SYSCTL_OID(_vm, OID_AUTO, zone, CTLTYPE_STRING|CTLFLAG_RD, + NULL, 0, sysctl_vm_zone, "A", "Zone Info"); + SYSCTL_PROC(_vm, OID_AUTO, zone_count, CTLFLAG_RD|CTLTYPE_INT, 0, 0, sysctl_vm_zone_count, "I", "Number of UMA zones"); @@ -1400,6 +1404,7 @@ zone->uz_allocs = 0; zone->uz_frees = 0; zone->uz_fails = 0; + zone->uz_sleeps = 0; zone->uz_fills = zone->uz_count = 0; zone->uz_flags = 0; keg = arg->keg; @@ -2287,6 +2292,7 @@ */ if (full && !empty) { zone->uz_flags |= UMA_ZFLAG_FULL; + zone->uz_sleeps++; msleep(zone, zone->uz_lock, PVM, "zonelimit", hz/100); zone->uz_flags &= ~UMA_ZFLAG_FULL; continue; @@ -3088,7 +3094,6 @@ } } -#ifdef DDB /* * Generate statistics across both the zone and its per-cpu cache's. Return * desired statistics if the pointer is non-NULL for that statistic. @@ -3130,7 +3135,85 @@ if (freesp != NULL) *freesp = frees; } -#endif /* DDB */ + +/* + * Sysctl handler for vm.zone + * + * stolen from vm_zone.c + */ +static int +sysctl_vm_zone(SYSCTL_HANDLER_ARGS) +{ + int error, len, cnt; + const int linesize = 128; /* conservative */ + int totalfree; + char *tmpbuf, *offset; + uma_zone_t z; + uma_keg_t zk; + char *p; + int cachefree; + uma_bucket_t bucket; + u_int64_t allocs, frees; + + cnt = 0; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) + cnt++; + } + mtx_unlock(&uma_mtx); + MALLOC(tmpbuf, char *, (cnt == 0 ? 1 : cnt) * linesize, + M_TEMP, M_WAITOK); + len = snprintf(tmpbuf, linesize, + "\nITEM SIZE LIMIT USED FREE REQ FAIL SLEEP\n\n"); + if (cnt == 0) + tmpbuf[len - 1] = '\0'; + error = SYSCTL_OUT(req, tmpbuf, cnt == 0 ? len-1 : len); + if (error || cnt == 0) + goto out; + offset = tmpbuf; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) { + if (cnt == 0) /* list may have changed size */ + break; + ZONE_LOCK(z); + cachefree = 0; + if (!(zk->uk_flags & UMA_ZFLAG_INTERNAL)) { + uma_zone_sumstat(z, &cachefree, &allocs, &frees); + } else { + allocs = z->uz_allocs; + frees = z->uz_frees; + } + + LIST_FOREACH(bucket, &z->uz_full_bucket, ub_link) { + cachefree += bucket->ub_cnt; + } + totalfree = zk->uk_free + cachefree; + len = snprintf(offset, linesize, + "%-12.12s %6.6u, %6.6u, %6.6u, %6.6u, %8.8llu, %4.4lu, %4.4lu\n", + /*ITEM*/z->uz_name, /*SIZE*/zk->uk_size, + /*LIMIT*/zk->uk_maxpages * zk->uk_ipers, + /*USED*/(zk->uk_ipers * (zk->uk_pages / zk->uk_ppera)) - totalfree, + /*FREE*/totalfree, + /*REQ*/(unsigned long long)allocs, + /*FAIL*/z->uz_fails, + /*SLEEP*/z->uz_sleeps); + ZONE_UNLOCK(z); + for (p = offset + 12; p > offset && *p == ' '; --p) + /* nothing */ ; + p[1] = ':'; + cnt--; + offset += len; + } + } + mtx_unlock(&uma_mtx); + *offset++ = '\0'; + error = SYSCTL_OUT(req, tmpbuf, offset - tmpbuf); +out: + FREE(tmpbuf, M_TEMP); + return (error); +} static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS) @@ -3236,6 +3319,7 @@ uth.uth_allocs = z->uz_allocs; uth.uth_frees = z->uz_frees; uth.uth_fails = z->uz_fails; + uth.uth_sleeps = z->uz_sleeps; if (sbuf_bcat(&sbuf, &uth, sizeof(uth)) < 0) { ZONE_UNLOCK(z); mtx_unlock(&uma_mtx); --------------000005030701090009030206 Content-Type: application/octet-stream; name="sleep_stat_stable8_r208530.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sleep_stat_stable8_r208530.diff.sig" iQEcBAABAgAGBQJL/BZfAAoJEJBXh4mJ2FR+nokH/A6sPbMDluImiQSZnJdhzuPXabr/QmaX vKuu7E3h7amoKKdsjRoY1dzGvXp5wx8+yBFe+DkagcPvbsOat/SMv1OLkJZXfxVWuXEXv5mH VT7c+ou6QdMDpSxLHxhh9VUlT3DSu7wyLxgUD6gFpzYDicEEcuIL2+X9ustZCpJXnBULAyOJ yj1mH8As27IVfRX1ujvboCSHnrk3Q/cEjnfuQcA2kyNNV6H9uc9Cu8WR1bkdSlZZWrmlXRkr Ai3ush4J5mVDa311k6N7zmaX0186tcPfnLzd5jM9wjp42DZTeoZnM6laoTk5GsHGIqmQ+kfN 08yQpyd87DexDJiOmyQkPow= --------------000005030701090009030206-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 19:05:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DBD31065672 for ; Tue, 25 May 2010 19:05:42 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (unknown [IPv6:2001:418:3fd::3]) by mx1.freebsd.org (Postfix) with ESMTP id D2BFD8FC2C for ; Tue, 25 May 2010 19:05:41 +0000 (UTC) Received: from m5p.com (wireless.m5p.com [IPv6:2001:418:3fd::f1]) by mailhost.m5p.com (8.14.3/8.14.3) with ESMTP id o4PJ5ZUN084543 for ; Tue, 25 May 2010 15:05:40 -0400 (EDT) (envelope-from george@m5p.com) Received: (from george@localhost) by m5p.com (8.14.4/8.13.7/Submit) id o4PJ5ZnF065366; Tue, 25 May 2010 15:05:35 -0400 (EDT) Date: Tue, 25 May 2010 15:05:35 -0400 (EDT) Message-Id: <201005251905.o4PJ5ZnF065366@m5p.com> From: george+freebsd@m5p.com To: freebsd-hackers@freebsd.org X-Spam-Score: 0.63 () AWL,BAYES_00,FH_DATE_PAST_20XX,NO_RELAYS X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:418:3fd::f7 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Tue, 25 May 2010 15:05:40 -0400 (EDT) Subject: Firefox startup impacted by distributed.net client X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 19:05:42 -0000 OS: FreeBSD post 8.0-RELEASE Firefox: 3.6 Distributed.net client: v2.9103 and later When the distributed.net application is not running, Firefox will start up on my box in less than two seconds. But with the distributed.net application running, the firefox startup slows down painfully, taking no less than 20 seconds, and in extreme cases up to 90 seconds (out of which it takes 50 seconds for anything to appear on the screen at all). Once firefox is started, it runs very responsively. distributed.net application is 100% CPU bound, It takes a chunk of memory, but it runs at "nice 20" level. Between firefox and distributed.net, my system still uses 0% of its swap space according to swapinfo. During the startup period, top reports that firefox-bin is consuming an increasing amount of memory and spending a lot of time in "ucond" state. At a guess, something about the way firefox requests memory causes it to block for some period of time before it can do anything else. Has anyone else experienced this? How should I go about analyzing it? Thanks for your help. -- George Mitchell From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 20:08:26 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87EC106566C for ; Tue, 25 May 2010 20:08:26 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 70E548FC1D for ; Tue, 25 May 2010 20:08:26 +0000 (UTC) Received: by wwe15 with SMTP id 15so100775wwe.13 for ; Tue, 25 May 2010 13:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=jhJLKm0D9pH+pDm3538izZuf2BXyV+QmMwpLTbJkfJE=; b=qOSiGcdphb3iW3ji6ad4z5B6ySWnilt4aRP6GxDk12dajn2XdItF28t2QH0o1m94Q3 ddBsL+dpXEJj60WXylrPTAN2hQvnM5x3yO3ibz3XQOWV0xtvrNBmIkP71FzCX9xsRYhu g5uAFv35ZhGI1EsNSFF0a/sO1vEd/rCjgtWyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=B4i0HscC69hmbNgTjHdYrWuXi3VQPwH8GkJsbvnAcjHJRztQK/UR0TLX1SH7FawEH2 VFECSHKmXIVB6ojG9lWnHkLrBty2Lfhh9B26JdsnFmVmk9ZG47z01U5qz7TigIvigcDa d/R4u7DR77jCWuXR4CUTOekvxc1f38P9QfiXI= MIME-Version: 1.0 Received: by 10.216.93.19 with SMTP id k19mr5012514wef.223.1274818105360; Tue, 25 May 2010 13:08:25 -0700 (PDT) Received: by 10.216.13.6 with HTTP; Tue, 25 May 2010 13:08:25 -0700 (PDT) Date: Tue, 25 May 2010 23:08:25 +0300 Message-ID: From: Mohammed Farrag To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: New GSoC Student .. Mohammed Farrag X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 20:08:26 -0000 Hi all, My name is Mohammed Farrag, Student in the faculty of Computers and Information in Menofeya University, Egypt. I am goona work on New FreeBSD Kernel Theme. Tasks Suggested are : 1. Providing a block diagram of the new embedded freebsd. 2. Determine the functionality of these blocks in freebsd what exists and what doesn't. 3. Write/Collect the code for these blocks. 4.Debug the code. I started my work with my Mentor yesterday and we hope to provide you soon with block diagram.I will Keep in touch, Good Luck, Mohammed Farrag From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 19:54:21 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E12B7106566C for ; Tue, 25 May 2010 19:54:21 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 746818FC1A for ; Tue, 25 May 2010 19:54:21 +0000 (UTC) Received: by wyj26 with SMTP id 26so650003wyj.13 for ; Tue, 25 May 2010 12:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=p+Y5e6r20P+nwm7Ua4Tls64hB0yJ1Vcj6USRvlfDS+U=; b=rFfKwpb8y32u1IiHuVUk+DXVKf04yIQ64RjlULHX7WZ6FdlXVtJhnTxQ+c2NRfzWhn e/fnfaaLgZUuukAhWxmvL3VfwK6cDNys6cC0XjIeumhN54NOWF0/+zj4daRzTz8/ScsS dJVTTCKGLYS/PrCBSJB/S7EsPG2NJ6zOCavs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Oyy8nNZ7IxrrPc/OfPMoM//wMJwRu23RYCVRpb7IUD4z0iKml52ARIwB9VODOAiE7X j5wtSNHZj+XxcdVWEE3KKTsYZ+K+0EMkxnWjAKpKEwKa1S3glWPVGKPFxHfK99/WIDDz 7OHQYQKDK9pu3QOKhwCWreBtaKQySNlZyMKus= MIME-Version: 1.0 Received: by 10.216.93.19 with SMTP id k19mr4982707wef.223.1274815869135; Tue, 25 May 2010 12:31:09 -0700 (PDT) Received: by 10.216.13.6 with HTTP; Tue, 25 May 2010 12:31:08 -0700 (PDT) Date: Tue, 25 May 2010 22:31:08 +0300 Message-ID: From: Mohammed Farrag To: hackers@freebsd.org X-Mailman-Approved-At: Tue, 25 May 2010 20:26:06 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: New GSoC Student .. Mohammed Farrag X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 19:54:22 -0000 Hi all, My name is Mohammed Farrag, Student in the faculty of Computers and Information in Menofeya University, Egypt. I am goona work on New FreeBSD Kernel Theme. Tasks Suggested are : 1. Providing a block diagram of the new embedded freebsd. 2. Determine the functionality of these blocks in freebsd what exists and what doesn't. 3. Write/Collect the code for these blocks. 4.Debug the code. I started my work with my Mentor yesterday and we hope to provide you soon with block diagram.I will Keep in touch, Good Luck, Mohammed Farrag From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 22:21:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8837F106566B for ; Tue, 25 May 2010 22:21:42 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0B28FC0C for ; Tue, 25 May 2010 22:21:41 +0000 (UTC) Received: by gxk26 with SMTP id 26so2737197gxk.13 for ; Tue, 25 May 2010 15:21:41 -0700 (PDT) Received: by 10.231.156.1 with SMTP id u1mr7108243ibw.46.1274826100258; Tue, 25 May 2010 15:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.148.136 with HTTP; Tue, 25 May 2010 15:21:20 -0700 (PDT) In-Reply-To: <4BFC00E7.1060307@feral.com> References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> <4BFC004F.1090101@elischer.org> <4BFC00E7.1060307@feral.com> From: Eitan Adler Date: Wed, 26 May 2010 01:21:20 +0300 Message-ID: To: Matthew Jacob Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 22:21:42 -0000 On Tue, May 25, 2010 at 7:55 PM, Matthew Jacob wrote: > On 5/25/2010 9:52 AM, Julian Elischer wrote: >> >> On 5/25/10 8:33 AM, Eitan Adler wrote: >>>> >>>> No. Do not remove groff or associated tools from /usr/src ! >>>> Roff has been in Unix /usr/src since '77 or earlier. >>>> A lot of people use tools from that descendancy as production tools. >>> >>> So? If it isn't a very commonly used tool and isn't necessary for 99% >>> of cases I don't seem the harm of removing it from base and making it >>> a port? >> >> BSD has always =C2=A0been ab;e to produce it's documentation as part of = its >> build >> >> Please keep this true. > This is what mdocml will be for. I never advocated removing the utilities required for building documentation from the base - just the soon to be superfluous groff utility (once the GSOC project is done). --=20 Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 22:49:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C316A106564A for ; Tue, 25 May 2010 22:49:29 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 97BED8FC0C for ; Tue, 25 May 2010 22:49:29 +0000 (UTC) Received: from dereel.lemis.com (sat-gw-ext.lemis.com [180.181.112.227]) by w3.lemis.com (Postfix) with ESMTP id 1EEF53BACE for ; Tue, 25 May 2010 22:49:17 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id A2744A1098; Wed, 26 May 2010 08:49:13 +1000 (EST) Date: Wed, 26 May 2010 08:49:13 +1000 From: Greg 'groggy' Lehey To: freebsd-hackers@freebsd.org Message-ID: <20100525224913.GB11076@dereel.lemis.com> References: <20100524191307.GE216@comcast.net> <20100524191701.GA29256@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <20100524191701.GA29256@britannica.bec.de> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 22:49:29 -0000 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Monday, 24 May 2010 at 21:17:01 +0200, Joerg Sonnenberger wrote: > On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: > >> Is the thinking that groff has only been in base to support manpages? >> If so, this project makes sense. But even so, some clarification of the >> intent is needed. > > The use of (g)roff for anything but man pages is practically > non-existent. I wrote two books in it. It's good for typesetting. It's pretty much useless for man pages. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkv8U+kACgkQIubykFB6QiON4wCfWfHVbnRiJ0Z1CK8Zr/uW2Wum WFEAnA4rtkyYlbWNfRo1C2EZ/P8JNkkD =XzAB -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 22:50:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A354F106567A for ; Tue, 25 May 2010 22:50:42 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7634A8FC08 for ; Tue, 25 May 2010 22:50:42 +0000 (UTC) Received: from dereel.lemis.com (sat-gw-ext.lemis.com [180.181.112.227]) by w3.lemis.com (Postfix) with ESMTP id 106BD3BACE; Tue, 25 May 2010 22:50:40 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id 71FEDA1098; Wed, 26 May 2010 08:50:37 +1000 (EST) Date: Wed, 26 May 2010 08:50:37 +1000 From: Greg 'groggy' Lehey To: Kostik Belousov Message-ID: <20100525225037.GC11076@dereel.lemis.com> References: <20100524191307.GE216@comcast.net> <20100524191701.GA29256@britannica.bec.de> <20100524194337.GN83316@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk" Content-Disposition: inline In-Reply-To: <20100524194337.GN83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 22:50:42 -0000 --HG+GLK89HZ1zG0kk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Monday, 24 May 2010 at 22:43:37 +0300, Kostik Belousov wrote: > On Mon, May 24, 2010 at 09:17:01PM +0200, Joerg Sonnenberger wrote: >> On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: >>> I welcome this change, but groff is used for much more than manpages. >>> What happens to pic, tbl, and the other troff-related "little >>> languages"? How can you say mdocml is "completely replacing" groff if >>> it doesn't support those kinds of things? >> >> tbl(1) is going to be supported fully at some point in the future. >> It is work-in-progress. I am not sure if pic(1) is actually used beyond >> the groff documentation, at least I don't remember anything in NetBSD >> where I checked. Similiar usage is found for eqn(1). >> >>> Is the thinking that groff has only been in base to support manpages? >>> If so, this project makes sense. But even so, some clarification of the >>> intent is needed. >> >> The use of (g)roff for anything but man pages is practically non-existent. >> If you want to use it for typesetting, you can always install it. > > Would it support ps/dvi output ? If "it" refers to groff, it always has supported PostScript. It's trivial to create PS output from man pages at the moment. I don't see dvi output as an interesting goal. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --HG+GLK89HZ1zG0kk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkv8VD0ACgkQIubykFB6QiOtkgCfUf7ElMZ2Ntv7mm+kQI+wtru4 LEcAniiQzfC5bTb1lpoKpepVtveQH8J3 =xQp5 -----END PGP SIGNATURE----- --HG+GLK89HZ1zG0kk-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 23:00:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 503F71065672 for ; Tue, 25 May 2010 23:00:03 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 111828FC15 for ; Tue, 25 May 2010 23:00:02 +0000 (UTC) Received: from dereel.lemis.com (sat-gw-ext.lemis.com [180.181.112.227]) by w3.lemis.com (Postfix) with ESMTP id 7FD293BACE; Tue, 25 May 2010 23:00:00 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id 1711CA1098; Wed, 26 May 2010 08:59:58 +1000 (EST) Date: Wed, 26 May 2010 08:59:58 +1000 From: Greg 'groggy' Lehey To: Eitan Adler Message-ID: <20100525225958.GD11076@dereel.lemis.com> References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> <4BFC004F.1090101@elischer.org> <4BFC00E7.1060307@feral.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GpGaEY17fSl8rd50" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 23:00:03 -0000 --GpGaEY17fSl8rd50 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wednesday, 26 May 2010 at 1:21:20 +0300, Eitan Adler wrote: >> On 5/25/2010 9:52 AM, Julian Elischer wrote: >>> BSD has always =A0been ab;e to produce it's documentation as part of its >>> build >>> >>> Please keep this true. > > This is what mdocml will be for. I never advocated removing the > utilities required for building documentation from the base - just > the soon to be superfluous groff utility (once the GSOC project is > done). But groff *is* a tool required for building documentation. There are more documents than mdoc in the source tree. And there's no reason to remove groff just because you're introducing mdocml. mdocml is possibly a good idea; a better one IMO would be to replace the whole mdoc crud with something better, produce tools to format it, and leave groff the way it is. Then you could migrate the man pages gradually. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --GpGaEY17fSl8rd50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkv8Vm4ACgkQIubykFB6QiOMkQCfelKX9tiP4A4zzuGkBhYFDcTN 3OwAnRpzo0tXgGF9vQwsaqV/RgrFU6zx =aMHv -----END PGP SIGNATURE----- --GpGaEY17fSl8rd50-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 23:05:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A581065678 for ; Tue, 25 May 2010 23:05:50 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A53B8FC12 for ; Tue, 25 May 2010 23:05:49 +0000 (UTC) Received: by pxi7 with SMTP id 7so2685430pxi.13 for ; Tue, 25 May 2010 16:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7YzV51J8mCP1pSCb9EhouwwAyvdKPcJQe998dDVuXNc=; b=GsnSlGEiU4KNdmZKiwoV6ifmEVbQisQbku0JbPOy/Daew61TBLoHD4NSt3EXLx6Q8c WV3A5h5TiRfbMx7t7BGHcqtcuUbqumfr0nRmWAUAhNkgf8XSPqJ8HKqbjfAxV5sTVxiN H7lEcJ3VtlGsbnskSxb2Nx6TXKpJvtEF74aoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=n95RklD9AAOKyvCFTnR+kUJAJQjjTl7ZtGY27bAu4P3Gsc6E3URHnAUvoGNKJcJbXA u/6t0LgWpyhLcBIfPDa0ImP9xDcdCzvj2K/rqZ3a4nyWQH8F0HbkYH+i6r1Bh9JE1Ehw W1eONi6p9nHm9dEM+Td9YQeAcUNqhuEhVG5Ds= Received: by 10.142.65.22 with SMTP id n22mr5219186wfa.86.1274827009212; Tue, 25 May 2010 15:36:49 -0700 (PDT) Received: from [10.240.2.46] (db.kiwiplan.co.nz [202.27.222.237]) by mx.google.com with ESMTPS id 20sm4741815pzk.7.2010.05.25.15.36.46 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 15:36:48 -0700 (PDT) Message-ID: <4BFC50FC.9060809@gmail.com> Date: Wed, 26 May 2010 10:36:44 +1200 From: James Butler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eitan Adler References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> <4BFC004F.1090101@elischer.org> <4BFC00E7.1060307@feral.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 23:05:50 -0000 On 26/05/10 10:21, Eitan Adler wrote: > On Tue, May 25, 2010 at 7:55 PM, Matthew Jacob wrote: >> On 5/25/2010 9:52 AM, Julian Elischer wrote: >>> >>> On 5/25/10 8:33 AM, Eitan Adler wrote: >>>>> >>>>> No. Do not remove groff or associated tools from /usr/src ! >>>>> Roff has been in Unix /usr/src since '77 or earlier. >>>>> A lot of people use tools from that descendancy as production tools. >>>> >>>> So? If it isn't a very commonly used tool and isn't necessary for 99% >>>> of cases I don't seem the harm of removing it from base and making it >>>> a port? >>> >>> BSD has always been ab;e to produce it's documentation as part of its >>> build >>> >>> Please keep this true. >> > This is what mdocml will be for. I never advocated removing the > utilities required for building documentation from the base - just the > soon to be superfluous groff utility (once the GSOC project is done). There are several pieces of documentation in the FreeBSD tree which use macro packages other than mdoc and man, which are all mdocml (currently) supports - see the contents of /usr/share/doc/papers for example. groff is used for more than just manpages, even in the base system. -James Butler From owner-freebsd-hackers@FreeBSD.ORG Tue May 25 23:33:33 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6B21065675 for ; Tue, 25 May 2010 23:33:33 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 002F28FC0C for ; Tue, 25 May 2010 23:33:32 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C88115B30; Tue, 25 May 2010 16:16:11 -0700 (PDT) To: Eitan Adler In-reply-to: Your message of "Wed, 26 May 2010 01:21:20 +0300." References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> <4BFC004F.1090101@elischer.org> <4BFC00E7.1060307@feral.com> Date: Tue, 25 May 2010 16:16:10 -0700 From: Bakul Shah Message-Id: <20100525231611.C88115B30@mail.bitblocks.com> Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 23:33:33 -0000 On Wed, 26 May 2010 01:21:20 +0300 Eitan Adler wrote: > On Tue, May 25, 2010 at 7:55 PM, Matthew Jacob wrote: > > On 5/25/2010 9:52 AM, Julian Elischer wrote: > >> > >> On 5/25/10 8:33 AM, Eitan Adler wrote: > >>>> > >>>> No. Do not remove groff or associated tools from /usr/src ! > >>>> Roff has been in Unix /usr/src since '77 or earlier. > >>>> A lot of people use tools from that descendancy as production tools. > >>> > >>> So? If it isn't a very commonly used tool and isn't necessary for 99% > >>> of cases I don't seem the harm of removing it from base and making it > >>> a port? > >> > >> BSD has always =C2=A0been ab;e to produce it's documentation as part of = > its > >> build > >> > >> Please keep this true. > > > This is what mdocml will be for. I never advocated removing the > utilities required for building documentation from the base - just the > soon to be superfluous groff utility (once the GSOC project is done). mdocml handles -mdoc and -man but not other formats. There are documents in /usr/src/share/doc needing -ms and -me etc. groff can't be replaced with mdocml. If you must kick groff out, why not "port" plan9 troff which now does unicode, has 27 macro packages including ms, weighs in at about 10K lines of C code written by Joe Ossanna, Brian Kernighan, Ken Thompson, Jaap Akkerhuis & others, is now open source (subject to Lucent Public License), and traces its lineage back to Joe Ossanna's original troff? There is also pic, tbl, eqn and grap (for drawing graphs). Also troff2html. AFAIK plan9 troff doesn't do dvi but I think most people can live with that. All of these already work under FreeBSD, Linux, MacOS & others as part of Plan 9 from User space. Integrating them into FreeBSD base is bound to be far easier than replicating its functionality. See http://plan9.bell-labs.com/sys/doc/troff.pdf for troff details, http://www.swtch.com/plan9port for Plan9 from User Space. From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 06:54:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1870C106566B for ; Wed, 26 May 2010 06:54:41 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id DD5E68FC14 for ; Wed, 26 May 2010 06:54:40 +0000 (UTC) Received: from dereel.lemis.com (sat-gw-ext.lemis.com [180.181.112.227]) by w3.lemis.com (Postfix) with ESMTP id A35F33BACC; Wed, 26 May 2010 06:54:38 +0000 (UTC) Received: by dereel.lemis.com (Postfix, from userid 1004) id D7A02A1098; Wed, 26 May 2010 16:54:35 +1000 (EST) Date: Wed, 26 May 2010 16:54:35 +1000 From: Greg 'groggy' Lehey To: Bakul Shah Message-ID: <20100526065435.GE11076@dereel.lemis.com> References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> <4BFC004F.1090101@elischer.org> <4BFC00E7.1060307@feral.com> <20100525231611.C88115B30@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VUDLurXRWRKrGuMn" Content-Disposition: inline In-Reply-To: <20100525231611.C88115B30@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Eitan Adler , Matthew Jacob , freebsd-hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:54:41 -0000 --VUDLurXRWRKrGuMn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 25 May 2010 at 16:16:10 -0700, Bakul Shah wrote: > > If you must kick groff out, why not "port" plan9 troff which > now does unicode, has 27 macro packages including ms, weighs > in at about 10K lines of C code written by Joe Ossanna, Brian > Kernighan, Ken Thompson, Jaap Akkerhuis & others, is now open > source (subject to Lucent Public License), and traces its > lineage back to Joe Ossanna's original troff? There is also > pic, tbl, eqn and grap (for drawing graphs). Also > troff2html. AFAIK plan9 troff doesn't do dvi but I think > most people can live with that. This sounds too good to be true. I'd certainly be in favour of such a change, *if* it proves feasible. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --VUDLurXRWRKrGuMn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkv8xasACgkQIubykFB6QiNWcACeOrCW6rqtQQhluISkCk9TjUpv cU8Ani4BfGE6B3lKUYJCiDslAowSc/My =DEC/ -----END PGP SIGNATURE----- --VUDLurXRWRKrGuMn-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 06:55:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAD591065672 for ; Wed, 26 May 2010 06:55:43 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id AB9C88FC13 for ; Wed, 26 May 2010 06:55:43 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [141.76.6.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 0200D8A1E15; Wed, 26 May 2010 08:55:41 +0200 (CEST) Message-ID: <4BFCC5ED.6080909@bsdforen.de> Date: Wed, 26 May 2010 08:55:41 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Rui Paulo References: <4BF7C455.6040806@bsdforen.de> <4BF7CDC3.8050908@bsdforen.de> <95EA8683-E0AD-48DF-9148-8DE3E368F26C@lavabit.com> In-Reply-To: <95EA8683-E0AD-48DF-9148-8DE3E368F26C@lavabit.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Activate PCIe slot deactivated by BIOS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:55:44 -0000 On 25/05/2010 13:57, Rui Paulo wrote: > On 22 May 2010, at 13:27, Dominic Fandrey wrote: > >> On 22/05/2010 13:47, Dominic Fandrey wrote: >>> Today the card arrived and the BIOS complains (HP 6510b): >>> 104-Unsupported wireless network device detected. >>> System halted. Remove device and restart. >>> >>> The system boots if I turn off the wireless device in BIOS, but >>> this means I cannot use it. >>> >>> Now, I could just get a BIOS image and exchange the device IDs >>> there. But I wonder, wouldn't it be easier to just reactivate the >>> PCIe slot through the OS? >> >> This e-mail is written through the ath wireless I got: >> >> # ifconfig >> ath0: flags=8843 metric 0 mtu 2290 >> ether 00:24:2c:1d:f0:2f >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >> status: associated >> ... >> wlan0: flags=8843 metric 0 mtu 1500 >> ether 00:24:2c:1d:f0:2f >> inet 192.168.178.41 netmask 0xffffff00 broadcast 192.168.178.255 >> media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g >> status: associated >> ssid "Obi-Wan Kenobi" channel 7 (2442 MHz 11g) bssid 00:15:0c:d5:37:a0 >> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >> deftxkey UNDEF AES-CCM 2:128-bit txpower 20 bmiss 7 scanvalid 450 >> bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 >> protmode CTS wme burst roaming MANUAL >> >> I achieved this by passing the BIOS check with the intel wireless and >> hot-swapping it with the atheros card afterwards. This is impractical >> and evil, so I'm still searching for a solution. >> >> But at least I know that the device works. > > HP laptops really dislike the fact that your card isn't part of the Centrino brand, so they halt if they find an Atheros. Your best option is to change the Atheros card EEPROM to match the device and vendor id of your wpi card. Then you also need to change the ath driver to attach to that device id. > > It's evil, but it's better than hot-swapping. Yes, but it still sucks. And I actually have no idea how to flash the ath device. All the instructions on this I have found use Linux. I'd prefer to flash the notebook BIOS, but I have no way to defeat its evil compression. > The other option is to buy a iwn card which works better in FreeBSD than wpi. Nay, this is my goodbye to Intel brand wireless. I always thought wpa_supplicant was to blame for unreliable connections, but it all just works with the Atheros hardware. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 16:46:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB14B106566C for ; Wed, 26 May 2010 16:46:59 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 554AF8FC0A for ; Wed, 26 May 2010 16:46:59 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C68875B2E; Wed, 26 May 2010 09:46:56 -0700 (PDT) To: Greg 'groggy' Lehey In-reply-to: Your message of "Wed, 26 May 2010 16:54:35 +1000." <20100526065435.GE11076@dereel.lemis.com> References: <201005251450.o4PEo9tF099503@fire.js.berklix.net> <4BFC004F.1090101@elischer.org> <4BFC00E7.1060307@feral.com> <20100525231611.C88115B30@mail.bitblocks.com> <20100526065435.GE11076@dereel.lemis.com> Comments: In-reply-to Greg 'groggy' Lehey message dated "Wed, 26 May 2010 16:54:35 +1000." Date: Wed, 26 May 2010 09:46:56 -0700 From: Bakul Shah Message-Id: <20100526164656.C68875B2E@mail.bitblocks.com> Cc: Eitan Adler , freebsd-hackers@freebsd.org Subject: Re: GSoC: BSD text tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:47:00 -0000 On Wed, 26 May 2010 16:54:35 +1000 Greg 'groggy' Lehey wrote: > On Tuesday, 25 May 2010 at 16:16:10 -0700, Bakul Shah wrote: > > > > If you must kick groff out, why not "port" plan9 troff which > > now does unicode, has 27 macro packages including ms, weighs > > in at about 10K lines of C code written by Joe Ossanna, Brian > > Kernighan, Ken Thompson, Jaap Akkerhuis & others, is now open > > source (subject to Lucent Public License), and traces its > > lineage back to Joe Ossanna's original troff? There is also > > pic, tbl, eqn and grap (for drawing graphs). Also > > troff2html. AFAIK plan9 troff doesn't do dvi but I think > > most people can live with that. > > This sounds too good to be true. I'd certainly be in favour of such a > change, *if* it proves feasible. pkg_add -r plan9port to play with these programs. People who use *roff a lot should satisfy themselves p9p versions meet their needs. [p9p has a lot of other goodies worth nibbling on] There are two issues in integrating with BSD: licensing and the amount of effort required. For licensing issues a good place to start would be to look at /usr/local/plan9/LICENSE (once you install the p9p port). For what it's worth, my sense is that the relevant licenses should allow bundling with *BSD but I am not a lawyer. As for effort, p9p has already made the changes needed to allow compiling with gcc (plan9 C is not std C but close enough). p9p programs rely on a porting layer that emulates some of plan9 environment. If these porting/ported libraries are imported into BSD, porting is almost a trivial task. If you just want troff&co, I suspect one would need a small subset of these libraries. Only one way to find out! From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 18:05:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED8B1065672 for ; Wed, 26 May 2010 18:05:53 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-15.arcor-online.net (mail-in-15.arcor-online.net [151.189.21.55]) by mx1.freebsd.org (Postfix) with ESMTP id 41C328FC15 for ; Wed, 26 May 2010 18:05:53 +0000 (UTC) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id 95F0F1ABABA for ; Wed, 26 May 2010 20:05:51 +0200 (CEST) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id 86DB073FBF for ; Wed, 26 May 2010 20:05:51 +0200 (CEST) Received: from lorvorc.mips.inka.de (dslb-094-217-098-010.pools.arcor-ip.net [94.217.98.10]) by mail-in-17.arcor-online.net (Postfix) with ESMTPS id 07E92CBFE6 for ; Wed, 26 May 2010 20:05:50 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-17.arcor-online.net 07E92CBFE6 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.4/8.14.3) with ESMTP id o4QI5oSI014539 for ; Wed, 26 May 2010 20:05:50 +0200 (CEST) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.4/8.14.4/Submit) id o4QI5ocW014538 for freebsd-hackers@freebsd.org; Wed, 26 May 2010 20:05:50 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Wed, 26 May 2010 18:05:50 +0000 (UTC) Message-ID: References: <201005251129.o4PBSsLS049798@fire.js.berklix.net> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-hackers@freebsd.org Subject: Re: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German & French X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:05:53 -0000 Julian H. Stacey wrote: > Problem: /usr/src/usr.bin/fmt/fmt.c is not 8 bit clean. > (ie French or German etc text with accents in gets broken) Can you provide an example where it fails? It works fine for ISO 8859-1 and UTF-8 for me, *provided* the locale is set correctly. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 17:30:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E17A106567D; Wed, 26 May 2010 17:30:56 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 745458FC0C; Wed, 26 May 2010 17:30:56 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4QHTpC5030356; Wed, 26 May 2010 10:29:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=VZW7EEU+Xa3eCwZnS7DNghfezDGMkusdJDT+QRUZfML1TL+3RFSpHp73ogVyGzoQ From: Sean Bruno To: jhell In-Reply-To: <1274798852.4715.1.camel@localhost.localdomain> References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> <1274798852.4715.1.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 May 2010 10:29:29 -0700 Message-ID: <1274894969.2481.47.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 May 2010 18:12:40 +0000 Cc: freebsd-hackers , "sbruno@freebsd.org" Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 17:30:56 -0000 On Tue, 2010-05-25 at 07:47 -0700, Sean Bruno wrote: > > Hi Sean, > > > > Nice work on this. I applied this to stable/8 r208530 and I am in the > > process of compiling the kernel right now. Everything else has built & > > runs as expected "i386". Attached is the adjusted patch which was one > > modification to the line number for uz_sleeps in sys/vm/uma_int.h. > > > > 8 files changed, 106 insertions(+), 7 deletions(-) > > > > For those wishing to apply this patch and test for them self: > > > > cd /usr/src > > patch > cd /usr/src/include > > make obj && make depend && make includes && make install > > cd /usr/src/lib/libmemstat > > make obj && make depend && make includes && make install > > cd /usr/src/usr.bin/vmstat > > make obj && make depend && make install > > cd /usr/src > > make kernel KERNCONF=YOUR_KERN_CONF > > reboot > > > > Can't wait to see some results from this & I will report back with > > either negative results of the build & run or positive results from the > > stats collected. > > > > If there is anything needed feel free to let me know and I will do what > > is possible ASAP. > > > > Thanks again, > > > > - -- > > > > jhell > > Excellent. Please check the output of vmstat -z and the appropriate > sysctl. I changed the display a bit to keep it from wrapping on a > standard terminal. > > Sean > > P.S. My intention it to MFC this to all releases. > I do have a concern related to the removal of an #ifdef DDB in this patch. Any comments? Sean From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 18:52:04 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6CF81065676 for ; Wed, 26 May 2010 18:52:04 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 8F28D8FC12 for ; Wed, 26 May 2010 18:52:04 +0000 (UTC) Received: by qyk11 with SMTP id 11so9995861qyk.13 for ; Wed, 26 May 2010 11:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vrkDJyQqlitcaLO18QL6Pd8yc+2RSmf6kRKKiwYGNVE=; b=n2NFIRpUDhN1qgHIf0dBe052w0rz7/DaF/3XQidtAcPuDDthYvUaj/Aj1y00622Xhw Tye36NR/vd5VJTv6vDmsZSyGx4QTlbyvqKUz7E/pZrQZi9GT9QlsJWSsKMqhh2kbTp+t 97Hcn+MQWM6XbZaVP/ZbOWpah1SyD7ISM/y+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Af0KoZoYh7jnUnGDmXNI+spNFI4SxRgahAuagamLoQTdLKdv7MQaqZTMAupqmd6hjG 9S7MoGiTHo4H87kkTmp62le0ZENwYb2bV6IoNdj6WxPXOHJaWJhNxoTCGBbhtezY03CI JaAivn+JKhRksySCTVOUltOnTn3dfWX5LnsMo= MIME-Version: 1.0 Received: by 10.224.19.9 with SMTP id y9mr5058818qaa.353.1274899914376; Wed, 26 May 2010 11:51:54 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Wed, 26 May 2010 11:51:52 -0700 (PDT) In-Reply-To: <4BFC1660.1000405@dataix.net> References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> <4BFC1660.1000405@dataix.net> Date: Wed, 26 May 2010 11:51:52 -0700 Message-ID: From: Garrett Cooper To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , sbruno@freebsd.org, Sean Bruno Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:52:05 -0000 On Tue, May 25, 2010 at 11:26 AM, jhell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/25/2010 10:01, jhell wrote: >> On 05/24/2010 18:26, Sean Bruno wrote: >>> Find attached a patch against -CURRENT. >> >>> This update exposes a counter that indicates the number of times that w= e >>> sleep when attempting to allocate a slab from the keg. =A0In other word= s, >>> the number of times we BLOCK and wait, which is bad. >> >>> This allows differentiation between times when we failed to allocate an= d >>> it was ok and times where we were forced to sleep. =A0The current FAIL >>> counter does not make this distinction. >> >>> Exposes this information via uma_zone_t->uz_sleeps. >> >>> Add a new sysctl to retrieve this information. >>> Enhance vmstat -z to retrieve this information. >> >>> We've found this *extremely* useful here at Yahoo in the past and would >>> like to commit this if it is acceptable. >> >>> Tested on 32bit and 64bit architectures on 6/7/CURRENT. >> >> >> Hi Sean, >> >> Nice work on this. I applied this to stable/8 r208530 and I am in the >> process of compiling the kernel right now. Everything else has built & >> runs as expected "i386". Attached is the adjusted patch which was one >> modification to the line number for uz_sleeps in sys/vm/uma_int.h. >> >> 8 files changed, 106 insertions(+), 7 deletions(-) >> >> For those wishing to apply this patch and test for them self: >> >> cd /usr/src >> patch > cd /usr/src/include >> make obj && make depend && make includes && make install >> cd /usr/src/lib/libmemstat >> make obj && make depend && make includes && make install >> cd /usr/src/usr.bin/vmstat >> make obj && make depend && make install >> cd /usr/src >> make kernel KERNCONF=3DYOUR_KERN_CONF >> reboot >> >> Can't wait to see some results from this & I will report back with >> either negative results of the build & run or positive results from the >> stats collected. >> >> If there is anything needed feel free to let me know and I will do what >> is possible ASAP. >> >> Thanks again, >> > > This patch instead pardon the early.post but there was a problem with > the last patch that I attached for stable/8 r208530 with arguments 10 & > 11 to function sysctl_vm_zone where it wanted a long unsigned integer > rather than u_int64_t. > > This patch satisfies that. Whether its correct is left to the reader but > compiles cleanly & runs smoothly. I know this seems trivial, but could you change: + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", + "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP"); to + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", + "LIMIT", "USED", "FREE", "REQS", "FAIL", "SLEEP"); that way the plural nature of requests is more straightforward and understo= od. Also, do all of the fields _really_ need to have a field width? Seems like overkill to me... Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 18:52:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22BBD1065672 for ; Wed, 26 May 2010 18:52:54 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id CD9DC8FC12 for ; Wed, 26 May 2010 18:52:53 +0000 (UTC) Received: by qyk11 with SMTP id 11so9997163qyk.13 for ; Wed, 26 May 2010 11:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hB8xZH3zcHHfCJ6weTeMW7cJ5piGmH+z+PZzUlC/Erw=; b=G2r2MnrtK5NmB76I98YAoeJCc+WYwj2fSNoMbmG9qc05zrOtFoJL6lgkBc6dUfy7zR EfoLldxlje8I5HzUBEy7gioR2o/7bre5qUWqGqlRrsXHEIHxtfbPSpu3gUQ+uelHo2g7 hTD3TYVtrxlZ4Q0H/19Dwlak/AEvwLCWZw/cU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OCMTryp4xbUMflBY2Tat1wNz0oWsme/ufkLONqHL1MPVTy9UN4hUeLIfNLaKT+DpZf V6fOVb7L1wwGN64E6knDj9NwHgmTICoWPtZOlEP8ORPYQCEZmQWwPIhcOtW+vq0Jg0RO lvuf+iyYFfuGIxDjpdKDAeot51bDHHQ1cNTIo= MIME-Version: 1.0 Received: by 10.224.58.78 with SMTP id f14mr5099480qah.385.1274899971952; Wed, 26 May 2010 11:52:51 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Wed, 26 May 2010 11:52:51 -0700 (PDT) In-Reply-To: References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> <4BFC1660.1000405@dataix.net> Date: Wed, 26 May 2010 11:52:51 -0700 Message-ID: From: Garrett Cooper To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , sbruno@freebsd.org, Sean Bruno Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:52:54 -0000 On Wed, May 26, 2010 at 11:51 AM, Garrett Cooper wrote= : > On Tue, May 25, 2010 at 11:26 AM, jhell wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 05/25/2010 10:01, jhell wrote: >>> On 05/24/2010 18:26, Sean Bruno wrote: >>>> Find attached a patch against -CURRENT. >>> >>>> This update exposes a counter that indicates the number of times that = we >>>> sleep when attempting to allocate a slab from the keg. =A0In other wor= ds, >>>> the number of times we BLOCK and wait, which is bad. >>> >>>> This allows differentiation between times when we failed to allocate a= nd >>>> it was ok and times where we were forced to sleep. =A0The current FAIL >>>> counter does not make this distinction. >>> >>>> Exposes this information via uma_zone_t->uz_sleeps. >>> >>>> Add a new sysctl to retrieve this information. >>>> Enhance vmstat -z to retrieve this information. >>> >>>> We've found this *extremely* useful here at Yahoo in the past and woul= d >>>> like to commit this if it is acceptable. >>> >>>> Tested on 32bit and 64bit architectures on 6/7/CURRENT. >>> >>> >>> Hi Sean, >>> >>> Nice work on this. I applied this to stable/8 r208530 and I am in the >>> process of compiling the kernel right now. Everything else has built & >>> runs as expected "i386". Attached is the adjusted patch which was one >>> modification to the line number for uz_sleeps in sys/vm/uma_int.h. >>> >>> 8 files changed, 106 insertions(+), 7 deletions(-) >>> >>> For those wishing to apply this patch and test for them self: >>> >>> cd /usr/src >>> patch >> cd /usr/src/include >>> make obj && make depend && make includes && make install >>> cd /usr/src/lib/libmemstat >>> make obj && make depend && make includes && make install >>> cd /usr/src/usr.bin/vmstat >>> make obj && make depend && make install >>> cd /usr/src >>> make kernel KERNCONF=3DYOUR_KERN_CONF >>> reboot >>> >>> Can't wait to see some results from this & I will report back with >>> either negative results of the build & run or positive results from the >>> stats collected. >>> >>> If there is anything needed feel free to let me know and I will do what >>> is possible ASAP. >>> >>> Thanks again, >>> >> >> This patch instead pardon the early.post but there was a problem with >> the last patch that I attached for stable/8 r208530 with arguments 10 & >> 11 to function sysctl_vm_zone where it wanted a long unsigned integer >> rather than u_int64_t. >> >> This patch satisfies that. Whether its correct is left to the reader but >> compiles cleanly & runs smoothly. > > I know this seems trivial, but could you change: > > + =A0 =A0 =A0 printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SI= ZE", > + =A0 =A0 =A0 =A0 =A0 "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP"); > > to > > + =A0 =A0 =A0 printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SI= ZE", > + =A0 =A0 =A0 =A0 =A0 "LIMIT", "USED", "FREE", "REQS", "FAIL", "SLEEP"); > > that way the plural nature of requests is more straightforward and unders= tood. > > Also, do all of the fields _really_ need to have a field width? Seems > like overkill to me... Oh, and the field width for the last item is wrong; SLEEP will be truncated to SLEE. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 18:58:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55A1C1065674; Wed, 26 May 2010 18:58:25 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB538FC1D; Wed, 26 May 2010 18:58:24 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4QIwAhx008986; Wed, 26 May 2010 11:58:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=Xas408tEB/xuAYCHIPxn3unFnuy2FJoqpmirqCw/1I1GHgG2pkz4NpecjuQBPJs3 From: Sean Bruno To: Garrett Cooper In-Reply-To: References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> <4BFC1660.1000405@dataix.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 May 2010 11:58:10 -0700 Message-ID: <1274900290.2481.135.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 May 2010 19:06:25 +0000 Cc: "sbruno@freebsd.org" , freebsd-hackers Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:58:25 -0000 On Wed, 2010-05-26 at 11:52 -0700, Garrett Cooper wrote: > >> > >> This patch instead pardon the early.post but there was a problem with > >> the last patch that I attached for stable/8 r208530 with arguments 10 & > >> 11 to function sysctl_vm_zone where it wanted a long unsigned integer > >> rather than u_int64_t. > >> > >> This patch satisfies that. Whether its correct is left to the reader but > >> compiles cleanly & runs smoothly. > > > > I know this seems trivial, but could you change: > > > > + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", > > + "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP"); > > > > to > > > > + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", > > + "LIMIT", "USED", "FREE", "REQS", "FAIL", "SLEEP"); > > > > that way the plural nature of requests is more straightforward and understood. > > > > Also, do all of the fields _really_ need to have a field width? Seems > > like overkill to me... > > Oh, and the field width for the last item is wrong; SLEEP will be > truncated to SLEE. > Thanks, > -Garrett I hate this type of column implementation. Any ideas on a more useful implementation? also, I'm missing an email in this thread somehow. I didn't see the second version of the REL-8 patch. Sean From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 20:53:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE1151065672 for ; Wed, 26 May 2010 20:53:11 +0000 (UTC) (envelope-from rpaulo@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 80F048FC18 for ; Wed, 26 May 2010 20:53:11 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 2E86424ED9D; Wed, 26 May 2010 15:53:10 -0500 (CDT) Received: from 77.54.35.145 (145.35.54.77.rev.vodafone.pt [77.54.35.145]) by lavabit.com with ESMTP id 7MRYTG8VU8XB; Wed, 26 May 2010 15:53:10 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=A7m+LFHCr802/1cnmpsgXAfj4wYtYYrja5RffUMOh677wEuvz4nIlEbDjEju2jCDV5PVDdednOyqY5vk7DdP1uy1jv6N3Au1PiiiRPp2ga1ngV/uCpoe7FdFP3KN9IBrBk8y7ejJgthwnFhHaWT7QXRfZz2HaCr8NhCIgz+otUQ=; h=References:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Mailer:Mime-Version:Subject:Date:Cc; References: <4BF7C455.6040806@bsdforen.de> <4BF7CDC3.8050908@bsdforen.de> <95EA8683-E0AD-48DF-9148-8DE3E368F26C@lavabit.com> <4BFCC5ED.6080909@bsdforen.de> Message-Id: <88D963CA-DB03-4FA3-B770-0EB4638D7A48@lavabit.com> From: Rui Paulo To: Dominic Fandrey In-Reply-To: <4BFCC5ED.6080909@bsdforen.de> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 26 May 2010 21:52:41 +0100 X-Mailman-Approved-At: Wed, 26 May 2010 21:01:11 +0000 Cc: "freebsd-hackers@freebsd.org" Subject: Re: Activate PCIe slot deactivated by BIOS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 20:53:12 -0000 On 26 May 2010, at 07:55, Dominic Fandrey wrote: > On 25/05/2010 13:57, Rui Paulo wrote: >> On 22 May 2010, at 13:27, Dominic Fandrey wrote: >> >>> On 22/05/2010 13:47, Dominic Fandrey wrote: >>>> Today the card arrived and the BIOS complains (HP 6510b): >>>> 104-Unsupported wireless network device detected. >>>> System halted. Remove device and restart. >>>> >>>> The system boots if I turn off the wireless device in BIOS, but >>>> this means I cannot use it. >>>> >>>> Now, I could just get a BIOS image and exchange the device IDs >>>> there. But I wonder, wouldn't it be easier to just reactivate the >>>> PCIe slot through the OS? >>> >>> This e-mail is written through the ath wireless I got: >>> >>> # ifconfig >>> ath0: flags=8843 metric 0 >>> mtu 2290 >>> ether 00:24:2c:1d:f0:2f >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>> status: associated >>> ... >>> wlan0: flags=8843 metric 0 >>> mtu 1500 >>> ether 00:24:2c:1d:f0:2f >>> inet 192.168.178.41 netmask 0xffffff00 broadcast 192.168.178.255 >>> media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g >>> status: associated >>> ssid "Obi-Wan Kenobi" channel 7 (2442 MHz 11g) bssid >>> 00:15:0c:d5:37:a0 >>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>> deftxkey UNDEF AES-CCM 2:128-bit txpower 20 bmiss 7 scanvalid 450 >>> bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 >>> protmode CTS wme burst roaming MANUAL >>> >>> I achieved this by passing the BIOS check with the intel wireless >>> and >>> hot-swapping it with the atheros card afterwards. This is >>> impractical >>> and evil, so I'm still searching for a solution. >>> >>> But at least I know that the device works. >> >> HP laptops really dislike the fact that your card isn't part of the >> Centrino brand, so they halt if they find an Atheros. Your best >> option is to change the Atheros card EEPROM to match the device and >> vendor id of your wpi card. Then you also need to change the ath >> driver to attach to that device id. >> >> It's evil, but it's better than hot-swapping. > > Yes, but it still sucks. And I actually have no idea how to flash the > ath device. All the instructions on this I have found use Linux. Please ask sam@FreeBSD.org about that. > > I'd prefer to flash the notebook BIOS, but I have no way to defeat > its evil compression. I think flashing the bios is more risky than fixing the EEPROM. > >> The other option is to buy a iwn card which works better in FreeBSD >> than wpi. > > Nay, this is my goodbye to Intel brand wireless. I always thought > wpa_supplicant was to blame for unreliable connections, but it > all just works with the Atheros hardware. Intel has made progress and I really think that they are on the right track to produce good cards. > > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > > ____________________________________________________________________________________ > Use the link below to report this message as spam. > https://lavabit.com/apps/teacher?sig=1117002&key=1739816679 > ____________________________________________________________________________________ From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 21:31:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D88461065675; Wed, 26 May 2010 21:31:23 +0000 (UTC) (envelope-from jhellenthal@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 3953A8FC15; Wed, 26 May 2010 21:31:22 +0000 (UTC) Received: by fxm12 with SMTP id 12so202231fxm.13 for ; Wed, 26 May 2010 14:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=DThanP05aW/+M1ZNi6m7goyC/mcJs52Mm8E4DL8W5VM=; b=KfIXdRBECSqHt+PMqbw1RbqWphq/liP030OYhAFpRhi2HXvUPise5+6APGvX34mbPn XDFQx3YGy4Y/4TlbW3+Hp6ANiGM14XDINLWmZ4F57w39fbZv3gIcyMcT9Wo6w7xYrhCh Sau/uZE7kK6ayV0QpHlUPge2I1o9CC6b0KkXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=yEK3iJB+465D92jma1b3m2yNoZ/IWPmN4KbOF+cIsoUE5tIKeljFqJ4sxUoGXkD3Ly 0k/HJyv+Gotp8uH2VBwz99CStSK2pw2qTTrlL6ctRXc+FBC98BsGuvXS07MK5Tc4sgvm vVrA8lzxX6xULbIFGZPthep9JUzWNf4t2EF7Y= Received: by 10.204.36.209 with SMTP id u17mr1189943bkd.184.1274909481232; Wed, 26 May 2010 14:31:21 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-40-41.dsl.klmzmi.sbcglobal.net [99.19.40.41]) by mx.google.com with ESMTPS id d5sm2205273bkd.7.2010.05.26.14.31.18 (version=SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 14:31:20 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BFD9325.50905@dataix.net> Date: Wed, 26 May 2010 17:31:17 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: Sean Bruno References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> <1274798852.4715.1.camel@localhost.localdomain> <1274894969.2481.47.camel@localhost.localdomain> In-Reply-To: <1274894969.2481.47.camel@localhost.localdomain> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , "sbruno@freebsd.org" Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 21:31:23 -0000 On 05/26/2010 13:29, Sean Bruno wrote: > On Tue, 2010-05-25 at 07:47 -0700, Sean Bruno wrote: >>> Hi Sean, >>> >>> Nice work on this. I applied this to stable/8 r208530 and I am in the >>> process of compiling the kernel right now. Everything else has built & >>> runs as expected "i386". Attached is the adjusted patch which was one >>> modification to the line number for uz_sleeps in sys/vm/uma_int.h. >>> >>> 8 files changed, 106 insertions(+), 7 deletions(-) >>> >>> For those wishing to apply this patch and test for them self: >>> >>> cd /usr/src >>> patch >> cd /usr/src/include >>> make obj && make depend && make includes && make install >>> cd /usr/src/lib/libmemstat >>> make obj && make depend && make includes && make install >>> cd /usr/src/usr.bin/vmstat >>> make obj && make depend && make install >>> cd /usr/src >>> make kernel KERNCONF=YOUR_KERN_CONF >>> reboot >>> >>> Can't wait to see some results from this & I will report back with >>> either negative results of the build & run or positive results from the >>> stats collected. >>> >>> If there is anything needed feel free to let me know and I will do what >>> is possible ASAP. >>> >>> Thanks again, >>> >>> - -- >>> >>> jhell >> >> Excellent. Please check the output of vmstat -z and the appropriate >> sysctl. I changed the display a bit to keep it from wrapping on a >> standard terminal. >> >> Sean >> >> P.S. My intention it to MFC this to all releases. >> > > I do have a concern related to the removal of an #ifdef DDB in this > patch. Any comments? > > Sean This was in your original patch sent to the list. I questioned it too but as far as testing it goes it has caused no harm that I can see here but I will add those back in along with the improvements from Garrett, then regenerate the patch and send it back to the list. Regards, -- jhell From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 00:49:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E81C1065678; Thu, 27 May 2010 00:49:51 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 18BAB8FC16; Thu, 27 May 2010 00:49:50 +0000 (UTC) Received: by gwj21 with SMTP id 21so1092466gwj.13 for ; Wed, 26 May 2010 17:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type; bh=kf9hSD6SwC0957KKAOFfVzhorSQIqZgHaSpM2q6PJwM=; b=IeZRWmgRqFLAmUvNpZnTNcEA+AxMUHQ+o7MHjNwWRbzClt0Ovmjflj6UW7fVS1yXjM Y9Y8OD5q9U+qvUiR9pwfhYfmYM5RRqdNxxtGjtIrWxHGK7CBMthrE8MUXb0fOGG1SvE7 P0mrIZLm15waDErikWXXnKNqGuZX1+pyR9css= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type; b=eiZisWi1i4Hbj/npUcvATN1/tVwLPCXzSCx/OeIn/Whtguta1AVvOmv8XtQ7Sr6vte hElDlAuSQ4vciXpRO0L7K1DXkWxyZVYTkb/MwrHQLN3UWhFu6q8HnBAaIqDjZfcVRHuE mQMWAx7+JpXh8lJv7plQiR/GrRGp3LsHQwRdg= Received: by 10.231.147.18 with SMTP id j18mr7925493ibv.12.1274921390006; Wed, 26 May 2010 17:49:50 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-40-41.dsl.klmzmi.sbcglobal.net [99.19.40.41]) by mx.google.com with ESMTPS id t28sm2809561ibg.18.2010.05.26.17.49.48 (version=SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 17:49:49 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BFDC1AB.4090604@dataix.net> Date: Wed, 26 May 2010 20:49:47 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: Sean Bruno References: <1274739973.31299.23.camel@localhost.localdomain> <4BFBD838.40208@dataix.net> <4BFC1660.1000405@dataix.net> <1274900290.2481.135.camel@localhost.localdomain> In-Reply-To: <1274900290.2481.135.camel@localhost.localdomain> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: multipart/mixed; boundary="------------030108020004090702040307" Cc: Garrett Cooper , "sbruno@freebsd.org" , freebsd-hackers Subject: Re: Exposing Zone Sleeps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 00:49:51 -0000 This is a multi-part message in MIME format. --------------030108020004090702040307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2010 14:58, Sean Bruno wrote: > On Wed, 2010-05-26 at 11:52 -0700, Garrett Cooper wrote: > > >>>> >>>> This patch instead pardon the early.post but there was a problem with >>>> the last patch that I attached for stable/8 r208530 with arguments 10 & >>>> 11 to function sysctl_vm_zone where it wanted a long unsigned integer >>>> rather than u_int64_t. >>>> >>>> This patch satisfies that. Whether its correct is left to the reader but >>>> compiles cleanly & runs smoothly. >>> >>> I know this seems trivial, but could you change: >>> >>> + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", >>> + "LIMIT", "USED", "FREE", "REQ", "FAIL", "SLEEP"); >>> >>> to >>> >>> + printf("%-20s %6s %6s %8s %8s %8s %4s %4s\n\n", "ITEM", "SIZE", >>> + "LIMIT", "USED", "FREE", "REQS", "FAIL", "SLEEP"); >>> >>> that way the plural nature of requests is more straightforward and understood. >>> >>> Also, do all of the fields _really_ need to have a field width? Seems >>> like overkill to me... >> >> Oh, and the field width for the last item is wrong; SLEEP will be >> truncated to SLEE. >> Thanks, >> -Garrett > > I hate this type of column implementation. Any ideas on a more useful > implementation? > > also, I'm missing an email in this thread somehow. I didn't see the > second version of the REL-8 patch. > > Sean Attached is the diff against vmstat.c only *just* to view the differences. This is also in the sleep_stat_stable8-r208580.diff so no need to patch twice. Also attached is the patch for sleep stat on stable/8 "revised". against r208580: Changes: * Added back the #ifdef DDB * vmstat(1) displays all columns in a 80 column display cleanly. Comments & suggestions ? I am a little bit shaky about putting the last column so close to the end of the terminal but that may just be my own personal worries but for now every field should have enough room to grow as far as I can verify on my own equipment. Test this out and let me know what you think, if it wraps or not and whether you think there is enough space for the numbers to grow in the current layout of the columns. Thanks again & regards, - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJL/cGqAAoJEJBXh4mJ2FR+oo4IAJWt9sOEhnlmZOG+8Ehf7SKt QX5ZxBDHz196FR5zOW1p4xjfkGX5ZVD0WytHS7JyTxTiMxkvzELfFpbzfGFtp1U8 Hgtv76gCZnZOEdOTCdtjknJmJNw6FC9FMAXLv5f4tzBj8HNo5sfg0x9wBmEiUfI0 8WO9f83n62lKV5SRyx+jRM/FeAZsNz9zAT0+Z8UmYUDSy+u6jFLYbWD71TzwLMKd 8+Ba/5qsnTTFVfqZOG3lRPcOCdj1QBicRzL+hyKfmNFT1IN8Xek+BhE9sDiOmqK2 0dt87kaDBV5reAeQ1P0Cqvgl7m1JGWg0bJL+c5Z7O2MpcosOxqbfTji1lHQiVZo= =uA4o -----END PGP SIGNATURE----- --------------030108020004090702040307 Content-Type: text/x-patch; name="vmstat-z.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vmstat-z.diff" Index: vmstat.c =================================================================== --- vmstat.c (revision 208580) +++ vmstat.c (working copy) @@ -1286,16 +1286,17 @@ memstat_strerror(error)); } } - printf("%-20s %8s %8s %8s %8s %8s %8s\n\n", "ITEM", "SIZE", - "LIMIT", "USED", "FREE", "REQUESTS", "FAILURES"); + printf("%-20s %+6s %+8s %+8s %+6s %+10s %+8s %+6s\n\n", "ITEM", "SIZE", + "LIMIT", "USED", "FREE", "REQS", "FAIL", "SLEEP"); for (mtp = memstat_mtl_first(mtlp); mtp != NULL; mtp = memstat_mtl_next(mtp)) { strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME); strcat(name, ":"); - printf("%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n", name, + printf("%-20s %+6llu,%+8llu,%+8llu,%+6llu,%+10llu,%+8llu,%+6llu\n",name, memstat_get_size(mtp), memstat_get_countlimit(mtp), memstat_get_count(mtp), memstat_get_free(mtp), - memstat_get_numallocs(mtp), memstat_get_failures(mtp)); + memstat_get_numallocs(mtp), memstat_get_failures(mtp), + memstat_get_sleeps(mtp)); } memstat_mtl_free(mtlp); printf("\n"); --------------030108020004090702040307 Content-Type: text/x-patch; name="sleep_stat_stable8_r208580.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sleep_stat_stable8_r208580.diff" Index: usr.bin/vmstat/vmstat.c =================================================================== --- usr.bin/vmstat/vmstat.c (revision 208580) +++ usr.bin/vmstat/vmstat.c (working copy) @@ -1286,16 +1286,17 @@ memstat_strerror(error)); } } - printf("%-20s %8s %8s %8s %8s %8s %8s\n\n", "ITEM", "SIZE", - "LIMIT", "USED", "FREE", "REQUESTS", "FAILURES"); + printf("%-20s %+6s %+8s %+8s %+6s %+10s %+8s %+6s\n\n", "ITEM", "SIZE", + "LIMIT", "USED", "FREE", "REQS", "FAIL", "SLEEP"); for (mtp = memstat_mtl_first(mtlp); mtp != NULL; mtp = memstat_mtl_next(mtp)) { strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME); strcat(name, ":"); - printf("%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n", name, + printf("%-20s %+6llu,%+8llu,%+8llu,%+6llu,%+10llu,%+8llu,%+6llu\n",name, memstat_get_size(mtp), memstat_get_countlimit(mtp), memstat_get_count(mtp), memstat_get_free(mtp), - memstat_get_numallocs(mtp), memstat_get_failures(mtp)); + memstat_get_numallocs(mtp), memstat_get_failures(mtp), + memstat_get_sleeps(mtp)); } memstat_mtl_free(mtlp); printf("\n"); Index: lib/libmemstat/memstat.h =================================================================== --- lib/libmemstat/memstat.h (revision 208580) +++ lib/libmemstat/memstat.h (working copy) @@ -139,6 +139,7 @@ uint64_t memstat_get_count(const struct memory_type *mtp); uint64_t memstat_get_free(const struct memory_type *mtp); uint64_t memstat_get_failures(const struct memory_type *mtp); +uint64_t memstat_get_sleeps(const struct memory_type *mtp); void *memstat_get_caller_pointer(const struct memory_type *mtp, int index); void memstat_set_caller_pointer(struct memory_type *mtp, Index: lib/libmemstat/memstat.c =================================================================== --- lib/libmemstat/memstat.c (revision 208580) +++ lib/libmemstat/memstat.c (working copy) @@ -188,6 +188,7 @@ mtp->mt_count = 0; mtp->mt_free = 0; mtp->mt_failures = 0; + mtp->mt_sleeps = 0; mtp->mt_zonefree = 0; mtp->mt_kegfree = 0; @@ -304,6 +305,13 @@ return (mtp->mt_failures); } +uint64_t +memstat_get_sleeps(const struct memory_type *mtp) +{ + + return (mtp->mt_sleeps); +} + void * memstat_get_caller_pointer(const struct memory_type *mtp, int index) { Index: lib/libmemstat/memstat_internal.h =================================================================== --- lib/libmemstat/memstat_internal.h (revision 208580) +++ lib/libmemstat/memstat_internal.h (working copy) @@ -65,6 +65,7 @@ uint64_t mt_count; /* Number of current allocations. */ uint64_t mt_free; /* Number of cached free items. */ uint64_t mt_failures; /* Number of allocation failures. */ + uint64_t mt_sleeps; /* Number of allocation sleeps. */ /* * Caller-owned memory. Index: lib/libmemstat/memstat_uma.c =================================================================== --- lib/libmemstat/memstat_uma.c (revision 208580) +++ lib/libmemstat/memstat_uma.c (working copy) @@ -208,6 +208,7 @@ mtp->mt_numallocs = uthp->uth_allocs; mtp->mt_numfrees = uthp->uth_frees; mtp->mt_failures = uthp->uth_fails; + mtp->mt_sleeps = uthp->uth_sleeps; for (j = 0; j < maxcpus; j++) { upsp = (struct uma_percpu_stat *)p; @@ -402,6 +403,7 @@ mtp->mt_numallocs = uz.uz_allocs; mtp->mt_numfrees = uz.uz_frees; mtp->mt_failures = uz.uz_fails; + mtp->mt_sleeps = uz.uz_sleeps; if (kz.uk_flags & UMA_ZFLAG_INTERNAL) goto skip_percpu; for (i = 0; i < mp_maxid + 1; i++) { Index: sys/vm/uma_int.h =================================================================== --- sys/vm/uma_int.h (revision 208580) +++ sys/vm/uma_int.h (working copy) @@ -314,7 +314,8 @@ u_int64_t uz_allocs; /* Total number of allocations */ u_int64_t uz_frees; /* Total number of frees */ - u_int64_t uz_fails; /* Total number of alloc failures */ + long unsigned int uz_fails; /* Total number of alloc failures */ + long unsigned int uz_sleeps; /* Total number of alloc sleeps */ u_int32_t uz_flags; /* Flags inherited from kegs */ u_int32_t uz_size; /* Size inherited from kegs */ uint16_t uz_fills; /* Outstanding bucket fills */ Index: sys/vm/uma.h =================================================================== --- sys/vm/uma.h (revision 208580) +++ sys/vm/uma.h (working copy) @@ -600,7 +600,8 @@ u_int64_t uth_allocs; /* Zone: number of allocations. */ u_int64_t uth_frees; /* Zone: number of frees. */ u_int64_t uth_fails; /* Zone: number of alloc failures. */ - u_int64_t _uth_reserved1[3]; /* Reserved. */ + u_int64_t _uth_reserved1[2]; /* Reserved. */ + u_int64_t uth_sleeps; /* Zone: number of alloc sleeps. */ }; struct uma_percpu_stat { Index: sys/vm/uma_core.c =================================================================== --- sys/vm/uma_core.c (revision 208580) +++ sys/vm/uma_core.c (working copy) @@ -249,11 +249,15 @@ void uma_print_zone(uma_zone_t); void uma_print_stats(void); +static int sysctl_vm_zone(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS); static int sysctl_vm_zone_stats(SYSCTL_HANDLER_ARGS); SYSINIT(uma_startup3, SI_SUB_VM_CONF, SI_ORDER_SECOND, uma_startup3, NULL); +SYSCTL_OID(_vm, OID_AUTO, zone, CTLTYPE_STRING|CTLFLAG_RD, + NULL, 0, sysctl_vm_zone, "A", "Zone Info"); + SYSCTL_PROC(_vm, OID_AUTO, zone_count, CTLFLAG_RD|CTLTYPE_INT, 0, 0, sysctl_vm_zone_count, "I", "Number of UMA zones"); @@ -1400,6 +1404,7 @@ zone->uz_allocs = 0; zone->uz_frees = 0; zone->uz_fails = 0; + zone->uz_sleeps = 0; zone->uz_fills = zone->uz_count = 0; zone->uz_flags = 0; keg = arg->keg; @@ -2287,6 +2292,7 @@ */ if (full && !empty) { zone->uz_flags |= UMA_ZFLAG_FULL; + zone->uz_sleeps++; msleep(zone, zone->uz_lock, PVM, "zonelimit", hz/100); zone->uz_flags &= ~UMA_ZFLAG_FULL; continue; @@ -3132,6 +3138,85 @@ } #endif /* DDB */ +/* + * Sysctl handler for vm.zone + * + * stolen from vm_zone.c + */ +static int +sysctl_vm_zone(SYSCTL_HANDLER_ARGS) +{ + int error, len, cnt; + const int linesize = 128; /* conservative */ + int totalfree; + char *tmpbuf, *offset; + uma_zone_t z; + uma_keg_t zk; + char *p; + int cachefree; + uma_bucket_t bucket; + u_int64_t allocs, frees; + + cnt = 0; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) + cnt++; + } + mtx_unlock(&uma_mtx); + MALLOC(tmpbuf, char *, (cnt == 0 ? 1 : cnt) * linesize, + M_TEMP, M_WAITOK); + len = snprintf(tmpbuf, linesize, + "\nITEM SIZE LIMIT USED FREE REQ FAIL SLEEP\n\n"); + if (cnt == 0) + tmpbuf[len - 1] = '\0'; + error = SYSCTL_OUT(req, tmpbuf, cnt == 0 ? len-1 : len); + if (error || cnt == 0) + goto out; + offset = tmpbuf; + mtx_lock(&uma_mtx); + LIST_FOREACH(zk, &uma_kegs, uk_link) { + LIST_FOREACH(z, &zk->uk_zones, uz_link) { + if (cnt == 0) /* list may have changed size */ + break; + ZONE_LOCK(z); + cachefree = 0; + if (!(zk->uk_flags & UMA_ZFLAG_INTERNAL)) { + uma_zone_sumstat(z, &cachefree, &allocs, &frees); + } else { + allocs = z->uz_allocs; + frees = z->uz_frees; + } + + LIST_FOREACH(bucket, &z->uz_full_bucket, ub_link) { + cachefree += bucket->ub_cnt; + } + totalfree = zk->uk_free + cachefree; + len = snprintf(offset, linesize, + "%-12.12s %6.6u, %6.6u, %6.6u, %6.6u, %8.8llu, %4.4lu, %4.4lu\n", + /*ITEM*/z->uz_name, /*SIZE*/zk->uk_size, + /*LIMIT*/zk->uk_maxpages * zk->uk_ipers, + /*USED*/(zk->uk_ipers * (zk->uk_pages / zk->uk_ppera)) - totalfree, + /*FREE*/totalfree, + /*REQ*/(unsigned long long)allocs, + /*FAIL*/z->uz_fails, + /*SLEEP*/z->uz_sleeps); + ZONE_UNLOCK(z); + for (p = offset + 12; p > offset && *p == ' '; --p) + /* nothing */ ; + p[1] = ':'; + cnt--; + offset += len; + } + } + mtx_unlock(&uma_mtx); + *offset++ = '\0'; + error = SYSCTL_OUT(req, tmpbuf, offset - tmpbuf); +out: + FREE(tmpbuf, M_TEMP); + return (error); +} + static int sysctl_vm_zone_count(SYSCTL_HANDLER_ARGS) { @@ -3236,6 +3321,7 @@ uth.uth_allocs = z->uz_allocs; uth.uth_frees = z->uz_frees; uth.uth_fails = z->uz_fails; + uth.uth_sleeps = z->uz_sleeps; if (sbuf_bcat(&sbuf, &uth, sizeof(uth)) < 0) { ZONE_UNLOCK(z); mtx_unlock(&uma_mtx); --------------030108020004090702040307 Content-Type: application/octet-stream; name="vmstat-z.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vmstat-z.diff.sig" iQEcBAABAgAGBQJL/cGrAAoJEJBXh4mJ2FR+OKEIAJonhKdbXekseQv6caOe7uLdJlv+nd8w ypyc/O85lTtN+6ZsUOa+hE+lCiLAdtX4gNCN33PlxJP+mV2x0VY1P6zqRsbVYn2LicfFpis9 4bbrX77JEO6DKXhwyjotTTBZ/B8wQ9SDEqifM1oNGEnROY69zyhmDKH+GEdnz7i/CUvIha8Y sATAF+aEhJv5DHa60r0JMu8tbVrzyB5tyBNWMcZZvXPQMl1elrFCqkDlAiec+QgVixRupT8X nD0OurUOL0Fnk0AiiG1tGilk5radR7yA7drfjZuUV20Cobi4jTqGxAQUDtAW5T39ayiJP5Fg wYK/PY2ize9jKFAEdZeeyCA= --------------030108020004090702040307 Content-Type: application/octet-stream; name="sleep_stat_stable8_r208580.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sleep_stat_stable8_r208580.diff.sig" iQEcBAABAgAGBQJL/cGrAAoJEJBXh4mJ2FR+A+QH/iv53Ra7coIY2sNHxbKyRm26lTe3HaU9 blb6x7Jw9Kku688Gti/F9sYhUhz/UIlJk4XF3hcGNxU4E4FgIGHZtCBLESISzRzQV28cbLq1 q0uUZsOL4Z/TcLBUAxmrDtyHmPDuYDGkSNX+A/vP0aw+YoBn0qWOPED2dEOsA9gHhJ7B+4eu lmBxrUR3X6cAzMxfbX4ZEV/6XwhXfLwK20MTz7cBVnzlhLki9ZIPCgVVX+u6l3whW2hloY+W DFiiokn/9ITMAlhHWuALqsqyvB3NOs46s7POaf4qorZUo4Mc6VN4QXrgWLvjxvsRpKoYycMF 8qZO10Mt/Z14060u8i1TwCU= --------------030108020004090702040307-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 02:09:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA7851065672 for ; Thu, 27 May 2010 02:09:41 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 46E8C8FC13 for ; Thu, 27 May 2010 02:09:41 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [141.76.6.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id D0C9B8A1E25; Thu, 27 May 2010 04:09:39 +0200 (CEST) Message-ID: <4BFDD460.30300@bsdforen.de> Date: Thu, 27 May 2010 04:09:36 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Rui Paulo References: <4BF7C455.6040806@bsdforen.de> <4BF7CDC3.8050908@bsdforen.de> <95EA8683-E0AD-48DF-9148-8DE3E368F26C@lavabit.com> <4BFCC5ED.6080909@bsdforen.de> <88D963CA-DB03-4FA3-B770-0EB4638D7A48@lavabit.com> In-Reply-To: <88D963CA-DB03-4FA3-B770-0EB4638D7A48@lavabit.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" Subject: Re: Activate PCIe slot deactivated by BIOS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 02:09:41 -0000 On 26/05/2010 22:52, Rui Paulo wrote: > On 26 May 2010, at 07:55, Dominic Fandrey wrote: > >> On 25/05/2010 13:57, Rui Paulo wrote: >>> On 22 May 2010, at 13:27, Dominic Fandrey wrote: >>> >>>> On 22/05/2010 13:47, Dominic Fandrey wrote: >>>>> Today the card arrived and the BIOS complains (HP 6510b): >>>>> 104-Unsupported wireless network device detected. >>>>> System halted. Remove device and restart. >>>>> >>>>> The system boots if I turn off the wireless device in BIOS, but >>>>> this means I cannot use it. >>>>> >>>>> Now, I could just get a BIOS image and exchange the device IDs >>>>> there. But I wonder, wouldn't it be easier to just reactivate the >>>>> PCIe slot through the OS? >>>> >>>> This e-mail is written through the ath wireless I got: >>>> >>>> # ifconfig >>>> ath0: flags=8843 metric 0 >>>> mtu 2290 >>>> ether 00:24:2c:1d:f0:2f >>>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>>> status: associated >>>> ... >>>> wlan0: flags=8843 metric 0 >>>> mtu 1500 >>>> ether 00:24:2c:1d:f0:2f >>>> inet 192.168.178.41 netmask 0xffffff00 broadcast 192.168.178.255 >>>> media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g >>>> status: associated >>>> ssid "Obi-Wan Kenobi" channel 7 (2442 MHz 11g) bssid >>>> 00:15:0c:d5:37:a0 >>>> regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON >>>> deftxkey UNDEF AES-CCM 2:128-bit txpower 20 bmiss 7 scanvalid 450 >>>> bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 >>>> protmode CTS wme burst roaming MANUAL >>>> >>>> I achieved this by passing the BIOS check with the intel wireless and >>>> hot-swapping it with the atheros card afterwards. This is impractical >>>> and evil, so I'm still searching for a solution. >>>> >>>> But at least I know that the device works. >>> >>> HP laptops really dislike the fact that your card isn't part of the >>> Centrino brand, so they halt if they find an Atheros. Your best >>> option is to change the Atheros card EEPROM to match the device and >>> vendor id of your wpi card. Then you also need to change the ath >>> driver to attach to that device id. >>> >>> It's evil, but it's better than hot-swapping. >> >> Yes, but it still sucks. And I actually have no idea how to flash the >> ath device. All the instructions on this I have found use Linux. > > Please ask sam@FreeBSD.org about that. > >> >> I'd prefer to flash the notebook BIOS, but I have no way to defeat >> its evil compression. > > I think flashing the bios is more risky than fixing the EEPROM. Yes, it's a philosophical thing. By flashing the BIOS I address the error. By changing the wireles EEPROM I counter the error with another error. >>> The other option is to buy a iwn card which works better in FreeBSD >>> than wpi. >> >> Nay, this is my goodbye to Intel brand wireless. I always thought >> wpa_supplicant was to blame for unreliable connections, but it >> all just works with the Atheros hardware. > > Intel has made progress and I really think that they are on the right > track to produce good cards. While wpi is the first one in my care that does not work at all, all other Intel brand wireless devices in my use have proven to be at least unreliable. So what if they work reliable one day. The Atheros I got is reliable, now! Not in a far fetched future that might never actually come to be. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 08:35:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A450A106568A; Thu, 27 May 2010 08:35:39 +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 57C5A8FC1E; Thu, 27 May 2010 08:35:37 +0000 (UTC) Received: from porto.topspin.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 LAA13679; Thu, 27 May 2010 11:35:36 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OHYYx-000O7i-Vp; Thu, 27 May 2010 11:35:36 +0300 Message-ID: <4BFE2ED6.1070402@freebsd.org> Date: Thu, 27 May 2010 11:35:34 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Robert Noland , freebsd-fs@freebsd.org References: <4BEBA334.6080101@icyb.net.ua> <4BEC040E.9080303@FreeBSD.org> In-Reply-To: <4BEC040E.9080303@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Roman Divacky Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 08:35:39 -0000 I think I nailed this problem now. What was additionally needed was the following change: if (!vdev || !vdev->v_read) return (EIO); - if (vdev->v_read(vdev, bp, &zio_gb, offset, SPA_GANGBLOCKSIZE)) + if (vdev->v_read(vdev, NULL, &zio_gb, offset, SPA_GANGBLOCKSIZE)) return (EIO); Full patch is here: http://people.freebsd.org/~avg/boot-zfs-gang.diff Apparently I am not as smart as Roman :) because I couldn't find the bug by just starring at this rather small function (for couple of hours), so I had to reproduce the problem to catch it. Hence I am copying hackers@ to share couple of tricks that were new to me. Perhaps, they could help someone else some other day. First, after very helpful hints that I received in parallel from pjd and two Oracle/Sun developers it became very easy to reproduce a pool with files with gang blocks in them. One can set metaslab_gang_bang variable in metaslab.c to some value < 128K and then blocks with size greater than metaslab_gang_bang will be allocated as gang blocks with 25% chance. I personally did something similar but slightly more deterministic: --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c @@ -1572,6 +1572,12 @@ zio_dva_allocate(zio_t *zio) ASSERT3U(zio->io_prop.zp_ndvas, <=, spa_max_replication(spa)); ASSERT3U(zio->io_size, ==, BP_GET_PSIZE(bp)); + /*XXX XXX XXX XXX*/ + if (zio->io_size > 8 * 1024) { + return (zio_write_gang_block(zio)); + } + /*XXX XXX XXX XXX*/ + error = metaslab_alloc(spa, mc, zio->io_size, bp, zio->io_prop.zp_ndvas, zio->io_txg, NULL, 0); This ensured that any block > 8K would be a gang block. Then I compiled zfs.ko with this change and put it into a virtual machine where I created a pool and populated its root/boot filesystem with /boot directory. Booted in virtual machine from the new virtual disk and immediately hit the problem. So far, so good, but still no clue why zfsboot crashes upon encountering a gang block. So I decided to debug the crash with gdb. Standard steps: $ qemu ... -S -s $ gdb ... (gdb) target remote localhost:1234 Now I didn't want to single-step through the whole boot process, so I decided to get some help from gdb. Here's a trick: (gdb) add-symbol-file /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot.out 0xa000 gptzfsboot.out is an ELF image produced by GCC, which then gets transformed into a raw binary and then into final BTX binary (gptzfsboot). gptzfsboot.out is built without much debugging data but at least it contains information about function names. Perhaps it's even possible to compile gptzfsboot.out with higher debug level, then debugging would be much more pleasant. 0xA000 is where _code_ from gptzfsboot.out ends up being loaded in memory. BTW, having only shallow knowledge about boot chain and BTX I didn't know this address. Another GDB trick helped me: (gdb) append memory boot.memdump 0x0 0x10000 This command dumps memory content in range 0x0-0x10000 to a file named boot.memdump. Then I produced a hex dump and searched for byte sequence with which gptzfsboot.bin starts (raw binary produced produced from gptzfsboot.out). Of course, memory dump should be taken after gptzfsboot is loaded into memory :) Catching the right moment requires a little bit of boot process knowledge. I caught it with: (gdb) b *0xC000 That is, memory dump was taken after gdb stopped at the above break point. After that it was a piece of cake. I set break point on zio_read_gang function (after add-symbol-file command) and the stepi-ed through the code (that is, instruction by instruction). The following command made it easier to see what's getting executed: (gdb) display/i 0xA000 + $eip I quickly stepped though the code and saw that a large value was passed to vdev_read as 'bytes' parameter. But this should have been 512. The oversized read into a buffer allocated on stack smashed the stack and that was the end. Backtracking the call chain in source code I immediately noticed the bp condition in vdev_read_phys and realized what the problem was. Hope this would be a useful reading. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 14:35:19 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9574F106566C; Thu, 27 May 2010 14:35:19 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 659018FC1A; Thu, 27 May 2010 14:35:19 +0000 (UTC) Received: from [10.170.20.44] (nat-170-142-177-44.tn.gov [170.142.177.44]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o4REZGAd016324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 May 2010 10:35:17 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) Message-ID: <4BFE8306.6030006@FreeBSD.org> Date: Thu, 27 May 2010 09:34:46 -0500 From: Robert Noland Organization: FreeBSD User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: Andriy Gapon References: <4BEBA334.6080101@icyb.net.ua> <4BEC040E.9080303@FreeBSD.org> <4BFE2ED6.1070402@freebsd.org> In-Reply-To: <4BFE2ED6.1070402@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.6 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Roman Divacky Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 14:35:19 -0000 Andriy Gapon wrote: > > I think I nailed this problem now. > What was additionally needed was the following change: > if (!vdev || !vdev->v_read) > return (EIO); > - if (vdev->v_read(vdev, bp, &zio_gb, offset, SPA_GANGBLOCKSIZE)) > + if (vdev->v_read(vdev, NULL, &zio_gb, offset, SPA_GANGBLOCKSIZE)) > return (EIO); > > Full patch is here: > http://people.freebsd.org/~avg/boot-zfs-gang.diff > > Apparently I am not as smart as Roman :) because I couldn't find the bug by just > starring at this rather small function (for couple of hours), so I had to > reproduce the problem to catch it. Hence I am copying hackers@ to share couple > of tricks that were new to me. Perhaps, they could help someone else some other > day. Excellent, I'm glad that this is finally tested and seems to be working. When I initially added the code, I wasn't able to test it and it turned out the the issue that I was trying to resolve wasn't actually gang block related anyway. robert. > First, after very helpful hints that I received in parallel from pjd and two > Oracle/Sun developers it became very easy to reproduce a pool with files with > gang blocks in them. > One can set metaslab_gang_bang variable in metaslab.c to some value < 128K and > then blocks with size greater than metaslab_gang_bang will be allocated as gang > blocks with 25% chance. I personally did something similar but slightly more > deterministic: > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c > @@ -1572,6 +1572,12 @@ zio_dva_allocate(zio_t *zio) > ASSERT3U(zio->io_prop.zp_ndvas, <=, spa_max_replication(spa)); > ASSERT3U(zio->io_size, ==, BP_GET_PSIZE(bp)); > > + /*XXX XXX XXX XXX*/ > + if (zio->io_size > 8 * 1024) { > + return (zio_write_gang_block(zio)); > + } > + /*XXX XXX XXX XXX*/ > + > error = metaslab_alloc(spa, mc, zio->io_size, bp, > zio->io_prop.zp_ndvas, zio->io_txg, NULL, 0); > > This ensured that any block > 8K would be a gang block. > Then I compiled zfs.ko with this change and put it into a virtual machine where > I created a pool and populated its root/boot filesystem with /boot directory. > Booted in virtual machine from the new virtual disk and immediately hit the problem. > > So far, so good, but still no clue why zfsboot crashes upon encountering a gang > block. > > So I decided to debug the crash with gdb. > Standard steps: > $ qemu ... -S -s > $ gdb > ... > (gdb) target remote localhost:1234 > > Now I didn't want to single-step through the whole boot process, so I decided to > get some help from gdb. Here's a trick: > (gdb) add-symbol-file /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot.out > 0xa000 > > gptzfsboot.out is an ELF image produced by GCC, which then gets transformed into > a raw binary and then into final BTX binary (gptzfsboot). > gptzfsboot.out is built without much debugging data but at least it contains > information about function names. Perhaps it's even possible to compile > gptzfsboot.out with higher debug level, then debugging would be much more pleasant. > > 0xA000 is where _code_ from gptzfsboot.out ends up being loaded in memory. > BTW, having only shallow knowledge about boot chain and BTX I didn't know this > address. Another GDB trick helped me: > (gdb) append memory boot.memdump 0x0 0x10000 > > This command dumps memory content in range 0x0-0x10000 to a file named > boot.memdump. Then I produced a hex dump and searched for byte sequence with > which gptzfsboot.bin starts (raw binary produced produced from gptzfsboot.out). > > Of course, memory dump should be taken after gptzfsboot is loaded into memory :) > Catching the right moment requires a little bit of boot process knowledge. > I caught it with: > (gdb) b *0xC000 > > That is, memory dump was taken after gdb stopped at the above break point. > > After that it was a piece of cake. I set break point on zio_read_gang function > (after add-symbol-file command) and the stepi-ed through the code (that is, > instruction by instruction). The following command made it easier to see what's > getting executed: > (gdb) display/i 0xA000 + $eip > > I quickly stepped though the code and saw that a large value was passed to > vdev_read as 'bytes' parameter. But this should have been 512. The oversized > read into a buffer allocated on stack smashed the stack and that was the end. > > Backtracking the call chain in source code I immediately noticed the bp > condition in vdev_read_phys and realized what the problem was. > > Hope this would be a useful reading. From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 15:03:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228C0106567C; Thu, 27 May 2010 15:03:18 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC928FC19; Thu, 27 May 2010 15:03:16 +0000 (UTC) Received: by fxm20 with SMTP id 20so95309fxm.13 for ; Thu, 27 May 2010 08:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.158.133 with SMTP id u5mr978444hbc.179.1274971207933; Thu, 27 May 2010 07:40:07 -0700 (PDT) Received: by 10.239.153.73 with HTTP; Thu, 27 May 2010 07:40:07 -0700 (PDT) In-Reply-To: <4BFE2ED6.1070402@freebsd.org> References: <4BEBA334.6080101@icyb.net.ua> <4BEC040E.9080303@FreeBSD.org> <4BFE2ED6.1070402@freebsd.org> Date: Thu, 27 May 2010 15:40:07 +0100 Message-ID: From: Doug Rabson To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Roman Divacky , Robert Noland Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 15:03:18 -0000 On 27 May 2010 09:35, Andriy Gapon wrote: > > > I think I nailed this problem now. > What was additionally needed was the following change: > if (!vdev || !vdev->v_read) > return (EIO); > - if (vdev->v_read(vdev, bp, &zio_gb, offset, SPA_GANGBLOCKSIZE)) > + if (vdev->v_read(vdev, NULL, &zio_gb, offset, SPA_GANGBLOCKSIZE)) > return (EIO); > > Full patch is here: > http://people.freebsd.org/~avg/boot-zfs-gang.diff > > Apparently I am not as smart as Roman :) because I couldn't find the bug by > just > starring at this rather small function (for couple of hours), so I had to > reproduce the problem to catch it. Hence I am copying hackers@ to share > couple > of tricks that were new to me. Perhaps, they could help someone else some > other > day. > > First, after very helpful hints that I received in parallel from pjd and > two > Oracle/Sun developers it became very easy to reproduce a pool with files > with > gang blocks in them. > One can set metaslab_gang_bang variable in metaslab.c to some value < 128K > and > then blocks with size greater than metaslab_gang_bang will be allocated as > gang > blocks with 25% chance. I personally did something similar but slightly > more > deterministic: > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c > @@ -1572,6 +1572,12 @@ zio_dva_allocate(zio_t *zio) > ASSERT3U(zio->io_prop.zp_ndvas, <=, spa_max_replication(spa)); > ASSERT3U(zio->io_size, ==, BP_GET_PSIZE(bp)); > > + /*XXX XXX XXX XXX*/ > + if (zio->io_size > 8 * 1024) { > + return (zio_write_gang_block(zio)); > + } > + /*XXX XXX XXX XXX*/ > + > error = metaslab_alloc(spa, mc, zio->io_size, bp, > zio->io_prop.zp_ndvas, zio->io_txg, NULL, 0); > > This ensured that any block > 8K would be a gang block. > Then I compiled zfs.ko with this change and put it into a virtual machine > where > I created a pool and populated its root/boot filesystem with /boot > directory. > Booted in virtual machine from the new virtual disk and immediately hit the > problem. > > So far, so good, but still no clue why zfsboot crashes upon encountering a > gang > block. > > So I decided to debug the crash with gdb. > Standard steps: > $ qemu ... -S -s > $ gdb > ... > (gdb) target remote localhost:1234 > > Now I didn't want to single-step through the whole boot process, so I > decided to > get some help from gdb. Here's a trick: > (gdb) add-symbol-file > /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot.out > 0xa000 > > gptzfsboot.out is an ELF image produced by GCC, which then gets transformed > into > a raw binary and then into final BTX binary (gptzfsboot). > gptzfsboot.out is built without much debugging data but at least it > contains > information about function names. Perhaps it's even possible to compile > gptzfsboot.out with higher debug level, then debugging would be much more > pleasant. > > 0xA000 is where _code_ from gptzfsboot.out ends up being loaded in memory. > BTW, having only shallow knowledge about boot chain and BTX I didn't know > this > address. Another GDB trick helped me: > (gdb) append memory boot.memdump 0x0 0x10000 > > This command dumps memory content in range 0x0-0x10000 to a file named > boot.memdump. Then I produced a hex dump and searched for byte sequence > with > which gptzfsboot.bin starts (raw binary produced produced from > gptzfsboot.out). > > Of course, memory dump should be taken after gptzfsboot is loaded into > memory :) > Catching the right moment requires a little bit of boot process knowledge. > I caught it with: > (gdb) b *0xC000 > > That is, memory dump was taken after gdb stopped at the above break point. > > After that it was a piece of cake. I set break point on zio_read_gang > function > (after add-symbol-file command) and the stepi-ed through the code (that is, > instruction by instruction). The following command made it easier to see > what's > getting executed: > (gdb) display/i 0xA000 + $eip > > I quickly stepped though the code and saw that a large value was passed to > vdev_read as 'bytes' parameter. But this should have been 512. The > oversized > read into a buffer allocated on stack smashed the stack and that was the > end. > > Backtracking the call chain in source code I immediately noticed the bp > condition in vdev_read_phys and realized what the problem was. > > Hope this would be a useful reading. > Excellent work - thanks for looking into this. I still think its easier to debug this code in userland using a shim that redirects the zfsboot i/o calls to simple read system calls... From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 15:13:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5226106564A; Thu, 27 May 2010 15:13:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 956BE8FC15; Thu, 27 May 2010 15:13:20 +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 SAA22282; Thu, 27 May 2010 18:13:12 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BFE8C07.9010303@icyb.net.ua> Date: Thu, 27 May 2010 18:13:11 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Doug Rabson References: <4BEBA334.6080101@icyb.net.ua> <4BEC040E.9080303@FreeBSD.org> <4BFE2ED6.1070402@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Robert Noland Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 15:13:21 -0000 on 27/05/2010 17:40 Doug Rabson said the following: > > Excellent work - thanks for looking into this. I still think its easier > to debug this code in userland using a shim that redirects the zfsboot > i/o calls to simple read system calls... Absolutely! That should much easier. Do you have such a shim that you could share? I'd be much obliged for it. And not only I, I think. Thanks! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 22:53:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B25231065676 for ; Thu, 27 May 2010 22:53:41 +0000 (UTC) (envelope-from rank1seeker@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 444178FC08 for ; Thu, 27 May 2010 22:53:40 +0000 (UTC) Received: by fxm20 with SMTP id 20so607566fxm.13 for ; Thu, 27 May 2010 15:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=EAA05qBsKyDRVwskXyCtYVjST5IihMXY4EU/AfAA+E4=; b=RZYzsMORni2I56WwZgLeCbyPdcA/IGVjfTCy/d0ONUs1Kdu07J7tlzfR8Gbo5Y637k wOrF2Q2RlHLiwWFQHdMKW0N/p3Gk8AhyjRfAs8HudrTkCOT8CgjDdeZgzoYSF8kg8zHh ihUZppavkHtyg78ogNEtZ6e0tgRe5Mfj4nvUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=EMtEZCtslNDsGa/XnrHQXfGkQOmw7PbvcMIiFAIG+oEukPrMuabYSk2OENBHWszfty 8zIERgZs7wzMdLymO4r9H1LsOCn2uVXw/80mfXjj3dItwPGYDXpl24RkXlbzS9iwYT/h xWSqWWirbK47dFp9OSGROS2tEarJqqq7dC3Gg= MIME-Version: 1.0 Received: by 10.223.29.156 with SMTP id q28mr3696031fac.77.1275000820081; Thu, 27 May 2010 15:53:40 -0700 (PDT) Received: by 10.223.118.10 with HTTP; Thu, 27 May 2010 15:53:39 -0700 (PDT) In-Reply-To: References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> <4BEDCB32.8070206@buffalo.edu> Date: Fri, 28 May 2010 00:53:39 +0200 Message-ID: From: none none To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 22:53:41 -0000 Still no answer? Hey, there is also a thread: http://forums.freebsd.org/showthread.php?t=14059 From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 23:02:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6C751065677 for ; Thu, 27 May 2010 23:02:23 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.221.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7D78E8FC16 for ; Thu, 27 May 2010 23:02:23 +0000 (UTC) Received: by qyk5 with SMTP id 5so857919qyk.3 for ; Thu, 27 May 2010 16:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9LAdc8Yh6bmY2vw/9YKkzcxqR40pNBSQSpT5CzVqQzc=; b=tdguynwO9MOwjsVD3hZ7l4K3oP3LXILis8/dqW6jQ8MG+Hj41RrMdlGfkMB/+5pLuJ 1vCoHdBudZgikkC349wASEkDZ+7NFB7I1GwX6UKgFne8zQ5cbXtIFixVpKpR56kKHXv0 7UYBdfYgFBo8vesAITfeYxpDBEHqIP8hC4nnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iZGd/b/J1rHAeQeLYkoaZmNjzDjRdcFFMLFD/TnZEtHLWtIJgoXYAly7Y/NpVdv38Y u07XcFMWxztmKCwwqB2Qj06d5GWgUpT61XAaFIhtlAFLYdpbXZB31Gd0jxBdIloFPurp 7DzvWc1gERCQC/gKo5AX6GrkqAH4i7c808HMY= MIME-Version: 1.0 Received: by 10.229.229.132 with SMTP id ji4mr2489092qcb.167.1275001342531; Thu, 27 May 2010 16:02:22 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Thu, 27 May 2010 16:02:22 -0700 (PDT) In-Reply-To: References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> <4BEDCB32.8070206@buffalo.edu> Date: Thu, 27 May 2010 16:02:22 -0700 Message-ID: From: Garrett Cooper To: none none Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 23:02:23 -0000 On Thu, May 27, 2010 at 3:53 PM, none none wrote: > Still no answer? > > Hey, there is also a thread: > http://forums.freebsd.org/showthread.php?t=14059 Hate to say but you're doing something unsupported, so unless you walk through the process by yourself to figure out where things are going wrong, I'm not sure others have the time to help you in this endeavor. sysinstall(8) assumes a custom environment and setup; trying to unravel it would be painful, so I don't suggest doing that. If you're going to roll your own solution you might as well roll the entire thing from scratch. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu May 27 23:49:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECFFD106564A for ; Thu, 27 May 2010 23:49:07 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailB.acsu.buffalo.edu (localmailB.acsu.buffalo.edu [128.205.5.200]) by mx1.freebsd.org (Postfix) with ESMTP id ABCB18FC0C for ; Thu, 27 May 2010 23:49:07 +0000 (UTC) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E88CA17EE54 for ; Thu, 27 May 2010 19:41:42 -0400 (EDT) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailB.acsu.buffalo.edu (Postfix) with ESMTP id 2F00D17EF57 for ; Thu, 27 May 2010 19:41:42 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailB.acsu.buffalo.edu (Prefixe) with ESMTP id 295CF17EE54 for ; Thu, 27 May 2010 19:41:42 -0400 (EDT) Received: from ken-smiths-macbook-pro.local (cpe-76-180-182-44.buffalo.res.rr.com [76.180.182.44]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id D25AA4C4006 for ; Thu, 27 May 2010 19:41:41 -0400 (EDT) Message-ID: <4BFF0332.7040404@buffalo.edu> Date: Thu, 27 May 2010 19:41:38 -0400 From: Ken Smith User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> <4BEDCB32.8070206@buffalo.edu> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PM-EL-Spam-Prob: XX: 27% Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 23:49:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/15/10 8:01 AM, none none wrote: > On Sat, May 15, 2010 at 12:14 AM, Ken Smith wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 5/14/10 1:16 PM, none none wrote: >>> I've read it, all. >>> What he is proposing, is about building our own image flavor. (make-memstick.sh) >>> Exactly, that act, is an issue here, as it confuses sysinstall's USB detection. >> >> This part of what you say confuses me. I use make-memstick.sh to build >> the .img files people are downloading and using to do installs with. >> So if you are using it correctly any machine that can use the .img >> files I build and we distribute should be able to use what you >> produce. > > Ah, I was unclear. When I've put "make-memstick.sh", in bracket, I was > referring to similarity of steps. > Not to the usage, of actual make-memstick.sh script. > > There are 2 types of customizations: > A) Content (All in UFS) > B) Layout (MBR, slices, boot code, bsdlabel,...) > > make-memstick.sh script is limited only to customization of A), so I > am not using it. > And shell command which I utilize are far more complex. > > I do A) and B) customizations, where B) is a culprit, that confuses sysinstall. > > Focus on this: > Official FreeBSD memstick.img once 'dd'-ed appears as da0a > My edition appears as da0s2a ( because of me doing B) ) > > Once I turn on my machine, at boot time I select USB as a boot device. > Then: BIOS -> MBR of da0 -> slice 2 -> boot loader -> sysinstall > > Now, while in sysinstall, I decide to go in Fixit mode. > When I select a USB device, I get an error msg: > "No USB devices found!" > > Other parts of sysinstall, DO list ad4 (my HDD) and da0 (my USB stick) > correctly. With respect to your "Still no answer" message I'm not sure what you're expecting for an answer. You answer yourself above. The customizations you're doing that you refer to as "B" do indeed confuse sysinstall's disk recognition semantics. As part of your customizations you'll need to adjust sysinstall's disk recognition semantics to understand the layout you are setting up. I'm not quite sure what else you are expecting. I can't think of some easy fix that would get you past the problem you are experiencing without some hacking done to sysinstall. I'm also not sure if that sort of hacking would be suitable for the general case (what works now). - -- Ken Smith - - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv/AzIACgkQ/G14VSmup/a6AgCeKkm2mP3H47jOjHVpU90I7gDy t3MAmwYxKxaoHbwsBrgmX27M6DqzbmZd =03Ri -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 28 00:27:24 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A681065674 for ; Fri, 28 May 2010 00:27:24 +0000 (UTC) (envelope-from rank1seeker@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 C59D58FC12 for ; Fri, 28 May 2010 00:27:23 +0000 (UTC) Received: by fxm20 with SMTP id 20so657032fxm.13 for ; Thu, 27 May 2010 17:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=1dVFYV1QfQ8kDiQy6vrF//tdnYBQRlDAVFOxvWhOJ/s=; b=ZxQ81PxZgAwkKjB/qgcf79Iem3ViiiY22u3XNnOK8RjedzNWU8cYTS2GvDL/AL02s2 xaF6zW4s4PN808mZIaANMb0yMKiBqP2wnowTg1W8hO4W/sTnqyP9yLSGZGcvIWXxmF5t k3Mg5xtRXQY2FjDzgGkAkm+5ttxyFi8Zxufug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XnARzXw81EOXDGtkRfaMNaJizv+Gk3gU8JL+QAHn6oePhTEQS4ZAlo6O/gDRUnkvpU qMaaXAwpmMjFxa6XYA902deD3HyTRuhHIPJ39uXkxB2DtMKGgVI8YPADtAFogZJt+W7q x2vEcbCZF/SukpTnfGvUrk8Jz1znNjFVv7idk= MIME-Version: 1.0 Received: by 10.223.45.22 with SMTP id c22mr1258378faf.107.1275006442514; Thu, 27 May 2010 17:27:22 -0700 (PDT) Received: by 10.223.118.10 with HTTP; Thu, 27 May 2010 17:27:22 -0700 (PDT) In-Reply-To: References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> <4BEDCB32.8070206@buffalo.edu> Date: Fri, 28 May 2010 02:27:22 +0200 Message-ID: From: "Domagoj S." To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 00:27:24 -0000 On Fri, May 28, 2010 at 1:02 AM, Garrett Cooper wrote: > On Thu, May 27, 2010 at 3:53 PM, none none wrote: >> Still no answer? >> >> Hey, there is also a thread: >> http://forums.freebsd.org/showthread.php?t=14059 > > Hate to say but you're doing something unsupported, so unless you walk > through the process by yourself to figure out where things are going > wrong, I'm not sure others have the time to help you in this endeavor. I did found and posted code snippet that is responsible for detecting devices. But I have no C lang knowledge needed to do any coding. I know PHP and JS, ..., so have been observing patterns and echo-ed text/strings to terminal > sysinstall(8) assumes a custom environment and setup; trying to > unravel it would be painful, so I don't suggest doing that. sysinstall(8) expects precise enviroment. Anything deviating from it's hardcoded path is being ignored. > If you're going to roll your own solution you might as well roll the entire > thing from scratch. > > Thanks, > -Garrett My solution is to get rid of sysinstall. Idealy, if sysinstall would be skipped upon boot and Fixit# started immediately I have a blueprint in my head, with beginning, that I am hammering here, but without knowledge to code it. > With respect to your "Still no answer" message I'm not sure what > you're expecting for an answer. You answer yourself above. I expected a patch, an .diff, which I would apply to /usr/src/usr.sbin/sysinstall/... And finally recompile it. > The customizations you're doing that you refer to as "B" do indeed > confuse sysinstall's disk recognition semantics. As part of > your customizations you'll need to adjust sysinstall's disk > recognition semantics to understand the layout you are setting > up. I'm not quite sure what else you are expecting. Someone, to do that for me and handed over, to me, on a silver plate. I am not a FreeBSD dev. Hell, I've just entered this list and this is my first "topic"., > I can't think of some easy fix that would get you past the problem you > are experiencing without some hacking done to sysinstall. I'm > also not sure if that sort of hacking would be suitable for > the general case (what works now). > > - -- > Ken Smith I think it would be, as it would just look in a extended way for devices. Thus, covering old ones and satisfying my needs/aims Domagoj S. From owner-freebsd-hackers@FreeBSD.ORG Fri May 28 04:42:49 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA7F106564A for ; Fri, 28 May 2010 04:42:49 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 73DA18FC0A for ; Fri, 28 May 2010 04:42:49 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward2.mail.yandex.net (Yandex) with ESMTP id 8C88C38A9373; Fri, 28 May 2010 08:42:47 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1275021767; bh=Goey993zHxZuGQ2lknnhxBRn4EM5KjNWwVUCP2+gUjo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eHQK+m+2SBO56H5yaG/hWTa3hmpkwI9GZ2i+a04AVLlsSjG/xOFO2LTxI10Q0+v4F KEDatrZIaz0i4LDcDUWpe8BoRIqlvzu/34iPDaFypF6Enr68x2L1L78O1mMbnznTir RUFbELo0Wl2vnd+aMn5rFZWsV8j5DgQmf940Gqfs= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp3.mail.yandex.net (Yandex) with ESMTPSA id 564802780A4; Fri, 28 May 2010 08:42:47 +0400 (MSD) Message-ID: <4BFF49C6.9070004@yandex.ru> Date: Fri, 28 May 2010 08:42:46 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: "Domagoj S." References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> <4BEDCB32.8070206@buffalo.edu> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1275021767 X-Yandex-Spam: 1 X-Yandex-Front: smtp3.mail.yandex.net Cc: freebsd-hackers@freebsd.org Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 04:42:49 -0000 On 28.05.2010 4:27, Domagoj S. wrote: > I did found and posted code snippet that is responsible for detecting devices. > But I have no C lang knowledge needed to do any coding. > I know PHP and JS, ..., so have been observing patterns and echo-ed > text/strings to terminal This code doesn't responsible for detecting devices. Look at "deviceGetAll" function. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Fri May 28 05:08:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C98B21065676; Fri, 28 May 2010 05:08:47 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id 47E2D8FC08; Fri, 28 May 2010 05:08:47 +0000 (UTC) Received: from [127.0.0.1] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.3) with ESMTP id o4S58gWJ088149; Fri, 28 May 2010 08:08:43 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [127.0.0.1] X-AntiVirus: Checked by Dr.Web [version: 6.0.0.03250, engine: 6.0.0.04010, virus records: 1371417, updated: 28.05.2010] Message-ID: <4BFF4F8D.7040504@ukr.net> Date: Fri, 28 May 2010 08:07:25 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: setfb not work with ipv6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 05:08:47 -0000 9.0-CURRENT #0: Sun Apr 11 23:26:21 EEST 2010 amd64 net.my_fibnum: 0 net.add_addr_allfibs: 1 net.fibs: 3 # netstat -rn | grep default default XXX.XXX.XXX.254 UGS 0 37594940 tun1 default 2001:5c0:1400:b::27e8 UGS gif0 # setfib 1 netstat -rn | grep default default 2001:5c0:1400:b::27e8 UGS gif0 # setfib 2 netstat -rn | grep default default 2001:5c0:1400:b::27e8 UGS gif0 # setfib 2 route -n add -inet6 default 2001:470:27:140::1 route: writing to routing socket: File exists add net default: gateway 2001:470:27:140::1: route already in table # setfib 2 route -n add -inet6 default 2001:470:27:140::1 route: writing to routing socket: File exists add net default: gateway 2001:470:27:140::1: route already in table Change routes without setfib # route -n change -inet6 default 2001:470:27:140::1 change net default: gateway 2001:470:27:140::1 # route -n change -inet6 default 2001:5c0:1400:b::27e8 change net default: gateway 2001:5c0:1400:b::27e8 Open PR? From owner-freebsd-hackers@FreeBSD.ORG Fri May 28 05:15:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E68106564A; Fri, 28 May 2010 05:15:41 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id 2ECD58FC0A; Fri, 28 May 2010 05:15:40 +0000 (UTC) Received: from [127.0.0.1] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.3) with ESMTP id o4S5FbTr088598; Fri, 28 May 2010 08:15:37 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [127.0.0.1] X-AntiVirus: Checked by Dr.Web [version: 6.0.0.03250, engine: 6.0.0.04010, virus records: 1371417, updated: 28.05.2010] Message-ID: <4BFF512C.4000807@ukr.net> Date: Fri, 28 May 2010 08:14:20 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: net@freebsd.org References: <4BFF4F8D.7040504@ukr.net> In-Reply-To: <4BFF4F8D.7040504@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: setfb not work with ipv6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 05:15:41 -0000 Sorry... Instead, "add" to read "change"... > # setfib 2 route -n add -inet6 default 2001:470:27:140::1 > route: writing to routing socket: File exists > add net default: gateway 2001:470:27:140::1: route already in table # setfib 2 route -n change -inet6 default 2001:470:27:140::1 route: writing to routing socket: Address family not supported by protocol family change net default: gateway 2001:470:27:140::1: Address family not supported by protocol family From owner-freebsd-hackers@FreeBSD.ORG Fri May 28 14:49:49 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78E331065673; Fri, 28 May 2010 14:49:49 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C52C8FC1F; Fri, 28 May 2010 14:49:48 +0000 (UTC) Received: by vws12 with SMTP id 12so1322673vws.13 for ; Fri, 28 May 2010 07:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.63.68 with SMTP id a4mr307723vci.9.1275058187678; Fri, 28 May 2010 07:49:47 -0700 (PDT) Received: by 10.220.199.134 with HTTP; Fri, 28 May 2010 07:49:47 -0700 (PDT) In-Reply-To: <4BFE8C07.9010303@icyb.net.ua> References: <4BEBA334.6080101@icyb.net.ua> <4BEC040E.9080303@FreeBSD.org> <4BFE2ED6.1070402@freebsd.org> <4BFE8C07.9010303@icyb.net.ua> Date: Fri, 28 May 2010 15:49:47 +0100 Message-ID: From: Doug Rabson To: Andriy Gapon Content-Type: multipart/mixed; boundary=e0cb4e8879015834f40487a89e4e X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Robert Noland Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 14:49:49 -0000 --e0cb4e8879015834f40487a89e4e Content-Type: text/plain; charset=ISO-8859-1 On 27 May 2010 16:13, Andriy Gapon wrote: > on 27/05/2010 17:40 Doug Rabson said the following: > > > > Excellent work - thanks for looking into this. I still think its easier > > to debug this code in userland using a shim that redirects the zfsboot > > i/o calls to simple read system calls... > > Absolutely! That should much easier. > Do you have such a shim that you could share? > I'd be much obliged for it. And not only I, I think. > Thanks! > Attached. I thought I sent it to the list before but perhaps I only sent to one of the participants in the last gang block thread. --e0cb4e8879015834f40487a89e4e Content-Type: application/octet-stream; name="zfstest.c" Content-Disposition: attachment; filename="zfstest.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9r4pi2m0 I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgojaW5jbHVkZSA8c3lzL3F1ZXVlLmg+CiNpbmNsdWRlIDxm Y250bC5oPgojaW5jbHVkZSA8c3RkaW50Lmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8 c3RyaW5nLmg+CiNpbmNsdWRlIDxzdGRhcmcuaD4KI2luY2x1ZGUgPHN0ZGRlZi5oPgojaW5jbHVk ZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxlcnJuby5oPgoKI2RlZmluZSBOQkJZIDgKCnZvaWQKcGFn ZXJfb3V0cHV0KGNvbnN0IGNoYXIgKmxpbmUpCnsKCXByaW50ZigiJXMiLCBsaW5lKTsKfQoKI2lu Y2x1ZGUgInpmc2ltcGwuYyIKCnN0YXRpYyBpbnQKdmRldl9yZWFkKHZkZXZfdCAqdmRldiwgdm9p ZCAqcHJpdiwgb2ZmX3Qgb2ZmLCB2b2lkICpidWYsIHNpemVfdCBieXRlcykKewoJaW50IGZkID0g KihpbnQgKikgcHJpdjsKCglpZiAocHJlYWQoZmQsIGJ1ZiwgYnl0ZXMsIG9mZikgIT0gYnl0ZXMp CgkJcmV0dXJuIC0xOwoJcmV0dXJuIDA7Cn0KCnN0YXRpYyBpbnQKemZzX3JlYWQoc3BhX3QgKnNw YSwgZG5vZGVfcGh5c190ICpkbiwgdm9pZCAqYnVmLCBzaXplX3Qgc2l6ZSwgb2ZmX3Qgb2ZmKQp7 Cgljb25zdCB6bm9kZV9waHlzX3QgKnpwID0gKGNvbnN0IHpub2RlX3BoeXNfdCAqKSBkbi0+ZG5f Ym9udXM7CglzaXplX3QgbjsKCWludCByYzsKCgluID0gc2l6ZTsKCWlmIChvZmYgKyBuID4genAt PnpwX3NpemUpCgkJbiA9IHpwLT56cF9zaXplIC0gb2ZmOwoJCglyYyA9IGRub2RlX3JlYWQoc3Bh LCBkbiwgb2ZmLCBidWYsIG4pOwoJaWYgKHJjKQoJCXJldHVybiAocmMpOwoKCXJldHVybiAobik7 Cn0KCmludAptYWluKGludCBhcmdjLCBjaGFyKiogYXJndikKewoJaW50IGksIG4sIG9mZjsKCWlu dCBmZFs5OV07CglzcGFfdCAqc3BhOwoJZG5vZGVfcGh5c190IGRuOwoJY2hhciBidWZbNTEyXTsK Cgl6ZnNfaW5pdCgpOwoJaWYgKGFyZ2MgPT0gMSkgewoJCXN0YXRpYyBjaGFyICphdltdID0gewoJ CQkiemZzdGVzdCIsICIvZGV2L2RhMHAyIiwgIi9kZXYvZGExcDIiLCAiL2Rldi9kYTJwMiIsCgkJ CU5VTEwsCgkJfTsKCQlhcmdjID0gNDsKCQlhcmd2ID0gYXY7Cgl9Cglmb3IgKGkgPSAxOyBpIDwg YXJnYzsgaSsrKSB7CgkJZmRbaV0gPSBvcGVuKGFyZ3ZbaV0sIE9fUkRPTkxZKTsKCQlpZiAoZmRb aV0gPCAwKQoJCQljb250aW51ZTsKCQlpZiAodmRldl9wcm9iZSh2ZGV2X3JlYWQsICZmZFtpXSwg TlVMTCkgIT0gMCkKCQkJY2xvc2UoZmRbaV0pOwoJfQoJc3BhX2FsbF9zdGF0dXMoKTsKCglzcGEg PSBTVEFJTFFfRklSU1QoJnpmc19wb29scyk7CglpZiAoIXNwYSB8fCB6ZnNfbW91bnRfcG9vbChz cGEpKQoJCWV4aXQoMSk7CgoJaWYgKHpmc19sb29rdXAoc3BhLCAiemZzLmMiLCAmZG4pKQoJCWV4 aXQoMSk7CgoJb2ZmID0gMDsKCWRvIHsKCQluID0gemZzX3JlYWQoc3BhLCAmZG4sIGJ1ZiwgNTEy LCBvZmYpOwoJCXdyaXRlKDEsIGJ1Ziwgbik7CgkJb2ZmICs9IG47Cgl9IHdoaWxlIChuID09IDUx Mik7Cn0K --e0cb4e8879015834f40487a89e4e-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 28 19:37:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF806106564A; Fri, 28 May 2010 19:37:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE5D8FC1D; Fri, 28 May 2010 19:37:06 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o4SJb4YN024744; Fri, 28 May 2010 12:37:04 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id AA8F02D6013; Fri, 28 May 2010 12:37:03 -0700 (PDT) Message-ID: <4C001B6A.8070506@elischer.org> Date: Fri, 28 May 2010 12:37:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Vladislav V. Prodan" References: <4BFF4F8D.7040504@ukr.net> In-Reply-To: <4BFF4F8D.7040504@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org, net@freebsd.org Subject: Re: setfb not work with ipv6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 19:37:06 -0000 On 5/27/10 10:07 PM, Vladislav V. Prodan wrote: > 9.0-CURRENT #0: Sun Apr 11 23:26:21 EEST 2010 amd64 > net.my_fibnum: 0 > net.add_addr_allfibs: 1 > net.fibs: 3 > > # netstat -rn | grep default > default XXX.XXX.XXX.254 UGS 0 37594940 tun1 > default 2001:5c0:1400:b::27e8 UGS gif0 > > > # setfib 1 netstat -rn | grep default > default 2001:5c0:1400:b::27e8 UGS gif0 > # setfib 2 netstat -rn | grep default > default 2001:5c0:1400:b::27e8 UGS gif0 > you are correct. IPV6 does not yet support multiple FIBS. the work is straight forward. basically teh same as done in IPV4 but as I have no IPV6 facility or experience I am reticent to start it without an IPV6 'partner'. > # setfib 2 route -n add -inet6 default 2001:470:27:140::1 > route: writing to routing socket: File exists > add net default: gateway 2001:470:27:140::1: route already in table > > # setfib 2 route -n add -inet6 default 2001:470:27:140::1 > route: writing to routing socket: File exists > add net default: gateway 2001:470:27:140::1: route already in table > > Change routes without setfib > # route -n change -inet6 default 2001:470:27:140::1 > change net default: gateway 2001:470:27:140::1 > # route -n change -inet6 default 2001:5c0:1400:b::27e8 > change net default: gateway 2001:5c0:1400:b::27e8 > > Open PR? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat May 29 12:25:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8C9D106566B for ; Sat, 29 May 2010 12:25:16 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89C508FC20 for ; Sat, 29 May 2010 12:25:16 +0000 (UTC) Received: by pwj4 with SMTP id 4so1175992pwj.13 for ; Sat, 29 May 2010 05:25:15 -0700 (PDT) Received: by 10.115.37.28 with SMTP id p28mr1380805waj.218.1275135913992; Sat, 29 May 2010 05:25:13 -0700 (PDT) Received: from [192.168.20.101] ([119.42.86.40]) by mx.google.com with ESMTPS id 33sm29026573wad.8.2010.05.29.05.25.12 (version=SSLv3 cipher=RC4-MD5); Sat, 29 May 2010 05:25:13 -0700 (PDT) Message-ID: <4C0108F1.5050004@pathscale.com> Date: Sat, 29 May 2010 19:30:41 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Announcing PathDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 12:25:16 -0000 PathScale is slowly open sourcing and porting some of our core software technology and thought the BSD community might be interested in PathDB. Months ago we gave a few FBSD developers private access to the source, but never received any feedback. Now we're asking more people to please test and tell us what you think. Source git clone git://git.pathscale.com/path64/debugger.git Note : We have a small patch which makes it build with gcc-4.3+ that should be pushed soon. License (GPLv3, *BUT* if we get a lot of positive feedback from the BSD community we can change this any time - see below) Benefits * Very well designed * Robust and well tested * Similar interface as GDB * Commercially supported * Recently revived roadmap (We're evaluating things like gpu support, reverse debugging, latest dwarf standards, tight integration with compiler for optimized debugging.. etc) Promise - Give us a hand in testing and improving and we'll relicense to a more permissive license. Questions/comments - Say hi on #pathscale - irc.freenode.net or email me directly Thanks Christopher From owner-freebsd-hackers@FreeBSD.ORG Sat May 29 16:12:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA5DB1065670 for ; Sat, 29 May 2010 16:12:14 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A843B8FC12 for ; Sat, 29 May 2010 16:12:14 +0000 (UTC) Received: by pvg16 with SMTP id 16so1113477pvg.13 for ; Sat, 29 May 2010 09:12:13 -0700 (PDT) Received: by 10.115.144.3 with SMTP id w3mr1599636wan.7.1275149533817; Sat, 29 May 2010 09:12:13 -0700 (PDT) Received: from [192.168.20.101] ([119.42.86.40]) by mx.google.com with ESMTPS id c1sm30620064wam.19.2010.05.29.09.12.11 (version=SSLv3 cipher=RC4-MD5); Sat, 29 May 2010 09:12:12 -0700 (PDT) Message-ID: <4C013E24.6020204@pathscale.com> Date: Sat, 29 May 2010 23:17:40 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: Thordur I Bjornsson , freebsd-hackers@freebsd.org, Michael Dexter References: <4C0108F1.5050004@pathscale.com> <20100529160155.GA3519@anja> In-Reply-To: <20100529160155.GA3519@anja> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Announcing PathDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 16:12:14 -0000 Thordur I Bjornsson wrote: >> PathScale is slowly open sourcing and porting some of our core >> software technology and thought the BSD community might be >> interested in PathDB. Months ago we gave a few FBSD developers >> private access to the source, but never received any feedback. Now >> we're asking more people to please test and tell us what you think. >> > Maybe noone gave you feedback because you are a douchbag ? > > I mean: > >> Promise - Give us a hand in testing and improving and we'll >> relicense to a more permissive license. >> > What kind of a fucked up way of getting free development done on > your shitty little "commercially supported" product is this ? > > Are you on crack ? > Can someone in the FreeBSD community please talk with this guy. If you're going to send a snotty email at least be brave enough to do it publicly.. fwiw.. I never said free anywhere in my email.. It's assumed testing has a reciprocal benefit assuming we fix bugs. I've spoken with 5-10 people in the BSD community and most are supportive of our idea.. They of course wanted the BSD license from the start, but to me this is a conservative approach which I saw as a win/win.. So honestly am I on crack? From owner-freebsd-hackers@FreeBSD.ORG Sat May 29 18:28:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F3D01065670 for ; Sat, 29 May 2010 18:28:50 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 21ED08FC18 for ; Sat, 29 May 2010 18:28:49 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o4TISmGl010471 for ; Sat, 29 May 2010 11:28:48 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C015CE5.1050602@feral.com> Date: Sat, 29 May 2010 11:28:53 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4C0108F1.5050004@pathscale.com> <20100529160155.GA3519@anja> <4C013E24.6020204@pathscale.com> In-Reply-To: <4C013E24.6020204@pathscale.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Sat, 29 May 2010 11:28:48 -0700 (PDT) Subject: Re: Announcing PathDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 18:28:50 -0000 On 5/29/2010 9:17 AM, "C. Bergström" wrote: > > > Can someone in the FreeBSD community please talk with this guy. If > you're going to send a snotty email at least be brave enough to do it > publicly.. Sorry for his rudeness. > > fwiw.. I never said free anywhere in my email.. It's assumed testing > has a reciprocal benefit assuming we fix bugs. I've spoken with 5-10 > people in the BSD community and most are supportive of our idea.. They > of course wanted the BSD license from the start, but to me this is a > conservative approach which I saw as a win/win.. So honestly am I on > crack? > > _ I don't think any of us really know what your product is. I certainly never knew about it. In any case, this list is for discussions for people who are actively working on FreeBSD itself, so perhaps this place isn't the best place for discussing your company's work. From owner-freebsd-hackers@FreeBSD.ORG Sat May 29 18:55:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A881B1065675 for ; Sat, 29 May 2010 18:55:48 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 867208FC14 for ; Sat, 29 May 2010 18:55:48 +0000 (UTC) Received: by pwj4 with SMTP id 4so1282778pwj.13 for ; Sat, 29 May 2010 11:55:48 -0700 (PDT) Received: by 10.115.80.1 with SMTP id h1mr1720837wal.116.1275159347706; Sat, 29 May 2010 11:55:47 -0700 (PDT) Received: from [192.168.20.101] ([119.42.86.40]) by mx.google.com with ESMTPS id 33sm31792430wad.8.2010.05.29.11.55.45 (version=SSLv3 cipher=RC4-MD5); Sat, 29 May 2010 11:55:46 -0700 (PDT) Message-ID: <4C01647A.4060903@pathscale.com> Date: Sun, 30 May 2010 02:01:14 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: Matthew Jacob References: <4C0108F1.5050004@pathscale.com> <20100529160155.GA3519@anja> <4C013E24.6020204@pathscale.com> <4C015CE5.1050602@feral.com> In-Reply-To: <4C015CE5.1050602@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: Announcing PathDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 18:55:48 -0000 Matthew Jacob wrote: > On 5/29/2010 9:17 AM, "C. Bergström" wrote: >> >> >> Can someone in the FreeBSD community please talk with this guy. If >> you're going to send a snotty email at least be brave enough to do it >> publicly.. > Sorry for his rudeness. > >> >> fwiw.. I never said free anywhere in my email.. It's assumed testing >> has a reciprocal benefit assuming we fix bugs. I've spoken with 5-10 >> people in the BSD community and most are supportive of our idea.. >> They of course wanted the BSD license from the start, but to me this >> is a conservative approach which I saw as a win/win.. So honestly am >> I on crack? >> >> _ > > I don't think any of us really know what your product is. I certainly > never knew about it. Apologies.. I didn't really expect anyone to know about it. To me the best way to describe it is similar to gdb, but much cleaner codebase. > > In any case, this list is for discussions for people who are actively > working on FreeBSD itself, so perhaps this place isn't the best place > for discussing your company's work. We're announcing this under a few assumptions #1 It's going to be relicensed to something BSD community finds acceptable. .(not GPL anything) #2 It's going to be ported BSD #3 It'll end up in ports #4 We'll take feedback for features like how to implement kernel level debugging and see if we can help with it I hope this helps clarify a little.. Thanks ./C From owner-freebsd-hackers@FreeBSD.ORG Sat May 29 19:07:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CAF91065676 for ; Sat, 29 May 2010 19:07:52 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 573258FC19 for ; Sat, 29 May 2010 19:07:51 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2FC92.dip.t-dialin.net [217.226.252.146]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id EC62484419C; Sat, 29 May 2010 20:48:40 +0200 (CEST) Received: from unknown (unknown [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 2BF6B5C4A; Sat, 29 May 2010 20:48:38 +0200 (CEST) Date: Sat, 29 May 2010 20:48:35 +0200 From: Alexander Leidinger To: freebsd-hackers@freebsd.org, "C. =?ISO-8859-1?Q?Bergstr=F6m?=" Message-ID: <20100529204835.0000028d@unknown> In-Reply-To: <4C013E24.6020204@pathscale.com> References: <4C0108F1.5050004@pathscale.com> <20100529160155.GA3519@anja> <4C013E24.6020204@pathscale.com> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: EC62484419C.AA1EF X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: netchild@freebsd.org X-EBL-MailScanner-Watermark: 1275763721.34515@Y4H36/0c3eBlJUt6GD65IQ X-EBL-Spam-Status: No Cc: Subject: Re: Announcing PathDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 19:07:52 -0000 On Sat, 29 May 2010 23:17:40 +0700 "C. Bergstr=F6m" wrote: > Thordur I Bjornsson wrote: > >> PathScale is slowly open sourcing and porting some of our core > >> software technology and thought the BSD community might be > >> interested in PathDB. Months ago we gave a few FBSD developers You may want to introduce what it is (people which read careful enough may assume it is a debugger) and explain why it is better than the competition. > Can someone in the FreeBSD community please talk with this guy. If=20 > you're going to send a snotty email at least be brave enough to do it=20 > publicly.. He is for sure not one of the FreeBSD committers. Maybe a troll, so it may be better to just ignore him. > fwiw.. I never said free anywhere in my email.. It's assumed testing=20 > has a reciprocal benefit assuming we fix bugs. I've spoken with 5-10=20 > people in the BSD community and most are supportive of our idea.. > They of course wanted the BSD license from the start, but to me this > is a conservative approach which I saw as a win/win.. So honestly am > I on crack? I don't think your offer to relicense is bad, I just think your introduction of it could have been a little bit more verbose (tell the people something to make them want to have a look at it). Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Sat May 29 19:53:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E6601065670 for ; Sat, 29 May 2010 19:53:53 +0000 (UTC) (envelope-from yanefbsd@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 DC6368FC1C for ; Sat, 29 May 2010 19:53:52 +0000 (UTC) Received: by vws12 with SMTP id 12so3173708vws.13 for ; Sat, 29 May 2010 12:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=conaBnw1sR+zOoz9msVCrbPZ7u8vYyEY/Dm2qjeWSHw=; b=NHjhHypbfD/kwEatuVehRjYQFFqgp3/icn6oWOFoBATr6PCI5k8BHAKx1o2Kb+PW/8 fn7HA+Pj62rwJ/cc09LD7Lf12oZ9wBixcSHR9iKFd1fLVYtLnsnxeKgr0BxtGmmpzuRu GAp/bzsHypwRQ5QQ1ctx4TQ9vz26UukXqnKt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=H2wLIdDYpYesS/qVhl8jM6RkikEBYEhZUHon5wu0RdzutR4B6TRUalcK652IW7gcdq S7pA2CdYKTm/STNigswIsGMyouuLzEEpDUgidvSFmFxXg7Sroa114mren9Gf22TE6sby WXmEimLJwynyshyFYLgfphOwYjsTncuIyztVk= MIME-Version: 1.0 Received: by 10.229.182.1 with SMTP id ca1mr377056qcb.158.1275162831799; Sat, 29 May 2010 12:53:51 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Sat, 29 May 2010 12:53:51 -0700 (PDT) In-Reply-To: <4C0108F1.5050004@pathscale.com> References: <4C0108F1.5050004@pathscale.com> Date: Sat, 29 May 2010 12:53:51 -0700 Message-ID: From: Garrett Cooper To: =?ISO-8859-1?B?Qy4gQmVyZ3N0cvZt?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Hackers , dfr@freebsd.org Subject: Re: Announcing PathDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 19:53:53 -0000 2010/5/29 "C. Bergstr=F6m" : > > PathScale is slowly open sourcing and porting some of our core software > technology and thought the BSD community might be interested in PathDB. > =A0Months ago we gave a few FBSD developers private access to the source,= but > never received any feedback. =A0Now we're asking more people to please te= st > and tell us what you think. > > Source > git clone git://git.pathscale.com/path64/debugger.git > Note : We have a small patch which makes it build with gcc-4.3+ that shou= ld > be pushed soon. > > License (GPLv3, *BUT* if we get a lot of positive feedback from the BSD > community we can change this any time - see below) > > Benefits > =A0 * Very well designed > =A0 * Robust and well tested > =A0 * Similar interface as GDB > =A0 * Commercially supported > =A0 * Recently revived roadmap (We're evaluating things like gpu support, > reverse debugging, latest dwarf standards, tight integration with compile= r > for optimized debugging.. etc) > > Promise - Give us a hand in testing and improving and we'll relicense to = a > more permissive license. > > Questions/comments - Say hi on #pathscale - irc.freenode.net or email me > directly Hi Christopher, Have you spoken with Doug Rabson about this? He has work which is to going to meet a similar end as PathDB could provide. Also, it might be a good time and a good idea to consider going to one of the BSD conferences and presenting PathDB as a useful alternative to gdb (especially if folks provide some degree of interest in your work). I'll take a look at it if I have time. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat May 29 20:17:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21C08106567C for ; Sat, 29 May 2010 20:17:03 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id CA0598FC17 for ; Sat, 29 May 2010 20:17:02 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o4TKHKaC047549; Sat, 29 May 2010 20:17:20 GMT (envelope-from kientzle@freebsd.org) Received: from horton.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id x9g6mfz47pszuzrs453fgyq92a; Sat, 29 May 2010 20:17:19 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4C01763B.6000003@freebsd.org> Date: Sat, 29 May 2010 13:16:59 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20100314 SeaMonkey/1.1.18 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= References: <4C0108F1.5050004@pathscale.com> In-Reply-To: <4C0108F1.5050004@pathscale.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: Announcing PathDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 20:17:03 -0000 Sounds interesting. There has been a lot of interest within the FreeBSD community on getting a complete set of core development tools that are free of GPL. A debugger is obviously a key part of that. Do you have a Wiki page with more details about what it does and how to start using it? What CPUs does it support? What is required to add support for a new CPU? What executable/debugging formats? What is required to add support for new ones? What languages does it support? What is required to add support for new languages? Does it handle the GDB wire protocol? I would recommend that you put together a FreeBSD port and make that available somewhere. That would make it much easier for people to try it out. Especially for a large project like this, it takes a while to build a user base and even longer to build interest among external developers. Please don't be discouraged by the lack of (constructive) feedback so far. Cheers, Tim Kientzle C. Bergström wrote: > > PathScale is slowly open sourcing and porting some of our core software > technology and thought the BSD community might be interested in PathDB. > Months ago we gave a few FBSD developers private access to the source, > but never received any feedback. Now we're asking more people to please > test and tell us what you think. > > Source > git clone git://git.pathscale.com/path64/debugger.git > Note : We have a small patch which makes it build with gcc-4.3+ that > should be pushed soon. > > License (GPLv3, *BUT* if we get a lot of positive feedback from the BSD > community we can change this any time - see below) > > Benefits > * Very well designed > * Robust and well tested > * Similar interface as GDB > * Commercially supported > * Recently revived roadmap (We're evaluating things like gpu support, > reverse debugging, latest dwarf standards, tight integration with > compiler for optimized debugging.. etc) > > Promise - Give us a hand in testing and improving and we'll relicense to > a more permissive license. > > Questions/comments - Say hi on #pathscale - irc.freenode.net or email me > directly > > > Thanks > > Christopher > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >