From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 01:21:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02FDC16A4CE; Sun, 15 Feb 2004 01:21:09 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBBEE43D1F; Sun, 15 Feb 2004 01:21:08 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E13496548B; Sun, 15 Feb 2004 09:21:07 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02922-02-2; Sun, 15 Feb 2004 09:21:07 +0000 (GMT) Received: from saboteur.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 626EB653AC; Sun, 15 Feb 2004 09:20:58 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 2C2FC2B; Sun, 15 Feb 2004 09:20:57 +0000 (GMT) Date: Sun, 15 Feb 2004 09:20:56 +0000 From: Bruce M Simpson To: Garance A Drosihn Message-ID: <20040215092056.GF22136@saboteur.dek.spc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: hackers@FreeBSD.org cc: ru@FreeBSD.org Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 09:21:09 -0000 On Sun, Feb 15, 2004 at 02:42:07AM -0500, Garance A Drosihn wrote: > It occurs to me that the simple, reliable solution to this is to > add a 'realclean' target to /usr/src/Makefile, such as: I don't have a problem with this. However, on a related but somewhat separate note: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). BMS From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 03:57:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B72F16A4CF; Sun, 15 Feb 2004 03:57:18 -0800 (PST) Received: from praetor.linc-it.com (adsl-068-157-070-217.sip.jan.bellsouth.net [68.157.70.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14BBD43D1D; Sun, 15 Feb 2004 03:57:18 -0800 (PST) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-81-244-89.jan.bellsouth.net [65.81.244.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by praetor.linc-it.com (Postfix) with ESMTP id AE2B7155E2; Sun, 15 Feb 2004 05:57:16 -0600 (CST) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 642A220F93; Sun, 15 Feb 2004 05:57:14 -0600 (CST) Date: Sun, 15 Feb 2004 05:57:14 -0600 From: "Matthew D. Fuller" To: Bruce M Simpson Message-ID: <20040215115713.GA33332@over-yonder.net> References: <20040215092056.GF22136@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040215092056.GF22136@saboteur.dek.spc.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.6i-fullermd.2 cc: ru@FreeBSD.org cc: hackers@FreeBSD.org cc: Garance A Drosihn Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 11:57:18 -0000 On Sun, Feb 15, 2004 at 09:20:56AM +0000 I heard the voice of Bruce M Simpson, and lo! it spake thus: > > It would be helpful if it were pointed out in documentation somewhere > that the path to the compile and source directories, when doing NFS > kernel installs, has to be identical to those which were in effect on > the build box due to the treatment of MAKEOBJDIRPREFIX during the modules > build (and subsequent modules/* path creation). And, last time I tried it (which admittedly was a long time ago, so grab your salt grainer), the same applied to world builds too. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 08:37:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4BA516A4CE; Sun, 15 Feb 2004 08:37:15 -0800 (PST) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [68.213.16.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A41843D1D; Sun, 15 Feb 2004 08:37:15 -0800 (PST) (envelope-from richardcoleman@mindspring.com) Received: from mindspring.com (titan.criticalmagic.com [68.213.16.23]) by saturn.criticalmagic.com (Postfix) with ESMTP id 5AEA93BD2A; Sun, 15 Feb 2004 11:37:14 -0500 (EST) Message-ID: <402FA047.70609@mindspring.com> Date: Sun, 15 Feb 2004 11:37:27 -0500 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <20040215092056.GF22136@saboteur.dek.spc.org> In-Reply-To: <20040215092056.GF22136@saboteur.dek.spc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: ru@FreeBSD.org cc: hackers@FreeBSD.org cc: Garance A Drosihn Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richardcoleman@mindspring.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 16:37:15 -0000 Bruce M Simpson wrote: > On Sun, Feb 15, 2004 at 02:42:07AM -0500, Garance A Drosihn wrote: > >>It occurs to me that the simple, reliable solution to this is to >>add a 'realclean' target to /usr/src/Makefile, such as: > > > I don't have a problem with this. > > However, on a related but somewhat separate note: > > It would be helpful if it were pointed out in documentation somewhere > that the path to the compile and source directories, when doing NFS > kernel installs, has to be identical to those which were in effect on > the build box due to the treatment of MAKEOBJDIRPREFIX during the modules > build (and subsequent modules/* path creation). > > BMS I believe this is mentioned in the development(7) man page. But I do not believe it is not mentioned in the relevant handbook section. And this (very useful) man page is never mentioned in the handbook anywhere. I found it by accident one day when looking for something else. Richard Coleman richardcoleman@mindspring.com From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 09:20:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4B0116A4D0; Sun, 15 Feb 2004 09:20:01 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C4BD43D1F; Sun, 15 Feb 2004 09:20:01 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1FHJvnJ084564; Sun, 15 Feb 2004 10:19:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 15 Feb 2004 10:19:00 -0700 (MST) Message-Id: <20040215.101900.20429400.imp@bsdimp.com> To: drosih@rpi.edu From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 17:20:01 -0000 In message: Garance A Drosihn writes: : realclean : : rm -Rf ${.OBJDIR}/* I'd make that be more like: realclean : @chflags -R 0 ${.OBJDIR}/* @rm -Rf ${.OBJDIR}/* since sometimes you wind up files that have flags set on them. I once looked into hacking rm to do that in one step, but couldn't figure out a way to do it race free and punted. There was no notion of a funlink. this is conceptually as close as I got: fd = open(path, O_RDRW); /*1*/ fchflags(fd, 0); unlink(path); /*2*/ which races between /*1*/ and /*2*/. If you can tolerate errors in the output, the following is faster because the chflags has lots less work to do: realclean : @rm -Rf ${.OBJDIR}/* @chflags -R 0 ${.OBJDIR}/* @rm -Rf ${.OBJDIR}/* Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 09:21:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6697C16A4CE; Sun, 15 Feb 2004 09:21:30 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2B4643D2D; Sun, 15 Feb 2004 09:21:29 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1FHLTnJ084595; Sun, 15 Feb 2004 10:21:29 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 15 Feb 2004 10:20:32 -0700 (MST) Message-Id: <20040215.102032.46712244.imp@bsdimp.com> To: bms@spc.org From: "M. Warner Losh" In-Reply-To: <20040215092056.GF22136@saboteur.dek.spc.org> References: <20040215092056.GF22136@saboteur.dek.spc.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: drosih@rpi.edu Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 17:21:30 -0000 In message: <20040215092056.GF22136@saboteur.dek.spc.org> Bruce M Simpson writes: : It would be helpful if it were pointed out in documentation somewhere : that the path to the compile and source directories, when doing NFS : kernel installs, has to be identical to those which were in effect on ^^^^^^^^ : the build box due to the treatment of MAKEOBJDIRPREFIX during the modules : build (and subsequent modules/* path creation). Remove the word kernel. It has to be identical for *ALL* installs. *OR* you have to play games with symbolic links (which is what Timing Solutions does for their chroot build environments). Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 10:48:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4472816A4CE for ; Sun, 15 Feb 2004 10:48:11 -0800 (PST) Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 2556D43D1D for ; Sun, 15 Feb 2004 10:48:11 -0800 (PST) (envelope-from joseph@magnesium.net) Received: (qmail 37842 invoked by uid 1248); 15 Feb 2004 18:48:11 -0000 Date: 15 Feb 2004 12:48:11 -0600 Date: Sun, 15 Feb 2004 12:48:11 -0600 From: Joseph Dunn To: freebsd-hackers@freebsd.org Message-ID: <20040215184811.GA36863@toxic.magnesium.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Maestro-2E no workee in 5.2.1-RC2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 18:48:11 -0000 Hello, I recently upgraded from FreeBSD 5.1 to 5.2.1-RC2 because I needed support for my Atheros-based wifi card. However, my Maestro-2E sound card does not function under 5.2.1, whereas it worked fine with 5.1. For what it's worth, the machine is a Toshiba Portege 7020CT, and ACPI is (necessarily) disabled. Here is the kernel output that occurs when I run "kldload snd_maestro": -- snip -- pcm0: port 0xee00-0xeeff irq 11 at device 12.0 on pci0 pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: ac97 codec reports dac not ready pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_wrcodec() PROGLESS timed out. -- snip -- Any help/suggestions would be greatly appreciated. Joseph Dunn From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 10:54:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D5CB16A4CE for ; Sun, 15 Feb 2004 10:54:07 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AFFB43D1D for ; Sun, 15 Feb 2004 10:54:07 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.10/8.12.10) with ESMTP id i1FIrtOE050522; Sun, 15 Feb 2004 10:53:55 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) i1FIrtcM066848; Sun, 15 Feb 2004 10:53:55 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id i1FIrpoE066847; Sun, 15 Feb 2004 10:53:51 -0800 (PST) (envelope-from marcel) Date: Sun, 15 Feb 2004 10:53:51 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Message-ID: <20040215185351.GB65052@dhcp01.pn.xcllnt.net> References: <20040215.101900.20429400.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040215.101900.20429400.imp@bsdimp.com> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org cc: drosih@rpi.edu Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 18:54:07 -0000 On Sun, Feb 15, 2004 at 10:19:00AM -0700, M. Warner Losh wrote: > In message: > Garance A Drosihn writes: > : realclean : > : rm -Rf ${.OBJDIR}/* > > I'd make that be more like: > > realclean : > @chflags -R 0 ${.OBJDIR}/* > @rm -Rf ${.OBJDIR}/* > > since sometimes you wind up files that have flags set on them. Sounds like a bug to me. Do you have examples? > If you can tolerate errors in the output, the following is faster > because the chflags has lots less work to do: > > realclean : > @rm -Rf ${.OBJDIR}/* > @chflags -R 0 ${.OBJDIR}/* > @rm -Rf ${.OBJDIR}/* Since there should be no flags on files in the object directory in principle, the errors are probably useful to track down where these get set. In any case: I think a realclean target based on a recursive rm is generally useful. Adding a chflags in there makes it more foolproof and thus ideal for UPDATING and other user oriented documentation. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 10:57:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E3E716A4CE for ; Sun, 15 Feb 2004 10:57:47 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C6F43D1D for ; Sun, 15 Feb 2004 10:57:46 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1FIvknJ085752; Sun, 15 Feb 2004 11:57:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 15 Feb 2004 11:56:41 -0700 (MST) Message-Id: <20040215.115641.52781677.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: <20040215185351.GB65052@dhcp01.pn.xcllnt.net> References: <20040215.101900.20429400.imp@bsdimp.com> <20040215185351.GB65052@dhcp01.pn.xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: drosih@rpi.edu Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 18:57:47 -0000 In message: <20040215185351.GB65052@dhcp01.pn.xcllnt.net> Marcel Moolenaar writes: : On Sun, Feb 15, 2004 at 10:19:00AM -0700, M. Warner Losh wrote: : > In message: : > Garance A Drosihn writes: : > : realclean : : > : rm -Rf ${.OBJDIR}/* : > : > I'd make that be more like: : > : > realclean : : > @chflags -R 0 ${.OBJDIR}/* : > @rm -Rf ${.OBJDIR}/* : > : > since sometimes you wind up files that have flags set on them. : : Sounds like a bug to me. Do you have examples? libc.so.4 in the installed libraries in MAKEOBJDIRPREFIX if you have a really old obj tree. This is supposed to be foolproof, no? : > If you can tolerate errors in the output, the following is faster : > because the chflags has lots less work to do: : > : > realclean : : > @rm -Rf ${.OBJDIR}/* : > @chflags -R 0 ${.OBJDIR}/* : > @rm -Rf ${.OBJDIR}/* : : Since there should be no flags on files in the object directory in : principle, the errors are probably useful to track down where these : get set. : : In any case: I think a realclean target based on a recursive rm is : generally useful. Adding a chflags in there makes it more foolproof : and thus ideal for UPDATING and other user oriented documentation. Yup. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 12:34:52 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E65A916A4CE for ; Sun, 15 Feb 2004 12:34:52 -0800 (PST) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FE243D1D for ; Sun, 15 Feb 2004 12:34:52 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i1FKYlHQ001724; Sun, 15 Feb 2004 15:34:47 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040215.101900.20429400.imp@bsdimp.com> References: <20040215.101900.20429400.imp@bsdimp.com> Date: Sun, 15 Feb 2004 15:34:46 -0500 To: "M. Warner Losh" From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: hackers@freebsd.org Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 20:34:53 -0000 At 10:19 AM -0700 2/15/04, M. Warner Losh wrote: >In message: > Garance A Drosihn writes: >: realclean : >: rm -Rf ${.OBJDIR}/* > >I'd make that be more like: > >realclean : > @chflags -R 0 ${.OBJDIR}/* > @rm -Rf ${.OBJDIR}/* > >If you can tolerate errors in the output, the following is >faster because the chflags has lots less work to do: > >realclean : > @rm -Rf ${.OBJDIR}/* > @chflags -R 0 ${.OBJDIR}/* > @rm -Rf ${.OBJDIR}/* The more foolproof/reliable we can make it for everybody, the more I like it. I'll see your chflags, and add one redirection of stderr so the user won't see errors that we don't really care about: realclean : @rm -Rf ${.OBJDIR}/* 2>/dev/null @chflags -R 0 ${.OBJDIR}/* @rm -Rf ${.OBJDIR}/* Any errors that showed up on the first 'rm' should also show up on the second 'rm', so we shouldn't really lose any useful info. I might also try wrapping the second two commands in an 'if', so they will be executed only if there's still something left over after the first 'rm'. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 12:47:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2507616A4CE for ; Sun, 15 Feb 2004 12:47:03 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 915B243D1F for ; Sun, 15 Feb 2004 12:47:02 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 9FB2C5309; Sun, 15 Feb 2004 21:46:59 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 704E45308; Sun, 15 Feb 2004 21:46:50 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id EECAC33C6F; Sun, 15 Feb 2004 21:46:49 +0100 (CET) To: Alexandr Kovalenko References: <200402101129.34337.wes@softweyr.com> <20040214082420.GB77411@nevermind.kiev.ua> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 15 Feb 2004 21:46:49 +0100 In-Reply-To: <20040214082420.GB77411@nevermind.kiev.ua> (Alexandr Kovalenko's message of "Sat, 14 Feb 2004 10:24:21 +0200") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: Juan Tumani cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 20:47:03 -0000 Alexandr Kovalenko writes: > Could you please explain me this? Result is fully reproduceable. Please n= ote, > that the only difference is the output file name. Even resulting files ma= tch > bit-to-bit. [...] Definitely some kind of alignment problem, but it only shows up at some optimization levels and not others. des@dwp ~/src/flops% ll f*s lrwxr-xr-x 1 des des 5 Feb 15 21:34 fffffffffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:06 ffffffffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:06 fffffffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:08 ffffffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:08 fffffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:08 ffffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:03 fffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:03 ffffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 ffffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 ffffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 ffffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 ffflops@ -> flops lrwxr-xr-x 1 des des 5 Feb 15 21:02 fflops@ -> flops -rwxr-xr-x 1 des des 20875 Feb 15 21:05 flops* lrwxr-xr-x 1 des des 5 Feb 15 20:55 flucking-slow-flops@ -> flops des@dwp ~/src/flops% cc -DUNIX -o flops flops.c des@dwp ~/src/flops% for f in f*s ; do ./$f |& grep MFLOPS.1. ; done MFLOPS(1) =3D 386.3844 MFLOPS(1) =3D 365.9330 MFLOPS(1) =3D 364.1425 MFLOPS(1) =3D 366.6225 MFLOPS(1) =3D 389.3461 MFLOPS(1) =3D 377.1758 MFLOPS(1) =3D 354.1909 MFLOPS(1) =3D 356.5961 MFLOPS(1) =3D 371.7964 MFLOPS(1) =3D 366.3965 MFLOPS(1) =3D 407.1590 MFLOPS(1) =3D 375.0376 MFLOPS(1) =3D 353.9504 MFLOPS(1) =3D 394.1439 MFLOPS(1) =3D 134.2436 MFLOPS(1) =3D 148.3984 MFLOPS(1) =3D 390.5495 MFLOPS(1) =3D 373.4338 MFLOPS(1) =3D 341.5228 des@dwp ~/src/flops% cc -DUNIX -O0 -o flops flops.c des@dwp ~/src/flops% for f in f*s ; do ./$f |& grep MFLOPS.1. ; done MFLOPS(1) =3D 392.9511 MFLOPS(1) =3D 361.4795 MFLOPS(1) =3D 407.0004 MFLOPS(1) =3D 368.2120 MFLOPS(1) =3D 355.9699 MFLOPS(1) =3D 378.2740 MFLOPS(1) =3D 372.4568 MFLOPS(1) =3D 339.8898 MFLOPS(1) =3D 367.3776 MFLOPS(1) =3D 379.0460 MFLOPS(1) =3D 363.5696 MFLOPS(1) =3D 379.5704 MFLOPS(1) =3D 390.2681 MFLOPS(1) =3D 382.3747 MFLOPS(1) =3D 175.9839 MFLOPS(1) =3D 131.9588 MFLOPS(1) =3D 379.4554 MFLOPS(1) =3D 385.6065 MFLOPS(1) =3D 363.8399 des@dwp ~/src/flops% cc -DUNIX -O -o flops flops.c des@dwp ~/src/flops% for f in f*s ; do ./$f |& grep MFLOPS.1. ; done MFLOPS(1) =3D 438.2079 MFLOPS(1) =3D 445.7388 MFLOPS(1) =3D 143.9707 MFLOPS(1) =3D 152.9320 MFLOPS(1) =3D 420.0060 MFLOPS(1) =3D 450.3305 MFLOPS(1) =3D 176.8822 MFLOPS(1) =3D 177.4155 MFLOPS(1) =3D 453.1921 MFLOPS(1) =3D 463.7040 MFLOPS(1) =3D 431.8273 MFLOPS(1) =3D 440.2074 MFLOPS(1) =3D 457.4747 MFLOPS(1) =3D 430.3638 MFLOPS(1) =3D 438.6455 MFLOPS(1) =3D 436.4352 MFLOPS(1) =3D 403.4691 MFLOPS(1) =3D 429.3843 MFLOPS(1) =3D 166.5295 des@dwp ~/src/flops% cc -DUNIX -O2 -o flops flops.c des@dwp ~/src/flops% for f in f*s ; do ./$f |& grep MFLOPS.1. ; done MFLOPS(1) =3D 486.4274 MFLOPS(1) =3D 462.6540 MFLOPS(1) =3D 448.6820 MFLOPS(1) =3D 483.4713 MFLOPS(1) =3D 456.5398 MFLOPS(1) =3D 456.2924 MFLOPS(1) =3D 458.9312 MFLOPS(1) =3D 443.5167 MFLOPS(1) =3D 527.0580 MFLOPS(1) =3D 488.1867 MFLOPS(1) =3D 478.7150 MFLOPS(1) =3D 456.2584 MFLOPS(1) =3D 476.7231 MFLOPS(1) =3D 473.5441 MFLOPS(1) =3D 480.3434 MFLOPS(1) =3D 457.3464 MFLOPS(1) =3D 478.5790 MFLOPS(1) =3D 473.1698 MFLOPS(1) =3D 444.4634 des@dwp ~/src/flops% cc -DUNIX -O3 -o flops flops.c des@dwp ~/src/flops% for f in f*s ; do ./$f |& grep MFLOPS.1. ; done MFLOPS(1) =3D 485.9121 MFLOPS(1) =3D 470.1213 MFLOPS(1) =3D 434.6227 MFLOPS(1) =3D 438.2213 MFLOPS(1) =3D 460.9863 MFLOPS(1) =3D 458.5821 MFLOPS(1) =3D 472.2775 MFLOPS(1) =3D 438.6205 MFLOPS(1) =3D 437.6345 MFLOPS(1) =3D 468.6643 MFLOPS(1) =3D 432.0184 MFLOPS(1) =3D 437.1364 MFLOPS(1) =3D 469.7258 MFLOPS(1) =3D 463.0537 MFLOPS(1) =3D 465.8361 MFLOPS(1) =3D 500.6559 MFLOPS(1) =3D 458.3052 MFLOPS(1) =3D 470.0315 MFLOPS(1) =3D 441.1284 DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 13:32:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8576C16A4CE for ; Sun, 15 Feb 2004 13:32:33 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0DDD43D1F for ; Sun, 15 Feb 2004 13:32:32 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i1FLWUhM016512 for ; Sun, 15 Feb 2004 22:32:31 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: hackers@freebsd.org From: Poul-Henning Kamp Date: Sun, 15 Feb 2004 22:32:30 +0100 Message-ID: <16511.1076880750@critter.freebsd.dk> Subject: Neat little, not so simple project... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 21:32:33 -0000 We can compile our kernel with "--test-coverage --profile-arcs" to do basic-block profiling (see kernbb(8) and gcov(1)/gcc(1) docs.) Modify the code GCC inserts, so that it records if giant was held in one bit, and if not held in another, ie: if (giant) *counter_loc |= 1; else *counter_loc |= 2; Run your kernel for a few days. Use kernbb(8) to retrieve output. Produce graphics/statistics showing which code is Giant, which is giant free and which is mixed mode. Consider for instance the "xterm unreadable" font approach, and render the source files into pngs (a 800x660 png holds ten by ten standard pages without margins between) where you color the characters and lines by the result: black - not executed. red - executed with giant always yellow - executed with mixed giant holding green - never executed with giant. Brownie points: Get slashdotted when they discover you did it. -- 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 Sun Feb 15 14:10:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6050216A4CE for ; Sun, 15 Feb 2004 14:10:16 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D7C643D1D for ; Sun, 15 Feb 2004 14:10:16 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.10/8.12.10) with ESMTP id i1FMAGOE051281; Sun, 15 Feb 2004 14:10:16 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) i1FMAFcM067409; Sun, 15 Feb 2004 14:10:15 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id i1FMAFup067408; Sun, 15 Feb 2004 14:10:15 -0800 (PST) (envelope-from marcel) Date: Sun, 15 Feb 2004 14:10:15 -0800 From: Marcel Moolenaar To: Poul-Henning Kamp Message-ID: <20040215221015.GA67309@dhcp01.pn.xcllnt.net> References: <16511.1076880750@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16511.1076880750@critter.freebsd.dk> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org Subject: Re: Neat little, not so simple project... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 22:10:16 -0000 On Sun, Feb 15, 2004 at 10:32:30PM +0100, Poul-Henning Kamp wrote: > > Modify the code GCC inserts, so that it records if giant was held > in one bit, and if not held in another, ie: > > if (giant) > *counter_loc |= 1; > else > *counter_loc |= 2; Alternatively, modify the profiling code to "or" a global, like: *counter_loc |= global_state; And have each binary condition be represented by two bits. For giant this can be: NO_GIANT 1 GIANT 2 To see if code is executed with interrupts enabled or disabled, one can add: INT_ENABLE 4 INT_DISABLE 8 and so forth. When we grab or release giant, we change the global state as follows: grab: global_state = (global_state & ~NO_GIANT) | GIANT; rel: global_state = (global_state & ~GIAN) | NO_GIANT; Likewise for other binary conditions. > black - not executed. > red - executed with giant always > yellow - executed with mixed giant holding > green - never executed with giant. The two bit per binary condition then gives the above: 0 = black 1 = green 2 = red 3 = yellow Just a thought, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 16:42:00 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64FF716A4EC for ; Sun, 15 Feb 2004 16:42:00 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22F4343D1F for ; Sun, 15 Feb 2004 16:42:00 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i1G0fxnI022939 for ; Sun, 15 Feb 2004 19:41:59 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040215.101900.20429400.imp@bsdimp.com> References: <20040215.101900.20429400.imp@bsdimp.com> Date: Sun, 15 Feb 2004 19:41:58 -0500 To: hackers@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 00:42:00 -0000 At 10:19 AM -0700 2/15/04, M. Warner Losh wrote: > >If you can tolerate errors in the output, the following is >faster because the chflags has lots less work to do: > >realclean : > @rm -Rf ${.OBJDIR}/* > @chflags -R 0 ${.OBJDIR}/* > @rm -Rf ${.OBJDIR}/* After some testing, I am planning to go with: Index: Makefile =================================================================== RCS file: /home/ncvs/src/Makefile,v retrieving revision 1.292 diff -u -r1.292 Makefile --- Makefile 9 Dec 2003 02:08:19 -0000 1.292 +++ Makefile 16 Feb 2004 00:29:54 -0000 @@ -104,6 +104,21 @@ .endif # +# This 'realclean' target is not included in TGTS, because it is not +# a recursive target. All of the work for it is done right here. +# The first 'rm' will usually remove all files and directories. If +# it does not, then there are probably some files with chflags set. +# Unset all special chflags, and try the 'rm' a second time. +realclean : + -rm -Rf ${.OBJDIR}/* 2>/dev/null + @-if [ "`echo ${.OBJDIR}/*`" != "${.OBJDIR}/*" ] ; then \ + echo "chflags -R 0 ${.OBJDIR}/*" ; \ + chflags -R 0 ${.OBJDIR}/* ; \ + echo "rm -Rf ${.OBJDIR}/*" ; \ + rm -Rf ${.OBJDIR}/* ; \ + fi + +# # Handle the user-driven targets, using the source relative mk files. # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = If the first 'rm' works, the other two commands will not be executed, and the user will only see the first 'rm'. If the other two commands are executed, then the user will also see echoed-versions of those commands before they are executed. So, if there is some chflag'ed file in /usr/obj/..., what the user sees is: (330) keep-talking/root # make realclean rm -Rf /usr/obj/usr/src/* 2>/dev/null *** Error code 1 (ignored) chflags -R 0 /usr/obj/usr/src/* rm -Rf /usr/obj/usr/src/* -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 19:51:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B429316A4CE for ; Sun, 15 Feb 2004 19:51:30 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF9243D1D for ; Sun, 15 Feb 2004 19:51:30 -0800 (PST) (envelope-from wes@softweyr.com) Received: from 204.68.178.129 (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 463A78836A3; Sun, 15 Feb 2004 19:51:26 -0800 (PST) From: Wes Peters To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=), Alexandr Kovalenko Date: Mon, 16 Feb 2004 03:52:16 -0800 User-Agent: KMail/1.5.4 References: <20040214082420.GB77411@nevermind.kiev.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200402160352.16477.wes@softweyr.com> cc: freebsd-hackers@freebsd.org cc: Juan Tumani Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 03:51:30 -0000 On Sunday 15 February 2004 12:46, Dag-Erling Sm=F8rgrav wrote: > Alexandr Kovalenko writes: > > Could you please explain me this? Result is fully reproduceable. Please > > note, that the only difference is the output file name. Even resulting > > files match bit-to-bit. [...] > > Definitely some kind of alignment problem, but it only shows up at > some optimization levels and not others. I've tested the patch Dan mentioned before and the results were astonishing= =2E =20 Running the flops.c 1.2 program in a loop, lengthening the environment stri= ng=20 by one byte each time, I get 8 successive runs of fast, then 8 successive=20 runs of slow, where fast and slow vary between 650 and 990 mflops. With th= e=20 patch, the performance is always 990, within a few percent. Should I commit this? RCS file: /big/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.235 diff -u -w -r1.235 kern_exec.c =2D-- kern_exec.c 28 Dec 2003 04:37:59 -0000 1.235 +++ kern_exec.c 11 Feb 2004 16:47:28 -0000 @@ -1014,6 +1014,15 @@ */ vectp =3D (char **)(destp - (imgp->argc + imgp->envc + 2) * sizeof(char *)); +=20 + /* + * Align stack to a multiple of 0x20. + * XXX vectp has the wrong type; we usually want a vm_offset_t; + * the suword() family takes a void *, but should take a vm_offset_= t. + * XXX should align stack for signals too. + * XXX should do this more machine/compiler-independently. + */ + vectp =3D (char **)(((vm_offset_t)vectp & ~(vm_offset_t)0x1F) - 4); =20 /* * vectp also becomes our initial stack base =2D-=20 "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 02:13:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8FE016A4CF for ; Mon, 16 Feb 2004 02:13:14 -0800 (PST) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302D543D1F for ; Mon, 16 Feb 2004 02:13:14 -0800 (PST) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with asmtp (Exim 4.30; FreeBSD) id 1AsffV-000Iws-7g for freebsd-hackers@freebsd.org; Mon, 16 Feb 2004 18:08:01 +0800 Message-Id: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> X-Sender: ganbold@micom.mng.net@202.179.0.80 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 16 Feb 2004 18:17:26 +0800 To: freebsd-hackers@freebsd.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 10:13:15 -0000 Hi, I installed FreeBSD 5.2 and updated using cvsup on Dell Poweredge 1600SC. However still FreeBSD doesn't recognize network card. It has onboard Intel Pro/1000 MT card. What should I do in order to use this onboard Intel PRO/1000 card? I checked Intel web site and found only em driver for FreeBSD 4.7. Where can I find latest driver for Intel PRO/1000 MT network card? tia, Ganbold From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 02:22:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 454D416A4DA for ; Mon, 16 Feb 2004 02:22:09 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id D73B043D2D for ; Mon, 16 Feb 2004 02:22:08 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 97147 invoked from network); 16 Feb 2004 10:22:07 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 16 Feb 2004 10:22:07 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 16 Feb 2004 04:22:06 -0600 (CST) From: Mike Silbersack To: Ganbold In-Reply-To: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> Message-ID: <20040216042004.E2262@odysseus.silby.com> References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 10:22:09 -0000 On Mon, 16 Feb 2004, Ganbold wrote: > Hi, > > I installed FreeBSD 5.2 and updated using cvsup on Dell Poweredge 1600SC. > However still FreeBSD doesn't recognize network card. It has onboard Intel > Pro/1000 MT card. > What should I do in order to use this onboard Intel PRO/1000 card? I > checked Intel web site and found only > em driver for FreeBSD 4.7. > Where can I find latest driver for Intel PRO/1000 MT network card? > > tia, > > Ganbold The driver in 5.2 should support that card. Can you post the results of a "pciconf -lv" so we can see the PCI ID of your specific card? Thanks, Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 02:41:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 754EC16A4CE for ; Mon, 16 Feb 2004 02:41:20 -0800 (PST) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADF2843D1D for ; Mon, 16 Feb 2004 02:41:19 -0800 (PST) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with asmtp (Exim 4.30; FreeBSD) id 1Asg6j-000J9y-1Y; Mon, 16 Feb 2004 18:36:09 +0800 Message-Id: <6.0.3.0.2.20040216184426.02970990@202.179.0.80> X-Sender: ganbold@micom.mng.net@202.179.0.80 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 16 Feb 2004 18:45:39 +0800 To: Mike Silbersack From: Ganbold In-Reply-To: <20040216042004.E2262@odysseus.silby.com> References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> <20040216042004.E2262@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 10:41:20 -0000 Hi, Following is the output of pciconf -lv command: hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class = bridge subclass = HOST-PCI hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class = bridge subclass = HOST-PCI rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 hdr=0x00 vendor = 'Accton Technology Corporation' device = 'EN-1207D Fast Ethernet Adapter' class = network subclass = ethernet none0@pci0:14:0: class=0x030000 card=0x01351028 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage XL PCI' class = display subclass = VGA hostb2@pci0:15:0: class=0x060000 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class = bridge subclass = HOST-PCI atapci0@pci0:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI EIDE Controller' class = mass storage subclass = ATA ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class = serial bus subclass = USB isab0@pci0:15:3: class=0x060100 card=0x02301166 chip=0x02251166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI Bridge' class = bridge subclass = PCI-ISA hostb3@pci0:16:0: class=0x060000 card=0x00000000 chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class = bridge subclass = HOST-PCI hostb4@pci0:16:2: class=0x060000 card=0x00000000 chip=0x01011166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CIOB-X2' class = bridge subclass = HOST-PCI mpt0@pci1:4:0: class=0x010000 card=0x01351028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class = mass storage subclass = SCSI Ganbold At 06:22 PM 16.02.2004, you wrote: >On Mon, 16 Feb 2004, Ganbold wrote: > > > Hi, > > > > I installed FreeBSD 5.2 and updated using cvsup on Dell Poweredge 1600SC. > > However still FreeBSD doesn't recognize network card. It has onboard Intel > > Pro/1000 MT card. > > What should I do in order to use this onboard Intel PRO/1000 card? I > > checked Intel web site and found only > > em driver for FreeBSD 4.7. > > Where can I find latest driver for Intel PRO/1000 MT network card? > > > > tia, > > > > Ganbold > >The driver in 5.2 should support that card. Can you post the results of a >"pciconf -lv" so we can see the PCI ID of your specific card? > >Thanks, > >Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 02:54:17 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 488EC16A4CE for ; Mon, 16 Feb 2004 02:54:17 -0800 (PST) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9AF143D2F for ; Mon, 16 Feb 2004 02:54:16 -0800 (PST) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 9-md50000000119.tmp for ; Mon, 16 Feb 2004 10:44:43 +0000 Message-ID: <008c01c3f47b$2649c770$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Mike Silbersack" , "Ganbold" References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> <20040216042004.E2262@odysseus.silby.com> <6.0.3.0.2.20040216184426.02970990@202.179.0.80> Date: Mon, 16 Feb 2004 10:53:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: multiplay.co.uk, Mon, 16 Feb 2004 10:44:43 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 10:54:17 -0000 Not wishing to point out the obvious but there's no EM controller there? Steve ----- Original Message ----- From: "Ganbold" To: "Mike Silbersack" Cc: Sent: Monday, February 16, 2004 10:45 AM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current > Hi, > > Following is the output of pciconf -lv command: > > hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 > rev=0x32 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CMIC-SL' > class = bridge > subclass = HOST-PCI > hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 > rev=0x00 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CMIC-SL' > class = bridge > subclass = HOST-PCI > rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 > hdr=0x00 > vendor = 'Accton Technology Corporation' > device = 'EN-1207D Fast Ethernet Adapter' > class = network > subclass = ethernet > none0@pci0:14:0: class=0x030000 card=0x01351028 chip=0x47521002 > rev=0x27 hdr=0x00 > vendor = 'ATI Technologies' > device = 'Rage XL PCI' > class = display > subclass = VGA > hostb2@pci0:15:0: class=0x060000 card=0x02011166 chip=0x02011166 > rev=0x93 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CSB5 PCI to ISA Bridge' > class = bridge > subclass = HOST-PCI > atapci0@pci0:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 > rev=0x93 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CSB5 PCI EIDE Controller' > class = mass storage > subclass = ATA > ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 > rev=0x05 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'OSB4 OpenHCI Compliant USB Controller' > class = serial bus > subclass = USB > isab0@pci0:15:3: class=0x060100 card=0x02301166 chip=0x02251166 > rev=0x00 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CSB5 PCI Bridge' > class = bridge > subclass = PCI-ISA > hostb3@pci0:16:0: class=0x060000 card=0x00000000 chip=0x01011166 > rev=0x05 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CIOB-X2' > class = bridge > subclass = HOST-PCI > hostb4@pci0:16:2: class=0x060000 card=0x00000000 chip=0x01011166 > rev=0x05 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CIOB-X2' > class = bridge > subclass = HOST-PCI > mpt0@pci1:4:0: class=0x010000 card=0x01351028 chip=0x00301000 rev=0x07 > hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' > class = mass storage > subclass = SCSI ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 03:07:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BA1A16A4CE for ; Mon, 16 Feb 2004 03:07:01 -0800 (PST) Received: from mail.evilcoder.org (cust.94.120.adsl.cistron.nl [195.64.94.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3BFE43D1D for ; Mon, 16 Feb 2004 03:07:00 -0800 (PST) (envelope-from remko@elvandar.org) From: "Remko Lodder" To: "Steven Hartland" , "Mike Silbersack" , "Ganbold" Date: Mon, 16 Feb 2004 12:07:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <20040216105918.954783F@mail.elvandar.org> Importance: Normal X-Virus-Scanned: for evilcoder.org Message-Id: <20040216110656.D93C52B4D6C@mail.evilcoder.org> cc: freebsd-hackers@freebsd.org Subject: RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 11:07:01 -0000 What happends when you load the module if_em.ko kldload if_em.ko Cheers, -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene mrtg.grunn.org Dutch mirror of MRTG -----Oorspronkelijk bericht----- Van: freebsd-hackers-bounces@lists.elvandar.org [mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens Steven Hartland Verzonden: maandag 16 februari 2004 11:54 Aan: Mike Silbersack; Ganbold CC: freebsd-hackers@freebsd.org Onderwerp: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current Not wishing to point out the obvious but there's no EM controller there? Steve ----- Original Message ----- From: "Ganbold" To: "Mike Silbersack" Cc: Sent: Monday, February 16, 2004 10:45 AM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current > Hi, > > Following is the output of pciconf -lv command: > > hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 > rev=0x32 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CMIC-SL' > class = bridge > subclass = HOST-PCI > hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 > rev=0x00 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CMIC-SL' > class = bridge > subclass = HOST-PCI > rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 > hdr=0x00 > vendor = 'Accton Technology Corporation' > device = 'EN-1207D Fast Ethernet Adapter' > class = network > subclass = ethernet > none0@pci0:14:0: class=0x030000 card=0x01351028 chip=0x47521002 > rev=0x27 hdr=0x00 > vendor = 'ATI Technologies' > device = 'Rage XL PCI' > class = display > subclass = VGA > hostb2@pci0:15:0: class=0x060000 card=0x02011166 chip=0x02011166 > rev=0x93 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CSB5 PCI to ISA Bridge' > class = bridge > subclass = HOST-PCI > atapci0@pci0:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 > rev=0x93 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CSB5 PCI EIDE Controller' > class = mass storage > subclass = ATA > ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 > rev=0x05 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'OSB4 OpenHCI Compliant USB Controller' > class = serial bus > subclass = USB > isab0@pci0:15:3: class=0x060100 card=0x02301166 chip=0x02251166 > rev=0x00 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CSB5 PCI Bridge' > class = bridge > subclass = PCI-ISA > hostb3@pci0:16:0: class=0x060000 card=0x00000000 chip=0x01011166 > rev=0x05 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CIOB-X2' > class = bridge > subclass = HOST-PCI > hostb4@pci0:16:2: class=0x060000 card=0x00000000 chip=0x01011166 > rev=0x05 hdr=0x00 > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > device = 'CIOB-X2' > class = bridge > subclass = HOST-PCI > mpt0@pci1:4:0: class=0x010000 card=0x01351028 chip=0x00301000 rev=0x07 > hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' > class = mass storage > subclass = SCSI ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. _______________________________________________ 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" _______________________________________________ Freebsd-hackers mailing list Freebsd-hackers@lists.elvandar.org http://lists.elvandar.org/mailman/listinfo/freebsd-hackers From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 03:09:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F1BB16A4CE for ; Mon, 16 Feb 2004 03:09:28 -0800 (PST) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 811BD43D2D for ; Mon, 16 Feb 2004 03:09:27 -0800 (PST) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with asmtp (Exim 4.30; FreeBSD) id 1AsgXz-000JIP-4o; Mon, 16 Feb 2004 19:04:19 +0800 Message-Id: <6.0.3.0.2.20040216191013.02a201a0@202.179.0.80> X-Sender: ganbold@micom.mng.net@202.179.0.80 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 16 Feb 2004 19:13:49 +0800 To: "Steven Hartland" From: Ganbold In-Reply-To: <008c01c3f47b$2649c770$b3db87d4@multiplay.co.uk> References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> <20040216042004.E2262@odysseus.silby.com> <6.0.3.0.2.20040216184426.02970990@202.179.0.80> <008c01c3f47b$2649c770$b3db87d4@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 11:09:28 -0000 Hi, Maybe server doesn't have EM card at the end. Only reason why I'm thinking is there are 2 identical Dell Poweredge 1600SC servers and the other one has Redhat Linux 9.0 installed and Intel PRO/1000MT card is recognized properly. Ganbold At 06:53 PM 16.02.2004, you wrote: >Not wishing to point out the obvious but there's no EM controller there? > Steve >----- Original Message ----- >From: "Ganbold" >To: "Mike Silbersack" >Cc: >Sent: Monday, February 16, 2004 10:45 AM >Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD >5.2-current > > > > Hi, > > > > Following is the output of pciconf -lv command: > > > > hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 > > rev=0x32 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CMIC-SL' > > class = bridge > > subclass = HOST-PCI > > hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 > > rev=0x00 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CMIC-SL' > > class = bridge > > subclass = HOST-PCI > > rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 > > hdr=0x00 > > vendor = 'Accton Technology Corporation' > > device = 'EN-1207D Fast Ethernet Adapter' > > class = network > > subclass = ethernet > > none0@pci0:14:0: class=0x030000 card=0x01351028 chip=0x47521002 > > rev=0x27 hdr=0x00 > > vendor = 'ATI Technologies' > > device = 'Rage XL PCI' > > class = display > > subclass = VGA > > hostb2@pci0:15:0: class=0x060000 card=0x02011166 chip=0x02011166 > > rev=0x93 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI to ISA Bridge' > > class = bridge > > subclass = HOST-PCI > > atapci0@pci0:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 > > rev=0x93 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI EIDE Controller' > > class = mass storage > > subclass = ATA > > ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'OSB4 OpenHCI Compliant USB Controller' > > class = serial bus > > subclass = USB > > isab0@pci0:15:3: class=0x060100 card=0x02301166 chip=0x02251166 > > rev=0x00 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI Bridge' > > class = bridge > > subclass = PCI-ISA > > hostb3@pci0:16:0: class=0x060000 card=0x00000000 chip=0x01011166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CIOB-X2' > > class = bridge > > subclass = HOST-PCI > > hostb4@pci0:16:2: class=0x060000 card=0x00000000 chip=0x01011166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CIOB-X2' > > class = bridge > > subclass = HOST-PCI > > mpt0@pci1:4:0: class=0x010000 card=0x01351028 chip=0x00301000 rev=0x07 > > hdr=0x00 > > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > > device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' > > class = mass storage > > subclass = SCSI > >================================================ >This e.mail is private and confidential between Multiplay (UK) Ltd. and >the person or entity to whom it is addressed. In the event of >misdirection, the recipient is prohibited from using, copying, printing or >otherwise disseminating it or any information contained in it. > >In the event of misdirection, illegible or incomplete transmission please >telephone (023) 8024 3137 >or return the E.mail to postmaster@multiplay.co.uk. > > >_______________________________________________ >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 Mon Feb 16 03:11:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8C5916A4CE for ; Mon, 16 Feb 2004 03:11:15 -0800 (PST) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id C14F943D1F for ; Mon, 16 Feb 2004 03:11:14 -0800 (PST) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with asmtp (Exim 4.30; FreeBSD) id 1AsgZj-000JJC-16; Mon, 16 Feb 2004 19:06:07 +0800 Message-Id: <6.0.3.0.2.20040216191443.029b8dd0@202.179.0.80> X-Sender: ganbold@micom.mng.net@202.179.0.80 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 16 Feb 2004 19:15:39 +0800 To: "Remko Lodder" From: Ganbold In-Reply-To: <20040216110656.D93C52B4D6C@mail.evilcoder.org> References: <20040216105918.954783F@mail.elvandar.org> <20040216110656.D93C52B4D6C@mail.evilcoder.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-hackers@freebsd.org Subject: RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 11:11:15 -0000 When I try to load if_em.ko module /var/log/messages says: Feb 16 19:08:41 mnao1 kernel: module_register: module pci/em already exists! Feb 16 19:08:41 mnao1 kernel: Module pci/em failed to register: 17 Ganbold At 07:07 PM 16.02.2004, you wrote: >What happends when you load the module if_em.ko > >kldload if_em.ko > >Cheers, > >-- > >Kind regards, > >Remko Lodder >Elvandar.org/DSINet.org >www.mostly-harmless.nl Dutch community for helping newcomers on the >hackerscene > >mrtg.grunn.org Dutch mirror of MRTG > >-----Oorspronkelijk bericht----- >Van: freebsd-hackers-bounces@lists.elvandar.org >[mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens Steven >Hartland >Verzonden: maandag 16 februari 2004 11:54 >Aan: Mike Silbersack; Ganbold >CC: freebsd-hackers@freebsd.org >Onderwerp: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network >cardproblem in FreeBSD 5.2-current > > >Not wishing to point out the obvious but there's no EM controller there? > Steve >----- Original Message ----- >From: "Ganbold" >To: "Mike Silbersack" >Cc: >Sent: Monday, February 16, 2004 10:45 AM >Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD >5.2-current > > > > Hi, > > > > Following is the output of pciconf -lv command: > > > > hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 > > rev=0x32 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CMIC-SL' > > class = bridge > > subclass = HOST-PCI > > hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 > > rev=0x00 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CMIC-SL' > > class = bridge > > subclass = HOST-PCI > > rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 > > hdr=0x00 > > vendor = 'Accton Technology Corporation' > > device = 'EN-1207D Fast Ethernet Adapter' > > class = network > > subclass = ethernet > > none0@pci0:14:0: class=0x030000 card=0x01351028 chip=0x47521002 > > rev=0x27 hdr=0x00 > > vendor = 'ATI Technologies' > > device = 'Rage XL PCI' > > class = display > > subclass = VGA > > hostb2@pci0:15:0: class=0x060000 card=0x02011166 chip=0x02011166 > > rev=0x93 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI to ISA Bridge' > > class = bridge > > subclass = HOST-PCI > > atapci0@pci0:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 > > rev=0x93 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI EIDE Controller' > > class = mass storage > > subclass = ATA > > ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'OSB4 OpenHCI Compliant USB Controller' > > class = serial bus > > subclass = USB > > isab0@pci0:15:3: class=0x060100 card=0x02301166 chip=0x02251166 > > rev=0x00 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI Bridge' > > class = bridge > > subclass = PCI-ISA > > hostb3@pci0:16:0: class=0x060000 card=0x00000000 chip=0x01011166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CIOB-X2' > > class = bridge > > subclass = HOST-PCI > > hostb4@pci0:16:2: class=0x060000 card=0x00000000 chip=0x01011166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CIOB-X2' > > class = bridge > > subclass = HOST-PCI > > mpt0@pci1:4:0: class=0x010000 card=0x01351028 chip=0x00301000 rev=0x07 > > hdr=0x00 > > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > > device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' > > class = mass storage > > subclass = SCSI > >================================================ >This e.mail is private and confidential between Multiplay (UK) Ltd. and the >person or entity to whom it is addressed. In the event of misdirection, the >recipient is prohibited from using, copying, printing or otherwise >disseminating it or any information contained in it. > >In the event of misdirection, illegible or incomplete transmission please >telephone (023) 8024 3137 >or return the E.mail to postmaster@multiplay.co.uk. > > >_______________________________________________ >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" >_______________________________________________ >Freebsd-hackers mailing list >Freebsd-hackers@lists.elvandar.org >http://lists.elvandar.org/mailman/listinfo/freebsd-hackers From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 03:14:56 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75D2116A4CE for ; Mon, 16 Feb 2004 03:14:56 -0800 (PST) Received: from mail.evilcoder.org (cust.94.120.adsl.cistron.nl [195.64.94.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF2C743D1D for ; Mon, 16 Feb 2004 03:14:55 -0800 (PST) (envelope-from remko@elvandar.org) From: "Remko Lodder" To: "Ganbold" Date: Mon, 16 Feb 2004 12:15:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <20040216111135.ABD2518@mail.elvandar.org> Importance: Normal X-Virus-Scanned: for evilcoder.org Message-Id: <20040216111455.0C15F2B4D6C@mail.evilcoder.org> cc: freebsd-hackers@freebsd.org Subject: RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 11:14:56 -0000 Alright, the module is already compiled into the kernel, or the driver is already loaded. Strange, because i yesterday build in the same nic on my machine. uname -a FreeBSD luca.elvandar.org 5.2.1-RC2 FreeBSD 5.2.1-RC2 #2: Sun Feb 15 19:44:28 CET 2004 root@luca.elvandar.org:/usr/freebsd52/src/sys/i386/compile/ELVANDAR i386 em0: port 0xa000-0xa03f mem 0xde000000-0xde01ffff,0xde800000-0xde81ffff irq 12 at device 10.0 on pci0 em0: Speed:N/A Duplex:N/A Could it be a bios setting (note that i am guessing now) ?, onboard nic enabled.. Cheers -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene mrtg.grunn.org Dutch mirror of MRTG -----Oorspronkelijk bericht----- Van: Ganbold [mailto:ganbold@micom.mng.net] Verzonden: maandag 16 februari 2004 12:16 Aan: Remko Lodder CC: freebsd-hackers@freebsd.org Onderwerp: RE: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network cardproblem in FreeBSD 5.2-current When I try to load if_em.ko module /var/log/messages says: Feb 16 19:08:41 mnao1 kernel: module_register: module pci/em already exists! Feb 16 19:08:41 mnao1 kernel: Module pci/em failed to register: 17 Ganbold At 07:07 PM 16.02.2004, you wrote: >What happends when you load the module if_em.ko > >kldload if_em.ko > >Cheers, > >-- > >Kind regards, > >Remko Lodder >Elvandar.org/DSINet.org >www.mostly-harmless.nl Dutch community for helping newcomers on the >hackerscene > >mrtg.grunn.org Dutch mirror of MRTG > >-----Oorspronkelijk bericht----- >Van: freebsd-hackers-bounces@lists.elvandar.org >[mailto:freebsd-hackers-bounces@lists.elvandar.org]Namens Steven >Hartland >Verzonden: maandag 16 februari 2004 11:54 >Aan: Mike Silbersack; Ganbold >CC: freebsd-hackers@freebsd.org >Onderwerp: [Freebsd-hackers] Re: Intel PRO/1000 MT onboard network >cardproblem in FreeBSD 5.2-current > > >Not wishing to point out the obvious but there's no EM controller there? > Steve >----- Original Message ----- >From: "Ganbold" >To: "Mike Silbersack" >Cc: >Sent: Monday, February 16, 2004 10:45 AM >Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD >5.2-current > > > > Hi, > > > > Following is the output of pciconf -lv command: > > > > hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 > > rev=0x32 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CMIC-SL' > > class = bridge > > subclass = HOST-PCI > > hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 > > rev=0x00 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CMIC-SL' > > class = bridge > > subclass = HOST-PCI > > rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 > > hdr=0x00 > > vendor = 'Accton Technology Corporation' > > device = 'EN-1207D Fast Ethernet Adapter' > > class = network > > subclass = ethernet > > none0@pci0:14:0: class=0x030000 card=0x01351028 chip=0x47521002 > > rev=0x27 hdr=0x00 > > vendor = 'ATI Technologies' > > device = 'Rage XL PCI' > > class = display > > subclass = VGA > > hostb2@pci0:15:0: class=0x060000 card=0x02011166 chip=0x02011166 > > rev=0x93 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI to ISA Bridge' > > class = bridge > > subclass = HOST-PCI > > atapci0@pci0:15:1: class=0x01018a card=0xc1351028 chip=0x02121166 > > rev=0x93 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI EIDE Controller' > > class = mass storage > > subclass = ATA > > ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'OSB4 OpenHCI Compliant USB Controller' > > class = serial bus > > subclass = USB > > isab0@pci0:15:3: class=0x060100 card=0x02301166 chip=0x02251166 > > rev=0x00 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CSB5 PCI Bridge' > > class = bridge > > subclass = PCI-ISA > > hostb3@pci0:16:0: class=0x060000 card=0x00000000 chip=0x01011166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CIOB-X2' > > class = bridge > > subclass = HOST-PCI > > hostb4@pci0:16:2: class=0x060000 card=0x00000000 chip=0x01011166 > > rev=0x05 hdr=0x00 > > vendor = 'ServerWorks (Was: Reliance Computer Corp)' > > device = 'CIOB-X2' > > class = bridge > > subclass = HOST-PCI > > mpt0@pci1:4:0: class=0x010000 card=0x01351028 chip=0x00301000 rev=0x07 > > hdr=0x00 > > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > > device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' > > class = mass storage > > subclass = SCSI > >================================================ >This e.mail is private and confidential between Multiplay (UK) Ltd. and the >person or entity to whom it is addressed. In the event of misdirection, the >recipient is prohibited from using, copying, printing or otherwise >disseminating it or any information contained in it. > >In the event of misdirection, illegible or incomplete transmission please >telephone (023) 8024 3137 >or return the E.mail to postmaster@multiplay.co.uk. > > >_______________________________________________ >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" >_______________________________________________ >Freebsd-hackers mailing list >Freebsd-hackers@lists.elvandar.org >http://lists.elvandar.org/mailman/listinfo/freebsd-hackers From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 03:37:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAB816A4CE for ; Mon, 16 Feb 2004 03:37:05 -0800 (PST) Received: from tuminfo2.informatik.tu-muenchen.de (tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91E6443D1D for ; Mon, 16 Feb 2004 03:37:05 -0800 (PST) (envelope-from langd@informatik.tu-muenchen.de) Date: Mon, 16 Feb 2004 12:37:03 +0100 From: Daniel Lang To: Ganbold Message-ID: <20040216113703.GA51000@atrbg11.informatik.tu-muenchen.de> References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> <20040216042004.E2262@odysseus.silby.com> <6.0.3.0.2.20040216184426.02970990@202.179.0.80> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <6.0.3.0.2.20040216184426.02970990@202.179.0.80> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de cc: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 11:37:06 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Ganbold wrote on Mon, Feb 16, 2004 at 06:45:39PM +0800: [..] > rl0@pci0:4:0: class=3D0x020000 card=3D0x9207103c chip=3D0x12111113 rev= =3D0x10=20 > hdr=3D0x00 > vendor =3D 'Accton Technology Corporation' > device =3D 'EN-1207D Fast Ethernet Adapter' > class =3D network > subclass =3D ethernet [..] This is the only probed Ethernet device and it seems rl driver has already attached to it. I know that DELL servers can be equipped with an em NIC optionally, maybe this is the case for your second machine. You should check the connectors on the back, if there is an additional TP or SX port (I think the Pro/1000 is SX only). If your RedHat machine has the SX port, but your other one doesn't, that would solve the mystery, wouldn't it? HTH, Daniel --=20 IRCnet: Mr-Spock - Truth lies in the eye of the beholder -=20 Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ --k1lZvvs/B4yU6o8G Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIXgAYJKoZIhvcNAQcCoIIXcTCCF20CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FUAwggbMMIIFtKADAgECAgIVezANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCREUxETAP BgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVu Y2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEYMBYGA1UEAxMPUkJH LUJlbnV0emVyLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDMwNTIwMTIz MTQyWhcNMDQwNTIxMDAwMDAwWjCBqzELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVu MSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZ RmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEUMBIGA1UEAxMLRGFuaWVsIExhbmcxJDAiBgkq hkiG9w0BCQEWFWRhbmllbC5sYW5nQGluLnR1bS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAk55VXazdhYUuEJAHmO439gJwKVfvcdF64VyP8tzhYwiIx/9FOsQj8r8Gw2g0MDCa X2mCNiSKz32sUI33SQFhBhwxoF6bpq7d6pfeJ7UL+2T/bkRVF/Y7zPuMMK/wMbiEwyfvdjxk 8XsVtpj500LjW7QYdAHlijHRAY2nFk4f8bcCAwEAAaOCA38wggN7MAwGA1UdEwEB/wQCMAAw HQYDVR0OBBYEFPMLcu3eegcL6m8ObwlveYDdoYOpMIHKBgNVHSMEgcIwgb+AFK81Ou8wbY/H n0tx1dgCig9IKGPUoYGjpIGgMIGdMQswCQYDVQQGEwJERTERMA8GA1UEBxMITXVlbmNoZW4x KTAnBgNVBAoTIFRlY2huaXNjaGUgVW5pdmVyc2l0YWV0IE11ZW5jaGVuMSIwIAYDVQQLExlG YWt1bHRhZXQgZnVlciBJbmZvcm1hdGlrMQ8wDQYDVQQDEwZSQkctQ0ExGzAZBgkqhkiG9w0B CQEWDGNhQGluLnR1bS5kZYIBAjAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMIGxBgNVHREEgakwgaaBD2xhbmdkQGluLnR1bS5kZYEVZGFuaWVsLmxh bmdAaW4udHVtLmRlgR9sYW5nZEBpbmZvcm1hdGlrLnR1LW11ZW5jaGVuLmRlgSVkYW5pZWwu bGFuZ0BpbmZvcm1hdGlrLnR1LW11ZW5jaGVuLmRlgRBsYW5nZEBjcy50dW0uZWR1gRZkYW5p ZWwubGFuZ0Bjcy50dW0uZWR1gQpkbEBsZW8ub3JnMAkGA1UdEgQCMAAwOAYDVR0fBDEwLzAt oCugKYYnaHR0cDovL2NhLmluLnR1bS5kZS9jcmxzL3VzZXJjYV9jcmwuY3JsMBEGCWCGSAGG +EIBAQQEAwIFoDCBnwYJYIZIAYb4QgENBIGRFoGORGllc2VzIFplcnRpZmlrYXQgd3VyZGUg YXVzZ2VzdGVsbHQgZnVlciBEYW5pZWwgTGFuZyB2b24gZGVyIFJCRy1CZW51dHplci1DQSwg RmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpayBkZXIgVGVjaG5pc2NoZW4gVW5pdmVyc2l0YWV0 IE11ZW5jaGVuLjA2BglghkgBhvhCAQMEKRYnaHR0cDovL2NhLmluLnR1bS5kZS9jZ2ktYmlu L3VzZXJjYS1yZXY/MDIGCWCGSAGG+EIBBAQlFiNodHRwOi8vY2EuaW4udHVtLmRlL2NnaS1i aW4vY2EtcmV2PzA2BglghkgBhvhCAQgEKRYnaHR0cDovL2NhLmluLnR1bS5kZS9wb2xpY2ll cy9yYmdjYS5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQAGrfB5rH9D6jl6Tx+hwXpv0a/TuV39 vIQWMCA1hi0V4pI+bMyGTW1k/Ve5C58wRZv7CSTnxTGoqZmqnV37GGQlZBmvsDE+u3FKL/T7 Tk/rlVajExCXGHwjgHp2FfCaVMawKSUrI60aDcUgLUtT2DKpEfKfr/MC7CDtCaYy6TW93cHc uv2oM+1PN+CIcR5PaqEySmeYoXBMXd6sktjyNUWLxsNhtFMVnOiwF3SZYbRbRobuEWM3o+W7 nijECUIKz8rvK3f/c8v9HlVitMbeaTs4J1nZUR9lsvGLik6vsfIgbmuP6MMkrKFYwq5XTR1x JtMcmvnqcWytpYFDVPGuGaj1MIIHKDCCBRCgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnTEL MAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVu aXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRp azEPMA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDIx MDA5MTY0MTAzWhcNMDQwNTIxMDAwMDAwWjCBpDELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11 ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAG A1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEWMBQGA1UEAxMNUkJHLVNlcnZlci1D QTEbMBkGCSqGSIb3DQEJARYMY2FAaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAzAHBIFy4tKTvbMMg037hc9t2jR5MVpEUIPvrSWC4xpbr6Hw7abQW/lRfFpV8 enf9tSgfcl8kvGjAAD8AYeuDash6TQSUjBdZCe7V297oZ0dsuurZBkM5BwvLWF8vMiY+SD/+ XTqhnU6B/E9C+R5VXjXsXV2u9hDtKVC5hqVgnxRM5rT/LsUhcchgAXk2WuI8r9Llb+voPWwM FmHk2jxUwhvxZfGo15HDrvJUgzYsL36SmeYMI9Eo70uGmAQRPVVq2zn/3AC4z8X1cBd3ItnH YPbx0iUH5kEGq2KH5iCndwNq9oaFhKj+Y34wEv5BYl6sb5C9EBvtGyebNwuvmtC3tQIDAQAB o4ICaDCCAmQwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUH9QPe0VQVF1D2v8Su/itK/4O QMwwgcoGA1UdIwSBwjCBv4AU2WV+TUF/hD+1KtZ7E519yuW0XRqhgaOkgaAwgZ0xCzAJBgNV BAYTAkRFMREwDwYDVQQHEwhNdWVuY2hlbjEpMCcGA1UEChMgVGVjaG5pc2NoZSBVbml2ZXJz aXRhZXQgTXVlbmNoZW4xIjAgBgNVBAsTGUZha3VsdGFldCBmdWVyIEluZm9ybWF0aWsxDzAN BgNVBAMTBlJCRy1DQTEbMBkGCSqGSIb3DQEJARYMY2FAaW4udHVtLmRlggEAMA4GA1UdDwEB /wQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDATA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8v Y2EuaW4udHVtLmRlL2NybHMvY2FfY3JsLmNybDARBglghkgBhvhCAQEEBAMCAgQwgYQGCWCG SAGG+EIBDQR3FnVaZXJ0aWZpa2F0IGZ1ZXIgUkJHLVNlcnZlci1DQSBhdXNnZXN0ZWxsdCB2 b24gUkJHLUNBLCBGYWt1bHRhZXQgZnVlciBJbmZvcm1hdGlrIGRlciBUZWNobmlzY2hlbiBV bml2ZXJzaXRhZXQgTXVlbmNoZW4wMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jYS5pbi50dW0u ZGUvY2dpLWJpbi9jYS1yZXY/MDwGCWCGSAGG+EIBCAQvFi1odHRwOi8vY2EuaW4udHVtLmRl L3BvbGljaWVzL3NlcnZlcmNhcG9sLmh0bWwwDQYJKoZIhvcNAQEFBQADggIBAMzKnULQb6Kd hPNmKKmPSJJUOtbHxGH7Qi8paskt7dzDja/X7wz3524LGN2f05c1uAfyAP9Ar0nFthWy0qeM ueOtrOcSCj8AYwYN5H4drMC8GglQwlkD0M/nhPJ5xtAj8JzNYHzG1DK5tVgoJnF+t4KmTpI6 QJ6Dh3XDoZXubWd0jkHxQIzOKhs9PPjEzydmerC7B3Zt8vh7457Sk6wwZFhXc+nkeIIplnlD sBioOSyF7hZOwx4I2Auxss1zsyUQHCX88sOuZC0kYB7yRd1TMRti8josznux8k13sZBezFMP S2yCuKRBEk5Nt57OyGbIF4O7Mhn01mTnol2BDpTKJek45bIpRvSLl/xRPpjnzxLO1rXtXgCs GtkmXj+Zwo5fnL6OvZIiFgMV4ASsFclZexceHxDjpia1IHSFB/4I5fAys8Bw03idI+rfsla1 mW0AJuw260QgoBz+b+LKGosJdNosMfOJmNl0vW3Kq6NfYpZLkG0YJF9Xo6vsATFk9kNq56ye ila80uE2wDO/BGAcBMWQ4uwfrWqVPoW5X/oHcPISApnCBeZ+LyWvnTkgxCUeyqyxNOvaA/j7 jUoBb9l+GWup8EGND16mR/wYWAxYLgis1pn5QmSTbbKSWKcqDo6HBo1Zx9XRf76CZc7RJRp9 EXqYrkmlL9eg7qcnnS1rJbqxMIIHQDCCBSigAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnTEL MAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVu aXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRp azEPMA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDIx MDA5MTcwMzUyWhcNMDQwNTIxMDAwMDAwWjCBpjELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11 ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAG A1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEYMBYGA1UEAxMPUkJHLUJlbnV0emVy LUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCtYQ5ycRY6fyrlvJgpeQCNhPxQduU59Kpv6xWId9sHL8NyI7nlmlWzMroD ddIqeg7QvvtPS+xorbQJ9rxh94lXZtwlGPYg4LC/1PHGnDt+8RGiq8GLbHyeJZoQnEGSovyn uR4wZ9qnApFRsXcUZ5W/CSSwjKnQeN39oFj8EC4xtmUuudV65sxGuGToRVoSnjeULJKYBNnC RxVx2MU5exKGQAuvgaVd7Ozb7ziZyWxhVCNrUQOGrSKDgyKLguWTNnD7sSOiOpie3IX8H2DV DvbcKcmMQr8ojwWutNDPadOth+J6qd/modqxB1VbH8wu0lezbhPM5dh7yUFCEqZoXXh9AgMB AAGjggJ+MIICejAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSvNTrvMG2Px59LcdXYAooP SChj1DCBygYDVR0jBIHCMIG/gBTZZX5NQX+EP7Uq1nsTnX3K5bRdGqGBo6SBoDCBnTELMAkG A1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZl cnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEP MA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGWCAQAwDgYDVR0P AQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA0BgNVHR8ELTArMCmg J6AlhiNodHRwOi8vY2EuaW4udHVtLmRlL2NybHMvY2FfY3JsLmNybDAJBgNVHRIEAjAAMBEG CWCGSAGG+EIBAQQEAwIBBjCBhwYJYIZIAYb4QgENBHoWeFplcnRpZmlrYXQgZnVlciBSQkct QmVudXR6ZXItQ0EsIGF1c2dlc3RlbGx0IHZvbiBSQkctQ0EsIEZha3VsdGFldCBmdWVyIElu Zm9ybWF0aWsgZGVyIFRlY2huaXNjaGVuIFVuaXZlcnNpdGFldCBNdWVuY2hlbjAyBglghkgB hvhCAQQEJRYjaHR0cDovL2NhLmluLnR1bS5kZS9jZ2ktYmluL2NhLXJldj8wOgYJYIZIAYb4 QgEIBC0WK2h0dHA6Ly9jYS5pbi50dW0uZGUvcG9saWNpZXMvdXNlcmNhcG9sLmh0bWwwDQYJ KoZIhvcNAQEFBQADggIBAJapnE3b+p2nrryUkfTEl5iKTl7o8hLrB4FbLZsdBs16pIb0fIIq yGR0wlv0Qq5OLHm1hQzGkfhqEb2O+oBQJgaykxAB+6rKKOJdL12LSQrYXbDV8t/isyurwkFi fmcWDxVF4reDcz8F61KrVz46k2KtdY39CcuW+x1xQZRgier+jdBLLsbkM21XkufUrwnnO5Vr j0cD48XmcsVuWF0EkGo49jPHk8LG2cMyhQR/ZT4f1kegi9WmoV4NjKJnEU2QaTfbLUb2i509 RYf31oDnhq6oO1wCcRvVeDfyx5aj0y68sL1ySNmTQEELOmOFPqmVqa9BAR4wzuTXJi9UvOwF tQMsKq9AX4cFegDl4D4E5QQ7JladBMvJ0VALdGSGlGHARQGvO8SvapsOTVPC5n+UD6jwhTw0 pCPSypzIIrpT9vjxD7bDvudOfKguVRuX8poWID7yXcB0ApHdoNIMrGJx1Tc6SN6rGKWYre+W y/AsqMNNmR+YrJn/UOs6lKX9TtaHOFbxNPwo7RgdRg/srESEtIQ5IKkPA0Vt9Eh5H3VWBhrU b1gmvyNTwJFRqYmFhr7jFFdgnX3Jsbw81jl1z4jLdeeslLxs8vmnwQvWRz3BEPo+g0mrIuYt QjSdgGF8xHgyeRxfa8o3P/rncBysyNYe/AdWd6UGPmompEBZuFzSN+G8MYICCDCCAgQCAQEw ga0wgaYxCzAJBgNVBAYTAkRFMREwDwYDVQQHEwhNdWVuY2hlbjEpMCcGA1UEChMgVGVjaG5p c2NoZSBVbml2ZXJzaXRhZXQgTXVlbmNoZW4xIjAgBgNVBAsTGUZha3VsdGFldCBmdWVyIElu Zm9ybWF0aWsxGDAWBgNVBAMTD1JCRy1CZW51dHplci1DQTEbMBkGCSqGSIb3DQEJARYMY2FA aW4udHVtLmRlAgIVezAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDIxNjExMzcwM1owIwYJKoZIhvcNAQkEMRYEFCVAW9CyPHCT PVZnUdxE93SvwotHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAJ5BnU0a++LRTwI+bmlPdqqHDZjHiOQco9ix9zn1Ek76BkSGFVshf2iaKvrPB35ug Wm4gkm4RMo9tKSMPNxqaOR97V/ycwKihFpQmOgqSX8IvNkVV9whhWTQfkZtNn3tbtY2+2PMn jAGK+6uOg5s/D0r6Llt0cysJs+ZOGliEaOA= --k1lZvvs/B4yU6o8G-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 04:04:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21D1916A4CE for ; Mon, 16 Feb 2004 04:04:37 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 218AD43D1D for ; Mon, 16 Feb 2004 04:04:34 -0800 (PST) (envelope-from ru@FreeBSD.org.ua) Received: from phantom.cris.net (ru@localhost [127.0.0.1]) by phantom.cris.net (8.12.10/8.12.10) with ESMTP id i1GC5Tmt017030; Mon, 16 Feb 2004 14:05:30 +0200 (EET) (envelope-from ru@FreeBSD.org.ua) Received: (from ru@localhost) by phantom.cris.net (8.12.10/8.12.10/Submit) id i1GC5L9q017025; Mon, 16 Feb 2004 14:05:21 +0200 (EET) (envelope-from ru) Date: Mon, 16 Feb 2004 14:05:20 +0200 From: Ruslan Ermilov To: "Matthew D. Fuller" Message-ID: <20040216120520.GA16772@FreeBSD.org.ua> References: <20040215092056.GF22136@saboteur.dek.spc.org> <20040215115713.GA33332@over-yonder.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20040215115713.GA33332@over-yonder.net> User-Agent: Mutt/1.5.5.1i cc: hackers@FreeBSD.org cc: Garance A Drosihn Subject: Re: Adding 'realclean' target to /usr/src/Makefile X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 12:04:37 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 15, 2004 at 05:57:14AM -0600, Matthew D. Fuller wrote: > On Sun, Feb 15, 2004 at 09:20:56AM +0000 I heard the voice of > Bruce M Simpson, and lo! it spake thus: > >=20 > > It would be helpful if it were pointed out in documentation somewhere > > that the path to the compile and source directories, when doing NFS > > kernel installs, has to be identical to those which were in effect on > > the build box due to the treatment of MAKEOBJDIRPREFIX during the modul= es > > build (and subsequent modules/* path creation). >=20 > And, last time I tried it (which admittedly was a long time ago, so > grab your salt grainer), the same applied to world builds too. >=20 To stop this from being happening, Jun Kuriyama has done a cleanup lately to replace lots of symlink created during buildworld with cp(1) commands. Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAMLIAUkv4P6juNwoRAofzAJ9KYXHRr4veokXjxCbmMk1ALzWsVgCdHI/A ULw3nWVgwo8eRSuk1GyZWNQ= =+EJa -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 04:27:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1185C16A4CE for ; Mon, 16 Feb 2004 04:27:43 -0800 (PST) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 502D943D31 for ; Mon, 16 Feb 2004 04:27:42 -0800 (PST) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with asmtp (Exim 4.30; FreeBSD) id 1AshLk-000JWx-1w for freebsd-hackers@freebsd.org; Mon, 16 Feb 2004 19:55:44 +0800 Message-Id: <6.0.3.0.2.20040216200451.02a27b60@202.179.0.80> X-Sender: ganbold@micom.mng.net@202.179.0.80 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 16 Feb 2004 20:05:01 +0800 To: freebsd-hackers@freebsd.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 12:27:43 -0000 Yes I installed Realtek card because FreeBSD doesn't recognize onboard card. It has onboard TP connector same as Redhat machine has. Ganbold At 07:37 PM 16.02.2004, you wrote: >Hi, > >Ganbold wrote on Mon, Feb 16, 2004 at 06:45:39PM +0800: >[..] > > rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 > > hdr=0x00 > > vendor = 'Accton Technology Corporation' > > device = 'EN-1207D Fast Ethernet Adapter' > > class = network > > subclass = ethernet >[..] > >This is the only probed Ethernet device and it seems rl driver >has already attached to it. > >I know that DELL servers can be equipped with an em NIC >optionally, maybe this is the case for your second machine. > >You should check the connectors on the back, if there is an >additional TP or SX port (I think the Pro/1000 is SX only). >If your RedHat machine has the SX port, but your other one >doesn't, that would solve the mystery, wouldn't it? > >HTH, > Daniel >-- >IRCnet: Mr-Spock - Truth lies in the eye of the beholder - > Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 04:48:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E92DF16A4CE for ; Mon, 16 Feb 2004 04:48:01 -0800 (PST) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AB6743D1F for ; Mon, 16 Feb 2004 04:48:01 -0800 (PST) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 30-md50000000123.tmp for ; Mon, 16 Feb 2004 12:38:29 +0000 Message-ID: <012101c3f48b$0b9bd7a0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , "Ganbold" References: <6.0.3.0.2.20040216200451.02a27b60@202.179.0.80> Date: Mon, 16 Feb 2004 12:47:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: multiplay.co.uk, Mon, 16 Feb 2004 12:38:29 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 12:48:02 -0000 If that's the case doesn't look like its being detected. Is it disabled in the bios? Steve ----- Original Message ----- From: "Ganbold" To: Sent: Monday, February 16, 2004 12:05 PM Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current > Yes I installed Realtek card because FreeBSD doesn't recognize onboard card. > It has onboard TP connector same as Redhat machine has. > > Ganbold ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 05:10:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C77E116A4CE; Mon, 16 Feb 2004 05:10:07 -0800 (PST) Received: from relay1.ntu-kpi.kiev.ua (noc.ntu-kpi.kiev.ua [195.245.194.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6897F43D1D; Mon, 16 Feb 2004 05:10:07 -0800 (PST) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (unknown [10.0.1.184]) by relay1.ntu-kpi.kiev.ua (Postfix) with ESMTP id 8640917BE6C; Mon, 16 Feb 2004 15:10:05 +0200 (EET) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)i1GFCItv044212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2004 15:12:18 GMT Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id A62E52B3; Mon, 16 Feb 2004 15:09:58 +0200 (EET) Date: Mon, 16 Feb 2004 15:09:58 +0200 From: Andrey Simonenko To: freebsd-hackers@freebsd.org Message-ID: <20040216130958.GC304@pm514-9.comsys.ntu-kpi.kiev.ua> References: <20040213090838.GA221@pm514-9.comsys.ntu-kpi.kiev.ua> <200402140249.i1E2ns8R001417@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402140249.i1E2ns8R001417@green.homeunix.org> User-Agent: Mutt/1.4.1i Subject: Re: Changing v_op for vnode on the fly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 13:10:08 -0000 On Fri, Feb 13, 2004 at 09:49:53PM -0500, Brian F. Feldman wrote: > Andrey Simonenko wrote: > > > > Is it enough to get exclusive lock on vnode, before changing > > v_op pointer? Here is my code: > > > > vn_lock(cvp->vp, LK_EXCLUSIVE | LK_RETRY, p); > > > > if (flag > 0) > > cvp->vp->v_op = catch_vnode_vnodeop_p; /* My vnodeop_p. */ > > else > > cvp->vp->v_op = cvp->vnodeop_p; /* Original v_op. */ > > > > VOP_UNLOCK(cvp->vp, 0, p); > > > > I made some tests and see that most of VOP_xxx require lock (shared > > or exclusive) on vnode, as well this is documented in the manual pages. > > No, you are not allowed to change v_op, ever. Can you do what you're trying > to do in the MAC framework? It seems like that is what you want to be > doing! The other possibility is using something like umapfs/lomacfs/ > unionfs. > First of all thanks for your answer. I need to control activities on vnode not for protecting it from processes. I try to find a way to synchronize shared access (read, write, mmap'ed file) to existent vnode (vnode which is currently is used on home host by local processes) from process on remote hosts. This situation is like NFS, but NFS (or similar systems) has own vnode operation vector for their vnodes and can synchronize access in their VOPs. Since in my situation vnodes can have different vnode operation vectors (i.e. files can belong to different VFS) I can't set v_op for vnode when vnode is created (getnewvnode()). Having read documentation and analyzed sources, I think that MAC can't help. MAC allows to synchronize access in read() and write() syscalls, but access to VOP_GETPAGES, which is called in vm_fault() for example, can't be synchronized using MAC framework. File systems umapfs, lomacfs, unionfs also don't help. May be it is possible to do something with stackable VFS, but I haven't find a solution with stackable VFS yet. What can be broken when v_op is changed during holding exclusive lock on vnode? Does a moment when v_op is changed can cause any problems? Currently I found that nullfs and uniofs will not work if v_op is changed, because they compare v_op with their vnodeop_p. Thanks for your help again. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 08:42:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AADD816A4CE for ; Sun, 15 Feb 2004 08:42:31 -0800 (PST) Received: from mail.teleri.net (teleri.net [216.193.194.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id A462343D1D for ; Sun, 15 Feb 2004 08:42:31 -0800 (PST) (envelope-from trent@teleri.net) Received: by mail.teleri.net (Postfix, from userid 1010) id 22D911144D; Sun, 15 Feb 2004 10:42:31 -0600 (CST) Date: Sun, 15 Feb 2004 08:42:31 -0800 From: Trent Nelson To: freebsd-hackers@freebsd.org Message-ID: <20040215164231.GA54709@teleri.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Mon, 16 Feb 2004 05:40:28 -0800 Subject: Branch prediction X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 16:42:31 -0000 For as long as I've been programming, I've always been under the impression that CPUs will always predict a branch as being false the first time they come across it. Many, many years ago, I came across a DEC programming guide that said the same thing. It suggested using 'do { } while()' over 'while() {}' for loops as this ensured that the loop block was correctly pre-fetched (rather than whatever followed the loop) the first time the branch was encountered. To this day, I still write all my code in this fashion. I was wondering, have either CPU architectures or compilers improved over time such that this isn't an issue anymore? Are CPUs able to intelligently predict a branch the first time they encounter it? Do compilers re-order blocks to optimise pre-fetching and minimise branch mis-prediction? With CPUs like the P4 -- with it's 20-something stage pipeline -- branch mis-prediction is expensive. I realise certain CPUs optimise their branch prediction units by maintaining branch prediction histories, which would help when a branch is encoun- tered repeatedly, but does the old adage of "always predict false" still hold true the first time a branch is encountered? So, writing code such that the "true" branch is intended to be executed far less than what comes after it; good practice or pointless habit? Regards, Trent. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 09:05:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8311916A4CE for ; Sun, 15 Feb 2004 09:05:30 -0800 (PST) Received: from hotmail.com (bay12-f55.bay12.hotmail.com [64.4.35.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B8D243D1F for ; Sun, 15 Feb 2004 09:05:30 -0800 (PST) (envelope-from jtumani55@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 15 Feb 2004 09:05:30 -0800 Received: from 161.44.73.245 by by12fd.bay12.hotmail.msn.com with HTTP; Sun, 15 Feb 2004 17:05:30 GMT X-Originating-IP: [161.44.73.245] X-Originating-Email: [jtumani55@hotmail.com] X-Sender: jtumani55@hotmail.com From: "Juan Tumani" To: freebsd-hackers@freebsd.org Date: Sun, 15 Feb 2004 12:05:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Feb 2004 17:05:30.0449 (UTC) FILETIME=[EA8A2C10:01C3F3E5] X-Mailman-Approved-At: Mon, 16 Feb 2004 05:40:28 -0800 Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2004 17:05:30 -0000 We did some more experiments and when we compiled the object file on 5.2 then linked it on the 4.9 machine and then ran it on the 5.2 machine, there was no cyclical problem seen (Frankenstein run). Kind of points to the 5.2 link stage, i.e., 5.2 libraries? Check out the graphical exhibits at http://www.employees.org/~rsargent/flops/ The graph at the very bottom shows the Frankenstein run. The graphs depict the /usr/bin/time results of running 300 iterations of flops 1.2 while incrementing the env one byte between iterations. I use flops 1.2, it runs less modules than 2.0 but still exhibits the cyclical slowness [alignment] problem as module #2 in flops 2.0. Source code for flops 1.2 is at the bottom of the above link. Juan >From: Alexandr Kovalenko >To: Wes Peters >CC: Juan Tumani , freebsd-hackers@freebsd.org >Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s >gcc2.9.5) >Date: Sat, 14 Feb 2004 10:24:21 +0200 > >Hello, Wes Peters! > >On Tue, Feb 10, 2004 at 11:29:34AM -0800, you wrote: > > > On Monday 09 February 2004 13:20, Juan Tumani wrote: > > > I have an Intel D845GE m/b w/ a P4 1.7 CPU and I have the box setup > > > to dual boot to either 4.9 or 5.2. Both OS are right off the latest > > > posted iso CD image, i.e., no updates, no kernel tweaks, everything > > > vanilla right out of the box. I compiled flops.c on both 4.9 and > > > 5.2 and the 5.2 performance is less than half that of 4.9: 760 > > > MFLOPS on 4.9 v/s 340 MFLOPS on 5.2. > > > > > > I tried turning off the SMP and other kernel tweaks and no > > > improvement in 5.2. I then downloaded and installed gcc295 on the > > > 5.2 machine and that fixed the problem. So now all I have to do is > > > figure out the gcc 3.3.3 switches to make it run like gcc 2.9.5 or > > > figure out how to rebuild 5.2 w/ gcc 2.9.5 :-). > > > > I'm not sure that kernel tweaks are going to make much difference on a > > single-threaded floating point benchmark. Compiler optimizations sure > > do, though. (Note: I couldn't find version 1.2 of flops.c, so this is > > based on version 2.0.) On a 2.0GHz P4, I see: > > > > wpeters@salty> cc -o flops -O -DUNIX flops.c > >Could you please explain me this? Result is fully reproduceable. Please >note, >that the only difference is the output file name. Even resulting files >match >bit-to-bit. If I do > >mv very-slow-flops flops2 > >and then run ./flops2, it runs as flops2 - fast. > >Machine is Dual 2.8 GHz Xeon with HTT disabled (in BIOS). FreeBSD is >5.2.1-RC2. > >%fetch http://home.iae.nl/users/mhx/flops.c >Receiving flops.c (34942 bytes): 100% >34942 bytes transferred in 0.6 seconds (54.72 kBps) >%cc -o flops2 -O2 -mcpu=pentium4 -DUNIX flops.c >flops.c: In function `main': >flops.c:174: warning: return type of `main' is not `int' >%cc -o flops-sse-4 -O2 -mcpu=pentium4 -DUNIX flops.c >flops.c: In function `main': >flops.c:174: warning: return type of `main' is not `int' >%cc -o very-slow-flops -O2 -mcpu=pentium4 -DUNIX flops.c >flops.c: In function `main': >flops.c:174: warning: return type of `main' is not `int' >%./flops2 > > FLOPS C Program (Double Precision), V2.0 18 Dec 1992 > > Module Error RunTime MFLOPS > (usec) > 1 4.0146e-13 0.0130 1074.8815 > 2 -1.4166e-13 0.0128 545.3338 > 3 4.7184e-14 0.0177 960.4579 > 4 -1.2557e-13 0.0166 903.6914 > 5 -1.3800e-13 0.0317 915.0687 > 6 3.2380e-13 0.0310 936.3149 > 7 -8.4583e-11 0.0403 297.7250 > 8 3.4867e-13 0.0310 968.6112 > > Iterations = 512000000 > NullTime (usec) = 0.0006 > MFLOPS(1) = 635.0698 > MFLOPS(2) = 560.4516 > MFLOPS(3) = 805.4502 > MFLOPS(4) = 945.5219 > >%./flops-sse-4 > > FLOPS C Program (Double Precision), V2.0 18 Dec 1992 > > Module Error RunTime MFLOPS > (usec) > 1 4.0146e-13 0.0177 791.6075 > 2 -1.4166e-13 0.0309 226.7944 > 3 4.7184e-14 0.0202 842.7146 > 4 -1.2557e-13 0.0166 902.8921 > 5 -1.3800e-13 0.0317 916.2631 > 6 3.2380e-13 0.0309 937.0923 > 7 -8.4583e-11 0.0403 297.9173 > 8 3.4867e-13 0.0309 969.3446 > > Iterations = 512000000 > NullTime (usec) = 0.0006 > MFLOPS(1) = 297.9983 > MFLOPS(2) = 546.3944 > MFLOPS(3) = 775.3701 > MFLOPS(4) = 922.1566 > >%./very-slow-flops > > FLOPS C Program (Double Precision), V2.0 18 Dec 1992 > > Module Error RunTime MFLOPS > (usec) > 1 4.0146e-13 0.0317 442.0039 > 2 -1.4166e-13 0.0331 211.3728 > 3 4.7184e-14 0.0350 485.1899 > 4 -1.2557e-13 0.0168 892.8307 > 5 -1.3800e-13 0.0319 909.7385 > 6 3.2380e-13 0.0311 931.1527 > 7 -8.4583e-11 0.0405 296.4570 > 8 3.4867e-13 0.0312 962.3224 > > Iterations = 512000000 > NullTime (usec) = 0.0004 > MFLOPS(1) = 259.1938 > MFLOPS(2) = 492.7930 > MFLOPS(3) = 669.1527 > MFLOPS(4) = 797.1471 > >-- >NEVE-RIPE, will build world for food >Ukrainian FreeBSD User Group >http://uafug.org.ua/ _________________________________________________________________ Find great local high-speed Internet access value at the MSN High-Speed Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 15 19:54:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5EB816A4CE for ; Sun, 15 Feb 2004 19:54:26 -0800 (PST) Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE56A43D1F for ; Sun, 15 Feb 2004 19:54:26 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (887afddb0dab63bb592d9a03c63df388@adsl-67-119-53-169.dsl.lsan03.pacbell.net [67.119.53.169]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i1G3rIhF017365; Sun, 15 Feb 2004 19:53:29 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AB2AF66D0E; Sun, 15 Feb 2004 19:54:12 -0800 (PST) Date: Sun, 15 Feb 2004 19:54:12 -0800 From: Kris Kennaway To: Wes Peters Message-ID: <20040216035412.GA70593@xor.obsecurity.org> References: <20040214082420.GB77411@nevermind.kiev.ua> <200402160352.16477.wes@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <200402160352.16477.wes@softweyr.com> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Mon, 16 Feb 2004 05:40:28 -0800 cc: Dag-Erling Sm?rgrav cc: Juan Tumani cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 03:54:26 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: > On Sunday 15 February 2004 12:46, Dag-Erling Sm?rgrav wrote: > > Alexandr Kovalenko writes: > > > Could you please explain me this? Result is fully reproduceable. Plea= se > > > note, that the only difference is the output file name. Even resulting > > > files match bit-to-bit. [...] > > > > Definitely some kind of alignment problem, but it only shows up at > > some optimization levels and not others. >=20 > I've tested the patch Dan mentioned before and the results were astonishi= ng. =20 > Running the flops.c 1.2 program in a loop, lengthening the environment st= ring=20 > by one byte each time, I get 8 successive runs of fast, then 8 successive= =20 > runs of slow, where fast and slow vary between 650 and 990 mflops. With = the=20 > patch, the performance is always 990, within a few percent. >=20 > Should I commit this? What effect does it have on non-i386 architectures? Kris --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAMD7kWry0BWjoQKURAqk0AKCQKvboUsykiATe1L3fdZixEHkE5gCdGXSl R974BIIGfx8in4rCOfbkUqA= =a2WA -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 05:51:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD09C16A4CE for ; Mon, 16 Feb 2004 05:51:30 -0800 (PST) Received: from tx0.oucs.ox.ac.uk (tx0.oucs.ox.ac.uk [129.67.1.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B746B43D1F for ; Mon, 16 Feb 2004 05:51:30 -0800 (PST) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan0.oucs.ox.ac.uk ([129.67.1.162] helo=localhost) by tx0.oucs.ox.ac.uk with esmtp (Exim 4.24) id 1Asj9l-0001wn-Fp for freebsd-hackers@freebsd.org; Mon, 16 Feb 2004 13:51:29 +0000 Received: from rx0.oucs.ox.ac.uk ([129.67.1.161]) by localhost (scan0.oucs.ox.ac.uk [129.67.1.162]) (amavisd-new, port 25) with ESMTP id 07203-07 for ; Mon, 16 Feb 2004 13:51:29 +0000 (GMT) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx0.oucs.ox.ac.uk with smtp (Exim 4.24) id 1Asj9l-0001wc-2H for freebsd-hackers@freebsd.org; Mon, 16 Feb 2004 13:51:29 +0000 Received: (qmail 31321 invoked by uid 0); 16 Feb 2004 13:51:29 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.16 (sweep: 2.14/3.71. spamassassin: 2.53. Clear:. Processed in 1.763373 secs); 16 Feb 2004 13:51:29 -0000 X-Qmail-Scanner-Mail-From: colin.percival@wadham.ox.ac.uk via gateway X-Qmail-Scanner: 1.16 (Clear:. Processed in 1.763373 secs) Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 16 Feb 2004 13:51:27 -0000 Message-Id: <6.0.1.1.1.20040216134828.0390bfa0@imap.sfu.ca> X-Sender: cperciva@imap.sfu.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 16 Feb 2004 13:51:25 +0000 To: Trent Nelson From: Colin Percival In-Reply-To: <20040215164231.GA54709@teleri.net> References: <20040215164231.GA54709@teleri.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: Branch prediction X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 13:51:31 -0000 At 16:42 15/02/2004, Trent Nelson wrote: >does the old adage of "always predict >false" still hold true the first time a branch is encountered? Most processors predict that forward branches are not taken, and backward branches are taken (since backward branches occur most often in loops). Of course, some processors now have hints (conditional-jump- which-is-usually-taken, conditional-jump-which-is-usually-not- taken, etc.) Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 05:54:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67A4416A4CE for ; Mon, 16 Feb 2004 05:54:47 -0800 (PST) Received: from mail.amarand.org (mail.amarand.org [24.106.108.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2691A43D1F for ; Mon, 16 Feb 2004 05:54:47 -0800 (PST) (envelope-from freebsd@amarand.org) Received: from mail.amarand.org (localhost.amarand.org [127.0.0.1]) by mail.amarand.org (8.12.8/8.12.8) with ESMTP id i1GDsfui010520; Mon, 16 Feb 2004 08:54:41 -0500 Received: from localhost (freebsd@localhost)i1GDscDU010516; Mon, 16 Feb 2004 08:54:38 -0500 Date: Mon, 16 Feb 2004 08:54:38 -0500 (EST) From: freebsd@amarand.org To: freebsd-hackers@freebsd.org In-Reply-To: <20040216113703.GA51000@atrbg11.informatik.tu-muenchen.de> Message-ID: References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> <6.0.3.0.2.20040216184426.02970990@202.179.0.80> <20040216113703.GA51000@atrbg11.informatik.tu-muenchen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Ganbold Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 13:54:47 -0000 On Mon, 16 Feb 2004, Daniel Lang wrote: > Hi, > > Ganbold wrote on Mon, Feb 16, 2004 at 06:45:39PM +0800: > [..] > > rl0@pci0:4:0: class=0x020000 card=0x9207103c chip=0x12111113 rev=0x10 > > hdr=0x00 > > vendor = 'Accton Technology Corporation' > > device = 'EN-1207D Fast Ethernet Adapter' > > class = network > > subclass = ethernet > [..] > > This is the only probed Ethernet device and it seems rl driver > has already attached to it. > > I know that DELL servers can be equipped with an em NIC > optionally, maybe this is the case for your second machine. > > You should check the connectors on the back, if there is an > additional TP or SX port (I think the Pro/1000 is SX only). > If your RedHat machine has the SX port, but your other one > doesn't, that would solve the mystery, wouldn't it? Hopefully no one has mentioned this already, but if the network connector is there on the back next to the USB ports, did you ensure that it was enabled in the BIOS? I have a PowerEdge 400SC with the exact same internal Gigabit chipset and, although it was enabled by default on this machine, YMMV. Just something to check if you haven't already.... --Sean From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 06:06:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63BD416A4CE for ; Mon, 16 Feb 2004 06:06:28 -0800 (PST) Received: from hotmail.com (bay12-f74.bay12.hotmail.com [64.4.35.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D25D43D1D for ; Mon, 16 Feb 2004 06:06:28 -0800 (PST) (envelope-from jtumani55@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Feb 2004 06:06:28 -0800 Received: from 161.44.73.245 by by12fd.bay12.hotmail.msn.com with HTTP; Mon, 16 Feb 2004 14:06:27 GMT X-Originating-IP: [161.44.73.245] X-Originating-Email: [jtumani55@hotmail.com] X-Sender: jtumani55@hotmail.com From: "Juan Tumani" To: wes@softweyr.com Date: Mon, 16 Feb 2004 09:06:27 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Feb 2004 14:06:28.0242 (UTC) FILETIME=[12193720:01C3F496] cc: freebsd-hackers@freebsd.org cc: des@des.no Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 14:06:28 -0000 Hi Wes, How many mflops do you get if on your 5.2 machine you run a flops that was compiled -static on 4.9 ? My tests show the speed more than doubles. Thanks- JT >From: Wes Peters >To: des@des.no (Dag-Erling Smørgrav),Alexandr Kovalenko > >CC: freebsd-hackers@freebsd.org, Juan Tumani >Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 >v/sgcc2.9.5) >Date: Mon, 16 Feb 2004 03:52:16 -0800 >MIME-Version: 1.0 >Received: from mx2.freebsd.org ([216.136.204.119]) by mc9-f9.hotmail.com >with Microsoft SMTPSVC(5.0.2195.6824); Sun, 15 Feb 2004 19:52:44 -0800 >Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18])by >mx2.freebsd.org (Postfix) with ESMTPid B8559565B0; Sun, 15 Feb 2004 >19:51:57 -0800 (PST)(envelope-from owner-freebsd-hackers@freebsd.org) >Received: from hub.freebsd.org (localhost [127.0.0.1])by hub.freebsd.org >(Postfix) with ESMTPid 6CDEE16A50C; Sun, 15 Feb 2004 19:51:53 -0800 (PST) >Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])by >hub.freebsd.org (Postfix) with ESMTP id B429316A4CEfor >;Sun, 15 Feb 2004 19:51:30 -0800 (PST) >Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26])by >mx1.FreeBSD.org (Postfix) with ESMTP id AAF9243D1Dfor >;Sun, 15 Feb 2004 19:51:30 -0800 >(PST)(envelope-from wes@softweyr.com) >Received: from 204.68.178.129 (66-91-236-204.san.rr.com [66.91.236.204])by >smtp-relay.omnis.com (Postfix) with ESMTPid 463A78836A3; Sun, 15 Feb 2004 >19:51:26 -0800 (PST) >X-Message-Info: EoYTbT2lH2OyKE31GpCEKyiRPPOIBbCy >Delivered-To: freebsd-hackers@freebsd.org >User-Agent: KMail/1.5.4 >References: ><20040214082420.GB77411@nevermind.kiev.ua> > >In-Reply-To: >Message-Id: <200402160352.16477.wes@softweyr.com> >X-BeenThere: freebsd-hackers@freebsd.org >X-Mailman-Version: 2.1.1 >Precedence: list >List-Id: Technical Discussions relating to >FreeBSD >List-Unsubscribe: >, >List-Archive: >List-Post: >List-Help: >List-Subscribe: >, >Errors-To: owner-freebsd-hackers@freebsd.org >Return-Path: owner-freebsd-hackers@freebsd.org >X-OriginalArrivalTime: 16 Feb 2004 03:52:45.0036 (UTC) >FILETIME=[55C1E2C0:01C3F440] > >On Sunday 15 February 2004 12:46, Dag-Erling Smørgrav wrote: > > Alexandr Kovalenko writes: > > > Could you please explain me this? Result is fully reproduceable. >Please > > > note, that the only difference is the output file name. Even resulting > > > files match bit-to-bit. [...] > > > > Definitely some kind of alignment problem, but it only shows up at > > some optimization levels and not others. > >I've tested the patch Dan mentioned before and the results were >astonishing. >Running the flops.c 1.2 program in a loop, lengthening the environment >string >by one byte each time, I get 8 successive runs of fast, then 8 successive >runs of slow, where fast and slow vary between 650 and 990 mflops. With >the >patch, the performance is always 990, within a few percent. > >Should I commit this? > >RCS file: /big/ncvs/src/sys/kern/kern_exec.c,v >retrieving revision 1.235 >diff -u -w -r1.235 kern_exec.c >--- kern_exec.c 28 Dec 2003 04:37:59 -0000 1.235 >+++ kern_exec.c 11 Feb 2004 16:47:28 -0000 >@@ -1014,6 +1014,15 @@ > */ > vectp = (char **)(destp - (imgp->argc + imgp->envc + 2) * > sizeof(char *)); >+ >+ /* >+ * Align stack to a multiple of 0x20. >+ * XXX vectp has the wrong type; we usually want a vm_offset_t; >+ * the suword() family takes a void *, but should take a >vm_offset_t. >+ * XXX should align stack for signals too. >+ * XXX should do this more machine/compiler-independently. >+ */ >+ vectp = (char **)(((vm_offset_t)vectp & ~(vm_offset_t)0x1F) - 4); > > /* > * vectp also becomes our initial stack base > > >-- > "Where am I, and what am I doing in this handbasket?" > >Wes Peters Softweyr LLC >wes@softweyr.com http://softweyr.com/ > >_______________________________________________ >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" _________________________________________________________________ Let the advanced features & services of MSN Internet Software maximize your online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:11:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64C2D16A4CE for ; Mon, 16 Feb 2004 10:11:25 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3400E43D1D for ; Mon, 16 Feb 2004 10:11:25 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 740CB5309; Mon, 16 Feb 2004 19:11:23 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id EDFD65308; Mon, 16 Feb 2004 19:11:16 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 8A58233C6F; Mon, 16 Feb 2004 19:11:16 +0100 (CET) To: Kris Kennaway References: <20040214082420.GB77411@nevermind.kiev.ua> <200402160352.16477.wes@softweyr.com> <20040216035412.GA70593@xor.obsecurity.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Mon, 16 Feb 2004 19:11:16 +0100 In-Reply-To: <20040216035412.GA70593@xor.obsecurity.org> (Kris Kennaway's message of "Sun, 15 Feb 2004 19:54:12 -0800") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: Juan Tumani cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:11:25 -0000 Kris Kennaway writes: > On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: > > Should I commit this? > What effect does it have on non-i386 architectures? It can't possibly hurt. If the stack is already aligned on a "better" boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary since 64 and 128 are multiples of 32, and the patch is a no-op. If only a 16-byte alignment is required, a 32-byte alignment wastes a small amount of memory but does not hurt performance. I believe that less-than-16 (and possibly even less-than-32) alignment is pessimal on all platforms we support. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:29:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE84316A4CE for ; Mon, 16 Feb 2004 10:29:42 -0800 (PST) Received: from mail.dgap.mipt.ru (dgap-gw.mipt.ru [194.85.81.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D14243D1D for ; Mon, 16 Feb 2004 10:29:39 -0800 (PST) (envelope-from andrew@nas.dgap.mipt.ru) Received: (qmail 11468 invoked from network); 16 Feb 2004 18:29:37 -0000 Received: from unknown (HELO nas.dgap.mipt.ru) ([194.85.81.203]) (envelope-sender ) by dgap-gw.mipt.ru (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2004 18:29:37 -0000 Received: from nas.dgap.mipt.ru (localhost [127.0.0.1]) by nas.dgap.mipt.ru (8.12.8p2/8.12.8) with ESMTP id i1GITbLU075702 for ; Mon, 16 Feb 2004 21:29:37 +0300 (MSK) (envelope-from andrew@nas.dgap.mipt.ru) Received: (from andrew@localhost) by nas.dgap.mipt.ru (8.12.8p2/8.12.8/Submit) id i1GITb0K075701 for hackers@freebsd.org; Mon, 16 Feb 2004 21:29:37 +0300 (MSK) Date: Mon, 16 Feb 2004 21:29:37 +0300 From: "Andrew L. Neporada" To: hackers@freebsd.org Message-ID: <20040216182937.GA75325@nas.dgap.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: maximum mfsroot size limit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:29:42 -0000 Hi. I have a problem with very large mfsroot filesystems in FreeBSD-4.9. 100Mb mfsroot fs boots and works fine, but 128Mb fs with the same content cause immediate reboot after 'Booting kernel in xxx seconds' line. Kernel config is GENERIC minus some unneeded things. Box with 1Gb of RAM is booting from IDE flash device (DiskOnChip). I've tried to bump MD_NSECT, but it doesn't make any difference. Andrew. P.S. I'm sorry if I am asking in the wrong list. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:33:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFB2116A4CE for ; Mon, 16 Feb 2004 10:33:37 -0800 (PST) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6054F43D2D for ; Mon, 16 Feb 2004 10:33:37 -0800 (PST) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 2-md50000000139.tmp for ; Mon, 16 Feb 2004 18:24:01 +0000 Message-ID: <031a01c3f4bb$50b1d800$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Kris Kennaway" , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20040214082420.GB77411@nevermind.kiev.ua> <200402160352.16477.wes@softweyr.com><20040216035412.GA70593@xor.obsecurity.org> Date: Mon, 16 Feb 2004 18:33:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: multiplay.co.uk, Mon, 16 Feb 2004 18:24:01 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org cc: freebsd-hackers@freebsd.org cc: Juan Tumani Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:33:37 -0000 Some interesting finding there what if any are the impacts for performance in real life applications? Steve ----- Original Message ----- From: "Dag-Erling Smørgrav" Kris Kennaway writes: > On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: > > Should I commit this? > What effect does it have on non-i386 architectures? It can't possibly hurt. If the stack is already aligned on a "better" boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary since 64 and 128 are multiples of 32, and the patch is a no-op. If only a 16-byte alignment is required, a 32-byte alignment wastes a small amount of memory but does not hurt performance. I believe that less-than-16 (and possibly even less-than-32) alignment is pessimal on all platforms we support. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:44:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D6FD16A4CE for ; Mon, 16 Feb 2004 10:44:36 -0800 (PST) Received: from hotmail.com (bay12-f28.bay12.hotmail.com [64.4.35.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94F2543D1D for ; Mon, 16 Feb 2004 10:44:36 -0800 (PST) (envelope-from jtumani55@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Feb 2004 10:44:29 -0800 Received: from 161.44.73.245 by by12fd.bay12.hotmail.msn.com with HTTP; Mon, 16 Feb 2004 18:44:29 GMT X-Originating-IP: [161.44.73.245] X-Originating-Email: [jtumani55@hotmail.com] X-Sender: jtumani55@hotmail.com From: "Juan Tumani" To: wes@softweyr.com, des@des.no, never@nevermind.kiev.ua Date: Mon, 16 Feb 2004 13:44:29 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Feb 2004 18:44:29.0301 (UTC) FILETIME=[E8C8D250:01C3F4BC] cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:44:36 -0000 Wes, I patched in the patch shown below and it didn't fix the problem, it only changed the frequency of the spikes to 32 on/off. Please see the second chart at this URL: http://www.employees.org/~rsargent/flops/charts2.html Did you run the script [long enuf] to see what frequency you experience with the kern pacthed on your system? JT >From: Wes Peters >To: des@des.no (Dag-Erling Smørgrav),Alexandr Kovalenko > >CC: freebsd-hackers@freebsd.org, Juan Tumani >Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 >v/sgcc2.9.5) >Date: Mon, 16 Feb 2004 03:52:16 -0800 > >On Sunday 15 February 2004 12:46, Dag-Erling Smørgrav wrote: > > Alexandr Kovalenko writes: > > > Could you please explain me this? Result is fully reproduceable. >Please > > > note, that the only difference is the output file name. Even resulting > > > files match bit-to-bit. [...] > > > > Definitely some kind of alignment problem, but it only shows up at > > some optimization levels and not others. > >I've tested the patch Dan mentioned before and the results were >astonishing. >Running the flops.c 1.2 program in a loop, lengthening the environment >string >by one byte each time, I get 8 successive runs of fast, then 8 successive >runs of slow, where fast and slow vary between 650 and 990 mflops. With >the >patch, the performance is always 990, within a few percent. > >Should I commit this? > >RCS file: /big/ncvs/src/sys/kern/kern_exec.c,v >retrieving revision 1.235 >diff -u -w -r1.235 kern_exec.c >--- kern_exec.c 28 Dec 2003 04:37:59 -0000 1.235 >+++ kern_exec.c 11 Feb 2004 16:47:28 -0000 >@@ -1014,6 +1014,15 @@ > */ > vectp = (char **)(destp - (imgp->argc + imgp->envc + 2) * > sizeof(char *)); >+ >+ /* >+ * Align stack to a multiple of 0x20. >+ * XXX vectp has the wrong type; we usually want a vm_offset_t; >+ * the suword() family takes a void *, but should take a >vm_offset_t. >+ * XXX should align stack for signals too. >+ * XXX should do this more machine/compiler-independently. >+ */ >+ vectp = (char **)(((vm_offset_t)vectp & ~(vm_offset_t)0x1F) - 4); > > /* > * vectp also becomes our initial stack base > > >-- > "Where am I, and what am I doing in this handbasket?" > >Wes Peters Softweyr LLC >wes@softweyr.com http://softweyr.com/ > >_______________________________________________ >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" _________________________________________________________________ Click here for a FREE online computer virus scan from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:47:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF09A16A4CE for ; Mon, 16 Feb 2004 10:47:36 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF53843D1F for ; Mon, 16 Feb 2004 10:47:36 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id BBF675309; Mon, 16 Feb 2004 19:47:35 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 78E295308; Mon, 16 Feb 2004 19:47:29 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id F22CD33C6F; Mon, 16 Feb 2004 19:47:28 +0100 (CET) To: "Juan Tumani" References: From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Mon, 16 Feb 2004 19:47:28 +0100 In-Reply-To: (Juan Tumani's message of "Mon, 16 Feb 2004 13:44:29 -0500") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.63 cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:47:37 -0000 "Juan Tumani" writes: > I patched in the patch shown below and it didn't fix the problem, it > only changed the frequency of the spikes to 32 on/off. try replacing 0x1F with 0x3F in the patch and see what happens. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:48:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 41A2D16A4CE; Mon, 16 Feb 2004 10:48:24 -0800 (PST) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.10/8.12.9) with ESMTP id i1GImKpe075445; Mon, 16 Feb 2004 13:48:20 -0500 (EST) (envelope-from green@green.homeunix.org) Received: from localhost (green@localhost)i1GImJIg075442; Mon, 16 Feb 2004 13:48:20 -0500 (EST) Message-Id: <200402161848.i1GImJIg075442@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Andrey Simonenko In-Reply-To: Message from Andrey Simonenko <20040216130958.GC304@pm514-9.comsys.ntu-kpi.kiev.ua> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Feb 2004 13:48:19 -0500 Sender: green@green.homeunix.org cc: freebsd-hackers@freebsd.org Subject: Re: Changing v_op for vnode on the fly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:48:24 -0000 Andrey Simonenko wrote: > On Fri, Feb 13, 2004 at 09:49:53PM -0500, Brian F. Feldman wrote: > > Andrey Simonenko wrote: > > > > > > Is it enough to get exclusive lock on vnode, before changing > > > v_op pointer? Here is my code: > > > > > > vn_lock(cvp->vp, LK_EXCLUSIVE | LK_RETRY, p); > > > > > > if (flag > 0) > > > cvp->vp->v_op = catch_vnode_vnodeop_p; /* My vnodeop_p. */ > > > else > > > cvp->vp->v_op = cvp->vnodeop_p; /* Original v_op. */ > > > > > > VOP_UNLOCK(cvp->vp, 0, p); > > > > > > I made some tests and see that most of VOP_xxx require lock (shared > > > or exclusive) on vnode, as well this is documented in the manual pages. > > > > No, you are not allowed to change v_op, ever. Can you do what you're trying > > to do in the MAC framework? It seems like that is what you want to be > > doing! The other possibility is using something like umapfs/lomacfs/ > > unionfs. > > > > First of all thanks for your answer. > > I need to control activities on vnode not for protecting it from > processes. I try to find a way to synchronize shared access (read, > write, mmap'ed file) to existent vnode (vnode which is currently is > used on home host by local processes) from process on remote hosts. > > This situation is like NFS, but NFS (or similar systems) has own > vnode operation vector for their vnodes and can synchronize access > in their VOPs. Since in my situation vnodes can have different vnode > operation vectors (i.e. files can belong to different VFS) I can't > set v_op for vnode when vnode is created (getnewvnode()). > > Having read documentation and analyzed sources, I think that MAC can't > help. MAC allows to synchronize access in read() and write() syscalls, > but access to VOP_GETPAGES, which is called in vm_fault() for example, > can't be synchronized using MAC framework. Well, there is the ability to prevent the mmap(2) in the first place using mac_check_vnode_mmap(). Is that close to sufficient for those purposes? > File systems umapfs, lomacfs, unionfs also don't help. May be it is > possible to do something with stackable VFS, but I haven't find > a solution with stackable VFS yet. Try to look closer at them; I think it's possible to do a lot of what you want because the initial LOMAC implementation for FreeBSD, before the MAC framework existed, did just such a thing. > What can be broken when v_op is changed during holding exclusive > lock on vnode? Does a moment when v_op is changed can cause any problems? > Currently I found that nullfs and uniofs will not work if v_op is changed, > because they compare v_op with their vnodeop_p. The thing that you're missing if you just modify v_op is synchronization for each vnode's v_op field for VOP_*() calls. In short, there is no synchronization for that field at all (if you ignore the special-cased Giant). In some cases, this matters -- in others, it doesn't -- so if you don't actually add any new fields to the vnode then changing the v_op might work reasonably well for some filesystems (the ones that don't actually examine the value of v_op). Happy to help, -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:54:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37F1816A4CE for ; Mon, 16 Feb 2004 10:54:48 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C558B43D1F for ; Mon, 16 Feb 2004 10:54:47 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i1GIskkX043592; Mon, 16 Feb 2004 10:54:47 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <403111F6.2040505@acm.org> Date: Mon, 16 Feb 2004 10:54:46 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Trent Nelson References: <20040215164231.GA54709@teleri.net> In-Reply-To: <20040215164231.GA54709@teleri.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Branch prediction X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:54:48 -0000 Trent Nelson wrote: > For as long as I've been programming, I've always been under the > impression that CPUs will always predict a branch as being false > the first time they come across it. The state of the art has advanced considerably since then. > Many, many years ago, I came across a DEC programming guide that > said the same thing. It suggested using 'do { } while()' over > 'while() {}' for loops as this ensured that the loop block was > correctly pre-fetched (rather than whatever followed the loop) > the first time the branch was encountered. That must have been a long time ago. while() {} loops routinely get compiled as: bra condition_check looptop: <... body of loop ...> condition: <... test condition ...> bcc looptop: A 'do' loop differs only in omitting the initial forward branch. Since this is an unconditional forward branch, it's always correctly predicted. ;-) Thus, as a practical matter, there's no performance difference between do/while and while. > ... have either CPU architectures or compilers improved > over time such that this isn't an issue anymore? Are CPUs able > to intelligently predict a branch the first time they encounter > it? Do compilers re-order blocks to optimise pre-fetching and > minimise branch mis-prediction? Yes, compilers re-order blocks. I once spent a couple of weeks trying to hand-assemble some code to run faster than the compiler. I was only able to accomplish it if there were particular processor features (SIMD instructions or explicit prefetch) that the compiler was unaware of. For serial C code, the compilers are pretty smart these days. In particular, modern instruction sets allow the compiler to specify whether the branch should be default-taken or default-not-taken. Processors contain "branch history" that can detect and record certain common patterns (e.g., "branch is not taken every third time") to improve prediction. (This history is maintained as long as the branch remains in the instruction cache, and can be very effective for tight inner loops.) If there are no compiler hints and no branch history, I think Colin was right: default taken for backward branches (assume loops happen) default not taken for forward branches (assume if tests succeed). Practically speaking, I find it very rarely worth the trouble of trying to predict this sort of thing unless you're dealing with unusually performance-critical code. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:59:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C01B716A4CE for ; Mon, 16 Feb 2004 10:59:48 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5DE5D43D1F for ; Mon, 16 Feb 2004 10:59:48 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 42955 invoked from network); 16 Feb 2004 18:59:47 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 16 Feb 2004 18:59:47 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 16 Feb 2004 12:59:45 -0600 (CST) From: Mike Silbersack To: Ganbold In-Reply-To: <6.0.3.0.2.20040216184426.02970990@202.179.0.80> Message-ID: <20040216125810.F2262@odysseus.silby.com> References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> <6.0.3.0.2.20040216184426.02970990@202.179.0.80> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:59:48 -0000 On Mon, 16 Feb 2004, Ganbold wrote: > Hi, > > Following is the output of pciconf -lv command: As others have pointed out, the problem isn't in the em driver, since the card isn't even showing up in pciconf. Either it's somehow not enabled, or FreeBSD isn't detecting the PCI bridge that the card is connected to. If you're running in ACPI mode, I suggest that you try running without ACPI and see if that changes anything. Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 11:06:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3CA616A4CE for ; Mon, 16 Feb 2004 11:06:12 -0800 (PST) Received: from tx1.oucs.ox.ac.uk (tx1.oucs.ox.ac.uk [129.67.1.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE4C543D1F for ; Mon, 16 Feb 2004 11:06:12 -0800 (PST) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan1.oucs.ox.ac.uk ([129.67.1.166] helo=localhost) by tx1.oucs.ox.ac.uk with esmtp (Exim 4.24) id 1Aso4J-0002Wm-Iw for hackers@freebsd.org; Mon, 16 Feb 2004 19:06:11 +0000 Received: from rx1.oucs.ox.ac.uk ([129.67.1.165]) by localhost (scan1.oucs.ox.ac.uk [129.67.1.166]) (amavisd-new, port 25) with ESMTP id 09596-02 for ; Mon, 16 Feb 2004 19:06:11 +0000 (GMT) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx1.oucs.ox.ac.uk with smtp (Exim 4.24) id 1Aso4J-0002Wf-5X for hackers@freebsd.org; Mon, 16 Feb 2004 19:06:11 +0000 Received: (qmail 25676 invoked by uid 0); 16 Feb 2004 19:06:11 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.16 (sweep: 2.14/3.71. spamassassin: 2.53. Clear:. Processed in 1.485482 secs); 16 Feb 2004 19:06:11 -0000 X-Qmail-Scanner-Mail-From: colin.percival@wadham.ox.ac.uk via gateway X-Qmail-Scanner: 1.16 (Clear:. Processed in 1.485482 secs) Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 16 Feb 2004 19:06:10 -0000 Message-Id: <6.0.1.1.1.20040216185516.039bd6b0@imap.sfu.ca> X-Sender: cperciva@imap.sfu.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 16 Feb 2004 19:06:07 +0000 To: "Andrew L. Neporada" From: Colin Percival In-Reply-To: <20040216182937.GA75325@nas.dgap.mipt.ru> References: <20040216182937.GA75325@nas.dgap.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: hackers@freebsd.org Subject: Re: maximum mfsroot size limit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 19:06:12 -0000 At 18:29 16/02/2004, Andrew L. Neporada wrote: >I have a problem with very large mfsroot filesystems in FreeBSD-4.9. >100Mb mfsroot fs boots and works fine, but 128Mb fs with the same >content cause immediate reboot after 'Booting kernel in xxx seconds' >line. Increase the value of NKPT in src/sys/i386/include/pmap.h. Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 11:34:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E37E316A4CE for ; Mon, 16 Feb 2004 11:34:06 -0800 (PST) Received: from hotmail.com (bay12-f35.bay12.hotmail.com [64.4.35.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF0B243D1D for ; Mon, 16 Feb 2004 11:34:06 -0800 (PST) (envelope-from jtumani55@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Feb 2004 11:34:06 -0800 Received: from 161.44.73.245 by by12fd.bay12.hotmail.msn.com with HTTP; Mon, 16 Feb 2004 19:34:06 GMT X-Originating-IP: [161.44.73.245] X-Originating-Email: [jtumani55@hotmail.com] X-Sender: jtumani55@hotmail.com From: "Juan Tumani" To: des@des.no Date: Mon, 16 Feb 2004 14:34:06 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Feb 2004 19:34:06.0784 (UTC) FILETIME=[D780AC00:01C3F4C3] cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 19:34:07 -0000 >"Juan Tumani" writes: > > I patched in the patch shown below and it didn't fix the problem, it > > only changed the frequency of the spikes to 32 on/off. > >try replacing 0x1F with 0x3F in the patch and see what happens. That seems to work in that it flattens the line out. Not sure why programs linked in 4.9 don't need the alignment fix in 5.2. Also, if you compare the 'floor' shown in the first 2 charts (as well as the last chart) at: http://www.employees.org/~rsargent/flops/ with the 3rd chart at: http://www.employees.org/~rsargent/flops/charts2.html you can see the program is more than twice as fast when linked in FreeBSD 4.9 than when linked in 5.2 as shown by the floor being 1.25 seconds/iteration for 4.9 linking v/s 2.96 seconds/iteration for 5.2 linking (on my ref machine). Any ideas, things to try, linker options in 5.2? Thanks- JT _________________________________________________________________ Choose now from 4 levels of MSN Hotmail Extra Storage - no more account overload! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 11:58:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A15FE16A4CE for ; Mon, 16 Feb 2004 11:58:08 -0800 (PST) Received: from mail.dgap.mipt.ru (dgap-gw.mipt.ru [194.85.81.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EE0343D1F for ; Mon, 16 Feb 2004 11:58:06 -0800 (PST) (envelope-from andrew@nas.dgap.mipt.ru) Received: (qmail 22201 invoked from network); 16 Feb 2004 19:58:00 -0000 Received: from unknown (HELO nas.dgap.mipt.ru) ([194.85.81.203]) (envelope-sender ) by dgap-gw.mipt.ru (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2004 19:58:00 -0000 Received: from nas.dgap.mipt.ru (localhost [127.0.0.1]) by nas.dgap.mipt.ru (8.12.8p2/8.12.8) with ESMTP id i1GJvxLU076169; Mon, 16 Feb 2004 22:57:59 +0300 (MSK) (envelope-from andrew@nas.dgap.mipt.ru) Received: (from andrew@localhost) by nas.dgap.mipt.ru (8.12.8p2/8.12.8/Submit) id i1GJvxn8076168; Mon, 16 Feb 2004 22:57:59 +0300 (MSK) Date: Mon, 16 Feb 2004 22:57:59 +0300 From: "Andrew L. Neporada" To: Colin Percival Message-ID: <20040216195759.GA76097@nas.dgap.mipt.ru> References: <20040216182937.GA75325@nas.dgap.mipt.ru> <6.0.1.1.1.20040216185516.039bd6b0@imap.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.1.20040216185516.039bd6b0@imap.sfu.ca> User-Agent: Mutt/1.4i cc: hackers@freebsd.org Subject: Re: maximum mfsroot size limit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 19:58:08 -0000 On Mon, Feb 16, 2004 at 07:06:07PM +0000, Colin Percival wrote: > At 18:29 16/02/2004, Andrew L. Neporada wrote: > >I have a problem with very large mfsroot filesystems in FreeBSD-4.9. > >100Mb mfsroot fs boots and works fine, but 128Mb fs with the same > >content cause immediate reboot after 'Booting kernel in xxx seconds' > >line. > > Increase the value of NKPT in src/sys/i386/include/pmap.h. Thanks. Everything works as expected now. > > Colin Percival > Andrew. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 12:17:01 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A993916A4CE for ; Mon, 16 Feb 2004 12:17:01 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E91B43D1D for ; Mon, 16 Feb 2004 12:17:01 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 88C5B653C2; Mon, 16 Feb 2004 20:17:00 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21295-02-5; Mon, 16 Feb 2004 20:17:00 +0000 (GMT) Received: from saboteur.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id B4D62651EE; Mon, 16 Feb 2004 20:16:59 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id DA29D47; Mon, 16 Feb 2004 20:16:58 +0000 (GMT) Date: Mon, 16 Feb 2004 20:16:58 +0000 From: Bruce M Simpson To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040216201658.GE3791@saboteur.dek.spc.org> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Kris Kennaway , Juan Tumani , freebsd-hackers@freebsd.org References: <20040214082420.GB77411@nevermind.kiev.ua> <200402160352.16477.wes@softweyr.com> <20040216035412.GA70593@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: cc: freebsd-hackers@freebsd.org cc: Juan Tumani cc: Kris Kennaway Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 20:17:01 -0000 On Mon, Feb 16, 2004 at 07:11:16PM +0100, Dag-Erling Smørgrav wrote: > It can't possibly hurt. If the stack is already aligned on a "better" > boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary > since 64 and 128 are multiples of 32, and the patch is a no-op. If > only a 16-byte alignment is required, a 32-byte alignment wastes a > small amount of memory but does not hurt performance. I believe that > less-than-16 (and possibly even less-than-32) alignment is pessimal on > all platforms we support. I'm not happy with the patch as-is and would be happier if a cleaner MI-way of expressing this were found. BMS From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 12:20:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6CB616A4CE for ; Mon, 16 Feb 2004 12:20:07 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 761FB43D3F for ; Mon, 16 Feb 2004 12:20:07 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id EB9035309; Mon, 16 Feb 2004 21:20:05 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 1C6ED5308; Mon, 16 Feb 2004 21:19:58 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id B4C7033C6F; Mon, 16 Feb 2004 21:19:57 +0100 (CET) To: Kris Kennaway References: <20040214082420.GB77411@nevermind.kiev.ua> <200402160352.16477.wes@softweyr.com> <20040216035412.GA70593@xor.obsecurity.org> <20040216201658.GE3791@saboteur.dek.spc.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Mon, 16 Feb 2004 21:19:57 +0100 In-Reply-To: <20040216201658.GE3791@saboteur.dek.spc.org> (Bruce M. Simpson's message of "Mon, 16 Feb 2004 20:16:58 +0000") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-hackers@freebsd.org cc: Juan Tumani Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 20:20:07 -0000 Bruce M Simpson writes: > I'm not happy with the patch as-is and would be happier if a cleaner > MI-way of expressing this were found. What exactly is wrong with the patch? (except for the fact that empirical tests show it should align on a 64-byte boundary) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 13:12:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FB7116A4CE for ; Mon, 16 Feb 2004 13:12:18 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59C4943D2D for ; Mon, 16 Feb 2004 13:12:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i1GLCF82087317; Mon, 16 Feb 2004 13:12:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i1GLCFMV087316; Mon, 16 Feb 2004 13:12:15 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Feb 2004 13:12:15 -0800 (PST) From: Matthew Dillon Message-Id: <200402162112.i1GLCFMV087316@apollo.backplane.com> To: "Juan Tumani" References: cc: des@des.no cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 21:12:18 -0000 I'm surprised Bruce hasn't chimed in here yet. I guess he's tired of repeating himself. In 4.9, libcsu, which generates crt1.o (which is the start code for C programs which the linker links in automatically) has this line in it: andl $~0xf, %%esp # align stack to 16-byte boundary So anything linked with 4.9 is going to align the stack on a 16 byte boundary no matter WHAT the kernel does. FreeBSD-5 does not have this alignment in its crt1.o because GCC3 automatically aligns the stack on a per-procedure basis. Or at least it is supposed to. Maybe it's broke? :-) -Matt From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 13:36:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FD4216A4CE for ; Mon, 16 Feb 2004 13:36:35 -0800 (PST) Received: from hotmail.com (bay12-f54.bay12.hotmail.com [64.4.35.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A87743D31 for ; Mon, 16 Feb 2004 13:36:35 -0800 (PST) (envelope-from jtumani55@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Feb 2004 13:36:35 -0800 Received: from 161.44.73.245 by by12fd.bay12.hotmail.msn.com with HTTP; Mon, 16 Feb 2004 21:36:35 GMT X-Originating-IP: [161.44.73.245] X-Originating-Email: [jtumani55@hotmail.com] X-Sender: jtumani55@hotmail.com From: "Juan Tumani" To: dillon@apollo.backplane.com Date: Mon, 16 Feb 2004 16:36:35 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Feb 2004 21:36:35.0283 (UTC) FILETIME=[F38CA230:01C3F4D4] cc: des@des.no cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 21:36:35 -0000 Thanks Matt for picking up on the linker problem. Patching the kernel would, to me, be masking the real problem. What other "improvements" does gcc333 have over gcc295 that might explain why it's linked products run in a half-fast mode (take twice+ as long)? JT >From: Matthew Dillon >To: "Juan Tumani" >CC: des@des.no, freebsd-hackers@freebsd.org >Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance >(gcc3.3.3v/sgcc2.9.5) >Date: Mon, 16 Feb 2004 13:12:15 -0800 (PST) > > I'm surprised Bruce hasn't chimed in here yet. I guess he's tired of > repeating himself. > > In 4.9, libcsu, which generates crt1.o (which is the start code for > C programs which the linker links in automatically) has this line in >it: > > andl $~0xf, %%esp # align stack to 16-byte boundary > > So anything linked with 4.9 is going to align the stack on a > 16 byte boundary no matter WHAT the kernel does. > > FreeBSD-5 does not have this alignment in its crt1.o because GCC3 > automatically aligns the stack on a per-procedure basis. Or at least > it is supposed to. Maybe it's broke? :-) > > -Matt > _________________________________________________________________ Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 14:10:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5319416A4CE for ; Mon, 16 Feb 2004 14:10:16 -0800 (PST) Received: from orange.csi.cam.ac.uk (orange.csi.cam.ac.uk [131.111.8.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AA2243D1D for ; Mon, 16 Feb 2004 14:10:16 -0800 (PST) (envelope-from br260@cam.ac.uk) Received: from br260.wolfson.cam.ac.uk ([131.111.242.109]) by orange.csi.cam.ac.uk with esmtp (Exim 4.12) id 1AsqwR-0004OS-00 for hackers@freebsd.org; Mon, 16 Feb 2004 22:10:15 +0000 Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <0A771943-1DDB-11B2-ADA8-000A9576014E@cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Hackers FreeBSD From: Bin Ren X-Mailer: Apple Mail (2.612) Subject: more info about KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 16 Feb 2004 22:10:16 -0000 X-Original-Date: Thu, 1 Jan 1970 02:04:10 +0100 X-List-Received-Date: Mon, 16 Feb 2004 22:10:16 -0000 Hi, I have two questions: (1) Is there any more detailed information regarding KLD in addition to the KDL facility programming in DaemonNews and in Architecture Book? (2) Can I turn an arbitrary piece of codes in kernel into a KLD? Say, the entire TCP/IP stack? Thanks a lot! -- Bin Ren From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 14:23:22 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D1516A4CE for ; Mon, 16 Feb 2004 14:23:22 -0800 (PST) Received: from newman.gte.com (newman.gte.com [132.197.8.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABAE43D1D for ; Mon, 16 Feb 2004 14:23:22 -0800 (PST) (envelope-from ak03@gte.com) Received: from h132-197-179-27.gte.com (kanpc.gte.com [132.197.179.27]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id RAA01722; Mon, 16 Feb 2004 17:23:21 -0500 (EST) Received: from kanpc.gte.com (localhost [IPv6:::1])i1GMNIed011846; Mon, 16 Feb 2004 17:23:18 -0500 (EST) (envelope-from ak03@gte.com) Date: Mon, 16 Feb 2004 17:23:18 -0500 From: Alexander Kabaev To: "Juan Tumani" Message-Id: <20040216172318.4b76daa2@kanpc.gte.com> In-Reply-To: References: Organization: Verizon Data Services X-Mailer: Sylpheed version 0.9.8claws23 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: des@des.no cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 22:23:23 -0000 On Mon, 16 Feb 2004 16:36:35 -0500 "Juan Tumani" wrote: > Thanks Matt for picking up on the linker problem. Patching the kernel > would, to me, be masking the real problem. > > What other "improvements" does gcc333 have over gcc295 that might > explain why it's linked products run in a half-fast mode (take twice+ > as long)? > > JT > > > >From: Matthew Dillon > >To: "Juan Tumani" > >CC: des@des.no, freebsd-hackers@freebsd.org > >Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance > >(gcc3.3.3v/sgcc2.9.5) > >Date: Mon, 16 Feb 2004 13:12:15 -0800 (PST) > > > > I'm surprised Bruce hasn't chimed in here yet. I guess he's > > tired of repeating himself. > > > > In 4.9, libcsu, which generates crt1.o (which is the start code > > for C programs which the linker links in automatically) has this > > line in > >it: > > > > andl $~0xf, %%esp # align stack to 16-byte > > boundary > > > > So anything linked with 4.9 is going to align the stack on a > > 16 byte boundary no matter WHAT the kernel does. > > > > FreeBSD-5 does not have this alignment in its crt1.o because > > GCC3 automatically aligns the stack on a per-procedure basis. > > Or at least it is supposed to. Maybe it's broke? :-) > > > > -Matt > > Quite possibly. I run the same test using the latest GCC snapshot configured as system compiler and did not see such a massive slowdown. GCC 3.3.3 wins slightly on most tests and loses only on module #2 of the flops.c program posted here. -- Alexander Kabaev From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 15:58:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3145916A4CF for ; Mon, 16 Feb 2004 15:58:49 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1806C43D2F for ; Mon, 16 Feb 2004 15:58:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i1GNwk82088107; Mon, 16 Feb 2004 15:58:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i1GNwkkm088106; Mon, 16 Feb 2004 15:58:46 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Feb 2004 15:58:46 -0800 (PST) From: Matthew Dillon Message-Id: <200402162358.i1GNwkkm088106@apollo.backplane.com> To: "Juan Tumani" References: cc: des@des.no cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 23:58:49 -0000 : :Thanks Matt for picking up on the linker problem. Patching the kernel :would, to me, be masking the real problem. : :What other "improvements" does gcc333 have over gcc295 that might :explain why it's linked products run in a half-fast mode (take twice+ :as long)? : :JT I do not see a 50% loss in performance in my tests, but the GCC3 on DragonFly is a later snapshot (gcc-3.3-20040126). Generally speaking GCC3 does a better job -O2 then GCC2 when I optimize for my Athlon64. (-O2 and -O3 have the same results on GCC3 in my tests). These tests were run on an Athlon 64 3200+, on a DragonFly system of course, (which has both gcc2 and gcc3 in the base system): GCC2 GCC2 GCC2 GCC3 GCC3 GCC3 GCC3 -O -O2 -O2/k6 -O -O2 -O2 -O2 athlon athlon stackbndry=5 MFLOPS(1) 1111 1071 1068 794 926 862 861 MFLOPS(2) 832 818 810 789 825 855 857 MFLOPS(3) 1131 1121 1105 1021 1134 1208 1208 MFLOPS(4) 1306 1356 1350 1156 1346 1460 1456 GCC3 only loses in MFLOPS(1). When I looked at the assembly generated for MFLOPS(1) between GCC2 and GCC3 two things stand out: * GCC2 does a few extra stack-relative memory ops and they are spread out more. GCC3 does fewer memory ops and they are concentrated at the beginning and the end of the loop code. * GCC2 uses fld %st(x) to shift the FP stack around, while GCC3 uses fxch %st(x) to shift the FP stack around. Since we know FP operations are stack-alignment-sensitive I can see how a stack misalignment can result in terrible performance. What is less certain is whether (FP aligned) accesses to *different* data-cache lines effects performance, and that is something that GCC does not seem to optimize. My guess at least in regards to MFLOPS(1), for which GCC3 generates consistently worse results on my machine, is that FXCH (exchange fp reg with top of fp stack) performance is not hardware optimized as well as FLD (load to top of FP stack) performance, at least on my Athlon 64. This also points to the fact that both Intel and AMD have done major reoptimizations of their floating point instruction set in nearly every processor release they've ever done. The performance loss you are seeing on your machine could very well turn into a performance gain on different cpu. On a DELL-2550 I get this: DELL2550 2xPentiumIII @ 1.1GHz GCC2 GCC3 GCC3 GCC3 -O3 -O3 -O3 -O3 -march= (nil) (nil) p3 ppro MFLOPS(1) 380 290 283 283 MFLOPS(2) 302 293 291 291 MFLOPS(3) 454 459 462 463 MFLOPS(4) 563 581 593 593 My guess is that GCC3 introduced a bit of pessimization when they started over-using FXCH and that the MFLOPS(1) code just happens to hit the case due to the huge number of FXCH's it uses. It's probably stalling the instruction pipline in a few more places. -Matt From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 16:18:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FF8016A4E4 for ; Mon, 16 Feb 2004 16:18:39 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3960D43D1D for ; Mon, 16 Feb 2004 16:18:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i1H0Ia82088315; Mon, 16 Feb 2004 16:18:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i1H0IaWd088314; Mon, 16 Feb 2004 16:18:36 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Feb 2004 16:18:36 -0800 (PST) From: Matthew Dillon Message-Id: <200402170018.i1H0IaWd088314@apollo.backplane.com> To: "Juan Tumani" , des@des.no, freebsd-hackers@freebsd.org References: <200402162358.i1GNwkkm088106@apollo.backplane.com> Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 00:18:39 -0000 One last note... if you guys are trying to compile flops.c with the GCC2.95 port it is probably being linked against FreeBSD-5's lib/csu's crt1.o, which does not have the stack alignment. Original 4.9-compiled binaries will have been linked against 4.9's crt1.o, which DOES have the stack alignment. Modifying kern_exec.c is not the right solution, I don't think. Adding some basic alignment back into crt1.o (like 4.9 has) would be a reasonable solution. In DragonFly I kept 4.9's alignment code in lib/csu's crt1.c, and I will be keeping it in there even when we wholely switch to gcc3 at some future date. It doesn't hurt anything and I don't like 'assuming' that GCC will always be used for C compiling. -Matt From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 16:26:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A98416A4CF for ; Mon, 16 Feb 2004 16:26:50 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5683943D1D for ; Mon, 16 Feb 2004 16:26:49 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 8475 invoked by uid 65534); 17 Feb 2004 00:26:48 -0000 Received: from p508E6BFD.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.142.107.253) by mail.gmx.net (mp002) with SMTP; 17 Feb 2004 01:26:48 +0100 X-Authenticated: #5374206 Received: by rota (Postfix, from userid 1001) id 841D796; Tue, 17 Feb 2004 01:26:49 +0100 (CET) Date: Tue, 17 Feb 2004 01:26:49 +0100 From: Thomas Moestl To: freebsd-hackers@freebsd.org Message-ID: <20040217002649.GA5185@timesink.dyndns.org> References: <20040214082420.GB77411@nevermind.kiev.ua> <200402160352.16477.wes@softweyr.com> <20040216035412.GA70593@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.6i Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 00:26:50 -0000 On Mon, 2004/02/16 at 19:11:16 +0100, Dag-Erling Smørgrav wrote: > Kris Kennaway writes: > > On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote: > > > Should I commit this? > > What effect does it have on non-i386 architectures? > > It can't possibly hurt. If the stack is already aligned on a "better" > boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary > since 64 and 128 are multiples of 32, and the patch is a no-op. If > only a 16-byte alignment is required, a 32-byte alignment wastes a > small amount of memory but does not hurt performance. I believe that > less-than-16 (and possibly even less-than-32) alignment is pessimal on > all platforms we support. Well, it misaligns stack_base on 64-bit architectures, for example (notice the "- 4", which is there to compensate for the fixup in kern_execve() that will subtract another sizeof(register_t)): vectp = (char **)(((vm_offset_t)vectp & ~(vm_offset_t)0x1F) - 4); It would by much better to be able to align the stack in exec_setregs(), like amd64, ia64, powerpc and sparc64 do. Unfortunately that would require changes to crt1, so it would pose a compatibility problem. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ "Oh, great altar of passive entertainment... Bestow upon me thy discordant images at such speed as to render linear thought impossible!" -- Calvin and Hobbes From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 17:00:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D51DB16A4CE for ; Mon, 16 Feb 2004 17:00:09 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5095543D1D for ; Mon, 16 Feb 2004 17:00:09 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i1H0xvkX045275; Mon, 16 Feb 2004 16:59:58 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <4031678D.2060704@acm.org> Date: Mon, 16 Feb 2004 16:59:57 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <200402162112.i1GLCFMV087316@apollo.backplane.com> In-Reply-To: <200402162112.i1GLCFMV087316@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: des@des.no cc: Juan Tumani cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 01:00:09 -0000 Matthew Dillon wrote: > I'm surprised Bruce hasn't chimed in here yet. I guess he's tired of > repeating himself. > > In 4.9, libcsu, which generates crt1.o (which is the start code for > C programs which the linker links in automatically) has this line in it: > > andl $~0xf, %%esp # align stack to 16-byte boundary > > So anything linked with 4.9 is going to align the stack on a > 16 byte boundary no matter WHAT the kernel does. > > FreeBSD-5 does not have this alignment in its crt1.o because GCC3 > automatically aligns the stack on a per-procedure basis. Or at least > it is supposed to. Maybe it's broke? :-) I've not looked at 3.3, but I seem to recall that GCC 3.2 did not actually align the stack within each function, but preserved the alignment. (That is, each function assumed the stack had a certain alignment on entry and ensured that alignment was preserved for any subsequent function calls.) I had my doubts about this, as it meant there was a LOT of stack fiddling before and after every function call. (The alignment was handled at caller, not callee. A lot of functions don't need any alignment at all, really, so it seems like it could be wasted effort in a lot of cases.) If I'm remembering this correctly, then aligning the stack in crt1.o would be pretty much essential. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 17:52:10 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 071FE16A4CE for ; Mon, 16 Feb 2004 17:52:10 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E791A43D1D for ; Mon, 16 Feb 2004 17:52:09 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i1H1q582088727; Mon, 16 Feb 2004 17:52:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i1H1q44u088726; Mon, 16 Feb 2004 17:52:04 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Feb 2004 17:52:04 -0800 (PST) From: Matthew Dillon Message-Id: <200402170152.i1H1q44u088726@apollo.backplane.com> To: kientzle@acm.org References: <200402162112.i1GLCFMV087316@apollo.backplane.com> <4031678D.2060704@acm.org> cc: des@des.no cc: Juan Tumani cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 01:52:10 -0000 :I've not looked at 3.3, but I seem to recall that GCC 3.2 :did not actually align the stack within each function, but :preserved the alignment. (That is, each function assumed the stack :had a certain alignment on entry and ensured that alignment :was preserved for any subsequent function calls.) Easy to test... ah, ok. 3.3 aligns the stack in main(). main: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp <<<<< ailgns stack here andl 0xfffffff0,%esp ... And the preserves the alignment in other procedures... 8 + ebp + retaddr is 16 bytes: charlie: pushl %ebp movl %esp, %ebp subl $8, %esp /* I declared 'volatile int x' as a stack var */ call fubar call fubar call fubar leave ret :If I'm remembering this correctly, then aligning :the stack in crt1.o would be pretty much essential. : :Tim Kientzle For gcc 2.95, yes. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 18:54:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F79216A4CE for ; Mon, 16 Feb 2004 18:54:57 -0800 (PST) Received: from hotmail.com (bay12-f102.bay12.hotmail.com [64.4.35.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B28D43D1D for ; Mon, 16 Feb 2004 18:54:57 -0800 (PST) (envelope-from jtumani55@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Feb 2004 18:54:57 -0800 Received: from 161.44.73.245 by by12fd.bay12.hotmail.msn.com with HTTP; Tue, 17 Feb 2004 02:54:57 GMT X-Originating-IP: [161.44.73.245] X-Originating-Email: [jtumani55@hotmail.com] X-Sender: jtumani55@hotmail.com From: "Juan Tumani" To: dillon@apollo.backplane.com Date: Mon, 16 Feb 2004 21:54:57 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Feb 2004 02:54:57.0417 (UTC) FILETIME=[6D4EF790:01C3F501] cc: des@des.no cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3v/sgcc2.9.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 02:54:57 -0000 I just downloaded gcc33 (20040202) and it does not need the kern_exec.c hack. Thanks for your cycles. JT _________________________________________________________________ Get some great ideas here for your sweetheart on Valentine's Day - and beyond. http://special.msn.com/network/celebrateromance.armx From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 19:37:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4897716A4CE for ; Mon, 16 Feb 2004 19:37:03 -0800 (PST) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30DD843D1D for ; Mon, 16 Feb 2004 19:37:03 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 21408 invoked from network); 17 Feb 2004 03:37:02 -0000 Received: from dsl017-045-168.spk4.dsl.speakeasy.net (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Feb 2004 03:37:02 -0000 Received: from hydrogen.funkthat.com (zmjktu@localhost.funkthat.com [127.0.0.1])i1H3ax7Y066559; Mon, 16 Feb 2004 19:36:59 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i1H3avqe066558; Mon, 16 Feb 2004 19:36:57 -0800 (PST) Date: Mon, 16 Feb 2004 19:36:57 -0800 From: John-Mark Gurney To: Bin Ren Message-ID: <20040217033657.GG85686@funkthat.com> Mail-Followup-To: Bin Ren , Hackers FreeBSD References: <0A771943-1DDB-11B2-ADA8-000A9576014E@cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A771943-1DDB-11B2-ADA8-000A9576014E@cam.ac.uk> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Hackers FreeBSD Subject: Re: more info about KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 03:37:03 -0000 Bin Ren wrote this message on Thu, Jan 01, 1970 at 02:04 +0100: Might want to run ntpdate on your machine... > I have two questions: > (1) Is there any more detailed information regarding KLD in > addition to the KDL facility programming in DaemonNews > and in Architecture Book? have you checked the kernel developers handbook.. > (2) Can I turn an arbitrary piece of codes in kernel into a KLD? > Say, the entire TCP/IP stack? Yes, for the most part you can. Though you may limited on when you can load/unload the code. The tcp/ip stack may be a bit difficult as it has interdependancies on other parts, like ipv6... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 19:56:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B12216A4CE for ; Mon, 16 Feb 2004 19:56:55 -0800 (PST) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id D989143D1D for ; Mon, 16 Feb 2004 19:56:54 -0800 (PST) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with asmtp (Exim 4.30; FreeBSD) id 1AswGp-0004N7-S1; Tue, 17 Feb 2004 11:51:39 +0800 Message-Id: <6.0.3.0.2.20040217115243.02acb520@202.179.0.80> X-Sender: ganbold@micom.mng.net@202.179.0.80 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 17 Feb 2004 11:59:08 +0800 To: Mike Silbersack From: Ganbold In-Reply-To: <20040216125810.F2262@odysseus.silby.com> References: <6.0.3.0.2.20040216181316.029c0cf0@202.179.0.80> <6.0.3.0.2.20040216184426.02970990@202.179.0.80> <20040216125810.F2262@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 03:56:55 -0000 Hi Mike and all, I found the problem with the Intel PRO/1000 card. I looked in the BIOS and it says NO MAC address! I even reset BIOS but no results. It seems like onboard Intel card is broken or malfunctioning. I told the owner to change Dell server to another. Thanks for all who tried to help me and suggested ideas. Ganbold At 02:59 AM 17.02.2004, you wrote: >On Mon, 16 Feb 2004, Ganbold wrote: > > > Hi, > > > > Following is the output of pciconf -lv command: > >As others have pointed out, the problem isn't in the em driver, since the >card isn't even showing up in pciconf. Either it's somehow not enabled, >or FreeBSD isn't detecting the PCI bridge that the card is connected to. >If you're running in ACPI mode, I suggest that you try running without >ACPI and see if that changes anything. > >Mike "Silby" Silbersack >_______________________________________________ >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 Feb 17 01:05:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AD0116A4CE for ; Tue, 17 Feb 2004 01:05:44 -0800 (PST) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C9BE43D1D for ; Tue, 17 Feb 2004 01:05:43 -0800 (PST) (envelope-from takawata@axe-inc.co.jp) Received: from localhost (localhost [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id SAA27653 for ; Tue, 17 Feb 2004 18:05:42 +0900 (JST) Message-Id: <200402170905.SAA27653@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost [127.0.0.1] didn't use HELO protocol To: hackers@freebsd.org From: takawata@jp.freebsd.org In-reply-to: Your message of "Mon, 16 Feb 2004 19:36:57 PST." <20040217033657.GG85686@funkthat.com> Date: Tue, 17 Feb 2004 18:05:42 +0900 Sender: takawata@axe-inc.co.jp Subject: Re: more info about KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 09:05:44 -0000 In message <20040217033657.GG85686@funkthat.com>, John-Mark Gurney wrote: >> I have two questions: >> (1) Is there any more detailed information regarding KLD in >> addition to the KDL facility programming in DaemonNews >> and in Architecture Book? > >have you checked the kernel developers handbook.. > >> (2) Can I turn an arbitrary piece of codes in kernel into a KLD? >> Say, the entire TCP/IP stack? > >Yes, for the most part you can. Though you may limited on when you >can load/unload the code. The tcp/ip stack may be a bit difficult as >it has interdependancies on other parts, like ipv6... It may have some problem when the code is initialized early or using #ifdef. Kernel modules are loaded by loader(8) or kldload(2). When kernel module should be initialized early, the module have to be loaded by loader(8). The loaded module is linked in kernel boot sequence after VM initialzied. Another thing, #ifdef is interpreted on compiling. If there are some code like this, the FUGAFUGA option cannot turn into module. INET option is this example. switch(foo){ case BAR: hehehe(); break; #ifdef FUGAFUGA case BAZ: function_in_fugafuga(); break; #endif default: } From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 17 02:06:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EF4716A4CE for ; Tue, 17 Feb 2004 02:06:13 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-2-18.dsl.pltn13.pacbell.net [68.122.2.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3417C43D1F for ; Tue, 17 Feb 2004 02:06:12 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i1HA6AER003193; Tue, 17 Feb 2004 02:06:10 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i1HA6AiU003192; Tue, 17 Feb 2004 02:06:10 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Tue, 17 Feb 2004 02:06:10 -0800 From: David Schultz To: Trent Nelson Message-ID: <20040217100610.GA2961@VARK.homeunix.com> Mail-Followup-To: Trent Nelson , freebsd-hackers@FreeBSD.ORG References: <20040215164231.GA54709@teleri.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040215164231.GA54709@teleri.net> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Branch prediction X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 10:06:13 -0000 On Sun, Feb 15, 2004, Trent Nelson wrote: > For as long as I've been programming, I've always been under the > impression that CPUs will always predict a branch as being false > the first time they come across it. > > Many, many years ago, I came across a DEC programming guide that > said the same thing. It suggested using 'do { } while()' over > 'while() {}' for loops as this ensured that the loop block was > correctly pre-fetched (rather than whatever followed the loop) > the first time the branch was encountered. > > To this day, I still write all my code in this fashion. I was > wondering, have either CPU architectures or compilers improved > over time such that this isn't an issue anymore? Are CPUs able > to intelligently predict a branch the first time they encounter > it? Do compilers re-order blocks to optimise pre-fetching and > minimise branch mis-prediction? > > With CPUs like the P4 -- with it's 20-something stage pipeline > -- branch mis-prediction is expensive. I realise certain CPUs > optimise their branch prediction units by maintaining branch > prediction histories, which would help when a branch is encoun- > tered repeatedly, but does the old adage of "always predict > false" still hold true the first time a branch is encountered? > > So, writing code such that the "true" branch is intended to be > executed far less than what comes after it; good practice or > pointless habit? Both CPUs and compilers have evolved considerably since then, largely because modern processors such as the Pentium 4 have such long pipelines. Typically processors have branch history tables with accuracy in the 95% to 99% range for many applications, although there's a wide range of ways to implement these. Some processors rely on per-branch patterns, some use global patterns, and some use combinations of the two. Here are two good papers on the topic: Marius Evers, Sanjay J. Patel, Robert S. Chappell, and Yale N. Patt, "Analysis of Correlation and Predictability: What Makes Two-Level Branch Predictors Work," Proceedings of the International Symposium on Computer Architecture (ISCA-25), June 1998 Tse-Yu Yeh and Yale Patt, "Alternative Implementations of Two-level Adaptive Branch Prediction", Proceedings of the International Symposium on Computer Architecture (ISCA), 1992. Heuristics such as ``always predict false'' are uncommon. The first time a branch is encountered, many processors choose to predict taken for backwards branches (because of loops) and predict not taken for forwards branches. However, branches that are not in the history cache make up a very small proportion of all branches encountered, and thus have only a modest impact on performance. Compilers are also pretty smart these days, and have been for quite some time. A good compiler will do the loop unrolling, software pipelining, blocking, prefetching, and instruction scheduling necessary to get good performance regardless of how you write your loops. Of course, in the specific case of 'while () {}' versus 'do { } while ()' the two loops do not have exactly the same semantics; the former *requires* the compiler to perform the test before entering the loop for the first time unless it can prove the test unnecessary. But chances are that this will be a forward branch that is correctly predicted, so the cost will be only a cycle or two. Of course, the compiler doesn't always know what your code is going to do at runtime, so it can't always make the best optimizations. Some commercial compilers can use profiling data generated at runtime to perform better optimizations. In gcc, you can use the builtins __builtin_expect(test, 1) and __builtin_expect(test, 0) for performance-critical code. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 17 02:23:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DB2516A4CE for ; Tue, 17 Feb 2004 02:23:13 -0800 (PST) Received: from yellow.csi.cam.ac.uk (yellow.csi.cam.ac.uk [131.111.8.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EA943D1F for ; Tue, 17 Feb 2004 02:23:13 -0800 (PST) (envelope-from br260@cam.ac.uk) Received: from br260.wolfson.cam.ac.uk ([131.111.242.109]) by yellow.csi.cam.ac.uk with esmtp (Exim 4.12) id 1At2Nk-0000CH-00 for hackers@freebsd.org; Tue, 17 Feb 2004 10:23:12 +0000 Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <4A1C3989-6133-11D8-91F3-000A9576014E@cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Hackers FreeBSD From: Bin Ren Date: Tue, 17 Feb 2004 10:23:12 +0000 X-Mailer: Apple Mail (2.612) Subject: pin a subsystem to a CPU X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 10:23:13 -0000 Hi, I'm thinking about whether it's possible and how to pin a subsystem of kernel, from a particular driver (such as software RAID) to TCP network stack, to a particular CPU. In other words, I have dual processors and how can I make one of the CPU JUST runs TCP stack so as to increase network throughput? Shall I turn the piece of codes into a kernel thread? Then how hard is it? Thanks a lot! -- Bin From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 11:50:40 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E9516A4CE for ; Mon, 16 Feb 2004 11:50:40 -0800 (PST) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9B1243D6B for ; Mon, 16 Feb 2004 11:50:40 -0800 (PST) (envelope-from mikulas@artax.karlin.mff.cuni.cz) Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 17421) id 282B0408C; Mon, 16 Feb 2004 20:50:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by artax.karlin.mff.cuni.cz (Postfix) with ESMTP id 278D03F92 for ; Mon, 16 Feb 2004 20:50:39 +0100 (CET) Date: Mon, 16 Feb 2004 20:50:39 +0100 (CET) From: Mikulas Patocka To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 17 Feb 2004 06:06:23 -0800 Subject: signed char bug in regexp library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 19:50:41 -0000 Hi I ripped regexp library from FreeBSD 4 and use it in another program. I get random crashes because the library casts char to int and uses it as array index ... the most obvious case is engine.i:189: register char *dp; dp += charjump[(int)*dp]; but there are many more and I'm unable to spot them all. When i compile library with -funsigned-char, it works fine. But it isn't compiled with that flag in FreeBSD. Mikulas From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 17 06:22:28 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 008DA16A4CE for ; Tue, 17 Feb 2004 06:22:28 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 3B34443D1D for ; Tue, 17 Feb 2004 06:22:27 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Feb 2004 14:22:26 +0000 (GMT) Date: Tue, 17 Feb 2004 14:22:26 +0000 From: David Malone To: Mikulas Patocka Message-ID: <20040217142225.GA83796@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: signed char bug in regexp library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 14:22:28 -0000 On Mon, Feb 16, 2004 at 08:50:39PM +0100, Mikulas Patocka wrote: > When i compile library with -funsigned-char, it works fine. But it isn't > compiled with that flag in FreeBSD. The signedness of chars is left as a choice for the compiler - on the platform you are working on they must have decided to use signed chars. David. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 17 10:11:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1D0016A4CE for ; Tue, 17 Feb 2004 10:11:12 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A94443D1D for ; Tue, 17 Feb 2004 10:11:12 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i1HIB5kX050276; Tue, 17 Feb 2004 10:11:09 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <40325939.6000104@acm.org> Date: Tue, 17 Feb 2004 10:11:05 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mikulas Patocka References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: signed char bug in regexp library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 18:11:12 -0000 Mikulas Patocka wrote: > Hi > > I ripped regexp library from FreeBSD 4 and use it in another program. I > get random crashes because the library casts char to int and uses it as > array index ... the most obvious case is engine.i:189: > register char *dp; > dp += charjump[(int)*dp]; > but there are many more and I'm unable to spot them all. > > When i compile library with -funsigned-char, it works fine. But it isn't > compiled with that flag in FreeBSD. Mikulas, Could you verify that programs in FreeBSD 4 crash because of this? That would provide incentive to get it fixed. One easy fix, by the way, is: dp += charjump[(int)(unsigned char)*dp]; For what it's worth, the code probably isn't assuming unsigned characters; it's probably assuming ASCII. ;-) Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 17 10:37:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDB2E16A4CE for ; Tue, 17 Feb 2004 10:37:57 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C2C543D1D for ; Tue, 17 Feb 2004 10:37:57 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i1HIbrkX050446; Tue, 17 Feb 2004 10:37:54 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <40325F81.502@acm.org> Date: Tue, 17 Feb 2004 10:37:53 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mikulas Patocka References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: signed char bug in regexp library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 18:37:57 -0000 Mikulas Patocka wrote: > Hi > > I ripped regexp library from FreeBSD 4 and use it in another program. I > get random crashes because the library casts char to int and uses it as > array index ... the most obvious case is engine.i:189: > register char *dp; > dp += charjump[(int)*dp]; > but there are many more and I'm unable to spot them all. This problem was fixed in 2000 by offsetting the array so that accesses such as the above work correctly. A key part of the fix is this line in regcomp.c: g->charjump = &g->charjump[-(CHAR_MIN)]; Here's the log entry: ---------------------------- revision 1.20 date: 2000/07/07 07:46:36; author: dcs; state: Exp; lines: +6 -4 Deal with the signed/unsigned chars issue in a more proper manner. We use a CHAR_MIN-based array, like elsewhere in the code. Remove a number of unused variables (some due to the above change, one that was left after a number of optimizing steps through the source). Brucified by: bde ---------------------------- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 17 16:13:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54EB416A4CE for ; Tue, 17 Feb 2004 16:13:12 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id B948B43D1F for ; Tue, 17 Feb 2004 16:13:11 -0800 (PST) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) i1I0DAG3081184 for ; Wed, 18 Feb 2004 01:13:10 +0100 (CET) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) i1I0DAV1045175 for ; Wed, 18 Feb 2004 01:13:10 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.12.10/8.12.10/Submit) id i1I0DAca045172; Wed, 18 Feb 2004 01:13:10 +0100 (MET) (envelope-from arno) To: freebsd-hackers@freebsd.org From: Arno Date: 18 Feb 2004 01:13:10 +0100 Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Miltered: at shiva.jussieu.fr with ID 4032AE16.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Antivirus: scanned by sophie at shiva.jussieu.fr Subject: vmstat name lookups X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2004 00:13:12 -0000 --=-=-= Hello, is this a correct patch to get rid of the following problem : [vmstat -is : ] ... 4096 bytes per page -1946329673 total name lookups cache hits (-108% pos + -3% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% patch is against -current and output from -stable, but codebase seems to be the same. Thanx, arno --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=vmstat.patch Index: sys/sys/namei.h =================================================================== RCS file: /home/ncvs/src/sys/sys/namei.h,v retrieving revision 1.40 diff -r1.40 namei.h 187,194c187,194 < long ncs_goodhits; /* hits that we can really use */ < long ncs_neghits; /* negative hits that we can use */ < long ncs_badhits; /* hits we must drop */ < long ncs_falsehits; /* hits with id mismatch */ < long ncs_miss; /* misses */ < long ncs_long; /* long names that ignore cache */ < long ncs_pass2; /* names found with passes == 2 */ < long ncs_2passes; /* number of times we attempt it */ --- > u_long ncs_goodhits; /* hits that we can really use */ > u_long ncs_neghits; /* negative hits that we can use */ > u_long ncs_badhits; /* hits we must drop */ > u_long ncs_falsehits; /* hits with id mismatch */ > u_long ncs_miss; /* misses */ > u_long ncs_long; /* long names that ignore cache */ > u_long ncs_pass2; /* names found with passes == 2 */ > u_long ncs_2passes; /* number of times we attempt it */ Index: usr.bin/vmstat/vmstat.c =================================================================== RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.c,v retrieving revision 1.79 diff -r1.79 vmstat.c 160c160 < static long pct(long, long); --- > static u_long pct(u_long, u_long); 680,681c680,681 < static long < pct(long top, long bot) --- > static u_long > pct(u_long top, u_long bot) 683c683 < long ans; --- > u_long ans; 687c687 < ans = (quad_t)top * 100 / bot; --- > ans = (u_quad_t)top * 100 / bot; 697c697 < long nchtotal; --- > u_quad_t nchtotal; --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 17 12:10:19 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 852A716A4EA for ; Tue, 17 Feb 2004 12:10:19 -0800 (PST) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53CF843D1D for ; Tue, 17 Feb 2004 12:10:19 -0800 (PST) (envelope-from mikulas@artax.karlin.mff.cuni.cz) Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 17421) id 5296640A1; Tue, 17 Feb 2004 21:10:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by artax.karlin.mff.cuni.cz (Postfix) with ESMTP id 51EBD408C; Tue, 17 Feb 2004 21:10:17 +0100 (CET) Date: Tue, 17 Feb 2004 21:10:17 +0100 (CET) From: Mikulas Patocka To: Tim Kientzle In-Reply-To: <40325F81.502@acm.org> Message-ID: References: <40325F81.502@acm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 18 Feb 2004 05:39:56 -0800 cc: freebsd-hackers@freebsd.org Subject: Re: signed char bug in regexp library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 20:10:19 -0000 > > Hi > > > > I ripped regexp library from FreeBSD 4 and use it in another program. I > > get random crashes because the library casts char to int and uses it as > > array index ... the most obvious case is engine.i:189: > > register char *dp; > > dp += charjump[(int)*dp]; > > but there are many more and I'm unable to spot them all. > > This problem was fixed in 2000 by offsetting the array > so that accesses such as the above work correctly. > A key part of the fix is this line in regcomp.c: > > g->charjump = &g->charjump[-(CHAR_MIN)]; > > Here's the log entry: > > ---------------------------- > revision 1.20 > date: 2000/07/07 07:46:36; author: dcs; state: Exp; lines: +6 -4 > Deal with the signed/unsigned chars issue in a more proper manner. We > use a CHAR_MIN-based array, like elsewhere in the code. > > Remove a number of unused variables (some due to the above change, one > that was left after a number of optimizing steps through the source). > > Brucified by: bde > ---------------------------- Sorry for bogus bug report --- now I got it. CHAR_MAX was incorrectly defined as (unsigned) type, so loops like int i; for (i = CHAR_MIN; i <= CHAR_MAX; i++) in regexp library didn't work. When I changed CHAR_MAX to signed type, it works fine. Of course it doesn't happen on FreeBSD because it has signed CHAR_MAX. Mikulas From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 18 08:18:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCF7E16A4D0 for ; Wed, 18 Feb 2004 08:18:35 -0800 (PST) Received: from athenas.yan.com.br (athenas.yan.com.br [200.202.253.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 9443B43D31 for ; Wed, 18 Feb 2004 08:18:34 -0800 (PST) (envelope-from ddg@yan.com.br) Received: (qmail 14708 invoked by uid 1023); 18 Feb 2004 13:18:32 -0300 Received: from unknown (HELO pegasus) (ddg@200.202.253.166) by athenas.yan.com.br with SMTP; 18 Feb 2004 13:18:32 -0300 Date: Wed, 18 Feb 2004 10:18:42 -0300 From: Daniel Dias Goncalves To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-bugs@freebsd.org Message-Id: <20040218101842.37dbd067.ddg@yan.com.br> X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Dlink Dwl 520 E1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2004 16:18:36 -0000 I have two wireless device. - Pcmcia Orinoco Wireless Silver 11mbps - Dlink Dwl 520 revision v.E1 FreeBSD 5.2.1-R Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2.1-RC #0: Sat Mar 15 15:59:14 BRT 2003 root@gibson.x86.net:/usr/src/sys/i386/compile/GIBSON Preloaded elf kernel "/boot/kernel/kernel" at 0xc0753000. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P54C (166.40-MHz 586-class CPU) Origin =3D "GenuineIntel" Id =3D 0x52c Stepping =3D 12 Features=3D0x1bf real memory =3D 67108864 (64 MB) avail memory =3D 59830272 (57 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00fd9d0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci_cfgintr: 0:7 INTD BIOS irq 11 pci_cfgintr: 0:8 INTA BIOS irq 10 pci_cfgintr: 0:9 INTA BIOS irq 9 pci_cfgintr: 0:10 INTA BIOS irq 12 pci_cfgintr: 0:11 INTA BIOS irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on= pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 7.2 (no driver attached) pci0: at device 8.0 (no driver attached) cbb0: irq 9 at device 9.0 on pci0 wi0: mem 0xe0410000-0xe0410fff irq 12 at device 10.0 on= pci0 wi0: timeout in wi_cmd 0x0000; event status 0x0000 wi0: wi_cmd: busy bit won't clear. : init failed device_probe_and_attach: wi0 attach returned 6 rl0: port 0x6100-0x61ff mem 0xe0411000-0xe04110= ff irq 11 at device 11.0 on pci0 rl0: Ethernet address: 00:50:fc:5f:c8:80 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: