From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 22:49:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C259810656A5; Sat, 21 Aug 2010 22:49:47 +0000 (UTC) (envelope-from sektie@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 57F9F8FC21; Sat, 21 Aug 2010 22:49:46 +0000 (UTC) Received: by qwg5 with SMTP id 5so4640608qwg.13 for ; Sat, 21 Aug 2010 15:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=DliOtuYO3Twj2Mmpet2fwK3sLt+nwKc5FF6QVNzyCt4=; b=aihmDUoWhX2DPqJ2AViIgSROZQ4xRu3aCh2oCV4LpryFWK8+/TT6p0zpnU2hSMYzOW gzHHnRGt4CtDf6tTDoO0Y1biXWuyon/hGZ2w73EY2bahjDRMedUE9V4SpCAsTGL2fLO8 /U3HI83UhcWVaj28H22ef0RFNxefT3zbwWBCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=nMG5cduwnUNX68WpFD+bONN4MMSnhD8mmgK0RpOOuxKiFxOOgm2IN5vwVxTrKXNNam svuSPqmC2SlSHml3cwK7zmfbKA5TotUfe873TukVn3KaHuim28hX9wfc7t1+fj9b5YB6 TGTShV022HZKEOqIRBMWdS6z4GRQIek4ph0g4= Received: by 10.229.251.210 with SMTP id mt18mr2290055qcb.151.1282429379256; Sat, 21 Aug 2010 15:22:59 -0700 (PDT) Received: from [192.168.0.34] ([173.156.245.188]) by mx.google.com with ESMTPS id l8sm5011232qck.30.2010.08.21.15.22.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Aug 2010 15:22:58 -0700 (PDT) References: <9674C06D-DC2D-40C3-B523-E397C9ADC37B@christianserving.org> <641B7F47-CD12-415D-A808-861F4E85F60C@FreeBSD.org> Message-Id: From: Randi Harper To: Rui Paulo In-Reply-To: <641B7F47-CD12-415D-A808-861F4E85F60C@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B367) Mime-Version: 1.0 (iPad Mail 7B367) Date: Sat, 21 Aug 2010 15:24:22 -0700 X-Mailman-Approved-At: Sun, 22 Aug 2010 00:15:27 +0000 Cc: "freebsd-current@freebsd.org" , Jim Riggs Subject: Re: CD/DVD ejecting after sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 22:49:47 -0000 On Aug 20, 2010, at 14:21, Rui Paulo wrote: >=20 > On 20 Aug 2010, at 20:46, Jim Riggs wrote: >=20 >> References: >>=20 >> http://www.mail-archive.com/svn-src-all@freebsd.org/msg24380.html >> http://forums.freebsd.org/showthread.php?t=3D17126 >>=20 >>=20 >> This commit automatically ejects the CD when sysinstall exits which = almost had dire consequences for me this week. As described in the = forum post, I keep a LiveFS CD in all of my servers so that I can = remotely diagnose and fix issues. I have done this for several years = now, and it has saved my tail many times. >>=20 >> However, I got a surprise when I tried it today with the new 8.1 = LiveFS CDs I had just burned. After attempting to fix a problem from = the LiveFS and rebooting back to the HD, the problem still existed. No = problem. I just tried to boot back to the CD only to find that it was = gone. Luckily, this was on a box in-house, so I was quickly able to see = what was wrong. >>=20 >> Now that I have the commit, I can roll my own patched sysinstall and = CDs, but the question is: Should we be ejecting the media without any = prompt? Obviously, for my use case, I liked the old behavior of just = reminding the user to eject the media when rebooting. I understand that = may not be optimal for some users. Can we present a dialog asking the = user if they want the media to be ejected? That still leaves me at risk = of selecting the wrong answer, I suppose. I would rather not have to = roll my own LiveFS CDs every time, though. >>=20 >> Thoughts from anyone else? (Please copy me on responses.) >=20 > You are correct. We should not be ejecting the CD without a prompt. If = the commit is reverted, it should be explicitly noted in the code so = that we don't do this mistake again. >=20 > Regards, > -- > Rui Paulo >=20 >=20 That's a judgement call, not an absolute. I think what we are doing = isn't a problem for 99.999% of use cases. -- randi= From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 01:28:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 534FA106564A; Sun, 22 Aug 2010 01:28:57 +0000 (UTC) (envelope-from amvandemore@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 E77028FC12; Sun, 22 Aug 2010 01:28:56 +0000 (UTC) Received: by qwg5 with SMTP id 5so4698623qwg.13 for ; Sat, 21 Aug 2010 18:28:56 -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=CnwQXMZcS0U266jjW4jXUoKXrTpGw+PJuE4+SwyJrA4=; b=uTPP2liTUANCNSJJS+HQDVnx4diCSHfrBUqptDMgCJksBfqB2mgLmZ6lG3/w6Silbu ptBcr6VQmERTQ8N4N4bmmvF5Lc+QRL9ft8k0WhtL/64jk7TsXdC1y/oP0byxor9Gv9rS 1efSg5R+IW6KtdFNDRIO8MIg044+f/BzySk74= 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=APBtu9sV2bLsrCIXu0fea0aMoYwxa09jzRnD3VmYIUoV3NJ1xnhu6o7vted1HneioU E1bb+OzjFcvNiBsYBH4DYq7aqh0rW+/rzIuEZey6UNd2QROAPnCyhtCDKi2wH6CNZoeH 4qGltXSp0UMZuqKhvBcMOWZw7Q29XMTeiakf0= MIME-Version: 1.0 Received: by 10.229.117.25 with SMTP id o25mr1248018qcq.197.1282438985498; Sat, 21 Aug 2010 18:03:05 -0700 (PDT) Received: by 10.229.75.76 with HTTP; Sat, 21 Aug 2010 18:03:05 -0700 (PDT) In-Reply-To: References: <9674C06D-DC2D-40C3-B523-E397C9ADC37B@christianserving.org> <641B7F47-CD12-415D-A808-861F4E85F60C@FreeBSD.org> Date: Sat, 21 Aug 2010 20:03:05 -0500 Message-ID: From: Adam Vande More To: Randi Harper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-current@freebsd.org" , Rui Paulo , Jim Riggs Subject: Re: CD/DVD ejecting after sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 01:28:57 -0000 On Sat, Aug 21, 2010 at 5:24 PM, Randi Harper wrote: > On Aug 20, 2010, at 14:21, Rui Paulo wrote: > > > > You are correct. We should not be ejecting the CD without a prompt. If > the commit is reverted, it should be explicitly noted in the code so that we > don't do this mistake again. > > > > Regards, > > -- > > Rui Paulo > > > > > > That's a judgement call, not an absolute. I think what we are doing isn't a > problem for 99.999% of use cases. > I think 99.999% is a bit high, as couple times during my FreeBSD usage this would have been a problem for me although is not currently an issue. I don't really know what problem this solves as it is unnecessary in 100% of use cases as far as I can tell. It's not that I don't appreciate the thought behind it, but this will be problem for others I imagine as well. It's a VERY big inconvenience sometimes to visit a datacenter when you thought you had a rock solid remote setup in place. In defense of the current behavior, you can get basically the same behavior by setting up a PXE boot system, but that is not always desirable or convenient. Also all KVM's don't give the option to remotely load ISO's. -- Adam Vande More From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 05:58:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0072E1065695; Sun, 22 Aug 2010 05:58:35 +0000 (UTC) (envelope-from jhellenthal@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 A9A4A8FC08; Sun, 22 Aug 2010 05:58:34 +0000 (UTC) Received: by iwn36 with SMTP id 36so5213655iwn.13 for ; Sat, 21 Aug 2010 22:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=bD6QWBlJ4gj+wMSGOA12DGJpqP0liEpZsIhFuYg655k=; b=QLOv6QAmTHk4BixkH1JZISJRD7Wz6n69MsukUaS54eV7YSaU4YjWViC/NMM6L/MG51 ezTaO7UoW01ywL49Eo2s1kIlraObwYXitYqWC5pw7h3Cox9j8sbN5eRw+ZLdzqzQTVlN k06Wy4wYlD4TkoTePQmsZveFUxiF40oi0oPZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=fK2hP/GkEg21ghLvzZbcJ/wzerdb0dvjwTjkEQnUOz0hyS0bJwslJlmI6fbeiJAtSj 5iEB46cUcS3QNTSMZsAskXOO9pVbz0UUIyrTn+fajVqpy5pLIeiyGLHIPohFSxpPf/LC MnDMhBe9aLTTUFkYq69nNcgnYe42F4aEJYweg= Received: by 10.231.166.72 with SMTP id l8mr4500801iby.95.1282456714144; Sat, 21 Aug 2010 22:58:34 -0700 (PDT) Received: from centel.dataix.local (adsl-99-190-84-182.dsl.klmzmi.sbcglobal.net [99.190.84.182]) by mx.google.com with ESMTPS id h8sm4609698ibk.9.2010.08.21.22.58.31 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Aug 2010 22:58:32 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C70BC86.2040906@DataIX.net> Date: Sun, 22 Aug 2010 01:58:30 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Doug Barton References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: malus.x@gmail.com, freebsd-current@freebsd.org Subject: Re: npviewer.bin and nspluginwrapper errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 05:58:35 -0000 On 08/21/2010 01:56, Doug Barton wrote: > These are various error messages collected from running X and/or firefox > from the command line: > > *** NSPlugin Viewer *** WARNING: unhandled variable 18 ( variable>) in > NPN_GetValue() > > I get lots and lots of these, even when things are working well. > > npviewer.bin: ../src/npw-rpc.c:1190: do_send_NPObject: Assertion > `npobj_id != 0' > failed. > > *** NSPlugin Wrapper *** ERROR: NPN_ReleaseObject() get args: > Connection closed > *** NSPlugin Wrapper *** ERROR: NPP_Destroy() wait for reply: > Connection closed > *** NSPlugin Wrapper *** ERROR: NPObject 0x2fac2100 is no longer valid! > > When I get these "no longer valid" errors is usually about the time that > intr starts to run away. > > *** NSPlugin Wrapper *** > WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwra > pper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: > asse > rtion failed: (rpc_method_invoke_possible(plugin->connection)) > > *** NSPlugin Wrapper *** ERROR: NPClass::HasProperty() wait for reply: > Connection closed > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** > WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwrapper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: > assertion failed: (rpc_method_invoke_possible(plugin->connection)) > *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! > *** NSPlugin Wrapper *** > WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwrapper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: > assertion failed: (rpc_method_invoke_possible(plugin->connection)) > > > FWIW I get these very same errors on a stable/8 client machine and I do not have the same results as you with intr or any other video adapter. Everything seems fine here. Good luck, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 11:05:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3357210656A7; Sun, 22 Aug 2010 11:05:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id CAD8E8FC16; Sun, 22 Aug 2010 11:05:39 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2AC5F45E86; Wed, 18 Aug 2010 14:15:56 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1AC1945CAC; Wed, 18 Aug 2010 14:15:51 +0200 (CEST) Date: Wed, 18 Aug 2010 14:15:50 +0200 From: Pawel Jakub Dawidek To: Ed Schouten Message-ID: <20100818121550.GD2177@garage.freebsd.pl> References: <4C6B9F51.1060009@freebsd.org> <20100818104853.GB2978@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Km1U/tdNT/EmXiR1" Content-Disposition: inline In-Reply-To: <20100818104853.GB2978@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, Daichi GOTO , freebsd-current@freebsd.org Subject: Re: Mounting cd9660 multiple times gives EBUSY [Was: unionfs a little improvement] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 11:05:40 -0000 --Km1U/tdNT/EmXiR1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 18, 2010 at 12:48:53PM +0200, Ed Schouten wrote: > Hi Daichi, >=20 > I think Keith Packard of Xorg once wrote a commit message along the > lines of "5000 lines of code removed, feature added" This seems to be > similar, albeit on a smaller scale. ;-) >=20 > Apart from this issue with unionfs, I am also experiencing another > issue, where for some reason I cannot perform a second mount of the CD > right after booting the system. Basically, my WIP FreeBSD boot CD does > the following (but written in C): >=20 > mount -t cd9660 /dev/iso9660/freebsd /mnt > mount -t tmpfs none /tmp > mount -t unionfs /tmp /mnt > mount -t devfs none /mnt/dev > chroot /mnt /sbin/init >=20 > The first step fails with EBUSY. I use the following hack to get it > working, but I don't think it's the proper way to solve it: What you are trying to do here is to mount /dev/iso9660/freebsd for the second time? This is not supported. The check is there to prevent doing this, as it will panic on you when you try to unmount first mount (not really a problem in your case, as the first mount is /, so you probably don't want to unmount it, but it is a problem in general). You should be able to reproduce the panic with your patch applied by doing the following: # mount -t cd9660 /dev/iso9660/freebsd /mnt0 # mount -t cd9660 /dev/iso9660/freebsd /mnt1 # umount /mnt0 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Km1U/tdNT/EmXiR1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkxrzvUACgkQForvXbEpPzRytgCgo8Cm2ShBhf8i+rFg9nvOiNn8 bMoAn2J+eG3iColgrWmofQQlfPP4OIvW =GD6x -----END PGP SIGNATURE----- --Km1U/tdNT/EmXiR1-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 11:21:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E78B0106564A; Sun, 22 Aug 2010 11:21:36 +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 A21408FC1C; Sun, 22 Aug 2010 11:21:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B65DA1FFC34; Sun, 22 Aug 2010 11:21:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 97D34845D6; Sun, 22 Aug 2010 13:21:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gabor PALI References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <86r5htdqmu.fsf@ds4.des.no> Date: Sun, 22 Aug 2010 13:21:35 +0200 In-Reply-To: (Gabor PALI's message of "Fri, 20 Aug 2010 21:40:21 +0200") Message-ID: <86wrriki4g.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-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 11:21:37 -0000 Gabor PALI writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Gabor PALI writes: > > > Sorry for chiming in, just a quick idea. If you find the "get a > > > high-level language that compiled to C" idea good, > > I don't think it's a good idea > Could you be more specific on your concerns? I am just curious. If we want compiled code, we already have C and C++. What we need is an interpreted language with good libraries so people can write scripts and one-liners without having to jump through too many hoops and worry about quoting. The result may not be as fast as a compiled program, but it will be much faster than a shell script and take less time to write than either C or shell. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 11:42:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D43A21065694; Sun, 22 Aug 2010 11:42:39 +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 938B88FC1C; Sun, 22 Aug 2010 11:42:39 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A9C9C1FFC37; Sun, 22 Aug 2010 11:42:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 836B88447F; Sun, 22 Aug 2010 13:42:38 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Randi Harper References: <9674C06D-DC2D-40C3-B523-E397C9ADC37B@christianserving.org> <641B7F47-CD12-415D-A808-861F4E85F60C@FreeBSD.org> Date: Sun, 22 Aug 2010 13:42:38 +0200 In-Reply-To: (Randi Harper's message of "Sat, 21 Aug 2010 15:24:22 -0700") Message-ID: <86sk26kh5d.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-current@freebsd.org" , Rui Paulo , Jim Riggs Subject: Re: CD/DVD ejecting after sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 11:42:39 -0000 Randi Harper writes: > Rui Paulo writes: > > You are correct. We should not be ejecting the CD without a > > prompt. If the commit is reverted, it should be explicitly noted in > > the code so that we don't do this mistake again. > That's a judgement call, not an absolute. I think what we are doing > isn't a problem for 99.999% of use cases. On the rare occasions where I use sysinstall, I usually find that prompt annoying... but I almost broke a CD drive once by ejecting the tray with the enclosure's dust cover half closed. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 11:48:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 234EC106577B for ; Sun, 22 Aug 2010 11:48:39 +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 B6AFC8FC0C for ; Sun, 22 Aug 2010 11:48:38 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id BA56D1FFC34; Sun, 22 Aug 2010 11:48:37 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 95965844B1; Sun, 22 Aug 2010 13:48:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: gahn References: <781712.60498.qm@web52302.mail.re2.yahoo.com> Date: Sun, 22 Aug 2010 13:48:37 +0200 In-Reply-To: <781712.60498.qm@web52302.mail.re2.yahoo.com> (gahn's message of "Fri, 20 Aug 2010 15:08:30 -0700 (PDT)") Message-ID: <86occukgve.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: free bsd , freebsd general questions Subject: Re: meory file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 11:48:40 -0000 gahn writes: > I am running 8.1. under /dev, I don't see /dev/md0, /dev/md0 won't show up until you actually run mdconfig. > so i am trying to add following lines in kernel file and got error > messages: > > options MFS #Memory Filesystem The correct line is "device md", but mdconfig(8) will automatically load the module, so you don't need it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 11:54:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F51810656AD; Sun, 22 Aug 2010 11:54:37 +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 C2C848FC16; Sun, 22 Aug 2010 11:54:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B17F61FFC37; Sun, 22 Aug 2010 11:54:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8A3E4844B1; Sun, 22 Aug 2010 13:54:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Haertel References: <201008210231.o7L2VRvI031700@ducky.net> Date: Sun, 22 Aug 2010 13:54:35 +0200 In-Reply-To: <201008210231.o7L2VRvI031700@ducky.net> (Mike Haertel's message of "Fri, 20 Aug 2010 19:31:27 -0700") Message-ID: <86k4nikglg.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-current@freebsd.org, gabor@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 11:54:40 -0000 Mike Haertel writes: > GNU grep uses the well-known Boyer-Moore algorithm, which looks > first for the final letter of the target string, and uses a lookup > table to tell it how far ahead it can skip in the input whenever > it finds a non-matching character. Boyer-Moore is for fixed search strings. I don't see how that optimization can work with a regexp search unless the regexp is so simple that you break it down into a small number of cases with known length and final character. > GNU grep uses raw Unix input system calls and avoids copying data > after reading it. Yes, that was the first thing we looked at (and fixed) in BSD grep. > Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking > for newlines would slow grep down by a factor of several times, > because to find the newlines it would have to look at every byte! Amen. The current bottleneck in BSD grep is the memchr() that looks for '\n' in the input buffer. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 12:10:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 143981065694; Sun, 22 Aug 2010 12:10:50 +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 C4CE08FC19; Sun, 22 Aug 2010 12:10:49 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D289F1FFC34; Sun, 22 Aug 2010 12:10:48 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A585584497; Sun, 22 Aug 2010 14:10:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Whitehorn References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> <4C6E825C.5060509@freebsd.org> <86fwy9f5vj.fsf@ds4.des.no> <4C6F0813.9030007@freebsd.org> <86aaofpr7j.fsf@ds4.des.no> <4C704CD2.9040604@freebsd.org> Date: Sun, 22 Aug 2010 14:10:48 +0200 In-Reply-To: <4C704CD2.9040604@freebsd.org> (Nathan Whitehorn's message of "Sat, 21 Aug 2010 17:01:54 -0500") Message-ID: <86bp8ukfuf.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: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 12:10:50 -0000 Nathan Whitehorn writes: > Dag-Erling Sm=C3=B8rgrav writes: > > I'm not sure I understand what you mean (or rather, how it would > > help the tinderbox). What *would* help would be an easy way to > > determine, *before* trying to build it, whether a specific kernel > > config is appropriate for a specific target. Can you think of an > > easier way to do this than to scan the config for the "machine" > > line? > That's exactly what I proposed. You use config, before trying the > build, to look up the machine specification for the config file. I > sent you a 5 line patch to tinderbox.pl that does this by private > email. Here's a solution that works regadless of config(8) version, though I'm not sure it qualifies as either easy or clean: Index: tinderbox.pl =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 RCS file: /home/projcvs/projects/tinderbox/tinderbox.pl,v retrieving revision 1.68 diff -u -r1.68 tinderbox.pl --- tinderbox.pl 25 Aug 2009 17:28:14 -0000 1.68 +++ tinderbox.pl 22 Aug 2010 12:08:46 -0000 @@ -722,10 +722,29 @@ } =20 # Build additional kernels + kernel: foreach my $kernel (sort(keys(%kernels))) { if (! -f "$srcdir/sys/$machine/conf/$kernel") { warning("no kernel config for $kernel"); - next; + next kernel; + } + # Hack: check that the config is appropriate for this target. + # If no "machine" declaration is present, assume that it is. + local *KERNCONF; + if (open(KERNCONF, "<", "$srcdir/sys/$machine/conf/$kernel")) { + while () { + next unless m/^machine\s+(\w+(?:\s+\w+)?)\s*(?:\#.*)?$/; + if ($1 !~ m/^\Q$machine\E(\s+\Q$arch\E)?$/) { + warning("skipping $kernel"); + close(KERNCONF); + next kernel; + } + last; + } + close(KERNCONF); + } else { + warning("$kernel: $!"); + next kernel; } logstage("building $kernel kernel"); logenv(); It will break if the "machine" declaration ever moves into an included file, since it does not follow include statements, but it will do for now. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 12:20:21 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFE91065673 for ; Sun, 22 Aug 2010 12:20:21 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4408FC1A for ; Sun, 22 Aug 2010 12:20:20 +0000 (UTC) Received: from [192.168.0.3] (p4FE323AF.dip.t-dialin.net [79.227.35.175]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id o7MC3J0n012235 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 22 Aug 2010 14:03:19 +0200 (CEST) Message-ID: <4C711207.5090608@FreeBSD.org> Date: Sun, 22 Aug 2010 14:03:19 +0200 From: Matthias Andree Organization: FreeBSD User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Mnenhy/0.8.2 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <86r5htdqmu.fsf@ds4.des.no> <86wrriki4g.fsf@ds4.des.no> In-Reply-To: <86wrriki4g.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 12:20:21 -0000 Am 22.08.2010 13:21, schrieb Dag-Erling Smørgrav: > Gabor PALI writes: >> Dag-Erling Smørgrav writes: >>> Gabor PALI writes: >>>> Sorry for chiming in, just a quick idea. If you find the "get a >>>> high-level language that compiled to C" idea good, >>> I don't think it's a good idea >> Could you be more specific on your concerns? I am just curious. > > If we want compiled code, we already have C and C++. What we need is an > interpreted language with good libraries so people can write scripts and > one-liners without having to jump through too many hoops and worry about > quoting. The result may not be as fast as a compiled program, but it > will be much faster than a shell script and take less time to write than > either C or shell. Looks a bit like a swing. First we remove Perl from the base system (years ago) and move to sed/awk, now we discuss using a scripting language in the base system... From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 13:29:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E77A10656A5; Sun, 22 Aug 2010 13:29:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 28C388FC0C; Sun, 22 Aug 2010 13:29:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7MDTOIm074415; Sun, 22 Aug 2010 09:29:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7MDTOIM074414; Sun, 22 Aug 2010 13:29:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 22 Aug 2010 13:29:24 GMT Message-Id: <201008221329.o7MDTOIM074414@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 13:29:25 -0000 TB --- 2010-08-22 11:13:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-22 11:13:56 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-22 11:13:56 - cleaning the object tree TB --- 2010-08-22 11:14:44 - cvsupping the source tree TB --- 2010-08-22 11:14:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-22 11:15:15 - building world TB --- 2010-08-22 11:15:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 11:15:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 11:15:15 - TARGET=powerpc TB --- 2010-08-22 11:15:15 - TARGET_ARCH=powerpc64 TB --- 2010-08-22 11:15:15 - TZ=UTC TB --- 2010-08-22 11:15:15 - __MAKE_CONF=/dev/null TB --- 2010-08-22 11:15:15 - cd /src TB --- 2010-08-22 11:15:15 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 11:15:15 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Aug 22 12:58:14 UTC 2010 TB --- 2010-08-22 12:58:14 - generating LINT kernel config TB --- 2010-08-22 12:58:14 - cd /src/sys/powerpc/conf TB --- 2010-08-22 12:58:14 - /usr/bin/make -B LINT TB --- 2010-08-22 12:58:14 - building LINT kernel TB --- 2010-08-22 12:58:14 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 12:58:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 12:58:14 - TARGET=powerpc TB --- 2010-08-22 12:58:14 - TARGET_ARCH=powerpc64 TB --- 2010-08-22 12:58:14 - TZ=UTC TB --- 2010-08-22 12:58:14 - __MAKE_CONF=/dev/null TB --- 2010-08-22 12:58:14 - cd /src TB --- 2010-08-22 12:58:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 12:58:14 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Aug 22 13:24:10 UTC 2010 TB --- 2010-08-22 13:24:10 - building GENERIC kernel TB --- 2010-08-22 13:24:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 13:24:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 13:24:10 - TARGET=powerpc TB --- 2010-08-22 13:24:10 - TARGET_ARCH=powerpc64 TB --- 2010-08-22 13:24:10 - TZ=UTC TB --- 2010-08-22 13:24:10 - __MAKE_CONF=/dev/null TB --- 2010-08-22 13:24:10 - cd /src TB --- 2010-08-22 13:24:10 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 22 13:24:10 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 13:29:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 13:29:24 - ERROR: failed to build GENERIC kernel TB --- 2010-08-22 13:29:24 - 5654.18 user 1511.02 system 8127.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 13:47:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 895FB1065674 for ; Sun, 22 Aug 2010 13:47:51 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 184018FC1B for ; Sun, 22 Aug 2010 13:47:50 +0000 (UTC) Received: (qmail 61817 invoked from network); 22 Aug 2010 13:21:08 -0000 Received: from 93.166.52.54 (HELO x2.osted.lan) (93.166.52.54) by relay01.pair.com with SMTP; 22 Aug 2010 13:21:08 -0000 X-pair-Authenticated: 93.166.52.54 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.3/8.14.3) with ESMTP id o7MDL6eT007688; Sun, 22 Aug 2010 15:21:06 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.3/8.14.3/Submit) id o7MDL53q007685; Sun, 22 Aug 2010 15:21:05 +0200 (CEST) (envelope-from pho) Date: Sun, 22 Aug 2010 15:21:04 +0200 From: Peter Holm To: Michael Butler Message-ID: <20100822132104.GA7300@x2.osted.lan> References: <4C7011B9.4020902@protected-networks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7011B9.4020902@protected-networks.net> User-Agent: Mutt/1.4.2.3i Cc: Jeff Roberson , current@freebsd.org Subject: Re: softupdate with journal panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 13:47:51 -0000 On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote: > While updating sysutils/coreutils port on -current as of this morning > (SVN r211550), I noted a panic during the directory rename config test. > Your problem seems identical to this report: http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC - Peter From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 15:15:04 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 260211065674 for ; Sun, 22 Aug 2010 15:15:04 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [IPv6:2a01:4f8:100:1043::2]) by mx1.freebsd.org (Postfix) with ESMTP id B30B58FC16 for ; Sun, 22 Aug 2010 15:15:03 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 9B7469EC1D for ; Sun, 22 Aug 2010 17:15:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZWAwoByzKFSz for ; Sun, 22 Aug 2010 17:15:00 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 9AA469EC08 for ; Sun, 22 Aug 2010 17:15:00 +0200 (CEST) Message-ID: <4C713EF5.8080402@FreeBSD.org> Date: Sun, 22 Aug 2010 17:15:01 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: Subject: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 15:15:04 -0000 Dear FreeBSD community, many of our [2] (and Solaris [3]) users today are complaining about slow ZFS writes. One of the causes for these writes is the selection of the proper allocation method for allocation of new blocks [3] [4]. Another issue a write slowdown during TXG sync times. Solaris 10 (and OpenSolaris up to november 2009) have the following scenario: - pool has more than 30% free space: use first fit method [1] - pool has less than 30% free space: use best fit method [1] This causes a major slowdown of the writes if we go below 30% of free space. On large pools, 30% may be terabytes of free space. OpenSolaris has changed this in November 2009 and the Oracle Storage Appliances also included the new code in Q1/2010 [1]. The source [1] states, that with this change they archieved a speedup of: "50% Improved OLTP Performance, 70% Reduced Variability, 200% Improvement on MS Exchange" I would like to issue a Call For Testing for the following 9-CURRENT patch: http://people.freebsd.org/~mm/patches/zfs/zfs_metaslab.patch To apply the patch against 8-STABLE, you need to apply the v15 update first: http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch The patch includes the following OpenSolaris onnv revisions: 10921 (partial), 11146, 11728, 12047 And covers the following Bug IDs: 6826241 Sync write IOPS drops dramatically during TXG sync 6869229 zfs should switch to shiny new metaslabs more frequently 6917066 zfs block picking can be improved 6918420 zdb -m has issues printing metaslab statistics References: [1] http://blogs.sun.com/roch/entry/doubling_exchange_performance [2] http://forums.freebsd.org/showthread.php?t=8270 [3] http://blogs.everycity.co.uk/alasdair/2010/07/zfs-runs-really-slowly-when-free-disk-usage-goes-above-80/ [4] http://blogs.sun.com/bonwick/entry/zfs_block_allocation [5] http://blogs.sun.com/bonwick/entry/space_maps From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 15:25:36 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9097106564A for ; Sun, 22 Aug 2010 15:25:36 +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 9E1988FC16 for ; Sun, 22 Aug 2010 15:25:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A82651FFC34; Sun, 22 Aug 2010 15:25:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 83272845D4; Sun, 22 Aug 2010 17:25:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Matthias Andree References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <86r5htdqmu.fsf@ds4.des.no> <86wrriki4g.fsf@ds4.des.no> <4C711207.5090608@FreeBSD.org> Date: Sun, 22 Aug 2010 17:25:35 +0200 In-Reply-To: <4C711207.5090608@FreeBSD.org> (Matthias Andree's message of "Sun, 22 Aug 2010 14:03:19 +0200") Message-ID: <86r5hqzn2o.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-current@FreeBSD.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 15:25:37 -0000 Matthias Andree writes: > Looks a bit like a swing. First we remove Perl from the base system > (years ago) and move to sed/awk, now we discuss using a scripting > language in the base system... Read the discussion from the beginning. We are discussing introducing a domain-specific scripting language, not a general-purpose one. BTW, most of the Perl scripts we had were rewritten in C, not sed / awk. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 15:26:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0F63106564A for ; Sun, 22 Aug 2010 15:26:19 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 928CF8FC17 for ; Sun, 22 Aug 2010 15:26:19 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id o7MF2bvm086739; Sun, 22 Aug 2010 11:02:37 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id o7MF2bfZ086738; Sun, 22 Aug 2010 11:02:37 -0400 (EDT) (envelope-from wollman) Date: Sun, 22 Aug 2010 11:02:37 -0400 (EDT) From: Garrett Wollman Message-Id: <201008221502.o7MF2bfZ086738@hergotha.csail.mit.edu> To: des@des.no In-Reply-To: <86k4nikglg.fsf@ds4.des.no> References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> Organization: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 22 Aug 2010 11:02:37 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 22 Aug 2010 15:41:38 +0000 Cc: current@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 15:26:20 -0000 In article <86k4nikglg.fsf@ds4.des.no> you write: >Mike Haertel writes: >> GNU grep uses the well-known Boyer-Moore algorithm, which looks >> first for the final letter of the target string, and uses a lookup >> table to tell it how far ahead it can skip in the input whenever >> it finds a non-matching character. > >Boyer-Moore is for fixed search strings. I don't see how that >optimization can work with a regexp search unless the regexp is so >simple that you break it down into a small number of cases with known >length and final character. The common case of regexps used in the "grep" utility (and, for obvious reasons, universal in the "fgrep" utility) is fixed-length search strings. Even non-fixed-length regexps typically consist of one one or two variable-length parts. Matching a completely variable-length regexp is just hard, computationally, so it's OK for it to be slower. There are other tricks you can do, such as turning the anchors ^ and $ into explicit newlines in your search -- "^foo" is a very common regexp to search for, and it's really a fixed-string search for "\nfoo" which is entirely amenable to the B-M treatment. You just have to remember that a matched newline isn't part of the result. The GNU regexp library also uses the Boyer-Moore (or is it Boyer-Moore-Gosper?) strategy. -GAWollman From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 15:44:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F4410656A5 for ; Sun, 22 Aug 2010 15:44:53 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 812C98FC20 for ; Sun, 22 Aug 2010 15:44:53 +0000 (UTC) Received: by iwn36 with SMTP id 36so5560600iwn.13 for ; Sun, 22 Aug 2010 08:44:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.31.71 with SMTP id x7mr4871366ibc.33.1282491892704; Sun, 22 Aug 2010 08:44:52 -0700 (PDT) Received: by 10.231.176.140 with HTTP; Sun, 22 Aug 2010 08:44:52 -0700 (PDT) In-Reply-To: <4C713EF5.8080402@FreeBSD.org> References: <4C713EF5.8080402@FreeBSD.org> Date: Sun, 22 Aug 2010 17:44:52 +0200 Message-ID: From: Olivier Smedts To: Martin Matuska Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 15:44:53 -0000 2010/8/22 Martin Matuska : > Dear FreeBSD community, > > many of our [2] (and Solaris [3]) users today are complaining about slow > ZFS writes. One of the causes for these writes is the selection of the > proper allocation method for allocation of new blocks [3] [4]. Another > issue a write slowdown during TXG sync times. > > Solaris 10 (and OpenSolaris up to november 2009) have the > following scenario: > > - pool has more than 30% free space: use first fit method [1] > - pool has less than 30% free space: use best fit method [1] > > This causes a major slowdown of the writes if we go below 30% of free > space. On large pools, 30% may be terabytes of free space. > > OpenSolaris has changed this in November 2009 and the Oracle Storage > Appliances also included the new code in Q1/2010 [1]. > > The source [1] states, that with this change they archieved a speedup > of: "50% Improved OLTP Performance, 70% Reduced Variability, 200% > Improvement on MS Exchange" > > I would like to issue a Call For Testing for the following 9-CURRENT patc= h: > http://people.freebsd.org/~mm/patches/zfs/zfs_metaslab.patch > > To apply the patch against 8-STABLE, you need to apply the v15 update fir= st: > http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch This one doesn't apply cleanly since few minutes : # svn log -l 1 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c ------------------------------------------------------------------------ r211599 | avg | 2010-08-22 10:18:32 +0200 (Dim 22 ao=FB 2010) | 7 lignes Fix a mismerge in r211581, MFC of r210427 This is a direct commit. Reported by: many Pointyhat to: avg ------------------------------------------------------------------------ But it does not seem hard to correct. Do you want me to submit an updated patch for 8-stable ? > The patch includes the following OpenSolaris onnv revisions: > 10921 (partial), 11146, 11728, 12047 > > And covers the following Bug IDs: > 6826241 Sync write IOPS drops dramatically during TXG sync > 6869229 zfs should switch to shiny new metaslabs more frequently > 6917066 zfs block picking can be improved > 6918420 zdb -m has issues printing metaslab statistics > > References: > [1] http://blogs.sun.com/roch/entry/doubling_exchange_performance > [2] http://forums.freebsd.org/showthread.php?t=3D8270 > [3] > http://blogs.everycity.co.uk/alasdair/2010/07/zfs-runs-really-slowly-when= -free-disk-usage-goes-above-80/ > [4] http://blogs.sun.com/bonwick/entry/zfs_block_allocation > [5] http://blogs.sun.com/bonwick/entry/space_maps > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 16:11:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DB9D1065672 for ; Sun, 22 Aug 2010 16:11:47 +0000 (UTC) (envelope-from delphij@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 2392D8FC0A for ; Sun, 22 Aug 2010 16:11:46 +0000 (UTC) Received: by iwn36 with SMTP id 36so5579996iwn.13 for ; Sun, 22 Aug 2010 09:11:46 -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=iHt57/CWRy9qkdFDwlm5HbTTxVA8zV9qFRJcL7xT8KE=; b=B/fQLA0sD+p47ggUFbg/n8tt8er4j4J4D64Fb4YHSdFi3lHYilQA6gp3YL9zNZH1vV VeEDPlYvDMBBYvXZet/Fd7Pu241AhVt0O9ex/4Jwyn0auREWvyzgaa0Mf4SrbuHvFFBS iUJqrn2zCG24rOac+taAr80v2O0DY5tA8J6Uc= 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=KmwjVmtiOigDQppf0SVFxuXaErLK1sHhQ5vfgOo3JiDSF2zn9zV6+YK2lrzo3oHAzi DjBxJykF8dFz4Pd0hG9boJktNzWE14QzsfcspltozaQ6yt2KFpWFTbXRh5i0nXFF/VxT Ievy1cLNqEnoCSikVWtdq1s8lPTqi0AalZGT8= MIME-Version: 1.0 Received: by 10.231.85.206 with SMTP id p14mr5101007ibl.89.1282492108934; Sun, 22 Aug 2010 08:48:28 -0700 (PDT) Received: by 10.231.146.10 with HTTP; Sun, 22 Aug 2010 08:48:28 -0700 (PDT) In-Reply-To: <86k4nikglg.fsf@ds4.des.no> References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> Date: Sun, 22 Aug 2010 08:48:28 -0700 Message-ID: From: Xin LI To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Haertel , gabor@freebsd.org, freebsd-current@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 16:11:47 -0000 2010/8/22 Dag-Erling Sm=C3=B8rgrav : > Amen. =C2=A0The current bottleneck in BSD grep is the memchr() that looks= for > '\n' in the input buffer. FYI I actually have a rewritten memchr() which is faster than the current one here: http://people.freebsd.org/~delphij/for_review/memchr.c Review/comments welcome. I've done some preliminary validation/benchmark on this but still need to compare it with some hand optimized assembler implementations that I have seen and see if it's worthy. Cheers, --=20 Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 16:26:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08C481065694 for ; Sun, 22 Aug 2010 16:26:43 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [IPv6:2a01:4f8:100:1043::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9456A8FC08 for ; Sun, 22 Aug 2010 16:26:42 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 5C82BA1B65; Sun, 22 Aug 2010 18:26:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qz3VjAdZoApj; Sun, 22 Aug 2010 18:26:38 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id C8986A1B57; Sun, 22 Aug 2010 18:26:38 +0200 (CEST) Message-ID: <4C714FC0.90005@FreeBSD.org> Date: Sun, 22 Aug 2010 18:26:40 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Olivier Smedts References: <4C713EF5.8080402@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 16:26:43 -0000 Thank you, I have updated the v15 patch for 8-STABLE. Dňa 22. 8. 2010 17:44, Olivier Smedts wrote / napísal(a): > 2010/8/22 Martin Matuska : >> Dear FreeBSD community, >> >> many of our [2] (and Solaris [3]) users today are complaining about slow >> ZFS writes. One of the causes for these writes is the selection of the >> proper allocation method for allocation of new blocks [3] [4]. Another >> issue a write slowdown during TXG sync times. >> >> Solaris 10 (and OpenSolaris up to november 2009) have the >> following scenario: >> >> - pool has more than 30% free space: use first fit method [1] >> - pool has less than 30% free space: use best fit method [1] >> >> This causes a major slowdown of the writes if we go below 30% of free >> space. On large pools, 30% may be terabytes of free space. >> >> OpenSolaris has changed this in November 2009 and the Oracle Storage >> Appliances also included the new code in Q1/2010 [1]. >> >> The source [1] states, that with this change they archieved a speedup >> of: "50% Improved OLTP Performance, 70% Reduced Variability, 200% >> Improvement on MS Exchange" >> >> I would like to issue a Call For Testing for the following 9-CURRENT patch: >> http://people.freebsd.org/~mm/patches/zfs/zfs_metaslab.patch >> >> To apply the patch against 8-STABLE, you need to apply the v15 update first: >> http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch > This one doesn't apply cleanly since few minutes : > # svn log -l 1 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > ------------------------------------------------------------------------ > r211599 | avg | 2010-08-22 10:18:32 +0200 (Dim 22 aoû 2010) | 7 lignes > > Fix a mismerge in r211581, MFC of r210427 > > This is a direct commit. > > Reported by: many > Pointyhat to: avg > > ------------------------------------------------------------------------ > > But it does not seem hard to correct. Do you want me to submit an > updated patch for 8-stable ? > >> The patch includes the following OpenSolaris onnv revisions: >> 10921 (partial), 11146, 11728, 12047 >> >> And covers the following Bug IDs: >> 6826241 Sync write IOPS drops dramatically during TXG sync >> 6869229 zfs should switch to shiny new metaslabs more frequently >> 6917066 zfs block picking can be improved >> 6918420 zdb -m has issues printing metaslab statistics >> >> References: >> [1] http://blogs.sun.com/roch/entry/doubling_exchange_performance >> [2] http://forums.freebsd.org/showthread.php?t=8270 >> [3] >> http://blogs.everycity.co.uk/alasdair/2010/07/zfs-runs-really-slowly-when-free-disk-usage-goes-above-80/ >> [4] http://blogs.sun.com/bonwick/entry/zfs_block_allocation >> [5] http://blogs.sun.com/bonwick/entry/space_maps >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 16:30:08 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F20A61065693; Sun, 22 Aug 2010 16:30:07 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0E58FC0A; Sun, 22 Aug 2010 16:30:07 +0000 (UTC) Received: from [192.168.1.201] ([192.168.1.201]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o7MGU1s0063186; Sun, 22 Aug 2010 11:30:01 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sun, 22 Aug 2010 11:30:01 -0500 (CDT) From: "Sean C. Farley" To: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <86k4nikglg.fsf@ds4.des.no> Message-ID: References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="4255886656-1237390696-1282494601=:1989" X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.farley.org Cc: freebsd-current@FreeBSD.org, Mike Haertel , gabor@FreeBSD.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 16:30:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4255886656-1237390696-1282494601=:1989 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote: > Mike Haertel writes: >> GNU grep uses the well-known Boyer-Moore algorithm, which looks first >> for the final letter of the target string, and uses a lookup table to >> tell it how far ahead it can skip in the input whenever it finds a >> non-matching character. > > Boyer-Moore is for fixed search strings. I don't see how that > optimization can work with a regexp search unless the regexp is so > simple that you break it down into a small number of cases with known > length and final character. When I was working on making FreeGrep faster (years ago), I wrote down a few notes about possible algorithms, especially those that could be useful for fgrep functionality. I am just passing these onto the list. Some algorithms: 1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm 2. http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm 3. GNU fgrep: Commentz-Walter 4. GLIMPSE: http://webglimpse.net/pubs/TR94-17.pdf (Boyer-Moore variant) Also, this may be a useful book: http://www.dcc.uchile.cl/~gnavarro/FPMbook/ Sean -- scf@FreeBSD.org --4255886656-1237390696-1282494601=:1989-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 16:36:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7226106567A; Sun, 22 Aug 2010 16:36:45 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 65AA98FC14; Sun, 22 Aug 2010 16:36:45 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id C5C462A28D21; Sun, 22 Aug 2010 18:36:44 +0200 (CEST) Date: Sun, 22 Aug 2010 18:36:44 +0200 From: Ed Schouten To: Mike Haertel Message-ID: <20100822163644.GU2978@hoeg.nl> References: <201008210231.o7L2VRvI031700@ducky.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zu4V1sHRt6IpqgDQ" Content-Disposition: inline In-Reply-To: <201008210231.o7L2VRvI031700@ducky.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, gabor@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 16:36:45 -0000 --Zu4V1sHRt6IpqgDQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Mike Haertel wrote: > Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking > for newlines would slow grep down by a factor of several times, > because to find the newlines it would have to look at every byte! I think that implementing a simple fgrep boils down to mmap()ing a file and calling memmem() on the mapping to search for the input string. Of course this relies on having an efficient memmem() implementation, for example using one of the algorithms mentioned in this thread. --=20 Ed Schouten WWW: http://80386.nl/ --Zu4V1sHRt6IpqgDQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxxUhwACgkQ52SDGA2eCwUZkQCcDc4rDxdk9c9GEH8duXUt42Vc g4EAnRCjEnYVt9eS8tvuE0if6BWUUFOw =yYgr -----END PGP SIGNATURE----- --Zu4V1sHRt6IpqgDQ-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 17:31:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 559861065698 for ; Sun, 22 Aug 2010 17:31:50 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3377D8FC15 for ; Sun, 22 Aug 2010 17:31:49 +0000 (UTC) Received: by pwi8 with SMTP id 8so450425pwi.13 for ; Sun, 22 Aug 2010 10:31:49 -0700 (PDT) Received: by 10.143.9.6 with SMTP id m6mr3184455wfi.310.1282498309659; Sun, 22 Aug 2010 10:31:49 -0700 (PDT) Received: from [10.123.2.181] (99-74-170-25.lightspeed.sntcca.sbcglobal.net [99.74.170.25]) by mx.google.com with ESMTPS id v38sm7179056wfh.0.2010.08.22.10.31.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 10:31:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <201008221502.o7MF2bfZ086738@hergotha.csail.mit.edu> Date: Sun, 22 Aug 2010 10:31:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <201008221502.o7MF2bfZ086738@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.1081) Cc: current@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 17:31:50 -0000 On Aug 22, 2010, at 8:02 AM, Garrett Wollman wrote: > In article <86k4nikglg.fsf@ds4.des.no> you write: >> Mike Haertel writes: >>> GNU grep uses the well-known Boyer-Moore algorithm, which looks >>> first for the final letter of the target string, and uses a lookup >>> table to tell it how far ahead it can skip in the input whenever >>> it finds a non-matching character. >> >> Boyer-Moore is for fixed search strings. I don't see how that >> optimization can work with a regexp search unless the regexp is so >> simple that you break it down into a small number of cases with known >> length and final character. > > The common case of regexps used in the "grep" utility (and, for > obvious reasons, universal in the "fgrep" utility) is fixed-length > search strings. Even non-fixed-length regexps typically consist of > one one or two variable-length parts. This is an important point: A good grep implementation will use different strategies depending on the input regexp. Fixed-string matching is a very important special case. > Matching a completely > variable-length regexp is just hard, computationally, See Russ Cox' articles for why this is not true. It does require considerable sophistication to build an efficient DFA but the actual matcher, once built, can run very fast indeed: http://swtch.com/~rsc/regexp/ Tim From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 17:04:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FCFB1065670 for ; Sun, 22 Aug 2010 17:04:08 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 55D678FC19 for ; Sun, 22 Aug 2010 17:04:08 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id o7MH40BG088796; Sun, 22 Aug 2010 13:04:00 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id o7MH40pV088795; Sun, 22 Aug 2010 13:04:00 -0400 (EDT) (envelope-from wollman) Date: Sun, 22 Aug 2010 13:04:00 -0400 (EDT) From: Garrett Wollman Message-Id: <201008221704.o7MH40pV088795@hergotha.csail.mit.edu> To: ed@80386.nl X-Newsgroups: mit.lcs.mail.freebsd-current In-Reply-To: <20100822163644.GU2978@hoeg.nl> References: <20100822163644.GU2978@hoeg.nl> <201008210231.o7L2VRvI031700@ducky.net> Organization: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 22 Aug 2010 13:04:01 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 22 Aug 2010 17:34:17 +0000 Cc: current@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 17:04:08 -0000 In article <20100822163644.GU2978@hoeg.nl> you write: >I think that implementing a simple fgrep boils down to mmap()ing a file >and calling memmem() on the mapping to search for the input string. Of >course this relies on having an efficient memmem() implementation, for >example using one of the algorithms mentioned in this thread. It's actually more complicated than that, because you have to ensure that you are not matching the middle of a multibyte character, when the current locale specifies a character set with a multibyte encoding. Likewise when searching for the newlines that delimit the matched line. (I'm not sure whether FreeBSD supports any character encodings that would be ambiguous in that way.) I don't think this was considered an issue when Mike Haertel was developing GNU grep. It seems reasonable to implement BMG or some other fast search in memmem(). Note that if you can't (or don't want to) mmap the whole file at once, you'll need special handling for the boundary conditions -- both at the string search level and at the search for line delimiters. This is much easier in the fgrep case, obviously, since the length of the query puts a finite upper bound on the amount of the old buffer you need to keep -- with regexps you really need your regexp engine to be able to report its matching state, or else limit your input to strictly conforming POSIX text files (i.e., line lengths limited to {LINE_MAX}). -GAWollman From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 17:36:24 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035741065670; Sun, 22 Aug 2010 17:36:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id C56D28FC15; Sun, 22 Aug 2010 17:36:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0L7K00H00E8NYC00@smtpauth1.wiscmail.wisc.edu>; Sun, 22 Aug 2010 12:36:23 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.62.197]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L7K003VKE8KLG40@smtpauth1.wiscmail.wisc.edu>; Sun, 22 Aug 2010 12:36:22 -0500 (CDT) Date: Sun, 22 Aug 2010 12:36:20 -0500 From: Nathan Whitehorn In-reply-to: <86bp8ukfuf.fsf@ds4.des.no> To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Message-id: <4C716014.7050400@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.62.197 X-Spam-PmxInfo: Server=avs-12, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.8.22.172414, SenderIP=76.210.62.197 References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> <4C6E825C.5060509@freebsd.org> <86fwy9f5vj.fsf@ds4.des.no> <4C6F0813.9030007@freebsd.org> <86aaofpr7j.fsf@ds4.des.no> <4C704CD2.9040604@freebsd.org> <86bp8ukfuf.fsf@ds4.des.no> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100729 Thunderbird/3.0.6 Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 17:36:24 -0000 On 08/22/10 07:10, Dag-Erling Smørgrav wrote: > Nathan Whitehorn writes: > >> Dag-Erling Smørgrav writes: >> >>> I'm not sure I understand what you mean (or rather, how it would >>> help the tinderbox). What *would* help would be an easy way to >>> determine, *before* trying to build it, whether a specific kernel >>> config is appropriate for a specific target. Can you think of an >>> easier way to do this than to scan the config for the "machine" >>> line? >>> >> That's exactly what I proposed. You use config, before trying the >> build, to look up the machine specification for the config file. I >> sent you a 5 line patch to tinderbox.pl that does this by private >> email. >> > Here's a solution that works regadless of config(8) version, though I'm > not sure it qualifies as either easy or clean: > > Index: tinderbox.pl > =================================================================== > RCS file: /home/projcvs/projects/tinderbox/tinderbox.pl,v > retrieving revision 1.68 > diff -u -r1.68 tinderbox.pl > --- tinderbox.pl 25 Aug 2009 17:28:14 -0000 1.68 > +++ tinderbox.pl 22 Aug 2010 12:08:46 -0000 > @@ -722,10 +722,29 @@ > } > > # Build additional kernels > + kernel: > foreach my $kernel (sort(keys(%kernels))) { > if (! -f "$srcdir/sys/$machine/conf/$kernel") { > warning("no kernel config for $kernel"); > - next; > + next kernel; > + } > + # Hack: check that the config is appropriate for this target. > + # If no "machine" declaration is present, assume that it is. > + local *KERNCONF; > + if (open(KERNCONF, "<", "$srcdir/sys/$machine/conf/$kernel")) { > + while () { > + next unless m/^machine\s+(\w+(?:\s+\w+)?)\s*(?:\#.*)?$/; > + if ($1 !~ m/^\Q$machine\E(\s+\Q$arch\E)?$/) { > + warning("skipping $kernel"); > + close(KERNCONF); > + next kernel; > + } > + last; > + } > + close(KERNCONF); > + } else { > + warning("$kernel: $!"); > + next kernel; > } > logstage("building $kernel kernel"); > logenv(); > > It will break if the "machine" declaration ever moves into an included > file, since it does not follow include statements, but it will do for > now. > Thanks! I think we are pretty likely to stay in the situation where this hack works for the foreseeable future. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 17:47:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B9CA10656A6; Sun, 22 Aug 2010 17:47:46 +0000 (UTC) (envelope-from tim@kientzle.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 D5A1C8FC08; Sun, 22 Aug 2010 17:47:45 +0000 (UTC) Received: by pvg4 with SMTP id 4so2214482pvg.13 for ; Sun, 22 Aug 2010 10:47:45 -0700 (PDT) Received: by 10.142.187.6 with SMTP id k6mr3495843wff.3.1282497607616; Sun, 22 Aug 2010 10:20:07 -0700 (PDT) Received: from [10.123.2.181] (99-74-170-25.lightspeed.sntcca.sbcglobal.net [99.74.170.25]) by mx.google.com with ESMTPS id z1sm7158828wfd.15.2010.08.22.10.20.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 10:20:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Sun, 22 Aug 2010 10:20:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <628366E1-AF71-4A22-95AF-BC77A21C21A8@kientzle.com> References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> To: Sean C. Farley X-Mailer: Apple Mail (2.1081) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@FreeBSD.org, Mike Haertel , gabor@FreeBSD.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 17:47:46 -0000 On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote: > On Sun, 22 Aug 2010, Dag-Erling Sm=F8rgrav wrote: >> Mike Haertel writes: >>> GNU grep uses the well-known Boyer-Moore algorithm, which looks = first for the final letter of the target string, and uses a lookup table = to tell it how far ahead it can skip in the input whenever it finds a = non-matching character. >>=20 >> Boyer-Moore is for fixed search strings. I don't see how that = optimization can work with a regexp search unless the regexp is so = simple that you break it down into a small number of cases with known = length and final character. >=20 > When I was working on making FreeGrep faster (years ago), I wrote down = a few notes about possible algorithms, especially those that could be = useful for fgrep functionality. I am just passing these onto the list. >=20 > Some algorithms: > 1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm > 2. http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm > 3. GNU fgrep: Commentz-Walter > 4. GLIMPSE: http://webglimpse.net/pubs/TR94-17.pdf (Boyer-Moore = variant) >=20 > Also, this may be a useful book: > http://www.dcc.uchile.cl/~gnavarro/FPMbook/ And of course, Russ Cox' excellent series of articles starting at: http://swtch.com/~rsc/regexp/regexp1.html Later on, he summarizes some of the existing implementations, including comments about the Plan 9 implementation and his own RE2, both of which efficiently handle international text (which seems to be a major concern of Gabor's). The key comment in Mike's GNU grep notes is the one about not breaking into lines. That's simply double-scanning the input; instead, run the matcher over blocks of text and, when it finds a match, work backwards from the match to find the appropriate line beginning. This is efficient because most lines don't match. Boyer-Moore is great for fixed strings (a very common use case for grep) and for more complex patterns that contain long fixed strings (helps to discard most lines early). Sophisticated regex matchers implement a number of strategies and choose different ones depending on the pattern. In the case of bsdgrep, it might make sense to use the regex library for the general case but implement a hand-tuned search for fixed strings that can be heavily optimized for that case. Of course, international text support complicates the picture; you have to consider the input character set (if you want to auto-detect Unicode encodings by looking for leading BOMs, for example, you either need to translate the fixed-string pattern to match the input encoding or vice-versa). Tim From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 18:22:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888BC106567A; Sun, 22 Aug 2010 18:22:17 +0000 (UTC) (envelope-from mike@ducky.net) Received: from ducky.net (ducky.net [71.216.22.205]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4228FC14; Sun, 22 Aug 2010 18:22:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ducky.net (8.14.3/8.14.3) with ESMTP id o7MIMCRN050408; Sun, 22 Aug 2010 11:22:12 -0700 (PDT) (envelope-from mike@ducky.net) Message-Id: <201008221822.o7MIMCRN050408@ducky.net> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-reply-to: <86k4nikglg.fsf@ds4.des.no> References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> Comments: In-reply-to =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= message dated "Sun, 22 Aug 2010 13:54:35 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Aug 2010 11:22:12 -0700 From: Mike Haertel X-Mailman-Approved-At: Sun, 22 Aug 2010 19:18:51 +0000 Cc: freebsd-current@freebsd.org, gabor@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 18:22:18 -0000 Dag-Erling Sm=F8rgrav writes: > Mike Haertel writes: > > GNU grep uses the well-known Boyer-Moore algorithm, which looks > > first for the final letter of the target string, and uses a lookup > > table to tell it how far ahead it can skip in the input whenever > > it finds a non-matching character. >=20 > Boyer-Moore is for fixed search strings. I don't see how that > optimization can work with a regexp search unless the regexp is so > simple that you break it down into a small number of cases with known > length and final character. GNU grep uses heuristics to look for a fixed string that any string matching the regex *must* contain, and uses that fixed string as the bases for its initial Boyer-Moore search. For example if your regex is /foo.*bar/, the initial Boyer-Moore search is (probably) searching for foo. If the initial search succeeds, GNU grep isolates the containing line, and then runs the full regex matcher on that line to make sure. This is the sort of thing that a good regex library could do internally. Unfortunately, you can'd do this with a library that conforms to the =21=40=23%=24=21=40=23% POSIX regex API. The problem is that regexec()'s interface is based on NUL-terminated strings, rather than byte-counted buffers. So POSIX regexec() is necessarily character-at-a-time, because it has to look for that input-terminating NUL byte, and also you can't use it to search binary data that might contain NULs. (GNU grep works fine with arbitrary input files, as long as it can allocate enough memory to hold the longest line.) For these reasons a good grep implementation is pretty muched doomed to bundle its own regex matcher. From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 19:53:40 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 323DF10656AA; Sun, 22 Aug 2010 19:53:40 +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 E6C498FC18; Sun, 22 Aug 2010 19:53:39 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E2CB31FFC37; Sun, 22 Aug 2010 19:53:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 9D4648456E; Sun, 22 Aug 2010 21:53:38 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sean C. Farley" References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> Date: Sun, 22 Aug 2010 21:53:38 +0200 In-Reply-To: (Sean C. Farley's message of "Sun, 22 Aug 2010 11:30:01 -0500 (CDT)") Message-ID: <861v9qmnjx.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-current@FreeBSD.org, Mike Haertel , gabor@FreeBSD.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 19:53:40 -0000 "Sean C. Farley" writes: > Some algorithms: > 1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm Aho-Corasick is not really a search algorithm, but an algorithm for constructing a table-driven finite state machine that will match either of the search strings you fed it. I believe it is less efficient than Boyer-Moore for small numbers of search terms, since it scans the entire input. I don't see the point in using it in grep, because grep already has an algorithm for constructing finite state machines: regcomp(3). > 2. http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm It doesn't seem to compare favorably to the far older Aho-Corasick. It uses slightly less memory, but memory is usually not an issue with grep. > 4. GLIMPSE: http://webglimpse.net/pubs/TR94-17.pdf (Boyer-Moore > variant) Glimpse is a POS... and not really comparable, because grep is designed to search for a single search string in multiple texts, while glimpse is designed to search a large amount of text over and over with different search strings. I believe it uses suffix tables to construct its index, and Boyer-Moore only to locate specific matches, since the index lists only files, not exact positions. For anything other than fixed strings, it reverts to agrep, but I assume (I haven't looked at the code) that if the regexp has one or more fixed components, it uses those to narrow the search space before running agrep. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 20:44:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DE0B10656A7; Sun, 22 Aug 2010 20:44:15 +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 E4C2A8FC14; Sun, 22 Aug 2010 20:44:14 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E59BA1FFC33; Sun, 22 Aug 2010 20:44:13 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A9FAC845D4; Sun, 22 Aug 2010 22:44:13 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Haertel References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <201008221822.o7MIMCRN050408@ducky.net> Date: Sun, 22 Aug 2010 22:44:13 +0200 In-Reply-To: <201008221822.o7MIMCRN050408@ducky.net> (Mike Haertel's message of "Sun, 22 Aug 2010 11:22:12 -0700") Message-ID: <86lj7yl6n6.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-current@freebsd.org, gabor@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 20:44:15 -0000 Mike Haertel writes: > For example if your regex is /foo.*bar/, the initial Boyer-Moore search > is (probably) searching for foo. > > If the initial search succeeds, GNU grep isolates the containing line, > and then runs the full regex matcher on that line to make sure. You don't really need to "isolate the containing line" unless you have an actual match, do you? There are two cases: 1) The regexp does not use any character classes, including /./, so the FSA will stop if it hits EOL before it reaches an accepting state. 2) The regexp uses character classes, and you rewrite them to exclude \n: /[^bar]/ becomes /[^bar\n]/, /./ becomes /[^\n]/, etc., and the FSA will stop if it hits EOL before it reaches an accepting state. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 22:11:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EE821065697; Sun, 22 Aug 2010 22:11:50 +0000 (UTC) (envelope-from mike@ducky.net) Received: from ducky.net (ducky.net [71.216.22.205]) by mx1.freebsd.org (Postfix) with ESMTP id 345BF8FC20; Sun, 22 Aug 2010 22:11:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ducky.net (8.14.3/8.14.3) with ESMTP id o7MMBeC8065026; Sun, 22 Aug 2010 15:11:40 -0700 (PDT) (envelope-from mike@ducky.net) Message-Id: <201008222211.o7MMBeC8065026@ducky.net> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-reply-to: <86lj7yl6n6.fsf@ds4.des.no> References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <201008221822.o7MIMCRN050408@ducky.net> <86lj7yl6n6.fsf@ds4.des.no> Comments: In-reply-to =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= message dated "Sun, 22 Aug 2010 22:44:13 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Aug 2010 15:11:40 -0700 From: Mike Haertel X-Mailman-Approved-At: Sun, 22 Aug 2010 23:25:37 +0000 Cc: mike@ducky.net, gabor@freebsd.org, freebsd-current@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 22:11:50 -0000 Dag-Erling Sm=F8rgrav writes: > Mike Haertel writes: > > For example if your regex is /foo.*bar/, the initial Boyer-Moore sear= ch > > is (probably) searching for foo. > > > > If the initial search succeeds, GNU grep isolates the containing line= , > > and then runs the full regex matcher on that line to make sure. >=20 > You don't really need to =22isolate the containing line=22 unless you h= ave > an actual match, do you? There are two cases: Theoretically no. However, suppose the pattern was /foo.*blah/. The Boyer-Moore search will be for =22blah=22, since that's the longest fixed substring. But verifying a match for the full regexp either requires a regexp matcher with the feature =22start here, at THIS point in the middle of the RE and THAT point in the middle of the buffer, and match backwards and forwards=22, or else running a more standard RE matcher starting from the beginning of the line. So, in practice you pretty much have to at least search backwards for the preceding newline. As you mentioned, you can avoid searching forwards for the next newline if your RE matcher supports using newline as an exit marker. But if the workload characteristics are that matching lines are scarce compared to the input, this is an optimization that just won't matter much either way. From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 01:29:08 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394E610656A3; Mon, 23 Aug 2010 01:29:08 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id E719F8FC16; Mon, 23 Aug 2010 01:29:07 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o7N1T1n5071341; Sun, 22 Aug 2010 20:29:01 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sun, 22 Aug 2010 20:29:01 -0500 (CDT) From: "Sean C. Farley" To: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <861v9qmnjx.fsf@ds4.des.no> Message-ID: References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <861v9qmnjx.fsf@ds4.des.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="56599777-308394701-1282526342=:93799" Content-ID: X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.farley.org Cc: freebsd-current@FreeBSD.org, Mike Haertel , gabor@FreeBSD.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 01:29:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --56599777-308394701-1282526342=:93799 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote: > "Sean C. Farley" writes: >> Some algorithms: >> 1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm > > Aho-Corasick is not really a search algorithm, but an algorithm for > constructing a table-driven finite state machine that will match > either of the search strings you fed it. I believe it is less > efficient than Boyer-Moore for small numbers of search terms, since it > scans the entire input. I don't see the point in using it in grep, > because grep already has an algorithm for constructing finite state > machines: regcomp(3). especially those that could be useful for fgrep functionality I was mainly talking about algorithms useful for the fgrep portion within FreeGrep. fgrep would run (still runs?) over the same text for each pattern. Therefore, Aho–Corasick had to be mentioned for the reason referenced within the link: The Aho–Corasick string matching algorithm formed the basis of the original Unix command fgrep. >> 2. http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm > > It doesn't seem to compare favorably to the far older Aho-Corasick. > It uses slightly less memory, but memory is usually not an issue with > grep. I agree, yet I like to keep alternative algorithms in mind in case a variant would be useful. >> 4. GLIMPSE: http://webglimpse.net/pubs/TR94-17.pdf (Boyer-Moore >> variant) > > Glimpse is a POS... and not really comparable, because grep is > designed to search for a single search string in multiple texts, while > glimpse is designed to search a large amount of text over and over > with different search strings. I believe it uses suffix tables to > construct its index, and Boyer-Moore only to locate specific matches, > since the index lists only files, not exact positions. For anything > other than fixed strings, it reverts to agrep, but I assume (I haven't > looked at the code) that if the regexp has one or more fixed > components, it uses those to narrow the search space before running > agrep. Glimpse may be a POS; I have not used it personally. I only noted its algorithm for possible use within fgrep. Of course, there may be much better algorithms out there to boost fgrep's speed, but these are what I had found at one time. Sean -- scf@FreeBSD.org --56599777-308394701-1282526342=:93799-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 01:37:15 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98031065679; Mon, 23 Aug 2010 01:37:14 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 96D3C8FC12; Mon, 23 Aug 2010 01:37:14 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o7N1b9Lf071486; Sun, 22 Aug 2010 20:37:09 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sun, 22 Aug 2010 20:37:09 -0500 (CDT) From: "Sean C. Farley" To: Tim Kientzle In-Reply-To: <628366E1-AF71-4A22-95AF-BC77A21C21A8@kientzle.com> Message-ID: References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <628366E1-AF71-4A22-95AF-BC77A21C21A8@kientzle.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="56599777-2042966741-1282527429=:93799" X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.farley.org Cc: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@FreeBSD.org, Mike Haertel , gabor@FreeBSD.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 01:37:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --56599777-2042966741-1282527429=:93799 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 22 Aug 2010, Tim Kientzle wrote: > On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote: >> On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote: >>> Mike Haertel writes: >>>> GNU grep uses the well-known Boyer-Moore algorithm, which looks >>>> first for the final letter of the target string, and uses a lookup >>>> table to tell it how far ahead it can skip in the input whenever it >>>> finds a non-matching character. >>> >>> Boyer-Moore is for fixed search strings. I don't see how that >>> optimization can work with a regexp search unless the regexp is so >>> simple that you break it down into a small number of cases with >>> known length and final character. >> >> When I was working on making FreeGrep faster (years ago), I wrote >> down a few notes about possible algorithms, especially those that >> could be useful for fgrep functionality. I am just passing these >> onto the list. >> >> Some algorithms: >> 1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm >> 2. http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm >> 3. GNU fgrep: Commentz-Walter >> 4. GLIMPSE: http://webglimpse.net/pubs/TR94-17.pdf (Boyer-Moore variant) >> >> Also, this may be a useful book: >> http://www.dcc.uchile.cl/~gnavarro/FPMbook/ > > And of course, Russ Cox' excellent series of articles starting at: > > http://swtch.com/~rsc/regexp/regexp1.html I saved that link from an E-mail earlier because it looked very interesting. > Later on, he summarizes some of the existing implementations, > including comments about the Plan 9 implementation and his own RE2, > both of which efficiently handle international text (which seems to be > a major concern of Gabor's). I believe Gabor is considering TRE for a good replacement regex library. > The key comment in Mike's GNU grep notes is the one about not breaking > into lines. That's simply double-scanning the input; instead, run the > matcher over blocks of text and, when it finds a match, work backwards > from the match to find the appropriate line beginning. This is > efficient because most lines don't match. I do like the idea. > Boyer-Moore is great for fixed strings (a very common use case for > grep) and for more complex patterns that contain long fixed strings > (helps to discard most lines early). Sophisticated regex matchers > implement a number of strategies and choose different ones depending > on the pattern. That is what fastgrep (in bsdgrep) attempts to accomplish with very simply regex lines (beginning of line, end of line and dot). > In the case of bsdgrep, it might make sense to use the regex library > for the general case but implement a hand-tuned search for fixed > strings that can be heavily optimized for that case. Of course, > international text support complicates the picture; you have to > consider the input character set (if you want to auto-detect Unicode > encodings by looking for leading BOMs, for example, you either need to > translate the fixed-string pattern to match the input encoding or > vice-versa). BTW, the fastgrep portion of bsdgrep is my fault/contribution to do a faster search bypassing the regex library. :) It certainly was not written with any encodings in mind; it was purely ASCII. As I have not kept up with it, I do not know if anyone improved it or not. Sean -- scf@FreeBSD.org --56599777-2042966741-1282527429=:93799-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 03:17:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DBE010656A4 for ; Mon, 23 Aug 2010 03:17:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 08E2F8FC1D for ; Mon, 23 Aug 2010 03:17:46 +0000 (UTC) Received: (qmail 13433 invoked by uid 399); 23 Aug 2010 03:17:46 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Aug 2010 03:17:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C71E858.90009@FreeBSD.org> Date: Sun, 22 Aug 2010 20:17:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, Andriy Gapon X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 03:17:47 -0000 Thanks to help from Andriy I've been working on narrowing down the cause of my "runaway intr" problems and we've found some interesting things. First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than C1 things seem to work fine. Using one or the other sort of works, but between the 2 powerd seems to cause the most problems. However, the more interesting thing is that generally the problem seems to be caused by contention on IRQ 20 between the following: 20 (ehci0) 20 (uhci0) 20 (hpet0) If I set the following in loader.conf: kern.eventtimer.timer1="i8254" kern.eventtimer.timer2="RTC" Then everything works (where "everything" is 40 minutes or so of watching a video that previously caused the runaway problem consistently in about 10-20 minutes, although in the past it sometimes took hours to manifest). Or, if I build a kernel with no USB (so IRQ 20 is no longer shared) then once again, everything works (as above) using: kern.eventtimer.timer1: LAPIC kern.eventtimer.timer2: HPET (I.e., the default) I also got another interesting set of data today from a "runaway intr" situation that did not involve swi:4. The symptoms were the same as previously, but the devices involved were totally different. This may have to do with the fact that I switched back to ULE for the testing today, and/or I hadn't set cx_lowest=C3. http://people.freebsd.org/~dougb/intr-out-3.txt This was with ULE + USB in the kernel, LAPIC/HPET, cx_lowest=C1, but running powerd with the following: powerd_flags="-a adaptive -b adaptive -n adaptive" ... and so it goes, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 06:20:39 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F9F710656A5; Mon, 23 Aug 2010 06:20:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 68FAF8FC0C; Mon, 23 Aug 2010 06:20:37 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA11445; Mon, 23 Aug 2010 09:20:36 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OnQOa-000DnA-KR; Mon, 23 Aug 2010 09:20:36 +0300 Message-ID: <4C721334.1050000@icyb.net.ua> Date: Mon, 23 Aug 2010 09:20:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4C71E858.90009@FreeBSD.org> In-Reply-To: <4C71E858.90009@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 06:20:39 -0000 on 23/08/2010 06:17 Doug Barton said the following: > I also got another interesting set of data today from a "runaway intr" situation > that did not involve swi:4. The symptoms were the same as previously, but the > devices involved were totally different. This may have to do with the fact that > I switched back to ULE for the testing today, and/or I hadn't set cx_lowest=C3. Yes, ULE rules. 4BSD usually only makes things better when there is some real problem and 4BSD masks it due to its design. > http://people.freebsd.org/~dougb/intr-out-3.txt So, hm, npviewer.bin eats all the CPU time? Just google that name and see that you are not alone. Can't help with that though. > This was with ULE + USB in the kernel, LAPIC/HPET, cx_lowest=C1, but running > powerd with the following: > powerd_flags="-a adaptive -b adaptive -n adaptive" -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 06:48:20 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B802D106567A for ; Mon, 23 Aug 2010 06:48:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1C78FC15 for ; Mon, 23 Aug 2010 06:48:20 +0000 (UTC) Received: (qmail 25055 invoked by uid 399); 23 Aug 2010 06:48:19 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Aug 2010 06:48:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C7219B2.4070303@FreeBSD.org> Date: Sun, 22 Aug 2010 23:48:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> In-Reply-To: <4C721334.1050000@icyb.net.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 06:48:20 -0000 On 08/22/2010 23:20, Andriy Gapon wrote: > on 23/08/2010 06:17 Doug Barton said the following: > >> http://people.freebsd.org/~dougb/intr-out-3.txt > > So, hm, npviewer.bin eats all the CPU time? No, the odd bits of that one are the fact that the intr threads irq17, irq256, and irq20; are showing up at all, and/or showing up with more than a fraction of a percent of cpu time. Usually they don't, and the fact that they did at that point in time was indicative of the fact that the "runaway intr" problem was happening. _Incidentally_ npviewer.bin was taking up more cpu than it usually does, but I think that's another symptom of the underlying problem. Here is a typical, non-problematic top output while running a flash video: last pid: 10841; load averages: 0.22, 0.12, 0.19 up 0+04:15:49 23:46:11 171 processes: 3 running, 148 sleeping, 20 waiting CPU 0: 14.8% user, 0.0% nice, 3.1% system, 0.0% interrupt, 82.0% idle CPU 1: 18.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 81.3% idle Mem: 342M Active, 1397M Inact, 168M Wired, 49M Cache, 112M Buf, 45M Free Swap: 1024M Total, 1444K Used, 1022M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 16K CPU0 0 203:29 82.86% {idle: cpu0} 10 root 171 ki31 0K 16K RUN 1 191:24 81.05% {idle: cpu1} 10813 dougb 54 0 420M 78196K select 0 0:18 17.77% npviewer.bin 10822 dougb 47 0 420M 78196K futex 1 0:05 6.30% npviewer.bin 10839 dougb 45 0 420M 78196K futex 1 0:03 3.66% npviewer.bin 10840 dougb 45 0 420M 78196K futex 1 0:03 3.66% npviewer.bin 10832 dougb 45 0 420M 78196K pcmwrv 1 0:03 2.88% npviewer.bin 1598 dougb 44 0 163M 142M select 1 12:06 1.56% Xorg 11 root -68 - 0K 160K WAIT 1 1:10 0.49% {irq17: wpi0} 10770 dougb 44 0 178M 136M ucond 0 0:00 0.39% {firefox-bin} 10770 dougb 45 0 178M 136M select 1 0:15 0.29% {initial thread 11 root -80 - 0K 160K WAIT 0 0:45 0.10% {irq256: hdac0} I really wish people would stop focusing on flash here. :) It's simply the easiest and most consistent way that I have triggered this problem, it's not the only one. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 07:23:57 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B491065694; Mon, 23 Aug 2010 07:23:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C34E98FC13; Mon, 23 Aug 2010 07:23:56 +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 KAA12193; Mon, 23 Aug 2010 10:23:55 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OnRNq-000DsE-RL; Mon, 23 Aug 2010 10:23:55 +0300 Message-ID: <4C722209.1020405@icyb.net.ua> Date: Mon, 23 Aug 2010 10:23:53 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> In-Reply-To: <4C7219B2.4070303@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 07:23:57 -0000 on 23/08/2010 09:48 Doug Barton said the following: > On 08/22/2010 23:20, Andriy Gapon wrote: >> on 23/08/2010 06:17 Doug Barton said the following: >> >>> http://people.freebsd.org/~dougb/intr-out-3.txt >> >> So, hm, npviewer.bin eats all the CPU time? > > No, the odd bits of that one are the fact that the intr threads irq17, irq256, > and irq20; are showing up at all, and/or showing up with more than a fraction of > a percent of cpu time. DTrace output doesn't show anything abnormal for those, but it does show that those interrupts do happen and those drivers do work. E.g. there is hdac (sound) activity [irq256: hdac0] and wireless activity [irq17: wpi0]. irq20 is hpet + usb. So did you do anything wireless? Did you play sound? The %WCPU may be _reported_ higher than what it actually is due to other issues with your system (high load by npviewer.bin, HPET+USB interrupt sharing, C3 with LAPIC timer). > Usually they don't, and the fact that they did at that > point in time was indicative of the fact that the "runaway intr" problem was > happening. _Incidentally_ npviewer.bin was taking up more cpu than it usually > does, but I think that's another symptom of the underlying problem. In complex systems it's not always trivially obvious what's incidental and what's not. > Here is a typical, non-problematic top output while running a flash video: > > last pid: 10841; load averages: 0.22, 0.12, 0.19 up 0+04:15:49 23:46:11 > 171 processes: 3 running, 148 sleeping, 20 waiting > CPU 0: 14.8% user, 0.0% nice, 3.1% system, 0.0% interrupt, 82.0% idle > CPU 1: 18.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 81.3% idle > Mem: 342M Active, 1397M Inact, 168M Wired, 49M Cache, 112M Buf, 45M Free > Swap: 1024M Total, 1444K Used, 1022M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 10 root 171 ki31 0K 16K CPU0 0 203:29 82.86% {idle: cpu0} > 10 root 171 ki31 0K 16K RUN 1 191:24 81.05% {idle: cpu1} > 10813 dougb 54 0 420M 78196K select 0 0:18 17.77% npviewer.bin > 10822 dougb 47 0 420M 78196K futex 1 0:05 6.30% npviewer.bin > 10839 dougb 45 0 420M 78196K futex 1 0:03 3.66% npviewer.bin > 10840 dougb 45 0 420M 78196K futex 1 0:03 3.66% npviewer.bin > 10832 dougb 45 0 420M 78196K pcmwrv 1 0:03 2.88% npviewer.bin > 1598 dougb 44 0 163M 142M select 1 12:06 1.56% Xorg > 11 root -68 - 0K 160K WAIT 1 1:10 0.49% {irq17: wpi0} > 10770 dougb 44 0 178M 136M ucond 0 0:00 0.39% {firefox-bin} > 10770 dougb 45 0 178M 136M select 1 0:15 0.29% {initial thread > 11 root -80 - 0K 160K WAIT 0 0:45 0.10% {irq256: hdac0} Well, notice that in this case your npviewer.bin processes are not "run away" either. They spend most of the time waiting for something and use only a fraction of CPU time. In the report that I commented on they were mostly running on CPU (and who knows what else they were doing, like driving sound card crazy etc). > I really wish people would stop focusing on flash here. :) It's simply the > easiest and most consistent way that I have triggered this problem, it's not the > only one. Well, I just interpreted the DTrace output you gave. No prejudice against flash, although all those reports/complaints by Linux folks are suspicious. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 07:55:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DE3D1065694 for ; Mon, 23 Aug 2010 07:55:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id BB7558FC19 for ; Mon, 23 Aug 2010 07:55:43 +0000 (UTC) Received: (qmail 31340 invoked by uid 399); 23 Aug 2010 07:55:42 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Aug 2010 07:55:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C72297D.90104@FreeBSD.org> Date: Mon, 23 Aug 2010 00:55:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua> In-Reply-To: <4C722209.1020405@icyb.net.ua> X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 07:55:44 -0000 On 8/23/2010 12:23 AM, Andriy Gapon wrote: > on 23/08/2010 09:48 Doug Barton said the following: >> On 08/22/2010 23:20, Andriy Gapon wrote: >>> on 23/08/2010 06:17 Doug Barton said the following: >>> >>>> http://people.freebsd.org/~dougb/intr-out-3.txt >>> >>> So, hm, npviewer.bin eats all the CPU time? >> >> No, the odd bits of that one are the fact that the intr threads irq17, irq256, >> and irq20; are showing up at all, and/or showing up with more than a fraction of >> a percent of cpu time. > > DTrace output doesn't show anything abnormal for those, but it does show that > those interrupts do happen and those drivers do work. > E.g. there is hdac (sound) activity [irq256: hdac0] and wireless activity > [irq17: wpi0]. irq20 is hpet + usb. > > So did you do anything wireless? Did you play sound? Yes. My laptop is using wireless exclusively, and the streaming/flash video was attempting to play sound, but given that it was starved for resources the video and the audio were both very choppy. > The %WCPU may be _reported_ higher than what it actually is due to other issues > with your system (high load by npviewer.bin, HPET+USB interrupt sharing, C3 with > LAPIC timer). > >> Usually they don't, and the fact that they did at that >> point in time was indicative of the fact that the "runaway intr" problem was >> happening. _Incidentally_ npviewer.bin was taking up more cpu than it usually >> does, but I think that's another symptom of the underlying problem. > > In complex systems it's not always trivially obvious what's incidental and > what's not. Yep, sorry, no reason for you to have read my mind there. :) > Well, I just interpreted the DTrace output you gave. Right-o. I am about 80% ready to take the old HD out and put the new one in and start installing, at which point I'm going to set up the schedgraph stuff which will hopefully give more useful information. Meanwhile, with the combination of ULE, no powerd, and cx_lowest=C1 I was able to watch 2 movies streaming over flash, plus do backups to various USB drives, read mail, etc. etc. for several hours; all without a hiccup. So clearly (in my mind at least) there is a problem with powerd, at least in the situation like mine where there is IRQ contention for HPET. I forgot to mention that in my previous testing today I tried running just powerd (not changing cx_lowest) and I when intr started running away I could "solve" the problem by killing powerd. The intr process went back to normal, and I could go back to doing what I was doing without having to reboot again. anyways thanks again, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 07:56:33 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EAA510656A9; Mon, 23 Aug 2010 07:56:33 +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 2DBA48FC27; Mon, 23 Aug 2010 07:56:32 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 8E07E1FFC37; Mon, 23 Aug 2010 07:56:31 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 5FD848452E; Mon, 23 Aug 2010 09:56:31 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sean C. Farley" References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <861v9qmnjx.fsf@ds4.des.no> Date: Mon, 23 Aug 2010 09:56:30 +0200 In-Reply-To: (Sean C. Farley's message of "Sun, 22 Aug 2010 20:29:01 -0500 (CDT)") Message-ID: <86bp8tzrrl.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-current@FreeBSD.org, Mike Haertel , gabor@FreeBSD.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 07:56:33 -0000 "Sean C. Farley" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Aho-Corasick is not really a search algorithm, but an algorithm for > > constructing a table-driven finite state machine that will match > > either of the search strings you fed it. I believe it is less > > efficient than Boyer-Moore for small numbers of search terms, since > > it scans the entire input. I don't see the point in using it in > > grep, because grep already has an algorithm for constructing finite > > state machines: regcomp(3). > especially those that could be useful for fgrep functionality Not entirely sure what you mean by that, but in most cases, I think Boyer-Moore is a better fit for fgrep. For large numbers of search terms, I might use Aho-Corasick... if it weren't for the fact that, as mentioned, grep already has a regexp engine, which is a superset of Aho-Corasick. It might be a tad slower at building the FSA, because it's more general, and the FSA might occupy a tad more memory, but the complexity is *exactly* the same, and adding Aho-Corasick just for fgrep is, for lack of a better word, pedantry. For all you know, the increased code size could very well offset whatever performance advantage Aho-Corasick might offer. > Glimpse may be a POS; I have not used it personally. I only noted its > algorithm for possible use within fgrep. Apples and oranges. The problem glimpse tries to solve (fixed corpus, variable search terms) is precisely the opposite of the one fgrep tries to solve (fixed search terms, variable corpus). Glimpse does include grep-like functionality, but in the form of agrep, which is designed for approximate matching. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 08:01:37 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21BD71065698; Mon, 23 Aug 2010 08:01:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 369318FC19; Mon, 23 Aug 2010 08:01:35 +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 LAA12812; Mon, 23 Aug 2010 11:01:34 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OnRyI-000Dw7-8G; Mon, 23 Aug 2010 11:01:34 +0300 Message-ID: <4C722ADD.1030103@icyb.net.ua> Date: Mon, 23 Aug 2010 11:01:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua> <4C72297D.90104@FreeBSD.org> In-Reply-To: <4C72297D.90104@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 08:01:37 -0000 on 23/08/2010 10:55 Doug Barton said the following: > Meanwhile, with the combination of ULE, no powerd, and cx_lowest=C1 I was able > to watch 2 movies streaming over flash, plus do backups to various USB drives, > read mail, etc. etc. for several hours; all without a hiccup. So clearly (in my > mind at least) there is a problem with powerd, at least in the situation like > mine where there is IRQ contention for HPET. I forgot to mention that in my > previous testing today I tried running just powerd (not changing cx_lowest) and > I when intr started running away I could "solve" the problem by killing powerd. > The intr process went back to normal, and I could go back to doing what I was > doing without having to reboot again. Speaking of which you seem to have too many powerd levels. What cpufreq drivers are in use on your system? Maybe you'd want to stick to just one of them? E.g.: http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 08:12:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5006D10656A8; Mon, 23 Aug 2010 08:12:14 +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 11EF18FC17; Mon, 23 Aug 2010 08:12:13 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 08B281FFC37; Mon, 23 Aug 2010 08:12:13 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CF2C28452E; Mon, 23 Aug 2010 10:12:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Haertel References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <201008221822.o7MIMCRN050408@ducky.net> <86lj7yl6n6.fsf@ds4.des.no> <201008222211.o7MMBeC8065026@ducky.net> Date: Mon, 23 Aug 2010 10:12:12 +0200 In-Reply-To: <201008222211.o7MMBeC8065026@ducky.net> (Mike Haertel's message of "Sun, 22 Aug 2010 15:11:40 -0700") Message-ID: <867hjhzr1f.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-current@freebsd.org, gabor@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 08:12:14 -0000 Mike Haertel writes: > Dag-Erling Sm=C3=B8rgrav writes: > > You don't really need to "isolate the containing line" unless you have > > an actual match, do you? > Theoretically no. However, suppose the pattern was /foo.*blah/. > The Boyer-Moore search will be for "blah", since that's the longest > fixed substring. But verifying a match for the full regexp either > requires a regexp matcher with the feature "start here, at THIS point > in the middle of the RE and THAT point in the middle of the buffer, > and match backwards and forwards", or else running a more standard > RE matcher starting from the beginning of the line. Stupidly enough, I only considered the case where the fixed search string is at the end of the regexp :) For the general case, you'd have to either build a second FSA that mirrors the first, or design your engine and data structures in such a way that the FSA can be traversed in either direction. Then you note which states correspond to the beginning and end of the fixed substring, and run the FSA forward from the end and backward from the beginning. That could prove advantageous when the input consists of very long lines and the frequency of partial matches is relatively high; large files with very long lines are very common in bioinformatics. > As you mentioned, you can avoid searching forwards for the next > newline if your RE matcher supports using newline as an exit marker. Umm, I don't understand why it needs to support using *anything* as an exit marker. The newline character will simply not match any of the transitions from whichever state the FSA is currently in, and neither will the null character. The only bit that needs to know about them is the bit that handles end-of-line and end-of-word anchors. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 08:43:15 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0C931065679 for ; Mon, 23 Aug 2010 08:43:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 679388FC0A for ; Mon, 23 Aug 2010 08:43:15 +0000 (UTC) Received: (qmail 5889 invoked by uid 399); 23 Aug 2010 08:43:14 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Aug 2010 08:43:14 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C7234A1.3050108@FreeBSD.org> Date: Mon, 23 Aug 2010 01:43:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua> <4C72297D.90104@FreeBSD.org> <4C722ADD.1030103@icyb.net.ua> In-Reply-To: <4C722ADD.1030103@icyb.net.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 08:43:15 -0000 On 08/23/2010 01:01, Andriy Gapon wrote: > Speaking of which you seem to have too many powerd levels. D'oh! > What cpufreq drivers are in use on your system? The only one I have is the cpufreq that's in GENERIC. > Maybe you'd want to stick to just one of them? > E.g.: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html Ok, so it seems that you're suggesting to disable throttling, so I added the following to /boot/loader.conf: hint.p4tcc.0.disabled="1" hint.p4tcc.1.disabled="1" hint.acpi_throttle.0.disabled="1" hint.acpi_throttle.1.disabled="1" Not sure the .1.'s are necessary, but I wanted to be thorough. With that I get: dev.cpu.0.freq_levels: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 dev.est.0.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 dev.est.1.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 hopefully that's more in line with what it should be? I'd really like to be able to at least use powerd since it does seem to help with heat when the system is idle (and by extension, power consumption as well). Unless you say differently when I get up tomorrow I'll try this configuration for a little while and see how it goes. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 10:12:53 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 194C710656A7; Mon, 23 Aug 2010 10:12:53 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id C886A8FC14; Mon, 23 Aug 2010 10:12:52 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id E012214DC79D; Mon, 23 Aug 2010 12:12:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sh+De72yGKgs; Mon, 23 Aug 2010 12:12:49 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 4215D14DC75D; Mon, 23 Aug 2010 12:12:49 +0200 (CEST) Message-ID: <4C7249A0.7010507@FreeBSD.org> Date: Mon, 23 Aug 2010 12:12:48 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4C6CD229.1010401@FreeBSD.org> In-Reply-To: <4C6CD229.1010401@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: delphij@FreeBSD.org, current@FreeBSD.org Subject: Re: BSD grep performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 10:12:53 -0000 Em 2010.08.19. 8:41, Doug Barton escreveu: > >> The performance is now almost comparable to GNU grep. > > I think you're using a very liberal definition of "comparable." Ok, comparable for the casual cases but not generally comparable. > >> I think with this, BSD grep may remain default if no other serious >> issues come up. > > I'm not going to re-state my opinion here except to say it hasn't > changed. Even if the performance were not an issue I think the bugs > mentioned below combined with your 4-day absence should also have been > considerations. However, in regards to this particular case I think > it's pretty obvious that I'm either alone, or in a very non-vocal > group; so c'est la vie. I think the 4-day absence was not such a big deal given that we are talking about -current, I just wanted to let you know that I would not be responsive because of absence not ignorance. Other people also felt in the same way; it's fine to allow a short unstable period in -current to get things arranged. > > However, from the standpoint of committer relations I think that first > stating that you would change the default, then not doing so before > all of the outstanding issues were resolved is not what I would > consider a good model for others to follow. > I've just changed it back. No, I didn't lie to you, I just wanted to reevaluate if the remaining difference in ther performance was acceptable. We improved it a lot since you let us know about this problem and there is possibility that further improvements are to happen soon. I thank you that you helped the process with valuable feedback but I think it could have been done in a less noisy way and arrogant way. You called the attention to the performance problem, which is fine and necessary but I'd have reacted in the same way if you hadn't CC'd core@ in the very first mail and hadn't included the "Official request" words in the subject. But I know that there are people, who feel them so important that they have to always call the attention in the noisy way (ego in the Buddhist meaning) and I also have some personal problems that I feel bothered by such type of behaviour. This is a sign for me that I have to practice more acceptance and patience in the life. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 10:16:56 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6873E10656B3 for ; Mon, 23 Aug 2010 10:16:56 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 22DC38FC08 for ; Mon, 23 Aug 2010 10:16:55 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 4751114DC799; Mon, 23 Aug 2010 12:16:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5vpmo-RufkNH; Mon, 23 Aug 2010 12:16:52 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id BEAE014DC79D; Mon, 23 Aug 2010 12:16:52 +0200 (CEST) Message-ID: <4C724A93.6090702@FreeBSD.org> Date: Mon, 23 Aug 2010 12:16:51 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "b. f." Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 10:16:56 -0000 Em 2010.08.19. 23:42, b. f. escreveu: > Gabor: > > One more thing to look into, in addition to the context problems, > ndisgen breakage, and problems on certain file systems: > > At r211506, 'grep -wq' does not seem to work properly (in the very > least, it is not the same as with GNU grep), and has broken the > 'check-categories' target (and hence builds) of all ports with 'lisp' > in CATEGORIES. > Thanks, I added to my TODO list. > > P.S. I hope that you have recovered from your influenza, and are > feeling better now. Oh, thanks, I'm fine now but I'm moving soon to another country, so will be busy for some time. But I've changed back the default to GNU grep, so now the fixes aren't so urgent. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 10:21:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9E6F1065694 for ; Mon, 23 Aug 2010 10:21:01 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 63D398FC12 for ; Mon, 23 Aug 2010 10:20:58 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 14B0414DC799; Mon, 23 Aug 2010 12:20:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XWw3HG+MzINt; Mon, 23 Aug 2010 12:20:56 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id ECB3D14DC75D; Mon, 23 Aug 2010 12:20:55 +0200 (CEST) Message-ID: <4C724B86.7070205@FreeBSD.org> Date: Mon, 23 Aug 2010 12:20:54 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mike Haertel References: <201008210231.o7L2VRvI031700@ducky.net> In-Reply-To: <201008210231.o7L2VRvI031700@ducky.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 10:21:01 -0000 Em 2010.08.21. 4:31, Mike Haertel escreveu: > Hi Gabor, > > I am the original author of GNU grep. I am also a FreeBSD user, > although I live on -stable (and older) and rarely pay attention > to -current. > > However, while searching the -current mailing list for an unrelated > reason, I stumbled across some flamage regarding BSD grep vs GNU grep > performance. You may have noticed that discussion too... > > Anyway, just FYI, here's a quick summary of where GNU grep gets > its speed. Hopefully you can carry these ideas over to BSD grep. Thanks, Mike, I'll check how I could adopt these ideas into BSD grep. I think your kind help was such a nice gesture and the open souce world should be based on such cooperation instead of meaningless competition. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 10:23:09 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EE8010656A4; Mon, 23 Aug 2010 10:23:09 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 44AF28FC0A; Mon, 23 Aug 2010 10:23:09 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 8D2B314DC799; Mon, 23 Aug 2010 12:23:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xzcdovdv9erp; Mon, 23 Aug 2010 12:23:06 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 4836914DC75D; Mon, 23 Aug 2010 12:23:06 +0200 (CEST) Message-ID: <4C724C09.6090104@FreeBSD.org> Date: Mon, 23 Aug 2010 12:23:05 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Sean C. Farley" References: <201008210231.o7L2VRvI031700@ducky.net> <86k4nikglg.fsf@ds4.des.no> <628366E1-AF71-4A22-95AF-BC77A21C21A8@kientzle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgr?=, freebsd-current@FreeBSD.org, Mike Haertel , =?ISO-8859-1?Q?av?= Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 10:23:09 -0000 > >> Later on, he summarizes some of the existing implementations, >> including comments about the Plan 9 implementation and his own RE2, >> both of which efficiently handle international text (which seems to >> be a major concern of Gabor's). > > I believe Gabor is considering TRE for a good replacement regex library. Yes. Oniguruma is slow, Google RE2 only supports Perl and fgrep syntax but not standard regex and Plan 9 implementation iirc only supports fgrep syntax and Unicode but not wchar_t in general. > >> The key comment in Mike's GNU grep notes is the one about not >> breaking into lines. That's simply double-scanning the input; >> instead, run the matcher over blocks of text and, when it finds a >> match, work backwards from the match to find the appropriate line >> beginning. This is efficient because most lines don't match. > > I do like the idea. So do I. > > BTW, the fastgrep portion of bsdgrep is my fault/contribution to do a > faster search bypassing the regex library. :) It certainly was not > written with any encodings in mind; it was purely ASCII. As I have > not kept up with it, I do not know if anyone improved it or not. > It has been made wchar-compliant. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 11:02:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60DC610656AD; Mon, 23 Aug 2010 11:02:00 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 012FA8FC19; Mon, 23 Aug 2010 11:01:59 +0000 (UTC) Received: by yxe42 with SMTP id 42so2346013yxe.13 for ; Mon, 23 Aug 2010 04:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=lzEUCW1ffFLeUrFzEpy/L54tN5YsOhSy/KxvidGhJn0=; b=Rx7tcF04av/Pk4ZAZX01jUytZxsnr8e1zdp8ViTGufL5wndHqh7wlQc6er34rfz3Ai dDV7WKvQJvlLIB5YYsOUDOInVV7a2Q10V2n2uJIWR4/Czca7J5TTP30RGmXa8TZLnPen 8wA7wwzH7t6dE3jfTzBw5IHO9zE6WagnjoITk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type:content-transfer-encoding; b=W3BfAG3e8QPnBg6zspTw6VKrvKnsnOt7nX7u3C7GGK61TGxa1jRJ07jvnaJNcM2ESD 0097jm5TLZxlnG4wIMKzIi7ETimcbDoOregQeX1QEldGDWAhF46i9XtvjKHRdMYJhU/7 Pb/9ZyJiyxE7f7CDDOqXA4QoQyGa+JX4yY2QY= Received: by 10.151.132.16 with SMTP id j16mr5181322ybn.21.1282561319231; Mon, 23 Aug 2010 04:01:59 -0700 (PDT) Received: from localhost (tor-exit-proxy1-readme.formlessnetworking.net [208.53.142.37]) by mx.google.com with ESMTPS id q3sm7129731ybe.14.2010.08.23.04.01.56 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 04:01:58 -0700 (PDT) From: Anonymous To: Gabor Kovesdan References: <4C16C5B5.1070308@FreeBSD.org> <867hlzq4lb.fsf@gmail.com> <867hlzufl6.fsf@gmail.com> <4C1A7A57.3000006@FreeBSD.org> <86bpb9z77g.fsf@gmail.com> <4C2F7917.7040900@FreeBSD.org> <86pqz29sy2.fsf@gmail.com> <86mxu4sj0n.fsf@gmail.com> <4C35EF85.6010905@FreeBSD.org> <86lj8ot09d.fsf@gmail.com> Date: Mon, 23 Aug 2010 14:57:07 +0400 Message-ID: <86hbilha0s.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: [CFT] BSDL iconv in base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 11:02:00 -0000 Anonymous writes: [...] > BTW, running GNU iconv(1) with following in libmap.conf > > libiconv.so.3 libc.so.7 > > produces > > $ gnu-iconv > /libexec/ld-elf.so.1: Undefined symbol "_libiconv_version" referenced f= rom COPY relocation in LOCALBASE/bin/iconv I guess gettext hanging is due to ABI incompatibility, too. $ cat foo.po msgid "" msgstr "" "Content-Type: text/plain; charset=3DUTF-8\n" "Content-Transfer-Encoding: 8bit\n" msgid "don=E2=80=99t" msgstr "do not" $ msgmerge foo.po /dev/null # GNU iconv . done. msgid "" msgstr "" "Content-Type: text/plain; charset=3DUTF-8\n" "Content-Transfer-Encoding: 8bit\n" #~ msgid "don=E2=80=99t" #~ msgstr "do not" $ msgmerge foo.po /dev/null # BSD iconv . done. msgid "" load: 0.10 cmd: msgmerge 65132 [runnable] 2.74r 2.72u 0.00s 23% 2844k ^C (gdb) bt #0 _citrus_iconv_none_iconv_convert (ci=3D0x80f00f190, in=3D0x7fffffff0b= 40, inbytes=3D0x7fffffff0b40, out=3D0x7fffffff0b48, outbytes=3D0x7fffffff0b= 50, flags=3D0, invalids=3D0x7fffffff0aa0) at /usr/src/lib/libiconv_modules/iconv_non= e/citrus_iconv_none.c:119 len =3D 1 e2big =3D 0 #1 0x00000008064b9142 in _citrus_iconv_convert (cv=3D0x80f00f190, in=3D0= x7fffffff0b38, inbytes=3D0x7fffffff0b40, out=3D0x7fffffff0b48, outbytes=3D0= x7fffffff0b50, flags=3D0, nresults=3D0x7fffffff0aa0) at citrus_iconv.h:60 No locals. #2 0x00000008064b90b2 in libiconv (handle=3D0x80f00f190, in=3D0x7fffffff= 0b38, szin=3D0x7fffffff0b40, out=3D0x7fffffff0b48, szout=3D0x7fffffff0b50) at /usr/src/lib/libc/iconv/iconv.c:147 ret =3D 0 err =3D 0 #3 0x00000008036db20a in wrap (mp=3D0x80f020400, stream=3D0x80f0123c0, l= ine_prefix=3D0x0, extra_indent=3D0, css_class=3D0x80370a2f0 "msgstr", name=3D0x80370a3a9 "msgstr", value=3D0x80f01f0b0 "Content-Type: text/= plain; charset=3DUTF-8\nContent-Transfer-Encoding: 8bit\n", do_wrap=3Dundec= ided, page_width=3D79, charset=3D0x7fffffff0d80 "UTF-8") at write-po.c:724 #4 0x00000008036dcbdd in message_print (mp=3D0x80f020400, stream=3D0x80f= 0123c0, charset=3D0x7fffffff0d80 "UTF-8", page_width=3D79, blank_line=3Dfal= se, debug=3Dfalse) at write-po.c:1283 #5 0x00000008036dd736 in msgdomain_list_print_po (mdlp=3D0x80f0071c0, st= ream=3D0x80f0123c0, page_width=3D79, debug=3Dfalse) at write-po.c:1511 #6 0x00000008036d8859 in msgdomain_list_print (mdlp=3D0x80f0071c0, filen= ame=3D0x80370a0a6 "standard output", output_syntax=3D0x40d7b0, force=3Dfals= e, debug=3Dfalse) at write-catalog.c:246 #7 0x0000000000403604 in main (argc=3D3, argv=3D0x7fffffff0ff0) at msgme= rge.c:463 It's a bit tweaked version, though. %% Index: devel/gettext/Makefile =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 RCS file: /a/.cvsup/ports/devel/gettext/Makefile,v retrieving revision 1.87 diff -u -p -r1.87 Makefile --- devel/gettext/Makefile 3 Jun 2010 09:46:38 -0000 1.87 +++ devel/gettext/Makefile 23 Aug 2010 10:04:26 -0000 @@ -28,7 +28,7 @@ CONFIGURE_ENV=3D ACLOCAL=3D"${TRUE}" \ AUTOHEADER=3D"${TRUE}" \ MAKEINFO=3D"makeinfo --no-split" \ CPPFLAGS=3D"-I${LOCALBASE}/include" \ - LDFLAGS=3D"-L${LOCALBASE}/lib" \ + LDFLAGS=3D"-L${LOCALBASE}/lib -liconv" \ EMACS=3D"no" CONFIGURE_ARGS=3D --disable-csharp --disable-threads --disable-openmp \ --with-included-gettext --with-included-glib \ @@ -65,6 +65,8 @@ pre-extract: .endif =20 post-patch: + @${REINPLACE_CMD} 's/-DENABLE_RELOCATABLE=3D1//' \ + ${WRKSRC}/gettext-runtime/intl/Makefile.in @${FIND} ${WRKSRC} -name configure -print | ${XARGS} \ ${REINPLACE_CMD} -e 's|mkdir gmkdir|mkdir|' .if defined (NOPORTDOCS) %% From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 11:06:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B047A10656A4; Mon, 23 Aug 2010 11:06:41 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 251AB8FC1E; Mon, 23 Aug 2010 11:06:40 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnUrH-0000f5-FR; Mon, 23 Aug 2010 13:06:39 +0200 Message-ID: <4C725635.8080604@kkip.pl> Date: Mon, 23 Aug 2010 13:06:29 +0200 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100702 Lanikai/3.1 MIME-Version: 1.0 References: <4C613C56.109@kkip.pl> <86r5i61hwd.fsf@gmail.com> <4C61C0B4.5030009@FreeBSD.org> <4C61C70E.2060207@kkip.pl> In-Reply-To: <4C61C70E.2060207@kkip.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.72 (build at 10-Jun-2010 13:05:33) X-Date: 2010-08-23 13:06:39 X-Connected-IP: 78.8.144.74:55475 X-Message-Linecount: 50 X-Body-Linecount: 36 X-Message-Size: 1855 X-Body-Size: 1161 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Anonymous , freebsd-current@freebsd.org, Gabor Kovesdan Subject: Re: [bsdgrep] -w option matches part of words (Was: Apache 2.2 port and missing modules on current.) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 11:06:41 -0000 On 2010-08-10 23:39, Bartosz Stec wrote: > On 2010-08-10 23:12, Gabor Kovesdan wrote: >> Em 2010.08.10. 19:45, Anonymous escreveu: >>> Seems like APACHE_MODULES is incorrectly populated. >>> >>> $ make -V APACHE_MODULES BATCH= >>> GREP=${LOCALBASE-/usr/local}/bin/grep | fgrep cache >>> ...cache disk_cache file_cache... >>> $ make -V APACHE_MODULES BATCH= | fgrep cache >>> ...disk_cache file_cache... >>> >>> I guess the failing line is below in bsd.apache.mk >>> >>> ${ECHO_CMD} ${WITHOUT_MODULES} | ${GREP} -wq $${module} 2> >>> /dev/null || \ >>> >>> It can be reduced to >>> >>> $ echo mem_cache | grep --color -w cache >> I'm sorry for this issue, it didn't come up in the exp-run because it >> didn't make the port actually fail. I have a fix in my queue, which I >> sent to my mentor and I'll commit it soon. >> >> Gabor > > Thanks for your help with investigating this. I guess that in that > case submitting PR is unnecesary. > regards! > Here's quick confirmation that with sources builded yesterday, apache22 port compilation was succesful and all modules were populated as expected. Thanks Gabor! :) -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:20:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DED7D1065693; Mon, 23 Aug 2010 12:20:16 +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 A039F8FC1F; Mon, 23 Aug 2010 12:20:16 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B25391FFC39; Mon, 23 Aug 2010 12:20:15 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8875F8452E; Mon, 23 Aug 2010 14:20:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: bf1783@gmail.com References: <86mxshdqgh.fsf@ds4.des.no> Date: Mon, 23 Aug 2010 14:20:15 +0200 In-Reply-To: (b. f.'s message of "Fri, 20 Aug 2010 21:07:56 +0000") Message-ID: <86r5hpwmf4.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-current@freebsd.org, gabor@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:20:17 -0000 "b. f." writes: > Dag-Erling Sm=C3=B8rgrav writes: > > "Does not seem to work properly" is not a very useful statement. The > > least you could do is provide an example. > I did provide an example, later in the same sentence that you quoted. I forgot to answer this part. By example, I mean an actual grep command line and sample input that demonstrates the problem, the smaller the better: % echo elisp lisp | grep -w lisp && echo good || echo bad elisp lisp good % echo elisp lisp | grep -wq lisp && echo good || echo bad bad No idea what causes it, but a quick grep (hah!) for qflag turns up the following horror: /* Find out the correct return value according to the results and the command line option. */ exit(c ? (notfound ? (qflag ? 0 : 2) : 0) : (notfound ? 2 : 1)); which shows that -q *does* affect the exit code, but my brain refuses to try to understand that code. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:03:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6081710656A7; Mon, 23 Aug 2010 12:03:01 +0000 (UTC) (envelope-from chrisk-freebsd@list.mightyreason.com) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 3868C8FC1B; Mon, 23 Aug 2010 12:03:01 +0000 (UTC) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 8D6542FDBF2; Mon, 23 Aug 2010 07:51:43 -0400 (EDT) Received: from chris-kuklewiczs-macbook-pro.local (unknown [137.195.54.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2E03B22E247; Mon, 23 Aug 2010 07:51:41 -0400 (EDT) Message-ID: <4C7260CC.9070407@list.mightyreason.com> Date: Mon, 23 Aug 2010 12:51:40 +0100 From: chrisk-freebsd@list.mightyreason.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, gabor@FreeBSD.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 23 Aug 2010 12:26:45 +0000 Cc: Subject: grep and Regular expression correctness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:03:01 -0000 I saw the discussion on this list with the subject "why GNU grep is fast" and I thought I would contribute to a discussion of the correctness of the POSIX regular expressions. Gabor wrote: >> I believe Gabor is considering TRE for a good replacement regex library. > Yes. Oniguruma is slow, Google RE2 only supports Perl and fgrep syntax > but not standard regex and Plan 9 implementation iirc only supports > fgrep syntax and Unicode but not wchar_t in general. I specifically need to mention that the ideas used in the TRE algorithm can work, but that libtre is very buggy (see footnote [1]). The hardest part of POSIX regular expressions is in picking out the correct captured subexpressions. This makes programs like "sed" vulnerable to the bad regex.h engine that comes with the operating system. Luckily grep does not need the captured subexpressions, and thus does not need the complexity that comes from the ideas behind TRE. I use OS X which inherits an older freebsd suite of tools with bugs like this: > echo XababaYababaZ | sed -E 's/((X)(aba|b|ab)(aba|b|ab)(Y)(aba|b|ab)*(Z))/[\1] => [\2][\3][\4][\5][\6][\7]/' [XababaYababaZ] => [X][ab][aba][Y][b][Z] Where the [b] between [Y] and [Z] is completely (insanely) wrong. It cannot even get the leftmost-longest correct: > echo "ab" | sed -E 's/(()|.)(b)/[\1][\3]/' a[][b] Where the answer should have been the same as > echo "ab" | sed -E 's/(.|())(b)/[\1][\3]/' [a][b] I have no idea if these bugs are still present in freebsd-current. Cheers, Chris Kuklewicz [1] libtre has problems such as this (from Haskell's regex-tre wrapper) >> "searchme" =~ "s(()|^)e" :: Array Int (MatchOffset,MatchLength) > array (0,2) [(0,(0,2)),(1,(1,0)),(2,(1,0))] The above looks sane but re-ordering the alternative causes the match to fail: >> "searchme" =~ "s(^|())e" :: Array Int (MatchOffset,MatchLength) > array (1,0) [] And the problems with ^ and $ are not the only ones: >> "searchme" =~ "((s)|(e)|(a))*" :: Array Int (MatchOffset,MatchLength) > array (0,4) [(0,(0,3)),(1,(2,1)),(2,(-1,0)),(3,(-1,0)),(4,(2,1))] The above is correct, but this is not: >> "searchme" =~ "((s)|(e)|())*" :: Array Int (MatchOffset,MatchLength) > array (0,4) [(0,(0,2)),(1,(1,1)),(2,(-1,0)),(3,(1,1)),(4,(2,0))] From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:40:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745F010656AD for ; Mon, 23 Aug 2010 12:40:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABEB8FC0C for ; Mon, 23 Aug 2010 12:40:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A954646B2C; Mon, 23 Aug 2010 08:40:33 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 223038A04F; Mon, 23 Aug 2010 08:40:32 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 23 Aug 2010 08:26:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008230826.49509.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Aug 2010 08:40:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ian FREISLICH Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:40:34 -0000 On Friday, August 20, 2010 12:11:00 pm Ian FREISLICH wrote: > Hi > > I have a system that relies on Fuse and OWFS to manage the power > at my house. I get the following panic when writing to to one of > the PIO devices: > > The panic isn't really helpful because it looks like the stack frame > has been broken. > > Have others seen this? I've tried rebuilding everything from a > clean slate but it doesn't help. The machine used to be -STABLE, > which worked until 21 April 2010, but no kernel since has worked. > > brane.freislich.nom.za dumped core - see /var/crash/vmcore.7 > > Fri Aug 20 16:07:17 SAST 2010 > > FreeBSD brane.freislich.nom.za 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Fri Aug 20 13:53:55 SAST 2010 ianf@brane.freislich.nom.za:/usr/obj/usr/src/sys/BRANE i386 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xe75d3b50 > frame pointer = 0x28:0xe75d3c14 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 56578 (sh) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at kdb_backtrace+0x29 > panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf > trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 > trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b > trap(e75d3b10) at trap+0x423 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- > uart_z8530_class(c784ab00,ffffff9c,284052c4,0,402,...) at 0 > kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 > open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 > syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at syscallenter+0x343 > syscall(e75d3d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, ebp = 0xbfbfea28 --- > Uptime: 1h49m31s > Physical memory: 2007 MB > Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 The uart thing is a red herring, notice the actual PC value is '0'. Something in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in kgdb would be a good start of where to look. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:40:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AB7D10657A2 for ; Mon, 23 Aug 2010 12:40:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 19C588FC08 for ; Mon, 23 Aug 2010 12:40:36 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B5F6246B37; Mon, 23 Aug 2010 08:40:35 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8537C8A050; Mon, 23 Aug 2010 08:40:34 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 23 Aug 2010 08:37:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C6FF0A9.9020809@icyb.net.ua> In-Reply-To: <4C6FF0A9.9020809@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008230837.22200.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Aug 2010 08:40:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: bf1783@gmail.com, Andriy Gapon Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:40:36 -0000 On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote: > on 21/08/2010 16:04 b. f. said the following: > > Andriy Gapon wrote: > >> on 21/08/2010 12:35 Andriy Gapon said the following: > >>> I feel like you might be having a problem with clocks... > >> FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 > >> and I see this sentence: "All of the clocks in the processor core are > >> stopped in the C3 state". > >> > >> I see that you have C3 state enabled and it's regularly entered: > >> dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us > > > > I don't think this accounts for all of his problems, unless his > > machine has an unusual configuration. > > Well, let's try to not muddy the waters prematurely. It could easily account for it. If the lapic is going to sleep in C3, then you are actually missing statclock interrupts and likely screwing up the accounting (idle threads wouldn't accumulate "time" correctly for example). Even though his system really isn't spending a lot of time executing interrupts, the cp_time[] values would be skewed and wrong. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:40:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3290B10656A5; Mon, 23 Aug 2010 12:40:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 02B788FC21; Mon, 23 Aug 2010 12:40:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A01D446B46; Mon, 23 Aug 2010 08:40:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 797E28A04E; Mon, 23 Aug 2010 08:40:36 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 23 Aug 2010 08:39:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C71E858.90009@FreeBSD.org> In-Reply-To: <4C71E858.90009@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201008230839.15284.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Aug 2010 08:40:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Doug Barton , Andriy Gapon Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:40:38 -0000 On Sunday, August 22, 2010 11:17:44 pm Doug Barton wrote: > Thanks to help from Andriy I've been working on narrowing down the cause > of my "runaway intr" problems and we've found some interesting things. > First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than > C1 things seem to work fine. Using one or the other sort of works, but > between the 2 powerd seems to cause the most problems. I think this just means that when C3 is enabled the system is getting skewed results in cp_time[] and so the stats are off. The system isn't actually stuck in an interrupt storm of sorts, the numbers reported to top are just wrong so it looks like it is. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:45:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01F151065673 for ; Mon, 23 Aug 2010 12:45:43 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 97CD58FC18 for ; Mon, 23 Aug 2010 12:45:42 +0000 (UTC) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id o7NCjcTs046356; Mon, 23 Aug 2010 13:45:38 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [192.168.2.3] (host86-153-254-17.range86-153.btcentralplus.com [86.153.254.17]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id o7NCjWJQ089222; Mon, 23 Aug 2010 13:45:32 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <4C7260CC.9070407@list.mightyreason.com> Date: Mon, 23 Aug 2010 13:45:26 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1179D92F-9AB7-43A4-8943-7DA58F5E234D@gid.co.uk> References: <4C7260CC.9070407@list.mightyreason.com> To: chrisk-freebsd@list.mightyreason.com X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, gabor@freebsd.org Subject: Re: grep and Regular expression correctness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:45:43 -0000 Hi, On 23 Aug 2010, at 12:51, chrisk-freebsd@list.mightyreason.com wrote: > [...]The hardest part of POSIX regular expressions is in picking out the > correct captured subexpressions. This makes programs like "sed" > vulnerable to the bad regex.h engine that comes with the operating system. > > Luckily grep does not need the captured subexpressions, and thus does > not need the complexity that comes from the ideas behind TRE. [etc] I think grep does potentially need the captured subexpressions, for eg: \([abc]\)99\1 matching eg b99b -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:59:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3033C10656AB; Mon, 23 Aug 2010 12:59:04 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id BF7D88FC12; Mon, 23 Aug 2010 12:59:03 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OnWc8-0001Fe-A8; Mon, 23 Aug 2010 14:59:00 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnWc7-0001Kv-47; Mon, 23 Aug 2010 14:58:59 +0200 Message-Id: To: John Baldwin From: Ian FREISLICH In-Reply-To: <201008230826.49509.jhb@freebsd.org> References: <201008230826.49509.jhb@freebsd.org> X-Attribution: BOFH Date: Mon, 23 Aug 2010 14:58:59 +0200 Cc: freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:59:04 -0000 John Baldwin wrote: > The uart thing is a red herring, notice the actual PC value is '0'. Something > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in > kgdb would be a good start of where to look. (kgdb) l *kern_open+0x35 0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040). 1035 kern_open(struct thread *td, char *path, enum uio_seg pathseg, int flags, 1036 int mode) 1037 { 1038 1039 return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode)); 1040 } 1041 1042 int 1043 kern_openat(struct thread *td, int fd, char *path, enum uio_seg pathseg, 1044 int flags, int mode) That's what my reading seemed indicate. I had to downgrade the system back to 8.0-STABLE at around 21 April 2010, to get the system working. I'm currently doing a binary search to find offending commit, since CURRENT and STABLE panic reliably, and in the same way I'm sure that the problem is common to both. I'm down to a window of 9 hours. My money is currently on: Working file: sys/kern/vfs_syscalls.c Approved by: re (bz) ---------------------------- revision 1.487.2.7 date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15 SVN rev 207270 on 2010-04-27 10:47:54Z by kib MFC r206547: Handle a case in kern_openat() when vn_open() change file type from DTYPE_VNODE. ---------------------------- Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:26:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D1110656A4; Mon, 23 Aug 2010 13:26:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E83EF8FC18; Mon, 23 Aug 2010 13:26:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7NDPqsd072143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 16:25:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7NDPqxs016050; Mon, 23 Aug 2010 16:25:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7NDPpi3016049; Mon, 23 Aug 2010 16:25:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Aug 2010 16:25:51 +0300 From: Kostik Belousov To: Ian FREISLICH Message-ID: <20100823132551.GE2396@deviant.kiev.zoral.com.ua> References: <201008230826.49509.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C5mNXtOYtedg0se9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:26:23 -0000 --C5mNXtOYtedg0se9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2010 at 02:58:59PM +0200, Ian FREISLICH wrote: > John Baldwin wrote: > > The uart thing is a red herring, notice the actual PC value is '0'. So= mething > > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x= 35' in > > kgdb would be a good start of where to look. >=20 > (kgdb) l *kern_open+0x35 > 0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040). > 1035 kern_open(struct thread *td, char *path, enum uio_seg pathseg, in= t flags, > 1036 int mode) > 1037 { > 1038 > 1039 return (kern_openat(td, AT_FDCWD, path, pathseg, flags, m= ode)); > 1040 } > 1041 > 1042 int > 1043 kern_openat(struct thread *td, int fd, char *path, enum uio_seg p= athseg, > 1044 int flags, int mode) >=20 > That's what my reading seemed indicate. I had to downgrade the > system back to 8.0-STABLE at around 21 April 2010, to get the system > working. >=20 > I'm currently doing a binary search to find offending commit, since > CURRENT and STABLE panic reliably, and in the same way I'm sure > that the problem is common to both. >=20 > I'm down to a window of 9 hours. My money is currently on: >=20 > Working file: sys/kern/vfs_syscalls.c > Approved by: re (bz) > ---------------------------- > revision 1.487.2.7 > date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15 > SVN rev 207270 on 2010-04-27 10:47:54Z by kib >=20 > MFC r206547: > Handle a case in kern_openat() when vn_open() change file type from > DTYPE_VNODE. > ---------------------------- Which most likely means that fusesfs filled its own struct fileops without properly initializing fo_truncate member. --C5mNXtOYtedg0se9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxydt8ACgkQC3+MBN1Mb4iNywCgsQTc+2NQ9opXPQK8pqpHduxc XVoAn2Gmn9rw/4OShipmoOoYq+Z0Td+W =Zbnq -----END PGP SIGNATURE----- --C5mNXtOYtedg0se9-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:29:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D4D1065694; Mon, 23 Aug 2010 13:29:10 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5851D8FC1A; Mon, 23 Aug 2010 13:29:09 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OnX5H-0004I9-M4; Mon, 23 Aug 2010 15:29:07 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnX5G-0001O3-PV; Mon, 23 Aug 2010 15:29:06 +0200 Message-Id: From: Ian FREISLICH X-Attribution: BOFH Date: Mon, 23 Aug 2010 15:29:06 +0200 Cc: freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:29:10 -0000 Ian FREISLICH wrote: > John Baldwin wrote: > > The uart thing is a red herring, notice the actual PC value is '0'. Someth ing > > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in > > kgdb would be a good start of where to look. > > (kgdb) l *kern_open+0x35 > 0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040). > 1035 kern_open(struct thread *td, char *path, enum uio_seg pathseg, int fl ags, > 1036 int mode) > 1037 { > 1038 > 1039 return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode) ); > 1040 } > 1041 > 1042 int > 1043 kern_openat(struct thread *td, int fd, char *path, enum uio_seg paths eg, > 1044 int flags, int mode) > > That's what my reading seemed indicate. I had to downgrade the > system back to 8.0-STABLE at around 21 April 2010, to get the system > working. > > I'm currently doing a binary search to find offending commit, since > CURRENT and STABLE panic reliably, and in the same way I'm sure > that the problem is common to both. > > I'm down to a window of 9 hours. My money is currently on: > > Working file: sys/kern/vfs_syscalls.c > Approved by: re (bz) > ---------------------------- > revision 1.487.2.7 > date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15 > SVN rev 207270 on 2010-04-27 10:47:54Z by kib > > MFC r206547: > Handle a case in kern_openat() when vn_open() change file type from > DTYPE_VNODE. > ---------------------------- Confirmed. 1.487.2.6 doesn't panic, 1.487.2.7 does. This is the change that results in the panic. --- sys/kern/vfs_syscalls.c 16 Apr 2010 08:32:08 -0000 1.487.2.6 +++ sys/kern/vfs_syscalls.c 27 Apr 2010 10:47:54 -0000 1.487.2.7 @@ -35,7 +35,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.6 2010/04/16 08:32:08 kib Exp $"); +__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.7 2010/04/27 10:47:54 kib Exp $"); #include "opt_compat.h" #include "opt_kdtrace.h" @@ -1047,8 +1047,6 @@ struct filedesc *fdp = p->p_fd; struct file *fp; struct vnode *vp; - struct vattr vat; - struct mount *mp; int cmode; struct file *nfp; int type, indx, error; @@ -1141,7 +1139,7 @@ } VOP_UNLOCK(vp, 0); - if (flags & (O_EXLOCK | O_SHLOCK)) { + if (fp->f_type == DTYPE_VNODE && (flags & (O_EXLOCK | O_SHLOCK)) != 0) { lf.l_whence = SEEK_SET; lf.l_start = 0; lf.l_len = 0; @@ -1158,18 +1156,7 @@ atomic_set_int(&fp->f_flag, FHASLOCK); } if (flags & O_TRUNC) { - if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0) - goto bad; - VATTR_NULL(&vat); - vat.va_size = 0; - vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); -#ifdef MAC - error = mac_vnode_check_write(td->td_ucred, fp->f_cred, vp); - if (error == 0) -#endif - error = VOP_SETATTR(vp, &vat, td->td_ucred); - VOP_UNLOCK(vp, 0); - vn_finished_write(mp); + error = fo_truncate(fp, 0, td->td_ucred, td); if (error) goto bad; } mount: /dev/fuse0 on /1-wire (fusefs, local, synchronous) Something about it has a write echo -n 192 > /1-wire/29.A52A03000000/PIO.BYTE Panic. But not like: echo -n 192 >> /1-wire/29.A52A03000000/PIO.BYTE I suspect the truncate is not safe. Or, at least this fuse presented fite cannot be truncated. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:35:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60C8F106564A for ; Mon, 23 Aug 2010 13:35:56 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id EC9398FC1C for ; Mon, 23 Aug 2010 13:35:55 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 495992A28D21; Mon, 23 Aug 2010 15:35:55 +0200 (CEST) Date: Mon, 23 Aug 2010 15:35:55 +0200 From: Ed Schouten To: Kostik Belousov Message-ID: <20100823133555.GA64651@hoeg.nl> References: <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <20100823132551.GE2396@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:35:56 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kostik Belousov wrote: > Which most likely means that fusesfs filled its own struct fileops > without properly initializing fo_truncate member. It's a bit misleading that cdevs automatically patch the table, while the fileops don't. Maybe it would be a good idea to patch finit() to check whether under INVARIATIONS all fileops are set? --=20 Ed Schouten WWW: http://80386.nl/ --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxyeTsACgkQ52SDGA2eCwU2VQCcDavDTevsi1HbgVeqC/abHLH0 uNcAnR726XfGSriSdtaIHBemp5k3x7Yi =eLR7 -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:40:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76CB41065693 for ; Mon, 23 Aug 2010 13:40:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 39D7B8FC13 for ; Mon, 23 Aug 2010 13:40:10 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 9F47C2A28D23; Mon, 23 Aug 2010 15:40:09 +0200 (CEST) Date: Mon, 23 Aug 2010 15:40:09 +0200 From: Ed Schouten To: Kostik Belousov Message-ID: <20100823134009.GB64651@hoeg.nl> References: <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <20100823133555.GA64651@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:40:10 -0000 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > check whether under INVARIATIONS all fileops are set? INVARIANTS, that is. --=20 Ed Schouten WWW: http://80386.nl/ --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxyejkACgkQ52SDGA2eCwWERgCeNJBe1FGeV3eKjwiuLOKz2rwI dEMAnRCW751zBF2TkNzQ/YVVuPnxa8oo =3Q6O -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:42:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AD0A1065670; Mon, 23 Aug 2010 13:42:59 +0000 (UTC) (envelope-from chrisk-freebsd@list.mightyreason.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC9E8FC12; Mon, 23 Aug 2010 13:42:58 +0000 (UTC) Received: from chris-kuklewiczs-macbook-pro.local (unknown [137.195.54.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B16322E1F3; Mon, 23 Aug 2010 09:42:57 -0400 (EDT) Message-ID: <4C727AE0.8090709@list.mightyreason.com> Date: Mon, 23 Aug 2010 14:42:56 +0100 From: chrisk-freebsd@list.mightyreason.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Bob Bishop References: <4C7260CC.9070407@list.mightyreason.com> <1179D92F-9AB7-43A4-8943-7DA58F5E234D@gid.co.uk> In-Reply-To: <1179D92F-9AB7-43A4-8943-7DA58F5E234D@gid.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 23 Aug 2010 13:45:53 +0000 Cc: freebsd-current@freebsd.org, gabor@freebsd.org Subject: Re: grep and Regular expression correctness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:42:59 -0000 On 23/08/2010 13:45, Bob Bishop wrote: > On 23 Aug 2010, at 12:51, chrisk-freebsd@list.mightyreason.com wrote: >> [...]The hardest part of POSIX regular expressions is in picking out the >> correct captured subexpressions. This makes programs like "sed" >> vulnerable to the bad regex.h engine that comes with the operating system. >> >> Luckily grep does not need the captured subexpressions, and thus does >> not need the complexity that comes from the ideas behind TRE. [etc] > I think grep does potentially need the captured subexpressions, for eg: > > \([abc]\)99\1 > > matching eg b99b That would be "basic POSIX" instead of "extended POSIX" regular expressions. Making basic regular expressions correct is something I have never attempted. Correctness is what I would like to emphasize. GNU grep defines the regex.h header for POSIX regular expressions but does not try to deliver the correct POSIX answer. Getting the wrong answer quickly is not a virtue as debugging prematurely optimized code is too hard. http://www2.research.att.com/~gsf/testregex/re-interpretation.html has the best explanation of basic and extended POSIX regular expressions. And last I checked the AT&T code was nearly correct but exponentially slow. I hope that if "grep" in *BSD and thus OSX gets worked on that it gets more correct, not less. I hope that someday the regex.h engine in *BSD and thus OSX gets fixed, but I am not holding my breath for that. All I have written is a correct (and efficient) "extended POSIX" matching engine in Haskell and OCaml. Cheers, Chris Kuklewicz From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:46:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875961065696 for ; Mon, 23 Aug 2010 13:46:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 03E0F8FC08 for ; Mon, 23 Aug 2010 13:46:09 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7NDixu4073549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 16:44:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7NDix0m016183; Mon, 23 Aug 2010 16:44:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7NDixvg016182; Mon, 23 Aug 2010 16:44:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Aug 2010 16:44:59 +0300 From: Kostik Belousov To: Ed Schouten Message-ID: <20100823134459.GF2396@deviant.kiev.zoral.com.ua> References: <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FaWovXeSfYgRrgy1" Content-Disposition: inline In-Reply-To: <20100823133555.GA64651@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:46:10 -0000 --FaWovXeSfYgRrgy1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > * Kostik Belousov wrote: > > Which most likely means that fusesfs filled its own struct fileops > > without properly initializing fo_truncate member. >=20 > It's a bit misleading that cdevs automatically patch the table, while > the fileops don't. Maybe it would be a good idea to patch finit() to I do not understand your first sentence. Would you please elaborate ? > check whether under INVARIATIONS all fileops are set? >=20 > --=20 > Ed Schouten > WWW: http://80386.nl/ --FaWovXeSfYgRrgy1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxye1sACgkQC3+MBN1Mb4gk7gCdHrK4S7LR/7a0qSidiM6QJYBQ NqkAn0zHBlaS1G6WSCuU/cH2+mw1BHzm =wEUw -----END PGP SIGNATURE----- --FaWovXeSfYgRrgy1-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 13:47:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C43761065694 for ; Mon, 23 Aug 2010 13:47:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 8433C8FC1A for ; Mon, 23 Aug 2010 13:47:24 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id E3FD72A28D2E; Mon, 23 Aug 2010 15:47:23 +0200 (CEST) Date: Mon, 23 Aug 2010 15:47:23 +0200 From: Ed Schouten To: Kostik Belousov Message-ID: <20100823134723.GC64651@hoeg.nl> References: <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline In-Reply-To: <20100823134459.GF2396@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:47:24 -0000 --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kostik Belousov wrote: > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > * Kostik Belousov wrote: > > > Which most likely means that fusesfs filled its own struct fileops > > > without properly initializing fo_truncate member. > >=20 > > It's a bit misleading that cdevs automatically patch the table, while > > the fileops don't. Maybe it would be a good idea to patch finit() to > I do not understand your first sentence. Would you please elaborate ? Say, you create a cdev, if you don't implement all ops, it will check for null pointers and return error codes accordingly. This doesn't happen for fileops, which is probably one of the reasons why people sometimes forget to implement them. Wouldn't it be better to prevent this form of footshooting by adding assertions? This will add some overhead for any file descriptor created, but a kernel with INVARIANTS isn't meant to be fast. --=20 Ed Schouten WWW: http://80386.nl/ --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxye+sACgkQ52SDGA2eCwXtewCfeU4xVL5Q5bEYTTGDTntIhpwY n6kAnibyW8f9geMMz1zsMmgw2L8UulKV =hxFa -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 14:02:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A72571065672 for ; Mon, 23 Aug 2010 14:02:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0B28FC13 for ; Mon, 23 Aug 2010 14:02:31 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7NE1n5O074940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 17:01:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7NE1neb016314; Mon, 23 Aug 2010 17:01:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7NE1na6016313; Mon, 23 Aug 2010 17:01:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Aug 2010 17:01:49 +0300 From: Kostik Belousov To: Ed Schouten Message-ID: <20100823140149.GG2396@deviant.kiev.zoral.com.ua> References: <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> <20100823134723.GC64651@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7hK5U8dVDlZxii7z" Content-Disposition: inline In-Reply-To: <20100823134723.GC64651@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:02:32 -0000 --7hK5U8dVDlZxii7z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote: > * Kostik Belousov wrote: > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > > * Kostik Belousov wrote: > > > > Which most likely means that fusesfs filled its own struct fileops > > > > without properly initializing fo_truncate member. > > >=20 > > > It's a bit misleading that cdevs automatically patch the table, while > > > the fileops don't. Maybe it would be a good idea to patch finit() to > > I do not understand your first sentence. Would you please elaborate ? >=20 > Say, you create a cdev, if you don't implement all ops, it will check > for null pointers and return error codes accordingly. This doesn't > happen for fileops, which is probably one of the reasons why people > sometimes forget to implement them. >=20 > Wouldn't it be better to prevent this form of footshooting by adding > assertions? This will add some overhead for any file descriptor created, > but a kernel with INVARIANTS isn't meant to be fast. Thanks, I see it now. The cdev interface definitely falls into the public kernel interface. Having to fill all cdevsw methods for a random driver is too much burden put on the several dozens maintainers. On the other hand, file level is not much widely used by third-party components, and even in-tree code implements only ten different file types. I would not object loudly if someone put such checks as proposed under INVARIANTS, but also I do not see a real point in having them. Might be slightly better to put the checks, again under INVARIANTS, in the fo_XXX() wrappers. --7hK5U8dVDlZxii7z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxyf0wACgkQC3+MBN1Mb4gjkACfWQSnkIDLXKiZECPd0x38vUpv IpwAnAqH9sGw8rGNp4eg4ud0SUBLgreK =ftxV -----END PGP SIGNATURE----- --7hK5U8dVDlZxii7z-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 14:09:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D301065693 for ; Mon, 23 Aug 2010 14:09:42 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id B844F8FC16 for ; Mon, 23 Aug 2010 14:09:41 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 22C652A28D23; Mon, 23 Aug 2010 16:09:41 +0200 (CEST) Date: Mon, 23 Aug 2010 16:09:41 +0200 From: Ed Schouten To: Kostik Belousov Message-ID: <20100823140941.GD64651@hoeg.nl> References: <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> <20100823134723.GC64651@hoeg.nl> <20100823140149.GG2396@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IDYEmSnFhs3mNXr+" Content-Disposition: inline In-Reply-To: <20100823140149.GG2396@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ian FREISLICH , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:09:42 -0000 --IDYEmSnFhs3mNXr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kostik Belousov wrote: > I would not object loudly if someone put such checks as proposed > under INVARIANTS, but also I do not see a real point in having them. > Might be slightly better to put the checks, again under INVARIANTS, > in the fo_XXX() wrappers. Well, the entire point is to put them in finit(), because that way you as a programmer will get punished as soon as possible, namely when you implement the new type of file descriptor. Putting them in the fo_XXX() wrappers makes little sense, because that will only cause a panic 1 microsecond before it would have crashed on the null pointer anyway. --=20 Ed Schouten WWW: http://80386.nl/ --IDYEmSnFhs3mNXr+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxygSUACgkQ52SDGA2eCwXjIQCeNT5l1GHhFlTIyoTJxzqx1VAL N8QAniHJ3jQbbtQVxu5BLj7y6XOuyvQU =G6fR -----END PGP SIGNATURE----- --IDYEmSnFhs3mNXr+-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 14:34:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30B361065694 for ; Mon, 23 Aug 2010 14:34:35 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6967E8FC21 for ; Mon, 23 Aug 2010 14:34:34 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OnY6Z-0002R9-UR; Mon, 23 Aug 2010 16:34:32 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnY55-0001YZ-0L; Mon, 23 Aug 2010 16:32:59 +0200 Message-Id: To: Kostik Belousov From: Ian FREISLICH In-Reply-To: <20100823140149.GG2396@deviant.kiev.zoral.com.ua> References: <20100823140149.GG2396@deviant.kiev.zoral.com.ua> <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> <20100823134723.GC64651@hoeg.nl> X-Attribution: BOFH Date: Mon, 23 Aug 2010 16:32:58 +0200 Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:34:35 -0000 Kostik Belousov wrote: > > --7hK5U8dVDlZxii7z > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote: > > * Kostik Belousov wrote: > > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > > > * Kostik Belousov wrote: > > > > > Which most likely means that fusesfs filled its own struct fileops > > > > > without properly initializing fo_truncate member. > > > >=20 > > > > It's a bit misleading that cdevs automatically patch the table, while > > > > the fileops don't. Maybe it would be a good idea to patch finit() to > > > I do not understand your first sentence. Would you please elaborate ? > >=20 > > Say, you create a cdev, if you don't implement all ops, it will check > > for null pointers and return error codes accordingly. This doesn't > > happen for fileops, which is probably one of the reasons why people > > sometimes forget to implement them. > >=20 > > Wouldn't it be better to prevent this form of footshooting by adding > > assertions? This will add some overhead for any file descriptor created, > > but a kernel with INVARIANTS isn't meant to be fast. > Thanks, I see it now. > > The cdev interface definitely falls into the public kernel interface. > Having to fill all cdevsw methods for a random driver is too much > burden put on the several dozens maintainers. > > On the other hand, file level is not much widely used by third-party > components, and even in-tree code implements only ten different file > types. > > I would not object loudly if someone put such checks as proposed > under INVARIANTS, but also I do not see a real point in having them. > Might be slightly better to put the checks, again under INVARIANTS, > in the fo_XXX() wrappers. So, in this case is the fusefs module broken? I'm guessing it is. I don't like the way fuse_fileops is initialised in fuse4bsd. I would prefer for the struct to be zeroed and then the fo_xxx implimented bits set as appropriate. That way when the struct is changed, you don't get stung again. Patch attached to that makes fusefs-kmod not blowup kernels post this change. Ian -- Ian Freislich Index: files/patch-fuse_module__fuse_vnops.c =================================================================== RCS file: /home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_vnops.c,v retrieving revision 1.4 diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c --- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 -0000 1.4 +++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 -0000 +@@ -214,6 +214,7 @@ + * following fields are filled from vnops, but "vnops.foo" is not + * legitimate in a definition, so we set them at module load time + */ ++ .fo_truncate = NULL, + .fo_ioctl = NULL, + .fo_poll = NULL, + .fo_kqfilter = NULL, +@@ -799,8 +800,11 @@ struct vnode *vp = ap->a_vp; struct vattr *vap = ap->a_vap; struct ucred *cred = ap->a_cred; @@ -13,7 +21,7 @@ struct fuse_dispatcher fdi; struct timespec uptsp; int err = 0; -@@ -871,7 +874,11 @@ +@@ -871,7 +875,11 @@ fuse_access(ap) struct vop_access_args /* { struct vnode *a_vp; @@ -25,7 +33,7 @@ struct ucred *a_cred; struct thread *a_td; } */ *ap; -@@ -886,7 +893,13 @@ +@@ -886,7 +894,13 @@ else facp.facc_flags |= FACCESS_DO_ACCESS; @@ -40,7 +48,7 @@ } /* -@@ -946,7 +959,11 @@ +@@ -946,7 +960,11 @@ /* We are to do the check in-kernel */ if (! (facp->facc_flags & FACCESS_VA_VALID)) { @@ -53,7 +61,7 @@ if (err) return (err); facp->facc_flags |= FACCESS_VA_VALID; -@@ -1929,7 +1946,11 @@ +@@ -1929,7 +1947,11 @@ * It will not invalidate pages which are dirty, locked, under * writeback or mapped into pagetables.") */ @@ -65,7 +73,7 @@ fufh->flags |= FOPEN_KEEP_CACHE; } -@@ -3005,8 +3026,11 @@ +@@ -3005,8 +3027,11 @@ struct vattr *vap = ap->a_vap; struct vnode *vp = ap->a_vp; struct ucred *cred = ap->a_cred; From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 14:44:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0821B1065696 for ; Mon, 23 Aug 2010 14:44:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 77A188FC17 for ; Mon, 23 Aug 2010 14:44:16 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7NEhXQh078108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 17:43:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7NEhWEH016605; Mon, 23 Aug 2010 17:43:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7NEhWsp016604; Mon, 23 Aug 2010 17:43:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Aug 2010 17:43:32 +0300 From: Kostik Belousov To: Ian FREISLICH Message-ID: <20100823144332.GH2396@deviant.kiev.zoral.com.ua> References: <20100823140149.GG2396@deviant.kiev.zoral.com.ua> <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> <20100823134723.GC64651@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KyN5VKAiO6iH4v7I" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:44:18 -0000 --KyN5VKAiO6iH4v7I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2010 at 04:32:58PM +0200, Ian FREISLICH wrote: > Kostik Belousov wrote: > >=20 > > --7hK5U8dVDlZxii7z > > Content-Type: text/plain; charset=3Dus-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > >=20 > > On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote: > > > * Kostik Belousov wrote: > > > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote: > > > > > * Kostik Belousov wrote: > > > > > > Which most likely means that fusesfs filled its own struct file= ops > > > > > > without properly initializing fo_truncate member. > > > > >=3D20 > > > > > It's a bit misleading that cdevs automatically patch the table, w= hile > > > > > the fileops don't. Maybe it would be a good idea to patch finit()= to > > > > I do not understand your first sentence. Would you please elaborate= ? > > >=3D20 > > > Say, you create a cdev, if you don't implement all ops, it will check > > > for null pointers and return error codes accordingly. This doesn't > > > happen for fileops, which is probably one of the reasons why people > > > sometimes forget to implement them. > > >=3D20 > > > Wouldn't it be better to prevent this form of footshooting by adding > > > assertions? This will add some overhead for any file descriptor creat= ed, > > > but a kernel with INVARIANTS isn't meant to be fast. > > Thanks, I see it now. > >=20 > > The cdev interface definitely falls into the public kernel interface. > > Having to fill all cdevsw methods for a random driver is too much > > burden put on the several dozens maintainers. > >=20 > > On the other hand, file level is not much widely used by third-party > > components, and even in-tree code implements only ten different file > > types. > >=20 > > I would not object loudly if someone put such checks as proposed > > under INVARIANTS, but also I do not see a real point in having them. > > Might be slightly better to put the checks, again under INVARIANTS, > > in the fo_XXX() wrappers. >=20 > So, in this case is the fusefs module broken? I'm guessing it is. > I don't like the way fuse_fileops is initialised in fuse4bsd. I > would prefer for the struct to be zeroed and then the fo_xxx > implimented bits set as appropriate. That way when the struct is > changed, you don't get stung again. >=20 > Patch attached to that makes fusefs-kmod not blowup kernels post this cha= nge. >=20 > Ian >=20 > --=20 > Ian Freislich >=20 > Index: files/patch-fuse_module__fuse_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__= fuse_vnops.c,v > retrieving revision 1.4 > diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c > --- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 -0000 1.4 > +++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 -0000 > +@@ -214,6 +214,7 @@ > + * following fields are filled from vnops, but "vnops.foo" is n= ot > + * legitimate in a definition, so we set them at module load ti= me > + */ > ++ .fo_truncate =3D NULL, > + .fo_ioctl =3D NULL, > + .fo_poll =3D NULL, > + .fo_kqfilter =3D NULL, Did you tested this ? I suppose that it would not change anything. Fuse, most likely, lacks real implementation of .fo_truncate method. The implementation was required for long time, otherwise file truncation would not work. --KyN5VKAiO6iH4v7I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxyiRQACgkQC3+MBN1Mb4jU1gCdGGyYoMujuWFSPy8ZM1wIVYeq 2y4An2RCVdK6QJsvTTISBOnnHUFwxYxL =73Dj -----END PGP SIGNATURE----- --KyN5VKAiO6iH4v7I-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 14:57:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8A1A1065672 for ; Mon, 23 Aug 2010 14:57:46 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9DE8FC1B for ; Mon, 23 Aug 2010 14:57:46 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OnYT2-0004ho-04; Mon, 23 Aug 2010 16:57:44 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnYSy-0001e9-Vv; Mon, 23 Aug 2010 16:57:41 +0200 Message-Id: From: Ian FREISLICH In-Reply-To: References: <20100823140149.GG2396@deviant.kiev.zoral.com.ua> <201008230826.49509.jhb@freebsd.org> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> <20100823134723.GC64651@hoeg.nl> X-Attribution: BOFH Date: Mon, 23 Aug 2010 16:57:40 +0200 Cc: Kostik Belousov , Ed Schouten , freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:57:46 -0000 Ian FREISLICH wrote: > So, in this case is the fusefs module broken? I'm guessing it is. > I don't like the way fuse_fileops is initialised in fuse4bsd. I > would prefer for the struct to be zeroed and then the fo_xxx > implimented bits set as appropriate. That way when the struct is > changed, you don't get stung again. I am an idiot - that will have no effect. This patch needs to be included in sysutils/fusefs-kmod/files -- Ian Freislich patch-fuse_module__fuse_main.c --- fuse_module/fuse_main.c.orig 2010-08-23 16:52:20.000000000 +0200 +++ fuse_module/fuse_main.c 2010-08-23 16:48:17.000000000 +0200 @@ -108,6 +108,7 @@ switch (what) { case MOD_LOAD: /* kldload */ + fuse_fileops.fo_truncate = vnops.fo_truncate; fuse_fileops.fo_ioctl = vnops.fo_ioctl; fuse_fileops.fo_poll = vnops.fo_poll; fuse_fileops.fo_kqfilter = vnops.fo_kqfilter; From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 15:04:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C11E106564A for ; Mon, 23 Aug 2010 15:04:12 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 09DCF8FC0C for ; Mon, 23 Aug 2010 15:04:11 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 210F614DC7A5 for ; Mon, 23 Aug 2010 17:04:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Uj+lvcWQ13Vr for ; Mon, 23 Aug 2010 17:04:07 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 9DC8914DC689 for ; Mon, 23 Aug 2010 17:04:07 +0200 (CEST) Message-ID: <4C728DE5.4060809@FreeBSD.org> Date: Mon, 23 Aug 2010 17:04:05 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201008210231.o7L2VRvI031700@ducky.net> In-Reply-To: <201008210231.o7L2VRvI031700@ducky.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: What to learn from the BSD grep case [Was: why GNU grep is fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:04:12 -0000 Hi all, there are some consequences that we can see from the grep case. Here I'd like to add a summary, which raises some questions. All comments are welcome. 1, When grep entered -CURRENT and bugs were found I immediately got kind bug reports and sharp criticism, as well. According to my understanding, -CURRENT is for development and it's fine to expose new pieces of work there but now I'm in doubt about that because of complaining people. On the other hand, an earlier version of BSD grep has been in the ports tree for a very long time and users reported some problems, which have been fixed but still, there is a lot of bugs there which haven't been reported that time. If users don't volunteer to test new pieces of code on a volunteer basis, somehow we have to make them test it, so I think committing BSD grep to -CURRENT was a good decision in the first round. 2, This issue also brought up some bottlenecks and potential optimization points (like memchr() and mmap), which other softwre may benefit from. This is another reason to let such pieces of work in. But unfortunately, this means that noone profiled another utilities because these bottlenecks remained undiscovered. Neither did I. It's a lesson that we have to learn from this particular case. 3, Because of point 2, we need more content to developers-handbook to help development with such ideas and best practices. It has been also raised on another list that our end-user documentation isn't that shiny and cool that it used to be and actually, developers-handbook has never been "finished" to be more or less complete. If someone looks at it, it looks like a sketch, not a book. I'll see if I can write a section on profiling. 4, We really need a good regex library. From the comments, it seems there's no such in the open source world. GNU libregex isn't efficient because GNU grep uses those workarounds that Mike kindly pointed out. Oniguruma was extremely slow when I checked it. PCRE supports Perl-style syntax with a POSIX-like API but not POSIX regex. Google RE2 is the same with additional egrep syntax but doesn't have support for standard POSIX regexes. Plan 9 regex only supports egrep syntax. It seems that TRE is the best choice. It is BSD-licensed, supports wchar and POSIX(ish) regexes and it is quite fast. I don't know the theoretical background of regex engines but I'm wondering if it's possible top provide an alternative API with byte-counted buffers and use the heuristical speedup with fixed string matching. As Mike pointed out the POSIX API is quite limiting because it works on NUL-terminated strings and not on byte-counted buffers, so we couldn't just do it with a POSIX-conformant library but it would be nice if we could implement it in such a library with an alternative interface. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 15:18:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A072D1065697; Mon, 23 Aug 2010 15:18:51 +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 603CD8FC08; Mon, 23 Aug 2010 15:18:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AA90A1FFC37; Mon, 23 Aug 2010 15:18:49 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7F9E38452E; Mon, 23 Aug 2010 17:18:49 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: bf1783@gmail.com References: <86mxshdqgh.fsf@ds4.des.no> <86r5hpwmf4.fsf@ds4.des.no> Date: Mon, 23 Aug 2010 17:18:49 +0200 In-Reply-To: <86r5hpwmf4.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 23 Aug 2010 14:20:15 +0200") Message-ID: <864oelwe5i.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-current@freebsd.org, gabor@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:18:51 -0000 Dag-Erling Sm=C3=B8rgrav writes: > No idea what causes it, but a quick grep (hah!) for qflag turns up the > following horror: > > /* Find out the correct return value according to the > results and the command line option. */ > exit(c ? (notfound ? (qflag ? 0 : 2) : 0) : (notfound ? 2 : 1)); > > which shows that -q *does* affect the exit code, but my brain refuses to > try to understand that code. My brain is in need of a break from $REALJOB. POSIX says EXIT STATUS The following exit values shall be returned: 0 One or more lines were selected. 1 No lines were selected. >1 An error occurred. CONSEQUENCES OF ERRORS If the -q option is specified, the exit status shall be zero if an input line is selected, even if an error was detected. Otherwise, default actions shall be performed. I suppose c is supposed to indicate, in some manner, whether an error occurred, but it's hard to tell; the code seems almost deliberately obfuscated. The name gives no clue whatsoever as to its meaning. It is incremented like a counter, but tested like a boolean. Its value is derived from the value returned by procfile(), but that value is also named "c", and is derived from values returned by other functions which I could not be bothered to track down. In any case - c notfound qflag result true true true 0 true true false 2 true false true 0 true false false 0 false true true 2 false true false 2 false false true 1 false false false 1 By this point, my brain is tied into the shape of a pretzel, but it looks like c might actually be a count of matching lines and notfound might be an error flag. I give it -10 for calling the count "c" instead of "count" or "matches" (I'm being generous because "c" is the first letter of "count"), another -10 for testing it as a boolean instead of comparing it to 0, -1,000 for calling the error flag "notfound", and -1,000,000 for writing code so convoluted that, even with the source code in front of me, I had to reverse-engineer it to figure out what it does. I think that adds up to -1,001,020. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 17:00:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94B8810656A3; Mon, 23 Aug 2010 17:00:18 +0000 (UTC) (envelope-from bf1783@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 0572F8FC20; Mon, 23 Aug 2010 17:00:17 +0000 (UTC) Received: by wyj26 with SMTP id 26so8292551wyj.13 for ; Mon, 23 Aug 2010 10:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=BA89BhNNAdy9X8RW0g3ZTDjAcj0QrileDiF7puB1Lkc=; b=sPI66XXoR0EGZq7aTue82alSo9HPZsIORrZLdHkntMOCA1PFYoPaEIDJtGou4ebkxc bzfFjHAFMCP87PPI1YYfqHQt2gjDMnEaGoJGUKq/nsVDGdXJGfAE6J3mxT4esnCmlODZ IKC+4kiGi5k6RxDzKE4/MCFroX6P0Xr53UAus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=TjKMNTMr8L5F8UHgGaLsf6cPYKfriynVFJaJ8WEctbbqsx+qu5dkurBnhj5C5KmkLY JL9TGWp+HmDeJWWn9win6WuC4ws1nQafWrFHnm/6/3rzfi0hJwhKwsNTE6NtGfJFeqJN 3sgkD0FnS+SZ5OFS05cP6waWvH3u6eYgwOKZA= MIME-Version: 1.0 Received: by 10.216.90.148 with SMTP id e20mr4850072wef.8.1282582816911; Mon, 23 Aug 2010 10:00:16 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Mon, 23 Aug 2010 10:00:16 -0700 (PDT) In-Reply-To: <201008230837.22200.jhb@freebsd.org> References: <4C6FF0A9.9020809@icyb.net.ua> <201008230837.22200.jhb@freebsd.org> Date: Mon, 23 Aug 2010 17:00:16 +0000 Message-ID: From: "b. f." To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:00:18 -0000 On 8/23/10, John Baldwin wrote: > On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote: >> on 21/08/2010 16:04 b. f. said the following: >> > Andriy Gapon wrote: >> >> on 21/08/2010 12:35 Andriy Gapon said the following: >> >>> I feel like you might be having a problem with clocks... >> >> FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 >> >> and I see this sentence: "All of the clocks in the processor core are >> >> stopped in the C3 state". >> >> >> >> I see that you have C3 state enabled and it's regularly entered: >> >> dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us >> > >> > I don't think this accounts for all of his problems, unless his >> > machine has an unusual configuration. >> >> Well, let's try to not muddy the waters prematurely. > > It could easily account for it. If the lapic is going to sleep in C3, then > you are actually missing statclock interrupts and likely screwing up the > accounting (idle threads wouldn't accumulate "time" correctly for example). > Even though his system really isn't spending a lot of time executing > interrupts, the cp_time[] values would be skewed and wrong. Right, I can easily see how it is _a_ problem. I remembered that it was the reason Alexander gave for reviving the use of the rtc and the i8254 as eventtimers/timecounters, and it's partly why I suggested switching clock sources earlier. My point in my reply to Andriy was that Doug had reported similar problems when the hpet was the sole eventtimer/timecounter, and also when the i8254 was the only one, which suggested that there were other problems, too. But then Doug also assured me that he was satisfied that usb wasn't the source of the problem, where now he and Andriy seem to think it plays a primary role, so I give up. I only hope that new interrupt-handling that you are working on makes the system less susceptible to these kinds of problems. b. From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 17:12:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D974D10656A3; Mon, 23 Aug 2010 17:12:56 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8376D8FC13; Mon, 23 Aug 2010 17:12:56 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:153e:890e:2af6:cf40] (unknown [IPv6:2001:7b8:3a7:0:153e:890e:2af6:cf40]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 615F65C59; Mon, 23 Aug 2010 19:12:55 +0200 (CEST) Message-ID: <4C72AC1D.20100@andric.com> Date: Mon, 23 Aug 2010 19:13:01 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: bf1783@gmail.com References: <86mxshdqgh.fsf@ds4.des.no> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090708010302010401080909" Cc: =?ISO-8859-1?Q?av?= , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgr?=, freebsd-current@freebsd.org, "b. f." , =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:12:57 -0000 This is a multi-part message in MIME format. --------------090708010302010401080909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2010-08-20 23:07, b. f. wrote: > The lisp category is the only category that causes a problem with the > new bsdgrep, and I didn't take the time to analyze why ( which is why > I was not more specific in my original message). 'lisp' is preceded by > 'elisp', which would normally be a match for the 'lisp' in a port > Makefile, were it not for the -w flag. 'x11' succeeds, but it > precedes all of the x11-* categories. I suspect that there is an > error in the logic of either the -w or the -q flag implementation in > bsdgrep, which causes problems when the two options are used together. > The target succeeds as expected with GNU grep. Can you please try the following patch? I think this solves more than one problem in bsdgrep's logic, but it needs to be reviewed by Gabor and others. In usr.bin/grep/util.c, in the function procline(), there is the following fragment: 290 /* Loop to process the whole line */ 291 while (st <= l->len) { [...] 295 /* Loop to compare with all the patterns */ 296 for (i = 0; i < patterns; i++) { [... sets r to 0 if a match was found ...] 336 if (r == 0) { [...] 341 /* matches - skip further patterns */ 342 if ((color != NULL && !oflag) || qflag || lflag) 343 break; 344 } 345 } [...] 351 /* One pass if we are not recording matches */ 352 if ((color != NULL && !oflag) || qflag || lflag) 353 break; [...] 357 } If during the first iteration of the "loop to process the whole line" no match was found (for example, if doing a word search for "lisp" and the string "elisp" is found instead), AND the -q option was used, the test in line 352 aborts the whole loop, without searching any further! Thus it will miss the "lisp" string later in the line. It looks like line 352 should only be evaluated if the for() loop just above it resulted in one or or more matches, so it is probably easiest to just replace line 343 with a goto that jumps out of the two enclosing loops (it is still a pity C does not have a "break 2" statement), and delete lines 351..353 entirely. However, if there are unintended side effects, for example with weird combinations of the --color, -o and/or -l flags, please let me know. :) --------------090708010302010401080909 Content-Type: text/plain; name="bsdgrep-wq-fix.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bsdgrep-wq-fix.diff" diff --git a/usr.bin/grep/util.c b/usr.bin/grep/util.c index c65d8f2..97a14f3 100644 --- a/usr.bin/grep/util.c +++ b/usr.bin/grep/util.c @@ -340,7 +340,7 @@ procline(struct str *l, int nottext) matches[m++] = pmatch; /* matches - skip further patterns */ if ((color != NULL && !oflag) || qflag || lflag) - break; + goto skip; } } @@ -348,9 +348,6 @@ procline(struct str *l, int nottext) c = !c; break; } - /* One pass if we are not recording matches */ - if ((color != NULL && !oflag) || qflag || lflag) - break; if (st == (size_t)pmatch.rm_so) break; /* No matches */ @@ -358,6 +355,7 @@ procline(struct str *l, int nottext) } else c = !vflag; +skip: if (c && binbehave == BINFILE_BIN && nottext) return (c); /* Binary file */ --------------090708010302010401080909-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 17:20:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12EC11065693; Mon, 23 Aug 2010 17:20:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id AAB2F8FC1F; Mon, 23 Aug 2010 17:20:54 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o7NGhSJ4091983; Mon, 23 Aug 2010 10:43:28 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4C728DE5.4060809@FreeBSD.org> Date: Mon, 23 Aug 2010 10:43:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4D2AEF-5852-4FF1-BAE5-4C0A51AB75D3@samsco.org> References: <201008210231.o7L2VRvI031700@ducky.net> <4C728DE5.4060809@FreeBSD.org> To: Gabor Kovesdan X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: What to learn from the BSD grep case [Was: why GNU grep is fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:20:55 -0000 On Aug 23, 2010, at 9:04 AM, Gabor Kovesdan wrote: > Hi all, >=20 > there are some consequences that we can see from the grep case. Here = I'd like to add a summary, which raises some questions. All comments are = welcome. >=20 > 1, When grep entered -CURRENT and bugs were found I immediately got = kind bug reports and sharp criticism, as well. According to my = understanding, -CURRENT is for development and it's fine to expose new = pieces of work there but now I'm in doubt about that because of = complaining people. On the other hand, an earlier version of BSD grep = has been in the ports tree for a very long time and users reported some = problems, which have been fixed but still, there is a lot of bugs there = which haven't been reported that time. If users don't volunteer to test = new pieces of code on a volunteer basis, somehow we have to make them = test it, so I think committing BSD grep to -CURRENT was a good decision = in the first round. You did everything right. You were responsive, you were open to = suggestions, and you got the code in. Even more importantly, you got = the code in a year before 9.0, instead of waiting until the last minute, = months from now, and creating a dilemma for the release engineers. = Software is an iterative process of feedback and improvement. The way = that you've handled this should be a model for the project. Scott From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 17:52:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01A39106566B; Mon, 23 Aug 2010 17:52:26 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id C6CB78FC26; Mon, 23 Aug 2010 17:52:25 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id B20732C2A91; Mon, 23 Aug 2010 12:52:17 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t13j4dvwm1Mt; Mon, 23 Aug 2010 12:52:09 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 85CD92C2A8C; Mon, 23 Aug 2010 12:52:09 -0500 (CDT) Message-ID: <4C72B550.2000001@cs.rice.edu> Date: Mon, 23 Aug 2010 12:52:16 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> <4C6D3BBB.7030104@andric.com> <4C6D5302.4030602@cs.rice.edu> <8639u9f5jj.fsf@ds4.des.no> In-Reply-To: <8639u9f5jj.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: alc@freebsd.org, Dimitry Andric , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:52:26 -0000 Dag-Erling Smørgrav wrote: > Alan Cox writes: > >> Here is what actually puzzles me about these results. With >> traditional I/O, even after the optimizations to bsdgrep, the system >> time for gnugrep is still less than half that of the optimized >> bsdgrep. I haven't looked at the changes, but I would have thought >> the system time for gnugrep and bsdgrep would be almost the same. >> > > Two reasons: > > 1) BSD grep does tons of unnecessary memory-to-memory copy operations in > grep_fgetln(). > > 2) GNU grep has its own highly optimized regex code. > > Umm, not really. Notice that I said "system time" not "user time". Even after the recent changes to optimize the I/O in bsdgrep, Dimitry's results show that bsdgrep is spending more than twice as much time in the kernel as gnugrep. That said, in the end, you may be right in the sense that the user space inefficiencies may indirectly result in more cache misses in the kernel because the additional user space memory used by bsdgrep displaces more kernel data from the cache between system calls. However, I would not jump to that conclusion. The explanation for the difference in system time may be more straightforward and easy to fix. It would be nice to see a comparison of bsdgrep and gnugrep using pmcstat to profile L2 cache misses. That might be enlightening. Alan From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 18:56:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B856210656B3 for ; Mon, 23 Aug 2010 18:56:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 46D458FC12 for ; Mon, 23 Aug 2010 18:56:19 +0000 (UTC) Received: (qmail 8181 invoked by uid 399); 23 Aug 2010 18:56:18 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Aug 2010 18:56:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C72C451.4070407@FreeBSD.org> Date: Mon, 23 Aug 2010 11:56:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: John Baldwin References: <4C71E858.90009@FreeBSD.org> <201008230839.15284.jhb@freebsd.org> In-Reply-To: <201008230839.15284.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:56:19 -0000 On 08/23/2010 05:39, John Baldwin wrote: > On Sunday, August 22, 2010 11:17:44 pm Doug Barton wrote: >> Thanks to help from Andriy I've been working on narrowing down the cause >> of my "runaway intr" problems and we've found some interesting things. >> First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than >> C1 things seem to work fine. Using one or the other sort of works, but >> between the 2 powerd seems to cause the most problems. > > I think this just means that when C3 is enabled the system is getting skewed > results in cp_time[] and so the stats are off. The system isn't actually > stuck in an interrupt storm of sorts, the numbers reported to top are just > wrong so it looks like it is. That may be true, however what's happening at that time is that the video and audio both become choppy (as in, painfully so) and every other thing that's running, whether it's desktop clients like thunderbird or something being compiled, also moves very very slow, as if it's resource-starved. So while I'm perfectly ready to admit that the top output may be just a symptom instead of the real problem, something fundamentally bad IS happening under the hood. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 19:14:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3C2E106566C for ; Mon, 23 Aug 2010 19:14:03 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from smtp.fullrate.dk (smtp.fullrate.dk [90.185.1.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6F64C8FC21 for ; Mon, 23 Aug 2010 19:14:03 +0000 (UTC) Received: from [192.168.4.25] (unknown [90.184.171.166]) by smtp.fullrate.dk (Postfix) with ESMTP id 6F5C69D09B for ; Mon, 23 Aug 2010 20:56:09 +0200 (CEST) From: "Simon L. B. Nielsen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Aug 2010 20:56:08 +0200 Message-Id: To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: New FreeBSD SVN seed snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:14:03 -0000 Hey, I have made a new snapshot of the svn repo which can be used to start = new FreeBSD svn mirrors. Hopefully I made it the right way, but... let me know if there are any = issues. Since the original snapshot was made by peter the repo was 'packed' = which means it uses a lot fewer files. The snapshot can be found at: ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ You need ports/archivers/xz installed if you aren't running FreeBSD = 8.1+. Thanks to rpaulo and bz for prodding my into finding out how this worked = and making the new snapshot :-). I can't think of what else to say, so that was probably it :-). --=20 Simon L. B. Nielsen Hat: svn janitor From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 19:19:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86761065670 for ; Mon, 23 Aug 2010 19:19:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88DDA8FC12 for ; Mon, 23 Aug 2010 19:19:50 +0000 (UTC) Received: by pxi17 with SMTP id 17so2677359pxi.13 for ; Mon, 23 Aug 2010 12:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=A6AuWXDiczrqHRnAwc1Ajq3sVn0b+532jszy26yc1So=; b=jaCxynHnjwnPU89fZfWyufWGB3E3D5jnxTXRMcMurxQ0e+1KvAL8Ez3ibfIejVh/SK EAHorAr8MHDMufuVWGEv83rcDjyC6fu78O1qJYjdSqG9Bob8qshTacoHqyc5dwYVnZFF QO9TDeMYKdcqRt/IoKpsBu8VIEURxvdx+IfDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=wuJeqPnjgQ3E2xs99W3+3bPqUWaNES9UXAiWVbvCBKZJtBjEW/gKu6cnbUPKRz/pJJ 961PLpJ+xqeXjl77lSFaTKEiETNCCrvl99V/tfpM8oNm7xsPQK0lIih9bl2UpTZjYpy5 U65oJRw6dARyHOABhWtimHEuB5MG4cV5dErCY= Received: by 10.114.39.18 with SMTP id m18mr6458204wam.225.1282591190379; Mon, 23 Aug 2010 12:19:50 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c10sm13065188wam.13.2010.08.23.12.19.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 12:19:48 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 23 Aug 2010 12:19:46 -0700 From: Pyun YongHyeon Date: Mon, 23 Aug 2010 12:19:46 -0700 To: freebsd-current@freebsd.org Message-ID: <20100823191946.GF1116@michelle.cdnetworks.com> References: <20100811223150.GH15858@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100811223150.GH15858@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Subject: Re: CFT: xl(4) WOL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:19:51 -0000 On Wed, Aug 11, 2010 at 03:31:50PM -0700, Pyun YongHyeon wrote: > Hi, > > Here is patch that adds support WOL for xl(4). Note, not all xl(4) > controllers support WOL. Some controllers require additional 3-wire > auxiliary remote wakeup connector to draw power. I don't have the > connector so I don't know whether WOL really works or not but I > did not see any regressions. > If you're user of xl(4) please give it try and let me know whether > I introduced regressions. > You can find latest WOL patch at the following URL. > http://people.freebsd.org/~yongari/xl/xl.wol.patch > FYI: Patch committed to HEAD(r211717). From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 19:27:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BD9E106566C for ; Mon, 23 Aug 2010 19:27:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id A078C8FC16 for ; Mon, 23 Aug 2010 19:27:24 +0000 (UTC) Received: from f8x64.laiers.local (dslb-088-066-049-083.pools.arcor-ip.net [88.66.49.83]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lp8j6-1PJP7X1UXc-00f62T; Mon, 23 Aug 2010 21:27:23 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Mon, 23 Aug 2010 21:27:22 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008232127.22377.max@love2party.net> X-Provags-ID: V02:K0:vmrGT/+yKHCpYh+M2h8mUjYcvp6rGBYLblDnbIBogIq yat2EiKCWvnlVDZVvFGdw+Ve/tL+RC7k0f+501WGEE8jlMBf23 BuHLW4W+tmXYVygPfCALLHYp/7xHqu7juIWP8y9IBq1EewUf6f zKgOPpnPBIimtC9sQpSHRhm0nAYurGR1HtG/x2OiECngnLx4Y3 NYQt4Yb0h88QUtFD+W8Sg== Cc: "Simon L. B. Nielsen" Subject: Re: New FreeBSD SVN seed snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:27:25 -0000 On Monday 23 August 2010 20:56:08 Simon L. B. Nielsen wrote: > I can't think of what else to say, so that was probably it :-). MD5/SHA256/SIZE? Thank you! Max From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 20:31:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96506106566B for ; Mon, 23 Aug 2010 20:31:23 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from smtp.fullrate.dk (smtp.fullrate.dk [90.185.1.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F18C8FC0C for ; Mon, 23 Aug 2010 20:31:23 +0000 (UTC) Received: from [192.168.4.25] (unknown [90.184.171.166]) by smtp.fullrate.dk (Postfix) with ESMTP id 5CB5D9CE5C; Mon, 23 Aug 2010 22:31:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Simon L. B. Nielsen" In-Reply-To: <201008232127.22377.max@love2party.net> Date: Mon, 23 Aug 2010 22:31:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <453388FF-C536-413E-A669-A37287D347AF@nitro.dk> References: <201008232127.22377.max@love2party.net> To: Max Laier X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org Subject: Re: New FreeBSD SVN seed snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:31:23 -0000 On 23 Aug 2010, at 21:27, Max Laier wrote: > On Monday 23 August 2010 20:56:08 Simon L. B. Nielsen wrote: >> I can't think of what else to say, so that was probably it :-). >=20 > MD5/SHA256/SIZE? People use that? That sounds difficult ;-) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SIZE (svnmirror-base-r211583.tar.xz) =3D 893293980 SHA256 (svnmirror-base-r211583.tar.xz) =3D = aeb176e4f8121e1ceab9be3acbc15d7d09995de2a5262e1db5999f92571799a1 MD5 (svnmirror-base-r211583.tar.xz) =3D caf3ba55c2d5bf3c140b2127b6722ae6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkxy2ZQACgkQFdaIBMps37IHcwCgiqbxZGzaVHwujhPpvQcFarM0 ZEMAn2P9KtafEfr5OBfgSy9wtG94sOKD =3D0Y7Z -----END PGP SIGNATURE----- I'm using a new MUA so I'm not entirely sure if will leave the above = signature without mangling it... If it fails, for now the info is at = http://people.freebsd.org/~simon/tmp/seedinfo.txt.asc (will go away at = some point in the future). --=20 Simon L. B. Nielsen From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 21:13:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45E3F10656A3; Mon, 23 Aug 2010 21:13:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B5E248FC08; Mon, 23 Aug 2010 21:13:00 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7NLCwUB007459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2010 00:12:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7NLCw9p019952; Tue, 24 Aug 2010 00:12:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7NLCvuH019951; Tue, 24 Aug 2010 00:12:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Aug 2010 00:12:57 +0300 From: Kostik Belousov To: Peter Holm Message-ID: <20100823211257.GI2396@deviant.kiev.zoral.com.ua> References: <4C7011B9.4020902@protected-networks.net> <20100822132104.GA7300@x2.osted.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3SKAfNXaYt19qiWj" Content-Disposition: inline In-Reply-To: <20100822132104.GA7300@x2.osted.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: Michael Butler , Jeff Roberson , current@freebsd.org Subject: Re: softupdate with journal panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 21:13:01 -0000 --3SKAfNXaYt19qiWj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote: > On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote: > > While updating sysutils/coreutils port on -current as of this morning > > (SVN r211550), I noted a panic during the directory rename config test. > >=20 >=20 > Your problem seems identical to this report: >=20 > http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8j= VHWPU5mC >=20 I believe that dotdotremref in this case is legitimately NULL. With this assumption, the following patch would help. diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c index b666c0f..65e5255 100644 --- a/sys/ufs/ffs/ffs_softdep.c +++ b/sys/ufs/ffs/ffs_softdep.c @@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref, dotdot= remref) mkdir->md_jaddref =3D NULL; if (mkdir->md_state & MKDIR_PARENT) { if (cancel_jaddref(jaddref, NULL, - &dirrem->dm_jwork) =3D=3D 0) { + &dirrem->dm_jwork) =3D=3D 0 && + dotdotremref !=3D NULL) { free_jremref(dotdotremref); dotdotremref =3D NULL; } --3SKAfNXaYt19qiWj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxy5FgACgkQC3+MBN1Mb4hzZgCgsd5xo26VcO1Wv1IVtbT+tKKU 8U0AoI9l6QOtkbbysUrxxCBTILLDtUbW =1nI7 -----END PGP SIGNATURE----- --3SKAfNXaYt19qiWj-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 22:21:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197F41065697; Mon, 23 Aug 2010 22:21:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D95D48FC21; Mon, 23 Aug 2010 22:21:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7NMLQl2083353; Mon, 23 Aug 2010 18:21:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7NMLQwk083352; Mon, 23 Aug 2010 22:21:26 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 23 Aug 2010 22:21:26 GMT Message-Id: <201008232221.o7NMLQwk083352@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 22:21:28 -0000 TB --- 2010-08-23 20:43:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-23 20:43:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-08-23 20:43:22 - cleaning the object tree TB --- 2010-08-23 20:44:03 - cvsupping the source tree TB --- 2010-08-23 20:44:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-08-23 20:44:39 - building world TB --- 2010-08-23 20:44:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-23 20:44:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-23 20:44:39 - TARGET=powerpc TB --- 2010-08-23 20:44:39 - TARGET_ARCH=powerpc TB --- 2010-08-23 20:44:39 - TZ=UTC TB --- 2010-08-23 20:44:39 - __MAKE_CONF=/dev/null TB --- 2010-08-23 20:44:39 - cd /src TB --- 2010-08-23 20:44:39 - /usr/bin/make -B buildworld >>> World build started on Mon Aug 23 20:44:39 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/load_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/reloc_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/dev_net.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/interp_forth.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../ofw/common/main.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -nostdlib -static -T /src/sys/boot/powerpc/ofw/ldscript.powerpc -o loader conf.o metadata.o vers.o start.o ucmpdi2.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o reloc_elf32.o dev_net.o interp_forth.o main.o /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ficl/libficl.a /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ofw/libofw/libofw.a -lstand /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ofw/libofw/libofw.a(ppc64_elf_freebsd.o)(.text+0xd8): In function `ppc64_ofw_elf_loadfile': : undefined reference to `elf64_loadfile' *** Error code 1 Stop in /src/sys/boot/powerpc/ofw. *** Error code 1 Stop in /src/sys/boot/powerpc. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-23 22:21:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-23 22:21:26 - ERROR: failed to build world TB --- 2010-08-23 22:21:26 - 4196.38 user 1029.75 system 5884.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 01:16:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B861010656A4 for ; Tue, 24 Aug 2010 01:16:10 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8598FC08 for ; Tue, 24 Aug 2010 01:16:10 +0000 (UTC) Received: by qwg5 with SMTP id 5so6312224qwg.13 for ; Mon, 23 Aug 2010 18:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.137 with SMTP id m9mr3868720qac.381.1282612569544; Mon, 23 Aug 2010 18:16:09 -0700 (PDT) Received: by 10.229.95.145 with HTTP; Mon, 23 Aug 2010 18:16:09 -0700 (PDT) X-Originating-IP: [93.203.40.83] In-Reply-To: <4C728DE5.4060809@FreeBSD.org> References: <201008210231.o7L2VRvI031700@ducky.net> <4C728DE5.4060809@FreeBSD.org> Date: Tue, 24 Aug 2010 03:16:09 +0200 Message-ID: From: "C. P. Ghost" To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: What to learn from the BSD grep case [Was: why GNU grep is fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 01:16:10 -0000 On Mon, Aug 23, 2010 at 5:04 PM, Gabor Kovesdan wrote: > 4, We really need a good regex library. From the comments, it seems there's > no such in the open source world. GNU libregex isn't efficient because GNU > grep uses those workarounds that Mike kindly pointed out. Oniguruma was > extremely slow when I checked it. PCRE supports Perl-style syntax with a > POSIX-like API but not POSIX regex. Google RE2 is the same with additional > egrep syntax but doesn't have support for standard POSIX regexes. Plan 9 > regex only supports egrep syntax. It seems that TRE is the best choice. It > is BSD-licensed, supports wchar and POSIX(ish) regexes and it is quite fast. I know it's C++ and not exactly what you're needing, but have you evaluated Boost::Regex? Isn't there some code that can be retrofitted into a C lib? http://www.boost.org/doc/libs/1_44_0/libs/regex/doc/html/index.html > I don't know the theoretical background of regex engines but I'm wondering > if it's possible top provide an alternative API with byte-counted buffers > and use the heuristical speedup with fixed string matching. As Mike pointed > out the POSIX API is quite limiting because it works on NUL-terminated > strings and not on byte-counted buffers, so we couldn't just do it with a > POSIX-conformant library but it would be nice if we could implement it in > such a library with an alternative interface. > > Gabor -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 02:12:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0DB1065679; Tue, 24 Aug 2010 02:12:19 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C40328FC20; Tue, 24 Aug 2010 02:12:18 +0000 (UTC) Received: by vws7 with SMTP id 7so27613vws.13 for ; Mon, 23 Aug 2010 19:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=v1VbfmnEZ1PI6MAmOfW3qYbj0XXHsPN6ZvAYeo0yBQc=; b=qehASKX/OnRqcJk4toECiXMsKot2PS/JVVtkSmqZeUXjciPldRMEn8AX7EtMEQ+IB4 UNOg30hkprlHdynsOfyLRdPjjYcqSSUcnBogWUw70YdDdi7t6jPE5xSJZe+8yDml88us i86k/BUz7fs+Z5cjSTux48xkr36ThqfbBkl6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=RPpF9poUHQOe289SKpBzX9Ys74zp8gXaaBHzZFk9LI1AOeB7ZiF/Y6j7OQ51WPqkbg WyF0XPkBu6EzjhfLRWsl6B9ARzJlvwNGk9wDuzed/4UVUTs1wzwsdq5YSWLZJ0Ftkput 1g74QRWlehZ2W7nwcqL1JKBh3cbEjh4Aw94ic= Received: by 10.220.124.224 with SMTP id v32mr3787015vcr.144.1282614567221; Mon, 23 Aug 2010 18:49:27 -0700 (PDT) Received: from ono-sendai.local ([75.111.34.169]) by mx.google.com with ESMTPS id v11sm3951073vbb.12.2010.08.23.18.49.24 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 18:49:26 -0700 (PDT) Message-ID: <4C732522.1010400@gmail.com> Date: Mon, 23 Aug 2010 18:49:22 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100819 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Sleep/Lenovo SL410 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 02:12:19 -0000 Hope double post is ok, have issue with -CURRENT and ACPI. Kernel is ~week old cvsup -CURRENT amd64, issue has occurred with all versions of freebsd amd64 tried, however. Upon entering S3 sleep (or S4), the laptop emits 3 loud beeps and the sleep indicator begins flashing faster than normal. Older -CURRENT kernels also result in spinning fans at this point, which no longer occurs. Device will remain in this state indefinitely. Device must be powered off using the ten second rule. Occurs with custom kernel as well as GENERIC. Last entry is /var/log/messages is: Aug 23 17:59:09 ono-sendai acpi: suspend at 20100823 17:59:09 Please note atrtc0 error in dmesg? Can provide KERNCONF or other files as needed. Thank you all! I have been using various *bsd since I was 15 (~decade), can't tell you how grateful I am for your work, I hope to be able to help more soon! ACPI dump: http://pastebin.com/buQktjnq Dmesg: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #2: Sun Aug 15 23:33:22 PDT 2010 root@ono-sendai.local:/usr/obj/usr/src/sys/ONOSENDAI amd64 CPU: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (2094.80-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3927597056 (3745 MB) Event timer "LAPIC" frequency 0 Hz quality 500 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 hpet0: [FILTER] Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xf2400000-0xf27fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: mem 0xf2100000-0xf21fffff at device 2.1 on pci0 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1860-0x187f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xf2a04800-0xf2a04bff irq 19 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf2a00000-0xf2a03fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pci2: at device 0.2 (no driver attached) pci2: at device 0.3 (no driver attached) pci2: at device 0.4 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 pcib3: irq 18 at device 28.2 on pci0 pci4: on pcib3 pcib4: irq 19 at device 28.3 on pci0 pci5: on pcib4 iwn0: mem 0xf2200000-0xf2201fff irq 19 at device 0.0 on pci5 iwn0: MIMO 1T2R, BGS, address xx:xx:xx:xx:xx:xx iwn0: [ITHREAD] iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pcib5: irq 17 at device 28.4 on pci0 pci6: on pcib5 pcib6: irq 16 at device 28.5 on pci0 pci8: on pcib6 re0: port 0x3000-0x30ff mem 0xf2004000-0xf2004fff,0xf2000000-0xf2003fff irq 17 at device 0.0 on pci8 re0: Using 1 MSI messages re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: xx:xx:xx:xx:xx:xx re0: [FILTER] uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x18a0-0x18bf irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] usbus6: on uhci5 ehci1: mem 0xf2a04c00-0xf2a04fff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib7: at device 30.0 on pci0 pci9: on pcib7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1818-0x181f,0x180c-0x180f,0x1810-0x1817,0x1808-0x180b,0x18e0-0x18ff mem 0xf2a04000-0xf2a047ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.20 controller with 4 3Gbps ports, PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ichsmb0: port 0x1c00-0x1c1f irq 19 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [FILTER] Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Synaptics Touchpad, device ID 0 acpi_ibm0: on acpi0 orm0: at iomem 0xe0000-0xe1fff,0xe2000-0xe37ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 Starting kernel event timers: LAPIC @ 1000Hz, HPET @ 127Hz Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ad4: 476940MB at ata2-master UDMA100 SATA 3Gb/s ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 GEOM: ad4: partition 1 does not start on a track boundary. GEOM: ad4: partition 1 does not end on a track boundary. acd0: DVDR at ata3-master UDMA33 SATA 1.5Gb/s hdac0: HDA Codec #0: Realtek ALC269 hdac0: HDA Codec #3: Intel G45 HDMI pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 3 nid 1 on hdac0 SMP: AP CPU #1 Launched! GEOM_JOURNAL: Journal 4173665370: ad4s2e contains journal. GEOM_JOURNAL: Journal 2133010362: ad4s2f contains journal. GEOM_JOURNAL: Journal 2133010362: ad4s2g contains data. GEOM_JOURNAL: Journal 4173665370: ad4s3a contains data. GEOM_JOURNAL: Journal ad4s2g consistent. GEOM_JOURNAL: Journal ad4s3a consistent. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ad4s3a.journal WARNING: / was not properly dismounted acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata3:0:0:0): CAM status: SCSI Status Error (probe0:ata3:0:0:0): SCSI status: Check Condition (probe0:ata3:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) cd0 at ata3 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed vboxdrv: fAsync=0 offMin=0x2d4 offMax=0x1179 vboxnet0: Ethernet address: xx:xx:xx:xx:xx:xx drm0: [ITHREAD] wlan0: Ethernet address: xx:xx:xx:xx:xx:xx Sysctl hw.acpi: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: NONE hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.acline: 0 hw.acpi.battery.life: 55 hw.acpi.battery.time: 87 hw.acpi.battery.state: 1 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 40.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 105.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 2 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 100 From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 02:28:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6623C10656A3; Tue, 24 Aug 2010 02:28:20 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 307368FC1D; Tue, 24 Aug 2010 02:28:20 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id BB5566143; Mon, 23 Aug 2010 22:28:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1282616899; bh=QuJhnOG3adPp/X1+DM8Oe7Hwj9Goqk77hgH5w3eUOe8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=M3E1UZp4TGrV3j3trnC4lk9khI7jb12RAZYQ7rdAdPIpiGbguOEv05auCF6jjHsw/ C/VxKGCCFvOORUfuS1B43X086VAMBR9d/m7pJH3Hc/jwjO8MVyIUWB4Ffn/vJIT DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=OHCRJ5zmXpH5l04yWl/50wFjClgc2ngCxO+HtnffveAH/WuPpT3Rv6UJ01lWURwej Ec5P/nO5XwWOda6XWk0j5VuRUFTG/b0Siclz3ij6TWXeGVEzKqIUBwMSP9sJOJt Message-ID: <4C732E3B.7050005@protected-networks.net> Date: Mon, 23 Aug 2010 22:28:11 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Matt References: <4C732522.1010400@gmail.com> In-Reply-To: <4C732522.1010400@gmail.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Sleep/Lenovo SL410 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 02:28:20 -0000 On 08/23/10 21:49, Matt wrote: > Please note atrtc0 error in dmesg? [ .. ] > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: [FILTER] I get this on a Toshiba A105 but it doesn't seem to hurt anything, imb From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 02:54:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E95C106567A; Tue, 24 Aug 2010 02:54:47 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 353368FC12; Tue, 24 Aug 2010 02:54:47 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id C22636143; Mon, 23 Aug 2010 22:54:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1282618486; bh=teFNRlfSQqlboReRVIpR8eymQ8HivXCdnIqfEYspzRY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nkLqSPR5YJwSmGoE5pZNDAATMCX169DyblGNbmnht0317SGMqLp0fu0dUmhYxUnpM olH+Y084PO+Vcrfa4CM1XRBabNIeahHsMq8H9y7daVv0ug76XZ/jV0bDfGAjOI3 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=bHsu0RRf/Wv3FEriC3pEDqWYg+iHdipUDefyikKEaPOmKJiEphTvQHdXVGgkogvGZ X9EPDjACBAp5Mlia3AkfCMJRF1xenaIj+YvNeZoH1Ydq7GJZhJFILChsatrIY+K Message-ID: <4C733471.3000202@protected-networks.net> Date: Mon, 23 Aug 2010 22:54:41 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Kostik Belousov References: <4C7011B9.4020902@protected-networks.net> <20100822132104.GA7300@x2.osted.lan> <20100823211257.GI2396@deviant.kiev.zoral.com.ua> In-Reply-To: <20100823211257.GI2396@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Peter Holm , Jeff Roberson , current@freebsd.org Subject: Re: softupdate with journal panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 02:54:47 -0000 On 08/23/10 17:12, Kostik Belousov wrote: > On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote: >> On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote: >>> While updating sysutils/coreutils port on -current as of this morning >>> (SVN r211550), I noted a panic during the directory rename config test. >>> >> >> Your problem seems identical to this report: >> >> http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC >> > I believe that dotdotremref in this case is legitimately NULL. With this > assumption, the following patch would help. Confirmed - with the patch below, it works as expected; thanks! imb > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index b666c0f..65e5255 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref, dotdotremref) > mkdir->md_jaddref = NULL; > if (mkdir->md_state & MKDIR_PARENT) { > if (cancel_jaddref(jaddref, NULL, > - &dirrem->dm_jwork) == 0) { > + &dirrem->dm_jwork) == 0 && > + dotdotremref != NULL) { > free_jremref(dotdotremref); > dotdotremref = NULL; > } From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 05:31:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CDA11065675 for ; Tue, 24 Aug 2010 05:31:22 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 013D58FC12 for ; Tue, 24 Aug 2010 05:31:21 +0000 (UTC) Received: (qmail 61341 invoked from network); 24 Aug 2010 05:31:20 -0000 Received: from 93.166.52.54 (HELO x2.osted.lan) (93.166.52.54) by relay03.pair.com with SMTP; 24 Aug 2010 05:31:20 -0000 X-pair-Authenticated: 93.166.52.54 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.3/8.14.3) with ESMTP id o7O5VJhE056964; Tue, 24 Aug 2010 07:31:19 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.3/8.14.3/Submit) id o7O5VI0X056963; Tue, 24 Aug 2010 07:31:18 +0200 (CEST) (envelope-from pho) Date: Tue, 24 Aug 2010 07:31:17 +0200 From: Peter Holm To: Kostik Belousov Message-ID: <20100824053117.GA56917@x2.osted.lan> References: <4C7011B9.4020902@protected-networks.net> <20100822132104.GA7300@x2.osted.lan> <20100823211257.GI2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100823211257.GI2396@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: Michael Butler , Jeff Roberson , current@freebsd.org Subject: Re: softupdate with journal panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 05:31:22 -0000 On Tue, Aug 24, 2010 at 12:12:57AM +0300, Kostik Belousov wrote: > On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote: > > On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote: > > > While updating sysutils/coreutils port on -current as of this morning > > > (SVN r211550), I noted a panic during the directory rename config test. > > > > > > > Your problem seems identical to this report: > > > > http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC > > > I believe that dotdotremref in this case is legitimately NULL. With this > assumption, the following patch would help. > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index b666c0f..65e5255 100644 > --- a/sys/ufs/ffs/ffs_softdep.c Yes, works for me. - Peter From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 10:17:58 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C5FB10656AA for ; Tue, 24 Aug 2010 10:17:58 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [IPv6:2a01:4f8:100:1043::2]) by mx1.freebsd.org (Postfix) with ESMTP id C9F928FC12 for ; Tue, 24 Aug 2010 10:17:57 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id D5F01B77CE for ; Tue, 24 Aug 2010 12:17:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eOdEaqnH7Fys for ; Tue, 24 Aug 2010 12:17:55 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 06575B77BF for ; Tue, 24 Aug 2010 12:17:54 +0200 (CEST) Message-ID: <4C739C55.3020800@FreeBSD.org> Date: Tue, 24 Aug 2010 12:17:57 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: Subject: [CFT] ZFS ACL and rrwlock speedup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 10:17:58 -0000 Dear FreeBSD community, in my last CFT I presented a patch that improves ZFS write speed. There have been easily portable improvements on the read side in OpenSolaris, too. Of course, the improvement here is by far not that dramatic as in the zfs_metaslab.patch, but OpenSolaris developers claim this also improves the speed of stat() calls. I would like to Call For Testing for the following patch (9-CURRENT): http://people.freebsd.org/~mm/patches/zfs/zfs_abe_stat_rrwlock.patch This patch adds the following: - better ACL caching and speedup of the ACL permission checks - lowered mutex contention in the read/writer lock (rrwlock) - several bugfixes This patch does not interfere with the zfs_metaslab.patch To apply the patch against 8-STABLE, you need to apply the v15 update first: http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch The patch imports the following OpenSolaris onnv revisions: 9749 (without zlook), 9866, 9981, 10143, 10232, 10295, 10250, 10269 And covers the following OpenSolaris Bug IDs: 6802734 Support for Access Based Enumeration (not used on FreeBSD) 6844861 inconsistent xattr readdir behavior with too-small buffer 6848431 zfs with rstchown=0 or file_chown_self privilege allows user to "take" ownership 6775100 stat() performance on files on zfs should be improved 6827779 rrwlock is overly protective of its counters 6857433 memory leaks found at: zfs_acl_alloc/zfs_acl_node_alloc 6860318 truncate() on zfsroot succeeds when file has a component of its path set without access permission 6865875 zfs sometimes incorrectly giving search access to a dir 6870564 panic in zfs_getsecattr 6867395 zpool_upgrade_007_pos testcase panic'd with BAD TRAP: type=e (#pf Page fault) 6868276 zfs_rezget() can be hazardous when znode has a cached ACL Cheers, mm From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 10:53:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1753A1065697 for ; Tue, 24 Aug 2010 10:53:43 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from s2m-is-001.service2media.com (rev-132-102.virtu.nl [217.114.102.132]) by mx1.freebsd.org (Postfix) with ESMTP id AD5BD8FC12 for ; Tue, 24 Aug 2010 10:53:42 +0000 (UTC) Received: from pieter-dev.localnet ([10.0.1.91] RDNS failed) by s2m-is-001.service2media.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 12:41:37 +0200 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Tue, 24 Aug 2010 12:41:37 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201008241241.37317.pieter@degoeje.nl> X-OriginalArrivalTime: 24 Aug 2010 10:41:37.0656 (UTC) FILETIME=[EDE55F80:01CB4378] Subject: make installworld fails; tzsetup missing -C option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 10:53:43 -0000 I'm trying to do a remote upgrade of a machine by mounting it's root filesystem on /mnt using nfs. The build machine runs a recent 8-STABLE. The target runs 9-CURRENT. make installworld fails with: install -o root -g wheel -m 444 /data/FreeBSD/FreeBSD-current/src/share/zoneinfo/../../contrib/tzdata//zone.tab /mnt/usr/share/zoneinfo/ Updating /etc/localtime tzsetup: illegal option -- C usage: tzsetup [-ns] *** Error code 1 Build script does the equivalent of this: $ mount target:/ /mnt $ cd /FreeBSD/FreeBSD-current/src $ make -j4 buildworld && make -j4 buildkernel $ setenv DESTDIR /mnt $ make installkernel $ setenv NO_FSCHG 1 $ make installworld uname on the build machine: FreeBSD 8.1-STABLE #1: Tue Aug 10 13:09:59 CEST 2010 - Pieter From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 11:31:46 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1831065695; Tue, 24 Aug 2010 11:31:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C4F518FC0C; Tue, 24 Aug 2010 11:31:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7OBVi62063789; Tue, 24 Aug 2010 07:31:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7OBViPl063782; Tue, 24 Aug 2010 11:31:44 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 11:31:44 GMT Message-Id: <201008241131.o7OBViPl063782@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 11:31:46 -0000 TB --- 2010-08-24 11:15:42 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 11:15:42 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-24 11:15:42 - cleaning the object tree TB --- 2010-08-24 11:16:35 - cvsupping the source tree TB --- 2010-08-24 11:16:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-24 11:17:08 - building world TB --- 2010-08-24 11:17:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 11:17:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 11:17:08 - TARGET=powerpc TB --- 2010-08-24 11:17:08 - TARGET_ARCH=powerpc64 TB --- 2010-08-24 11:17:08 - TZ=UTC TB --- 2010-08-24 11:17:08 - __MAKE_CONF=/dev/null TB --- 2010-08-24 11:17:08 - cd /src TB --- 2010-08-24 11:17:08 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 11:17:09 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc1: warnings being treated as errors /src/lib/libc/powerpc/gen/makecontext.c: In function '__makecontext': /src/lib/libc/powerpc/gen/makecontext.c:83: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:83: warning: cast to pointer from integer of different size /src/lib/libc/powerpc/gen/makecontext.c:116: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:117: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:118: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:119: warning: cast from pointer to integer of different size *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 11:31:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 11:31:44 - ERROR: failed to build world TB --- 2010-08-24 11:31:44 - 612.48 user 213.71 system 961.90 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 12:28:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 178B51065695; Tue, 24 Aug 2010 12:28:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D555B8FC25; Tue, 24 Aug 2010 12:28:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7OCSE6x099086; Tue, 24 Aug 2010 08:28:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7OCSE05099085; Tue, 24 Aug 2010 12:28:14 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 12:28:14 GMT Message-Id: <201008241228.o7OCSE05099085@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 12:28:15 -0000 TB --- 2010-08-24 10:54:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 10:54:47 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-08-24 10:54:47 - cleaning the object tree TB --- 2010-08-24 10:55:14 - cvsupping the source tree TB --- 2010-08-24 10:55:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-08-24 10:55:53 - building world TB --- 2010-08-24 10:55:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 10:55:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 10:55:53 - TARGET=powerpc TB --- 2010-08-24 10:55:53 - TARGET_ARCH=powerpc TB --- 2010-08-24 10:55:53 - TZ=UTC TB --- 2010-08-24 10:55:53 - __MAKE_CONF=/dev/null TB --- 2010-08-24 10:55:53 - cd /src TB --- 2010-08-24 10:55:53 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 10:55:54 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/load_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/reloc_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/dev_net.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/interp_forth.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../ofw/common/main.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -nostdlib -static -T /src/sys/boot/powerpc/ofw/ldscript.powerpc -o loader conf.o metadata.o vers.o start.o ucmpdi2.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o reloc_elf32.o dev_net.o interp_forth.o main.o /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ficl/libficl.a /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ofw/libofw/libofw.a -lstand /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ofw/libofw/libofw.a(ppc64_elf_freebsd.o)(.text+0xd8): In function `ppc64_ofw_elf_loadfile': : undefined reference to `elf64_loadfile' *** Error code 1 Stop in /src/sys/boot/powerpc/ofw. *** Error code 1 Stop in /src/sys/boot/powerpc. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 12:28:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 12:28:13 - ERROR: failed to build world TB --- 2010-08-24 12:28:13 - 4141.86 user 992.57 system 5606.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 15:49:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB71106567A; Tue, 24 Aug 2010 15:49:08 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 051CE8FC19; Tue, 24 Aug 2010 15:49:07 +0000 (UTC) Received: by eyx24 with SMTP id 24so3507254eyx.13 for ; Tue, 24 Aug 2010 08:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=W4VhxRii+ldf85XWAfqS45vZpxF0rEQwhxMdAxQt8fA=; b=P2wcLn6EscnOLNjNG/yK4z7Jz0fAFtDOaA+Az1tyhlWaYTwTN9FCL5qXzf2/ifyKE3 HAK13m+nRJjNroUZwFn6fQZk6MHVU4o3DKdeVn/xsNkB3i3RnkBG8CEuQSxRWuRFh4zJ wsd6P9bbsO01V1Vl6PkXH/w1p640PbiAN7Kuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=BdZqACemoIrntDVGop+eO8TBHit2id/UaZSCBPqtZt8RXWURU0HNDLGkstCkt5+jM6 NcVHYQ7c3bevI71Ne4QLGe6EL9rCrjl7f1GqQQ7m3atZtA2mN87dRpldPVhe9oSxZgx0 g/iDyZ1ynIkwl5O105Pe/sVyJGdxxqXHZp5a8= Received: by 10.216.90.8 with SMTP id d8mr4103444wef.89.1282663558252; Tue, 24 Aug 2010 08:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.156.3 with HTTP; Tue, 24 Aug 2010 08:25:37 -0700 (PDT) In-Reply-To: <20100823211257.GI2396@deviant.kiev.zoral.com.ua> References: <4C7011B9.4020902@protected-networks.net> <20100822132104.GA7300@x2.osted.lan> <20100823211257.GI2396@deviant.kiev.zoral.com.ua> From: Renato Botelho Date: Tue, 24 Aug 2010 12:25:37 -0300 Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Peter Holm , Michael Butler , Jeff Roberson , current@freebsd.org Subject: Re: softupdate with journal panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 15:49:08 -0000 On Mon, Aug 23, 2010 at 6:12 PM, Kostik Belousov wrot= e: > > On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote: > > On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote: > > > While updating sysutils/coreutils port on -current as of this morning > > > (SVN r211550), I noted a panic during the directory rename config tes= t. > > > > > > > Your problem seems identical to this report: > > > > http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E= 8jVHWPU5mC > > > I believe that dotdotremref in this case is legitimately NULL. With this > assumption, the following patch would help. > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index b666c0f..65e5255 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref, dotd= otremref) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mkdir->md_jaddref =3D NULL= ; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (mkdir->md_state & MKDI= R_PARENT) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (cancel= _jaddref(jaddref, NULL, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &di= rrem->dm_jwork) =3D=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &di= rrem->dm_jwork) =3D=3D 0 && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dot= dotremref !=3D NULL) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0free_jremref(dotdotremref); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0dotdotremref =3D NULL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} I was having a kernel panic trying to build coreutils, at configure time it make some tests with rename() and system crashed. It was just happening on the box i'm using SUJ. After apply this patch everything went fine. Thanks! -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 15:53:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1E871065695 for ; Tue, 24 Aug 2010 15:53:11 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 777578FC0C for ; Tue, 24 Aug 2010 15:53:11 +0000 (UTC) Received: by fxm4 with SMTP id 4so4474645fxm.13 for ; Tue, 24 Aug 2010 08:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=PyOLAfkUPJIr7kdCztZrxZL9wrctaDMhzmJ/eOEWFik=; b=qn2nGmmKCTlNDcDFFTaxkhbh+C1TlyVC3u81T7zZ9w73SDenGV3dQTe/8iRmO0f4a8 yXBW8FiHrZf2usTef2jx6UkiToxe0fMDUFxagTjFJfTB8z5QcY50W4F28r7rB3yV3HMz S2jKL43uEV6Ry20Ma6wwTbIS5QpLUbWvzKGAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=L5tq+aMsDZdKLMvM+b3qy31eQ0BK2KRvT+Z0KpHTSsURxiFKSzPoLztmQtCV9eHPxs VHQhBHC78UCAcT2PBxUZdvR/ixFg41WsB4HIWbgOfp7GmGVVwwCvF3fsPFhauWDWLQ54 Gwd+qvWIY3EK+5yFTB3GITxImBT85BMmFNB0k= Received: by 10.223.121.147 with SMTP id h19mr6130753far.76.1282665190056; Tue, 24 Aug 2010 08:53:10 -0700 (PDT) Received: from ernst.jennejohn.org (p578E2343.dip.t-dialin.net [87.142.35.67]) by mx.google.com with ESMTPS id b9sm131968faq.31.2010.08.24.08.53.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 08:53:08 -0700 (PDT) Date: Tue, 24 Aug 2010 17:53:07 +0200 From: Gary Jennejohn To: Pieter de Goeje Message-ID: <20100824175307.11952030@ernst.jennejohn.org> In-Reply-To: <201008241241.37317.pieter@degoeje.nl> References: <201008241241.37317.pieter@degoeje.nl> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: make installworld fails; tzsetup missing -C option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 15:53:12 -0000 On Tue, 24 Aug 2010 12:41:37 +0200 Pieter de Goeje wrote: > I'm trying to do a remote upgrade of a machine by mounting > it's root filesystem on /mnt using nfs. The build machine > runs a recent 8-STABLE. The target runs 9-CURRENT. > > make installworld fails with: > > install -o root -g wheel -m 444 /data/FreeBSD/FreeBSD-current/src/share/zoneinfo/../../contrib/tzdata//zone.tab /mnt/usr/share/zoneinfo/ > Updating /etc/localtime > tzsetup: illegal option -- C > usage: tzsetup [-ns] > *** Error code 1 > > Build script does the equivalent of this: > $ mount target:/ /mnt > $ cd /FreeBSD/FreeBSD-current/src > $ make -j4 buildworld && make -j4 buildkernel > $ setenv DESTDIR /mnt > $ make installkernel > $ setenv NO_FSCHG 1 > $ make installworld > > uname on the build machine: > FreeBSD 8.1-STABLE #1: Tue Aug 10 13:09:59 CEST 2010 > You're trying to install 9-CURRENT using 8.1-STABLE binaries, which just won't work in this (tzsetup) case. The -C flag is only set when DESTDIR is set, which might be considered a bug since it prevents cross-compiling and cross-installation using different versions of FreeBSD, like in your case. But I'm not so sure that support for this is guaranteed when going from an older version to a newer version. I suppose you could try a) editing share/zoneinfo/Makefile and deleting the optC code or b) pointing PATH at DESTDIR, if it's already populated. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 18:46:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0B4D10656A7; Tue, 24 Aug 2010 18:46:59 +0000 (UTC) (envelope-from pgollucci@p6m7g8.com) Received: from cell.p6m7g8.net (static-71-178-236-107.washdc.fios.verizon.net [71.178.236.107]) by mx1.freebsd.org (Postfix) with ESMTP id 96E5A8FC19; Tue, 24 Aug 2010 18:46:59 +0000 (UTC) Received: from philip.hq.rws (wsip-174-79-184-239.dc.dc.cox.net [174.79.184.239]) (authenticated bits=0) by cell.p6m7g8.net (8.14.4/8.14.3) with ESMTP id o7OIkrJ4044250 (version=TLSv1/SSLv3 cipher=DHE-DSS-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Aug 2010 18:46:53 GMT (envelope-from pgollucci@p6m7g8.com) Message-ID: <4C74139D.20006@p6m7g8.com> Date: Tue, 24 Aug 2010 18:46:53 +0000 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100607 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Matuska References: <4C739C55.3020800@FreeBSD.org> In-Reply-To: <4C739C55.3020800@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on cell.p6m7g8.net Cc: freebsd-current@freebsd.org Subject: Re: [CFT] ZFS ACL and rrwlock speedup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 18:47:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://people.freebsd.org/~mm/patches/zfs/zfs_metaslab.patch http://people.freebsd.org/~mm/patches/zfs/zfs_abe_stat_rrwlock.patch FreeBSD frieza.p6m7g8.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Tue Aug 24 18:32:38 UTC 2010 root@frieza.p6m7g8.net:/usr/obj/usr/src/sys/FRIEZA amd64 This is my tinderbox, so it should see some big usage in the next few days. Its also an ssd. $ zpool status pool: zroot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 $ zpool upgrade This system is currently running ZFS pool version 15. All pools are formatted using this version. Before patch: (not cached) $ time find /usr/src >/dev/null real 0m2.036s user 0m0.137s sys 0m0.878s After patch: (not cached) $ time find /usr/src >/dev/null real 0m0.593s user 0m0.073s sys 0m0.520s - -- - ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFMdBOcdbiP+9ubjBwRAurDAJ41vtb660rb3/ZoW8JjJl0HX8a3mQCfUh3/ Ebc5CzKTpRn6KZS2orNZtOg= =BM/g -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 22:06:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CE7B1065693 for ; Tue, 24 Aug 2010 22:06:15 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx2.utsp.utwente.nl [130.89.2.13]) by mx1.freebsd.org (Postfix) with ESMTP id B316A8FC14 for ; Tue, 24 Aug 2010 22:06:14 +0000 (UTC) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.160.140]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o7OLlAh2018990; Tue, 24 Aug 2010 23:47:11 +0200 From: Pieter de Goeje To: gljennjohn@googlemail.com Date: Tue, 24 Aug 2010 23:47:14 +0200 User-Agent: KMail/1.9.10 References: <201008241241.37317.pieter@degoeje.nl> <20100824175307.11952030@ernst.jennejohn.org> In-Reply-To: <20100824175307.11952030@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201008242347.14717.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: make installworld fails; tzsetup missing -C option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 22:06:15 -0000 On Tuesday 24 August 2010 17:53:07 Gary Jennejohn wrote: > On Tue, 24 Aug 2010 12:41:37 +0200 > > Pieter de Goeje wrote: > > I'm trying to do a remote upgrade of a machine by mounting > > it's root filesystem on /mnt using nfs. The build machine > > runs a recent 8-STABLE. The target runs 9-CURRENT. > > > > make installworld fails with: > > > > install -o root -g wheel -m 444 > > /data/FreeBSD/FreeBSD-current/src/share/zoneinfo/../../contrib/tzdata//zo > >ne.tab /mnt/usr/share/zoneinfo/ Updating /etc/localtime > > tzsetup: illegal option -- C > > usage: tzsetup [-ns] > > *** Error code 1 > > > > Build script does the equivalent of this: > > $ mount target:/ /mnt > > $ cd /FreeBSD/FreeBSD-current/src > > $ make -j4 buildworld && make -j4 buildkernel > > $ setenv DESTDIR /mnt > > $ make installkernel > > $ setenv NO_FSCHG 1 > > $ make installworld > > > > uname on the build machine: > > FreeBSD 8.1-STABLE #1: Tue Aug 10 13:09:59 CEST 2010 > > You're trying to install 9-CURRENT using 8.1-STABLE binaries, which just > won't work in this (tzsetup) case. > > The -C flag is only set when DESTDIR is set, which might be considered > a bug since it prevents cross-compiling and cross-installation using > different versions of FreeBSD, like in your case. > > But I'm not so sure that support for this is guaranteed when going from > an older version to a newer version. It's a bit of an edge case I agree. A working cross installation is desirable if for example you want to upgrade a machine in place, but have a fallback mechanism by installing everyting on a separate root filesystem first. > > I suppose you could try a) editing share/zoneinfo/Makefile and deleting > the optC code or b) pointing PATH at DESTDIR, if it's already populated. > As I'm not cross compiling, I simply used the tzetup it built to complete the install. I temporarily replaced the 8-STABLE version with the 9-CURRENT version on the build box. I wonder if tzsetup should be a bootstrap tool... -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 22:34:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87CC510656A6; Tue, 24 Aug 2010 22:34:11 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BFB48FC17; Tue, 24 Aug 2010 22:34:11 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o7OMY9kn022269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Aug 2010 15:34:09 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7E0941CC3A; Tue, 24 Aug 2010 15:34:09 -0700 (PDT) To: Doug Barton In-reply-to: Your message of "Mon, 23 Aug 2010 11:56:17 PDT." <4C72C451.4070407@FreeBSD.org> Date: Tue, 24 Aug 2010 15:34:09 -0700 From: "Kevin Oberman" Message-Id: <20100824223409.7E0941CC3A@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-24_12:2010-08-25, 2010-08-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008240165 Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 22:34:11 -0000 > Date: Mon, 23 Aug 2010 11:56:17 -0700 > From: Doug Barton > Sender: owner-freebsd-current@freebsd.org > > On 08/23/2010 05:39, John Baldwin wrote: > > On Sunday, August 22, 2010 11:17:44 pm Doug Barton wrote: > >> Thanks to help from Andriy I've been working on narrowing down the cause > >> of my "runaway intr" problems and we've found some interesting things. > >> First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than > >> C1 things seem to work fine. Using one or the other sort of works, but > >> between the 2 powerd seems to cause the most problems. > > > > I think this just means that when C3 is enabled the system is getting skewed > > results in cp_time[] and so the stats are off. The system isn't actually > > stuck in an interrupt storm of sorts, the numbers reported to top are just > > wrong so it looks like it is. > > That may be true, however what's happening at that time is that the > video and audio both become choppy (as in, painfully so) and every other > thing that's running, whether it's desktop clients like thunderbird or > something being compiled, also moves very very slow, as if it's > resource-starved. So while I'm perfectly ready to admit that the top > output may be just a symptom instead of the real problem, something > fundamentally bad IS happening under the hood. This sounds wrong. C3 should only be entered when a CPU is halted for an extended time. When I am plying a movie, I never see C3, but I am using an old uniprocessor on my T43. I would believe that dropping to C3 could be detrimental to playing video as it takes quite a few clock cycles for the system to climb out of C3 and start doing real work again. Things that come to mind...does the player move between CPUs while this is going on? Does ULE take processor ACPI state into account when scheduling? Can you try locking the player to a single CPU with cpuset(1) so it does not move around? Try different CPUs. Some are more equal than others, at least in my network performance testing using FreeBSD and I have been unable to figure out, other than empirically, which ons(s) work best. just some random thoughts from an un-air conditioned office on a very hot afternoon in Berzerkley. I may simply be delirious. :-) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 02:23:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C5A51065670; Wed, 25 Aug 2010 02:23:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 56AA78FC18; Wed, 25 Aug 2010 02:23:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7P2Nc80022900; Tue, 24 Aug 2010 22:23:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7P2NcGv022895; Wed, 25 Aug 2010 02:23:38 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Aug 2010 02:23:38 GMT Message-Id: <201008250223.o7P2NcGv022895@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 02:23:39 -0000 TB --- 2010-08-25 00:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-25 00:15:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-08-25 00:15:00 - cleaning the object tree TB --- 2010-08-25 00:16:08 - cvsupping the source tree TB --- 2010-08-25 00:16:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-08-25 00:16:43 - building world TB --- 2010-08-25 00:16:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 00:16:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 00:16:43 - TARGET=pc98 TB --- 2010-08-25 00:16:43 - TARGET_ARCH=i386 TB --- 2010-08-25 00:16:43 - TZ=UTC TB --- 2010-08-25 00:16:43 - __MAKE_CONF=/dev/null TB --- 2010-08-25 00:16:43 - cd /src TB --- 2010-08-25 00:16:43 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 25 00:16:44 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Aug 25 02:06:21 UTC 2010 TB --- 2010-08-25 02:06:21 - generating LINT kernel config TB --- 2010-08-25 02:06:21 - cd /src/sys/pc98/conf TB --- 2010-08-25 02:06:21 - /usr/bin/make -B LINT TB --- 2010-08-25 02:06:21 - building LINT kernel TB --- 2010-08-25 02:06:21 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 02:06:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 02:06:21 - TARGET=pc98 TB --- 2010-08-25 02:06:21 - TARGET_ARCH=i386 TB --- 2010-08-25 02:06:21 - TZ=UTC TB --- 2010-08-25 02:06:21 - __MAKE_CONF=/dev/null TB --- 2010-08-25 02:06:21 - cd /src TB --- 2010-08-25 02:06:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 25 02:06:21 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c: In function 'fasttrap_enable_callbacks': /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: 'dtrace_pid_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: (Each undeclared identifier is reported only once /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: for each function it appears in.) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:919: error: 'dtrace_return_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c: In function 'fasttrap_disable_callbacks': /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:949: error: 'dtrace_pid_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:950: error: 'dtrace_return_probe_ptr' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/modules/dtrace/fasttrap. *** Error code 1 Stop in /src/sys/modules/dtrace. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-25 02:23:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-25 02:23:38 - ERROR: failed to build lint kernel TB --- 2010-08-25 02:23:38 - 5603.98 user 1329.98 system 7718.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 02:32:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A35E11065693; Wed, 25 Aug 2010 02:32:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 714778FC13; Wed, 25 Aug 2010 02:32:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7P2W5Ua082287; Tue, 24 Aug 2010 22:32:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7P2W5l4082285; Wed, 25 Aug 2010 02:32:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Aug 2010 02:32:05 GMT Message-Id: <201008250232.o7P2W5l4082285@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 02:32:06 -0000 TB --- 2010-08-25 00:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-25 00:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-08-25 00:15:00 - cleaning the object tree TB --- 2010-08-25 00:16:10 - cvsupping the source tree TB --- 2010-08-25 00:16:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-08-25 00:21:57 - building world TB --- 2010-08-25 00:21:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 00:21:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 00:21:57 - TARGET=i386 TB --- 2010-08-25 00:21:57 - TARGET_ARCH=i386 TB --- 2010-08-25 00:21:57 - TZ=UTC TB --- 2010-08-25 00:21:57 - __MAKE_CONF=/dev/null TB --- 2010-08-25 00:21:57 - cd /src TB --- 2010-08-25 00:21:57 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 25 00:21:58 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Aug 25 02:11:53 UTC 2010 TB --- 2010-08-25 02:11:53 - generating LINT kernel config TB --- 2010-08-25 02:11:53 - cd /src/sys/i386/conf TB --- 2010-08-25 02:11:53 - /usr/bin/make -B LINT TB --- 2010-08-25 02:11:53 - building LINT kernel TB --- 2010-08-25 02:11:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 02:11:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 02:11:53 - TARGET=i386 TB --- 2010-08-25 02:11:53 - TARGET_ARCH=i386 TB --- 2010-08-25 02:11:53 - TZ=UTC TB --- 2010-08-25 02:11:53 - __MAKE_CONF=/dev/null TB --- 2010-08-25 02:11:53 - cd /src TB --- 2010-08-25 02:11:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 25 02:11:53 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c: In function 'fasttrap_enable_callbacks': /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: 'dtrace_pid_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: (Each undeclared identifier is reported only once /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: for each function it appears in.) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:919: error: 'dtrace_return_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c: In function 'fasttrap_disable_callbacks': /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:949: error: 'dtrace_pid_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:950: error: 'dtrace_return_probe_ptr' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/modules/dtrace/fasttrap. *** Error code 1 Stop in /src/sys/modules/dtrace. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-25 02:32:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-25 02:32:05 - ERROR: failed to build lint kernel TB --- 2010-08-25 02:32:05 - 5781.38 user 1337.44 system 8225.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 03:01:46 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44927106564A; Wed, 25 Aug 2010 03:01:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1268FC08; Wed, 25 Aug 2010 03:01:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7P31jhU004480; Tue, 24 Aug 2010 23:01:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7P31jf5004475; Wed, 25 Aug 2010 03:01:45 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Aug 2010 03:01:45 GMT Message-Id: <201008250301.o7P31jf5004475@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 03:01:46 -0000 TB --- 2010-08-25 00:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-25 00:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-08-25 00:15:00 - cleaning the object tree TB --- 2010-08-25 00:16:23 - cvsupping the source tree TB --- 2010-08-25 00:16:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-08-25 00:22:11 - building world TB --- 2010-08-25 00:22:11 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 00:22:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 00:22:11 - TARGET=amd64 TB --- 2010-08-25 00:22:11 - TARGET_ARCH=amd64 TB --- 2010-08-25 00:22:11 - TZ=UTC TB --- 2010-08-25 00:22:11 - __MAKE_CONF=/dev/null TB --- 2010-08-25 00:22:11 - cd /src TB --- 2010-08-25 00:22:11 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 25 00:22:11 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Aug 25 02:43:09 UTC 2010 TB --- 2010-08-25 02:43:09 - generating LINT kernel config TB --- 2010-08-25 02:43:09 - cd /src/sys/amd64/conf TB --- 2010-08-25 02:43:09 - /usr/bin/make -B LINT TB --- 2010-08-25 02:43:09 - building LINT kernel TB --- 2010-08-25 02:43:09 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 02:43:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 02:43:09 - TARGET=amd64 TB --- 2010-08-25 02:43:09 - TARGET_ARCH=amd64 TB --- 2010-08-25 02:43:09 - TZ=UTC TB --- 2010-08-25 02:43:09 - __MAKE_CONF=/dev/null TB --- 2010-08-25 02:43:09 - cd /src TB --- 2010-08-25 02:43:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 25 02:43:09 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c: In function 'fasttrap_enable_callbacks': /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: 'dtrace_pid_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: (Each undeclared identifier is reported only once /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:918: error: for each function it appears in.) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:919: error: 'dtrace_return_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c: In function 'fasttrap_disable_callbacks': /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:949: error: 'dtrace_pid_probe_ptr' undeclared (first use in this function) /src/sys/modules/dtrace/fasttrap/../../../cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c:950: error: 'dtrace_return_probe_ptr' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/modules/dtrace/fasttrap. *** Error code 1 Stop in /src/sys/modules/dtrace. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-25 03:01:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-25 03:01:44 - ERROR: failed to build lint kernel TB --- 2010-08-25 03:01:44 - 6938.20 user 1710.35 system 10004.86 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 03:16:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 539441065674; Wed, 25 Aug 2010 03:16:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E6D2F8FC16; Wed, 25 Aug 2010 03:16:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7P3GsCs090672; Tue, 24 Aug 2010 23:16:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7P3Gs3E090671; Wed, 25 Aug 2010 03:16:54 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Aug 2010 03:16:54 GMT Message-Id: <201008250316.o7P3Gs3E090671@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 03:16:55 -0000 TB --- 2010-08-25 03:01:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-25 03:01:45 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-25 03:01:45 - cleaning the object tree TB --- 2010-08-25 03:01:54 - cvsupping the source tree TB --- 2010-08-25 03:01:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-25 03:02:24 - building world TB --- 2010-08-25 03:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 03:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 03:02:24 - TARGET=powerpc TB --- 2010-08-25 03:02:24 - TARGET_ARCH=powerpc64 TB --- 2010-08-25 03:02:24 - TZ=UTC TB --- 2010-08-25 03:02:24 - __MAKE_CONF=/dev/null TB --- 2010-08-25 03:02:24 - cd /src TB --- 2010-08-25 03:02:24 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 25 03:02:24 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc1: warnings being treated as errors /src/lib/libc/powerpc/gen/makecontext.c: In function '__makecontext': /src/lib/libc/powerpc/gen/makecontext.c:83: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:83: warning: cast to pointer from integer of different size /src/lib/libc/powerpc/gen/makecontext.c:116: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:117: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:118: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:119: warning: cast from pointer to integer of different size *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-25 03:16:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-25 03:16:54 - ERROR: failed to build world TB --- 2010-08-25 03:16:54 - 613.43 user 178.47 system 908.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 03:27:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9AE51065697 for ; Wed, 25 Aug 2010 03:27:32 +0000 (UTC) (envelope-from danilobaio@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 80B5D8FC0C for ; Wed, 25 Aug 2010 03:27:32 +0000 (UTC) Received: by iwn36 with SMTP id 36so214077iwn.13 for ; Tue, 24 Aug 2010 20:27:31 -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=mi8+u7mRYMcOs0zXu0WK93aj/pwblJc07FBgvy9R8tw=; b=MYu+h1HefvaruhG/PHBA3I6GiKhMwvCLHFh1hcAU6SITtsgJcb7g58E/HPZm2QE2Dc e4zPeAFOLTWTeco7E6I2PD5W23J+osPQ18Zl0PyNVUF94QOZMqyG1+Sm998mMmLSNX9U fmTuDc91Kh9LgLutbo3SWTr/EFBgAQvr0pSRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xA8XP8RRB0icc5RucBQVaPoKMuGQXeP3KxUG+73oS4v0D/jTzInr5GYDdKI5JuIT/9 SvpzOR7YZfz2Daoweq9Nonh1SWfoeQ3jG8ywB2L58OL3BD39J9efnZBppLlF14HRGAL0 CV/LOrLBCiSbI3Fs9uDFndTOLUu+MLzBRenYw= MIME-Version: 1.0 Received: by 10.231.182.201 with SMTP id cd9mr9662163ibb.21.1282705023767; Tue, 24 Aug 2010 19:57:03 -0700 (PDT) Received: by 10.231.168.213 with HTTP; Tue, 24 Aug 2010 19:57:03 -0700 (PDT) Date: Tue, 24 Aug 2010 23:57:03 -0300 Message-ID: From: Danilo Baio To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: mfi and Dell PERC 6/i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 03:27:32 -0000 Hi guys, I have a DELL PERC 6/i controller and I can't find the problem. The system was running and lost disk access with this messages on console: "mfi0: COMMAND 0xffffff80005d1770 TIMEOUT AFTER 6178 SECONDS" ... http://img806.imageshack.us/img806/2300/errorr6102.png I can't log in, after a reboot, nothing on the logs. only shows this on boot: Aug 24 23:04:58 bazinga kernel: mfi0: 2806 (335999491s/0x0020/DEAD) - Fatal firmware error: Line 156 in ../../raid/1078int.c What can I do to find the problem ? This controller is really supported by mfi ? Thanks for the help. bazinga# mfiutil show volumes mfi0 Volumes: Id Size Level Stripe State Cache Name mfid0 ( 465G) RAID-1 64K OPTIMAL Disabled mfid1 ( 272G) RAID-10 64K OPTIMAL Disabled bazinga# mfiutil show drives mfi0 Physical Drives: ( 137G) ONLINE SAS enclosure 1= , slot 0 ( 137G) ONLINE SAS enclosure 1= , slot 1 ( 137G) ONLINE SAS enclosure 1= , slot 2 ( 137G) ONLINE SAS enclosure 1= , slot 3 ( 466G) ONLINE SAS enclosure 1= , slot 4 ( 466G) ONLINE SAS enclosure 1= , slot 5 bazinga# mfiutil show firmware mfi0 Firmware Package Version: 6.2.0-0013 mfi0 Firmware Images: Name Version Date Time Status APP 1.22.02-0612 Mar 30 2009 14:41:22 active BIOS 2.04.00 active BCON 1.1-46-e_15-Rel Mar 2 2008 14:06:08 active CTLR 1.02-015B Jan 27 2009 12:02:58 active PCLI 01.00-023:#%00006 Nov 25 2008 17:21:50 active BTBL 1.00.00.01-0011 Nov 27 2007 18:29:20 active I am running 8.1-RELEASE amd64 with DELL R610. This is all messages from boot that shows "mfi0" Aug 24 23:04:58 bazinga kernel: mfi0: port 0xfc00-0xfcff mem 0xdf180000-0xdf1bffff,0xdf1c0000-0xdf1fffff irq 16 at device 0.0 on pci3 Aug 24 23:04:58 bazinga kernel: mfi0: Megaraid SAS driver Ver 3.00 Aug 24 23:04:58 bazinga kernel: mfi0: 2708 (335880663s/0x0020/info) - Shutdown command received from host Aug 24 23:04:58 bazinga kernel: mfi0: 2709 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/1f0c/1028) Aug 24 23:04:58 bazinga kernel: mfi0: 2710 (boot + 3s/0x0020/info) - Firmware version 1.22.02-0612 Aug 24 23:04:58 bazinga kernel: mfi0: 2711 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/1f0c/1028) Aug 24 23:04:58 bazinga kernel: mfi0: 2712 (boot + 3s/0x0020/info) - Firmware version 1.22.02-0612 Aug 24 23:04:58 bazinga kernel: mfi0: 2713 (boot + 23s/0x0008/info) - Battery Present Aug 24 23:04:58 bazinga kernel: mfi0: 2714 (boot + 23s/0x0020/info) - Controller hardware revision ID (0x0) Aug 24 23:04:58 bazinga kernel: mfi0: 2715 (boot + 23s/0x0020/info) - Package version 6.2.0-0013 Aug 24 23:04:58 bazinga kernel: mfi0: 2716 (boot + 23s/0x0020/info) - Board Revision Aug 24 23:04:58 bazinga kernel: mfi0: 2717 (boot + 49s/0x0002/info) - Unexpected sense: Encl PD 20 Path 5a4ba0b032c08400, CDB: 12 00 00 00 04 00, Sense: 6/29/00 Aug 24 23:04:58 bazinga kernel: mfi0: 2718 (boot + 50s/0x0004/info) - Enclosure PD 20(c None/p0) communication restored Aug 24 23:04:58 bazinga kernel: mfi0: 2719 (boot + 50s/0x0004/info) - Enclosure PD 20(c None/p0) element (SES code 0x17) status changed Aug 24 23:04:58 bazinga kernel: mfi0: 2720 (boot + 50s/0x0004/info) - Enclosure PD 20(c None/p0) element (SES code 0x17) status changed Aug 24 23:04:58 bazinga kernel: mfi0: 2721 (boot + 50s/0x0004/info) - Enclosure PD 20(c None/p0) element (SES code 0x17) status changed Aug 24 23:04:58 bazinga kernel: mfi0: 2722 (boot + 50s/0x0004/info) - Enclosure PD 20(c None/p0) element (SES code 0x17) status changed Aug 24 23:04:58 bazinga kernel: mfi0: 2723 (boot + 50s/0x0004/info) - Enclosure PD 20(c None/p0) element (SES code 0x17) status changed Aug 24 23:04:58 bazinga kernel: mfi0: 2724 (boot + 50s/0x0004/info) - Enclosure PD 20(c None/p0) element (SES code 0x17) status changed Aug 24 23:04:58 bazinga kernel: mfi0: 2725 (boot + 50s/0x0002/info) - Inserted: Encl PD 20 Aug 24 23:04:58 bazinga kernel: mfi0: 2726 (boot + 50s/0x0002/info) - Inserted: PD 20(c None/p0) Info: enclPd=3D20, scsiType=3Dd, portMap=3D09, sasAddr=3D5a4ba0b032c08400,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2727 (boot + 50s/0x0002/info) - Inserted: PD 00(e0x20/s0) Aug 24 23:04:58 bazinga kernel: mfi0: 2728 (boot + 50s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=3D20, scsiType=3D0, portMap=3D00, sasAddr=3D5000c500231e5111,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2729 (boot + 50s/0x0002/info) - Inserted: PD 01(e0x20/s1) Aug 24 23:04:58 bazinga kernel: mfi0: 2730 (boot + 50s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=3D20, scsiType=3D0, portMap=3D01, sasAddr=3D5000c500231e6e4d,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2731 (boot + 50s/0x0002/info) - Inserted: PD 02(e0x20/s2) Aug 24 23:04:58 bazinga kernel: mfi0: 2732 (boot + 50s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=3D20, scsiType=3D0, portMap=3D02, sasAddr=3D5000c500231e5239,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2733 (boot + 50s/0x0002/info) - Inserted: PD 03(e0x20/s3) Aug 24 23:04:58 bazinga kernel: mfi0: 2734 (boot + 50s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: enclPd=3D20, scsiType=3D0, portMap=3D03, sasAddr=3D5000c500231e0b2d,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2735 (boot + 50s/0x0002/info) - Inserted: PD 04(e0x20/s4) Aug 24 23:04:58 bazinga kernel: mfi0: 2736 (boot + 50s/0x0002/info) - Inserted: PD 04(e0x20/s4) Info: enclPd=3D20, scsiType=3D0, portMap=3D04, sasAddr=3D5000c50020c23955,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2737 (boot + 50s/0x0002/info) - Inserted: PD 05(e0x20/s5) Aug 24 23:04:58 bazinga kernel: mfi0: 2738 (boot + 50s/0x0002/info) - Inserted: PD 05(e0x20/s5) Info: enclPd=3D20, scsiType=3D0, portMap=3D05, sasAddr=3D5000c50020c244c9,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2739 (335880741s/0x0020/info) - Time established as 08/23/10 12:12:21; (51 seconds since power on) Aug 24 23:04:58 bazinga kernel: mfi0: 2740 (335880778s/0x0008/info) - Battery temperature is normal Aug 24 23:04:58 bazinga kernel: mfi0: 2741 (335880778s/0x0008/info) - Battery started charging Aug 24 23:04:58 bazinga kernel: mfi0: 2742 (335880778s/0x0008/info) - Current capacity of the battery is above threshold Aug 24 23:04:58 bazinga kernel: mfi0: 2743 (335891243s/0x0008/info) - Battery charge complete Aug 24 23:04:58 bazinga kernel: mfi0: 2744 (335891851s/0x0020/info) - Patro= l Read started Aug 24 23:04:58 bazinga kernel: mfi0: 2805 (335899090s/0x0020/info) - Patro= l Read complete Aug 24 23:04:58 bazinga kernel: mfi0: 2806 (335999491s/0x0020/DEAD) - Fatal firmware error: Line 156 in ../../raid/1078int.c Aug 24 23:04:58 bazinga kernel: Aug 24 23:04:58 bazinga kernel: mfi0: 2807 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/1f0c/1028) Aug 24 23:04:58 bazinga kernel: mfi0: 2808 (boot + 3s/0x0020/info) - Firmware version 1.22.02-0612 Aug 24 23:04:58 bazinga kernel: mfi0: 2809 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/1f0c/1028) Aug 24 23:04:58 bazinga kernel: mfi0: 2810 (boot + 3s/0x0020/info) - Firmware version 1.22.02-0612 Aug 24 23:04:58 bazinga kernel: mfi0: 2811 (boot + 23s/0x0008/info) - Battery Present Aug 24 23:04:58 bazinga kernel: mfi0: 2812 (boot + 23s/0x0020/info) - Controller hardware revision ID (0x0) Aug 24 23:04:58 bazinga kernel: mfi0: 2813 (boot + 23s/0x0020/info) - Package version 6.2.0-0013 Aug 24 23:04:58 bazinga kernel: mfi0: 2814 (boot + 23s/0x0020/info) - Board Revision Aug 24 23:04:58 bazinga kernel: mfi0: 2815 (boot + 62s/0x0002/WARN) - PD 110(e0x00/s16) Path 5a4ba0b032c08400 reset (Type 03) Aug 24 23:04:58 bazinga kernel: mfi0: 2816 (boot + 66s/0x0004/info) - Enclosure PD 20(c None/p0) communication restored Aug 24 23:04:58 bazinga kernel: mfi0: 2817 (boot + 67s/0x0002/info) - Inserted: Encl PD 20 Aug 24 23:04:58 bazinga kernel: mfi0: 2818 (boot + 67s/0x0002/info) - Inserted: PD 20(c None/p0) Info: enclPd=3D20, scsiType=3Dd, portMap=3D09, sasAddr=3D5a4ba0b032c08400,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2819 (boot + 67s/0x0002/info) - Inserted: PD 00(e0x20/s0) Aug 24 23:04:58 bazinga kernel: mfi0: 2820 (boot + 67s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=3D20, scsiType=3D0, portMap=3D00, sasAddr=3D5000c500231e5111,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2821 (boot + 67s/0x0002/info) - Inserted: PD 01(e0x20/s1) Aug 24 23:04:58 bazinga kernel: mfi0: 2822 (boot + 67s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=3D20, scsiType=3D0, portMap=3D01, sasAddr=3D5000c500231e6e4d,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2823 (boot + 67s/0x0002/info) - Inserted: PD 02(e0x20/s2) Aug 24 23:04:58 bazinga kernel: mfi0: 2824 (boot + 67s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=3D20, scsiType=3D0, portMap=3D02, sasAddr=3D5000c500231e5239,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2825 (boot + 67s/0x0002/info) - Inserted: PD 03(e0x20/s3) Aug 24 23:04:58 bazinga kernel: mfi0: 2826 (boot + 67s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: enclPd=3D20, scsiType=3D0, portMap=3D03, sasAddr=3D5000c500231e0b2d,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2827 (boot + 67s/0x0002/info) - Inserted: PD 04(e0x20/s4) Aug 24 23:04:58 bazinga kernel: mfi0: 2828 (boot + 67s/0x0002/info) - Inserted: PD 04(e0x20/s4) Info: enclPd=3D20, scsiType=3D0, portMap=3D04, sasAddr=3D5000c50020c23955,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2829 (boot + 67s/0x0002/info) - Inserted: PD 05(e0x20/s5) Aug 24 23:04:58 bazinga kernel: mfi0: 2830 (boot + 67s/0x0002/info) - Inserted: PD 05(e0x20/s5) Info: enclPd=3D20, scsiType=3D0, portMap=3D05, sasAddr=3D5000c50020c244c9,0000000000000000 Aug 24 23:04:58 bazinga kernel: mfi0: 2831 (336006245s/0x0020/info) - Time established as 08/24/10 23:04:05; (68 seconds since power on) Aug 24 23:04:58 bazinga kernel: mfi0: 2832 (336006265s/0x0008/info) - Battery temperature is normal --=20 Danilo Gon=E7alves Baio (dbaio) danilobaio (*) gmail . com +55 (44) 8801 1257 From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 04:05:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DEAB106564A; Wed, 25 Aug 2010 04:05:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1027B8FC23; Wed, 25 Aug 2010 04:05:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7P45sHH004066; Wed, 25 Aug 2010 00:05:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7P45soi004065; Wed, 25 Aug 2010 04:05:54 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Aug 2010 04:05:54 GMT Message-Id: <201008250405.o7P45soi004065@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 04:05:55 -0000 TB --- 2010-08-25 02:32:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-25 02:32:05 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-08-25 02:32:05 - cleaning the object tree TB --- 2010-08-25 02:32:26 - cvsupping the source tree TB --- 2010-08-25 02:32:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-08-25 02:33:07 - building world TB --- 2010-08-25 02:33:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 02:33:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 02:33:07 - TARGET=powerpc TB --- 2010-08-25 02:33:07 - TARGET_ARCH=powerpc TB --- 2010-08-25 02:33:07 - TZ=UTC TB --- 2010-08-25 02:33:07 - __MAKE_CONF=/dev/null TB --- 2010-08-25 02:33:07 - cd /src TB --- 2010-08-25 02:33:07 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 25 02:33:08 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/load_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/reloc_elf32.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/dev_net.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../common/interp_forth.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -c /src/sys/boot/powerpc/ofw/../../ofw/common/main.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/powerpc/ofw/../../ficl -I/src/sys/boot/powerpc/ofw/../../ficl/powerpc -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/powerpc/ofw/../../common -I/src/sys/boot/powerpc/ofw/../../.. -I. -ffreestanding -msoft-float -DRELOC=0x1C00000 -Wa,-mppc64bridge -I/src/sys/boot/powerpc/ofw/../../ofw/libofw -I/src/sys/boot/powerpc/ofw/../../../../lib/libstand/ -std=gnu99 -nostdlib -static -T /src/sys/boot/powerpc/ofw/ldscript.powerpc -o loader conf.o metadata.o vers.o start.o ucmpdi2.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o reloc_elf32.o dev_net.o interp_forth.o main.o /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ficl/libficl.a /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ofw/libofw/libofw.a -lstand /obj/powerpc.powerpc/src/sys/boot/powerpc/ofw/../../ofw/libofw/libofw.a(ppc64_elf_freebsd.o)(.text+0xd8): In function `ppc64_ofw_elf_loadfile': : undefined reference to `elf64_loadfile' *** Error code 1 Stop in /src/sys/boot/powerpc/ofw. *** Error code 1 Stop in /src/sys/boot/powerpc. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-25 04:05:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-25 04:05:54 - ERROR: failed to build world TB --- 2010-08-25 04:05:54 - 4170.81 user 969.22 system 5628.40 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 04:56:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE3510656AB for ; Wed, 25 Aug 2010 04:56:18 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9528FC16 for ; Wed, 25 Aug 2010 04:56:17 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o7P4uFlm006127; Tue, 24 Aug 2010 22:56:15 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Tue, 24 Aug 2010 22:56:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <34E50FDC-C866-4E13-8391-55503B94EB8B@samsco.org> References: To: Danilo Baio X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-49.4 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD,URIBL_SBL autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: mfi and Dell PERC 6/i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 04:56:18 -0000 On Aug 24, 2010, at 8:57 PM, Danilo Baio wrote: > Hi guys, >=20 > I have a DELL PERC 6/i controller and I can't find the problem. > The system was running and lost disk access with this messages on = console: > "mfi0: COMMAND 0xffffff80005d1770 TIMEOUT AFTER 6178 SECONDS" > ... > http://img806.imageshack.us/img806/2300/errorr6102.png >=20 >=20 > I can't log in, after a reboot, nothing on the logs. >=20 > only shows this on boot: >=20 > Aug 24 23:04:58 bazinga kernel: mfi0: 2806 (335999491s/0x0020/DEAD) - = Fatal > firmware error: Line 156 in ../../raid/1078int.c The firmware on the controller crashed. The best I can suggest is to = look for newer firmware (mfiutil can flash firmware) and to call LSI or = Dell tech-support and report the problem. In the past, there have been = bugs with patrol reads causing crashes under heavy load, so you might = also look at disabling that option. Scott From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 12:31:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEE9F106564A for ; Wed, 25 Aug 2010 12:31:02 +0000 (UTC) (envelope-from danilobaio@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 746B68FC08 for ; Wed, 25 Aug 2010 12:31:02 +0000 (UTC) Received: by iwn36 with SMTP id 36so651268iwn.13 for ; Wed, 25 Aug 2010 05:31:01 -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=CuB7+MhfhyLJWY6K9Vh+eBU5Mu32m0loFsystWB4zVg=; b=iVKaUfLcFt54bGD7waYkKAF62RKRVlDFimp1zxt6lnWFbCjemcRtuq+P+anTzO5WOd OYnwmmBi7WelucNecbStNl3PQ7/C45CWR461E4dgOk+xX4SbCzO2agR+IIA4xO2MZ742 QcOm8MGAHZ6utwvfsfAH6+APmqbs0fvtOnNoM= 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=s60EWgFdqFwnJlzjprlSSo97h/K1sX8GQOQJFKWm7ijn1xgWES4IybD59JV6hrSiXz TfChg8SFNxbJLqkXJKUoQn9Qsw1XBzvY/qpBunaHn9Qz9CWrUu6kPxYLqLYiLXQqhgUf AezhamGYpTX1Tfv06ucZkGrbcyIaVedNtcmm4= MIME-Version: 1.0 Received: by 10.231.33.131 with SMTP id h3mr7359164ibd.148.1282739461793; Wed, 25 Aug 2010 05:31:01 -0700 (PDT) Received: by 10.231.168.213 with HTTP; Wed, 25 Aug 2010 05:31:01 -0700 (PDT) In-Reply-To: <34E50FDC-C866-4E13-8391-55503B94EB8B@samsco.org> References: <34E50FDC-C866-4E13-8391-55503B94EB8B@samsco.org> Date: Wed, 25 Aug 2010 09:31:01 -0300 Message-ID: From: Danilo Baio To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: mfi and Dell PERC 6/i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 12:31:02 -0000 On Wed, Aug 25, 2010 at 1:56 AM, Scott Long wrote: > On Aug 24, 2010, at 8:57 PM, Danilo Baio wrote: > > > Hi guys, > > > > I have a DELL PERC 6/i controller and I can't find the problem. > > The system was running and lost disk access with this messages on > console: > > "mfi0: COMMAND 0xffffff80005d1770 TIMEOUT AFTER 6178 SECONDS" > > ... > > http://img806.imageshack.us/img806/2300/errorr6102.png > > > > > > I can't log in, after a reboot, nothing on the logs. > > > > only shows this on boot: > > > > Aug 24 23:04:58 bazinga kernel: mfi0: 2806 (335999491s/0x0020/DEAD) - > Fatal > > firmware error: Line 156 in ../../raid/1078int.c > > The firmware on the controller crashed. The best I can suggest is to loo= k > for newer firmware (mfiutil can flash firmware) and to call LSI or Dell > tech-support and report the problem. In the past, there have been bugs w= ith > patrol reads causing crashes under heavy load, so you might also look at > disabling that option. > > Scott > > Intersting, patrol read is automatic and before crash show on the logs that patrol read has started. I disabled this feature, rebooted the server and didn't show that firmware error... I will test for some days. Thank you Scott. --=20 Danilo Gon=E7alves Baio (dbaio) danilobaio (*) gmail . com +55 (44) 8801 1257 From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 13:24:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B138710656A4 for ; Wed, 25 Aug 2010 13:24:21 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9298FC1C for ; Wed, 25 Aug 2010 13:24:20 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OoFxh-0004vB-Af; Wed, 25 Aug 2010 15:24:17 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoFxb-0004sM-Vf; Wed, 25 Aug 2010 15:24:12 +0200 Message-Id: To: Danilo Baio From: Ian FREISLICH In-Reply-To: References: <34E50FDC-C866-4E13-8391-55503B94EB8B@samsco.org> X-Attribution: BOFH Date: Wed, 25 Aug 2010 15:24:11 +0200 Cc: freebsd-current@freebsd.org Subject: Re: mfi and Dell PERC 6/i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 13:24:21 -0000 Danilo Baio wrote: > > Scott Long wrote: > > The firmware on the controller crashed. The best I can suggest is to look > > for newer firmware (mfiutil can flash firmware) and to call LSI or Dell > > tech-support and report the problem. In the past, there have been bugs with > > patrol reads causing crashes under heavy load, so you might also look at > > disabling that option. Dell will not be interested unless the adapter is running the most recent firmware. > Intersting, patrol read is automatic and before crash show on the logs that > patrol read has started. > > I disabled this feature, rebooted the server and didn't show that firmware > error... > > I will test for some days. Dell, (maybe) Scott and I recomend that you ensure you're on the latest firmware: [firewall2] ~ # mfiutil -u0 show adapter mfi0 Adapter: Product Name: PERC 6/i Adapter Serial Number: 1122334455667788 Firmware: 6.2.0-0013 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 256M Minimum Stripe: 8K Maximum Stripe: 1M I'm sure there are bugs on this firmware too, but reading the fixes that were made between the version that came on the adapter and this version were Truely Frightening. It's trivial to update the firmware with the mfiutl program. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 13:51:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 331E610656A7 for ; Wed, 25 Aug 2010 13:51:44 +0000 (UTC) (envelope-from danilobaio@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE5B88FC08 for ; Wed, 25 Aug 2010 13:51:43 +0000 (UTC) Received: by ywt2 with SMTP id 2so248123ywt.13 for ; Wed, 25 Aug 2010 06:51:43 -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=7KYxp0WJ8JXUpWqTAanMu7U4OIrTHsZj1Ok7vuBjE4E=; b=i4mTQ6UGaQQQVsB0YQbSQo/5YPocG6IIBMyxflKkpO/pOtNDKFrHBjg3y1T2/O/DiG WqrZ4X2bQRdO2GGFVWq+ypZQ9ml3cStmeAdXL0D6QvIJhtChsplvL/A6SaBpJ8IPTvfi Z5iqmVK6BBPwQT86AJK6o2IZ5Ab6fFJClN7EI= 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=dSVqsbeusKQC/3o3RjgvOxzb+kohBKTn7ZQbGK+wCtyrbgrGzm/HpfSP2Do7rwzoKy NVckLu2v+lgLqkaUe0uB1+oa3vm2UdVSgUHojqIylo/x6b7f2gS/q8UNRLpXvXSRdVBi LSetD1FA2ahylemDQIZZyv9ZQ0OF0LbXg2Syg= MIME-Version: 1.0 Received: by 10.90.36.6 with SMTP id j6mr5526291agj.180.1282744300890; Wed, 25 Aug 2010 06:51:40 -0700 (PDT) Received: by 10.231.168.213 with HTTP; Wed, 25 Aug 2010 06:51:40 -0700 (PDT) In-Reply-To: References: <34E50FDC-C866-4E13-8391-55503B94EB8B@samsco.org> Date: Wed, 25 Aug 2010 10:51:40 -0300 Message-ID: From: Danilo Baio To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: mfi and Dell PERC 6/i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 13:51:44 -0000 On Wed, Aug 25, 2010 at 10:24 AM, Ian FREISLICH wrote: > Danilo Baio wrote: > > > Scott Long wrote: > > > The firmware on the controller crashed. The best I can suggest is to > look > > > for newer firmware (mfiutil can flash firmware) and to call LSI or De= ll > > > tech-support and report the problem. In the past, there have been bu= gs > with > > > patrol reads causing crashes under heavy load, so you might also look > at > > > disabling that option. > > Dell will not be interested unless the adapter is running the most > recent firmware. > > > Intersting, patrol read is automatic and before crash show on the logs > that > > patrol read has started. > > > > I disabled this feature, rebooted the server and didn't show that > firmware > > error... > > > > I will test for some days. > > Dell, (maybe) Scott and I recomend that you ensure you're on the > latest firmware: > > [firewall2] ~ # mfiutil -u0 show adapter > mfi0 Adapter: > Product Name: PERC 6/i Adapter > Serial Number: 1122334455667788 > Firmware: 6.2.0-0013 > RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 > Battery Backup: present > NVRAM: 32K > Onboard Memory: 256M > Minimum Stripe: 8K > Maximum Stripe: 1M > > I'm sure there are bugs on this firmware too, but reading the fixes > that were made between the version that came on the adapter and > this version were Truely Frightening. > > It's trivial to update the firmware with the mfiutl program. > > Ian > > -- > Ian Freislich > Hi Ian, It=B4s already running the last one. bazinga# mfiutil -u0 show adapter mfi0 Adapter: Product Name: PERC 6/i Integrated Serial Number: 1122334455667788 Firmware: 6.2.0-0013 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 256M Minimum Stripe: 8K Maximum Stripe: 1M bazinga# mfiutil -u0 show firmware mfi0 Firmware Package Version: 6.2.0-0013 mfi0 Firmware Images: Name Version Date Time Status APP 1.22.02-0612 Mar 30 2009 14:41:22 active BIOS 2.04.00 active BCON 1.1-46-e_15-Rel Mar 2 2008 14:06:08 active CTLR 1.02-015B Jan 27 2009 12:02:58 active PCLI 01.00-023:#%00006 Nov 25 2008 17:21:50 active BTBL 1.00.00.01-0011 Nov 27 2007 18:29:20 active bazinga# It is the last one that i've found on dell website: http://ftp.us.dell.com/SAS-RAID/R216023.txt This is a firmware release for the Dell PERC 6/i Adapter. Component Current Version Previous Version Package 6.2.0-0013 6.1.1-0047 Firmware 1.22.02-0612 1.21.02-0528 Bootblock 1.00.00.01-0011 1.00.00.01-0011 Ctrl-R 1.02.015B 1.02.014B Thank you... --=20 Danilo Gon=E7alves Baio (dbaio) danilobaio (*) gmail . com +55 (44) 8801 1257 From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 18:29:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D50A10656AB; Wed, 25 Aug 2010 18:29:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0B44D8FC1C; Wed, 25 Aug 2010 18:29:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7PITEdm012284; Wed, 25 Aug 2010 14:29:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7PITEPl012275; Wed, 25 Aug 2010 18:29:14 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Aug 2010 18:29:14 GMT Message-Id: <201008251829.o7PITEPl012275@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 18:29:16 -0000 TB --- 2010-08-25 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-25 16:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-08-25 16:15:00 - cleaning the object tree TB --- 2010-08-25 16:15:50 - cvsupping the source tree TB --- 2010-08-25 16:15:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-08-25 16:21:37 - building world TB --- 2010-08-25 16:21:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 16:21:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 16:21:37 - TARGET=i386 TB --- 2010-08-25 16:21:37 - TARGET_ARCH=i386 TB --- 2010-08-25 16:21:37 - TZ=UTC TB --- 2010-08-25 16:21:37 - __MAKE_CONF=/dev/null TB --- 2010-08-25 16:21:37 - cd /src TB --- 2010-08-25 16:21:37 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 25 16:21:38 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Aug 25 18:12:15 UTC 2010 TB --- 2010-08-25 18:12:15 - generating LINT kernel config TB --- 2010-08-25 18:12:15 - cd /src/sys/i386/conf TB --- 2010-08-25 18:12:15 - /usr/bin/make -B LINT TB --- 2010-08-25 18:12:15 - building LINT kernel TB --- 2010-08-25 18:12:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 18:12:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 18:12:15 - TARGET=i386 TB --- 2010-08-25 18:12:15 - TARGET_ARCH=i386 TB --- 2010-08-25 18:12:15 - TZ=UTC TB --- 2010-08-25 18:12:15 - __MAKE_CONF=/dev/null TB --- 2010-08-25 18:12:15 - cd /src TB --- 2010-08-25 18:12:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 25 18:12:16 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel trap.o(.text+0xca9): In function `trap': : undefined reference to `dtrace_fasttrap_probe_ptr' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-25 18:29:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-25 18:29:14 - ERROR: failed to build lint kernel TB --- 2010-08-25 18:29:14 - 5642.29 user 1320.22 system 8054.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 19:49:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C3B91065695; Wed, 25 Aug 2010 19:49:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F2D018FC08; Wed, 25 Aug 2010 19:49:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7PJnOnI021990; Wed, 25 Aug 2010 15:49:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7PJnOQq021989; Wed, 25 Aug 2010 19:49:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 25 Aug 2010 19:49:24 GMT Message-Id: <201008251949.o7PJnOQq021989@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 19:49:25 -0000 TB --- 2010-08-25 19:34:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-25 19:34:03 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-25 19:34:03 - cleaning the object tree TB --- 2010-08-25 19:34:06 - cvsupping the source tree TB --- 2010-08-25 19:34:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-25 19:34:41 - building world TB --- 2010-08-25 19:34:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-25 19:34:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-25 19:34:41 - TARGET=powerpc TB --- 2010-08-25 19:34:41 - TARGET_ARCH=powerpc64 TB --- 2010-08-25 19:34:41 - TZ=UTC TB --- 2010-08-25 19:34:41 - __MAKE_CONF=/dev/null TB --- 2010-08-25 19:34:41 - cd /src TB --- 2010-08-25 19:34:41 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 25 19:34:42 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc1: warnings being treated as errors /src/lib/libc/powerpc/gen/makecontext.c: In function '__makecontext': /src/lib/libc/powerpc/gen/makecontext.c:83: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:83: warning: cast to pointer from integer of different size /src/lib/libc/powerpc/gen/makecontext.c:116: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:117: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:118: warning: cast from pointer to integer of different size /src/lib/libc/powerpc/gen/makecontext.c:119: warning: cast from pointer to integer of different size *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-25 19:49:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-25 19:49:24 - ERROR: failed to build world TB --- 2010-08-25 19:49:24 - 616.62 user 172.39 system 920.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 10:40:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C2B10656A5; Thu, 26 Aug 2010 10:40:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3FADB8FC15; Thu, 26 Aug 2010 10:40:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7QAetGA092663; Thu, 26 Aug 2010 06:40:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7QAetac092661; Thu, 26 Aug 2010 10:40:55 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 26 Aug 2010 10:40:55 GMT Message-Id: <201008261040.o7QAetac092661@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 10:40:56 -0000 TB --- 2010-08-26 08:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-26 08:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-08-26 08:30:00 - cleaning the object tree TB --- 2010-08-26 08:30:56 - cvsupping the source tree TB --- 2010-08-26 08:30:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-08-26 08:33:47 - building world TB --- 2010-08-26 08:33:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-26 08:33:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-26 08:33:47 - TARGET=i386 TB --- 2010-08-26 08:33:47 - TARGET_ARCH=i386 TB --- 2010-08-26 08:33:47 - TZ=UTC TB --- 2010-08-26 08:33:47 - __MAKE_CONF=/dev/null TB --- 2010-08-26 08:33:47 - cd /src TB --- 2010-08-26 08:33:47 - /usr/bin/make -B buildworld >>> World build started on Thu Aug 26 08:33:48 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Aug 26 10:23:47 UTC 2010 TB --- 2010-08-26 10:23:47 - generating LINT kernel config TB --- 2010-08-26 10:23:47 - cd /src/sys/i386/conf TB --- 2010-08-26 10:23:47 - /usr/bin/make -B LINT TB --- 2010-08-26 10:23:48 - building LINT kernel TB --- 2010-08-26 10:23:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-26 10:23:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-26 10:23:48 - TARGET=i386 TB --- 2010-08-26 10:23:48 - TARGET_ARCH=i386 TB --- 2010-08-26 10:23:48 - TZ=UTC TB --- 2010-08-26 10:23:48 - __MAKE_CONF=/dev/null TB --- 2010-08-26 10:23:48 - cd /src TB --- 2010-08-26 10:23:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Aug 26 10:23:48 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel trap.o(.text+0xca9): In function `trap': : undefined reference to `dtrace_fasttrap_probe_ptr' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-26 10:40:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-26 10:40:55 - ERROR: failed to build lint kernel TB --- 2010-08-26 10:40:55 - 5631.01 user 1312.59 system 7855.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 10:44:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0451065698; Thu, 26 Aug 2010 10:44:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF9B78FC18; Thu, 26 Aug 2010 10:44:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7QAilcB014461; Thu, 26 Aug 2010 06:44:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7QAiksl014450; Thu, 26 Aug 2010 10:44:46 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 26 Aug 2010 10:44:46 GMT Message-Id: <201008261044.o7QAiksl014450@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 10:44:48 -0000 TB --- 2010-08-26 10:40:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-26 10:40:55 - starting HEAD tinderbox run for mips/mips TB --- 2010-08-26 10:40:55 - cleaning the object tree TB --- 2010-08-26 10:41:16 - cvsupping the source tree TB --- 2010-08-26 10:41:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-08-26 10:41:48 - building world TB --- 2010-08-26 10:41:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-26 10:41:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-26 10:41:48 - TARGET=mips TB --- 2010-08-26 10:41:48 - TARGET_ARCH=mips TB --- 2010-08-26 10:41:48 - TZ=UTC TB --- 2010-08-26 10:41:48 - __MAKE_CONF=/dev/null TB --- 2010-08-26 10:41:48 - cd /src TB --- 2010-08-26 10:41:48 - /usr/bin/make -B buildworld >>> World build started on Thu Aug 26 10:41:49 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] "/src/share/mk/bsd.arch.inc.mk", line 7: if-less elif "/src/Makefile.mips", line 3: Malformed conditional (${TARGET_ABI} == "n64") "/src/Makefile.mips", line 5: if-less endif "/src/share/mk/bsd.arch.inc.mk", line 9: if-less elif "/src/Makefile.mips", line 3: Malformed conditional (${TARGET_ABI} == "n64") "/src/Makefile.mips", line 5: if-less endif "/src/share/mk/bsd.arch.inc.mk", line 11: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-26 10:44:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-26 10:44:46 - ERROR: failed to build world TB --- 2010-08-26 10:44:46 - 151.11 user 54.55 system 231.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 11:40:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D265010656B3; Thu, 26 Aug 2010 11:40:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 849838FC16; Thu, 26 Aug 2010 11:40:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7QBeOdU065448; Thu, 26 Aug 2010 07:40:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7QBeO7I065447; Thu, 26 Aug 2010 11:40:24 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 26 Aug 2010 11:40:24 GMT Message-Id: <201008261140.o7QBeO7I065447@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 11:40:26 -0000 TB --- 2010-08-26 11:11:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-26 11:11:39 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-26 11:11:39 - cleaning the object tree TB --- 2010-08-26 11:11:51 - cvsupping the source tree TB --- 2010-08-26 11:11:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-26 11:12:20 - building world TB --- 2010-08-26 11:12:20 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-26 11:12:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-26 11:12:20 - TARGET=powerpc TB --- 2010-08-26 11:12:20 - TARGET_ARCH=powerpc64 TB --- 2010-08-26 11:12:20 - TZ=UTC TB --- 2010-08-26 11:12:20 - __MAKE_CONF=/dev/null TB --- 2010-08-26 11:12:20 - cd /src TB --- 2010-08-26 11:12:20 - /usr/bin/make -B buildworld >>> World build started on Thu Aug 26 11:12:21 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-26 11:40:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-26 11:40:24 - ERROR: failed to build world TB --- 2010-08-26 11:40:24 - 1145.02 user 348.07 system 1724.74 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 13:27:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 585E91065670; Thu, 26 Aug 2010 13:27:51 +0000 (UTC) Date: Thu, 26 Aug 2010 13:27:51 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100826132751.GA15636@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline Subject: concerning GCC GPLv2 vs. GPLv3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:27:51 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, the FreeBSD base GCC version is dated 20070719 which is the release date of GCC 4.2.1. after this release the 4.2 branch got GPLv3'ed which is the reason anything after 20070719 in the 4.2 branch cannot be imported into the FreeBSD. Also all the other branches > 4.2 are GPLv3'ed too. however i noticed a lot of commits to the 4.2 and later branches have been backported into the 4.1 branch which is still licensed under GPLv2. the last snapshot of the 4.1 branch is dated 29/06/2008 [1], so it's possible to import all those backported changes into the FreeBSD source tree without any legal issues. i'm not sure how many problems that would fix though. one of them is PR 118188. i've attached an excerpt of the 4.1 branches Changelog file which documents the commits to that branch which aren't in the FreeBSD source tree yet. cheers. alex [1] ftp://ftp.fu-berlin.de/unix/languages/gcc/snapshots/4.1-20080630/ -- a13x --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Changelog-4.2.1-against-4.1_trunk" 2008-05-29 Eric Botcazou * gcc.dg/nested-func-6.c: New test. 2008-04-08 Richard Guenther * gcc.c-torture/execute/20080408-1.c: New testcase. 2008-03-25 Richard Guenther Backport from mainline: 2008-02-12 Richard Guenther PR middle-end/35163 * gcc.c-torture/execute/pr35163.c: New testcase. 2008-02-13 Kaveh R. Ghazi Backport: 2005-11-30 Richard Guenther PR tree-optimization/21655 * g++.dg/tree-ssa/pr14814.C: Remove XFAIL. 2008-02-12 Kaveh R. Ghazi * obj-c++.dg/bitfield-1.mm: Expect failures. * obj-c++.dg/bitfield-4.mm: Likewise. * obj-c++.dg/cxx-ivars-2.mm: Likewise. * obj-c++.dg/encode-8.mm: Likewise. * obj-c++.dg/isa-field-1.mm: Likewise. * obj-c++.dg/layout-1.mm: Likewise. * obj-c++.dg/lookup-2.mm: Likewise. * obj-c++.dg/try-catch-2.mm: Likewise. * obj-c++.dg/try-catch-9.mm: Likewise. 2008-02-12 Kaveh R. Ghazi PR objc++/34193 * obj-c++.dg/gnu-runtime-2.mm: Fix signature of function main(). 2008-02-10 Kaveh R. Ghazi PR objc++/27232 Backport: 2006-09-22 Mike Stump * obj-c++.dg/encode-3.mm: Fix for 64-bit support. 2008-02-04 Richard Guenther PR middle-end/33631 * gcc.c-torture/execute/pr33631.c: New testcase. 2008-01-31 Andreas Krebbel * gcc.dg/tf_to_di-1.c: New testcase. 2008-01-24 Kaveh R. Ghazi Backport: 2008-01-10 Kaveh R. Ghazi * gcc.dg/pr33826.c: Require nonpic. 2007-11-08 Kenneth Zadeck PR middle-end/33826 * gcc.dg/pr33826.c: New. * gcc.dg/tree-ssa/20030714-1.c: Removed two tests that depend on recursive functions being marked pure or const. 2008-01-22 Kaveh R. Ghazi * gcc.dg/vect/vect-ifcvt-9.c: Use inline. 2008-01-19 John David Anglin * g++.dg/eh/ia64-2.C: Add "dg-require-weak" statement. Place "dg-do run" statement before "dg-require-weak" statement. * g++.dg/eh/weak1.C: Likewise. 2008-01-19 Kaveh R. Ghazi Backport: 2007-03-21 Richard Sandiford * gcc.target/i386/pr21291.c: Require nonpic or ! ilp32. 2008-01-17 Eric Botcazou * gcc.c-torture/compile/20080114-1.c: Use empty asm statements. 2008-01-14 Eric Botcazou * gcc.c-torture/compile/20080114-1.c: New test. 2008-01-09 Kaveh R. Ghazi * gcc.c-torture/execute/builtins/chk.h: Don't check !__PIE__. Also check __pic__. * lib/target-supports.exp (check_effective_target_nonpic): Likewise. * gcc.dg/assign-warn-3.c: Use "static inline" instead of "inline". Backport: 2007-03-21 Richard Sandiford * gcc.c-torture/execute/builtins/chk.h (LOCAL): Define. * gcc.c-torture/execute/builtins/sprintf-chk.c (s1): Make LOCAL. * gcc.c-torture/execute/builtins/stpcpy-chk.c (s1): Likewise. * gcc.c-torture/execute/builtins/strcpy-chk.c (s1): Likewise. 2007-07-26 Nathan Froyd PR/19232 * gcc.dg/assign-warn-3.c (f0): Declare as inline. (f1): Likewise. 2007-01-15 Dale Johannesen * gcc.dg/tree-ssa/loop-3.c: Disable with -fpic or -fPIC. 2007-03-21 Richard Sandiford * lib/target-supports.exp (check_effective_target_nonpic): New procedure. 2007-12-20 Jakub Jelinek PR bootstrap/34003 * gcc.dg/pr34003-1.c: New test. * gcc.dg/pr34003-2.c: New. 2007-12-19 Richard Sandiford PR rtl-optimization/34456 * gcc.c-torture/execute/pr34456.c: New test. 2007-11-29 Matthias Klose Backport from mainline: 2007-11-17 Richard Guenther PR middle-end/34130 * gcc.c-torture/execute/pr34130.c: New testcase. 2007-11-16 Richard Guenther PR middle-end/34030 * gcc.c-torture/compile/pr34030.c: New testcase. 2007-11-07 Eric Botcazou * gcc.dg/out-of-bounds-1.c: New test. 2007-11-02 Eric Botcazou PR rtl-optimization/28062 * gcc.c-torture/compile/20071102-1.c: New test. 2007-10-26 Jakub Jelinek PR c++/33744 * g++.dg/template/arg6.C: New test. 2007-09-06 David Daney Richard Sandiford PR target/33256 * gcc.target/mips/mips.exp (setup_mips_tests): Set mips_forced_le. (dg-mips-options): Skip -EB and -meb tests when $mips_forced_le. * gcc.target/mips/pr33256.c: New test. 2007-08-31 Paolo Carlini PR c++/32113 * g++.dg/template/crash70.C: New. 2007-08-24 Jakub Jelinek PR middle-end/32912 * gcc.dg/pr32912-1.c: New test. * gcc.dg/pr32912-2.c: New test. PR c++/31941 * g++.dg/parse/crash37.C: New test. 2007-08-22 Richard Guenther PR tree-optimization/33142 * gcc.c-torture/execute/pr33142.c: New testcase. 2007-08-20 Jakub Jelinek PR c++/32992 * g++.dg/opt/nrv14.C: New test. 2007-08-18 Paolo Carlini PR c++/32112 * g++.dg/template/error26.C: New. 2007-08-10 Paolo Carlini PR c++/17763 * g++.dg/other/error16.C: New. 2007-08-01 Andreas Krebbel * gcc.dg/20070801-1.c: New testcase. 2007-07-21 Kaveh R. Ghazi * gcc.dg/c99-math-double-1.c: Mark test variables as volatile. Test negative numbers also. * gcc.dg/c99-math-float-1.c: Likewise. * gcc.dg/c99-math-long-double-1.c: Likewise. * gcc.dg/c99-math.h: Check for FP exceptions. Update for negative test inputs. --5mCyUwZo2JvN/JJP-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 19:53:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D402410656AB for ; Thu, 26 Aug 2010 19:53:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 77CF68FC08 for ; Thu, 26 Aug 2010 19:53:45 +0000 (UTC) Received: by qyk4 with SMTP id 4so2348671qyk.13 for ; Thu, 26 Aug 2010 12:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=43874TbKjj9uAt5/UKsK7RYq724oxkYCIaaSOB59+0w=; b=GvhjPOR16bwekihw15DpsGeB5xxn7wBaUiBGNVKk+rtj96NLkeDBMiYXGFO1ObY5lG f8ZRMkSOii+kNTXJ3n8qR/COZCH91bKwzXpKjW2nHMMEwVHtJqwvvq7vjZA5trEXlL1A D4DGJLt/FeWZDEqVEgZ0RFarKQi2Fa1afOBnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=f+dK/v20tLhf+ZWQRtVD0oaQ4Xfjlppe3f5cSpc/q88A41O6Hxkt/2iVs1iA1PwNud eWYXyPRsGFOzXjSn+mgI/fOWfjKyru74Nt2UEtMahXrrG11OwtAhPdZFRlLoxHlYeyXF lq21hNNYDrzK3GiJ5f7RoLb5W2jFKtcxxaoSQ= MIME-Version: 1.0 Received: by 10.229.181.8 with SMTP id bw8mr7514151qcb.113.1282852424516; Thu, 26 Aug 2010 12:53:44 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Thu, 26 Aug 2010 12:53:44 -0700 (PDT) Date: Thu, 26 Aug 2010 23:53:44 +0400 Message-ID: From: pluknet To: freebsd-rc@freebsd.org Content-Type: multipart/mixed; boundary=0016361e81a810124b048ebf5b14 Cc: FreeBSD Current Subject: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 19:53:45 -0000 --0016361e81a810124b048ebf5b14 Content-Type: text/plain; charset=ISO-8859-1 [cc'ing current@ as rc@ looks too quite] Hi. Since ifconfig has grown to label interfaces with ifconfig $ifname description "foobar", what about to give it more life and store i/face descriptions semi-permanently, so they will survive between reboots? This patch adds a functionality to rc.d to label interfaces at boot time. Comments are welcome. %%% Index: etc/rc.d/netif =================================================================== --- etc/rc.d/netif (revision 211280) +++ etc/rc.d/netif (working copy) @@ -75,6 +75,9 @@ # Rename interfaces. ifnet_rename + + # Give description to interfaces. + ifnet_descr fi # Configure the interface(s). Index: etc/network.subr =================================================================== --- etc/network.subr (revision 211280) +++ etc/network.subr (working copy) @@ -1187,6 +1187,24 @@ return 0 } +# ifnet_descr +# Add description to all requested interfaces. +# +ifnet_descr() +{ + local _if _ifdescr + + # ifconfig_IF_descr + for _if in `ifconfig -l`; do + _ifdescr="`get_if_var $_if ifconfig_IF_descr`" + if [ ! -z "$_ifdescr" ]; then + ifconfig $_if descr "$_ifdescr" + fi + done + + return 0 +} + # list_net_interfaces type # List all network interfaces. The type of interface returned # can be controlled by the type argument. The type Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 211280) +++ etc/defaults/rc.conf (working copy) @@ -215,6 +215,7 @@ #ifconfig_ed0_ipv6="inet6 2001:db8:1::1 prefixlen 64" # Sample IPv6 addr entry #ifconfig_ed0_alias0="inet6 2001:db8:2::1 prefixlen 64" # Sample IPv6 alias #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. +#ifconfig_fxp0_descr="Uplink to Gigabit Switch 2" # Label fxp0 interface #vlans_fxp0="101 vlan0" # vlan(4) interfaces for fxp0 device #create_arg_vlan0="vlan 102" # vlan tag for vlan0 device #wlans_ath0="wlan0" # wlan(4) interfaces for ath0 device %%% -- wbr, pluknet --0016361e81a810124b048ebf5b14 Content-Type: text/x-diff; charset=US-ASCII; name="descr.rc.d.diff" Content-Disposition: attachment; filename="descr.rc.d.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gdc15hj10 SW5kZXg6IGV0Yy9yYy5kL25ldGlmCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9yYy5kL25ldGlmCShyZXZp c2lvbiAyMTEyODApCisrKyBldGMvcmMuZC9uZXRpZgkod29ya2luZyBjb3B5KQpAQCAtNzUsNiAr NzUsOSBAQAogCiAJCSMgUmVuYW1lIGludGVyZmFjZXMuCiAJCWlmbmV0X3JlbmFtZQorCisJCSMg R2l2ZSBkZXNjcmlwdGlvbiB0byBpbnRlcmZhY2VzLgorCQlpZm5ldF9kZXNjcgogCWZpCiAKIAkj IENvbmZpZ3VyZSB0aGUgaW50ZXJmYWNlKHMpLgpJbmRleDogZXRjL25ldHdvcmsuc3Vicgo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBldGMvbmV0d29yay5zdWJyCShyZXZpc2lvbiAyMTEyODApCisrKyBldGMvbmV0 d29yay5zdWJyCSh3b3JraW5nIGNvcHkpCkBAIC0xMTg3LDYgKzExODcsMjQgQEAKIAlyZXR1cm4g MAogfQogCisjIGlmbmV0X2Rlc2NyCisjCUFkZCBkZXNjcmlwdGlvbiB0byBhbGwgcmVxdWVzdGVk IGludGVyZmFjZXMuCisjCitpZm5ldF9kZXNjcigpCit7CisJbG9jYWwgX2lmIF9pZmRlc2NyCisK KwkjIGlmY29uZmlnX0lGX2Rlc2NyCisJZm9yIF9pZiBpbiBgaWZjb25maWcgLWxgOyBkbworCQlf aWZkZXNjcj0iYGdldF9pZl92YXIgJF9pZiBpZmNvbmZpZ19JRl9kZXNjcmAiCisJCWlmIFsgISAt eiAiJF9pZmRlc2NyIiBdOyB0aGVuCisJCQlpZmNvbmZpZyAkX2lmIGRlc2NyICIkX2lmZGVzY3Ii CisJCWZpCisJZG9uZQorCisJcmV0dXJuIDAKK30KKwogIyBsaXN0X25ldF9pbnRlcmZhY2VzIHR5 cGUKICMJTGlzdCBhbGwgbmV0d29yayBpbnRlcmZhY2VzLiBUaGUgdHlwZSBvZiBpbnRlcmZhY2Ug cmV0dXJuZWQKICMJY2FuIGJlIGNvbnRyb2xsZWQgYnkgdGhlIHR5cGUgYXJndW1lbnQuIFRoZSB0 eXBlCkluZGV4OiBldGMvZGVmYXVsdHMvcmMuY29uZgo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvZGVmYXVs dHMvcmMuY29uZgkocmV2aXNpb24gMjExMjgwKQorKysgZXRjL2RlZmF1bHRzL3JjLmNvbmYJKHdv cmtpbmcgY29weSkKQEAgLTIxNSw2ICsyMTUsNyBAQAogI2lmY29uZmlnX2VkMF9pcHY2PSJpbmV0 NiAyMDAxOmRiODoxOjoxIHByZWZpeGxlbiA2NCIgIyBTYW1wbGUgSVB2NiBhZGRyIGVudHJ5CiAj aWZjb25maWdfZWQwX2FsaWFzMD0iaW5ldDYgMjAwMTpkYjg6Mjo6MSBwcmVmaXhsZW4gNjQiICMg U2FtcGxlIElQdjYgYWxpYXMKICNpZmNvbmZpZ19meHAwX25hbWU9Im5ldDAiCSMgQ2hhbmdlIGlu dGVyZmFjZSBuYW1lIGZyb20gZnhwMCB0byBuZXQwLgorI2lmY29uZmlnX2Z4cDBfZGVzY3I9IlVw bGluayB0byBHaWdhYml0IFN3aXRjaCAyIgkjIExhYmVsIGZ4cDAgaW50ZXJmYWNlCiAjdmxhbnNf ZnhwMD0iMTAxIHZsYW4wIgkJIyB2bGFuKDQpIGludGVyZmFjZXMgZm9yIGZ4cDAgZGV2aWNlCiAj Y3JlYXRlX2FyZ192bGFuMD0idmxhbiAxMDIiCSMgdmxhbiB0YWcgZm9yIHZsYW4wIGRldmljZQog I3dsYW5zX2F0aDA9IndsYW4wIgkJIyB3bGFuKDQpIGludGVyZmFjZXMgZm9yIGF0aDAgZGV2aWNl Cg== --0016361e81a810124b048ebf5b14-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 20:03:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080071065695 for ; Thu, 26 Aug 2010 20:03:40 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F60C8FC12 for ; Thu, 26 Aug 2010 20:03:39 +0000 (UTC) Received: by eyx24 with SMTP id 24so1857390eyx.13 for ; Thu, 26 Aug 2010 13:03: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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/2q83W3kbgFioJeitCefUvryK8AeBuKrnLDN7dndL+E=; b=lkgDCupk8P249aYxRkYRtBf/gPo/SgSjWvKeyXLR/7r+WPpSLYAaWQOECFic/uNOwi NF4vdCU/CpntjBq2iYJs+41gSztpn1x2eA5TPoURGAlW+jMhUfZoFOsjHGrZUH8FqqGg lLOSfsztEhdsb272J9RgWubbpWNLjy6YvKlgg= 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=e8X/lgb3wbeppzhEPvCSdIEvB6rw7KhzVQjaPZ+b4+08jxO0ZHjYERwJ93poWOluEU swo07fXfseCpLxrLP2SmL/qBCKy8hxKJdXa6ZTCmZ+hN9Z0heKwxGCefANF4qwqcWRZK MTwptdiVVO6q8Oe2xy9oWVB66t6JMCD0bdYDM= MIME-Version: 1.0 Received: by 10.213.114.83 with SMTP id d19mr213361ebq.7.1282853018285; Thu, 26 Aug 2010 13:03:38 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.213.20.144 with HTTP; Thu, 26 Aug 2010 13:03:38 -0700 (PDT) Date: Thu, 26 Aug 2010 13:03:38 -0700 X-Google-Sender-Auth: Ywk1QEnRRcKMSnafRa55xCYdCvs Message-ID: From: mdf@FreeBSD.org To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeff Roberson Subject: sched_pin() bug in SCHED_ULE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:03:40 -0000 Back at the beginning of August I posted about issues with sched_pin() and witness_warn(): http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.html After a lot of debugging I think I've basically found the issue. I found this bug on stable/7, but looking at the commit log for CURRENT I don't see any reason the bug doesn't exist there. This analysis is specific to amd64/i386 but the problem is likely to exist on most arches. The basic problem is that in both tdq_move() and sched_setcpu() can manipulate the ts->ts_cpu variable of another process, which may be running. This means that a process running on CPU N may be set to run on CPU M the next context switch. Then, that process may call sched_pin(), then grab a PCPU variable. An IPI_PREEMPT can come in, causing the thread to call mi_switch() in ipi_bitmap_handler(). sched_switch() will then notice that ts->ts_cpu is not PCPU_GET(cpuid), and call sched_switch_migrate(), migrating the thread to the intended CPU. Thus after sched_pin() and potentially before using any PCPU variable the process can get migrated to another CPU, and now it is using a PCPU variable for the wrong processor. Given that ts_cpu can be set by other threads, it doesn't seem worth checking at sched_pin time whether ts_cpu is not the same as td_oncpu, because to make the check would require taking the thread_lock. Instead, I propose adding a check for !THREAD_CAN_MIGRATE() before calling sched_switch_migrate(). However, sched_pin() is also used by sched_bind(9) to force the thread to stay on the intended cpu. I would handle this by adding a TSF_BINDING state that is different from TSF_BOUND. The thing that has me wondering whether this is all correct is that I don't see any checks in tdq_move() or sched_setcpu() for either TSF_BOUND or THREAD_CAN_MIGRATE(). Perhaps that logic is managed in the various calling functions; in that case I would propose adding asserts that the thread is THREAD_CAN_MIGRATE() unless it's marked TSF_BINDING. Does this analysis seem correct? Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 20:09:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075EF10656A5 for ; Thu, 26 Aug 2010 20:09:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 87B888FC21 for ; Thu, 26 Aug 2010 20:09:44 +0000 (UTC) Received: (qmail 13043 invoked by uid 399); 26 Aug 2010 20:09:43 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Aug 2010 20:09:43 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C76CA06.5010001@FreeBSD.org> Date: Thu, 26 Aug 2010 13:09:42 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: pluknet References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-rc@freebsd.org Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:09:45 -0000 On 08/26/2010 12:53 PM, pluknet wrote: > [cc'ing current@ as rc@ looks too quite] > > Hi. > > Since ifconfig has grown to label interfaces with > ifconfig $ifname description "foobar", what about > to give it more life and store i/face descriptions > semi-permanently, so they will survive between reboots? > > This patch adds a functionality to rc.d to label > interfaces at boot time. > > Comments are welcome. This seems like a good addition, thanks. Please also write a patch for rc.conf.5 to describe this new functionality and I'll be happy to commit it. One note below. > --- etc/network.subr (revision 211280) > +++ etc/network.subr (working copy) > @@ -1187,6 +1187,24 @@ > return 0 > } > > +# ifnet_descr > +# Add description to all requested interfaces. > +# > +ifnet_descr() > +{ > + local _if _ifdescr > + > + # ifconfig_IF_descr > + for _if in `ifconfig -l`; do > + _ifdescr="`get_if_var $_if ifconfig_IF_descr`" > + if [ ! -z "$_ifdescr" ]; then This is probably better as [ -n "$_ifdescr" ] Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 20:49:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B55D10656A4; Thu, 26 Aug 2010 20:49:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 135988FC18; Thu, 26 Aug 2010 20:49:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9949C46B91; Thu, 26 Aug 2010 16:49:30 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 65BFE8A03C; Thu, 26 Aug 2010 16:49:29 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 26 Aug 2010 16:49:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008261649.20543.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 26 Aug 2010 16:49:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: mdf@freebsd.org, Jeff Roberson Subject: Re: sched_pin() bug in SCHED_ULE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:49:31 -0000 On Thursday, August 26, 2010 4:03:38 pm mdf@freebsd.org wrote: > Back at the beginning of August I posted about issues with sched_pin() > and witness_warn(): > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.html > > After a lot of debugging I think I've basically found the issue. I > found this bug on stable/7, but looking at the commit log for CURRENT > I don't see any reason the bug doesn't exist there. This analysis is > specific to amd64/i386 but the problem is likely to exist on most > arches. > > The basic problem is that in both tdq_move() and sched_setcpu() can > manipulate the ts->ts_cpu variable of another process, which may be > running. This means that a process running on CPU N may be set to run > on CPU M the next context switch. > > Then, that process may call sched_pin(), then grab a PCPU variable. > An IPI_PREEMPT can come in, causing the thread to call mi_switch() in > ipi_bitmap_handler(). sched_switch() will then notice that ts->ts_cpu > is not PCPU_GET(cpuid), and call sched_switch_migrate(), migrating the > thread to the intended CPU. Thus after sched_pin() and potentially > before using any PCPU variable the process can get migrated to another > CPU, and now it is using a PCPU variable for the wrong processor. > > Given that ts_cpu can be set by other threads, it doesn't seem worth > checking at sched_pin time whether ts_cpu is not the same as td_oncpu, > because to make the check would require taking the thread_lock. > Instead, I propose adding a check for !THREAD_CAN_MIGRATE() before > calling sched_switch_migrate(). However, sched_pin() is also used by > sched_bind(9) to force the thread to stay on the intended cpu. I > would handle this by adding a TSF_BINDING state that is different from > TSF_BOUND. > > The thing that has me wondering whether this is all correct is that I > don't see any checks in tdq_move() or sched_setcpu() for either > TSF_BOUND or THREAD_CAN_MIGRATE(). Perhaps that logic is managed in > the various calling functions; in that case I would propose adding > asserts that the thread is THREAD_CAN_MIGRATE() unless it's marked > TSF_BINDING. > > Does this analysis seem correct? Calling code does check THREAD_CAN_MIGRATE(), but the problem is that it is not safe to call that on anything but curthread as td_pinned is not locked. It is assumed that only curthread would ever check td_pinned, not other threads. I suspect what is happening is that another CPU is seeing a stale value of td_pinned. You could fix this by grabbing the thread lock in sched_pin()/unpin() for ULE, but that is a bit expensive perhaps. You could test your theory by disabling thread stealing btw. There are a few sysctl knobs to turn it off. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 21:10:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ECAF1065673 for ; Thu, 26 Aug 2010 21:10:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id D8D2A8FC17 for ; Thu, 26 Aug 2010 21:10:15 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 63219A600ED; Fri, 27 Aug 2010 05:10:14 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id zm-K9vSFijQ4; Fri, 27 Aug 2010 05:10:04 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id C8227A5FDBE; Fri, 27 Aug 2010 05:10:01 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type; b=KTiX7fNPyJI8hXRdKWrxdMoOXQxTcuyDk8JcBmTOv6Lht9Mk+IW2uVDawCy7AMJE6 ppX3CJJ6uPACTlrR1MXow== Message-ID: <4C76D823.7070703@delphij.net> Date: Thu, 26 Aug 2010 14:09:55 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4C76CA06.5010001@FreeBSD.org> In-Reply-To: <4C76CA06.5010001@FreeBSD.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------020709080901060207010303" Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 21:10:16 -0000 This is a multi-part message in MIME format. --------------020709080901060207010303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/08/26 13:09, Doug Barton wrote: > On 08/26/2010 12:53 PM, pluknet wrote: >> [cc'ing current@ as rc@ looks too quite] >> >> Hi. >> >> Since ifconfig has grown to label interfaces with >> ifconfig $ifname description "foobar", what about >> to give it more life and store i/face descriptions >> semi-permanently, so they will survive between reboots? >> >> This patch adds a functionality to rc.d to label >> interfaces at boot time. >> >> Comments are welcome. > > This seems like a good addition, thanks. Please also write a patch for > rc.conf.5 to describe this new functionality and I'll be happy to commit > it. One note below. I have drafted one. (Note that fxp is a 100Mbps card so it might be sensible to replace it with just Switch 2?) >> --- etc/network.subr (revision 211280) >> +++ etc/network.subr (working copy) >> @@ -1187,6 +1187,24 @@ >> return 0 >> } >> >> +# ifnet_descr >> +# Add description to all requested interfaces. >> +# >> +ifnet_descr() >> +{ >> + local _if _ifdescr >> + >> + # ifconfig_IF_descr >> + for _if in `ifconfig -l`; do >> + _ifdescr="`get_if_var $_if ifconfig_IF_descr`" >> + if [ ! -z "$_ifdescr" ]; then > > This is probably better as [ -n "$_ifdescr" ] > > Doug > - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMdtgjAAoJEATO+BI/yjfBywEIALQZMUFUKlkQ/DZjrqBgymFx Mnj6YkLaPXcvNI5OI15Q3hy730pIZzzNPGKV9ecXLSQ1PikZUIXy5fuRfYh9iXE3 d9f4UgDId0Sn55WmD6/Sfza0oSlH3C1fus6e9NSmm/aR3ekWyLWZzW0wGTgEXFxK bo0ZcQw7AxRxDLc7EifWUfxV/Ej5pga5YjVyhBBdCoAHl2bPJuFFuxd140Y6+Mlf gH4zgf2rdGpCWNpWF6L8PsGoVNBoK0R1fUwJZT+GB2ANvMuuQ+jsks+R8h8XFIO6 TE4O8onVcOaoTGZ3873M3CqcO1jfaK5rBfGg3Cr9wUjOkvkQ8SL+k4uvBm4CuX4= =VtCo -----END PGP SIGNATURE----- --------------020709080901060207010303 Content-Type: text/plain; name="rc.conf.5-ifdescr.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rc.conf.5-ifdescr.diff" SW5kZXg6IHJjLmNvbmYuNQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByYy5jb25mLjUJKHJldmlzaW9u IDIxMTg0NykKKysrIHJjLmNvbmYuNQkod29ya2luZyBjb3B5KQpAQCAtMTEyOCw2ICsxMTI4 LDE5IEBACiB2YXJpYWJsZXMuCiAuUHAKIElmIGEKKy5WYSBpZmNvbmZpZ18gTnMgQW8gQXIg aW50ZXJmYWNlIEFjIE5zIFZhIF9kZXNjcgordmFyaWFibGUgaXMgc2V0LCB0aGUgaW50ZXJm YWNlIHdvdWxkIGJlIGFzc2lnbmVkIHRoZSBkZXNjcmlwdGlvbgorc3BlY2lmaWVkIGJ5IHRo ZSB2YXJpYWJsZS4KKy5QcAorVG8gYXNzaWduIGFuIGRlc2NyaXB0aW9uIG9mCisuRHEgVXBs aW5rIHRvIEdpZ2FiaXQgU3dpdGNoIDEKK29uIHRoZSBpbnRlcmZhY2UgbmFtZWQKKy5MaSBl bTAgOgorLkJkIC1saXRlcmFsCitpZmNvbmZpZ19lbTBfZGVzY3I9IlVwbGluayB0byBHaWdh Yml0IFN3aXRjaCAxIgorLkVkCisuUHAKK0lmIGEKIC5WYSB2bGFuc18gTnMgQXEgQXIgaW50 ZXJmYWNlCiB2YXJpYWJsZSBpcyBzZXQsCiBhCg== --------------020709080901060207010303-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 21:20:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5805B1065694; Thu, 26 Aug 2010 21:20:33 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB1C98FC16; Thu, 26 Aug 2010 21:20:32 +0000 (UTC) Received: by ewy4 with SMTP id 4so1783283ewy.13 for ; Thu, 26 Aug 2010 14:20:31 -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=jCmhhprGU6cL33UZWALWlLU593s1UI6h5PJcH/H76PQ=; b=UQl/s3VeLj3Vy0c9TbSkIQSh21QGtNq6KmZ5s230oh5Rf1qORKTtBPY8aIdfvQhLyn DV2MVR/II8LJKuHWwGotP+IxEHUKHpkuDNRhcE3GkG3Mc1IdBXgA8UtP4yJdgCsQxTiT 9euGizqpK9IOcFw25eAsNhQS/pZyKJ5geV+TQ= 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=eU4wjSjnEeTAC+Osq7GDXP2LX8d1B19s04tX5pdlY1YoW1rs11oLTctXFJKwXCfVVC HIZlkADewWnlDa+rQ5yMtuG3JCozjyl9b6poKIQb6BoJqSdhRPAxS/wylUB8vLGh6mWe siBrHtItU87YqUCTqwNUeoTlpyIvWHd4gzJYo= MIME-Version: 1.0 Received: by 10.213.28.20 with SMTP id k20mr84684ebc.73.1282857631407; Thu, 26 Aug 2010 14:20:31 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.213.20.144 with HTTP; Thu, 26 Aug 2010 14:20:31 -0700 (PDT) In-Reply-To: <201008261649.20543.jhb@freebsd.org> References: <201008261649.20543.jhb@freebsd.org> Date: Thu, 26 Aug 2010 14:20:31 -0700 X-Google-Sender-Auth: 1ApI06c0i1UhCXHueyrKY3X_ayo Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jeff Roberson Subject: Re: sched_pin() bug in SCHED_ULE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 21:20:33 -0000 On Thu, Aug 26, 2010 at 1:49 PM, John Baldwin wrote: > On Thursday, August 26, 2010 4:03:38 pm mdf@freebsd.org wrote: >> Back at the beginning of August I posted about issues with sched_pin() >> and witness_warn(): >> >> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032553.ht= ml >> >> After a lot of debugging I think I've basically found the issue. =A0I >> found this bug on stable/7, but looking at the commit log for CURRENT >> I don't see any reason the bug doesn't exist there. =A0This analysis is >> specific to amd64/i386 but the problem is likely to exist on most >> arches. >> >> The basic problem is that in both tdq_move() and sched_setcpu() can >> manipulate the ts->ts_cpu variable of another process, which may be >> running. =A0This means that a process running on CPU N may be set to run >> on CPU M the next context switch. >> >> Then, that process may call sched_pin(), then grab a PCPU variable. >> An IPI_PREEMPT can come in, causing the thread to call mi_switch() in >> ipi_bitmap_handler(). =A0sched_switch() will then notice that ts->ts_cpu >> is not PCPU_GET(cpuid), and call sched_switch_migrate(), migrating the >> thread to the intended CPU. =A0Thus after sched_pin() and potentially >> before using any PCPU variable the process can get migrated to another >> CPU, and now it is using a PCPU variable for the wrong processor. >> >> Given that ts_cpu can be set by other threads, it doesn't seem worth >> checking at sched_pin time whether ts_cpu is not the same as td_oncpu, >> because to make the check would require taking the thread_lock. >> Instead, I propose adding a check for !THREAD_CAN_MIGRATE() before >> calling sched_switch_migrate(). =A0However, sched_pin() is also used by >> sched_bind(9) to force the thread to stay on the intended cpu. =A0I >> would handle this by adding a TSF_BINDING state that is different from >> TSF_BOUND. >> >> The thing that has me wondering whether this is all correct is that I >> don't see any checks in tdq_move() or sched_setcpu() for either >> TSF_BOUND or THREAD_CAN_MIGRATE(). =A0Perhaps that logic is managed in >> the various calling functions; in that case I would propose adding >> asserts that the thread is THREAD_CAN_MIGRATE() unless it's marked >> TSF_BINDING. >> >> Does this analysis seem correct? > > Calling code does check THREAD_CAN_MIGRATE(), but the problem is that it = is > not safe to call that on anything but curthread as td_pinned is not locke= d. > It is assumed that only curthread would ever check td_pinned, not other > threads. =A0I suspect what is happening is that another CPU is seeing a s= tale > value of td_pinned. =A0You could fix this by grabbing the thread lock in > sched_pin()/unpin() for ULE, but that is a bit expensive perhaps. I tried making sched_pin() a real function which used intr_disable/intr_restore around saving off td->td_oncpu, td->td_lastcpu and ts->ts_cpu, and the stack at the time of call. In sched_switch when I saw an unexpected migration I printed all that out. I found that on my boxes, at sched_pin() time ts_cpu was already different from td->td_oncpu, so the specific problem I was having was that while another thread can change ts_cpu it has no way to force that thread to immediately migrate. I believe the below patch fixes the issue, though I'm open to other methods= : Index: kern/sched_ule.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- kern/sched_ule.c (.../head/src/sys) (revision 158279) +++ kern/sched_ule.c (.../branches/BR_BUG_67957/src/sys) (revision 158279) @@ -112,6 +112,7 @@ /* flags kept in ts_flags */ #define TSF_BOUND 0x0001 /* Thread can not migrate. */ #define TSF_XFERABLE 0x0002 /* Thread was added as transferable. */ +#define TSF_BINDING 0x0004 /* Thread is being bound. */ static struct td_sched td_sched0; @@ -1859,6 +1858,7 @@ struct mtx *mtx; int srqflag; int cpuid; + int do_switch; THREAD_LOCK_ASSERT(td, MA_OWNED); @@ -1888,10 +1888,21 @@ srqflag =3D (flags & SW_PREEMPT) ? SRQ_OURSELF|SRQ_YIELDING|SRQ_PREEMPTED : SRQ_OURSELF|SRQ_YIELDING; - if (ts->ts_cpu =3D=3D cpuid) + /* + * Allow the switch to another processor as requested + * only if the thread can migrate or we are in the + * middle of binding for sched_bind(9). This keeps + * sched_pin() quick, since other threads can + * manipulate ts_cpu. + */ + do_switch =3D (ts->ts_cpu !=3D cpuid); + if (!THREAD_CAN_MIGRATE(td) && + (ts->ts_flags & TSF_BINDING) =3D=3D 0) + do_switch =3D 0; + if (do_switch) + mtx =3D sched_switch_migrate(tdq, td, srqflag); + else tdq_add(tdq, td, srqflag); - else - mtx =3D sched_switch_migrate(tdq, td, srqflag); } else { /* This thread must be going to sleep. */ TDQ_LOCK(tdq); @@ -1938,12 +1949,25 @@ */ cpuid =3D PCPU_GET(cpuid); tdq =3D TDQ_CPU(cpuid); + KASSERT(THREAD_CAN_MIGRATE(td) || + (ts->ts_flags & TSF_BINDING) !=3D 0 || + cpuid =3D=3D td->td_lastcpu, + ("Non-migratable thread %p migrated from %d to %d", + td, td->td_lastcpu, cpuid)); #ifdef HWPMC_HOOKS if (PMC_PROC_IS_USING_PMCS(td->td_proc)) PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_IN); #endif } else thread_unblock_switch(td, mtx); + + if ((ts->ts_flags & TSF_BINDING) !=3D 0) { + ts->ts_flags &=3D ~TSF_BINDING; + ts->ts_flags |=3D TSF_BOUND; + } + KASSERT((ts->ts_flags & TSF_BOUND) =3D=3D 0 || ts->ts_cpu =3D=3D cpuid, + ("Bound thread %p on %d not %d", td, cpuid, ts->ts_cpu)); + /* * Assert that all went well and return. */ @@ -2607,15 +2631,21 @@ ts =3D td->td_sched; if (ts->ts_flags & TSF_BOUND) sched_unbind(td); - ts->ts_flags |=3D TSF_BOUND; + KASSERT(THREAD_CAN_MIGRATE(td), + ("%s called on non-migratable thread %p", __func__, td)); #ifdef SMP + ts->ts_flags |=3D TSF_BINDING; sched_pin(); if (PCPU_GET(cpuid) =3D=3D cpu) return; ts->ts_cpu =3D cpu; /* When we return from mi_switch we'll be on the correct cpu. */ mi_switch(SW_VOL, NULL); +#else + ts->ts_flags |=3D TSF_BOUND; #endif + KASSERT((ts->ts_flags & TSF_BOUND) !=3D 0 && cpu =3D=3D PCPU_GET(cpuid), + ("Should be bound to %d", cpu)); } /* @@ -2640,7 +2670,7 @@ sched_is_bound(struct thread *td) { THREAD_LOCK_ASSERT(td, MA_OWNED); - return (td->td_sched->ts_flags & TSF_BOUND); + return ((td->td_sched->ts_flags & (TSF_BOUND | TSF_BINDING)) !=3D 0); } /* From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 22:10:46 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AFB010656CC for ; Thu, 26 Aug 2010 22:10:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 808A88FC0A for ; Thu, 26 Aug 2010 22:10:45 +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 BAA06779; Fri, 27 Aug 2010 01:10:43 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ookeg-000Pj7-Ob; Fri, 27 Aug 2010 01:10:42 +0300 Message-ID: <4C76E661.60600@icyb.net.ua> Date: Fri, 27 Aug 2010 01:10:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <201008261649.20543.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: sched_pin() bug in SCHED_ULE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 22:10:46 -0000 on 27/08/2010 00:20 mdf@FreeBSD.org said the following: > > I tried making sched_pin() a real function which used > intr_disable/intr_restore around saving off td->td_oncpu, > td->td_lastcpu and ts->ts_cpu, and the stack at the time of call. In > sched_switch when I saw an unexpected migration I printed all that > out. I found that on my boxes, at sched_pin() time ts_cpu was already > different from td->td_oncpu, so the specific problem I was having was > that while another thread can change ts_cpu it has no way to force > that thread to immediately migrate. Like e.g. in sched_affinity where ts_cpu is first changed and then the old cpu is ipi-ed? > I believe the below patch fixes the issue, though I'm open to other methods: > > > Index: kern/sched_ule.c > =================================================================== > --- kern/sched_ule.c (.../head/src/sys) (revision 158279) > +++ kern/sched_ule.c (.../branches/BR_BUG_67957/src/sys) (revision 158279) > @@ -112,6 +112,7 @@ > /* flags kept in ts_flags */ > #define TSF_BOUND 0x0001 /* Thread can not migrate. */ > #define TSF_XFERABLE 0x0002 /* Thread was added as transferable. */ > +#define TSF_BINDING 0x0004 /* Thread is being bound. */ I don't really follow why TSF_BINDING is needed, i.e. why TSF_BOUND is not sufficient in this case? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 22:24:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C8C10656A9 for ; Thu, 26 Aug 2010 22:24:39 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 271908FC13 for ; Thu, 26 Aug 2010 22:24:38 +0000 (UTC) Received: by ewy4 with SMTP id 4so1827020ewy.13 for ; Thu, 26 Aug 2010 15:24: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=AFvfxNmUuCyjItBzkqTouJJBJdEG6egXItEN1Lan0L4=; b=shL/D3EWfkK487rhdxYhBK+cuJtSsJVo/oR97AnVJbjORkwB7/NSryVfeYMhGVDbXg 3N4Dv+UJ5dAVSNCshMUS59FXkwdar2K6RRlYbCxBfqzVwo1VhpxyYEwvWwh3temzb9NR fcG/Li3H+m9VflQB/NaK24IVecA84V065VuT8= 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=TnJLpKgOIQRh184K0Cl6+Jg7HaTNSsRnVSquZWxG3UJ0LyB0+ptcvsvY6o/ZuAnxr9 66Z6zUUV1Ftet/0Fl9ahOjTuLoHXZRFA7Iobieb/83RVDz1dErKmxYMVn80yyM+a5paK BGr00Gz+b/Osytp2ov47hd25LD+jN0nKSuvHY= MIME-Version: 1.0 Received: by 10.213.47.76 with SMTP id m12mr1453405ebf.43.1282861477922; Thu, 26 Aug 2010 15:24:37 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.213.20.144 with HTTP; Thu, 26 Aug 2010 15:24:37 -0700 (PDT) In-Reply-To: <4C76E661.60600@icyb.net.ua> References: <201008261649.20543.jhb@freebsd.org> <4C76E661.60600@icyb.net.ua> Date: Thu, 26 Aug 2010 15:24:37 -0700 X-Google-Sender-Auth: fDOKo6L0PnjExsqxxCWDHpLmWig Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sched_pin() bug in SCHED_ULE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 22:24:39 -0000 On Thu, Aug 26, 2010 at 3:10 PM, Andriy Gapon wrote: > on 27/08/2010 00:20 mdf@FreeBSD.org said the following: >> >> I tried making sched_pin() a real function which used >> intr_disable/intr_restore around saving off td->td_oncpu, >> td->td_lastcpu and ts->ts_cpu, and the stack at the time of call. =A0In >> sched_switch when I saw an unexpected migration I printed all that >> out. =A0I found that on my boxes, at sched_pin() time ts_cpu was already >> different from td->td_oncpu, so the specific problem I was having was >> that while another thread can change ts_cpu it has no way to force >> that thread to immediately migrate. > > Like e.g. in sched_affinity where ts_cpu is first changed and then the ol= d cpu > is ipi-ed? That could do it. I didn't follow the stack of the places that were touching ts_cpu for non-curthread. >> I believe the below patch fixes the issue, though I'm open to other meth= ods: >> >> >> Index: kern/sched_ule.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- kern/sched_ule.c =A0(.../head/src/sys) =A0 =A0 =A0(revision 158279) >> +++ kern/sched_ule.c =A0(.../branches/BR_BUG_67957/src/sys) =A0 =A0 (rev= ision 158279) >> @@ -112,6 +112,7 @@ >> =A0/* flags kept in ts_flags */ >> =A0#define =A0 =A0 =A0TSF_BOUND =A0 =A0 =A0 0x0001 =A0 =A0 =A0 =A0 =A0/*= Thread can not migrate. */ >> =A0#define =A0 =A0 =A0TSF_XFERABLE =A0 =A00x0002 =A0 =A0 =A0 =A0 =A0/* T= hread was added as transferable. */ >> +#define =A0 =A0 =A0TSF_BINDING =A0 =A0 0x0004 =A0 =A0 =A0 =A0 =A0/* Thr= ead is being bound. */ > > I don't really follow why TSF_BINDING is needed, i.e. why TSF_BOUND is no= t > sufficient in this case? I wanted to tighten up the asserts, so that the only time it was okay for a td_pinned thread to migrate was the one time it was moving to the target cpu. Having a separate flag allows that. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 22:35:40 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 623BF1065675 for ; Thu, 26 Aug 2010 22:35:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9AA8FC0A for ; Thu, 26 Aug 2010 22:35:39 +0000 (UTC) Received: (qmail 24732 invoked by uid 399); 26 Aug 2010 22:35:39 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Aug 2010 22:35:39 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C76EC39.9020500@FreeBSD.org> Date: Thu, 26 Aug 2010 15:35:37 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Apparent regression in extended/logical partition handling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 22:35:40 -0000 Howdy, Summary: FreeBSD 9-current can't "see" logical drives inside an extended partition unless all space is assigned to a logical volume, and all logical volumes are formatted with a file system. 7.3-RELEASE does not have this problem. Background: So I got a new HD, and wanted to put Windows, a fat 32 data partition, 2 FreeBSDs, and Linux on it. After much juggling, cursing, etc. I finally hit upon a solution. Windows and FreeBSDs in primary partitions, and fat32-data and Linux in an extended partition. Voila! My first pass at this configuration had the 3 primary partitions first, but the linux (ubuntu gnome to be specific) "Disk Utility" tool was showing all the freebsd-style partitions (ad[12]s[a-f]) as linux-style partitions (sdaN) under the extended dos-style partition, which not only looked odd, but other tools on the linux desktop (such as Nautilus) were confused by this. So I looked on line and found a how-to that said this is caused by having the extended partition last, and the confusion can be avoided if I put the extended partition 2nd, and the 2 FreeBSD partitions after it. So I did that, and unfortunately it did not help Nautilus be any less confused. However, it did lead to what I think is a regression in -current. Specifically what I did was to boot Windows XP, delete all the partitions other than the XP partition (first primary dos-style partition) and then create a dos-style extended partition, and a logical drive inside of it, leaving room for linux in that same extended partition. Since I want that data volume to be fat32, and it is too large for windows to do it, I next installed FreeBSD 9-current, in a dos-style primary partition. I got it installed fine, but when I booted into FreeBSD 9 to format the logical volume it could not see it. fdisk showed the right information about the extended partition, but in /dev instead of seeing no ad0s2 and seeing ad0s5 like I expected instead there was no ad0s5 and there were ad0s2 entries that mirrored the ad0s3 that FreeBSD 9 was installed on. IOW, I had ad0s3 and ad0s3[a-f] as expected, but I had the same for ad0s2 even though they were obviously not valid. "Well that's odd" I thought, but undaunted I proceeded to install FreeBSD 7.3-RELEASE in the last dos-style primary partition. When I booted it I could see the expected set of entries in /dev, and was finally able to newfs the fat32 volume. After confirming that Windows can see the fat32 volume I proceeded to boot FreeBSD 9 again. Still no joy. So then I proceeded with the Linux install (using up the last of the space inside the extended partition) and now FreeBSD 9 has the expected entries in /dev, and I can mount the fat32 volume. Haven't tried mounting the Linux volumes yet, although the right number of entries are there in /dev. So this appears to be an actual bug/regression. FYI, after getting everything installed and working I did not nuke it all again to see if moving the extended partition last fixed the issue for FreeBSD 9, but I sort of vaguely recall that when I did the install the first time (with extended at the end) I couldn't see it in FreeBSD 9 either; but didn't dwell on it. One side note, I was taught "back in the day" that dos-style extended partitions always had to be at the end of the disk. Before trying the configuration I have I searched quite a few places to find a reference to that rule and couldn't find one. Perhaps this is something that's actually improved in the PC world in the last 25 years? :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 00:50:26 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0631065674; Fri, 27 Aug 2010 00:50:26 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3145B8FC0C; Fri, 27 Aug 2010 00:50:26 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 0A0DDA6045E; Fri, 27 Aug 2010 08:50:25 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id EW4kt63j2FmH; Fri, 27 Aug 2010 08:50:19 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 6B070A5FC43; Fri, 27 Aug 2010 08:50:12 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:x-enigmail-version:openpgp:content-type; b=I4GHk3HimcDBLUAG8LaIoDFV6qKm7x+6aq4BT7NBfKdKxnvDg59Ulu0PL+ZGm50Zv DJ78y7knKGwp9G7VikFgw== Message-ID: <4C770BB9.2070900@delphij.net> Date: Thu, 26 Aug 2010 17:50:01 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------050307080802070809060606" Cc: Subject: [PATCH] Use MACHINE_ARCH for boot loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 00:50:27 -0000 This is a multi-part message in MIME format. --------------050307080802070809060606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and FreeBSD/amd64 on amd64. Comments welcome! I'll commit it in by the weekend if there is no objection on this. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMdwu5AAoJEATO+BI/yjfBe+4H/i/LVqSlVP4XbQ8Xfzs2x0Xr pv+sOtSMOKOBmtKb6KrTxyZ/GyLTAxxERlJCDLuxFZ1fVZ+E+q3BrhNRyJGcCjYx 6B3gdFwgiOlZbbFw/FGrI0W32xbeTnzd4oHqZWli4Nn6L7h+smX+O11aFaAg4ktG y8E3ngJrG3ublbUskJ6/Vbi2xIbkTt0iPPa7jZlGGU2rTrLGTtB7E/5GNIXbiOWe NwfKW+c2vaNCWTzwrUM/jHAkVgM3ZFXVEwx0BFGuhY4Rc2z5sGLwvpbueNT7xkTv Y6goyuw6vwxnxA6ps2eka38Dz1JsoDNXsdFgpkgEF57c1hROSHF39lJhIfEB5t8= =HL2J -----END PGP SIGNATURE----- --------------050307080802070809060606 Content-Type: text/plain; name="boot.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="boot.diff" SW5kZXg6IHN5cy9ib290L2kzODYvYm9vdDIvYm9vdDIuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvYm9vdC9pMzg2L2Jvb3QyL2Jvb3QyLmMJKHJldmlzaW9uIDIxMTg0NykKKysrIHN5cy9i b290L2kzODYvYm9vdDIvYm9vdDIuYwkod29ya2luZyBjb3B5KQpAQCAtMjgzLDcgKzI4Myw3 IEBAIG1haW4odm9pZCkKIAogICAgIGZvciAoOzspIHsKIAlpZiAoIWF1dG9ib290IHx8ICFP UFRfQ0hFQ0soUkJYX1FVSUVUKSkKLQkgICAgcHJpbnRmKCJcbkZyZWVCU0QveDg2IGJvb3Rc biIKKwkgICAgcHJpbnRmKCJcbkZyZWVCU0QvIiBNQUNISU5FX0FSQ0ggIiBib290XG4iCiAJ CSAgICJEZWZhdWx0OiAldTolcygldSwlYyklc1xuIgogCQkgICAiYm9vdDogIiwKIAkJICAg ZHNrLmRyaXZlICYgRFJWX01BU0ssIGRldl9ubVtkc2sudHlwZV0sIGRzay51bml0LApJbmRl eDogc3lzL2Jvb3QvaTM4Ni9ib290Mi9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv Ym9vdC9pMzg2L2Jvb3QyL01ha2VmaWxlCShyZXZpc2lvbiAyMTE4NDcpCisrKyBzeXMvYm9v dC9pMzg2L2Jvb3QyL01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0zNCw2ICszNCw3IEBA IENGTEFHUz0JLU9zIFwKIAktbW5vLW1teCAtbW5vLTNkbm93IC1tbm8tc3NlIC1tbm8tc3Nl MiAtbW5vLXNzZTMgXAogCS1EJHtCT09UMl9VRlN9IFwKIAktREZMQUdTPSR7Qk9PVF9CT09U MV9GTEFHU30gXAorCS1ETUFDSElORV9BUkNIPVwiJHtNQUNISU5FX0FSQ0h9XCIgXAogCS1E U0lPUFJUPSR7Qk9PVF9DT01DT05TT0xFX1BPUlR9IFwKIAktRFNJT0ZNVD0ke0IyU0lPRk1U fSBcCiAJLURTSU9TUEQ9JHtCT09UX0NPTUNPTlNPTEVfU1BFRUR9IFwKSW5kZXg6IHN5cy9i b290L2kzODYvemZzYm9vdC96ZnNib290LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Jvb3Qv aTM4Ni96ZnNib290L3pmc2Jvb3QuYwkocmV2aXNpb24gMjExODQ3KQorKysgc3lzL2Jvb3Qv aTM4Ni96ZnNib290L3pmc2Jvb3QuYwkod29ya2luZyBjb3B5KQpAQCAtNzMxLDcgKzczMSw3 IEBAIG1haW4odm9pZCkKIAogICAgIGZvciAoOzspIHsKIAlpZiAoIWF1dG9ib290IHx8ICFP UFRfQ0hFQ0soUkJYX1FVSUVUKSkKLQkgICAgcHJpbnRmKCJcbkZyZWVCU0QveDg2IGJvb3Rc biIKKwkgICAgcHJpbnRmKCJcbkZyZWVCU0QvIiBNQUNISU5FX0FSQ0ggIiBib290XG4iCiAJ CSAgICJEZWZhdWx0OiAlczolc1xuIgogCQkgICAiYm9vdDogIiwKIAkJICAgc3BhLT5zcGFf bmFtZSwga25hbWUpOwpJbmRleDogc3lzL2Jvb3QvaTM4Ni96ZnNib290L01ha2VmaWxlCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHN5cy9ib290L2kzODYvemZzYm9vdC9NYWtlZmlsZQkocmV2aXNp b24gMjExODQ3KQorKysgc3lzL2Jvb3QvaTM4Ni96ZnNib290L01ha2VmaWxlCSh3b3JraW5n IGNvcHkpCkBAIC0yNiw2ICsyNiw3IEBAIENGTEFHUz0JLU9zIC1nIFwKIAktbW5vLW1teCAt bW5vLTNkbm93IC1tbm8tc3NlIC1tbm8tc3NlMiAtbW5vLXNzZTMgXAogCS1EQk9PVDIgXAog CS1ERkxBR1M9JHtCT09UX0JPT1QxX0ZMQUdTfSBcCisJLURNQUNISU5FX0FSQ0g9XCIke01B Q0hJTkVfQVJDSH1cIiBcCiAJLURTSU9QUlQ9JHtCT09UX0NPTUNPTlNPTEVfUE9SVH0gXAog CS1EU0lPRk1UPSR7QjJTSU9GTVR9IFwKIAktRFNJT1NQRD0ke0JPT1RfQ09NQ09OU09MRV9T UEVFRH0gXApJbmRleDogc3lzL2Jvb3QvaTM4Ni96ZnNsb2FkZXIvTWFrZWZpbGUKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gc3lzL2Jvb3QvaTM4Ni96ZnNsb2FkZXIvTWFrZWZpbGUJKHJldmlzaW9u IDIxMTg0NykKKysrIHN5cy9ib290L2kzODYvemZzbG9hZGVyL01ha2VmaWxlCSh3b3JraW5n IGNvcHkpCkBAIC0zLDcgKzMsNyBAQAogLlBBVEg6CSR7LkNVUkRJUn0vLi4vbG9hZGVyCiAK IExPQURFUj0JCXpmc2xvYWRlcgotTkVXVkVSU1dIQVQ9CSJaRlMgZW5hYmxlZCBib290c3Ry YXAgbG9hZGVyIiBpMzg2CitORVdWRVJTV0hBVD0JIlpGUyBlbmFibGVkIGJvb3RzdHJhcCBs b2FkZXIiICR7TUFDSElORV9BUkNIfQogTE9BREVSX1pGU19TVVBQT1JUPXllcwogTE9BREVS X09OTFk9CXllcwogTk9fTUFOPQkJeWVzCkluZGV4OiBzeXMvYm9vdC9pMzg2L2xvYWRlci9N YWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYm9vdC9pMzg2L2xvYWRlci9NYWtlZmls ZQkocmV2aXNpb24gMjExODQ3KQorKysgc3lzL2Jvb3QvaTM4Ni9sb2FkZXIvTWFrZWZpbGUJ KHdvcmtpbmcgY29weSkKQEAgLTYsNyArNiw3IEBAIE1LX1NTUD0JCW5vCiBMT0FERVI/PQls b2FkZXIKIFBST0c9CQkke0xPQURFUn0uc3ltCiBJTlRFUk5BTFBST0c9Ci1ORVdWRVJTV0hB VD89CSJib290c3RyYXAgbG9hZGVyIiBpMzg2CitORVdWRVJTV0hBVD89CSJib290c3RyYXAg bG9hZGVyIiAke01BQ0hJTkVfQVJDSH0KIAogIyBhcmNoaXRlY3R1cmUtc3BlY2lmaWMgbG9h ZGVyIGNvZGUKIFNSQ1M9CQltYWluLmMgY29uZi5jIHZlcnMuYwpJbmRleDogc3lzL2Jvb3Qv aTM4Ni9ncHRib290L2dwdGJvb3QuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYm9vdC9pMzg2 L2dwdGJvb3QvZ3B0Ym9vdC5jCShyZXZpc2lvbiAyMTE4NDcpCisrKyBzeXMvYm9vdC9pMzg2 L2dwdGJvb3QvZ3B0Ym9vdC5jCSh3b3JraW5nIGNvcHkpCkBAIC0yODEsNyArMjgxLDcgQEAg bWFpbih2b2lkKQogCiAgICAgZm9yICg7OykgewogCWlmICghYXV0b2Jvb3QgfHwgIU9QVF9D SEVDSyhSQlhfUVVJRVQpKQotCSAgICBwcmludGYoIlxuRnJlZUJTRC94ODYgYm9vdFxuIgor CSAgICBwcmludGYoIlxuRnJlZUJTRC8iIE1BQ0hJTkVfQVJDSCAiIGJvb3RcbiIKIAkJICAg IkRlZmF1bHQ6ICV1OiVzKCV1cCV1KSVzXG4iCiAJCSAgICJib290OiAiLAogCQkgICBkc2su ZHJpdmUgJiBEUlZfTUFTSywgZGV2X25tW2Rzay50eXBlXSwgZHNrLnVuaXQsCkluZGV4OiBz eXMvYm9vdC9pMzg2L2dwdGJvb3QvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Jv b3QvaTM4Ni9ncHRib290L01ha2VmaWxlCShyZXZpc2lvbiAyMTE4NDcpCisrKyBzeXMvYm9v dC9pMzg2L2dwdGJvb3QvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTI3LDYgKzI3LDcg QEAgQ0ZMQUdTPQktT3MgXAogCS1tcnRkIFwKIAktbW5vLW1teCAtbW5vLTNkbm93IC1tbm8t c3NlIC1tbm8tc3NlMiAtbW5vLXNzZTMgXAogCS1EJHtHUFRCT09UX1VGU30gXAorCS1ETUFD SElORV9BUkNIPVwiJHtNQUNISU5FX0FSQ0h9XCIgXAogCS1EU0lPUFJUPSR7Qk9PVF9DT01D T05TT0xFX1BPUlR9IFwKIAktRFNJT0ZNVD0ke0IyU0lPRk1UfSBcCiAJLURTSU9TUEQ9JHtC T09UX0NPTUNPTlNPTEVfU1BFRUR9IFwK --------------050307080802070809060606-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 02:23:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D55E1065697 for ; Fri, 27 Aug 2010 02:23:59 +0000 (UTC) (envelope-from edhoprima@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 CB7908FC12 for ; Fri, 27 Aug 2010 02:23:58 +0000 (UTC) Received: by iwn36 with SMTP id 36so2429530iwn.13 for ; Thu, 26 Aug 2010 19:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=u29J6KGTYaD03DeF+QYp2pqZ49wtk3lCX8g11Hy+35Q=; b=x1cndqlVncUB8OREaOTzIbGXs37j4SPDy9EQCBhNT2o+RX5reaif57nVwvWGe6bl3J ddYTeK7tMxkCD0kMu7qFXORxSpLwCHneMKrD9nV4cUa6qKrQOP19GOq/cs86rCHCJJTM dPWeYC+GXF6pcgWUgpLKQpTK1BnfQBTjS9A4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=RCZ+nUyXr372DvPdnXm2FIawCnm0CkP2XEUeAO5OvafrvOj+Zq9et7nEda1ANOgshU 81wWDbZhXlQLxDCY6S8E7pf+Ba4tSneKbhp1EEGb7ScKNiNNGzJzfW7FTceUqAyMSG8+ RnNxNTY9pZctttmzeOem7Av8fN6IiivPEqeQ4= Received: by 10.231.31.71 with SMTP id x7mr300024ibc.33.1282874028132; Thu, 26 Aug 2010 18:53:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.168.83 with HTTP; Thu, 26 Aug 2010 18:53:28 -0700 (PDT) In-Reply-To: <4C76EC39.9020500@FreeBSD.org> References: <4C76EC39.9020500@FreeBSD.org> From: Edho P Arief Date: Fri, 27 Aug 2010 08:53:28 +0700 Message-ID: To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Apparent regression in extended/logical partition handling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 02:23:59 -0000 On Fri, Aug 27, 2010 at 5:35 AM, Doug Barton wrote: > Specifically what I did was to boot Windows XP, delete all the partitions > other than the XP partition (first primary dos-style partition) and then > create a dos-style extended partition, and a logical drive inside of it, > leaving room for linux in that same extended partition. Since I want that > data volume to be fat32, and it is too large for windows to do it, I next > installed FreeBSD 9-current, in a dos-style primary partition. I got it > installed fine, but when I booted into FreeBSD 9 to format the logical > volume it could not see it. fdisk showed the right information about the > extended partition, but in /dev instead of seeing no ad0s2 and seeing ad0s5 > like I expected instead there was no ad0s5 and there were ad0s2 entries that > mirrored the ad0s3 that FreeBSD 9 was installed on. IOW, I had ad0s3 and > ad0s3[a-f] as expected, but I had the same for ad0s2 even though they were > obviously not valid. how does it look like in # gpart show ? > One side note, I was taught "back in the day" that dos-style extended > partitions always had to be at the end of the disk. Before trying the > configuration I have I searched quite a few places to find a reference to > that rule and couldn't find one. Perhaps this is something that's actually > improved in the PC world in the last 25 years? :) after 25 years, x86 world finally started adapting GPT :) -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 04:18:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528CB1065670; Fri, 27 Aug 2010 04:18:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9458FC13; Fri, 27 Aug 2010 04:18:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7R4IZwh044088; Fri, 27 Aug 2010 00:18:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7R4IZEC044083; Fri, 27 Aug 2010 04:18:35 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Aug 2010 04:18:35 GMT Message-Id: <201008270418.o7R4IZEC044083@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 04:18:37 -0000 TB --- 2010-08-27 03:49:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-27 03:49:08 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-27 03:49:08 - cleaning the object tree TB --- 2010-08-27 03:49:22 - cvsupping the source tree TB --- 2010-08-27 03:49:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-27 03:50:12 - building world TB --- 2010-08-27 03:50:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-27 03:50:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-27 03:50:12 - TARGET=powerpc TB --- 2010-08-27 03:50:12 - TARGET_ARCH=powerpc64 TB --- 2010-08-27 03:50:12 - TZ=UTC TB --- 2010-08-27 03:50:12 - __MAKE_CONF=/dev/null TB --- 2010-08-27 03:50:12 - cd /src TB --- 2010-08-27 03:50:12 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 27 03:50:12 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-27 04:18:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-27 04:18:35 - ERROR: failed to build world TB --- 2010-08-27 04:18:35 - 1145.49 user 368.49 system 1766.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 04:35:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93668106566B for ; Fri, 27 Aug 2010 04:35:36 +0000 (UTC) (envelope-from ccuiyyan@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 5D48F8FC13 for ; Fri, 27 Aug 2010 04:35:36 +0000 (UTC) Received: by iwn36 with SMTP id 36so2539533iwn.13 for ; Thu, 26 Aug 2010 21:35: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:date:message-id :subject:from:to:content-type; bh=yVjRbZDwWhNAtCbGy8UePSkpavjm4/X2HPr/0D/qaNw=; b=pC86M/hCIxS5qsb+Qcm6CnU2OYVIRkrEDRz+nrv2BwwP10JEVHNmj2fNsWVrKQF0u1 hO/eAsPWOB5j2x90pm2C4kTsrsHrso+M7AwUwpeOEVvxotd0LnDX1yKCuXNOI/qoZtgX EpUCiVWaZapwN+cCzGFb1VAYHnynsryNNkInk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IJ2NvC4PtUWqf8HR0vUkvW4RAU2W6RzWSblTJvcAemdCsBckQzPSluEiX1nPFEUju4 Oj79Ia8b9Jq2FRlcax3zB9Hhm/h+75TV6Zvcps/dpNntoJT+buCnFEKPkGaX0NBKdylv UMB28mbvWZ+QuSWNV9qSwGl8ua8n+qslK8DxM= MIME-Version: 1.0 Received: by 10.231.59.1 with SMTP id j1mr461007ibh.55.1282882031427; Thu, 26 Aug 2010 21:07:11 -0700 (PDT) Received: by 10.231.188.229 with HTTP; Thu, 26 Aug 2010 21:07:11 -0700 (PDT) Date: Fri, 27 Aug 2010 12:07:11 +0800 Message-ID: From: =?GB2312?B?tN7R0mNjdWl5eWFuQGdtYWlsLmNvbQ==?= To: freebsd-current@freebsd.org X-Mailman-Approved-At: Fri, 27 Aug 2010 05:07:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 04:35:36 -0000 Dear all: A quick question about the FreeBSD. In my lab, there is a multicore machine and i install a FreeBSD system on it. I wonder to know how to see the utilization for each core? are there such tools? Thanks! -- Think big; Dream impossible; Make it happen. From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 05:10:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A84E1065693 for ; Fri, 27 Aug 2010 05:10:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 623278FC08 for ; Fri, 27 Aug 2010 05:10:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o7R5AGce025896; Thu, 26 Aug 2010 22:10:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o7R5AGkD025895; Thu, 26 Aug 2010 22:10:16 -0700 (PDT) (envelope-from sgk) Date: Thu, 26 Aug 2010 22:10:15 -0700 From: Steve Kargl To: "????ccuiyyan@gmail.com" Message-ID: <20100827051015.GA25885@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 05:10:16 -0000 On Fri, Aug 27, 2010 at 12:07:11PM +0800, ????ccuiyyan@gmail.com wrote: > Dear all: > > A quick question about the FreeBSD. In my lab, there is a multicore > machine and i install a FreeBSD > system on it. I wonder to know how to see the utilization for each > core? are there such tools? Thanks! > Wrong mailing list. Try freebsd-question@freebsd.org. Also, try man top. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 06:12:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C9B51065670 for ; Fri, 27 Aug 2010 06:12:41 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (svr20881129-177.ihostservers.net [208.81.129.177]) by mx1.freebsd.org (Postfix) with ESMTP id 069F78FC28 for ; Fri, 27 Aug 2010 06:12:40 +0000 (UTC) Received: from bigguy.am-productions.biz (adsl-99-174-178-97.dsl.wotnoh.sbcglobal.net [99.174.178.97]) (authenticated bits=0) by mail.united-ware.com (8.14.3/8.14.3) with ESMTP id o7R5gxeR011582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Aug 2010 01:42:59 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Fri, 27 Aug 2010 01:45:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <20100823134723.GC64651@hoeg.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4880343.zCa5A4Wjn5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008270145.40699.mistry.7@osu.edu> Cc: Kostik Belousov , Ed Schouten , Ian FREISLICH Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 06:12:41 -0000 --nextPart4880343.zCa5A4Wjn5 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Monday 23 August 2010 10:57:40 Ian FREISLICH wrote: > Ian FREISLICH wrote: > > So, in this case is the fusefs module broken? I'm guessing it is. > > I don't like the way fuse_fileops is initialised in fuse4bsd. I > > would prefer for the struct to be zeroed and then the fo_xxx > > implimented bits set as appropriate. That way when the struct is > > changed, you don't get stung again. >=20 > I am an idiot - that will have no effect. This patch needs to be > included in sysutils/fusefs-kmod/files Would you file a PR with the patch accounting for the correct=20 __FreeBSD_version__? Thanks, =2D-=20 Anish Mistry --nextPart4880343.zCa5A4Wjn5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEABECAAYFAkx3UQQACgkQxqA5ziudZT0PbQCgyzpcJSFupM20S5rsGh3osZw3 Nb8AnjO1XKofGyaNsqhRF8/AbXSjEjOK =ablL -----END PGP SIGNATURE----- --nextPart4880343.zCa5A4Wjn5-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 08:25:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 635CA1065696 for ; Fri, 27 Aug 2010 08:25:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CF57A8FC15 for ; Fri, 27 Aug 2010 08:25:01 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7R8OYo2022530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Aug 2010 11:24:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7R8OYg2045776; Fri, 27 Aug 2010 11:24:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7R8OYHo045748; Fri, 27 Aug 2010 11:24:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Aug 2010 11:24:34 +0300 From: Kostik Belousov To: d@delphij.net Message-ID: <20100827082434.GW2396@deviant.kiev.zoral.com.ua> References: <4C770BB9.2070900@delphij.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4RKFTa9IRjtxz5WY" Content-Disposition: inline In-Reply-To: <4C770BB9.2070900@delphij.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: [PATCH] Use MACHINE_ARCH for boot loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 08:25:02 -0000 --4RKFTa9IRjtxz5WY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 26, 2010 at 05:50:01PM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi, >=20 > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > FreeBSD/amd64 on amd64. >=20 > Comments welcome! I'll commit it in by the weekend if there is no > objection on this. Change to FreeBSD/x86 was on purpose. And, since the same loader can boot both i386 and amd64 kernels, I consider the current state more logical. Later, kernel reports its architecture explicitely. --4RKFTa9IRjtxz5WY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx3dkIACgkQC3+MBN1Mb4jmtwCfT/LCdCbArz1KdWD7FjWfZdzH 11sAoNuUMhLZoaEIx81PJYwTbr3k5HDh =SQ8C -----END PGP SIGNATURE----- --4RKFTa9IRjtxz5WY-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 08:25:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 327B31065697 for ; Fri, 27 Aug 2010 08:25:40 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 026EF8FC27 for ; Fri, 27 Aug 2010 08:25:39 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id 550924B781B; Fri, 27 Aug 2010 16:10:37 +0800 (CST) Date: Fri, 27 Aug 2010 16:10:37 +0800 From: Denny Lin To: =?utf-8?B?5bSU5bKpY2N1aXl5YW5AZ21haWwuY29t?= Message-ID: <20100827081036.GG7511@mail.hs.ntnu.edu.tw> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 08:25:40 -0000 On Fri, Aug 27, 2010 at 12:07:11PM +0800, 崔岩ccuiyyan@gmail.com wrote: > A quick question about the FreeBSD. In my lab, there is a multicore > machine and i install a FreeBSD > system on it. I wonder to know how to see the utilization for each > core? are there such tools? Thanks! Try $ top -P. -- Denny Lin From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 08:36:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197A810656AC for ; Fri, 27 Aug 2010 08:36:22 +0000 (UTC) (envelope-from pluknet@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 C4F3A8FC20 for ; Fri, 27 Aug 2010 08:36:21 +0000 (UTC) Received: by qwg5 with SMTP id 5so2780099qwg.13 for ; Fri, 27 Aug 2010 01:36:21 -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=QlkZHKV+gOcd6CiC5EFpLblLWbM9HHsZVAeoUAmY/PM=; b=WNlrkV46NF4NLftBkKkOPPsG4k20MNLwVPTkNmWtXrJpFeydFqbvaY/uktjD1gdRnr 2r5ZVN1YEUFOaWZU5i8H/pRzyYc9tochKwTZwjuwikQtbCJEG8Ywb1sPwTgFfIMnoMFP S357e9d9NCoj1TOGaOgt4lPoYyfVH1tvr5yCY= 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=FqHMwpna6Bf2mkMfZOkURWCNb35I9Iu+RBR+1DwTzHD9OCY/rlTVSExjLovamS2SQf cUY6DkKmA+e7Fng49rhAyOXskPvEteCON/mr2q0HttSquwQ0jk0vS2U1VXcIBkNON3wf Qgas7dGtKjVy5IOYPgVieWhM3G6LBPT76X7so= MIME-Version: 1.0 Received: by 10.224.121.65 with SMTP id g1mr87543qar.370.1282898181049; Fri, 27 Aug 2010 01:36:21 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Fri, 27 Aug 2010 01:36:20 -0700 (PDT) In-Reply-To: <4C76D823.7070703@delphij.net> References: <4C76CA06.5010001@FreeBSD.org> <4C76D823.7070703@delphij.net> Date: Fri, 27 Aug 2010 12:36:20 +0400 Message-ID: From: pluknet To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 08:36:22 -0000 On 27 August 2010 01:09, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/08/26 13:09, Doug Barton wrote: >> On 08/26/2010 12:53 PM, pluknet wrote: >>> [cc'ing current@ as rc@ looks too quite] >>> >>> Hi. >>> >>> Since ifconfig has grown to label interfaces with >>> ifconfig $ifname description "foobar", what about >>> to give it more life and store i/face descriptions >>> semi-permanently, so they will survive between reboots? >>> >>> This patch adds a functionality to rc.d to label >>> interfaces at boot time. >>> >>> Comments are welcome. >> >> This seems like a good addition, thanks. Please also write a patch for >> rc.conf.5 to describe this new functionality and I'll be happy to commit >> it. =A0One note below. > > I have drafted one. Nice, thank you! With my poor English, this is a valuable help from you. > > (Note that fxp is a 100Mbps card so it might be sensible to replace it > with just Switch 2?) > Thanks for catching this. Will fix it. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 09:17:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E0FA1065670; Fri, 27 Aug 2010 09:17:18 +0000 (UTC) (envelope-from pluknet@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 0B7488FC12; Fri, 27 Aug 2010 09:17:17 +0000 (UTC) Received: by qwg5 with SMTP id 5so2806554qwg.13 for ; Fri, 27 Aug 2010 02:17:17 -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=6qpRf0y73wJhfdDgBA9ZiHoZG3msbNmLWHbC6Q/l+E0=; b=Fw94O2+DYD9Aq5+7Kr4f7Avylg1GcL0uwTSrWHaxG1vJkt5URbx3cTqQp2yMC6+Rbj o/1G2XUOIXvGCJd5oR4UQRSPhZqw47HYBg6UA5tC58YYxeGh/+TWhATIgioo+h8PpcGX mS0bNVMU0/WjOViJP2cWRQgEIX2ak5UbZuTZk= 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=pHe83f31en4z5KSseu9IQ1Sil+wiYC5zXkPqIRc+3dnkDBmN8UUz88Sr76Ybun6Bvh LBi9rZPf1IYiXngDIscmMeSWxe424CJjMlUoAhDlZnByW2QVKyGsx2941N9rl5/tJh3x h/ad08nTQ7+TSgXpYVnTD/7IpN/UNc3jb7gIA= MIME-Version: 1.0 Received: by 10.224.64.167 with SMTP id e39mr127007qai.271.1282900637299; Fri, 27 Aug 2010 02:17:17 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Fri, 27 Aug 2010 02:17:17 -0700 (PDT) In-Reply-To: <4C76CA06.5010001@FreeBSD.org> References: <4C76CA06.5010001@FreeBSD.org> Date: Fri, 27 Aug 2010 13:17:17 +0400 Message-ID: From: pluknet To: Doug Barton Content-Type: multipart/mixed; boundary=0016e64bbf02c4b4e7048eca940d Cc: FreeBSD Current , freebsd-rc@freebsd.org Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 09:17:18 -0000 --0016e64bbf02c4b4e7048eca940d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27 August 2010 00:09, Doug Barton wrote: > On 08/26/2010 12:53 PM, pluknet wrote: >> >> [cc'ing current@ as rc@ looks too quite] >> >> Hi. >> >> Since ifconfig has grown to label interfaces with >> ifconfig $ifname description "foobar", what about >> to give it more life and store i/face descriptions >> semi-permanently, so they will survive between reboots? >> >> This patch adds a functionality to rc.d to label >> interfaces at boot time. >> >> Comments are welcome. > > This seems like a good addition, thanks. Please also write a patch for > rc.conf.5 to describe this new functionality and I'll be happy to commit = it. Xin Li helped me with updating rc.conf.5 (thanks!). It's included in attached patch. > =A0One note below. > > >> --- etc/network.subr =A0 =A0(revision 211280) >> +++ etc/network.subr =A0 =A0(working copy) >> @@ -1187,6 +1187,24 @@ >> =A0 =A0 =A0 =A0 return 0 >> =A0} >> >> +# ifnet_descr >> +# =A0 =A0 =A0Add description to all requested interfaces. >> +# >> +ifnet_descr() >> +{ >> + =A0 =A0 =A0 local _if _ifdescr >> + >> + =A0 =A0 =A0 # ifconfig_IF_descr >> + =A0 =A0 =A0 for _if in `ifconfig -l`; do >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ifdescr=3D"`get_if_var $_if ifconfig_IF_d= escr`" >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ ! -z "$_ifdescr" ]; then > > This is probably better as [ -n "$_ifdescr" ] > This was blindly copy&pasted after ifnet_rename(). So, it makes sense probably to change test expression there as well. [see ifnet_rename() proposed change below inline] This change to ifnet_rename() is not included in attached patch to not complicate things unnecessarily for now. Index: etc/network.subr =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 --- etc/network.subr (revision 211280) +++ etc/network.subr (working copy) @@ -1179,7 +1179,7 @@ # ifconfig_IF_name for _if in `ifconfig -l`; do _ifname=3D`get_if_var $_if ifconfig_IF_name` - if [ ! -z "$_ifname" ]; then + if [ -n "$_ifname" ]; then ifconfig $_if name $_ifname fi done --=20 wbr, pluknet --0016e64bbf02c4b4e7048eca940d Content-Type: application/octet-stream; name="descr.rc.d.2.diff" Content-Disposition: attachment; filename="descr.rc.d.2.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gdctruj10 SW5kZXg6IGV0Yy9yYy5kL25ldGlmCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9yYy5kL25ldGlmCShyZXZp c2lvbiAyMTEyODApCisrKyBldGMvcmMuZC9uZXRpZgkod29ya2luZyBjb3B5KQpAQCAtNzUsNiAr NzUsOSBAQAogCiAJCSMgUmVuYW1lIGludGVyZmFjZXMuCiAJCWlmbmV0X3JlbmFtZQorCisJCSMg R2l2ZSBkZXNjcmlwdGlvbiB0byBpbnRlcmZhY2VzLgorCQlpZm5ldF9kZXNjcgogCWZpCiAKIAkj IENvbmZpZ3VyZSB0aGUgaW50ZXJmYWNlKHMpLgpJbmRleDogZXRjL25ldHdvcmsuc3Vicgo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBldGMvbmV0d29yay5zdWJyCShyZXZpc2lvbiAyMTEyODApCisrKyBldGMvbmV0 d29yay5zdWJyCSh3b3JraW5nIGNvcHkpCkBAIC0xMTg3LDYgKzExODcsMjQgQEAKIAlyZXR1cm4g MAogfQogCisjIGlmbmV0X2Rlc2NyCisjCUFkZCBkZXNjcmlwdGlvbiB0byBhbGwgcmVxdWVzdGVk IGludGVyZmFjZXMuCisjCitpZm5ldF9kZXNjcigpCit7CisJbG9jYWwgX2lmIF9pZmRlc2NyCisK KwkjIGlmY29uZmlnX0lGX2Rlc2NyCisJZm9yIF9pZiBpbiBgaWZjb25maWcgLWxgOyBkbworCQlf aWZkZXNjcj0iYGdldF9pZl92YXIgJF9pZiBpZmNvbmZpZ19JRl9kZXNjcmAiCisJCWlmIFsgLW4g IiRfaWZkZXNjciIgXTsgdGhlbgorCQkJaWZjb25maWcgJF9pZiBkZXNjciAiJF9pZmRlc2NyIgor CQlmaQorCWRvbmUKKworCXJldHVybiAwCit9CisKICMgbGlzdF9uZXRfaW50ZXJmYWNlcyB0eXBl CiAjCUxpc3QgYWxsIG5ldHdvcmsgaW50ZXJmYWNlcy4gVGhlIHR5cGUgb2YgaW50ZXJmYWNlIHJl dHVybmVkCiAjCWNhbiBiZSBjb250cm9sbGVkIGJ5IHRoZSB0eXBlIGFyZ3VtZW50LiBUaGUgdHlw ZQpJbmRleDogZXRjL2RlZmF1bHRzL3JjLmNvbmYKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL2RlZmF1bHRz L3JjLmNvbmYJKHJldmlzaW9uIDIxMTI4MCkKKysrIGV0Yy9kZWZhdWx0cy9yYy5jb25mCSh3b3Jr aW5nIGNvcHkpCkBAIC0yMTUsNiArMjE1LDcgQEAKICNpZmNvbmZpZ19lZDBfaXB2Nj0iaW5ldDYg MjAwMTpkYjg6MTo6MSBwcmVmaXhsZW4gNjQiICMgU2FtcGxlIElQdjYgYWRkciBlbnRyeQogI2lm Y29uZmlnX2VkMF9hbGlhczA9ImluZXQ2IDIwMDE6ZGI4OjI6OjEgcHJlZml4bGVuIDY0IiAjIFNh bXBsZSBJUHY2IGFsaWFzCiAjaWZjb25maWdfZnhwMF9uYW1lPSJuZXQwIgkjIENoYW5nZSBpbnRl cmZhY2UgbmFtZSBmcm9tIGZ4cDAgdG8gbmV0MC4KKyNpZmNvbmZpZ19meHAwX2Rlc2NyPSJVcGxp bmsgdG8gU3dpdGNoIDIiCSMgTGFiZWwgZnhwMCBpbnRlcmZhY2UKICN2bGFuc19meHAwPSIxMDEg dmxhbjAiCQkjIHZsYW4oNCkgaW50ZXJmYWNlcyBmb3IgZnhwMCBkZXZpY2UKICNjcmVhdGVfYXJn X3ZsYW4wPSJ2bGFuIDEwMiIJIyB2bGFuIHRhZyBmb3IgdmxhbjAgZGV2aWNlCiAjd2xhbnNfYXRo MD0id2xhbjAiCQkjIHdsYW4oNCkgaW50ZXJmYWNlcyBmb3IgYXRoMCBkZXZpY2UKSW5kZXg6IHNo YXJlL21hbi9tYW41L3JjLmNvbmYuNQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFuNS9yYy5j b25mLjUJKHJldmlzaW9uIDIwOTY2NCkKKysrIHNoYXJlL21hbi9tYW41L3JjLmNvbmYuNQkod29y a2luZyBjb3B5KQpAQCAtMTEyOCw2ICsxMTI4LDE5IEBACiB2YXJpYWJsZXMuCiAuUHAKIElmIGEK Ky5WYSBpZmNvbmZpZ18gTnMgQW8gQXIgaW50ZXJmYWNlIEFjIE5zIFZhIF9kZXNjcgordmFyaWFi bGUgaXMgc2V0LCB0aGUgaW50ZXJmYWNlIHdvdWxkIGJlIGFzc2lnbmVkIHRoZSBkZXNjcmlwdGlv bgorc3BlY2lmaWVkIGJ5IHRoZSB2YXJpYWJsZS4KKy5QcAorVG8gYXNzaWduIGFuIGRlc2NyaXB0 aW9uIG9mCisuRHEgVXBsaW5rIHRvIEdpZ2FiaXQgU3dpdGNoIDEKK29uIHRoZSBpbnRlcmZhY2Ug bmFtZWQKKy5MaSBlbTAgOgorLkJkIC1saXRlcmFsCitpZmNvbmZpZ19lbTBfZGVzY3I9IlVwbGlu ayB0byBHaWdhYml0IFN3aXRjaCAxIgorLkVkCisuUHAKK0lmIGEKIC5WYSB2bGFuc18gTnMgQXEg QXIgaW50ZXJmYWNlCiB2YXJpYWJsZSBpcyBzZXQsCiBhCg== --0016e64bbf02c4b4e7048eca940d-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 10:25:41 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29F1710656A4; Fri, 27 Aug 2010 10:25:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 410528FC1C; Fri, 27 Aug 2010 10:25:39 +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 NAA17443; Fri, 27 Aug 2010 13:25:38 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Oow7u-0002lf-BQ; Fri, 27 Aug 2010 13:25:38 +0300 Message-ID: <4C7792A1.9090909@icyb.net.ua> Date: Fri, 27 Aug 2010 13:25:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua> <4C72297D.90104@FreeBSD.org> <4C722ADD.1030103@icyb.net.ua> <4C7234A1.3050108@FreeBSD.org> In-Reply-To: <4C7234A1.3050108@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 10:25:41 -0000 on 23/08/2010 11:43 Doug Barton said the following: > Ok, so it seems that you're suggesting to disable throttling, so I added the > following to /boot/loader.conf: > > hint.p4tcc.0.disabled="1" > hint.p4tcc.1.disabled="1" > hint.acpi_throttle.0.disabled="1" > hint.acpi_throttle.1.disabled="1" > > Not sure the .1.'s are necessary, but I wanted to be thorough. With that I get: > dev.cpu.0.freq_levels: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 > dev.est.0.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 > dev.est.1.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 > > hopefully that's more in line with what it should be? I'd really like to be able > to at least use powerd since it does seem to help with heat when the system is > idle (and by extension, power consumption as well). > > Unless you say differently when I get up tomorrow I'll try this configuration > for a little while and see how it goes. So, how did this go? Did the change make any difference? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 11:32:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0EB5010656A9; Fri, 27 Aug 2010 11:32:50 +0000 (UTC) Date: Fri, 27 Aug 2010 11:32:50 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20100827113250.GA51376@freebsd.org> References: <4C770BB9.2070900@delphij.net> <20100827082434.GW2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100827082434.GW2396@deviant.kiev.zoral.com.ua> Cc: FreeBSD Current , d@delphij.net Subject: Re: [PATCH] Use MACHINE_ARCH for boot loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 11:32:50 -0000 On Fri Aug 27 10, Kostik Belousov wrote: > On Thu, Aug 26, 2010 at 05:50:01PM -0700, Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Hi, > > > > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > > FreeBSD/amd64 on amd64. > > > > Comments welcome! I'll commit it in by the weekend if there is no > > objection on this. > Change to FreeBSD/x86 was on purpose. And, since the same loader > can boot both i386 and amd64 kernels, I consider the current state > more logical. yeah. i think jhb wanted this to happen. the old thread for this can be found here [1]. there's also a PR with a patch submitted by myself which will make use of the keyword 'x86' throughout the whole loader(8) code. the PR number for that is 147120. would be nice if someone would commit the patch. that is of course if in fact it has really been decided that for code that's being shared between amd64 and i386 the keyword 'x86' shall be used consistently. however recently i've seen quite some commits to HEAD which make me believe that the developers (most of all jhb) want to make heavy use of the 'x86' keyword. cheers. alex > > Later, kernel reports its architecture explicitely. -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 11:46:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 031B8106564A; Fri, 27 Aug 2010 11:46:37 +0000 (UTC) Date: Fri, 27 Aug 2010 11:46:37 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20100827114637.GA55491@freebsd.org> References: <4C770BB9.2070900@delphij.net> <20100827082434.GW2396@deviant.kiev.zoral.com.ua> <20100827113250.GA51376@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100827113250.GA51376@freebsd.org> Cc: FreeBSD Current , d@delphij.net Subject: Re: [PATCH] Use MACHINE_ARCH for boot loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 11:46:38 -0000 On Fri Aug 27 10, Alexander Best wrote: > On Fri Aug 27 10, Kostik Belousov wrote: > > On Thu, Aug 26, 2010 at 05:50:01PM -0700, Xin LI wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > Hi, > > > > > > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > > > FreeBSD/amd64 on amd64. > > > > > > Comments welcome! I'll commit it in by the weekend if there is no > > > objection on this. > > Change to FreeBSD/x86 was on purpose. And, since the same loader > > can boot both i386 and amd64 kernels, I consider the current state > > more logical. > > yeah. i think jhb wanted this to happen. the old thread for this can be found > here [1]. oops. forgot the reference. :( it's [1] http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70613.html ...also r205662 seems to have introduced x86. the commit message might be interesting. cheers. alex > > there's also a PR with a patch submitted by myself which will make use of the > keyword 'x86' throughout the whole loader(8) code. > > the PR number for that is 147120. would be nice if someone would commit the > patch. that is of course if in fact it has really been decided that for code > that's being shared between amd64 and i386 the keyword 'x86' shall be used > consistently. > > however recently i've seen quite some commits to HEAD which make me believe > that the developers (most of all jhb) want to make heavy use of the 'x86' > keyword. > > cheers. > alex > > > > > Later, kernel reports its architecture explicitely. > > > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 13:37:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E66610656A5 for ; Fri, 27 Aug 2010 13:37:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED8B8FC0A for ; Fri, 27 Aug 2010 13:37:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BAFD546B2E; Fri, 27 Aug 2010 09:37:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CFFD78A04E; Fri, 27 Aug 2010 09:37:45 -0400 (EDT) From: John Baldwin To: d@delphij.net Date: Fri, 27 Aug 2010 09:34:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C770BB9.2070900@delphij.net> In-Reply-To: <4C770BB9.2070900@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008270934.56323.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 27 Aug 2010 09:37:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: FreeBSD Current Subject: Re: [PATCH] Use MACHINE_ARCH for boot loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 13:37:47 -0000 On Thursday, August 26, 2010 8:50:01 pm Xin LI wrote: > Hi, > > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > FreeBSD/amd64 on amd64. > > Comments welcome! I'll commit it in by the weekend if there is no > objection on this. As others have noted, the 'x86' is on purpose, and I would rather it continue to do that rather than this change. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 16:19:19 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D53A1065696 for ; Fri, 27 Aug 2010 16:19:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B71218FC15 for ; Fri, 27 Aug 2010 16:19:18 +0000 (UTC) Received: (qmail 20149 invoked by uid 399); 27 Aug 2010 16:19:16 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 27 Aug 2010 16:19:16 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C77E582.5080706@FreeBSD.org> Date: Fri, 27 Aug 2010 09:19:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua> <4C72297D.90104@FreeBSD.org> <4C722ADD.1030103@icyb.net.ua> <4C7234A1.3050108@FreeBSD.org> <4C7792A1.9090909@icyb.net.ua> In-Reply-To: <4C7792A1.9090909@icyb.net.ua> X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:19:19 -0000 On 08/27/2010 03:25 AM, Andriy Gapon wrote: > on 23/08/2010 11:43 Doug Barton said the following: >> Ok, so it seems that you're suggesting to disable throttling, so I added the >> following to /boot/loader.conf: >> >> hint.p4tcc.0.disabled="1" >> hint.p4tcc.1.disabled="1" >> hint.acpi_throttle.0.disabled="1" >> hint.acpi_throttle.1.disabled="1" >> >> Not sure the .1.'s are necessary, but I wanted to be thorough. With that I get: >> dev.cpu.0.freq_levels: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 >> dev.est.0.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 >> dev.est.1.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 >> >> hopefully that's more in line with what it should be? I'd really like to be able >> to at least use powerd since it does seem to help with heat when the system is >> idle (and by extension, power consumption as well). >> >> Unless you say differently when I get up tomorrow I'll try this configuration >> for a little while and see how it goes. > > So, how did this go? > Did the change make any difference? Yes, it improved things greatly. I first ran with just powerd for several hours and that worked fine. The next day I was able to use powerd and cx_lowest=C2 for the better part of a day (including watching a few flash videos). By the end of the day intr started to run away again, so not out of the woods yet, but at least this shows we're going in the right direction. Also, while poking around in the BIOS settings I noticed in one of the "information only" screens that I don't usually visit one line about the "minimum cpu speed" is 1.00 GHz, which the sysctl output above seems to verify. So where the throttling code was getting all those other numbers I don't know. Meanwhile I've actually not been running FreeBSD for most of this week I've been working on re-partitioning my new disk and running ubuntu. So 2 interesting pieces of information there, first the "CPU Frequency Scaling Monitor" for the gnome that comes with ubuntu never goes below 1 GHz, so that bit seems extra verified. Second, I can watch all the flash videos I want while doing other stuff in the background (like restoring the backups of my data) without any problems, so add that to windows in terms of OS' that work on this same hardware. Now that I have finally figured out how to boot windows, linux, and 2 FreeBSDs on the same disk I'll be able to set up 7-stable i386 and 9-current amd64 to see how they compare to the 9-current i386 I was using previously; so I should have more information in a few days. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 16:35:51 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E509106564A for ; Fri, 27 Aug 2010 16:35:51 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 934698FC1E for ; Fri, 27 Aug 2010 16:35:50 +0000 (UTC) Received: from [78.35.64.47] (helo=r500.local) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Op1hz-0005uJ-N0 for freebsd-current@FreeBSD.org; Fri, 27 Aug 2010 18:23:15 +0200 Date: Fri, 27 Aug 2010 18:21:08 +0200 From: Fabian Keil To: freebsd-current@FreeBSD.org Message-ID: <20100827182108.12764ff4@r500.local> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/gaK_zXOLYEbRERvZmi8AKtL"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: Subject: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:35:51 -0000 --Sig_/gaK_zXOLYEbRERvZmi8AKtL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. It aborts on exit (C-x C-c) after receiving SIGBUS: fk@r500 ~ $gdb emacs GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) run Starting program: /usr/local/bin/emacs=20 [New LWP 100281] [New Thread 1260600 (LWP 100281)] Program received signal SIGBUS, Bus error. [Switching to Thread 1260600 (LWP 100281)] 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 (gdb) where #0 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 #1 0x0000000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x00000008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 #3 0x00000008045682c7 in exit () from /lib/libc.so.7 #4 0x0000000000556817 in Fkill_emacs (arg=3DCould not find the frame base = for "Fkill_emacs". ) at emacs.c:2146 #5 0x0000000000600ec0 in Ffuncall (nargs=3D1, args=3D0x7fffffffc880) at ev= al.c:3024 #6 0x0000000000658d47 in Fbyte_code (bytestr=3D8602321, vector=3D8602357, = maxdepth=3D20) at bytecode.c:680 #7 0x00000000006017e6 in funcall_lambda (fun=3D8602229, nargs=3D0, arg_vec= tor=3D0x7fffffffcdc8) at eval.c:3211 #8 0x00000000006011e0 in Ffuncall (nargs=3D1, args=3D0x7fffffffcdc0) at ev= al.c:3070 #9 0x0000000000658d47 in Fbyte_code (bytestr=3D9558105, vector=3D9558141, = maxdepth=3D20) at bytecode.c:680 #10 0x00000000006017e6 in funcall_lambda (fun=3D9558029, nargs=3D1, arg_vec= tor=3D0x7fffffffd358) at eval.c:3211 #11 0x00000000006011e0 in Ffuncall (nargs=3D2, args=3D0x7fffffffd350) at ev= al.c:3070 #12 0x00000000005fb954 in Fcall_interactively (function=3D11961778, record_= flag=3D11544578, keys=3D20138021) at callint.c:869 #13 0x0000000000600f36 in Ffuncall (nargs=3D4, args=3D0x7fffffffd760) at ev= al.c:3030 #14 0x00000000006008fd in call3 (fn=3D11756290, arg1=3D11961778, arg2=3D115= 44578, arg3=3D20138021) at eval.c:2850 #15 0x000000000056b7ac in Fcommand_execute (cmd=3D11961778, record_flag=3D1= 1544578, keys=3D20138021, special=3D11544674) at keyboard.c:10507 #16 0x000000000055cc69 in read_char (commandflag=3D1, nmaps=3D2, maps=3D0x7= fffffffdb70, prev_event=3D11544578, used_mouse_menu=3D0x7fffffffded4, end_t= ime=3D0x0) at keyboard.c:3166 #17 0x000000000056880e in read_key_sequence (keybuf=3D0x7fffffffe280, bufsi= ze=3D30, prompt=3D11544578, dont_downcase_last=3D0, can_return_switch_frame= =3D1,=20 fix_current_buffer=3D1) at keyboard.c:9512 #18 0x0000000000558a33 in command_loop_1 () at keyboard.c:1643 #19 0x00000000005fe0aa in internal_condition_case (bfun=3D0x5586a0 , handlers=3D11629954, hfun=3D0x557f90 ) at eval.c:1490 #20 0x000000000055836a in command_loop_2 () at keyboard.c:1360 #21 0x00000000005fda2c in internal_catch (tag=3D11621170, func=3D0x558350 <= command_loop_2>, arg=3D11544578) at eval.c:1226 #22 0x0000000000558320 in command_loop () at keyboard.c:1339 #23 0x0000000000557a85 in recursive_edit_1 () at keyboard.c:954 #24 0x0000000000557c45 in Frecursive_edit () at keyboard.c:1016 #25 0x00000000005560b8 in main (argc=3D1, argv=3D0x7fffffffe840) at emacs.c= :1833 Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, using 1.11 brings back the crashes. I didn't csup between those versions and thus don't have 1.10 in git, but given that it's a style change it shouldn't matter. I'm using amd64 and so far I only noticed the problem with emacs. Is anyone else seeing this? Fabian --Sig_/gaK_zXOLYEbRERvZmi8AKtL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkx35fYACgkQBYqIVf93VJ38hwCfS2sxelA9Z5QMQGgB3ehG8U4C pxgAoIvbl7mSYMNhb/Nm+ksljZsJ7Izp =iTzG -----END PGP SIGNATURE----- --Sig_/gaK_zXOLYEbRERvZmi8AKtL-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 17:00:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 018881065780 for ; Fri, 27 Aug 2010 17:00:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-0.mx.aerioconnect.net [216.240.47.60]) by mx1.freebsd.org (Postfix) with ESMTP id B7DF58FC14 for ; Fri, 27 Aug 2010 17:00:09 +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 o7RGj2Em001440; Fri, 27 Aug 2010 09:45:02 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 52B3C2D6011; Fri, 27 Aug 2010 09:45:01 -0700 (PDT) Message-ID: <4C77EB9C.5060404@elischer.org> Date: Fri, 27 Aug 2010 09:45:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Steve Kargl References: <20100827051015.GA25885@troutmask.apl.washington.edu> In-Reply-To: <20100827051015.GA25885@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-current@freebsd.org, "????ccuiyyan@gmail.com" Subject: Re: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:00:10 -0000 On 8/26/10 10:10 PM, Steve Kargl wrote: > On Fri, Aug 27, 2010 at 12:07:11PM +0800, ????ccuiyyan@gmail.com wrote: >> Dear all: >> >> A quick question about the FreeBSD. In my lab, there is a multicore >> machine and i install a FreeBSD >> system on it. I wonder to know how to see the utilization for each >> core? are there such tools? Thanks! >> > > Wrong mailing list. Try freebsd-question@freebsd.org. > > Also, try man top. > specifically, there will be an idle thread for each CPU so top -SH will allow you to see how much idle time there is on each cpu. From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 17:13:01 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AAEB10656A8; Fri, 27 Aug 2010 17:13:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2F68FC0A; Fri, 27 Aug 2010 17:13:00 +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 UAA22476; Fri, 27 Aug 2010 20:12:56 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C77F218.9060901@icyb.net.ua> Date: Fri, 27 Aug 2010 20:12:56 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua> <4C72297D.90104@FreeBSD.org> <4C722ADD.1030103@icyb.net.ua> <4C7234A1.3050108@FreeBSD.org> <4C7792A1.9090909@icyb.net.ua> <4C77E582.5080706@FreeBSD.org> In-Reply-To: <4C77E582.5080706@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:13:01 -0000 on 27/08/2010 19:19 Doug Barton said the following: > Yes, it improved things greatly. I first ran with just powerd for several hours > and that worked fine. The next day I was able to use powerd and cx_lowest=C2 for > the better part of a day (including watching a few flash videos). By the end of > the day intr started to run away again, so not out of the woods yet, but at least > this shows we're going in the right direction. Also, while poking around in the > BIOS settings I noticed in one of the "information only" screens that I don't > usually visit one line about the "minimum cpu speed" is 1.00 GHz, which the sysctl > output above seems to verify. So where the throttling code was getting all those > other numbers I don't know. > > Meanwhile I've actually not been running FreeBSD for most of this week I've been > working on re-partitioning my new disk and running ubuntu. So 2 interesting pieces > of information there, first the "CPU Frequency Scaling Monitor" for the gnome that > comes with ubuntu never goes below 1 GHz, so that bit seems extra verified. > Second, I can watch all the flash videos I want while doing other stuff in the > background (like restoring the backups of my data) without any problems, so add > that to windows in terms of OS' that work on this same hardware. Now that I have > finally figured out how to boot windows, linux, and 2 FreeBSDs on the same disk > I'll be able to set up 7-stable i386 and 9-current amd64 to see how they compare > to the 9-current i386 I was using previously; so I should have more information in > a few days. Cool! Meanwhile can you double-check what timers does Linux use there? (No idea how to do that, especially if it's NO_HZ kernel). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 17:39:21 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A4281065696 for ; Fri, 27 Aug 2010 17:39:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 12C528FC18 for ; Fri, 27 Aug 2010 17:39:20 +0000 (UTC) Received: (qmail 6120 invoked by uid 399); 27 Aug 2010 17:39:19 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 27 Aug 2010 17:39:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C77F846.7010903@FreeBSD.org> Date: Fri, 27 Aug 2010 10:39:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua> <4C72297D.90104@FreeBSD.org> <4C722ADD.1030103@icyb.net.ua> <4C7234A1.3050108@FreeBSD.org> <4C7792A1.9090909@icyb.net.ua> <4C77E582.5080706@FreeBSD.org> <4C77F218.9060901@icyb.net.ua> In-Reply-To: <4C77F218.9060901@icyb.net.ua> X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:39:21 -0000 On 08/27/2010 10:12 AM, Andriy Gapon wrote: > Cool! > Meanwhile can you double-check what timers does Linux use there? > (No idea how to do that, especially if it's NO_HZ kernel). Sure, if someone can tell me what to do. I know even less about linux than I do about freebsd. :) First thing that came to mind: sysctl -a | grep -i time kernel.sched_time_avg = 1000 kernel.timer_migration = 1 kernel.sched_rt_runtime_us = 950000 kernel.hung_task_timeout_secs = 120 fs.lease-break-time = 45 dev.parport.default.timeslice = 200 dev.parport.default.spintime = 500 net.core.xfrm_aevent_etime = 10 Also this looks promising from /proc: http://people.freebsd.org/~dougb/timer_list.txt Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 17:48:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DB88106566B for ; Fri, 27 Aug 2010 17:48:01 +0000 (UTC) (envelope-from fjwcash@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 218CE8FC1A for ; Fri, 27 Aug 2010 17:48:01 +0000 (UTC) Received: by iwn36 with SMTP id 36so3155459iwn.13 for ; Fri, 27 Aug 2010 10:48:00 -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=rFYrFx1oZ1oNXjsKBH69WAAnZ5UrcrbTE/ZMBnxL2q0=; b=AV9+ckoBnS2S8h9bSKK0/etbdGmsTlIixDghSFAemNE0t7Dprgn4YmvLzvpqgRJ5ie QvuQoEe2QRb5+hTpSSm2mAeklsotVl2PyBuWKZGPiZUcDqp2z4Hv6xf1jNYZjTmh//D/ M7kJBwA5TZHiHM5SwTQd3p+KDrKiuNAVVCeMA= 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=B+DaKsAPpwK4BH7506vTcpRa4uoCyHyXeQo/GWkbyZUkoWgynPDMW76spAlChcXA7y HhN2lDiKAfct741BhqaQYC7qPbQ74oMB4oK7vkX9JqZOUzxw6S+8RGXkds0clkn2ZLWI Zhi3re5uAuL1gkb/ifwUdFYt4JONegz6tL9vM= MIME-Version: 1.0 Received: by 10.231.184.71 with SMTP id cj7mr1380026ibb.159.1282929662236; Fri, 27 Aug 2010 10:21:02 -0700 (PDT) Received: by 10.231.161.131 with HTTP; Fri, 27 Aug 2010 10:21:02 -0700 (PDT) In-Reply-To: <4C77EB9C.5060404@elischer.org> References: <20100827051015.GA25885@troutmask.apl.washington.edu> <4C77EB9C.5060404@elischer.org> Date: Fri, 27 Aug 2010 10:21:02 -0700 Message-ID: From: Freddie Cash To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "????ccuiyyan@gmail.com" , Steve Kargl Subject: Re: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:48:01 -0000 On Fri, Aug 27, 2010 at 9:45 AM, Julian Elischer wrot= e: > On 8/26/10 10:10 PM, Steve Kargl wrote: >> On Fri, Aug 27, 2010 at 12:07:11PM +0800, ????ccuiyyan@gmail.com wrote: >>> >>> Dear all: >>> >>> =C2=A0 =C2=A0 =C2=A0A quick question about the FreeBSD. In my lab, ther= e is a multicore >>> machine and i install a FreeBSD >>> =C2=A0 =C2=A0 =C2=A0system on it. I wonder to know how to see the utili= zation for each >>> core? are there such tools? Thanks! >> >> Wrong mailing list. =C2=A0Try freebsd-question@freebsd.org. >> >> Also, try man top. > > specifically, there will be an idle thread for each CPU > > so top -SH will allow you to see how much idle time there is on each cpu. -C will show stats for individual CPUs at the top of the screen (similar to pressing 0 in top on Linux). This was added to top in 7.2 or 7.3 or thereabouts. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 17:59:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FEFF1065673 for ; Fri, 27 Aug 2010 17:59:43 +0000 (UTC) (envelope-from cardiforia@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 186008FC1C for ; Fri, 27 Aug 2010 17:59:42 +0000 (UTC) Received: by gxk24 with SMTP id 24so1424004gxk.13 for ; Fri, 27 Aug 2010 10:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=zDfqXKLYJYHkU+7NI8q036DG+xmcOXnpQX0ZhEPdaHQ=; b=AhQee00mbZFH/IE664y/uybHBaINYzoJ++jiLimjHsj5z41pzQkzYpgz+bpboIprIn EfQ8AnNUv4Z0kWpysjmcExmN5++E0G8mHdwnFmPWfaBTkq0xhUxq/rUvWXfEaqg4on3q zo9XO3qbS9dUZvkvqXZsPq9M50xe1XpcJNu80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=rxcN2kH1lQa0dFEyGNDYXBVC5SJTx23rckQCqoGJ/vmj8hyy5sfqrJowhEJPxuCFwa QzCaGjaypyk8PE5gTSprCF8Y/bWAGr84xDuMC2KtGb01t4P+/chIEzwLOOMEeJ6h5NSv 6GZ3WWCYh0tAzelWGXTRXGNWyO7KdCTWS+n+Y= Received: by 10.100.48.14 with SMTP id v14mr1239013anv.146.1282930420730; Fri, 27 Aug 2010 10:33:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.158.16 with HTTP; Fri, 27 Aug 2010 10:33:20 -0700 (PDT) In-Reply-To: References: From: Ventsislav Nikolov Date: Fri, 27 Aug 2010 20:33:20 +0300 Message-ID: To: =?UTF-8?B?5bSU5bKpY2N1aXl5YW5AZ21haWwuY29t?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:59:43 -0000 Hi, Try using htop from the ports. ---------------------- Love & Light Ventsislav Nikolov On Fri, Aug 27, 2010 at 7:07 AM, =E5=B4=94=E5=B2=A9ccuiyyan@gmail.com wrote: > Dear all: > > A quick question about the FreeBSD. In my lab, there is a multicore > machine and i install a FreeBSD > system on it. I wonder to know how to see the utilization for each > core? are there such tools? Thanks! > > -- > Think big; Dream impossible; Make it happen. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 18:05:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A56010656BE for ; Fri, 27 Aug 2010 18:05:48 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2E78FC08 for ; Fri, 27 Aug 2010 18:05:47 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1Op3JD-0001K4-5I; Fri, 27 Aug 2010 20:05:47 +0200 Message-ID: <4C77FE79.3010200@continum.net> Date: Fri, 27 Aug 2010 20:05:45 +0200 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Freddie Cash References: <20100827051015.GA25885@troutmask.apl.washington.edu> <4C77EB9C.5060404@elischer.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:05:48 -0000 Freddie Cash wrote: >>> Also, try man top. > -C will show stats for individual CPUs at the top of the screen > (similar to pressing 0 in top on Linux). This was added to top in 7.2 > or 7.3 or thereabouts. You mean top -P -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 18:18:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A1551065695 for ; Fri, 27 Aug 2010 18:18:49 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 97B5B8FC1D for ; Fri, 27 Aug 2010 18:18:48 +0000 (UTC) Received: by ewy4 with SMTP id 4so2435246ewy.13 for ; Fri, 27 Aug 2010 11:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=MVH0Z3bSkLcvrxf39QEx4j9NdXCGXhA9gbvD2ZZ51iE=; b=Trx9iotjv3SmYou+RqjZqat2ejDtTyAHt25sW/Lq7R/Nuek1a+NYuaZbNrVJkOu1HV khf5J6xoCmZhoZ5YU1/dY3+yVRPTbBdpOYUiDsJMSCBTlCi8xFw+ZfOj9roct7hH4nX0 cH7vlsXGGoGUpyCpoQnpjR9NwHR7avDqtIhVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=m1UA3oKFsWkRgeZ0oRPrOLWPSKRSYrcrJW3qjDNhGcvXN59f8TX8q48rHgF6EW4dFP raVI4tM8yE18Oz45kQGMWyLAOttrcejRvv1lIHcevxOZuarsSBmE2GnqcXKY18TY8HE3 M9rZB5PgpIbuRFLa6ONNb1PPtrbdVIbAq1vOI= Received: by 10.213.19.67 with SMTP id z3mr2781354eba.25.1282933127576; Fri, 27 Aug 2010 11:18:47 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-33.dsl.klmzmi.sbcglobal.net [99.181.132.33]) by mx.google.com with ESMTPS id v8sm6552425eeh.14.2010.08.27.11.18.45 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Aug 2010 11:18:46 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C780184.6050703@DataIX.net> Date: Fri, 27 Aug 2010 14:18:44 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Fabian Keil References: <20100827182108.12764ff4@r500.local> In-Reply-To: <20100827182108.12764ff4@r500.local> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:18:49 -0000 On 08/27/2010 12:21, Fabian Keil wrote: > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. > It aborts on exit (C-x C-c) after receiving SIGBUS: > r211704 was just a style(9) fix and should coincide with cvs/1.10 that your talking about. r211706 or cvs/1.11 is the culprit that has caused your problem but I have no way to verify that here without merging it locally. If this is the case please mark the MFC of r211706 cvs/1.11 as a do-not-do. Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 18:32:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A977410656A3 for ; Fri, 27 Aug 2010 18:32:55 +0000 (UTC) (envelope-from fjwcash@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 6EE3C8FC08 for ; Fri, 27 Aug 2010 18:32:55 +0000 (UTC) Received: by iwn36 with SMTP id 36so3185024iwn.13 for ; Fri, 27 Aug 2010 11:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=DLJDwbMSY05UR+aaWNKRXqNe0W1ku4JWad2AQ8fHdgs=; b=TQLd5WGhW+e+WE+loRhZ/u2qCrdx6RPrEqwP69tFn5SFFUYz/5cGB8T3xP040AiDJ9 RGrzSyoMbHT/o6Ua1n9t88wSzaByaaAY9up08NKpil8ObTPI0UHQIfVxkas1Nr4x/4uS EY2wbmCyutmn5JDBVxEH1tjcwoAEbq9+Wdtpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=NmzRd6ETp+GTXJW4xY1xc+XFj58QVrz4dCFdSsEanUYHCvhIVUOyTxDi9aAWoz5s01 zDZrg+gDuw67S6sfVyqvqYhpoObG5sVMCJFYFvB7/yeeC+5y/KMerJ3GAfAN8yTDkkXW nl4EwDd6QBKpK8B+E3vrPP0eGlrxwCiGa8+98= MIME-Version: 1.0 Received: by 10.231.174.72 with SMTP id s8mr1523580ibz.41.1282933974396; Fri, 27 Aug 2010 11:32:54 -0700 (PDT) Received: by 10.231.161.131 with HTTP; Fri, 27 Aug 2010 11:32:54 -0700 (PDT) In-Reply-To: <4C77FE79.3010200@continum.net> References: <20100827051015.GA25885@troutmask.apl.washington.edu> <4C77EB9C.5060404@elischer.org> <4C77FE79.3010200@continum.net> Date: Fri, 27 Aug 2010 11:32:54 -0700 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: a question about FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:32:55 -0000 On Fri, Aug 27, 2010 at 11:05 AM, V. T. Mueller, Continum wrote: > Freddie Cash wrote: >>>> >>>> Also, try man top. >> >> -C will show stats for individual CPUs at the top of the screen >> (similar to pressing 0 in top on Linux). =C2=A0This was added to top in = 7.2 >> or 7.3 or thereabouts. > > You mean top -P Whoops, you're right. That's what I get for looking at "echo $TOP" and guessing at which of CHP did it, instead of reading the man page. :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 19:04:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A77410656A4 for ; Fri, 27 Aug 2010 19:04:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 264F18FC14 for ; Fri, 27 Aug 2010 19:04:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7RJ4796072727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Aug 2010 22:04:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7RJ47F1036053; Fri, 27 Aug 2010 22:04:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7RJ47gT036052; Fri, 27 Aug 2010 22:04:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Aug 2010 22:04:07 +0300 From: Kostik Belousov To: Fabian Keil Message-ID: <20100827190407.GA2396@deviant.kiev.zoral.com.ua> References: <20100827182108.12764ff4@r500.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7W5gc0PssggrLAk" Content-Disposition: inline In-Reply-To: <20100827182108.12764ff4@r500.local> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:04:22 -0000 --w7W5gc0PssggrLAk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. > It aborts on exit (C-x C-c) after receiving SIGBUS: >=20 > fk@r500 ~ $gdb emacs > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... > (gdb) run > Starting program: /usr/local/bin/emacs=20 > [New LWP 100281] > [New Thread 1260600 (LWP 100281)] >=20 > Program received signal SIGBUS, Bus error. > [Switching to Thread 1260600 (LWP 100281)] > 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > (gdb) where > #0 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > #1 0x0000000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 > #2 0x00000008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 > #3 0x00000008045682c7 in exit () from /lib/libc.so.7 > #4 0x0000000000556817 in Fkill_emacs (arg=3DCould not find the frame bas= e for "Fkill_emacs". > ) at emacs.c:2146 > #5 0x0000000000600ec0 in Ffuncall (nargs=3D1, args=3D0x7fffffffc880) at = eval.c:3024 > #6 0x0000000000658d47 in Fbyte_code (bytestr=3D8602321, vector=3D8602357= , maxdepth=3D20) at bytecode.c:680 > #7 0x00000000006017e6 in funcall_lambda (fun=3D8602229, nargs=3D0, arg_v= ector=3D0x7fffffffcdc8) at eval.c:3211 > #8 0x00000000006011e0 in Ffuncall (nargs=3D1, args=3D0x7fffffffcdc0) at = eval.c:3070 > #9 0x0000000000658d47 in Fbyte_code (bytestr=3D9558105, vector=3D9558141= , maxdepth=3D20) at bytecode.c:680 > #10 0x00000000006017e6 in funcall_lambda (fun=3D9558029, nargs=3D1, arg_v= ector=3D0x7fffffffd358) at eval.c:3211 > #11 0x00000000006011e0 in Ffuncall (nargs=3D2, args=3D0x7fffffffd350) at = eval.c:3070 > #12 0x00000000005fb954 in Fcall_interactively (function=3D11961778, recor= d_flag=3D11544578, keys=3D20138021) at callint.c:869 > #13 0x0000000000600f36 in Ffuncall (nargs=3D4, args=3D0x7fffffffd760) at = eval.c:3030 > #14 0x00000000006008fd in call3 (fn=3D11756290, arg1=3D11961778, arg2=3D1= 1544578, arg3=3D20138021) at eval.c:2850 > #15 0x000000000056b7ac in Fcommand_execute (cmd=3D11961778, record_flag= =3D11544578, keys=3D20138021, special=3D11544674) at keyboard.c:10507 > #16 0x000000000055cc69 in read_char (commandflag=3D1, nmaps=3D2, maps=3D0= x7fffffffdb70, prev_event=3D11544578, used_mouse_menu=3D0x7fffffffded4, end= _time=3D0x0) > at keyboard.c:3166 > #17 0x000000000056880e in read_key_sequence (keybuf=3D0x7fffffffe280, buf= size=3D30, prompt=3D11544578, dont_downcase_last=3D0, can_return_switch_fra= me=3D1,=20 > fix_current_buffer=3D1) at keyboard.c:9512 > #18 0x0000000000558a33 in command_loop_1 () at keyboard.c:1643 > #19 0x00000000005fe0aa in internal_condition_case (bfun=3D0x5586a0 , handlers=3D11629954, hfun=3D0x557f90 ) at eval.c:1490 > #20 0x000000000055836a in command_loop_2 () at keyboard.c:1360 > #21 0x00000000005fda2c in internal_catch (tag=3D11621170, func=3D0x558350= , arg=3D11544578) at eval.c:1226 > #22 0x0000000000558320 in command_loop () at keyboard.c:1339 > #23 0x0000000000557a85 in recursive_edit_1 () at keyboard.c:954 > #24 0x0000000000557c45 in Frecursive_edit () at keyboard.c:1016 > #25 0x00000000005560b8 in main (argc=3D1, argv=3D0x7fffffffe840) at emacs= .c:1833 >=20 > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, > using 1.11 brings back the crashes. I didn't csup between those > versions and thus don't have 1.10 in git, but given that it's a > style change it shouldn't matter. >=20 > I'm using amd64 and so far I only noticed the problem with emacs. >=20 > Is anyone else seeing this? Reverting the atexit change might cover the issue in some other place. Please build and install rtld, libc and libthr with symbolic debug information. On of the way to do this is to: cd /usr/src/libexec/rtld-elf make obj && make depend && make all install DEBUG_FLAGS=3D-g cd ../../lib/libc make obj && make depend && make all install DEBUG_FLAGS=3D-g cd ../../lib/libthr make obj && make depend && make all install DEBUG_FLAGS=3D-g Then, reproduce the crash and get "bt full" output from the core. I may need some further information after that. Thank you for the report. --w7W5gc0PssggrLAk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx4DCcACgkQC3+MBN1Mb4hUswCeIrmIuBWYBjtdyI4vpoZHPBp/ 98gAoPZM7eTMFMMdKVpx9hMEkVbxCQ6L =1g5f -----END PGP SIGNATURE----- --w7W5gc0PssggrLAk-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 19:26:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F02610656A7 for ; Fri, 27 Aug 2010 19:26:52 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by mx1.freebsd.org (Postfix) with ESMTP id BA0058FC12 for ; Fri, 27 Aug 2010 19:26:51 +0000 (UTC) Received: from [87.78.61.30] (helo=r500.local) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Op4Ze-0000fj-0g; Fri, 27 Aug 2010 21:26:50 +0200 Date: Fri, 27 Aug 2010 21:25:34 +0200 From: Fabian Keil To: Kostik Belousov Message-ID: <20100827212534.5960efdf@r500.local> In-Reply-To: <20100827190407.GA2396@deviant.kiev.zoral.com.ua> References: <20100827182108.12764ff4@r500.local> <20100827190407.GA2396@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Tq+xvGg.jfpFioxNcyGd.mM"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-current@freebsd.org Subject: Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:26:52 -0000 --Sig_/Tq+xvGg.jfpFioxNcyGd.mM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: > > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for > > me. It aborts on exit (C-x C-c) after receiving SIGBUS: > >=20 > > fk@r500 ~ $gdb emacs > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and > > you are welcome to change it and/or distribute copies of it under > > certain conditions. Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. This GDB was configured as "amd64-marcel-freebsd"... > > (gdb) run > > Starting program: /usr/local/bin/emacs=20 > > [New LWP 100281] > > [New Thread 1260600 (LWP 100281)] > >=20 > > Program received signal SIGBUS, Bus error. > > [Switching to Thread 1260600 (LWP 100281)] > > 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > (gdb) where > > #0 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > #1 0x0000000803038abb in __pthread_cxa_finalize () > > from /lib/libthr.so.3 #2 0x00000008045bdfa7 in __cxa_finalize () > > from /lib/libc.so.7 #3 0x00000008045682c7 in exit () > > from /lib/libc.so.7 #4 0x0000000000556817 in Fkill_emacs (arg=3DCould > > not find the frame base for "Fkill_emacs". ) at emacs.c:2146 > > #5 0x0000000000600ec0 in Ffuncall (nargs=3D1, args=3D0x7fffffffc880) at > > eval.c:3024 #6 0x0000000000658d47 in Fbyte_code (bytestr=3D8602321, > > vector=3D8602357, maxdepth=3D20) at bytecode.c:680 #7 0x00000000006017= e6 > > in funcall_lambda (fun=3D8602229, nargs=3D0, arg_vector=3D0x7fffffffcdc= 8) at > > eval.c:3211 #8 0x00000000006011e0 in Ffuncall (nargs=3D1, > > args=3D0x7fffffffcdc0) at eval.c:3070 #9 0x0000000000658d47 in > > Fbyte_code (bytestr=3D9558105, vector=3D9558141, maxdepth=3D20) at > > bytecode.c:680 #10 0x00000000006017e6 in funcall_lambda (fun=3D9558029, > > nargs=3D1, arg_vector=3D0x7fffffffd358) at eval.c:3211 #11 > > 0x00000000006011e0 in Ffuncall (nargs=3D2, args=3D0x7fffffffd350) at > > eval.c:3070 #12 0x00000000005fb954 in Fcall_interactively > > (function=3D11961778, record_flag=3D11544578, keys=3D20138021) at > > callint.c:869 #13 0x0000000000600f36 in Ffuncall (nargs=3D4, > > args=3D0x7fffffffd760) at eval.c:3030 #14 0x00000000006008fd in call3 > > (fn=3D11756290, arg1=3D11961778, arg2=3D11544578, arg3=3D20138021) at > > eval.c:2850 #15 0x000000000056b7ac in Fcommand_execute (cmd=3D11961778, > > record_flag=3D11544578, keys=3D20138021, special=3D11544674) at > > keyboard.c:10507 #16 0x000000000055cc69 in read_char (commandflag=3D1, > > nmaps=3D2, maps=3D0x7fffffffdb70, prev_event=3D11544578, > > used_mouse_menu=3D0x7fffffffded4, end_time=3D0x0) at keyboard.c:3166 #17 > > 0x000000000056880e in read_key_sequence (keybuf=3D0x7fffffffe280, > > bufsize=3D30, prompt=3D11544578, dont_downcase_last=3D0, > > can_return_switch_frame=3D1, fix_current_buffer=3D1) at keyboard.c:9512 > > #18 0x0000000000558a33 in command_loop_1 () at keyboard.c:1643 #19 > > 0x00000000005fe0aa in internal_condition_case (bfun=3D0x5586a0 > > , handlers=3D11629954, hfun=3D0x557f90 ) at > > eval.c:1490 #20 0x000000000055836a in command_loop_2 () at > > keyboard.c:1360 #21 0x00000000005fda2c in internal_catch > > (tag=3D11621170, func=3D0x558350 , arg=3D11544578) at > > eval.c:1226 #22 0x0000000000558320 in command_loop () at > > keyboard.c:1339 #23 0x0000000000557a85 in recursive_edit_1 () at > > keyboard.c:954 #24 0x0000000000557c45 in Frecursive_edit () at > > keyboard.c:1016 #25 0x00000000005560b8 in main (argc=3D1, > > argv=3D0x7fffffffe840) at emacs.c:1833 > >=20 > > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, > > using 1.11 brings back the crashes. I didn't csup between those > > versions and thus don't have 1.10 in git, but given that it's a > > style change it shouldn't matter. > >=20 > > I'm using amd64 and so far I only noticed the problem with emacs. > >=20 > > Is anyone else seeing this? > Reverting the atexit change might cover the issue in some other place. > Please build and install rtld, libc and libthr with symbolic > debug information. On of the way to do this is to: > cd /usr/src/libexec/rtld-elf > make obj && make depend && make all install DEBUG_FLAGS=3D-g > cd ../../lib/libc > make obj && make depend && make all install DEBUG_FLAGS=3D-g > cd ../../lib/libthr > make obj && make depend && make all install DEBUG_FLAGS=3D-g >=20 > Then, reproduce the crash and get "bt full" output from the > core. I may need some further information after that. #0 0x00000008045dd44c in kill () at kill.S:3 3 RSYSCALL(kill) [New Thread 1260600 (LWP 100244)] (gdb) bt full #0 0x00000008045dd44c in kill () at kill.S:3 No locals. #1 0x00000000005545c0 in fatal_error_signal (sig=3D10) at emacs.c:402 No locals. #2 No symbol table info available. #3 __elf_phdr_match_addr (phdr_info=3D0x7fffffffcf90, addr=3D0x69ba20) at = /usr/src/lib/libc/gen/elf_utils.c:39 i =3D 109 #4 0x0000000803038fdb in __pthread_cxa_finalize (phdr_info=3D0x7fffffffcf9= 0) at /usr/src/lib/libthr/thread/thr_fork.c:109 af =3D (struct pthread_atfork *) 0xe1e7c0 af1 =3D (struct pthread_atfork *) 0x0 #5 0x00000008045be0a7 in __cxa_finalize (dso=3D0x0) at /usr/src/lib/libc/s= tdlib/atexit.c:204 phdr_info =3D {dlpi_addr =3D 0, dlpi_name =3D 0x7fffffffd080 "`=D1= =FF=FF=FF\177", dlpi_phdr =3D 0x7fffffffe848, dlpi_phnum =3D 59448, dlpi_ad= ds =3D 0, dlpi_subs =3D 34367899629,=20 dlpi_tls_modid =3D 15046784, dlpi_tls_data =3D 0x12c2538} p =3D (struct atexit *) 0x0 fn =3D {fn_type =3D 1, fn_ptr =3D {std_func =3D 0x8007ccff0 , cxa_func =3D 0x8007ccff0 }, fn_arg =3D 0x0, fn_dso =3D 0x0} n =3D -1 has_phdr =3D 0 #6 0x00000008045683c7 in exit (status=3D0) at /usr/src/lib/libc/stdlib/exi= t.c:67 No locals. #7 0x0000000000556817 in Fkill_emacs (arg=3DCould not find the frame base = for "Fkill_emacs". ) at emacs.c:2146 gcpro1 =3D Could not find the frame base for "Fkill_emacs". Current language: auto; currently asm Fabian --Sig_/Tq+xvGg.jfpFioxNcyGd.mM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkx4ETEACgkQBYqIVf93VJ2A2QCfYNcxxT/+NZ9g2nT1gULHH5w5 ofoAoIOkdMOwPKAvRwoKJV62RNjkB62J =riy6 -----END PGP SIGNATURE----- --Sig_/Tq+xvGg.jfpFioxNcyGd.mM-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 19:30:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B2A11065695 for ; Fri, 27 Aug 2010 19:30:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 161038FC0A for ; Fri, 27 Aug 2010 19:30:06 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o7RJU5up055874 for ; Fri, 27 Aug 2010 12:30:05 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o7RJU5nS055871 for freebsd-current@freebsd.org; Fri, 27 Aug 2010 12:30:05 -0700 (PDT) (envelope-from sgk) Date: Fri, 27 Aug 2010 12:30:05 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20100827193005.GA22719@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: kernel panic and corrupt vmcore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:30:06 -0000 Installed a kernel based on yesterday's src/ tree. The kernel panicked and the generated core seems to be corrupt. Is there a known issue with getting core dumps on x86_64 freebsd? The top of the core.txt.0 file shows troutmask.apl.washington.edu dumped core - see /usr/tmp/vmcore.0 Fri Aug 27 11:26:26 PDT 2010 FreeBSD troutmask.apl.washington.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r211766M: Tue Aug 24 14:52:25 PDT 2010 kargl@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Cannot access memory at address 0xffffff01ffffffe0 (kgdb) #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 (kgdb) If anyone wants the entire content of core.txt.0, simply request it. My was doing the following when the panic occurred: 1) Running rsync via cron to back up /usr/home accounts from /dev/ad6s1f to /dev/ad4s1f. Both file systems use softupdates+journaling. 2) Building ports/www/firefox (which is version 3.6.8) 3) Running the GCC dejagnu testsuite for the gfortran compiler 4) Using firefox-3.5.11 to view a site that drives the Xorg srever to 90% CPU usage. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 19:37:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F037610656A5 for ; Fri, 27 Aug 2010 19:37:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBAF8FC08 for ; Fri, 27 Aug 2010 19:37:24 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7RJbLVj074811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Aug 2010 22:37:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7RJbKJD036350; Fri, 27 Aug 2010 22:37:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7RJbKXc036349; Fri, 27 Aug 2010 22:37:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Aug 2010 22:37:20 +0300 From: Kostik Belousov To: Fabian Keil Message-ID: <20100827193720.GB2396@deviant.kiev.zoral.com.ua> References: <20100827182108.12764ff4@r500.local> <20100827190407.GA2396@deviant.kiev.zoral.com.ua> <20100827212534.5960efdf@r500.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ph+hsrg5jWGcqD/d" Content-Disposition: inline In-Reply-To: <20100827212534.5960efdf@r500.local> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:37:26 -0000 --ph+hsrg5jWGcqD/d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote: > Kostik Belousov wrote: >=20 > > On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: > > > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for > > > me. It aborts on exit (C-x C-c) after receiving SIGBUS: > > >=20 > > > fk@r500 ~ $gdb emacs > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and > > > you are welcome to change it and/or distribute copies of it under > > > certain conditions. Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > details. This GDB was configured as "amd64-marcel-freebsd"... > > > (gdb) run > > > Starting program: /usr/local/bin/emacs=20 > > > [New LWP 100281] > > > [New Thread 1260600 (LWP 100281)] > > >=20 > > > Program received signal SIGBUS, Bus error. > > > [Switching to Thread 1260600 (LWP 100281)] > > > 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > > (gdb) where > > > #0 0x00000008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > > #1 0x0000000803038abb in __pthread_cxa_finalize () > > > from /lib/libthr.so.3 #2 0x00000008045bdfa7 in __cxa_finalize () > > > from /lib/libc.so.7 #3 0x00000008045682c7 in exit () > > > from /lib/libc.so.7 #4 0x0000000000556817 in Fkill_emacs (arg=3DCould > > > not find the frame base for "Fkill_emacs". ) at emacs.c:2146 > > > #5 0x0000000000600ec0 in Ffuncall (nargs=3D1, args=3D0x7fffffffc880)= at > > > eval.c:3024 #6 0x0000000000658d47 in Fbyte_code (bytestr=3D8602321, > > > vector=3D8602357, maxdepth=3D20) at bytecode.c:680 #7 0x000000000060= 17e6 > > > in funcall_lambda (fun=3D8602229, nargs=3D0, arg_vector=3D0x7fffffffc= dc8) at > > > eval.c:3211 #8 0x00000000006011e0 in Ffuncall (nargs=3D1, > > > args=3D0x7fffffffcdc0) at eval.c:3070 #9 0x0000000000658d47 in > > > Fbyte_code (bytestr=3D9558105, vector=3D9558141, maxdepth=3D20) at > > > bytecode.c:680 #10 0x00000000006017e6 in funcall_lambda (fun=3D955802= 9, > > > nargs=3D1, arg_vector=3D0x7fffffffd358) at eval.c:3211 #11 > > > 0x00000000006011e0 in Ffuncall (nargs=3D2, args=3D0x7fffffffd350) at > > > eval.c:3070 #12 0x00000000005fb954 in Fcall_interactively > > > (function=3D11961778, record_flag=3D11544578, keys=3D20138021) at > > > callint.c:869 #13 0x0000000000600f36 in Ffuncall (nargs=3D4, > > > args=3D0x7fffffffd760) at eval.c:3030 #14 0x00000000006008fd in call3 > > > (fn=3D11756290, arg1=3D11961778, arg2=3D11544578, arg3=3D20138021) at > > > eval.c:2850 #15 0x000000000056b7ac in Fcommand_execute (cmd=3D1196177= 8, > > > record_flag=3D11544578, keys=3D20138021, special=3D11544674) at > > > keyboard.c:10507 #16 0x000000000055cc69 in read_char (commandflag=3D1, > > > nmaps=3D2, maps=3D0x7fffffffdb70, prev_event=3D11544578, > > > used_mouse_menu=3D0x7fffffffded4, end_time=3D0x0) at keyboard.c:3166 = #17 > > > 0x000000000056880e in read_key_sequence (keybuf=3D0x7fffffffe280, > > > bufsize=3D30, prompt=3D11544578, dont_downcase_last=3D0, > > > can_return_switch_frame=3D1, fix_current_buffer=3D1) at keyboard.c:95= 12 > > > #18 0x0000000000558a33 in command_loop_1 () at keyboard.c:1643 #19 > > > 0x00000000005fe0aa in internal_condition_case (bfun=3D0x5586a0 > > > , handlers=3D11629954, hfun=3D0x557f90 ) at > > > eval.c:1490 #20 0x000000000055836a in command_loop_2 () at > > > keyboard.c:1360 #21 0x00000000005fda2c in internal_catch > > > (tag=3D11621170, func=3D0x558350 , arg=3D11544578) at > > > eval.c:1226 #22 0x0000000000558320 in command_loop () at > > > keyboard.c:1339 #23 0x0000000000557a85 in recursive_edit_1 () at > > > keyboard.c:954 #24 0x0000000000557c45 in Frecursive_edit () at > > > keyboard.c:1016 #25 0x00000000005560b8 in main (argc=3D1, > > > argv=3D0x7fffffffe840) at emacs.c:1833 > > >=20 > > > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, > > > using 1.11 brings back the crashes. I didn't csup between those > > > versions and thus don't have 1.10 in git, but given that it's a > > > style change it shouldn't matter. > > >=20 > > > I'm using amd64 and so far I only noticed the problem with emacs. > > >=20 > > > Is anyone else seeing this? > > Reverting the atexit change might cover the issue in some other place. > > Please build and install rtld, libc and libthr with symbolic > > debug information. On of the way to do this is to: > > cd /usr/src/libexec/rtld-elf > > make obj && make depend && make all install DEBUG_FLAGS=3D-g > > cd ../../lib/libc > > make obj && make depend && make all install DEBUG_FLAGS=3D-g > > cd ../../lib/libthr > > make obj && make depend && make all install DEBUG_FLAGS=3D-g > >=20 > > Then, reproduce the crash and get "bt full" output from the > > core. I may need some further information after that. >=20 > #0 0x00000008045dd44c in kill () at kill.S:3 > 3 RSYSCALL(kill) > [New Thread 1260600 (LWP 100244)] > (gdb) bt full > #0 0x00000008045dd44c in kill () at kill.S:3 > No locals. > #1 0x00000000005545c0 in fatal_error_signal (sig=3D10) at emacs.c:402 > No locals. > #2 > No symbol table info available. > #3 __elf_phdr_match_addr (phdr_info=3D0x7fffffffcf90, addr=3D0x69ba20) a= t /usr/src/lib/libc/gen/elf_utils.c:39 > i =3D 109 > #4 0x0000000803038fdb in __pthread_cxa_finalize (phdr_info=3D0x7fffffffc= f90) at /usr/src/lib/libthr/thread/thr_fork.c:109 > af =3D (struct pthread_atfork *) 0xe1e7c0 > af1 =3D (struct pthread_atfork *) 0x0 > #5 0x00000008045be0a7 in __cxa_finalize (dso=3D0x0) at /usr/src/lib/libc= /stdlib/atexit.c:204 > phdr_info =3D {dlpi_addr =3D 0, dlpi_name =3D 0x7fffffffd080 "`??= ??\177", dlpi_phdr =3D 0x7fffffffe848, dlpi_phnum =3D 59448, dlpi_adds =3D = 0, dlpi_subs =3D 34367899629,=20 > dlpi_tls_modid =3D 15046784, dlpi_tls_data =3D 0x12c2538} > p =3D (struct atexit *) 0x0 > fn =3D {fn_type =3D 1, fn_ptr =3D {std_func =3D 0x8007ccff0 , cxa_func =3D 0x8007ccff0 }, fn_arg =3D 0x0, fn_dso =3D 0= x0} > n =3D -1 > has_phdr =3D 0 > #6 0x00000008045683c7 in exit (status=3D0) at /usr/src/lib/libc/stdlib/e= xit.c:67 > No locals. > #7 0x0000000000556817 in Fkill_emacs (arg=3DCould not find the frame bas= e for "Fkill_emacs". > ) at emacs.c:2146 > gcpro1 =3D Could not find the frame base for "Fkill_emacs". > Current language: auto; currently asm >=20 > Fabian Ewww. Please try this. diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c index 97cf234..511172a 100644 --- a/lib/libc/stdlib/atexit.c +++ b/lib/libc/stdlib/atexit.c @@ -200,6 +200,6 @@ __cxa_finalize(void *dso) if (dso =3D=3D NULL) _MUTEX_DESTROY(&atexit_mutex); =20 - if (&__pthread_cxa_finalize !=3D NULL) + if (has_phdr && &__pthread_cxa_finalize !=3D NULL) __pthread_cxa_finalize(&phdr_info); } --ph+hsrg5jWGcqD/d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx4E/AACgkQC3+MBN1Mb4hRkwCgiKCncmQ+62WXLYrJy32VtoWd ZpgAoK2x3pi9/bsNXn2vaj0FioqN9Rsu =ML/C -----END PGP SIGNATURE----- --ph+hsrg5jWGcqD/d-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 19:47:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77B5410656B8 for ; Fri, 27 Aug 2010 19:47:32 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id 08C0B8FC12 for ; Fri, 27 Aug 2010 19:47:31 +0000 (UTC) Received: from [87.78.61.30] (helo=r500.local) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Op4te-0001X3-AE; Fri, 27 Aug 2010 21:47:30 +0200 Date: Fri, 27 Aug 2010 21:46:35 +0200 From: Fabian Keil To: Kostik Belousov Message-ID: <20100827214635.40471d37@r500.local> In-Reply-To: <20100827193720.GB2396@deviant.kiev.zoral.com.ua> References: <20100827182108.12764ff4@r500.local> <20100827190407.GA2396@deviant.kiev.zoral.com.ua> <20100827212534.5960efdf@r500.local> <20100827193720.GB2396@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/sZIOLvqIw__qVj8hA1SWr9S"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-current@freebsd.org Subject: Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:47:32 -0000 --Sig_/sZIOLvqIw__qVj8hA1SWr9S Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote: > > Kostik Belousov wrote: > >=20 > > > On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: > > > > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) = for > > > > me. It aborts on exit (C-x C-c) after receiving SIGBUS: > > > > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, > > > > using 1.11 brings back the crashes. I didn't csup between those > > > > versions and thus don't have 1.10 in git, but given that it's a > > > > style change it shouldn't matter. > > > >=20 > > > > I'm using amd64 and so far I only noticed the problem with emacs. > > > >=20 > > > > Is anyone else seeing this? > > > Reverting the atexit change might cover the issue in some other place. > > > Please build and install rtld, libc and libthr with symbolic > > > debug information. On of the way to do this is to: > > > cd /usr/src/libexec/rtld-elf > > > make obj && make depend && make all install DEBUG_FLAGS=3D-g > > > cd ../../lib/libc > > > make obj && make depend && make all install DEBUG_FLAGS=3D-g > > > cd ../../lib/libthr > > > make obj && make depend && make all install DEBUG_FLAGS=3D-g > > >=20 > > > Then, reproduce the crash and get "bt full" output from the > > > core. I may need some further information after that. > >=20 > > #0 0x00000008045dd44c in kill () at kill.S:3 > > 3 RSYSCALL(kill) > > [New Thread 1260600 (LWP 100244)] > > (gdb) bt full > > #0 0x00000008045dd44c in kill () at kill.S:3 > > No locals. > > #1 0x00000000005545c0 in fatal_error_signal (sig=3D10) at emacs.c:402 > > No locals. > > #2 > > No symbol table info available. > > #3 __elf_phdr_match_addr (phdr_info=3D0x7fffffffcf90, addr=3D0x69ba20)= at /usr/src/lib/libc/gen/elf_utils.c:39 > > i =3D 109 > > #4 0x0000000803038fdb in __pthread_cxa_finalize (phdr_info=3D0x7ffffff= fcf90) at /usr/src/lib/libthr/thread/thr_fork.c:109 > > af =3D (struct pthread_atfork *) 0xe1e7c0 > > af1 =3D (struct pthread_atfork *) 0x0 > > #5 0x00000008045be0a7 in __cxa_finalize (dso=3D0x0) at /usr/src/lib/li= bc/stdlib/atexit.c:204 > > phdr_info =3D {dlpi_addr =3D 0, dlpi_name =3D 0x7fffffffd080 "`= ????\177", dlpi_phdr =3D 0x7fffffffe848, dlpi_phnum =3D 59448, dlpi_adds = =3D 0, dlpi_subs =3D 34367899629,=20 > > dlpi_tls_modid =3D 15046784, dlpi_tls_data =3D 0x12c2538} > > p =3D (struct atexit *) 0x0 > > fn =3D {fn_type =3D 1, fn_ptr =3D {std_func =3D 0x8007ccff0 , cxa_func =3D 0x8007ccff0 }, fn_arg =3D 0x0, fn_dso =3D= 0x0} > > n =3D -1 > > has_phdr =3D 0 > > #6 0x00000008045683c7 in exit (status=3D0) at /usr/src/lib/libc/stdlib= /exit.c:67 > > No locals. > > #7 0x0000000000556817 in Fkill_emacs (arg=3DCould not find the frame b= ase for "Fkill_emacs". > > ) at emacs.c:2146 > > gcpro1 =3D Could not find the frame base for "Fkill_emacs". > > Current language: auto; currently asm =20 > Ewww. Please try this. >=20 > diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c > index 97cf234..511172a 100644 > --- a/lib/libc/stdlib/atexit.c > +++ b/lib/libc/stdlib/atexit.c > @@ -200,6 +200,6 @@ __cxa_finalize(void *dso) > if (dso =3D=3D NULL) > _MUTEX_DESTROY(&atexit_mutex); > =20 > - if (&__pthread_cxa_finalize !=3D NULL) > + if (has_phdr && &__pthread_cxa_finalize !=3D NULL) > __pthread_cxa_finalize(&phdr_info); > } That fixed it. Thanks a lot. Fabian --Sig_/sZIOLvqIw__qVj8hA1SWr9S Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkx4Fh8ACgkQBYqIVf93VJ0hZQCgwr9nDDhmhXx/rW/i+wf93hbL PWUAoMmeu0Q9n4HEO7GNkBrNbRZUpcUe =YJGB -----END PGP SIGNATURE----- --Sig_/sZIOLvqIw__qVj8hA1SWr9S-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 20:00:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA62210656A3 for ; Fri, 27 Aug 2010 20:00:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD5D8FC08 for ; Fri, 27 Aug 2010 20:00:07 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7RK032U076481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Aug 2010 23:00:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7RK03BD037376; Fri, 27 Aug 2010 23:00:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7RK03e4037375; Fri, 27 Aug 2010 23:00:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Aug 2010 23:00:03 +0300 From: Kostik Belousov To: Fabian Keil Message-ID: <20100827200003.GC2396@deviant.kiev.zoral.com.ua> References: <20100827182108.12764ff4@r500.local> <20100827190407.GA2396@deviant.kiev.zoral.com.ua> <20100827212534.5960efdf@r500.local> <20100827193720.GB2396@deviant.kiev.zoral.com.ua> <20100827214635.40471d37@r500.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8rHj2ch2EiN5qBn3" Content-Disposition: inline In-Reply-To: <20100827214635.40471d37@r500.local> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:00:08 -0000 --8rHj2ch2EiN5qBn3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 27, 2010 at 09:46:35PM +0200, Fabian Keil wrote: > > diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c > > index 97cf234..511172a 100644 > > --- a/lib/libc/stdlib/atexit.c > > +++ b/lib/libc/stdlib/atexit.c > > @@ -200,6 +200,6 @@ __cxa_finalize(void *dso) > > if (dso =3D=3D NULL) > > _MUTEX_DESTROY(&atexit_mutex); > > =20 > > - if (&__pthread_cxa_finalize !=3D NULL) > > + if (has_phdr && &__pthread_cxa_finalize !=3D NULL) > > __pthread_cxa_finalize(&phdr_info); > > } >=20 > That fixed it. Thanks a lot. Thank for your help, fixed in r211894. --8rHj2ch2EiN5qBn3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx4GUMACgkQC3+MBN1Mb4i3UgCgvyqh60JWR+zW9rmft33ylt7X r1AAoK8L1oT3wpg+K2eYWwrvGJ4mnLh1 =zs3+ -----END PGP SIGNATURE----- --8rHj2ch2EiN5qBn3-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 20:31:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FB3A1065693 for ; Fri, 27 Aug 2010 20:31:56 +0000 (UTC) (envelope-from sullrich@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 18D618FC08 for ; Fri, 27 Aug 2010 20:31:55 +0000 (UTC) Received: by iwn36 with SMTP id 36so3279257iwn.13 for ; Fri, 27 Aug 2010 13:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=y9/y8wQshMO/fsLN5vje5fkSukJUzKocdVmZ2Bs2ns0=; b=KjHK4ypjrb1Fm2fwViO22BTWuc6b57JQWIjW7Yw0Jf6STN6r/PA03JNCHdad6+Wk9L peNfbkJ2VnPfF5+b1/wTp6U0W+VjufbpGKI0C7XjwHQ0SIEsOCb3CzE9Ys2YtolXLVTy LGCR8NBRg/z7KfsZ2X3TiX+qlr8WZCQ82tiqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=I2kgGfQfU7PiN+33J1UL5DjCNcKbxG9yCjmeR6V2FLjKHzBXm84oxxxCBoKpmSV5j9 LTLNWoVvsimJfQEIXk4Jrg9kVPvqCkyYgeBSVu/QtWiOrXR/jWWHN46WPQNrbhgfBXcv 5HQDqG0/pXQ0Nsei4lQ8J3QljNbQLjlFls9Rs= Received: by 10.231.11.71 with SMTP id s7mr1611277ibs.85.1282939613526; Fri, 27 Aug 2010 13:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.148.10 with HTTP; Fri, 27 Aug 2010 13:06:33 -0700 (PDT) In-Reply-To: <4C739C55.3020800@FreeBSD.org> References: <4C739C55.3020800@FreeBSD.org> From: Scott Ullrich Date: Fri, 27 Aug 2010 16:06:33 -0400 Message-ID: To: Martin Matuska Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: [CFT] ZFS ACL and rrwlock speedup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:31:56 -0000 2010/8/24 Martin Matuska : > Dear FreeBSD community, > > in my last CFT I presented a patch that improves ZFS write speed. There > have been easily portable improvements on the read side in OpenSolaris, > too. Of course, the improvement here is by far not that dramatic as in > the zfs_metaslab.patch, but OpenSolaris developers claim this also > improves the speed of stat() calls. > > I would like to Call For Testing for the following patch (9-CURRENT): > http://people.freebsd.org/~mm/patches/zfs/zfs_abe_stat_rrwlock.patch > > This patch adds the following: > - better ACL caching and speedup of the ACL permission checks > - lowered mutex contention in the read/writer lock (rrwlock) > - several bugfixes > > This patch does not interfere with the zfs_metaslab.patch > > To apply the patch against 8-STABLE, you need to apply the v15 update first: > http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch > > The patch imports the following OpenSolaris onnv revisions: > 9749 (without zlook), 9866, 9981, 10143, 10232, 10295, 10250, 10269 > > And covers the following OpenSolaris Bug IDs: > 6802734 Support for Access Based Enumeration (not used on FreeBSD) > 6844861 inconsistent xattr readdir behavior with too-small buffer > 6848431 zfs with rstchown=0 or file_chown_self privilege allows user to > "take" ownership > 6775100 stat() performance on files on zfs should be improved > 6827779 rrwlock is overly protective of its counters > 6857433 memory leaks found at: zfs_acl_alloc/zfs_acl_node_alloc > 6860318 truncate() on zfsroot succeeds when file has a component of its > path set without access permission > 6865875 zfs sometimes incorrectly giving search access to a dir > 6870564 panic in zfs_getsecattr > 6867395 zpool_upgrade_007_pos testcase panic'd with BAD TRAP: type=e > (#pf Page fault) > 6868276 zfs_rezget() can be hazardous when znode has a cached ACL So far so good on this patch as well. Running it for a good 3 days with 4TB and it is nice and fast (220MB/sec for 1.5 TB drives). Scott From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 20:32:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 527B110656A8 for ; Fri, 27 Aug 2010 20:32:53 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 004B38FC20 for ; Fri, 27 Aug 2010 20:32:52 +0000 (UTC) Received: by yxn35 with SMTP id 35so885885yxn.13 for ; Fri, 27 Aug 2010 13:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0us22LIwELvEYB/IphOGL+JXQOun/qunXvLil2cB7YI=; b=HQFUrhMjIbSkbYd95BuiEfZRGh3krY0smd24RrXQ7akqDwm9i9+PZh4x2VsYTdsj3M 87PzpMLp1glJLYp6BY7qqREdl1z7Bd7YiP3kFE+/uJfYoPOS0kM261cdMXNMu5pkJ5Gj kF3vCVHUhRIXVCpt195RqSC9hZauEVyg2ZXqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gMScISKwkHx7GRbgFDNWClsAq2F5f+qhdwaiPqx7WveTp33RHdoDUJvSfuuvE4vHo6 cmijoNWGShOJHRFVsU7RBmteCiiFmq1lesCCmhTib39WcEUu/gk2cSxq6zD3FPtOjPan DsE0/i96+IC+E//Lfq44Na2kGF3sYg6iuWaco= Received: by 10.151.7.9 with SMTP id k9mr2539417ybi.46.1282939520180; Fri, 27 Aug 2010 13:05:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.148.10 with HTTP; Fri, 27 Aug 2010 13:05:00 -0700 (PDT) In-Reply-To: <4C714FC0.90005@FreeBSD.org> References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> From: Scott Ullrich Date: Fri, 27 Aug 2010 16:05:00 -0400 Message-ID: To: Martin Matuska Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:32:53 -0000 On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska wrote: > =A0Thank you, I have updated the v15 patch for 8-STABLE. I have been running your patch for a couple days now and no issues. Nice work! Scott From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 21:29:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4E7D106576B; Fri, 27 Aug 2010 21:29:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6C76B8FC18; Fri, 27 Aug 2010 21:29:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7RLT4B5014786; Fri, 27 Aug 2010 17:29:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7RLT4GB014775; Fri, 27 Aug 2010 21:29:04 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 27 Aug 2010 21:29:04 GMT Message-Id: <201008272129.o7RLT4GB014775@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 21:29:05 -0000 TB --- 2010-08-27 20:41:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-27 20:41:32 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-27 20:41:32 - cleaning the object tree TB --- 2010-08-27 20:41:48 - cvsupping the source tree TB --- 2010-08-27 20:41:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-27 21:01:08 - building world TB --- 2010-08-27 21:01:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-27 21:01:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-27 21:01:08 - TARGET=powerpc TB --- 2010-08-27 21:01:08 - TARGET_ARCH=powerpc64 TB --- 2010-08-27 21:01:08 - TZ=UTC TB --- 2010-08-27 21:01:08 - __MAKE_CONF=/dev/null TB --- 2010-08-27 21:01:08 - cd /src TB --- 2010-08-27 21:01:08 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 27 21:01:09 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-27 21:29:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-27 21:29:04 - ERROR: failed to build world TB --- 2010-08-27 21:29:04 - 1144.83 user 376.58 system 2851.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 23:19:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 5C8EF1065670; Fri, 27 Aug 2010 23:19:18 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sat, 28 Aug 2010 08:19:17 +0900 From: Norikatsu Shigemura To: Martin Matuska Message-Id: <20100828081917.ee931f7f.nork@FreeBSD.org> In-Reply-To: References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Olivier Smedts , freebsd-current@freebsd.org, Scott, nork@FreeBSD.org, Ullrich Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 23:19:19 -0000 Hi mm. On Fri, 27 Aug 2010 16:05:00 -0400 Scott Ullrich wrote: > On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska wrote: > >  Thank you, I have updated the v15 patch for 8-STABLE. > I have been running your patch for a couple days now and no issues. > Nice work! Yes, me too. I'll try to zpool/zfs upgrade! I'm waiting for your update v15, metaslab and abe_stat_rrwlock:-). -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 23:50:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7CD210656A4 for ; Fri, 27 Aug 2010 23:50:35 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 80D7B8FC15 for ; Fri, 27 Aug 2010 23:50:35 +0000 (UTC) Received: by vws7 with SMTP id 7so3979792vws.13 for ; Fri, 27 Aug 2010 16:50:34 -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:content-type:content-transfer-encoding; bh=1MYwA+yb1yh9IT63EJTcvfuBY547UX+9HIZiMEB08Y8=; b=r0OdbUsU+/66+a/4v1sBoxDRmsuJkIaS5EeRUvtuxgPEVy22Q5d0vZ2GxaEMZX9NHm P5u81M4iSIx7jlEzVgNu+/Be0TyV1jQ3joh7Rmpjkmk6wHLZqUAIdoa2hlXqXlltp0Te HK5EkkGOixDZzndqviXYmK7Zq6M2+PxkKC5wg= 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:content-type :content-transfer-encoding; b=JTazy0rYnE6vRmb+dq5Xv/N5JV84TOMBGKJYUWAN2JFF19/9aCETIYDRMXvNU9QFYp 22sZaOlLjwXf8l+xJKUyiUlDGqdju+G5Q7j96KwMdfzjmyb6grC1THY8g6pYNO7GYYln QGOWpUgs3VWZga0ASl+xF4jxzw+WwU6fvAyWU= MIME-Version: 1.0 Received: by 10.220.88.155 with SMTP id a27mr956703vcm.149.1282953034829; Fri, 27 Aug 2010 16:50:34 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.66.227 with HTTP; Fri, 27 Aug 2010 16:50:34 -0700 (PDT) In-Reply-To: <20100828081917.ee931f7f.nork@FreeBSD.org> References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> <20100828081917.ee931f7f.nork@FreeBSD.org> Date: Fri, 27 Aug 2010 16:50:34 -0700 X-Google-Sender-Auth: JGELYy2t2U3gqQP-V0766KFHRK0 Message-ID: From: Artem Belevich To: Martin Matuska , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 23:50:36 -0000 Another "me too" here. 8-stable/amd64 + v15 (zpool still uses v14) + metaslab + abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches. The box survived few days of pounding on it without any signs of trouble. --Artem On Fri, Aug 27, 2010 at 4:19 PM, Norikatsu Shigemura wro= te: > Hi mm. > > On Fri, 27 Aug 2010 16:05:00 -0400 > Scott Ullrich wrote: >> On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska wrote: >> > =A0Thank you, I have updated the v15 patch for 8-STABLE. >> I have been running your patch for a couple days now and no issues. >> Nice work! > > =A0 =A0 =A0 =A0Yes, me too. =A0I'll try to zpool/zfs upgrade! > =A0 =A0 =A0 =A0I'm waiting for your update v15, metaslab and abe_stat_rrw= lock:-). > > -- > Norikatsu Shigemura > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 01:24:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C7510656A8 for ; Sat, 28 Aug 2010 01:24:48 +0000 (UTC) (envelope-from jhellenthal@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 808B08FC17 for ; Sat, 28 Aug 2010 01:24:48 +0000 (UTC) Received: by iwn36 with SMTP id 36so3534514iwn.13 for ; Fri, 27 Aug 2010 18:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=3ehRE4cpqjmbvGXfjlCs6ExgR1/OO1L9IB9tYcp/gVI=; b=NqN0258Ccku0MFlaHy8Z87vZaNozKjEKx3wCPj6A2UlhJaKa5O3dP+n8ygdmtZA3lD e7ZyF5spKvcUq0J5IKq6IKx07IlM29bzKNwRfaUTXtXTLxvxAVTjLY/ePLWMcLwbozAd uGzdmg6FrLv/e/P2kaCjhJPBALtk/O9RQlA3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=i5BEHakuCNsuAQIzSPbTIOhmRkt1lVdweZHMG6mt98UH4ZULLUoBMTtkjK72WeCbsf XzZ/c83ZzLlQrkSPsNjBG+8zP/f6f1ujibl5lt0ihLg0AbSVdgcYoKyY1trSKL0hYI0/ l0yZzxnAdBbHstFaX2olrP0Zm4k3OKMVJHZFE= Received: by 10.231.183.67 with SMTP id cf3mr1884602ibb.187.1282958687744; Fri, 27 Aug 2010 18:24:47 -0700 (PDT) Received: from centel.dataix.local ([99.181.137.20]) by mx.google.com with ESMTPS id r3sm4219121ibk.1.2010.08.27.18.24.45 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Aug 2010 18:24:46 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C78655C.3010200@DataIX.net> Date: Fri, 27 Aug 2010 21:24:44 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Artem Belevich References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> <20100828081917.ee931f7f.nork@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Martin Matuska Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 01:24:48 -0000 On 08/27/2010 19:50, Artem Belevich wrote: > Another "me too" here. > > 8-stable/amd64 + v15 (zpool still uses v14) + metaslab + > abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches. > > The box survived few days of pounding on it without any signs of trouble. > I must have missed the uma defrag patches but according to the code those patches should not have any effect on your implimentation of ZFS on your system because vfs.zfs.zio.use_uma defaults to off unless you have manually turned this on or the patch reverts that facility back to its original form. Running on a full ZFSv15 system with the metaslab & rrwlock patches and a slightly modified patch from avg@ for vm_paging_needed() I was able to achieve the results in read and write ops that I was looking for. The modified patch from avg@ (portion patch) is: #ifdef _KERNEL if (arc_reclaim_needed()) { needfree = 0; wakeup(&needfree); } #endif I still moved that down to below _KERNEL for the obvious reasons. But when I was using the original patch with if (needfree) I noticed a performance degradation after ~12 hours of use with and without UMA turned on. So far with ~48 hours of testing with the top half of that being with the above change, I have not seen more degradation of performance after that ~12 hour mark. In another 12 hours of testing with UMA turned off Ill be turning UMA back on and testing for another 24 hours. Before that third patch from avg@ had come along I had turned UMA on and had no performance loss for ~7 hours. Obviously I had to reboot after applying avg@'s patch and decided to test strictly without UMA at that point. There seems to be a problem in the logic behind the needfree use and or arc_reclaim_needed() area that should be worked out, but at least for this system i386 8.1-STABLE where my code is at right now "Is STABLE!". ======================================================================= For reference I have also adjusted these: (arc.c) - /* Start out with 1/8 of all memory */ - arc_c = kmem_size() / 8; + /* Start out with 1/4 of all memory */ + arc_c = kmem_size() / 4; And these: (arc.c) - arc_c = MIN(arc_c, vmem_size(heap_arena, VMEM_ALLOC | VMEM_FREE) / 8); + arc_c = MIN(arc_c, vmem_size(heap_arena, VMEM_ALLOC | VMEM_FREE) / 4); There seems to be no relative way currently to handle adjusting these properly based on the amount of memory in the system and sets a blind default currently to 1/8 and in a system with 2GB that is ~256MB but if you are adjusting to kmem_size as stated above and you set KVA_PAGES to 512 like suggested, then you end up with an arc_c equaling 64MB. So unless you adjust your kmem_size accordingly on some systems to make up for the 1/8th problem your ZFS install is going to suffer. This is more of a problem for systems below the 2GB memory range. Now for systems that have quite high ranges of memory 8G for example your really only using 1GB and it will be fairly hard besides adjusting the source to use more RAM without effecting something else in the system inherently by bumping vm.kmem_size* ======================================================================= 1GB RAM on ZFSv15 with the patches mentioned: (loader.conf) adjust accordingly to your own systems environment. kern.maxdsiz="640M" kern.maxusers="512" # Overcome the max calculated 384 for >1G of MEM. # See: /sys/kern/subr_param.c for details. ??? vfs.zfs.arc_min="62M" vfs.zfs.arc_max="496M" vfs.zfs.prefetch_disable=0 vm.kmem_size="512M" vm.kmem_size_max="768M" vm.kmem_size_min="128M" Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 03:34:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26EC10656AC; Sat, 28 Aug 2010 03:34:19 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 350C58FC0A; Sat, 28 Aug 2010 03:34:18 +0000 (UTC) Received: by vws7 with SMTP id 7so4093374vws.13 for ; Fri, 27 Aug 2010 20:34:18 -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=pmvM1AJQPCiiI8NBdYWpMbu/QsYijCwJW1o2Mf7liQo=; b=sn4GwLVnwjUG+lUtph5OQ6vuPZOPqOMoP07EDasFDJPpFIzBcpp5QKcU4nPYRk8vGW 8r29OlMnjFEhYtqyqggAfwP//tOtkakYa0oguCblp+aD5iIYU7s85wSTqXSXzGQk6ze6 mccb0/lIwmuGFAZltTL76Ig/ocLobrYBPb72s= 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=gD+TzcjDccbsYIHuGhgexMxOuKaScpsqaKViwWfe9tsuVoo7K0nJF2NDzVkCCwfBRW PPRY1x5SEcJpHadlm39WEx9kfrNn3+h4dDl6YOv4lekrSZcOLgftdpFsqKjeF7g12xYx k1e4jrUe6XK0jFLALkNVRxQ93ehfmvk5bb7rs= MIME-Version: 1.0 Received: by 10.220.125.38 with SMTP id w38mr1012180vcr.189.1282966458134; Fri, 27 Aug 2010 20:34:18 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.66.227 with HTTP; Fri, 27 Aug 2010 20:34:18 -0700 (PDT) In-Reply-To: <4C78655C.3010200@DataIX.net> References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> <20100828081917.ee931f7f.nork@FreeBSD.org> <4C78655C.3010200@DataIX.net> Date: Fri, 27 Aug 2010 20:34:18 -0700 X-Google-Sender-Auth: gPOTKelcpzKLc4vFq-Pee6tKKQ8 Message-ID: From: Artem Belevich To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Martin Matuska Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 03:34:19 -0000 On Fri, Aug 27, 2010 at 6:24 PM, jhell wrote: > On 08/27/2010 19:50, Artem Belevich wrote: >> Another "me too" here. >> >> 8-stable/amd64 + v15 (zpool still uses v14) + metaslab + >> abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches. >> >> The box survived few days of pounding on it without any signs of trouble= . >> > > =A0 =A0 =A0 =A0I must have missed the uma defrag patches but according to= the code Here is the UMA patch I was talking about: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2010-08/msg00188.ht= ml > those patches should not have any effect on your implimentation of ZFS > on your system because vfs.zfs.zio.use_uma defaults to off unless you > have manually turned this on or the patch reverts that facility back to > its original form. Hmm. Indeed. Kmem_malloc carves memory allocations directly from kmem. Yet the difference in max ARC size with the patch applied is there. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2010-08/msg00257.ht= ml Perhaps reduced UMA fragmentation helps those subsystem that do use UMA (including ZFS which always uses uma for various housekeeping data). --Artem From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 08:14:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D11810656C1; Sat, 28 Aug 2010 08:14:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8F17A8FC18; Sat, 28 Aug 2010 08:14:06 +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 LAA02316; Sat, 28 Aug 2010 11:14:00 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OpGY4-0007C0-E1; Sat, 28 Aug 2010 11:14:00 +0300 Message-ID: <4C78C543.40302@icyb.net.ua> Date: Sat, 28 Aug 2010 11:13:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: jhell References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> <20100828081917.ee931f7f.nork@FreeBSD.org> <4C78655C.3010200@DataIX.net> In-Reply-To: <4C78655C.3010200@DataIX.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Artem Belevich , Martin Matuska Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 08:14:07 -0000 on 28/08/2010 04:24 jhell said the following: > I must have missed the uma defrag patches but according to the code > those patches should not have any effect on your implimentation of ZFS > on your system because vfs.zfs.zio.use_uma defaults to off unless you > have manually turned this on or the patch reverts that facility back to > its original form. ZFS uses UMA even for other things besides ARC and those are not controlled by vfs.zfs.zio.use_uma. Those zones also happen to be the most fragmented ones for me. To name a few: dnode_t, dmu_buf_impl_t, arc_buf_hdr_t. So the patch should help there. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 08:20:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5BB51065695; Sat, 28 Aug 2010 08:20:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EA1518FC16; Sat, 28 Aug 2010 08:20:24 +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 LAA02397; Sat, 28 Aug 2010 11:20:20 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OpGeC-0007Cb-Di; Sat, 28 Aug 2010 11:20:20 +0300 Message-ID: <4C78C6C3.1010005@icyb.net.ua> Date: Sat, 28 Aug 2010 11:20:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: jhell References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> <20100828081917.ee931f7f.nork@FreeBSD.org> <4C78655C.3010200@DataIX.net> In-Reply-To: <4C78655C.3010200@DataIX.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Artem Belevich , Martin Matuska Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 08:20:25 -0000 on 28/08/2010 04:24 jhell said the following: > The modified patch from avg@ (portion patch) is: > > #ifdef _KERNEL > if (arc_reclaim_needed()) { > needfree = 0; > wakeup(&needfree); > } > #endif > > I still moved that down to below _KERNEL for the obvious reasons. But > when I was using the original patch with if (needfree) I noticed a > performance degradation after ~12 hours of use with and without UMA > turned on. So far with ~48 hours of testing with the top half of that > being with the above change, I have not seen more degradation of This is quite unexpected. needfree should be checked as the very first thing in arc_reclaim_needed() [unless you have patched it locally]. So if needfree is 1 then arc_reclaim_needed() should also return 1. But the converse is not true, arc_reclaim_needed() may return 1 even if needfree is zero. So if your testing results are conclusive then it must mean that some extra wakeups on needfree are needed. I.e. needfree is zero, so there shouldn't be anything waiting on it (see arc_lowmem) and no notification should be needed, but issuing somehow does make difference, Hmm... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 09:03:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5479F1065694; Sat, 28 Aug 2010 09:03:56 +0000 (UTC) (envelope-from jhellenthal@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 044478FC14; Sat, 28 Aug 2010 09:03:55 +0000 (UTC) Received: by iwn36 with SMTP id 36so3827916iwn.13 for ; Sat, 28 Aug 2010 02:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=jFLv9I3QR74RIUEzQf6j7AxtIOZ6YKQJ8Hf6xi7efWw=; b=xEidw9RtGD5i018+rzzDaTL7gKDRJ57MPhDtkqqdNuzvBsBFE5aZfZxE5YG9fjGWrm Kj22JxmsB1U6gFzZu/Ii/R65BampmZcHFCyBY5uoJgDu3Frr/xsHi2O2VzPATIvj+yNd 43jx4TDeknLPfpXgMsC5lhHpne6E5Q+vL4WgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=RdeT43Td55tNL9chQD6tbIEPrlIFX2PRttAbXLQyd52hPiBk9t1xvZv9lxYErcpRtc bWGpbjW3Q2WFdQreKYbyeYEzRbxVWBGkYRMll3fgkewqMlBkfHzDQTEjX+n7tivy48Md 54/LPmHgLMW2pBhKpf+RWWC85ppcjbPXHFELA= Received: by 10.231.11.71 with SMTP id s7mr2447534ibs.85.1282986225621; Sat, 28 Aug 2010 02:03:45 -0700 (PDT) Received: from centel.dataix.local ([99.181.137.20]) by mx.google.com with ESMTPS id n20sm4670291ibe.17.2010.08.28.02.03.43 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Aug 2010 02:03:44 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C78D0EE.6040708@DataIX.net> Date: Sat, 28 Aug 2010 05:03:42 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Andriy Gapon References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> <20100828081917.ee931f7f.nork@FreeBSD.org> <4C78655C.3010200@DataIX.net> <4C78C6C3.1010005@icyb.net.ua> In-Reply-To: <4C78C6C3.1010005@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Artem Belevich , Martin Matuska Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 09:03:56 -0000 On 08/28/2010 04:20, Andriy Gapon wrote: > on 28/08/2010 04:24 jhell said the following: >> The modified patch from avg@ (portion patch) is: >> >> #ifdef _KERNEL >> if (arc_reclaim_needed()) { >> needfree = 0; >> wakeup(&needfree); >> } >> #endif >> >> I still moved that down to below _KERNEL for the obvious reasons. But >> when I was using the original patch with if (needfree) I noticed a >> performance degradation after ~12 hours of use with and without UMA >> turned on. So far with ~48 hours of testing with the top half of that >> being with the above change, I have not seen more degradation of > > This is quite unexpected. > needfree should be checked as the very first thing in arc_reclaim_needed() > [unless you have patched it locally]. So if needfree is 1 then > arc_reclaim_needed() should also return 1. But the converse is not true, > arc_reclaim_needed() may return 1 even if needfree is zero. > > So if your testing results are conclusive then it must mean that some extra > wakeups on needfree are needed. I.e. needfree is zero, so there shouldn't be > anything waiting on it (see arc_lowmem) and no notification should be needed, > but issuing somehow does make difference, > Hmm... > I will look further into this and see if I can throw a counter around it or some printf's so I can at least log what its doing in both instances. I thought the very same thing you said above when I saw your patch for that and was astounded at the results that were returned from it. So in short testing I reverted it back quickly to see if that was the cause of the problem and sure enough everything resumed to the way it was before. Anyway thanks for the reply. I will get back to you if I see anything cool arise from this. Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 09:26:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 021A01065696 for ; Sat, 28 Aug 2010 09:26:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC0E8FC0A for ; Sat, 28 Aug 2010 09:26:16 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 12C2145EAE; Sat, 28 Aug 2010 11:26:15 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DB63045E87; Sat, 28 Aug 2010 11:26:09 +0200 (CEST) Date: Sat, 28 Aug 2010 11:26:02 +0200 From: Pawel Jakub Dawidek To: jhell Message-ID: <20100828092602.GG2077@garage.freebsd.pl> References: <4C713EF5.8080402@FreeBSD.org> <4C714FC0.90005@FreeBSD.org> <20100828081917.ee931f7f.nork@FreeBSD.org> <4C78655C.3010200@DataIX.net> <4C78C6C3.1010005@icyb.net.ua> <4C78D0EE.6040708@DataIX.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Iq5ULCa7nGtWwZS" Content-Disposition: inline In-Reply-To: <4C78D0EE.6040708@DataIX.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Martin Matuska , freebsd-current@freebsd.org, Andriy Gapon , Artem Belevich Subject: Re: [CFT] Improved ZFS metaslab code (faster write speed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 09:26:17 -0000 --9Iq5ULCa7nGtWwZS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 28, 2010 at 05:03:42AM -0400, jhell wrote: > On 08/28/2010 04:20, Andriy Gapon wrote: > > on 28/08/2010 04:24 jhell said the following: > >> The modified patch from avg@ (portion patch) is: > >> > >> #ifdef _KERNEL > >> if (arc_reclaim_needed()) { > >> needfree =3D 0; > >> wakeup(&needfree); > >> } > >> #endif > >> > >> I still moved that down to below _KERNEL for the obvious reasons. But > >> when I was using the original patch with if (needfree) I noticed a > >> performance degradation after ~12 hours of use with and without UMA > >> turned on. So far with ~48 hours of testing with the top half of that > >> being with the above change, I have not seen more degradation of > >=20 > > This is quite unexpected. > > needfree should be checked as the very first thing in arc_reclaim_neede= d() > > [unless you have patched it locally]. So if needfree is 1 then > > arc_reclaim_needed() should also return 1. But the converse is not tru= e, > > arc_reclaim_needed() may return 1 even if needfree is zero. > >=20 > > So if your testing results are conclusive then it must mean that some e= xtra > > wakeups on needfree are needed. I.e. needfree is zero, so there should= n't be > > anything waiting on it (see arc_lowmem) and no notification should be n= eeded, > > but issuing somehow does make difference, > > Hmm... > >=20 >=20 > I will look further into this and see if I can throw a counter around it > or some printf's so I can at least log what its doing in both instances. >=20 > I thought the very same thing you said above when I saw your patch for > that and was astounded at the results that were returned from it. So in > short testing I reverted it back quickly to see if that was the cause of > the problem and sure enough everything resumed to the way it was before. >=20 > Anyway thanks for the reply. I will get back to you if I see anything > cool arise from this. Could you include the following patch to your testing: http://people.freebsd.org/~pjd/patches/arc.c.9.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --9Iq5ULCa7nGtWwZS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkx41ioACgkQForvXbEpPzRrUACg9sVloPTUnapi2fJGssoVg0VU Th0An0B3wVgQh+UYIs4WTmsRe0LoPU+P =TQVw -----END PGP SIGNATURE----- --9Iq5ULCa7nGtWwZS-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 14:15:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 274F410656B0; Sat, 28 Aug 2010 14:15:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CF2618FC15; Sat, 28 Aug 2010 14:15:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7SEFWHL069282; Sat, 28 Aug 2010 10:15:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7SEFWT7069266; Sat, 28 Aug 2010 14:15:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 28 Aug 2010 14:15:32 GMT Message-Id: <201008281415.o7SEFWT7069266@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 14:15:34 -0000 TB --- 2010-08-28 13:46:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-28 13:46:24 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-28 13:46:24 - cleaning the object tree TB --- 2010-08-28 13:46:37 - cvsupping the source tree TB --- 2010-08-28 13:46:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-28 13:47:18 - building world TB --- 2010-08-28 13:47:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-28 13:47:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-28 13:47:18 - TARGET=powerpc TB --- 2010-08-28 13:47:18 - TARGET_ARCH=powerpc64 TB --- 2010-08-28 13:47:18 - TZ=UTC TB --- 2010-08-28 13:47:18 - __MAKE_CONF=/dev/null TB --- 2010-08-28 13:47:18 - cd /src TB --- 2010-08-28 13:47:18 - /usr/bin/make -B buildworld >>> World build started on Sat Aug 28 13:47:19 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-28 14:15:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-28 14:15:32 - ERROR: failed to build world TB --- 2010-08-28 14:15:32 - 1142.86 user 372.12 system 1748.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 17:30:10 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA0110656AC for ; Sat, 28 Aug 2010 17:30:10 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8FB8FC16 for ; Sat, 28 Aug 2010 17:30:10 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id o7SHU9Io008672 for ; Sat, 28 Aug 2010 13:30:09 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id o7SHU9nn008669; Sat, 28 Aug 2010 13:30:09 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19577.18337.120013.129482@hergotha.csail.mit.edu> Date: Sat, 28 Aug 2010 13:30:09 -0400 From: Garrett Wollman To: current@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 28 Aug 2010 13:30:09 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu Cc: Subject: Difficulty playing DVDs under AHCI/CAM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 17:30:11 -0000 After a recent upgrade, I switched to AHCI/CAM for my SATA devices, including a new DVD drive. Now I find that nothing can play DVDs any more. For example, here's what mplayer does: 8469 initial thread CALL open(0x806c25450,O_RDONLY,0) 8469 initial thread NAMI "/dev/cd0" 8469 initial thread RET open 3 8469 initial thread CALL fstat(0x3,0x7fffffffb410) 8469 initial thread STRU struct stat {dev=50396928, ino=89, mode=crw-r----- , nlink=1, uid=0, gid=5, rdev=89, atime=1282953341.461532000, stime=1282953341.461532000, ctime=1282953341.461532000, birthtime=-1, size=0, blksize=4096, blocks=0, flags=0x0 } 8469 initial thread RET fstat 0 8469 initial thread CALL ioctl(0x3,DVDIOCREADSTRUCTURE,0x7fffffffac30) 8469 initial thread RET ioctl 0 8469 initial thread CALL ioctl(0x3,DVDIOCREPORTKEY,0x7fffffffb430) 8469 initial thread RET ioctl 0 ...so two DVD-specific ioctl calls succeed... 8469 initial thread CALL open(0x7fffffffbcd0,O_RDWR|O_CREAT,S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH) 8469 initial thread NAMI "/home/wollman/.dvdcss/CACHEDIR.TAG" 8469 initial thread RET open 4 ...write to this file omitted for clarity... 8469 initial thread CALL close(0x4) 8469 initial thread RET close 0 8469 initial thread CALL read(0x3,0x7fffffffb4d0,0x800) 8469 initial thread RET read -1 errno 6 Device not configured ...say what? Why is the cd driver suddenly returning ENXIO? 8469 initial thread CALL lseek(0x3,0,SEEK_SET) 8469 initial thread RET lseek 0 8469 initial thread CALL lseek(0x3,0x80000,SEEK_SET) 8469 initial thread RET lseek 524288/0x80000 8469 initial thread CALL read(0x3,0x7fffffff6000,0x800) 8469 initial thread RET read -1 errno 6 Device not configured 8469 initial thread CALL write(0x2,0x7fffffffb2b0,0x43) 8469 initial thread GIO fd 2 wrote 67 bytes "libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed " Same results (but without error messages) in vlc. My drive is identified as: at scbus0 target 0 lun 0 (pass0,cd0) -GAWollman From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 17:38:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09CE01065670 for ; Sat, 28 Aug 2010 17:38:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E24C8FC15 for ; Sat, 28 Aug 2010 17:38:37 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA08165; Sat, 28 Aug 2010 20:38:36 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OpPMS-0007n0-6W; Sat, 28 Aug 2010 20:38:36 +0300 Message-ID: <4C79499B.3050305@icyb.net.ua> Date: Sat, 28 Aug 2010 20:38:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Garrett Wollman References: <19577.18337.120013.129482@hergotha.csail.mit.edu> In-Reply-To: <19577.18337.120013.129482@hergotha.csail.mit.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Difficulty playing DVDs under AHCI/CAM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 17:38:39 -0000 on 28/08/2010 20:30 Garrett Wollman said the following: > After a recent upgrade, I switched to AHCI/CAM for my SATA devices, > including a new DVD drive. Now I find that nothing can play DVDs any > more. For example, here's what mplayer does: [snip] > 8469 initial thread CALL close(0x4) > 8469 initial thread RET close 0 > 8469 initial thread CALL read(0x3,0x7fffffffb4d0,0x800) > 8469 initial thread RET read -1 errno 6 Device not configured > > ...say what? Why is the cd driver suddenly returning ENXIO? Strange indeed. Can you dtrace this read? You can use combination of syscall and fbt providers with execname predicate. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 17:41:54 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFF8D1065675 for ; Sat, 28 Aug 2010 17:41:54 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id AA96B8FC08 for ; Sat, 28 Aug 2010 17:41:54 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id o7SHfrWL008852; Sat, 28 Aug 2010 13:41:53 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id o7SHfqH1008851; Sat, 28 Aug 2010 13:41:52 -0400 (EDT) (envelope-from wollman) Date: Sat, 28 Aug 2010 13:41:52 -0400 (EDT) Message-Id: <201008281741.o7SHfqH1008851@hergotha.csail.mit.edu> From: Garrett Wollman To: avg@icyb.net.ua References: <19577.18337.120013.129482@hergotha.csail.mit.edu> <4C79499B.3050305@icyb.net.ua> Organization: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 28 Aug 2010 13:41:53 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu Cc: current@freebsd.org Subject: Re: Difficulty playing DVDs under AHCI/CAM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 17:41:55 -0000 In article <4C79499B.3050305@icyb.net.ua> avg@icyb.net.ua writes: >> [I wrote:] >> ...say what? Why is the cd driver suddenly returning ENXIO? > >Strange indeed. >Can you dtrace this read? You can use combination of syscall and fbt providers >with execname predicate. You're going to have to be much much more specific than that. -GAWollman