From owner-freebsd-hackers@FreeBSD.ORG Sun May 29 01:00:05 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A3E106566C; Sun, 29 May 2011 01:00:05 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id E007E8FC19; Sun, 29 May 2011 01:00:04 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id p4T0kGLW005978; Sat, 28 May 2011 18:46:20 -0600 From: Erich Dollansky To: freebsd-hackers@freebsd.org Date: Sun, 29 May 2011 07:47:05 +0700 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.5.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105290747.06088.erichfreebsdlist@ovitrap.com> Cc: Mark Saad , "hackers@freebsd.org" Subject: Re: Freebsd on the sun x4440 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 01:00:05 -0000 Hi, I would like to suggest to try 8.2. It is my experience that the different version behave very different on the same hardware. It does not mean that the newer version is the better. As an example, I have a machine here on 7.x as 8.0 did not support the USB hardware found. After a machine works with a branch, I will stick with this branch on the specific machine until the end of support for the branch. This make life much easier and keeps surprises away. On Thursday 17 May 2012 07:34:50 Mark Saad wrote: > All > I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs have 4x 4-core opterons and 128G of ram each . Once the servers boot they are a good fit for what we are doing and preform well . The odd thing I am seeing is a long delay in boot up . Once in the initial loading of the kernel at the "|" for 1-2 mins . Then again shortly after printing the kernel banner "freebsd 7.3-release etc etc etc" . This delay is about 1-2 mins as well. So my question does any one know what I could do to speed up the boot up ? I suspect the first delay is due to a serial device probe the second is a mystery . also the bios load up time is about 5 mins on this box does anyone have any ideas on speeding that up ? Does this machine have SCSI or SAS hardware? If the controllers are there but not drives are installed, a GENERIC kernel will wait for some time for SCSI to settle. If you deactivate SCSI or reduce the waiting time, at least a part of the problem is solved. Erich > > ---- > mark saad > Nonesuch@longcount.org_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sun May 29 01:00:05 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A3E106566C; Sun, 29 May 2011 01:00:05 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id E007E8FC19; Sun, 29 May 2011 01:00:04 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id p4T0kGLW005978; Sat, 28 May 2011 18:46:20 -0600 From: Erich Dollansky To: freebsd-hackers@freebsd.org Date: Sun, 29 May 2011 07:47:05 +0700 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.5.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105290747.06088.erichfreebsdlist@ovitrap.com> Cc: Mark Saad , "hackers@freebsd.org" Subject: Re: Freebsd on the sun x4440 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 01:00:05 -0000 Hi, I would like to suggest to try 8.2. It is my experience that the different version behave very different on the same hardware. It does not mean that the newer version is the better. As an example, I have a machine here on 7.x as 8.0 did not support the USB hardware found. After a machine works with a branch, I will stick with this branch on the specific machine until the end of support for the branch. This make life much easier and keeps surprises away. On Thursday 17 May 2012 07:34:50 Mark Saad wrote: > All > I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs have 4x 4-core opterons and 128G of ram each . Once the servers boot they are a good fit for what we are doing and preform well . The odd thing I am seeing is a long delay in boot up . Once in the initial loading of the kernel at the "|" for 1-2 mins . Then again shortly after printing the kernel banner "freebsd 7.3-release etc etc etc" . This delay is about 1-2 mins as well. So my question does any one know what I could do to speed up the boot up ? I suspect the first delay is due to a serial device probe the second is a mystery . also the bios load up time is about 5 mins on this box does anyone have any ideas on speeding that up ? Does this machine have SCSI or SAS hardware? If the controllers are there but not drives are installed, a GENERIC kernel will wait for some time for SCSI to settle. If you deactivate SCSI or reduce the waiting time, at least a part of the problem is solved. Erich > > ---- > mark saad > Nonesuch@longcount.org_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sun May 29 15:28:12 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C47991065672 for ; Sun, 29 May 2011 15:28:12 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9508FC12 for ; Sun, 29 May 2011 15:28:11 +0000 (UTC) Received: by wwc33 with SMTP id 33so3088782wwc.31 for ; Sun, 29 May 2011 08:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=5TLdprMi4pDMpDepFUtHf2SVvrBDdv1zP7Vw89elhgA=; b=g6N8mxmXNiH1BAzIYhxxzSC8C/+jhxwq/MyPpF9ipcvQVYQBVKrSBTDi/hc0S0TtSN 84u7CKFZo8hVFwq4WKrozdsjjjarOF0iKcBHdcGUzlavJSMmuMX5qH1babOz3kQz3BJq aZF5WCmLajQNME5VQc+Jf9LfvBzKjevLCndOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; b=KxqzKaRPWJ+IUKfr5Ja6r4Ju1OP2mrQ+sdVhnK6/JkDawmRLeFGxdQ73uz8OlsgaMg HEdjx85WmgWKvEk4W1ryrj4+9Q3f4cLySeisp/udOj3CTWNWF1HjnsY0ZZj+oRTG5YJO Wy6eJjpCveG0ZYSEle5ftEbHq1QdrvouoJ63I= Received: by 10.227.63.6 with SMTP id z6mr3872660wbh.53.1306682890887; Sun, 29 May 2011 08:28:10 -0700 (PDT) Received: from DEV ([82.193.208.173]) by mx.google.com with ESMTPS id gb6sm2465094wbb.17.2011.05.29.08.27.45 (version=SSLv3 cipher=OTHER); Sun, 29 May 2011 08:28:09 -0700 (PDT) Message-ID: <20110529.152808.781.1@DEV> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Sun, 29 May 2011 17:28:08 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <4DE139C9.2080808@freebsd.org> References: <20110527.124553.718.1@DEV> <20110527134754.GA94769@freebsd.org> <20110527.164723.750.2@DEV> <496B0C04-7777-458D-A116-27944A4006BB@bsdimp.com> <4DE0BA7C.8080707@freebsd.org> <20110528.130639.921.1@DEV> <4DE139C9.2080808@freebsd.org> X-Mailer: POP Peeper (3.7.0.0) Cc: Subject: Re: Active slice, only for a next boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 15:28:12 -0000 ----- Original Message -----=0D=0AFrom: Julian Elischer = =0D=0ATo: rank1seeker@gmail.com=0D=0ACc: = hackers@freebsd.org, Doug Ambrisko =0D=0ADate: Sat, = 28 May 2011 11:07:05 -0700=0D=0ASubject: Re: Active slice, only for a = next boot=0D=0A=0D=0A> On 5/28/11 6:06 AM, rank1seeker@gmail.com = wrote:=0D=0A> > And how about this:=0D=0A> >=0D=0A> > # boot0cfg -o = noupdate -s 1=0D=0A> > Now when you choose to hit slice 2, it is only for = a this one boot.=0D=0A> > Next and each boot, defaults to slice 1=0D=0A> = >=0D=0A> > Problem is, that you must see, early bootstrap, to manually = choose, so this won't work on a remote server.=0D=0A> > This = requires:=0D=0A> > a) physicall access=0D=0A> > or=0D=0A> > b) ssh = access to the remote box, which is conected via serial cable, to your = server.=0D=0A> >=0D=0A> > Anyone has any idea, for a case of a remote = server, which is accessible over ssh, only when it is "up"?=0D=0A> = =0D=0A> pull the old bootblocks from about 2000 and use them.=0D=0A> and = nextboot as well=0D=0A> they do exactly what you want.=0D=0A> =0D=0A> = OR=0D=0A> =0D=0A> ask Doug Ambrisko (cc'd) for a copy of them that he = still uses at work.=0D=0A> He may have updates to make them work with = modern systems that would =0D=0A> save you time.=0D=0A> =0D=0A> the old = nextboot(8) stored instructions as to what to do on block 1 of =0D=0A> = the drive=0D=0A> (you can make it a small 1 block partition if you = want). Actually it =0D=0A> stored a series of them, NULL = separated.=0D=0A> On each boot the boot 0 bloter would read the first = (after skipping =0D=0A> any nulls) and then write Nulls over=0D=0A> what = it just read and write it back to block 1.=0D=0A> so it would progress = gradualy boot by boot over the sequence written =0D=0A> by = nextboot.=0D=0A> =0D=0A> it would pass on the stack, what it had read to = boot1.=0D=0A> =0D=0A> =0D=0A> the format was "hd(1,a)/boot/loader" = (for example)=0D=0A> personally I would like to hav ethis capabiltiy back = because it's =0D=0A> stupid rely on a=0D=0A> possibly dead filesystem to = get around booting from the possibly dead =0D=0A> filesystem.=0D=0A> = =0D=0A> by default we used to have a /etc/rc entry that would rewrite the = =0D=0A> 'current' setup several times on successful boot,=0D=0A> followed = by a couple of alternate boot targets.=0D=0A> If boot failed a coupke of = times it would automatically boot from the =0D=0A> second drive or from = another partition,=0D=0A> ..=0D=0A> =0D=0A=0D=0AWell, if he has a working = code and you have an idea, then it should be modernized and integarted = into FreeBSD's src tree.=0D=0ASo everyone could use it.=0D=0A=0D=0A> = =0D=0A> =0D=0A> >=0D=0A> > Domagoj Smol=E8i=E6=0D=0A> > = _______________________________________________=0D=0A> > = freebsd-hackers@freebsd.org mailing list=0D=0A> > = http://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0D=0A> > To = unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org"=0D=0A> >=0D=0A> >=0D=0A> = =0D=0A> From owner-freebsd-hackers@FreeBSD.ORG Sun May 29 21:54:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10609106566B for ; Sun, 29 May 2011 21:54:12 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id C91A68FC17 for ; Sun, 29 May 2011 21:54:11 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p4TLs8ec003508; Sun, 29 May 2011 16:54:08 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 29 May 2011 16:54:04 -0500 Received: from SBHFISLTCGW07.FNFIS.COM ([10.132.248.135]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 29 May 2011 16:54:03 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW07.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 29 May 2011 16:54:01 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: <5536F45D-82C1-44EE-8BF2-E1C081FAC095@vicor.com> Date: Sun, 29 May 2011 14:53:46 -0700 Message-Id: <7D68720F-A9D2-4FAF-A9AA-D6DEB6CE473C@vicor.com> References: <20110430192737.287270@gmx.com> <20110501031105.GA16357@DataIX.net> <20110504040621.GC78390@DataIX.net> <5536F45D-82C1-44EE-8BF2-E1C081FAC095@vicor.com> To: Devin Teske X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 29 May 2011 21:54:01.0570 (UTC) FILETIME=[EB949C20:01CC1E4A] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Hellenthal , 'Dieter BSD' , freebsd-hackers@freebsd.org Subject: Re: [RELEASE] New Boot-Loader Menu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 21:54:12 -0000 On May 4, 2011, at 8:57 AM, Devin Teske wrote: >=20 > On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: >=20 >>=20 >> Devin, >>=20 >>=20 >> On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: >>>=20 >>> On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: >>>=20 >>>>=20 >>>> Devin, >>>>=20 >>>>=20 >>>> On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: >>>>>=20 >>>>>> Would be nice: "uname -v" of the kernel it will boot. >>>>>=20 >>>>> That's a bit more technically challenging. I'll have another look at = the >>>>> FICL words available, but I don't recall if there was a way to crawl = the >>>>> object space of the items loaded with ``load'' (looking for the uname= ). I'm >>>>> open to suggestions if you had an idea of how to do this in Forth -- = else >>>>> I'd think this would need to be a loader(8) modification. >>>>=20 >>>> How about forgetting a mention of unmae & ... instead look into if we >>>> can support some sort of bootcode versioning to be displayed on the >>>> screen. This would serve to be very helpful in the future when for say= a >>>> new version of bootcode for ZFS has to be installed then it would be >>>> easy for announce@ to simply say "A new version of ZFS has been MFCd a= nd >>>> requires boot version >=3D X. To find out your version please see the >>>> bottom right hand corner of your boot screen." >>>>=20 >>>> I would place a pretty good bet that loader(8) could be modified to >>>> export some sort of versioning of the bootcode to make this a easier >>>> stance for the user to gather information before a upgrade. >>>=20 >>> Piece of cake! If you give me a loader(8) that exports a "version" envi= ronment variable, I'll give the Forth functionality in mere seconds. It's a= lready been developed (but was not packaged). >>>=20 >>> I have a module named "version.4th" which prints the value of the "vers= ion" environment variable at the bottom-right of the screen underneath the = beastie logo. >>>=20 >>> Since you mention this, I'll add the code to the next package and if/wh= en loader(8) ever exports a "version" environment variable, it will just ma= gically appear. How's that sound? >>>=20 >>=20 >> Sounds perfect! >=20 > One minor adjustment... can we make that environment variable "loader_ver= sion" instead of "version"? >=20 > The code is already in for "loader_version". Whatever string you export i= nto that environment variable will be displayed on-screen at bottom-right, = right-justified. The code for thew new menu has been committed to HEAD. http://svnweb.freebsd.org/base?view=3Drevision&revision=3D222417 Now... Who wants to make the necessary patch to loader(8) to export $loader_versio= n text? Or maybe a suggestion on another list worth including on this? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 01:08:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBC17106566C for ; Mon, 30 May 2011 01:08:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id C77FA8FC0C for ; Mon, 30 May 2011 01:08:56 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p4U18kQb074482 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 29 May 2011 18:08:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DE2EE28.6050308@freebsd.org> Date: Sun, 29 May 2011 18:08:56 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Devin Teske References: <20110430192737.287270@gmx.com> <20110501031105.GA16357@DataIX.net> <20110504040621.GC78390@DataIX.net> <5536F45D-82C1-44EE-8BF2-E1C081FAC095@vicor.com> <7D68720F-A9D2-4FAF-A9AA-D6DEB6CE473C@vicor.com> In-Reply-To: <7D68720F-A9D2-4FAF-A9AA-D6DEB6CE473C@vicor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Hellenthal , 'Dieter BSD' , freebsd-hackers@freebsd.org Subject: Re: [RELEASE] New Boot-Loader Menu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 01:08:57 -0000 On 5/29/11 2:53 PM, Devin Teske wrote: > On May 4, 2011, at 8:57 AM, Devin Teske wrote: > >> On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: >> >>> Devin, >>> >>> >>> On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: >>>> On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: >>>> >>>>> Devin, >>>>> >>>>> >>>>> On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: >>>>>>> Would be nice: "uname -v" of the kernel it will boot. >>>>>> That's a bit more technically challenging. I'll have another look at the >>>>>> FICL words available, but I don't recall if there was a way to crawl the >>>>>> object space of the items loaded with ``load'' (looking for the uname). I'm >>>>>> open to suggestions if you had an idea of how to do this in Forth -- else >>>>>> I'd think this would need to be a loader(8) modification. >>>>> How about forgetting a mention of unmae& ... instead look into if we >>>>> can support some sort of bootcode versioning to be displayed on the >>>>> screen. This would serve to be very helpful in the future when for say a >>>>> new version of bootcode for ZFS has to be installed then it would be >>>>> easy for announce@ to simply say "A new version of ZFS has been MFCd and >>>>> requires boot version>= X. To find out your version please see the >>>>> bottom right hand corner of your boot screen." >>>>> >>>>> I would place a pretty good bet that loader(8) could be modified to >>>>> export some sort of versioning of the bootcode to make this a easier >>>>> stance for the user to gather information before a upgrade. >>>> Piece of cake! If you give me a loader(8) that exports a "version" environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). >>>> >>>> I have a module named "version.4th" which prints the value of the "version" environment variable at the bottom-right of the screen underneath the beastie logo. >>>> >>>> Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a "version" environment variable, it will just magically appear. How's that sound? >>>> >>> Sounds perfect! >> One minor adjustment... can we make that environment variable "loader_version" instead of "version"? >> >> The code is already in for "loader_version". Whatever string you export into that environment variable will be displayed on-screen at bottom-right, right-justified. > The code for thew new menu has been committed to HEAD. > > http://svnweb.freebsd.org/base?view=revision&revision=222417 > > Now... > > Who wants to make the necessary patch to loader(8) to export $loader_version text? > > Or maybe a suggestion on another list worth including on this? I suggest this move to -current since it is checked on there, and a port be kept for 8.x/7.x Devin, a fix was made at 222450 as it was broken for ppc. From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 02:26:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F5B3106566B; Mon, 30 May 2011 02:26:38 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1199A8FC13; Mon, 30 May 2011 02:26:37 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p4U2QYbB015162; Sun, 29 May 2011 21:26:34 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 29 May 2011 21:26:34 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 29 May 2011 21:26:34 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 29 May 2011 21:26:32 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: <4DE2EE28.6050308@freebsd.org> Date: Sun, 29 May 2011 19:26:30 -0700 Message-Id: <8C5F02EB-E700-453F-988A-0DEEB8BB263B@vicor.com> References: <20110430192737.287270@gmx.com> <20110501031105.GA16357@DataIX.net> <20110504040621.GC78390@DataIX.net> <5536F45D-82C1-44EE-8BF2-E1C081FAC095@vicor.com> <7D68720F-A9D2-4FAF-A9AA-D6DEB6CE473C@vicor.com> <4DE2EE28.6050308@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 30 May 2011 02:26:32.0942 (UTC) FILETIME=[FDC1F8E0:01CC1E70] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Hellenthal , 'Dieter BSD' , freebsd-hackers@freebsd.org Subject: Re: [RELEASE] New Boot-Loader Menu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 02:26:38 -0000 On May 29, 2011, at 6:08 PM, Julian Elischer wrote: > On 5/29/11 2:53 PM, Devin Teske wrote: >> On May 4, 2011, at 8:57 AM, Devin Teske wrote: >>=20 >>> On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: >>>=20 >>>> Devin, >>>>=20 >>>>=20 >>>> On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: >>>>> On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: >>>>>=20 >>>>>> Devin, >>>>>>=20 >>>>>>=20 >>>>>> On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: >>>>>>>> Would be nice: "uname -v" of the kernel it will boot. >>>>>>> That's a bit more technically challenging. I'll have another look a= t the >>>>>>> FICL words available, but I don't recall if there was a way to craw= l the >>>>>>> object space of the items loaded with ``load'' (looking for the una= me). I'm >>>>>>> open to suggestions if you had an idea of how to do this in Forth -= - else >>>>>>> I'd think this would need to be a loader(8) modification. >>>>>> How about forgetting a mention of unmae& ... instead look into if we >>>>>> can support some sort of bootcode versioning to be displayed on the >>>>>> screen. This would serve to be very helpful in the future when for s= ay a >>>>>> new version of bootcode for ZFS has to be installed then it would be >>>>>> easy for announce@ to simply say "A new version of ZFS has been MFCd= and >>>>>> requires boot version>=3D X. To find out your version please see the >>>>>> bottom right hand corner of your boot screen." >>>>>>=20 >>>>>> I would place a pretty good bet that loader(8) could be modified to >>>>>> export some sort of versioning of the bootcode to make this a easier >>>>>> stance for the user to gather information before a upgrade. >>>>> Piece of cake! If you give me a loader(8) that exports a "version" en= vironment variable, I'll give the Forth functionality in mere seconds. It's= already been developed (but was not packaged). >>>>>=20 >>>>> I have a module named "version.4th" which prints the value of the "ve= rsion" environment variable at the bottom-right of the screen underneath th= e beastie logo. >>>>>=20 >>>>> Since you mention this, I'll add the code to the next package and if/= when loader(8) ever exports a "version" environment variable, it will just = magically appear. How's that sound? >>>>>=20 >>>> Sounds perfect! >>> One minor adjustment... can we make that environment variable "loader_v= ersion" instead of "version"? >>>=20 >>> The code is already in for "loader_version". Whatever string you export= into that environment variable will be displayed on-screen at bottom-right= , right-justified. >> The code for thew new menu has been committed to HEAD. >>=20 >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D222417 >>=20 >> Now... >>=20 >> Who wants to make the necessary patch to loader(8) to export $loader_ver= sion text? >>=20 >> Or maybe a suggestion on another list worth including on this? > I suggest this move to -current since it is checked on there, > and a port be kept for 8.x/7.x >=20 > Devin, a fix was made at 222450 as it was broken for ppc. >=20 Regarding fix 222450: Oops. Slight oversight. Thanks for the one-liner fix. Looks like we'll have to do the same thing for the following: sys/boot/ia64/common/Makefile sys/boot/powerpc/ps3/Makefile sys/boot/sparc64/loader/Makefile Here's a patch that can be applied by anyone willing: http://druidbsd.sourceforge.net/download/loader_menu-1.6.1-HEAD201105210929= 52-fixup.patch --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. _____________ From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 17:42:46 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419B7106566C for ; Mon, 30 May 2011 17:42:46 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id AA6BF8FC16 for ; Mon, 30 May 2011 17:42:45 +0000 (UTC) Received: (qmail 2790 invoked by uid 0); 30 May 2011 17:42:44 -0000 Received: from 67.206.163.100 by rms-us010.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 30 May 2011 17:42:39 +0000 From: "Dieter BSD" Message-ID: <20110530174243.95200@gmx.com> MIME-Version: 1.0 To: hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: K+DWeUVi6DOxPQ/fDGBwy4F9ZUVSRJcS Cc: Subject: Re: Active slice, only for a next boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 17:42:46 -0000 >> I have i.e; 3 slices, of which first is active. >> Now I wana set slice 2 active, but only for a one/next boot. >> Once slice 2 is booted and system is shutdown or rebooted, >> once again, first slice is active and booted, without user's intervention. I think that setting the active slice is the wrong approach. Because then whatever OS you boot must then somehow know to automagically change the active slice back to the default. A better approach is to be able to boot whatever slice you want without having to change the active slice. NetBSD can do this.  The MBR puts up a menu of the bootable slices on the disk being booted.  You can allow the timer to time out and boot the default.  Or you can enter the number of the slice you want to boot.  Or you can type a function key F1 F2 ... to boot a different disk, and it will load the MBR from that disk and run it.  There is an alternative for keyboards without function keys. And it works great.  Except that one of the 27 stages of boot code that FreeBSD uses INSISTS on booting the active slice, so you can tell the MBR to boot slice 3 and slice 3's boot code sees that slice 4 is active and boots slice 4. My ugly workaround is to have my backup FreeBSD slice on a different disk.  The better solution would be to fix FreeBSD's boot code so that it boots the slice it is in rather than insisting on booting the active slice.  And import the NetBSD boot selector MBR. > Anyone has any idea, for a case of a remote server, > which is accessible over ssh, only when it is "up"? Remote access only when the system is up will bite you, sooner or later.  The classic formula is: RS-232 console + hardware modem + POTS = remote console From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 17:44:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 122A21065673 for ; Mon, 30 May 2011 17:44:28 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 8559F8FC08 for ; Mon, 30 May 2011 17:44:27 +0000 (UTC) Received: (qmail 18921 invoked by uid 0); 30 May 2011 17:44:26 -0000 Received: from 67.206.163.100 by rms-us004.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 30 May 2011 17:44:22 +0000 From: "Dieter BSD" Message-ID: <20110530174423.95220@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org,freebsd-toolchain@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: QOHQeVBt62mhIQ/aCmA5McRCRzdyMoOj Cc: Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 17:44:28 -0000 > maybe we find some nice -Wwarning options which are reasonable > to have -Wmissing-declarations -Wimplicit FreeBSD's gcc doesn't seem to have  -Wcoercion  ??? Bugzilla indicates that it was added years ago (2006?). It would be really really nice if -static worked on (nearly) everything. > and - most importantly - don't break tinderbox That's a matter of fixing the bugs before adding the warning flags to tinderbox. Ports need attention.  The warnings I get there are frightening. From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 18:04:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 466781065674 for ; Mon, 30 May 2011 18:04:35 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 989B78FC0A for ; Mon, 30 May 2011 18:04:34 +0000 (UTC) Received: by bwz12 with SMTP id 12so4523766bwz.13 for ; Mon, 30 May 2011 11:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=kL+W3q3uyk45rDnB2rHKzMyV26h/hoYGP4OWHbEx8J4=; b=EHpdJb4kTcW7DttHSi8ZRhOd7pJpRm2T/KI0oZ5MVVq42OEkU8lDJsffY86PBsqr4B nnoadt1AsxnO5kGJEuhLaQMnFyXesmkSNOULshhOjYjs4/HPFlNAfhu3gpWjrrO91PRd 7uAImxftQTkgkkK70DGt+wwU+vJlIP+4eCuQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; b=dmsr0414g4eXjFT3ielzlTQPMNySHfQYC55FYGFvxeqa9K+AmEEjujd7LjTlxsELKr LCk37+EUMfpVmMv1yI+zSHp2nMpuIboBbFaEWwKtem6mY2P4V6LsaW90LCouwhr65w7P tIubkATBcmDc585PJNv/FEkLoO2dNErMax0Tw= Received: by 10.204.82.149 with SMTP id b21mr4533117bkl.196.1306778673353; Mon, 30 May 2011 11:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.66.81 with HTTP; Mon, 30 May 2011 11:04:03 -0700 (PDT) In-Reply-To: <20110530174423.95220@gmx.com> References: <20110530174423.95220@gmx.com> From: Chris Rees Date: Mon, 30 May 2011 19:04:03 +0100 Message-ID: To: Dieter BSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 18:04:35 -0000 On 30 May 2011 18:44, Dieter BSD wrote: >> maybe we find some nice -Wwarning options which are reasonable >> to have > > -Wmissing-declarations > -Wimplicit > > FreeBSD's gcc doesn't seem to have =A0-Wcoercion =A0??? > Bugzilla indicates that it was added years ago (2006?). > > It would be really really nice if -static worked on (nearly) everything. > >> and - most importantly - don't break tinderbox > > That's a matter of fixing the bugs before adding the warning flags > to tinderbox. > > Ports need attention. =A0The warnings I get there are frightening. I find it comforting that they're just that: warnings. How do they frighten you? Chris From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 18:27:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A62781065673; Mon, 30 May 2011 18:27:29 +0000 (UTC) Date: Mon, 30 May 2011 18:27:29 +0000 From: Alexander Best To: Dieter BSD Message-ID: <20110530182729.GA94451@freebsd.org> References: <20110530174423.95220@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110530174423.95220@gmx.com> Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 18:27:29 -0000 On Mon May 30 11, Dieter BSD wrote: > > maybe we find some nice -Wwarning options which are reasonable > > to have > > -Wmissing-declarations > -Wimplicit > > FreeBSD's gcc doesn't seem to have  -Wcoercion  ??? > Bugzilla indicates that it was added years ago (2006?). -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc trunk and it's not in the gcc(1) manual. [1] http://gcc.gnu.org/wiki/Wcoercion > > It would be really really nice if -static worked on (nearly) everything. > > > and - most importantly - don't break tinderbox > > That's a matter of fixing the bugs before adding the warning flags > to tinderbox. > > Ports need attention.  The warnings I get there are frightening. -- a13x From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 22:44:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 466F2106566C for ; Mon, 30 May 2011 22:44:00 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id ACB648FC13 for ; Mon, 30 May 2011 22:43:59 +0000 (UTC) Received: (qmail 9551 invoked by uid 0); 30 May 2011 22:43:58 -0000 Received: from 67.206.161.57 by rms-us005.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 30 May 2011 22:43:55 +0000 From: "Dieter BSD" Message-ID: <20110530224357.95220@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org,freebsd-toolchain@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: mS/TeltcynCoPwXIBmBn/g9vcmZ1Zlxg Cc: Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 22:44:00 -0000 Chris writes: >> Ports need attention. The warnings I get there are frightening. > > I find it comforting that they're just that: warnings. > > How do they frighten you? High quality code does not have any warnings. The most frightening thing is the attitute that "They're just warnings, so I'll ignore them."  Most compiler warnings should be fatal errors. And a lot of the warnings that require a -Wwhatever should be on by default. Code that doesn't compile cleanly often has other problems, like assuming that all CPUs are ILP32 little endian, like not checking return codes, etc. But hey, the next time the weather service issues a tornado warning, feel free to go outside and fly a kite.  After all it's just a warning. a13x writes: > -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc > trunk and it's not in the gcc(1) manual. > > [1] http://gcc.gnu.org/wiki/Wcoercion And yet someone marked the bug fixed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 23:31:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9C53106566C; Mon, 30 May 2011 23:31:20 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5348FC0C; Mon, 30 May 2011 23:31:19 +0000 (UTC) Received: by ewy1 with SMTP id 1so1909864ewy.13 for ; Mon, 30 May 2011 16:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.4.209 with SMTP id 57mr1988395eej.87.1306798278724; Mon, 30 May 2011 16:31:18 -0700 (PDT) Received: by 10.14.95.144 with HTTP; Mon, 30 May 2011 16:31:18 -0700 (PDT) X-Originating-IP: [70.111.69.251] In-Reply-To: <201105290747.06088.erichfreebsdlist@ovitrap.com> References: <201105290747.06088.erichfreebsdlist@ovitrap.com> Date: Mon, 30 May 2011 19:31:18 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org, "hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Freebsd on the sun x4440 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 23:31:20 -0000 On Sat, May 28, 2011 at 8:47 PM, Erich Dollansky wrote: > Hi, > > I would like to suggest to try 8.2. > > It is my experience that the different version behave very different on t= he same hardware. It does not mean that the newer version is the better. As= an example, I have a machine here on 7.x as 8.0 did not support the USB ha= rdware found. After a machine works with a branch, I will stick with this b= ranch on the specific machine until the end of support for the branch. This= make life much easier and keeps surprises away. While 8.2 has some nice features we are sticking with 7.x for the time being. Also I did not see any improvement using 8.2v. > > On Thursday 17 May 2012 07:34:50 Mark Saad wrote: >> All >> =C2=A0 I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs h= ave 4x 4-core opterons and 128G of ram each . Once the servers boot they ar= e a good fit for what we are doing and preform well . The odd thing I am se= eing is a long delay in boot up . Once in the initial loading of the kernel= at the "|" for 1-2 mins . Then again shortly after printing the kernel ban= ner "freebsd 7.3-release etc etc etc" . =C2=A0This delay is about 1-2 mins = as well. =C2=A0So my question does any one know what I could do to speed up= the boot up ? I suspect the first delay is due to a serial =C2=A0device pr= obe the second is a mystery . also the bios load up time is about 5 mins on= this box does anyone have any ideas on speeding that up ? > > Does this machine have SCSI or SAS hardware? If the controllers are there= but not drives are installed, a GENERIC kernel will wait for some time for= SCSI to settle. If you deactivate SCSI or reduce the waiting time, at leas= t a part of the problem is solved. > Its not SCSI / SAS probe time its well before that part of the boot up stag= e. > Erich >> >> ---- >> mark saad >> Nonesuch@longcount.org_______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >> >> > Anyone figured out how to add 6 more hours to the day ? I could use a 30hr = day. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 23:31:20 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9C53106566C; Mon, 30 May 2011 23:31:20 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5348FC0C; Mon, 30 May 2011 23:31:19 +0000 (UTC) Received: by ewy1 with SMTP id 1so1909864ewy.13 for ; Mon, 30 May 2011 16:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.4.209 with SMTP id 57mr1988395eej.87.1306798278724; Mon, 30 May 2011 16:31:18 -0700 (PDT) Received: by 10.14.95.144 with HTTP; Mon, 30 May 2011 16:31:18 -0700 (PDT) X-Originating-IP: [70.111.69.251] In-Reply-To: <201105290747.06088.erichfreebsdlist@ovitrap.com> References: <201105290747.06088.erichfreebsdlist@ovitrap.com> Date: Mon, 30 May 2011 19:31:18 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org, "hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Freebsd on the sun x4440 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 23:31:20 -0000 On Sat, May 28, 2011 at 8:47 PM, Erich Dollansky wrote: > Hi, > > I would like to suggest to try 8.2. > > It is my experience that the different version behave very different on t= he same hardware. It does not mean that the newer version is the better. As= an example, I have a machine here on 7.x as 8.0 did not support the USB ha= rdware found. After a machine works with a branch, I will stick with this b= ranch on the specific machine until the end of support for the branch. This= make life much easier and keeps surprises away. While 8.2 has some nice features we are sticking with 7.x for the time being. Also I did not see any improvement using 8.2v. > > On Thursday 17 May 2012 07:34:50 Mark Saad wrote: >> All >> =C2=A0 I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs h= ave 4x 4-core opterons and 128G of ram each . Once the servers boot they ar= e a good fit for what we are doing and preform well . The odd thing I am se= eing is a long delay in boot up . Once in the initial loading of the kernel= at the "|" for 1-2 mins . Then again shortly after printing the kernel ban= ner "freebsd 7.3-release etc etc etc" . =C2=A0This delay is about 1-2 mins = as well. =C2=A0So my question does any one know what I could do to speed up= the boot up ? I suspect the first delay is due to a serial =C2=A0device pr= obe the second is a mystery . also the bios load up time is about 5 mins on= this box does anyone have any ideas on speeding that up ? > > Does this machine have SCSI or SAS hardware? If the controllers are there= but not drives are installed, a GENERIC kernel will wait for some time for= SCSI to settle. If you deactivate SCSI or reduce the waiting time, at leas= t a part of the problem is solved. > Its not SCSI / SAS probe time its well before that part of the boot up stag= e. > Erich >> >> ---- >> mark saad >> Nonesuch@longcount.org_______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >> >> > Anyone figured out how to add 6 more hours to the day ? I could use a 30hr = day. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 23:43:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3DCB1065670; Mon, 30 May 2011 23:43:08 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA398FC0C; Mon, 30 May 2011 23:43:08 +0000 (UTC) Received: by ewy1 with SMTP id 1so1911760ewy.13 for ; Mon, 30 May 2011 16:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.4.209 with SMTP id 57mr1991077eej.87.1306798987125; Mon, 30 May 2011 16:43:07 -0700 (PDT) Received: by 10.14.95.144 with HTTP; Mon, 30 May 2011 16:43:07 -0700 (PDT) X-Originating-IP: [70.111.69.251] Date: Mon, 30 May 2011 19:43:07 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org, "hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: Subject: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 23:43:09 -0000 Hello All So I am stumped on this one. I want to know what the IP of each nfs server that is providing each nfs export. I am running 7.4-RELEASE When I run "mount -t nfs" I see something like this VIP-01:/export/source on /mnt/src VIP-02:/export/target on /mnt/target VIP-01:/export/logs on /mnt/logs VIP-02:/export/package on /mnt/pkg The issue is I use a load balanced nfs server , from isilon. So VIP-01 could be any one of a group of IPs . I am trying to track down a network congestion issue and I cant find a way to match the output of lsof , and netstat to the output of mount -t nfs . Does anyone have any ideas how I could track this down , is there a way to run mount and have it show the IP and not the name of the source server ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Mon May 30 23:43:08 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3DCB1065670; Mon, 30 May 2011 23:43:08 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA398FC0C; Mon, 30 May 2011 23:43:08 +0000 (UTC) Received: by ewy1 with SMTP id 1so1911760ewy.13 for ; Mon, 30 May 2011 16:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.4.209 with SMTP id 57mr1991077eej.87.1306798987125; Mon, 30 May 2011 16:43:07 -0700 (PDT) Received: by 10.14.95.144 with HTTP; Mon, 30 May 2011 16:43:07 -0700 (PDT) X-Originating-IP: [70.111.69.251] Date: Mon, 30 May 2011 19:43:07 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org, "hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: Subject: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 23:43:09 -0000 Hello All So I am stumped on this one. I want to know what the IP of each nfs server that is providing each nfs export. I am running 7.4-RELEASE When I run "mount -t nfs" I see something like this VIP-01:/export/source on /mnt/src VIP-02:/export/target on /mnt/target VIP-01:/export/logs on /mnt/logs VIP-02:/export/package on /mnt/pkg The issue is I use a load balanced nfs server , from isilon. So VIP-01 could be any one of a group of IPs . I am trying to track down a network congestion issue and I cant find a way to match the output of lsof , and netstat to the output of mount -t nfs . Does anyone have any ideas how I could track this down , is there a way to run mount and have it show the IP and not the name of the source server ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 00:13:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4743A106566C for ; Tue, 31 May 2011 00:13:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id AE4918FC16 for ; Tue, 31 May 2011 00:13:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAHYx5E2DaFvO/2dsb2JhbABUhEmiWIhxqnOQRoErg2yBBwSQT4dAh3Y X-IronPort-AV: E=Sophos;i="4.65,294,1304308800"; d="scan'208";a="126315204" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 May 2011 20:13:20 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D2F0FB3F61; Mon, 30 May 2011 20:13:20 -0400 (EDT) Date: Mon, 30 May 2011 20:13:20 -0400 (EDT) From: Rick Macklem To: Mark Saad Message-ID: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 00:13:22 -0000 > Hello All > So I am stumped on this one. I want to know what the IP of each > nfs server that is providing each nfs export. I am running 7.4-RELEASE > When I run "mount -t nfs" I see something like this > > VIP-01:/export/source on /mnt/src > VIP-02:/export/target on /mnt/target > VIP-01:/export/logs on /mnt/logs > VIP-02:/export/package on /mnt/pkg > > The issue is I use a load balanced nfs server , from isilon. So VIP-01 > could be any one of a group of IPs . I am trying to track down a > network congestion issue and I cant find a way to match the output of > lsof , and netstat to the output of mount -t nfs . Does anyone have > any ideas how I could track this down , is there a way to run mount > and have it show the IP and not the name of the source server ? > Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump doesn't know much about NFS, but if al you want are the IP#s, it'll do. But, no, mount won't tell you more than what the argument looked like. rick From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 00:42:04 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C9C7106566B for ; Tue, 31 May 2011 00:42:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EBAEA8FC13 for ; Tue, 31 May 2011 00:42:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAHYx5E2DaFvO/2dsb2JhbABUhEmiWIhxqnOQRoErg2yBBwSQT4dAh3Y X-IronPort-AV: E=Sophos;i="4.65,294,1304308800"; d="scan'208";a="126315204" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 May 2011 20:13:20 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D2F0FB3F61; Mon, 30 May 2011 20:13:20 -0400 (EDT) Date: Mon, 30 May 2011 20:13:20 -0400 (EDT) From: Rick Macklem To: Mark Saad Message-ID: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 00:42:04 -0000 > Hello All > So I am stumped on this one. I want to know what the IP of each > nfs server that is providing each nfs export. I am running 7.4-RELEASE > When I run "mount -t nfs" I see something like this > > VIP-01:/export/source on /mnt/src > VIP-02:/export/target on /mnt/target > VIP-01:/export/logs on /mnt/logs > VIP-02:/export/package on /mnt/pkg > > The issue is I use a load balanced nfs server , from isilon. So VIP-01 > could be any one of a group of IPs . I am trying to track down a > network congestion issue and I cant find a way to match the output of > lsof , and netstat to the output of mount -t nfs . Does anyone have > any ideas how I could track this down , is there a way to run mount > and have it show the IP and not the name of the source server ? > Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump doesn't know much about NFS, but if al you want are the IP#s, it'll do. But, no, mount won't tell you more than what the argument looked like. rick From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 02:17:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8915D1065670; Tue, 31 May 2011 02:17:50 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED7C08FC15; Tue, 31 May 2011 02:17:49 +0000 (UTC) Received: by eyg7 with SMTP id 7so1980304eyg.13 for ; Mon, 30 May 2011 19:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.98.71 with SMTP id u47mr2014512eef.247.1306808268515; Mon, 30 May 2011 19:17:48 -0700 (PDT) Received: by 10.14.95.144 with HTTP; Mon, 30 May 2011 19:17:48 -0700 (PDT) X-Originating-IP: [70.111.69.251] In-Reply-To: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> References: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 30 May 2011 22:17:48 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 02:17:50 -0000 On Mon, May 30, 2011 at 8:13 PM, Rick Macklem wrote: >> Hello All >> So I am stumped on this one. I want to know what the IP of each >> nfs server that is providing each nfs export. I am running 7.4-RELEASE >> When I run "mount -t nfs" I see something like this >> >> VIP-01:/export/source on /mnt/src >> VIP-02:/export/target on /mnt/target >> VIP-01:/export/logs on /mnt/logs >> VIP-02:/export/package on /mnt/pkg >> >> The issue is I use a load balanced nfs server , from isilon. So VIP-01 >> could be any one of a group of IPs . I am trying to track down a >> network congestion issue and I cant find a way to match the output of >> lsof , and netstat to the output of mount -t nfs . Does anyone have >> any ideas how I could track this down , is there a way to run mount >> and have it show the IP and not the name of the source server ? >> > Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump > doesn't know much about NFS, but if al you want are the IP#s, it'll do. > > But, no, mount won't tell you more than what the argument looked like. > > rick > Wireshark seams like using a tank to swap a fly. -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 02:17:50 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8915D1065670; Tue, 31 May 2011 02:17:50 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED7C08FC15; Tue, 31 May 2011 02:17:49 +0000 (UTC) Received: by eyg7 with SMTP id 7so1980304eyg.13 for ; Mon, 30 May 2011 19:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.98.71 with SMTP id u47mr2014512eef.247.1306808268515; Mon, 30 May 2011 19:17:48 -0700 (PDT) Received: by 10.14.95.144 with HTTP; Mon, 30 May 2011 19:17:48 -0700 (PDT) X-Originating-IP: [70.111.69.251] In-Reply-To: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> References: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 30 May 2011 22:17:48 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 02:17:50 -0000 On Mon, May 30, 2011 at 8:13 PM, Rick Macklem wrote: >> Hello All >> So I am stumped on this one. I want to know what the IP of each >> nfs server that is providing each nfs export. I am running 7.4-RELEASE >> When I run "mount -t nfs" I see something like this >> >> VIP-01:/export/source on /mnt/src >> VIP-02:/export/target on /mnt/target >> VIP-01:/export/logs on /mnt/logs >> VIP-02:/export/package on /mnt/pkg >> >> The issue is I use a load balanced nfs server , from isilon. So VIP-01 >> could be any one of a group of IPs . I am trying to track down a >> network congestion issue and I cant find a way to match the output of >> lsof , and netstat to the output of mount -t nfs . Does anyone have >> any ideas how I could track this down , is there a way to run mount >> and have it show the IP and not the name of the source server ? >> > Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump > doesn't know much about NFS, but if al you want are the IP#s, it'll do. > > But, no, mount won't tell you more than what the argument looked like. > > rick > Wireshark seams like using a tank to swap a fly. -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 03:01:38 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D27B91065704; Tue, 31 May 2011 03:01:38 +0000 (UTC) (envelope-from tdamas@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 778FC8FC14; Tue, 31 May 2011 03:01:38 +0000 (UTC) Received: by vws18 with SMTP id 18so4138079vws.13 for ; Mon, 30 May 2011 20:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=obYBM4EHKvv5Wxdjn/6DOZsWkrJf9ucbuEnSQnOr3KU=; b=DNLHLzq94GfSPVv9UJm+4ZS3f88XDFXluwIyJ+htLu2nN+QTMQvLiYDwhUMq1UVNhg 1pSrkxn9hfR+3pcV3H6OP6QKq+tuUYxguSFKQFmoNhukqwgXCtWr1vcXOF4Y8Prr1rXW m85+Gzn9rFQrRxXVSI2e/tBL1rwyqBRNlkP7A= 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=L9E5NQinh6iNSwjhybbKudzymtXcQ7rAAeA1AfMUewoMerGXcHow+lv3G+qLOJUNcc YeuyPAQcR5o37rgorT4i3SEXdFq4zV7fSUvifYdrYUbkU+rdfozv2ENfTpvlitTvD7+K nmcfALaqWYgA/3isMJZXBRnk5K8g9EA1UcdUg= Received: by 10.52.177.36 with SMTP id cn4mr1212436vdc.26.1306809223116; Mon, 30 May 2011 19:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.169.201 with HTTP; Mon, 30 May 2011 19:33:23 -0700 (PDT) In-Reply-To: References: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> From: Thiago Damas Date: Mon, 30 May 2011 23:33:23 -0300 Message-ID: To: Mark Saad Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 03:01:38 -0000 Maybe you can use "showmount -a SERVER-IP", foreach server you have... Thiago 2011/5/30 Mark Saad : > On Mon, May 30, 2011 at 8:13 PM, Rick Macklem wrote: >>> Hello All >>> So I am stumped on this one. I want to know what the IP of each >>> nfs server that is providing each nfs export. I am running 7.4-RELEASE >>> When I run "mount -t nfs" I see something like this >>> >>> VIP-01:/export/source on /mnt/src >>> VIP-02:/export/target on /mnt/target >>> VIP-01:/export/logs on /mnt/logs >>> VIP-02:/export/package on /mnt/pkg >>> >>> The issue is I use a load balanced nfs server , from isilon. So VIP-01 >>> could be any one of a group of IPs . I am trying to track down a >>> network congestion issue and I cant find a way to match the output of >>> lsof , and netstat to the output of mount -t nfs . Does anyone have >>> any ideas how I could track this down , is there a way to run mount >>> and have it show the IP and not the name of the source server ? >>> >> Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump >> doesn't know much about NFS, but if al you want are the IP#s, it'll do. >> >> But, no, mount won't tell you more than what the argument looked like. >> >> rick >> > Wireshark seams like using a tank to swap a fly. > > > -- > mark saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 03:01:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D27B91065704; Tue, 31 May 2011 03:01:38 +0000 (UTC) (envelope-from tdamas@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 778FC8FC14; Tue, 31 May 2011 03:01:38 +0000 (UTC) Received: by vws18 with SMTP id 18so4138079vws.13 for ; Mon, 30 May 2011 20:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=obYBM4EHKvv5Wxdjn/6DOZsWkrJf9ucbuEnSQnOr3KU=; b=DNLHLzq94GfSPVv9UJm+4ZS3f88XDFXluwIyJ+htLu2nN+QTMQvLiYDwhUMq1UVNhg 1pSrkxn9hfR+3pcV3H6OP6QKq+tuUYxguSFKQFmoNhukqwgXCtWr1vcXOF4Y8Prr1rXW m85+Gzn9rFQrRxXVSI2e/tBL1rwyqBRNlkP7A= 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=L9E5NQinh6iNSwjhybbKudzymtXcQ7rAAeA1AfMUewoMerGXcHow+lv3G+qLOJUNcc YeuyPAQcR5o37rgorT4i3SEXdFq4zV7fSUvifYdrYUbkU+rdfozv2ENfTpvlitTvD7+K nmcfALaqWYgA/3isMJZXBRnk5K8g9EA1UcdUg= Received: by 10.52.177.36 with SMTP id cn4mr1212436vdc.26.1306809223116; Mon, 30 May 2011 19:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.169.201 with HTTP; Mon, 30 May 2011 19:33:23 -0700 (PDT) In-Reply-To: References: <1385828099.1028129.1306800800853.JavaMail.root@erie.cs.uoguelph.ca> From: Thiago Damas Date: Mon, 30 May 2011 23:33:23 -0300 Message-ID: To: Mark Saad Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 03:01:38 -0000 Maybe you can use "showmount -a SERVER-IP", foreach server you have... Thiago 2011/5/30 Mark Saad : > On Mon, May 30, 2011 at 8:13 PM, Rick Macklem wrote: >>> Hello All >>> So I am stumped on this one. I want to know what the IP of each >>> nfs server that is providing each nfs export. I am running 7.4-RELEASE >>> When I run "mount -t nfs" I see something like this >>> >>> VIP-01:/export/source on /mnt/src >>> VIP-02:/export/target on /mnt/target >>> VIP-01:/export/logs on /mnt/logs >>> VIP-02:/export/package on /mnt/pkg >>> >>> The issue is I use a load balanced nfs server , from isilon. So VIP-01 >>> could be any one of a group of IPs . I am trying to track down a >>> network congestion issue and I cant find a way to match the output of >>> lsof , and netstat to the output of mount -t nfs . Does anyone have >>> any ideas how I could track this down , is there a way to run mount >>> and have it show the IP and not the name of the source server ? >>> >> Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump >> doesn't know much about NFS, but if al you want are the IP#s, it'll do. >> >> But, no, mount won't tell you more than what the argument looked like. >> >> rick >> > Wireshark seams like using a tank to swap a fly. > > > -- > mark saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 08:45:36 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84A4F106566C; Tue, 31 May 2011 08:45:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6190A8FC1C; Tue, 31 May 2011 08:45:36 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id F0F2346B2A; Tue, 31 May 2011 04:45:35 -0400 (EDT) Date: Tue, 31 May 2011 09:45:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mark Saad In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, "hackers@freebsd.org" Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 08:45:36 -0000 On Mon, 30 May 2011, Mark Saad wrote: > So I am stumped on this one. I want to know what the IP of each > nfs server that is providing each nfs export. I am running 7.4-RELEASE > When I run "mount -t nfs" I see something like this > > VIP-01:/export/source on /mnt/src > VIP-02:/export/target on /mnt/target > VIP-01:/export/logs on /mnt/logs > VIP-02:/export/package on /mnt/pkg > > The issue is I use a load balanced nfs server , from isilon. So VIP-01 could > be any one of a group of IPs . I am trying to track down a network > congestion issue and I cant find a way to match the output of lsof , and > netstat to the output of mount -t nfs . Does anyone have any ideas how I > could track this down , is there a way to run mount and have it show the IP > and not the name of the source server ? Unfortunately, there's not a good answer to this question. nfsstat(1) should have a mode that can iterate down active mount points displaying statistics and connection information for each, but doesn't. NFS sockets generally don't appear in sockstat(1) either. However, they should appear in netstat(1), so you can at least identify the sockets open to various NFS server IP addresses (especially if they are TCP mounts). Enhancing nfsstat(1) to display more detailed information would, I think, be a very useful task for someone to get up to (and perhaps should appear on our ideas list). Something that would be nice to have, in support of this, is a way for file systems to provide extended status via a system call that queries mountpoints, both "portable" information that spans file systems, and file system-specific data. Morally, similar to nmount(2) but for statistics rather than setting things. The "easier" route is to add new sysctls that dump per-mountpoint state directly from NFS, but given how much other information we'd like to export, it would be great to have a more general mechanism. (The more adventurous can, with a fairly high degree of safety, use kgdb on /dev/mem (read-only) to walk the NFS stack's mount tables, but that's not much fun.) Robert From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 08:45:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84A4F106566C; Tue, 31 May 2011 08:45:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6190A8FC1C; Tue, 31 May 2011 08:45:36 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id F0F2346B2A; Tue, 31 May 2011 04:45:35 -0400 (EDT) Date: Tue, 31 May 2011 09:45:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mark Saad In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, "hackers@freebsd.org" Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 08:45:36 -0000 On Mon, 30 May 2011, Mark Saad wrote: > So I am stumped on this one. I want to know what the IP of each > nfs server that is providing each nfs export. I am running 7.4-RELEASE > When I run "mount -t nfs" I see something like this > > VIP-01:/export/source on /mnt/src > VIP-02:/export/target on /mnt/target > VIP-01:/export/logs on /mnt/logs > VIP-02:/export/package on /mnt/pkg > > The issue is I use a load balanced nfs server , from isilon. So VIP-01 could > be any one of a group of IPs . I am trying to track down a network > congestion issue and I cant find a way to match the output of lsof , and > netstat to the output of mount -t nfs . Does anyone have any ideas how I > could track this down , is there a way to run mount and have it show the IP > and not the name of the source server ? Unfortunately, there's not a good answer to this question. nfsstat(1) should have a mode that can iterate down active mount points displaying statistics and connection information for each, but doesn't. NFS sockets generally don't appear in sockstat(1) either. However, they should appear in netstat(1), so you can at least identify the sockets open to various NFS server IP addresses (especially if they are TCP mounts). Enhancing nfsstat(1) to display more detailed information would, I think, be a very useful task for someone to get up to (and perhaps should appear on our ideas list). Something that would be nice to have, in support of this, is a way for file systems to provide extended status via a system call that queries mountpoints, both "portable" information that spans file systems, and file system-specific data. Morally, similar to nmount(2) but for statistics rather than setting things. The "easier" route is to add new sysctls that dump per-mountpoint state directly from NFS, but given how much other information we'd like to export, it would be great to have a more general mechanism. (The more adventurous can, with a fairly high degree of safety, use kgdb on /dev/mem (read-only) to walk the NFS stack's mount tables, but that's not much fun.) Robert From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 09:30:49 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C74F1065670 for ; Tue, 31 May 2011 09:30:49 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1058FC13 for ; Tue, 31 May 2011 09:30:48 +0000 (UTC) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p4V7Nt4C021331 for ; Tue, 31 May 2011 17:23:55 +1000 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p4V7Nm70025655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2011 17:23:50 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p4V7NlNI056902; Tue, 31 May 2011 17:23:47 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p4V7Nl35056901; Tue, 31 May 2011 17:23:47 +1000 (EST) (envelope-from peter) Date: Tue, 31 May 2011 17:23:47 +1000 From: Peter Jeremy To: Dieter BSD Message-ID: <20110531072346.GA56848@server.vk2pj.dyndns.org> References: <20110530174243.95200@gmx.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20110530174243.95200@gmx.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org Subject: Re: Active slice, only for a next boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 09:30:49 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-May-30 17:42:39 +0000, Dieter BSD wrote: >A better approach is to be able to boot whatever slice you >want without having to change the active slice. > >NetBSD can do this. =A0The MBR puts up a menu of the bootable >slices on the disk being booted. =A0You can allow the timer >to time out and boot the default. =A0Or you can enter the number >of the slice you want to boot. =A0Or you can type a function key >F1 F2 ... to boot a different disk, and it will load the MBR >from that disk and run it. =A0There is an alternative for keyboards >without function keys. So can FreeBSD - though only for MBR - this functionality doesn't seem to have made it into the GPT bootcode. >And it works great. =A0Except that one of the 27 stages of boot >code that FreeBSD uses INSISTS on booting the active slice, >so you can tell the MBR to boot slice 3 and slice 3's boot >code sees that slice 4 is active and boots slice 4. Multibooting worked correctly when I last used it (a few years ago). Have you raised this as a PR? >RS-232 console + hardware modem + POTS =3D remote console And even that doesn't fully work unless you have a serial-aware BIOS. --=20 Peter Jeremy --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3kl4IACgkQ/opHv/APuIeN9ACfdJwWxSOlKuosmbgIATQP+wKq YpMAoMFhfRyK4KobphuIXMYk+aXJzJcA =Duuz -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 09:57:42 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 3A79F1065678; Tue, 31 May 2011 09:57:42 +0000 (UTC) Date: Tue, 31 May 2011 09:57:42 +0000 From: Alexander Best To: Bruce Cran Message-ID: <20110531095742.GA99888@freebsd.org> References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110528202619.GA27204@muon.cran.org.uk> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-toolchain@FreeBSD.ORG, Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 09:57:42 -0000 On Sat May 28 11, Bruce Cran wrote: > On Sat, May 28, 2011 at 06:23:26PM +0000, Alexander Best wrote: > > > > well i'm not an expert on this. but are we 100% sure that a kernel on amd64 > > compiled with -O2 frename-registers can be debugged the same way as one with > > -O? if that is the case: sure...-O2 is fine. ;) > > > > however i've often read messages - mostly by bruce evans - claiming that > > anything greater than -O will in fact decrease a kernel's ability to be > > debugged just as well as a kernel with -O. > > > > The critical option when -O2 is used is -fno-omit-frame-pointers, since removing > frame pointers makes debugging impossible (on i386). With -O2 code is moved around and > removed, so debugging is more difficult, but can still provide useful > information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? > > -- > Bruce Cran -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 10:37:06 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90FD5106564A; Tue, 31 May 2011 10:37:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 179008FC14; Tue, 31 May 2011 10:37:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26] (unknown [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0EDFD5C37; Tue, 31 May 2011 12:37:04 +0200 (CEST) Message-ID: <4DE4C4CC.4020905@FreeBSD.org> Date: Tue, 31 May 2011 12:37:00 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18pre) Gecko/20110527 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Best References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> In-Reply-To: <20110531095742.GA99888@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-hackers@FreeBSD.ORG, freebsd-toolchain@FreeBSD.ORG, Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 10:37:06 -0000 On 2011-05-31 11:57, Alexander Best wrote: ... >>> however i've often read messages - mostly by bruce evans - claiming that >>> anything greater than -O will in fact decrease a kernel's ability to be >>> debugged just as well as a kernel with -O. >> The critical option when -O2 is used is -fno-omit-frame-pointers, since removing >> frame pointers makes debugging impossible (on i386). With -O2 code is moved around and >> removed, so debugging is more difficult, but can still provide useful >> information. > any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as > standard COPTFLAGS with debugging enabled for *all* archs? Most likely, the performance gain from -O2 is rather small, except for special cases, but the pain during debugging is increased a great deal. Even if you add frame pointers, with -O2 large pieces of code can be transformed, variables or even entire functions can be completely eliminated, and so on, making debugging much more difficult. From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 10:46:39 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id C2AF91065670; Tue, 31 May 2011 10:46:39 +0000 (UTC) Date: Tue, 31 May 2011 10:46:39 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110531104639.GA4218@freebsd.org> References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE4C4CC.4020905@FreeBSD.org> Cc: Bruce Cran , freebsd-hackers@FreeBSD.ORG, freebsd-toolchain@FreeBSD.ORG, Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 10:46:39 -0000 On Tue May 31 11, Dimitry Andric wrote: > On 2011-05-31 11:57, Alexander Best wrote: > ... > >>>however i've often read messages - mostly by bruce evans - claiming that > >>>anything greater than -O will in fact decrease a kernel's ability to be > >>>debugged just as well as a kernel with -O. > >>The critical option when -O2 is used is -fno-omit-frame-pointers, since > >>removing > >>frame pointers makes debugging impossible (on i386). With -O2 code is > >>moved around and > >>removed, so debugging is more difficult, but can still provide useful > >>information. > >any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing > >as > >standard COPTFLAGS with debugging enabled for *all* archs? > > Most likely, the performance gain from -O2 is rather small, except for > special cases, but the pain during debugging is increased a great deal. > > Even if you add frame pointers, with -O2 large pieces of code can be > transformed, variables or even entire functions can be completely > eliminated, and so on, making debugging much more difficult. *lol* we're moving in circles. so back to the beginning: why not use -O for all archs, if debugging was enabled? for amd64 -O2 is always set, no matter, if debugging is enabled or disabled. cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 11:16:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id AA6C3106566C; Tue, 31 May 2011 11:16:47 +0000 (UTC) Date: Tue, 31 May 2011 11:16:47 +0000 From: Alexander Best To: Dieter BSD Message-ID: <20110531111647.GA7168@freebsd.org> References: <20110530224357.95220@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110530224357.95220@gmx.com> Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 11:16:47 -0000 On Mon May 30 11, Dieter BSD wrote: > Chris writes: > >> Ports need attention. The warnings I get there are frightening. > > > > I find it comforting that they're just that: warnings. > > > > How do they frighten you? > > High quality code does not have any warnings. > > The most frightening thing is the attitute that "They're just warnings, > so I'll ignore them."  Most compiler warnings should be fatal errors. > And a lot of the warnings that require a -Wwhatever should be on by > default. please keep in mind that -Wfoo does reflect the ideas of the GNU people regarding *proper* code. the warnings themselves are sometimes wrong, because they complain about perfectly correct code. so -Wfoo should not be considered a code verifier, but in fact what it is: a warning flag. sometimes it's correct and indeed reports wrong code, sometimes it is completely wrong. cheers. alex > > Code that doesn't compile cleanly often has other problems, like assuming > that all CPUs are ILP32 little endian, like not checking return codes, etc. > > But hey, the next time the weather service issues a tornado warning, > feel free to go outside and fly a kite.  After all it's just a warning. > > a13x writes: > > -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc > > trunk and it's not in the gcc(1) manual. > > > > [1] http://gcc.gnu.org/wiki/Wcoercion > > And yet someone marked the bug fixed. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 11:18:29 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8C96106564A; Tue, 31 May 2011 11:18:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CBFB78FC18; Tue, 31 May 2011 11:18:28 +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 OAA07910; Tue, 31 May 2011 14:18:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE4CE82.4030301@FreeBSD.org> Date: Tue, 31 May 2011 14:18:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jung-uk Kim References: <201105241356.45543.jkim@FreeBSD.org> In-Reply-To: <201105241356.45543.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 11:18:29 -0000 on 24/05/2011 20:56 Jung-uk Kim said the following: > I think it's about time to enable invariant TSC timecounter on SMP by > default. Please see the attached patch. It is also available from > here: > > http://people.freebsd.org/~jkim/tsc_smp_test4.diff > > avg convinced me enough that it should be an opt-out feature going > forward. :-) Not sure if I really did that. My position is this: - if we think that TSC is SMP-safe then it should have the best priority - we should do our best to auto-guess if TSC is SMP-safe unless a user explicitly overrides that property (either via explicit testing or by making guesses based on CPU model or etc) > Comments? Perhaps I missed it, but I don't remember the "lowres" part of the patch being discussed. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 13:02:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F28B4106566B; Tue, 31 May 2011 13:02:01 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF5458FC14; Tue, 31 May 2011 13:02:01 +0000 (UTC) Received: by pvg11 with SMTP id 11so2528252pvg.13 for ; Tue, 31 May 2011 06:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=4D2Tk7ynIckQ02ADSQDYOl+6bKpZF+l/3gettiq9qUs=; b=WP4AIyiIonYsT4aVJaStgGwAmd2qh5I9sXHhJF1MiKYwUCOY9sQZLtSxAaTdQvg+J4 nTlIQBkTnqmPRd37U6qzRqEDWtudPUWfOfe2q1lLMU6KUk0cMFTGCFpiF+jajFG4a9ld TE6fQWuckT7VM4RAZH88Jcdk1MuoUXLV5DUE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=mPZjvHF94ttUmGGXk6F/B6Nb72PfcpUrM/Bdcj/mH9qESOTDGsJLZ9LISYrCUURb/h m8yPOxSSGAUafllSKYRbZN3eAift03fHFKuzuXC764NrYe2R8WmZU0fwLcut48fgz2SV 9VqpGNi8lg43uCGU+5Bih0oWxoKTOdvE55Bpk= Received: by 10.68.14.74 with SMTP id n10mr1211710pbc.489.1306846921094; Tue, 31 May 2011 06:02:01 -0700 (PDT) Received: from [192.168.20.56] (c-24-6-49-154.hsd1.ca.comcast.net [24.6.49.154]) by mx.google.com with ESMTPS id i7sm35345pbj.10.2011.05.31.06.01.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 06:01:59 -0700 (PDT) References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> In-Reply-To: <20110531104639.GA4218@freebsd.org> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> X-Mailer: iPhone Mail (8J2) From: Garrett Cooper Date: Tue, 31 May 2011 06:01:55 -0700 To: Alexander Best Cc: Bruce Cran , "freebsd-hackers@FreeBSD.ORG" , "freebsd-toolchain@FreeBSD.ORG" , Dimitry Andric , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:02:02 -0000 On May 31, 2011, at 3:46 AM, Alexander Best wrote: > On Tue May 31 11, Dimitry Andric wrote: >> On 2011-05-31 11:57, Alexander Best wrote: >> ... >>>>> however i've often read messages - mostly by bruce evans - claiming th= at >>>>> anything greater than -O will in fact decrease a kernel's ability to b= e >>>>> debugged just as well as a kernel with -O. >>>> The critical option when -O2 is used is -fno-omit-frame-pointers, since= =20 >>>> removing >>>> frame pointers makes debugging impossible (on i386). With -O2 code is=20= >>>> moved around and >>>> removed, so debugging is more difficult, but can still provide useful >>>> information. >>> any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasi= ng=20 >>> as >>> standard COPTFLAGS with debugging enabled for *all* archs? >>=20 >> Most likely, the performance gain from -O2 is rather small, except for >> special cases, but the pain during debugging is increased a great deal. >>=20 >> Even if you add frame pointers, with -O2 large pieces of code can be >> transformed, variables or even entire functions can be completely >> eliminated, and so on, making debugging much more difficult. >=20 > *lol* we're moving in circles. so back to the beginning: why not use -O > for all archs, if debugging was enabled? for amd64 -O2 is always set, no > matter, if debugging is enabled or disabled. I don't know, but I've run into cases where gcc has inlined or shuffled arou= nd code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to= use -O0 when DEBUG_FLAGS was defined. Thanks, -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 13:08:03 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E60801065670; Tue, 31 May 2011 13:08:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF8418FC0C; Tue, 31 May 2011 13:08:03 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5BC3746B39; Tue, 31 May 2011 09:08:03 -0400 (EDT) Date: Tue, 31 May 2011 14:08:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Best In-Reply-To: <20110531111647.GA7168@freebsd.org> Message-ID: References: <20110530224357.95220@gmx.com> <20110531111647.GA7168@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1637175785-1306847283=:14209" Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org, Dieter BSD Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:08:04 -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. --621616949-1637175785-1306847283=:14209 Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 31 May 2011, Alexander Best wrote: > On Mon May 30 11, Dieter BSD wrote: >> Chris writes: >>>> Ports need attention. The warnings I get there are frightening. >>> >>> I find it comforting that they're just that: warnings. >>> >>> How do they frighten you? >> >> High quality code does not have any warnings. >> >> The most frightening thing is the attitute that "They're just warnings, so >> I'll ignore them."  Most compiler warnings should be fatal errors. And a >> lot of the warnings that require a -Wwhatever should be on by default. > > please keep in mind that -Wfoo does reflect the ideas of the GNU people > regarding *proper* code. the warnings themselves are sometimes wrong, > because they complain about perfectly correct code. so -Wfoo should not be > considered a code verifier, but in fact what it is: a warning flag. > sometimes it's correct and indeed reports wrong code, sometimes it is > completely wrong. And, it's also worth remembering that warnings change over time, as the compiler changes. One of the known issues building with clang is that large quantities of "warning-free code" under gcc are in fact rife with warnings under clang, including the gcc source code itself. In general, my hope is that we can get the FreeBSD base warning-free for a useful set of warnings, and on the whole, this is the case. Pretty much the entire kernel is compiled with quite a large number of warning classes enabled, and -Werror set, for example. (One of the other tensions, of course, is the locally maintained vs externally maintained tension: fixing warnings in other people's code is useful only if you can get them to accept the fixes back -- maintaining large numbers of patch sets over time is not sustainable for non-trivial quantifies of code, if you're tracking the upstream vendor. Ports is the worst possible case, where maintaining local patches is quite expensive. In the FreeBSD base we can do a lot better, since we can use revision control and automatic merging to help us, but it's still an overhead that has to be reasoned about carefully.) Robert --621616949-1637175785-1306847283=:14209-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 14:39:14 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 12444106566B; Tue, 31 May 2011 14:39:14 +0000 (UTC) Date: Tue, 31 May 2011 14:39:14 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110531143914.GA30260@freebsd.org> References: <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> Cc: Bruce Cran , "freebsd-hackers@FreeBSD.ORG" , "freebsd-toolchain@FreeBSD.ORG" , Dimitry Andric , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:39:14 -0000 On Tue May 31 11, Garrett Cooper wrote: > On May 31, 2011, at 3:46 AM, Alexander Best wrote: > > > On Tue May 31 11, Dimitry Andric wrote: > >> On 2011-05-31 11:57, Alexander Best wrote: > >> ... > >>>>> however i've often read messages - mostly by bruce evans - claiming that > >>>>> anything greater than -O will in fact decrease a kernel's ability to be > >>>>> debugged just as well as a kernel with -O. > >>>> The critical option when -O2 is used is -fno-omit-frame-pointers, since > >>>> removing > >>>> frame pointers makes debugging impossible (on i386). With -O2 code is > >>>> moved around and > >>>> removed, so debugging is more difficult, but can still provide useful > >>>> information. > >>> any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing > >>> as > >>> standard COPTFLAGS with debugging enabled for *all* archs? > >> > >> Most likely, the performance gain from -O2 is rather small, except for > >> special cases, but the pain during debugging is increased a great deal. > >> > >> Even if you add frame pointers, with -O2 large pieces of code can be > >> transformed, variables or even entire functions can be completely > >> eliminated, and so on, making debugging much more difficult. > > > > *lol* we're moving in circles. so back to the beginning: why not use -O > > for all archs, if debugging was enabled? for amd64 -O2 is always set, no > > matter, if debugging is enabled or disabled. > > I don't know, but I've run into cases where gcc has inlined or shuffled around code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to use -O0 when DEBUG_FLAGS was defined. ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't -fno-omit-frame-pointer be set uncondtitionally on all archs? just like -fno-strict-aliasing? cheers. alex > Thanks, > -Garrett -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 15:01:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98072106564A for ; Tue, 31 May 2011 15:01:26 +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 711F08FC08 for ; Tue, 31 May 2011 15:01:26 +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 2443746B35; Tue, 31 May 2011 11:01:26 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B3D018A027; Tue, 31 May 2011 11:01:25 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 31 May 2011 10:29:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DE01421.7080902@rawbw.com> In-Reply-To: <4DE01421.7080902@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105311029.15259.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 31 May 2011 11:01:25 -0400 (EDT) Cc: Yuri Subject: Re: ndis driver presents the valid WiFi network as having the name 0x000000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:01:26 -0000 On Friday, May 27, 2011 5:14:09 pm Yuri wrote: > Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with > Windows driver. > This same card and driver work fine with pretty much any other network I > tried. > But this one particular network shows as 0x000000 and I can't connect to it. > Another FreeBSD desktop with native ath driver and apple both connect to > it fine. > > What might be causing such weird behavior? > Is this a known problem? > Any way to troubleshoot this? I have this same problem. I've had to resort to using wpa_cli to 'select' my network at work that has this issue and then using 'ap_scan 2' to force wpa_supplicant to associate with it. You also will want ndis_events running if you need to do WPA authentication. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 15:01:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A85106566C for ; Tue, 31 May 2011 15:01:28 +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 A8E628FC0A for ; Tue, 31 May 2011 15:01:28 +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 5C0B246B37; Tue, 31 May 2011 11:01:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 501C58A02A; Tue, 31 May 2011 11:01:27 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 31 May 2011 10:33:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <20110530174243.95200@gmx.com> In-Reply-To: <20110530174243.95200@gmx.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201105311033.47021.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 31 May 2011 11:01:28 -0400 (EDT) Cc: Dieter BSD Subject: Re: Active slice, only for a next boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:01:28 -0000 On Monday, May 30, 2011 1:42:39 pm Dieter BSD wrote: > And it works great. Except that one of the 27 stages of boot > code that FreeBSD uses INSISTS on booting the active slice, > so you can tell the MBR to boot slice 3 and slice 3's boot > code sees that slice 4 is active and boots slice 4. There are only 3 stages, and boot1.S is what looks at the active slice. Unfortunately it doesn't have a better way to do this as the only input it gets from boot0 or any other MBR boot loader is the BIOS drive number in %dl. I'm not sure how else you would detect that a non-active slice was booted from when that is your only input. One could define some extended structure to pass that information and send it in a register, but you'd still have to cope with MBR boot loaders that don't pass it (e.g. the Windows ones if you are dual-booting with Windows) and you'd need to have some sanity checks to make sure one doesn't treat garbage input as valid. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 15:26:54 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id BA37D1065670; Tue, 31 May 2011 15:26:54 +0000 (UTC) Date: Tue, 31 May 2011 15:26:54 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110531152654.GA42990@freebsd.org> References: <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20110531143914.GA30260@freebsd.org> Cc: Bruce Cran , "freebsd-hackers@FreeBSD.ORG" , "freebsd-toolchain@FreeBSD.ORG" , Dimitry Andric , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:26:54 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue May 31 11, Alexander Best wrote: > On Tue May 31 11, Garrett Cooper wrote: > > On May 31, 2011, at 3:46 AM, Alexander Best wrote: > > > > > On Tue May 31 11, Dimitry Andric wrote: > > >> On 2011-05-31 11:57, Alexander Best wrote: > > >> ... > > >>>>> however i've often read messages - mostly by bruce evans - claiming that > > >>>>> anything greater than -O will in fact decrease a kernel's ability to be > > >>>>> debugged just as well as a kernel with -O. > > >>>> The critical option when -O2 is used is -fno-omit-frame-pointers, since > > >>>> removing > > >>>> frame pointers makes debugging impossible (on i386). With -O2 code is > > >>>> moved around and > > >>>> removed, so debugging is more difficult, but can still provide useful > > >>>> information. > > >>> any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing > > >>> as > > >>> standard COPTFLAGS with debugging enabled for *all* archs? > > >> > > >> Most likely, the performance gain from -O2 is rather small, except for > > >> special cases, but the pain during debugging is increased a great deal. > > >> > > >> Even if you add frame pointers, with -O2 large pieces of code can be > > >> transformed, variables or even entire functions can be completely > > >> eliminated, and so on, making debugging much more difficult. > > > > > > *lol* we're moving in circles. so back to the beginning: why not use -O > > > for all archs, if debugging was enabled? for amd64 -O2 is always set, no > > > matter, if debugging is enabled or disabled. > > > > I don't know, but I've run into cases where gcc has inlined or shuffled around code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to use -O0 when DEBUG_FLAGS was defined. > > ...which leads me to the conclusion that -O should be set when DEBUG was > defined: an all ARCHS. > > right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the > kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't > -fno-omit-frame-pointer be set uncondtitionally on all archs? just like > -fno-strict-aliasing? so how about the following patch? cheers. alex > > cheers. > alex > > > Thanks, > > -Garrett > -- > a13x -- a13x --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern.pre.mk.diff" diff --git a/sys/conf/Makefile.amd64 b/sys/conf/Makefile.amd64 index 5096829..f70f3de 100644 --- a/sys/conf/Makefile.amd64 +++ b/sys/conf/Makefile.amd64 @@ -31,13 +31,6 @@ S= ../../.. .endif .include "$S/conf/kern.pre.mk" -DDB_ENABLED!= grep DDB opt_ddb.h || true -DTR_ENABLED!= grep KDTRACE_FRAME opt_kdtrace.h || true -HWPMC_ENABLED!= grep HWPMC opt_hwpmc_hooks.h || true -.if !empty(DDB_ENABLED) || !empty(DTR_ENABLED) || !empty(HWPMC_ENABLED) -CFLAGS+= -fno-omit-frame-pointer -.endif - MKMODULESENV+= MACHINE=amd64 .if ${CC:T:Mclang} == "clang" diff --git a/sys/conf/Makefile.powerpc b/sys/conf/Makefile.powerpc index e4cd85f..04bc66b 100644 --- a/sys/conf/Makefile.powerpc +++ b/sys/conf/Makefile.powerpc @@ -37,11 +37,6 @@ INCLUDES+= -I$S/contrib/libfdt CFLAGS+= -msoft-float -DDB_ENABLED!= grep DDB opt_ddb.h || true -.if !empty(DDB_ENABLED) -CFLAGS+= -fno-omit-frame-pointer -.endif - %BEFORE_DEPEND %OBJS diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk index e9aa6e2..0314ada 100644 --- a/sys/conf/kern.pre.mk +++ b/sys/conf/kern.pre.mk @@ -24,26 +24,28 @@ OBJCOPY?= objcopy SIZE?= size .if defined(DEBUG) -_MINUS_O= -O +COPTFLAGS?= -O -pipe CTFFLAGS+= -g +.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang" +COPTFLAGS?= -O2 -frename-registers -pipe .else -_MINUS_O= -O2 +COPTFLAGS?= -O2 -pipe .endif -.if ${MACHINE_CPUARCH} == "amd64" -COPTFLAGS?=-O2 -frename-registers -pipe -.else -COPTFLAGS?=${_MINUS_O} -pipe + +.if !empty(COPTFLAGS:M-O[234sz]) && empty(COPTFLAGS:M-fno-strict-aliasing) +COPTFLAGS+= -fno-strict-aliasing .endif -.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) -COPTFLAGS+= -fno-strict-aliasing + +.if empty(COPTFLAGS:M-O0) && empty(COPTFLAGS:M-fno-omit-frame-pointer) +COPTFLAGS+= -fno-omit-frame-pointer .endif + .if !defined(NO_CPU_COPTFLAGS) -COPTFLAGS+= ${_CPUCFLAGS} +COPTFLAGS+= ${_CPUCFLAGS} .endif -C_DIALECT= -std=c99 -NOSTDINC= -nostdinc -INCLUDES= ${NOSTDINC} ${INCLMAGIC} -I. -I$S +C_DIALECT= -std=c99 +INCLUDES= -nostdinc ${INCLMAGIC} -I. -I$S # This hack lets us use the OpenBSD altq code without spamming a new # include path into contrib'ed source files. @@ -146,8 +148,7 @@ SYSTEM_LD_TAIL= @${OBJCOPY} --strip-symbol gcc2_compiled. ${.TARGET} ; \ ${SIZE} ${.TARGET} ; chmod 755 ${.TARGET} SYSTEM_DEP+= ${LDSCRIPT} -# MKMODULESENV is set here so that port makefiles can augment -# them. +# MKMODULESENV is set here so that port makefiles can augment them. MKMODULESENV+= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR} MKMODULESENV+= MACHINE_CPUARCH=${MACHINE_CPUARCH} --zhXaljGHf11kAtnf-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 16:29:28 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD48A106566B; Tue, 31 May 2011 16:29:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 57E7D8FC16; Tue, 31 May 2011 16:29:28 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4VGNkNc014197 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 10:23:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 31 May 2011 10:23:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D934AF4.9080503@FreeBSD.org> <742085CD-7F6F-4879-9FFD-517EC3203D52@bsdimp.com> <5AF348C8-6AB6-490D-A12E-89A51528F58F@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 31 May 2011 10:23:49 -0600 (MDT) Cc: mdf@FreeBSD.org, "Robert N. M. Watson" , Dimitry Andric , freebsd-hackers Subject: Re: Include file search path X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:29:28 -0000 On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: > Hi Warner, >=20 > On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh wrote: >>=20 >> On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: >>=20 >>> On 2 Apr 2011, at 19:47, Warner Losh wrote: >>>=20 >>>>> (2) Working clang/LLVM cross-compile of FreeBSD. This seems like = a basic >>>>> requirement to adopt clang/LLVM, and as far as I'm aware that's = not yet a >>>>> resolved issue? >>>>=20 >>>> 0 work has been done here to my knowledge. The world view for = clang and our in-tree gcc differ which makes it a challenge. >>>=20 >>> That's disappointing. I seem to recall it's more an issue of our = build integration with clang/LLVM than an underlying issue in = clang/LLVM? >>=20 >> Yes. The problem isn't hard, the cross compile paradigm is just a = little different. >>=20 >>>>> We (Cambridge) are currently bringing up FreeBSD on a new = soft-core 64-bit MIPS platform. We're already using a non-base gcc for = our boot loader work, and plan to move to using clang/LLVM later in the = year. The base system seems a bit short on detail when it comes to the = above, currently. >>>>=20 >>>> Yes. I've had to add about a dozen changes so far to get close to = building with xdev compilers. A similar number are needed to make it = easy to configure and add systree support, I think. >>>=20 >>> Sounds like great progress -- do you think we'll ship 9.0 in a "just = works" state with regard to this? >>=20 >> I sure hope so. I'd like to have demoable stuff by BSDcan. >>=20 > BSDCan has passed, has there been any advance made since that = discussion ? It is "demonstrable" but not ready to commit to the tree. Needs about 4 = hours of work that I've had trouble scheduling on it due to work getting = busier than I expected. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 16:56:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23320106564A; Tue, 31 May 2011 16:56:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B823C8FC14; Tue, 31 May 2011 16:56:18 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAP8c5U2DaFvO/2dsb2JhbABThEmiTYhxrG+QVYErg2yBBwSQT4dAh3Y X-IronPort-AV: E=Sophos;i="4.65,298,1304308800"; d="scan'208";a="126397416" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 31 May 2011 12:56:17 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D10ACB3F28; Tue, 31 May 2011 12:56:17 -0400 (EDT) Date: Tue, 31 May 2011 12:56:17 -0400 (EDT) From: Rick Macklem To: Thiago Damas Message-ID: <1932845737.25555.1306860977838.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org, Mark Saad , hackers@freebsd.org Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:56:19 -0000 > Maybe you can use "showmount -a SERVER-IP", foreach server you have... > That might work. NFS doesn't actually have a notion of a "mount", but the mount protocol daemon (typically called mountd) does try and keep track of NFSv3 mounts from the requests it sees. How well this works for NFSv3 will depend on how well the server keeps track of these things and how easily they are lost during a server reboot or similar. Since NFSv4 doesn't use the mount protocol, it will be useless for NFSv4. > Thiago > 2011/5/30 Mark Saad : > > On Mon, May 30, 2011 at 8:13 PM, Rick Macklem > > wrote: > >>> Hello All > >>> So I am stumped on this one. I want to know what the IP of each > >>> nfs server that is providing each nfs export. I am running > >>> 7.4-RELEASE > >>> When I run "mount -t nfs" I see something like this > >>> > >>> VIP-01:/export/source on /mnt/src > >>> VIP-02:/export/target on /mnt/target > >>> VIP-01:/export/logs on /mnt/logs > >>> VIP-02:/export/package on /mnt/pkg > >>> > >>> The issue is I use a load balanced nfs server , from isilon. So > >>> VIP-01 > >>> could be any one of a group of IPs . I am trying to track down a > >>> network congestion issue and I cant find a way to match the output > >>> of > >>> lsof , and netstat to the output of mount -t nfs . Does anyone > >>> have > >>> any ideas how I could track this down , is there a way to run > >>> mount > >>> and have it show the IP and not the name of the source server ? > >>> > >> Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump > >> doesn't know much about NFS, but if al you want are the IP#s, it'll > >> do. > >> > >> But, no, mount won't tell you more than what the argument looked > >> like. > >> > >> rick > >> > > Wireshark seams like using a tank to swap a fly. > > Maybe, but watching traffic isn't that scary and over the years I've discovered things I would have never expected from doing it. Like a case where one specific TCP segment was being dropped by a network switch (it was a hardware problem in the switch that didn't manifest itself any other way). Or, that one client was generating a massive number of Getattr and Lookup RPCs. (That one turned out to be a grad student who had made themselves an app. that had a bunch of threads continually scanning to fs changes. Not a bad idea, but the threads never took a break and continually did it.) I've always found watching traffic kinda fun, but then I'm weird, rick From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 16:56:19 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23320106564A; Tue, 31 May 2011 16:56:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B823C8FC14; Tue, 31 May 2011 16:56:18 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAP8c5U2DaFvO/2dsb2JhbABThEmiTYhxrG+QVYErg2yBBwSQT4dAh3Y X-IronPort-AV: E=Sophos;i="4.65,298,1304308800"; d="scan'208";a="126397416" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 31 May 2011 12:56:17 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D10ACB3F28; Tue, 31 May 2011 12:56:17 -0400 (EDT) Date: Tue, 31 May 2011 12:56:17 -0400 (EDT) From: Rick Macklem To: Thiago Damas Message-ID: <1932845737.25555.1306860977838.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org, Mark Saad , hackers@freebsd.org Subject: Re: Mount_nfs question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:56:19 -0000 > Maybe you can use "showmount -a SERVER-IP", foreach server you have... > That might work. NFS doesn't actually have a notion of a "mount", but the mount protocol daemon (typically called mountd) does try and keep track of NFSv3 mounts from the requests it sees. How well this works for NFSv3 will depend on how well the server keeps track of these things and how easily they are lost during a server reboot or similar. Since NFSv4 doesn't use the mount protocol, it will be useless for NFSv4. > Thiago > 2011/5/30 Mark Saad : > > On Mon, May 30, 2011 at 8:13 PM, Rick Macklem > > wrote: > >>> Hello All > >>> So I am stumped on this one. I want to know what the IP of each > >>> nfs server that is providing each nfs export. I am running > >>> 7.4-RELEASE > >>> When I run "mount -t nfs" I see something like this > >>> > >>> VIP-01:/export/source on /mnt/src > >>> VIP-02:/export/target on /mnt/target > >>> VIP-01:/export/logs on /mnt/logs > >>> VIP-02:/export/package on /mnt/pkg > >>> > >>> The issue is I use a load balanced nfs server , from isilon. So > >>> VIP-01 > >>> could be any one of a group of IPs . I am trying to track down a > >>> network congestion issue and I cant find a way to match the output > >>> of > >>> lsof , and netstat to the output of mount -t nfs . Does anyone > >>> have > >>> any ideas how I could track this down , is there a way to run > >>> mount > >>> and have it show the IP and not the name of the source server ? > >>> > >> Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump > >> doesn't know much about NFS, but if al you want are the IP#s, it'll > >> do. > >> > >> But, no, mount won't tell you more than what the argument looked > >> like. > >> > >> rick > >> > > Wireshark seams like using a tank to swap a fly. > > Maybe, but watching traffic isn't that scary and over the years I've discovered things I would have never expected from doing it. Like a case where one specific TCP segment was being dropped by a network switch (it was a hardware problem in the switch that didn't manifest itself any other way). Or, that one client was generating a massive number of Getattr and Lookup RPCs. (That one turned out to be a grad student who had made themselves an app. that had a bunch of threads continually scanning to fs changes. Not a bad idea, but the threads never took a break and continually did it.) I've always found watching traffic kinda fun, but then I'm weird, rick From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 16:58:27 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3C76106564A for ; Tue, 31 May 2011 16:58:27 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 784588FC16 for ; Tue, 31 May 2011 16:58:27 +0000 (UTC) Received: from park.js.berklix.net (p5DCBD110.dip.t-dialin.net [93.203.209.16]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p4VGYDYJ019054 for ; Tue, 31 May 2011 16:34:14 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p4VGY9Hj036674 for ; Tue, 31 May 2011 18:34:09 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id p4VGY4SW004129 for ; Tue, 31 May 2011 18:34:09 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201105311634.p4VGY4SW004129@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Tue, 31 May 2011 18:34:04 +0200 Sender: jhs@berklix.com Cc: Subject: /usr/share/calendar/calendar.british X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:58:28 -0000 Hi hackers@freebsd.org Britain had a national holiday yesterday. FreeBSD didn't notice as no /usr/share/calendar/calendar.british Other countries have their dates listed, so I wrote src/ http://www.freebsd.org/cgi/query-pr.cgi?pr=157466 If you'r British, or in Britain etc, please look at http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/calendars/calendar.british & mail me additions/ corrections. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; indent with "> "; cumulative like a play script. Mail plain text format; Not quoted-printable, Not HTML, Not base 64. From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 17:00:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E3A1065673 for ; Tue, 31 May 2011 17:00:49 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 642848FC1C for ; Tue, 31 May 2011 17:00:49 +0000 (UTC) Received: by bwz12 with SMTP id 12so5662641bwz.13 for ; Tue, 31 May 2011 10:00:48 -0700 (PDT) Received: by 10.204.26.200 with SMTP id f8mr1289118bkc.99.1306859779990; Tue, 31 May 2011 09:36:19 -0700 (PDT) Received: from amy.lab.techwires.net (p54B4C39E.dip.t-dialin.net [84.180.195.158]) by mx.google.com with ESMTPS id k10sm176242bkq.22.2011.05.31.09.36.18 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 09:36:18 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-hackers@freebsd.org Date: Tue, 31 May 2011 18:36:43 +0200 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.3; amd64; ; ) References: <4DE01421.7080902@rawbw.com> <201105311029.15259.jhb@freebsd.org> In-Reply-To: <201105311029.15259.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105311836.43543.bschmidt@freebsd.org> Cc: Yuri Subject: Re: ndis driver presents the valid WiFi network as having the name 0x000000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:00:49 -0000 On Tuesday 31 May 2011 16:29:15 John Baldwin wrote: > On Friday, May 27, 2011 5:14:09 pm Yuri wrote: > > Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with > > Windows driver. > > This same card and driver work fine with pretty much any other network I > > tried. > > But this one particular network shows as 0x000000 and I can't connect to it. > > Another FreeBSD desktop with native ath driver and apple both connect to > > it fine. > > > > What might be causing such weird behavior? > > Is this a known problem? > > Any way to troubleshoot this? > > I have this same problem. I've had to resort to using wpa_cli to 'select' my > network at work that has this issue and then using 'ap_scan 2' to force > wpa_supplicant to associate with it. You also will want ndis_events running > if you need to do WPA authentication. Are you using -D bsd or -D ndis as the driver for wpa_supplicant? -- Bernhard From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 17:45:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B4F1065673; Tue, 31 May 2011 17:45:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F39E8FC15; Tue, 31 May 2011 17:45:19 +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 BA81246B42; Tue, 31 May 2011 13:45:18 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5441E8A027; Tue, 31 May 2011 13:45:18 -0400 (EDT) From: John Baldwin To: Bernhard Schmidt Date: Tue, 31 May 2011 13:45:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DE01421.7080902@rawbw.com> <201105311029.15259.jhb@freebsd.org> <201105311836.43543.bschmidt@freebsd.org> In-Reply-To: <201105311836.43543.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105311345.17717.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 31 May 2011 13:45:18 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Yuri Subject: Re: ndis driver presents the valid WiFi network as having the name 0x000000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:45:19 -0000 On Tuesday, May 31, 2011 12:36:43 pm Bernhard Schmidt wrote: > On Tuesday 31 May 2011 16:29:15 John Baldwin wrote: > > On Friday, May 27, 2011 5:14:09 pm Yuri wrote: > > > Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with > > > Windows driver. > > > This same card and driver work fine with pretty much any other network I > > > tried. > > > But this one particular network shows as 0x000000 and I can't connect to it. > > > Another FreeBSD desktop with native ath driver and apple both connect to > > > it fine. > > > > > > What might be causing such weird behavior? > > > Is this a known problem? > > > Any way to troubleshoot this? > > > > I have this same problem. I've had to resort to using wpa_cli to 'select' my > > network at work that has this issue and then using 'ap_scan 2' to force > > wpa_supplicant to associate with it. You also will want ndis_events running > > if you need to do WPA authentication. > > Are you using -D bsd or -D ndis as the driver for wpa_supplicant? > > -- > Bernhard > -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 17:50:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0589106564A; Tue, 31 May 2011 17:50:24 +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 254E28FC0A; Tue, 31 May 2011 17:50:24 +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 C5EDA46B39; Tue, 31 May 2011 13:50:23 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5813E8A027; Tue, 31 May 2011 13:50:23 -0400 (EDT) From: John Baldwin To: Bernhard Schmidt Date: Tue, 31 May 2011 13:46:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DE01421.7080902@rawbw.com> <201105311029.15259.jhb@freebsd.org> <201105311836.43543.bschmidt@freebsd.org> In-Reply-To: <201105311836.43543.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105311346.12267.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 31 May 2011 13:50:23 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Yuri Subject: Re: ndis driver presents the valid WiFi network as having the name 0x000000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:50:24 -0000 On Tuesday, May 31, 2011 12:36:43 pm Bernhard Schmidt wrote: > On Tuesday 31 May 2011 16:29:15 John Baldwin wrote: > > On Friday, May 27, 2011 5:14:09 pm Yuri wrote: > > > Underlying card is Broadcom BCM94312MCGSG (mini-card for laptop) with > > > Windows driver. > > > This same card and driver work fine with pretty much any other network I > > > tried. > > > But this one particular network shows as 0x000000 and I can't connect to it. > > > Another FreeBSD desktop with native ath driver and apple both connect to > > > it fine. > > > > > > What might be causing such weird behavior? > > > Is this a known problem? > > > Any way to troubleshoot this? > > > > I have this same problem. I've had to resort to using wpa_cli to 'select' my > > network at work that has this issue and then using 'ap_scan 2' to force > > wpa_supplicant to associate with it. You also will want ndis_events running > > if you need to do WPA authentication. > > Are you using -D bsd or -D ndis as the driver for wpa_supplicant? Whatever the defaults are (which would be -B ndis). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 18:32:57 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46E871065673; Tue, 31 May 2011 18:32:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 01C2A8FC0C; Tue, 31 May 2011 18:32:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26] (unknown [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 012075C37; Tue, 31 May 2011 20:32:55 +0200 (CEST) Message-ID: <4DE53450.10109@FreeBSD.org> Date: Tue, 31 May 2011 20:32:48 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18pre) Gecko/20110527 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Best References: <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> In-Reply-To: <20110531143914.GA30260@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Bruce Cran , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:32:57 -0000 On 2011-05-31 16:39, Alexander Best wrote: ... > ...which leads me to the conclusion that -O should be set when DEBUG was > defined: an all ARCHS. > > right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the > kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't > -fno-omit-frame-pointer be set uncondtitionally on all archs? No, not unconditionally on all archs. Some arches have no problem debugging when gcc's frame pointer is turned off, namely arm, ia64, mips, powerpc and sparc, if I read the source correctly. On these arches, even -O already sets -fomit-frame-pointer. So, for all arches, if DEBUG is enabled, we could just use -O (as default only, if the user wants to override this for whatever reason, it should be honoured). > just like > -fno-strict-aliasing? That should only be needed in combination with -O2, if that is the default optimization (e.g. if DEBUG is not enabled). IMHO this option should not be forced, if users specify their own CFLAGS/COPTFLAGS. Summarizing, I would suggest: - If DEBUG is enabled, use plain -O by default, on all arches - If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all arches. From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 18:45:58 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08AF1065674; Tue, 31 May 2011 18:45:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id ABD308FC1F; Tue, 31 May 2011 18:45:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26] (unknown [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BDA7A5C37; Tue, 31 May 2011 20:45:57 +0200 (CEST) Message-ID: <4DE5375F.1050400@FreeBSD.org> Date: Tue, 31 May 2011 20:45:51 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18pre) Gecko/20110527 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Best References: <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> <20110531152654.GA42990@freebsd.org> In-Reply-To: <20110531152654.GA42990@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Bruce Cran , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:45:59 -0000 On 2011-05-31 17:26, Alexander Best wrote: ... > so how about the following patch? Could you please try to not mix spacing and style changes with functional changes in this patch? It makes it more difficult to review. From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 18:47:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A156D1065673; Tue, 31 May 2011 18:47:44 +0000 (UTC) (envelope-from yanegomi@gmail.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 569958FC15; Tue, 31 May 2011 18:47:43 +0000 (UTC) Received: by pwj8 with SMTP id 8so2763592pwj.13 for ; Tue, 31 May 2011 11:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=THxt1CEpaOZeKC4LuL29e/Hzcmh9Z1ZFZpRH1rY/Xus=; b=bNpa1OlUrmdbbQSWpwG3iRvgGnOxmJpGC57U+Rgq66y652VmOQUixVQX4a9+LX8CxV QuhUnHN4t+MDCfZsxq+EWcft+1qDWwXztbQ9e7mfrEbdqw+/q2oRpJzYaep14ZdmC1qF Mjx+c3DZqRuHKjaIME7aUMJZSByKkEZwSQ2ac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=vKtCZoWYQMECbxuB48UdhiFcVY1nsI1hsSJKw3i0PtSuCqitJS4EoXGRgyg8kyA46F clO4gm70qos1YdWxIOj8aM6f68rfoTaf7hV13L7kit28WXTvyeYxOHg6BIY8+fgwm+Ts JzxBbo1GKuqRFgzcEUXXrWz8+2WCYrS4NhxFU= Received: by 10.142.152.34 with SMTP id z34mr1169615wfd.197.1306867663698; Tue, 31 May 2011 11:47:43 -0700 (PDT) Received: from [173.37.1.90] (dhcp-173-37-1-90.cisco.com [173.37.1.90]) by mx.google.com with ESMTPS id q13sm165789wfd.23.2011.05.31.11.47.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 11:47:42 -0700 (PDT) References: <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> <20110531152654.GA42990@freebsd.org> <4DE5375F.1050400@FreeBSD.org> In-Reply-To: <4DE5375F.1050400@FreeBSD.org> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <43542F98-E35C-48D0-A582-40CD31F0056D@gmail.com> X-Mailer: iPhone Mail (8J2) From: Garrett Cooper Date: Tue, 31 May 2011 11:47:37 -0700 To: Dimitry Andric Cc: Bruce Cran , Alexander Best , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:47:44 -0000 On May 31, 2011, at 11:45 AM, Dimitry Andric wrote: > On 2011-05-31 17:26, Alexander Best wrote: > ... >> so how about the following patch? > > Could you please try to not mix spacing and style changes with > functional changes in this patch? It makes it more difficult to review. +1 From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 19:18:20 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0EA7C106566C; Tue, 31 May 2011 19:18:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1019314E236; Tue, 31 May 2011 19:18:16 +0000 (UTC) Message-ID: <4DE53EF7.2080603@FreeBSD.org> Date: Tue, 31 May 2011 12:18:15 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Best References: <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> In-Reply-To: <20110531143914.GA30260@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruce Cran , Garrett Cooper , "freebsd-hackers@FreeBSD.ORG" , Dimitry Andric , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 19:18:20 -0000 On 05/31/2011 07:39, Alexander Best wrote: > ...which leads me to the conclusion that -O should be set when DEBUG was > defined: an all ARCHS. +1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 20:00:06 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id B89641065674; Tue, 31 May 2011 20:00:06 +0000 (UTC) Date: Tue, 31 May 2011 20:00:06 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110531200006.GA74380@freebsd.org> References: <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> <4DE53450.10109@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <4DE53450.10109@FreeBSD.org> Cc: Garrett Cooper , Bruce Cran , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 20:00:06 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue May 31 11, Dimitry Andric wrote: > On 2011-05-31 16:39, Alexander Best wrote: > ... > >...which leads me to the conclusion that -O should be set when DEBUG was > >defined: an all ARCHS. > > > >right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the > >kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? > >shouldn't > >-fno-omit-frame-pointer be set uncondtitionally on all archs? > > No, not unconditionally on all archs. Some arches have no problem > debugging when gcc's frame pointer is turned off, namely arm, ia64, > mips, powerpc and sparc, if I read the source correctly. > > On these arches, even -O already sets -fomit-frame-pointer. > > So, for all arches, if DEBUG is enabled, we could just use -O (as > default only, if the user wants to override this for whatever reason, it > should be honoured). > > > >just like > >-fno-strict-aliasing? > > That should only be needed in combination with -O2, if that is the > default optimization (e.g. if DEBUG is not enabled). IMHO this option > should not be forced, if users specify their own CFLAGS/COPTFLAGS. > > Summarizing, I would suggest: > > - If DEBUG is enabled, use plain -O by default, on all arches > - If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all > arches. thanks for your suggestions. i've incorporated them into the patch. one thing i'm unsure is: what should be done when the user *doesn't* define DEBUG, but has DDB, KDTRACE_FRAME or HWPMC in his kernel config? the current behavior is to set -fno-omit-frame-pointer on amd64 and powerpc. i think this behavior shouldn't be change. even though the user didn't specify DEBUG, the fact that he has those kernel options indicates that he wants to do some kind of debugging imho. cheers. alex ps: sorry for the extra whitespace changes! -- a13x --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern.pre.mk.diff" diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk index e9aa6e2..e6beda8 100644 --- a/sys/conf/kern.pre.mk +++ b/sys/conf/kern.pre.mk @@ -24,18 +24,12 @@ OBJCOPY?= objcopy SIZE?= size .if defined(DEBUG) -_MINUS_O= -O +COPTFLAGS?= -O -pipe CTFFLAGS+= -g +.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang" +COPTFLAGS?= -O2 -fno-strict-aliasing -frename-registers -pipe .else -_MINUS_O= -O2 -.endif -.if ${MACHINE_CPUARCH} == "amd64" -COPTFLAGS?=-O2 -frename-registers -pipe -.else -COPTFLAGS?=${_MINUS_O} -pipe -.endif -.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) -COPTFLAGS+= -fno-strict-aliasing +COPTFLAGS?= -O2 -fno-strict-aliasing -pipe .endif .if !defined(NO_CPU_COPTFLAGS) COPTFLAGS+= ${_CPUCFLAGS} --CE+1k2dSO48ffgeK-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 20:16:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6B9371065672; Tue, 31 May 2011 20:16:40 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 31 May 2011 16:16:26 -0400 User-Agent: KMail/1.6.2 References: <201105241356.45543.jkim@FreeBSD.org> <4DE4CE82.4030301@FreeBSD.org> In-Reply-To: <4DE4CE82.4030301@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105311616.31256.jkim@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 20:16:41 -0000 On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote: > on 24/05/2011 20:56 Jung-uk Kim said the following: > > I think it's about time to enable invariant TSC timecounter on > > SMP by default. Please see the attached patch. It is also > > available from here: > > > > http://people.freebsd.org/~jkim/tsc_smp_test4.diff > > > > avg convinced me enough that it should be an opt-out feature > > going forward. :-) > > Not sure if I really did that. > My position is this: > - if we think that TSC is SMP-safe then it should have the best > priority > - we should do our best to auto-guess if TSC is SMP-safe > unless a user explicitly overrides that property (either via > explicit testing or by making guesses based on CPU model or etc) I am sorry if I misunderstood your intention. However, I added explicit boot-time TSC sanity check (to do our best to auto-guess) and I think TSC is fairly SMP-safe. Hence, I thought that it is about time for the change. > > Comments? > > Perhaps I missed it, but I don't remember the "lowres" part of the > patch being discussed. No, it wasn't discussed with you. Do you see any problem with that code? Thanks, Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 23:07:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E7C1065670 for ; Tue, 31 May 2011 23:07:32 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C56608FC08 for ; Tue, 31 May 2011 23:07:31 +0000 (UTC) Received: by wyf23 with SMTP id 23so5012303wyf.13 for ; Tue, 31 May 2011 16:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=0fJJrJeEiLX9xxDrS0BHyoCA0IXpn2PRvGikxdjLHFc=; b=QqnceRi6/CTb+JAOni/hTq4kyJz97v/SdVu9474ZfpDpeJJv5x8bchPKUPr1BNzN8r YNs7QpHFfJugxCj2jtgwftIttx3fJbwMLNuSN+XSOxLmib+BJjlMMpjpyFg1JXeAn2iI fGcKR20xUUG8o0ElT71GfUVhOD7mx+hmLSfBg= 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:content-type; b=RzFfqgkFkrUXStgjCys9r46JHIQCnII6bUQnX+eihERwcdxU8RxazKwMOpedrWBc1/ 7ouue1WPfiZXtydM6spBjjhvujkd8YHOaNO8H9MEKTW8aUQm2qYTFJHyHQa/k01re8Pu vT3WbP0NrYuSdlF2oLLbaM8y8pLHqwM6X0yJM= MIME-Version: 1.0 Received: by 10.216.221.158 with SMTP id r30mr4234207wep.50.1306883249998; Tue, 31 May 2011 16:07:29 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.93.193 with HTTP; Tue, 31 May 2011 16:07:29 -0700 (PDT) Date: Tue, 31 May 2011 16:07:29 -0700 X-Google-Sender-Auth: qVe6tI0JN3lDWH5oujhYOTEMak8 Message-ID: From: mdf@FreeBSD.org To: freebsd-hackers , Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:07:32 -0000 I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 23:23:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7013106566B; Tue, 31 May 2011 23:23:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 64BE78FC15; Tue, 31 May 2011 23:23:41 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4VNIG5h017858 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 17:18:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 31 May 2011 17:18:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: mdf@freebsd.org X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 31 May 2011 17:18:18 -0600 (MDT) Cc: freebsd-hackers , Bruce Evans Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:23:41 -0000 On May 31, 2011, at 5:07 PM, mdf@freebsd.org wrote: > I am looking into potentially MFC'ing r212367 and related, that adds > drains to sbufs. The reason for MFC is that several pieces of new > code in CURRENT are using the drain functionality and it would make > MFCing those changes much easier. >=20 > The problem is that r212367 added a pointer to a drain function in the > sbuf (it replaced a pointer to void). The C standard doesn't > guarantee that a void * and a function pointer have the same size, > though its true on amd64, i386 and I believe PPC. What I'm wondering > is, though not guaranteed by the standard, is it *practically* true > that sizeof(void *) =3D=3D sizeof(int(*)(void)), such that an MFC = won't > break binary compatibility for any supported architecture? (The > standard does guarantee, though not in words, that all function > pointers have the same size, since it guarantees that pointers to > functions can be cast to other pointers to functions and back without > changing the value). >=20 > Another possibility is to malloc a blob that is sizeof(int(*)(void)) > and store that in a renamed s_unused; this is a bit messier but > guaranteed to work. I'd just rather the code be an MCF instead of a > partial re-write. It is the same on MIPS too for all three ABIs that we support (and all = ABIs that I know about). It is true on ARM as well. Usually it is different only on segmented architectures like 16-bit x86. Warner= From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 23:39:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85DC106564A for ; Tue, 31 May 2011 23:39:16 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 9210D8FC14 for ; Tue, 31 May 2011 23:39:16 +0000 (UTC) Received: (qmail 28635 invoked by uid 0); 31 May 2011 23:38:57 -0000 Received: from 67.206.163.29 by rms-us007.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Tue, 31 May 2011 23:38:53 +0000 From: "Dieter BSD" Message-ID: <20110531233855.95190@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org,freebsd-toolchain@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: ag2MIl0dlTXuAivrAW5lMhRjaGRhZlq2 Cc: Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:39:17 -0000 >> please keep in mind that -Wfoo does reflect the ideas of the GNU people >> regarding *proper* code. the warnings themselves are sometimes wrong, >> because they complain about perfectly correct code. I attempted to get the gcc people to improve this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 Most of the warnings I see are either due to someone thinking all the world is ILP32 and doing things like storing a 64 bit pointer or long in a 32 bit int, or due to the compiler needing more info to insure that they are not trying to stuff 64 bits into 32, such as missing prototypes.  Either way it needs to be fixed. In many cases the developers that claim to write such great code, and claim that the compiler warnings don't matter are the ones whose code has the most bugs (seg faults, floating point exceptions, ...). > Pretty much the entire kernel is compiled > with quite a large number of warning classes enabled, and -Werror set, for > example. Whoever did this, THANK YOU!!! > fixing warnings in other people's code is useful only if > you can get them to accept the fixes back Fixing bugs is always useful.  Certainly it is a *lot* more efficient if you can get them fixed at the source rather than having to maintain patches. From owner-freebsd-hackers@FreeBSD.ORG Tue May 31 23:45:17 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423AE106566B for ; Tue, 31 May 2011 23:45:17 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 06D378FC23 for ; Tue, 31 May 2011 23:45:16 +0000 (UTC) Received: (qmail 8013 invoked by uid 0); 31 May 2011 23:45:16 -0000 Received: from 67.206.163.29 by rms-us013.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Tue, 31 May 2011 23:45:13 +0000 From: "Dieter BSD" Message-ID: <20110531234514.95200@gmx.com> MIME-Version: 1.0 To: hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: uUrXfAQNhTXpb1nbH2Nr4+5Sa2FkZtUX Cc: Subject: Re: Active slice, only for a next boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:45:17 -0000 Peter writes: >> A better approach is to be able to boot whatever slice you >> want without having to change the active slice. >> >> NetBSD can do this. The MBR puts up a menu of the bootable >> slices on the disk being booted. You can allow the timer >> to time out and boot the default. Or you can enter the number >> of the slice you want to boot. Or you can type a function key >> F1 F2 ... to boot a different disk, and it will load the MBR >> from that disk and run it. There is an alternative for keyboards >> without function keys. > So can FreeBSD - though only for MBR If so, the documentation could use improvement. Examples would be great. > - this functionality doesn't seem > to have made it into the GPT bootcode. Is anyone working on this?  MBR is only good for 2 TB and the 3 TB disks are becoming cost competitive.  I've switched over to GPT for everything except boot disks, as it is less brain damaged than MBR. >> And it works great. Except that one of the 27 stages of boot >> code that FreeBSD uses INSISTS on booting the active slice, >> so you can tell the MBR to boot slice 3 and slice 3's boot >> code sees that slice 4 is active and boots slice 4. > > Multibooting worked correctly when I last used it (a few years ago). > Have you raised this as a PR? No, partly because I haven't had much luck with PRs.  Mainly because I'd rather spend my time trying to migrate to GPT than improving MBR. So many bugs/misfeatures so little time, >> RS-232 console + hardware modem + POTS = remote console > > And even that doesn't fully work unless you have a serial-aware BIOS. Real computers have RS-232 consoles. If you neglected to specify RS-232 console in the requirements, there is this thing.  I haven't tried it. http://www.realweasel.com/ Somebody probably sells a KVM-over-IP box. You could see if openbios supports your mainboard. John writes: >> And it works great.  Except that one of the 27 stages of boot >> code that FreeBSD uses INSISTS on booting the active slice, >> so you can tell the MBR to boot slice 3 and slice 3's boot >> code sees that slice 4 is active and boots slice 4. > > There are only 3 stages, It feels like more.  :-) > and boot1.S is what looks at the active slice.   > Unfortunately it doesn't have a better way to do this as the only input it > gets from boot0 or any other MBR boot loader is the BIOS drive number in %dl. > I'm not sure how else you would detect that a non-active slice was booted from > when that is your only input. The NetBSD boot code manages to do it. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 00:28:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA96D106566C; Wed, 1 Jun 2011 00:28:53 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 424078FC1E; Wed, 1 Jun 2011 00:28:52 +0000 (UTC) Received: by qyk35 with SMTP id 35so1821262qyk.13 for ; Tue, 31 May 2011 17:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=IM66R4Za3evntw4WtQmp2GY7iMRljYhRKyJHHV4zoHg=; b=AsaFi7uiKbakyR8cTkioBmm0/4hFgLehmBFa7Icg6hWAr43NswOxrfqHn+hPAlqzKk kL5XKKVhweorkOznzYBTFNLp3GWyzobNWO48FK/pdtzTB4IXX9UeaRj4BaP4wBbj6YkJ NRKiQpS1pKA932836nWGcDQA6kJB+oOM3kXWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=uPPuS6omPM1SOU+USPUgF2VCKl6xr1dlnZwp8iYxsyZWjhlvYiNkwt9zo1/GmdXETD Mh3u/LFG9mPReM2KMenOrN2CKwtxuVZStodL1u6uMDzCxwUdlq0kGqLzY5SrwB9WJG8N Rtpv8cViG+TUwpAjp42QVapiRhmttZonTdX0U= Received: by 10.229.49.133 with SMTP id v5mr4786871qcf.165.1306886820296; Tue, 31 May 2011 17:07:00 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id j18sm356659qck.3.2011.05.31.17.06.58 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 17:06:59 -0700 (PDT) Date: Tue, 31 May 2011 20:06:52 -0400 From: Alexander Kabaev To: Warner Losh Message-ID: <20110531200652.3fd6fcbe@kan.dnsalias.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/T7iGdQ5fH88cY+VF2hw12sz"; protocol="application/pgp-signature" Cc: Bruce, mdf@freebsd.org, Evans , freebsd-hackers Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 00:28:53 -0000 --Sig_/T7iGdQ5fH88cY+VF2hw12sz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 31 May 2011 17:18:16 -0600 Warner Losh wrote: >=20 > On May 31, 2011, at 5:07 PM, mdf@freebsd.org wrote: >=20 > > I am looking into potentially MFC'ing r212367 and related, that adds > > drains to sbufs. The reason for MFC is that several pieces of new > > code in CURRENT are using the drain functionality and it would make > > MFCing those changes much easier. > >=20 > > The problem is that r212367 added a pointer to a drain function in > > the sbuf (it replaced a pointer to void). The C standard doesn't > > guarantee that a void * and a function pointer have the same size, > > though its true on amd64, i386 and I believe PPC. What I'm > > wondering is, though not guaranteed by the standard, is it > > *practically* true that sizeof(void *) =3D=3D sizeof(int(*)(void)), > > such that an MFC won't break binary compatibility for any supported > > architecture? (The standard does guarantee, though not in words, > > that all function pointers have the same size, since it guarantees > > that pointers to functions can be cast to other pointers to > > functions and back without changing the value). > >=20 > > Another possibility is to malloc a blob that is sizeof(int(*)(void)) > > and store that in a renamed s_unused; this is a bit messier but > > guaranteed to work. I'd just rather the code be an MCF instead of a > > partial re-write. >=20 > It is the same on MIPS too for all three ABIs that we support (and > all ABIs that I know about). It is true on ARM as well. >=20 > Usually it is different only on segmented architectures like 16-bit > x86. >=20 Not so on ia64, where they have special function descriptor type. --=20 Alexander Kabaev --Sig_/T7iGdQ5fH88cY+VF2hw12sz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFN5YKhQ6z1jMm+XZYRAiK3AKCSuEio0fx7ad5Fz2KpK+nuHTgKfwCfe3Ct Cd5nVJmXm44uRN/E6dm36yE= =hwor -----END PGP SIGNATURE----- --Sig_/T7iGdQ5fH88cY+VF2hw12sz-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 00:41:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E30A1106566B; Wed, 1 Jun 2011 00:41:56 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id B62F98FC0A; Wed, 1 Jun 2011 00:41:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LM30060035VNV00@smtpauth2.wiscmail.wisc.edu>; Tue, 31 May 2011 18:41:55 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-71-150-248-94.dsl.mdsnwi.sbcglobal.net [71.150.248.94]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LM3000TJ35U5B10@smtpauth2.wiscmail.wisc.edu>; Tue, 31 May 2011 18:41:54 -0500 (CDT) Date: Tue, 31 May 2011 18:41:53 -0500 From: Nathan Whitehorn In-reply-to: To: freebsd-hackers@freebsd.org, mdf@FreeBSD.org Message-id: <4DE57CC1.6000105@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=71.150.248.94 X-Spam-PmxInfo: Server=avs-14, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.31.233322, SenderIP=71.150.248.94 References: User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 Cc: Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 00:41:57 -0000 On 05/31/11 18:18, Warner Losh wrote: > On May 31, 2011, at 5:07 PM, mdf@freebsd.org wrote: > >> I am looking into potentially MFC'ing r212367 and related, that adds >> drains to sbufs. The reason for MFC is that several pieces of new >> code in CURRENT are using the drain functionality and it would make >> MFCing those changes much easier. >> >> The problem is that r212367 added a pointer to a drain function in the >> sbuf (it replaced a pointer to void). The C standard doesn't >> guarantee that a void * and a function pointer have the same size, >> though its true on amd64, i386 and I believe PPC. What I'm wondering >> is, though not guaranteed by the standard, is it *practically* true >> that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't >> break binary compatibility for any supported architecture? (The >> standard does guarantee, though not in words, that all function >> pointers have the same size, since it guarantees that pointers to >> functions can be cast to other pointers to functions and back without >> changing the value). >> >> Another possibility is to malloc a blob that is sizeof(int(*)(void)) >> and store that in a renamed s_unused; this is a bit messier but >> guaranteed to work. I'd just rather the code be an MCF instead of a >> partial re-write. > It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about). It is true on ARM as well. > > Usually it is different only on segmented architectures like 16-bit x86. It is also true on ARM, PPC, PPC64, and ia64, which I just tested. I think you're safe. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 01:19:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3601B1065672 for ; Wed, 1 Jun 2011 01:19:22 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 08A948FC1C for ; Wed, 1 Jun 2011 01:19:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LM300J007O9UO00@smtpauth2.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Tue, 31 May 2011 20:19:21 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-71-150-248-94.dsl.mdsnwi.sbcglobal.net [71.150.248.94]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LM300GHZ7O7HP00@smtpauth2.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Tue, 31 May 2011 20:19:20 -0500 (CDT) Date: Tue, 31 May 2011 20:19:19 -0500 From: Nathan Whitehorn In-reply-to: <20110531200652.3fd6fcbe@kan.dnsalias.net> To: freebsd-hackers@freebsd.org Message-id: <4DE59397.8010205@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=71.150.248.94 X-Spam-PmxInfo: Server=avs-12, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.1.10920, SenderIP=71.150.248.94 References: <20110531200652.3fd6fcbe@kan.dnsalias.net> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 01:19:22 -0000 On 05/31/11 19:06, Alexander Kabaev wrote: > On Tue, 31 May 2011 17:18:16 -0600 > Warner Losh wrote: > >> On May 31, 2011, at 5:07 PM, mdf@freebsd.org wrote: >> >>> I am looking into potentially MFC'ing r212367 and related, that adds >>> drains to sbufs. The reason for MFC is that several pieces of new >>> code in CURRENT are using the drain functionality and it would make >>> MFCing those changes much easier. >>> >>> The problem is that r212367 added a pointer to a drain function in >>> the sbuf (it replaced a pointer to void). The C standard doesn't >>> guarantee that a void * and a function pointer have the same size, >>> though its true on amd64, i386 and I believe PPC. What I'm >>> wondering is, though not guaranteed by the standard, is it >>> *practically* true that sizeof(void *) == sizeof(int(*)(void)), >>> such that an MFC won't break binary compatibility for any supported >>> architecture? (The standard does guarantee, though not in words, >>> that all function pointers have the same size, since it guarantees >>> that pointers to functions can be cast to other pointers to >>> functions and back without changing the value). >>> >>> Another possibility is to malloc a blob that is sizeof(int(*)(void)) >>> and store that in a renamed s_unused; this is a bit messier but >>> guaranteed to work. I'd just rather the code be an MCF instead of a >>> partial re-write. >> It is the same on MIPS too for all three ABIs that we support (and >> all ABIs that I know about). It is true on ARM as well. >> >> Usually it is different only on segmented architectures like 16-bit >> x86. >> > Not so on ia64, where they have special function descriptor type. > As is also true on PPC64 and (I think) at least some MIPS. But on all of these, a function pointer is a regular data pointer to the function descriptor, which then points to the function, so they are still the same size as a void *. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 03:01:28 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62A461065675 for ; Wed, 1 Jun 2011 03:01:28 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9BB8FC08 for ; Wed, 1 Jun 2011 03:01:27 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p5131M7W008263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 May 2011 20:01:23 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p5131MeI008262; Tue, 31 May 2011 20:01:22 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08843; Tue, 31 May 11 19:50:16 PDT Date: Tue, 31 May 2011 19:50:11 -0700 From: perryh@pluto.rain.com To: dieterbsd@engineer.com Message-Id: <4de5a8e3.kcNH3s3BI3v0Bcca%perryh@pluto.rain.com> References: <20110531234514.95200@gmx.com> In-Reply-To: <20110531234514.95200@gmx.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Active slice, only for a next boot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 03:01:28 -0000 "Dieter BSD" wrote: > If you neglected to specify RS-232 console in the requirements, > there is this thing. ??I haven't tried it. > http://www.realweasel.com/ Heard of it, aka the PC Weasel. I've never actually seen one. They have been around for a while; the original -- which they apparently still make -- was ISA. > Somebody probably sells a KVM-over-IP box. Raritan, at least. Probably others also. > > Unfortunately it doesn't have a better way to do this as the > > only input it gets from boot0 or any other MBR boot loader is > > the BIOS drive number in %dl. I'm not sure how else you would > > detect that a non-active slice was booted from when that is > > your only input. > > The NetBSD boot code manages to do it. Dunno how NetBSD does it, but one approach that comes to mind would be for whatever installs boot1 to set one of its bytes to the slice number in which it is installed. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 04:47:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0240E106564A; Wed, 1 Jun 2011 04:47:16 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4088FC14; Wed, 1 Jun 2011 04:47:15 +0000 (UTC) Received: from dhcp-192-168-2-22.wifi.xcllnt.net (atm.xcllnt.net [70.36.220.6]) (authenticated bits=0) by mail.xcllnt.net (8.14.4/8.14.4) with ESMTP id p5149AVg018682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 21:09:16 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20110531200652.3fd6fcbe@kan.dnsalias.net> Date: Tue, 31 May 2011 21:09:10 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20110531200652.3fd6fcbe@kan.dnsalias.net> To: Alexander Kabaev X-Mailer: Apple Mail (2.1084) Cc: mdf@freebsd.org, Evans , Bruce@freebsd.org, freebsd-hackers Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 04:47:16 -0000 On May 31, 2011, at 5:06 PM, Alexander Kabaev wrote: >> Usually it is different only on segmented architectures like 16-bit >> x86. >> > > Not so on ia64, where they have special function descriptor type. Actually, no. On ia64 a function pointer has the same size as a data pointer. It's just that a function pointer does not point to the actual function (i.e. the first instruction of a function), but to a function descriptor. The function descriptor contains the address of the actual function and the value of the GP register that needs to be set before entering the function. As such, only virtual functions in C++ are impacted by this. The function descriptor needs to be stored in the object instead of the function pointer in that case. FYI, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 05:40:37 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96403106564A; Wed, 1 Jun 2011 05:40:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B4E8F8FC0C; Wed, 1 Jun 2011 05:40:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA26536; Wed, 01 Jun 2011 08:40:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QReAU-000KAf-H2; Wed, 01 Jun 2011 08:40:34 +0300 Message-ID: <4DE5D0D1.1030903@FreeBSD.org> Date: Wed, 01 Jun 2011 08:40:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jung-uk Kim References: <201105241356.45543.jkim@FreeBSD.org> <4DE4CE82.4030301@FreeBSD.org> <201105311616.31256.jkim@FreeBSD.org> In-Reply-To: <201105311616.31256.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 05:40:37 -0000 on 31/05/2011 23:16 Jung-uk Kim said the following: > On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote: >> on 24/05/2011 20:56 Jung-uk Kim said the following: >>> I think it's about time to enable invariant TSC timecounter on >>> SMP by default. Please see the attached patch. It is also >>> available from here: >>> >>> http://people.freebsd.org/~jkim/tsc_smp_test4.diff >>> >>> avg convinced me enough that it should be an opt-out feature >>> going forward. :-) >> >> Not sure if I really did that. >> My position is this: >> - if we think that TSC is SMP-safe then it should have the best >> priority >> - we should do our best to auto-guess if TSC is SMP-safe >> unless a user explicitly overrides that property (either via >> explicit testing or by making guesses based on CPU model or etc) > > I am sorry if I misunderstood your intention. However, I added > explicit boot-time TSC sanity check (to do our best to auto-guess) > and I think TSC is fairly SMP-safe. Hence, I thought that it is > about time for the change. In this case - yes. But I remember that you were thinking about either improving or simplifying that check or both. >>> Comments? >> >> Perhaps I missed it, but I don't remember the "lowres" part of the >> patch being discussed. > > No, it wasn't discussed with you. Do you see any problem with that > code? I don't see any obvious problem, but I also don't understand rationale of using smaller max_freq for the ncpus > 1 case. Maybe these two logical changes should be done as two separate commits. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 07:45:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 598D21065670; Wed, 1 Jun 2011 07:45:10 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id F10A08FC18; Wed, 1 Jun 2011 07:45:08 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMGAL3k5U1bsdSL/2dsb2JhbABTmA+OEXjGYYYgBJ99 Received: from 139.212-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.212.139]) by relay.skynet.be with ESMTP; 01 Jun 2011 09:15:49 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id p517FmkN002636; Wed, 1 Jun 2011 09:15:48 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-hackers@freebsd.org Date: Wed, 1 Jun 2011 09:14:54 +0200 User-Agent: KMail/1.13.6 (FreeBSD/9.0-CURRENT; KDE/4.6.2; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart62236387.rDRI1Qijmq"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201106010915.46113.tijl@coosemans.org> Cc: mdf@freebsd.org, Bruce Evans Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:45:10 -0000 --nextPart62236387.rDRI1Qijmq Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wednesday 01 June 2011 01:07:29 mdf@freebsd.org wrote: > I am looking into potentially MFC'ing r212367 and related, that adds > drains to sbufs. The reason for MFC is that several pieces of new > code in CURRENT are using the drain functionality and it would make > MFCing those changes much easier. >=20 > The problem is that r212367 added a pointer to a drain function in the > sbuf (it replaced a pointer to void). The C standard doesn't > guarantee that a void * and a function pointer have the same size, > though its true on amd64, i386 and I believe PPC. What I'm wondering > is, though not guaranteed by the standard, is it *practically* true > that sizeof(void *) =3D=3D sizeof(int(*)(void)), such that an MFC won't > break binary compatibility for any supported architecture? It's guaranteed by POSIX. http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html Section 2.12.3 --nextPart62236387.rDRI1Qijmq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EABEIAAYFAk3l5yEACgkQfoCS2CCgtit8zQD/bq4ydYnWmKyewxO98ZhUqBED Ap9pJMIPywB7NGcpekgA/1zWORGnd9dsQHvZP7mrfEFoRCr3v0FwA0c7HqPsGCvY =5Uib -----END PGP SIGNATURE----- --nextPart62236387.rDRI1Qijmq-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 11:27:08 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C6F106564A for ; Wed, 1 Jun 2011 11:27:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 324818FC17 for ; Wed, 1 Jun 2011 11:27:07 +0000 (UTC) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p519DoAX026674 for ; Wed, 1 Jun 2011 19:13:50 +1000 Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p519Didd029695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 19:13:46 +1000 Date: Wed, 1 Jun 2011 19:13:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: mdf@FreeBSD.org In-Reply-To: Message-ID: <20110601183251.I1061@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 01 Jun 2011 11:55:23 +0000 Cc: freebsd-hackers , Bruce Evans Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 11:27:08 -0000 On Tue, 31 May 2011 mdf@FreeBSD.org wrote: > I am looking into potentially MFC'ing r212367 and related, that adds > drains to sbufs. The reason for MFC is that several pieces of new > code in CURRENT are using the drain functionality and it would make > MFCing those changes much easier. > > The problem is that r212367 added a pointer to a drain function in the > sbuf (it replaced a pointer to void). The C standard doesn't > guarantee that a void * and a function pointer have the same size, > though its true on amd64, i386 and I believe PPC. What I'm wondering > is, though not guaranteed by the standard, is it *practically* true > that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't > break binary compatibility for any supported architecture? (The Only on supported arches. > standard does guarantee, though not in words, that all function > pointers have the same size, since it guarantees that pointers to > functions can be cast to other pointers to functions and back without > changing the value). No, it doesn't guarantee that they have the same size. The casts may change inything in the representation including the size. In 1995 I added intfptr_t, uintfptr_t and fptrdiff_t to FreeBSD to handle this problem in the profil(2) APIs. You can check the MD definitions of these to verify that their size is always the same as the sizeof(void *). There are some style bugs and namespace issues with these. The definitions in /sys/*/include/_types.h are clean, but are mostly not used in their primary consumer /sys/*/include/profile.h. intfptr_t and uintfptr_t are bogusly declared for the kernel in a bogus declaration section in /sys/types.h. They are intentionally kept out of general headers, but even the kernel doesn't really need them there, unless they are used for more than profiling and then you might need them outside the kernel. > Another possibility is to malloc a blob that is sizeof(int(*)(void)) > and store that in a renamed s_unused; this is a bit messier but > guaranteed to work. I'd just rather the code be an MCF instead of a > partial re-write. It is only guaranteed to work if the value is converted to the actual function pointer type before use. (At least for use as a function pointer.) Someone pointed out that POSIX now requires function pointers to have the same representation as void *. This is a bug in POSIX IMO. It isn't in the 2001 version. I think POSIX had to do something for broken parts of dlcfn APIs. Hopefully this isn't required generally. Requiring all function pointers to be convertible to void * and back without breaking them is bad enough, but requiring the same representation is much more restrictive. It breaks any system that has type info in the pointers. The C standard is careful not to require this breakage even for data pointers. Someones pointed out that ia64 function pointers are actually handles. Systems that want to put type info in pointers would have to use handles instead of actual pointers to give the same representation, even if this is not the natural ABI. Whether handle values are useful when the data that they point to is unavailable is unclear. The profiling ABIs mainly need the function pointers (converted to integers) as ids, and handle values are hopefully enough for that. If not, the conversion needs to mangle the values sufficiently for uniqueness. Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 14:12:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A597106566C for ; Wed, 1 Jun 2011 14:12:11 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7B48FC13 for ; Wed, 1 Jun 2011 14:12:11 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 711215E24 for ; Wed, 1 Jun 2011 13:55:18 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p51DtI9o054094 for ; Wed, 1 Jun 2011 13:55:18 GMT (envelope-from phk@critter.freebsd.dk) To: freebsd-hackers@freebsd.org From: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 01 Jun 2011 13:55:18 +0000 Message-ID: <54093.1306936518@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Galep5 chip programmer works under FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:12:11 -0000 I recently needed a new chip programmer for various hardware work and since I know this is a recurring issue for people, I thought I would share this information. After researching the market, I decided to get the Galep5 from the German company Conitec.net Price EUR 417 + sales tax It's a nifty little device with an embedded ARM9 processor which talks ethernet over USB which neatly solves the "Damn, now we also have to write a USB device driver" issue for Conitec. Good thinking there. Getting the Linux GUI application was pretty trivial: http://phk.freebsd.dk/Galep5.html There are various hooks into this product which allows it to be controlled by programs, I have not used those (yet?) Recommended, Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 15:44:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA7A21065675; Wed, 1 Jun 2011 15:44:21 +0000 (UTC) (envelope-from kabaev@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 61BA28FC15; Wed, 1 Jun 2011 15:44:20 +0000 (UTC) Received: by vws18 with SMTP id 18so5845388vws.13 for ; Wed, 01 Jun 2011 08:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=5nVeVFvspanfsWAz2UbnT9NqGBrQWKv7ThRh5+PgAg0=; b=DfwQFbE+kajh4PIidO9LrIPEf02pK8VRNFjLcKlgbb5WvW23k5sK5RfMTL7NvgHthm J4h+Rzol/RlTTXBxbDOQfzIRTLZFb/6+LQgFouybEFebXgiKONbTLcNBgnGCMAM7k42q 7ptlh/g78KuhoumUq+AJMEtDBE8FHCpGuIlIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=d4W4Q+7F9y7+l4Ls/XE1MjXJ2Zb4gePvK8ExA99N70+ZPvInFn67ndLHqWdNxKeeDL BRiTLYk4z4c66G7fFj8wU+qmw6x5ggysCJhj1LrWCDnW+B3p31rm46qpVOjld8P5Ba6R bSKbz2YkD9HEhJHym7X6ZTg1MTxUXVJY5aMWA= Received: by 10.52.98.97 with SMTP id eh1mr1350981vdb.7.1306943060285; Wed, 01 Jun 2011 08:44:20 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id gi16sm182932vcb.25.2011.06.01.08.44.18 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 08:44:19 -0700 (PDT) Date: Wed, 1 Jun 2011 11:44:12 -0400 From: Alexander Kabaev To: Marcel Moolenaar Message-ID: <20110601114412.7de0b349@kan.dnsalias.net> In-Reply-To: References: <20110531200652.3fd6fcbe@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/X=ZUaLTmp5J0v+TFtfK7Erg"; protocol="application/pgp-signature" Cc: mdf@freebsd.org, Evans , Bruce@freebsd.org, freebsd-hackers Subject: Re: sizeof(function pointer) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:44:21 -0000 --Sig_/X=ZUaLTmp5J0v+TFtfK7Erg Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 31 May 2011 21:09:10 -0700 Marcel Moolenaar wrote: >=20 > On May 31, 2011, at 5:06 PM, Alexander Kabaev wrote: > >> Usually it is different only on segmented architectures like 16-bit > >> x86. > >>=20 > >=20 > > Not so on ia64, where they have special function descriptor type. >=20 > Actually, no. On ia64 a function pointer has the same size as a > data pointer. It's just that a function pointer does not point > to the actual function (i.e. the first instruction of a function), > but to a function descriptor. The function descriptor contains the > address of the actual function and the value of the GP register > that needs to be set before entering the function. >=20 > As such, only virtual functions in C++ are impacted by this. The > function descriptor needs to be stored in the object instead of > the function pointer in that case. >=20 > FYI, >=20 > --=20 Oh, you are correct. I forgot the double indirection we do to support that in dlsym, where we are maintain our own 'virtual table' of function descriptors within rtld itself. --=20 Alexander Kabaev --Sig_/X=ZUaLTmp5J0v+TFtfK7Erg Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFN5l5QQ6z1jMm+XZYRAjgVAJ9KOZOAbApte9l7IAQS4DzNqVVsHACfXNfw mhWAgk2PlN+4EAtGt9wIf0U= =P2pN -----END PGP SIGNATURE----- --Sig_/X=ZUaLTmp5J0v+TFtfK7Erg-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 15:54:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A218106566C for ; Wed, 1 Jun 2011 15:54:08 +0000 (UTC) (envelope-from aehlig@linta.de) Received: from linta.de (isilmar-3.linta.de [188.40.101.200]) by mx1.freebsd.org (Postfix) with ESMTP id D6FCC8FC12 for ; Wed, 1 Jun 2011 15:54:07 +0000 (UTC) Received: (qmail 19764 invoked by uid 10); 1 Jun 2011 15:27:25 -0000 Received: from kta1c10 by isilmar.linta.de with BSMTP; 1 Jun 2011 15:27:25 -0000 Received: by kta1c10.sesnet.soton.ac.uk (Postfix, from userid 1001) id CA6973981D; Wed, 1 Jun 2011 16:27:13 +0100 (BST) Date: Wed, 1 Jun 2011 16:27:13 +0100 From: "Klaus T. Aehlig" To: freebsd-hackers@freebsd.org Message-ID: <20110601152713.GB51073@kta1c10.sesnet.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 01 Jun 2011 16:31:51 +0000 Subject: fdopendir prototype on 7.3-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:54:08 -0000 [Please CC me, as I'm not subscribed to this list] Hallo, while dealing with PR ports/157274 [1], I found that the following program cause a segmentation fault on 7.3-RELEASE amd64, even though my understanding of the man page of fdopendir(3) says it should not. #include #include #include int main(int argc, char **argv) { DIR *dirp; int fd; fd = open(".", O_RDONLY); dirp = fdopendir(fd); (void) readdir(dirp); } Compiling gives the warning "assignment makes pointer from integer without a cast" refering to the line with the fdopendir call. Indeed, adding the prototype extern DIR *fdopendir(int); right after the #include lines solves this problem. Is my understanding of the man page that the above #include lines should suffice incorrect? Is this problem known---or even fixed already? I have reports that indicate that this problem also seems to exist on 7.3-RELEASE-p4 amd64 and 8.1-RELEASE i386. The above program does not segfault on my 8.2-STABLE amd64. Any hints on the status of this observation are very welcome. Best regards, Klaus [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/157274 From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 16:42:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F3DE106564A for ; Wed, 1 Jun 2011 16:42:44 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2117C8FC17 for ; Wed, 1 Jun 2011 16:42:43 +0000 (UTC) Received: by bwz12 with SMTP id 12so313482bwz.13 for ; Wed, 01 Jun 2011 09:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Z7fEjoOFze+FTpKPZmA+1I9RVmWaLpz5tS0b638/Mi4=; b=qXkLYrOYN26ZNjVzLNgOYeshGiMBmLkzTKZVZGBzdx1Bx7VCa32zze9tnMBKVJ6dLk SnVs+B4Efa5OmvuXXrzL9uHChiMh377LkJWeCtY+cksk/Qm6BVdDw6bvpawPCFqMQ7D1 7R6ed72vH5ECFy2Wo73qje2EpCcb+cqN29BU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tGPu4aSVphNsNaX+d3OXHyi6fVb18psXfjqC4PAYqGdD3XA4FkFD2NbYHUBQ7+EQ4f 1Z5BK8d5EPM0KYnIlA71mszbQGGP4i40YAjBVuUSz1cTAAPDZgjpHPjwydxNsJKemYVP tt6LzrGlE4f4vDGghD88uheoWTRLYNAoUMKSs= MIME-Version: 1.0 Received: by 10.204.128.85 with SMTP id j21mr1760032bks.89.1306946562862; Wed, 01 Jun 2011 09:42:42 -0700 (PDT) Received: by 10.204.3.149 with HTTP; Wed, 1 Jun 2011 09:42:42 -0700 (PDT) Date: Wed, 1 Jun 2011 20:42:42 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Bug in ksched_setscheduler? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:42:44 -0000 Hello Hackers, I think I found a bug in ksched_setscheduler() function. 178 int 179 ksched_setscheduler(struct ksched *ksched, 180 struct thread *td, int policy, const struct sched_param *param) 181 { 182 int e = 0; 183 struct rtprio rtp; 184 185 switch(policy) 186 { 187 case SCHED_RR: 188 case SCHED_FIFO: 189 190 if (param->sched_priority >= P1B_PRIO_MIN && 191 param->sched_priority <= P1B_PRIO_MAX) 192 { 193 rtp.prio = p4prio_to_rtpprio(param->sched_priority); 194 rtp.type = (policy == SCHED_FIFO) 195 ? RTP_PRIO_FIFO : RTP_PRIO_REALTIME; 196 197 rtp_to_pri(&rtp, td); 198 } 199 else 200 e = EPERM; 201 202 203 break; 204 205 case SCHED_OTHER: 206 if (param->sched_priority >= 0 && 207 param->sched_priority <= (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE)) { 208 rtp.type = RTP_PRIO_NORMAL; 209 rtp.prio = p4prio_to_rtpprio(param->sched_priority); 210 rtp_to_pri(&rtp, td); 211 } else 212 e = EINVAL; 213 214 break; 215 216 default: 217 e = EINVAL; 218 break; 219 } 220 221 return e; 222 } Shouldn't we use p4prio_to_tsprio instead of p4prio_to_rtpprio at the line 209? This macro is defined but never used in kernel code: $ grep -r 'p4prio_to_tsprio' /usr/src/sys/ /usr/src/sys/kern/ksched.c:#define p4prio_to_tsprio(P) ((PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) - (P)) $ Is it a real bug or just my misunderstanding of something? Thanks! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 17:31:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F9D106564A for ; Wed, 1 Jun 2011 17:31:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07E768FC13 for ; Wed, 1 Jun 2011 17:31:23 +0000 (UTC) Received: by vxc34 with SMTP id 34so32061vxc.13 for ; Wed, 01 Jun 2011 10:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=YLRMn3GTsbsdxh8G5PjWsZ6Hi4IYrxjDTRMb5BV0Jjk=; b=A1Z18DCOvPJaRZL3Zqi/1NyuSxPACeXZPlNI5X5EAWxwccLrkYEvgwu+e/kGMiTO4g h6Rgp1iLQJJIiZWZUbWB4DRUootVIepASYwlUKY9f/bHXO0HqANI066r4PJQCkWU5FkT lDbp6FtVQNMNa76qmvXYH9nqdEFdgnosPic8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=wpOMcjOIFM/KwawfQpwT1yv3bbD+zlj4oRXK7PDh/aqW2Uh2VG1dL21UnucCA9vO61 wNdCGYbaRAXQ6CtnRCYIaAHOjrlDbVdr8i772LBR4RJVRv/Fckf6KoB6khJGFestRdJF v7f6CNtGF50EDF/+y3x2NLhsSsyHO9mInQt68= Received: by 10.52.94.170 with SMTP id dd10mr3177099vdb.159.1306947620327; Wed, 01 Jun 2011 10:00:20 -0700 (PDT) Received: from oddish.mark-home (Mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id q1sm505023vdt.23.2011.06.01.10.00.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 10:00:19 -0700 (PDT) Date: Wed, 1 Jun 2011 13:00:17 -0400 From: Mark Johnston To: "Klaus T. Aehlig" Message-ID: <20110601170017.GB1830@oddish.mark-home> References: <20110601152713.GB51073@kta1c10.sesnet.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110601152713.GB51073@kta1c10.sesnet.soton.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: fdopendir prototype on 7.3-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:31:24 -0000 On Wed, Jun 01, 2011 at 04:27:13PM +0100, Klaus T. Aehlig wrote: > > [Please CC me, as I'm not subscribed to this list] > > Hallo, > > while dealing with PR ports/157274 [1], I found that the following > program cause a segmentation fault on 7.3-RELEASE amd64, even though > my understanding of the man page of fdopendir(3) says it should not. > > #include > #include > #include > > int main(int argc, char **argv) { > DIR *dirp; > int fd; > > fd = open(".", O_RDONLY); > dirp = fdopendir(fd); > (void) readdir(dirp); > > } > > Compiling gives the warning "assignment makes pointer from integer without a cast" > refering to the line with the fdopendir call. Indeed, adding the prototype > > extern DIR *fdopendir(int); > > right after the #include lines solves this problem. Is my understanding of the > man page that the above #include lines should suffice incorrect? Is this > problem known---or even fixed already? > > I have reports that indicate that this problem also seems to exist on 7.3-RELEASE-p4 amd64 > and 8.1-RELEASE i386. The above program does not segfault on my 8.2-STABLE amd64. > > Any hints on the status of this observation are very welcome. > > Best regards, > Klaus > > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/157274 > This has been fixed (in include/dirent.h) with r205265 on RELENG_7, but I can't see how you'd run into the problem on 8.1. The problem was that the fdopendir prototype was missing from dirent.h, so the code was compiled using the incorrect prototype "int fdopendir()". -Mark From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 17:38:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9451D106566B for ; Wed, 1 Jun 2011 17:38:54 +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 4A0D88FC15 for ; Wed, 1 Jun 2011 17:38:53 +0000 (UTC) Received: by qwc9 with SMTP id 9so27819qwc.13 for ; Wed, 01 Jun 2011 10:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RbO9F38iR5Luq+Akz8BDvn2ecVdZ7OZLvPJ+TtjQDDw=; b=XNc+m0lJYqycU00TIaiAPX5z8dvpfP6OnSFKKinqCdLqCZqGNfQM/KfrDBrTqqKeAZ Q9bRWr1exkr2D1QVJ/LeKJ4LLkHulsqCPoR/Rben5HLgTcWuWfINrv9bSFLUArCi2XsU Fhwb88m2r/5AN2Lo/KqI01T14kJvInUe7jb/w= 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=okAE5egtvaE24lzmfwHpkYBMFKnUHYHnzj9S6NkpsZOCbymhjzm+V1qW4p4etH+t86 5C1vu+oQeyebeoz0QpEHvB3kG9BOFYNl54xEsf+s35BY3/ESUeQt51J2qpj7Y/RH/Fgv UjooFukFAzRdw+MLn/6Vjewi7yNuBEAwVptSg= MIME-Version: 1.0 Received: by 10.229.67.218 with SMTP id s26mr5500598qci.40.1306948170089; Wed, 01 Jun 2011 10:09:30 -0700 (PDT) Received: by 10.229.86.133 with HTTP; Wed, 1 Jun 2011 10:09:30 -0700 (PDT) In-Reply-To: <20110601152713.GB51073@kta1c10.sesnet.soton.ac.uk> References: <20110601152713.GB51073@kta1c10.sesnet.soton.ac.uk> Date: Wed, 1 Jun 2011 21:09:30 +0400 Message-ID: From: Sergey Kandaurov To: "Klaus T. Aehlig" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: fdopendir prototype on 7.3-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:38:54 -0000 On 1 June 2011 19:27, Klaus T. Aehlig wrote: > > [Please CC me, as I'm not subscribed to this list] > > Hallo, > > while dealing with PR ports/157274 [1], I found that the following > program cause a segmentation fault on 7.3-RELEASE amd64, even though > my understanding of the man page of fdopendir(3) says it should not. > > #include > #include > #include > > int main(int argc, char **argv) { > =A0DIR *dirp; > =A0int fd; > > =A0fd =3D open(".", O_RDONLY); > =A0dirp =3D fdopendir(fd); > =A0(void) readdir(dirp); > > } > > Compiling gives the warning "assignment makes pointer from integer withou= t a cast" > refering to the line with the fdopendir call. Indeed, adding the prototyp= e > > extern DIR *fdopendir(int); > > right after the #include lines solves this problem. Is my understanding o= f the > man page that the above #include lines should suffice incorrect? Is this > problem known---or even fixed already? That is because 7.3 mistakenly misses the fdopendir() declaration in dirent.h, though it is the first release from 7.x that ought to support it. That was fixed in 7.3-STABLE past 7.3 release. There should be no problem for any release from 8.x branch. Also, the description from manpage only says that the function has appeared in 8.0, and there's nothing about 7.x. A segmentation fault is indeed due to missing declaration. Here gcc assumes that a return type of fdopendir() is int, and truncates a return value to sizeof(int). [On amd64 a pointer is 64-bit capable, int is 32-bit capable. I guess that 7.3 i386 does not fail here, though it prints the warning.] > > I have reports that indicate that this problem also seems to exist on 7.3= -RELEASE-p4 amd64 > and 8.1-RELEASE i386. The above program does not segfault on my 8.2-STABL= E amd64. Can you recheck it for 8.1? It should not be so. --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 17:59:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84766106564A for ; Wed, 1 Jun 2011 17:59:39 +0000 (UTC) (envelope-from aehlig@linta.de) Received: from linta.de (isilmar-3.linta.de [188.40.101.200]) by mx1.freebsd.org (Postfix) with ESMTP id C18B08FC08 for ; Wed, 1 Jun 2011 17:59:37 +0000 (UTC) Received: (qmail 1116 invoked by uid 10); 1 Jun 2011 17:59:35 -0000 Received: from kta1c10 by isilmar.linta.de with BSMTP; 1 Jun 2011 17:59:35 -0000 Received: by kta1c10.sesnet.soton.ac.uk (Postfix, from userid 1001) id C95223981D; Wed, 1 Jun 2011 18:59:26 +0100 (BST) Date: Wed, 1 Jun 2011 18:59:26 +0100 From: "Klaus T. Aehlig" To: Sergey Kandaurov Message-ID: <20110601175926.GB60894@kta1c10.sesnet.soton.ac.uk> References: <20110601152713.GB51073@kta1c10.sesnet.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 01 Jun 2011 18:10:29 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: fdopendir prototype on 7.3-RELEASE amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:59:39 -0000 > > I have reports that indicate that this problem also seems to exist on 7.3-RELEASE-p4 amd64 > > and 8.1-RELEASE i386. The above program does not segfault on my 8.2-STABLE amd64. > > Can you recheck it for 8.1? It should not be so. Yes, you're right. On 8.1 there is no problem. So that was probably a misunderstanding in a private mail with the submitter of the earlier mentioned PR. Thanks for your comments. BTW, are there plans to merge this header fix back into an errata for 7.3-RELEASE? I'm just curious, as, if not, more gnu software might run into a similar problem as the misc/findutils port. Best regards, Klaus From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 20:55:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id E0D07106566B; Wed, 1 Jun 2011 20:55:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Wed, 1 Jun 2011 16:55:49 -0400 User-Agent: KMail/1.6.2 References: <201105241356.45543.jkim@FreeBSD.org> <201105311616.31256.jkim@FreeBSD.org> <4DE5D0D1.1030903@FreeBSD.org> In-Reply-To: <4DE5D0D1.1030903@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106011655.51233.jkim@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:55:59 -0000 On Wednesday 01 June 2011 01:40 am, Andriy Gapon wrote: > on 31/05/2011 23:16 Jung-uk Kim said the following: > > On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote: > >> on 24/05/2011 20:56 Jung-uk Kim said the following: > >>> I think it's about time to enable invariant TSC timecounter on > >>> SMP by default. Please see the attached patch. It is also > >>> available from here: > >>> > >>> http://people.freebsd.org/~jkim/tsc_smp_test4.diff > >>> > >>> avg convinced me enough that it should be an opt-out feature > >>> going forward. :-) > >> > >> Not sure if I really did that. > >> My position is this: > >> - if we think that TSC is SMP-safe then it should have the best > >> priority > >> - we should do our best to auto-guess if TSC is SMP-safe > >> unless a user explicitly overrides that property (either via > >> explicit testing or by making guesses based on CPU model or etc) > > > > I am sorry if I misunderstood your intention. However, I added > > explicit boot-time TSC sanity check (to do our best to > > auto-guess) and I think TSC is fairly SMP-safe. Hence, I thought > > that it is about time for the change. > > In this case - yes. But I remember that you were thinking about > either improving or simplifying that check or both. Yes, it's still a work-in-progress. However, I thought it is good enough for 9.0 inclusion. BTW, the latest patch is here: http://people.freebsd.org/~jkim/tsc_smp_test5.diff FYI, the only meaningful change from the previous version is that it's limited to AMD single-socket Bulldozer platforms and Intel Core and later platforms. We may add more quirks if needed, of course. > >>> Comments? > >> > >> Perhaps I missed it, but I don't remember the "lowres" part of > >> the patch being discussed. > > > > No, it wasn't discussed with you. Do you see any problem with > > that code? > > I don't see any obvious problem, but I also don't understand > rationale of using smaller max_freq for the ncpus > 1 case. Consecutive RDTSCs used on a same CPU is always incremental but we cannot 100% guarantee that on two cores, even if TSC is derived from the same clock. I am hoping at least latency difference (I believe it's about few tens of cycles max) is "eaten up" by lowering resolution. It's not perfect but it's better than serialization (Linux) or heuristics (OpenSolaris), just because there are few rare conditions to consider. Thoughts? > Maybe these two logical changes should be done as two separate > commits. Will be done. Thanks, Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 1 22:07:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446D5106566C; Wed, 1 Jun 2011 22:07:17 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB418FC13; Wed, 1 Jun 2011 22:07:13 +0000 (UTC) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id A879BD1A608; Wed, 1 Jun 2011 23:47:33 +0200 (CEST) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 829FCD48031; Wed, 1 Jun 2011 23:47:24 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 6066133D08; Wed, 1 Jun 2011 21:47:23 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 43238A24A4; Wed, 1 Jun 2011 21:47:23 +0000 (UTC) Date: Wed, 1 Jun 2011 23:47:23 +0200 From: Jeremie Le Hen To: Kostik Belousov Message-ID: <20110601214723.GD53247@felucia.tataz.chchile.org> References: <20100919081406.GH6864@felucia.tataz.chchile.org> <20100919184146.GE2389@deviant.kiev.zoral.com.ua> <20100920162925.GL6864@felucia.tataz.chchile.org> <20100920192708.GK2389@deviant.kiev.zoral.com.ua> <20100927094651.GB57265@felucia.tataz.chchile.org> <20100927154457.GJ43070@deviant.kiev.zoral.com.ua> <20101005181804.GJ7536@felucia.tataz.chchile.org> <20101105213905.GT30284@felucia.tataz.chchile.org> <20101105190023.29e5d39d@kan.dnsalias.net> <20101106194702.GN2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <20101106194702.GN2392@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kan@freebsd.org, freebsd-hackers@freebsd.org, Jeremie Le Hen Subject: Re: compiling ports with SSP (was: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally)= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:07:17 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Kostik, Thanks to b.f., I've been reminded that this patch has yet to be committed :). As a reminder, here are the archive pointers to the discussion: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032549.html continued... http://lists.freebsd.org/pipermail/freebsd-hackers/2010-September/033028.html continued... http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033478.html On Sat, Nov 06, 2010 at 09:47:02PM +0200, Kostik Belousov wrote: > On Fri, Nov 05, 2010 at 07:00:23PM -0400, Alexander Kabaev wrote: > > On Fri, 5 Nov 2010 22:39:06 +0100 > > Jeremie Le Hen wrote: > > > > > Hi Kib, > > > > > > On Tue, Oct 05, 2010 at 08:18:04PM +0200, Jeremie Le Hen wrote: > > > > > > > > On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote: > > > > > Hardcoding /usr/lib as the path to the library in the script looks > > > > > problematic. For the buidlworld, you are linking resulting > > > > > binaries with the host library, instead of the > > > > > buildworld-produced one. For lib32, it makes non-working > > > > > combination of 32/64 bit. > > > > > > > > Sorry for the late reply, but I had to collect various evidences > > > > for my sayings and my development machine is reaaaaaaaaaaally slow. > > > > > > > > In fact it seems the toolchain built for buildworld contains a ld(1) > > > > binary which invariably bases lookups for libraries in ${WORLDTMP}, > > > > even in case of an absolute path. I have two evidences of this: > > > > - Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in > > > > /usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to > > > > use /usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a; > > > > - I also verified this with a hand-wrought opensnoop-like DTrace > > > > script. > > > > > > I dare to remind you about my patch. Do you have any other concerns? > > > > > > Thanks. > > > Regards, > > > -- > > > Jeremie Le Hen > > > > > > Humans are born free and equal. But some are more equal than others. > > > Coluche > > > > Hmm, I thought I did approve this patch already a long time agi, but > > since you asked: > > > > +.if defined(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) > > > > this should be: > > > > +.if defined(SHLIB_LDSCRIPT) > > > > ditto for all other similar places. Otherwise I do not think we should > > hold the patch in queue ans should unleash it on unsuspecting public. > > Also, I think the "DEBUG" lines should be removed. Sure, I'll do it in my next update. > You install the libxxx.ld and then symlink libxxx.so to libxxx.ld. > Why ? Would it be enough to install just the libxxx.so ? I just thought it would be less puzzling for users than noticing that libc.so is only a few hundred of ascii. I don't have a strong opinion about this though. > Otherwise, I think you need the similar > .if ${SHLIBDIR} == ${LIBDIR} > magic, that is better to be avoided. Can you explain a little bit more about this one please? I'm willing to post an updated patch for further review. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche --x+6KMIRAuhnl3hBn Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ld_ssp_nonshared.diff" diff -urNp src.orig/lib/libc/Makefile src/lib/libc/Makefile --- src.orig/lib/libc/Makefile 2010-08-01 12:35:01.000000000 +0000 +++ src/lib/libc/Makefile 2010-09-21 23:40:51.000000000 +0000 @@ -20,6 +20,7 @@ CFLAGS+=-DNLS CLEANFILES+=tags INSTALL_PIC_ARCHIVE= PRECIOUSLIB= +SHLIB_LDSCRIPT=libc.ldscript # # Only link with static libgcc.a (no libgcc_eh.a). diff -urNp src.orig/lib/libc/libc.ldscript src/lib/libc/libc.ldscript --- src.orig/lib/libc/libc.ldscript 1970-01-01 00:00:00.000000000 +0000 +++ src/lib/libc/libc.ldscript 2010-09-24 21:56:57.000000000 +0000 @@ -0,0 +1,2 @@ +/* $FreeBSD */ +GROUP ( @@SHLIB@@ /usr/lib/libssp_nonshared.a ) diff -urNp src.orig/share/mk/bsd.lib.mk src/share/mk/bsd.lib.mk --- src.orig/share/mk/bsd.lib.mk 2010-07-30 15:25:57.000000000 +0000 +++ src/share/mk/bsd.lib.mk 2010-09-24 22:01:04.000000000 +0000 @@ -293,9 +293,19 @@ _libinstall: ${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \ ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR} .if defined(SHLIB_LINK) +.if defined(SHLIB_LDSCRIPT) && !empty(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) + @echo "DEBUG: install lib${LIB}.ld to ${DESTDIR}${LIBDIR}/${SHLIB_LINK}" + sed -e 's,@@SHLIB@@,${SHLIBDIR}/${SHLIB_NAME},g' \ + ${.CURDIR}/${SHLIB_LDSCRIPT} > lib${LIB}.ld + ${INSTALL} -S -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ + ${_INSTALLFLAGS} lib${LIB}.ld ${DESTDIR}${LIBDIR} + ln -sf lib${LIB}.ld ${DESTDIR}${LIBDIR}/${SHLIB_LINK} +.else .if ${SHLIBDIR} == ${LIBDIR} + @echo "DEBUG: symlink (1) ${DESTDIR}${LIBDIR}/${SHLIB_LINK} to ${SHLIB_NAME}" ln -fs ${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} .else + @echo "DEBUG: symlink (2) ${DESTDIR}${LIBDIR}/${SHLIB_LINK} to ${_SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_NAME}" ln -fs ${_SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_NAME} \ ${DESTDIR}${LIBDIR}/${SHLIB_LINK} .if exists(${DESTDIR}${LIBDIR}/${SHLIB_NAME}) @@ -303,8 +313,9 @@ _libinstall: rm -f ${DESTDIR}${LIBDIR}/${SHLIB_NAME} .endif .endif -.endif -.endif +.endif # SHLIB_LDSCRIPT +.endif # SHLIB_LINK +.endif # SHIB_NAME .if defined(INSTALL_PIC_ARCHIVE) && defined(LIB) && !empty(LIB) && ${MK_TOOLCHAIN} != "no" ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ ${_INSTALLFLAGS} lib${LIB}_pic.a ${DESTDIR}${LIBDIR} @@ -372,6 +383,9 @@ clean: .endif .if defined(SHLIB_NAME) .if defined(SHLIB_LINK) +.if defined(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) + rm -f lib${LIB}.ld +.endif rm -f ${SHLIB_LINK} .endif .if defined(LIB) && !empty(LIB) --x+6KMIRAuhnl3hBn-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 2 10:06:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787691065673 for ; Thu, 2 Jun 2011 10:06:36 +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 1678E8FC16 for ; Thu, 2 Jun 2011 10:06:35 +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 p52A6JNl069996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 13:06:19 +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 p52A6J8Q005910; Thu, 2 Jun 2011 13:06:19 +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 p52A6H5J005909; Thu, 2 Jun 2011 13:06:17 +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: Thu, 2 Jun 2011 13:06:17 +0300 From: Kostik Belousov To: Jeremie Le Hen Message-ID: <20110602100617.GF48734@deviant.kiev.zoral.com.ua> References: <20100919184146.GE2389@deviant.kiev.zoral.com.ua> <20100920162925.GL6864@felucia.tataz.chchile.org> <20100920192708.GK2389@deviant.kiev.zoral.com.ua> <20100927094651.GB57265@felucia.tataz.chchile.org> <20100927154457.GJ43070@deviant.kiev.zoral.com.ua> <20101005181804.GJ7536@felucia.tataz.chchile.org> <20101105213905.GT30284@felucia.tataz.chchile.org> <20101105190023.29e5d39d@kan.dnsalias.net> <20101106194702.GN2392@deviant.kiev.zoral.com.ua> <20110601214723.GD53247@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OItkzkEMg3BnaIAB" Content-Disposition: inline In-Reply-To: <20110601214723.GD53247@felucia.tataz.chchile.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: kan@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: compiling ports with SSP (was: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally)= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 10:06:36 -0000 --OItkzkEMg3BnaIAB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 01, 2011 at 11:47:23PM +0200, Jeremie Le Hen wrote: > Hi Kostik, >=20 > Thanks to b.f., I've been reminded that this patch has yet to be > committed :). >=20 > As a reminder, here are the archive pointers to the discussion: > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032549.html > continued... > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-September/033028.= html > continued... > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033478.h= tml >=20 > On Sat, Nov 06, 2010 at 09:47:02PM +0200, Kostik Belousov wrote: > > On Fri, Nov 05, 2010 at 07:00:23PM -0400, Alexander Kabaev wrote: > > > On Fri, 5 Nov 2010 22:39:06 +0100 > > > Jeremie Le Hen wrote: > > >=20 > > > > Hi Kib, > > > >=20 > > > > On Tue, Oct 05, 2010 at 08:18:04PM +0200, Jeremie Le Hen wrote: > > > > >=20 > > > > > On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote: > > > > > > Hardcoding /usr/lib as the path to the library in the script lo= oks > > > > > > problematic. For the buidlworld, you are linking resulting > > > > > > binaries with the host library, instead of the > > > > > > buildworld-produced one. For lib32, it makes non-working > > > > > > combination of 32/64 bit. > > > > >=20 > > > > > Sorry for the late reply, but I had to collect various evidences > > > > > for my sayings and my development machine is reaaaaaaaaaaally slo= w. > > > > >=20 > > > > > In fact it seems the toolchain built for buildworld contains a ld= (1) > > > > > binary which invariably bases lookups for libraries in ${WORLDTMP= }, > > > > > even in case of an absolute path. I have two evidences of this: > > > > > - Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in > > > > > /usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to > > > > > use /usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonsh= ared.a; > > > > > - I also verified this with a hand-wrought opensnoop-like DTrace > > > > > script. > > > >=20 > > > > I dare to remind you about my patch. Do you have any other concern= s? > > > >=20 > > > > Thanks. > > > > Regards, > > > > --=20 > > > > Jeremie Le Hen > > > >=20 > > > > Humans are born free and equal. But some are more equal than other= s. > > > > Coluche > > >=20 > > > Hmm, I thought I did approve this patch already a long time agi, but > > > since you asked: > > >=20 > > > +.if defined(SHLIB_LDSCRIPT) && exists(${.CURDIR}/${SHLIB_LDSCRIPT}) > > >=20 > > > this should be: > > >=20 > > > +.if defined(SHLIB_LDSCRIPT) > > >=20 > > > ditto for all other similar places. Otherwise I do not think we should > > > hold the patch in queue ans should unleash it on unsuspecting public. > >=20 > > Also, I think the "DEBUG" lines should be removed. >=20 > Sure, I'll do it in my next update. >=20 > > You install the libxxx.ld and then symlink libxxx.so to libxxx.ld. > > Why ? Would it be enough to install just the libxxx.so ? >=20 > I just thought it would be less puzzling for users than noticing that > libc.so is only a few hundred of ascii. I don't have a strong opinion > about this though. I prefer to not have a symlink. >=20 > > Otherwise, I think you need the similar > > .if ${SHLIBDIR} =3D=3D ${LIBDIR} > > magic, that is better to be avoided. >=20 > Can you explain a little bit more about this one please? I'm willing to > post an updated patch for further review.=20 I think this comment was somehow related to the fact that make install does not work from the buildenv, or something similar. It was too long time ago for me to remember details. Also, I remember there was a concern about linker script not being installed in the cross-build environment during buildworld, or something close to what I stated. Was it resolved ? [I pinged you some time ago, you did not responded]. --OItkzkEMg3BnaIAB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3nYJkACgkQC3+MBN1Mb4h3WQCbBW5R7cvmvklT21YWMArLmH8/ F+gAoM3HrLgMK7Z62SzSBTiBl1d67QF1 =hdXj -----END PGP SIGNATURE----- --OItkzkEMg3BnaIAB-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 2 14:47:11 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E4E5106564A for ; Thu, 2 Jun 2011 14:47:11 +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 57A848FC17 for ; Thu, 2 Jun 2011 14:47:11 +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 0E89A46B38; Thu, 2 Jun 2011 10:47:11 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0EC28A02B; Thu, 2 Jun 2011 10:47:10 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 2 Jun 2011 10:34:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106021034.16366.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 02 Jun 2011 10:47:10 -0400 (EDT) Cc: Dmitry Krivenok Subject: Re: Bug in ksched_setscheduler? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:47:11 -0000 On Wednesday, June 01, 2011 12:42:42 pm Dmitry Krivenok wrote: > Hello Hackers, > I think I found a bug in ksched_setscheduler() function. > > 209 rtp.prio = p4prio_to_rtpprio(param->sched_priority); > > Shouldn't we use p4prio_to_tsprio instead of p4prio_to_rtpprio at the line 209? > This macro is defined but never used in kernel code: > > $ grep -r 'p4prio_to_tsprio' /usr/src/sys/ > /usr/src/sys/kern/ksched.c:#define p4prio_to_tsprio(P) > ((PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) - (P)) > $ > > Is it a real bug or just my misunderstanding of something? I think it is a real bug. Can you come up with a test case to show it? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 2 16:51:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7AF106564A for ; Thu, 2 Jun 2011 16:51:08 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: from email.aon.at (nat-warsl417-02.aon.at [195.3.96.120]) by mx1.freebsd.org (Postfix) with ESMTP id D533D8FC0A for ; Thu, 2 Jun 2011 16:51:07 +0000 (UTC) Received: (qmail 10524 invoked from network); 2 Jun 2011 16:24:25 -0000 Received: from unknown (HELO email.aon.at) ([172.18.1.199]) (envelope-sender ) by fallback43.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 2 Jun 2011 16:24:25 -0000 Received: (qmail 8542 invoked from network); 2 Jun 2011 16:24:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL605.highway.telekom.at X-Spam-Level: Received: from 188-23-43-10.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([188.23.43.10]) (envelope-sender ) by smarthub90.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 2 Jun 2011 16:24:22 -0000 Received: from atpcdvvc.xyzzy (atpcdvvc.xyzzy [IPv6:fec0:0:0:4d42::84]) by gandalf.xyzzy (8.14.4/8.14.4) with ESMTP id p52GOLTA022972 for ; Thu, 2 Jun 2011 18:24:22 +0200 (CEST) (envelope-from la5lbtyi@aon.at) Message-ID: <4DE7B935.9040004@aon.at> Date: Thu, 02 Jun 2011 18:24:21 +0200 From: Martin Birgmeier User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110522 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: some strange constructs (bugs?) in if_tun.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:51:08 -0000 I am looking at net/if_tun.c, function tunwrite() (this is 7.4, but 8.2 is nearly the same): There is a local variable "error" which is initialized to zero and then seemingly never changed, until it is used as a return value if m_uiotombuf() fails: ... int error = 0; ... if ((m = m_uiotombuf(uio, M_DONTWAIT, 0, 0, M_PKTHDR)) == NULL) { ifp->if_ierrors++; return (error); } ... a little further down, we see ... if (m->m_len < sizeof(family) && (m = m_pullup(m, sizeof(family))) == NULL) return (ENOBUFS); ... As far as I can see, the first return amounts to "drop the packet, but don't tell anything about it", whereas the second amounts to "drop the packet and say it's due to ENOBUFS". However, the first case is much more like ENOBUFS, so shouldn't we simply say "return (ENOBUFS)" there and remove the "error" variable altogether? There seem to be other functions in if_tun.c with a similar strange usage of an "error" variable. Regards, Martin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 2 23:54:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A417106564A for ; Thu, 2 Jun 2011 23:54:10 +0000 (UTC) (envelope-from mashtizadeh@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 5CF5E8FC17 for ; Thu, 2 Jun 2011 23:54:10 +0000 (UTC) Received: by qwc9 with SMTP id 9so842412qwc.13 for ; Thu, 02 Jun 2011 16:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=GsW2w8DpHc2FCUKwJ+QSH9wbFXv3e1OHqNfrZgUj3VQ=; b=uhWRI/PPtUzfaR6pqqZRguX0TeOU+vlXAbqqG1vdUNpgN9Qpplhrycjz5KaPjcdvGz N/BmnxmyZT92dPuoG2HMrF7cAMbrpgkKMGgV6gUJhHMYVUw/YKBxmVW8JhzOL5Ef+ZLd 3HvxKtjEkjUy8uGISUbNxrs0TG8GO5JwbrezY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MxYWOZs4EFPTfoL7DL2lRK3iB/sT7Z2D9WeA7JneYtd+znlyFaBH/mfFr51CygsORA AgwelNFWUDSBHCax2InKQVLD7z25zVhfWe3GXM7gGlHzXxqKh9dq+tO/Y7Vy0ckSfBTl T1t1agj3j+eLfM2eMRPJyrZyZXxg7WK3ymeAQ= MIME-Version: 1.0 Received: by 10.229.137.132 with SMTP id w4mr1009798qct.88.1307057044380; Thu, 02 Jun 2011 16:24:04 -0700 (PDT) Received: by 10.229.10.10 with HTTP; Thu, 2 Jun 2011 16:24:04 -0700 (PDT) Date: Thu, 2 Jun 2011 16:24:04 -0700 Message-ID: From: Ali Mashtizadeh To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: USENIX BoF X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 23:54:10 -0000 Hello Everyone, I was wondering if anyone is planning to put together a FreeBSD BoF at USENIX this year? Thanks, -- Ali Mashtizadeh From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 3 06:03:59 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C6B6106564A; Fri, 3 Jun 2011 06:03:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 851C68FC15; Fri, 3 Jun 2011 06:03:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA07176; Fri, 03 Jun 2011 09:03:56 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QSNUC-0000bw-HZ; Fri, 03 Jun 2011 09:03:56 +0300 Message-ID: <4DE8794B.60100@FreeBSD.org> Date: Fri, 03 Jun 2011 09:03:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jung-uk Kim References: <201105241356.45543.jkim@FreeBSD.org> <201105311616.31256.jkim@FreeBSD.org> <4DE5D0D1.1030903@FreeBSD.org> <201106011655.51233.jkim@FreeBSD.org> In-Reply-To: <201106011655.51233.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 06:03:59 -0000 on 01/06/2011 23:55 Jung-uk Kim said the following: > Yes, it's still a work-in-progress. However, I thought it is good > enough for 9.0 inclusion. BTW, the latest patch is here: > > http://people.freebsd.org/~jkim/tsc_smp_test5.diff > > FYI, the only meaningful change from the previous version is that it's > limited to AMD single-socket Bulldozer platforms and Intel Core and > later platforms. We may add more quirks if needed, of course. Looks good, but I think that the check is a little bit unfair to AMD Family 10h+ CPUs. Although TSCs in those CPUs are per core I've never seen them drift out of sync if they started with the same value. [snip] > Consecutive RDTSCs used on a same CPU is always incremental but we > cannot 100% guarantee that on two cores, even if TSC is derived from > the same clock. I am hoping at least latency difference (I believe > it's about few tens of cycles max) is "eaten up" by lowering > resolution. It's not perfect but it's better than serialization > (Linux) or heuristics (OpenSolaris), just because there are few rare > conditions to consider. Thoughts? I am still not sure which case this code should solve. Thread T1: x1 = rdtsc() on CPU1; Thread T1: x2 = rdtsc() on CPU2; x2 < x1 ? Or? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 3 12:04:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9CF31065680; Fri, 3 Jun 2011 12:04:24 +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 B0B5F8FC1C; Fri, 3 Jun 2011 12:04:24 +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 68E1E46B0D; Fri, 3 Jun 2011 08:04:24 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 03F978A027; Fri, 3 Jun 2011 08:04:24 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 3 Jun 2011 07:50:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201105241356.45543.jkim@FreeBSD.org> <201106011655.51233.jkim@FreeBSD.org> <4DE8794B.60100@FreeBSD.org> In-Reply-To: <4DE8794B.60100@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106030750.37264.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 03 Jun 2011 08:04:24 -0400 (EDT) Cc: Jung-uk Kim , Andriy Gapon Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 12:04:24 -0000 On Friday, June 03, 2011 2:03:55 am Andriy Gapon wrote: > > Consecutive RDTSCs used on a same CPU is always incremental but we > > cannot 100% guarantee that on two cores, even if TSC is derived from > > the same clock. I am hoping at least latency difference (I believe > > it's about few tens of cycles max) is "eaten up" by lowering > > resolution. It's not perfect but it's better than serialization > > (Linux) or heuristics (OpenSolaris), just because there are few rare > > conditions to consider. Thoughts? > > I am still not sure which case this code should solve. > > Thread T1: x1 = rdtsc() on CPU1; > Thread T1: x2 = rdtsc() on CPU2; > x2 < x1 ? > Or? Yes, that can happen. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 3 12:04:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 751DD1065690; Fri, 3 Jun 2011 12:04:25 +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 349F28FC16; Fri, 3 Jun 2011 12:04:25 +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 C849546B2C; Fri, 3 Jun 2011 08:04:24 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 657208A02A; Fri, 3 Jun 2011 08:04:24 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 3 Jun 2011 08:04:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DE7B935.9040004@aon.at> In-Reply-To: <4DE7B935.9040004@aon.at> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106030804.23084.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 03 Jun 2011 08:04:24 -0400 (EDT) Cc: glebius@freebsd.org, Martin Birgmeier Subject: Re: some strange constructs (bugs?) in if_tun.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 12:04:25 -0000 On Thursday, June 02, 2011 12:24:21 pm Martin Birgmeier wrote: > I am looking at net/if_tun.c, function tunwrite() (this is 7.4, but 8.2 > is nearly the same): > > There is a local variable "error" which is initialized to zero and then > seemingly never changed, until it is used as a return value if > m_uiotombuf() fails: > > ... > int error = 0; > ... > if ((m = m_uiotombuf(uio, M_DONTWAIT, 0, 0, M_PKTHDR)) == NULL) { > ifp->if_ierrors++; > return (error); > } > ... > a little further down, we see > ... > if (m->m_len < sizeof(family) && > (m = m_pullup(m, sizeof(family))) == NULL) > return (ENOBUFS); > ... > > As far as I can see, the first return amounts to "drop the packet, but > don't tell anything about it", whereas the second amounts to "drop the > packet and say it's due to ENOBUFS". > > However, the first case is much more like ENOBUFS, so shouldn't we > simply say "return (ENOBUFS)" there and remove the "error" variable > altogether? Yes, this error seems to have been introduced in 137101 when if_tun was switched to use m_uiotombuf() rather than a home-rolled version. tap(4) had the same bug, but it was fixed in 163986. I think this patch should be ok for tun(4): Index: if_tun.c =================================================================== --- if_tun.c (revision 222565) +++ if_tun.c (working copy) @@ -126,7 +126,7 @@ static void tunclone(void *arg, struct ucred *cred int namelen, struct cdev **dev); static void tuncreate(const char *name, struct cdev *dev); static int tunifioctl(struct ifnet *, u_long, caddr_t); -static int tuninit(struct ifnet *); +static void tuninit(struct ifnet *); static int tunmodevent(module_t, int, void *); static int tunoutput(struct ifnet *, struct mbuf *, struct sockaddr *, struct route *ro); @@ -494,14 +494,13 @@ tunclose(struct cdev *dev, int foo, int bar, struc return (0); } -static int +static void tuninit(struct ifnet *ifp) { struct tun_softc *tp = ifp->if_softc; #ifdef INET struct ifaddr *ifa; #endif - int error = 0; TUNDEBUG(ifp, "tuninit\n"); @@ -528,7 +527,6 @@ tuninit(struct ifnet *ifp) if_addr_runlock(ifp); #endif mtx_unlock(&tp->tun_mtx); - return (error); } /* @@ -552,12 +550,12 @@ tunifioctl(struct ifnet *ifp, u_long cmd, caddr_t mtx_unlock(&tp->tun_mtx); break; case SIOCSIFADDR: - error = tuninit(ifp); - TUNDEBUG(ifp, "address set, error=%d\n", error); + tuninit(ifp); + TUNDEBUG(ifp, "address set\n"); break; case SIOCSIFDSTADDR: - error = tuninit(ifp); - TUNDEBUG(ifp, "destination address set, error=%d\n", error); + tuninit(ifp); + TUNDEBUG(ifp, "destination address set\n"); break; case SIOCSIFMTU: ifp->if_mtu = ifr->ifr_mtu; @@ -857,7 +855,6 @@ tunwrite(struct cdev *dev, struct uio *uio, int fl struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); struct mbuf *m; - int error = 0; uint32_t family; int isr; @@ -877,7 +874,7 @@ tunwrite(struct cdev *dev, struct uio *uio, int fl if ((m = m_uiotombuf(uio, M_DONTWAIT, 0, 0, M_PKTHDR)) == NULL) { ifp->if_ierrors++; - return (error); + return (ENOBUFS); } m->m_pkthdr.rcvif = ifp; -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 3 12:12:56 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A19106564A; Fri, 3 Jun 2011 12:12:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 633498FC08; Fri, 3 Jun 2011 12:12:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13938; Fri, 03 Jun 2011 15:12:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QSTFF-0000sS-AG; Fri, 03 Jun 2011 15:12:53 +0300 Message-ID: <4DE8CFC4.8070602@FreeBSD.org> Date: Fri, 03 Jun 2011 15:12:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201105241356.45543.jkim@FreeBSD.org> <201106011655.51233.jkim@FreeBSD.org> <4DE8794B.60100@FreeBSD.org> <201106030750.37264.jhb@freebsd.org> In-Reply-To: <201106030750.37264.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Jung-uk Kim Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 12:12:56 -0000 on 03/06/2011 14:50 John Baldwin said the following: > On Friday, June 03, 2011 2:03:55 am Andriy Gapon wrote: >>> Consecutive RDTSCs used on a same CPU is always incremental but we >>> cannot 100% guarantee that on two cores, even if TSC is derived from >>> the same clock. I am hoping at least latency difference (I believe >>> it's about few tens of cycles max) is "eaten up" by lowering >>> resolution. It's not perfect but it's better than serialization >>> (Linux) or heuristics (OpenSolaris), just because there are few rare >>> conditions to consider. Thoughts? >> >> I am still not sure which case this code should solve. >> >> Thread T1: x1 = rdtsc() on CPU1; >> Thread T1: x2 = rdtsc() on CPU2; >> x2 < x1 ? >> Or? > > Yes, that can happen. Well, I think that the test based on smp_rendezvous should ensure that difference in TSC values is "small enough"; that is, I expect that cost (in TSC ticks) of migrating a thread from CPU to CPU should be larger than that difference if the test was passed. Is this an unreasonable expectation? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 3 13:14:49 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 683B2106566C; Fri, 3 Jun 2011 13:14:49 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id DCAF18FC08; Fri, 3 Jun 2011 13:14:48 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p53DEk6v017449; Fri, 3 Jun 2011 17:14:46 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p53DEkPo017448; Fri, 3 Jun 2011 17:14:46 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 3 Jun 2011 17:14:46 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20110603131446.GF12033@glebius.int.ru> References: <4DE7B935.9040004@aon.at> <201106030804.23084.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201106030804.23084.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, Martin Birgmeier Subject: Re: some strange constructs (bugs?) in if_tun.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 13:14:49 -0000 On Fri, Jun 03, 2011 at 08:04:22AM -0400, John Baldwin wrote: J> On Thursday, June 02, 2011 12:24:21 pm Martin Birgmeier wrote: J> > I am looking at net/if_tun.c, function tunwrite() (this is 7.4, but 8.2 J> > is nearly the same): J> > J> > There is a local variable "error" which is initialized to zero and then J> > seemingly never changed, until it is used as a return value if J> > m_uiotombuf() fails: J> > J> > ... J> > int error = 0; J> > ... J> > if ((m = m_uiotombuf(uio, M_DONTWAIT, 0, 0, M_PKTHDR)) == NULL) { J> > ifp->if_ierrors++; J> > return (error); J> > } J> > ... J> > a little further down, we see J> > ... J> > if (m->m_len < sizeof(family) && J> > (m = m_pullup(m, sizeof(family))) == NULL) J> > return (ENOBUFS); J> > ... J> > J> > As far as I can see, the first return amounts to "drop the packet, but J> > don't tell anything about it", whereas the second amounts to "drop the J> > packet and say it's due to ENOBUFS". J> > J> > However, the first case is much more like ENOBUFS, so shouldn't we J> > simply say "return (ENOBUFS)" there and remove the "error" variable J> > altogether? J> J> Yes, this error seems to have been introduced in 137101 when if_tun was J> switched to use m_uiotombuf() rather than a home-rolled version. tap(4) had J> the same bug, but it was fixed in 163986. I think this patch should be ok for J> tun(4): J> J> Index: if_tun.c J> =================================================================== J> --- if_tun.c (revision 222565) J> +++ if_tun.c (working copy) J> @@ -126,7 +126,7 @@ static void tunclone(void *arg, struct ucred *cred J> int namelen, struct cdev **dev); J> static void tuncreate(const char *name, struct cdev *dev); J> static int tunifioctl(struct ifnet *, u_long, caddr_t); J> -static int tuninit(struct ifnet *); J> +static void tuninit(struct ifnet *); J> static int tunmodevent(module_t, int, void *); J> static int tunoutput(struct ifnet *, struct mbuf *, struct sockaddr *, J> struct route *ro); J> @@ -494,14 +494,13 @@ tunclose(struct cdev *dev, int foo, int bar, struc J> return (0); J> } J> J> -static int J> +static void J> tuninit(struct ifnet *ifp) J> { J> struct tun_softc *tp = ifp->if_softc; J> #ifdef INET J> struct ifaddr *ifa; J> #endif J> - int error = 0; J> J> TUNDEBUG(ifp, "tuninit\n"); J> J> @@ -528,7 +527,6 @@ tuninit(struct ifnet *ifp) J> if_addr_runlock(ifp); J> #endif J> mtx_unlock(&tp->tun_mtx); J> - return (error); J> } J> J> /* J> @@ -552,12 +550,12 @@ tunifioctl(struct ifnet *ifp, u_long cmd, caddr_t J> mtx_unlock(&tp->tun_mtx); J> break; J> case SIOCSIFADDR: J> - error = tuninit(ifp); J> - TUNDEBUG(ifp, "address set, error=%d\n", error); J> + tuninit(ifp); J> + TUNDEBUG(ifp, "address set\n"); J> break; J> case SIOCSIFDSTADDR: J> - error = tuninit(ifp); J> - TUNDEBUG(ifp, "destination address set, error=%d\n", error); J> + tuninit(ifp); J> + TUNDEBUG(ifp, "destination address set\n"); J> break; J> case SIOCSIFMTU: J> ifp->if_mtu = ifr->ifr_mtu; J> @@ -857,7 +855,6 @@ tunwrite(struct cdev *dev, struct uio *uio, int fl J> struct tun_softc *tp = dev->si_drv1; J> struct ifnet *ifp = TUN2IFP(tp); J> struct mbuf *m; J> - int error = 0; J> uint32_t family; J> int isr; J> J> @@ -877,7 +874,7 @@ tunwrite(struct cdev *dev, struct uio *uio, int fl J> J> if ((m = m_uiotombuf(uio, M_DONTWAIT, 0, 0, M_PKTHDR)) == NULL) { J> ifp->if_ierrors++; J> - return (error); J> + return (ENOBUFS); J> } J> J> m->m_pkthdr.rcvif = ifp; Yes, that would be correct. Sorry, my bug :( -- Totus tuus, Glebius. From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 3 16:48:46 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678BC106566C; Fri, 3 Jun 2011 16:48:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 224AE8FC12; Fri, 3 Jun 2011 16:48:45 +0000 (UTC) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id p53GTB27063451; Fri, 3 Jun 2011 12:29:13 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 3 Jun 2011 12:28:34 -0400 User-Agent: KMail/1.6.2 References: <201105241356.45543.jkim@FreeBSD.org> <201106011655.51233.jkim@FreeBSD.org> <4DE8794B.60100@FreeBSD.org> In-Reply-To: <4DE8794B.60100@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106031228.58113.jkim@FreeBSD.org> X-Virus-Scanned: clamav-milter 0.95.3 at anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-hackers@FreeBSD.org Subject: Re: [RFC] Enabling invariant TSC timecounter on SMP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:48:46 -0000 On Friday 03 June 2011 02:03 am, Andriy Gapon wrote: > on 01/06/2011 23:55 Jung-uk Kim said the following: > > Yes, it's still a work-in-progress. However, I thought it is > > good enough for 9.0 inclusion. BTW, the latest patch is here: > > > > http://people.freebsd.org/~jkim/tsc_smp_test5.diff > > > > FYI, the only meaningful change from the previous version is that > > it's limited to AMD single-socket Bulldozer platforms and Intel > > Core and later platforms. We may add more quirks if needed, of > > course. > > Looks good, but I think that the check is a little bit unfair to > AMD Family 10h+ CPUs. Although TSCs in those CPUs are per core > I've never seen them drift out of sync if they started with the > same value. [snip] Unlike Intel, AMD did not guarantee "all TSCs reset to zero with RESET IPI" before Bulldozer[1]. In fact, I tried to measure deltas between cores when I started hacking on it using some crude heuristics, somewhat like the OpenSolaris hack[2]. Basically, a dual-core AMD Family 10h processor showed noticeably larger deltas than *two* dual-core Intel Woodcrest Xeons'. Jung-uk Kim [1] I couldn't find any clues from their publicly available documents whether they will implement (or need) additional mechanism for multi-socket Bulldozer platforms. It only says something like "all TSCs are synchronized with a clock source in north bridge". We will see when AMD Valencia & Interlagos are available. :-) [2] Unfortunately, there is no way to accurately measure it with current generation hardware. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 4 09:40:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02320106566B; Sat, 4 Jun 2011 09:40:08 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0BA28FC16; Sat, 4 Jun 2011 09:40:08 +0000 (UTC) Received: by iyj12 with SMTP id 12so3070998iyj.13 for ; Sat, 04 Jun 2011 02:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=NZ8BefQ5MN3KyIT7SERMxH0qLxu5uoxJnC20HfPhIbI=; b=rUCR4xdoCD/JTQRVLA+33Jt+poHIufte2jYn7REJIi3c1i0t40tuxCuBONZUaj04Iz yNgDFk+ZWMLWSHxy5oJZHs59lKy9wP6tKngE7u1qHQa0y15cSfGcjAcZpDnD1zQFrkgq aKT+FfjvT96cu9RaE9aj/ejptBQO8NQm+ngoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tp62KUVo1xLEnVRrS2ORYL9d5ImzdorToWknDrJXxDepZodGvXlaq0TnTs3SK7N/Gi kxSVJo7wbbOfEqkf6f7eWmQyl+GQMaOobNv9Te9YTJirupXxYlsEe39WA5q4j84Bbl59 05cSzsQ/+NfP65w/bEKocdqreV1mG5/rjXkPM= MIME-Version: 1.0 Received: by 10.231.67.74 with SMTP id q10mr3995408ibi.25.1307178614496; Sat, 04 Jun 2011 02:10:14 -0700 (PDT) Received: by 10.231.35.75 with HTTP; Sat, 4 Jun 2011 02:10:14 -0700 (PDT) Date: Sat, 4 Jun 2011 17:10:14 +0800 Message-ID: From: Buganini To: FreeBSD Current , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: [RFC] rcexecr: rcorder in parallel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 09:40:09 -0000 https://github.com/buganini/rcexecr Currently it is able to determine the exec/wait order There are something I haven't digged in deeply in the "self modification" part. patches/ideas are welcome. Regards, Buganini From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 4 12:07:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBFF51065670; Sat, 4 Jun 2011 12:07:28 +0000 (UTC) (envelope-from julien.laffaye@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 75A6B8FC17; Sat, 4 Jun 2011 12:07:28 +0000 (UTC) Received: by ywf7 with SMTP id 7so1618568ywf.13 for ; Sat, 04 Jun 2011 05:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WinnB7iO3GHWBHYPTP9fto4INdwbKxyadCxq3FDN0dU=; b=KjLiYsmrm8VoeVKDaUGL4MYYvxLvh/s/KvfGroADdwl7jKKnbrSOWfIac7XB/FT4Kv 675ip+6rOUsNwW51kv30bzBFu4d6vuIfmintiTvQYCX38c+AoLRBIHbIjHR+Zmy+ttB3 E0P3XLfgok07JP9Aqs+Kprt3LKyD3irkbdibc= 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; b=S0XUBIngcq3k1I5uh8kHaY/YZPjIInV/orLH942JCfmwU1DvGWny4Btp7kHQFiTh8j MjWN4s9QYyP/96oBiTDKcXAbUyhw7+zoejuG+M67UTKcxA/GixMO0jJVl6MY+YBTEwKo f5BZdAZObI6bs0pwP9VVuMkpraONkTmMCdsMM= MIME-Version: 1.0 Received: by 10.236.77.34 with SMTP id c22mr3799763yhe.120.1307187938140; Sat, 04 Jun 2011 04:45:38 -0700 (PDT) Sender: julien.laffaye@gmail.com Received: by 10.236.108.171 with HTTP; Sat, 4 Jun 2011 04:45:37 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Jun 2011 12:45:37 +0100 X-Google-Sender-Auth: au0E_jqemx_eHg9qRHBz2VolgLA Message-ID: From: Julien Laffaye To: Buganini Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, FreeBSD Current Subject: Re: [RFC] rcexecr: rcorder in parallel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 12:07:28 -0000 On Sat, Jun 4, 2011 at 10:10 AM, Buganini wrote: > https://github.com/buganini/rcexecr > > Currently it is able to determine the exec/wait order > > There are something I haven't digged in deeply in the "self modification" part. > > patches/ideas are welcome. Hello, Thanks for doing that! You should use kqueue(2) instead of waitpid(2) so that you can efficiently monitor a pool of processes. See pwait(1) for an example. Regards, Julien From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 4 12:27:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F088B1065674; Sat, 4 Jun 2011 12:27:04 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 9109A8FC1A; Sat, 4 Jun 2011 12:27:04 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 853E71DD789; Sat, 4 Jun 2011 14:27:03 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 796E6173E4; Sat, 4 Jun 2011 14:27:03 +0200 (CEST) Date: Sat, 4 Jun 2011 14:27:03 +0200 From: Jilles Tjoelker To: Julien Laffaye Message-ID: <20110604122703.GB33796@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Buganini , FreeBSD Current Subject: Re: [RFC] rcexecr: rcorder in parallel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 12:27:05 -0000 On Sat, Jun 04, 2011 at 12:45:37PM +0100, Julien Laffaye wrote: > On Sat, Jun 4, 2011 at 10:10 AM, Buganini wrote: > > https://github.com/buganini/rcexecr > > Currently it is able to determine the exec/wait order > > There are something I haven't digged in deeply in the "self > > modification" part. > > patches/ideas are welcome. > Thanks for doing that! Yes. > You should use kqueue(2) instead of waitpid(2) so that you can > efficiently monitor a pool of processes. > See pwait(1) for an example. Hmm, I don't think kqueue() should be used here. Its main advantage is that it works regardless of parent-child relationships, but that advantage is not relevant here. On the other hand, waitpid() is still necessary to get rid of the zombies. Furthermore, waitpid() is standard while kqueue() is not, and I think non-standard interfaces should only be used if they provide a real benefit above standard interfaces. The current approach with waitpid() for specific processes should be good enough for a proof of concept. It will keep zombies longer than necessary, particularly for things that are not explicitly depended on. To avoid this, use waitpid(-1, ...) and maintain more tracking for processes that have already terminated. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 4 18:22:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3FE9106566C for ; Sat, 4 Jun 2011 18:22:10 +0000 (UTC) (envelope-from mashtizadeh@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 718538FC0A for ; Sat, 4 Jun 2011 18:22:10 +0000 (UTC) Received: by qyk27 with SMTP id 27so1647416qyk.13 for ; Sat, 04 Jun 2011 11:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=e0Fqmm70OozrhKN95Yk4plbaIDg7of6fnzLyptTukgk=; b=rGYLIdtKozpS4I2FwVyu8a4/2geGT4ZXfSlQO/YiUIfGOZZRpnCuJq9lsLs+ZeI66u CiWk7CcFUCmauqeac0AzWXc/qgS85iO4vVIIOvWSVefpp3juWG+M5oF5ZCCxOUm48Pd5 T+2W3e8tZRvzVxGPR+L3KCcojyZi+spfWlgR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tulq4f5LE5H5krjY/kYJF5AivgVIVxCKFLSzMZFoMOtJ4QzGsZ+KAhpZJbcsMMIiw1 GuEvPgk61wnXd+GXuYTXO/gktuAc+/WgxjVn6N6AEZ4EYEFGIQdaxFQFLvLrqlAGYwlE CNSK7fAE/t+foNvUq0exK6ngCHbGj6WCnEEr4= MIME-Version: 1.0 Received: by 10.224.189.20 with SMTP id dc20mr771971qab.287.1307211729590; Sat, 04 Jun 2011 11:22:09 -0700 (PDT) Received: by 10.229.10.10 with HTTP; Sat, 4 Jun 2011 11:22:09 -0700 (PDT) Date: Sat, 4 Jun 2011 18:22:09 +0000 Message-ID: From: Ali Mashtizadeh To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Subject: Opening files from within geom filters X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 18:22:10 -0000 Hi Folks, I'm working on a small geom filter where I need to open a file with vn_open_cred, but this causes an assert because of a null pointer because g_run_event proc structure has null pointer for the current working directory. Thanks, -- Ali Mashtizadeh From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 4 20:56:50 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D19C106566C for ; Sat, 4 Jun 2011 20:56:50 +0000 (UTC) (envelope-from ben@links.org) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.freebsd.org (Postfix) with ESMTP id BFE1C8FC0A for ; Sat, 4 Jun 2011 20:56:49 +0000 (UTC) Received: from [193.133.15.218] (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.links.org (Postfix) with ESMTPS id A45EA33C3F for ; Sat, 4 Jun 2011 21:41:43 +0100 (BST) Message-ID: <4DEA988C.5030003@links.org> Date: Sat, 04 Jun 2011 21:41:48 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 04 Jun 2011 22:09:46 +0000 Cc: Subject: _LP64 and _ILP32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 20:56:50 -0000 It turns out that both clang and gcc define _LP64 when used native on amd64. Neither defines _ILP32 on i386 (native or cross-compiled). dt_popc() in cddl/contrib/opensolaris/lib/libdtrace/common/dt_subr.c needs on or the other. clang notices because when _ILP32 is missing there's no return. So ... thoughts?-- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff