From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 06:28:02 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 77CF0106566C for ; Mon, 5 Jul 2010 06:28:02 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 063318FC12 for ; Mon, 5 Jul 2010 06:28:01 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o656Rwtl002169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jul 2010 16:28:00 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o656RvYX080136; Mon, 5 Jul 2010 16:27:57 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o656RuC4080135; Mon, 5 Jul 2010 16:27:56 +1000 (EST) (envelope-from peter) Date: Mon, 5 Jul 2010 16:27:56 +1000 From: Peter Jeremy To: Philip Herron Message-ID: <20100705062756.GA80063@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library 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, 05 Jul 2010 06:28:02 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-02 23:53:17 +0100, Philip Herron wrote: >>> Although maybe not helpful but have you considered using >>> automake/libtool instead makes it so much simpler in my opinion. =2E.. >Automake will auto-handle Lex and Yacc files too. And is extremely portabl= e. You are joking, right? Of all the supposedly "portable" build environment tools I've used, GNU autotools is by far the slowest, most bloated and least portable. And when you run into problems, you are faced with trying to follow hundreds of KB of opaque shellscript and obfuscated makefiles. --=20 Peter Jeremy --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwxe2wACgkQ/opHv/APuIffNwCgwY3LdAvqrGvgbuy598zFTA2Z 2PMAnAnimtOSv40FjK9PhcIh+YDpcnIw =GF97 -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 06:43: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 6B976106566C for ; Mon, 5 Jul 2010 06:43:42 +0000 (UTC) (envelope-from dhruvakm@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2239F8FC18 for ; Mon, 5 Jul 2010 06:43:41 +0000 (UTC) Received: by qwg5 with SMTP id 5so2095668qwg.13 for ; Sun, 04 Jul 2010 23:43:36 -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=m8jJ2fCJQ5Gk7uMH8Xg6btX4Do10lv/0Pns9ot6AvlQ=; b=g16VPE+01OwoHDD1O0HruiN2X6kiEugJ4zdn9ieQHodPaA9qvm+z/hgLrlKbFM/1Nw fWbrNEsk/iVoEkD3DhJLD7AMKhaXI8cJzxoNtYvQXAPqPIUx4g/4Lp5602QR2V3Wzw4q JWPRAjIdZEtOSY8rYBvy7/2kJMVTrpuevQnpo= 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=e6kTAmscqmpQsDQaOMAS2ajF8HOXWFbujQTN5be4BLNx74qKINnw2L3RYHmV/FoeYc bgEktkA0/+R3VqIeuCdsm1VL/cgSHipNnm2gmMdrQGyUxjcBzBhxpxWWFJAAR1RSsKv/ n8RVPWu4HWyqSHRcX+SUXM6rSm4qUFMoJavT0= MIME-Version: 1.0 Received: by 10.224.36.92 with SMTP id s28mr1135956qad.337.1278312216324; Sun, 04 Jul 2010 23:43:36 -0700 (PDT) Received: by 10.229.220.16 with HTTP; Sun, 4 Jul 2010 23:43:36 -0700 (PDT) In-Reply-To: <20100705062756.GA80063@server.vk2pj.dyndns.org> References: <20100705062756.GA80063@server.vk2pj.dyndns.org> Date: Mon, 5 Jul 2010 12:13:36 +0530 Message-ID: From: dhruva To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: Philip Herron , freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library 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, 05 Jul 2010 06:43:42 -0000 On Mon, Jul 5, 2010 at 11:57 AM, Peter Jeremy wrote: > On 2010-Jul-02 23:53:17 +0100, Philip Herron wrote: >>>> Although maybe not helpful but have you considered using >>>> automake/libtool instead makes it so much simpler in my opinion. > ... >>Automake will auto-handle Lex and Yacc files too. And is extremely portable. > > You are joking, right? > > Of all the supposedly "portable" build environment tools I've used, > GNU autotools is by far the slowest, most bloated and least portable. > And when you run into problems, you are faced with trying to follow > hundreds of KB of opaque shellscript and obfuscated makefiles. > >From my experience, CMake is the best and hope it gets adopted more widely. I agree the initial effort of getting a cmake based build environment will take sometime but going forward, maintaining it is lot simpler when you care about portability. I do not work for kitware nor anyway involved with cmake apart from being a happy user. Quite a few large projects are moving to cmake. -dhruva From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 09:25: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 5A12B1065670; Mon, 5 Jul 2010 09:25:29 +0000 (UTC) (envelope-from jmorris@namei.org) Received: from tundra.namei.org (tundra.namei.org [65.99.196.166]) by mx1.freebsd.org (Postfix) with ESMTP id E6A488FC0C; Mon, 5 Jul 2010 09:25:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by tundra.namei.org (8.13.1/8.13.1) with ESMTP id o659PKc5027191; Mon, 5 Jul 2010 05:25:20 -0400 Date: Mon, 5 Jul 2010 19:25:20 +1000 (EST) From: James Morris To: "Robert N. M. Watson" In-Reply-To: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> Message-ID: References: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, David Quigley , Trond Myklebust , "J. Bruce Fields" , Chuck Lever , Rick Macklem Subject: Re: Extended attributes for NFSv3 - possible Linux interop 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, 05 Jul 2010 09:25:29 -0000 On Fri, 2 Jul 2010, Robert N. M. Watson wrote: > Something that's always worried me about the Mac OS X and Linux EA APIs > is the namespace issue: in FreeBSD, we have an explicit enumeration of > namespaces reflected in an argument to the system calls -- in our case, > an int, but you could imagine other options. As I recall, Linux (perhaps > also IRIX?) designated "system" EAs via an interpretation of names ('$' > prefix). Mac OS X doesn't do this, or at least, the namespace is > different. I wonder given the portability concerns: would it make sense > to make the NFS wire protocol identify the namespace explicitly, and > then OSes can map to/from their local implementation semantics? Linux > could strip the '$' before putting the name on the wire and select the > system namespace in the RPC, whereas FreeBSD could map its local notion > of EXTATTR_NAMESPACE_SYSTEM into whatever the NFS constant is. Then when > it pops out the other end, mapping back to local semantics would occur. > This seems more likely to get the security right (in FreeBSD, writing to > the system namespace requires a specific privilege in our privilege > system), and is an adequate superset of all the APIs to be useful. [added the Linux maintainers] In my current implementation, the server only provides storage for EAs, and never interprets them. Otherwise, security becomes very difficult and possibly not viable with such a basic general approach (i.e. a side simple protocol). The separate NFSv4 Labeled NFS effort is an example of how to go beyond simple sever storage. At Trond's suggestion, I've implemented a special sever namespace in the Linux code, where all client EAs are stored, so: system.foo on the client is transmitted over the wire as such, and then the server stores the EA in nfsd.system.foo. This is done transparently to the client, and the nfsd. namespace is privileged on the server, and also never interpreted by the server. I'd suggest generalizing this for a specification, to allow for a variety of possible server implementations (including where the server does not even support EAs locally itself). > I'm happy to help contribute to the writing on an Internet Draft and/or > RFC -- the lack of NFS support for EAs (and the EA vs. file fork > confusion) have long caused me frustration, and with systems like > SELinux, our various MAC policies, and all sorts of other things > floating around, there's a strong motivation to fix this ... in a > portable way! I'm just sorry I haven't gotten to this sooner... The IETF process is closed for NFSv3, so in this case, it would be not an ID or RFC. > Could we set up a phone call to chat about all this? Things are really > busy here this summer, both for good and bad reasons, but a phone call > on East Coast time is usually arrangeable for me (I'm mostly on British > time). I'm in Sydney, btw. We could set up a call with potential stake-holders. > Any chance you might be at USENIX Security in DC this August? No, but I will be in Boston for LinuxCon approx. 9th-12th August. -- James Morris From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 09:30: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 A8B2F106566B; Mon, 5 Jul 2010 09:30:52 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1208FC0C; Mon, 5 Jul 2010 09:30:52 +0000 (UTC) Received: from [192.168.2.110] (host86-162-156-210.range86-162.btcentralplus.com [86.162.156.210]) by cyrus.watson.org (Postfix) with ESMTPSA id 8644946B23; Mon, 5 Jul 2010 05:30:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Mon, 5 Jul 2010 10:30:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> To: James Morris X-Mailer: Apple Mail (2.1081) Cc: freebsd-hackers@freebsd.org, David Quigley , Trond Myklebust , "J. Bruce Fields" , Chuck Lever , Rick Macklem Subject: Re: Extended attributes for NFSv3 - possible Linux interop 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, 05 Jul 2010 09:30:52 -0000 On 5 Jul 2010, at 10:25, James Morris wrote: >> I'm happy to help contribute to the writing on an Internet Draft = and/or=20 >> RFC -- the lack of NFS support for EAs (and the EA vs. file fork=20 >> confusion) have long caused me frustration, and with systems like=20 >> SELinux, our various MAC policies, and all sorts of other things=20 >> floating around, there's a strong motivation to fix this ... in a=20 >> portable way! I'm just sorry I haven't gotten to this sooner... >=20 > The IETF process is closed for NFSv3, so in this case, it would be not = an=20 > ID or RFC. =46rom a working group, yes, but a third-party informational RFC might = fit the process? It's been about a decade since I've done anything in = IETF-land so I'm not familiar with how the process has evolved. However, = there used to be a way to feed "this is a best practice originating = outside the IETF with protocol implications" ID through the RFC system, = which leaves it "not a standard" but at least a useful reference in an = authoritative form. Robert= From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 09:57: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 16C0C106564A for ; Mon, 5 Jul 2010 09:57:41 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CEAFC8FC0A for ; Mon, 5 Jul 2010 09:57:40 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AD2951FFC33; Mon, 5 Jul 2010 09:57:39 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A3DA384550; Mon, 5 Jul 2010 11:55:27 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Matthew Fleming References: Date: Mon, 05 Jul 2010 11:55:27 +0200 In-Reply-To: (Matthew Fleming's message of "Fri, 2 Jul 2010 14:51:16 -0700") Message-ID: <86d3v2jlrk.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library 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, 05 Jul 2010 09:57:41 -0000 Not related to your problem, but related to $SUBJECT: make sure to use -P in LFLAGS so your lex-generated symbols don't conflict with those present in applications that use your library, or in other libraries those applications may use. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 11:05:00 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 D364C1065670 for ; Mon, 5 Jul 2010 11:05:00 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA208FC08 for ; Mon, 5 Jul 2010 11:04:56 +0000 (UTC) Received: by wwb13 with SMTP id 13so384522wwb.1 for ; Mon, 05 Jul 2010 04:04:49 -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=9BDlHvvPFdGR2SaULum8JTmn/adizZD9JQovrBJNCrg=; b=lf4HcAhedQIfv/Zq4FU53MSKsfMSZmNVuqb0OdoZsumOuhzsSP+zIHKgXG789nIbjA xxeXp7LYN+A/1hhoxKdOIn2pAsxYDTWVgkt9IXSReH6jOW4oe3ACMLTUo1KBWYOj9t8a 0kmpTa+M7rQYCPb2xULANO31PaIrS8xJhgMYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lkjl+xpYlojIobNJAwfIEMaXDMwfZ5HiwqENFwnn7WencHZcn9lX7cTvicI+piMu+M l8+KIXTP8/rgM0E6BRn+UpanRZl72nAw9RLrx+iuQBTIXaRmu18hOa+fCjp24a3L207J B7SUqdvokotWZtBn/vTjuhQntpncnFAxQGytQ= MIME-Version: 1.0 Received: by 10.213.14.81 with SMTP id f17mr2074079eba.33.1278327888953; Mon, 05 Jul 2010 04:04:48 -0700 (PDT) Received: by 10.213.9.194 with HTTP; Mon, 5 Jul 2010 04:04:48 -0700 (PDT) Date: Mon, 5 Jul 2010 15:04:48 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Do we still need libc_r and libkse in /usr/src/lib? 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, 05 Jul 2010 11:05:00 -0000 Hi Hackers, I've just started learning implementation of threads in FreeBSD-CURRENT. exctags found three different implementations of pthread_create function - libc_r, libkse and libthr: # pri kind tag file 1 F f _pthread_create lib/libc_r/uthread/uthread_create.c _pthread_create(pthread_t *thread, const pthread_attr_t *attr, 2 F f _pthread_create lib/libkse/thread/thr_create.c _pthread_create(pthread_t * thread, const pthread_attr_t * attr, 3 F f _pthread_create lib/libthr/thread/thr_create.c _pthread_create(pthread_t * thread, const pthread_attr_t * attr, I did a quick search in the google and found that libc_r (N:1 model) and libkse (N:M model) are no longer used in FreeBSD. So the only supported implementation of POSIX threads API is libthr (1:1 model), right? However, I found that both libc_r and libkse are still in /usr/src/lib. That looks like a bug because you even cannot build these libraries (I encountered compilation errors). I don't see obvious reason to keep such a dead code. Isn't it better to remove these libraries (of course you can still access the source code since SVN doesn't really delete anything)? If not, could you please explain why? Thanks! -- 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 Mon Jul 5 16:55:13 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 CB4CA1065674; Mon, 5 Jul 2010 16:55:13 +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 3D17F8FC15; Mon, 5 Jul 2010 16:55:11 +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 TAA01467; Mon, 05 Jul 2010 19:55:10 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C320E6E.4040007@freebsd.org> Date: Mon, 05 Jul 2010 19:55:10 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> In-Reply-To: <20100702082754.S14969@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Konstantin Belousov , Navdeep Parhar , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early 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, 05 Jul 2010 16:55:14 -0000 on 02/07/2010 11:29 Bjoern A. Zeeb said the following: > On Fri, 25 Jun 2010, Andriy Gapon wrote: > > Hey, > >> Proposed patch skips zero sized sections without going into trouble of >> allocating section entry (progtab), doing zero-sized memory allocs and >> copies. >> I observe that sometimes zero-sized set_pcpu sections are produced in >> module >> objects, maybe when a module doesn't create any per cpu data of its >> one, but >> references external pcpu data. Not sure. [snip] >> This work is based on np@'s investigation and original patch: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html >> > > Have you guys figured this out already? By 'this' - do you mean why that zero-sized section is produced at all? Does it really matter why that happens? I stated my guess already. Now I see that it is enough to simply include sys/pcpu.h for this to happen. Inline assembly at the start of the said header unconditionally creates the section. If DPCPU_DEFINE is never used in a module, then set_pcpu section remains empty. Neither compiler nor linker have any reason to drop empty sections in the build process for amd64 modules. I am not sure if ".section set_pcpu" assembly can be made conditional or moved some place else, so that the section is only created when DPCPU_DEFINE is actually used. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 17:15: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 0CC881065674; Mon, 5 Jul 2010 17:15:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9015C8FC12; Mon, 5 Jul 2010 17:15:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5DE3D41C750; Mon, 5 Jul 2010 19:15:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id F+RBi0PD9wXR; Mon, 5 Jul 2010 19:15:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id F0BF341C7A4; Mon, 5 Jul 2010 19:15:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9CCCE4448EC; Mon, 5 Jul 2010 17:12:42 +0000 (UTC) Date: Mon, 5 Jul 2010 17:12:42 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andriy Gapon In-Reply-To: <4C320E6E.4040007@freebsd.org> Message-ID: <20100705171155.K14969@maildrop.int.zabbadoz.net> References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Konstantin Belousov , Navdeep Parhar , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early 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, 05 Jul 2010 17:15:09 -0000 On Mon, 5 Jul 2010, Andriy Gapon wrote: > on 02/07/2010 11:29 Bjoern A. Zeeb said the following: >> On Fri, 25 Jun 2010, Andriy Gapon wrote: >> >> Hey, >> >>> Proposed patch skips zero sized sections without going into trouble of >>> allocating section entry (progtab), doing zero-sized memory allocs and >>> copies. >>> I observe that sometimes zero-sized set_pcpu sections are produced in >>> module >>> objects, maybe when a module doesn't create any per cpu data of its >>> one, but >>> references external pcpu data. Not sure. > [snip] >>> This work is based on np@'s investigation and original patch: >>> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html >>> >> >> Have you guys figured this out already? > > By 'this' - do you mean why that zero-sized section is produced at all? > Does it really matter why that happens? Well, no, I was thinking of the workaround and going ahead to commit somehting;) > I stated my guess already. Now I see that it is enough to simply include > sys/pcpu.h for this to happen. Inline assembly at the start of the said header > unconditionally creates the section. If DPCPU_DEFINE is never used in a module, > then set_pcpu section remains empty. Neither compiler nor linker have any reason > to drop empty sections in the build process for amd64 modules. > > I am not sure if ".section set_pcpu" assembly can be made conditional or moved > some place else, so that the section is only created when DPCPU_DEFINE is actually > used. The same applies to VIMAGE btw. Same technique. /bz -- Bjoern A. Zeeb From August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 17:19: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 4A94A106564A; Mon, 5 Jul 2010 17:19:09 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E53BD8FC1E; Mon, 5 Jul 2010 17:19:07 +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 UAA01890; Mon, 05 Jul 2010 20:19:05 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C321409.2070500@freebsd.org> Date: Mon, 05 Jul 2010 20:19:05 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> In-Reply-To: <20100705171155.K14969@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Konstantin Belousov , Navdeep Parhar , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early 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, 05 Jul 2010 17:19:09 -0000 on 05/07/2010 20:12 Bjoern A. Zeeb said the following: > On Mon, 5 Jul 2010, Andriy Gapon wrote: > >> on 02/07/2010 11:29 Bjoern A. Zeeb said the following: >>> On Fri, 25 Jun 2010, Andriy Gapon wrote: >>> >>> Hey, >>> >>>> Proposed patch skips zero sized sections without going into trouble of >>>> allocating section entry (progtab), doing zero-sized memory allocs and >>>> copies. >>>> I observe that sometimes zero-sized set_pcpu sections are produced in >>>> module >>>> objects, maybe when a module doesn't create any per cpu data of its >>>> one, but >>>> references external pcpu data. Not sure. >> [snip] >>>> This work is based on np@'s investigation and original patch: >>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html >>>> >>>> >>> >>> Have you guys figured this out already? >> >> By 'this' - do you mean why that zero-sized section is produced at all? >> Does it really matter why that happens? > > Well, no, I was thinking of the workaround and going ahead to commit > somehting;) Preview? :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 17:25: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 E0C79106564A; Mon, 5 Jul 2010 17:25:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id B5E638FC14; Mon, 5 Jul 2010 17:25:04 +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 o65HP3Bl020467; Mon, 5 Jul 2010 10:25:03 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e 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 33E832D6015; Mon, 5 Jul 2010 10:25:01 -0700 (PDT) Message-ID: <4C32158C.9080301@elischer.org> Date: Mon, 05 Jul 2010 10:25:32 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> In-Reply-To: <20100705171155.K14969@maildrop.int.zabbadoz.net> 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: Peter Wemm , freebsd-hackers@freebsd.org, Konstantin Belousov , Navdeep Parhar , Andriy Gapon Subject: Re: elf obj load: skip zero-sized sections early 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, 05 Jul 2010 17:25:05 -0000 On 7/5/10 10:12 AM, Bjoern A. Zeeb wrote: > On Mon, 5 Jul 2010, Andriy Gapon wrote: > [...] > > The same applies to VIMAGE btw. Same technique. or the proposed per-vimage AND per-CPU zone (to allow pcpu stats in a vimage..).. which degenerates to just more pcpu stuff if vimage is not enabled. > > /bz > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 19:34: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 0FD35106566C for ; Mon, 5 Jul 2010 19:34:35 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3648FC17 for ; Mon, 5 Jul 2010 19:34:33 +0000 (UTC) Received: from knopdnsimu13l.kn.op.dlr.de ([129.247.178.118]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 21:34:32 +0200 Date: Mon, 5 Jul 2010 21:32:35 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@knopdnsimu13l.kn.op.dlr.de To: Garrett Cooper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 05 Jul 2010 19:34:32.0118 (UTC) FILETIME=[17819560:01CB1C79] Cc: FreeBSD-Hackers Subject: Re: Non-POSIX compliant pmake with secondary expansion? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 19:34:35 -0000 Hi Garret, On Wed, 30 Jun 2010, Garrett Cooper wrote: GC> I currently set: GC> GC>.POSIX= I think this should be actually a target (the first one in the Makefile): .POSIX: GC> GC> In a Makefile thinking that it would enable only POSIX GC>functionality, and was fidgeting around with the Makefile trying to GC>get it to work. In short, I used secondary expansion, it worked, then GC>compared the output from gmake and it failed (because they have the GC>.SECONDEXPANSION keyword). POSIX doesn't mention secondary expansion, GC>so obviously it's not a POSIX feature. GC> So I was wondering if secondary expansion is enabled by default GC>with .POSIX instead of being disabled like it should on pmake? I remember that .POSIX does almost nothing (it switches of auto-makefile-dependency processing, set the %POSIX variable and disables banners for parallel makes). This is because of the way processing works in our make. I had Posix-compatibility of make on my list for some time but dropped it. This would require large rewrites of the code. Even the parser would need to be different because there are subtle differences. harti GC>Thanks, GC>-Garrett GC> GC>$ cat test_Makefile GC>.POSIX= GC> GC>TARGETS= GC> GC>all: $$(TARGETS) GC> GC>TARGETS+= idontexist GC> GC>idontexist: GC> @echo $@ GC>$ make -f test_Makefile all GC>idontexist GC>$ gmake -f test_Makefile GC>gmake: *** No rule to make target `$(TARGETS)', needed by `all'. Stop. GC>$ uname -a GC>FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r206173M: GC>Mon Apr 26 22:45:06 PDT 2010 GC>root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata amd64 GC>_______________________________________________ GC>freebsd-hackers@freebsd.org mailing list GC>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers GC>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" GC> GC> From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 22:55: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 487A01065672 for ; Mon, 5 Jul 2010 22:55:36 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:36b8:7bff:fee0:1a08]) by mx1.freebsd.org (Postfix) with ESMTP id 968EA8FC1F for ; Mon, 5 Jul 2010 22:55:35 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o65MtHC9076300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Jul 2010 08:25:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Tue, 6 Jul 2010 08:25:17 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <824CFAF1-A965-4848-A13D-48DA3724EBD1@gsoft.com.au> References: <02DA6157-87CE-47E5-91D0-ED014FB88AD0@gsoft.com.au> To: Christopher Bowman X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI Express and drivers 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, 05 Jul 2010 22:55:36 -0000 On 06/07/2010, at 5:32, Christopher Bowman wrote: > If I could, let me ask another question. My device could potential = have up to 6 BARs, that would be mapped into user space. Should I = simply bundle them together in my driver into one contiguous space or = should I make the user perform multiple mmap calls? If I go the = multiple mmap route, how do I match a mmap call to a particular BAR? Do = I use the size of the allocation? Yes, I think you just key off the requested address in the mmap() call. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 20:03:02 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 405621065675 for ; Mon, 5 Jul 2010 20:03:02 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 02A7D8FC12 for ; Mon, 5 Jul 2010 20:03:01 +0000 (UTC) Received: by qyk30 with SMTP id 30so2126389qyk.13 for ; Mon, 05 Jul 2010 13:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.130 with SMTP id m2mr1801507qac.146.1278360175434; Mon, 05 Jul 2010 13:02:55 -0700 (PDT) Received: by 10.229.247.1 with HTTP; Mon, 5 Jul 2010 13:02:55 -0700 (PDT) X-Originating-IP: [70.143.83.15] In-Reply-To: References: <02DA6157-87CE-47E5-91D0-ED014FB88AD0@gsoft.com.au> Date: Mon, 5 Jul 2010 13:02:55 -0700 Message-ID: From: Christopher Bowman To: "Daniel O'Connor" X-Mailman-Approved-At: Tue, 06 Jul 2010 03:02:45 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI Express and drivers 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, 05 Jul 2010 20:03:02 -0000 If I could, let me ask another question. My device could potential have up to 6 BARs, that would be mapped into user space. Should I simply bundle them together in my driver into one contiguous space or should I make the user perform multiple mmap calls? If I go the multiple mmap route, how do I match a mmap call to a particular BAR? Do I use the size of the allocation? Thanks Christopher On Sat, Jun 26, 2010 at 8:11 AM, Daniel O'Connor wrote: > > On 26/06/2010, at 14:50, Christopher Bowman wrote: > >> PS what board are you using? :) > >> > > Cool, that looks like what I am looking for. I'll go and read up on > it, thanks very much. I am using the Xilinx SP605 > http://www.xilinx.com/products/devkits/EK-S6-SP605-G.htm > > perfect for playing with hardware for a frame buffer device or graphics > device. It comes with a full license for the synthesis and PCIe IP for the > device on that board which is a great deal. > > Ahh, it does look like a fun toy :) > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 6 13:03: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 414F61065673 for ; Tue, 6 Jul 2010 13:03:49 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE42A8FC13 for ; Tue, 6 Jul 2010 13:03:48 +0000 (UTC) Received: from HexaDeca64.dmpriest.net.uk (HPQuadro64.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id o66D3lES004179 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Jul 2010 14:03:47 +0100 (BST) Date: Tue, 06 Jul 2010 14:04:43 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Message-ID: <518F0331CD800BA31E0236EB@HexaDeca64.dmpriest.net.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: 7.3-STABLE 'zfs attach' results in geom guid mismatch? 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, 06 Jul 2010 13:03:49 -0000 Hi All, This is related to a post I made the other day in freebsd-fs, which didn't get any replies (I'm a bit desperate as I need to replace a failing drive on the system - hence need to attach a spare - so apologies for the kind of cross-post)... I'm running 7.3-STABLE on an amd64, w/10Gb of RAM, and 2 * dual core Opteron 285's. When I do a 'zfs attach' the system hangs with no I/O - everything that touches zfs hangs. Doing some digging around (turning on ZFS debug) I see: host# zfs attach vol ad34 ad40 " vdev_geom_attach:112[1]: Attaching to ad40. vdev_geom_attach:153[1]: Created consumer for ad40. vdev_geom_read_guid:334[1]: guid for ad40 is 13247785578180267154 vdev_geom_detach:173[1]: Closing access to ad40. vdev_geom_detach:177[1]: Destroyed consumer to ad40. vdev_geom_open_by_path:472[1]: guid mismatch for provider /dev/ad40: 835553262974889329 != 13247785578180267154. vdev_geom_open_by_guid:430[1]: Searching by guid [835553262974889329]. " Should I be worried about that first "mismatch for provider"? It then seems to iterate through all the disk devices on the system (including some ZFS 'volumes') before appearing to hang on one of those (i.e. with GEOM debug turned on) the end of output is: " ... Jul 5 19:42:50 host kernel: g_access(0xffffff0035015380(zvol/vol2/zfs_backups/scanned), 1, 0, 0) Jul 5 19:42:50 host kernel: open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xffffff000e1fd000(zvol/vol2/zfs_backups/scanned) Jul 5 19:42:50 host kernel: g_access(0xffffff0035015380(zvol/vol2/zfs_backups/scanned), -1, 0, 0) Jul 5 19:42:50 host kernel: open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xffffff000e1fd000(zvol/vol2/zfs_backups/scanned) Jul 5 19:42:50 host kernel: g_detach(0xffffff0035015380) Jul 5 19:42:50 host kernel: g_access(0xffffff0035015380(zvol/vol/scanned@1237495449), 1, 0, 0) Jul 5 19:42:50 host kernel: open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xffffff000e60b300(zvol/vol/scanned@1237495449) [hangs here] " ps axl at that point shows: " 0 2250 2004 0 -8 0 14460 2044 g_wait D+ p0 0:00.01 zpool attach vol ad34 ad40 " So it appears to be hung in 'g_wait'. Any suggestions? -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 6 19:43: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 CA84D106566B for ; Tue, 6 Jul 2010 19:43:19 +0000 (UTC) (envelope-from mdf356@gmail.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 9F6618FC12 for ; Tue, 6 Jul 2010 19:43:19 +0000 (UTC) Received: by pvh1 with SMTP id 1so201073pvh.13 for ; Tue, 06 Jul 2010 12:43:14 -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=XRJ1PNym1PnhrUPpTKKQpmBkr1COpW7Gevj1VfVxUxE=; b=ms0jdbVEDm8o8uV/B5n2YTGAxYDhsS9TMi6wq+i7tSSjVbvndtF60pMgzeksU5Zn/m tt0bauNOF1tps/uFtkBbrJ5ilMUh7G2jAZw9cNn3Gj/TqwryExBsDrOtRihYAA8XffUC agLskV2gU5/4CBdouEOCCHeHXE0/jgV0HSKyQ= 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=VV05+x275SAlJxoEQEE6EkC5mGDz/9tAp/sbbbzxdEPbu2huipsuvYGMTB6gBbi2EY i5t4Gl6eQaz8ALXZTczIvkkMte8UOrfPgpMRVgdli+CnHPkcGPajBeqH9KSsRAkoKO9l Fxllh6dZmYpJu5wiMQUOPZOGU1TAm5rKgjJCo= MIME-Version: 1.0 Received: by 10.142.171.7 with SMTP id t7mr6238153wfe.211.1278445394284; Tue, 06 Jul 2010 12:43:14 -0700 (PDT) Received: by 10.42.5.78 with HTTP; Tue, 6 Jul 2010 12:43:14 -0700 (PDT) In-Reply-To: <4C2E7BCD.4020609@delphij.net> References: <4C2E7BCD.4020609@delphij.net> Date: Tue, 6 Jul 2010 12:43:14 -0700 Message-ID: From: Matthew Fleming To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library 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, 06 Jul 2010 19:43:19 -0000 On Fri, Jul 2, 2010 at 4:52 PM, Xin LI wrote: > I think you could probably just change the code and use %option noyywrap > in the .l file? =A0(do your code call yywrap() directly?) The code doesn't use yywrap directly, and this has fixed the build for amd6= 4. Thanks! matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 6 21:08: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 4B65B106566C; Tue, 6 Jul 2010 21:08: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 31BC38FC16; Tue, 6 Jul 2010 21:08:34 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o66L8LLp070923; Tue, 6 Jul 2010 14:08:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer; b=Xj2bRrZHftzqg2qa5qAFB4wSLb55PxZrR6b7ji+w/rCumHZmrdoxk7t9YrIbcTT8 From: Sean Bruno To: "freebsd-hackers@freebsd.org" In-Reply-To: <1278028001.2438.113.camel@localhost.localdomain> References: <1278028001.2438.113.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-bd7m8DoUYtvZhXKeUTe8" Date: Tue, 06 Jul 2010 14:08:21 -0700 Message-ID: <1278450501.6494.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Cc: bde Subject: Re: [Patch] Kgmon/Gprof On/Off Switch 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: Tue, 06 Jul 2010 21:08:35 -0000 --=-bd7m8DoUYtvZhXKeUTe8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote: > Found this lying around the Yahoo tree this week. Basically it allows > you to activate, reset and deactivate profiling with the '-f" flag. > > Kind of nice to have if you want the ability to turn on profiling for > debugging live systems. > > Applies cleanly to head at the moment. > > Sean Updated with proper man page formatting. Sean --=-bd7m8DoUYtvZhXKeUTe8 Content-Disposition: attachment; filename="kgmon_gprof_dynamic.diff" Content-Type: text/x-patch; name="kgmon_gprof_dynamic.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit Index: usr.sbin/kgmon/kgmon.8 =================================================================== --- usr.sbin/kgmon/kgmon.8 (revision 209745) +++ usr.sbin/kgmon/kgmon.8 (working copy) @@ -70,6 +70,9 @@ Dump the contents of the profile buffers into a .Pa gmon.out file. +.It Fl f +Free profiling buffer. +Also stops profiling. .It Fl r Reset all the profile buffers. If the Index: usr.sbin/kgmon/kgmon.c =================================================================== --- usr.sbin/kgmon/kgmon.c (revision 209745) +++ usr.sbin/kgmon/kgmon.c (working copy) @@ -72,7 +72,7 @@ struct gmonparam gpm; }; -int Bflag, bflag, hflag, kflag, rflag, pflag; +int Bflag, bflag, hflag, kflag, rflag, pflag, fflag; int debug = 0; int getprof(struct kvmvars *); int getprofhz(struct kvmvars *); @@ -82,6 +82,7 @@ void dumpstate(struct kvmvars *kvp); void reset(struct kvmvars *kvp); static void usage(void); +void freebuf(struct kvmvars *kvp); int main(int argc, char **argv) @@ -93,7 +94,7 @@ seteuid(getuid()); kmemf = NULL; system = NULL; - while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) { + while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) { switch((char)ch) { case 'M': @@ -113,6 +114,10 @@ bflag = 1; break; + case 'f': + fflag = 1; + break; + case 'h': hflag = 1; break; @@ -158,6 +163,10 @@ dumpstate(&kvmvars); if (rflag) reset(&kvmvars); + if (fflag) { + freebuf(&kvmvars); + disp = GMON_PROF_OFF; + } if (accessmode == O_RDWR) setprof(&kvmvars, disp); (void)fprintf(stdout, "kgmon: kernel profiling is %s.\n", @@ -403,36 +412,44 @@ /* * Write out the arc info. */ - if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) - errx(8, "cannot allocate froms space"); - if (kflag) { - i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, (void *)froms, - kvp->gpm.fromssize); - } else { - mib[2] = GPROF_FROMS; - i = kvp->gpm.fromssize; - if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) - i = 0; - } - if (i != kvp->gpm.fromssize) - errx(9, "read froms: read %lu, got %ld: %s", - kvp->gpm.fromssize, (long)i, - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); - if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == NULL) - errx(10, "cannot allocate tos space"); - if (kflag) { - i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, (void *)tos, - kvp->gpm.tossize); - } else { - mib[2] = GPROF_TOS; - i = kvp->gpm.tossize; - if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) - i = 0; - } - if (i != kvp->gpm.tossize) - errx(11, "read tos: read %lu, got %ld: %s", - kvp->gpm.tossize, (long)i, - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); + if (kvp->gpm.fromssize > 0) { + if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) + errx(8, "cannot allocate froms space"); + if (kflag) { + i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, + (void *)froms, + kvp->gpm.fromssize); + } else { + mib[2] = GPROF_FROMS; + i = kvp->gpm.fromssize; + if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) + i = 0; + } + if (i != kvp->gpm.fromssize) + errx(9, "read froms: read %lu, got %ld: %s", + kvp->gpm.fromssize, (long)i, + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); + } + if (kvp->gpm.tossize > 0) { + if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == + NULL) + errx(10, "cannot allocate tos space"); + if (kflag) { + i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, + (void *)tos, + kvp->gpm.tossize); + } else { + mib[2] = GPROF_TOS; + i = kvp->gpm.tossize; + if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) + i = 0; + } + if (i != kvp->gpm.tossize) + errx(11, "read tos: read %lu, got %ld: %s", + kvp->gpm.tossize, (long)i, + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); + } + if (debug) warnx("lowpc 0x%lx, textsize 0x%lx", (unsigned long)kvp->gpm.lowpc, kvp->gpm.textsize); @@ -509,11 +526,13 @@ if (kvm_write(kvp->kd, (u_long)kvp->gpm.kcount, zbuf, kvp->gpm.kcountsize) != kvp->gpm.kcountsize) errx(13, "tickbuf zero: %s", kvm_geterr(kvp->kd)); - if (kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, - kvp->gpm.fromssize) != kvp->gpm.fromssize) + if (kvp->gpm.fromssize > 0 && + kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, + kvp->gpm.fromssize) != kvp->gpm.fromssize) errx(14, "froms zero: %s", kvm_geterr(kvp->kd)); - if (kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, - kvp->gpm.tossize) != kvp->gpm.tossize) + if (kvp->gpm.tossize > 0 && + kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, + kvp->gpm.tossize) != kvp->gpm.tossize) errx(15, "tos zero: %s", kvm_geterr(kvp->kd)); return; } @@ -524,11 +543,33 @@ if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.kcountsize) < 0) err(13, "tickbuf zero"); mib[2] = GPROF_FROMS; - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) + if (kvp->gpm.fromssize > 0 && + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) err(14, "froms zero"); mib[2] = GPROF_TOS; - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) - err(15, "tos zero"); + if (kvp->gpm.tossize > 0 && + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) (void)seteuid(getuid()); free(zbuf); } + +/* + * Free the kernel profiling date structures. + */ +void +freebuf(kvp) + struct kvmvars *kvp; +{ + int mib[3]; + + setprof(kvp, GMON_PROF_OFF); + if (kflag) + return; + (void)seteuid(0); + mib[0] = CTL_KERN; + mib[1] = KERN_PROF; + mib[2] = GPROF_FREEBUF; + if (sysctl(mib, 3, NULL, 0, NULL, 0) < 0) + err(16, "Freeing profiling buffer failed"); + (void)seteuid(getuid()); +} Index: sys/kern/kern_clock.c =================================================================== --- sys/kern/kern_clock.c (revision 209745) +++ sys/kern/kern_clock.c (working copy) @@ -68,9 +68,7 @@ #include #include -#ifdef GPROF #include -#endif #ifdef HWPMC_HOOKS #include @@ -714,10 +712,8 @@ profclock(int usermode, uintfptr_t pc) { struct thread *td; -#ifdef GPROF struct gmonparam *g; uintfptr_t i; -#endif td = curthread; if (usermode) { @@ -730,7 +726,6 @@ if (td->td_proc->p_flag & P_PROFIL) addupc_intr(td, pc, 1); } -#ifdef GPROF else { /* * Kernel statistics are just like addupc_intr, only easier. @@ -743,7 +738,6 @@ } } } -#endif } /* Index: sys/kern/subr_prof.c =================================================================== --- sys/kern/subr_prof.c (revision 209745) +++ sys/kern/subr_prof.c (working copy) @@ -44,7 +44,6 @@ #include -#ifdef GPROF #include #include #undef MCOUNT @@ -136,7 +135,46 @@ free(cp, M_GPROF); } +#ifndef GPROF +/* Allocate kcount buffer and initialize state */ +static int +prof_alloc_kcountbuf(void) +{ + char *cp; + struct gmonparam *p = &_gmonparam; + int error = 0; + + mtx_lock(&Giant); + if (p->kcount == NULL) { + cp = (char *)malloc(p->kcountsize, M_GPROF, M_NOWAIT); + if (cp == 0) { + printf("No memory for profiling.\n"); + error = ENOMEM; + goto out; + } + bzero(cp, p->kcountsize); + p->kcount = (HISTCOUNTER *)cp; + } +out: + mtx_unlock(&Giant); + return error; +} + static void +prof_free_kcountbuf(void) +{ + struct gmonparam *p = &_gmonparam; + + mtx_lock(&Giant); + if (p->kcount != NULL) { + free(p->kcount, M_GPROF); + p->kcount = (HISTCOUNTER *)NULL; + } + mtx_unlock(&Giant); +} +#endif + +static void kmstartup(dummy) void *dummy; { @@ -152,6 +190,7 @@ int nullfunc_loop_profiled_time; uintfptr_t tmp_addr; #endif + int bufsize; /* * Round lowpc and highpc to multiples of the density we're using @@ -164,6 +203,7 @@ p->textsize, (uintmax_t)p->lowpc, (uintmax_t)p->highpc); p->kcountsize = p->textsize / HISTFRACTION; p->hashfraction = HASHFRACTION; +#ifdef GPROF p->fromssize = p->textsize / HASHFRACTION; p->tolimit = p->textsize * ARCDENSITY / 100; if (p->tolimit < MINARCS) @@ -171,13 +211,30 @@ else if (p->tolimit > MAXARCS) p->tolimit = MAXARCS; p->tossize = p->tolimit * sizeof(struct tostruct); - cp = (char *)malloc(p->kcountsize + p->fromssize + p->tossize, - M_GPROF, M_WAITOK | M_ZERO); + bufsize = p->kcountsize + p->fromssize + p->tossize; +#else + p->fromssize = 0; + p->tolimit = 0; + p->tossize = 0; + bufsize = 0; + p->kcount = (HISTCOUNTER *)NULL; +#endif + cp = NULL; + if (bufsize > 0) + cp = (char *)malloc(bufsize, M_GPROF, M_WAITOK | M_ZERO); +#ifdef GPROF p->tos = (struct tostruct *)cp; cp += p->tossize; +#else + p->tos = (struct tostruct *)NULL; +#endif p->kcount = (HISTCOUNTER *)cp; cp += p->kcountsize; +#ifdef GPROF p->froms = (u_short *)cp; +#else + p->froms = (u_short *)NULL; +#endif p->histcounter_type = FUNCTION_ALIGNMENT / HISTFRACTION * NBBY; #ifdef GUPROF @@ -351,6 +408,12 @@ } else if (state == GMON_PROF_ON) { gp->state = GMON_PROF_OFF; stopguprof(gp); +#ifndef GUPROF + /* Allocate kcount buffer and initialize state */ + error = prof_alloc_kcountbuf(); + if (error) + return error; +#endif gp->profrate = profhz; PROC_LOCK(&proc0); startprofclock(&proc0); @@ -368,15 +431,24 @@ } else if (state != gp->state) return (EINVAL); return (0); +#ifndef GPROF + if (gp->state != GMON_PROF_OFF) + return EINVAL; + /* Free kcount buffer */ + prof_free_kcountbuf(); +#endif + return 0; case GPROF_COUNT: return (sysctl_handle_opaque(oidp, gp->kcount, gp->kcountsize, req)); +#ifdef GPROF case GPROF_FROMS: return (sysctl_handle_opaque(oidp, gp->froms, gp->fromssize, req)); case GPROF_TOS: return (sysctl_handle_opaque(oidp, gp->tos, gp->tossize, req)); +#endif case GPROF_GMONPARAM: return (sysctl_handle_opaque(oidp, gp, sizeof *gp, req)); default: @@ -386,7 +458,6 @@ } SYSCTL_NODE(_kern, KERN_PROF, prof, CTLFLAG_RW, sysctl_kern_prof, ""); -#endif /* GPROF */ /* * Profiling system call. Index: sys/sys/gmon.h =================================================================== --- sys/sys/gmon.h (revision 209745) +++ sys/sys/gmon.h (working copy) @@ -197,6 +197,7 @@ #define GPROF_FROMS 2 /* struct: from location hash bucket */ #define GPROF_TOS 3 /* struct: destination/count structure */ #define GPROF_GMONPARAM 4 /* struct: profiling parameters (see above) */ +#define GPROF_FREEBUF 5 /* int: free flat profiling buffer */ #ifdef _KERNEL --=-bd7m8DoUYtvZhXKeUTe8-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 6 14:18: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 B0349106566C; Tue, 6 Jul 2010 14:18:33 +0000 (UTC) (envelope-from dpquigl@tycho.nsa.gov) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by mx1.freebsd.org (Postfix) with ESMTP id 542D08FC0A; Tue, 6 Jul 2010 14:18:33 +0000 (UTC) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o66E5dv4022430; Tue, 6 Jul 2010 14:05:39 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o66E6UQL021700; Tue, 6 Jul 2010 10:06:30 -0400 From: "David P. Quigley" To: "Robert N. M. Watson" In-Reply-To: References: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> Content-Type: text/plain Organization: National Security Agency Date: Tue, 06 Jul 2010 09:59:03 -0400 Message-Id: <1278424743.2494.28.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Jul 2010 00:26:22 +0000 Cc: freebsd-hackers@freebsd.org, James Morris , Trond Myklebust , "J. Bruce Fields" , Chuck Lever , Rick Macklem Subject: Re: Extended attributes for NFSv3 - possible Linux interop 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, 06 Jul 2010 14:18:33 -0000 On Mon, 2010-07-05 at 10:30 +0100, Robert N. M. Watson wrote: > On 5 Jul 2010, at 10:25, James Morris wrote: > > >> I'm happy to help contribute to the writing on an Internet Draft and/or > >> RFC -- the lack of NFS support for EAs (and the EA vs. file fork > >> confusion) have long caused me frustration, and with systems like > >> SELinux, our various MAC policies, and all sorts of other things > >> floating around, there's a strong motivation to fix this ... in a > >> portable way! I'm just sorry I haven't gotten to this sooner... > > > > The IETF process is closed for NFSv3, so in this case, it would be not an > > ID or RFC. > > >From a working group, yes, but a third-party informational RFC might fit the process? It's been about a decade since I've done anything in IETF-land so I'm not familiar with how the process has evolved. However, there used to be a way to feed "this is a best practice originating outside the IETF with protocol implications" ID through the RFC system, which leaves it "not a standard" but at least a useful reference in an authoritative form. > > Robert It is possible to do this work not as a working group document which would be ideal since there is no NFSv3 WG. What you need to do is draft up the specification and submit it as an personal internet draft. Then since there is no working group you would probably need to contact the Transport Area Director (Still Lars I believe) to have him sponsor your document. Of course this may take a few iterations of the document before Lars is happy with it. You should also get people on the NFSv4 working group to look it over as well since some of them were probably involved with v3. Once Lars decides to sponsor the document it needs IESG approval (I think its IESG and not IAB). They will put out a request for experts to review your document and once again several iterations of review and rewrites will happen. Once that is all done the IESG sends it along to the RFC editor and eventually you will get an informational rfc numbers. Most times leaving it at this is sufficient for most people. Make sure that everyone knows its informational though and you don't intend it for the standards track. CALIPSO which was the IPv6 mls security option (not really an option since IPv6 doesn't have options) was done as an informational RFC. Dave From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 08:35: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 837F31065672; Wed, 7 Jul 2010 08:35:59 +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 093A98FC22; Wed, 7 Jul 2010 08:35:57 +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 LAA20925; Wed, 07 Jul 2010 11:35:55 +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 1OWQ6k-0000Iq-JD; Wed, 07 Jul 2010 11:35:54 +0300 Message-ID: <4C343C68.8010302@freebsd.org> Date: Wed, 07 Jul 2010 11:35:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> In-Reply-To: <4C321409.2070500@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Navdeep Parhar , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early 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, 07 Jul 2010 08:35:59 -0000 What do you think about something like the following? diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h index 1ee7717..ddfdefc 100644 --- a/sys/sys/pcpu.h +++ b/sys/sys/pcpu.h @@ -53,14 +53,17 @@ extern uintptr_t *__start_set_pcpu; extern uintptr_t *__stop_set_pcpu; -__asm__( -#ifdef __arm__ - ".section set_pcpu, \"aw\", %progbits\n" +#if defined(__arm__) +#define _PROGBITS "%progbits" #else - ".section set_pcpu, \"aw\", @progbits\n" +#define _PROGBITS "@progbits" #endif - "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" - "\t.previous"); +#define _CUSTOM_SECTION(name, flags, align) \ + __asm__( \ + ".section " __XSTRING(name) \ + ",\"" __XSTRING(flags) "\"," _PROGBITS "\n" \ + "\t.p2align " __XSTRING(align) "\n" \ + "\t.previous") /* * Array of dynamic pcpu base offsets. Indexed by id. @@ -82,7 +85,10 @@ extern uintptr_t dpcpu_off[]; */ #define DPCPU_NAME(n) pcpu_entry_##n #define DPCPU_DECLARE(t, n) extern t DPCPU_NAME(n) -#define DPCPU_DEFINE(t, n) t DPCPU_NAME(n) __section("set_pcpu") __used + +#define DPCPU_DEFINE(t, n) \ + _CUSTOM_SECTION(set_pcpu, aw, CACHE_LINE_SHIFT); \ + t DPCPU_NAME(n) __section("set_pcpu") __used /* * Accessors with a given base. The diff looks a little bit messier than the resulting macros :-) So I am pasting them too, just for your convenience: #if defined(__arm__) #define _PROGBITS "%progbits" #else #define _PROGBITS "@progbits" #endif #define _CUSTOM_SECTION(name, flags, align) \ __asm__( \ ".section " __XSTRING(name) \ ",\"" __XSTRING(flags) "\"," _PROGBITS "\n" \ "\t.p2align " __XSTRING(align) "\n" \ "\t.previous") ... #define DPCPU_DEFINE(t, n) \ _CUSTOM_SECTION(set_pcpu, aw, CACHE_LINE_SHIFT); \ t DPCPU_NAME(n) __section("set_pcpu") __used Not sure if _CUSTOM_SECTION is an overkill here or a useful/reusable thing. The idea is to tie '.section' directive to DPCPU_DEFINE macro, so that [empty] set_pcpu section is not created by merely including pcpu.h. Multiple DPCPU_DEFINE instances would cause multiple '.section' directives for set_pcpu, but that doesn't cause any problem. Here's an example of how this case looks in gcc-generated assembly (with two DPCPU_DEFINE instances): #APP .section set_pcpu,"aw",@progbits .p2align 7 .previous .section set_pcpu,"aw",@progbits .p2align 7 .previous ... #NO_APP ... .globl pcpu_entry_dpcpu_nvram1 .section set_pcpu,"aw",@progbits .align 8 .type pcpu_entry_dpcpu_nvram1, @object .size pcpu_entry_dpcpu_nvram1, 8 pcpu_entry_dpcpu_nvram1: .zero 8 .globl pcpu_entry_dpcpu_nvram2 .align 8 .type pcpu_entry_dpcpu_nvram2, @object .size pcpu_entry_dpcpu_nvram2, 8 pcpu_entry_dpcpu_nvram2: .zero 8 .data ... Here's objdump of the resulting module: objdump -x -w nvram.ko | fgrep set_pcpu 5 set_pcpu 00000010 0000000000000000 0000000000000000 00000380 2**7 CONTENTS, ALLOC, LOAD, DATA 0000000000000000 l O set_pcpu 0000000000000008 pcpu_entry_dpcpu_nvram1 0000000000000008 l O set_pcpu 0000000000000008 pcpu_entry_dpcpu_nvram2 0000000000000000 l d set_pcpu 0000000000000000 Looks good to me. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 00:40:37 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 ED33A1065672; Wed, 7 Jul 2010 00:40:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA6C8FC12; Wed, 7 Jul 2010 00:40:35 +0000 (UTC) Received: from c122-106-145-25.carlnfd1.nsw.optusnet.com.au (c122-106-145-25.carlnfd1.nsw.optusnet.com.au [122.106.145.25]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o670eUIs025895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 10:40:32 +1000 Date: Wed, 7 Jul 2010 10:40:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Sean Bruno In-Reply-To: <1278449494.2587.7.camel@localhost.localdomain> Message-ID: <20100707081110.H56940@delplex.bde.org> References: <1278028001.2438.113.camel@localhost.localdomain> <1278449494.2587.7.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 07 Jul 2010 12:26:28 +0000 Cc: "freebsd-hackers@freebsd.org" , "sbruno@freebsd.org" , bde@FreeBSD.org Subject: Re: [Patch] Kgmon/Gprof On/Off Switch 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, 07 Jul 2010 00:40:37 -0000 On Tue, 6 Jul 2010, Sean Bruno wrote: > On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote: >> Found this lying around the Yahoo tree this week. Basically it allows >> you to activate, reset and deactivate profiling with the '-f" flag. I want something like this, but this implementation has too many style bugs and obscure or missing locking. >> Kind of nice to have if you want the ability to turn on profiling for >> debugging live systems. We already have this via `kgmon -hBb', but this patch implements something different. Normal profiling requires configuring the kernel with "config -p[p]", but that adds a lot of overhead, even when profiling is not turned on. The patch implements dynamic configuration of flat profiling only (since dynamic call graphs are too hard to implement, but this restriction is not mentioned anywhere in the patch or the accompanying mail. Userland profiling has the same lossage -- you have to configure programs specially by compiling with -pg, but that adds a lot of overhead, even when profiling is not turned on. Moreover, in userland there is no library support for turning profiling on and off or for dumping and clearing the statistics except on program start and completion, so the much larger overhead of always maintaining the call graph is normally always present. In FreeBSD-1, I (ab)used a bug in the implementation to turn on flat profiling (only) in the kernel. This avoids the large call graph overhead (it still costs a function call and some other branches on every call and maybe on every return, but the branches for this are predictable so the overhead is not very large. This should be made a standard feature, and perhaps this patch implements it as a bug without really trying, as in FreeBSD-1 (implementing it just takes setting gp->state to a value that gives flat profiling while keeping mcount() null if full profiling is configured. % Index: usr.sbin/kgmon/kgmon.8 % =================================================================== % --- usr.sbin/kgmon/kgmon.8 (revision 209745) % +++ usr.sbin/kgmon/kgmon.8 (working copy) % @@ -70,6 +70,9 @@ % Dump the contents of the profile buffers into a % .Pa gmon.out % file. % +.It Fl f % +Free profiling buffer. % +Also stops profiling. % .It Fl r % Reset all the profile buffers. % If the Freeing the profiling buffer alone isn't very useful. The memory wastage from always allocating it at boot time and never freeing it would be rarely noticed, and would fix some races or simplify avoidance of races. However, apart from the race problems, ordinary statically configured profiling should free things too, since unlike in userland it is normal to have profiling turned off most of the time even when it is statically configured. The above doesn't really describe what -f does. In normal profiling, there are multiple profiling buffers and freeing just the flat profiling one makes no sense. -f in fact frees the profiling buffer only if the kernel is _not_ configured for profiling (as is required to not corrupt the set of profiling buffers if the kernel is configured for profiling). The profiling buffer is automatically allocated on first use iff it is not already allocated, and of course -f has no effect if no buffer is allocated. Perhaps -r should automatically deallocate, so -f would not be needed. Kernel profiling has this feature of allowing multiple dumps of the buffer(s) before reset, so reset is a good time to deallocate. Style bugs in the above: f is unsorted between p and r. % Index: usr.sbin/kgmon/kgmon.c % =================================================================== % --- usr.sbin/kgmon/kgmon.c (revision 209745) % +++ usr.sbin/kgmon/kgmon.c (working copy) % @@ -72,7 +72,7 @@ % struct gmonparam gpm; % }; % % -int Bflag, bflag, hflag, kflag, rflag, pflag; % +int Bflag, bflag, hflag, kflag, rflag, pflag, fflag; Style bugs: now f is unsorted after r and p. p was already unsorted after r. % int debug = 0; % int getprof(struct kvmvars *); % int getprofhz(struct kvmvars *); % @@ -82,6 +82,7 @@ % void dumpstate(struct kvmvars *kvp); % void reset(struct kvmvars *kvp); % static void usage(void); % +void freebuf(struct kvmvars *kvp); Style bugs: f is unsorted after u; all the old declarations are indented with 1 tab while the new one is indented with spaces. % % int % main(int argc, char **argv) % @@ -93,7 +94,7 @@ % seteuid(getuid()); % kmemf = NULL; % system = NULL; % - while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) { % + while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) { % switch((char)ch) { % % case 'M': % @@ -113,6 +114,10 @@ % bflag = 1; % break; % % + case 'f': % + fflag = 1; % + break; % + % case 'h': % hflag = 1; % break; Now f is correctly sorted in the above 2 places. But it is missing from the usage message. % @@ -158,6 +163,10 @@ % dumpstate(&kvmvars); % if (rflag) % reset(&kvmvars); % + if (fflag) { % + freebuf(&kvmvars); % + disp = GMON_PROF_OFF; % + } % if (accessmode == O_RDWR) % setprof(&kvmvars, disp); % (void)fprintf(stdout, "kgmon: kernel profiling is %s.\n", % @@ -403,36 +412,44 @@ % /* % * Write out the arc info. % */ % - if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) % - errx(8, "cannot allocate froms space"); % - if (kflag) { % - i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, (void *)froms, % - kvp->gpm.fromssize); % - } else { % - mib[2] = GPROF_FROMS; % - i = kvp->gpm.fromssize; % - if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) % - i = 0; % - } % - if (i != kvp->gpm.fromssize) % - errx(9, "read froms: read %lu, got %ld: %s", % - kvp->gpm.fromssize, (long)i, % - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); % - if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == NULL) % - errx(10, "cannot allocate tos space"); % - if (kflag) { % - i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, (void *)tos, % - kvp->gpm.tossize); % - } else { % - mib[2] = GPROF_TOS; % - i = kvp->gpm.tossize; % - if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) % - i = 0; % - } % - if (i != kvp->gpm.tossize) % - errx(11, "read tos: read %lu, got %ld: %s", % - kvp->gpm.tossize, (long)i, % - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); % + if (kvp->gpm.fromssize > 0) { % + if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) % + errx(8, "cannot allocate froms space"); % + if (kflag) { % + i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, % + (void *)froms, % + kvp->gpm.fromssize); % + } else { % + mib[2] = GPROF_FROMS; % + i = kvp->gpm.fromssize; % + if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) % + i = 0; % + } % + if (i != kvp->gpm.fromssize) % + errx(9, "read froms: read %lu, got %ld: %s", % + kvp->gpm.fromssize, (long)i, % + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); % + } % + if (kvp->gpm.tossize > 0) { % + if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == % + NULL) % + errx(10, "cannot allocate tos space"); % + if (kflag) { % + i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, % + (void *)tos, % + kvp->gpm.tossize); % + } else { % + mib[2] = GPROF_TOS; % + i = kvp->gpm.tossize; % + if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) % + i = 0; % + } % + if (i != kvp->gpm.tossize) % + errx(11, "read tos: read %lu, got %ld: %s", % + kvp->gpm.tossize, (long)i, % + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); % + } % + The above is unreadable due to extra indentation and/or massive tab lossage. Most but not all tabs are corrupted to spaces. I think it requires the extra indentation as written, since `to' and `from' sizes of 0 now become non-errors, so they are skipped over by putting them in a conditional clause instead of aborted on. These cases would also happen with full profiling configured but only flat profiling enabled. I'm not sure how my FreeBSD-1 hack handled this. % if (debug) % warnx("lowpc 0x%lx, textsize 0x%lx", % (unsigned long)kvp->gpm.lowpc, kvp->gpm.textsize); % @@ -509,11 +526,13 @@ % if (kvm_write(kvp->kd, (u_long)kvp->gpm.kcount, zbuf, % kvp->gpm.kcountsize) != kvp->gpm.kcountsize) % errx(13, "tickbuf zero: %s", kvm_geterr(kvp->kd)); % - if (kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, % - kvp->gpm.fromssize) != kvp->gpm.fromssize) % + if (kvp->gpm.fromssize > 0 && % + kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, % + kvp->gpm.fromssize) != kvp->gpm.fromssize) % errx(14, "froms zero: %s", kvm_geterr(kvp->kd)); % - if (kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, % - kvp->gpm.tossize) != kvp->gpm.tossize) % + if (kvp->gpm.tossize > 0 && % + kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, % + kvp->gpm.tossize) != kvp->gpm.tossize) % errx(15, "tos zero: %s", kvm_geterr(kvp->kd)); % return; % } Now the indentation is not extra but tab lossage is still massive. % @@ -524,11 +543,33 @@ % if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.kcountsize) < 0) % err(13, "tickbuf zero"); % mib[2] = GPROF_FROMS; % - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) % + if (kvp->gpm.fromssize > 0 && % + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) % err(14, "froms zero"); % mib[2] = GPROF_TOS; % - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) % - err(15, "tos zero"); % + if (kvp->gpm.tossize > 0 && % + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) Tab lossage on every changed line, as usual. % (void)seteuid(getuid()); % free(zbuf); % } % + % +/* % + * Free the kernel profiling date structures. % + */ % +void % +freebuf(kvp) % + struct kvmvars *kvp; % +{ % + int mib[3]; % + % + setprof(kvp, GMON_PROF_OFF); % + if (kflag) % + return; % + (void)seteuid(0); % + mib[0] = CTL_KERN; % + mib[1] = KERN_PROF; % + mib[2] = GPROF_FREEBUF; % + if (sysctl(mib, 3, NULL, 0, NULL, 0) < 0) % + err(16, "Freeing profiling buffer failed"); % + (void)seteuid(getuid()); % +} No tab in sight in new code. Error message are not capitalized in KNF. This rule was followed in all the old error messages in this program. % Index: sys/kern/kern_clock.c % =================================================================== % --- sys/kern/kern_clock.c (revision 209745) % +++ sys/kern/kern_clock.c (working copy) % @@ -68,9 +68,7 @@ % #include % #include % % -#ifdef GPROF % #include % -#endif % % #ifdef HWPMC_HOOKS % #include % @@ -714,10 +712,8 @@ % profclock(int usermode, uintfptr_t pc) % { % struct thread *td; % -#ifdef GPROF % struct gmonparam *g; % uintfptr_t i; % -#endif % % td = curthread; % if (usermode) { % @@ -730,7 +726,6 @@ % if (td->td_proc->p_flag & P_PROFIL) % addupc_intr(td, pc, 1); % } % -#ifdef GPROF % else { % /* % * Kernel statistics are just like addupc_intr, only easier. % @@ -743,7 +738,6 @@ % } % } % } % -#endif % } % % /* Seems to be correct. Everything except initialization is here, and the changes for it are remarkably simple and low overhead. % Index: sys/kern/subr_prof.c % =================================================================== % --- sys/kern/subr_prof.c (revision 209745) % +++ sys/kern/subr_prof.c (working copy) % @@ -44,7 +44,6 @@ % % #include % % -#ifdef GPROF % #include % #include % #undef MCOUNT % @@ -136,7 +135,46 @@ % free(cp, M_GPROF); % } % % +#ifndef GPROF % +/* Allocate kcount buffer and initialize state */ Style bugs: - missing "." - no description (except the ifdef) that this only applies to the unusual case of non-static configuration. % +static int % +prof_alloc_kcountbuf(void) The prof_ namespace is not used by profiling code. % +{ % + char *cp; % + struct gmonparam *p = &_gmonparam; % + int error = 0; Style bug: initialization in declaration. Old profiling code has this for p but not for errno. % + % + mtx_lock(&Giant); There are lots of race problems in old and new profiling initialization and reinitialization code, and this has little effect on them. Higher level profiling code in kern_clock.c is mostly locked by time_lock, and the parts that use time_lock are correct AFAIK. However, this locking is not used by profclock(). profclock() used to use sched_lock, but now uses no explicit locking whatsoever. It is just called from the low-level timer interrupt handler, and that is required to be a fast interrupt handler so that it has interrupts disabled on the current CPU, and there is the pseudo-locking that profclock() is only called on 1 CPU at intervals of 1/profhz, so the calls shouldn't overlap. time_lock is a spinlock, so acquiring it locks out profclock() due to the bugfeature that spinlocks lock out all fast interrupt handlers. % + if (p->kcount == NULL) { % + cp = (char *)malloc(p->kcountsize, M_GPROF, M_NOWAIT); Style bug: useless cast copied from old code. This is not C++. The locking shouldn't be to use a spinlock, since calling malloc() while holding a spinlock is or should be a panic. For more ideas on correct locking, see below. % + if (cp == 0) { % + printf("No memory for profiling.\n"); Style bugs: - null pointer constants are not spelled "0" in the kernel - kernel error messages are not capitalized - kernel error messages are not terminated by a ".". % + error = ENOMEM; % + goto out; % + } % + bzero(cp, p->kcountsize); % + p->kcount = (HISTCOUNTER *)cp; More excessive casting, consistent with old code (*blush*). % + } % +out: % + mtx_unlock(&Giant); % + return error; Style bug: missing parentheses. % +} Locking is not so critical for allocation. You can simply rely on the profiling buffer not being used while it is an in-between state for the same reason that it wasn't used before it existed at all -- that the state variable prevents its use. You just need locking to prevent the state variable changing underneath you. Locking in the above is neither necessary nor sufficient for this, no matter what it is (without further changes to access the state variable in the above). No locking at all is required in the above. % + % static void % +prof_free_kcountbuf(void) % +{ % + struct gmonparam *p = &_gmonparam; % + % + mtx_lock(&Giant); % + if (p->kcount != NULL) { % + free(p->kcount, M_GPROF); % + p->kcount = (HISTCOUNTER *)NULL; % + } % + mtx_unlock(&Giant); % +} As above for locking and casts, etc. Now it is critical to change the state variable to "off" before calling the above (this is done) and to keep it off (this is not done). % +#endif The above has massive tab lossage, as usual. Old locking bugs: - note that the boot-time initialization (kmstartup()) uses no locking except for a couple of critical_enter()s, and that these are broken. This depends on the state being "off" initially and nothing external turning it on, which still works as intended AFAIK.. The critical_exit()s were correct when I wrote them initially as disable_intr()'s. They are supposed to prevent _all_ interrupts so as to get accurate and no interference from interrupt routines. critical_enter() only stops preemption -- it allows all fast interrupt handlers and all low-level code for normal interrupts to run, so using it here is very broken. Even if the initialization is so early as to prevent any interrupts, this is unclear. - dynamic reinitialization to support modules (kmupetext()) uses Giant and critical_enter() locking. This depends on things that aren't true. Giant locking has no effect on profiling (though it may have had a small effect when it was committed, since IIRC the places that use time_lock used to use Giant locking; anyway, this effect is almost useless here). It used to use disable_intr() instead of critical_enter(). This originally worked for UP systems, but for SMP systems it didn't lock out profclock(). Now, critical_enter() doesn't even lock out profclock() on UP systems, so changing to using it is even more broken here. It is necessary to set the state variable to "off" and keep it off, similarly to this change. kmupetext() also uses M_WAITOK malloc()s. This is simpler and probably good enough, but using M_NOWAIT as in this patch is safer. Now I wonder what is the size of the largest M_WAITOK malloc() that can be done by a privileged user. If it is larger than the flat profiling buffer size in this patch then there is no point in not waiting in this patch. % + % +static void % kmstartup(dummy) % void *dummy; % { % @@ -152,6 +190,7 @@ % int nullfunc_loop_profiled_time; % uintfptr_t tmp_addr; % #endif % + int bufsize; % % /* % * Round lowpc and highpc to multiples of the density we're using % @@ -164,6 +203,7 @@ % p->textsize, (uintmax_t)p->lowpc, (uintmax_t)p->highpc); % p->kcountsize = p->textsize / HISTFRACTION; % p->hashfraction = HASHFRACTION; % +#ifdef GPROF % p->fromssize = p->textsize / HASHFRACTION; % p->tolimit = p->textsize * ARCDENSITY / 100; % if (p->tolimit < MINARCS) % @@ -171,13 +211,30 @@ % else if (p->tolimit > MAXARCS) % p->tolimit = MAXARCS; % p->tossize = p->tolimit * sizeof(struct tostruct); % - cp = (char *)malloc(p->kcountsize + p->fromssize + p->tossize, % - M_GPROF, M_WAITOK | M_ZERO); % + bufsize = p->kcountsize + p->fromssize + p->tossize; Hmm, no tab lossage in small sections. % +#else % + p->fromssize = 0; % + p->tolimit = 0; % + p->tossize = 0; % + bufsize = 0; % + p->kcount = (HISTCOUNTER *)NULL; Massive tab lossage resumes. I think p is statically initialized to 0 and thus all of the code in thos `#else' clause is dead. % +#endif % + cp = NULL; % + if (bufsize > 0) % + cp = (char *)malloc(bufsize, M_GPROF, M_WAITOK | M_ZERO); % +#ifdef GPROF % p->tos = (struct tostruct *)cp; % cp += p->tossize; % +#else % + p->tos = (struct tostruct *)NULL; % +#endif % p->kcount = (HISTCOUNTER *)cp; % cp += p->kcountsize; % +#ifdef GPROF % p->froms = (u_short *)cp; % +#else % + p->froms = (u_short *)NULL; % +#endif % p->histcounter_type = FUNCTION_ALIGNMENT / HISTFRACTION * NBBY; % % #ifdef GUPROF % @@ -351,6 +408,12 @@ % } else if (state == GMON_PROF_ON) { % gp->state = GMON_PROF_OFF; % stopguprof(gp); I don't see any locking here. Are all sysctls still locked by Giant? Then we have almost enough locking here, and the Giant locking in the alloc/free code is null. We are missing something to propagate the state change to other CPUs, even for the current "working" version, except possibly in the GUPROF case, if stopguprof() does it accidentally (but it doesn't). This doesn't matter much if all the buffers have been allocated and won't be freed or moved, but for the patch and for kmupetext() we are freeing or moving (kmupetext() actually doesn't even change the state to off on the current CPU like this does). Giant or almost any locking is enough once we have propagated the change here: only code near here is allowed to change the state, so Giant or whatever locking prevents it changing. Later when the state is changed to on, we should be careful to propagate the change of all the pointers in *gp to other CPUs before setting the state to on. % +#ifndef GUPROF % + /* Allocate kcount buffer and initialize state */ Comment with style bug repeated ad nauseum. % + error = prof_alloc_kcountbuf(); % + if (error) % + return error; Style bug: missing parentheses. Sorry I made the code and critical locking changes unreadable by pointing out the style bugs. % +#endif % gp->profrate = profhz; % PROC_LOCK(&proc0); % startprofclock(&proc0); % @@ -368,15 +431,24 @@ % } else if (state != gp->state) % return (EINVAL); % return (0); Many examples of KNF with non-missing parentheses in nearby code. % +#ifndef GPROF % + if (gp->state != GMON_PROF_OFF) % + return EINVAL; Style bug: missing parentheses. Now we depend on a previous sysctl having set the state to off, and need locking to keep it off while we are changing things. % + /* Free kcount buffer */ Now the comment with style bug is not repeated, but it is still of negative use since the function name is too verbose and says more than the comment. % + prof_free_kcountbuf(); % +#endif % + return 0; Style bug: missing parentheses. After return, and hopefully not before, another sysctl may change the state to on, and we just need something to propagate the pointers in *gp to other CPUs. This is more critical for alloc. Any locking for the whole sysctl guarantees this. So does the Giant locking in the alloc/free functions (and similarly for propagating the state change), but I think it is an obfuscation of using nested Giant locking for its side affect of memory ordering (locking of the whole operation is still needed for exclusive access). % case GPROF_COUNT: % return (sysctl_handle_opaque(oidp, % gp->kcount, gp->kcountsize, req)); % +#ifdef GPROF % case GPROF_FROMS: % return (sysctl_handle_opaque(oidp, % gp->froms, gp->fromssize, req)); % case GPROF_TOS: % return (sysctl_handle_opaque(oidp, % gp->tos, gp->tossize, req)); % +#endif % case GPROF_GMONPARAM: % return (sysctl_handle_opaque(oidp, gp, sizeof *gp, req)); % default: % @@ -386,7 +458,6 @@ % } % % SYSCTL_NODE(_kern, KERN_PROF, prof, CTLFLAG_RW, sysctl_kern_prof, ""); % -#endif /* GPROF */ % % /* % * Profiling system call. % Index: sys/sys/gmon.h % =================================================================== % --- sys/sys/gmon.h (revision 209745) % +++ sys/sys/gmon.h (working copy) % @@ -197,6 +197,7 @@ % #define GPROF_FROMS 2 /* struct: from location hash bucket */ % #define GPROF_TOS 3 /* struct: destination/count structure */ % #define GPROF_GMONPARAM 4 /* struct: profiling parameters (see above) */ Examples of normal style in nearby code: tab after #define, and tabs to indent. % +#define GPROF_FREEBUF 5 /* int: free flat profiling buffer */ Style bugs: - space after #define - massive tab lossage to indent, as usual. % % #ifdef _KERNEL % Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 15:40: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 CB05B106566B; Wed, 7 Jul 2010 15:40:32 +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 B02B18FC0C; Wed, 7 Jul 2010 15:40:32 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o67FeHDX059571; Wed, 7 Jul 2010 08:40:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=XuJR4DkLcaUtkjgQv8JgFB5zBDKEYwoNKnHPejawjFjxwMVJxA1Vf+kjHPC64cNq From: Sean Bruno To: Bruce Evans In-Reply-To: <20100707081110.H56940@delplex.bde.org> References: <1278028001.2438.113.camel@localhost.localdomain> <1278449494.2587.7.camel@localhost.localdomain> <20100707081110.H56940@delplex.bde.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Jul 2010 08:40:17 -0700 Message-ID: <1278517217.2512.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "reebsd-hackers@freebsd.org" , "bde@FreeBSD.org" Subject: Re: [Patch] Kgmon/Gprof On/Off Switch 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: Wed, 07 Jul 2010 15:40:32 -0000 On Tue, 2010-07-06 at 17:40 -0700, Bruce Evans wrote: > On Tue, 6 Jul 2010, Sean Bruno wrote: > > > On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote: > >> Found this lying around the Yahoo tree this week. Basically it allows > >> you to activate, reset and deactivate profiling with the '-f" flag. > > I want something like this, but this implementation has too many style > bugs and obscure or missing locking. > > >> Kind of nice to have if you want the ability to turn on profiling for > >> debugging live systems. > > We already have this via `kgmon -hBb', but this patch implements > something different. Normal profiling requires configuring the kernel > with "config -p[p]", but that adds a lot of overhead, even when profiling > is not turned on. The patch implements dynamic configuration of flat > profiling only (since dynamic call graphs are too hard to implement, > but this restriction is not mentioned anywhere in the patch or the > accompanying mail. > > Userland profiling has the same lossage -- you have to configure > programs specially by compiling with -pg, but that adds a lot of > overhead, even when profiling is not turned on. Moreover, in userland > there is no library support for turning profiling on and off or for > dumping and clearing the statistics except on program start and > completion, so the much larger overhead of always maintaining the call > graph is normally always present. > > In FreeBSD-1, I (ab)used a bug in the implementation to turn on flat > profiling (only) in the kernel. This avoids the large call graph > overhead (it still costs a function call and some other branches on > every call and maybe on every return, but the branches for this are > predictable so the overhead is not very large. This should be made > a standard feature, and perhaps this patch implements it as a bug > without really trying, as in FreeBSD-1 (implementing it just takes > setting gp->state to a value that gives flat profiling while keeping > mcount() null if full profiling is configured. > > % Index: usr.sbin/kgmon/kgmon.8 > % =================================================================== > % --- usr.sbin/kgmon/kgmon.8 (revision 209745) > % +++ usr.sbin/kgmon/kgmon.8 (working copy) > % @@ -70,6 +70,9 @@ > % Dump the contents of the profile buffers into a > % .Pa gmon.out > % file. > % +.It Fl f > % +Free profiling buffer. > % +Also stops profiling. > % .It Fl r > % Reset all the profile buffers. > % If the > > Freeing the profiling buffer alone isn't very useful. The memory wastage > from always allocating it at boot time and never freeing it would be > rarely noticed, and would fix some races or simplify avoidance of races. > However, apart from the race problems, ordinary statically configured > profiling should free things too, since unlike in userland it is normal > to have profiling turned off most of the time even when it is statically > configured. > > The above doesn't really describe what -f does. In normal profiling, > there are multiple profiling buffers and freeing just the flat profiling > one makes no sense. -f in fact frees the profiling buffer only if the > kernel is _not_ configured for profiling (as is required to not corrupt > the set of profiling buffers if the kernel is configured for profiling). > The profiling buffer is automatically allocated on first use iff it > is not already allocated, and of course -f has no effect if no buffer > is allocated. Perhaps -r should automatically deallocate, so -f would > not be needed. Kernel profiling has this feature of allowing multiple > dumps of the buffer(s) before reset, so reset is a good time to deallocate. > > Style bugs in the above: f is unsorted between p and r. > > % Index: usr.sbin/kgmon/kgmon.c > % =================================================================== > % --- usr.sbin/kgmon/kgmon.c (revision 209745) > % +++ usr.sbin/kgmon/kgmon.c (working copy) > % @@ -72,7 +72,7 @@ > % struct gmonparam gpm; > % }; > % > % -int Bflag, bflag, hflag, kflag, rflag, pflag; > % +int Bflag, bflag, hflag, kflag, rflag, pflag, fflag; > > Style bugs: now f is unsorted after r and p. p was already unsorted after r. > > % int debug = 0; > % int getprof(struct kvmvars *); > % int getprofhz(struct kvmvars *); > % @@ -82,6 +82,7 @@ > % void dumpstate(struct kvmvars *kvp); > % void reset(struct kvmvars *kvp); > % static void usage(void); > % +void freebuf(struct kvmvars *kvp); > > Style bugs: f is unsorted after u; all the old declarations are indented > with 1 tab while the new one is indented with spaces. > > % > % int > % main(int argc, char **argv) > % @@ -93,7 +94,7 @@ > % seteuid(getuid()); > % kmemf = NULL; > % system = NULL; > % - while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) { > % + while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) { > % switch((char)ch) { > % > % case 'M': > % @@ -113,6 +114,10 @@ > % bflag = 1; > % break; > % > % + case 'f': > % + fflag = 1; > % + break; > % + > % case 'h': > % hflag = 1; > % break; > > Now f is correctly sorted in the above 2 places. But it is missing from > the usage message. > > % @@ -158,6 +163,10 @@ > % dumpstate(&kvmvars); > % if (rflag) > % reset(&kvmvars); > % + if (fflag) { > % + freebuf(&kvmvars); > % + disp = GMON_PROF_OFF; > % + } > % if (accessmode == O_RDWR) > % setprof(&kvmvars, disp); > % (void)fprintf(stdout, "kgmon: kernel profiling is %s.\n", > % @@ -403,36 +412,44 @@ > % /* > % * Write out the arc info. > % */ > % - if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) > % - errx(8, "cannot allocate froms space"); > % - if (kflag) { > % - i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, (void *)froms, > % - kvp->gpm.fromssize); > % - } else { > % - mib[2] = GPROF_FROMS; > % - i = kvp->gpm.fromssize; > % - if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) > % - i = 0; > % - } > % - if (i != kvp->gpm.fromssize) > % - errx(9, "read froms: read %lu, got %ld: %s", > % - kvp->gpm.fromssize, (long)i, > % - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); > % - if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == NULL) > % - errx(10, "cannot allocate tos space"); > % - if (kflag) { > % - i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, (void *)tos, > % - kvp->gpm.tossize); > % - } else { > % - mib[2] = GPROF_TOS; > % - i = kvp->gpm.tossize; > % - if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) > % - i = 0; > % - } > % - if (i != kvp->gpm.tossize) > % - errx(11, "read tos: read %lu, got %ld: %s", > % - kvp->gpm.tossize, (long)i, > % - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); > % + if (kvp->gpm.fromssize > 0) { > % + if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) > % + errx(8, "cannot allocate froms space"); > % + if (kflag) { > % + i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, > % + (void *)froms, > % + kvp->gpm.fromssize); > % + } else { > % + mib[2] = GPROF_FROMS; > % + i = kvp->gpm.fromssize; > % + if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) > % + i = 0; > % + } > % + if (i != kvp->gpm.fromssize) > % + errx(9, "read froms: read %lu, got %ld: %s", > % + kvp->gpm.fromssize, (long)i, > % + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); > % + } > % + if (kvp->gpm.tossize > 0) { > % + if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == > % + NULL) > % + errx(10, "cannot allocate tos space"); > % + if (kflag) { > % + i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, > % + (void *)tos, > % + kvp->gpm.tossize); > % + } else { > % + mib[2] = GPROF_TOS; > % + i = kvp->gpm.tossize; > % + if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) > % + i = 0; > % + } > % + if (i != kvp->gpm.tossize) > % + errx(11, "read tos: read %lu, got %ld: %s", > % + kvp->gpm.tossize, (long)i, > % + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); > % + } > % + > > The above is unreadable due to extra indentation and/or massive tab lossage. > Most but not all tabs are corrupted to spaces. > > I think it requires the extra indentation as written, since `to' and `from' > sizes of 0 now become non-errors, so they are skipped over by putting them > in a conditional clause instead of aborted on. These cases would also > happen with full profiling configured but only flat profiling enabled. I'm > not sure how my FreeBSD-1 hack handled this. > > % if (debug) > % warnx("lowpc 0x%lx, textsize 0x%lx", > % (unsigned long)kvp->gpm.lowpc, kvp->gpm.textsize); > % @@ -509,11 +526,13 @@ > % if (kvm_write(kvp->kd, (u_long)kvp->gpm.kcount, zbuf, > % kvp->gpm.kcountsize) != kvp->gpm.kcountsize) > % errx(13, "tickbuf zero: %s", kvm_geterr(kvp->kd)); > % - if (kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, > % - kvp->gpm.fromssize) != kvp->gpm.fromssize) > % + if (kvp->gpm.fromssize > 0 && > % + kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, > % + kvp->gpm.fromssize) != kvp->gpm.fromssize) > % errx(14, "froms zero: %s", kvm_geterr(kvp->kd)); > % - if (kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, > % - kvp->gpm.tossize) != kvp->gpm.tossize) > % + if (kvp->gpm.tossize > 0 && > % + kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, > % + kvp->gpm.tossize) != kvp->gpm.tossize) > % errx(15, "tos zero: %s", kvm_geterr(kvp->kd)); > % return; > % } > > Now the indentation is not extra but tab lossage is still massive. > > % @@ -524,11 +543,33 @@ > % if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.kcountsize) < 0) > % err(13, "tickbuf zero"); > % mib[2] = GPROF_FROMS; > % - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) > % + if (kvp->gpm.fromssize > 0 && > % + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) > % err(14, "froms zero"); > % mib[2] = GPROF_TOS; > % - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) > % - err(15, "tos zero"); > % + if (kvp->gpm.tossize > 0 && > % + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) > > Tab lossage on every changed line, as usual. > > % (void)seteuid(getuid()); > % free(zbuf); > % } > % + > % +/* > % + * Free the kernel profiling date structures. > % + */ > % +void > % +freebuf(kvp) > % + struct kvmvars *kvp; > % +{ > % + int mib[3]; > % + > % + setprof(kvp, GMON_PROF_OFF); > % + if (kflag) > % + return; > % + (void)seteuid(0); > % + mib[0] = CTL_KERN; > % + mib[1] = KERN_PROF; > % + mib[2] = GPROF_FREEBUF; > % + if (sysctl(mib, 3, NULL, 0, NULL, 0) < 0) > % + err(16, "Freeing profiling buffer failed"); > % + (void)seteuid(getuid()); > % +} > > No tab in sight in new code. > > Error message are not capitalized in KNF. This rule was followed in all > the old error messages in this program. > > % Index: sys/kern/kern_clock.c > % =================================================================== > % --- sys/kern/kern_clock.c (revision 209745) > % +++ sys/kern/kern_clock.c (working copy) > % @@ -68,9 +68,7 @@ > % #include > % #include > % > % -#ifdef GPROF > % #include > % -#endif > % > % #ifdef HWPMC_HOOKS > % #include > % @@ -714,10 +712,8 @@ > % profclock(int usermode, uintfptr_t pc) > % { > % struct thread *td; > % -#ifdef GPROF > % struct gmonparam *g; > % uintfptr_t i; > % -#endif > % > % td = curthread; > % if (usermode) { > % @@ -730,7 +726,6 @@ > % if (td->td_proc->p_flag & P_PROFIL) > % addupc_intr(td, pc, 1); > % } > % -#ifdef GPROF > % else { > % /* > % * Kernel statistics are just like addupc_intr, only easier. > % @@ -743,7 +738,6 @@ > % } > % } > % } > % -#endif > % } > % > % /* > > Seems to be correct. Everything except initialization is here, and the > changes for it are remarkably simple and low overhead. > > % Index: sys/kern/subr_prof.c > % =================================================================== > % --- sys/kern/subr_prof.c (revision 209745) > % +++ sys/kern/subr_prof.c (working copy) > % @@ -44,7 +44,6 @@ > % > % #include > % > % -#ifdef GPROF > % #include > % #include > % #undef MCOUNT > % @@ -136,7 +135,46 @@ > % free(cp, M_GPROF); > % } > % > % +#ifndef GPROF > % +/* Allocate kcount buffer and initialize state */ > > Style bugs: > - missing "." > - no description (except the ifdef) that this only applies to the unusual > case of non-static configuration. > > % +static int > % +prof_alloc_kcountbuf(void) > > The prof_ namespace is not used by profiling code. > > % +{ > % + char *cp; > % + struct gmonparam *p = &_gmonparam; > % + int error = 0; > > Style bug: initialization in declaration. Old profiling code has this > for p but not for errno. > > % + > % + mtx_lock(&Giant); > > There are lots of race problems in old and new profiling initialization > and reinitialization code, and this has little effect on them. Higher > level profiling code in kern_clock.c is mostly locked by time_lock, > and the parts that use time_lock are correct AFAIK. However, this > locking is not used by profclock(). profclock() used to use sched_lock, > but now uses no explicit locking whatsoever. It is just called from > the low-level timer interrupt handler, and that is required to be a > fast interrupt handler so that it has interrupts disabled on the current > CPU, and there is the pseudo-locking that profclock() is only called > on 1 CPU at intervals of 1/profhz, so the calls shouldn't overlap. > time_lock is a spinlock, so acquiring it locks out profclock() due to > the bugfeature that spinlocks lock out all fast interrupt handlers. > > % + if (p->kcount == NULL) { > % + cp = (char *)malloc(p->kcountsize, M_GPROF, M_NOWAIT); > > Style bug: useless cast copied from old code. This is not C++. > > The locking shouldn't be to use a spinlock, since calling malloc() while > holding a spinlock is or should be a panic. For more ideas on correct > locking, see below. > > % + if (cp == 0) { > % + printf("No memory for profiling.\n"); > > Style bugs: > - null pointer constants are not spelled "0" in the kernel > - kernel error messages are not capitalized > - kernel error messages are not terminated by a ".". > > % + error = ENOMEM; > % + goto out; > % + } > % + bzero(cp, p->kcountsize); > % + p->kcount = (HISTCOUNTER *)cp; > > More excessive casting, consistent with old code (*blush*). > > % + } > % +out: > % + mtx_unlock(&Giant); > % + return error; > > Style bug: missing parentheses. > > % +} > > Locking is not so critical for allocation. You can simply rely on the > profiling buffer not being used while it is an in-between state for the > same reason that it wasn't used before it existed at all -- that the > state variable prevents its use. You just need locking to prevent the > state variable changing underneath you. Locking in the above is neither > necessary nor sufficient for this, no matter what it is (without further > changes to access the state variable in the above). No locking at all > is required in the above. > > % + > % static void > % +prof_free_kcountbuf(void) > % +{ > % + struct gmonparam *p = &_gmonparam; > % + > % + mtx_lock(&Giant); > % + if (p->kcount != NULL) { > % + free(p->kcount, M_GPROF); > % + p->kcount = (HISTCOUNTER *)NULL; > % + } > % + mtx_unlock(&Giant); > % +} > > As above for locking and casts, etc. Now it is critical to change the > state variable to "off" before calling the above (this is done) and to > keep it off (this is not done). > > % +#endif > > The above has massive tab lossage, as usual. > > Old locking bugs: > - note that the boot-time initialization (kmstartup()) uses no locking > except for a couple of critical_enter()s, and that these are broken. > This depends on the state being "off" initially and nothing external > turning it on, which still works as intended AFAIK.. The critical_exit()s > were correct when I wrote them initially as disable_intr()'s. They > are supposed to prevent _all_ interrupts so as to get accurate and > no interference from interrupt routines. critical_enter() only stops > preemption -- it allows all fast interrupt handlers and all low-level > code for normal interrupts to run, so using it here is very broken. > Even if the initialization is so early as to prevent any interrupts, > this is unclear. > > - dynamic reinitialization to support modules (kmupetext()) uses Giant > and critical_enter() locking. This depends on things that aren't > true. Giant locking has no effect on profiling (though it may have > had a small effect when it was committed, since IIRC the places that > use time_lock used to use Giant locking; anyway, this effect is almost > useless here). It used to use disable_intr() instead of critical_enter(). > This originally worked for UP systems, but for SMP systems it didn't > lock out profclock(). Now, critical_enter() doesn't even lock out > profclock() on UP systems, so changing to using it is even more broken > here. > > It is necessary to set the state variable to "off" and keep it off, > similarly to this change. > > kmupetext() also uses M_WAITOK malloc()s. This is simpler and > probably good enough, but using M_NOWAIT as in this patch is safer. > Now I wonder what is the size of the largest M_WAITOK malloc() that > can be done by a privileged user. If it is larger than the flat > profiling buffer size in this patch then there is no point in not > waiting in this patch. > > % + > % +static void > % kmstartup(dummy) > % void *dummy; > % { > % @@ -152,6 +190,7 @@ > % int nullfunc_loop_profiled_time; > % uintfptr_t tmp_addr; > % #endif > % + int bufsize; > % > % /* > % * Round lowpc and highpc to multiples of the density we're using > % @@ -164,6 +203,7 @@ > % p->textsize, (uintmax_t)p->lowpc, (uintmax_t)p->highpc); > % p->kcountsize = p->textsize / HISTFRACTION; > % p->hashfraction = HASHFRACTION; > % +#ifdef GPROF > % p->fromssize = p->textsize / HASHFRACTION; > % p->tolimit = p->textsize * ARCDENSITY / 100; > % if (p->tolimit < MINARCS) > % @@ -171,13 +211,30 @@ > % else if (p->tolimit > MAXARCS) > % p->tolimit = MAXARCS; > % p->tossize = p->tolimit * sizeof(struct tostruct); > % - cp = (char *)malloc(p->kcountsize + p->fromssize + p->tossize, > % - M_GPROF, M_WAITOK | M_ZERO); > % + bufsize = p->kcountsize + p->fromssize + p->tossize; > > Hmm, no tab lossage in small sections. > > % +#else > % + p->fromssize = 0; > % + p->tolimit = 0; > % + p->tossize = 0; > % + bufsize = 0; > % + p->kcount = (HISTCOUNTER *)NULL; > > Massive tab lossage resumes. > > I think p is statically initialized to 0 and thus all of the code in thos > `#else' clause is dead. > > % +#endif > % + cp = NULL; > % + if (bufsize > 0) > % + cp = (char *)malloc(bufsize, M_GPROF, M_WAITOK | M_ZERO); > % +#ifdef GPROF > % p->tos = (struct tostruct *)cp; > % cp += p->tossize; > % +#else > % + p->tos = (struct tostruct *)NULL; > % +#endif > % p->kcount = (HISTCOUNTER *)cp; > % cp += p->kcountsize; > % +#ifdef GPROF > % p->froms = (u_short *)cp; > % +#else > % + p->froms = (u_short *)NULL; > % +#endif > % p->histcounter_type = FUNCTION_ALIGNMENT / HISTFRACTION * NBBY; > % > % #ifdef GUPROF > % @@ -351,6 +408,12 @@ > % } else if (state == GMON_PROF_ON) { > % gp->state = GMON_PROF_OFF; > % stopguprof(gp); > > I don't see any locking here. Are all sysctls still locked by Giant? > Then we have almost enough locking here, and the Giant locking in the > alloc/free code is null. We are missing something to propagate the > state change to other CPUs, even for the current "working" version, > except possibly in the GUPROF case, if stopguprof() does it accidentally > (but it doesn't). This doesn't matter much if all the buffers have > been allocated and won't be freed or moved, but for the patch and for > kmupetext() we are freeing or moving (kmupetext() actually doesn't > even change the state to off on the current CPU like this does). > > Giant or almost any locking is enough once we have propagated the change > here: only code near here is allowed to change the state, so Giant or > whatever locking prevents it changing. Later when the state is changed > to on, we should be careful to propagate the change of all the pointers > in *gp to other CPUs before setting the state to on. > > % +#ifndef GUPROF > % + /* Allocate kcount buffer and initialize state */ > > Comment with style bug repeated ad nauseum. > > % + error = prof_alloc_kcountbuf(); > % + if (error) > % + return error; > > Style bug: missing parentheses. > > Sorry I made the code and critical locking changes unreadable by pointing > out the style bugs. > > % +#endif > % gp->profrate = profhz; > % PROC_LOCK(&proc0); > % startprofclock(&proc0); > % @@ -368,15 +431,24 @@ > % } else if (state != gp->state) > % return (EINVAL); > % return (0); > > Many examples of KNF with non-missing parentheses in nearby code. > > % +#ifndef GPROF > % + if (gp->state != GMON_PROF_OFF) > % + return EINVAL; > > Style bug: missing parentheses. > > Now we depend on a previous sysctl having set the state to off, and need > locking to keep it off while we are changing things. > > % + /* Free kcount buffer */ > > Now the comment with style bug is not repeated, but it is still of > negative use since the function name is too verbose and says more than > the comment. > > % + prof_free_kcountbuf(); > % +#endif > % + return 0; > > Style bug: missing parentheses. > > After return, and hopefully not before, another sysctl may change the > state to on, and we just need something to propagate the pointers in > *gp to other CPUs. This is more critical for alloc. Any locking for > the whole sysctl guarantees this. So does the Giant locking in the > alloc/free functions (and similarly for propagating the state change), > but I think it is an obfuscation of using nested Giant locking for its > side affect of memory ordering (locking of the whole operation is still > needed for exclusive access). > > % case GPROF_COUNT: > % return (sysctl_handle_opaque(oidp, > % gp->kcount, gp->kcountsize, req)); > % +#ifdef GPROF > % case GPROF_FROMS: > % return (sysctl_handle_opaque(oidp, > % gp->froms, gp->fromssize, req)); > % case GPROF_TOS: > % return (sysctl_handle_opaque(oidp, > % gp->tos, gp->tossize, req)); > % +#endif > % case GPROF_GMONPARAM: > % return (sysctl_handle_opaque(oidp, gp, sizeof *gp, req)); > % default: > % @@ -386,7 +458,6 @@ > % } > % > % SYSCTL_NODE(_kern, KERN_PROF, prof, CTLFLAG_RW, sysctl_kern_prof, ""); > % -#endif /* GPROF */ > % > % /* > % * Profiling system call. > % Index: sys/sys/gmon.h > % =================================================================== > % --- sys/sys/gmon.h (revision 209745) > % +++ sys/sys/gmon.h (working copy) > % @@ -197,6 +197,7 @@ > % #define GPROF_FROMS 2 /* struct: from location hash bucket */ > % #define GPROF_TOS 3 /* struct: destination/count structure */ > % #define GPROF_GMONPARAM 4 /* struct: profiling parameters (see above) */ > > Examples of normal style in nearby code: tab after #define, and tabs to indent. > > % +#define GPROF_FREEBUF 5 /* int: free flat profiling buffer */ > > Style bugs: > - space after #define > - massive tab lossage to indent, as usual. > > % > % #ifdef _KERNEL > % > > Bruce Thank you for spending time on this patch review. I will need some time to digest your comments on this code. Sean From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 18:39:45 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 C6F981065670 for ; Wed, 7 Jul 2010 18:39:45 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 54B1D8FC1B for ; Wed, 7 Jul 2010 18:39:44 +0000 (UTC) Received: by wwi18 with SMTP id 18so1433413wwi.31 for ; Wed, 07 Jul 2010 11:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=IqJI/R2l3q7CBYnpSQR1fs0INflwjM6HCESqm+ReMlM=; b=tzlHnlqip/z4r5L+Q3zvMUUNYeDePUXUEXUqyEg7E9eAWXQ3RGjSmHNxr52bMQfalz crZXwRJXbTltJ0xk17NbqwHqPyZSjYtXyAzi07g0c7RSXq8p63tYHmuq9L6xuLSqXsqf LGTxRSKL2hU8dndtDU3lmkj6Iedn7EONg49WE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=Rf2MtTEV5F4+JudZWP16cRLPCsSWjiCBvIB0GO+0UtjuJROGifK/JfET/y/KtRXOkg 4LpVIGAni8vWS8GNno6R38RgNXmZc7FtdBQ30VC2k/6hajPv244f+wqL76ocMwwjsBMs MxTDqBlaod5tz2hZDkZuMZSQBaJipdGX/9sok= Received: by 10.227.151.207 with SMTP id d15mr5457216wbw.75.1278527979215; Wed, 07 Jul 2010 11:39:39 -0700 (PDT) Received: from viper.internal.network (dsl78-143-224-177.in-addr.fast.co.uk [78.143.224.177]) by mx.google.com with ESMTPS id a27sm44730430wbe.18.2010.07.07.11.39.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Jul 2010 11:39:38 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 91AF94AC08; Wed, 7 Jul 2010 18:39:35 +0000 (UTC) Date: Wed, 7 Jul 2010 18:39:35 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20100707183935.GA24697@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: envy24 driver broken 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, 07 Jul 2010 18:39:45 -0000 Hello. Is anyone using the envy24 audio driver? I've tried it with two cards (M-Audio Delta 66, M-Audio Audiophile) and it just doesn't work properly. Both are claimed to be supported and yet they spew errors to the console on boot: WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured WRITE_MIXER: Device not configured etc. I can get audio out (most of the time) but only on two channels despite the Delta 66 being a six channel card. I can't get audio in at all. It seems like the driver's not been updated for over a year and that nobody really seems to be interested in the fact that it doesn't work. Any assistance would be appreciated (or recommendations for "pro" audio hardware that actually works with freebsd). Regards, xw From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 18:50: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 64BC31065676 for ; Wed, 7 Jul 2010 18:50:21 +0000 (UTC) (envelope-from pluknet@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 F14A98FC1B for ; Wed, 7 Jul 2010 18:50:20 +0000 (UTC) Received: by wyb34 with SMTP id 34so4857685wyb.13 for ; Wed, 07 Jul 2010 11:50:14 -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=1SXMUQYj+WG68rjsbCAyc0Zy5nCCUb1X5A89dByxpqg=; b=LR+ZWauvnnvPirZ8RYhEwsOBB5BjKERco7UEofbRNOTBiE4d8fulJmF07guh3hyE5K 79zrGQ6T1rA6UlWmtmFOVOiC7Vk+sPu6wPXUVWCPRrnyxRweZ/Nqt26UbN64Esj4j3Wx ioAgM2Mi4EZ5L+myGELjYh4U3IrI/EiKzuKUg= 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=TUvqW4+m/P6M2TqV3CRH9aAhSZKQpmrLklCpvzqNMCmavK2WnM3Ys7XhiDxzLCK5CM LHFaokacnzOimYGJ3+Dh5p0xPc4clzNpgD1RABW0+es6HjbCz80qTQTzdX+V50SsccSW XvSup4pUCo/G/4KMDjunf6nJkHL+Sjs+vXo7k= MIME-Version: 1.0 Received: by 10.216.81.195 with SMTP id m45mr1390902wee.23.1278528614340; Wed, 07 Jul 2010 11:50:14 -0700 (PDT) Received: by 10.216.37.68 with HTTP; Wed, 7 Jul 2010 11:50:14 -0700 (PDT) In-Reply-To: <20100707183935.GA24697@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> Date: Wed, 7 Jul 2010 22:50:14 +0400 Message-ID: From: pluknet To: xorquewasp@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: envy24 driver broken 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, 07 Jul 2010 18:50:21 -0000 On 7 July 2010 22:39, wrote: > Hello. > > Is anyone using the envy24 audio driver? > > I've tried it with two cards (M-Audio Delta 66, M-Audio Audiophile) > and it just doesn't work properly. Both are claimed to be supported > and yet they spew errors to the console on boot: > > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > WRITE_MIXER: Device not configured > > etc. > > I can get audio out (most of the time) but only on two channels despite > the Delta 66 being a six channel card. I can't get audio in at all. > > It seems like the driver's not been updated for over a year and that > nobody really seems to be interested in the fact that it doesn't work. > > Any assistance would be appreciated (or recommendations for "pro" audio > hardware that actually works with freebsd). > > Regards, > xw Hi! I have audiophile192 card, it uses a different envy24ht (not envy24), but with the same mixer warnings you described above. I saw these warning since time driver has been committed to the tree. -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 18:58:55 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 5EF3B1065670 for ; Wed, 7 Jul 2010 18:58:55 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E206B8FC08 for ; Wed, 7 Jul 2010 18:58:54 +0000 (UTC) Received: by wwi18 with SMTP id 18so1453417wwi.31 for ; Wed, 07 Jul 2010 11:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=rcXMQA8z7O65TRUaXZlF9L5M1vJcIPKCF6tLhdX8MYM=; b=xvO8qSpusvMbQCc22jHVSySyfa9DFUp+MBqqNzdYnHhPGT1D4sEOo/mZJn8Y8k/z5N ZzotVmHi5+P5LNR6ZIB5g31IHrrryisVg0UxCBtbVtMPgmZRcVXsh1/Cefp1nSZDSvZI SLU8dNg/RbFoeFII9svYgydQD59D30GfwgrV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=AwQDFO3jbFcPx56r1XvD4CXcT+YWTWcV18BI9+j/xDm8gMuOljHt2fGxgUjXHTWSCW a5r/hEF3A2MYn10hMD0FXN73cdExcF3AIh5zhu3VgXAahmP2o1YqaF2OJjGtiTCm/JGc MLpI4JYI0tUucyJNCqLCsw2uHuL+Idsj+PKcc= Received: by 10.227.155.80 with SMTP id r16mr5489072wbw.83.1278529130506; Wed, 07 Jul 2010 11:58:50 -0700 (PDT) Received: from viper.internal.network (dsl78-143-224-177.in-addr.fast.co.uk [78.143.224.177]) by mx.google.com with ESMTPS id p29sm44846297wbc.19.2010.07.07.11.58.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Jul 2010 11:58:49 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 3CADE4AC08; Wed, 7 Jul 2010 18:58:48 +0000 (UTC) Date: Wed, 7 Jul 2010 18:58:48 +0000 From: xorquewasp@googlemail.com To: pluknet Message-ID: <20100707185848.GA53688@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: envy24 driver broken 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, 07 Jul 2010 18:58:55 -0000 On 2010-07-07 22:50:14, pluknet wrote: > > Hi! > > I have audiophile192 card, it uses a different envy24ht (not envy24), > but with the same mixer warnings you described above. > I saw these warning since time driver has been committed to the tree. Hi, Does the card actually work? Can you get audio input and output (and both at the same time, full duplex?) Regards, xw From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 8 04:22: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 4053A106566C for ; Thu, 8 Jul 2010 04:22:07 +0000 (UTC) (envelope-from pluknet@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 9211A8FC13 for ; Thu, 8 Jul 2010 04:22:06 +0000 (UTC) Received: by wyb34 with SMTP id 34so299742wyb.13 for ; Wed, 07 Jul 2010 21:21:59 -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=2vPK/MJCq2e9wlZ695R7XZoltdui8YXMmfSifDqOBoU=; b=KNubmuONGuPNh9VLoqj9XYGPAneYUs2GZkqAgOGryCimzq9+jCVOAsnUPgQdGvMOEY 2LXgemW5iluSAxLL5IO2y1RbrN23ui0DEVpRrAu7S0aHCDqdb1qAYRlIS2UrywiW9feW MM1wTjOMxDLI77aIeO1IUxM1megOiLbTY5TcY= 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=Kw9Y42rNMYOyAsCC7YFM5ABda5a4sJlZxF4pu80C4u7xyfWH/q4OgEGbkNNssXokBc KCqM9jO206viyHLg5OPuw0X9mxX4Vp9+S/x+rgPLIfMWR/5Yg+V3vSnCbxfmIi9zBBUK 16bEYO3IDFsuvGwPUyWA2y1lgvaxRdq2SZQWE= MIME-Version: 1.0 Received: by 10.227.151.80 with SMTP id b16mr6006975wbw.209.1278562919306; Wed, 07 Jul 2010 21:21:59 -0700 (PDT) Received: by 10.216.37.68 with HTTP; Wed, 7 Jul 2010 21:21:59 -0700 (PDT) In-Reply-To: <20100707185848.GA53688@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> <20100707185848.GA53688@logik.internal.network> Date: Thu, 8 Jul 2010 08:21:59 +0400 Message-ID: From: pluknet To: xorquewasp@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: envy24 driver broken 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, 08 Jul 2010 04:22:08 -0000 On 7 July 2010 22:58, wrote: > On 2010-07-07 22:50:14, pluknet wrote: >> >> Hi! >> >> I have audiophile192 card, it uses a different envy24ht (not envy24), >> but with the same mixer warnings you described above. >> I saw these warning since time driver has been committed to the tree. > > Hi, > > Does the card actually work? > > Can you get audio input and output (and both at the same time, > full duplex?) > I just tried 2ch output. -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 9 10:34: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 B6E59106564A; Fri, 9 Jul 2010 10:34:32 +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 565B68FC20; Fri, 9 Jul 2010 10:34:30 +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 NAA19608; Fri, 09 Jul 2010 13:34:27 +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 1OXAuZ-0006jl-FO; Fri, 09 Jul 2010 13:34:27 +0300 Message-ID: <4C36FB32.30901@freebsd.org> Date: Fri, 09 Jul 2010 13:34:26 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> In-Reply-To: <4C343C68.8010302@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Navdeep Parhar , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early 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, 09 Jul 2010 10:34:32 -0000 Having thought and experimented more, I don't see why we need inline assembly at all and why DPCPU_DEFINE can not simply be defined as follows: #define DPCPU_DEFINE(t, n) \ t DPCPU_NAME(n) __section("set_pcpu") \ __aligned(CACHE_LINE_SIZE) __used And, honestly, I can not understand the following comment in pcpu.h, although I think I understand what's going on. > /* > * Define a set for pcpu data. > * > * We don't use SET_DECLARE because it defines the set as 'a' when we Hmm, SET_DECLARE doesn't do anything like that. Perhaps __MAKE_SET or one of its aliases was meant here? > * want 'aw'. gcc considers uninitialized data in a separate section > * writable, and there is no generic zero initializer that works for > * structs and scalars. > */ So, what's the problem here? Don't we want that data to be considered writable? Haven't we just said that we want "aw"? Don't we explicitly create a section with "aw" flags? And why do we need a (universal) initializer? Why is it mentioned here at all? Educate me. I demand it! :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 9 12:12:22 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 5D5CA1065673; Fri, 9 Jul 2010 12:12:22 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 14A5A8FC21; Fri, 9 Jul 2010 12:12:21 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 157FE3358D; Fri, 9 Jul 2010 14:12:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id Vce4zUh9OVHQ; Fri, 9 Jul 2010 14:12:17 +0200 (CEST) Received: from ip-91.191.125.7.o2inet.sk (ip-91.191.125.7.o2inet.sk [91.191.125.7]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 713A933580; Fri, 9 Jul 2010 14:12:13 +0200 (CEST) Message-ID: <4C37121B.1000207@FreeBSD.org> Date: Fri, 09 Jul 2010 14:12:11 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7pre) Gecko/20100630 Lanikai/3.1.1pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Fwd: HEADSUP: Call for FreeBSD Status Reports - 2Q/2010 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, 09 Jul 2010 12:12:22 -0000 Hello, I'd like to remind you the deadline to submit the status report for your project, which is set to July 15th, 2010. To this date, I have received only one report; please find some time and write a few words about your current work. Thanks! -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports - 2Q/2010 Date: Wed, 16 Jun 2010 18:15:55 +0200 From: Daniel Gerzo Organization: The FreeBSD Project To: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org Dear all, I would like to remind you that the next round of status reports covering the second quarter of 2010 is due on July 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template to be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 9 14:56: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 4ADCD106566C; Fri, 9 Jul 2010 14:56:39 +0000 (UTC) (envelope-from yanegomi@gmail.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 0174F8FC13; Fri, 9 Jul 2010 14:56:38 +0000 (UTC) Received: by iwn35 with SMTP id 35so2798083iwn.13 for ; Fri, 09 Jul 2010 07:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=fMBKbb8R5q3xVx/POFfLK+TzQQHiz5kuxrNilX0Jmn4=; b=oMvlb5NUm9fDph/eDD0l2TiEfKjebyQckUj0h+u2ybqKqnERUru74ky6SGZ+B4kkwL RHC00yHb4DEO+qAWJVXhM1Z2MEksNMB58pZNRjZQpCV5952Lm4vHLGDrCbj9gl9Qhwrn 0SCYRXtetbv/qEBEEHwQ40kCH35lN/yD7/j6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Pz02Hvyn5NEMiTjH0wu53VZPm4vGQkCZR8Oxhd8zTQaADvbRQXwf2Aa1anrkGXmhpi U7SbtBT1C7Yw8izqehUN147btAHyp5tgHZxyI9gDc0zZCNEeaWvggyZPcL+joVcJWx4k ZXhaBrGCc/+S/Z0iElaamXBr5op2+KVFo0qpQ= MIME-Version: 1.0 Received: by 10.231.193.11 with SMTP id ds11mr9720653ibb.192.1278687397509; Fri, 09 Jul 2010 07:56:37 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.214.145 with HTTP; Fri, 9 Jul 2010 07:56:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Jul 2010 07:56:37 -0700 X-Google-Sender-Auth: g2OhCWWqH1UAiHIsW3_4Y3b1lr4 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [patch] SUBDIR_OVERRIDE `optimization' 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, 09 Jul 2010 14:56:39 -0000 (Let's try this again with the right email address) =A0 =A0Something simple that I noticed a while back when I was reviewing the Makefile.inc1 code. The SUBDIR_OVERRIDE code is executed after the conditional feature checks, which sets the value of SUBDIRS to the user defined value. So instead of going through the conditionals, one could just cut to the chase and set SUBDIRS to SUBDIRS_OVERRIDE, otherwise detect the conditional directories to include in Makefile.inc1. Thanks! -Garrett Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.inc1 (revision 209684) +++ Makefile.inc1 (working copy) @@ -41,6 +41,9 @@ # use that new version. And the new (dynamically-linked) /bin/sh # will expect to find appropriate libraries in /lib and /libexec. # +.if defined(SUBDIR_OVERRIDE) +SUBDIR=3D ${SUBDIR_OVERRIDE} +.else SUBDIR=3D share/info lib libexec SUBDIR+=3Dbin .if ${MK_GAMES} !=3D "no" @@ -79,8 +82,6 @@ .endif .endfor -.if defined(SUBDIR_OVERRIDE) -SUBDIR=3D ${SUBDIR_OVERRIDE} .endif .if defined(NOCLEAN) From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 9 15:00:25 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 C70FB106564A for ; Fri, 9 Jul 2010 15:00:25 +0000 (UTC) (envelope-from yanegomi@gmail.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 901248FC13 for ; Fri, 9 Jul 2010 15:00:25 +0000 (UTC) Received: by iwn35 with SMTP id 35so2802812iwn.13 for ; Fri, 09 Jul 2010 08:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=p+cO4s4ubZcDWjlkDe2LoOPcXrXwg8hQYEnvV9wKjro=; b=n2+MSoPACycSZbLcUFFoCxMixvWv7sFqb+6rcR9F6kG3lVULI0I2ZnQFOcwo3cBO+T pjS5h3hrq78/YVXYTmLwp2ionlrgKE+sc+HhxLi6wEt6/e8zsOgBHgsKXc3qSk0mnRGG oSD3gpCYZr1qzp3xt14a0FzQSy3Q7OhuI3PYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=r2UKPXwIk9kd5WuB5R9rQ3zznR/LmZfqhMj4/qcydw7Pmri/Mnm4SpAbdsF42fE0s6 ZgcstXry/JkuPr88otis8KcVnwTajktisHfatkos6k9lEkNpv8PYAKi0VWAP7OuIdyyg iW9bg1sWwqhnOuhsmSirCvihYHWDGqXoW8MZA= MIME-Version: 1.0 Received: by 10.42.0.66 with SMTP id 2mr3239361icb.75.1278686316445; Fri, 09 Jul 2010 07:38:36 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.214.145 with HTTP; Fri, 9 Jul 2010 07:38:36 -0700 (PDT) Date: Fri, 9 Jul 2010 07:38:36 -0700 X-Google-Sender-Auth: 4u4HjYXNjjUz0wnkOiInX53RcLc Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Florent Thoumie , portmgr@freebsd.org Subject: RFT: pkg_install patches 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, 09 Jul 2010 15:00:25 -0000 Hi hackers, There are a series of patches that I'd like to get reviewed before jumping onto another project that would clean up and move pkg_install forward. portmgr has been kind of busy lately (mostly flz), so I don't think that these have been reviewed by him: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/146857 - pkg_create(8): fix missing error call in uname check added to pkg_version in r206043 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/146859 - libpkg/msg.c removal and related cleanup I also have some patches outstanding in my p4 workspace that I'd like to get out into the real world because I added libarchive support (with bapt, kientzle, and jlaffaye's help) to pkg_install, but I suppose all in due time (I need to break down things into smaller chunks for easier consumption). Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 9 15:15: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 5289C106564A for ; Fri, 9 Jul 2010 15:15:56 +0000 (UTC) (envelope-from xorquewasp@googlemail.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 D6B6C8FC15 for ; Fri, 9 Jul 2010 15:15:55 +0000 (UTC) Received: by wyb34 with SMTP id 34so1928773wyb.13 for ; Fri, 09 Jul 2010 08:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to; bh=pUXMQgZjpY2j0zISD5LU5YNbkf8/oqqEwBA+LX8gPJA=; b=Q3fBM4WGQFe13UPvVP3Vpn1zCIyizNokFbFMpJefZCdhMmYfykF49e8J441ZNqwOIP Wbg5zyKKn/1+oyDtIZ4NGQfc6SguD+VTbs8YHga+SomUEz+OzVV/BTtHls+sGOHMYkjA PtVvpTfIlfIahVIWaUYUEDeyPhjjTm04c4T/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=m3kLmbJjhikn+r/yQI6OAraIjx10QxJnNp77k9WPNUc1yo+vDjFUwaulCaJ20o3nCv wuO+3HK3yvZRcMRMBWfe2l0OOQXMMe8fB5/intDST8rtwjz35vP+5JepubbWuqzB2SA2 zj0txG6ar/EldWWdrN49Ur80wriWaBT/0ZuRk= Received: by 10.227.146.149 with SMTP id h21mr7069939wbv.153.1278688550180; Fri, 09 Jul 2010 08:15:50 -0700 (PDT) Received: from viper.internal.network (dsl78-143-208-120.in-addr.fast.co.uk [78.143.208.120]) by mx.google.com with ESMTPS id a1sm7147521wbb.14.2010.07.09.08.15.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Jul 2010 08:15:48 -0700 (PDT) Received: by viper.internal.network (Postfix, from userid 11001) id 7BA774AC08; Fri, 9 Jul 2010 15:15:44 +0000 (UTC) Date: Fri, 9 Jul 2010 15:15:44 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20100709151544.GA42131@logik.internal.network> References: <20100707183935.GA24697@logik.internal.network> <20100707185848.GA53688@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: envy24 driver broken 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, 09 Jul 2010 15:15:56 -0000 So, anyway, I have both an Audiophile 2496 and a Delta 66 card that I can send to any developer interested in getting them working (ideally I'd like them back some day). Is there anyone interested in fixing these drivers? Bare in mind I have no idea how much work this is. The audio subsystem seems to have had a major upgrade last year but it seems that these envy24 drivers are incomplete. Regards, xw From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 10 19:33: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 5DA56106564A for ; Sat, 10 Jul 2010 19:33:12 +0000 (UTC) (envelope-from mashtizadeh@gmail.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 045E78FC17 for ; Sat, 10 Jul 2010 19:33:11 +0000 (UTC) Received: by iwn35 with SMTP id 35so4193154iwn.13 for ; Sat, 10 Jul 2010 12:33:11 -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=JQwcd/os0oAfhT+TzagDBAtihVJHjHZ8dLVO1HYxVLI=; b=AMdlpQfD/gI7cYLl/MbICMB1HSi7eCH6i2Y/zwL2TZ9202iU9T8z16N4fkdPymYzdM RZCHvORtLT6EjB6hLi+/yQgNpKua7YZUOkTDRLmJHwDYwQiwgUx4V2f3qF+5qKnxYymS byx8iION5EdGENvo2PWmURpyC1WqpoNK8ipMA= 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=Da8Zk+HjNcCJHkj2v95Gavl1EtISxHL6zQYzNabsvLaGEPs0vX6oOqvF2AAocNIZXS Dx5tJyfmv67MZ1qjmSZt+qpM++z889baL1vud28GaUvmlAocu0M05IluwQDy1TdZf42w T+m/yuLYHfbBU5dQWsyzg/efzXfvOjC2mAtJ8= MIME-Version: 1.0 Received: by 10.231.183.200 with SMTP id ch8mr10199144ibb.124.1278790390745; Sat, 10 Jul 2010 12:33:10 -0700 (PDT) Received: by 10.231.156.19 with HTTP; Sat, 10 Jul 2010 12:33:10 -0700 (PDT) In-Reply-To: <4B79297D.9080403@FreeBSD.org> References: <4B79297D.9080403@FreeBSD.org> Date: Sat, 10 Jul 2010 12:33:10 -0700 Message-ID: From: Ali Mashtizadeh To: Maxim Sobolev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jack Vogel , FreeBSD Hackers Subject: Re: Sudden mbuf demand increase and shortage under the load 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, 10 Jul 2010 19:33:12 -0000 Hi Maxim, I experienced the same issue recently on 8-STABLE branch and it seems it has been fixed since 8.1-RC2 and above. I couldn't track down the root cause in the code nor could I find a commit that seems to be the obvious fix. Thanks, ~ Ali 2010/2/15 Maxim Sobolev : > Hi, > > Our company have a FreeBSD based product that consists of the numerous > interconnected processes and it does some high-PPS UDP processing (30-50K > PPS is not uncommon). We are seeing some strange periodic failures under = the > load in several such systems, which usually evidences itself in IPC (even > through unix domain sockets) suddenly either breaking down or pausing and > restoring only some time later (like 5-10 minutes). The only sign of fail= ure > I managed to find was the increase of the "requests for mbufs denied" in = the > netstat -m and number of total mbuf clusters (nmbclusters) raising up to = the > limit. > > I have tried to raise some network-related limits (most notably maxusers = and > nmbclusters), but it has not helped with the issue - it's still happening > from time to time to us. Below you can find output from the netstat -m fe= w > minutes right after that shortage period - you see that somehow the syste= m > has allocated huge amount of memory for the network (700MB), with only ti= ny > amount of that being actually in use. This is for the kern.ipc.nmbcluster= s: > 302400. Eventually the system reclaims all that memory and goes back to i= ts > normal use of 30-70MB. > > This problem is killing us, so any suggestions are greatly appreciated. M= y > current hypothesis is that due to some issues either with the network dri= ver > or network subsystem itself, the system goes insane and "eats" up all mbu= fs > up to nmbclusters limit. But since mbufs are shared between network and > local IPC, IPC goes down as well. > > We observe this issue with systems using both em(4) driver and igb(4) > driver. I believe both drivers share the same design, however I am not su= re > if this is some kind of design flaw in the driver or part of a larger > problem with the network subsystem. > > This happens on amd64 7.2-RELEASE and 7.3-PRERELEASE alike, with 8GB of > memory. I have not tried upgrading to 8.0, this is production system so > upgrading will not be easy. =C2=A0I don't believe there are some differen= ces that > let us hope that this problem will go away after upgrade, but I can try i= t > as the last resort. > > As I said, this is very critical issue, so I can provide any additional > debug information upon request. We are ready to go as far as paying someb= ody > reasonable amount of money for tracking down and resolving the issue. > > Regards, > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > T/F: +1-646-651-1110 > Web: http://www.sippysoft.com > MSN: sales@sippysoft.com > Skype: SippySoft > > > [ssp-root@ds-467 /usr/src]$ netstat -m > 17061/417669/434730 mbufs in use (current/cache/total) > 10420/291980/302400/302400 mbuf clusters in use (current/cache/total/max) > 10420/0 mbuf+clusters out of packet secondary zone in use (current/cache) > 19/1262/1281/51200 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/25600 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) > 25181K/693425K/718606K bytes allocated to network (current/cache/total) > 1246681/129567494/67681640 requests for mbufs denied > (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > [FEW MINUTES LATER] > > [ssp-root@ds-467 /usr/src]$ netstat -m > 10001/84574/94575 mbufs in use (current/cache/total) > 6899/6931/13830/302400 mbuf clusters in use (current/cache/total/max) > 6899/6267 mbuf+clusters out of packet secondary zone in use (current/cach= e) > 2/1151/1153/51200 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/25600 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) > 16306K/39609K/55915K bytes allocated to network (current/cache/total) > 1246681/129567494/67681640 requests for mbufs denied > (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > _______________________________________________ > 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" > --=20 Ali Mashtizadeh =D8=B9=D9=84=DB=8C =D9=85=D8=B4=D8=AA=DB=8C =D8=B2=D8=A7=D8=AF=D9=87