From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 00:33:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F84016A4CE for ; Sun, 22 Feb 2004 00:33:03 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B0643D1D for ; Sun, 22 Feb 2004 00:33:03 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 603D12A8EB for ; Sun, 22 Feb 2004 00:33:03 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id C79EA2C1AC for ; Sun, 22 Feb 2004 00:33:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1M8X2JK010504; Sun, 22 Feb 2004 00:33:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1M8X1FG010503; Sun, 22 Feb 2004 00:33:01 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 00:33:01 -0800 User-Agent: KMail/1.6 References: <4CC57F17-64E9-11D8-ACAA-000A95BAD088@raisdorf.net> In-Reply-To: <4CC57F17-64E9-11D8-ACAA-000A95BAD088@raisdorf.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402220033.01795.peter@wemm.org> Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 08:33:03 -0000 On Saturday 21 February 2004 07:43 pm, Hendrik Scholz wrote: > On Feb 21, 2004, at 9:59 PM, Christian Weisgerber wrote: > > Why are these shared objects not built with -fPIC in the first > > place? > > Ask the authors of the third party applications :) > Most architectures don't need -fPIC and/or it slows them down (thanks > for the > comment Peter!). Yes, exactly. Some folks thought it would be an idea to add a flag to libtool to force it to link non-pic code into shared libraries. Essentially this reduces the sharability since we do relocations on the text segment, but the flipside is that its faster on i386 and on some libraries they figured it was worth burning extra memory that would be wasted by not using -fPIC. > The ports I've dealt with either use a hand written Makefile without > honoring > CFLAGS set in the environment or without having -fPIC set since i386 > (I guess that > is what most of the guys test and run their stuff on) doesn't need > it. Ports utilizing GNU configure may check if -fPIC is supported but > usually don't > set it since it's not needed on the developers system. The real shame is that the libtool/autoconf tests that attempt to determine if -fpic can be safely left out, are not tripping because the test code they use is too simple and doesn't cause the relocations types to be emitted that cause all the trouble. ie: even the ones that actually test it with autconf aren't doing it right. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 00:36:19 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D66D416A4CE for ; Sun, 22 Feb 2004 00:36:19 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D012843D2D for ; Sun, 22 Feb 2004 00:36:19 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 857412A8EB for ; Sun, 22 Feb 2004 00:36:19 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id E208B2C1AC for ; Sun, 22 Feb 2004 00:36:18 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1M8aIcJ010538; Sun, 22 Feb 2004 00:36:18 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1M8aIjm010537; Sun, 22 Feb 2004 00:36:18 -0800 (PST) (envelope-from peter) From: Peter Wemm To: Jason Lixfeld Date: Sun, 22 Feb 2004 00:36:18 -0800 User-Agent: KMail/1.6 References: <5421F6D2-6446-11D8-8485-000A95989E4A@lixfeld.ca> <200402211230.57825.peter@wemm.org> <249AC6EC-64B6-11D8-8485-000A95989E4A@lixfeld.ca> In-Reply-To: <249AC6EC-64B6-11D8-8485-000A95989E4A@lixfeld.ca> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402220036.18198.peter@wemm.org> cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 + Ports X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 08:36:19 -0000 On Saturday 21 February 2004 01:37 pm, Jason Lixfeld wrote: > On Feb 21, 2004, at 3:30 PM, Peter Wemm wrote: > > Have a look at http://people.freebsd.org/~peter/ezm3-amd64/ > > There are a mountain of diffs and hacks to try and get ezm3 to > > work with gcc on amd64. There is enough there to enable you to > > produce the same binary in the package you downloaded. ie: it will > > blow up with that zlib error. Be sure to put the > > boot-ezm3-1.1-FBSD_AMD64.tar.bs2 into your > > /usr/ports/distfiles/ezm3/ directory because its not in John's dist > > area that the port knows about. > > Thanks for the pointer. I applied the cvsup patch, no problem and > tried to install the ezm3 patch but messed up and kept screwing with > it to the point where the Makefile.orig no longer resembled the > original from the distribution. I need to look around and find the > original Makefile. How does one go about re-downloading the files > for one single port? I'd use CVSUP, but... :) You can use cvsup! We've been trying to tell you.. turn off compression! It'll either be something like '*default compress' if you're using one of the example cvsup files, or the -z flag if you're using the cvsup-mirror kit or the like. I'd try and build a cvsup-without-compression if I knew how to change the cvsup source. I really don't understand the language. Incidently, it makes porting the language compiler really interesting when its written in itself and you don't understand it. :-) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 00:37:30 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C965516A4CE for ; Sun, 22 Feb 2004 00:37:30 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31BF43D2D for ; Sun, 22 Feb 2004 00:37:30 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 9B82D2A8EF for ; Sun, 22 Feb 2004 00:37:30 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 069962C1AF for ; Sun, 22 Feb 2004 00:37:30 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1M8bTNZ010553; Sun, 22 Feb 2004 00:37:29 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1M8bTwN010552; Sun, 22 Feb 2004 00:37:29 -0800 (PST) (envelope-from peter) From: Peter Wemm To: Jason Lixfeld Date: Sun, 22 Feb 2004 00:37:29 -0800 User-Agent: KMail/1.6 References: <5421F6D2-6446-11D8-8485-000A95989E4A@lixfeld.ca> <200402211230.57825.peter@wemm.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402220037.29707.peter@wemm.org> cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 + Ports X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 08:37:30 -0000 On Saturday 21 February 2004 01:41 pm, Jason Lixfeld wrote: > On Feb 21, 2004, at 3:30 PM, Peter Wemm wrote: > > Have a look at http://people.freebsd.org/~peter/ezm3-amd64/ > > There are a mountain of diffs and hacks to try and get ezm3 to > > work with gcc on amd64. There is enough there to enable you to > > produce the same binary in the package you downloaded. ie: it will > > blow up with that zlib error. Be sure to put the > > boot-ezm3-1.1-FBSD_AMD64.tar.bs2 into your > > /usr/ports/distfiles/ezm3/ directory because its not in John's dist > > area that the port knows about. > > One other thing: http://people.freebsd.org/~peter/ezm3-amd64/ has > ezm3-1.1-FBSD_AMD64.tgz. The Makefile calls for > ezm3-${PORTVERSION}-${TARGET}-boot.tar.bz2. Just change the Makefile > to reflect the filename in ~peter, or am I looking in the wrong place > for this file? My mistake, sorry.. Just rename it. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 00:42:55 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCD8416A4CE for ; Sun, 22 Feb 2004 00:42:55 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B488643D1F for ; Sun, 22 Feb 2004 00:42:55 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 82F5E2A8EB for ; Sun, 22 Feb 2004 00:42:55 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 7A2282C1AC for ; Sun, 22 Feb 2004 00:42:54 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1M8gs3e010604; Sun, 22 Feb 2004 00:42:54 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1M8gscO010603; Sun, 22 Feb 2004 00:42:54 -0800 (PST) (envelope-from peter) From: Peter Wemm To: Jason Lixfeld Date: Sun, 22 Feb 2004 00:42:54 -0800 User-Agent: KMail/1.6 References: <5421F6D2-6446-11D8-8485-000A95989E4A@lixfeld.ca> <200402211230.57825.peter@wemm.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402220042.54158.peter@wemm.org> cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 + Ports X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 08:42:55 -0000 On Saturday 21 February 2004 01:41 pm, Jason Lixfeld wrote: > On Feb 21, 2004, at 3:30 PM, Peter Wemm wrote: > > Have a look at http://people.freebsd.org/~peter/ezm3-amd64/ > > There are a mountain of diffs and hacks to try and get ezm3 to > > work with gcc on amd64. There is enough there to enable you to > > produce the same binary in the package you downloaded. ie: it will > > blow up with that zlib error. Be sure to put the > > boot-ezm3-1.1-FBSD_AMD64.tar.bs2 into your > > /usr/ports/distfiles/ezm3/ directory because its not in John's dist > > area that the port knows about. > > One other thing: http://people.freebsd.org/~peter/ezm3-amd64/ has > ezm3-1.1-FBSD_AMD64.tgz. The Makefile calls for > ezm3-${PORTVERSION}-${TARGET}-boot.tar.bz2. Just change the Makefile > to reflect the filename in ~peter, or am I looking in the wrong place > for this file? Hmm. It seems I uploaded the wrong file. I uploaded the one I did on October 24th last year. That was clever, wasn't it? I'm sorry about that, please try again. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 00:57:08 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D6FD16A4CF for ; Sun, 22 Feb 2004 00:57:08 -0800 (PST) Received: from Reineke.Malepartus.DE (reineke.malepartus.de [194.25.4.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DA6B43D1F for ; Sun, 22 Feb 2004 00:57:07 -0800 (PST) (envelope-from bm@Reineke.Malepartus.DE) Received: from Reineke.Malepartus.DE (localhost [127.0.0.1]) by Reineke.Malepartus.DE (8.12.10/8.12.6) with ESMTP id i1M8v1lD047935 for ; Sun, 22 Feb 2004 09:57:01 +0100 (CET) (envelope-from bm@Reineke.Malepartus.DE) Received: (from bm@localhost) by Reineke.Malepartus.DE (8.12.10/8.12.10/Submit) id i1M8v12F047934; Sun, 22 Feb 2004 09:57:01 +0100 (CET) (envelope-from bm) Date: Sun, 22 Feb 2004 09:57:00 +0100 From: Burkard Meyendriesch To: freebsd-amd64@freebsd.org Message-Id: <20040222095700.2c58b1e7.bm@malepartus.de> Organization: The Home of Reineke Fuchs X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i386-portbld-freebsd4.9) X-Face: "[-; ]oI+8gP9>*J%knDN8d%DuhvJS2Lj4L\bRb7gz(pcT?2Zh6_Vam_6csAum3$<&lhAFd^ jt|!&Ut1C~Vg*E/q}+#cbFg-GU]c.bB8Ad,L'W$'9{^0y'AzM4#hS[C[F-1'|O; Kg3Vrq5q6dsU*TmJ@}+QPM\ b[^9Rhd,UoMpRpd5k[X=h.Dom*kbT`cNQ Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Sun__22_Feb_2004_09_57_00_+0100_V7M8I1c59oVQzVk2" X-Malepartus-MailScanner-Information: Please contact the ISP for more information X-Malepartus-MailScanner: Found to be clean Subject: CURRENT: error in "make buildworld" on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 08:57:08 -0000 --Signature=_Sun__22_Feb_2004_09_57_00_+0100_V7M8I1c59oVQzVk2 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi all, yesterday I launched my new box (Asus K8V Deluxe, Athlon64/3000, 1GB ECC RAM, 2x160GB RAID1). I installed 5.2-RELEASE from CD. After that I checked out the actual source tree and tried to "make buildworld". This ends up with: In file included from editline.c:4: /usr/src/lib/libedit/chared.c: In function `ch_init': /usr/src/lib/libedit/chared.c:456: error: `ED_UNASSIGNED' undeclared (first use in this function) /usr/src/lib/libedit/chared.c:456: error: (Each undeclared identifier is reported only once /usr/src/lib/libedit/chared.c:456: error: for each function it appears in.) /usr/src/lib/libedit/chared.c: In function `ch_reset': /usr/src/lib/libedit/chared.c:493: error: `ED_UNASSIGNED' undeclared (first use in this function) ... (lots of similar error messages follow...) What's going wrong? Burkard P.S.: I have no item enabled in /etc/make.conf. -- Burkard Meyendriesch Stevern 2 D-48301 Nottuln --Signature=_Sun__22_Feb_2004_09_57_00_+0100_V7M8I1c59oVQzVk2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkA4btwACgkQcWaHg5BcpatU6wCeOHoIaVw6/48EcRnA+0n4LbBS TBMAoLfnyPiY6cxtneq1WqkBXDhwg210 =AkOq -----END PGP SIGNATURE----- --Signature=_Sun__22_Feb_2004_09_57_00_+0100_V7M8I1c59oVQzVk2-- From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 00:57:39 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C075F16A4D6; Sun, 22 Feb 2004 00:57:39 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B54D643D1F; Sun, 22 Feb 2004 00:57:39 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 90A302A91B; Sun, 22 Feb 2004 00:57:39 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id BEC9D2C1AF; Sun, 22 Feb 2004 00:57:38 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1M8vcSk010755; Sun, 22 Feb 2004 00:57:38 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1M8vaif010754; Sun, 22 Feb 2004 00:57:36 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 00:57:36 -0800 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402220057.36903.peter@wemm.org> cc: amd64@freebsd.org cc: adridg@cs.kun.nl cc: Gerald Pfeifer Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 08:57:39 -0000 On Wednesday 18 February 2004 12:37 am, Gerald Pfeifer wrote: > On Mon, 16 Feb 2004, Adriaan de Groot wrote: > > On Mon, 16 Feb 2004, Gerald Pfeifer wrote: > >> *** Configuration amd64-portbld-freebsd5.2 not supported > >> Configure in /tmp/a/ports/lang/gcc33/work/build/gcc failed, > >> exiting. and my gut tells me someone renamed x86_64 to amd64 > >> somewhere without making proper adjustment in upstream packages or > >> something like that. > > > > From things David and/or Peter have written I've gathered the > > following: > > > > 1) AMD didn't give the platform an official name till fairly late > > 2) Some folks chose amd64 > > 3) Later the muttonheads at the FSF chose x86_64 > > And right they were. See yesterdays press announcement by Intel. That sequence of events isn't quite right. AMD originally came up with x86-64. When Microsoft got going on the port, they said "that name sucks to type, how about amd64? We're NOT using x86=64". And so it became "amd64" or AMD64. And FWIW, I agree. x86_64 is the worst possible name to type. I suspect the x86-64 name was chosen to make it a less bitter pill for Intel to pick it up (after all, thats what cross licensing agreements are for). However, Intel haven't chosen either of the two names.. They've done their own one. "IA-32e" was mentioned several times at the IDF this week. The preview winxp-64 ISO released from microsoft 2 weeks ago has got a hal.dll that does a strcmp for "AuthenticAMD" and "GenuineIntel". (see for yourself, do a cabextract on /amd64/hal.dl_). All over the system, from top to bottom, its called 'amd64' - except for the top level human visible stuff. I'll be suprised if they do a global search/replace at this stage, especially since their last few compiler releases etc know thats what its called and use amd64 in their ifdefs. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 00:57:39 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C075F16A4D6; Sun, 22 Feb 2004 00:57:39 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B54D643D1F; Sun, 22 Feb 2004 00:57:39 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 90A302A91B; Sun, 22 Feb 2004 00:57:39 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id BEC9D2C1AF; Sun, 22 Feb 2004 00:57:38 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1M8vcSk010755; Sun, 22 Feb 2004 00:57:38 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1M8vaif010754; Sun, 22 Feb 2004 00:57:36 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 00:57:36 -0800 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402220057.36903.peter@wemm.org> cc: amd64@freebsd.org cc: adridg@cs.kun.nl cc: Gerald Pfeifer Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 08:57:40 -0000 On Wednesday 18 February 2004 12:37 am, Gerald Pfeifer wrote: > On Mon, 16 Feb 2004, Adriaan de Groot wrote: > > On Mon, 16 Feb 2004, Gerald Pfeifer wrote: > >> *** Configuration amd64-portbld-freebsd5.2 not supported > >> Configure in /tmp/a/ports/lang/gcc33/work/build/gcc failed, > >> exiting. and my gut tells me someone renamed x86_64 to amd64 > >> somewhere without making proper adjustment in upstream packages or > >> something like that. > > > > From things David and/or Peter have written I've gathered the > > following: > > > > 1) AMD didn't give the platform an official name till fairly late > > 2) Some folks chose amd64 > > 3) Later the muttonheads at the FSF chose x86_64 > > And right they were. See yesterdays press announcement by Intel. That sequence of events isn't quite right. AMD originally came up with x86-64. When Microsoft got going on the port, they said "that name sucks to type, how about amd64? We're NOT using x86=64". And so it became "amd64" or AMD64. And FWIW, I agree. x86_64 is the worst possible name to type. I suspect the x86-64 name was chosen to make it a less bitter pill for Intel to pick it up (after all, thats what cross licensing agreements are for). However, Intel haven't chosen either of the two names.. They've done their own one. "IA-32e" was mentioned several times at the IDF this week. The preview winxp-64 ISO released from microsoft 2 weeks ago has got a hal.dll that does a strcmp for "AuthenticAMD" and "GenuineIntel". (see for yourself, do a cabextract on /amd64/hal.dl_). All over the system, from top to bottom, its called 'amd64' - except for the top level human visible stuff. I'll be suprised if they do a global search/replace at this stage, especially since their last few compiler releases etc know thats what its called and use amd64 in their ifdefs. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 01:06:09 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C01F16A4CE for ; Sun, 22 Feb 2004 01:06:09 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05F9E43D1D for ; Sun, 22 Feb 2004 01:06:09 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id CFFF52A8EB for ; Sun, 22 Feb 2004 01:06:08 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 2E61D2C1AF for ; Sun, 22 Feb 2004 01:06:08 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1M964T6010856; Sun, 22 Feb 2004 01:06:04 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1M964cf010855; Sun, 22 Feb 2004 01:06:04 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 01:06:04 -0800 User-Agent: KMail/1.6 References: <002c01c3f312$947a26a0$c901a8c0@ts> <20040216080408.GE54371@dragon.nuxi.com> <16434.34102.544869.558732@grasshopper.cs.duke.edu> In-Reply-To: <16434.34102.544869.558732@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402220106.04438.peter@wemm.org> cc: Andrew Gallatin Subject: Re: which motherboard and which chipset? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 09:06:09 -0000 On Tuesday 17 February 2004 01:18 pm, Andrew Gallatin wrote: > David O'Brien writes: > > nVidia nForce3 [for AMD64] chipsets are very problematic for > > Unix(BSD)/Linux. I would avoid them if you want to run a > > non-MS-Windows operating system. > > Whew. Just in time, I was just about to order an SK8N. What do you > suggest for a solid single-CPU socket-940 board which will use ECC > memory? Asus SK8V? I'd love to get hold of a SK8V if only I could find one. :-) I have two K8V deluxes (one at home, the other at work, both with ECC non-Registered PC3200 memory from crucial.com). My SK8N with my (then) $750 cpu and $350 of ECC/REG PC3200 ram is on a shelf gathering dust because I lost my trust in the board. Personally, I prefer the ASUS boards over the tyans because of the flexibility in the bios and the vastly superior active fan speed control system. But I have a slight preference for the AMD 8xxx chipset over the VIA K8T800, but its only slight. Both are (IMHO) way ahead of the nVidia nForce3-150. If you have to listen to the machine next to your desk, I suggest an asus - the tyan fans run at full speed all the time, with no thermal based fan throttling. If you don't have to listen to it, and want something slightly more server-oriented then the tyans are probably a slightly better bet because the AMD chipset has had longer to shake out the bugs. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 02:23:18 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CFCA16A4CE; Sun, 22 Feb 2004 02:23:18 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1218343D1D; Sun, 22 Feb 2004 02:23:18 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9AB457303A; Sun, 22 Feb 2004 05:23:17 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040222102317.9AB457303A@freebsd-current.sentex.ca> Date: Sun, 22 Feb 2004 05:23:17 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 10:23:18 -0000 TB --- 2004-02-22 09:24:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-22 09:24:56 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-22 09:24:56 - checking out the source tree TB --- cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-22 09:29:41 - building world TB --- cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-22 10:16:52 - building generic kernel TB --- cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Feb 22 10:16:52 GMT 2004 >>> Kernel build for GENERIC completed on Sun Feb 22 10:23:16 GMT 2004 TB --- 2004-02-22 10:23:16 - generating LINT kernel config TB --- cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- /usr/bin/make -B LINT TB --- 2004-02-22 10:23:16 - building LINT kernel TB --- cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 22 10:23:16 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-22 10:23:17 - TB --- /usr/bin/make returned exit code 1 TB --- 2004-02-22 10:23:17 - TB --- ERROR: failed to build lint kernel TB --- 2004-02-22 10:23:17 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 05:26:35 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBCA016A4CE for ; Sun, 22 Feb 2004 05:26:35 -0800 (PST) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id C733D43D1D for ; Sun, 22 Feb 2004 05:26:34 -0800 (PST) (envelope-from wjw@withagen.nl) Received: from vaiowjw (pc77 [212.61.27.77]) by freebee.digiware.nl (8.12.10/8.12.9) with SMTP id i1MDPGeL077089 for ; Sun, 22 Feb 2004 14:25:16 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <062501c3f947$7dfc5930$4d1b3dd4@digiware.nl> From: "Willem Jan Withagen" To: References: <0b6801c3f21f$1fd470b0$471b3dd4@dual> Date: Sun, 22 Feb 2004 14:26:34 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0622_01C3F94F.DF6CADC0" 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 Subject: Re: System advice requested X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 13:26:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0622_01C3F94F.DF6CADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Willem Jan Withagen" > If I were to get a dual opteron board/system what things would be > to watch out for, or would be required. Hardware wise that is. > > In the beginning I would like to use is as: > 1) FreeBSD/windows/linux desktop > and lateron it would turn into my > 2) Home NFS/Samba-server running FBSD > > In case 2) I'd remove any fancy user-interface stuff... > > All suggestions welcomed, To follow-up on myself... The attachement contains all(??) comments about hardware on this list in the last 4 months. Currently totally completely unorganised. (Other than the most recents comments are first in the file) Given some more time, I'll try to organise it more sensible. And of course: comments welcome. --WjW ------=_NextPart_000_0622_01C3F94F.DF6CADC0 Content-Type: text/plain; name="dual-opteron.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dual-opteron.txt" Gobrien at freebsd.org: you want to populate memory in pairs per CPU. This is so you can use both channels of the DDR memory controller. If you only put one DIMM per CPU, you're missing 1/2 your potential bandwidth.=20 =3D=3D=3D=3D james-freebsd-amd64 at jrv.org=20 > Note 5.2.1 also adds the Silicon Image 3114 SATA support needed to > install on a SATA drive in many Opteron systems. Is anyone else having trouble with this? The 3114 is found no problem but the drive is not seen. The culprit may be this code in ata_reset(). =3D=3D=3D=3D billsf at curacao.n2it.nl: > Is anyone using an Adptec 29320? Mine is not working. > I suspect is may be a BIOS problem on the Tyan K8W S2885. > I also have a Highpoint 1820 that does not work right. Not anymore. It worked for awhile and after a few days it just stopped. Next i was given a PERC 320/DC Adaptec FSA RAID (aac) This was much = better but still an Adaptec. I'm using a 29160 now and it is going to go! These cards just don't seem to be up to a busy Unix environment. In all cases the firmware was the latest. (Surprisingly FreeDOS runs quite well on=20 the amd64, and needed to run the flash.exe stuff.) I'm getting a real Cirrus Logic card. These cost a third what Adaptec costs and my = experience has only been good with these cheap (smb) cards. I work with servers and most BOFH's swear by them and deplore Adaptec. (Therefore all those = 'free' cards to try. ;-) Gladly stump up a hundred Euros or so for piece of = mind. =20 Presently I'm using an Asus K8 motherboard for an Opteron-100 marketed = as "Athlon-FX" or something. Not bad for Taiwan, but apparently Taiwan = thought amd64 was going to be Windows and therefore some really goofy features.=20 All AMD products seem to work better slightly overclocked. 2250MHz for a = 2200MHz chip is perfectly inline with the 3 - 5% rule. When increasing = the=20 bus speed, Adaptec cards give out first, then SATA and then the video = and=20 so on. Sorry, this is a bit offtopic. =3D=3D=3D=3D bob at immure.com: Well, my early Tyan Athlon MBs (Tiger S2460) didn't like Crucial DIMMs much, and my later Tyan boards (Tiger s2466's) won't work with the Crucial DIMMs at all (I have about 8 of them on a shelf that I can't use at all now). I never have seen any ECC errors (there registered ECC DIMMs) with these, just varying degrees of system unstability (random memory erors/panics). A couple of years ago I spent quite a bit of time on the phone with Crucial's tech support folks (shortly after I bought the memory) with no real resolution (the tech support guy tried to be helpful but couldn't really help). Following this experience, I have come to worry much more than I previously did about memory compatibility issues; and I began to wonder just how much good ECC memory really does in these systems when you wind up with all kinds of system instability. I now worry more about compatibility than do ECC vs. non-ECC memory. Note, that my newer Tyan dual MB systems (those with the S2466 MBs that can run with unbufferred/non-ECC DIMMs) have been running with unbufferred/non-ECC DIMMs for some time (over a year) and I have had much better stability with these systems than when I tried the Crucial reg/ECC DIMMs (generally, they either wouldn't boot at all or only ran for a short time, depending on how many DIMMs I installed--more meant shorter time to crash). Note that I never did try other brands of reg/ECC memory on these systems since they were stable with the cheaper stuff and I was growing tired of spending money on them. =3D=3D=3D=3D obrien at freebsd.org: Tyan GX28 support? > The onboard sATA on the S2885 isn't supported. The GX28 > uses a Promise controller chip that is more likely to work. > I have no idea if the LSI SCSI controller is supported. > It's a BCM5704c ethernet: mine is a 5705. Both the LSI SCSI and BCM5704c are supported. =3D=3D=3D=3D=3D obrien at freebsd.org: > what motherboard do you guys recommend for use on a dual cpu ssytem.=20 Server or workstation?? Workstation get the Tyan Thunder K8W or Iwill DK8X. Server get Arima RioWorks, or Tyan Thunder K8S PRO. > would prefer ddr non registered memory capability and sata drive = support. ALL Opterons require registered ECC memory. =3D=3D=3D=3D james-freebsd-amd64 at jrv.org: My Tyan K8W S2885 works fine with its onboard Broadcom. Will's problems appear caused by ACPI problems, which is a property of the particular BIOS the motherboard interacting with whatever bugs exist in FreeBSD's ACPI interpreter. Your Tyan probably works as-is. =3D=3D=3D=3D obrien at freebsd.org: > I downloaded the 5.2-RC2 AMD64 miniinst ISO to try on a MSI K8T800 > based dual opteron system today. What is the board model number? I am not aware of any K8T800 based SMP boards. The only MSI 2P board I know if is the K8D Master MS-9131 which is AMD 8100. =3D=3D=3D=3D chat95 at mbox.kyoto-inet.or.jp: Hm, I know it, but unfortunately, there are no data for Tyan thunder k8w (S2885) and Rioworks HDAMB-WO... anyway, for Rioworks HDAMB-WO, o RIOWORKS HDAMB-WO http://www.rioworks.co.jp/motherboard/popup/hdamb.html I found a PDF (though it was written in Japanese). o AMD Opteron Processor Compatible DDR Memory Modules AMD Tested Memory Validated DIMMs - AMD Opteron Processor = http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_881= 9%5E9394,00.html =3D=3D=3D=3D obrien at freebsd.org: At work we're pretty sloppy about what random no-name DIMM's we use. Only the Shuttle box has been picky. That said, Micron (MT) / Crucial DIMM's are probably the best quality. Samsung DIMM's also. These are the two brands AMD uses in the development systems it sends out. I've got a case load of Kingston 1GB ValueRAM in which 1 out of 4 DIMM's is bad. =3D=3D=3D=3D Markus at kpnqwest.ch: > The motherboard has the same Sil3114 SATA controller as the Tyan = Thunder K8W=20 > (S2885). I have seen other posts to this list that indicate success = in=20 > installing FreeBSD on the Thunder K8W, so I'm wondering why I can't = see the=20 > drives on my system. I made a simple modification to the driver which essentially maps the = 3114 as a 3112, which works, sort of (not with the recent changes though, I'm = getting those "TIMEOUT - ATAPI_IDENTIFY retrying messages" that others had = mentioned as well). The drives do not go into SATA DMA mode (150Mbps), but I have = the=20 slight suspicion the code doesn't really support those yet with the SiL = chipsets. On very high load on the drives, I sometimes get=20 ad4: WARNING - WRITE_DMA UDMA ICRC error (retrying request) style errors, but all in all, it's working very nicely. =3D=3D=3D=3D obrien at freebsd.org: > You might be able to save some money by using an Athlon64 CPU and > motherboard instead of Opteron, but registered DIMM might not work. Registered(buffered) DIMM's will not work in Athlon64 motherboards. =3D=3D=3D=3D obrien at freebsd.org: > Adaptec 3950U2B hosting a pair of LVD drives > Adaptec 2400A IDE RAID hosting a quartet of WD 120GB Sp. Editions > ATI Radeon 7200 (aka Radeon VIVO) > Netgear FA310TX serving the outside world > Netgear FA302T serving the inside LAN All of this will work. =3D=3D=3D=3D WillS at housing.ufl.edu: If you used an Opteron 240 on an MSI K8T Master2-FAR board you would spend ~$600. That board is ATX-sized so it doesn't = require any special case. Your RAM is too slow, and I don't know if you can run the memory bus=20 asynchronously, so if it were me I would figure on buying more RAM. I = think you can get 1GB of Corsair Registered ECC DDR400 in a 'matched pair' of=20 512MB modules for less than $400, so that would put you under your = spending limit. =3D=3D=3D=3D obrien at freebsd.org: > Your RAM is too slow, and I don't know if you can run the memory bus=20 > asynchronously, so if it were me I would figure on buying more RAM. Huh? I don't follow, why is running PC2100 in any AMD64 machine running the memory bus asynchronously?? PC1600 memory will work fine any any AMD64 mobo, so will PC2100 and PC2700. You'll need the latest BIOS's and a rev.C CPU to run DDR400. =3D=3D=3D=3D obrien at freebsd.org: Well tested are Matrox G4[05]0 and nVidia GeForce{3,4}. I have no ATI experience on FreeBSD/amd64. =3D=3D=3D=3D tilman at arved.at: I use an none0 at pci1:0:0: class=3D0x030000 card=3D0x596412ab chip=3D0x59641002 = rev=3D0x01 hdr=3D0x00 vendor =3D 'ATI Technologies' device =3D 'Radeon 9200 Series' class =3D display subclass =3D VGA =3D=3D=3D=3D obrien at freebsd.org: I don't quite follow you. You are using the 2015S ZCR in 32-bit or 64-bit FreeBSD? It should work with FreeBSD/i386 on Opteron HW. asr(4) isn't 64-bit clean and thus asr(4) devices aren't supported in the FreeBSD/amd64 OS. =3D=3D=3D=3D tomh at waterloo.equitrac.com: All right, so I gave up on my Adaptec 2100S RAID controller, and managed = to locate a used HP NetRAID 3Si (aka MegaRAID 438). The NetRAID is only = U2W (80 MB/s, as I recall?), but FreeBSD/amd64 seems to be much happier with = it. =3D=3D=3D=3D peter at wemm.org: The only major chunk of hardware that I know of that has big issues is = the=20 Promise SX6000. The driver tries to use a 32 bit field in a hardware = data=20 structure to store a 64 bit pointer. =3D=3D=3D=3D james-freebsd-amd64 at jrv.org: I'm using a Tyan S2885, which appears somewhat similar to this. FreeBSD has run flawlessly for me - no reboots, crashes or other headaches. I'm using FreeBSD 5.2 RC2. The onboard sATA on the S2885 isn't supported. The GX28 uses a Promise controller chip that is more likely to work. I have no idea if the LSI SCSI controller is supported. It's a BCM5704c ethernet: mine is a 5705. I'm using 8 GB of memory (8x Crucial part #CT12872Y335) and a HighPoint 1542 sATA controller. =3D=3D=3D=3D obrien at freebsd.org: > On the Tyan 2880 motherboard. I know you've already bought it... but to everyone else I strongly recommend not buying this motherboard. The 4+2 DIMM configuration[*] is sub-optimal and you can get 4+4 DIMM configuration from Tyan (K8S Pro) and other makers. [*] I fully know the bad history of Opteron 4+2 DIMM configurations... but can't speak publically about it. :-( =3D=3D=3D=3D peter at wemm.org: The ones I have personal experience with are: 940 pin: Asus SK8N: works (nForce3 chipset, no driver for onboard nVidia nic, = onboard promise 378 raid+SATA) Rioworks HDAMA: works (AMD chipset, 2 cpu, onboard if_bge gigabit, in = use on the freebsd.org cluster as sledge.freebsd.org and at = work) 754 pin: Asus K8V: works (VIA K8T800 chipset, onboard ide not recognized without patch which has integrated SATA support, decent onboard 3com/syskonnect gigabit nic (if_sk), onboard promise = 378 raid+SATA) Gigabyte K8NPro: works (nForce3, lousy tiny bios interface, realtek 8110 gigabit nic (if_re) - supposedly not bad. onboard = nVidia ethernet isn't connected (but we dont have a driver = anyway)). AMD Solo4, Solo5 and Solo7 (developer reference boards) I really like both of the ASUS boards for personal use and the Rioworks = for servers. I have not seen any of the MSI boards so I can't vouch for = them. The MSI 2xCPU board only has 2 dimm slots on one of the cpus so I'm not that interested in their server board. Their consumer board appears to have similar specs to the asus K8V but I haven't tried it. All of these boards work with ACPI, minus some quirks with ordering the serial ports. Some of them list the COM2 port first in the tables which means we assign 'sio0' to it. Thats only a minor annoyance though. The onboard nVidia ethernet is annoying because they only give out a = binary driver blob that you write an OS shim to use. This works for i386, but obviously isn't going to work too well for an amd64 kernel. The only = board affected by this is the Asus SK8N, but ethernet cards are not a big = deal. I really really dislike the bios on the Gigabyte, and really like the = ones on the ASUS boards. The Gigabyte bios interface is almost worthless and gives you very little control over anything. If it had to be named, I'd call it a 'BIOS for dummies'. On the other hand, the ASUS bios' give = you more than enough rope. For example, Gigabyte have 'PNP OS: Yes' by = default and dont give you the ability to turn it off. ASUS do let you turn it = off. =3D=3D=3D=3D obrien at freebsd.org: I've been asked a few times what case one can use in building a = dual-proc Opteron workstation. So I thought I'd answer it publically for all. AMD uses the InWin Q500 http://www.pcstats.com/articleview.cfm?articleID=3D570 with the internal = 3" drive cage removed. This case has tons of room and even with the 3" drive cage removed there are still 5 drive bays left. This case is US$69.32 from http://www.pricetool.com/pr-In_Win_IW_Q500_IW-Q500_ATX_Full_Tower_Case?sp= =3Dgcm&tid=3D921103 If you want a shorter case, I have also installed both Tyan K8W (s2885) and MSI-9131 mobos into the Antec SX835II Performance Series II = mid-Tower case http://www.antec-inc.com/pro_details_enclosure.php?ProdID=3D80843. Again with the internal 3" drive cage removed. =20 =3D=3D=3D=3D eric at fnordsystems.com: The "Antec" cases are also available under a variety of other names, = they are actually manufactured by: http://www.chieftec.com/products/products.htm =3D=3D=3D=3D WillS@housing.ufl.edu: At least with my board (an 'awful' 4+0 MSI K8T Master2-FAR board) the = onboard broadcom=20 NIC does not work correctly with bge. It does work with ndis though. = Also for whatever=20 reason -current as of last weekend would lock the machine up hard after = ~ 30 minutes.=20 Haven't had time to work on why. -Will =3D=3D=3D=3D On Sat, Feb 14, 2004 at 11:26:06PM +0100, Adriaan de Groot wrote: > Take a look at the archives of this list (via > ), there's = lot of > hardware mentioned. I think a lot depends on how much memory you need = to > support your users: Athlon64 boards (single CPU) tend to top out at 4G > theoretical and 3G practical (like my Asus k8v, with 3 slots so I = could > stick 3G of DDR266 in it) ; Opteron boards for single CPU with 4 slots = top > out at 8G theoretical (4x2G Registered), but I hear tales of an sk8n > supporting only 3.5G. Dual boards run up to 8 slots, for 16G of = memory. Not just SK8N's. Just about every AMD64 mobo will "loose" physical memory from 3.5-4GB. So one would get 17.5GB in your example of 8x2GB DIMM's. The reasons have been explained in this list before. =3D=3D=3D=3D nVidia nForce3 [for AMD64] chipsets are very problematic for Unix(BSD)/Linux. I would avoid them if you want to run a non-MS-Windows operating system. --=20 -- David (obrien@FreeBSD.org ) =3D=3D=3D=3D From: "Haapanen, Tom" Andrew Gallatin: > Thanks. But are you saying the VIA K8T800 chipset is flakey too, and I = > should only consider AMD-8000 based boards? Just from scanning the=20 > last month or so of archives, it looks like the bad hardware is pretty = > evenly distributed across chipsets, but perhaps that's not enough=20 > perspective. I'm new here, after all.. Absolutely not saying that. I don't have any experience with = K8T800-based boards at all. But many people have been highly successful with the Tyan boards (I have been running a K8S Pro-based server in production for more than two = weeks now, and the mysqld process is approaching 100 hours of CPU time.)=20 So I am only suggesting them as an option ... =3D=3D=3D=3D Tyan K8W here with dual 242's. Love it. Cheers, Dylan Carlson [absinthe@pobox.com] ------=_NextPart_000_0622_01C3F94F.DF6CADC0-- From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 09:28:36 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4E6316A4CE for ; Sun, 22 Feb 2004 09:28:36 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCBB543D1F for ; Sun, 22 Feb 2004 09:28:36 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1MHSXOJ091543; Sun, 22 Feb 2004 09:28:33 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1MHSWbh091542; Sun, 22 Feb 2004 09:28:32 -0800 (PST) (envelope-from obrien) Date: Sun, 22 Feb 2004 09:28:32 -0800 From: "David O'Brien" To: Andrew Gallatin Message-ID: <20040222172832.GC91129@dragon.nuxi.com> References: <16434.44274.200375.8454@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16434.44274.200375.8454@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org Subject: Re: which motherboard and which chipset? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 17:28:37 -0000 On Tue, Feb 17, 2004 at 07:08:18PM -0500, Andrew Gallatin wrote: > Thanks. But are you saying the VIA K8T800 chipset is flakey too, and I have heard of no such things. > I should only consider AMD-8000 based boards? For a workstation, you would probably prefer the VIA K8T800 chipset as you'll get things such as USB 2.0, and other niceities. The AMD 8100 chipset is server oriented and is a little more "plain". > Just from scanning the > last month or so of archives, it looks like the bad hardware is pretty > evenly distributed across chipsets, but perhaps that's not enough > perspective. I'm new here, after all.. I would re-read the archives. :-) -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 09:36:40 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F27A416A4CE for ; Sun, 22 Feb 2004 09:36:39 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8D2943D1D for ; Sun, 22 Feb 2004 09:36:39 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1MHadOJ091737; Sun, 22 Feb 2004 09:36:39 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1MHackj091736; Sun, 22 Feb 2004 09:36:38 -0800 (PST) (envelope-from obrien) Date: Sun, 22 Feb 2004 09:36:38 -0800 From: "David O'Brien" To: Scott Silzer Message-ID: <20040222173638.GD91129@dragon.nuxi.com> References: <16434.44274.200375.8454@grasshopper.cs.duke.edu> <42E6A174-6226-11D8-98F7-000393921E22@silzer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E6A174-6226-11D8-98F7-000393921E22@silzer.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org Subject: Re: which motherboard and which chipset? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 17:36:40 -0000 On Wed, Feb 18, 2004 at 10:22:27AM -0500, Scott Silzer wrote: > Seams like an appropriate thread to ask so has any one had any > experience with the Arima/Accelertech ATO2161-A ? > http://www.accelertech.com/motherboard.php Lots of people have that board; but it was sold to them as the "Arima HDAMA". It is a solid board. Being the first 4+4 DIMM configuration, a lot of vendors of 1U clusters use it. Note the Hurricane64 (Model: ATO2163) is the same as the Iwill DK8X. I really like the AGP slot location on this board. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 09:42:01 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB59F16A4CE; Sun, 22 Feb 2004 09:42:01 -0800 (PST) Received: from imf20aec.mail.bellsouth.net (imf20aec.mail.bellsouth.net [205.152.59.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D7BE43D2D; Sun, 22 Feb 2004 09:42:01 -0800 (PST) (envelope-from drhodus@machdep.com) Received: from [192.168.1.96] ([68.209.168.6]) by imf20aec.mail.bellsouth.netESMTP <20040222174201.PSYV1827.imf20aec.mail.bellsouth.net@[192.168.1.96]>; Sun, 22 Feb 2004 12:42:01 -0500 In-Reply-To: <20040222173638.GD91129@dragon.nuxi.com> References: <16434.44274.200375.8454@grasshopper.cs.duke.edu> <42E6A174-6226-11D8-98F7-000393921E22@silzer.net> <20040222173638.GD91129@dragon.nuxi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <692691A3-655E-11D8-84F2-000A959B213E@machdep.com> Content-Transfer-Encoding: 7bit From: David Rhodus Date: Sun, 22 Feb 2004 12:41:57 -0500 To: obrien@freebsd.org X-Mailer: Apple Mail (2.612) cc: freebsd-amd64@freebsd.org Subject: Re: which motherboard and which chipset? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 17:42:02 -0000 On Feb 22, 2004, at 12:36 PM, David O'Brien wrote: > On Wed, Feb 18, 2004 at 10:22:27AM -0500, Scott Silzer wrote: >> Seams like an appropriate thread to ask so has any one had any >> experience with the Arima/Accelertech ATO2161-A ? >> http://www.accelertech.com/motherboard.php > > Lots of people have that board; but it was sold to them as the "Arima > HDAMA". It is a solid board. Being the first 4+4 DIMM configuration, > a > lot of vendors of 1U clusters use it. What type of fan are people using to get that wedged into a 1U case ? -DR From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 09:49:26 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C977E16A4CE; Sun, 22 Feb 2004 09:49:26 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B155243D1F; Sun, 22 Feb 2004 09:49:26 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1MHnLOJ091875; Sun, 22 Feb 2004 09:49:21 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1MHnJIj091874; Sun, 22 Feb 2004 09:49:19 -0800 (PST) (envelope-from obrien) Date: Sun, 22 Feb 2004 09:49:19 -0800 From: "David O'Brien" To: Peter Wemm Message-ID: <20040222174919.GF91129@dragon.nuxi.com> References: <200402220057.36903.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402220057.36903.peter@wemm.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: amd64@freebsd.org cc: adridg@cs.kun.nl cc: Gerald Pfeifer cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 17:49:26 -0000 On Sun, Feb 22, 2004 at 12:57:36AM -0800, Peter Wemm wrote: > However, Intel haven't chosen either of the two names.. > They've done their own one. "IA-32e" was mentioned several times at > the IDF this week. My guess is it would wreck havoc with Intel's FUD that AMD64 isn't really 64-bits if Intel also used "64" in the platform's name. Intel has having to walk a very fine line to keep from damaging other product lines... From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 09:49:26 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C977E16A4CE; Sun, 22 Feb 2004 09:49:26 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B155243D1F; Sun, 22 Feb 2004 09:49:26 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1MHnLOJ091875; Sun, 22 Feb 2004 09:49:21 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1MHnJIj091874; Sun, 22 Feb 2004 09:49:19 -0800 (PST) (envelope-from obrien) Date: Sun, 22 Feb 2004 09:49:19 -0800 From: "David O'Brien" To: Peter Wemm Message-ID: <20040222174919.GF91129@dragon.nuxi.com> References: <200402220057.36903.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402220057.36903.peter@wemm.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: amd64@freebsd.org cc: adridg@cs.kun.nl cc: Gerald Pfeifer cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 17:49:26 -0000 On Sun, Feb 22, 2004 at 12:57:36AM -0800, Peter Wemm wrote: > However, Intel haven't chosen either of the two names.. > They've done their own one. "IA-32e" was mentioned several times at > the IDF this week. My guess is it would wreck havoc with Intel's FUD that AMD64 isn't really 64-bits if Intel also used "64" in the platform's name. Intel has having to walk a very fine line to keep from damaging other product lines... From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 10:00:23 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A28516A4FD for ; Sun, 22 Feb 2004 10:00:23 -0800 (PST) Received: from omega.metrics.com (internal.metrics.com [204.138.110.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4DCB43D1D for ; Sun, 22 Feb 2004 10:00:22 -0800 (PST) (envelope-from tomh@waterloo.equitrac.com) Received: from syncro.metrics.com ([192.168.96.20]) by omega.metrics.com (8.12.9/8.12.9) with ESMTP id i1MI1u0b094545 for ; Sun, 22 Feb 2004 13:01:56 -0500 (EST) (envelope-from tomh@waterloo.equitrac.com) Received: by SYNCRO with Internet Mail Service (5.5.2653.19) id ; Sun, 22 Feb 2004 12:58:56 -0500 Message-ID: From: "Haapanen, Tom" To: amd64@freebsd.org Date: Sun, 22 Feb 2004 12:58:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Flag: NO X-Scanned-By: milter-spamc/0.14.238 (omega [192.168.96.200]); pass=YES; Sun, 22 Feb 2004 13:01:56 -0500 X-Spam-Status: NO, hits=0.00 required=5.00 X-Spam-Level: Subject: RE: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 18:00:23 -0000 >> However, Intel haven't chosen either of the two names.. >> They've done their own one. "IA-32e" was mentioned several times >> at the IDF this week. David O'Brien: > My guess is it would wreck havoc with Intel's FUD that AMD64 isn't > really 64-bits if Intel also used "64" in the platform's name. Intel has > having to walk a very fine line to keep from damaging other product > lines... Since there is no universal name for the architecture, and Intel essentially is duplicating the "AMD64" instruction set, it makes sense to continue to use "amd64", I think. This is the same logic as "i386" which is called many things now by many different manufactureres, but still refers to Intel's original name. Tom From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 10:12:05 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF18716A4CE for ; Sun, 22 Feb 2004 10:12:05 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B9243D1F for ; Sun, 22 Feb 2004 10:12:05 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1MIC2OJ092310; Sun, 22 Feb 2004 10:12:02 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1MIC1Ud092309; Sun, 22 Feb 2004 10:12:01 -0800 (PST) (envelope-from obrien) Date: Sun, 22 Feb 2004 10:12:01 -0800 From: "David O'Brien" To: adridg@cs.kun.nl Message-ID: <20040222181200.GH91129@dragon.nuxi.com> References: <0b8201c3f222$a7d3eec0$471b3dd4@dual> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org Subject: Re: System advice requested X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 18:12:06 -0000 On Fri, Feb 13, 2004 at 02:02:29PM +0100, Adriaan de Groot wrote: > got a collegue of mine an sk8n w/ 4G (of which the BIOS apparently only > sees 3.5 G - very odd). The loss of 1/2 GB has been explained serveral times in this list. Please see the archives. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 10:41:57 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D352E16A4CE for ; Sun, 22 Feb 2004 10:41:57 -0800 (PST) Received: from tenor.codegen.com (tenor.CodeGen.COM [204.62.145.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id A93EE43D2D for ; Sun, 22 Feb 2004 10:41:57 -0800 (PST) (envelope-from parag@codegen.com) Received: from tenor.codegen.com (localhost.codegen.com [127.0.0.1]) by tenor.codegen.com (8.12.6p2/8.12.3) with ESMTP id i1MIfv67085135 for ; Sun, 22 Feb 2004 10:41:57 -0800 (PST) (envelope-from parag@tenor.codegen.com) Organization: CodeGen, Inc. X-URL: http://www.codegen.com/ X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm To: amd64@freebsd.org In-Reply-To: Message from "Haapanen, Tom" Date: Sun, 22 Feb 2004 10:41:57 -0800 Message-ID: <85134.1077475317@tenor.codegen.com> From: Parag Patel Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 18:41:57 -0000 "Haapanen, Tom" wrote: > >Since there is no universal name for the architecture, and Intel essentially >is duplicating the "AMD64" instruction set, it makes sense to continue to >use "amd64", I think. The Register has coined iAMD64 as the instruction set. :) -- __ /__)_ _ _ _ Advice to young men: Be ascetic, and if you can't be / (// (/(/ ascetic, then at least be asceptic. _/ From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 10:52:09 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB9716A4CE for ; Sun, 22 Feb 2004 10:52:09 -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 DDD8843D1F for ; Sun, 22 Feb 2004 10:52:08 -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 i1MIq8OE040661 for ; Sun, 22 Feb 2004 10:52:08 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.11/8.12.11) with ESMTP id i1MIq8oF053670 for ; Sun, 22 Feb 2004 10:52:08 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i1MIq8BI053669 for freebsd-amd64@freebsd.org; Sun, 22 Feb 2004 10:52:08 -0800 (PST) (envelope-from marcel) Date: Sun, 22 Feb 2004 10:52:08 -0800 From: Marcel Moolenaar To: freebsd-amd64@freebsd.org Message-ID: <20040222185208.GA53610@dhcp01.pn.xcllnt.net> References: <4CC57F17-64E9-11D8-ACAA-000A95BAD088@raisdorf.net> <200402220033.01795.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402220033.01795.peter@wemm.org> User-Agent: Mutt/1.4.2.1i Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 18:52:09 -0000 On Sun, Feb 22, 2004 at 12:33:01AM -0800, Peter Wemm wrote: > On Saturday 21 February 2004 07:43 pm, Hendrik Scholz wrote: > > On Feb 21, 2004, at 9:59 PM, Christian Weisgerber wrote: > > > Why are these shared objects not built with -fPIC in the first > > > place? > > > > Ask the authors of the third party applications :) > > Most architectures don't need -fPIC and/or it slows them down (thanks > > for the > > comment Peter!). > > Yes, exactly. Some folks thought it would be an idea to add a flag to > libtool to force it to link non-pic code into shared libraries. > Essentially this reduces the sharability since we do relocations on the > text segment, but the flipside is that its faster on i386 and on some > libraries they figured it was worth burning extra memory that would be > wasted by not using -fPIC. Not to mention that people generally attach -fPIC to the kind of library they are making and thus do not build with -fPIC if they create an archive library (the BSD make infrastructure has this too). This most of the time works, but not when the archive library is subsequently linked *into* a shared library later on. So, the use of -fPIC is determined by how the object files are eventually used to make up a process and that's not always known to the person writing the libraries, let alone some (in)convenience tools like libtool or automake/autoconf. With shared libraries the norm, the safest default would be -fPIC on some archs (amd64 and ia64 for example). The group of people that build archive only libraries and complete executables for performance reasons, a pretty small group, know how to fiddle with options to get the compiler/linker emit the best code for their purpose and a -fNOPIC doesn't add to the hazzle. I think it was Christian who asked why -fPIC was not the default and I think it's a good question. Although it should be compiler default, not some make logic to add to CFLAGS... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 10:58:26 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D31A416A4CE for ; Sun, 22 Feb 2004 10:58:26 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB3B543D1D for ; Sun, 22 Feb 2004 10:58:26 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id EC2FB3C8013; Sun, 22 Feb 2004 14:00:34 -0500 (EST) In-Reply-To: <200402220036.18198.peter@wemm.org> References: <5421F6D2-6446-11D8-8485-000A95989E4A@lixfeld.ca> <200402211230.57825.peter@wemm.org> <249AC6EC-64B6-11D8-8485-000A95989E4A@lixfeld.ca> <200402220036.18198.peter@wemm.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <131133C2-6569-11D8-AC84-000A95989E4A@lixfeld.ca> Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Sun, 22 Feb 2004 13:58:17 -0500 To: Peter Wemm X-Mailer: Apple Mail (2.613) cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 + Ports X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 18:58:26 -0000 On Feb 22, 2004, at 3:36 AM, Peter Wemm wrote: > You can use cvsup! We've been trying to tell you.. turn off > compression! It'll either be something like '*default compress' > if you're using one of the example cvsup files, or the -z flag if > you're > using the cvsup-mirror kit or the like. Thanks, sorry I didn't catch that you were trying to tell me to not use compression in the last post. I'm rather new to all this stuff so it didn't quite click. I'll give that a try. > I'd try and build a cvsup-without-compression if I knew how to change > the cvsup source. I really don't understand the language. Incidently, > it makes porting the language compiler really interesting when its > written in itself and you don't understand it. :-) > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 10:59:13 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40FF416A4CE for ; Sun, 22 Feb 2004 10:59:13 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28B3843D2D for ; Sun, 22 Feb 2004 10:59:13 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id E3F923C8013; Sun, 22 Feb 2004 14:01:25 -0500 (EST) In-Reply-To: <200402220042.54158.peter@wemm.org> References: <5421F6D2-6446-11D8-8485-000A95989E4A@lixfeld.ca> <200402211230.57825.peter@wemm.org> <200402220042.54158.peter@wemm.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <33D16BF6-6569-11D8-AC84-000A95989E4A@lixfeld.ca> Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Sun, 22 Feb 2004 13:59:12 -0500 To: Peter Wemm X-Mailer: Apple Mail (2.613) cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 + Ports X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 18:59:13 -0000 On Feb 22, 2004, at 3:42 AM, Peter Wemm wrote: > Hmm. It seems I uploaded the wrong file. I uploaded the one I did on > October 24th last year. That was clever, wasn't it? I'm sorry about > that, please try again. ah, I have a feeling this will make my life much easier! I'll give it a go and let you know. Thanks peter! > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 11:13:22 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A167916A4CF for ; Sun, 22 Feb 2004 11:13:22 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4177443D2D for ; Sun, 22 Feb 2004 11:13:22 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id A4C6A3C8013 for ; Sun, 22 Feb 2004 14:15:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v613) To: freebsd-amd64@freebsd.org Message-Id: <2BB4A67B-656B-11D8-AC84-000A95989E4A@lixfeld.ca> Content-Type: multipart/mixed; boundary=Apple-Mail-1-385749898 From: Jason Lixfeld Date: Sun, 22 Feb 2004 14:13:17 -0500 X-Mailer: Apple Mail (2.613) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: make Buildworld + make buildkernel errors -current X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 19:13:22 -0000 --Apple-Mail-1-385749898 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Ok, I've been trying for the last 24 hours to get a custom kernel and make buildworld to run. Make buildkernel KERNCONF=ESHARA is giving me issues with accf_http. Some reading (including a post yesterday re: CFLAGS+= -fPIC per default?) suggested CFLAGS -fPIC in /etc/make.conf which hasn't helped. Attached is the make output. --Apple-Mail-1-385749898 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Make buildworld has problems with libpam. Some reading suggested CFLAGS -O2 in /etc/make.conf which hasn't helped. Attached is the make output. --Apple-Mail-1-385749898 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Does this stuff ring a bell for anyone? Anyone have any bright ideas? :) --Apple-Mail-1-385749898-- From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 11:19:49 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E119116A4CE for ; Sun, 22 Feb 2004 11:19:49 -0800 (PST) Received: from tenor.codegen.com (tenor.CodeGen.COM [204.62.145.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6E3243D2D for ; Sun, 22 Feb 2004 11:19:49 -0800 (PST) (envelope-from parag@codegen.com) Received: from tenor.codegen.com (localhost.codegen.com [127.0.0.1]) by tenor.codegen.com (8.12.6p2/8.12.3) with ESMTP id i1MJJn67085644 for ; Sun, 22 Feb 2004 11:19:49 -0800 (PST) (envelope-from parag@tenor.codegen.com) Organization: CodeGen, Inc. X-URL: http://www.codegen.com/ X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm To: amd64@freebsd.org In-Reply-To: Message from Parag Patel of "Sun, 22 Feb 2004 10:41:57 PST." <85134.1077475317@tenor.codegen.com> Date: Sun, 22 Feb 2004 11:19:49 -0800 Message-ID: <85643.1077477589@tenor.codegen.com> From: Parag Patel Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 19:19:50 -0000 >The Register has coined iAMD64 as the instruction set. :) Whups - I meant The Inquirer. -- __ /__)_ _ _ _ If you want divine justice, die. -- Nick Seldon / (// (/(/ _/ From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 11:24:34 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F22ED16A4CE for ; Sun, 22 Feb 2004 11:24:33 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9246F43D2D for ; Sun, 22 Feb 2004 11:24:33 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id F16A63C8013 for ; Sun, 22 Feb 2004 14:26:45 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <2BB4A67B-656B-11D8-AC84-000A95989E4A@lixfeld.ca> References: <2BB4A67B-656B-11D8-AC84-000A95989E4A@lixfeld.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Sun, 22 Feb 2004 14:24:27 -0500 To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.613) Subject: Re: make Buildworld + make buildkernel errors -current X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 19:24:34 -0000 Lame. It strips attachments. Ok... here's the output pasted: make buildkernel: ===> accf_data cc -O -fPIC -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /usr/obj/usr/src/sys/ESHARA/opt_global.h -I. -I@ -I@/../include -finline-limit=8000 -fno-common -g -I/usr/obj/usr/src/sys/ESHARA -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/netinet/accf_data.c cc1: sorry, unimplemented: code model kernel not supported in PIC mode cc1: error: code model `kernel' not supported in the 64 bit mode *** Error code 1 Stop in /usr/src/sys/modules/accf_data. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/ESHARA. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real 5m3.031s user 3m18.948s sys 0m40.062s su-2.05b# make buildworkd: cc -O -fPIC -I/usr/src/lib/libpam/libpam -I/usr/src/lib/libpam/libpam/../../../contrib/openpam/include -DLIB_MAJ=2 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/contrib/openpam/lib/openpam_static.c ld -o openpam_static_modules.o -r --whole-archive openpam_static.o ../modules/pam_chroot/libpam_chroot.a ../modules/pam_deny/libpam_deny.a ../modules/pam_echo/libpam_echo.a ../modules/pam_exec/libpam_exec.a ../modules/pam_ftpusers/libpam_ftpusers.a ../modules/pam_group/libpam_group.a ../modules/pam_guest/libpam_guest.a ../modules/pam_krb5/libpam_krb5.a ../modules/pam_ksu/libpam_ksu.a ../modules/pam_lastlog/libpam_lastlog.a ../modules/pam_login_access/libpam_login_access.a ../modules/pam_nologin/libpam_nologin.a ../modules/pam_opie/libpam_opie.a ../modules/pam_opieaccess/libpam_opieaccess.a ../modules/pam_passwdqc/libpam_passwdqc.a ../modules/pam_permit/libpam_permit.a ../modules/pam_radius/libpam_radius.a ../modules/pam_rhosts/libpam_rhosts.a ../modules/pam_rootok/libpam_rootok.a ../modules/pam_securetty/libpam_securetty.a ../modules/pam_self/libpam_self.a ../modules/pam_ssh/libpam_ssh.a ../modules/pam_tacplus/libpam_tacplus.a ../modules/pam_unix/libpam_unix.a ../modules/pam_deny/libpam_deny.a(pam_deny.o): In function `pam_sm_open_session': pam_deny.o(.text+0x38): multiple definition of `pam_sm_open_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_open_session' changed from 476 to 6 in ../modules/pam_deny/libpam_deny.a(pam_deny.o) ../modules/pam_deny/libpam_deny.a(pam_deny.o): In function `pam_sm_close_session': pam_deny.o(.text+0x40): multiple definition of `pam_sm_close_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x1dc): first defined here ../modules/pam_echo/libpam_echo.a(pam_echo.o): In function `pam_sm_authenticate': pam_echo.o(.text+0x19c): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 32 to 14 in ../modules/pam_echo/libpam_echo.a(pam_echo.o) ../modules/pam_echo/libpam_echo.a(pam_echo.o): In function `pam_sm_setcred': pam_echo.o(.text+0x1ac): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_echo/libpam_echo.a(pam_echo.o): In function `pam_sm_acct_mgmt': pam_echo.o(.text+0x1b4): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ld: Warning: size of symbol `pam_sm_acct_mgmt' changed from 6 to 14 in ../modules/pam_echo/libpam_echo.a(pam_echo.o) ../modules/pam_echo/libpam_echo.a(pam_echo.o): In function `pam_sm_open_session': pam_echo.o(.text+0x1c4): multiple definition of `pam_sm_open_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_open_session' changed from 6 to 14 in ../modules/pam_echo/libpam_echo.a(pam_echo.o) ../modules/pam_echo/libpam_echo.a(pam_echo.o): In function `pam_sm_close_session': pam_echo.o(.text+0x1d4): multiple definition of `pam_sm_close_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x1dc): first defined here ld: Warning: size of symbol `pam_sm_close_session' changed from 6 to 14 in ../modules/pam_echo/libpam_echo.a(pam_echo.o) ../modules/pam_echo/libpam_echo.a(pam_echo.o): In function `pam_sm_chauthtok': pam_echo.o(.text+0x1e4): multiple definition of `pam_sm_chauthtok' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x30): first defined here ld: Warning: size of symbol `pam_sm_chauthtok' changed from 6 to 25 in ../modules/pam_echo/libpam_echo.a(pam_echo.o) ../modules/pam_exec/libpam_exec.a(pam_exec.o): In function `pam_sm_authenticate': pam_exec.o(.text+0x1a4): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ../modules/pam_exec/libpam_exec.a(pam_exec.o): In function `pam_sm_setcred': pam_exec.o(.text+0x1b4): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ld: Warning: size of symbol `pam_sm_setcred' changed from 6 to 14 in ../modules/pam_exec/libpam_exec.a(pam_exec.o) ../modules/pam_exec/libpam_exec.a(pam_exec.o): In function `pam_sm_acct_mgmt': pam_exec.o(.text+0x1c4): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ../modules/pam_exec/libpam_exec.a(pam_exec.o): In function `pam_sm_open_session': pam_exec.o(.text+0x1d4): multiple definition of `pam_sm_open_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x0): first defined here ../modules/pam_exec/libpam_exec.a(pam_exec.o): In function `pam_sm_close_session': pam_exec.o(.text+0x1e4): multiple definition of `pam_sm_close_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x1dc): first defined here ../modules/pam_exec/libpam_exec.a(pam_exec.o): In function `pam_sm_chauthtok': pam_exec.o(.text+0x1f4): multiple definition of `pam_sm_chauthtok' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x30): first defined here ld: Warning: size of symbol `pam_sm_chauthtok' changed from 25 to 14 in ../modules/pam_exec/libpam_exec.a(pam_exec.o) ../modules/pam_ftpusers/libpam_ftpusers.a(pam_ftpusers.o): In function `pam_sm_acct_mgmt': pam_ftpusers.o(.text+0x0): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ld: Warning: size of symbol `pam_sm_acct_mgmt' changed from 14 to 585 in ../modules/pam_ftpusers/libpam_ftpusers.a(pam_ftpusers.o) ../modules/pam_group/libpam_group.a(pam_group.o): In function `pam_sm_authenticate': pam_group.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 14 to 335 in ../modules/pam_group/libpam_group.a(pam_group.o) ../modules/pam_group/libpam_group.a(pam_group.o): In function `pam_sm_setcred': pam_group.o(.text+0x150): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ld: Warning: size of symbol `pam_sm_setcred' changed from 14 to 6 in ../modules/pam_group/libpam_group.a(pam_group.o) ../modules/pam_guest/libpam_guest.a(pam_guest.o): In function `pam_sm_authenticate': pam_guest.o(.text+0xa0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 335 to 273 in ../modules/pam_guest/libpam_guest.a(pam_guest.o) ../modules/pam_guest/libpam_guest.a(pam_guest.o): In function `pam_sm_setcred': pam_guest.o(.text+0x1b4): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o): In function `pam_sm_authenticate': pam_krb5.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 273 to 2354 in ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o) ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o): In function `pam_sm_setcred': pam_krb5.o(.text+0x934): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ld: Warning: size of symbol `pam_sm_setcred' changed from 6 to 1774 in ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o) ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o): In function `pam_sm_acct_mgmt': pam_krb5.o(.text+0x1024): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ld: Warning: size of symbol `pam_sm_acct_mgmt' changed from 585 to 535 in ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o) ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o): In function `pam_sm_chauthtok': pam_krb5.o(.text+0x123c): multiple definition of `pam_sm_chauthtok' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x30): first defined here ld: Warning: size of symbol `pam_sm_chauthtok' changed from 14 to 1080 in ../modules/pam_krb5/libpam_krb5.a(pam_krb5.o) ../modules/pam_ksu/libpam_ksu.a(pam_ksu.o): In function `pam_sm_authenticate': pam_ksu.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 2354 to 367 in ../modules/pam_ksu/libpam_ksu.a(pam_ksu.o) ../modules/pam_ksu/libpam_ksu.a(pam_ksu.o): In function `pam_sm_setcred': pam_ksu.o(.text+0x170): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ld: Warning: size of symbol `pam_sm_setcred' changed from 1774 to 6 in ../modules/pam_ksu/libpam_ksu.a(pam_ksu.o) ../modules/pam_lastlog/libpam_lastlog.a(pam_lastlog.o): In function `pam_sm_open_session': pam_lastlog.o(.text+0x0): multiple definition of `pam_sm_open_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_open_session' changed from 14 to 881 in ../modules/pam_lastlog/libpam_lastlog.a(pam_lastlog.o) ../modules/pam_lastlog/libpam_lastlog.a(pam_lastlog.o): In function `pam_sm_close_session': pam_lastlog.o(.text+0x374): multiple definition of `pam_sm_close_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x1dc): first defined here ld: Warning: size of symbol `pam_sm_close_session' changed from 14 to 149 in ../modules/pam_lastlog/libpam_lastlog.a(pam_lastlog.o) ../modules/pam_login_access/libpam_login_access.a(pam_login_access.o): In function `pam_sm_acct_mgmt': pam_login_access.o(.text+0x0): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ld: Warning: size of symbol `pam_sm_acct_mgmt' changed from 535 to 396 in ../modules/pam_login_access/libpam_login_access.a(pam_login_access.o) ../modules/pam_nologin/libpam_nologin.a(pam_nologin.o): In function `pam_sm_authenticate': pam_nologin.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 367 to 410 in ../modules/pam_nologin/libpam_nologin.a(pam_nologin.o) ../modules/pam_nologin/libpam_nologin.a(pam_nologin.o): In function `pam_sm_setcred': pam_nologin.o(.text+0x19c): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_opie/libpam_opie.a(pam_opie.o): In function `pam_sm_authenticate': pam_opie.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 410 to 420 in ../modules/pam_opie/libpam_opie.a(pam_opie.o) ../modules/pam_opie/libpam_opie.a(pam_opie.o): In function `pam_sm_setcred': pam_opie.o(.text+0x1a4): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_opieaccess/libpam_opieaccess.a(pam_opieaccess.o): In function `pam_sm_authenticate': pam_opieaccess.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 420 to 270 in ../modules/pam_opieaccess/libpam_opieaccess.a(pam_opieaccess.o) ../modules/pam_opieaccess/libpam_opieaccess.a(pam_opieaccess.o): In function `pam_sm_setcred': pam_opieaccess.o(.text+0x110): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_passwdqc/libpam_passwdqc.a(pam_passwdqc.o): In function `pam_sm_chauthtok': pam_passwdqc.o(.text+0x780): multiple definition of `pam_sm_chauthtok' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x30): first defined here ld: Warning: size of symbol `pam_sm_chauthtok' changed from 1080 to 2354 in ../modules/pam_passwdqc/libpam_passwdqc.a(pam_passwdqc.o) ../modules/pam_permit/libpam_permit.a(pam_permit.o): In function `pam_sm_authenticate': pam_permit.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 270 to 22 in ../modules/pam_permit/libpam_permit.a(pam_permit.o) ../modules/pam_permit/libpam_permit.a(pam_permit.o): In function `pam_sm_setcred': pam_permit.o(.text+0x18): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_permit/libpam_permit.a(pam_permit.o): In function `pam_sm_acct_mgmt': pam_permit.o(.text+0x20): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ld: Warning: size of symbol `pam_sm_acct_mgmt' changed from 396 to 6 in ../modules/pam_permit/libpam_permit.a(pam_permit.o) ../modules/pam_permit/libpam_permit.a(pam_permit.o): In function `pam_sm_chauthtok': pam_permit.o(.text+0x28): multiple definition of `pam_sm_chauthtok' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x30): first defined here ld: Warning: size of symbol `pam_sm_chauthtok' changed from 2354 to 6 in ../modules/pam_permit/libpam_permit.a(pam_permit.o) ../modules/pam_permit/libpam_permit.a(pam_permit.o): In function `pam_sm_open_session': pam_permit.o(.text+0x30): multiple definition of `pam_sm_open_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_open_session' changed from 881 to 6 in ../modules/pam_permit/libpam_permit.a(pam_permit.o) ../modules/pam_permit/libpam_permit.a(pam_permit.o): In function `pam_sm_close_session': pam_permit.o(.text+0x38): multiple definition of `pam_sm_close_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x1dc): first defined here ld: Warning: size of symbol `pam_sm_close_session' changed from 149 to 6 in ../modules/pam_permit/libpam_permit.a(pam_permit.o) ../modules/pam_radius/libpam_radius.a(pam_radius.o): In function `pam_sm_authenticate': pam_radius.o(.text+0x55c): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 22 to 915 in ../modules/pam_radius/libpam_radius.a(pam_radius.o) ../modules/pam_radius/libpam_radius.a(pam_radius.o): In function `pam_sm_setcred': pam_radius.o(.text+0x8f0): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_rhosts/libpam_rhosts.a(pam_rhosts.o): In function `pam_sm_authenticate': pam_rhosts.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 915 to 228 in ../modules/pam_rhosts/libpam_rhosts.a(pam_rhosts.o) ../modules/pam_rhosts/libpam_rhosts.a(pam_rhosts.o): In function `pam_sm_setcred': pam_rhosts.o(.text+0xe4): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_rootok/libpam_rootok.a(pam_rootok.o): In function `pam_sm_authenticate': pam_rootok.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 228 to 101 in ../modules/pam_rootok/libpam_rootok.a(pam_rootok.o) ../modules/pam_rootok/libpam_rootok.a(pam_rootok.o): In function `pam_sm_setcred': pam_rootok.o(.text+0x68): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_securetty/libpam_securetty.a(pam_securetty.o): In function `pam_sm_acct_mgmt': pam_securetty.o(.text+0x0): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ld: Warning: size of symbol `pam_sm_acct_mgmt' changed from 6 to 327 in ../modules/pam_securetty/libpam_securetty.a(pam_securetty.o) ../modules/pam_self/libpam_self.a(pam_self.o): In function `pam_sm_authenticate': pam_self.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 101 to 165 in ../modules/pam_self/libpam_self.a(pam_self.o) ../modules/pam_self/libpam_self.a(pam_self.o): In function `pam_sm_setcred': pam_self.o(.text+0xa8): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_ssh/libpam_ssh.a(pam_ssh.o): In function `pam_sm_authenticate': pam_ssh.o(.text+0x110): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 165 to 381 in ../modules/pam_ssh/libpam_ssh.a(pam_ssh.o) ../modules/pam_ssh/libpam_ssh.a(pam_ssh.o): In function `pam_sm_setcred': pam_ssh.o(.text+0x290): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_ssh/libpam_ssh.a(pam_ssh.o): In function `pam_sm_open_session': pam_ssh.o(.text+0x620): multiple definition of `pam_sm_open_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_open_session' changed from 6 to 173 in ../modules/pam_ssh/libpam_ssh.a(pam_ssh.o) ../modules/pam_ssh/libpam_ssh.a(pam_ssh.o): In function `pam_sm_close_session': pam_ssh.o(.text+0x6d0): multiple definition of `pam_sm_close_session' ../modules/pam_chroot/libpam_chroot.a(pam_chroot.o)(.text+0x1dc): first defined here ld: Warning: size of symbol `pam_sm_close_session' changed from 6 to 224 in ../modules/pam_ssh/libpam_ssh.a(pam_ssh.o) ../modules/pam_tacplus/libpam_tacplus.a(pam_tacplus.o): In function `pam_sm_authenticate': pam_tacplus.o(.text+0x10c): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 381 to 1213 in ../modules/pam_tacplus/libpam_tacplus.a(pam_tacplus.o) ../modules/pam_tacplus/libpam_tacplus.a(pam_tacplus.o): In function `pam_sm_setcred': pam_tacplus.o(.text+0x5cc): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_unix/libpam_unix.a(pam_unix.o): In function `pam_sm_authenticate': pam_unix.o(.text+0x0): multiple definition of `pam_sm_authenticate' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x0): first defined here ld: Warning: size of symbol `pam_sm_authenticate' changed from 1213 to 439 in ../modules/pam_unix/libpam_unix.a(pam_unix.o) ../modules/pam_unix/libpam_unix.a(pam_unix.o): In function `pam_sm_setcred': pam_unix.o(.text+0x1b8): multiple definition of `pam_sm_setcred' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x20): first defined here ../modules/pam_unix/libpam_unix.a(pam_unix.o): In function `pam_sm_acct_mgmt': pam_unix.o(.text+0x1c0): multiple definition of `pam_sm_acct_mgmt' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x28): first defined here ld: Warning: size of symbol `pam_sm_acct_mgmt' changed from 327 to 832 in ../modules/pam_unix/libpam_unix.a(pam_unix.o) ../modules/pam_unix/libpam_unix.a(pam_unix.o): In function `pam_sm_chauthtok': pam_unix.o(.text+0x500): multiple definition of `pam_sm_chauthtok' ../modules/pam_deny/libpam_deny.a(pam_deny.o)(.text+0x30): first defined here ld: Warning: size of symbol `pam_sm_chauthtok' changed from 6 to 1484 in ../modules/pam_unix/libpam_unix.a(pam_unix.o) *** Error code 1 Stop in /usr/src/lib/libpam/libpam. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real 9m33.784s user 7m7.094s sys 1m32.243s su-2.05b# On Feb 22, 2004, at 2:13 PM, Jason Lixfeld wrote: > Ok, I've been trying for the last 24 hours to get a custom kernel and > make buildworld to run. > > Make buildkernel KERNCONF=ESHARA is giving me issues with accf_http. > Some reading (including a post yesterday re: CFLAGS+= -fPIC per > default?) suggested CFLAGS -fPIC in /etc/make.conf which hasn't > helped. Attached is the make output. > > > > Make buildworld has problems with libpam. Some reading suggested > CFLAGS -O2 in /etc/make.conf which hasn't helped. Attached is the > make output. > > > > Does this stuff ring a bell for anyone? Anyone have any bright ideas? > :)_______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to > "freebsd-amd64-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 13:23:05 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07F0016A4CE for ; Sun, 22 Feb 2004 13:23:05 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E01E543D1D for ; Sun, 22 Feb 2004 13:23:04 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1MLN2OJ095017; Sun, 22 Feb 2004 13:23:02 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1MLN163095016; Sun, 22 Feb 2004 13:23:01 -0800 (PST) (envelope-from obrien) Date: Sun, 22 Feb 2004 13:23:01 -0800 From: "David O'Brien" To: David Rhodus Message-ID: <20040222212301.GA94800@dragon.nuxi.com> References: <16434.44274.200375.8454@grasshopper.cs.duke.edu> <42E6A174-6226-11D8-98F7-000393921E22@silzer.net> <20040222173638.GD91129@dragon.nuxi.com> <692691A3-655E-11D8-84F2-000A959B213E@machdep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <692691A3-655E-11D8-84F2-000A959B213E@machdep.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org Subject: Re: which motherboard and which chipset? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 21:23:05 -0000 On Sun, Feb 22, 2004 at 12:41:57PM -0500, David Rhodus wrote: > > On Feb 22, 2004, at 12:36 PM, David O'Brien wrote: > > >On Wed, Feb 18, 2004 at 10:22:27AM -0500, Scott Silzer wrote: > >>Seams like an appropriate thread to ask so has any one had any > >>experience with the Arima/Accelertech ATO2161-A ? > >>http://www.accelertech.com/motherboard.php > > > >Lots of people have that board; but it was sold to them as the "Arima > >HDAMA". It is a solid board. Being the first 4+4 DIMM configuration, > >a > >lot of vendors of 1U clusters use it. > > What type of fan are people using to get that wedged into a 1U case ? Conical blowers that sit in front of the mobo. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 13:27:50 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84F7816A4CE for ; Sun, 22 Feb 2004 13:27:50 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2844243D2F for ; Sun, 22 Feb 2004 13:27:50 -0800 (PST) (envelope-from jlfenton@citlink.net) Received: (qmail 10168 invoked from network); 22 Feb 2004 21:27:36 -0000 Received: from unknown (HELO citlink.net) ([67.136.108.212]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 22 Feb 2004 21:27:36 -0000 Message-ID: <40391EC6.7010808@citlink.net> Date: Sun, 22 Feb 2004 14:27:34 -0700 From: Joseph Fenton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> In-Reply-To: <20040222185212.EB6BE16A4D1@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 21:27:50 -0000 >>Adding CFLAGS= -fPIC to /etc/make.conf may be a local solution but >>are there any drawbacks by adding something like >>.if ${ARCH} == "amd64" >>CFLAGS+= -fPIC >>.endif >> >>to ports/Mk/bsd.port.mk? >> >> > >No.. please don't. Although the AMD64 platform supports PIC addressing >modes directly, it is still a penalty. (Although thankfully, its >nowhere near as expensive as it is on i386!) > >For example, in libc when built in PIC mode: >#ifdef PIC > movq PIC_GOT(HIDENAME(curbrk)),%rdx > movq (%rdx),%rax >#else > movq HIDENAME(curbrk)(%rip),%rax >#endif > >The problem is that we can't be sure that everything will be in +/- 31 >bit offsets of each other. This means that PIC objects have to do >indirect memory references that aren't required in no-pic mode. > >I386 also loses a general purpose register (%ebx) which is why -fpic is >more expensive there. But even though we don't lose a register, its >still a cost because of the extra global-offset-table memory >references. > >Footnote: you just made me wonder about some of these ifdefs.. We >shouldn't need them for intra-object references like this. I'll have >to go and look again. > > Sorry to be anal, but PC-relative addressing is by definition position-independent code. Who was the bright individual who decided that when compiling PIC code to NOT use PC-relative and to NOT use PC-relative for non-PIC code? This is counter-intuitive. For PIC code, you use PC-relative addressing in two cases: 1 - the code is guaranteed to be a constant distance apart, like code in the same section; 2 - when the loader guarantees the relative position of different sections, like code and data contained in a ROM. Case 1 could be violated by the code being too far apart for PC-relative addressing. This is virtually impossible for the AMD64 as I doubt we'll see code exceeding 2G in size in the next several decades. Code is only now exceeding a few megabytes. Case 2 is usually your problem, which leads to tables used to hold addresses or offsets. Both sides of the #ifdef PIC are doing valid PIC code. PC-relative addressing should be used wherever possible unless it incurs a speed penalty. Non-PIC code generally does PC-relative code if it is faster and is legal, for example, when referring to code within the same section. When the address must be set by the loader for non-PIC code, it seems to me that the fastest code would be like this: mov ,%rdx movq (%rdx),%rax or if the address is > 4G movq ,%rdx movq (%rdx),%rax The loader would then set the immediate vector upon loading the sections. This avoids a memory hit for accessing a table of addresses while only adding at most 5 bytes to the size of the code. I would probably use this unless the user is compiling with flags set to compile with minimized code size. Sorry to nit-pick like this, but having worked on both Mac and Amiga ROMs, PIC mode under BSD really seems backwards to me. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 13:43:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 769B116A4CE for ; Sun, 22 Feb 2004 13:43:03 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A46E43D2F for ; Sun, 22 Feb 2004 13:43:03 -0800 (PST) (envelope-from jlfenton@citlink.net) Received: (qmail 22183 invoked from network); 22 Feb 2004 21:43:01 -0000 Received: from unknown (HELO citlink.net) ([67.136.108.212]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 22 Feb 2004 21:43:01 -0000 Message-ID: <40392268.9000101@citlink.net> Date: Sun, 22 Feb 2004 14:43:04 -0700 From: Joseph Fenton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> In-Reply-To: <20040222185212.EB6BE16A4D1@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: which motherboard and which chipset? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 21:43:03 -0000 On Tuesday 17 February 2004 01:18 pm, Andrew Gallatin wrote: >> David O'Brien writes: >> > nVidia nForce3 [for AMD64] chipsets are very problematic for >> > Unix(BSD)/Linux. I would avoid them if you want to run a >> > non-MS-Windows operating system. >> >> Whew. Just in time, I was just about to order an SK8N. What do you >> suggest for a solid single-CPU socket-940 board which will use ECC >> memory? Asus SK8V? > > > > I'd love to get hold of a SK8V if only I could find one. I have two > K8V deluxes (one at home, the other at work, both with ECC > non-Registered PC3200 memory from crucial.com). My SK8N with my (then) > $750 cpu and $350 of ECC/REG PC3200 ram is on a shelf gathering dust > because I lost my trust in the board. > > Personally, I prefer the ASUS boards over the tyans because of the > flexibility in the bios and the vastly superior active fan speed > control system. But I have a slight preference for the AMD 8xxx > chipset over the VIA K8T800, but its only slight. Both are (IMHO) way > ahead of the nVidia nForce3-150. If you have to listen to the machine > next to your desk, I suggest an asus - the tyan fans run at full speed > all the time, with no thermal based fan throttling. If you don't have > to listen to it, and want something slightly more server-oriented then > the tyans are probably a slightly better bet because the AMD chipset > has had longer to shake out the bugs. The MSI Master1-FAR is just a single CPU version of the MSI Master2-FAR K8T800 motherboard. I have the Master2-FAR and it works great. The only problem I ran into was the memory - I bought bargain basement RAM; when the CPU got too loaded, it would crash. I was able to cure this by raising the memory voltage a little. The system has been rock-stable since then, even with el-cheapo memory. :) From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 14:02:12 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A9B416A4CE for ; Sun, 22 Feb 2004 14:02:12 -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 46CE443D1F for ; Sun, 22 Feb 2004 14:02:12 -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 i1MM2AOE041377; Sun, 22 Feb 2004 14:02:10 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) i1MM2AkY054128; Sun, 22 Feb 2004 14:02:10 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i1MM2Ae1054127; Sun, 22 Feb 2004 14:02:10 -0800 (PST) (envelope-from marcel) Date: Sun, 22 Feb 2004 14:02:10 -0800 From: Marcel Moolenaar To: Joseph Fenton Message-ID: <20040222220210.GA54064@dhcp01.pn.xcllnt.net> References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40391EC6.7010808@citlink.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-amd64@freebsd.org Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 22:02:12 -0000 On Sun, Feb 22, 2004 at 02:27:34PM -0700, Joseph Fenton wrote: > > Sorry to be anal, but PC-relative addressing is by definition > position-independent code. False. The fundamental property of PIC , besides the fact that it's a complete misnomer, is that there are no relocations in the code segment. The operating system cannot share read-only segments if the linker/loader has to modify it first to relocate it depending on where segments are loaded in memory for each process. Across processes the relative distance between two segments within the same shared executable is not fixed. Therefore, PIC has not so much to do with whether or not PC-relative addressing can be used per se, as it has to do with how much the compiler/assembler knows about the relative distance between addresses. In practice this is not as much as it seems due to the tendency to make the unit of compilation smaller. > Sorry to nit-pick like this, but having worked on both Mac > and Amiga ROMs, PIC mode under BSD really seems > backwards to me. It's no different than PIC on other OSes. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 14:41:25 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0130716A4CE for ; Sun, 22 Feb 2004 14:41:25 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97A9543D1D for ; Sun, 22 Feb 2004 14:41:24 -0800 (PST) (envelope-from jlfenton@citlink.net) Received: (qmail 25045 invoked from network); 22 Feb 2004 22:41:23 -0000 Received: from unknown (HELO citlink.net) ([67.136.108.212]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 22 Feb 2004 22:41:23 -0000 Message-ID: <40393010.4090402@citlink.net> Date: Sun, 22 Feb 2004 15:41:20 -0700 From: Joseph Fenton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar , freebsd-amd64@freebsd.org References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> <20040222220210.GA54064@dhcp01.pn.xcllnt.net> In-Reply-To: <20040222220210.GA54064@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 22:41:25 -0000 Marcel Moolenaar wrote: >On Sun, Feb 22, 2004 at 02:27:34PM -0700, Joseph Fenton wrote: > > >>Sorry to be anal, but PC-relative addressing is by definition >>position-independent code. >> >> > >False. > >The fundamental property of PIC , besides the fact that it's a >complete misnomer, is that there are no relocations in the code >segment. > You just proved my statement true. PC-relative code contains no relocation for within a code section. How do you think that conditional branches work? They do PC-relative jumps inside the code section. > The operating system cannot share read-only segments if >the linker/loader has to modify it first to relocate it depending >on where segments are loaded in memory for each process. Across >processes the relative distance between two segments within the >same shared executable is not fixed. Therefore, PIC has not so >much to do with whether or not PC-relative addressing can be used >per se, as it has to do with how much the compiler/assembler knows >about the relative distance between addresses. In practice this >is not as much as it seems due to the tendency to make the unit >of compilation smaller. > > > I stated in my email that between two sections you'd have to use a table. That in no way invalidates the fact that within a section, PC-relative is position-independent. As shown in the code snippets, PC-relative is also smaller. >>Sorry to nit-pick like this, but having worked on both Mac >>and Amiga ROMs, PIC mode under BSD really seems >>backwards to me. >> >> > >It's no different than PIC on other OSes. > > > You've obviously never looked at Mac or Amiga code. Not BSD on the Mac or Amiga, but Mac or Amiga code. You admit above that PIC on BSD is a complete misnomer. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 15:17:37 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3052E16A4CE for ; Sun, 22 Feb 2004 15:17:37 -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 0EE8343D1D for ; Sun, 22 Feb 2004 15:17:37 -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 i1MNHZOE041702; Sun, 22 Feb 2004 15:17:35 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) i1MNHZV9079670; Sun, 22 Feb 2004 15:17:35 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i1MNHZSt079669; Sun, 22 Feb 2004 15:17:35 -0800 (PST) (envelope-from marcel) Date: Sun, 22 Feb 2004 15:17:35 -0800 From: Marcel Moolenaar To: Joseph Fenton Message-ID: <20040222231735.GA79618@dhcp01.pn.xcllnt.net> References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> <20040222220210.GA54064@dhcp01.pn.xcllnt.net> <40393010.4090402@citlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40393010.4090402@citlink.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-amd64@freebsd.org Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 23:17:37 -0000 On Sun, Feb 22, 2004 at 03:41:20PM -0700, Joseph Fenton wrote: > Marcel Moolenaar wrote: > > >On Sun, Feb 22, 2004 at 02:27:34PM -0700, Joseph Fenton wrote: > > > > > >>Sorry to be anal, but PC-relative addressing is by definition > >>position-independent code. > >> > >> > > > >False. > > > >The fundamental property of PIC , besides the fact that it's a > >complete misnomer, is that there are no relocations in the code > >segment. > > > You just proved my statement true. PC-relative code contains no > relocation for within a code section. How do you think that conditional > branches work? They do PC-relative jumps inside the code section. You fail to see the point. PC relative relocations are not guaranteed to be without relocation and hence are not by definition PIC. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 15:50:17 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D929316A4CF for ; Sun, 22 Feb 2004 15:50:17 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71BA143D45 for ; Sun, 22 Feb 2004 15:50:17 -0800 (PST) (envelope-from jlfenton@citlink.net) Received: (qmail 25183 invoked from network); 22 Feb 2004 23:42:56 -0000 Received: from unknown (HELO citlink.net) ([67.136.108.212]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 22 Feb 2004 23:42:56 -0000 Message-ID: <40393E7C.2000300@citlink.net> Date: Sun, 22 Feb 2004 16:42:52 -0700 From: Joseph Fenton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> <20040222220210.GA54064@dhcp01.pn.xcllnt.net> <40393010.4090402@citlink.net> <20040222231735.GA79618@dhcp01.pn.xcllnt.net> In-Reply-To: <20040222231735.GA79618@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 23:50:18 -0000 Marcel Moolenaar wrote: >>>The fundamental property of PIC , besides the fact that it's a >>>complete misnomer, is that there are no relocations in the code >>>segment. >>> >>> >>> >>You just proved my statement true. PC-relative code contains no >>relocation for within a code section. How do you think that conditional >>branches work? They do PC-relative jumps inside the code section. >> >> > >You fail to see the point. PC relative relocations are not >guaranteed to be without relocation and hence are not by >definition PIC. > > > That makes no sense. Why would you relocate a PC-relative reference unless it was an access across sections? Do you mean to say that all Jcc opcodes are relocated? If not, then obviously PC-relative addresses are not always relocated and therefore suitable for PIC. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 16:12:54 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A38D16A4CE for ; Sun, 22 Feb 2004 16:12:54 -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 0894243D1D for ; Sun, 22 Feb 2004 16:12:54 -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 i1N0CqOE041929; Sun, 22 Feb 2004 16:12:52 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) i1N0CqR6079859; Sun, 22 Feb 2004 16:12:52 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i1N0CqKM079858; Sun, 22 Feb 2004 16:12:52 -0800 (PST) (envelope-from marcel) Date: Sun, 22 Feb 2004 16:12:52 -0800 From: Marcel Moolenaar To: Joseph Fenton Message-ID: <20040223001252.GA79774@dhcp01.pn.xcllnt.net> References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> <20040222220210.GA54064@dhcp01.pn.xcllnt.net> <40393010.4090402@citlink.net> <20040222231735.GA79618@dhcp01.pn.xcllnt.net> <40393E7C.2000300@citlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40393E7C.2000300@citlink.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-amd64@freebsd.org Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 00:12:54 -0000 On Sun, Feb 22, 2004 at 04:42:52PM -0700, Joseph Fenton wrote: > > > >You fail to see the point. PC relative relocations are not > >guaranteed to be without relocation and hence are not by > >definition PIC. > > > That makes no sense. Just not to you. You even use this in your argument by differentiating between intra- and inter-section addressing. The reason my words do not make sense to you is that you map it onto your own point of view as if we're approaching this from the same angle, but all you're seeing is the mismatch between my words and your PoV. I suggest you step away from depicting the final code when you implicitly do away with all the uncertainties that a compiler needs to work with, to which the -fPIC applies anyway and how it affects the behaviour of the compiler. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 16:27:52 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FBFD16A4CE for ; Sun, 22 Feb 2004 16:27:52 -0800 (PST) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2061143D1D for ; Sun, 22 Feb 2004 16:27:52 -0800 (PST) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-213-023-058-162.arcor-ip.net [213.23.58.162]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id A2BA6929749 for ; Mon, 23 Feb 2004 01:27:47 +0100 (CET) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.10/8.12.10) with ESMTP id i1N0Rkhw065643 for ; Mon, 23 Feb 2004 01:27:47 +0100 (CET) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.10/8.12.10/Submit) id i1N0Rkki065642 for freebsd-amd64@freebsd.org; Mon, 23 Feb 2004 01:27:46 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Mon, 23 Feb 2004 00:27:46 +0000 (UTC) Message-ID: References: <4CC57F17-64E9-11D8-ACAA-000A95BAD088@raisdorf.net> <200402220033.01795.peter@wemm.org> <20040222185208.GA53610@dhcp01.pn.xcllnt.net> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-amd64@freebsd.org Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 00:27:52 -0000 Marcel Moolenaar wrote: > I think it was Christian who asked why -fPIC was not the default > and I think it's a good question. No. All shared libraries, dynamically loaded modules, and the like should be built with -fPIC, independent of architecture. If some of them are currently not, then the respective ports are broken. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 17:08:00 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B69516A4D0 for ; Sun, 22 Feb 2004 17:08:00 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F74243D31 for ; Sun, 22 Feb 2004 17:08:00 -0800 (PST) (envelope-from jlfenton@citlink.net) Received: (qmail 29155 invoked from network); 23 Feb 2004 01:07:59 -0000 Received: from unknown (HELO citlink.net) ([67.136.108.212]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 23 Feb 2004 01:07:59 -0000 Message-ID: <40395271.3030907@citlink.net> Date: Sun, 22 Feb 2004 18:08:01 -0700 From: Joseph Fenton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> <20040222220210.GA54064@dhcp01.pn.xcllnt.net> <40393010.4090402@citlink.net> <20040222231735.GA79618@dhcp01.pn.xcllnt.net> <40393E7C.2000300@citlink.net> <20040223001252.GA79774@dhcp01.pn.xcllnt.net> In-Reply-To: <20040223001252.GA79774@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 01:08:00 -0000 Marcel Moolenaar wrote: >>That makes no sense. >> >> > >Just not to you. You even use this in your argument by differentiating >between intra- and inter-section addressing. The reason my words do not >make sense to you is that you map it onto your own point of view as if >we're approaching this from the same angle, but all you're seeing is >the mismatch between my words and your PoV. > >I suggest you step away from depicting the final code when you >implicitly do away with all the uncertainties that a compiler needs >to work with, to which the -fPIC applies anyway and how it affects >the behaviour of the compiler. > > > Most of the compilers I've dealt with on other platforms had no trouble dealing with intra versus inter-section addressing. Guess that's what's giving me the trouble seeing it from your end. It's also the reason I prefer to work in assembly language. If the compiler has a problem dealing with it, I sure don't. With assembly, it does EXACTLY what I want it to. I'll just accept what you say and chalk it up to limitations in the method currently used for cpu-independent compilation. Thanks for helping try to get me straight on this. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 19:02:22 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA2DE16A4CE; Sun, 22 Feb 2004 19:02:22 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5809C43D2D; Sun, 22 Feb 2004 19:02:22 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1N32Jo8045700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 22 Feb 2004 21:02:19 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1N32IgU045697; Sun, 22 Feb 2004 21:02:18 -0600 (CST) Date: Sun, 22 Feb 2004 21:02:18 -0600 (CST) Message-Id: <200402230302.i1N32IgU045697@bigtex.jrv.org> From: James Van Artsdalen To: peter@wemm.org In-reply-to: <200402220057.36903.peter@wemm.org> (message from Peter Wemm on Sun, 22 Feb 2004 00:57:36 -0800) References: <200402220057.36903.peter@wemm.org> cc: amd64@freebsd.org cc: adridg@cs.kun.nl cc: gerald@pfeifer.com cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 03:02:22 -0000 > From: Peter Wemm > Date: Sun, 22 Feb 2004 00:57:36 -0800 > > On Wednesday 18 February 2004 12:37 am, Gerald Pfeifer wrote: > > > 1) AMD didn't give the platform an official name till fairly late > > > 2) Some folks chose amd64 > > > 3) Later the muttonheads at the FSF chose x86_64 > > > > And right they were. See yesterdays press announcement by Intel. > > That sequence of events isn't quite right. AMD originally came up with > x86-64. When Microsoft got going on the port, they said "that name > sucks to type, how about amd64? We're NOT using x86=64". And so it > became "amd64" or AMD64. And FWIW, I agree. x86_64 is the worst > possible name to type. My understanding is that the linux crowd picked x86_64 and Microsoft and FreeBSD picked amd64. At this point everyone, except Microsoft, has done releases and systems are deployed and in the field. It's too late to go back and make changes without good reason: configure scripts need to accept both. Why not something like to solve the heartburn? There's still a collision of some sort between freebsd.h and x86_64.h that needs to be solved, but that's a different issue. *** config.guess.~1~ Thu Jan 30 17:25:36 2003 --- config.guess Sun Feb 22 20:41:42 2004 *************** *** 759,764 **** --- 759,767 ---- #endif EOF eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=` + if [ ".$UNAME_MACHINE" = ".amd64" ] ; then + UNAME_MACHINE=x86_64 + fi echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`${LIBC:+-$LIBC} exit 0 ;; i*:CYGWIN*:*) From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 19:02:22 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA2DE16A4CE; Sun, 22 Feb 2004 19:02:22 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5809C43D2D; Sun, 22 Feb 2004 19:02:22 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1N32Jo8045700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 22 Feb 2004 21:02:19 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1N32IgU045697; Sun, 22 Feb 2004 21:02:18 -0600 (CST) Date: Sun, 22 Feb 2004 21:02:18 -0600 (CST) Message-Id: <200402230302.i1N32IgU045697@bigtex.jrv.org> From: James Van Artsdalen To: peter@wemm.org In-reply-to: <200402220057.36903.peter@wemm.org> (message from Peter Wemm on Sun, 22 Feb 2004 00:57:36 -0800) References: <200402220057.36903.peter@wemm.org> cc: amd64@freebsd.org cc: adridg@cs.kun.nl cc: gerald@pfeifer.com cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 and lang/gcc3x on -CURRENT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 03:02:22 -0000 > From: Peter Wemm > Date: Sun, 22 Feb 2004 00:57:36 -0800 > > On Wednesday 18 February 2004 12:37 am, Gerald Pfeifer wrote: > > > 1) AMD didn't give the platform an official name till fairly late > > > 2) Some folks chose amd64 > > > 3) Later the muttonheads at the FSF chose x86_64 > > > > And right they were. See yesterdays press announcement by Intel. > > That sequence of events isn't quite right. AMD originally came up with > x86-64. When Microsoft got going on the port, they said "that name > sucks to type, how about amd64? We're NOT using x86=64". And so it > became "amd64" or AMD64. And FWIW, I agree. x86_64 is the worst > possible name to type. My understanding is that the linux crowd picked x86_64 and Microsoft and FreeBSD picked amd64. At this point everyone, except Microsoft, has done releases and systems are deployed and in the field. It's too late to go back and make changes without good reason: configure scripts need to accept both. Why not something like to solve the heartburn? There's still a collision of some sort between freebsd.h and x86_64.h that needs to be solved, but that's a different issue. *** config.guess.~1~ Thu Jan 30 17:25:36 2003 --- config.guess Sun Feb 22 20:41:42 2004 *************** *** 759,764 **** --- 759,767 ---- #endif EOF eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=` + if [ ".$UNAME_MACHINE" = ".amd64" ] ; then + UNAME_MACHINE=x86_64 + fi echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`${LIBC:+-$LIBC} exit 0 ;; i*:CYGWIN*:*) From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 20:29:29 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CD9E16A4CE; Sun, 22 Feb 2004 20:29:29 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EDF743D31; Sun, 22 Feb 2004 20:29:29 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id 5A1AA3C8013; Sun, 22 Feb 2004 23:31:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Sun, 22 Feb 2004 23:29:25 -0500 To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.613) cc: freebsd-questions@freebsd.org Subject: Kernel Compilation issues/5.2-CURRENT/AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 04:29:29 -0000 make buildkernel keeps failing here: ===> accf_data cc -O -fPIC -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /usr/obj/usr/src/sys/ESHARA/opt_global.h -I. -I@ -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/ESHARA -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/netinet/accf_data.c cc1: sorry, unimplemented: code model kernel not supported in PIC mode cc1: error: code model `kernel' not supported in the 64 bit mode *** Error code 1 Stop in /usr/src/sys/modules/accf_data. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/ESHARA. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I added in CFLAGS= -O -fPIC to /etc/make.conf. Here's the diff between my custom kernel and the plain vanilla GENERIC. GENERIC compiles fine, but for some reason, there is something missing from mine that's in GENERIC that's causing it to fail but I have no idea what. I thought I checked out NOTES pretty thoroughly but I guess not. su-2.05b# diff ESHARA GENERIC 3c3,5 < ident ESHARA --- > ident GENERIC > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > makeoptions NO_MODULES=not_yet 5a8 > options INET6 # IPv6 communications protocols 7a11 > options UFS_ACL # Support for access control lists 8a13,17 > options MD_ROOT # MD is a potential root device > options NFSCLIENT # Network Filesystem Client > options NFSSERVER # Network Filesystem Server > options NFS_ROOT # NFS usable as /, requires NFSCLIENT > options MSDOSFS # MSDOS Filesystem 9a19,20 > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework 11a23,24 > options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI > options KTRACE # ktrace(1) support 16a30,38 > options AHC_REG_PRETTY_PRINT # Print register bitfields in debug > options AHD_REG_PRETTY_PRINT # Print register bitfields in debug > options PFIL_HOOKS # pfil(9) framework > options DDB # Enable the kernel debugger > options INVARIANTS # Enable calls of extra sanity checking > options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > options SMP # Symmetric MultiProcessor Kernel 21a44,45 > device pcm > device fdc 25a50,51 > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives 26a53,83 > device ahb # EISA AHA1742 family > device ahc # AHA2940 and onboard AIC7xxx devices > device ahd # AHA39320/29320 and onboard AIC79xx devices > device amd # AMD 53C974 (Tekram DC-390(T)) > device isp # Qlogic family > device mpt # LSI-Logic MPT-Fusion > device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') > device trm # Tekram DC395U/UW/F DC315U adapters > device adv # Advansys SCSI adapters > device adw # Advansys wide SCSI adapters > device aha # Adaptec 154x SCSI adapters > device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. > device bt # Buslogic/Mylex MultiMaster SCSI adapters > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and SAF-TE) > device amr # AMI MegaRAID > device ciss # Compaq Smart RAID 5* > device dpt # DPT Smartcache III, IV - See NOTES for options > device iir # Intel Integrated RAID > device ips # IBM (Adaptec) ServeRAID > device mly # Mylex AcceleRAID/eXtremeRAID > device aac # Adaptec FSA RAID > device aacp # SCSI passthrough for aac (requires CAM) > device ida # Compaq Smart RAID > device mlx # Mylex DAC960 family > device twe # 3ware ATA RAID 28a86 > device psm # PS/2 mouse 31a90,92 > device cbb # cardbus (yenta) bridge > device pccard # PC Card (16-bit) bus > device cardbus # CardBus (32-bit) bus 32a94,102 > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip # TCP/IP over parallel > device ppi # Parallel port interface device > device de # DEC/Intel DC21x4x (``Tulip'') > device em # Intel PRO/1000 adapter Gigabit Ethernet Card > device txp # 3Com 3cR990 (``Typhoon'') > device vx # 3Com 3c590, 3c595 (``Vortex'') 33a104 > device bfe # Broadcom BCM440x 10/100 ethernet 34a106,130 > device dc # DEC/Intel 21143 and various workalikes > device fxp # Intel EtherExpress PRO/100B (82557, 82558) > device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') > device re # RealTek 8139C+/8169/8169S/8110S > device rl # RealTek 8129/8139 > device sf # Adaptec AIC-6915 (``Starfire'') > device sis # Silicon Integrated Systems SiS 900/SiS 7016 > device sk # SysKonnect SK-984x and SK-982x gigabit ethernet > device ste # Sundance ST201 (D-Link DFE-550TX) > device ti # Alteon Networks Tigon I/II gigabit ethernet > device tl # Texas Instruments ThunderLAN > device tx # SMC EtherPower II (83c170 ``EPIC'') > device vr # VIA Rhine, Rhine II > device wb # Winbond W89C840F > device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') > device cs # Crystal Semiconductor CS89x0 NIC > device ex # Intel EtherExpress Pro/10 and Pro/10+ > device ep # Etherlink III based cards > device fe # Fujitsu MB8696x based cards > device sn # SMC's 9000 series of ethernet chips > device xe # Xircom pccard ethernet > device wlan # 802.11 support > device an # Aironet 4500/4800 802.11 wireless NICs. > device awi # BayStack 660 and others > device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. 37a134,136 > device sl # Kernel SLIP > device ppp # Kernel PPP > device tun # Packet tunnel. 38a138,140 > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) 39a142 > device uhci # UHCI PCI->USB interface 44a148,159 > device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus and da > device ums # Mouse > device urio # Diamond Rio 500 MP3 player > device uscanner # Scanners > device aue # ADMtek USB ethernet > device axe # ASIX Electronics USB ethernet > device cue # CATC USB ethernet > device kue # Kawasaki LSI USB ethernet > device firewire # FireWire bus code > device sbp # SCSI over FireWire (Requires scbus and da) > device fwe # Ethernet over FireWire (non-standard!) From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 20:48:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E169A16A4CE for ; Sun, 22 Feb 2004 20:48:42 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93FA843D2D for ; Sun, 22 Feb 2004 20:48:42 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1N4mfo8048942 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 22 Feb 2004 22:48:41 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1N4mfHK048939; Sun, 22 Feb 2004 22:48:41 -0600 (CST) Date: Sun, 22 Feb 2004 22:48:41 -0600 (CST) Message-Id: <200402230448.i1N4mfHK048939@bigtex.jrv.org> From: James Van Artsdalen To: bm@malepartus.de In-reply-to: <20040222095700.2c58b1e7.bm@malepartus.de> (message from Burkard Meyendriesch on Sun, 22 Feb 2004 09:57:00 +0100) References: <20040222095700.2c58b1e7.bm@malepartus.de> cc: freebsd-amd64@freebsd.org Subject: Re: CURRENT: error in "make buildworld" on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 04:48:43 -0000 > Date: Sun, 22 Feb 2004 09:57:00 +0100 > From: Burkard Meyendriesch > > yesterday I launched my new box (Asus K8V Deluxe, Athlon64/3000, 1GB ECC RAM, 2x160GB RAID1). I installed 5.2-RELEASE from CD. After that I checked out the actual source tree and tried to "make buildworld". This ends up with: > > In file included from editline.c:4: > /usr/src/lib/libedit/chared.c: In function `ch_init': > /usr/src/lib/libedit/chared.c:456: error: `ED_UNASSIGNED' undeclared (first use in this function) > /usr/src/lib/libedit/chared.c:456: error: (Each undeclared identifier is reported only once > /usr/src/lib/libedit/chared.c:456: error: for each function it appears in.) > /usr/src/lib/libedit/chared.c: In function `ch_reset': > /usr/src/lib/libedit/chared.c:493: error: `ED_UNASSIGNED' undeclared (first use in this function) > ... (lots of similar error messages follow...) > > What's going wrong? > Burkard > > P.S.: I have no item enabled in /etc/make.conf. Do you really want to sync against -current? Most people should probably sync against the RELENG_5_2 tag. /etc/make.conf shouldn't be changed. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 21:01:24 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F65A16A4CE for ; Sun, 22 Feb 2004 21:01:24 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CAB243D2F for ; Sun, 22 Feb 2004 21:01:24 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1N51No8049547 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 22 Feb 2004 23:01:23 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1N51NB0049544; Sun, 22 Feb 2004 23:01:23 -0600 (CST) Date: Sun, 22 Feb 2004 23:01:23 -0600 (CST) Message-Id: <200402230501.i1N51NB0049544@bigtex.jrv.org> From: James Van Artsdalen To: freebsd-amd64@freebsd.org Subject: Opteron ECC X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 05:01:24 -0000 Several weeks ago I reported an instability in my system WRT ECC. It turns out that AMD has published its Opteron errata sheet and errate item 101 appears to be the issue: a bug in the Opteron means you can't have both "node interleave" and ECC scrubbing on at the same time. I've turned off node interleave. I have no idea what are reasonable values for ECC scrubbing in ROM setup but it seems more useful to leave scrubbing on than to enable node interleave, even without a NUMA-aware kernel. (this only applies to multiprocessor systems) > From: James Van Artsdalen > Subject: Re: shaky support or my system? > > > Date: Wed, 4 Feb 2004 06:07:19 -0600 (CST) > > From: James Van Artsdalen > > > > > From: Adriaan de Groot > > > Date: Wed, 4 Feb 2004 12:51:45 +0100 > > > > > > > in either fbsd5.2 nor the recent 5.2.1RC. One of the things that makes > > > > it crash for sure is the /usr/ports/benchmarks/ubench program. It does > > > > > > Don't run that, it'll just tell you that the system is only marginally faster > > > than the athlon XP it replaces. > > > > I've reproduced Janne's panic with ubench twice. Both show similar > > outputs from the panic. Panic #3 is proving more elusive: I'm running > > ubench for the fourth time in a row now waiting for crash #3. > > Unfortunately it appears my case was a false alarm. > My Tyan K8W S2885 is not stable unless ECC is turned off in ROM setup. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 21:32:09 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 917EC16A50B for ; Sun, 22 Feb 2004 21:32:09 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86EF543D1F for ; Sun, 22 Feb 2004 21:32:09 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 1A7132A8EC for ; Sun, 22 Feb 2004 21:32:09 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 94CAD2C1AF for ; Sun, 22 Feb 2004 21:32:08 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1N5W8Q3036093; Sun, 22 Feb 2004 21:32:08 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1N5W83R036092; Sun, 22 Feb 2004 21:32:08 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 21:32:08 -0800 User-Agent: KMail/1.6 References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> In-Reply-To: <40391EC6.7010808@citlink.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402222132.08092.peter@wemm.org> cc: Joseph Fenton Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 05:32:09 -0000 On Sunday 22 February 2004 01:27 pm, Joseph Fenton wrote: > >>Adding CFLAGS= -fPIC to /etc/make.conf may be a local solution but > >>are there any drawbacks by adding something like > >>.if ${ARCH} == "amd64" > >>CFLAGS+= -fPIC > >>.endif > >> > >>to ports/Mk/bsd.port.mk? > > > >No.. please don't. Although the AMD64 platform supports PIC > > addressing modes directly, it is still a penalty. (Although > > thankfully, its nowhere near as expensive as it is on i386!) > > > >For example, in libc when built in PIC mode: > >#ifdef PIC > > movq PIC_GOT(HIDENAME(curbrk)),%rdx > > movq (%rdx),%rax > >#else > > movq HIDENAME(curbrk)(%rip),%rax > >#endif > > > >The problem is that we can't be sure that everything will be in +/- > > 31 bit offsets of each other. This means that PIC objects have to > > do indirect memory references that aren't required in no-pic mode. > > > >I386 also loses a general purpose register (%ebx) which is why -fpic > > is more expensive there. But even though we don't lose a register, > > its still a cost because of the extra global-offset-table memory > > references. > > > >Footnote: you just made me wonder about some of these ifdefs.. We > >shouldn't need them for intra-object references like this. I'll > > have to go and look again. > > Sorry to be anal, but PC-relative addressing is by definition > position-independent code. Who was the bright individual > who decided that when compiling PIC code to NOT use > PC-relative and to NOT use PC-relative for non-PIC code? Recall the last paragraph you just quoted. I already said I thought the code wasn't quite right. However, I just remembered why its done that way. Remember.. unix link semantics have interesting symbol override effects. Although you might normally be jumping within the same library and can trivially use %rip-relative addressing, if the main program overrides libc symbols, we must use those instead. Thus, we can't use %rip-relative ways to access them because we can't be sure its going to be within +/- 2GB. In fact, its guaranteed to not be the case for dynamic linking on FreeBSD/amd64 because the default load address for shared libs is around the 8GB mark. For static linking though, we don't usually have this same 7.9GB hole in our symbol space. Also.. when compiling with -fpic, you don't know whether you're linking pc-relative code into an application or into a shared library that could be loaded just about anywhere. > This is counter-intuitive. For PIC code, you use PC-relative > addressing in two cases: 1 - the code is guaranteed to be > a constant distance apart, like code in the same section; 2 - > when the loader guarantees the relative position of different > sections, like code and data contained in a ROM. > > Case 1 could be violated by the code being too far apart > for PC-relative addressing. This is virtually impossible for > the AMD64 as I doubt we'll see code exceeding 2G in > size in the next several decades. Code is only now exceeding > a few megabytes. Case 2 is usually your problem, which leads > to tables used to hold addresses or offsets. Case 1 is violated by symbol overrides by the main program. > Both sides of the #ifdef PIC are doing valid PIC code. > PC-relative addressing should be used wherever possible > unless it incurs a speed penalty. gcc generally generates %rip-relative offsets where possible even without -fpic. > Non-PIC code generally does PC-relative code if it > is faster and is legal, for example, when referring to > code within the same section. When the address must > be set by the loader for non-PIC code, it seems to me > that the fastest code would be like this: > > mov ,%rdx > movq (%rdx),%rax Guess what.. look at the original code: movq PIC_GOT(HIDENAME(curbrk)),%rdx movq (%rdx),%rax The first instruction just happens to be of the form 'mov ,%rdx. > or if the address is > 4G > > movq ,%rdx > movq (%rdx),%rax Except that there is only one movq instruction, and it only works with %rax as a target, and its not particularly fast. Since you're guaranteed to have an offset table within +/- 2GB, you may as well use it. > The loader would then set the immediate vector upon > loading the sections. This avoids a memory hit for accessing > a table of addresses while only adding at most 5 bytes to the > size of the code. I would probably use this unless the user > is compiling with flags set to compile with minimized code > size. Also remember that this is in libc, where its not a user code size compile option. We have to cope with whatever environment we find outselves loaded into. We have to assume the worst case scenario. Incidently, for an example of what GCC does... given this program: extern int j; extern int foo(int i); int bar(int i) { return foo(i) + 10 + j; } cc -S -O produces: bar: subq $8, %rsp call foo addl j(%rip), %eax addl $10, %eax addq $8, %rsp ret cc -S -O -fPIC produces: bar: subq $8, %rsp call foo@PLT movq j@GOTPCREL(%rip), %rdx addl (%rdx), %eax addl $10, %eax addq $8, %rsp ret Note how the -fpic case is less efficient. Specifically, function calls are trampolined via the local object's procedure linkage table rather than just calling them directly.. because we dont know if they're within +/- 2GB or not. Or if they're even in the same object. Secondly, it uses the global offset table to find the address of 'j' and then indirectly references it as a two-step sequence. The non-pic case just makes a pc-relative reference in a single instruction. > Sorry to nit-pick like this, but having worked on both Mac > and Amiga ROMs, PIC mode under BSD really seems > backwards to me. Unix library semantics are very very different to ROM semantics. I've been there too. Also, this isn't BSD-specific. It's ELF specific and thats what the toolchain produces and expects. We use the same toolchain that linux does. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 21:35:27 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 941A816A4CE for ; Sun, 22 Feb 2004 21:35:27 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B42843D1F for ; Sun, 22 Feb 2004 21:35:27 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 541E72A8EB for ; Sun, 22 Feb 2004 21:35:27 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id CA69C2C1AC for ; Sun, 22 Feb 2004 21:35:26 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1N5ZRpd036142; Sun, 22 Feb 2004 21:35:27 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1N5ZRHl036141; Sun, 22 Feb 2004 21:35:27 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 21:35:26 -0800 User-Agent: KMail/1.6 References: <200402220033.01795.peter@wemm.org> <20040222185208.GA53610@dhcp01.pn.xcllnt.net> In-Reply-To: <20040222185208.GA53610@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402222135.26975.peter@wemm.org> Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 05:35:27 -0000 On Sunday 22 February 2004 10:52 am, Marcel Moolenaar wrote: > On Sun, Feb 22, 2004 at 12:33:01AM -0800, Peter Wemm wrote: > > On Saturday 21 February 2004 07:43 pm, Hendrik Scholz wrote: > > > On Feb 21, 2004, at 9:59 PM, Christian Weisgerber wrote: > > > > Why are these shared objects not built with -fPIC in the first > > > > place? > > > > > > Ask the authors of the third party applications :) > > > Most architectures don't need -fPIC and/or it slows them down > > > (thanks for the > > > comment Peter!). > > > > Yes, exactly. Some folks thought it would be an idea to add a flag > > to libtool to force it to link non-pic code into shared libraries. > > Essentially this reduces the sharability since we do relocations on > > the text segment, but the flipside is that its faster on i386 and > > on some libraries they figured it was worth burning extra memory > > that would be wasted by not using -fPIC. > > Not to mention that people generally attach -fPIC to the kind of > library they are making and thus do not build with -fPIC if they > create an archive library (the BSD make infrastructure has this > too). This most of the time works, but not when the archive library > is subsequently linked *into* a shared library later on. So, the > use of -fPIC is determined by how the object files are eventually > used to make up a process and that's not always known to the person > writing the libraries, let alone some (in)convenience tools like > libtool or automake/autoconf. Since you mentioned the BSD make infrastructure.. thats what we produce the _pic.a files for. eg: libc_pic.a, libgcc_pic.a etc. We even have a Makefile knob for it.. INSTALL_PIC_ARCHIVE.. if I remember the name correctly. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 21:38:11 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FF5516A4CE; Sun, 22 Feb 2004 21:38:11 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F2C43D1F; Sun, 22 Feb 2004 21:38:11 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 5B7762A8EC; Sun, 22 Feb 2004 21:38:11 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 14BDB2C1AC; Sun, 22 Feb 2004 21:38:11 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1N5cBMZ036164; Sun, 22 Feb 2004 21:38:11 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1N5cBL5036163; Sun, 22 Feb 2004 21:38:11 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 21:38:11 -0800 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402222138.11188.peter@wemm.org> cc: freebsd-questions@freebsd.org Subject: Re: Kernel Compilation issues/5.2-CURRENT/AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 05:38:11 -0000 On Sunday 22 February 2004 08:29 pm, Jason Lixfeld wrote: > make buildkernel keeps failing here: > > ===> accf_data > cc -O -fPIC -D_KERNEL -DKLD_MODULE -nostdinc -I- -include Stop right here! You've removed the 'makeoptions NO_MODULES=notyet' from your config file. Put it right back in there immediately. We don't support kld modules yet. Your buildkernel is failing because you're trying to do something that isn't possible with our toolchain. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 21:47:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3948F16A4CE for ; Sun, 22 Feb 2004 21:47:14 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 306CD43D1F for ; Sun, 22 Feb 2004 21:47:14 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id D521B2A8F0 for ; Sun, 22 Feb 2004 21:47:13 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 648B82C1AC for ; Sun, 22 Feb 2004 21:47:13 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1N5lD6u036258; Sun, 22 Feb 2004 21:47:13 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1N5lDEM036257; Sun, 22 Feb 2004 21:47:13 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 22 Feb 2004 21:47:13 -0800 User-Agent: KMail/1.6 References: <200402230501.i1N51NB0049544@bigtex.jrv.org> In-Reply-To: <200402230501.i1N51NB0049544@bigtex.jrv.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402222147.13520.peter@wemm.org> Subject: Re: Opteron ECC X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 05:47:14 -0000 On Sunday 22 February 2004 09:01 pm, James Van Artsdalen wrote: > Several weeks ago I reported an instability in my system WRT ECC. > > It turns out that AMD has published its Opteron errata sheet and > errate item 101 appears to be the issue: a bug in the Opteron means > you can't have both "node interleave" and ECC scrubbing on at the > same time. > > I've turned off node interleave. I have no idea what are reasonable > values for ECC scrubbing in ROM setup but it seems more useful to > leave scrubbing on than to enable node interleave, even without a > NUMA-aware kernel. > > (this only applies to multiprocessor systems) Oh my, thats bit of a stinker. Do you recall which steppings this applies to? BTW; I suspect you might find that node interleave is more useful (speed wise) than ecc background scrubbing. But I guess that depends on what you want.. If you're trying to wring every bit of performance out of it, pick node interleave over scrubbing. On the other hand, if you'd perfer to have the system constantly checking that the ECC ram is ok and you're not so worried about speed, then pick scrubbing. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 21:53:22 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A3F816A4CE; Sun, 22 Feb 2004 21:53:22 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1122343D1D; Sun, 22 Feb 2004 21:53:22 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id 2DA843C8013; Mon, 23 Feb 2004 00:55:35 -0500 (EST) In-Reply-To: <200402222138.11188.peter@wemm.org> References: <200402222138.11188.peter@wemm.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9401F882-65C4-11D8-AC84-000A95989E4A@lixfeld.ca> Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Mon, 23 Feb 2004 00:53:17 -0500 To: Peter Wemm X-Mailer: Apple Mail (2.613) cc: freebsd-questions@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: Kernel Compilation issues/5.2-CURRENT/AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 05:53:22 -0000 On Feb 23, 2004, at 12:38 AM, Peter Wemm wrote: > On Sunday 22 February 2004 08:29 pm, Jason Lixfeld wrote: >> make buildkernel keeps failing here: >> >> ===> accf_data >> cc -O -fPIC -D_KERNEL -DKLD_MODULE -nostdinc -I- -include > > Stop right here! You've removed the 'makeoptions NO_MODULES=notyet' > from your config file. Put it right back in there immediately. *gulp* when I built my custom kernel, I looked in /usr/src/sys/conf/NOTES and /usr/src/sys/amd64/conf/NOTES and found nothing pertaining to the use of this makeoption. I checked google, forums, lists, etc and found nothing specific on the use of this so I removed it. Perhaps add a comment saying that you will have weird stuff happen if this is not here will help deter people from overzealously removing it, as I did. Thanks! I'll give it a shot and see what happens. > We don't support kld modules yet. Your buildkernel is failing because > you're trying to do something that isn't possible with our toolchain. > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 22:18:26 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76ACB16A4CE for ; Sun, 22 Feb 2004 22:18:26 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0382743D1F for ; Sun, 22 Feb 2004 22:18:26 -0800 (PST) (envelope-from jlfenton@citlink.net) Received: (qmail 19216 invoked from network); 23 Feb 2004 06:18:25 -0000 Received: from unknown (HELO citlink.net) ([67.136.108.212]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 23 Feb 2004 06:18:25 -0000 Message-ID: <40399B30.3080804@citlink.net> Date: Sun, 22 Feb 2004 23:18:24 -0700 From: Joseph Fenton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <20040222185212.EB6BE16A4D1@hub.freebsd.org> <40391EC6.7010808@citlink.net> <200402222132.08092.peter@wemm.org> In-Reply-To: <200402222132.08092.peter@wemm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org Subject: Re: CFLAGS+= -fPIC per default? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 06:18:26 -0000 Peter Wemm wrote: >On Sunday 22 February 2004 01:27 pm, Joseph Fenton wrote: > > >>>>Adding CFLAGS= -fPIC to /etc/make.conf may be a local solution but >>>>are there any drawbacks by adding something like >>>>.if ${ARCH} == "amd64" >>>>CFLAGS+= -fPIC >>>>.endif >>>> >>>>to ports/Mk/bsd.port.mk? >>>> >>>> >>>No.. please don't. Although the AMD64 platform supports PIC >>>addressing modes directly, it is still a penalty. (Although >>>thankfully, its nowhere near as expensive as it is on i386!) >>> >>>For example, in libc when built in PIC mode: >>>#ifdef PIC >>> movq PIC_GOT(HIDENAME(curbrk)),%rdx >>> movq (%rdx),%rax >>>#else >>> movq HIDENAME(curbrk)(%rip),%rax >>>#endif >>> >>>The problem is that we can't be sure that everything will be in +/- >>>31 bit offsets of each other. This means that PIC objects have to >>>do indirect memory references that aren't required in no-pic mode. >>> >>>I386 also loses a general purpose register (%ebx) which is why -fpic >>>is more expensive there. But even though we don't lose a register, >>>its still a cost because of the extra global-offset-table memory >>>references. >>> >>>Footnote: you just made me wonder about some of these ifdefs.. We >>>shouldn't need them for intra-object references like this. I'll >>>have to go and look again. >>> >>> >>Sorry to be anal, but PC-relative addressing is by definition >>position-independent code. Who was the bright individual >>who decided that when compiling PIC code to NOT use >>PC-relative and to NOT use PC-relative for non-PIC code? >> >> > >Recall the last paragraph you just quoted. I already said I thought the >code wasn't quite right. However, I just remembered why its done that >way. > >Remember.. unix link semantics have interesting symbol override effects. >Although you might normally be jumping within the same library and can >trivially use %rip-relative addressing, if the main program overrides >libc symbols, we must use those instead. Thus, we can't use >%rip-relative ways to access them because we can't be sure its going to >be within +/- 2GB. In fact, its guaranteed to not be the case for >dynamic linking on FreeBSD/amd64 because the default load address for >shared libs is around the 8GB mark. For static linking though, we >don't usually have this same 7.9GB hole in our symbol space. > >Also.. when compiling with -fpic, you don't know whether you're linking >pc-relative code into an application or into a shared library that >could be loaded just about anywhere. > > > >>This is counter-intuitive. For PIC code, you use PC-relative >>addressing in two cases: 1 - the code is guaranteed to be >>a constant distance apart, like code in the same section; 2 - >>when the loader guarantees the relative position of different >>sections, like code and data contained in a ROM. >> >>Case 1 could be violated by the code being too far apart >>for PC-relative addressing. This is virtually impossible for >>the AMD64 as I doubt we'll see code exceeding 2G in >>size in the next several decades. Code is only now exceeding >>a few megabytes. Case 2 is usually your problem, which leads >>to tables used to hold addresses or offsets. >> >> > >Case 1 is violated by symbol overrides by the main program. > > > >>Both sides of the #ifdef PIC are doing valid PIC code. >>PC-relative addressing should be used wherever possible >>unless it incurs a speed penalty. >> >> > >gcc generally generates %rip-relative offsets where possible even >without -fpic. > > > >>Non-PIC code generally does PC-relative code if it >>is faster and is legal, for example, when referring to >>code within the same section. When the address must >>be set by the loader for non-PIC code, it seems to me >>that the fastest code would be like this: >> >> mov ,%rdx >> movq (%rdx),%rax >> >> > >Guess what.. look at the original code: > movq PIC_GOT(HIDENAME(curbrk)),%rdx > movq (%rdx),%rax >The first instruction just happens to be of the form 'mov ,%rdx. > > > >>or if the address is > 4G >> >> movq ,%rdx >> movq (%rdx),%rax >> >> > >Except that there is only one movq instruction, and it only >works with %rax as a target, and its not particularly fast. Since >you're guaranteed to have an offset table within +/- 2GB, you may as >well use it. > > > >>The loader would then set the immediate vector upon >>loading the sections. This avoids a memory hit for accessing >>a table of addresses while only adding at most 5 bytes to the >>size of the code. I would probably use this unless the user >>is compiling with flags set to compile with minimized code >>size. >> >> > >Also remember that this is in libc, where its not a user code size >compile option. We have to cope with whatever environment we find >outselves loaded into. We have to assume the worst case scenario. > >Incidently, for an example of what GCC does... given this program: >extern int j; >extern int foo(int i); >int >bar(int i) >{ > return foo(i) + 10 + j; >} >cc -S -O produces: >bar: > subq $8, %rsp > call foo > addl j(%rip), %eax > addl $10, %eax > addq $8, %rsp > ret > >cc -S -O -fPIC produces: >bar: > subq $8, %rsp > call foo@PLT > movq j@GOTPCREL(%rip), %rdx > addl (%rdx), %eax > addl $10, %eax > addq $8, %rsp > ret > >Note how the -fpic case is less efficient. Specifically, function calls >are trampolined via the local object's procedure linkage table rather >than just calling them directly.. because we dont know if they're >within +/- 2GB or not. Or if they're even in the same object. >Secondly, it uses the global offset table to find the address of 'j' and >then indirectly references it as a two-step sequence. The non-pic case >just makes a pc-relative reference in a single instruction. > > > >>Sorry to nit-pick like this, but having worked on both Mac >>and Amiga ROMs, PIC mode under BSD really seems >>backwards to me. >> >> > >Unix library semantics are very very different to ROM semantics. I've >been there too. > >Also, this isn't BSD-specific. It's ELF specific and thats what the >toolchain produces and expects. We use the same toolchain that linux >does. > > Okay, that made a lot more sense than the original post. Sorry about the whole thing. It is rather different, but the above clears a lot of the confusion. Thanks a bunch! Your example function in the two cases put it in terms I have dealt with on PowerMacs, so that was a good demonstration. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 22:33:01 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B47FF16A4CE for ; Sun, 22 Feb 2004 22:33:01 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F14F43D1F for ; Sun, 22 Feb 2004 22:33:01 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1N6X0o8069244 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Feb 2004 00:33:00 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1N6X0DB069241; Mon, 23 Feb 2004 00:33:00 -0600 (CST) Date: Mon, 23 Feb 2004 00:33:00 -0600 (CST) Message-Id: <200402230633.i1N6X0DB069241@bigtex.jrv.org> From: James Van Artsdalen To: peter@wemm.org In-reply-to: <200402222147.13520.peter@wemm.org> (message from Peter Wemm on Sun, 22 Feb 2004 21:47:13 -0800) References: <200402230501.i1N51NB0049544@bigtex.jrv.org> <200402222147.13520.peter@wemm.org> cc: freebsd-amd64@freebsd.org Subject: Re: Opteron ECC X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 06:33:01 -0000 > From: Peter Wemm > Date: Sun, 22 Feb 2004 21:47:13 -0800 > > On Sunday 22 February 2004 09:01 pm, James Van Artsdalen wrote: > > It turns out that AMD has published its Opteron errata sheet and > > errata item 101 appears to be the issue: a bug in the Opteron means > > you can't have both "node interleave" and ECC scrubbing on at the > > same time. > > Oh my, thats bit of a stinker. Do you recall which steppings this > applies to? > > BTW; I suspect you might find that node interleave is more useful (speed > wise) than ecc background scrubbing. But I guess that depends on what > you want.. If you're trying to wring every bit of performance out of > it, pick node interleave over scrubbing. On the other hand, if you'd > perfer to have the system constantly checking that the ECC ram is ok > and you're not so worried about speed, then pick scrubbing. The errata list is here: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf Bug 101 affects both B3 and C0 steppings. A word for people reading processor errata for the first time: here's a comment I made on another list: This errata list may look gruesome to those not used to such things, but it's not bad at all. I dealt with processor errata lists from Intel for years as a PC designer - the double-secret-NDA lists - and this is par for the course, perhaps even cleaner than usual. It might not hurt to add a line of code to the kernel to check for these steppings, node interleave and scrubbing, and print a warning if all three are met. There is little difference between a stored 1 and 0 in a modern DRAM. I'm not sure what the rate of error accumulation is. If you have high density DRAM and might not touch some for periods of time, scrubbing might prevent two errors from accumulating in one line. From owner-freebsd-amd64@FreeBSD.ORG Sun Feb 22 22:51:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D59616A4CE for ; Sun, 22 Feb 2004 22:51:03 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3493D43D2D for ; Sun, 22 Feb 2004 22:51:03 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 0D9FC2A8E7 for ; Sun, 22 Feb 2004 22:51:03 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 78D7B2C1AC for ; Sun, 22 Feb 2004 22:51:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1N6p24m037029; Sun, 22 Feb 2004 22:51:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1N6p2GD037028; Sun, 22 Feb 2004 22:51:02 -0800 (PST) (envelope-from peter) From: Peter Wemm To: James Van Artsdalen Date: Sun, 22 Feb 2004 22:51:02 -0800 User-Agent: KMail/1.6 References: <200402230501.i1N51NB0049544@bigtex.jrv.org> <200402222147.13520.peter@wemm.org> <200402230633.i1N6X0DB069241@bigtex.jrv.org> In-Reply-To: <200402230633.i1N6X0DB069241@bigtex.jrv.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402222251.02612.peter@wemm.org> cc: freebsd-amd64@freebsd.org Subject: Re: Opteron ECC X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 06:51:03 -0000 On Sunday 22 February 2004 10:33 pm, James Van Artsdalen wrote: > > From: Peter Wemm > > Date: Sun, 22 Feb 2004 21:47:13 -0800 > > > > On Sunday 22 February 2004 09:01 pm, James Van Artsdalen wrote: > > > It turns out that AMD has published its Opteron errata sheet and > > > errata item 101 appears to be the issue: a bug in the Opteron > > > means you can't have both "node interleave" and ECC scrubbing on > > > at the same time. > > > > Oh my, thats bit of a stinker. Do you recall which steppings this > > applies to? > > > > BTW; I suspect you might find that node interleave is more useful > > (speed wise) than ecc background scrubbing. But I guess that > > depends on what you want.. If you're trying to wring every bit of > > performance out of it, pick node interleave over scrubbing. On the > > other hand, if you'd perfer to have the system constantly checking > > that the ECC ram is ok and you're not so worried about speed, then > > pick scrubbing. > > The errata list is here: > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_do >cs/25759.pdf > > Bug 101 affects both B3 and C0 steppings. > > A word for people reading processor errata for the first time: here's > a comment I made on another list: > > This errata list may look gruesome to those not used to such > things, but it's not bad at all. I dealt with processor errata > lists from Intel for years as a PC designer - the > double-secret-NDA lists - and this is par for the course, perhaps > even cleaner than usual. Yes. I've read the public ("these are the ones we admit to") lists from intel and those were scary enough. > It might not hurt to add a line of code to the kernel to check for > these steppings, node interleave and scrubbing, and print a warning > if all three are met. Yes. I think a warning is in order, at the very least. Checking for errata and steppings has been on my todo list for a while. At least this time I've got around to printing the errata list. :-) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 23 01:23:24 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F67216A4CF for ; Mon, 23 Feb 2004 01:23:24 -0800 (PST) Received: from Reineke.Malepartus.DE (reineke.malepartus.de [194.25.4.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FB5143D2F for ; Mon, 23 Feb 2004 01:23:22 -0800 (PST) (envelope-from bm@Reineke.Malepartus.DE) Received: from Reineke.Malepartus.DE (localhost [127.0.0.1]) i1N9NHlD032271; Mon, 23 Feb 2004 10:23:17 +0100 (CET) (envelope-from bm@Reineke.Malepartus.DE) Received: (from bm@localhost) by Reineke.Malepartus.DE (8.12.10/8.12.10/Submit) id i1N9NHr0032270; Mon, 23 Feb 2004 10:23:17 +0100 (CET) (envelope-from bm) Date: Mon, 23 Feb 2004 10:23:17 +0100 From: Burkard Meyendriesch To: James Van Artsdalen Message-Id: <20040223102317.035824fd.bm@malepartus.de> In-Reply-To: <200402230448.i1N4mfHK048939@bigtex.jrv.org> References: <20040222095700.2c58b1e7.bm@malepartus.de> <200402230448.i1N4mfHK048939@bigtex.jrv.org> Organization: The Home of Reineke Fuchs X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i386-portbld-freebsd4.9) X-Face: "[-; ]oI+8gP9>*J%knDN8d%DuhvJS2Lj4L\bRb7gz(pcT?2Zh6_Vam_6csAum3$<&lhAFd^ jt|!&Ut1C~Vg*E/q}+#cbFg-GU]c.bB8Ad,L'W$'9{^0y'AzM4#hS[C[F-1'|O; Kg3Vrq5q6dsU*TmJ@}+QPM\ b[^9Rhd,UoMpRpd5k[X=h.Dom*kbT`cNQ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Malepartus-MailScanner-Information: Please contact the ISP for more information X-Malepartus-MailScanner: Found to be clean cc: freebsd-amd64@freebsd.org Subject: Re: CURRENT: error in "make buildworld" on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 09:23:24 -0000 Hi James, okay, you're right: I'd better use RELENG_5_2. But after CVSup'ing my src tree to "tag=RELENG_5_2" the problem with "make buildworld" is still the same: fcns.h:93:1: warning: "WI_" redefined fcns.h:92:1: warning: this is the location of the previous definition In file included from editline.c:4: /usr/src/lib/libedit/chared.c: In function `ch_init': /usr/src/lib/libedit/chared.c:456: error: `ED_UNASSIGNED' undeclared (first use in this function) /usr/src/lib/libedit/chared.c:456: error: (Each undeclared identifier is reported only once /usr/src/lib/libedit/chared.c:456: error: for each function it appears in.) /usr/src/lib/libedit/chared.c: In function `ch_reset': /usr/src/lib/libedit/chared.c:493: error: `ED_UNASSIGNED' undeclared (first use in this function) In file included from editline.c:5: /usr/src/lib/libedit/common.c: In function `ed_digit': /usr/src/lib/libedit/common.c:407: error: `EM_UNIVERSAL_ARGUMENT' undeclared (first use in this function) ... (lots of similar error messages . . .) Maybe I need some tuning of /etc/make.conf? Burkard On Sun, 22 Feb 2004 22:48:41 -0600 (CST) James Van Artsdalen wrote: > > Date: Sun, 22 Feb 2004 09:57:00 +0100 > > From: Burkard Meyendriesch > > > > yesterday I launched my new box (Asus K8V Deluxe, Athlon64/3000, 1GB > > ECC RAM, 2x160GB RAID1). I installed 5.2-RELEASE from CD. After that > > I checked out the actual source tree and tried to "make buildworld". > > This ends up with: > > > > In file included from editline.c:4: > > /usr/src/lib/libedit/chared.c: In function `ch_init': > > /usr/src/lib/libedit/chared.c:456: error: `ED_UNASSIGNED' > > undeclared (first use in this > > function)/usr/src/lib/libedit/chared.c:456: error: (Each > > undeclared identifier is reported only > > once/usr/src/lib/libedit/chared.c:456: error: for each function it > > appears in.)/usr/src/lib/libedit/chared.c: In function `ch_reset': > > /usr/src/lib/libedit/chared.c:493: error: `ED_UNASSIGNED' > > undeclared (first use in this function)... (lots of similar error > > messages follow...) > > > > What's going wrong? > > Burkard > > > > P.S.: I have no item enabled in /etc/make.conf. > > Do you really want to sync against -current? Most people should > probably sync against the RELENG_5_2 tag. > > /etc/make.conf shouldn't be changed. -- Burkard Meyendriesch Stevern 2 D-48301 Nottuln From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 23 03:21:57 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F3D16A4CE; Mon, 23 Feb 2004 03:21:57 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C43743D2D; Mon, 23 Feb 2004 03:21:57 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D5EFA7303A; Mon, 23 Feb 2004 06:21:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040223112155.D5EFA7303A@freebsd-current.sentex.ca> Date: Mon, 23 Feb 2004 06:21:55 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 11:21:57 -0000 TB --- 2004-02-23 10:22:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-23 10:22:33 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-23 10:22:33 - checking out the source tree TB --- 2004-02-23 10:22:33 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-23 10:22:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-23 10:27:31 - building world TB --- 2004-02-23 10:27:31 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-23 10:27:31 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-23 11:15:40 - building generic kernel TB --- 2004-02-23 11:15:40 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-23 11:15:40 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Feb 23 11:15:40 GMT 2004 >>> Kernel build for GENERIC completed on Mon Feb 23 11:21:55 GMT 2004 TB --- 2004-02-23 11:21:55 - generating LINT kernel config TB --- 2004-02-23 11:21:55 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-23 11:21:55 - /usr/bin/make -B LINT TB --- 2004-02-23 11:21:55 - building LINT kernel TB --- 2004-02-23 11:21:55 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-23 11:21:55 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 23 11:21:55 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-23 11:21:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-23 11:21:55 - ERROR: failed to build lint kernel TB --- 2004-02-23 11:21:55 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 23 09:24:45 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67C1D16A4CE for ; Mon, 23 Feb 2004 09:24:45 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6305843D1D for ; Mon, 23 Feb 2004 09:24:45 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 9DE862A8F3 for ; Mon, 23 Feb 2004 09:24:44 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 492D02C1AC for ; Mon, 23 Feb 2004 09:24:44 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1NHOgs9000923; Mon, 23 Feb 2004 09:24:42 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1NHOgiO000922; Mon, 23 Feb 2004 09:24:42 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Mon, 23 Feb 2004 09:24:41 -0800 User-Agent: KMail/1.6 References: <200402230501.i1N51NB0049544@bigtex.jrv.org> <200402230633.i1N6X0DB069241@bigtex.jrv.org> <200402222251.02612.peter@wemm.org> In-Reply-To: <200402222251.02612.peter@wemm.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402230924.42159.peter@wemm.org> cc: James Van Artsdalen Subject: Re: Opteron ECC X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 17:24:45 -0000 On Sunday 22 February 2004 10:51 pm, Peter Wemm wrote: > On Sunday 22 February 2004 10:33 pm, James Van Artsdalen wrote: > > > From: Peter Wemm > > > Date: Sun, 22 Feb 2004 21:47:13 -0800 > > > > > > On Sunday 22 February 2004 09:01 pm, James Van Artsdalen wrote: > > > > It turns out that AMD has published its Opteron errata sheet > > > > and errata item 101 appears to be the issue: a bug in the > > > > Opteron means you can't have both "node interleave" and ECC > > > > scrubbing on at the same time. > > > > > > Oh my, thats bit of a stinker. Do you recall which steppings > > > this applies to? > > > > > > BTW; I suspect you might find that node interleave is more useful > > > (speed wise) than ecc background scrubbing. But I guess that > > > depends on what you want.. If you're trying to wring every bit > > > of performance out of it, pick node interleave over scrubbing. > > > On the other hand, if you'd perfer to have the system constantly > > > checking that the ECC ram is ok and you're not so worried about > > > speed, then pick scrubbing. > > > > The errata list is here: > > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_ > >do cs/25759.pdf > > > > Bug 101 affects both B3 and C0 steppings. > > > > A word for people reading processor errata for the first time: > > here's a comment I made on another list: > > > > This errata list may look gruesome to those not used to such > > things, but it's not bad at all. I dealt with processor errata > > lists from Intel for years as a PC designer - the > > double-secret-NDA lists - and this is par for the course, perhaps > > even cleaner than usual. > > Yes. I've read the public ("these are the ones we admit to") lists > from intel and those were scary enough. > > > It might not hurt to add a line of code to the kernel to check for > > these steppings, node interleave and scrubbing, and print a warning > > if all three are met. > > Yes. I think a warning is in order, at the very least. Checking for > errata and steppings has been on my todo list for a while. At least > this time I've got around to printing the errata list. :-) I read the full errata list last night. There are a couple that we definately need to add workarounds for. Especially the ones that can cause a 32 bit compatability app to branch outside of its 32 bit address space. :-) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 23 11:01:41 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6872F16A502 for ; Mon, 23 Feb 2004 11:01:41 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63AB143D1F for ; Mon, 23 Feb 2004 11:01:41 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i1NJ1fbv035203 for ; Mon, 23 Feb 2004 11:01:41 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i1NJ1e6w035197 for freebsd-amd64@freebsd.org; Mon, 23 Feb 2004 11:01:40 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 Feb 2004 11:01:40 -0800 (PST) Message-Id: <200402231901.i1NJ1e6w035197@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 19:01:41 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59713 amd64 Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F365E16A4CE; Mon, 23 Feb 2004 15:17:23 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6EF243D1D; Mon, 23 Feb 2004 15:17:23 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 25E9D7303A; Mon, 23 Feb 2004 18:17:23 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040223231723.25E9D7303A@freebsd-current.sentex.ca> Date: Mon, 23 Feb 2004 18:17:23 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 23:17:24 -0000 TB --- 2004-02-23 22:21:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-23 22:21:06 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-23 22:21:06 - checking out the source tree TB --- 2004-02-23 22:21:06 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-23 22:21:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-23 22:24:48 - building world TB --- 2004-02-23 22:24:48 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-23 22:24:48 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-23 23:11:13 - building generic kernel TB --- 2004-02-23 23:11:13 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-23 23:11:13 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Feb 23 23:11:13 GMT 2004 >>> Kernel build for GENERIC completed on Mon Feb 23 23:17:21 GMT 2004 TB --- 2004-02-23 23:17:21 - generating LINT kernel config TB --- 2004-02-23 23:17:21 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-23 23:17:21 - /usr/bin/make -B LINT TB --- 2004-02-23 23:17:21 - building LINT kernel TB --- 2004-02-23 23:17:21 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-23 23:17:21 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 23 23:17:21 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-23 23:17:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-23 23:17:22 - ERROR: failed to build lint kernel TB --- 2004-02-23 23:17:22 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 02:32:52 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E34B716A4CE for ; Tue, 24 Feb 2004 02:32:52 -0800 (PST) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF8FB43D1D for ; Tue, 24 Feb 2004 02:32:52 -0800 (PST) (envelope-from Peter_Losher@isc.org) Received: from dhcp-2.sql1.plosh.net (tardis-nat.plosh.net [64.139.14.228]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 30F6EA82B for ; Tue, 24 Feb 2004 10:32:52 +0000 (UTC) (envelope-from Peter_Losher@isc.org) From: Peter Losher Organization: ISC To: amd64@freebsd.org Date: Tue, 24 Feb 2004 02:32:50 -0800 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <200402240232.50397.Peter_Losher@isc.org> Subject: Errors in 'make buildworld' (02.24.2004) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 10:32:53 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to update my amd64 system from 5.2-REL to 5.2.1-RC2 and I=20 keep coming across this error below in 'make buildworld'. Any idea what=20 may be causing it? Best Wishes - Peter =2D -=3D-=20 =3D=3D=3D> gnu/usr.bin/binutils/libbfd cc -O -pipe -D_GNU_SOURCE -I.=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/inc= lude=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd= =20 =2D -DBFD_VERSION=3D\"20021127\" -DBFD_VERSION_DATE=3D20021127=20 =2D -DBFD_VERSION_STRING=3D\""2.13.2 [FreeBSD] 2002-11-27"\"=20 =2D -DSELECT_ARCHITECTURES=3D"&bfd_i386_arch" -DHAVE_bfd_elf64_x86_64_vec=20 =2D -DHAVE_bfd_elf32_i386_freebsd_vec -DSELECT_VECS=3D"=20 &bfd_elf64_x86_64_vec ,&bfd_elf32_i386_freebsd_vec" =20 =2D -I/usr/obj/usr/src/amd64/legacy/usr/include=20 =2D -c /usr/src/contrib/binutils/bfd/cpu-i386.c cc -O -pipe -D_GNU_SOURCE -I.=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/inc= lude=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd= =20 =2D -DBFD_VERSION=3D\"20021127\" -DBFD_VERSION_DATE=3D20021127=20 =2D -DBFD_VERSION_STRING=3D\""2.13.2 [FreeBSD] 2002-11-27"\"=20 =2D -DSELECT_ARCHITECTURES=3D"&bfd_i386_arch" -DHAVE_bfd_elf64_x86_64_vec=20 =2D -DHAVE_bfd_elf32_i386_freebsd_vec -DSELECT_VECS=3D"=20 &bfd_elf64_x86_64_vec ,&bfd_elf32_i386_freebsd_vec" =20 =2D -I/usr/obj/usr/src/amd64/legacy/usr/include=20 =2D -c /usr/src/contrib/binutils/bfd/elf32-i386-fbsd.c cc -O -pipe -D_GNU_SOURCE -I.=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/inc= lude=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd= =20 =2D -DBFD_VERSION=3D\"20021127\" -DBFD_VERSION_DATE=3D20021127=20 =2D -DBFD_VERSION_STRING=3D\""2.13.2 [FreeBSD] 2002-11-27"\"=20 =2D -DSELECT_ARCHITECTURES=3D"&bfd_i386_arch" -DHAVE_bfd_elf64_x86_64_vec=20 =2D -DHAVE_bfd_elf32_i386_freebsd_vec -DSELECT_VECS=3D"=20 &bfd_elf64_x86_64_vec ,&bfd_elf32_i386_freebsd_vec" =20 =2D -I/usr/obj/usr/src/amd64/legacy/usr/include=20 =2D -c /usr/src/contrib/binutils/bfd/elf32-i386.c cc -O -pipe -D_GNU_SOURCE -I.=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/inc= lude=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd= =20 =2D -DBFD_VERSION=3D\"20021127\" -DBFD_VERSION_DATE=3D20021127=20 =2D -DBFD_VERSION_STRING=3D\""2.13.2 [FreeBSD] 2002-11-27"\"=20 =2D -DSELECT_ARCHITECTURES=3D"&bfd_i386_arch" -DHAVE_bfd_elf64_x86_64_vec=20 =2D -DHAVE_bfd_elf32_i386_freebsd_vec -DSELECT_VECS=3D"=20 &bfd_elf64_x86_64_vec ,&bfd_elf32_i386_freebsd_vec" =20 =2D -I/usr/obj/usr/src/amd64/legacy/usr/include=20 =2D -c /usr/src/contrib/binutils/bfd/elf32.c cc -O -pipe -D_GNU_SOURCE -I.=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/inc= lude=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd= =20 =2D -DBFD_VERSION=3D\"20021127\" -DBFD_VERSION_DATE=3D20021127=20 =2D -DBFD_VERSION_STRING=3D\""2.13.2 [FreeBSD] 2002-11-27"\"=20 =2D -DSELECT_ARCHITECTURES=3D"&bfd_i386_arch" -DHAVE_bfd_elf64_x86_64_vec=20 =2D -DHAVE_bfd_elf32_i386_freebsd_vec -DSELECT_VECS=3D"=20 &bfd_elf64_x86_64_vec ,&bfd_elf32_i386_freebsd_vec" =20 =2D -I/usr/obj/usr/src/amd64/legacy/usr/include=20 =2D -c /usr/src/contrib/binutils/bfd/elflink.c cc -O -pipe -D_GNU_SOURCE -I.=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/amd64=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/inc= lude=20 =2D -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd= =20 =2D -DBFD_VERSION=3D\"20021127\" -DBFD_VERSION_DATE=3D20021127=20 =2D -DBFD_VERSION_STRING=3D\""2.13.2 [FreeBSD] 2002-11-27"\"=20 =2D -DSELECT_ARCHITECTURES=3D"&bfd_i386_arch" -DHAVE_bfd_elf64_x86_64_vec=20 =2D -DHAVE_bfd_elf32_i386_freebsd_vec -DSELECT_VECS=3D"=20 &bfd_elf64_x86_64_vec ,&bfd_elf32_i386_freebsd_vec" =20 =2D -I/usr/obj/usr/src/amd64/legacy/usr/include -c elf64-amd64-fbsd.c elf64-amd64-fbsd.c:550: error: syntax error before '/' token *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. o1#=20 =2D -=3D- =2D --=20 Peter_Losher@isc.org | ISC | OpenPGP Key E8048D08 | "The bits must flow" =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAOyhSPtVx9OgEjQgRAox2AKDOl5tUBDhzjf6zFjc7/k5ifBNbXQCggcWf NuTJrzMHt5UgTTB4iZQVUnY=3D =3Du66x =2D----END PGP SIGNATURE----- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 03:17:47 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A4EC16A4CF; Tue, 24 Feb 2004 03:17:47 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1733B43D2F; Tue, 24 Feb 2004 03:17:47 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3B4D87303A; Tue, 24 Feb 2004 06:17:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040224111746.3B4D87303A@freebsd-current.sentex.ca> Date: Tue, 24 Feb 2004 06:17:46 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 11:17:47 -0000 TB --- 2004-02-24 10:21:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-24 10:21:19 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-24 10:21:19 - checking out the source tree TB --- 2004-02-24 10:21:19 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-24 10:21:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-24 10:25:00 - building world TB --- 2004-02-24 10:25:00 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-24 10:25:00 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-24 11:11:31 - building generic kernel TB --- 2004-02-24 11:11:31 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-24 11:11:31 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Feb 24 11:11:32 GMT 2004 >>> Kernel build for GENERIC completed on Tue Feb 24 11:17:45 GMT 2004 TB --- 2004-02-24 11:17:45 - generating LINT kernel config TB --- 2004-02-24 11:17:45 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-24 11:17:45 - /usr/bin/make -B LINT TB --- 2004-02-24 11:17:45 - building LINT kernel TB --- 2004-02-24 11:17:45 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-24 11:17:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 24 11:17:45 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-24 11:17:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-24 11:17:45 - ERROR: failed to build lint kernel TB --- 2004-02-24 11:17:45 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 03:31:22 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68AE616A4CE for ; Tue, 24 Feb 2004 03:31:22 -0800 (PST) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44AF143D3F for ; Tue, 24 Feb 2004 03:31:21 -0800 (PST) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.9) with SMTP id i1OBTseL038312 for ; Tue, 24 Feb 2004 12:29:55 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <071801c3fac9$932609e0$471b3dd4@dual> From: "Willem Jan Withagen" To: References: <0b6801c3f21f$1fd470b0$471b3dd4@dual> <062501c3f947$7dfc5930$4d1b3dd4@digiware.nl> Date: Tue, 24 Feb 2004 12:30:15 +0100 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 Subject: Re: System advice requested X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 11:31:22 -0000 > From: "Willem Jan Withagen" > > If I were to get a dual opteron board/system what things would be > > to watch out for, or would be required. Hardware wise that is. > > > > In the beginning I would like to use is as: > > 1) FreeBSD/windows/linux desktop > > and lateron it would turn into my > > 2) Home NFS/Samba-server running FBSD > > > > In case 2) I'd remove any fancy user-interface stuff... > > > > All suggestions welcomed, > > To follow-up on myself... And even more followup: HTML-ed version on: http://withagen.dyndns.org/FreeBSD/notes/amd64-hardware.html It is still every inaccurate, so suggestions are more than welcome. There is also still very little distinction between info on Athlon 64, single Opteron, SMP Opteron. So that creates a lot of confusion as well. To be honest: I would not be able to select a good board from all the gathered info myself. So I'm now sort of tempted to go for an MSI K8T Master2-FAR, even though this board has only 4 memory slots.... For me it has the advantage of a lot of PCI-32 slots, because I have oddles of old PCI cards. And as always: Suggestions, improvements, updates, add-ons are welcome Especially for David: Could you point me at the info for the 0,5 Gb loss of memory, so I can include that info? --WjW From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 03:47:23 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42A2C16A4CE; Tue, 24 Feb 2004 03:47:23 -0800 (PST) Received: from Reineke.Malepartus.DE (reineke.malepartus.de [194.25.4.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EAA543D1D; Tue, 24 Feb 2004 03:47:22 -0800 (PST) (envelope-from bm@Reineke.Malepartus.DE) Received: from Reineke.Malepartus.DE (localhost [127.0.0.1]) i1OBlFlT086736; Tue, 24 Feb 2004 12:47:15 +0100 (CET) (envelope-from bm@Reineke.Malepartus.DE) Received: (from bm@localhost) by Reineke.Malepartus.DE (8.12.10/8.12.10/Submit) id i1OBlE79086735; Tue, 24 Feb 2004 12:47:14 +0100 (CET) (envelope-from bm) Date: Tue, 24 Feb 2004 12:47:14 +0100 From: Burkard Meyendriesch To: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org Message-Id: <20040224124714.3f395617.bm@malepartus.de> Organization: The Home of Reineke Fuchs X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i386-portbld-freebsd4.9) X-Face: "[-; ]oI+8gP9>*J%knDN8d%DuhvJS2Lj4L\bRb7gz(pcT?2Zh6_Vam_6csAum3$<&lhAFd^ jt|!&Ut1C~Vg*E/q}+#cbFg-GU]c.bB8Ad,L'W$'9{^0y'AzM4#hS[C[F-1'|O; Kg3Vrq5q6dsU*TmJ@}+QPM\ b[^9Rhd,UoMpRpd5k[X=h.Dom*kbT`cNQ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Malepartus-MailScanner-Information: Please contact the ISP for more information X-Malepartus-MailScanner: Found to be clean Subject: 5.2.1-RELEASE: "make buildworld" on amd64 broken? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 11:47:23 -0000 Hi all, I CVSup'ed a complete new source tree (2004-02-24 11:30 UTC +01:00): --- /usr/sup/src-supfile --- *default host=cvsup.uk.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_5_2 *default delete use-rel-suffix # *default compress src-all ---------------------------- "make -B buildworld" does lots of compilations: root@grimbart:/tmp# grep ">>>" /tmp/make-buildworld.log >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries .. and then ends up with: In file included from editline.c:4: /usr/src/lib/libedit/chared.c: In function `ch_init': /usr/src/lib/libedit/chared.c:456: error: `ED_UNASSIGNED' undeclared (first use in this function) /usr/src/lib/libedit/chared.c:456: error: (Each undeclared identifier is reported only once /usr/src/lib/libedit/chared.c:456: error: for each function it appears in.) /usr/src/lib/libedit/chared.c: In function `ch_reset': /usr/src/lib/libedit/chared.c:493: error: `ED_UNASSIGNED' undeclared (first use in this function) Can anybody please tell me what is going wrong here? Thanks Burkard P.S.: I don't have any items in /etc/make.conf enabled. "make buildkernel" works fine: root@grimbart:/tmp# uname -a FreeBSD grimbart.malepartus.de 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Tue Feb 24 11:10:07 CET 2004 bm@grimbart.malepartus.de:/usr/src/sys/amd64/compile/REINEKE amd64 -- Burkard Meyendriesch Stevern 2 D-48301 Nottuln From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 12:11:41 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0CBE16A4CE for ; Tue, 24 Feb 2004 12:11:41 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E547F43D46 for ; Tue, 24 Feb 2004 12:11:40 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by pandora.cs.kun.nl (8.12.10/3.64) with ESMTP id i1OKBdUY024581 for ; Tue, 24 Feb 2004 21:11:39 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Tue, 24 Feb 2004 21:11:33 +0100 User-Agent: KMail/1.6.51 References: <200402171129.42641.peter@wemm.org> <200402181230.11078.adridg@cs.kun.nl> In-Reply-To: <200402181230.11078.adridg@cs.kun.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402242111.39048.adridg@cs.kun.nl> Subject: Re: The return of threading errors in ogg123 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 20:11:42 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 18 February 2004 12:30, Adriaan de Groot wrote: > libc_r seems solid as a rock; libpthread can play ok for a while but seems > to bail as soon as there is some load on the system. libpth doesn't work = at > all, missing a pthread_push_create symbol. Any gdb trickery I can use on > the core files to get more useful information out of them over the short > bt? ogg123 with libc_r played 1500 tracks without a hitch (all ripped from the = CDs=20 off my self, thanks); with libpthread (ie. kse) it takes a little prodding,= =20 but then it dumps core: Playing: TomCochrane/02-LoveUnderFire.ogg Ogg Vorbis stream: 2 channel, 44100 Hz Title: Love Under Fire Artist: Tom Cochrane Bus error (core dumped)5] of 04:48.17 (119.7 kbps) Output Buffer 96.9% (still with the same FreeBSD beans.ebn.kun.nl 5.2-CURRENT FreeBSD 5.2-CURRE= NT=20 #0: Mon Feb 16 08:12:04 CET 2004 =20 root@beans.ebn.kun.nl:/usr/obj/mnt/sys/CURRENT/src/sys/GENERIC amd64 ) It crashes here: #0 0x0000000200f19320 in pthread_testcancel () from /usr/lib/libpthread.so= =2E1 with this disassembly: 0x0000000200f19307 : nop 0x0000000200f19308 : mov 1085185(%rip),%rcx = =20 # 0x201022210 0x0000000200f1930f : jmpq *%ecx 0x0000000200f19311 : nop 0x0000000200f19312 : nop 0x0000000200f19313 : nop 0x0000000200f19314 : mov $0x17e,%rax 0x0000000200f1931b : mov %rcx,%r10 0x0000000200f1931e : syscall 0x0000000200f19320 : jb 0x200f19308=20 0x0000000200f19322 : retq 0x0000000200f19323 : nop 0x0000000200f19324 : mov 1085157(%rip),%rcx Not a place that looks like erroring. However: (gdb) print $rsp $1 =3D (void *) 0x51eeb8 (gdb) print $rbp $2 =3D (void *) 0x51ef80 looks like the stack-16-alignment has gotten broken again somewhere. =2D --=20 pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot Would you like a freem? =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAO6/7dqzuAf6io/4RAumYAJ9+2AblgDOTXG6x1yC9ZH2UJEqvzgCglwiv illIjGyTEEG0FzCtx6WWGrw=3D =3DyCGZ =2D----END PGP SIGNATURE----- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 12:39:37 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DDDC16A4CE for ; Tue, 24 Feb 2004 12:39:37 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92DC343D31 for ; Tue, 24 Feb 2004 12:39:36 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id <15P45RWM>; Tue, 24 Feb 2004 15:39:35 -0500 Message-ID: From: Don Bowman To: "'freebsd-amd64@FreeBSD.org'" Date: Tue, 24 Feb 2004 15:39:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: x86-64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 20:39:37 -0000 Has anyone evaluated running FreeBSD with Intel's x86-64 extensions (which appear to be a copy of AMD's?) http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spo tlight_64bit has intel's detailed instruction set reference on the subject. From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 13:39:36 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 468F616A4CE for ; Tue, 24 Feb 2004 13:39:36 -0800 (PST) Received: from host142.ipowerweb.com (host142.ipowerweb.com [66.235.193.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 270CA43D1D for ; Tue, 24 Feb 2004 13:39:36 -0800 (PST) (envelope-from jem@thejemreport.com) Received: (qmail 3433 invoked from network); 24 Feb 2004 21:39:07 -0000 Received: from unknown (HELO ?192.168.0.163?) (66.66.218.250) by 0 with SMTP; 24 Feb 2004 21:39:07 -0000 From: Jem Matzan To: "'freebsd-amd64@FreeBSD.org'" Content-Type: text/plain Message-Id: <1077658664.92943.15.camel@.rochester.rr.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 24 Feb 2004 16:37:44 -0500 Content-Transfer-Encoding: 7bit Subject: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 21:39:36 -0000 I've spent the last two weeks benchmarking an AMD64 machine with FreeBSD. I've acquired a decent amount of data that seems to show conclusively that a kernel using the ULE scheduler has slower compile times and inferior performance to a kernel running the 4BSD scheduler. The difference is roughly 11% in some cases, although I have not yet run all of the numbers through ministat yet. This is consistent for both i386 and AMD64. I tried both 5.2-RELEASE and 5.2.1-RC2 and the performance results were identical for this system. I've also found that the AMD64 edition of FreeBSD is significantly slower than the i386 edition when doing a buildworld (with any amount of simultaneous makes), but ubench reports a slightly higher CPU score. I'm still trying to work with John McCalpin to get Stream to work properly for testing, and I have openssl speed tests that I have not yet compared. For testing I used the same make.conf and rc.conf for both systems and eliminated every possible option from the kernel that I could, without breaking anything. I ran all tests in single user mode with none of the usual background process (network, usbd, fsck, etc.) running. The kernel config files were as identical as they could possibly be. I collected three sets of data per run, each being performed immediately after a fresh restart, and for the buildworld tests I did three sets of those three sets, for a total of nine per scheduler. I'm willing to type in all of my data on a temporary page before I finish testing everything (I have another system to test before the review can be written) for the purpose of peer review, but I don't want to go to the trouble if no one here has a reason to dispute my findings. I thought that ULE was supposed to offer superior performance -- or at least, that's the word around the Internet -- but I have yet to discover that through my experience. Can anyone offer any possible explanation for ULE performing worse than 4BSD? How about AMD64 being slower than i386 on the same hardware? By slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 mode. -Jem From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 13:59:00 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6458C16A4CE for ; Tue, 24 Feb 2004 13:59:00 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E2F143D1D for ; Tue, 24 Feb 2004 13:59:00 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i1OLwnKH028899; Tue, 24 Feb 2004 13:58:52 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i1OLwmRj028898; Tue, 24 Feb 2004 13:58:48 -0800 Date: Tue, 24 Feb 2004 13:58:47 -0800 From: Brooks Davis To: Jem Matzan Message-ID: <20040224215847.GC6356@Odin.AC.HMC.Edu> References: <1077658664.92943.15.camel@.rochester.rr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4jXrM3lyYWu4nBt5" Content-Disposition: inline In-Reply-To: <1077658664.92943.15.camel@.rochester.rr.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 21:59:00 -0000 --4jXrM3lyYWu4nBt5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2004 at 04:37:44PM -0500, Jem Matzan wrote: > I thought that ULE was supposed to offer superior performance -- or at > least, that's the word around the Internet -- but I have yet to discover > that through my experience. Can anyone offer any possible explanation > for ULE performing worse than 4BSD? Have you contacted the author of ULE? He is generally intrested in reports to this effect and has been able to fix reproducable problems in the past. > How about AMD64 being slower than i386 on the same hardware? By > slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 > mode. You can't usefully compare compile times when you are compiling for a different instructions set. The work involved is rairly the same so the results are meaning less. If you could factor out the cost of building the native bootstrap tools since that isn't the same job on each machine, the speed of a cross buildworld would be an intresting test. For comparing i386 and amd64, I'd probably build an alpha or sparc64 world so the target would be entierly different. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --4jXrM3lyYWu4nBt5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAO8kWXY6L6fI4GtQRAvClAKCnhgJwwaMMYxQrUjjoF5WHmX49HwCfehDy +fQCGmnAeDW9WglN6lD5vjw= =K7/T -----END PGP SIGNATURE----- --4jXrM3lyYWu4nBt5-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 14:06:17 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DBF116A4CE for ; Tue, 24 Feb 2004 14:06:17 -0800 (PST) Received: from host142.ipowerweb.com (host142.ipowerweb.com [66.235.193.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 8712443D1F for ; Tue, 24 Feb 2004 14:06:17 -0800 (PST) (envelope-from jem@thejemreport.com) Received: (qmail 15611 invoked from network); 24 Feb 2004 22:05:49 -0000 Received: from unknown (HELO thejemreport.com) (66.66.218.250) by 0 with SMTP; 24 Feb 2004 22:05:49 -0000 Message-ID: <403BCA6B.2050908@thejemreport.com> Date: Tue, 24 Feb 2004 17:04:27 -0500 From: Jem Matzan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040219 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'freebsd-amd64@FreeBSD.org'" References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> In-Reply-To: <20040224215847.GC6356@Odin.AC.HMC.Edu> Content-Type: multipart/mixed; boundary="------------080700020705010607030403" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 22:06:17 -0000 This is a multi-part message in MIME format. --------------080700020705010607030403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brooks Davis wrote: >On Tue, Feb 24, 2004 at 04:37:44PM -0500, Jem Matzan wrote: > > >>I thought that ULE was supposed to offer superior performance -- or at >>least, that's the word around the Internet -- but I have yet to discover >>that through my experience. Can anyone offer any possible explanation >>for ULE performing worse than 4BSD? >> >> > >Have you contacted the author of ULE? He is generally intrested in >reports to this effect and has been able to fix reproducable problems in >the past. > > > I'll write to the author right now. But I do want to get this to press sometime soon. >>How about AMD64 being slower than i386 on the same hardware? By >>slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 >>mode. >> >> > >You can't usefully compare compile times when you are compiling for >a different instructions set. The work involved is rairly the same >so the results are meaning less. If you could factor out the cost of >building the native bootstrap tools since that isn't the same job on >each machine, the speed of a cross buildworld would be an intresting >test. For comparing i386 and amd64, I'd probably build an alpha or >sparc64 world so the target would be entierly different. > >-- Brooks > > I figured that the world would be the same for both AMD64 and i386. That really sucks that all of this data and all of that time has been more or less wasted on doing buildworld time benchmarks. As far as I know it isn't possible to do a crossbuild (I've tried before, and I read on the list several weeks ago that it won't work). Do you have any suggestions for measuring compile times? -Jem --------------080700020705010607030403-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 14:35:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C10BC16A4CE for ; Tue, 24 Feb 2004 14:35:42 -0800 (PST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A036143D2F for ; Tue, 24 Feb 2004 14:35:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 30313 invoked from network); 24 Feb 2004 22:35:41 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 24 Feb 2004 22:35:41 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i1OMZY28039453; Tue, 24 Feb 2004 17:35:35 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: amd64@FreeBSD.org Date: Tue, 24 Feb 2004 17:36:55 -0500 User-Agent: KMail/1.6 References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> <403BCA6B.2050908@thejemreport.com> In-Reply-To: <403BCA6B.2050908@thejemreport.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402241736.55911.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Jem Matzan cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 22:35:42 -0000 On Tuesday 24 February 2004 05:04 pm, Jem Matzan wrote: > Brooks Davis wrote: > >On Tue, Feb 24, 2004 at 04:37:44PM -0500, Jem Matzan wrote: > >>How about AMD64 being slower than i386 on the same hardware? By > >>slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 > >>mode. > > > >You can't usefully compare compile times when you are compiling for > >a different instructions set. The work involved is rairly the same > >so the results are meaning less. If you could factor out the cost of > >building the native bootstrap tools since that isn't the same job on > >each machine, the speed of a cross buildworld would be an intresting > >test. For comparing i386 and amd64, I'd probably build an alpha or > >sparc64 world so the target would be entierly different. > > > >-- Brooks > > I figured that the world would be the same for both AMD64 and i386. That > really sucks that all of this data and all of that time has been more or > less wasted on doing buildworld time benchmarks. As far as I know it > isn't possible to do a crossbuild (I've tried before, and I read on the > list several weeks ago that it won't work). Do you have any suggestions > for measuring compile times? You can do a crossbuild easy, just do: make TARGET_ARCH=amd64 buildworld or subsitute whatever arch for amd64. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 14:35:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C410C16A4CF for ; Tue, 24 Feb 2004 14:35:42 -0800 (PST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A051C43D39 for ; Tue, 24 Feb 2004 14:35:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 30313 invoked from network); 24 Feb 2004 22:35:41 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 24 Feb 2004 22:35:41 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i1OMZY28039453; Tue, 24 Feb 2004 17:35:35 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: amd64@FreeBSD.org Date: Tue, 24 Feb 2004 17:36:55 -0500 User-Agent: KMail/1.6 References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> <403BCA6B.2050908@thejemreport.com> In-Reply-To: <403BCA6B.2050908@thejemreport.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402241736.55911.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Jem Matzan cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 22:35:42 -0000 On Tuesday 24 February 2004 05:04 pm, Jem Matzan wrote: > Brooks Davis wrote: > >On Tue, Feb 24, 2004 at 04:37:44PM -0500, Jem Matzan wrote: > >>How about AMD64 being slower than i386 on the same hardware? By > >>slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 > >>mode. > > > >You can't usefully compare compile times when you are compiling for > >a different instructions set. The work involved is rairly the same > >so the results are meaning less. If you could factor out the cost of > >building the native bootstrap tools since that isn't the same job on > >each machine, the speed of a cross buildworld would be an intresting > >test. For comparing i386 and amd64, I'd probably build an alpha or > >sparc64 world so the target would be entierly different. > > > >-- Brooks > > I figured that the world would be the same for both AMD64 and i386. That > really sucks that all of this data and all of that time has been more or > less wasted on doing buildworld time benchmarks. As far as I know it > isn't possible to do a crossbuild (I've tried before, and I read on the > list several weeks ago that it won't work). Do you have any suggestions > for measuring compile times? You can do a crossbuild easy, just do: make TARGET_ARCH=amd64 buildworld or subsitute whatever arch for amd64. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 14:51:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B05416A4CE; Tue, 24 Feb 2004 14:51:14 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21CBC43D1D; Tue, 24 Feb 2004 14:51:14 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i1OMpAKH009733; Tue, 24 Feb 2004 14:51:10 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i1OMp92i009730; Tue, 24 Feb 2004 14:51:09 -0800 Date: Tue, 24 Feb 2004 14:51:09 -0800 From: Brooks Davis To: John Baldwin Message-ID: <20040224225109.GE6356@Odin.AC.HMC.Edu> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> <403BCA6B.2050908@thejemreport.com> <200402241736.55911.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GxcwvYAGnODwn7V8" Content-Disposition: inline In-Reply-To: <200402241736.55911.jhb@FreeBSD.org> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: amd64@freebsd.org cc: Jem Matzan cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 22:51:14 -0000 --GxcwvYAGnODwn7V8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2004 at 05:36:55PM -0500, John Baldwin wrote: > On Tuesday 24 February 2004 05:04 pm, Jem Matzan wrote: > > Brooks Davis wrote: > > >On Tue, Feb 24, 2004 at 04:37:44PM -0500, Jem Matzan wrote: > > >>How about AMD64 being slower than i386 on the same hardware? By > > >>slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 > > >>mode. > > > > > >You can't usefully compare compile times when you are compiling for > > >a different instructions set. The work involved is rairly the same > > >so the results are meaning less. If you could factor out the cost of > > >building the native bootstrap tools since that isn't the same job on > > >each machine, the speed of a cross buildworld would be an intresting > > >test. For comparing i386 and amd64, I'd probably build an alpha or > > >sparc64 world so the target would be entierly different. > > > > > >-- Brooks > > > > I figured that the world would be the same for both AMD64 and i386. That > > really sucks that all of this data and all of that time has been more or > > less wasted on doing buildworld time benchmarks. As far as I know it > > isn't possible to do a crossbuild (I've tried before, and I read on the > > list several weeks ago that it won't work). Do you have any suggestions > > for measuring compile times? >=20 > You can do a crossbuild easy, just do: >=20 > make TARGET_ARCH=3Damd64 buildworld >=20 > or subsitute whatever arch for amd64. If you use this for benchmarking purposes, you can only count stage 4, the world stage. Before that you are building tools for the native OS type. If your purpose in using the box is developing architecture independent code, a buildworld does produce a vaguly useful benchmark of how fast compilation is, but that will have more to do with the compiler then the OS. Compiler performance is affected by both compiler efficency and the ease or difficulty of producing code that runs decently on the given architecture. It's hard to say anything definiative from a simple build time since a fast compiler might produce code that runs horribly slowly. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --GxcwvYAGnODwn7V8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAO9VcXY6L6fI4GtQRAta7AJ9weGt3gw/6IkHbTZc35PtR64BkQQCg2KJ1 hH98Q0LYQDGnxfJ+zUbyOP4= =YL4z -----END PGP SIGNATURE----- --GxcwvYAGnODwn7V8-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 14:51:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B05416A4CE; Tue, 24 Feb 2004 14:51:14 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21CBC43D1D; Tue, 24 Feb 2004 14:51:14 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i1OMpAKH009733; Tue, 24 Feb 2004 14:51:10 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i1OMp92i009730; Tue, 24 Feb 2004 14:51:09 -0800 Date: Tue, 24 Feb 2004 14:51:09 -0800 From: Brooks Davis To: John Baldwin Message-ID: <20040224225109.GE6356@Odin.AC.HMC.Edu> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> <403BCA6B.2050908@thejemreport.com> <200402241736.55911.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GxcwvYAGnODwn7V8" Content-Disposition: inline In-Reply-To: <200402241736.55911.jhb@FreeBSD.org> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: amd64@freebsd.org cc: Jem Matzan cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 22:51:14 -0000 --GxcwvYAGnODwn7V8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2004 at 05:36:55PM -0500, John Baldwin wrote: > On Tuesday 24 February 2004 05:04 pm, Jem Matzan wrote: > > Brooks Davis wrote: > > >On Tue, Feb 24, 2004 at 04:37:44PM -0500, Jem Matzan wrote: > > >>How about AMD64 being slower than i386 on the same hardware? By > > >>slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 > > >>mode. > > > > > >You can't usefully compare compile times when you are compiling for > > >a different instructions set. The work involved is rairly the same > > >so the results are meaning less. If you could factor out the cost of > > >building the native bootstrap tools since that isn't the same job on > > >each machine, the speed of a cross buildworld would be an intresting > > >test. For comparing i386 and amd64, I'd probably build an alpha or > > >sparc64 world so the target would be entierly different. > > > > > >-- Brooks > > > > I figured that the world would be the same for both AMD64 and i386. That > > really sucks that all of this data and all of that time has been more or > > less wasted on doing buildworld time benchmarks. As far as I know it > > isn't possible to do a crossbuild (I've tried before, and I read on the > > list several weeks ago that it won't work). Do you have any suggestions > > for measuring compile times? >=20 > You can do a crossbuild easy, just do: >=20 > make TARGET_ARCH=3Damd64 buildworld >=20 > or subsitute whatever arch for amd64. If you use this for benchmarking purposes, you can only count stage 4, the world stage. Before that you are building tools for the native OS type. If your purpose in using the box is developing architecture independent code, a buildworld does produce a vaguly useful benchmark of how fast compilation is, but that will have more to do with the compiler then the OS. Compiler performance is affected by both compiler efficency and the ease or difficulty of producing code that runs decently on the given architecture. It's hard to say anything definiative from a simple build time since a fast compiler might produce code that runs horribly slowly. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --GxcwvYAGnODwn7V8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAO9VcXY6L6fI4GtQRAta7AJ9weGt3gw/6IkHbTZc35PtR64BkQQCg2KJ1 hH98Q0LYQDGnxfJ+zUbyOP4= =YL4z -----END PGP SIGNATURE----- --GxcwvYAGnODwn7V8-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 14:51:35 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5A7E16A4D2 for ; Tue, 24 Feb 2004 14:51:35 -0800 (PST) Received: from host142.ipowerweb.com (host142.ipowerweb.com [66.235.193.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 898E043D1F for ; Tue, 24 Feb 2004 14:51:35 -0800 (PST) (envelope-from jem@thejemreport.com) Received: (qmail 34789 invoked from network); 24 Feb 2004 22:51:07 -0000 Received: from unknown (HELO thejemreport.com) (66.66.218.250) by 0 with SMTP; 24 Feb 2004 22:51:07 -0000 Message-ID: <403BD508.7080307@thejemreport.com> Date: Tue, 24 Feb 2004 17:49:44 -0500 From: Jem Matzan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040219 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'freebsd-amd64@FreeBSD.org'" References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> <403BCA6B.2050908@thejemreport.com> <200402241736.55911.jhb@FreeBSD.org> In-Reply-To: <200402241736.55911.jhb@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------060003000702020300050409" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 22:51:35 -0000 This is a multi-part message in MIME format. --------------060003000702020300050409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Baldwin wrote: >On Tuesday 24 February 2004 05:04 pm, Jem Matzan wrote: > > >>Brooks Davis wrote: >> >> >>>On Tue, Feb 24, 2004 at 04:37:44PM -0500, Jem Matzan wrote: >>> >>> >>>>How about AMD64 being slower than i386 on the same hardware? By >>>>slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 >>>>mode. >>>> >>>> >>>You can't usefully compare compile times when you are compiling for >>>a different instructions set. The work involved is rairly the same >>>so the results are meaning less. If you could factor out the cost of >>>building the native bootstrap tools since that isn't the same job on >>>each machine, the speed of a cross buildworld would be an intresting >>>test. For comparing i386 and amd64, I'd probably build an alpha or >>>sparc64 world so the target would be entierly different. >>> >>>-- Brooks >>> >>> >>I figured that the world would be the same for both AMD64 and i386. That >>really sucks that all of this data and all of that time has been more or >>less wasted on doing buildworld time benchmarks. As far as I know it >>isn't possible to do a crossbuild (I've tried before, and I read on the >>list several weeks ago that it won't work). Do you have any suggestions >>for measuring compile times? >> >> > >You can do a crossbuild easy, just do: > >make TARGET_ARCH=amd64 buildworld > >or subsitute whatever arch for amd64. > > > Ah -- I wasn't considering all of the possibilities. It was the AMD64 form i386 crossbuild that wasn't working for me (while actually trying to turn a working i386 system into an AMD64 build -- it was the installworld that failed and broke everything to hell. Now I remember). So instead I'll build a SPARC or ALPHA world on both AMD64 and i386. Of course this means another 18 hours of testing... unless I can build the i386 world with AMD64, in which case I only have half of everything to do again. -Jem --------------060003000702020300050409-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 15:10:40 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96C5E16A4CE; Tue, 24 Feb 2004 15:10:40 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 781F443D2F; Tue, 24 Feb 2004 15:10:40 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2646E7303A; Tue, 24 Feb 2004 18:10:36 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040224231036.2646E7303A@freebsd-current.sentex.ca> Date: Tue, 24 Feb 2004 18:10:36 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 23:10:40 -0000 TB --- 2004-02-24 22:13:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-24 22:13:59 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-24 22:13:59 - checking out the source tree TB --- 2004-02-24 22:13:59 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-24 22:13:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-24 22:17:43 - building world TB --- 2004-02-24 22:17:43 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-24 22:17:43 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-24 23:04:26 - building generic kernel TB --- 2004-02-24 23:04:26 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-24 23:04:26 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Feb 24 23:04:26 GMT 2004 >>> Kernel build for GENERIC completed on Tue Feb 24 23:10:33 GMT 2004 TB --- 2004-02-24 23:10:33 - generating LINT kernel config TB --- 2004-02-24 23:10:33 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-24 23:10:33 - /usr/bin/make -B LINT TB --- 2004-02-24 23:10:33 - building LINT kernel TB --- 2004-02-24 23:10:33 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-24 23:10:33 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 24 23:10:33 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-24 23:10:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-24 23:10:35 - ERROR: failed to build lint kernel TB --- 2004-02-24 23:10:35 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 16:09:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0CB916A4CE; Tue, 24 Feb 2004 16:09:03 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42ED143D2F; Tue, 24 Feb 2004 16:09:03 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id C19233C8013; Tue, 24 Feb 2004 19:11:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Tue, 24 Feb 2004 19:08:58 -0500 To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.613) cc: freebsd-questions@freebsd.org Subject: RELENG-5_2_1_RELEASE | make buildkernel | Crypto X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 00:09:03 -0000 Anyone have any ideas? options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security su-2.05b# make buildkernel KERNCONF=ESHARA ... ... sh /usr/src/sys/conf/newvers.sh ESHARA cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=20000 -fno-strict-aliasing -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror vers.c linking kernel.debug bf_ecb.o: In function `BF_ecb_encrypt': /usr/src/sys/crypto/blowfish/bf_ecb.c:79: undefined reference to `BF_encrypt' /usr/src/sys/crypto/blowfish/bf_ecb.c:81: undefined reference to `BF_decrypt' bf_skey.o: In function `BF_set_key': /usr/src/sys/crypto/blowfish/bf_skey.c:112: undefined reference to `BF_encrypt' /usr/src/sys/crypto/blowfish/bf_skey.c:119: undefined reference to `BF_encrypt' des_ecb.o: In function `des_ecb_encrypt': /usr/src/sys/crypto/des/des_ecb.c:107: undefined reference to `des_encrypt1' des_ecb.o: In function `des_ecb3_encrypt': /usr/src/sys/crypto/des/des_ecb.c:128: undefined reference to `des_encrypt3' /usr/src/sys/crypto/des/des_ecb.c:130: undefined reference to `des_decrypt3' *** Error code 1 Stop in /usr/obj/usr/src/sys/ESHARA. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real 2m52.297s user 2m22.967s sys 0m23.772s su-2.05b# From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 16:12:39 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3891816A4CE; Tue, 24 Feb 2004 16:12:39 -0800 (PST) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FAD643D1F; Tue, 24 Feb 2004 16:12:39 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (03a253d0ffa2fd76af56e527847ce81c@adsl-67-119-53-203.dsl.lsan03.pacbell.net [67.119.53.203])i1P0Caxn016162; Tue, 24 Feb 2004 18:12:36 -0600 (CST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3A87566CAF; Tue, 24 Feb 2004 16:12:35 -0800 (PST) Date: Tue, 24 Feb 2004 16:12:35 -0800 From: Kris Kennaway To: Jason Lixfeld Message-ID: <20040225001235.GA56691@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-questions@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: RELENG-5_2_1_RELEASE | make buildkernel | Crypto X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 00:12:39 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 24, 2004 at 07:08:58PM -0500, Jason Lixfeld wrote: > Anyone have any ideas? Post your cvsupfile..you may have an incomplete source tree. Kris --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAO+hyWry0BWjoQKURAl1JAJ95L2mtekT+pjaFQphXsOJKbMuDJQCgjh/v KfR5euApu+1pDBosqkSDJQM= =D1QW -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 16:16:16 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A5C716A4CE; Tue, 24 Feb 2004 16:16:16 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AD3443D3F; Tue, 24 Feb 2004 16:16:16 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id 404D13C8013; Tue, 24 Feb 2004 19:18:31 -0500 (EST) In-Reply-To: <20040225001235.GA56691@xor.obsecurity.org> References: <20040225001235.GA56691@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Tue, 24 Feb 2004 19:16:12 -0500 To: Kris Kennaway X-Mailer: Apple Mail (2.613) cc: freebsd-questions@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: RELENG-5_2_1_RELEASE | make buildkernel | Crypto X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 00:16:16 -0000 On Feb 24, 2004, at 7:12 PM, Kris Kennaway wrote: > On Tue, Feb 24, 2004 at 07:08:58PM -0500, Jason Lixfeld wrote: >> Anyone have any ideas? > > Post your cvsupfile..you may have an incomplete source tree. *default host=cvsup12.freebsd.org *default prefix=/usr *default release=cvs tag=RELENG_5_2_1_RELEASE *default delete use-rel-suffix *default compress src-all From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 16:20:16 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D341116A4CF for ; Tue, 24 Feb 2004 16:20:16 -0800 (PST) Received: from tenor.codegen.com (tenor.CodeGen.COM [204.62.145.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FB943D31 for ; Tue, 24 Feb 2004 16:20:16 -0800 (PST) (envelope-from parag@codegen.com) Received: from tenor.codegen.com (localhost.codegen.com [127.0.0.1]) by tenor.codegen.com (8.12.6p2/8.12.3) with ESMTP id i1P0KG67019166 for ; Tue, 24 Feb 2004 16:20:16 -0800 (PST) (envelope-from parag@tenor.codegen.com) Organization: CodeGen, Inc. X-URL: http://www.codegen.com/ X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm To: "'freebsd-amd64@FreeBSD.org'" In-Reply-To: Message from Jem Matzan of "Tue, 24 Feb 2004 17:49:44 EST." <403BD508.7080307@thejemreport.com> Date: Tue, 24 Feb 2004 16:20:16 -0800 Message-ID: <19165.1077668416@tenor.codegen.com> From: Parag Patel Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 00:20:17 -0000 Also check your kernel config file. I seem to recall that the default amd64 kernels have a bunch of debug and assertion code switched on. -- __ /__)_ _ _ _ Everybody wants to go to heaven, but nobody wants to die. / (// (/(/ _/ From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 16:30:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 472F716A4CE; Tue, 24 Feb 2004 16:30:59 -0800 (PST) Received: from mail.ebit.ca (ebit.ca [207.136.103.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id C657C43D39; Tue, 24 Feb 2004 16:30:58 -0800 (PST) (envelope-from jason+lists.freebsd@lixfeld.ca) Received: from [192.168.100.66] (trek.lixfeld.ca [216.7.194.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.ebit.ca (Postfix) with ESMTP id A37223C8013; Tue, 24 Feb 2004 19:33:13 -0500 (EST) In-Reply-To: References: <20040225001235.GA56691@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Lixfeld Date: Tue, 24 Feb 2004 19:30:54 -0500 To: Kris Kennaway X-Mailer: Apple Mail (2.613) cc: freebsd-questions@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: RELENG-5_2_1_RELEASE | make buildkernel | Crypto X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 00:30:59 -0000 On Feb 24, 2004, at 7:16 PM, Jason Lixfeld wrote: > > *default host=cvsup12.freebsd.org > *default prefix=/usr > *default release=cvs tag=RELENG_5_2_1_RELEASE > *default delete use-rel-suffix > *default compress > src-all > for shits and giggles I ran cvsup against cvsup.freebsd.org: su-2.05b# cvsup -Z -g -L 2 /usr/local/etc/cvsup/stable-supfile Parsing supfile "/usr/local/etc/cvsup/stable-supfile" Connecting to cvsup.freebsd.org Connected to cvsup.freebsd.org Server software version: SNAP_16_1e Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully su-2.05b# No difference from cvsup12. From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 16:45:12 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EB2016A4CE; Tue, 24 Feb 2004 16:45:12 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3571E43D1D; Tue, 24 Feb 2004 16:45:12 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1P0jBp9066981 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Feb 2004 18:45:11 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1P0jBfg066978; Tue, 24 Feb 2004 18:45:11 -0600 (CST) Date: Tue, 24 Feb 2004 18:45:11 -0600 (CST) Message-Id: <200402250045.i1P0jBfg066978@bigtex.jrv.org> From: James Van Artsdalen To: jason+lists.freebsd@lixfeld.ca In-reply-to: (message from Jason Lixfeld on Tue, 24 Feb 2004 19:08:58 -0500) References: cc: freebsd-questions@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: RELENG-5_2_1_RELEASE | make buildkernel | Crypto X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 00:45:12 -0000 > From: Jason Lixfeld > Date: Tue, 24 Feb 2004 19:08:58 -0500 > > Anyone have any ideas? > > options IPSEC #IP security > options IPSEC_ESP #IP security (crypto; define w/ > IPSEC) > options IPSEC_DEBUG #debug for IP security > > su-2.05b# make buildkernel KERNCONF=ESHARA > ... > ... > /usr/src/sys/crypto/blowfish/bf_ecb.c:79: undefined reference to > `BF_encrypt' I'd like to hear back how performance is, to know if assembly code is worthwhile. --- sys/conf/files.amd64.orig Mon Nov 17 02:58:16 2003 +++ sys/conf/files.amd64 Mon Feb 2 23:08:43 2004 @@ -123,3 +123,10 @@ compat/ia32/ia32_sigtramp.S optional ia32 compat/ia32/ia32_sysvec.c optional ia32 kern/imgact_elf32.c optional ia32 +# +crypto/des/des_ecb.c optional netsmbcrypto +crypto/des/des_enc.c optional netsmbcrypto +crypto/des/des_setkey.c optional netsmbcrypto +crypto/blowfish/bf_enc.c optional crypto +crypto/blowfish/bf_enc.c optional ipsec ipsec_esp +crypto/des/des_enc.c optional ipsec ipsec_esp From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 18:40:35 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1217E16A4CE for ; Tue, 24 Feb 2004 18:40:35 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C72743D1F for ; Tue, 24 Feb 2004 18:40:34 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1P2eXp9070996 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Feb 2004 20:40:33 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1P2eXtV070993; Tue, 24 Feb 2004 20:40:33 -0600 (CST) Date: Tue, 24 Feb 2004 20:40:33 -0600 (CST) Message-Id: <200402250240.i1P2eXtV070993@bigtex.jrv.org> From: James Van Artsdalen To: don@sandvine.com In-reply-to: (message from Don Bowman on Tue, 24 Feb 2004 15:39:35 -0500) References: cc: freebsd-amd64@freebsd.org Subject: Re: x86-64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 02:40:35 -0000 > From: Don Bowman > Date: Tue, 24 Feb 2004 15:39:35 -0500 > > Has anyone evaluated running FreeBSD with Intel's > x86-64 extensions (which appear to be a copy of AMD's?) > > http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit > > has intel's detailed instruction set reference on the subject. If the architecture is the same then it's more of a problem for the compiler people handle the lloonngg pipeline. If the architecture is broken ... then someone will have to volunteer to look into it. From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 24 19:01:16 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EABD916A4CE for ; Tue, 24 Feb 2004 19:01:16 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DE8643D1F for ; Tue, 24 Feb 2004 19:01:16 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1P31Dp9071631 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Feb 2004 21:01:13 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1P31COh071628; Tue, 24 Feb 2004 21:01:12 -0600 (CST) Date: Tue, 24 Feb 2004 21:01:12 -0600 (CST) Message-Id: <200402250301.i1P31COh071628@bigtex.jrv.org> From: James Van Artsdalen To: adridg@cs.kun.nl In-reply-to: <200402242111.39048.adridg@cs.kun.nl> (message from Adriaan de Groot on Tue, 24 Feb 2004 21:11:33 +0100) References: <200402181230.11078.adridg@cs.kun.nl> <200402242111.39048.adridg@cs.kun.nl> cc: freebsd-amd64@freebsd.org Subject: Re: The return of threading errors in ogg123 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 03:01:17 -0000 > From: Adriaan de Groot > Date: Tue, 24 Feb 2004 21:11:33 +0100 > > looks like the stack-16-alignment has gotten broken again somewhere. Hack the gcc function epilogue code to test %rsp before each return and branch to abort if stack is mis-aligned, or, maybe load 8(%rsp) to %xmm7 or something like that to force a fault. That will get you close to the scene of the crime, and flush out others that aren't near FP code. From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 03:17:52 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1450716A4CE; Wed, 25 Feb 2004 03:17:52 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4D4143D1F; Wed, 25 Feb 2004 03:17:51 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 182687303A; Wed, 25 Feb 2004 06:17:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040225111751.182687303A@freebsd-current.sentex.ca> Date: Wed, 25 Feb 2004 06:17:51 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 11:17:52 -0000 TB --- 2004-02-25 10:21:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-25 10:21:17 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-25 10:21:17 - checking out the source tree TB --- 2004-02-25 10:21:17 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-25 10:21:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-25 10:24:59 - building world TB --- 2004-02-25 10:24:59 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-25 10:24:59 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-25 11:11:32 - building generic kernel TB --- 2004-02-25 11:11:32 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-25 11:11:32 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Feb 25 11:11:33 GMT 2004 >>> Kernel build for GENERIC completed on Wed Feb 25 11:17:49 GMT 2004 TB --- 2004-02-25 11:17:49 - generating LINT kernel config TB --- 2004-02-25 11:17:49 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-25 11:17:49 - /usr/bin/make -B LINT TB --- 2004-02-25 11:17:50 - building LINT kernel TB --- 2004-02-25 11:17:50 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-25 11:17:50 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 25 11:17:50 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-25 11:17:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-25 11:17:50 - ERROR: failed to build lint kernel TB --- 2004-02-25 11:17:50 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 04:19:13 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A432616A4CE for ; Wed, 25 Feb 2004 04:19:13 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE13943D2F for ; Wed, 25 Feb 2004 04:19:12 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by pandora.cs.kun.nl (8.12.10/3.64) with ESMTP id i1PCJBUY026440 for ; Wed, 25 Feb 2004 13:19:11 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Wed, 25 Feb 2004 13:19:06 +0100 User-Agent: KMail/1.6.51 References: <200402242111.39048.adridg@cs.kun.nl> <200402250301.i1P31COh071628@bigtex.jrv.org> In-Reply-To: <200402250301.i1P31COh071628@bigtex.jrv.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402251319.11569.adridg@cs.kun.nl> Subject: Re: The return of threading errors in ogg123 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 12:19:13 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 25 February 2004 04:01, James Van Artsdalen wrote: > > From: Adriaan de Groot > > Date: Tue, 24 Feb 2004 21:11:33 +0100 > > > > looks like the stack-16-alignment has gotten broken again somewhere. > > Hack the gcc function epilogue code to test %rsp before each return and > branch to abort if stack is mis-aligned, or, maybe load 8(%rsp) to %xmm7 = or > something like that to force a fault. That will get you close to the sce= ne > of the crime, and flush out others that aren't near FP code. Ummm ... "Dammit Jim, I'm a doctor of computer science, not a compiler=20 hacker!" Can you give a suggestion? Although I'm not averse to wasting my=20 time figuring out how to do all those things, I think I'd rather waste it b= y=20 fixing the ed(4) driver. =2D --=20 pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot Would you like a freem? =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAPJK/dqzuAf6io/4RAjZPAJ9ZA34W9FRRRVaLjO+6Z031xFpicQCfXm4d N13I5qby0X/cf4EDU67ulhs=3D =3Dsckq =2D----END PGP SIGNATURE----- From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 07:59:38 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15F0216A4CE for ; Wed, 25 Feb 2004 07:59:38 -0800 (PST) Received: from mailhub.sweetdreamsracing.biz (mailhub.sweetdreamsracing.biz [66.92.171.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C190D43D1D for ; Wed, 25 Feb 2004 07:59:37 -0800 (PST) (envelope-from culverk@sweetdreamsracing.biz) Received: by mailhub.sweetdreamsracing.biz (Postfix, from userid 80) id DC3AC2D4; Wed, 25 Feb 2004 11:07:54 -0500 (EST) Received: from 141.156.69.109 ([141.156.69.109]) by www.sweetdreamsracing.biz (Horde) with HTTP for ; Wed, 25 Feb 2004 11:07:54 -0500 Message-ID: <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> Date: Wed, 25 Feb 2004 11:07:54 -0500 From: Kenneth Culver To: Jem Matzan References: <1077658664.92943.15.camel@.rochester.rr.com> In-Reply-To: <1077658664.92943.15.camel@.rochester.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 15:59:38 -0000 Quoting Jem Matzan : > I've spent the last two weeks benchmarking an AMD64 machine with > FreeBSD. I've acquired a decent amount of data that seems to show > conclusively that a kernel using the ULE scheduler has slower compile > times and inferior performance to a kernel running the 4BSD scheduler. > The difference is roughly 11% in some cases, although I have not yet run > all of the numbers through ministat yet. This is consistent for both > i386 and AMD64. > > I tried both 5.2-RELEASE and 5.2.1-RC2 and the performance results were > identical for this system. > > I've also found that the AMD64 edition of FreeBSD is significantly > slower than the i386 edition when doing a buildworld (with any amount of > simultaneous makes), but ubench reports a slightly higher CPU score. I'm > still trying to work with John McCalpin to get Stream to work properly > for testing, and I have openssl speed tests that I have not yet > compared. > > For testing I used the same make.conf and rc.conf for both systems and > eliminated every possible option from the kernel that I could, without > breaking anything. I ran all tests in single user mode with none of the > usual background process (network, usbd, fsck, etc.) running. The kernel > config files were as identical as they could possibly be. > > I collected three sets of data per run, each being performed immediately > after a fresh restart, and for the buildworld tests I did three sets of > those three sets, for a total of nine per scheduler. > > I'm willing to type in all of my data on a temporary page before I > finish testing everything (I have another system to test before the > review can be written) for the purpose of peer review, but I don't want > to go to the trouble if no one here has a reason to dispute my findings. > I thought that ULE was supposed to offer superior performance -- or at > least, that's the word around the Internet -- but I have yet to discover > that through my experience. Can anyone offer any possible explanation > for ULE performing worse than 4BSD? How about AMD64 being slower than > i386 on the same hardware? By slower, I mean a buildworld -j4 took about > 400 seconds longer in AMD64 mode. > The buildworld problem could just be because it takes longer for the compiler to generate amd64 code. In fact, I'm almost willing to bet that's the case since amd64 has 2x the GPR's that x86 does. It's likely that it's harder to optimize for it. Does anyone who knows compilers care to comment? Ken From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 08:13:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E58DE16A4CE; Wed, 25 Feb 2004 08:13:03 -0800 (PST) Received: from chaos.fxp.org (chaos.fxp.org [209.251.159.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id A790243D2F; Wed, 25 Feb 2004 08:13:03 -0800 (PST) (envelope-from jedgar@fxp.org) Received: by chaos.fxp.org (Postfix, from userid 1000) id C473A444; Wed, 25 Feb 2004 11:13:02 -0500 (EST) Date: Wed, 25 Feb 2004 11:13:02 -0500 From: Chris Faulhaber To: freebsd-amd64@freebsd.org, freebsd-mobile@freebsd.org Message-ID: <20040225161302.GB91049@chaos.fxp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline X-Mailer: socket() Subject: FreeBSD vs eMachines M6805 part II X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 16:13:04 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (crossposting to -amd64 and -mobile, please reply to either as appropriate. I'm not on -mobile so please include me in replies) I broke down last week and picked up an AMD Athlon 64-based eMachines M6805 Laptop. Overall I am quite happy with it. Under FreeBSD 5.2.1RC1 (i386) everything is supported except the internal winmodem and internal Broadcom 54g-based wireless adapter. Supported hardware on the laptop: Athlon 64 3000+, 512M RAM, 60G HD, CDRW/DVD-ROM, USB, Firewire, CF/Memory stick reader, Rhine II ethernet, 15.5" display with a ATI Radeon 9600 (requires XFree 3.99.xx). Very fast and quite affordable ($1300 after rebates from the local Best Buy). In order to get the ethernet controller and USB working I had to disable APIC support (same under Linux). ACPI seems to work fine under FreeBSD but Linux does not like the PCI handling and requires 'pci=3Dnoacpi'. So far I have had no luck getting FreeBSD 5.2.1-RC1 amd64 to boot on the laptop. The loader loads the kernel and displays the menu but upon before any messages from the kernel have shown on the console the machine locks. Same for NetBSD amd64. Linux amd64 works as well as FreeBSD i386 though. More info, including dmesg and pciconf info, can be found at http://www.fxp.org/jedgar/amd64/ Any help on getting FreeBSD amd64 supported would be greatly appreciated. --=20 Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: FreeBSD: The Power To Serve iD8DBQFAPMmOObaG4P6BelARAj8BAJ9w1yGaXUX9BTB5EP9rTst5jwMDCACffUuD 9dfQ9tOWH9OsBqj6JT/x8CA= =wvBH -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 08:44:23 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE5E016A4CE for ; Wed, 25 Feb 2004 08:44:23 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B90BF43D2D for ; Wed, 25 Feb 2004 08:44:23 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PGiNOJ006333 for ; Wed, 25 Feb 2004 08:44:23 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PGiMsP006332 for freebsd-amd64@freebsd.org; Wed, 25 Feb 2004 08:44:22 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 08:44:22 -0800 From: "David O'Brien" To: freebsd-amd64@freebsd.org Message-ID: <20040225164422.GA6194@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Broken(missing) packages required for release X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 16:44:24 -0000 Hi all, These packages are required for 5.2.1-RELEASE, but don't build: emacs-21.3.tbz freebsd-update-1.4.tbz libgmp-4.1.2_2.tbz librep-0.16.2_3.tbz rep-gtk2-0.17_2,1.tbz sawfish2-1.3_4,2.tbz Anyone with some time on their hands could contribute a lot to 5.3-RELEASE by ensuring that these packages build. The complete list of "must have" packages is generated by $ cd /usr/ports $ cvs -qR up -PdA $ cd /usr/src/release/scripts $ print-cdrom-packages.sh 1 -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 09:06:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 307A716A4CE for ; Wed, 25 Feb 2004 09:06:03 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B32443D3F for ; Wed, 25 Feb 2004 09:06:02 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by pandora.cs.kun.nl (8.12.10/3.64) with ESMTP id i1PH61UY020324 for ; Wed, 25 Feb 2004 18:06:01 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Wed, 25 Feb 2004 18:05:53 +0100 User-Agent: KMail/1.6.51 References: <20040225164422.GA6194@dragon.nuxi.com> In-Reply-To: <20040225164422.GA6194@dragon.nuxi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402251806.00964.adridg@cs.kun.nl> Subject: Re: Broken(missing) packages required for release X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 17:06:03 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 25 February 2004 17:44, David O'Brien wrote: > emacs-21.3.tbz Ugh, LISP. James had patches on this list a ways back that apparently helpe= d=20 him build it. > libgmp-4.1.2_2.tbz I'm on this one. > librep-0.16.2_3.tbz > rep-gtk2-0.17_2,1.tbz > sawfish2-1.3_4,2.tbz Ugh, LISP. The maxim "not all the world's a VAX" never really got through t= o=20 them. I suppose the main problem here is librep, since it's the LISP bit an= d=20 the requirement for all the rest. =2D --=20 pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot Would you like a freem? =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAPNX4dqzuAf6io/4RAlHcAJ43OPEJ1HMerpXd4lGUc7GdVu3r0ACdEpud =46jFbt7rrWWA/lnqJKj9nozs=3D =3DMVon =2D----END PGP SIGNATURE----- From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 09:28:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E4516A4CE for ; Wed, 25 Feb 2004 09:28:14 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832EC43D2D for ; Wed, 25 Feb 2004 09:28:13 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by pandora.cs.kun.nl (8.12.10/3.64) with ESMTP id i1PHSCUY022486 for ; Wed, 25 Feb 2004 18:28:12 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Wed, 25 Feb 2004 18:28:06 +0100 User-Agent: KMail/1.6.51 References: <20040225164422.GA6194@dragon.nuxi.com> In-Reply-To: <20040225164422.GA6194@dragon.nuxi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402251828.12284.adridg@cs.kun.nl> Subject: Re: Broken(missing) packages required for release X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 17:28:14 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 25 February 2004 17:44, David O'Brien wrote: > libgmp-4.1.2_2.tbz Perhaps you can be a little more specific? I hate looking for bento logs=20 (well, hunting down the URL). It builds for me here, but that's with=20 CFLAGS=3D-g in make.conf.=20 =2D --=20 pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot Would you like a freem? =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAPNsrdqzuAf6io/4RAoesAJsEEGKjUWYK8/Mr/MF9Tb6SehRsCQCcDDBw mRYAo552VxtV+jQicLNiCiY=3D =3DxIxC =2D----END PGP SIGNATURE----- From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 09:32:33 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FC1C16A4CE for ; Wed, 25 Feb 2004 09:32:33 -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 1E7DB43D1F for ; Wed, 25 Feb 2004 09:32:33 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.10/8.12.10) with ESMTP id i1PHWWOE058153 for ; Wed, 25 Feb 2004 09:32:32 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.10/8.12.10/Submit) id i1PHWWEC058152 for freebsd-amd64@freebsd.org; Wed, 25 Feb 2004 09:32:32 -0800 (PST) (envelope-from marcel) Date: Wed, 25 Feb 2004 09:32:32 -0800 From: Marcel Moolenaar To: freebsd-amd64@freebsd.org Message-ID: <20040225173232.GB58071@ns1.xcllnt.net> References: <20040225164422.GA6194@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040225164422.GA6194@dragon.nuxi.com> User-Agent: Mutt/1.5.5.1i Subject: Re: Broken(missing) packages required for release X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 17:32:33 -0000 On Wed, Feb 25, 2004 at 08:44:22AM -0800, David O'Brien wrote: > > These packages are required for 5.2.1-RELEASE, but don't build: > > freebsd-update-1.4.tbz *snip* The port is marked i386 only, but it builds on ia64 just fine (I too noticed this while getting the 5.2.1-RELEASE packages, so I gave it a try). I think we can just drop the ONLY_FOR_ARCH in the Makefile. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 10:28:18 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BB3316A4CE for ; Wed, 25 Feb 2004 10:28:18 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2594543D2D for ; Wed, 25 Feb 2004 10:28:18 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PISEOJ026228; Wed, 25 Feb 2004 10:28:14 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PISDCw026227; Wed, 25 Feb 2004 10:28:13 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 10:28:13 -0800 From: "David O'Brien" To: Brooks Davis Message-ID: <20040225182813.GE7567@dragon.nuxi.com> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040224215847.GC6356@Odin.AC.HMC.Edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Jem Matzan cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 18:28:18 -0000 On Tue, Feb 24, 2004 at 01:58:47PM -0800, Brooks Davis wrote: > > How about AMD64 being slower than i386 on the same hardware? By > > slower, I mean a buildworld -j4 took about 400 seconds longer in AMD64 > > mode. > > You can't usefully compare compile times when you are compiling for > a different instructions set. The work involved is rairly the same > so the results are meaning less. If you could factor out the cost of > building the native bootstrap tools since that isn't the same job on > each machine, the speed of a cross buildworld would be an intresting > test. For comparing i386 and amd64, I'd probably build an alpha or > sparc64 world so the target would be entierly different. While generally true (everyone used to compare i386 & Alpha); the 80% of the amd64 instruction set is the i386 instruction set, and most of the code generation code is shared between the two. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 10:30:01 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D92916A4CE for ; Wed, 25 Feb 2004 10:30:01 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E44BE43D45 for ; Wed, 25 Feb 2004 10:30:00 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PIU0OJ026381; Wed, 25 Feb 2004 10:30:00 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PITxTQ026380; Wed, 25 Feb 2004 10:29:59 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 10:29:59 -0800 From: "David O'Brien" To: Jem Matzan Message-ID: <20040225182959.GF7567@dragon.nuxi.com> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040224215847.GC6356@Odin.AC.HMC.Edu> <403BCA6B.2050908@thejemreport.com> <200402241736.55911.jhb@FreeBSD.org> <403BD508.7080307@thejemreport.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403BD508.7080307@thejemreport.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 18:30:01 -0000 On Tue, Feb 24, 2004 at 05:49:44PM -0500, Jem Matzan wrote: > Ah -- I wasn't considering all of the possibilities. It was the AMD64 > form i386 crossbuild that wasn't working for me (while actually trying > to turn a working i386 system into an AMD64 build -- it was the > installworld that failed and broke everything to hell. Now I remember). That is a TOTALLY different thing. Cross building works fine, installing the cross built bits on a 2nd machine is reported to work. Doing an in-place migration from 32-bit to 64-bit on an AMD64 isn't at all supported [at this time]. From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 10:32:37 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 518A816A4CF for ; Wed, 25 Feb 2004 10:32:37 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9D643D2D for ; Wed, 25 Feb 2004 10:32:36 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PIWZOJ026706; Wed, 25 Feb 2004 10:32:35 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PIWYGO026705; Wed, 25 Feb 2004 10:32:34 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 10:32:34 -0800 From: "David O'Brien" To: Kenneth Culver Message-ID: <20040225183234.GG7567@dragon.nuxi.com> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Jem Matzan cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-amd64@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 18:32:37 -0000 On Wed, Feb 25, 2004 at 11:07:54AM -0500, Kenneth Culver wrote: > The buildworld problem could just be because it takes longer for the > compiler to > generate amd64 code. In fact, I'm almost willing to bet that's the case > since > amd64 has 2x the GPR's that x86 does. It's likely that it's harder to > optimize > for it. Does anyone who knows compilers care to comment? s/harder/slower/ It is defineately easier to optimize for amd64 because if its increased # of registers. But I'm not sure even "slower" is a valid claim -- on the i386 the compiler has to do a lot of time figuring out the best way to do the spill code (when, where). -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 10:42:17 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0909216A4CE; Wed, 25 Feb 2004 10:42:17 -0800 (PST) Received: from mailhub.sweetdreamsracing.biz (mailhub.sweetdreamsracing.biz [66.92.171.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB93F43D2F; Wed, 25 Feb 2004 10:42:16 -0800 (PST) (envelope-from culverk@sweetdreamsracing.biz) Received: by mailhub.sweetdreamsracing.biz (Postfix, from userid 80) id A09152D4; Wed, 25 Feb 2004 13:50:35 -0500 (EST) Received: from 141.156.69.109 ([141.156.69.109]) by www.sweetdreamsracing.biz (Horde) with HTTP for ; Wed, 25 Feb 2004 13:50:35 -0500 Message-ID: <20040225135035.v66800cwkgw08wwc@www.sweetdreamsracing.biz> Date: Wed, 25 Feb 2004 13:50:35 -0500 From: Kenneth Culver To: freebsd-amd64@FreeBSD.org, David O'Brien References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> <20040225183234.GG7567@dragon.nuxi.com> In-Reply-To: <20040225183234.GG7567@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs cc: Jem Matzan cc: "'freebsd-amd64@FreeBSD.org'" Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 18:42:17 -0000 Quoting David O'Brien : > On Wed, Feb 25, 2004 at 11:07:54AM -0500, Kenneth Culver wrote: >> The buildworld problem could just be because it takes longer for the >> compiler to >> generate amd64 code. In fact, I'm almost willing to bet that's the >> case since >> amd64 has 2x the GPR's that x86 does. It's likely that it's harder >> to optimize >> for it. Does anyone who knows compilers care to comment? > > s/harder/slower/ > > It is defineately easier to optimize for amd64 because if its increased # > of registers. But I'm not sure even "slower" is a valid claim -- on the > i386 the compiler has to do a lot of time figuring out the best way to do > the spill code (when, where). > > -- > -- David (obrien@FreeBSD.org) Ok well maybe not with amd64, but I thought that when you add registers it can be harder/slower/whatever to optimize for since there are many more ways to do so. Like on PowerPC or Alpha or whatever there are a LOT more GPR's than there are on even Athlon64... I guess only having 2x the GPR's doesn't make a whole lot of difference... but it still wouldn't surprise me if the gcc people didn't have all the kinks worked out yet. Ken From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 10:45:21 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14EBE16A4CE for ; Wed, 25 Feb 2004 10:45:21 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id F05B043D31 for ; Wed, 25 Feb 2004 10:45:20 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i1PIjFKH012082; Wed, 25 Feb 2004 10:45:15 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i1PIjEDZ012081; Wed, 25 Feb 2004 10:45:14 -0800 Date: Wed, 25 Feb 2004 10:45:14 -0800 From: Brooks Davis To: freebsd-amd64@freebsd.org Message-ID: <20040225184512.GA8620@Odin.AC.HMC.Edu> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> <20040225183234.GG7567@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20040225183234.GG7567@dragon.nuxi.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: Jem Matzan Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 18:45:21 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2004 at 10:32:34AM -0800, David O'Brien wrote: > On Wed, Feb 25, 2004 at 11:07:54AM -0500, Kenneth Culver wrote: > > The buildworld problem could just be because it takes longer for the=20 > > compiler to > > generate amd64 code. In fact, I'm almost willing to bet that's the case= =20 > > since > > amd64 has 2x the GPR's that x86 does. It's likely that it's harder to= =20 > > optimize > > for it. Does anyone who knows compilers care to comment? >=20 > s/harder/slower/ >=20 > It is defineately easier to optimize for amd64 because if its increased # > of registers. But I'm not sure even "slower" is a valid claim -- on the > i386 the compiler has to do a lot of time figuring out the best way to do > the spill code (when, where). The other big thing with gcc for amd64 is that we're still more in the "run correctly" then the the "run fast" stage in terms of the development cycle. With a compiler, "produces fast/correct code" beats "run fast" any day. The code generator has been widly used for less then a year. Compared to the life history of the i386 code generator that's pretty short and the user base is still small relative to the installed base of i386 machines. Even if generating amd64 code is easier then generating i386 code, it's probably still a bit early to expect the compiler to do it quickly. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAPO03XY6L6fI4GtQRAu/iAJ92TV4ak0qdux3663E1zUu4oK36FwCeJQhb BUupL+Nr7R0ZHttVjtXv1Xs= =nlnH -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 10:54:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D99016A4CE for ; Wed, 25 Feb 2004 10:54:59 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6BFC43D1F for ; Wed, 25 Feb 2004 10:54:58 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PIsvOJ045940; Wed, 25 Feb 2004 10:54:57 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PIsqtF044990; Wed, 25 Feb 2004 10:54:52 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 10:54:52 -0800 From: "David O'Brien" To: Brooks Davis Message-ID: <20040225185452.GH7567@dragon.nuxi.com> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> <20040225183234.GG7567@dragon.nuxi.com> <20040225184512.GA8620@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040225184512.GA8620@Odin.AC.HMC.Edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Jem Matzan cc: freebsd-amd64@freebsd.org Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 18:54:59 -0000 On Wed, Feb 25, 2004 at 10:45:14AM -0800, Brooks Davis wrote: > The other big thing with gcc for amd64 is that we're still more in > the "run correctly" then the the "run fast" stage in terms of the > development cycle. With a compiler, "produces fast/correct code" beats > "run fast" any day. The code generator has been widly used for less > then a year. Compared to the life history of the i386 code generator > that's pretty short and the user base is still small relative to the > installed base of i386 machines. Even if generating amd64 code is > easier then generating i386 code, it's probably still a bit early to > expect the compiler to do it quickly. Not true -- AMD has spent more effort making GCC 3.3 (well the 3.3 hammer_branch) generate faster code than anyone has for any other architecture to date. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 10:58:23 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 988D516A4CE for ; Wed, 25 Feb 2004 10:58:23 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4407243D2F for ; Wed, 25 Feb 2004 10:58:23 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PIwHOJ069296; Wed, 25 Feb 2004 10:58:18 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PIwGxf069204; Wed, 25 Feb 2004 10:58:16 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 10:58:16 -0800 From: "David O'Brien" To: Brooks Davis Message-ID: <20040225185816.GI7567@dragon.nuxi.com> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> <20040225183234.GG7567@dragon.nuxi.com> <20040225184512.GA8620@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040225184512.GA8620@Odin.AC.HMC.Edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Jem Matzan cc: freebsd-amd64@freebsd.org Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 18:58:23 -0000 On Wed, Feb 25, 2004 at 10:45:14AM -0800, Brooks Davis wrote: > installed base of i386 machines. Even if generating amd64 code is > easier then generating i386 code, it's probably still a bit early to > expect the compiler to do it quickly. Oh, sorry, minor mis-read. No one for any platform spends any time trying to make GCC compile faster -- notice the compile speeds of GCC 2.7, 2.95, 3.0, 3.1, 3.2, 3.3[*]... each version *compiles* slower than the previous version. It is the quality and level of optimized code *produced* that any one spends major time on. No real effort has been spent making the i386 code generator run fast. [*] finally for GCC 3.4, compile time speed is being looked at to try to fix some of the really badly implimented algorthums used in GCC for its running (not generated code). But this is an architecturally neutral effort. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 11:00:56 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3446116A4CE for ; Wed, 25 Feb 2004 11:00:56 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9728543D31 for ; Wed, 25 Feb 2004 11:00:55 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PJ0sOJ085482; Wed, 25 Feb 2004 11:00:54 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PJ0qGO085330; Wed, 25 Feb 2004 11:00:52 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 11:00:52 -0800 From: "David O'Brien" To: Kenneth Culver Message-ID: <20040225190052.GJ7567@dragon.nuxi.com> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> <20040225183234.GG7567@dragon.nuxi.com> <20040225135035.v66800cwkgw08wwc@www.sweetdreamsracing.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040225135035.v66800cwkgw08wwc@www.sweetdreamsracing.biz> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Jem Matzan cc: freebsd-amd64@FreeBSD.org Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 19:00:56 -0000 On Wed, Feb 25, 2004 at 01:50:35PM -0500, Kenneth Culver wrote: > Ok well maybe not with amd64, but I thought that when you add registers ^^^^^^^ This is the key word here -- "thought". No one has done any real analsys and thus we can't say jack. While at first thought compiling for a large number of GPR's could be more time consuming; I think there are other phases of code generation where the process is slower due to lack of a large number of GPR's. > Like on PowerPC or Alpha or whatever there are a LOT more GPR's than > there are on even Athlon64... I guess only having 2x the GPR's doesn't > make a whole lot of difference... PowerPC and Alpha are also RISC and have other scheduling issues for the code generator to handle. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 11:13:41 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71B5116A4CE; Wed, 25 Feb 2004 11:13:41 -0800 (PST) Received: from mailhub.sweetdreamsracing.biz (mailhub.sweetdreamsracing.biz [66.92.171.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4357143D2D; Wed, 25 Feb 2004 11:13:41 -0800 (PST) (envelope-from culverk@sweetdreamsracing.biz) Received: by mailhub.sweetdreamsracing.biz (Postfix, from userid 80) id D00E42D1; Wed, 25 Feb 2004 14:22:00 -0500 (EST) Received: from 141.156.69.109 ([141.156.69.109]) by www.sweetdreamsracing.biz (Horde) with HTTP for ; Wed, 25 Feb 2004 14:22:00 -0500 Message-ID: <20040225142200.4bysswc44g0csss0@www.sweetdreamsracing.biz> Date: Wed, 25 Feb 2004 14:22:00 -0500 From: Kenneth Culver To: obrien@FreeBSD.org References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> <20040225183234.GG7567@dragon.nuxi.com> <20040225135035.v66800cwkgw08wwc@www.sweetdreamsracing.biz> <20040225190052.GJ7567@dragon.nuxi.com> In-Reply-To: <20040225190052.GJ7567@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs cc: Jem Matzan cc: freebsd-amd64@FreeBSD.org Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 19:13:41 -0000 Quoting David O'Brien : > On Wed, Feb 25, 2004 at 01:50:35PM -0500, Kenneth Culver wrote: >> Ok well maybe not with amd64, but I thought that when you add registers > ^^^^^^^ > > This is the key word here -- "thought". No one has done any real analsys > and thus we can't say jack. While at first thought compiling for a large > number of GPR's could be more time consuming; I think there are other > phases of code generation where the process is slower due to lack of a > large number of GPR's. Fair enough. > >> Like on PowerPC or Alpha or whatever there are a LOT more GPR's than >> there are on even Athlon64... I guess only having 2x the GPR's doesn't >> make a whole lot of difference... > > PowerPC and Alpha are also RISC and have other scheduling issues for the > code generator to handle. > I knew they were RISC, but I didn't know that there were that many other issues in addition to just the GPR's, or I thought that the issues stemmed from having more GPR's. Anyway, Thanks for the info. Ken From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 13:01:12 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDA7B16A4CE for ; Wed, 25 Feb 2004 13:01:12 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id C884C43D3F for ; Wed, 25 Feb 2004 13:01:11 -0800 (PST) (envelope-from jlfenton@citlink.net) Received: (qmail 32321 invoked from network); 25 Feb 2004 20:33:04 -0000 Received: from unknown (HELO citlink.net) ([67.136.108.212]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 25 Feb 2004 20:33:04 -0000 Message-ID: <403D067F.7050905@citlink.net> Date: Wed, 25 Feb 2004 13:33:03 -0700 From: Joseph Fenton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <20040225191344.ED82816A4D4@hub.freebsd.org> In-Reply-To: <20040225191344.ED82816A4D4@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: x86-64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 21:01:13 -0000 > Has anyone evaluated running FreeBSD with Intel's > x86-64 extensions (which appear to be a copy of AMD's?) It's much too soon for that. Just a few days ago at the IDF, Intel pointed at a box and claimed it had an x86-64 compatible chip in it. Noone was allowed to check it and nothing was demonstrated on it. Intel says it will be months before chips are available. Don't look for anyone other than major Intel distributors like Dell to even have prototype chips until summer. I have downloaded Intels manuals on the chip and it is identical to AMD64 with the addition of the Prescott New Instructions (mostly SSE3). There should be no reason why ia-32e (what Intel calls it) cannot run FreeBSD. Microsoft claims XP 64-bit Edition works on it. They probably ran it on the box that Intel had at IDF. Oh, there was ONE difference between AMD64 and ia-32e: the No Execute bit in AMD64 is not in ia-32e (yet). So if FreeBSD is using this bit, it will be ineffective on ia-32e based systems... unless Intel adds it between now and when the chip is actually available. From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 14:54:26 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F1B016A4CE; Wed, 25 Feb 2004 14:54:26 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8532343D2D; Wed, 25 Feb 2004 14:54:26 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:smmsp@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i1PMlrMD029377; Wed, 25 Feb 2004 14:54:19 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i1PJ0926014736; Wed, 25 Feb 2004 11:00:09 -0800 Date: Wed, 25 Feb 2004 11:00:09 -0800 From: Brooks Davis To: "David O'Brien" Message-ID: <20040225190004.GB8620@Odin.AC.HMC.Edu> References: <1077658664.92943.15.camel@.rochester.rr.com> <20040225110754.hcogcccokg84k44k@www.sweetdreamsracing.biz> <20040225183234.GG7567@dragon.nuxi.com> <20040225184512.GA8620@Odin.AC.HMC.Edu> <20040225185452.GH7567@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yEPQxsgoJgBvi8ip" Content-Disposition: inline In-Reply-To: <20040225185452.GH7567@dragon.nuxi.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: Jem Matzan cc: freebsd-amd64@FreeBSD.org Subject: Re: Performance comparison, ULE vs 4BSD and AMD64 vs i386 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 22:54:26 -0000 --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2004 at 10:54:52AM -0800, David O'Brien wrote: > On Wed, Feb 25, 2004 at 10:45:14AM -0800, Brooks Davis wrote: > > The other big thing with gcc for amd64 is that we're still more in > > the "run correctly" then the the "run fast" stage in terms of the > > development cycle. With a compiler, "produces fast/correct code" beats > > "run fast" any day. The code generator has been widly used for less > > then a year. Compared to the life history of the i386 code generator > > that's pretty short and the user base is still small relative to the > > installed base of i386 machines. Even if generating amd64 code is > > easier then generating i386 code, it's probably still a bit early to > > expect the compiler to do it quickly. >=20 > Not true -- AMD has spent more effort making GCC 3.3 (well the 3.3 > hammer_branch) generate faster code than anyone has for any other > architecture to date. I did not intend to suggest that gcc generates slow code. I intended to point out that it's still early to expect that it will generate that code exceptionally quickly. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --yEPQxsgoJgBvi8ip Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAPPCyXY6L6fI4GtQRAv47AJ0TsefhRqL9RwYq8zZ/56RKSLU1mQCbBDxO MtXa8Eg/8PXW8rwO7KCPMEY= =m0LQ -----END PGP SIGNATURE----- --yEPQxsgoJgBvi8ip-- From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 15:18:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB5BF16A4CE; Wed, 25 Feb 2004 15:18:14 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ADB643D2D; Wed, 25 Feb 2004 15:18:14 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D21B27303A; Wed, 25 Feb 2004 18:18:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040225231813.D21B27303A@freebsd-current.sentex.ca> Date: Wed, 25 Feb 2004 18:18:13 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 23:18:15 -0000 TB --- 2004-02-25 22:21:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-25 22:21:32 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-25 22:21:32 - checking out the source tree TB --- 2004-02-25 22:21:32 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-25 22:21:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-25 22:25:13 - building world TB --- 2004-02-25 22:25:13 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-25 22:25:13 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-25 23:11:53 - building generic kernel TB --- 2004-02-25 23:11:53 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-25 23:11:53 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Feb 25 23:11:54 GMT 2004 >>> Kernel build for GENERIC completed on Wed Feb 25 23:18:11 GMT 2004 TB --- 2004-02-25 23:18:11 - generating LINT kernel config TB --- 2004-02-25 23:18:11 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-25 23:18:11 - /usr/bin/make -B LINT TB --- 2004-02-25 23:18:11 - building LINT kernel TB --- 2004-02-25 23:18:11 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-25 23:18:11 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 25 23:18:11 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-25 23:18:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-25 23:18:13 - ERROR: failed to build lint kernel TB --- 2004-02-25 23:18:13 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 17:09:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3591416A4CE for ; Wed, 25 Feb 2004 17:09:14 -0800 (PST) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2FC943D1D for ; Wed, 25 Feb 2004 17:09:12 -0800 (PST) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.9) with SMTP id i1Q17ceL096828 for ; Thu, 26 Feb 2004 02:07:39 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <0aa001c3fc05$24d80a00$471b3dd4@dual> From: "Willem Jan Withagen" To: Date: Thu, 26 Feb 2004 02:09:11 +0100 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 Subject: MSI K8T-MASTER X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 01:09:14 -0000 Hi, I might be about to order a MSI K8T MASTER FAR2. But the info page goes like: ==== On the K8T you can see the conductor paths of HyperTransport and V-Link With VIA's V-Map architecture makes bandwidths possible up to 1066 MB/s. The memory interface -- all four slots -- are directly connected to the first CPU socket. The second CPU accesses the memory through the HyperTransport of the first CPU. Theoretically eight slots (4 for each CPU like on the VIA K8W) would be possible but through the restrictions of the ATX form there is no room left for the additional four slots. The VIA K8T800 chipset is passively cooled, the VIA 8237 chip doesn't need any cooling. ==== Which does not really sound like the 2nd processor is going to be well connected to main memory??? And thus this sounds like an unbalanced architecture with respect to memory access times.... This this correct? or how does it work otherwise? --WjW From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 25 20:25:13 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3AE316A4CE for ; Wed, 25 Feb 2004 20:25:12 -0800 (PST) Received: from bragi.housing.ufl.edu (bragi.housing.ufl.edu [128.227.47.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D96043D2F for ; Wed, 25 Feb 2004 20:25:12 -0800 (PST) (envelope-from WillS@housing.ufl.edu) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Feb 2004 23:25:11 -0500 Message-ID: <0E972CEE334BFE4291CD07E056C76ED8CBBE6F@bragi.housing.ufl.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSI K8T-MASTER Thread-Index: AcP8BTlN5WZX5O+0RWiSRMpkU9/OdwAGaCiw From: "Will Saxon" To: "Willem Jan Withagen" , Subject: RE: MSI K8T-MASTER X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 04:25:13 -0000 >=20 > Which does not really sound like the 2nd processor is going=20 > to be well connected > to main memory??? > And thus this sounds like an unbalanced architecture with=20 > respect to memory > access times.... >=20 > This this correct? or how does it work otherwise? Yes it is correct. The Master2-FAR has a "4+0" configuration where one = processor must conduct memory transactions through the other. I don't know how much of a performance penalty this imposes. I'm sure it = depends on the application. I'm happy with mine, although I might buy a different board if I were to = purchase a new one today. -Will From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 03:18:12 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F8FF16A4CE; Thu, 26 Feb 2004 03:18:12 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D48343D1D; Thu, 26 Feb 2004 03:18:12 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7CD937303A; Thu, 26 Feb 2004 06:18:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040226111811.7CD937303A@freebsd-current.sentex.ca> Date: Thu, 26 Feb 2004 06:18:11 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 11:18:12 -0000 TB --- 2004-02-26 10:21:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-26 10:21:30 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-26 10:21:30 - checking out the source tree TB --- 2004-02-26 10:21:30 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-26 10:21:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-26 10:25:14 - building world TB --- 2004-02-26 10:25:14 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-26 10:25:14 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-26 11:11:52 - building generic kernel TB --- 2004-02-26 11:11:52 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-26 11:11:52 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 26 11:11:52 GMT 2004 >>> Kernel build for GENERIC completed on Thu Feb 26 11:18:10 GMT 2004 TB --- 2004-02-26 11:18:10 - generating LINT kernel config TB --- 2004-02-26 11:18:10 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-26 11:18:10 - /usr/bin/make -B LINT TB --- 2004-02-26 11:18:10 - building LINT kernel TB --- 2004-02-26 11:18:10 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-26 11:18:10 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 26 11:18:10 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-26 11:18:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-26 11:18:11 - ERROR: failed to build lint kernel TB --- 2004-02-26 11:18:11 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 10:36:31 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFE6416A4CE; Thu, 26 Feb 2004 10:36:31 -0800 (PST) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32D7D43D1D; Thu, 26 Feb 2004 10:36:31 -0800 (PST) (envelope-from mi+mx@aldan.algebra.com) Received: from 250-217.customer.cloud9.net (195-11.customer.cloud9.net [168.100.195.11])i1QIaNKE070699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Feb 2004 13:36:30 -0500 (EST) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (mteterin@localhost [127.0.0.1]) i1QIaHw3021423; Thu, 26 Feb 2004 13:36:18 -0500 (EST) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Murex N.A. To: amd64@freebsd.org, ia64@freebsd.org Date: Thu, 26 Feb 2004 13:36:17 -0500 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402261336.17247@misha-mx.virtual-estates.net> X-Scanned-By: MIMEDefang 2.39 Subject: kern/63155 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mi+mx@aldan.algebra.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:36:31 -0000 Hello! Can I call your attention to: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/63155 Would be nice to have the patch (with whatever improvements to it) committed before the next release. Thanks! -mi From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 14:55:28 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DD7216A4CE for ; Thu, 26 Feb 2004 14:55:28 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C96F43D2D for ; Thu, 26 Feb 2004 14:55:28 -0800 (PST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: from dibbler.crodrigues.org (h00609772adf0.ne.client2.attbi.com[66.31.45.197]) by comcast.net (rwcrmhc13) with ESMTP id <2004022622552701500o9kaie>; Thu, 26 Feb 2004 22:55:27 +0000 Received: from dibbler.crodrigues.org (localhost.crodrigues.org [127.0.0.1]) i1QMtWOI070042 for ; Thu, 26 Feb 2004 17:55:33 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.crodrigues.org (8.12.10/8.12.10/Submit) id i1QMtWhS070041 for freebsd-amd64@freebsd.org; Thu, 26 Feb 2004 17:55:32 -0500 (EST) (envelope-from rodrigc) Date: Thu, 26 Feb 2004 17:55:32 -0500 From: Craig Rodrigues To: freebsd-amd64@freebsd.org Message-ID: <20040226225532.GA70004@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Need help compiling Apache APR on AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 22:55:28 -0000 Hi, I am the port maintainer for devel/apr. I recently submitted some fixes to the Apache maintainers for AMD64. I need help testing these fixes, because I don't have AMD64 hardware. Can someone do the following: cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co -r APR_0_9_BRANCH apr cd apr ./buildconf ./configure gmake and tell me if this builds properly on AMD64? Thanks. -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 15:11:43 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3711116A4CE for ; Thu, 26 Feb 2004 15:11:43 -0800 (PST) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A4B43D2D for ; Thu, 26 Feb 2004 15:11:42 -0800 (PST) (envelope-from bob@immure.com) Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1])i1QNAufD033932; Thu, 26 Feb 2004 18:10:56 -0500 Received: (from root@localhost) by maul.immure.com (8.12.10/8.12.10) id i1QNAuPe080344; Thu, 26 Feb 2004 17:10:56 -0600 (CST) (envelope-from bob@immure.com) Received: from luke.immure.com (luke.immure.com [10.1.132.3]) by maul.immure.com (8.12.10/8.12.3) with ESMTP id i1QNAsxQ080301; Thu, 26 Feb 2004 17:10:54 -0600 (CST) (envelope-from bob@immure.com) Received: from luke.immure.com (localhost [127.0.0.1]) by luke.immure.com (8.12.10/8.12.10) with ESMTP id i1QNAssb033153; Thu, 26 Feb 2004 17:10:54 -0600 (CST) (envelope-from bob@luke.immure.com) Received: (from bob@localhost) by luke.immure.com (8.12.10/8.12.10/Submit) id i1QNAsJQ033152; Thu, 26 Feb 2004 17:10:54 -0600 (CST) (envelope-from bob) Date: Thu, 26 Feb 2004 17:10:54 -0600 From: Bob Willcox To: Craig Rodrigues Message-ID: <20040226231054.GP25044@luke.immure.com> References: <20040226225532.GA70004@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040226225532.GA70004@crodrigues.org> User-Agent: Mutt/1.5.6i X-scanner: scanned by Inflex 1.0.12.3 on maul.immure.com cc: freebsd-amd64@freebsd.org Subject: Re: Need help compiling Apache APR on AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bob Willcox List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 23:11:43 -0000 On Thu, Feb 26, 2004 at 05:55:32PM -0500, Craig Rodrigues wrote: > Hi, > > I am the port maintainer for devel/apr. > > I recently submitted some fixes to the Apache maintainers > for AMD64. I need help testing these fixes, because > I don't have AMD64 hardware. > > Can someone do the following: > > cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co -r APR_0_9_BRANCH apr > > cd apr > ./buildconf > ./configure > gmake > > > and tell me if this builds properly on AMD64? I was able to build this on my system, though I can't really test it since I don't run apache as a rule. My system is a just installed 5.2.1 release: # uname -a FreeBSD qui-gon.immure.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Tue Feb 24 23:14:55 GMT 2004 root@quynh.NUXI.org:/usr/ obj/usr/src/sys/GENERIC amd64 Hope this helps, Bob -- Bob Willcox Just remember, wherever you go, there you are. bob@immure.com -- Buckeroo Banzai Austin, TX From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 15:18:17 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3B3916A4CE; Thu, 26 Feb 2004 15:18:16 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id C232643D3F; Thu, 26 Feb 2004 15:18:16 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BBE0D7303A; Thu, 26 Feb 2004 18:18:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040226231815.BBE0D7303A@freebsd-current.sentex.ca> Date: Thu, 26 Feb 2004 18:18:15 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 23:18:17 -0000 TB --- 2004-02-26 22:21:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-26 22:21:36 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-26 22:21:36 - checking out the source tree TB --- 2004-02-26 22:21:36 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-26 22:21:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-26 22:25:20 - building world TB --- 2004-02-26 22:25:20 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-26 22:25:20 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-26 23:12:00 - building generic kernel TB --- 2004-02-26 23:12:00 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-26 23:12:00 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 26 23:12:00 GMT 2004 >>> Kernel build for GENERIC completed on Thu Feb 26 23:18:14 GMT 2004 TB --- 2004-02-26 23:18:14 - generating LINT kernel config TB --- 2004-02-26 23:18:14 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-26 23:18:14 - /usr/bin/make -B LINT TB --- 2004-02-26 23:18:14 - building LINT kernel TB --- 2004-02-26 23:18:14 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-26 23:18:14 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 26 23:18:15 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-26 23:18:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-26 23:18:15 - ERROR: failed to build lint kernel TB --- 2004-02-26 23:18:15 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 15:18:56 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C60C16A4CF for ; Thu, 26 Feb 2004 15:18:56 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FFAB43D3F for ; Thu, 26 Feb 2004 15:18:55 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by pandora.cs.kun.nl (8.12.10/3.64) with ESMTP id i1QNI8UY019663; Fri, 27 Feb 2004 00:18:08 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Fri, 27 Feb 2004 00:17:59 +0100 User-Agent: KMail/1.6.51 References: <20040226225532.GA70004@crodrigues.org> In-Reply-To: <20040226225532.GA70004@crodrigues.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402270018.07731.adridg@cs.kun.nl> Subject: Re: Need help compiling Apache APR on AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 23:18:56 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 February 2004 23:55, Craig Rodrigues wrote: > Can someone do the following: > cd apr > ./buildconf > ./configure > gmake > and tell me if this builds properly on AMD64? Naively? No. beans.ebn.kun.nl$./buildconf buildconf: checking installation... buildconf: autoconf version 2.53 (ok) buildconf: libtool version 1.5a (ok) libtoolize not found in path Less naively? No. I've got libtools 1.[345] installed, but no libtool.m4=20 anywhere, and buildconf complains about it. But Bob points out it builds fo= r=20 him, so it must come from somewhere. =2D --=20 pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot Would you like a freem? =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAPn6vdqzuAf6io/4RAt2SAJ0YBqKmzjSPz4ZRaJAfAn+a5QquNQCfV9eA CxaYLh3FRGbNS9oAApDJrxw=3D =3D2oro =2D----END PGP SIGNATURE----- From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 15:25:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F37016A4D0 for ; Thu, 26 Feb 2004 15:25:14 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3851B43D31 for ; Thu, 26 Feb 2004 15:25:14 -0800 (PST) (envelope-from bob@immure.com) Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1])i1QNPAe2243968; Thu, 26 Feb 2004 18:25:10 -0500 Received: (from root@localhost) by maul.immure.com (8.12.10/8.12.10) id i1QNPA24080914; Thu, 26 Feb 2004 17:25:10 -0600 (CST) (envelope-from bob@immure.com) Received: from luke.immure.com (luke.immure.com [10.1.132.3]) by maul.immure.com (8.12.10/8.12.3) with ESMTP id i1QNP9xQ080889; Thu, 26 Feb 2004 17:25:09 -0600 (CST) (envelope-from bob@immure.com) Received: from luke.immure.com (localhost [127.0.0.1]) by luke.immure.com (8.12.10/8.12.10) with ESMTP id i1QNP8sb033408; Thu, 26 Feb 2004 17:25:08 -0600 (CST) (envelope-from bob@luke.immure.com) Received: (from bob@localhost) by luke.immure.com (8.12.10/8.12.10/Submit) id i1QNP8mX033407; Thu, 26 Feb 2004 17:25:08 -0600 (CST) (envelope-from bob) Date: Thu, 26 Feb 2004 17:25:08 -0600 From: Bob Willcox To: Adriaan de Groot Message-ID: <20040226232508.GQ25044@luke.immure.com> References: <20040226225532.GA70004@crodrigues.org> <200402270018.07731.adridg@cs.kun.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402270018.07731.adridg@cs.kun.nl> User-Agent: Mutt/1.5.6i X-scanner: scanned by Inflex 1.0.12.3 on maul.immure.com cc: freebsd-amd64@freebsd.org Subject: Re: Need help compiling Apache APR on AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bob Willcox List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 23:25:14 -0000 On Fri, Feb 27, 2004 at 12:17:59AM +0100, Adriaan de Groot wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 26 February 2004 23:55, Craig Rodrigues wrote: > > Can someone do the following: > > cd apr > > ./buildconf > > ./configure > > gmake > > and tell me if this builds properly on AMD64? > > Naively? No. > > beans.ebn.kun.nl$./buildconf > buildconf: checking installation... > buildconf: autoconf version 2.53 (ok) > buildconf: libtool version 1.5a (ok) > libtoolize not found in path > > Less naively? No. I've got libtools 1.[345] installed, but no libtool.m4 > anywhere, and buildconf complains about it. But Bob points out it builds for > him, so it must come from somewhere. I wound up creating a symlink for libtoolize to libtoolize14. As a matter of fact, I had to create a symlink for three libtool related files to get the buildconf step to run: in /usr/local/bin: lrwxr-xr-x 1 root wheel 9 Feb 26 17:01 libtool -> libtool14 lrwxr-xr-x 1 root wheel 12 Feb 26 17:02 libtoolize -> libtoolize14 and in /usr/local/share/aclocal: lrwxr-xr-x 1 root wheel 12 Feb 26 17:02 libtool.m4 -> libtool14.m4 Guess I should have mentioned this in my first reply. Bob > > - -- > pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot > Would you like a freem? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (FreeBSD) > > iD8DBQFAPn6vdqzuAf6io/4RAt2SAJ0YBqKmzjSPz4ZRaJAfAn+a5QquNQCfV9eA > CxaYLh3FRGbNS9oAApDJrxw= > =2oro > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" -- Bob Willcox Just remember, wherever you go, there you are. bob@immure.com -- Buckeroo Banzai Austin, TX From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 15:45:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 253DC16A4CE for ; Thu, 26 Feb 2004 15:45:59 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E5B743D2D for ; Thu, 26 Feb 2004 15:45:59 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i1QNjpKH019211; Thu, 26 Feb 2004 15:45:51 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i1QNjo5U019207; Thu, 26 Feb 2004 15:45:50 -0800 Date: Thu, 26 Feb 2004 15:45:49 -0800 From: Brooks Davis To: Craig Rodrigues Message-ID: <20040226234549.GB9203@Odin.AC.HMC.Edu> References: <20040226225532.GA70004@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <20040226225532.GA70004@crodrigues.org> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-amd64@freebsd.org Subject: Re: Need help compiling Apache APR on AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 23:45:59 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2004 at 05:55:32PM -0500, Craig Rodrigues wrote: > Hi, >=20 > I am the port maintainer for devel/apr. >=20 > I recently submitted some fixes to the Apache maintainers > for AMD64. I need help testing these fixes, because > I don't have AMD64 hardware. >=20 > Can someone do the following: >=20 > cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co -r APR_0_9_BRAN= CH apr >=20 > cd apr > ./buildconf > ./configure > gmake >=20 > and tell me if this builds properly on AMD64? It built here: FreeBSD brimstone 5.2-CURRENT FreeBSD 5.2-CURRENT #2: Wed Feb 18 09:43:30 P= ST 2004 -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAPoUsXY6L6fI4GtQRAlJXAKCSgxlGrIQvv1bhSqz+SfFHYlUgmQCeJHf9 8fx06yzrKz+76KBF0eJx6bg= =/kns -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 26 20:40:45 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3229F16A4CE for ; Thu, 26 Feb 2004 20:40:45 -0800 (PST) Received: from eterna.binary.net (eterna.binary.net [216.229.0.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B990843D2F for ; Thu, 26 Feb 2004 20:40:44 -0800 (PST) (envelope-from yura@binary.net) Received: from matrix.binary.net (matrix.binary.net [216.229.0.2]) by eterna.binary.net (Postfix) with ESMTP id CF7ACB45B5; Thu, 26 Feb 2004 22:40:43 -0600 (CST) Received: by matrix.binary.net (Postfix, from userid 100) id 76A16102822; Thu, 26 Feb 2004 22:40:43 -0600 (CST) Date: Thu, 26 Feb 2004 22:40:43 -0600 From: Yura Socolov To: Craig Rodrigues Message-ID: <20040227044043.GA95175@binary.net> References: <20040226225532.GA70004@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040226225532.GA70004@crodrigues.org> User-Agent: Mutt/1.4.2i cc: freebsd-amd64@freebsd.org Subject: Re: Need help compiling Apache APR on AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 04:40:45 -0000 On Thu, Feb 26, 2004 at 05:55:32PM -0500, Craig Rodrigues wrote: > I recently submitted some fixes to the Apache maintainers > for AMD64. I need help testing these fixes, because > I don't have AMD64 hardware. I didn't have any problems with libtoolize, but it did break thusly: checking whether stripping libraries is possible... yes checking dynamic linker characteristics... freebsd5.2.1 ld.so configure: error: tag name "CXX" already exists The box is this: [23:31] [kussi:/usr/local/src/apr] uname -a FreeBSD kussi.31337.net 5.2.1-RC2 FreeBSD 5.2.1-RC2 #3: Sun Feb 22 13:37:29 EST 2004 yura@kussi.31337.net:/usr/obj/usr/src/sys/KUSSI amd64 See below for the full buildconf/configure log. HTH. -- yu [23:29] [kussi:/usr/local/src/apr] ./buildconf buildconf: checking installation... buildconf: autoconf version 2.53 (ok) buildconf: libtool version 1.5 (ok) Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `include/arch/unix/apr_private.h.in' is created Creating configure ... [23:30] [kussi:/usr/local/src/apr] ./configure checking build system type... x86_64-unknown-freebsd5.2.1 checking host system type... x86_64-unknown-freebsd5.2.1 checking target system type... x86_64-unknown-freebsd5.2.1 Configuring APR library Platform: x86_64-unknown-freebsd5.2.1 checking for working mkdir -p... yes APR Version: 0.9.5 checking for chosen layout... apr checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes Applying APR hints file rules for x86_64-unknown-freebsd5.2.1 setting enable_threads to "no" setting apr_lock_method to "USE_FLOCK_SERIALIZE" setting CPPFLAGS to "-D_REENTRANT -D_THREAD_SAFE" (Default will be unix) checking whether make sets ${MAKE}... yes checking how to run the C preprocessor... gcc -E checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether ln -s works... yes checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for rm... rm checking for as... as checking for cpp... cpp checking for ar... ar checking for AIX... no checking for library containing strerror... none required checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether system uses EBCDIC... no performing libtool configuration... checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 16384 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... (cached) ar checking for ranlib... (cached) ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... freebsd5.2.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... freebsd5.2.1 ld.so appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... freebsd5.2.1 ld.so configure: error: tag name "CXX" already exists [23:31] [kussi:/usr/local/src/apr] From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 03:18:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62F1116A4CE; Fri, 27 Feb 2004 03:18:03 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 337F643D2F; Fri, 27 Feb 2004 03:18:03 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6E9807303A; Fri, 27 Feb 2004 06:18:02 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040227111802.6E9807303A@freebsd-current.sentex.ca> Date: Fri, 27 Feb 2004 06:18:02 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 11:18:03 -0000 TB --- 2004-02-27 10:21:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-27 10:21:24 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-27 10:21:24 - checking out the source tree TB --- 2004-02-27 10:21:24 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-27 10:21:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-27 10:25:07 - building world TB --- 2004-02-27 10:25:07 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-27 10:25:07 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-27 11:11:44 - building generic kernel TB --- 2004-02-27 11:11:44 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-27 11:11:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Feb 27 11:11:44 GMT 2004 >>> Kernel build for GENERIC completed on Fri Feb 27 11:18:01 GMT 2004 TB --- 2004-02-27 11:18:01 - generating LINT kernel config TB --- 2004-02-27 11:18:01 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-27 11:18:01 - /usr/bin/make -B LINT TB --- 2004-02-27 11:18:01 - building LINT kernel TB --- 2004-02-27 11:18:01 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-27 11:18:01 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 27 11:18:01 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-27 11:18:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-27 11:18:02 - ERROR: failed to build lint kernel TB --- 2004-02-27 11:18:02 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 04:34:15 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D050A16A4CF; Fri, 27 Feb 2004 04:34:15 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8731E43D2F; Fri, 27 Feb 2004 04:34:15 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id BDBC25309; Fri, 27 Feb 2004 13:34:14 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 0F3075308; Fri, 27 Feb 2004 13:34:10 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id DA02B33C68; Fri, 27 Feb 2004 13:34:09 +0100 (CET) To: FreeBSD Tinderbox References: <20040227111802.6E9807303A@freebsd-current.sentex.ca> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 27 Feb 2004 13:34:09 +0100 In-Reply-To: <20040227111802.6E9807303A@freebsd-current.sentex.ca> (FreeBSD Tinderbox's message of "Fri, 27 Feb 2004 06:18:02 -0500 (EST)") 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: amd64@freebsd.org cc: current@freebsd.org Subject: Re: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 12:34:16 -0000 FreeBSD Tinderbox writes: > FYI: static unit limits for vcoda are set: NVCODA=3D4 > config: Error: device "cy" is unknown > config: 1 errors > WARNING: kernel contains GPL contaminated ext2fs filesystem > *** Error code 1 Is somebody going to fix this? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 06:35:22 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6F9B16A4CE; Fri, 27 Feb 2004 06:35:22 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F174643D31; Fri, 27 Feb 2004 06:35:21 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.office.ipnet (heffalump.office.ipnet [10.71.1.80]) by tigra.ip.net.ua (8.12.10/8.12.9) with ESMTP id i1REbQ7I063303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2004 16:37:27 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.office.ipnet (8.12.11/8.12.11) id i1REZ9xQ002886; Fri, 27 Feb 2004 16:35:09 +0200 (EET) (envelope-from ru) Date: Fri, 27 Feb 2004 16:35:05 +0200 From: Ruslan Ermilov To: "David O'Brien" Message-ID: <20040227143505.GA2685@ip.net.ua> References: <20040227111802.6E9807303A@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: amd64@FreeBSD.org Subject: Re: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 14:35:23 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 27, 2004 at 01:34:09PM +0100, Dag-Erling Sm?rgrav wrote: > FreeBSD Tinderbox writes: > > FYI: static unit limits for vcoda are set: NVCODA=3D4 > > config: Error: device "cy" is unknown > > config: 1 errors > > WARNING: kernel contains GPL contaminated ext2fs filesystem > > *** Error code 1 >=20 > Is somebody going to fix this? >=20 David maybe, who brought it up recently to amd64/NOTES? According to Peter who moved "cy" into MD sys/conf/files.*, "pci/cy_pci.c is still MD, it needs i386/isa/cy.c for the core". So either David forgot to commit the cy(4) amd64 bits, or "cy" was added to amd64/NOTES by mistake. Cheers, --=20 Ruslan Ermilov FreeBSD committer ru@FreeBSD.org --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAP1WZUkv4P6juNwoRAnhTAJ4oSiwqRg/APe8vH4LibSbepZnfqACfb1qf rX95nfaaskKrYYNcJ3fQUaw= =tVoe -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 09:35:26 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44E9B16A4CE for ; Fri, 27 Feb 2004 09:35:26 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09EED43D39 for ; Fri, 27 Feb 2004 09:35:26 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id D779C5308; Fri, 27 Feb 2004 18:35:24 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 31122530C; Fri, 27 Feb 2004 18:35:20 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 118C033C71; Fri, 27 Feb 2004 18:35:20 +0100 (CET) To: Joseph Fenton References: <20040225191344.ED82816A4D4@hub.freebsd.org> <403D067F.7050905@citlink.net> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 27 Feb 2004 18:35:20 +0100 In-Reply-To: <403D067F.7050905@citlink.net> (Joseph Fenton's message of "Wed, 25 Feb 2004 13:33:03 -0700") 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-amd64@freebsd.org Subject: Re: x86-64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 17:35:26 -0000 Joseph Fenton writes: > It's much too soon for that. Just a few days ago at the > IDF, Intel pointed at a box and claimed it had an x86-64 > compatible chip in it. Noone was allowed to check it and > nothing was demonstrated on it. Heh, they probably had an Opteron in it ;) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 14:23:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32D5A16A4CE; Fri, 27 Feb 2004 14:23:03 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01D3C43D46; Fri, 27 Feb 2004 14:23:02 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id B274A2A8E7; Fri, 27 Feb 2004 14:23:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 71D792C1AC; Fri, 27 Feb 2004 14:23:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1RMN1ZR046240; Fri, 27 Feb 2004 14:23:01 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1RMN1iS046239; Fri, 27 Feb 2004 14:23:01 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Fri, 27 Feb 2004 14:23:01 -0800 User-Agent: KMail/1.6 References: <20040227111802.6E9807303A@freebsd-current.sentex.ca> <20040227143505.GA2685@ip.net.ua> In-Reply-To: <20040227143505.GA2685@ip.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402271423.01374.peter@wemm.org> cc: amd64@freebsd.org cc: Ruslan Ermilov Subject: Re: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 22:23:03 -0000 On Friday 27 February 2004 06:35 am, Ruslan Ermilov wrote: > On Fri, Feb 27, 2004 at 01:34:09PM +0100, Dag-Erling Sm?rgrav wrote: > > FreeBSD Tinderbox writes: > > > FYI: static unit limits for vcoda are set: NVCODA=4 > > > config: Error: device "cy" is unknown > > > config: 1 errors > > > WARNING: kernel contains GPL contaminated ext2fs filesystem > > > *** Error code 1 > > > > Is somebody going to fix this? > > David maybe, who brought it up recently to amd64/NOTES? > > According to Peter who moved "cy" into MD sys/conf/files.*, > "pci/cy_pci.c is still MD, it needs i386/isa/cy.c for the core". > So either David forgot to commit the cy(4) amd64 bits, or > "cy" was added to amd64/NOTES by mistake. Actually, David has utterly hosed amd64/conf/NOTES. He's spammed the working copy with a completely and utterly bogus version that he obviously hasn't tested even slightly. He's even added drivers back in that we don't support and never will! AARGH! -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 14:23:03 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32D5A16A4CE; Fri, 27 Feb 2004 14:23:03 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01D3C43D46; Fri, 27 Feb 2004 14:23:02 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id B274A2A8E7; Fri, 27 Feb 2004 14:23:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (unknown [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 71D792C1AC; Fri, 27 Feb 2004 14:23:02 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.10) with ESMTP id i1RMN1ZR046240; Fri, 27 Feb 2004 14:23:01 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.10/Submit) id i1RMN1iS046239; Fri, 27 Feb 2004 14:23:01 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Fri, 27 Feb 2004 14:23:01 -0800 User-Agent: KMail/1.6 References: <20040227111802.6E9807303A@freebsd-current.sentex.ca> <20040227143505.GA2685@ip.net.ua> In-Reply-To: <20040227143505.GA2685@ip.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402271423.01374.peter@wemm.org> cc: amd64@freebsd.org cc: Ruslan Ermilov Subject: Re: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 22:23:03 -0000 On Friday 27 February 2004 06:35 am, Ruslan Ermilov wrote: > On Fri, Feb 27, 2004 at 01:34:09PM +0100, Dag-Erling Sm?rgrav wrote: > > FreeBSD Tinderbox writes: > > > FYI: static unit limits for vcoda are set: NVCODA=4 > > > config: Error: device "cy" is unknown > > > config: 1 errors > > > WARNING: kernel contains GPL contaminated ext2fs filesystem > > > *** Error code 1 > > > > Is somebody going to fix this? > > David maybe, who brought it up recently to amd64/NOTES? > > According to Peter who moved "cy" into MD sys/conf/files.*, > "pci/cy_pci.c is still MD, it needs i386/isa/cy.c for the core". > So either David forgot to commit the cy(4) amd64 bits, or > "cy" was added to amd64/NOTES by mistake. Actually, David has utterly hosed amd64/conf/NOTES. He's spammed the working copy with a completely and utterly bogus version that he obviously hasn't tested even slightly. He's even added drivers back in that we don't support and never will! AARGH! -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 15:06:18 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E3E016A4CE; Fri, 27 Feb 2004 15:06:18 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 187AB43D1F; Fri, 27 Feb 2004 15:06:18 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 956147303A; Fri, 27 Feb 2004 18:06:17 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040227230617.956147303A@freebsd-current.sentex.ca> Date: Fri, 27 Feb 2004 18:06:17 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 23:06:18 -0000 TB --- 2004-02-27 22:09:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-27 22:09:28 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-27 22:09:28 - checking out the source tree TB --- 2004-02-27 22:09:28 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-27 22:09:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-27 22:13:13 - building world TB --- 2004-02-27 22:13:13 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-27 22:13:13 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-27 23:00:06 - building generic kernel TB --- 2004-02-27 23:00:06 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-27 23:00:06 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Feb 27 23:00:06 GMT 2004 >>> Kernel build for GENERIC completed on Fri Feb 27 23:06:16 GMT 2004 TB --- 2004-02-27 23:06:16 - generating LINT kernel config TB --- 2004-02-27 23:06:16 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-27 23:06:16 - /usr/bin/make -B LINT TB --- 2004-02-27 23:06:16 - building LINT kernel TB --- 2004-02-27 23:06:16 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-27 23:06:16 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 27 23:06:16 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-27 23:06:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-27 23:06:17 - ERROR: failed to build lint kernel TB --- 2004-02-27 23:06:17 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 15:56:34 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F43D16A4CE for ; Fri, 27 Feb 2004 15:56:34 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15A4B43D1F for ; Fri, 27 Feb 2004 15:56:33 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by pandora.cs.kun.nl (8.12.10/3.64) with ESMTP id i1RNuVUY029965 for ; Sat, 28 Feb 2004 00:56:31 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Sat, 28 Feb 2004 00:56:25 +0100 User-Agent: KMail/1.6.51 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_pk9PAH254Em1ye7" Message-Id: <200402280056.31231.adridg@cs.kun.nl> Subject: Lock order reversals X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 23:56:34 -0000 --Boundary-00=_pk9PAH254Em1ye7 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attached find the dump of a lock order reversal I found on my console just= =20 now. It might have happened while I was compiling and ripping CDs at the sa= me=20 time. Anyway .. is it useful to post these?They do suggest the _possibility= _=20 of deadlock. I also recently managed to panic my box with an, um, non-sleepable mutex=20 discombobulation. Forget what exactly, but it was while trying to mount a U= SB=20 pendrive. Next time ..=20 =2D --=20 pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot Would you like a freem? =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAP9kvdqzuAf6io/4RAndXAJ0aC5SBY2s7vSypHXFFGEBBtt5xQgCffM6u o+0jIBHEa2tIizAwOjAd/3Q=3D =3DS8AE =2D----END PGP SIGNATURE----- --Boundary-00=_pk9PAH254Em1ye7 Content-Type: text/plain; charset="us-ascii"; name="rev" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rev" lock order reversal 1st 0xffffff0003a929a0 vm object (vm object) @ /mnt/sys/CURRENT/src/sys/vm/swap _pager.c:1314 2nd 0xffffffff807dcca0 swap_pager swhash (swap_pager swhash) @ /mnt/sys/CURRENT /src/sys/vm/swap_pager.c:1822 3rd 0xffffff003e0e8700 vm object (vm object) @ /mnt/sys/CURRENT/src/sys/vm/uma_ core.c:886 Stack backtrace: backtrace() at backtrace+0x17 witness_checkorder() at witness_checkorder+0x678 _mtx_lock_flags() at _mtx_lock_flags+0x80 obj_alloc() at obj_alloc+0x41 slab_zalloc() at slab_zalloc+0xa2 uma_zone_slab() at uma_zone_slab+0xd5 uma_zalloc_internal() at uma_zalloc_internal+0x3c uma_zalloc_arg() at uma_zalloc_arg+0x3a6 swp_pager_meta_build() at swp_pager_meta_build+0x14b swap_pager_putpages() at swap_pager_putpages+0x2f3 default_pager_putpages() at default_pager_putpages+0xa vm_pageout_flush() at vm_pageout_flush+0x15e vm_pageout_clean() at vm_pageout_clean+0x292 vm_pageout_scan() at vm_pageout_scan+0x65f vm_pageout() at vm_pageout+0x377 fork_exit() at fork_exit+0xd9 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa9976d00, rbp = 0 --- --Boundary-00=_pk9PAH254Em1ye7-- From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 18:05:05 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8798216A4CE; Fri, 27 Feb 2004 18:05:05 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D45E43D1D; Fri, 27 Feb 2004 18:05:05 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1S251p9072715 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Feb 2004 20:05:01 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1S250o3072709; Fri, 27 Feb 2004 20:05:00 -0600 (CST) Date: Fri, 27 Feb 2004 20:05:00 -0600 (CST) Message-Id: <200402280205.i1S250o3072709@bigtex.jrv.org> From: James Van Artsdalen To: adridg@cs.kun.nl In-reply-to: <200402251806.00964.adridg@cs.kun.nl> (message from Adriaan de Groot on Wed, 25 Feb 2004 18:05:53 +0100) References: <20040225164422.GA6194@dragon.nuxi.com> <200402251806.00964.adridg@cs.kun.nl> cc: freebsd-amd64@freebsd.org Subject: Re: Broken(missing) packages required for release X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 02:05:05 -0000 > From: Adriaan de Groot > Date: Wed, 25 Feb 2004 18:05:53 +0100 > Ugh, LISP. James had patches on this list a ways back that apparently helped > him build it. That was to emacs21, and it was a hack. This is easier to use: it patches the ports "files" directory for emacs21, and then lets the normal port build process patch emacs itself in the usual way. It is however the same code and seems reliable for me. Dave: I'll volunteer for any of the emacs ports if you will tell me what results you'd like. --- editors/emacs21/files/patch-configure.in.orig Wed Nov 26 09:05:08 2003 +++ editors/emacs21/files/patch-configure.in Fri Feb 27 17:44:04 2004 @@ -1,6 +1,6 @@ ---- configure.in.orig Sun Mar 16 14:06:05 2003 -+++ configure.in Thu Nov 20 13:54:06 2003 -@@ -179,6 +179,17 @@ +--- configure.in.orig Sun Mar 16 16:06:05 2003 ++++ configure.in Fri Feb 27 17:16:25 2004 +@@ -179,6 +179,18 @@ machine='' opsys='' unported=no case "${canonical}" in @@ -10,6 +10,7 @@ + case "${canonical}" in + alpha*-*-freebsd*) machine=alpha ;; + ia64-*-freebsd*) machine=ia64 ;; ++ amd64-*-freebsd*) machine=amd64 ;; + i[3456]86-*-freebsd*) machine=intel386 ;; + sparc64-*-freebsd*) machine=sparc ;; + esac @@ -18,7 +19,7 @@ ## NetBSD ports *-*-netbsd* ) opsys=netbsd -@@ -1032,7 +1043,6 @@ +@@ -1032,7 +1044,6 @@ ;; *-sysv4.2uw* ) opsys=unixware; NON_GNU_CPP=/lib/cpp ;; *-386bsd* ) opsys=386bsd ;; @@ -26,7 +27,7 @@ *-nextstep* ) opsys=nextstep ;; ## Otherwise, we'll fall through to the generic opsys code at the bottom. esac -@@ -2050,6 +2060,7 @@ +@@ -2050,6 +2061,7 @@ # Solaris requires -lintl if you want strerror (which calls dgettext) # to return localized messages. AC_CHECK_LIB(intl, dgettext) --- editors/emacs21/files/patch-src:m:amd64.h.orig Fri Feb 27 17:42:11 2004 +++ editors/emacs21/files/patch-src:m:amd64.h Fri Feb 27 17:24:34 2004 @@ -0,0 +1,163 @@ +--- src/m/amd64.h.orig Fri Feb 27 17:14:38 2004 ++++ src/m/amd64.h Fri Feb 27 17:20:56 2004 +@@ -0,0 +1,160 @@ ++/* machine description file For the amd64 chip. ++ Copyright (C) 1994, 1997, 1999 Free Software Foundation, Inc. ++ ++This file is part of GNU Emacs. ++ ++GNU Emacs is free software; you can redistribute it and/or modify ++it under the terms of the GNU General Public License as published by ++the Free Software Foundation; either version 1, or (at your option) ++any later version. ++ ++GNU Emacs is distributed in the hope that it will be useful, ++but WITHOUT ANY WARRANTY; without even the implied warranty of ++MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ++GNU General Public License for more details. ++ ++You should have received a copy of the GNU General Public License ++along with GNU Emacs; see the file COPYING. If not, write to ++the Free Software Foundation, Inc., 59 Temple Place - Suite 330, ++Boston, MA 02111-1307, USA. */ ++ ++ ++/* The following line tells the configuration script what sort of ++ operating system this machine is likely to run. ++ USUAL-OPSYS="note" ++ ++NOTE-START ++Use -opsystem=freebsd ++NOTE-END ++ ++*/ ++ ++#define BITS_PER_LONG 64 ++#define BITS_PER_EMACS_INT 64 ++#ifndef _LP64 ++#define _LP64 ++#endif ++ ++/* Define WORDS_BIG_ENDIAN iff lowest-numbered byte in a word ++ is the most significant byte. */ ++ ++#undef WORDS_BIG_ENDIAN ++ ++/* Define NO_ARG_ARRAY if you cannot take the address of the first of a ++ * group of arguments and treat it as an array of the arguments. */ ++ ++#define NO_ARG_ARRAY ++ ++/* Now define a symbol for the cpu type, if your compiler ++ does not define it automatically: ++ Ones defined so far include vax, m68000, ns16000, pyramid, ++ orion, tahoe, APOLLO and many others */ ++ ++/* __amd64__ defined automatically */ ++ ++ ++/* Use type EMACS_INT rather than a union, to represent Lisp_Object */ ++/* This is desirable for most machines. */ ++ ++#define NO_UNION_TYPE ++ ++/* Define the type to use. */ ++#define EMACS_INT long ++#define EMACS_UINT unsigned long ++#define SPECIAL_EMACS_INT ++ ++/* Define EXPLICIT_SIGN_EXTEND if XINT must explicitly sign-extend ++ the 24-bit bit field into an int. In other words, if bit fields ++ are always unsigned. ++ ++ If you use NO_UNION_TYPE, this flag does not matter. */ ++ ++#undef EXPLICIT_SIGN_EXTEND ++ ++/* Data type of load average, as read out of kmem. */ ++ ++#define LOAD_AVE_TYPE long ++ ++/* Convert that into an integer that is 100 for a load average of 1.0 */ ++ ++#define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE) ++ ++/* Define C_ALLOCA if this machine does not support a true alloca ++ and the one written in C should be used instead. ++ Define HAVE_ALLOCA to say that the system provides a properly ++ working alloca function and it should be used. ++ Define neither one if an assembler-language alloca ++ in the file alloca.s should be used. */ ++ ++#define HAVE_ALLOCA ++ ++/* #define SYSTEM_MALLOC */ ++ ++#ifdef __ELF__ ++/* With ELF, make sure that all common symbols get allocated to in the ++ data section. Otherwise, the dump of temacs may miss variables in ++ the shared library that have been initialized. For example, with ++ GNU libc, __malloc_initialized would normally be resolved to the ++ shared library's .bss section, which is fatal. */ ++# ifdef __GNUC__ ++# define C_SWITCH_MACHINE -fno-common ++# else ++# error Sorry Charlie - must have gcc ++# endif ++#endif ++ ++#if defined(__OpenBSD__) ++#define ORDINARY_LINK ++#endif ++ ++#ifdef __ELF__ ++#undef UNEXEC ++#define UNEXEC unexelf.o ++#endif ++ ++#if defined (LINUX) && __GNU_LIBRARY__ - 0 < 6 ++/* This controls a conditional in main. */ ++#define LINUX_SBRK_BUG ++#endif ++ ++ ++#define PNTR_COMPARISON_TYPE unsigned long ++ ++/* On the 64 bit architecture, we can use 60 bits for addresses */ ++ ++#define VALBITS 60 ++ ++ ++/* This definition of MARKBIT is necessary because of the comparison of ++ ARRAY_MARK_FLAG and MARKBIT in an #if in lisp.h, which cpp doesn't like. */ ++ ++/* #define MARKBIT 0x8000000000000000L */ ++ ++ ++/* Define XINT and XUINT so that they can take arguments of type int */ ++ ++#define XINT(a) (((long) (a) << (BITS_PER_LONG - VALBITS)) >> (BITS_PER_LONG - VALBITS)) ++#define XUINT(a) ((long) (a) & VALMASK) ++ ++/* Define XPNTR to avoid or'ing with DATA_SEG_BITS */ ++ ++#define XPNTR(a) XUINT (a) ++ ++#ifndef NOT_C_CODE ++/* We need these because pointers are larger than the default ints. */ ++#if !defined(__NetBSD__) && !defined(__OpenBSD__) && !defined(__FreeBSD__) ++#include ++#endif ++#endif /* not NOT_C_CODE */ ++ ++#if defined (LINUX) || defined (__NetBSD__) || defined (__OpenBSD__) ++# define TEXT_END ({ extern int _etext; &_etext; }) ++# ifndef __ELF__ ++# define COFF ++# define DATA_END ({ extern int _EDATA; &_EDATA; }) ++# endif /* notdef __ELF__ */ ++#endif ++ ++#if (defined (__NetBSD__) || defined (__OpenBSD__)) && defined (__ELF__) ++#define HAVE_TEXT_START ++#endif --- editors/emacs21/files/patch-src:mem-limits.h.orig Fri Feb 27 17:42:22 2004 +++ editors/emacs21/files/patch-src:mem-limits.h Fri Feb 27 17:49:51 2004 @@ -0,0 +1,11 @@ +--- src/mem-limits.h.orig Wed Mar 8 12:49:46 2000 ++++ src/mem-limits.h Fri Feb 27 17:14:38 2004 +@@ -98,7 +98,7 @@ + static POINTER data_space_start; + + /* Number of bytes of writable memory we can expect to be able to get */ +-static unsigned long lim_data; ++static rlim_t lim_data; + + #ifdef NO_LIM_DATA + static void From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 19:41:00 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 867B916A4CE; Fri, 27 Feb 2004 19:41:00 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 218FC43D2D; Fri, 27 Feb 2004 19:41:00 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1S3exp9075628 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Feb 2004 21:40:59 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1S3exlM075625; Fri, 27 Feb 2004 21:40:59 -0600 (CST) Date: Fri, 27 Feb 2004 21:40:59 -0600 (CST) Message-Id: <200402280340.i1S3exlM075625@bigtex.jrv.org> From: James Van Artsdalen To: obrien@freebsd.org In-reply-to: <20040225164422.GA6194@dragon.nuxi.com> (obrien@freebsd.org) References: <20040225164422.GA6194@dragon.nuxi.com> cc: freebsd-amd64@freebsd.org Subject: Re: Broken(missing) packages required for release X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 03:41:00 -0000 > Date: Wed, 25 Feb 2004 08:44:22 -0800 > From: "David O'Brien" > > These packages are required for 5.2.1-RELEASE, but don't build: > > sawfish2-1.3_4,2.tbz > > Anyone with some time on their hands could contribute a lot to > 5.3-RELEASE by ensuring that these packages build. port x11-wm/sawfish2 just built for me. I had to update a bunch of things it depended on, and update still more packages those in turn relied on, but it does build. Unfortunately I'm not an X user. Maybe someone else can build it and see if it works? From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 27 19:56:50 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19DAB16A4CE; Fri, 27 Feb 2004 19:56:50 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id A847C43D1D; Fri, 27 Feb 2004 19:56:49 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id i1S3unp9076240 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Feb 2004 21:56:49 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id i1S3unHB076237; Fri, 27 Feb 2004 21:56:49 -0600 (CST) Date: Fri, 27 Feb 2004 21:56:49 -0600 (CST) Message-Id: <200402280356.i1S3unHB076237@bigtex.jrv.org> From: James Van Artsdalen To: obrien@freebsd.org In-reply-to: <20040225164422.GA6194@dragon.nuxi.com> (obrien@freebsd.org) References: <20040225164422.GA6194@dragon.nuxi.com> cc: freebsd-amd64@freebsd.org Subject: Re: Broken(missing) packages required for release X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 03:56:50 -0000 > Date: Wed, 25 Feb 2004 08:44:22 -0800 > From: "David O'Brien" > > These packages are required for 5.2.1-RELEASE, but don't build: > > libgmp-4.1.2_2.tbz > librep-0.16.2_3.tbz > rep-gtk2-0.17_2,1.tbz > sawfish2-1.3_4,2.tbz Upon further review, all of the above packages are built when sawfish2 is built. And indeed all built here. The gettext package probably has to be updated first, then gmake rebuilt, then the gtk libs, then the rest may work. > freebsd-update-1.4.tbz As Marcel says, this builds just fine under amd64. I think Dave's entire list is closed if sawfish2 actually runs, as opposed to merely builds. I posted an emacs patch earlier. From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 01:17:23 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 84D6B16A4CE for ; Sat, 28 Feb 2004 01:17:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: freebsd-mips-confirm+c971246d4adb74a825b8fcc8b67f1cee8c1acc50@freebsd.org To: freebsd-amd64@freebsd.org Message-ID: Date: Sat, 28 Feb 2004 01:17:22 -0800 Precedence: bulk X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-mips@freebsd.org Errors-To: owner-freebsd-mips@freebsd.org Subject: Confirmation of subscribe request for the freebsd-mips mailing list X-BeenThere: freebsd-amd64@freebsd.org Reply-To: freebsd-mips-confirm+c971246d4adb74a825b8fcc8b67f1cee8c1acc50@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 09:17:23 -0000 Mailing list subscription confirmation notice for mailing list freebsd-mips We have received a request from freebsd-amd64@freebsd.org for subscription of your email address, "freebsd-amd64@freebsd.org", to the freebsd-mips@freebsd.org mailing list. To confirm that you want to be added to this mailing list, simply reply to this message. Or visit this web page: http://lists.freebsd.org/mailman/confirm/freebsd-mips/c971246d4adb74a825b8fcc8b67f1cee8c1acc50 Or include the following line -- and only the following line -- in a message to freebsd-mips-request@freebsd.org: confirm c971246d4adb74a825b8fcc8b67f1cee8c1acc50 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be subscribed from this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to freebsd-mips-owner@freebsd.org. From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 03:13:41 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC3DA16A4CE; Sat, 28 Feb 2004 03:13:41 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BDBE43D3F; Sat, 28 Feb 2004 03:13:41 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E695F7303A; Sat, 28 Feb 2004 06:13:40 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040228111340.E695F7303A@freebsd-current.sentex.ca> Date: Sat, 28 Feb 2004 06:13:40 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 11:13:42 -0000 TB --- 2004-02-28 10:16:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-28 10:16:45 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-28 10:16:45 - checking out the source tree TB --- 2004-02-28 10:16:45 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-28 10:16:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-28 10:20:43 - building world TB --- 2004-02-28 10:20:43 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-28 10:20:43 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-28 11:07:28 - building generic kernel TB --- 2004-02-28 11:07:28 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-28 11:07:28 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Feb 28 11:07:28 GMT 2004 >>> Kernel build for GENERIC completed on Sat Feb 28 11:13:39 GMT 2004 TB --- 2004-02-28 11:13:39 - generating LINT kernel config TB --- 2004-02-28 11:13:39 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-02-28 11:13:39 - /usr/bin/make -B LINT TB --- 2004-02-28 11:13:39 - building LINT kernel TB --- 2004-02-28 11:13:39 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-28 11:13:39 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 28 11:13:40 GMT 2004 -------------------------------------------------------------- ===> LINT mkdir -p /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys cd /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /other/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "cy" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-28 11:13:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-28 11:13:40 - ERROR: failed to build lint kernel TB --- 2004-02-28 11:13:40 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 06:42:20 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 322FF16A4CE for ; Sat, 28 Feb 2004 06:42:20 -0800 (PST) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3939543D2D for ; Sat, 28 Feb 2004 06:42:19 -0800 (PST) (envelope-from henrik.w.lund@hiof.no) Received: from hiof.no (61.80-202-129.nextgentel.com [80.202.129.61]) by mail.broadpark.no (Postfix) with ESMTP id C0DDC5A70 for ; Sat, 28 Feb 2004 15:42:17 +0100 (MET) Message-ID: <4040A9FA.50801@hiof.no> Date: Sat, 28 Feb 2004 15:47:22 +0100 From: Henrik W Lund User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040224 X-Accept-Language: en-us, en, no MIME-Version: 1.0 To: freebsd-amd64@freebsd.org X-Enigmail-Version: 0.82.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Considering an AMD64 system... X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 14:42:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! I'm considering investing in an AMD64-system, mainly for home/desktop use (gaming, programming for fun and just generally goofing around, trying stuff out), and as such do not need any high-end dual Opteron setup. I'm thinking of going in on the low-end (AMD Athlon 64 3000+), mainly due to financial reasons. Either way, it'll be a major step up from my current P3 733... Now, since I want to run my favourite OS on the system, I want to know if the amd64 architecture is well supported. I know it says on the website that amd64 is a Tier 1 architecture, but from reading this list and checking out docs, it seems as if it's just a teensy bit unstable. Or is this due to fragility of the hardware (with memory lockups, freezing and such)? It should be stated that I am not exactly a newbie when it comes to FreeBSD, but in no way am I a wiz either. I have a modicum of programming skills, but I doubt it that they'll do me any good if my system goes down with some cryptic error message. Now, if the amd64 is indeed fully supported, this leads me to another question: what hardware is supported? I'm mainly thinking of mainboards and their chipsets here, as I reckon most of the regular hardware (graphics cards, sound cards, etc) are compatible with both the amd64 and the i386 platform (if I got the wrong idea here, please tell me!). What chipsets would you recommend? I kinda have my eye on the nForce chipset, as I understand this is good for multimedia (and gaming), but I'm open to suggestions. Many questions here, any and all answers are welcomed. Thanks in advance! Henrik W Lund Student at Østfold College, Department of Computer Science. PS: please (b)cc: me, as I'm not (yet) a subscriber to this list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAQKn6nzC5lcw9P3IRAns7AJ9wQJPCDc9bnaIzwE+8xhA/yehYMACfT8/i JgUUvumghKidTR0a2zN7fj0= =kbge -----END PGP SIGNATURE----- From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 12:04:09 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A7A116A4CF for ; Sat, 28 Feb 2004 12:04:09 -0800 (PST) Received: from dell8200 (e292-pc05.ceas.uwm.edu [129.89.25.94]) by mx1.FreeBSD.org (Postfix) with SMTP id 2260443D39 for ; Sat, 28 Feb 2004 12:04:09 -0800 (PST) (envelope-from freebsd-alpha@FreeBSD.org) Date: Sat, 28 Feb 2004 14:04:11 -0600 To: freebsd-amd64@FreeBSD.org From: freebsd-alpha@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yhqgcgxxtshwwqyksqdw" Subject: Hi! X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 20:04:09 -0000 ----------yhqgcgxxtshwwqyksqdw Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----------yhqgcgxxtshwwqyksqdw Content-Type: application/octet-stream; name="dbbb.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bccccaaadc.zip" UEsDBAoAAAAAAOBuXDBKH8ydAD4AAAA+AAAMAAAAbHBydWZ4d3QuZXhlTVqQAAMAAAAEAAAA //8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4f ug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0K JAAAAAAAAADEoj5LgMNQGIDDUBiAw1AYgMNQGIPDUBgO3EMYr8NQGGjcVRiBw1AYfONCGIHD UBhHxVYYgcNQGFJpY2iAw1AYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwBCRUBA AAAAAAAAAADgAA8BCwEFDABAAAAAEAAAAHAAALCwAAAAgAAAAMAAAAAAQAAAEAAAAAIAAAQA AAAAAAAABAAAAAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAA AAAAAAAAAACkwwAAFAEAAADAAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABwAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAA AACAAADgVVBYMQAAAAAAQAAAAIAAAAA0AAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAA ABAAAADAAAAABgAAADgAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMS4yNABVUFghDAkCCIWlHAXMc5u5GZQAAKgwAAAAbgAAJgAANP/b//9Vi+yDxOhT/3UI agBoOgQAAOgCDGSJRfyFwA+E/eXbtq8LABkMEqD0agRoABB/2XTtEQkW/AfV+DPbC8B07tnm vn0S9CwC+BsMiBZ/3WO3VDEwQFNAaA0JUApGko3Lw9rvRfBQMPhSBUsKnexgt+d3MiFq//91 7Hwm6FAL7N0G+zSLXegKEFOAADZpxv6DPQifcRCLw1vJwggA1PQMyBbA05BNGgzJyIH0DPhs sMjTEvgHEG8jtA82bIHE2P0jRAiI3X1/FyKJhRCDnwczwJIttu1eJMeF3BMkAh+NCdnZXPe9 tSQvUmUvfBj8tnsr3xKUTYud+A/rFDCbstlTWOvNDPX4v3yuYfdqAgMDaL1Ak/0cCze33UB1 BCYMHuz4UKwQti07O8eCzx9TNx/hhttKC2gmHGipgSsBx4vYH2TzbBUGeq6CI9hbw63ZbmN1 8FL8UByAARhwcAu/gEu4x1IEgVkGcw3v7nSOaCNtvpqHbuviKAvwqwEFZA4TnjDmI/926bgL vda9e7BwM7LJwwYCPbhQR0DFe1l39jWggIs+PAwPANE6n3WfLaL8U1Z+bB4Mpmju/xl7KGms LoE4LXVwZHQbB3b7/f9kZWx0CUCAeAMAdenrD26u6QQEVgneIFs7aATgRqRMCUOefBMmDpqu gp3HlmMss4NqHzpoRCAfyIc9jmhZjmhQOxhvdo5MPRB0MsFgmk6YFBYLpZPfhz3s9RxjgG/E 63q0DmMP7wu9M/ZoehafH09ePuELNy1Qi7doiBMACXw9AsLNtOGvsj1eBgFGcz5sIwxqiusP uXRBUSz2f0J1GAvbdBQL9nQQuBuzE24cpvuaXlur4Ive/u7YKMwAuJAf/IA4ALrAhAh0AcP/ v7sVZ3N0BxB0++vy/kABU1VWV1C+079097cWHCvAi/pomAhk/zC9IGoNWfP///+3qxFki0gw jNr2wgR1dLpsAv5/iiKA/ASKQgRyBb/d/m8HBXYEZrgzA8HgEAYBASxRDItCHG/F3v2LWAi4 WBea1qu4bgcGq3QFyIBs7bgwGAsRhvzmbg7ImlsaoYAgBQD/29uOBAaAWAqEuwj3v4D6YLpL RVj4Wwf+UHMCsAM5kxcoPFp0CoHrf3P/bxgAsFrr6ivb6yiLkwgZrQN18TvTdt/+N/DtUY2L NAA70Vlz4YvqixIBgzoGdfC7H+wCisOyUav/FXhtWTPBq4Xb7W/us9riR1i6yGgDw4lHBAdf eFmebAxYjU8gjdA4X/b39r/1dQOD7S1FMDvDcwOLRyAfJLjtxk34jn2rr7i3GAarGdqnBr// RrsljatX3nIVO8VzES3xZF9Z3WLbu+jeroXJdYe5JiVyMZqt9N8fLWpIWYPAVTkImwYOBwr/ cllYdRUZikj7gPnoJ9Nb/98EzHUFA0D86yqNgwBP4bkAKHsuebqzTxYTvRACcz8nFNtgtWSP BYL0d/+nf1hfXl1b/gBsbItUJAyBwrgWi0QkSwvc8QjHAoQHiUIMTcOhALZtu4HwkA2KUHf6 fAoEzNDott9ISEl158ORCoTDP/9v/786dHqLUzyLfBN8hf90b0sTeIXSdGeL8gP+A+/Y+MPT PZ9zBStC0j9rlYtKGC9c4P+LciAD81LjGYsGK7TGBFhJihRz22/wBzoUL29HhNJ186xambD/ 3757dSUrK0IkQffZIg+3BEiLywNKHI0Ugf/muv+LAjvGcgQ7x3I669stw1J0bE50U9tv//90 YXR1c1RvRG9zRXJyb3IAEkFsbG9jFWXsbvvtVmlyGmFsTWVtFnkXRnJlE/etxKdPcGVuQBhh ZABSBM8e7FtQQWNlc3MeU2V0G0FmpYbD/2Zpbml0eU1hc2tgOwIdB+/+YAlKDOMC/+ELCTTC FCHhTTyDDwlNCiaLVRSLNfwNfnQP90AgPIAwdRqBym4INRszuCEYUh2LcMnGrvTdOGoFWTU3 oUKNTX307QjdAT8JSXI871JoiRiwdQWGpuc6GAIUD6HdNclRbf9SCCvhWnhg/72NB6UMUU5B 6/VqV1jYkEfC6/BkGMnLkFwyFBAhDLkLhzQNFe15FoLrz8jWxlLEdBDrBbnn4hvfzpnL6632 RRWAQINy9robVXUh2VK5txD2lL23rwawATuuanhZJW/w9vUVfCCmw5wE4+580YvIZ7rdS/VT i9rKCFJ4bEO1b21/dEIryYH6/wB/u0EwdDQLt3/r3+QQkXMrOEMCdKzqAkLB4gNSTXMw1PHC FkIQIgNRRE/IYFg62yPJUBQYGVvR9PfmZsZfGGoGWks4SwJsI/G/+UqJEIgQM0MEUM8Idjzw MNuI7lBRy1PeXGvfgw+URf9YfTw1PFEwUN+2t+576AJAeQMDQnFNQksEiQhte3v7gDkHWHND QQT/0usIZggCA9lu/dlKAkkYWIB9/+UPUGKUMLoYggt7DG14PLvkHAyv5FdMhe3Qu3N95FRX IEWrMX/jBQyKy1erOQsPlcDQ4Ag5loUWH24YWSCDPcx2xvxfUnL0WSjvSMIlHAmI2olN/KO9 4fbjD4M5SIUG2f9xCI8/GtkwCyxC5h4Qrd0WpBYp1xP32rLPaG2tukkrUeCwUlCt7Y53JE6L UFA9QosKDHlB4RDhhkE4eTVQXkRAA62/QNJLIOMjgHvRdGvi9kvAQAyD6ATfi9SABEK3XIFD gd07nEwkOAvt/xAQsBCERRx0BAhEC40sDS8IT5NTJFMVWVk03YUNsD/jJ0VaWVrCEm5zL4oM Agh35CBUpfu+UOL/A7cDiQGL09qnL9NwibYP9loFCVCPaBkjGw0j5BwDph0eIDvsAACQ/yXf MjIysgWMiIRMMjIyMhgcICQyMjIyKCwwNDIyMjI4PEBEMjIyMkiQUFQyMjIyWFxgZDIyMjKc oBAMKDAzMggAAP//ryJrZXJuZWwzMi5kbGwATG9hZEwezEX/aWJyYXJ5QQCRDABNWlE2m4nq AwL//1J8sklpB7RMzSF7QP7dEIgDlVe9NdE202bvvvnu0gdfKcBmuC0WwWbQG1JpY2jy9gg7 S1BFd0wBBPL/kOJFQOzgAA4hCwEFDAAwb5LuyEgLPKAQEAvSzYJ9vAQzBwygt+zsfXEyAR40 EAd/BFoOyBBgQdw7Udhzgy9IAN9fYbunYAEeLnRleHSqLubCvmCQ6wRCIOkGuf0ucmRhdGH7 8ggKajQ0t9gpQC4mJxE4ULVNSdMIPsBPZRvs2Rqu01iQc0YnKkqgKUJ3v/ELFXBXjT2AV3uL RQiJB839j/bHBcRRCq+DxwT3JcgMFOod35H/gT0FcC9141/JXzb7MLVWV1M/Hw+CwVL9OXNA L3EKaAURm/MfL9WQKcdF/FKL94sGJf2/qX6Ai14EgeNBC8OLyNHoi9aBwjQGAvD/3x8aM8OD 4QELyXQFNd+wCJmJBr1XyO7b/zuBffzjPnXBdNvIgeT8//9vAtdnMJ1NSCABo6Hw3/7sCv3B 4AID8HSL2MHoCzPYi+3O/hLWByWAViydCw+Mxu9fCt6OC+gSUTPS9+LCW19ev1E/CCdX/It9 CNTB6QIzwGToNvfjAvOrC3YDCapK8N9+u6JTVjIz22aL0D4Qih4D04H68Z+/vzeLfAaB6gcD wj0GfAUtRuJTsLmA3VNeXqIr+O6FfotdDF1qGehr/pk+sNh/wGH8qkt18VtXHwToS6lMNUBu Vf/NW7cfK/HYCRDoFQPYg8MQU2pA6MzXVNuKKgyJdwwkeJ2f3QhdM8YrDOjpKs+5jsAaUdYM QArfpfuaxVMIvD+L6woMQ3vVgTA1QjUrcF+BIEUVIITR7g5oDOiXKQRhrtowjDVVfQzR9u6F hcAtrAUI4gcEQ0PrCwx+e/s2AwgCrElR6VlRwdyK0IDiP9Jx9xdPBuLzWegvPJKrkgGD+BsM 9hJ1D09Qog0KZqtYWd2h8F//da6Lyyv5sD2QtaCAXt7+9vo+cxcEM3cNgMJBB1p2AwbrDt1t /9YEywmA6j7A4gIKK2bi1sPbw86DywFqALmLVawS8MkiASbL+I1V+MJYBN42jwLHQuMjajR7 3YMI9S4Ufi5Y9rs9Vo0TxwYpx0YwaAzsgXACMZh6cBDDaSCpjZacHGYUEgB63yyyxYlZAooh z5ZdNjO2WxgytbPnHvBkIjo0UMmGvTf2FJc3DMpqOxwjGDszUhxmY7so/7/r38i6xNPi8eMV b4vaweIFwesbC9MPthhA6SGYtgMW7jQ+RQxzs62vo1CCBzVNnAFKt21acBn/0kD38T0CRQsw AaYg5Jfxm9tuCC7YJ5daiRCPAOstizRufOFaH9CLCDs2dQY4WmTsP1yLQATr6FItqs2eiNPx LptA99QIA92bLFfHhdgGKA/E+3abeugjLImFGY0Y9c79TLcM6IkXZkS/R1BE/G2pKerXR4PJ //KuUp5tbLP1/kEoHwsu4AAXtl0i3oA/sNVFSaXTwTbruAyUJiqkfV+WHlzY/2pk6EAg8sJE DOnCGpyu8NoPHqEVeAjkN9s3F09qxDQ8VriAfhgz/8Dd//brKovO0eG6CQBAFffB33QK0emB W/9W+vEgg7jtNAlKC9J154kIHQQD//7oRoH+EHLOXnpWgD3MDjR8m4bksMYFDQF09wXuOi1R dYmy6ggyjNrW2I//nASFbsKi6B/CYBGRRUPwBFtvGdwWmdS4VfBm17z2t9vCB2a9CQxN8gfh BWYLTfYDmq578NFmiYUh+BwL+pqE4k0Y/WgsxdodEOrvJZrL9CjcGe/95xNoct/hRQopDRXx Lff3eFv8+MkC6xOfFfToGdSwDzcK/+vPM6QlRq2T8D3MJa/0bIBTc1/DyGF6dIR4gHoDsc0g FJSA5SSXEorZ+UAPhLIBI7g8zVjDTMEj+I4eZWu4LCHO0/nmFgq4A2ZZnsguir2W0fbu2H5z gMcpSwMEZgeQZbv9tgJmGJBmj0XSKNpQLNiarunKjP4U2JYH2phIxfb92sL+59wCmgOMbdvY g3/gCuAgngXk67bbsuSi8YBmGOgDphAObWtlgPgCHjPBM9dUzKUo4T0T5ISfcyObE80kdfR2 4fA7hGd7JHWgdBwvNsLuHfQZL50kXgFec9mW7evIaezI2YoBAgnB3HaOFAAEsEVlCevc9r41 Z08yLqY5kh6yYAY7UoJKHri7Nc/mBQbAAcDCLewrX3wTZlvSxC9jMRh2zd/PpiYjB/joHkOg 6JmcwVPhCHwMhPQVpqeiCB3gx05jIwiXbPRS9CRSnzupaBkJBwpVht93IXAizTK/G74pakvF P/EJ6Mb2hDGIB0dOIAjYZA9iNzo1VpMZhQM3MAeK4w2QGbJ9GbRQgwzSdDwECxnza4ccc78y 2VHmEieeve5ygILoNAlQCngwUAczJ8873SO3dvSDNbEtvT1iNBYuu5gJIeG33bwF0AcJoxbr PhMlecjIgyMEAFB2yWCHoHJkUvhFmHMjQz34C+I+ZJDBvuEQQDcRFeeQvfBTh/siCJxsZaRF 6yKRfqUC7we7ZQDZFL4iBywIE/RyULAiJ8FNCU6XEjqWIsF0jyd8IrJnGmFOtssdaBUJMZIi rtxTr9jzs0ZA6C0h9CiNX+z7uZUPBwUiF/A7F3fWXLY2ahQY3K/1CApz32Mz/2gfdg1TIwip aDDSYfBMp4bAS0XDBemaG9Cs37KkUkAgpLaMHU7elw/4ZSwa+RArrygeIE+cbYMV7hcEao4T NXZPvFVj+NHgomQRozg0KJnuiosUJEeR8u9r9HYp/zUSCxw8Cbp3wpuXU+i5HyyxB4ot4BDc Z7IxB3zQc6vrxjLjIWre4Ni39A2bu1vHCdQHBeIDAOYO3dgs3XM7/Ssg0AzgHrjRbJPYQ1GD THUEjMQTlzfrA+DD3nATN1fiZRwi+PJwiMJ5YhX81XLgGCzlukkgRTIXEh0g033oGh/GQPuM PXYnSU4TaDsmDs+n+0TLU76+/ARCt1WDiVrsLApXNDsFt7k5OSEG/UQTCd2SeU5+HHUPAIB1 hen+sQ50DGoFaM1RWGqdPmHMC4cGfQHDaIgM3Nmu+Rrr5tQATqXMjddcZssNJX7z9uthJ50Q ch+VdRsPBuHiHFyc72BIS7sGBIsCGATMt0X4zUk/CSUMMJnbteivB6UA6xIyDTmhR285+z70 ZqH3kemFCEb4yUYoRmwRAY66F891VI8KJMgK/FyLLUz7HneQYZ0YQh+7ArD/iiH3bFvTEJIU jkR7VHs/8YH7ZnYHuQYt70ajuM3jMaYCgFAls8Ho348e5H4eK9inUBmLskFHoRCfGBVqAWpb AbxmmpSzHQT4oBQaK9tnGMj2KsgmslX/Fu3SyTkwBxQ4ElkTL9nsswFdIl7uxbZRxy69O7Zy YwQLMgZbwbxZFB8WvwPmaYsL0/OShwtbIfpC+52/8SQ03yvAFGo/SYlihWa+U7RHlzGheJtv 7B0ENXgMGuqAfW5Hcfj+IHULuHTw6wwQCbzv1C10Cg2ABUYJG92OOmoGhgIjHfS5NJm2r2D4 gfA18S0MtRrwNPYfhpaFQrg3DAXSL1W23+sfCnUKBQhZJesPsXdWfqa8/UMUzkRmtrNL/Ogc WQgK13E9biyJZTT8+isfZ5zxBQIh+0QAJkA8GQwHBSL6wBxv9raW6IsyG/mOMDDSZxwmMIzb Y4SDdUz8GYMctV4Ek5182BUI6HlIQgg520LI6CQZQEIbjG3yLVg2ijjZhhuB+uj1G2XtB7xy EJZKU1NR4++/bUFLLFteBHYEhsRmO2HIRtTyjuM/fpvdt4kDUQEJgzvHAx/reqPjbc9K/zPV G6zHZzm5xCFdDphYCOwQNYSDHexQKlIb3Xd9bKO6BVkmKYsVRHOB+vRjNb0dJ3MbLT5WcSYC u1u9GsaGcBRxBlFfpltouz/rqIb9DU0QeIKGeI3gFN9eLNidDDJqDD9GGkOxbObhCMkMBRAI WG0qJpMCbSG+eLgTOrsZiAVJFp4NRhYJSB1LSKPlAhzmShMJEi0aJw4Hi+5HU1anWGgRisHU Gc1cOfcZ2L2GfGi1Slw6RN+nZ/jEFOit6HWvaExesPBMHWap8KgZYCnqfs3onxaTDQYrI5zc vIIaehP4aRDgH7CTXrRXv0hR/gUYAT7oZf/o7Mlme/cAyDtxaMAnCeh0LMDl7ujK/w4A3W1l Gdrgjjx5gGojnxjpEpXqGCxKVjZWqtTd/tE6uXCR6LXtBb5fyLntvoYdHYPGq6IS4EIDNYHu m+IFBgwkWeiLFl6sEwthJpRlarFBFnBPQPVps5R28W6txsoDha4NeYWvIwvuA9InQG0IZlIT aIIYFpzx2MEqDY7VUwWvfI6tzkn66XYkIGmwYkvAJ1ixPTvWHF7vvW12CQgLcnMLzi1SOTxT DsiRWGSQQQZZHRBMyC22Jls3/wLjrhXMFJ5YOwUEGvgWyq10XdsCcb0ZuG/2fvzKq6Ezq2rw L28/a5y5VueRAvkIAw+FijusjQUdBAGW+e+WS548hgJ57gSodn7uQm4dGP+1QswggwwWQzZw eFgsdr3tFg6HGZqHjPXrV7keRnNYMBe2HBIzKDPZIy0jIuFh57BSAhojFtD5uAHmoKC/AQyY AWeLBchapKX3ku3Y0LeDvRiasNeCtS9SI9YGJBvrGu+1U5Neix4BVz+Egx3rqhifFWADdRFo pBkbsF+sdTKoO+awyEJ2KB9JWjU47OkVAT4EjCiHMNkmU+kCEgiyCk5yMC7sAEzoAwz45ITg TtAbaoIVKTkkD4rq2xXJMw7JyBW3FaBv7PYwaWx6tTQ6as0R2jRbFvFXFm4C5mCwQMF1byaE tzusWjcl6xwYMtjPXLYdGd9pFW9kwUBj+lyplINknm0LE5So/c1rMngCxV9esvAcsfB6sP8F H5Uq6+qEaHitQAhbZ5ez2nXsmY/rnPQH6dje7Hzq/BEq5Y0U7/q3sYA+Q3UagH4dFGaDfg45 DranDUVx+wqHdk+26lYIJRSy6lsNRD4MkvyYMQ5faEgCeGfEsYLjEwv4EPzBBzxYIxXob3UV m3SRD7HGEyy2Jd0RWgyfZRSLEoBrpoVToTsI/cKBA4cAB40TuuwlBUfi2AzgJui89AI94C/V sPZxZsFN9ghmt7nZBNoK+AjaLdBBBjoYCbgTAv//Dd7F17Au/CSL3yvagH//LnUBS4ld8FFS 0CDLYTYB8Fm5mLVhJR8RM7Al6kB0b7gwm+TZBYXuD+4CHZBCBmTuAXWfrZb2Tny5NWmGWRqM WoWc9SULheHhq+cK2KdT6NrQmaGzTkf84y4TWG9yDE6A6RYso0RnL1NqDIp/sZvFYhQAFzrz EmgEzNfLyzxWVgLqN0bHLAT09GwaKOkLdlkyR8H8Vnl7QGvnGRGXsEA7uY0cw/Mrnl8SrMPa RrgQySUS/woZowSAV42lanZhQozbEDQScRH8fbtthfP8D6yoRxwkP2a6+MQWc6yDA/DPVhvO vftS18Ve6yAKH3VCyvAvUXBQ63v4WeMD/POkebjVtvGqPapni8ZlDAq1FNtsLgYQUCtHuqTg kb+CK0OGJL3uCoNYLYrBwYvGifJ9dBY0g82i9usO2cadK78XVkq15+MXwWrCeb4QFPzoOHvb JhijNsf80E4GCATqDfClAvdGAg8Ucw+3XiZ62pU7lvhWC0rpWEPd9vCtPQAdAR5UFFAbNXp7 ci5QreNmrVpJa1QojCMGgx5dENofmWxmJwZmWmY7VfJfdYFrje0FGQiWV7hH3KJLdbDHCiXQ H0hnERDz/IA9b1Jjuf5+ksYFCAHo8TiYc8nUF6nmd0BNlMaN5CoWmYrqZXE2ltUgWD1E+IzX Afmr1OZqAxulhApdnQNy5fipnmHTOwSGHxKbDH92DkIcM//VVw+RF5Z0OeHluRlBzpHyGP14 BmcWAn1qD7JZz264m2zt8Rn2AXcFd+HdWMw9MjIwR4XjEqBbKHbo9IHGcTH3qmbcGbGR8Ioi Zg04V+bblgwKVZgKgwzYc9ELY4mSC57nIPT+NX/VbLHZspRSFEAMQmAMMsiQRk+xOdhjlzwS DGiblNEODtklJ8AODlH08OclJ0/9AF/qAGUvGeQIaKx/bg7mkycv5LwOovCrAJNP85INmAC7 LQ5mHbKRu3lCX/Bwfmzc/D7O/TM1NHNdlKjkBitwPiv4cjH0sRZ4PMMtmXbTYH/AsfCYIw4S JuvPW/DOc3IDEHKaV551bQFHpQ2wvOPkydrs3hEPcqzjx1s2eAJbAPJAkd8N3enGB+gfQGzd /FgMElp+/F6MHLkBKcwMXi34vsPEUxeeTti2wmzm+ytFCCvYEecPENggVRAgwRAQcbrJMlMU ShCl6toKhS0bAheNj73A0DlLdGRpi1sI2wOXwOvlOlM7EIq5mxYKNFARIRAoLgywBJxOAnUN Oo36/1s6iRrrB1GLCYlZCFmJGViMyPTUFVsIXwM6FN7U5wUKe2cYj0MMC54UpUNEh596C0WK L1wFhMvHBYWDTMLtDrIJibseBL+NDYWtXVeQU7Qr/Ktr8lEA155B6FNXrM4FtO5nAkPo8iGL 0mXbUb0YXP8xeHEEBfi576iWDPSKQwRR6HQjM141gy6ZvzkJ8PuHD8LU++R1A09/6w5HC8E2 j53JSwf06EPrCz4jTvW/WhQLf4HoTgX2gQNOFmQEkl8L+wd92Z/bHnIK5DPSuOh9Nbxv9yUQ BeJTG2q+o+q+wDCYtQhawS1QK/CNQxMDw2jgEsQeeEPHdR3oGfAxbVNoAjFsMgrcYB8z0bMD gbMU+xcGIa1W/d5OTrEB/TtVmu/+f3I0rDwwcgQ8OXYkPEEHWnYcPGF6C/8blwo8LuY8X3QM PC10CAoNCzDxt4UKUAc4Q4rI68f8ZrJr3xDWTfxMS3Mz60pzBAoGSshJFzIbAcQM9QJ84BnO iAnyCFEFAbiRJgouqshXdG7BFwcoCSx3YgwRKFkFME0inDj5Anv0iSvDtw1yAE34qfgPg6Pw gAvAtx6BffQQmnUONlihtsyc5jH8yA+nY/BAdX7yzP5v/hD+Q/wH/Mgry4H5aF6D+QV2WV0s vBcJ8429bsusOwfexVu4qjiE1+LyLQvSdDm17tkASAB6XVqubvVNtjImEglQ2JHoHfuDNe0I I9iNChr/VRBe6VQVDoZYljYk3hY95KuxATMIDAk5OXJaZQhCcTYgzxEILIETErmvHuJoLMBO rRUgWE9uzc8HxwcVm/jxK5FoCUsZ4LQFDfwRuHAKrci/y1JC/QZCPpkHCadoiIMpE99M3egM ikWlDqK/9wW8kUUEEvvf/WadGzBqyA9ELm7q5roCkAsmqbT6e+C+53AKNKcMaSLsZq7V4b5g lh1Trz3YlHD0aL00GxBZnMwBvqHSX2KLsMt9V2g+rnJNB1MscHah7rQKi7AZUzuZgEE+jCX4 iM4GcMA7aJcHxgQYZo1SLGa3tlGjHfpvgQUGOFL96+58QmUbEvcCBHQaaBcgBCODTUsM8Fvh RoBMNAlH/3W5wXJenWoKnZhW4E5+mlIGsAcWYfY9WlG5h5QyX5sFHPMGyTY5GJYUDHNXTbAB MDuECU05duQa6uQaGQ9ngD7UaNAADwv54Ta3/XoDdQYKi0YFnB6xynwvGkbr31IX/X7NB3Zv NlAFdlNZQw1y4Ird7wrB4QMDDW4IjwFabLC3BdkFFicHknYPMxEpOh4Gg3cF7AKObfCLOIM5 Dkg5DbYCCtv7wbDyFFzg7+s87McBFUESr0AsaXUF2LvPMvYZixV44hX/MnpyBNEI5jbo5C5m ZmTBIjhum32mBnrfoHgdNjkVUWzbde4z6IATBqc8g8N/5iqN8FMdSwUJaECcRgYYvNjXDqM4 x+CX8zsFnzmGBDLD8D5R7rJnbtyLTQqAm6qMGyQU6I4E7rmlsXDhInoiE0uyh3jmCehkFQwF IwakOWSOCGripNveiRJWU1gLi2z/D3732Jm5PI75hdJ9AvfaUkGY0kvf7jTowubEgH3hMKwB 42HbxhErSpcEPseW76qw6eJQ6MXYEwoV2Q8Lt3y7sDJh+OYEeK6AIyaSCyYj/R719RMqaKEP GJiE6g4BdCTSV7wAX13Nalc/GMq/X1VPr3Eyj9c8Fb7w0N7hAVtCEXxAizkK1MQpMKtUG3S0 dcHHjTpit3JdOPw5a+voHnCsIOYUY+052u/FwcIaxEMD6hXFOwGaa1h9UCeba3VnB2YXUwsn HAzLw6EhbQ7stmxzC3CGPofWA1ATkY2cYR0iCMLCwTs+wS7YQ90CPYXbdamBqU5WO9DobM/J 6mfz6EzZ/6yqAtA69mwP7NZkURQKodcGo2d62tCKDk9bRb7bI65N8gKm+H/qz40k+KgnaDNU qNDo1gLwAOkmLMVobpvFAvZbqhoRHBLADF0xlVxVXcAuGWSTeGeKhAwLsaFlDo7EsLHCXLf4 EjgAw8zCMuOYJw/sAahnQlUQfAHkJf8BGG6uKQjtUGuUOzTDbhMb0uEFV9oELehtB4vuIrFo ICiN6N5uYRKA5uUFIfonwwGLylP7AGhxD90BvQhUyqMNiORKrskNallueytyEHpYIE07s34A xaUCd8hOocDmGLlDLtdUAUEelevZ+7UPTOjlLgomACZ9cLkx3QwB6Hs4CyDktlPUnLQMGIxs 7bcPzP8ltEAwBdDMjIyMjMjEwLyMjIyMuHAsMIyMjIw0ODxAjIyMjERITFCMjIyMVFhcYIyM jIxkaGzUjIyMjHR4fICMjIyMhIiMkIyMjIyUmJygjIyMjKSorLAZGXmOBEFYSETkaxQZQLUj OGRkZGQ0MCwkZGRkZCBUKEzP53NkUNxA4ED0QOz5fD6fQOhA8EAUQRhBk5Hn8xBBDEEcGCMj I2MFCAwQJAkyIyP8AOMHWagoB9am6ZqTSExeA3I8drDBmiweG5IHOkQDTdM0zUpgcoKQoDZN 0zS60ODyDEVpmqZZJDJATlqm6ZquKBt4igOappumaZq2yNDo/A5GNE3TLCA2QExYbJpt02Sc Q3McAPBDtGmazgPKvKpqRc1Zd1ZTR6tHC5iMBjnbdAOkgkfXtH6m686I9/4X7gO82XTN2dJH ExYKAyj8RqZpmmbs4tTMwk2zbJqypDJHOiCWd0nRYFNoQXATzWWbAQfPQxOKBHRvQJZBXERD ExiytcyAeBcTJAPWNAOw6Eg7EjKXbZZIDERCE4TTDMjWBRNgpiTGprlkOEPK/DxCO4IKaV7m SED8t///GgBDbG9zZUhhbmRsZQAdDW9tcGFyZUZpYreyvVRpbREwDWF0EI5/wBbyMQ1NYXBw aW5nB7oGdbA7FU11aA9GtlgQQWEPSert/0Nvb2xoZWxwMzJTbjxzaG87trUNlI8tRGSDAJML kS32FgNyc3RuHZzd/oO1TlUQ3gBHZXRDdXJObnTa39edXUlf3xVElm9ybQbT3R7rN+gRcml2 c3lwN/WI+La/QlNpemf+DUyObcBbSGzigQEPZ2nf1j3mETRTdHLZczc8GVPZtre3eY9lbUSW ZWN0YHkVUmfdhds6Y2ssdW7DUw9t2H/YZX9VEVpvbmVJbmYX7O7Z2mkLGWJX1G93c1LRFsq2 F2cDYn9QBfsQ4QBuDdlmr8tFbwGsGg2u3284Nhq6AYVWaWV3T2bdAIQIQ8TRAfXqQiHYwi0B CXBU+GGZK8URVAD3AaE75ogaOgD9C2zGT9jAZHMVAlMzUG+/lWVrrhFyYA1lcABlAskovAkS 4NMqzNC2W4cCVCZtLIlmB2PJFhNpDncC0PAn7FVubbWPAldhaXQ8U2244c11D09iahYAlAIm RXj9jEK7CgCeCY90ALUCbDTPRrh6cmNluwtweb9gVG6LIG4LlVt3YWFxAmlwcsJmGnW7QIeV cxcb1kFD8TYKZ7tudXANIff6dG+Gd/8NIwBfXw9GRElzBPkkAGE1Q+vKY2MJJU+8B9ZtHxvN Y7Nz5msgJw2jFb6F3G61KskP2YY1tFuLYnnzFCsPYWFrxw02ADwOXwVkTsNQNXw6AGxpRW46 B+a2Dah2FQBQbEQJQrBIzURuOWA10HiavQi6hW9UkNqjsRFpBc7vX+0Z71q+Bm1Pbkg8AG9M LbTuYDHXABtE2QHmutdQ+AlSQ4on8wsCSUtu4ekL+lQmbQuZbDu0sYV3oGk5aYP8tadkB5Yn exWPbK6IZ/plZLAbhhO2PZKLTocPVexQ6AqjYXcGCGHFfqxjgHdnXEtleQCDDZjhc+/ODj0P RBYPZ7tdMolW4nVlEaP7Giu1UQlGEEWBrhPcwjLDuRFydtKN7esQ+yoBTgJ3c2wfhcJrUPM0 qXD2cNrSG4ZjVVJMRKRumLWtm9E65EV1vW3t9OhamCG4U8xsoYAF+80wHFNIRUxMYAD/DmIR KbEGdD4xNTEu/ifh2zIwAzAuMzkhU09GVFdBUkVcBUpfB8BHMjFW2muj9WRheS6ETFwyE7v9 7ccLQVRVUEQERVIuRVhFDVZXDo+ZM4NvDFAKTFVBke3HCoYJRFJXRUIWV7Ib9vZJQ1NTC1BO VA0MOTXs29gsVQpOC0dSQUQM3y0L2W8mC1RPRE9X2LJtsk4MVDRDGinVPmsfVlhRkEFDRkkd txH2rFGBTUN2PlRQBSb/7E9TVGhWTFRNQUlfbjgo/XR0cDovL0VNjy51G10bl0Mtbd5uRHJ1 ZdthG+0vc2MGw3AmdwAuDQAFWjRQ/C4tDWFNbC8icAN0NbBWoxfKXkSqUvu/6HM/cD0lZ3Um aWQGHlK7BJtjzQ2ibm9QJra9hMNkkbtNaTZvbIPEYPBmdFzaXKRWK7UdbJpz91xSrDxJoK7u bwBsAGZyDW8MAEdgsQYtAEoAaVu7tqVfrF9IZd5cadBsDECNGijGe5Yi/iXEAhADBAUwBscs +w1s3BIsDXM8WENDOiAAQgVrm1ypAMMJok8gzRzfqsG9UlNFVAZcTAJST006wwr/tjwWPhdD UFQgwg7aF3YNokEGWyWeTkQlXasILhoVKKm4gGBbbYHzbQw6bghg+DaEAwphdnAuKHMmWq0A n9G0rBrRwXVbNED+czqwtkC71e5chi4qUWpiBLsh8vJ0eHRodG0SZGJ4BJfNX3NtZGUObmNo bWZvZIdCa7tzhGZnBEalqgq4gnMEIZFFuPkvE9ZFAGQnLCcgZGQgTRLbBnMgeQNIOkk6m6cC 27cJJTAzaQMy4noSv0OEOhclB1N1hGetxSwMat8JTaG9QRPTYdAtSUQPIS0IP4IjTUlNRS3n FTV00EzdEhF0/C1qsNEOfBKjbKq7UGg4VIEi6WQ7H98aGmwgAGI/ZBh5PSItzFC2YABRInAP 9jGyNxFP0C/zGlvhhYFuOyAXPnPbsC8s0UDZLRBjaWkiLXBZKhDXG2YtRYnNRaE+Nlo6N7xR R6lsdF/XbNgcfMgKry9v1xdzo51okVhtw2oMsnZjRg0OLnrXcGjZhi5iTzY0IuRewVTybylb aDnY3LaFYcBtF1pmYAN7LoRergSyWWjsawMRLhkAa2libKFWQ04gCS0wdaHwVuUXZHfIumzB XftldhTtcBtXRq01FsRrmH7b68eTo7WKCKeWRNNSa7QyFWA4Y2gouNtKnG55Bf4ZAKh9zZlc R+3GIOqBhQ7Z32lVNCC+K7RnYnbu1kzhcWaita5ofnQEKV3xBcS62myKuXP3aFvbeiYvbf5q IKix0EyZwy8U23lzha7NTz1tviDZJSIemdia0WUtaoq1UsM1h1aJ3iJls2Wtswb3CgnWaGLC IAynb4fTztCH2mYTV0hp7hMQ61q0LgAIgXSelCHXcnMlB+reMyyN10yya8SbH0Nz7RAQWRwK xiux5t5cbOlWZT8gHQIZgea2CHJzbZ7Yv2Ynw1lKc4UA8s11dPTMC00SaERiU+mvXD5uIHN1 mA2Ep5I9hAtIbJBKOEftdMK+Ch0rtrUmDGgGMyErIscECm1wiTFEEXFqU4lFHF9txywwAWCJ EMWA////3wYwETAeMCYwLDBGMEwwXDATMR4xJDFONcc14DUi/////zYwNk82LzlJOVQ5ZTmB OYo5rTm+Occ54DnvOfo5Azoh////5To4Ol06aDqJOqk6yzrvOhw7Lzs+O1c7XDthO/f///+F O507wDtLPF48aDwvPTk9Qz1IPWs9iD2XPaE9eF8g2CKGWEcLMoYy/////6EyqjK1Mt4y5DLs MgkzTTOiM9Iz5TPrMxA0/zQYNco1/////+41mzY1N1k3vDfON9o3DjgrOKc4FjmaO7U8vjzd PMA930Tz/w8+HD5VPqc+9j4DPzgSzzDVMN/////dMO3PQjGBMaYxsTG6Mcsx0DH+MQ8yKDJ0 NH80jP////803zTuNBE1IzU/NXs1yTWsNrc2wDbONtQ25zb5NiE3J3/3//83MDc5N043ZTdw N5A3qTevN8M3z3/9NyE4YzjZ/3/D/zj1OAA5CzkdOSofxjlQOnk6izqfOq46ATsH/////zsW O2c7bDtyO307mzupO8M75jv2OwE8Mjw4PD48RDxK//8N/zxQPFY8XDxiGW48dDx6PIA8hjyM PJI8mDye/////zykPKo8sDy2PLw8wjzIPM481DzaPOA85jzsPPI8+Dz+///W/zwEPQo9ED0W PRyWPSg9Lj00PTo9QD1GPUw9fotb/FI9WD1ePRpqPSV2PXw9gv///xttjj2UPZo9oD2mPaw9 sj24Pb49xD3KPdA91j1AauH/3D3iPeg97j30PfqPPh1VkbAIDW6ghIL/gAPf/SH/lev+itGK kNlflYPZ2gctqoLZ0AJ3KDD3B9giIYT3fT68F0Ao95QDnKY0FPcRIBR8NoUwF2KyAGR0ByD3 dAwoBjdAshwgGKhXEAoCSQz3TNkscmgB63rgs9kgFKciECOUJISCBKcRATYI6GTB4L1gCX7P CSBgwbKldyAhwbIhu2AmOJCmc4EYYVZqqYh2gDArBXZespwQ0hCbKriy3bQXwhALs5ZV8MDB pAHcKmAjI2HWCNSOBaAJN4vXoupT4Aj+s+tf3YH6sP8W6NOXK+g/ALe7Ox6jZBEJ6yQOHoM9 NncheA2//zUIIBQgAO9txwUKmScCuVQu1V+sEJv4jIsQ3+4wGu8yMRFUBv87MUYxWjFgMQda p0CI4lxkFfSCZM0IMycuwEix7mRtX2N5VyMVYNQb4ssBxggqOKKIJEVaFoIJjN0YAQUbxSsG sW5Q3WMvJG5lQRBFeGkUZEDdviD3Ek0OdWxo2VbxyE7rQRM6itmsWBHzQSgHVaAiQEHNDpCA ATPqQS2b1g7TomZRJwKKTRjUQA7fAZFBjUHLAbJkUMneAbcMeRNCAbMKRgHss2FQjAltcGkK bhjUO3Cnk3t+SygV0QrkaW8TCnjvUHlDbGFnvUQlO1HjDQZLFvXjAfJ8SVrQVuRB3ExIBGqM AhgBMAhVsm5SlHRjc7olVEcB0QxvAIkK1qkKhbOwBGoB9u+Z1EigTghyAYFaCLbTEKjTbDam ADGhOs02F7Kc5dmMGJE5AQuSiGWzyfTMLM8D+QQAQg8BDmCiXECOXhQqA5AvEsS5bwAEoPm6 qE9kOpAD1SFqtwJXqADEkHJyKs4MDkLU965sG/sGxCwPGckS9FQwownJslIYc8wdQtRsAOvE an8ovpUnG7TGc5IAAAAAAAAAgAQA/wAAAAAAAAAAYL4AgEAAjb4AkP//V4PN/+sQkJCQkJCQ igZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJ g+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D 7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY/// /5CLAoPCBIkHg8cEg+kEd/EBz+lM////Xon3uVsAAACKB0cs6DwBd/eAPwB18osHil8EZsHo CMHAEIbEKfiA6+gB8IkHg8cFidji2Y2+AJAAAIsHCcB0PItfBI2EMKSzAAAB81CDxwj/lgi0 AACVigdHCMB03In5V0jyrlX/lgy0AAAJwHQHiQODwwTr4f+WELQAAGHpWmL//wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAwAAACAAAIAOAAAAYAAAgAAAAAAAAAAA AAAAAAAAAQABAAAAOAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAUAAAAKTAAADoAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAQAAAHgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAJAAAACQwwAA FAAAAAAAAAAAAAAAoJAAACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACHd3d3d3d3d3d3d3cAAAAAj//////////////3AAAAAI//////////////9w AAAACP/3d3d3d3d3d3f/cAAAAAj/9///f/d3/3d//3AAAAAI//f//3/3d/93f/9wAAAACP/3 d3d393f/d3//cAAAAAj/9///f/d3d3d//3AAAAAI//f//3/3d/93f/9wAAAACP/3d3d393f/ d3//cCgoKCgoKCgof////3d//3CCgoKCgoKCgn//9/////9wKP///////yh3d3d3d3//cIL/ ///4KCiCf//3//9//3Ao8oKCgvKCKH//9///f/9wgvgoKC8oL4J3d3d3d3//cCjygoLygo8o f//3//9//3CC/ygvKCgvgn//9///f/9wKP/y8oKP/yh3d3d3d3//cIL/LygoKP+Cf//3//9/ /3Ao8vKCgoKPKH//9///f/9wgvgoKPgoL4J3d3d3gAAAACjygo//go8o/////4//eACC//// ////gv////+P94AAKCgoKCgoKCh3d3//j3gAAIKCgoKCgoKC/////4eAAAAAAAAI//////// //+IAAAAAAAACP//////////gAAAAAAAAAiIiIiIiIiIiIAAAAD///////////4AAAD+AAAA /gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAMAAAAHAAAAD/4AAB/+AAA/ /gAAf4iTAAAAAAEAAQAgIBAAAQAEAOgCAAABAAAAAAAAAAAAAAAAADDEAAAIxAAAAAAAAAAA AAAAAAAAPcQAABjEAAAAAAAAAAAAAAAAAABKxAAAIMQAAAAAAAAAAAAAAAAAAFbEAAAoxAAA AAAAAAAAAAAAAAAAAAAAAAAAAABgxAAAbsQAAH7EAAAAAAAAjMQAAAAAAACaxAAAAAAAAKrE AAAAAAAAS0VSTkVMMzIuRExMAGFkdmFwaTMyLmRsbABTSEVMTDMyLmRsbAB1c2VyMzIuZGxs AABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3Nl S2V5AAAAU2hlbGxFeGVjdXRlQQAAAEZpbmRXaW5kb3dBAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwECFAAKAAAAAADgblww Sh/MnQA+AAAAPgAADAAAAAAAAAAAACAAAAAAAAAAbHBydWZ4d3QuZXhlUEsFBgAAAAABAAEA OgAAACo+AAAAAA== ----------yhqgcgxxtshwwqyksqdw-- From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 12:04:54 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0669216A4CF for ; Sat, 28 Feb 2004 12:04:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-ia64@freebsd.org To: freebsd-amd64@freebsd.org Message-ID: Date: Sat, 28 Feb 2004 12:04:45 -0800 Precedence: bulk X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-ia64@freebsd.org Errors-To: owner-freebsd-ia64@freebsd.org Subject: Your message to freebsd-ia64 awaits moderator approval X-BeenThere: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 20:04:54 -0000 Your mail to 'freebsd-ia64' with the subject Jessica Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-ia64/c2cd8bdbd29f776a6118452aeb29d93022e7b341 PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 15:01:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B014316A4CE; Sat, 28 Feb 2004 15:01:42 -0800 (PST) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67B9643D2D; Sat, 28 Feb 2004 15:01:42 -0800 (PST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E12F77303A; Sat, 28 Feb 2004 18:01:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040228230141.E12F77303A@freebsd-current.sentex.ca> Date: Sat, 28 Feb 2004 18:01:41 -0500 (EST) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 23:01:42 -0000 TB --- 2004-02-28 22:09:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-02-28 22:09:39 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-02-28 22:09:39 - checking out the source tree TB --- 2004-02-28 22:09:39 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-02-28 22:09:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-02-28 22:13:33 - building world TB --- 2004-02-28 22:13:33 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-28 22:13:33 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2004-02-28 23:00:37 - building generic kernel TB --- 2004-02-28 23:00:37 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-02-28 23:00:37 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Feb 28 23:00:37 GMT 2004 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/other/tinderbox/CURRENT/amd64/amd64/src/sys -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/utalloc.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/other/tinderbox/CURRENT/amd64/amd64/src/sys -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/utclib.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/other/tinderbox/CURRENT/amd64/amd64/src/sys -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/utcopy.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/other/tinderbox/CURRENT/amd64/amd64/src/sys -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/utdebug.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/other/tinderbox/CURRENT/amd64/amd64/src/sys -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/utdelete.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/other/tinderbox/CURRENT/amd64/amd64/src/sys -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/uteval.c /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/uteval.c: In function `AcpiUtExecute_Sxds': /other/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/uteval.c:702: warning: cast discards qualifiers from pointer target type *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/obj/amd64/other/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /other/tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-02-28 23:01:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-02-28 23:01:41 - ERROR: failed to build generic kernel TB --- 2004-02-28 23:01:41 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 16:33:23 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1624016A501; Sat, 28 Feb 2004 16:33:23 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA56943D2F; Sat, 28 Feb 2004 16:33:20 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1T0XGOJ030558; Sat, 28 Feb 2004 16:33:16 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1T0XFZR030551; Sat, 28 Feb 2004 16:33:15 -0800 (PST) (envelope-from obrien) Date: Sat, 28 Feb 2004 16:33:15 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20040229003315.GA30407@dragon.nuxi.com> References: <20040227111802.6E9807303A@freebsd-current.sentex.ca> <20040227143505.GA2685@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040227143505.GA2685@ip.net.ua> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: amd64@FreeBSD.org Subject: Re: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 00:33:23 -0000 On Fri, Feb 27, 2004 at 04:35:05PM +0200, Ruslan Ermilov wrote: > On Fri, Feb 27, 2004 at 01:34:09PM +0100, Dag-Erling Sm?rgrav wrote: > > FreeBSD Tinderbox writes: > > > FYI: static unit limits for vcoda are set: NVCODA=4 > > > config: Error: device "cy" is unknown > > > config: 1 errors > > > WARNING: kernel contains GPL contaminated ext2fs filesystem > > > *** Error code 1 > > > > Is somebody going to fix this? > > > David maybe, who brought it up recently to amd64/NOTES? I'm fixing it this weekend. From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 16:34:25 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D44516A4CE; Sat, 28 Feb 2004 16:34:25 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E79F43D31; Sat, 28 Feb 2004 16:34:25 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1T0YOOJ030591; Sat, 28 Feb 2004 16:34:24 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1T0YO7s030590; Sat, 28 Feb 2004 16:34:24 -0800 (PST) (envelope-from obrien) Date: Sat, 28 Feb 2004 16:34:23 -0800 From: "David O'Brien" To: Peter Wemm Message-ID: <20040229003423.GB30407@dragon.nuxi.com> References: <20040227111802.6E9807303A@freebsd-current.sentex.ca> <20040227143505.GA2685@ip.net.ua> <200402271423.01374.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402271423.01374.peter@wemm.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: amd64@freebsd.org cc: Ruslan Ermilov cc: freebsd-amd64@freebsd.org Subject: Re: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 00:34:25 -0000 On Fri, Feb 27, 2004 at 02:23:01PM -0800, Peter Wemm wrote: > Actually, David has utterly hosed amd64/conf/NOTES. He's spammed the > working copy with a completely and utterly bogus version that he NOTES wasn't suspose to exist yet -- we an agreement about it I won't bring up here. I'll do something about it this weekend. From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 28 16:34:25 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D44516A4CE; Sat, 28 Feb 2004 16:34:25 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E79F43D31; Sat, 28 Feb 2004 16:34:25 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1T0YOOJ030591; Sat, 28 Feb 2004 16:34:24 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1T0YO7s030590; Sat, 28 Feb 2004 16:34:24 -0800 (PST) (envelope-from obrien) Date: Sat, 28 Feb 2004 16:34:23 -0800 From: "David O'Brien" To: Peter Wemm Message-ID: <20040229003423.GB30407@dragon.nuxi.com> References: <20040227111802.6E9807303A@freebsd-current.sentex.ca> <20040227143505.GA2685@ip.net.ua> <200402271423.01374.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402271423.01374.peter@wemm.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: amd64@freebsd.org cc: Ruslan Ermilov cc: freebsd-amd64@freebsd.org Subject: Re: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Feb 2004 00:34:25 -0000 On Fri, Feb 27, 2004 at 02:23:01PM -0800, Peter Wemm wrote: > Actually, David has utterly hosed amd64/conf/NOTES. He's spammed the > working copy with a completely and utterly bogus version that he NOTES wasn't suspose to exist yet -- we an agreement about it I won't bring up here. I'll do something about it this weekend.