From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 22 02:06:12 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org 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 A825B16A41F for ; Sun, 22 Jan 2006 02:06:12 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32910.mail.mud.yahoo.com (web32910.mail.mud.yahoo.com [68.142.206.57]) by mx1.FreeBSD.org (Postfix) with SMTP id 3486343D46 for ; Sun, 22 Jan 2006 02:06:12 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 88640 invoked by uid 60001); 22 Jan 2006 02:06:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=3g70P7O5QIpOHN9Kib6AV2N5FwikzIZ2t5GxjSBnz5nucbyoN/WQl/n64N2K1JVE+XdgoKeTVMH2GBNB/h4WKMz8VIVWmWRMmjtb1kI+toF9krBDDoCCwR3VYN4KmIGWH3yoR/G5Wu6XY630YTOsUwWY3OKCCk0bHhwwia3fR8k= ; Message-ID: <20060122020611.88638.qmail@web32910.mail.mud.yahoo.com> Received: from [69.79.134.72] by web32910.mail.mud.yahoo.com via HTTP; Sun, 22 Jan 2006 03:06:11 CET Date: Sun, 22 Jan 2006 03:06:11 +0100 (CET) From: To: freebsd-amd64@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Cc: Subject: amd64 vs x86_64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2006 02:06:12 -0000 Hi; I wonder if anyone builds gcc without the port: I was building a preliminary g95 port and after some time trying to find out why "amd64" is not understood by gcc I found this in the gcc4* ports: .if ${ARCH} == "amd64" CONFIGURE_TARGET= x86_64-portbld-freebsd${OSREL} .else CONFIGURE_TARGET= ${ARCH}-portbld-freebsd${OSREL} .endif Since this is not part of bsd.port.mk, I guess this is a workaround... so... where should it be fixed, in configure/autoconf, or renaming the architecture ? cheers, Pedro. ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 22 02:49:16 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 9A89416A440 for ; Sun, 22 Jan 2006 02:49:16 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36F9643D45 for ; Sun, 22 Jan 2006 02:49:16 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0M2nFSs003242; Sat, 21 Jan 2006 18:49:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0M2nFRS003241; Sat, 21 Jan 2006 18:49:15 -0800 (PST) (envelope-from sgk) Date: Sat, 21 Jan 2006 18:49:15 -0800 From: Steve Kargl To: pfgshield-freebsd@yahoo.com Message-ID: <20060122024915.GA3225@troutmask.apl.washington.edu> References: <20060122020611.88638.qmail@web32910.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060122020611.88638.qmail@web32910.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 vs x86_64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 02:49:16 -0000 On Sun, Jan 22, 2006 at 03:06:11AM +0100, pfgshield-freebsd@yahoo.com wrote: > > I wonder if anyone builds gcc without the port: I build gcc 10 to 20 times a week. This includes both the 4.1 branch and trunk. Configure automatically picks up the architecture. > I was building a preliminary g95 port. Have you tried gfortran? It is a part of GCC. I use 4.1 (pre-release) gfortran everyday. I routinely build and test gfortran from gcc trunk. -- Steve From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 22 03:39:41 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 7E9AF16A41F for ; Sun, 22 Jan 2006 03:39:41 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32915.mail.mud.yahoo.com (web32915.mail.mud.yahoo.com [68.142.206.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 0094A43D45 for ; Sun, 22 Jan 2006 03:39:40 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 82394 invoked by uid 60001); 22 Jan 2006 03:39:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qg/vYhmKKhceoPusVDJhuJFQwFn1x6xCLJjM5K7xRhIvCoTeBO0gtRN6xZBlLa+j2sJWXdXzHse/aHxC7DmSNnCrzOziJVr0GQ30fIgvB0aP0Q5BEh6Cz48J4M078gavh7LBuYLg9J25fXZdqzeq4iDnf5P1Wt+vflBoLhDo/Vs= ; Message-ID: <20060122033939.82391.qmail@web32915.mail.mud.yahoo.com> Received: from [69.79.134.72] by web32915.mail.mud.yahoo.com via HTTP; Sun, 22 Jan 2006 04:39:39 CET Date: Sun, 22 Jan 2006 04:39:39 +0100 (CET) From: To: freebsd-amd64@freebsd.org In-Reply-To: <20060122024915.GA3225@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: amd64 vs x86_64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2006 03:39:41 -0000 --- Steve Kargl ha scritto: > On Sun, Jan 22, 2006 at 03:06:11AM +0100, pfgshield-freebsd@yahoo.com wrote: > > > > I wonder if anyone builds gcc without the port: > > I build gcc 10 to 20 times a week. This includes > both the 4.1 branch and trunk. Configure automatically > picks up the architecture. > Hmm...I extracted the gcc40 port here and it didn't finish the build without changing the arch to x86_64. Still it was very strange to find the same lines on all the gcc4x ports. > > I was building a preliminary g95 port. > > Have you tried gfortran? It is a part of GCC. I use 4.1 > (pre-release) gfortran everyday. I routinely build and > test gfortran from gcc trunk. > Yes. I'm in the process of porting Elmer: http://www.csc.fi/elmer/ Last week the Elmer developers were recommending g95 and even mentioned that gfortran40 (which is the one of the ports tree) was not building Elmer. This week they had problems with g95 and now they are recommending gfortran. I tried gfortran41 and I'm having some issues with a module but it's not gfortran's fault: while they fix the issue I though I should try to build g95 on amd64 JIC. cheers, Pedro. ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 22 04:30:35 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 20F0F16A429 for ; Sun, 22 Jan 2006 04:30:35 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id C606A43D46 for ; Sun, 22 Jan 2006 04:30:34 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0M4UYcb003778; Sat, 21 Jan 2006 20:30:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0M4UYwA003777; Sat, 21 Jan 2006 20:30:34 -0800 (PST) (envelope-from sgk) Date: Sat, 21 Jan 2006 20:30:34 -0800 From: Steve Kargl To: pfgshield-freebsd@yahoo.com Message-ID: <20060122043034.GA3760@troutmask.apl.washington.edu> References: <20060122024915.GA3225@troutmask.apl.washington.edu> <20060122033939.82391.qmail@web32915.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060122033939.82391.qmail@web32915.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 vs x86_64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 04:30:35 -0000 On Sun, Jan 22, 2006 at 04:39:39AM +0100, pfgshield-freebsd@yahoo.com wrote: > > --- Steve Kargl ha scritto: > > > On Sun, Jan 22, 2006 at 03:06:11AM +0100, pfgshield-freebsd@yahoo.com wrote: > > > > > > I wonder if anyone builds gcc without the port: > > > > I build gcc 10 to 20 times a week. This includes > > both the 4.1 branch and trunk. Configure automatically > > picks up the architecture. > > > > Hmm...I extracted the gcc40 port here and it didn't finish the build without > changing the arch to x86_64. Still it was very strange to find the same lines > on all the gcc4x ports. Build it from GCC sources. Don't use the gcc40. > > > I was building a preliminary g95 port. > > > > Have you tried gfortran? It is a part of GCC. I use 4.1 > > (pre-release) gfortran everyday. I routinely build and > > test gfortran from gcc trunk. > > > Yes. I'm in the process of porting Elmer: > http://www.csc.fi/elmer/ > Last week the Elmer developers were recommending g95 and even mentioned that > gfortran40 (which is the one of the ports tree) was not building Elmer. This > week they had problems with g95 and now they are recommending gfortran. Don't use gfortran40. You want at least 4.1 pre-release. -- Steve From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 23 11:02:30 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 85EA316A41F for ; Mon, 23 Jan 2006 11:02:30 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7100143D46 for ; Mon, 23 Jan 2006 11:02:19 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0NB2Iuu086165 for ; Mon, 23 Jan 2006 11:02:18 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0NB2Hsg086159 for freebsd-amd64@freebsd.org; Mon, 23 Jan 2006 11:02:17 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 Jan 2006 11:02:17 GMT Message-Id: <200601231102.k0NB2Hsg086159@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 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 11:02:30 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/08/09] amd64/84693 amd64 Keyboard not recognized during first step o [2005/11/17] amd64/89202 amd64 [ufs] [panic] Kernel crash when accessing 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/07/28] amd64/69704 amd64 ext2/ext3 unstable in amd64 o [2004/07/28] amd64/69707 amd64 IPC32 dont work OK in amd64 FreeBSD o [2004/09/07] amd64/71471 amd64 Can not install 5.3beta3/amd64 on IBM eSe o [2004/09/12] amd64/71644 amd64 [panic] amd64 5.3-BETA4 crash when heavy o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see o [2004/10/30] amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdo o [2004/11/07] amd64/73650 amd64 5.3-release panics on boot o [2004/11/10] amd64/73775 amd64 Kernel panic (trap 12) when booting with o [2004/11/16] amd64/74014 amd64 5.3-RELEASE-AMD64 freezes on boot during o [2004/12/05] amd64/74747 amd64 System panic on shutdown when process wil o [2004/12/18] amd64/75209 amd64 5.3-Release panics on attempted boot from o [2004/12/23] amd64/75417 amd64 ACPI: SATA Hard-disk o [2005/01/12] amd64/76136 amd64 system halts before reboot o [2005/01/17] amd64/76336 amd64 racoon/setkey -D cases instant "Fatal Tra o [2005/02/02] amd64/77011 amd64 consisten 5.3-p5 make crash on installwor o [2005/02/23] amd64/77949 amd64 Pb boot FreeBSD 64 o [2005/03/04] amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/p o [2005/03/07] amd64/78558 amd64 installation o [2005/03/14] amd64/78848 amd64 [sis] sis driver on FreeBSD 5.x does not o [2005/04/12] amd64/79813 amd64 Will not install/run on amd64 nForce 4 pl o [2005/04/19] amd64/80114 amd64 kldload snd_ich causes interrupt storm wh o [2005/05/06] amd64/80691 amd64 amd64 kernel hangs on load o [2005/05/14] amd64/81037 amd64 SATA problem o [2005/05/28] amd64/81602 amd64 SATA crashes with parallel pcm access o [2005/06/09] amd64/82071 amd64 incorrect -march's parameter to build 32b o [2005/06/19] amd64/82425 amd64 [fxp] fxp0: device timeout, fxp interface o [2005/06/23] amd64/82555 amd64 Kernel Panic - after i connect to my "amd o [2005/07/05] amd64/83005 amd64 Memory Occupied during installation of th o [2005/08/12] amd64/84832 amd64 Installation crashes just at boot AMD64/ o [2005/08/14] amd64/84930 amd64 [msdosfs] something wrong with msdosfs on o [2005/08/29] amd64/85431 amd64 AMD64 has short but temporary freezes (ha o [2005/08/29] amd64/85451 amd64 [hang] 6.0-BETA3 lockups on AMD64 (PREEMP o [2005/09/13] amd64/86080 amd64 [radeon] [hang] radeon DRI causes system o [2005/09/23] amd64/86503 amd64 [atapicam] [panic] k3b crash the system l o [2005/10/09] amd64/87156 amd64 First Installation: Kernel crashes o [2005/10/11] amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Are o [2005/10/12] amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powe o [2005/10/12] amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD a [2005/10/12] amd64/87328 amd64 [boot] BTX halted error o [2005/10/12] amd64/87348 amd64 amd64+smp+startkde always crashing o [2005/10/15] amd64/87472 amd64 I downloaded 5.4 and went to install it, o [2005/10/16] amd64/87514 amd64 6.0-CURRENT freezes machine using >4GB on o [2005/10/19] amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron o [2005/10/25] amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock c o [2005/10/31] amd64/88299 amd64 swapcontext fails with errno 0 o [2005/11/06] amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not b f [2005/11/09] amd64/88746 amd64 Buffer problem with SSH2 under amd64 arch o [2005/11/10] amd64/88790 amd64 kernel panic on first boot (after the Fre o [2005/11/24] amd64/89501 amd64 System crashes on install using ftp on lo o [2005/11/24] amd64/89503 amd64 Cant Boot Installation Disk o [2005/11/25] amd64/89546 amd64 [geom] GEOM error o [2005/11/25] amd64/89549 amd64 [amd64] nve timeouts on 6.0-release o [2005/11/25] amd64/89550 amd64 [amd64] sym0: VTOBUS failed (6.0 Release) o [2005/12/05] amd64/89968 amd64 [ata] Asus A8N-E MediaShield RAID problem o [2005/12/22] amd64/90798 amd64 asking if motherboard is compatible o [2006/01/06] amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr o [2006/01/08] amd64/91492 amd64 BTX halted 58 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/01/11] amd64/61209 amd64 ppc0: cannot reserve I/O port range o [2004/02/21] amd64/63188 amd64 [ti] ti(4) broken on amd64 o [2004/07/28] amd64/69705 amd64 IPC problem (msq_queues) o [2004/12/02] amd64/74608 amd64 [mpt] [hang] mpt hangs 5 minutes when boo o [2004/12/07] amd64/74811 amd64 [nfs] df, nfs mount, negative Avail -> 32 o [2004/12/13] ports/75015 amd64 cvsup on amd64 coredumps with either runs o [2005/03/17] amd64/78954 amd64 kerberos 5 failed to build o [2005/06/18] amd64/82399 amd64 MSI K8N Neo4 Platinium is not supported o [2005/08/07] amd64/84652 amd64 kbdmap -r dumps core o [2005/08/20] amd64/85144 amd64 Asus K8S-MX mobo, integ LAN not recognize o [2005/09/06] amd64/85812 amd64 "Rebooting..." on serial console appears o [2005/09/07] amd64/85820 amd64 1.5 times slower performance with SCHED_U o [2005/10/23] amd64/87882 amd64 emu10k1 and APCI on amd64 is just noisy o [2005/11/09] amd64/88730 amd64 kernel panics during booting from the ins o [2006/01/02] amd64/91195 amd64 FreeBSD 6.0(amd64) and Asus A8R-MVP o [2006/01/09] amd64/91571 amd64 amd64 startup not initializing 32-bit lib o [2006/01/18] amd64/91966 amd64 an error in config of kernel 17 problems total. From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 17:54:05 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 A8B1216A420 for ; Tue, 24 Jan 2006 17:54:05 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56D2943D45 for ; Tue, 24 Jan 2006 17:54:05 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 22C55F80F for ; Tue, 24 Jan 2006 10:54:02 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id CA01FF805 for ; Tue, 24 Jan 2006 10:54:01 -0700 (MST) Date: Tue, 24 Jan 2006 11:03:34 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060124110334.40e81208.kgunders@teamcool.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 17:54:05 -0000 Greets Everyone: I was getting into a discussion the other day about this and decided to see what the FBSD amd64 gurus had to say about it. Given approximately equal cost of, for example, a single core Opteron150 (2.4GHz) and a dual core Opteron165 (1.8GHz) under what kind of situations would one be preferred over the other? fwiw- my friend asserts it will ALWAYS be the faster single core because of context switches and dual cores are optimized for highly multi- threaded OS's (e.g. WInblows). But 1) I think the scheduler has been improved in 6.0, and 2) he's a linuxer. And yes, I know what AMD has to say on this but am interested in the FBSD community's perspective on this w.r.t. FBSD. TIA -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 18:09:10 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 C36D616A41F for ; Tue, 24 Jan 2006 18:09:10 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD5A743D58 for ; Tue, 24 Jan 2006 18:09:08 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from [192.168.245.40] ([213.112.167.229] [213.112.167.229]) by mxfep02.bredband.com with ESMTP id <20060124180907.DICV2008.mxfep02.bredband.com@[192.168.245.40]>; Tue, 24 Jan 2006 19:09:07 +0100 Message-ID: <43D66D52.2090008@bredband.net> Date: Tue, 24 Jan 2006 19:09:22 +0100 From: Lars Tunkrans User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.12) Gecko/20051118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Gunderson References: <20060124110334.40e81208.kgunders@teamcool.net> In-Reply-To: <20060124110334.40e81208.kgunders@teamcool.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 18:09:10 -0000 Ken Gunderson wrote: >Greets Everyone: > >I was getting into a discussion the other day about this and decided to >see what the FBSD amd64 gurus had to say about it. Given approximately >equal cost of, for example, a single core Opteron150 (2.4GHz) and a >dual core Opteron165 (1.8GHz) under what kind of situations would >one be preferred over the other? > >fwiw- my friend asserts it will ALWAYS be the faster single core because >of context switches and dual cores are optimized for highly multi- >threaded OS's (e.g. WInblows). But 1) I think the scheduler has been >improved in 6.0, and 2) he's a linuxer. > >And yes, I know what AMD has to say on this but am interested in the >FBSD community's perspective on this w.r.t. FBSD. > >TIA > > > The DUAL core will be prefferd for Webservers, Application servers, and databases that are multithreaded and transaction oriented. The singel Core will be preffered for Simulations, Compute intensive stuff - image Rendering , Games , that are singel threaded. //Lars From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 18:38:27 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 B5F7516A420 for ; Tue, 24 Jan 2006 18:38:27 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58A9043D46 for ; Tue, 24 Jan 2006 18:38:27 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id B5BDAF80F; Tue, 24 Jan 2006 11:38:26 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 7AEB4F805; Tue, 24 Jan 2006 11:38:26 -0700 (MST) Date: Tue, 24 Jan 2006 11:47:45 -0700 From: Ken Gunderson To: Lars Tunkrans Message-Id: <20060124114745.561f4e31.kgunders@teamcool.net> In-Reply-To: <43D66D52.2090008@bredband.net> References: <20060124110334.40e81208.kgunders@teamcool.net> <43D66D52.2090008@bredband.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 18:38:27 -0000 On Tue, 24 Jan 2006 19:09:22 +0100 Lars Tunkrans wrote: > Ken Gunderson wrote: > > >Greets Everyone: > > > >I was getting into a discussion the other day about this and decided to > >see what the FBSD amd64 gurus had to say about it. Given approximately > >equal cost of, for example, a single core Opteron150 (2.4GHz) and a > >dual core Opteron165 (1.8GHz) under what kind of situations would > >one be preferred over the other? > > > >fwiw- my friend asserts it will ALWAYS be the faster single core because > >of context switches and dual cores are optimized for highly multi- > >threaded OS's (e.g. WInblows). But 1) I think the scheduler has been > >improved in 6.0, and 2) he's a linuxer. > > > >And yes, I know what AMD has to say on this but am interested in the > >FBSD community's perspective on this w.r.t. FBSD. > > > >TIA > > > > > > > The DUAL core will be prefferd for Webservers, Application servers, > and databases > that are multithreaded and transaction oriented. That was his point- precious few of these exist in FOSS, e.g. X, anything Python based, etc. I thought, even so, the dual cores will benefit at higher concurrency (just not quite as good a dual CPU). Then enter his comment that "context switching on FBSD sucks.. Blah, blah, blah..." Moreover, he's more of a workstation than server dude and in this respect the faster single core may have an edge. But extending his ALWAYS to include servers I think he's over stepping. > The singel Core will be preffered for Simulations, Compute intensive > stuff - image Rendering , > Games , that are singel threaded. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 19:08:28 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 5CB1616A420 for ; Tue, 24 Jan 2006 19:08:28 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id E06E943D72 for ; Tue, 24 Jan 2006 19:08:26 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from [192.168.245.40] ([213.112.167.229] [213.112.167.229]) by mxfep02.bredband.com with ESMTP id <20060124190825.ECIH2008.mxfep02.bredband.com@[192.168.245.40]>; Tue, 24 Jan 2006 20:08:25 +0100 Message-ID: <43D67B38.2040104@bredband.net> Date: Tue, 24 Jan 2006 20:08:40 +0100 From: Lars Tunkrans User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.12) Gecko/20051118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Gunderson References: <20060124110334.40e81208.kgunders@teamcool.net> <43D66D52.2090008@bredband.net> <20060124114745.561f4e31.kgunders@teamcool.net> In-Reply-To: <20060124114745.561f4e31.kgunders@teamcool.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 19:08:28 -0000 Ken Gunderson wrote: >On Tue, 24 Jan 2006 19:09:22 +0100 >Lars Tunkrans wrote: > > > >>Ken Gunderson wrote: >> >> >> >>>Greets Everyone: >>> >>>I was getting into a discussion the other day about this and decided to >>>see what the FBSD amd64 gurus had to say about it. Given approximately >>>equal cost of, for example, a single core Opteron150 (2.4GHz) and a >>>dual core Opteron165 (1.8GHz) under what kind of situations would >>>one be preferred over the other? >>> >>> >>> >>The DUAL core will be prefferd for Webservers, Application servers, >>and databases >>that are multithreaded and transaction oriented. >> >> > >That was his point- precious few of these exist in FOSS, e.g. X, >anything Python based, etc. I thought, even so, the dual cores will >benefit at higher concurrency (just not quite as good a dual CPU). >Then enter his comment that "context switching on FBSD sucks.. >Blah, blah, blah..." > > Really ? your friend should know that when you deploy apache/tomcat you always start several instance of the httpd servers. Even if they individually where completly singel threaded, starting the normal 5 to 10 httpd's on a dualcore would double the throughput, ( not the performance ) compared to a single core CPU, provided you dont have other bottlenecks in the architecure, like too few diskdrives, aso. And provided that you get enough http requests to use the added processing power. Context switching will take the same time per-proccess regardless of the number of CPU's Remember that additional CPU's dont imply that things work faster. Only that you can do more OF THEM concurrently. Throughput increases, not individual task performance. //Lars From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 19:10:22 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 376BB16A41F for ; Tue, 24 Jan 2006 19:10:22 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50D743D6E for ; Tue, 24 Jan 2006 19:10:21 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id CECD4AD; Tue, 24 Jan 2006 13:10:20 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id B6E3C61C2B; Tue, 24 Jan 2006 13:10:19 -0600 (CST) Date: Tue, 24 Jan 2006 13:10:19 -0600 From: "Matthew D. Fuller" To: Ken Gunderson Message-ID: <20060124191019.GE34914@over-yonder.net> References: <20060124110334.40e81208.kgunders@teamcool.net> <43D66D52.2090008@bredband.net> <20060124114745.561f4e31.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060124114745.561f4e31.kgunders@teamcool.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 19:10:22 -0000 On Tue, Jan 24, 2006 at 11:47:45AM -0700 I heard the voice of Ken Gunderson, and lo! it spake thus: > > That was his point- precious few of these exist in FOSS, e.g. X, > anything Python based, etc. Don't focus on threading, focus on processing. X is certainly going to gain from multiprocessors, because you've got multiple processes (at least the X server and a client) running. Web servers will gain because you can run things on multiple processors. Me, I'd always take the double. Life's too short to run one process at a time. Dual-core is not remotely as crippled as HT. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 19:45:34 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 06A2416A420 for ; Tue, 24 Jan 2006 19:45:34 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8BAF43D45 for ; Tue, 24 Jan 2006 19:45:33 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 9BEA7F80F for ; Tue, 24 Jan 2006 12:45:32 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 506F0F805 for ; Tue, 24 Jan 2006 12:45:32 -0700 (MST) Date: Tue, 24 Jan 2006 12:54:30 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060124125430.461be737.kgunders@teamcool.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Tyan K8SRE X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 19:45:34 -0000 A while back there were some comments regarding issues with this board. IIRC, some BIOS updates were subsequently released wh/were supposed to address these issues? There's not info about them on the fbsd amd mainboard compat page. Anyone running one of these can report in? TIA-- -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 21:30:30 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 2500D16A41F for ; Tue, 24 Jan 2006 21:30:30 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 782C543D53 for ; Tue, 24 Jan 2006 21:30:29 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail27.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0OLUO02029638 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 Jan 2006 08:30:27 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id k0OLUOHh039167; Wed, 25 Jan 2006 08:30:24 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id k0OLUL5H039166; Wed, 25 Jan 2006 08:30:21 +1100 (EST) (envelope-from pjeremy) Date: Wed, 25 Jan 2006 08:30:21 +1100 From: Peter Jeremy To: Ken Gunderson Message-ID: <20060124213021.GY25397@cirb503493.alcatel.com.au> References: <20060124110334.40e81208.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060124110334.40e81208.kgunders@teamcool.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 21:30:30 -0000 On Tue, 2006-Jan-24 11:03:34 -0700, Ken Gunderson wrote: >I was getting into a discussion the other day about this and decided to >see what the FBSD amd64 gurus had to say about it. Given approximately >equal cost of, for example, a single core Opteron150 (2.4GHz) and a >dual core Opteron165 (1.8GHz) under what kind of situations would >one be preferred over the other? Unless you're running exactly one single-threaded CPU-intensive task, the dual cores would provide greater total CPU power. (As others have pointed out, this may or may not be usable, depending on where the system bottlenecks are). On a server, your virtually always going to have multiple processes competing for resources. Even on a workstation, the Xserver is competing for resources with your application. >fwiw- my friend asserts it will ALWAYS be the faster single core The truth of this statement is highly dependent on exactly what 'it' is. As always, the best benchmark is your own application set. > because of context switches An SMP system should never have more context switches - since you've got multiple processes running simultaneously, you may have fewer. Consider "a|b" - on an SMP system this need never generate context switches because both processes can run (conceptually - in practice there will be other processes so you will get context switches). > and dual cores are optimized for highly multi- >threaded OS's (e.g. WInblows). I don't see how this follows. Dual core is basically the same as having two physical CPUs and it's difficult to see how optimisations for one OS would not help other OSs. (This differs from HTT where the scheduler needed to understand HTT limitations to be able to successfully utilise HTT - and I believe Winbloze did, whereas I don't believe any FOSS did). -- Peter Jeremy From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 22:34:45 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 41B8F16A41F for ; Tue, 24 Jan 2006 22:34:45 +0000 (GMT) (envelope-from r.mahoney@iconz.co.nz) Received: from frigg.iconz.co.nz (etrn.iconz.co.nz [210.48.22.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id C442943D48 for ; Tue, 24 Jan 2006 22:34:44 +0000 (GMT) (envelope-from r.mahoney@iconz.co.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by frigg.iconz.co.nz (Postfix) with ESMTP id 0BA902106A; Wed, 25 Jan 2006 11:34:41 +1300 (NZDT) Received: from frigg.iconz.co.nz ([127.0.0.1]) by localhost (frigg [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31419-17; Wed, 25 Jan 2006 11:34:36 +1300 (NZDT) Received: from 192.168.1.3 (firewall.indica-et-buddhica.org [210.48.84.26]) by frigg.iconz.co.nz (Postfix) with ESMTP id 9186D2099E; Wed, 25 Jan 2006 11:19:45 +1300 (NZDT) From: Richard MAHONEY To: Ken Gunderson In-Reply-To: <20060124110334.40e81208.kgunders@teamcool.net> References: <20060124110334.40e81208.kgunders@teamcool.net> Content-Type: text/plain Message-Id: <1138141170.10892.2.camel@proliant> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Wed, 25 Jan 2006 11:19:30 +1300 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at frigg.iconz.co.nz Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 22:34:45 -0000 On Wed, 2006-01-25 at 07:03, Ken Gunderson wrote: > Greets Everyone: > > I was getting into a discussion the other day about this and decided to > see what the FBSD amd64 gurus had to say about it. Given approximately > equal cost of, for example, a single core Opteron150 (2.4GHz) and a > dual core Opteron165 (1.8GHz) under what kind of situations would > one be preferred over the other? > > fwiw- my friend asserts it will ALWAYS be the faster single core because > of context switches and dual cores are optimized for highly multi- > threaded OS's (e.g. WInblows). But 1) I think the scheduler has been > improved in 6.0, and 2) he's a linuxer. For Sun's take on the advantages of multi-core CPUs you might like to look at what they have to say about the T2000: http://www.sun.com/servers/coolthreads/t2000/ Best, Richard MAHONEY -- Richard MAHONEY | internet: http://indica-et-buddhica.org Littledene | telephone/telefax (man.): ++64 3 312 1699 Bay Road | cellular: ++64 27 482 9986 OXFORD, NZ | e-mail: r.mahoney[use"@"]iconz.co.nz From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 23:22:50 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 4F19116A422 for ; Tue, 24 Jan 2006 23:22:50 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F83343D6A for ; Tue, 24 Jan 2006 23:22:44 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 2D523F80F for ; Tue, 24 Jan 2006 16:22:44 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id EB376F805 for ; Tue, 24 Jan 2006 16:22:43 -0700 (MST) Date: Tue, 24 Jan 2006 16:30:36 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060124163036.61433c2e.kgunders@teamcool.net> In-Reply-To: <4372B9DB.4050706@meijome.net> References: <025a01c5e452$cb1d8d90$0200a8c0@lfarr> <4372B9DB.4050706@meijome.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Tyan GT24 - Thunder K8SRE mainboard X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 23:22:50 -0000 On Thu, 10 Nov 2005 14:09:15 +1100 Norberto Meijome wrote: > Lawrence Farr wrote: > >>hi there - i have said box, was running 6. just fine with the first > >>release of the BIOS . After updating to BIOS to the latest > >>one (had some > >>interesting upgrades), i started getting some errors about > >>ACPI PCI-PCI > >>memory (end < start)...are those the errors you were getting? still > >>trying to solve it :( I may start a separate thread if I can't figure > >>this one out soon. > > > > > > Yep, that's the ones. Never tried downgrading the BIOS, just checked > > it was the latest. > > > > > > ok - i can confirm installing v.1 of the BIOS fixes the issue. Haven't > tried with the one in between the latest and v1.0. > > The BIOS files are from > http://tyan.com/support/html/b_s2891.html > > * dmesg -a after booting verbose for working BIOS : > http://www.meijome.net/files/freebsd/amd64/OK_bios_2891v100.txt > > * dmesg -a after booting verbose new,not working BIOS : > http://www.meijome.net/files/freebsd/amd64/NOT_OK_bios_2891_201.txt > > Is it worth submitting a PR for this? what information do you / anyone > suggest is included in it? I'd love to be able to test more, but I can't > keep this box offline any longer. Would you mind elaborating on your current status with this box and what BIOS version you're referencing? Thanks. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 24 23:55:12 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 4542516A41F for ; Tue, 24 Jan 2006 23:55:12 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate1.pacific.net.sg (smtpgate1.pacific.net.sg [203.120.90.31]) by mx1.FreeBSD.org (Postfix) with SMTP id 09C6643D4C for ; Tue, 24 Jan 2006 23:55:10 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 2899 invoked from network); 24 Jan 2006 23:55:08 -0000 Received: from maxwell2.pacific.net.sg (203.120.90.192) by smtpgate1.pacific.net.sg with SMTP; 24 Jan 2006 23:55:08 -0000 Received: from [192.168.0.107] ([210.24.122.211]) by maxwell2.pacific.net.sg with ESMTP id <20060124235508.EKZE28656.maxwell2.pacific.net.sg@[192.168.0.107]>; Wed, 25 Jan 2006 07:55:08 +0800 Message-ID: <43D6BE24.40604@pacific.net.sg> Date: Wed, 25 Jan 2006 07:54:12 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Ken Gunderson References: <20060124110334.40e81208.kgunders@teamcool.net> In-Reply-To: <20060124110334.40e81208.kgunders@teamcool.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 23:55:12 -0000 Hi, Ken Gunderson wrote: > > fwiw- my friend asserts it will ALWAYS be the faster single core because > of context switches and dual cores are optimized for highly multi- the calculations will be faster but not the response. The second core will handle mouse and keyboard while the first does the computation. A average user will always believe a dual 1 GHz machine is faster than a single CPU 3 GHz machine as long as there is no complex computation. Erich From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 25 01:41:10 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 2825F16A41F for ; Wed, 25 Jan 2006 01:41:10 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0137A43D62 for ; Wed, 25 Jan 2006 01:41:03 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id C8819AD; Tue, 24 Jan 2006 19:41:02 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id DAA7961C2B; Tue, 24 Jan 2006 19:41:01 -0600 (CST) Date: Tue, 24 Jan 2006 19:41:01 -0600 From: "Matthew D. Fuller" To: Erich Dollansky Message-ID: <20060125014101.GG34914@over-yonder.net> References: <20060124110334.40e81208.kgunders@teamcool.net> <43D6BE24.40604@pacific.net.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D6BE24.40604@pacific.net.sg> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 01:41:10 -0000 On Wed, Jan 25, 2006 at 07:54:12AM +0800 I heard the voice of Erich Dollansky, and lo! it spake thus: > > A average user will always believe a dual 1 GHz machine is faster > than a single CPU 3 GHz machine as long as there is no complex > computation. Until early this month, I sat at a dual-proc 200MHz PPro every day for the last 7 years. If it were a single (heck, if it were a single 300MHz system), I couldn't have managed that long. As a dual... sure, Mozilla was unusable, and I'd just go to bed for big compiles, but interactive response was always good. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 25 13:01:33 2006 Return-Path: X-Original-To: amd64@freebsd.org 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 D384116A41F; Wed, 25 Jan 2006 13:01:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 476FB43D45; Wed, 25 Jan 2006 13:01:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k0PD1VvE007933; Wed, 25 Jan 2006 08:01:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id k0PD1VwI049447; Wed, 25 Jan 2006 08:01:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F140D7302F; Wed, 25 Jan 2006 08:01:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060125130130.F140D7302F@freebsd-current.sentex.ca> Date: Wed, 25 Jan 2006 08:01:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 13:01:34 -0000 TB --- 2006-01-25 11:11:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-01-25 11:11:46 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-01-25 11:11:46 - cleaning the object tree TB --- 2006-01-25 11:12:24 - checking out the source tree TB --- 2006-01-25 11:12:24 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-01-25 11:12:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-01-25 11:19:17 - building world (CFLAGS=-O2 -pipe) TB --- 2006-01-25 11:19:17 - cd /src TB --- 2006-01-25 11:19:17 - /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 >>> stage 5.1: building 32 bit shim libraries TB --- 2006-01-25 12:52:20 - generating LINT kernel config TB --- 2006-01-25 12:52:20 - cd /src/sys/amd64/conf TB --- 2006-01-25 12:52:20 - /usr/bin/make -B LINT TB --- 2006-01-25 12:52:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-01-25 12:52:20 - cd /src TB --- 2006-01-25 12:52:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 25 12:52:20 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -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 -finstrument-functions -Wno-inline /src/sys/kern/kern_jail.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -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 -finstrument-functions -Wno-inline /src/sys/kern/kern_kse.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -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 -finstrument-functions -Wno-inline /src/sys/kern/kern_kthread.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -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 -finstrument-functions -Wno-inline /src/sys/kern/kern_ktr.c /src/sys/kern/kern_ktr.c: In function `sysctl_debug_ktr_alq_enable': /src/sys/kern/kern_ktr.c:151: error: `KTR_WITNESS' undeclared (first use in this function) /src/sys/kern/kern_ktr.c:151: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_ktr.c:151: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-01-25 13:01:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-01-25 13:01:30 - ERROR: failed to build lint kernel TB --- 2006-01-25 13:01:30 - tinderbox aborted TB --- 1.34 user 6.66 system 6584.04 real From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 25 17:06:49 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 8826C16A41F for ; Wed, 25 Jan 2006 17:06:49 +0000 (GMT) (envelope-from antonfb@hesiod.org) Received: from paris.hesiod.org (cust.hesiod.org [66.219.69.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88E6343D6B for ; Wed, 25 Jan 2006 17:06:47 +0000 (GMT) (envelope-from antonfb@hesiod.org) Received: from [192.168.1.9] (atlas.hesiod.org [192.168.1.9]) by paris.hesiod.org (8.13.3/8.13.3) with ESMTP id k0PH6kIJ098718 for ; Wed, 25 Jan 2006 09:06:46 -0800 (PST) (envelope-from antonfb@hesiod.org) Message-ID: <43D7B026.10303@hesiod.org> Date: Wed, 25 Jan 2006 09:06:46 -0800 From: Jeff Anton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060114 X-Accept-Language: en-us, en-gb, en, fr-ca, fr-fr, fr MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 17:06:49 -0000 I just finished building an Opteron 165 on a Tyan K8E S2865AG2NRF. I'm confident that dual core was the right move for me. Now I have a couple of my own database and computational applications and I've added threading support to most of these applications. Matrix multiplication threads like a dream. Even database stuff which is just reading records and aggregating improved 25% realtime at a cost of 165% cpu time relative to 70% cpu time single threaded. (a lot more thread processing overhead with the db stuff to get computation done while another thread waits for disk I/O.) Just operationally, X seems more interactive, but moving windows seems sluggish I think because the mouse processing produces more intermediate move points giving a smooth but sluggish window move. Mozilla is using threads. W/FreeBSD 6.0 run 'top' then hit 'H' to see each thread. My Mozilla currently has five threads. I have not yet tried overclocking. I think the Opteron will be fine. When building the machine I ran for 15 minutes without the cpu fan due to bumping the fan cable. (A little concerned that the system ran at all) After 15 minutes of fanless operation the BIOS reported the CPU was 122 deg C. Hard to believe, but I burned my hand reattaching the fan power. For the record the issues I had with putting the system together were: 1. The 2865 MB came with a BIOS v 1.0 which does not recognize dual-core (reported unknown processor) flashed to v 3.01 2. Hard drives were delivered late so I did a test FreeBSD install with and old small (20Gbyte) disk. FreeBSD 6.0 seemed to install but then crashed with a divide by zero error. This is a reported problem with the ataraid driver I learned by searching this lists archives. However, I also tried moving a disk from a working FreeBSD 6.0/i386 installation and that also crashed with a divide by zero error at the same place. That this happened with both the amd64 kernel and the i386 kernel makes me think this is strictly a motherboard (nVidia 4) ataraid driver issue not a strictly amd64 issue. Maybe the bug report should be re-classified. I tried a disk with a working FreeBSD 5.4/i386 installation and that actually ran but did not find the onboard ethernet. 3. The INSTALL notes still have several references to using floppy disks even though there are no floppy disk images. 4. When my SATA disks came I tried the 3.0 Gb mode since the Tyan documentation claims the board supports that, but FreeBSD 6.0 reported SATA150 and crashed being unable to write to the disks. Changed disks to 1.5 Gb mode and they worked. (Actually I had one crash due to 'lost mount' which was a cable problem I think.) 5. The reported problem with X11 not working because of no 'sync on green' support is a minor problem at best. Lack of 'sync on green' is only an issue with component cableing not an SVGA cable. Mind you the onboard ATI Rage XL has only 8 Mbytes of SGRAM (Tyan documentation here is poor) so you can not run with much resolution using the onboard graphics. Jeff Anton From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 26 02:00:17 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3995316A420 for ; Thu, 26 Jan 2006 02:00:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A244343D46 for ; Thu, 26 Jan 2006 02:00:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0Q20EvY057375 for ; Thu, 26 Jan 2006 02:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0Q20E8S057374; Thu, 26 Jan 2006 02:00:14 GMT (envelope-from gnats) Resent-Date: Thu, 26 Jan 2006 02:00:14 GMT Resent-Message-Id: <200601260200.k0Q20E8S057374@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Clifford Cawthon Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCAC716A420 for ; Thu, 26 Jan 2006 01:52:40 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id F31B843D55 for ; Thu, 26 Jan 2006 01:52:39 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k0Q1qblO046981 for ; Thu, 26 Jan 2006 01:52:37 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k0Q1qbKI046978; Thu, 26 Jan 2006 01:52:37 GMT (envelope-from nobody) Message-Id: <200601260152.k0Q1qbKI046978@www.freebsd.org> Date: Thu, 26 Jan 2006 01:52:37 GMT From: Clifford Cawthon To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/92337: FreeBsd 6.0 Release Intel Pro 1000 MT em1 no buffer space available X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 02:00:17 -0000 >Number: 92337 >Category: amd64 >Synopsis: FreeBsd 6.0 Release Intel Pro 1000 MT em1 no buffer space available >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 26 02:00:14 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Clifford Cawthon >Release: FreeBsd 6.0 >Organization: >Environment: FreeBSD black.labmaster.com 6.0-RELEASE #0 - Wed Nov 2 19:07:38 UTC 2005 root@rat.samsco.home:/usr/obj/usr/src/sys/GENERIC amd64 >Description: The em1 interface which currently has nothing connected to it constantly produces the following error: routed[296]: Send bcast sendto (em1: 192.168.5.255.520): No buffer space available. >How-To-Repeat: The problem constantly available >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 26 18:24:54 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 6A62B16A422 for ; Thu, 26 Jan 2006 18:24:54 +0000 (GMT) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (c-67-168-241-176.hsd1.or.comcast.net [67.168.241.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05DC543D48 for ; Thu, 26 Jan 2006 18:24:53 +0000 (GMT) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (localhost.home.localnet [127.0.0.1]) by schitzo.solgatos.com (8.13.4/8.13.4) with ESMTP id k0QIOqqD003570 for ; Thu, 26 Jan 2006 10:24:53 -0800 Received: from sopwith.solgatos.com (uucp@localhost) by schitzo.solgatos.com (8.13.4/8.13.4/Submit) with UUCP id k0QIOqac003567 for freebsd-amd64@freebsd.org; Thu, 26 Jan 2006 10:24:52 -0800 Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id SAA28303; Thu, 26 Jan 2006 18:20:02 GMT Message-Id: <200601261820.SAA28303@sopwith.solgatos.com> To: freebsd-amd64@freebsd.org Date: Thu, 26 Jan 2006 10:20:02 +0000 From: Dieter Subject: Tyan 2865 (was: dual vs single core opteron 100's) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@sopwith.solgatos.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 Jan 2006 18:24:54 -0000 > 5. The reported problem with X11 not working because of no 'sync on green' > support is a minor problem at best. Lack of 'sync on green' is > only an issue with component cableing not an SVGA cable. > Mind you the onboard ATI Rage XL has only 8 Mbytes of SGRAM > (Tyan documentation here is poor) so you can not run with > much resolution using the onboard graphics. A workstation should be able to use a workstation class monitor. Many, probably most, workstation class CRT monitors require sync-on-green. A "SVGA cable" (I'm assuming you mean a HD-15 connector) is not an option if the monitor does not have an HD-15 input. Workstation monitors tend to have BNC or 13W3 connectors. HD-15 connectors are used on pee-cee class monitors and do not provide the bandwidth or shielding of BNC connectors. And users wanting a digital connection for a LCD are also out of luck. A modern workstation should provide at least DVI-I, and sync-on-green. A higher end workstation should add dual link and multi-head. The Tyan 2865 is mostly a workstation class board, except for the pee-cee class video and the pee-cee class buggy firmware. From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 26 20:01:49 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 2B08F16A422 for ; Thu, 26 Jan 2006 20:01:49 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DCB343D70 for ; Thu, 26 Jan 2006 20:01:35 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k0QK1Zie015618; Thu, 26 Jan 2006 12:01:35 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k0QK1YAq015617; Thu, 26 Jan 2006 12:01:34 -0800 Date: Thu, 26 Jan 2006 12:01:34 -0800 From: Brooks Davis To: Dieter Message-ID: <20060126200134.GE13079@odin.ac.hmc.edu> References: <200601261820.SAA28303@sopwith.solgatos.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="47eKBCiAZYFK5l32" Content-Disposition: inline In-Reply-To: <200601261820.SAA28303@sopwith.solgatos.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-amd64@freebsd.org Subject: Re: Tyan 2865 (was: dual vs single core opteron 100's) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 20:01:49 -0000 --47eKBCiAZYFK5l32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 26, 2006 at 10:20:02AM +0000, Dieter wrote: > > 5. The reported problem with X11 not working because of no 'sync on gre= en' > > support is a minor problem at best. Lack of 'sync on green' is > > only an issue with component cableing not an SVGA cable. > > Mind you the onboard ATI Rage XL has only 8 Mbytes of SGRAM > > (Tyan documentation here is poor) so you can not run with > > much resolution using the onboard graphics. >=20 > A workstation should be able to use a workstation class > monitor. Many, probably most, workstation class CRT monitors > require sync-on-green. A "SVGA cable" (I'm assuming you mean > a HD-15 connector) is not an option if the monitor does not > have an HD-15 input. Workstation monitors tend to have BNC > or 13W3 connectors. HD-15 connectors are used on pee-cee > class monitors and do not provide the bandwidth or shielding > of BNC connectors. And users wanting a digital connection > for a LCD are also out of luck. A modern workstation should > provide at least DVI-I, and sync-on-green. A higher end > workstation should add dual link and multi-head. >=20 > The Tyan 2865 is mostly a workstation class board, except for > the pee-cee class video and the pee-cee class buggy firmware. Integrated video is not intended to be workstation class. It's intended to be cheap. That's unlikely to change any time soon. -- 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 --47eKBCiAZYFK5l32 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFD2SqeXY6L6fI4GtQRAto8AJ4+7czfnU2KSsU2u8Ugm7GgYOZ3ngCfaXUG ZSPPBrIwdWxMtecnnMsn9eA= =SYM3 -----END PGP SIGNATURE----- --47eKBCiAZYFK5l32-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 26 20:21:37 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 80C4816A420 for ; Thu, 26 Jan 2006 20:21:37 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.178.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B80843D53 for ; Thu, 26 Jan 2006 20:21:36 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from [134.93.180.123] (ipamzra.Physik.Uni-Mainz.DE [134.93.180.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate2.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 83028300067B; Thu, 26 Jan 2006 21:21:35 +0100 (CET) Message-ID: <43D92F4F.8000702@uni-mainz.de> Date: Thu, 26 Jan 2006 21:21:35 +0100 From: "O. Hartmann" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lars Tunkrans References: <20060124110334.40e81208.kgunders@teamcool.net> <43D66D52.2090008@bredband.net> In-Reply-To: <43D66D52.2090008@bredband.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 20:21:37 -0000 Lars Tunkrans schrieb: > Ken Gunderson wrote: > >> Greets Everyone: >> >> I was getting into a discussion the other day about this and decided to >> see what the FBSD amd64 gurus had to say about it. Given approximately >> equal cost of, for example, a single core Opteron150 (2.4GHz) and a >> dual core Opteron165 (1.8GHz) under what kind of situations would >> one be preferred over the other? >> fwiw- my friend asserts it will ALWAYS be the faster single core because >> of context switches and dual cores are optimized for highly multi- >> threaded OS's (e.g. WInblows). But 1) I think the scheduler has been >> improved in 6.0, and 2) he's a linuxer. >> >> And yes, I know what AMD has to say on this but am interested in the >> FBSD community's perspective on this w.r.t. FBSD. >> >> TIA >> >> >> > The DUAL core will be prefferd for Webservers, Application servers, > and databases > that are multithreaded and transaction oriented. > The singel Core will be preffered for Simulations, Compute intensive > stuff - image Rendering , > Games , that are singel threaded. There are some performance tests around the net concerning povray. Povray performs much better on a dual core than a single CPU, if it is multithreaded. In many cases, such as modelling, numbercrunching, multi-core or multi CPU systems perform much better than single core/CPU systems! That depends higly on the way the programmer of the application has aimed multithreading. From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 03:04:25 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org 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 2195916A420 for ; Fri, 27 Jan 2006 03:04:25 +0000 (GMT) (envelope-from conrads@cox.net) Received: from eastrmmtao05.cox.net (eastrmmtao05.cox.net [68.230.240.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDE3143D49 for ; Fri, 27 Jan 2006 03:04:23 +0000 (GMT) (envelope-from conrads@cox.net) Received: from serene.no-ip.org ([68.14.59.177]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060127030429.WGWV14098.eastrmmtao05.cox.net@serene.no-ip.org> for ; Thu, 26 Jan 2006 22:04:29 -0500 Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.13.4/8.13.4) with ESMTP id k0R34A9M060279 for ; Thu, 26 Jan 2006 21:04:13 -0600 (CST) (envelope-from conrads@serene.no-ip.org) Received: (from conrads@localhost) by serene.no-ip.org (8.13.4/8.13.4/Submit) id k0R345uo060278 for freebsd-amd64@FreeBSD.org; Thu, 26 Jan 2006 21:04:05 -0600 (CST) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Thu, 26 Jan 2006 21:04:04 -0600 (CST) Sender: conrads@cox.net From: conrads@cox.net To: freebsd-amd64@FreeBSD.org Cc: Subject: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 03:04:25 -0000 In experimenting with running 32-bit apps, I've hit a snag: what to do about programs that require 32-bit X libraries? Is there any solution to this problem? -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 04:25:01 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 0624E16A420 for ; Fri, 27 Jan 2006 04:25:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A65E43D45 for ; Fri, 27 Jan 2006 04:25:00 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k0R4Ou07042456; Thu, 26 Jan 2006 21:24:56 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43D9A099.8060909@samsco.org> Date: Thu, 26 Jan 2006 21:24:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: conrads@cox.net References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 04:25:01 -0000 conrads@cox.net wrote: > In experimenting with running 32-bit apps, I've hit a snag: what to do about > programs that require 32-bit X libraries? > > Is there any solution to this problem? > Snag the xorg libraries package for i386 and unpack the appropriate libraries by hand into the lib32 directory. Maybe it makes sense to have a port that puts them into /usr/X11R6/lib32 or something. Scott From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 04:33:25 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 A309B16A420 for ; Fri, 27 Jan 2006 04:33:25 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6495643D45 for ; Fri, 27 Jan 2006 04:33:25 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 43A6E1A3C2A; Thu, 26 Jan 2006 20:33:25 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 57462521B9; Thu, 26 Jan 2006 23:33:24 -0500 (EST) Date: Thu, 26 Jan 2006 23:33:23 -0500 From: Kris Kennaway To: Scott Long Message-ID: <20060127043323.GA31513@xor.obsecurity.org> References: <43D9A099.8060909@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <43D9A099.8060909@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 04:33:25 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 26, 2006 at 09:24:57PM -0700, Scott Long wrote: > conrads@cox.net wrote: > >In experimenting with running 32-bit apps, I've hit a snag: what to do= =20 > >about > >programs that require 32-bit X libraries? > > > >Is there any solution to this problem? > > >=20 > Snag the xorg libraries package for i386 and unpack the appropriate=20 > libraries by hand into the lib32 directory. Maybe it makes sense to > have a port that puts them into /usr/X11R6/lib32 or something. What would be really cool would be a way to easily do this for any package. Kris --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD2aKTWry0BWjoQKURAm31AJ94E1ht9elbEtKLQq/7a8lckxpW1gCfVuCe acD9FOGXtYmkJXi7M9rY9gI= =Eu9P -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 08:29:04 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 6AEE516A424 for ; Fri, 27 Jan 2006 08:29:04 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1017B43D45 for ; Fri, 27 Jan 2006 08:29:04 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 74DE9F80F for ; Fri, 27 Jan 2006 01:29:03 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 2A40CF805 for ; Fri, 27 Jan 2006 01:29:03 -0700 (MST) Date: Fri, 27 Jan 2006 01:29:02 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060127012902.61e974dd.kgunders@teamcool.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: the jem report bashes fbsd-6.0 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 08:29:04 -0000 An older article I just happened across: Personally think he's far off the mark, e.g. "The AMD64 edition didn't work well on two systems. Since it has a long and inglorious history of severe stability problems that appear to have carried over into 6.0, I would strongly recommend using the i386 edition of FreeBSD instead of the AMD64 edition." Definitely not congruous with my experiences but then my amd64 systems are far from stressed:-) But thought I'd post the link in case someone wanted to address in more detail. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 08:44:33 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 008AE16A420 for ; Fri, 27 Jan 2006 08:44:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05BF243D64 for ; Fri, 27 Jan 2006 08:44:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id C42D51A3C1F; Fri, 27 Jan 2006 00:44:29 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1A78F52727; Fri, 27 Jan 2006 03:44:27 -0500 (EST) Date: Fri, 27 Jan 2006 03:44:27 -0500 From: Kris Kennaway To: Ken Gunderson Message-ID: <20060127084427.GA35556@xor.obsecurity.org> References: <20060127012902.61e974dd.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <20060127012902.61e974dd.kgunders@teamcool.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: the jem report bashes fbsd-6.0 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 08:44:33 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2006 at 01:29:02AM -0700, Ken Gunderson wrote: > An older article I just happened across: >=20 > >=20 > Personally think he's far off the mark, e.g. >=20 > "The AMD64 edition didn't work well on two systems. Since it has a long > and inglorious history of severe stability problems that appear to have > carried over into 6.0, I would strongly recommend using the i386 > edition of FreeBSD instead of the AMD64 edition." >=20 > Definitely not congruous with my experiences but then my amd64 systems > are far from stressed:-) But thought I'd post the link in case someone > wanted to address in more detail. You're right that it's old news, but the consensus seemed to be that he's posting from some kind of weird parallel universe where things work Differently :-) Kris --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD2d1rWry0BWjoQKURAp1UAJ9Hpovhh92Pr8oQyjr1LmiA1KYwywCggCVR UmBDjRIow4iPlVTAjCfofv0= =CVls -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 08:56:54 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 B250C16A420 for ; Fri, 27 Jan 2006 08:56:54 +0000 (GMT) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (omega.nanophys.kth.se [130.237.35.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id C252B43D48 for ; Fri, 27 Jan 2006 08:56:53 +0000 (GMT) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (localhost [127.0.0.1]) by omega.nanophys.kth.se (8.13.4/8.13.1) with ESMTP id k0R8vib0072632; Fri, 27 Jan 2006 09:57:44 +0100 (CET) (envelope-from kono@kth.se) Received: from localhost (localhost [[UNIX: localhost]]) by omega.nanophys.kth.se (8.13.4/8.13.1/Submit) id k0R8viej072631; Fri, 27 Jan 2006 09:57:44 +0100 (CET) (envelope-from kono@kth.se) X-Authentication-Warning: omega.nanophys.kth.se: kono set sender to kono@kth.se using -f From: Alexander Konovalenko Organization: KTH To: freebsd-amd64@freebsd.org Date: Fri, 27 Jan 2006 09:57:43 +0100 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200601270957.44032.kono@kth.se> Cc: mumag@nist.gov Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kono@kth.se List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 08:56:54 -0000 I used to run OOMMF (http://math.nist.gov/oommf/) micromagnetic simulations which may consume a lot of memory (for me it's 100..500Mb depending on the size of the magnetic system). I have upgraded my AMD64 Athlon 3000+ to dual core X2 4400+. Now I can run two oommf tasks at the same time, and performance (I measure total execution time of the task) is around 186% comparing with 100% when only one task is running. This 7% degrade in performance per task is probably due to concurrent data transferring CPU<->RAM. I am very satisfied with X2 but just wonder if dual core Opteron gives better performance? Does anybody run OOMMF on Opteron? I use FreeBSD 5.4 (STABLE). /Alexander Konovalenko +46-8-5537-8142 (office) +46-7-3752-2116 http://daemon.nanophys.kth.se/~kono Royal Institute of Technology (KTH) Nanostructure Physics Department, Albanova Roslagstullsbacken 21 10691 Stockholm Sweden From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 08:57:44 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 4E3F016A426 for ; Fri, 27 Jan 2006 08:57:44 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp108.rog.mail.re2.yahoo.com (smtp108.rog.mail.re2.yahoo.com [68.142.225.206]) by mx1.FreeBSD.org (Postfix) with SMTP id 71DF443D46 for ; Fri, 27 Jan 2006 08:57:43 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 83115 invoked from network); 27 Jan 2006 08:57:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bTcVO+SHVN9JQJPShwAWYRqNLDNWEElo4xZXAt5XPh5nVPcgdTvMrwJAPA7zh3OnDuwbx+mQdx55c1+vZcQ/CMrdNKWvQmzmzB1sLTZgp0Kcic+SrH7KDR2cWZfwma9D6HtazH8ErnPjIIDCDXzRAJPTsch0mpvz/1Vjptsfd4E= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 27 Jan 2006 08:57:42 -0000 Message-ID: <43D9E08A.5000307@rogers.com> Date: Fri, 27 Jan 2006 03:57:46 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kris Kennaway References: <20060127012902.61e974dd.kgunders@teamcool.net> <20060127084427.GA35556@xor.obsecurity.org> In-Reply-To: <20060127084427.GA35556@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: the jem report bashes fbsd-6.0 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 08:57:44 -0000 Kris Kennaway wrote: > On Fri, Jan 27, 2006 at 01:29:02AM -0700, Ken Gunderson wrote: > >> An older article I just happened across: >> >> >> >> Personally think he's far off the mark, e.g. >> >> "The AMD64 edition didn't work well on two systems. Since it has a long >> and inglorious history of severe stability problems that appear to have >> carried over into 6.0, I would strongly recommend using the i386 >> edition of FreeBSD instead of the AMD64 edition." >> >> Definitely not congruous with my experiences but then my amd64 systems >> are far from stressed:-) But thought I'd post the link in case someone >> wanted to address in more detail. >> > > You're right that it's old news, but the consensus seemed to be that > he's posting from some kind of weird parallel universe where things > work Differently :-) > > Kris > Write him back, and tell him he's a tool :P From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 09:03:53 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 B483816A422 for ; Fri, 27 Jan 2006 09:03:53 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E039E43D49 for ; Fri, 27 Jan 2006 09:03:52 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id E0FBCF811 for ; Fri, 27 Jan 2006 02:03:51 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 96381F805 for ; Fri, 27 Jan 2006 02:03:51 -0700 (MST) Date: Fri, 27 Jan 2006 02:03:50 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060127020350.02abf989.kgunders@teamcool.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 09:03:53 -0000 Greets: I've only run fbsd-amd64 on servers. My favorite server ports all work great but not sure about status of desktop related stuff. For example, I know OpenOffice has issues. Any other gotchas I should know about? Also that there were some thread a while back that i386 was better performer if you don't need the extra ram capability. But that was also in reference to 5.x. What would y'all recommend for a desktop machine? TIA-- -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 09:30:10 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62C3B16A420 for ; Fri, 27 Jan 2006 09:30:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D29D243D45 for ; Fri, 27 Jan 2006 09:30:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0R9U9KJ096563 for ; Fri, 27 Jan 2006 09:30:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0R9U9wD096562; Fri, 27 Jan 2006 09:30:09 GMT (envelope-from gnats) Resent-Date: Fri, 27 Jan 2006 09:30:09 GMT Resent-Message-Id: <200601270930.k0R9U9wD096562@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Bruce Becker Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 689BA16A420 for ; Fri, 27 Jan 2006 09:21:49 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9891343D7D for ; Fri, 27 Jan 2006 09:21:44 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k0R9Livk082584 for ; Fri, 27 Jan 2006 09:21:44 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k0R9LiEs082567; Fri, 27 Jan 2006 09:21:44 GMT (envelope-from nobody) Message-Id: <200601270921.k0R9LiEs082567@www.freebsd.org> Date: Fri, 27 Jan 2006 09:21:44 GMT From: Bruce Becker To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/92410: calloc.c missing from Makefile.inc X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 09:30:10 -0000 >Number: 92410 >Category: amd64 >Synopsis: calloc.c missing from Makefile.inc >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 27 09:30:08 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Bruce Becker >Release: 6.0 >Organization: G.T.S. >Environment: FreeBSD vhcst.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:25:49 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 >Description: Make buildworld failed with missing reference to calloc at link of atrun >How-To-Repeat: make buildworld >Fix: add "calloc.c" to MISRCS+= declaration in /usr/src/lib/libc/stdlib/Makefile.inc (# $FreeBSD: src/lib/libc/stdlib/Makefile.inc,v 1.48.8.1 2006/01/27 05:17:25 trhodes Exp $) -STABLE shouldn't ever have untested code in it :| >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 09:40:07 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF50416A420 for ; Fri, 27 Jan 2006 09:40:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5949243D58 for ; Fri, 27 Jan 2006 09:40:04 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0R9e4Zt099979 for ; Fri, 27 Jan 2006 09:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0R9e4rc099978; Fri, 27 Jan 2006 09:40:04 GMT (envelope-from gnats) Resent-Date: Fri, 27 Jan 2006 09:40:04 GMT Resent-Message-Id: <200601270940.k0R9e4rc099978@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Bruce Becker Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90FAE16A420 for ; Fri, 27 Jan 2006 09:32:44 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id E030343D75 for ; Fri, 27 Jan 2006 09:32:39 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k0R9WdVP090786 for ; Fri, 27 Jan 2006 09:32:39 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k0R9WdAI090784; Fri, 27 Jan 2006 09:32:39 GMT (envelope-from nobody) Message-Id: <200601270932.k0R9WdAI090784@www.freebsd.org> Date: Fri, 27 Jan 2006 09:32:39 GMT From: Bruce Becker To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 09:40:08 -0000 >Number: 92412 >Category: amd64 >Synopsis: rcp.rstatd reports bogus packets/per/second info >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 27 09:40:03 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Bruce Becker >Release: 6.0 >Organization: G.T.S. >Environment: FreeBSD tarantula.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:25:49 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 >Description: packets/second value reported by rpc.rstatd to remote monitor hovers around 8000 or so with odd downward spikes approx every 90 seconds (it's not at all related to actual interface traffic) >How-To-Repeat: keep displaying rpc.rstatd data from 6.0 system >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 09:40:09 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BC7E16A422 for ; Fri, 27 Jan 2006 09:40:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3DDE43D5E for ; Fri, 27 Jan 2006 09:40:04 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0R9e465000120 for ; Fri, 27 Jan 2006 09:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0R9e4ja000115; Fri, 27 Jan 2006 09:40:04 GMT (envelope-from gnats) Resent-Date: Fri, 27 Jan 2006 09:40:04 GMT Resent-Message-Id: <200601270940.k0R9e4ja000115@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Bruce Becker Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 225E616A422 for ; Fri, 27 Jan 2006 09:35:40 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADB0543D4C for ; Fri, 27 Jan 2006 09:35:39 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k0R9ZdtT092346 for ; Fri, 27 Jan 2006 09:35:39 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k0R9ZdBe092345; Fri, 27 Jan 2006 09:35:39 GMT (envelope-from nobody) Message-Id: <200601270935.k0R9ZdBe092345@www.freebsd.org> Date: Fri, 27 Jan 2006 09:35:39 GMT From: Bruce Becker To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/92413: jail won't shut down X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 09:40:09 -0000 >Number: 92413 >Category: amd64 >Synopsis: jail won't shut down >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 27 09:40:04 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Bruce Becker >Release: 6.0 >Organization: G.T.S. >Environment: FreeBSD tarantula.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:25:49 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 >Description: jail often won't disappear when shut down >How-To-Repeat: start jail; use it; try to shut it down >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 10:00:22 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E284616A420 for ; Fri, 27 Jan 2006 10:00:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF82843D45 for ; Fri, 27 Jan 2006 10:00:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RA0L9D001301 for ; Fri, 27 Jan 2006 10:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RA0Lpc001300; Fri, 27 Jan 2006 10:00:21 GMT (envelope-from gnats) Date: Fri, 27 Jan 2006 10:00:21 GMT Message-Id: <200601271000.k0RA0Lpc001300@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Kris Kennaway Cc: Subject: Re: amd64/92410: calloc.c missing from Makefile.inc X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 10:00:23 -0000 The following reply was made to PR amd64/92410; it has been noted by GNATS. From: Kris Kennaway To: Bruce Becker Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: amd64/92410: calloc.c missing from Makefile.inc Date: Fri, 27 Jan 2006 04:57:56 -0500 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2006 at 09:21:44AM +0000, Bruce Becker wrote: >=20 > >Number: 92410 > >Category: amd64 > >Synopsis: calloc.c missing from Makefile.inc > >Confidential: no > >Severity: critical > >Priority: high > >Responsible: freebsd-amd64 > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Fri Jan 27 09:30:08 GMT 2006 > >Closed-Date: > >Last-Modified: > >Originator: Bruce Becker > >Release: 6.0 > >Organization: > G.T.S. > >Environment: > FreeBSD vhcst.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:25:4= 9 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 >=20 > >Description: > =20 > Make buildworld failed with missing reference to calloc at link of atrun You omitted the error. It's probably caused by something on your end, since 6.0-STABLE in fact builds just fine. > >How-To-Repeat: > make buildworld > >Fix: > add "calloc.c" to MISRCS+=3D declaration in /usr/src/lib/libc/stdlib/Make= file.inc > (# $FreeBSD: src/lib/libc/stdlib/Makefile.inc,v 1.48.8.1 2006/01/27 05:17= :25 trhodes Exp $) >=20 > -STABLE shouldn't ever have untested code in it :| If you say so :) Kris --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD2e6kWry0BWjoQKURAlkDAJ9eY1MSQ/2JsNQipK3Cq8GpZFvkWwCgthAc xuw+uR00lVVSPtwAyDXziwU= =hEqn -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 10:00:25 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1B6D16A420 for ; Fri, 27 Jan 2006 10:00:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B389043D45 for ; Fri, 27 Jan 2006 10:00:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RA0Pbe001309 for ; Fri, 27 Jan 2006 10:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RA0Ptw001308; Fri, 27 Jan 2006 10:00:25 GMT (envelope-from gnats) Date: Fri, 27 Jan 2006 10:00:25 GMT Message-Id: <200601271000.k0RA0Ptw001308@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Kris Kennaway Cc: Subject: Re: amd64/92413: jail won't shut down X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 10:00:26 -0000 The following reply was made to PR amd64/92413; it has been noted by GNATS. From: Kris Kennaway To: Bruce Becker Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: amd64/92413: jail won't shut down Date: Fri, 27 Jan 2006 04:58:50 -0500 --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2006 at 09:35:39AM +0000, Bruce Becker wrote: >=20 > >Number: 92413 > >Category: amd64 > >Synopsis: jail won't shut down > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-amd64 > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Fri Jan 27 09:40:04 GMT 2006 > >Closed-Date: > >Last-Modified: > >Originator: Bruce Becker > >Release: 6.0 > >Organization: > G.T.S. > >Environment: > FreeBSD tarantula.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:= 25:49 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 >=20 > >Description: > jail often won't disappear when shut down >=20 > >How-To-Repeat: > start jail; use it; try to shut it down This isn't a very useful PR either..can you please try to explain precisely the problem you are seeing in a way that others can try to repeat it? Kris --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD2e7aWry0BWjoQKURAqw1AJ47/bZPrPLf6IEtOBHSiBABW+kdLQCfc6TG or/DFnEOTuYMnQgnZkyJ6DE= =VRwc -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 10:10:08 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 312BD16A420 for ; Fri, 27 Jan 2006 10:10:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0004F43D53 for ; Fri, 27 Jan 2006 10:10:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RAA7BH001550 for ; Fri, 27 Jan 2006 10:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RAA7fM001549; Fri, 27 Jan 2006 10:10:07 GMT (envelope-from gnats) Date: Fri, 27 Jan 2006 10:10:07 GMT Message-Id: <200601271010.k0RAA7fM001549@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Kris Kennaway Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 10:10:08 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: Kris Kennaway To: Bruce Becker Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Fri, 27 Jan 2006 05:01:58 -0500 --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2006 at 09:32:39AM +0000, Bruce Becker wrote: > FreeBSD tarantula.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:= 25:49 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 >=20 > >Description: > packets/second value reported by rpc.rstatd to remote monitor hovers arou= nd > 8000 or so with odd downward spikes approx every 90 seconds (it's not at = all related to actual interface traffic) >=20 > >How-To-Repeat: > keep displaying rpc.rstatd data from 6.0 system How are you using rpc.rstatd and rup? I don't see a way to make rup display "packets/second", it only gives uptime and load average: # rup fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 Kris --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD2e+VWry0BWjoQKURAiTZAJ0QmUU1XiuLnn/IjVDN9MoAKMrWiQCg1jkD 8OKCk1CrpCaV0q1uLBOW1tk= =vnXm -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 10:13:10 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org 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 004C916A420 for ; Fri, 27 Jan 2006 10:13:09 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88E1143D45 for ; Fri, 27 Jan 2006 10:13:09 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1F2QbL-00028S-W3; Fri, 27 Jan 2006 12:13:08 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Kris Kennaway In-Reply-To: Message from Kris Kennaway of "Fri, 27 Jan 2006 10:00:21 GMT." <200601271000.k0RA0Lpc001300@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jan 2006 12:13:07 +0200 From: Danny Braniss Message-ID: Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/92410: calloc.c missing from Makefile.inc X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 10:13:10 -0000 > The following reply was made to PR amd64/92410; it has been noted by GNATS. > > From: Kris Kennaway > To: Bruce Becker > Cc: freebsd-gnats-submit@FreeBSD.org > Subject: Re: amd64/92410: calloc.c missing from Makefile.inc > Date: Fri, 27 Jan 2006 04:57:56 -0500 > > --ZGiS0Q5IWpPtfppv > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Jan 27, 2006 at 09:21:44AM +0000, Bruce Becker wrote: > >=20 > > >Number: 92410 > > >Category: amd64 > > >Synopsis: calloc.c missing from Makefile.inc > > >Confidential: no > > >Severity: critical > > >Priority: high > > >Responsible: freebsd-amd64 > > >State: open > > >Quarter: =20 > > >Keywords: =20 > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Fri Jan 27 09:30:08 GMT 2006 > > >Closed-Date: > > >Last-Modified: > > >Originator: Bruce Becker > > >Release: 6.0 > > >Organization: > > G.T.S. > > >Environment: > > FreeBSD vhcst.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:25:4= > 9 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 > >=20 > > >Description: > > =20 > > Make buildworld failed with missing reference to calloc at link of atrun > > You omitted the error. It's probably caused by something on your end, > since 6.0-STABLE in fact builds just fine. it's happening to me too: (cvs'ed about one hour ago) export MAKEOBJDIRPREFIX=/r+d/obj/bsd cd /r+d/6.0/src; make TARGET_ARCH=amd64 buildworld ... ===> libexec/atrun (all) cc -O2 -fno-strict-aliasing -pipe -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/r+d/6.0/src/libexec/atrun/../../usr.bin/at -I/r+d/6.0/src/libexec/atrun -c /r+d/6.0/src/libexec/atrun/atrun.c cc -O2 -fno-strict-aliasing -pipe -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/r+d/6.0/src/libexec/atrun/../../usr.bin/at -I/r+d/6.0/src/libexec/atrun -c /r+d/6.0/src/libexec/atrun/gloadavg.c cc -O2 -fno-strict-aliasing -pipe -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/r+d/6.0/src/libexec/atrun/../../usr.bin/at -I/r+d/6.0/src/libexec/atrun -o atrun atrun.o gloadavg.o /r+d/obj/bsd/r+d/6.0/src/tmp/usr/lib/libc.so: undefined reference to `calloc' *** Error code 1 Stop in /r+d/6.0/src/libexec/atrun. From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 10:16:57 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E55C316A420; Fri, 27 Jan 2006 10:16:57 +0000 (GMT) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A08AC43D45; Fri, 27 Jan 2006 10:16:57 +0000 (GMT) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RAGv2F001794; Fri, 27 Jan 2006 10:16:57 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RAGvjD001790; Fri, 27 Jan 2006 10:16:57 GMT (envelope-from bz) Date: Fri, 27 Jan 2006 10:16:57 GMT From: "Bjoern A. Zeeb" Message-Id: <200601271016.k0RAGvjD001790@freefall.freebsd.org> To: hostmaster@whois.gts.net, bz@FreeBSD.org, freebsd-amd64@FreeBSD.org, bz-amd64@FreeBSD.org Cc: Subject: Re: amd64/92413: jail won't shut down X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 10:16:58 -0000 Synopsis: jail won't shut down State-Changed-From-To: open->closed State-Changed-By: bz State-Changed-When: Fri Jan 27 10:16:08 UTC 2006 State-Changed-Why: Duplicate of kern/89528. You'll find more information there. Responsible-Changed-From-To: freebsd-amd64->bz-amd64 Responsible-Changed-By: bz Responsible-Changed-When: Fri Jan 27 10:16:08 UTC 2006 Responsible-Changed-Why: Assign to me in case of followups. http://www.freebsd.org/cgi/query-pr.cgi?pr=92413 From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 10:42:55 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 1CCE716A420 for ; Fri, 27 Jan 2006 10:42:55 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail21.syd.optusnet.com.au (mail21.syd.optusnet.com.au [211.29.133.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5852243D49 for ; Fri, 27 Jan 2006 10:42:54 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail21.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0RAgq5u020311 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 Jan 2006 21:42:52 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k0RAgqln085078; Fri, 27 Jan 2006 21:42:52 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k0RAgpWu085077; Fri, 27 Jan 2006 21:42:51 +1100 (EST) (envelope-from peter) Date: Fri, 27 Jan 2006 21:42:51 +1100 From: Peter Jeremy To: Ken Gunderson Message-ID: <20060127104251.GE2217@turion.vk2pj.dyndns.org> References: <20060127020350.02abf989.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060127020350.02abf989.kgunders@teamcool.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-amd64@freebsd.org Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 10:42:55 -0000 On Fri, 2006-Jan-27 02:03:50 -0700, Ken Gunderson wrote: >I've only run fbsd-amd64 on servers. My favorite server ports all >work great but not sure about status of desktop related stuff. For >example, I know OpenOffice has issues. Any other gotchas I should know >about? Bare mozilla (no plugins yet), gnupg, mutt-devel, emacs, mplayer all seem to work for me (though the lack of win32 codecs may be an issue over time). What particular tools are you interested in? >Also that there were some thread a while back that i386 was better >performer if you don't need the extra ram capability. But that was >also in reference to 5.x. I suspect this is highly application dependent. Multi-precision math ([g]mp, RSA/DSA etc) will run lots faster in 64-bit mode. OTOH, applications will be larger (pointers are twice as big) and (generally) have larger working set sizes, leading to lower cache hit rates. Your best bet is to try both and see if you notice a difference. -- Peter Jeremy From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 11:28:08 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 36C6216A427 for ; Fri, 27 Jan 2006 11:28:08 +0000 (GMT) (envelope-from groot@kde.org) Received: from multi.science.ru.nl (multi.science.ru.nl [131.174.16.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BA343D49 for ; Fri, 27 Jan 2006 11:28:07 +0000 (GMT) (envelope-from groot@kde.org) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost) by multi.science.ru.nl (8.13.5/5.7) with ESMTP id k0RBRvjw008399; Fri, 27 Jan 2006 12:27:57 +0100 (MET) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Fri, 27 Jan 2006 12:28:02 +0100 User-Agent: KMail/1.8.3 References: <20060127020350.02abf989.kgunders@teamcool.net> In-Reply-To: <20060127020350.02abf989.kgunders@teamcool.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601271228.02675.groot@kde.org> X-Spam-Score: -1.665 () BAYES_00 X-Scanned-By: MIMEDefang 2.48 on 131.174.16.159 Cc: Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 11:28:09 -0000 On Friday 27 January 2006 10:03, Ken Gunderson wrote: > I've only run fbsd-amd64 on servers. My favorite server ports all > work great but not sure about status of desktop related stuff. For > example, I know OpenOffice has issues. Any other gotchas I should know > about? A lot depends on what kind of desktop you intend to run. KDE, for instance, has no gotchas that don't also apply to i386 (basically, many hardware detection and configuration things are linux-specific in that codebase, so they don't work on any FreeBSD). For common desktop applications like pirating CDs (k3b) and surfing dubious websites (webbrowser + mplayer), amd64 desktops are fine. -- As of September 1st, 2004, the University of Nijmegen will _still_ be the University of Nijmegen, but with a different nonsensical adjective in front. Reach me at groot@kde.org instead. GPG FEA2 A3FE From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 12:07:49 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 0C5E316A420 for ; Fri, 27 Jan 2006 12:07:49 +0000 (GMT) (envelope-from jamesoff@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id F024F43D58 for ; Fri, 27 Jan 2006 12:07:42 +0000 (GMT) (envelope-from jamesoff@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so612326nzo for ; Fri, 27 Jan 2006 04:07:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cm3rGS7f0gaBabUvOxmk1yLuusm9I2+K07E1ZetCrV85iMMooMTBCBvH3F5FF7VB6+DJnYI+BOQlBESPqZf1yHZlCZX4vMM6E1Kf1FGEVv7RhOFBTjYJNEUWxiKtwDhmNh1s+oIINWKxcZJj8GrZ5QFpaECNg63qjD4K2mnojYY= Received: by 10.36.81.11 with SMTP id e11mr2359972nzb; Fri, 27 Jan 2006 04:07:42 -0800 (PST) Received: by 10.36.109.17 with HTTP; Fri, 27 Jan 2006 04:07:41 -0800 (PST) Message-ID: <720051dc0601270407h1cb71f57l933afb395bf7235e@mail.gmail.com> Date: Fri, 27 Jan 2006 12:07:41 +0000 From: James Seward To: freebsd-amd64@freebsd.org In-Reply-To: <200601271228.02675.groot@kde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060127020350.02abf989.kgunders@teamcool.net> <200601271228.02675.groot@kde.org> Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 12:07:49 -0000 On 1/27/06, Adriaan de Groot wrote: > On Friday 27 January 2006 10:03, Ken Gunderson wrote: > > I've only run fbsd-amd64 on servers. My favorite server ports all > > work great but not sure about status of desktop related stuff. For > > example, I know OpenOffice has issues. Any other gotchas I should know > > about? FreeBSD6/amd64 worked fine for me on my desktop using GNOME, firefox, and some other bits and pieces. As mentioned previously, win32-codecs doesn't work so you'll be unable to play some formats (like WMV). nvidia-driver doesn't work on amd64 either. I recently switched back to 6-RELEASE/i386 on that machine from 6-STABLE/amd64 because recent kernels (after the beginning of November) couldn't see any of my disks at boot time. I haven't tried recent i386 kernels yet because I haven't had time, and the lack of response to the problem I had on amd64 disheartened me :( (Including a PR that seemingly got ignored.) amd64 was fine and stable and stuff, but I need i386 for a couple of things that aren't available otherwise. /JMS From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 12:14:21 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 D5B9D16A422 for ; Fri, 27 Jan 2006 12:14:21 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2DA643D58 for ; Fri, 27 Jan 2006 12:14:20 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: by uproxy.gmail.com with SMTP id o2so537252uge for ; Fri, 27 Jan 2006 04:14:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kkRje3xvCB1I6Paq0jF7D32/N0tgzG17swph24XlX+M/jRjiMd848lL7qjKv+07E2D/syoC36OSAJbl5I48Wnzz8ZwDKr0pb/hVGRWoUEqMsA/h20i0XxL5/bV1fWBm6/rj9ZWPti+BgLXY5Bdnv1GLBkwccNtkuhgqZFejgvaA= Received: by 10.48.108.11 with SMTP id g11mr48791nfc; Fri, 27 Jan 2006 04:14:18 -0800 (PST) Received: by 10.48.30.13 with HTTP; Fri, 27 Jan 2006 04:14:18 -0800 (PST) Message-ID: <61c746830601270414w44e868b9q77dd50565bc448b6@mail.gmail.com> Date: Fri, 27 Jan 2006 13:14:18 +0100 From: Antoine Pelisse To: Kris Kennaway In-Reply-To: <20060127043323.GA31513@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3535_12319067.1138364058295" References: <43D9A099.8060909@samsco.org> <20060127043323.GA31513@xor.obsecurity.org> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 12:14:22 -0000 ------=_Part_3535_12319067.1138364058295 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Still there is my patch that looks first in the /compat/ia32 directory before it looks anywhere else. It's the exact same thing that for the linux compatibility. All that needs to do is to install every 32bit files (binaries, libraries, etc) in the /compat/ia32 directory. The patch requires some testing and may not apply on the latest CURRENT but I attached it anyway. Regards, Antoine On 1/27/06, Kris Kennaway wrote: > > On Thu, Jan 26, 2006 at 09:24:57PM -0700, Scott Long wrote: > > conrads@cox.net wrote: > > >In experimenting with running 32-bit apps, I've hit a snag: what to do > > >about > > >programs that require 32-bit X libraries? > > > > > >Is there any solution to this problem? > > > > > > > Snag the xorg libraries package for i386 and unpack the appropriate > > libraries by hand into the lib32 directory. Maybe it makes sense to > > have a port that puts them into /usr/X11R6/lib32 or something. > > What would be really cool would be a way to easily do this for any > package. > > Kris > > ------=_Part_3535_12319067.1138364058295 Content-Type: application/octet-stream; name=freebsd32prefix-current.patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="freebsd32prefix-current.patch" diff -ru sys.old/compat/freebsd32/freebsd32_file.c sys/compat/freebsd32/freebsd32_file.c --- sys.old/compat/freebsd32/freebsd32_file.c Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_file.c Fri Dec 9 21:37:03 2005 @@ -0,0 +1,268 @@ +/*- + * Copyright (c) 2005 Antoine Pelisse + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include + +#include "opt_compat.h" + +#include +#include +#include + +#include +#include +#include + +int +freebsd32_open(struct thread *td, struct freebsd32_open_args *args) +{ + int error; + char *path; + + if (args->flags & O_CREAT) + CONVPATHCREAT(td, args->path, &path); + else + CONVPATHEXIST(td, args->path, &path); + + error = kern_open(td, path, UIO_SYSSPACE, args->flags, args->mode); + FREEPATH(path); + return (error); +} + +int +freebsd32_access(struct thread *td, struct freebsd32_access_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_access(td, path, UIO_SYSSPACE, args->flags); + FREEPATH(path); + return (error); +} + +int +freebsd32_eaccess(struct thread *td, struct freebsd32_eaccess_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_eaccess(td, path, UIO_SYSSPACE, args->flags); + FREEPATH(path); + return (error); +} + +int +freebsd32_unlink(struct thread *td, struct freebsd32_unlink_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_unlink(td, path, UIO_SYSSPACE); + FREEPATH(path); + return (error); +} + +int +freebsd32_chdir(struct thread *td, struct freebsd32_chdir_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_chdir(td, path, UIO_SYSSPACE); + FREEPATH(path); + return (error); +} + +int +freebsd32_chmod(struct thread *td, struct freebsd32_chmod_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_chmod(td, path, UIO_SYSSPACE, args->mode); + FREEPATH(path); + return (error); +} + +int +freebsd32_lchmod(struct thread *td, struct freebsd32_lchmod_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_lchmod(td, path, UIO_SYSSPACE, args->mode); + FREEPATH(path); + return (error); +} + +int +freebsd32_mknod(struct thread *td, struct freebsd32_mknod_args *args) +{ + int error; + char *path; + + CONVPATHCREAT(td, args->path, &path); + + error = kern_mknod(td, path, UIO_SYSSPACE, args->mode, args->dev); + FREEPATH(path); + return (error); +} + +int +freebsd32_mkdir(struct thread *td, struct freebsd32_mkdir_args *args) +{ + int error; + char *path; + + CONVPATHCREAT(td, args->path, &path); + + error = kern_mkdir(td, path, UIO_SYSSPACE, args->mode); + FREEPATH(path); + return (error); +} + +int +freebsd32_rmdir(struct thread *td, struct freebsd32_rmdir_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_rmdir(td, path, UIO_SYSSPACE); + FREEPATH(path); + return (error); +} + +int +freebsd32_rename(struct thread *td, struct freebsd32_rename_args *args) +{ + int error; + char *frompath, *topath; + + CONVPATHEXIST(td, args->from, &frompath); + error = freebsd32_convpath(td, args->to, UIO_USERSPACE, &topath, 1); + if (topath == NULL) { + FREEPATH(frompath); + return (error); + } + + error = kern_rename(td, frompath, topath, UIO_SYSSPACE); + FREEPATH(frompath); + FREEPATH(topath); + return (error); +} + +int +freebsd32_symlink(struct thread *td, struct freebsd32_symlink_args *args) +{ + int error; + char *path, *link; + + CONVPATHEXIST(td, args->path, &path); + error = freebsd32_convpath(td, args->link, UIO_USERSPACE, &link, 1); + if (link == NULL) { + FREEPATH(path); + return (error); + } + + error = kern_symlink(td, path, link, UIO_SYSSPACE); + FREEPATH(path); + FREEPATH(link); + return (error); +} + +int +freebsd32_readlink(struct thread *td, struct freebsd32_readlink_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_readlink(td, path, UIO_SYSSPACE, args->buf, UIO_USERSPACE, + args->count); + FREEPATH(path); + return (error); +} + +int +freebsd32_link(struct thread *td, struct freebsd32_link_args *args) +{ + int error; + char *path, *link; + + CONVPATHEXIST(td, args->path, &path); + error = freebsd32_convpath(td, args->link, UIO_USERSPACE, &link, 1); + if (link == NULL) { + FREEPATH(path); + return (error); + } + + error = kern_link(td, path, link, UIO_SYSSPACE); + FREEPATH(path); + FREEPATH(link); + return (error); +} + +int +freebsd32_chown(struct thread *td, struct freebsd32_chown_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_chown(td, path, UIO_SYSSPACE, args->uid, args->gid); + FREEPATH(path); + return (error); +} + +int +freebsd32_lchown(struct thread *td, struct freebsd32_lchown_args *args) +{ + int error; + char *path; + + CONVPATHEXIST(td, args->path, &path); + + error = kern_lchown(td, path, UIO_SYSSPACE, args->uid, args->gid); + FREEPATH(path); + return (error); +} diff -ru sys.old/compat/freebsd32/freebsd32_misc.c sys/compat/freebsd32/freebsd32_misc.c --- sys.old/compat/freebsd32/freebsd32_misc.c Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_misc.c Fri Dec 9 21:37:03 2005 @@ -1205,6 +1205,9 @@ struct timeval32 s32[2]; struct timeval s[2], *sp; int error; + char *path; + + CONVPATHEXIST(td, uap->path, &path); if (uap->tptr != NULL) { error = copyin(uap->tptr, s32, sizeof(s32)); @@ -1217,7 +1220,10 @@ sp = s; } else sp = NULL; - return (kern_utimes(td, uap->path, UIO_USERSPACE, sp, UIO_SYSSPACE)); + + error = kern_utimes(td, path, UIO_SYSSPACE, sp, UIO_SYSSPACE); + FREEPATH(path); + return (error); } int @@ -1274,8 +1280,12 @@ struct statfs32 s32; struct statfs s; int error; + char *path; - error = kern_statfs(td, uap->path, UIO_USERSPACE, &s); + CONVPATHEXIST(td, uap->path, &path); + + error = kern_statfs(td, path, UIO_SYSSPACE, &s); + FREEPATH(path); if (error) return (error); copy_statfs(&s, &s32); @@ -1390,11 +1400,15 @@ int freebsd32_truncate(struct thread *td, struct freebsd32_truncate_args *uap) { - struct truncate_args ap; + int error; + char *path; - ap.path = uap->path; - ap.length = (uap->lengthlo | ((off_t)uap->lengthhi << 32)); - return (truncate(td, &ap)); + CONVPATHEXIST(td, uap->path, &path); + + error = kern_truncate(td, path, UIO_SYSSPACE, + (uap->lengthlo | ((off_t)uap->lengthhi << 32))); + FREEPATH(path); + return (error); } int @@ -1490,8 +1504,12 @@ struct stat sb; struct stat32 sb32; int error; + char *path; - error = kern_stat(td, uap->path, UIO_USERSPACE, &sb); + CONVPATHEXIST(td, uap->path, &path); + + error = kern_stat(td, path, UIO_SYSSPACE, &sb); + FREEPATH(path); if (error) return (error); copy_stat(&sb, &sb32); @@ -1520,8 +1538,12 @@ struct stat sb; struct stat32 sb32; int error; + char *path; + + CONVPATHEXIST(td, uap->path, &path); - error = kern_lstat(td, uap->path, UIO_USERSPACE, &sb); + error = kern_lstat(td, path, UIO_SYSSPACE, &sb); + FREEPATH(path); if (error) return (error); copy_stat(&sb, &sb32); diff -ru sys.old/compat/freebsd32/freebsd32_proto.h sys/compat/freebsd32/freebsd32_proto.h --- sys.old/compat/freebsd32/freebsd32_proto.h Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_proto.h Fri Dec 9 21:50:29 2005 @@ -32,12 +32,41 @@ #define PADR_(t) 0 #endif +struct freebsd32_open_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)]; + char mode_l_[PADL_(int)]; int mode; char mode_r_[PADR_(int)]; +}; struct freebsd32_wait4_args { char pid_l_[PADL_(int)]; int pid; char pid_r_[PADR_(int)]; char status_l_[PADL_(int *)]; int * status; char status_r_[PADR_(int *)]; char options_l_[PADL_(int)]; int options; char options_r_[PADR_(int)]; char rusage_l_[PADL_(struct rusage32 *)]; struct rusage32 * rusage; char rusage_r_[PADR_(struct rusage32 *)]; }; +struct freebsd32_link_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char link_l_[PADL_(char *)]; char * link; char link_r_[PADR_(char *)]; +}; +struct freebsd32_unlink_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; +}; +struct freebsd32_chdir_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; +}; +struct freebsd32_mknod_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char mode_l_[PADL_(int)]; int mode; char mode_r_[PADR_(int)]; + char dev_l_[PADL_(int)]; int dev; char dev_r_[PADR_(int)]; +}; +struct freebsd32_chmod_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char mode_l_[PADL_(int)]; int mode; char mode_r_[PADR_(int)]; +}; +struct freebsd32_chown_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char uid_l_[PADL_(int)]; int uid; char uid_r_[PADR_(int)]; + char gid_l_[PADL_(int)]; int gid; char gid_r_[PADR_(int)]; +}; struct freebsd32_recvmsg_args { char s_l_[PADL_(int)]; int s; char s_r_[PADR_(int)]; char msg_l_[PADL_(struct msghdr32 *)]; struct msghdr32 * msg; char msg_r_[PADR_(struct msghdr32 *)]; @@ -56,6 +85,10 @@ char from_l_[PADL_(u_int32_t)]; u_int32_t from; char from_r_[PADR_(u_int32_t)]; char fromlenaddr_l_[PADL_(u_int32_t)]; u_int32_t fromlenaddr; char fromlenaddr_r_[PADR_(u_int32_t)]; }; +struct freebsd32_access_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)]; +}; struct ofreebsd32_sigpending_args { register_t dummy; }; @@ -63,6 +96,15 @@ char ss_l_[PADL_(struct sigaltstack32 *)]; struct sigaltstack32 * ss; char ss_r_[PADR_(struct sigaltstack32 *)]; char oss_l_[PADL_(struct sigaltstack32 *)]; struct sigaltstack32 * oss; char oss_r_[PADR_(struct sigaltstack32 *)]; }; +struct freebsd32_symlink_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char link_l_[PADL_(char *)]; char * link; char link_r_[PADR_(char *)]; +}; +struct freebsd32_readlink_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)]; + char count_l_[PADL_(int)]; int count; char count_r_[PADR_(int)]; +}; struct freebsd32_execve_args { char fname_l_[PADL_(char *)]; char * fname; char fname_r_[PADR_(char *)]; char argv_l_[PADL_(u_int32_t *)]; u_int32_t * argv; char argv_r_[PADR_(u_int32_t *)]; @@ -106,6 +148,17 @@ char tv_l_[PADL_(struct timeval32 *)]; struct timeval32 * tv; char tv_r_[PADR_(struct timeval32 *)]; char tzp_l_[PADL_(struct timezone *)]; struct timezone * tzp; char tzp_r_[PADR_(struct timezone *)]; }; +struct freebsd32_rename_args { + char from_l_[PADL_(char *)]; char * from; char from_r_[PADR_(char *)]; + char to_l_[PADL_(char *)]; char * to; char to_r_[PADR_(char *)]; +}; +struct freebsd32_mkdir_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char mode_l_[PADL_(int)]; int mode; char mode_r_[PADR_(int)]; +}; +struct freebsd32_rmdir_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; +}; struct freebsd32_utimes_args { char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; char tptr_l_[PADL_(struct timeval32 *)]; struct timeval32 * tptr; char tptr_r_[PADR_(struct timeval32 *)]; @@ -220,6 +273,15 @@ char rqtp_l_[PADL_(const struct timespec32 *)]; const struct timespec32 * rqtp; char rqtp_r_[PADR_(const struct timespec32 *)]; char rmtp_l_[PADL_(struct timespec32 *)]; struct timespec32 * rmtp; char rmtp_r_[PADR_(struct timespec32 *)]; }; +struct freebsd32_lchown_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char uid_l_[PADL_(int)]; int uid; char uid_r_[PADR_(int)]; + char gid_l_[PADL_(int)]; int gid; char gid_r_[PADR_(int)]; +}; +struct freebsd32_lchmod_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char mode_l_[PADL_(mode_t)]; mode_t mode; char mode_r_[PADR_(mode_t)]; +}; struct freebsd32_preadv_args { char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)]; char iovp_l_[PADL_(struct iovec32 *)]; struct iovec32 * iovp; char iovp_r_[PADR_(struct iovec32 *)]; @@ -244,6 +306,10 @@ char nevents_l_[PADL_(int)]; int nevents; char nevents_r_[PADR_(int)]; char timeout_l_[PADL_(const struct timespec32 *)]; const struct timespec32 * timeout; char timeout_r_[PADR_(const struct timespec32 *)]; }; +struct freebsd32_eaccess_args { + char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; + char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)]; +}; struct freebsd32_sendfile_args { char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)]; char s_l_[PADL_(int)]; int s; char s_r_[PADR_(int)]; @@ -272,11 +338,21 @@ char oucp_l_[PADL_(struct freebsd32_ucontext *)]; struct freebsd32_ucontext * oucp; char oucp_r_[PADR_(struct freebsd32_ucontext *)]; char ucp_l_[PADL_(const struct freebsd32_ucontext *)]; const struct freebsd32_ucontext * ucp; char ucp_r_[PADR_(const struct freebsd32_ucontext *)]; }; +int freebsd32_open(struct thread *, struct freebsd32_open_args *); int freebsd32_wait4(struct thread *, struct freebsd32_wait4_args *); +int freebsd32_link(struct thread *, struct freebsd32_link_args *); +int freebsd32_unlink(struct thread *, struct freebsd32_unlink_args *); +int freebsd32_chdir(struct thread *, struct freebsd32_chdir_args *); +int freebsd32_mknod(struct thread *, struct freebsd32_mknod_args *); +int freebsd32_chmod(struct thread *, struct freebsd32_chmod_args *); +int freebsd32_chown(struct thread *, struct freebsd32_chown_args *); int freebsd32_recvmsg(struct thread *, struct freebsd32_recvmsg_args *); int freebsd32_sendmsg(struct thread *, struct freebsd32_sendmsg_args *); int freebsd32_recvfrom(struct thread *, struct freebsd32_recvfrom_args *); +int freebsd32_access(struct thread *, struct freebsd32_access_args *); int freebsd32_sigaltstack(struct thread *, struct freebsd32_sigaltstack_args *); +int freebsd32_symlink(struct thread *, struct freebsd32_symlink_args *); +int freebsd32_readlink(struct thread *, struct freebsd32_readlink_args *); int freebsd32_execve(struct thread *, struct freebsd32_execve_args *); int freebsd32_setitimer(struct thread *, struct freebsd32_setitimer_args *); int freebsd32_getitimer(struct thread *, struct freebsd32_getitimer_args *); @@ -286,6 +362,9 @@ int freebsd32_readv(struct thread *, struct freebsd32_readv_args *); int freebsd32_writev(struct thread *, struct freebsd32_writev_args *); int freebsd32_settimeofday(struct thread *, struct freebsd32_settimeofday_args *); +int freebsd32_rename(struct thread *, struct freebsd32_rename_args *); +int freebsd32_mkdir(struct thread *, struct freebsd32_mkdir_args *); +int freebsd32_rmdir(struct thread *, struct freebsd32_rmdir_args *); int freebsd32_utimes(struct thread *, struct freebsd32_utimes_args *); int freebsd32_adjtime(struct thread *, struct freebsd32_adjtime_args *); int freebsd32_semsys(struct thread *, struct freebsd32_semsys_args *); @@ -306,10 +385,13 @@ int freebsd32_clock_settime(struct thread *, struct freebsd32_clock_settime_args *); int freebsd32_clock_getres(struct thread *, struct freebsd32_clock_getres_args *); int freebsd32_nanosleep(struct thread *, struct freebsd32_nanosleep_args *); +int freebsd32_lchown(struct thread *, struct freebsd32_lchown_args *); +int freebsd32_lchmod(struct thread *, struct freebsd32_lchmod_args *); int freebsd32_preadv(struct thread *, struct freebsd32_preadv_args *); int freebsd32_pwritev(struct thread *, struct freebsd32_pwritev_args *); int freebsd32_modstat(struct thread *, struct freebsd32_modstat_args *); int freebsd32_kevent(struct thread *, struct freebsd32_kevent_args *); +int freebsd32_eaccess(struct thread *, struct freebsd32_eaccess_args *); int freebsd32_sendfile(struct thread *, struct freebsd32_sendfile_args *); int freebsd32_sigaction(struct thread *, struct freebsd32_sigaction_args *); int freebsd32_sigreturn(struct thread *, struct freebsd32_sigreturn_args *); diff -ru sys.old/compat/freebsd32/freebsd32_syscall.h sys/compat/freebsd32/freebsd32_syscall.h --- sys.old/compat/freebsd32/freebsd32_syscall.h Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_syscall.h Fri Dec 9 21:50:29 2005 @@ -11,18 +11,18 @@ #define FREEBSD32_SYS_fork 2 #define FREEBSD32_SYS_read 3 #define FREEBSD32_SYS_write 4 -#define FREEBSD32_SYS_open 5 +#define FREEBSD32_SYS_freebsd32_open 5 #define FREEBSD32_SYS_close 6 #define FREEBSD32_SYS_freebsd32_wait4 7 /* 8 is obsolete old creat */ -#define FREEBSD32_SYS_link 9 -#define FREEBSD32_SYS_unlink 10 +#define FREEBSD32_SYS_freebsd32_link 9 +#define FREEBSD32_SYS_freebsd32_unlink 10 /* 11 is obsolete execv */ -#define FREEBSD32_SYS_chdir 12 +#define FREEBSD32_SYS_freebsd32_chdir 12 #define FREEBSD32_SYS_fchdir 13 -#define FREEBSD32_SYS_mknod 14 -#define FREEBSD32_SYS_chmod 15 -#define FREEBSD32_SYS_chown 16 +#define FREEBSD32_SYS_freebsd32_mknod 14 +#define FREEBSD32_SYS_freebsd32_chmod 15 +#define FREEBSD32_SYS_freebsd32_chown 16 #define FREEBSD32_SYS_break 17 /* 18 is old freebsd32_getfsstat */ /* 19 is obsolete olseek */ @@ -39,7 +39,7 @@ #define FREEBSD32_SYS_accept 30 #define FREEBSD32_SYS_getpeername 31 #define FREEBSD32_SYS_getsockname 32 -#define FREEBSD32_SYS_access 33 +#define FREEBSD32_SYS_freebsd32_access 33 #define FREEBSD32_SYS_chflags 34 #define FREEBSD32_SYS_fchflags 35 #define FREEBSD32_SYS_sync 36 @@ -61,8 +61,8 @@ #define FREEBSD32_SYS_ioctl 54 #define FREEBSD32_SYS_reboot 55 #define FREEBSD32_SYS_revoke 56 -#define FREEBSD32_SYS_symlink 57 -#define FREEBSD32_SYS_readlink 58 +#define FREEBSD32_SYS_freebsd32_symlink 57 +#define FREEBSD32_SYS_freebsd32_readlink 58 #define FREEBSD32_SYS_freebsd32_execve 59 #define FREEBSD32_SYS_umask 60 #define FREEBSD32_SYS_chroot 61 @@ -129,7 +129,7 @@ /* 125 is obsolete orecvfrom */ #define FREEBSD32_SYS_setreuid 126 #define FREEBSD32_SYS_setregid 127 -#define FREEBSD32_SYS_rename 128 +#define FREEBSD32_SYS_freebsd32_rename 128 /* 129 is obsolete otruncate */ /* 130 is obsolete ftruncate */ #define FREEBSD32_SYS_flock 131 @@ -137,8 +137,8 @@ #define FREEBSD32_SYS_sendto 133 #define FREEBSD32_SYS_shutdown 134 #define FREEBSD32_SYS_socketpair 135 -#define FREEBSD32_SYS_mkdir 136 -#define FREEBSD32_SYS_rmdir 137 +#define FREEBSD32_SYS_freebsd32_mkdir 136 +#define FREEBSD32_SYS_freebsd32_rmdir 137 #define FREEBSD32_SYS_freebsd32_utimes 138 /* 139 is obsolete 4.2 sigreturn */ #define FREEBSD32_SYS_freebsd32_adjtime 140 @@ -209,9 +209,9 @@ #define FREEBSD32_SYS_rfork 251 #define FREEBSD32_SYS_openbsd_poll 252 #define FREEBSD32_SYS_issetugid 253 -#define FREEBSD32_SYS_lchown 254 +#define FREEBSD32_SYS_freebsd32_lchown 254 #define FREEBSD32_SYS_getdents 272 -#define FREEBSD32_SYS_lchmod 274 +#define FREEBSD32_SYS_freebsd32_lchmod 274 #define FREEBSD32_SYS_netbsd_lchown 275 #define FREEBSD32_SYS_lutimes 276 #define FREEBSD32_SYS_netbsd_msync 277 @@ -280,7 +280,7 @@ #define FREEBSD32_SYS_extattr_get_fd 372 #define FREEBSD32_SYS_extattr_delete_fd 373 #define FREEBSD32_SYS___setugid 374 -#define FREEBSD32_SYS_eaccess 376 +#define FREEBSD32_SYS_freebsd32_eaccess 376 #define FREEBSD32_SYS_nmount 378 #define FREEBSD32_SYS_kse_exit 379 #define FREEBSD32_SYS_kse_wakeup 380 diff -ru sys.old/compat/freebsd32/freebsd32_syscalls.c sys/compat/freebsd32/freebsd32_syscalls.c --- sys.old/compat/freebsd32/freebsd32_syscalls.c Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_syscalls.c Fri Dec 9 21:50:29 2005 @@ -12,18 +12,18 @@ "fork", /* 2 = fork */ "read", /* 3 = read */ "write", /* 4 = write */ - "open", /* 5 = open */ + "freebsd32_open", /* 5 = freebsd32_open */ "close", /* 6 = close */ "freebsd32_wait4", /* 7 = freebsd32_wait4 */ "obs_old", /* 8 = obsolete old creat */ - "link", /* 9 = link */ - "unlink", /* 10 = unlink */ + "freebsd32_link", /* 9 = freebsd32_link */ + "freebsd32_unlink", /* 10 = freebsd32_unlink */ "obs_execv", /* 11 = obsolete execv */ - "chdir", /* 12 = chdir */ + "freebsd32_chdir", /* 12 = freebsd32_chdir */ "fchdir", /* 13 = fchdir */ - "mknod", /* 14 = mknod */ - "chmod", /* 15 = chmod */ - "chown", /* 16 = chown */ + "freebsd32_mknod", /* 14 = freebsd32_mknod */ + "freebsd32_chmod", /* 15 = freebsd32_chmod */ + "freebsd32_chown", /* 16 = freebsd32_chown */ "break", /* 17 = break */ "old.freebsd32_getfsstat", /* 18 = old freebsd32_getfsstat */ "obs_olseek", /* 19 = obsolete olseek */ @@ -40,7 +40,7 @@ "accept", /* 30 = accept */ "getpeername", /* 31 = getpeername */ "getsockname", /* 32 = getsockname */ - "access", /* 33 = access */ + "freebsd32_access", /* 33 = freebsd32_access */ "chflags", /* 34 = chflags */ "fchflags", /* 35 = fchflags */ "sync", /* 36 = sync */ @@ -64,8 +64,8 @@ "ioctl", /* 54 = ioctl */ "reboot", /* 55 = reboot */ "revoke", /* 56 = revoke */ - "symlink", /* 57 = symlink */ - "readlink", /* 58 = readlink */ + "freebsd32_symlink", /* 57 = freebsd32_symlink */ + "freebsd32_readlink", /* 58 = freebsd32_readlink */ "freebsd32_execve", /* 59 = freebsd32_execve */ "umask", /* 60 = umask */ "chroot", /* 61 = chroot */ @@ -135,7 +135,7 @@ "obs_orecvfrom", /* 125 = obsolete orecvfrom */ "setreuid", /* 126 = setreuid */ "setregid", /* 127 = setregid */ - "rename", /* 128 = rename */ + "freebsd32_rename", /* 128 = freebsd32_rename */ "obs_otruncate", /* 129 = obsolete otruncate */ "obs_ftruncate", /* 130 = obsolete ftruncate */ "flock", /* 131 = flock */ @@ -143,8 +143,8 @@ "sendto", /* 133 = sendto */ "shutdown", /* 134 = shutdown */ "socketpair", /* 135 = socketpair */ - "mkdir", /* 136 = mkdir */ - "rmdir", /* 137 = rmdir */ + "freebsd32_mkdir", /* 136 = freebsd32_mkdir */ + "freebsd32_rmdir", /* 137 = freebsd32_rmdir */ "freebsd32_utimes", /* 138 = freebsd32_utimes */ "obs_4.2", /* 139 = obsolete 4.2 sigreturn */ "freebsd32_adjtime", /* 140 = freebsd32_adjtime */ @@ -261,7 +261,7 @@ "rfork", /* 251 = rfork */ "openbsd_poll", /* 252 = openbsd_poll */ "issetugid", /* 253 = issetugid */ - "lchown", /* 254 = lchown */ + "freebsd32_lchown", /* 254 = freebsd32_lchown */ "#255", /* 255 = nosys */ "#256", /* 256 = nosys */ "#257", /* 257 = nosys */ @@ -281,7 +281,7 @@ "#271", /* 271 = nosys */ "getdents", /* 272 = getdents */ "#273", /* 273 = nosys */ - "lchmod", /* 274 = lchmod */ + "freebsd32_lchmod", /* 274 = freebsd32_lchmod */ "netbsd_lchown", /* 275 = netbsd_lchown */ "lutimes", /* 276 = lutimes */ "netbsd_msync", /* 277 = netbsd_msync */ @@ -383,7 +383,7 @@ "extattr_delete_fd", /* 373 = extattr_delete_fd */ "__setugid", /* 374 = __setugid */ "#375", /* 375 = nfsclnt */ - "eaccess", /* 376 = eaccess */ + "freebsd32_eaccess", /* 376 = freebsd32_eaccess */ "#377", /* 377 = afs_syscall */ "nmount", /* 378 = nmount */ "kse_exit", /* 379 = kse_exit */ diff -ru sys.old/compat/freebsd32/freebsd32_sysent.c sys/compat/freebsd32/freebsd32_sysent.c --- sys.old/compat/freebsd32/freebsd32_sysent.c Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_sysent.c Fri Dec 9 21:50:29 2005 @@ -37,18 +37,18 @@ { SYF_MPSAFE | 0, (sy_call_t *)fork, AUE_NULL }, /* 2 = fork */ { SYF_MPSAFE | AS(read_args), (sy_call_t *)read, AUE_NULL }, /* 3 = read */ { SYF_MPSAFE | AS(write_args), (sy_call_t *)write, AUE_NULL }, /* 4 = write */ - { SYF_MPSAFE | AS(open_args), (sy_call_t *)open, AUE_NULL }, /* 5 = open */ + { SYF_MPSAFE | AS(freebsd32_open_args), (sy_call_t *)freebsd32_open, AUE_NULL }, /* 5 = freebsd32_open */ { SYF_MPSAFE | AS(close_args), (sy_call_t *)close, AUE_NULL }, /* 6 = close */ { SYF_MPSAFE | AS(freebsd32_wait4_args), (sy_call_t *)freebsd32_wait4, AUE_NULL }, /* 7 = freebsd32_wait4 */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 8 = obsolete old creat */ - { SYF_MPSAFE | AS(link_args), (sy_call_t *)link, AUE_NULL }, /* 9 = link */ - { SYF_MPSAFE | AS(unlink_args), (sy_call_t *)unlink, AUE_NULL }, /* 10 = unlink */ + { SYF_MPSAFE | AS(freebsd32_link_args), (sy_call_t *)freebsd32_link, AUE_NULL }, /* 9 = freebsd32_link */ + { SYF_MPSAFE | AS(freebsd32_unlink_args), (sy_call_t *)freebsd32_unlink, AUE_NULL }, /* 10 = freebsd32_unlink */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 11 = obsolete execv */ - { SYF_MPSAFE | AS(chdir_args), (sy_call_t *)chdir, AUE_NULL }, /* 12 = chdir */ + { SYF_MPSAFE | AS(freebsd32_chdir_args), (sy_call_t *)freebsd32_chdir, AUE_NULL }, /* 12 = freebsd32_chdir */ { SYF_MPSAFE | AS(fchdir_args), (sy_call_t *)fchdir, AUE_NULL }, /* 13 = fchdir */ - { SYF_MPSAFE | AS(mknod_args), (sy_call_t *)mknod, AUE_NULL }, /* 14 = mknod */ - { SYF_MPSAFE | AS(chmod_args), (sy_call_t *)chmod, AUE_NULL }, /* 15 = chmod */ - { SYF_MPSAFE | AS(chown_args), (sy_call_t *)chown, AUE_NULL }, /* 16 = chown */ + { SYF_MPSAFE | AS(freebsd32_mknod_args), (sy_call_t *)freebsd32_mknod, AUE_NULL }, /* 14 = freebsd32_mknod */ + { SYF_MPSAFE | AS(freebsd32_chmod_args), (sy_call_t *)freebsd32_chmod, AUE_NULL }, /* 15 = freebsd32_chmod */ + { SYF_MPSAFE | AS(freebsd32_chown_args), (sy_call_t *)freebsd32_chown, AUE_NULL }, /* 16 = freebsd32_chown */ { SYF_MPSAFE | AS(obreak_args), (sy_call_t *)obreak, AUE_NULL }, /* 17 = break */ { compat4(SYF_MPSAFE | AS(freebsd4_freebsd32_getfsstat_args),freebsd32_getfsstat), AUE_NULL }, /* 18 = old freebsd32_getfsstat */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 19 = obsolete olseek */ @@ -65,7 +65,7 @@ { SYF_MPSAFE | AS(accept_args), (sy_call_t *)accept, AUE_NULL }, /* 30 = accept */ { SYF_MPSAFE | AS(getpeername_args), (sy_call_t *)getpeername, AUE_NULL }, /* 31 = getpeername */ { SYF_MPSAFE | AS(getsockname_args), (sy_call_t *)getsockname, AUE_NULL }, /* 32 = getsockname */ - { SYF_MPSAFE | AS(access_args), (sy_call_t *)access, AUE_NULL }, /* 33 = access */ + { SYF_MPSAFE | AS(freebsd32_access_args), (sy_call_t *)freebsd32_access, AUE_NULL }, /* 33 = freebsd32_access */ { SYF_MPSAFE | AS(chflags_args), (sy_call_t *)chflags, AUE_NULL }, /* 34 = chflags */ { SYF_MPSAFE | AS(fchflags_args), (sy_call_t *)fchflags, AUE_NULL }, /* 35 = fchflags */ { SYF_MPSAFE | 0, (sy_call_t *)sync, AUE_NULL }, /* 36 = sync */ @@ -89,8 +89,8 @@ { SYF_MPSAFE | AS(ioctl_args), (sy_call_t *)ioctl, AUE_NULL }, /* 54 = ioctl */ { SYF_MPSAFE | AS(reboot_args), (sy_call_t *)reboot, AUE_NULL }, /* 55 = reboot */ { SYF_MPSAFE | AS(revoke_args), (sy_call_t *)revoke, AUE_NULL }, /* 56 = revoke */ - { SYF_MPSAFE | AS(symlink_args), (sy_call_t *)symlink, AUE_NULL }, /* 57 = symlink */ - { SYF_MPSAFE | AS(readlink_args), (sy_call_t *)readlink, AUE_NULL }, /* 58 = readlink */ + { SYF_MPSAFE | AS(freebsd32_symlink_args), (sy_call_t *)freebsd32_symlink, AUE_NULL }, /* 57 = freebsd32_symlink */ + { SYF_MPSAFE | AS(freebsd32_readlink_args), (sy_call_t *)freebsd32_readlink, AUE_NULL }, /* 58 = freebsd32_readlink */ { SYF_MPSAFE | AS(freebsd32_execve_args), (sy_call_t *)freebsd32_execve, AUE_NULL }, /* 59 = freebsd32_execve */ { SYF_MPSAFE | AS(umask_args), (sy_call_t *)umask, AUE_NULL }, /* 60 = umask */ { SYF_MPSAFE | AS(chroot_args), (sy_call_t *)chroot, AUE_NULL }, /* 61 = chroot */ @@ -160,7 +160,7 @@ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 125 = obsolete orecvfrom */ { SYF_MPSAFE | AS(setreuid_args), (sy_call_t *)setreuid, AUE_NULL }, /* 126 = setreuid */ { SYF_MPSAFE | AS(setregid_args), (sy_call_t *)setregid, AUE_NULL }, /* 127 = setregid */ - { SYF_MPSAFE | AS(rename_args), (sy_call_t *)rename, AUE_NULL }, /* 128 = rename */ + { SYF_MPSAFE | AS(freebsd32_rename_args), (sy_call_t *)freebsd32_rename, AUE_NULL }, /* 128 = freebsd32_rename */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 129 = obsolete otruncate */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 130 = obsolete ftruncate */ { SYF_MPSAFE | AS(flock_args), (sy_call_t *)flock, AUE_NULL }, /* 131 = flock */ @@ -168,8 +168,8 @@ { SYF_MPSAFE | AS(sendto_args), (sy_call_t *)sendto, AUE_NULL }, /* 133 = sendto */ { SYF_MPSAFE | AS(shutdown_args), (sy_call_t *)shutdown, AUE_NULL }, /* 134 = shutdown */ { SYF_MPSAFE | AS(socketpair_args), (sy_call_t *)socketpair, AUE_NULL }, /* 135 = socketpair */ - { SYF_MPSAFE | AS(mkdir_args), (sy_call_t *)mkdir, AUE_NULL }, /* 136 = mkdir */ - { SYF_MPSAFE | AS(rmdir_args), (sy_call_t *)rmdir, AUE_NULL }, /* 137 = rmdir */ + { SYF_MPSAFE | AS(freebsd32_mkdir_args), (sy_call_t *)freebsd32_mkdir, AUE_NULL }, /* 136 = freebsd32_mkdir */ + { SYF_MPSAFE | AS(freebsd32_rmdir_args), (sy_call_t *)freebsd32_rmdir, AUE_NULL }, /* 137 = freebsd32_rmdir */ { SYF_MPSAFE | AS(freebsd32_utimes_args), (sy_call_t *)freebsd32_utimes, AUE_NULL }, /* 138 = freebsd32_utimes */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 139 = obsolete 4.2 sigreturn */ { SYF_MPSAFE | AS(freebsd32_adjtime_args), (sy_call_t *)freebsd32_adjtime, AUE_NULL }, /* 140 = freebsd32_adjtime */ @@ -286,7 +286,7 @@ { SYF_MPSAFE | AS(rfork_args), (sy_call_t *)rfork, AUE_NULL }, /* 251 = rfork */ { SYF_MPSAFE | AS(openbsd_poll_args), (sy_call_t *)openbsd_poll, AUE_NULL }, /* 252 = openbsd_poll */ { SYF_MPSAFE | 0, (sy_call_t *)issetugid, AUE_NULL }, /* 253 = issetugid */ - { SYF_MPSAFE | AS(lchown_args), (sy_call_t *)lchown, AUE_NULL }, /* 254 = lchown */ + { SYF_MPSAFE | AS(freebsd32_lchown_args), (sy_call_t *)freebsd32_lchown, AUE_NULL }, /* 254 = freebsd32_lchown */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 255 = nosys */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 256 = nosys */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 257 = nosys */ @@ -306,7 +306,7 @@ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 271 = nosys */ { SYF_MPSAFE | AS(getdents_args), (sy_call_t *)getdents, AUE_NULL }, /* 272 = getdents */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 273 = nosys */ - { SYF_MPSAFE | AS(lchmod_args), (sy_call_t *)lchmod, AUE_NULL }, /* 274 = lchmod */ + { SYF_MPSAFE | AS(freebsd32_lchmod_args), (sy_call_t *)freebsd32_lchmod, AUE_NULL }, /* 274 = freebsd32_lchmod */ { SYF_MPSAFE | AS(lchown_args), (sy_call_t *)lchown, AUE_NULL }, /* 275 = netbsd_lchown */ { SYF_MPSAFE | AS(lutimes_args), (sy_call_t *)lutimes, AUE_NULL }, /* 276 = lutimes */ { SYF_MPSAFE | AS(msync_args), (sy_call_t *)msync, AUE_NULL }, /* 277 = netbsd_msync */ @@ -408,7 +408,7 @@ { AS(extattr_delete_fd_args), (sy_call_t *)extattr_delete_fd, AUE_NULL }, /* 373 = extattr_delete_fd */ { SYF_MPSAFE | AS(__setugid_args), (sy_call_t *)__setugid, AUE_NULL }, /* 374 = __setugid */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 375 = nfsclnt */ - { SYF_MPSAFE | AS(eaccess_args), (sy_call_t *)eaccess, AUE_NULL }, /* 376 = eaccess */ + { SYF_MPSAFE | AS(freebsd32_eaccess_args), (sy_call_t *)freebsd32_eaccess, AUE_NULL }, /* 376 = freebsd32_eaccess */ { 0, (sy_call_t *)nosys, AUE_NULL }, /* 377 = afs_syscall */ { AS(nmount_args), (sy_call_t *)nmount, AUE_NULL }, /* 378 = nmount */ { SYF_MPSAFE | 0, (sy_call_t *)kse_exit, AUE_NULL }, /* 379 = kse_exit */ diff -ru sys.old/compat/freebsd32/freebsd32_util.c sys/compat/freebsd32/freebsd32_util.c --- sys.old/compat/freebsd32/freebsd32_util.c Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_util.c Fri Dec 9 21:37:03 2005 @@ -0,0 +1,46 @@ +/*- + * Copyright (c) 2005 Antoine Pelisse + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include + +#include "opt_compat.h" + +#include +#include + +#include + +const char freebsd32_path[] = "/compat/ia32"; + +int +freebsd32_convpath(struct thread *td, char *path, enum uio_seg pathseg, + char **pbuf, int cflag) +{ + + return (kern_alternate_path(td, freebsd32_path, path, pathseg, pbuf, + cflag)); +} diff -ru sys.old/compat/freebsd32/freebsd32_util.h sys/compat/freebsd32/freebsd32_util.h --- sys.old/compat/freebsd32/freebsd32_util.h Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/freebsd32_util.h Fri Dec 9 21:37:03 2005 @@ -32,9 +32,10 @@ #include #include - #include +#include #include +#include #include struct freebsd32_ps_strings { @@ -47,6 +48,22 @@ #if defined(__amd64__) || defined(__ia64__) #include #endif + +int freebsd32_convpath(struct thread *, char *, enum uio_seg, char **, int); + +#define CONVPATH(td, upath, pathp, creat) \ + do { \ + int _error; \ + \ + _error = freebsd32_convpath(td, upath, UIO_USERSPACE, \ + pathp, creat); \ + if (*(pathp) == NULL) \ + return (_error); \ + } while (0) + +#define CONVPATHEXIST(td, upath, pathp) CONVPATH(td, upath, pathp, 0) +#define CONVPATHCREAT(td, upath, pathp) CONVPATH(td, upath, pathp, 1) +#define FREEPATH(path) free(path, M_TEMP) #define FREEBSD32_PS_STRINGS \ (FREEBSD32_USRSTACK - sizeof(struct freebsd32_ps_strings)) diff -ru sys.old/compat/freebsd32/syscalls.master sys/compat/freebsd32/syscalls.master --- sys.old/compat/freebsd32/syscalls.master Mon Dec 19 23:15:56 2005 +++ sys/compat/freebsd32/syscalls.master Fri Dec 9 21:49:32 2005 @@ -58,20 +58,22 @@ size_t nbyte); } 4 AUE_NULL MNOPROTO { ssize_t write(int fd, const void *buf, \ size_t nbyte); } -5 AUE_NULL MNOPROTO { int open(char *path, int flags, \ +5 AUE_NULL MSTD { int freebsd32_open(char *path, int flags, \ int mode); } 6 AUE_NULL MNOPROTO { int close(int fd); } 7 AUE_NULL MSTD { int freebsd32_wait4(int pid, int *status, \ int options, struct rusage32 *rusage); } 8 AUE_NULL OBSOL old creat -9 AUE_NULL MNOPROTO { int link(char *path, char *link); } -10 AUE_NULL MNOPROTO { int unlink(char *path); } +9 AUE_NULL MSTD { int freebsd32_link(char *path, char *link); } +10 AUE_NULL MSTD { int freebsd32_unlink(char *path); } 11 AUE_NULL OBSOL execv -12 AUE_NULL MNOPROTO { int chdir(char *path); } -13 AUE_NULL MNOPROTO { int fchdir(int fd); } -14 AUE_NULL MNOPROTO { int mknod(char *path, int mode, int dev); } -15 AUE_NULL MNOPROTO { int chmod(char *path, int mode); } -16 AUE_NULL MNOPROTO { int chown(char *path, int uid, int gid); } +12 AUE_NULL MSTD { int freebsd32_chdir(char *path); } +13 AUE_NULL MNOPROTO { int fchdir(int fd); } +14 AUE_NULL MSTD { int freebsd32_mknod(char *path, int mode, \ + int dev); } +15 AUE_NULL MSTD { int freebsd32_chmod(char *path, int mode); } +16 AUE_NULL MSTD { int freebsd32_chown(char *path, int uid, \ + int gid); } 17 AUE_NULL MNOPROTO { int obreak(char *nsize); } break \ obreak_args int 18 AUE_NULL MCOMPAT4 { int freebsd32_getfsstat( \ @@ -101,10 +103,10 @@ int *alen); } 32 AUE_NULL MNOPROTO { int getsockname(int fdes, caddr_t asa, \ int *alen); } -33 AUE_NULL MNOPROTO { int access(char *path, int flags); } -34 AUE_NULL MNOPROTO { int chflags(char *path, int flags); } -35 AUE_NULL MNOPROTO { int fchflags(int fd, int flags); } -36 AUE_NULL MNOPROTO { int sync(void); } +33 AUE_NULL MSTD { int freebsd32_access(char *path, int flags); } +34 AUE_NULL MNOPROTO { int chflags(char *path, int flags); } +35 AUE_NULL MNOPROTO { int fchflags(int fd, int flags); } +36 AUE_NULL MNOPROTO { int sync(void); } 37 AUE_NULL MNOPROTO { int kill(int pid, int signum); } 38 AUE_NULL UNIMPL ostat 39 AUE_NULL MNOPROTO { pid_t getppid(void); } @@ -133,15 +135,16 @@ 54 AUE_NULL MNOPROTO { int ioctl(int fd, u_long com, \ caddr_t data); } 55 AUE_NULL MNOPROTO { int reboot(int opt); } -56 AUE_NULL MNOPROTO { int revoke(char *path); } -57 AUE_NULL MNOPROTO { int symlink(char *path, char *link); } -58 AUE_NULL MNOPROTO { int readlink(char *path, char *buf, \ - int count); } +56 AUE_NULL MNOPROTO { int revoke(char *path); } +57 AUE_NULL MSTD { int freebsd32_symlink(char *path, \ + char *link); } +58 AUE_NULL MSTD { int freebsd32_readlink(char *path, \ + char *buf, int count); } 59 AUE_NULL MSTD { int freebsd32_execve(char *fname, \ u_int32_t *argv, u_int32_t *envv); } 60 AUE_NULL MNOPROTO { int umask(int newmask); } umask \ umask_args int -61 AUE_NULL MNOPROTO { int chroot(char *path); } +61 AUE_NULL MNOPROTO { int chroot(char *path); } 62 AUE_NULL OBSOL ofstat 63 AUE_NULL OBSOL ogetkerninfo 64 AUE_NULL OBSOL ogetpagesize @@ -190,7 +193,7 @@ struct timeval32 *tv); } ; XXX need to override for big-endian - little-endian should work fine. 94 AUE_NULL UNIMPL setdopt -95 AUE_NULL MNOPROTO { int fsync(int fd); } +95 AUE_NULL MNOPROTO { int fsync(int fd); } 96 AUE_NULL MNOPROTO { int setpriority(int which, int who, \ int prio); } 97 AUE_NULL MNOPROTO { int socket(int domain, int type, \ @@ -235,24 +238,24 @@ 122 AUE_NULL MSTD { int freebsd32_settimeofday( \ struct timeval32 *tv, \ struct timezone *tzp); } -123 AUE_NULL MNOPROTO { int fchown(int fd, int uid, int gid); } -124 AUE_NULL MNOPROTO { int fchmod(int fd, int mode); } +123 AUE_NULL MNOPROTO { int fchown(int fd, int uid, int gid); } +124 AUE_NULL MNOPROTO { int fchmod(int fd, int mode); } 125 AUE_NULL OBSOL orecvfrom 126 AUE_NULL MNOPROTO { int setreuid(int ruid, int euid); } 127 AUE_NULL MNOPROTO { int setregid(int rgid, int egid); } -128 AUE_NULL MNOPROTO { int rename(char *from, char *to); } +128 AUE_NULL MSTD { int freebsd32_rename(char *from, char *to); } 129 AUE_NULL OBSOL otruncate 130 AUE_NULL OBSOL ftruncate 131 AUE_NULL MNOPROTO { int flock(int fd, int how); } -132 AUE_NULL MNOPROTO { int mkfifo(char *path, int mode); } +132 AUE_NULL MNOPROTO { int mkfifo(char *path, int mode); } 133 AUE_NULL MNOPROTO { int sendto(int s, caddr_t buf, \ size_t len, int flags, caddr_t to, \ int tolen); } 134 AUE_NULL MNOPROTO { int shutdown(int s, int how); } 135 AUE_NULL MNOPROTO { int socketpair(int domain, int type, \ int protocol, int *rsv); } -136 AUE_NULL MNOPROTO { int mkdir(char *path, int mode); } -137 AUE_NULL MNOPROTO { int rmdir(char *path); } +136 AUE_NULL MSTD { int freebsd32_mkdir(char *path, int mode); } +137 AUE_NULL MSTD { int freebsd32_rmdir(char *path); } 138 AUE_NULL MSTD { int freebsd32_utimes(char *path, \ struct timeval32 *tptr); } 139 AUE_NULL OBSOL 4.2 sigreturn @@ -289,7 +292,7 @@ struct statfs32 *buf); } 159 AUE_NULL UNIMPL nosys 160 AUE_NULL UNIMPL nosys -161 AUE_NULL MNOPROTO { int getfh(char *fname, \ +161 AUE_NULL MNOPROTO { int getfh(char *fname, \ struct fhandle *fhp); } 162 AUE_NULL MNOPROTO { int getdomainname(char *domainname, \ int len); } @@ -451,7 +454,8 @@ 252 AUE_NULL MNOPROTO { int openbsd_poll(struct pollfd *fds, \ u_int nfds, int timeout); } 253 AUE_NULL MNOPROTO { int issetugid(void); } -254 AUE_NULL MNOPROTO { int lchown(char *path, int uid, int gid); } +254 AUE_NULL MSTD { int freebsd32_lchown(char *path, int uid, \ + int gid); } 255 AUE_NULL UNIMPL nosys 256 AUE_NULL UNIMPL nosys 257 AUE_NULL UNIMPL nosys @@ -469,20 +473,21 @@ 269 AUE_NULL UNIMPL nosys 270 AUE_NULL UNIMPL nosys 271 AUE_NULL UNIMPL nosys -272 AUE_NULL MNOPROTO { int getdents(int fd, char *buf, \ +272 AUE_NULL MNOPROTO { int getdents(int fd, char *buf, \ size_t count); } 273 AUE_NULL UNIMPL nosys -274 AUE_NULL MNOPROTO { int lchmod(char *path, mode_t mode); } +274 AUE_NULL MSTD { int freebsd32_lchmod(char *path, \ + mode_t mode); } 275 AUE_NULL MNOPROTO { int lchown(char *path, uid_t uid, \ gid_t gid); } netbsd_lchown \ lchown_args int -276 AUE_NULL MNOPROTO { int lutimes(char *path, \ +276 AUE_NULL MNOPROTO { int lutimes(char *path, \ struct timeval *tptr); } 277 AUE_NULL MNOPROTO { int msync(void *addr, size_t len, \ int flags); } netbsd_msync msync_args int -278 AUE_NULL MNOPROTO { int nstat(char *path, struct nstat *ub); } +278 AUE_NULL MNOPROTO { int nstat(char *path, struct nstat *ub); } 279 AUE_NULL MNOPROTO { int nfstat(int fd, struct nstat *sb); } -280 AUE_NULL MNOPROTO { int nlstat(char *path, struct nstat *ub); } +280 AUE_NULL MNOPROTO { int nlstat(char *path, struct nstat *ub); } 281 AUE_NULL UNIMPL nosys 282 AUE_NULL UNIMPL nosys 283 AUE_NULL UNIMPL nosys @@ -510,9 +515,9 @@ 297 AUE_NULL MCOMPAT4 { int freebsd32_fhstatfs( \ const struct fhandle *u_fhp, \ struct statfs32 *buf); } -298 AUE_NULL MNOPROTO { int fhopen(const struct fhandle *u_fhp, \ +298 AUE_NULL MNOPROTO { int fhopen(const struct fhandle *u_fhp, \ int flags); } -299 AUE_NULL MNOPROTO { int fhstat(const struct fhandle *u_fhp, \ +299 AUE_NULL MNOPROTO { int fhstat(const struct fhandle *u_fhp, \ struct stat *sb); } ; syscall numbers for FreeBSD 300 AUE_NULL MNOPROTO { int modnext(int modid); } @@ -545,7 +550,7 @@ 323 AUE_NULL OBSOL thr_wakeup 324 AUE_NULL MNOPROTO { int mlockall(int how); } 325 AUE_NULL MNOPROTO { int munlockall(void); } -326 AUE_NULL MNOPROTO { int __getcwd(u_char *buf, u_int buflen); } +326 AUE_NULL MNOPROTO { int __getcwd(u_char *buf, u_int buflen); } 327 AUE_NULL MNOPROTO { int sched_setparam (pid_t pid, \ const struct sched_param *param); } @@ -568,7 +573,7 @@ u_int32_t offsetlo, u_int32_t offsethi, \ size_t nbytes, struct sf_hdtr *hdtr, \ off_t *sbytes, int flags); } -337 AUE_NULL MNOPROTO { int kldsym(int fileid, int cmd, \ +337 AUE_NULL MNOPROTO { int kldsym(int fileid, int cmd, \ void *data); } 338 AUE_NULL MNOPROTO { int jail(struct jail *jail); } 339 AUE_NULL UNIMPL pioctl @@ -642,26 +647,27 @@ const char *attrname); } 374 AUE_NULL MNOPROTO { int __setugid(int flag); } 375 AUE_NULL UNIMPL nfsclnt -376 AUE_NULL MNOPROTO { int eaccess(char *path, int flags); } +376 AUE_NULL MSTD { int freebsd32_eaccess(char *path, \ + int flags); } 377 AUE_NULL UNIMPL afs_syscall 378 AUE_NULL NOPROTO { int nmount(struct iovec *iovp, \ unsigned int iovcnt, int flags); } -379 AUE_NULL MNOPROTO { int kse_exit(void); } -380 AUE_NULL MNOPROTO { int kse_wakeup(struct kse_mailbox *mbx); } -381 AUE_NULL MNOPROTO { int kse_create(struct kse_mailbox *mbx, \ +379 AUE_NULL MNOPROTO { int kse_exit(void); } +380 AUE_NULL MNOPROTO { int kse_wakeup(struct kse_mailbox *mbx); } +381 AUE_NULL MNOPROTO { int kse_create(struct kse_mailbox *mbx, \ int newgroup); } -382 AUE_NULL MNOPROTO { int kse_thr_interrupt( \ +382 AUE_NULL MNOPROTO { int kse_thr_interrupt( \ struct kse_thr_mailbox *tmbx); } -383 AUE_NULL MNOPROTO { int kse_release(void); } +383 AUE_NULL MNOPROTO { int kse_release(void); } 384 AUE_NULL UNIMPL __mac_get_proc 385 AUE_NULL UNIMPL __mac_set_proc 386 AUE_NULL UNIMPL __mac_get_fd 387 AUE_NULL UNIMPL __mac_get_file 388 AUE_NULL UNIMPL __mac_set_fd 389 AUE_NULL UNIMPL __mac_set_file -390 AUE_NULL MNOPROTO { int kenv(int what, const char *name, \ +390 AUE_NULL MNOPROTO { int kenv(int what, const char *name, \ char *value, int len); } -391 AUE_NULL MNOPROTO { int lchflags(const char *path, int flags); } +391 AUE_NULL MNOPROTO { int lchflags(const char *path, int flags); } 392 AUE_NULL MNOPROTO { int uuidgen(struct uuid *store, \ int count); } 393 AUE_NULL MSTD { int freebsd32_sendfile(int fd, int s, \ @@ -669,12 +675,12 @@ size_t nbytes, struct sf_hdtr *hdtr, \ off_t *sbytes, int flags); } 394 AUE_NULL UNIMPL mac_syscall -395 AUE_NULL MNOPROTO { int getfsstat(struct statfs *buf, \ +395 AUE_NULL MNOPROTO { int getfsstat(struct statfs *buf, \ long bufsize, int flags); } -396 AUE_NULL MNOPROTO { int statfs(char *path, \ +396 AUE_NULL MNOPROTO { int statfs(char *path, \ struct statfs *buf); } -397 AUE_NULL MNOPROTO { int fstatfs(int fd, struct statfs *buf); } -398 AUE_NULL MNOPROTO { int fhstatfs(const struct fhandle *u_fhp, \ +397 AUE_NULL MNOPROTO { int fstatfs(int fd, struct statfs *buf); } +398 AUE_NULL MNOPROTO { int fhstatfs(const struct fhandle *u_fhp, \ struct statfs *buf); } 399 AUE_NULL UNIMPL nosys ; XXX implement these? diff -ru sys.old/conf/files.amd64 sys/conf/files.amd64 --- sys.old/conf/files.amd64 Mon Dec 19 23:15:56 2005 +++ sys/conf/files.amd64 Fri Dec 9 21:37:03 2005 @@ -204,9 +204,11 @@ amd64/ia32/ia32_signal.c optional compat_ia32 amd64/ia32/ia32_sigtramp.S optional compat_ia32 amd64/ia32/ia32_syscall.c optional compat_ia32 +compat/freebsd32/freebsd32_file.c optional compat_ia32 compat/freebsd32/freebsd32_misc.c optional compat_ia32 compat/freebsd32/freebsd32_syscalls.c optional compat_ia32 compat/freebsd32/freebsd32_sysent.c optional compat_ia32 +compat/freebsd32/freebsd32_util.c optional compat_ia32 compat/ia32/ia32_sysvec.c optional compat_ia32 kern/imgact_elf32.c optional compat_ia32 # diff -ru sys.old/conf/files.ia64 sys/conf/files.ia64 --- sys.old/conf/files.ia64 Mon Dec 19 23:15:56 2005 +++ sys/conf/files.ia64 Fri Dec 9 21:37:03 2005 @@ -28,9 +28,11 @@ no-obj no-implicit-rule before-depend \ clean "ukbdmap.h" # +compat/freebsd32/freebsd32_file.c optional compat_ia32 compat/freebsd32/freebsd32_misc.c optional compat_ia32 compat/freebsd32/freebsd32_syscalls.c optional compat_ia32 compat/freebsd32/freebsd32_sysent.c optional compat_ia32 +compat/freebsd32/freebsd32_util.c optional compat_ia32 compat/ia32/ia32_sysvec.c optional compat_ia32 contrib/ia64/libuwx/src/uwx_bstream.c standard contrib/ia64/libuwx/src/uwx_context.c standard diff -ru sys.old/kern/vfs_syscalls.c sys/kern/vfs_syscalls.c --- sys.old/kern/vfs_syscalls.c Mon Dec 19 23:15:56 2005 +++ sys/kern/vfs_syscalls.c Fri Dec 9 21:37:03 2005 @@ -1908,18 +1908,25 @@ int flags; } */ *uap; { + + return (kern_eaccess(td, uap->path, UIO_USERSPACE, uap->flags)); +} + +int +kern_eaccess(struct thread *td, char *path, enum uio_seg pathseg, int flags) +{ struct nameidata nd; struct vnode *vp; int vfslocked; int error; - NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | MPSAFE, UIO_USERSPACE, - uap->path, td); + NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | MPSAFE, pathseg, + path, td); if ((error = namei(&nd)) != 0) return (error); vp = nd.ni_vp; vfslocked = NDHASGIANT(&nd); - error = vn_access(vp, uap->flags, td->td_ucred, td); + error = vn_access(vp, flags, td->td_ucred, td); NDFREE(&nd, NDF_ONLY_PNBUF); vput(vp); VFS_UNLOCK_GIANT(vfslocked); @@ -2521,16 +2528,23 @@ int mode; } */ *uap; { + + return (kern_lchmod(td, uap->path, UIO_USERSPACE, uap->mode)); +} + +int +kern_lchmod(struct thread *td, char *path, enum uio_seg pathseg, int mode) +{ int error; struct nameidata nd; int vfslocked; - NDINIT(&nd, LOOKUP, NOFOLLOW | MPSAFE, UIO_USERSPACE, uap->path, td); + NDINIT(&nd, LOOKUP, NOFOLLOW | MPSAFE, pathseg, path, td); if ((error = namei(&nd)) != 0) return (error); vfslocked = NDHASGIANT(&nd); NDFREE(&nd, NDF_ONLY_PNBUF); - error = setfmode(td, nd.ni_vp, uap->mode); + error = setfmode(td, nd.ni_vp, mode); vrele(nd.ni_vp); VFS_UNLOCK_GIANT(vfslocked); return (error); ------=_Part_3535_12319067.1138364058295-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 13:06:43 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 07B4916A420 for ; Fri, 27 Jan 2006 13:06:43 +0000 (GMT) (envelope-from Lennart.Sorth@uni-c.dk) Received: from mail.ssi.uni-c.dk (mail.ssi.uni-c.dk [130.228.9.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EAFE43D49 for ; Fri, 27 Jan 2006 13:06:42 +0000 (GMT) (envelope-from Lennart.Sorth@uni-c.dk) Received: from [172.16.121.2] (ls.ssi.uni-c.dk [172.16.121.2]) by mail.ssi.uni-c.dk (Postfix) with ESMTP id 8C130B84D; Fri, 27 Jan 2006 14:06:40 +0100 (CET) Message-ID: <43DA1A5A.3000409@uni-c.dk> Date: Fri, 27 Jan 2006 14:04:26 +0100 From: Lennart Sorth User-Agent: Mozilla Thunderbird 1.0 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <20060127020350.02abf989.kgunders@teamcool.net> <200601271228.02675.groot@kde.org> In-Reply-To: <200601271228.02675.groot@kde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 13:06:43 -0000 Adriaan de Groot wrote: > and surfing dubious websites (webbrowser + mplayer), amd64 > desktops are fine. ... as long as you don't need win32-codecs which nowadays means you're cut off from most streaming services (including NasaTV :-( ) But apart from that FreeBSD 6.0 on amd64 desktop is a pleasure, and seems a lot quicker than 5.4 /Lennart From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 15:50:37 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 0864016A424 for ; Fri, 27 Jan 2006 15:50:37 +0000 (GMT) (envelope-from morten@atreides.freenix.no) Received: from freenix.no (atreides.freenix.no [212.33.142.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89CA843E38 for ; Fri, 27 Jan 2006 14:16:35 +0000 (GMT) (envelope-from morten@atreides.freenix.no) Received: from atreides.freenix.no (localhost [127.0.0.1]) by freenix.no (8.13.1/8.13.1) with ESMTP id k0REGVcW059557 for ; Fri, 27 Jan 2006 15:16:31 +0100 (CET) (envelope-from morten@atreides.freenix.no) Received: (from morten@localhost) by atreides.freenix.no (8.13.1/8.13.1/Submit) id k0REGQa3059556 for freebsd-amd64@freebsd.org; Fri, 27 Jan 2006 15:16:26 +0100 (CET) (envelope-from morten) Date: Fri, 27 Jan 2006 15:16:26 +0100 From: "Morten A. Middelthon" To: freebsd-amd64@freebsd.org Message-ID: <20060127141626.GA38042@freenix.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline X-PGP-Key: http://freenix.no/~morten/pgp.txt X-PGP-Key-FingerPrint: D48B 5C4E 1590 7DE6 08A0 6539 BECC F62E 829F DF6A X-Operating-System: FreeBSD 4.11-RELEASE-p2 X-Warning: So cunning you could brush your teeth with it. User-Agent: Mutt/1.5.11 Subject: CPUTYPE in /etc/make.conf X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 15:50:37 -0000 --TRYliJ5NKNqkz5bu Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi list, I'm currently setting up a Dell PowerEdge 1855 server using Intel's EM64T. I am therefore installing the FreeBSD 6.0 amd64 port. What should I set CPUTY= PE to in /etc/make.conf? If I try with pentium4 I get an error during 'make buildworld' telling me that the cpu selected does not support 64 bit instructions, which I guess is correct. But what should I set it to then? D= oes it actually make any big difference anyway?=20 The server has 2 x Intel Xeon 3.2 GHz CPU with EM64T. I have attached the dmesg output, if that's of any interest with regards, --=20 Morten A. Middelthon A system admin's life is a sorry one. The only advantage he has over Emergency Room doctors is that malpractice suits are rare. On the other hand, ER doctors never have to deal with patients installing new versions of their own innards! (Michael O'Brien) --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.amd64" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #0: Fri Jan 27 13:30:16 CET 2006 morten@amd64-test:/usr/src/sys/amd64/compile/amd64-test Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf43 Stepping =3D 3 Features=3D0xbfebfbff Features2=3D0x641d> AMD Features=3D0x20100800 Hyperthreading: 2 logical CPUs real memory =3D 2147221504 (2047 MB) avail memory =3D 2066685952 (1970 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic1: WARNING: intbase 32 !=3D expected base 24 ioapic2: Changing APIC ID to 10 ioapic2: WARNING: intbase 64 !=3D expected base 56 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 15 on acpi0 pci_link1: irq 7 on acpi0 pci_link2: irq 10 on acpi0 pci_link3: irq 14 on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: irq 11 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 4.0 on pci0 pci2: on pcib2 pcib3: at device 6.0 on pci0 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 mpt0: port 0xec00-0xecff mem 0xfe9f0000-0xfe= 9fffff,0xfe9e0000-0xfe9effff irq 42 at device 4.0 on pci4 mpt0: [GIANT-LOCKED] mpt0: MPI Version=3D1.2.12.0 mpt0: Unhandled Event Notify Frame. Event 0xa. mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) pci3: at device 0.1 (no driver atta= ched) pcib5: at device 0.2 on pci3 pci5: on pcib5 em0: port 0xdcc0-0x= dcff mem 0xfe7e0000-0xfe7fffff irq 68 at device 4.0 on pci5 em0: Ethernet address: 00:14:22:b1:f1:36 em0: Speed:1000 Mbps Duplex:Full em1: port 0xdc80-0x= dcbf mem 0xfe7c0000-0xfe7dffff irq 69 at device 4.1 on pci5 em1: Ethernet address: 00:14:22:b1:f1:37 em1: Speed:1000 Mbps Duplex:Full pci3: at device 0.3 (no driver atta= ched) uhci0: port 0xbce0-0xbcff irq 1= 6 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbcc0-0xbcdf irq 1= 9 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfeb00000-0xfeb003ff irq 23= at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib6: at device 30.0 on pci0 pci6: on pcib6 pci6: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0x= cefff,0xcf000-0xcffff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:0:0): Primary (mpt0:0:1): Secondary mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:0): Physical (mpt0:0:0), Pass-thru (mpt0:1:0) (mpt0:vol0:0): Online (mpt0:vol0:1): Physical (mpt0:0:1), Pass-thru (mpt0:1:1) (mpt0:vol0:1): Online ses0 at mpt0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device pass2 at mpt0 bus 1 target 0 lun 0 pass2: Fixed unknown SCSI-3 device=20 pass2: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queuei= ng Enabled pass3 at mpt0 bus 1 target 1 lun 0 pass3: Fixed unknown SCSI-3 device=20 pass3: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queuei= ng Enabled da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing= Enabled da0: 69878MB (143110145 512 byte sectors: 255H 63S/T 8908C) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/da0s3a --+QahgC5+KEYLbs62-- --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD2is5vsz2LoKf32oRAvjEAJwLOp2MU0rjgUVdLNejGTFytZ58kwCfYila f+j5gGYZYhgRL9qlXabkIxM= =5bFC -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 16:12:34 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 93BBB16A420 for ; Fri, 27 Jan 2006 16:12:34 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B5884429C for ; Fri, 27 Jan 2006 16:12:34 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so388003wxc for ; Fri, 27 Jan 2006 08:12:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZUsLck9AepZ+6NGFQ0Q2J9QERBmXeyD86agr08gLK7Oqje9wYjEBNIc9QANCSGGmQ4zGK60Vfap2w7g4uIlDqa+/p6cDtRlX9kSTrMQNVL2fJ87hiRgOulsdxAlFmX0r1mZYxm/7CMOOvstLAohWqviWHk5pq282fZDCE5JYWZk= Received: by 10.70.108.19 with SMTP id g19mr3672054wxc; Fri, 27 Jan 2006 08:12:33 -0800 (PST) Received: by 10.70.105.2 with HTTP; Fri, 27 Jan 2006 08:12:33 -0800 (PST) Message-ID: <84dead720601270812vbfab477i27e6def1aed324f6@mail.gmail.com> Date: Fri, 27 Jan 2006 21:42:33 +0530 From: Joseph Koshy To: "Morten A. Middelthon" In-Reply-To: <20060127141626.GA38042@freenix.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060127141626.GA38042@freenix.no> Cc: freebsd-amd64@freebsd.org Subject: Re: CPUTYPE in /etc/make.conf X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 16:12:34 -0000 > What should I set CPUTYPE to in /etc/make.conf? You can leave it blank or set it to 'nocona'. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 16:25:21 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 144C016A473 for ; Fri, 27 Jan 2006 16:25:18 +0000 (GMT) (envelope-from jonnyv@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A03C44169 for ; Fri, 27 Jan 2006 15:55:44 +0000 (GMT) (envelope-from jonnyv@gmail.com) Received: by uproxy.gmail.com with SMTP id o2so629087uge for ; Fri, 27 Jan 2006 07:55:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Xik6HiGL4DM5qBFvkUhhdL6APHV+S4saaZ0PLcN1X5q1D3M5hmnRYXevWqb7UtFdIVSq4NSTGhOIt1Qg1ofhhIqWeVYpKVXcMgHKzpIDQM2aYXIFhkRoT2j2hEz10rOaVDYmRymD4bP+LmhGzxKvm+yNZeh0Dm5xDsYgrNLxtSo= Received: by 10.66.220.3 with SMTP id s3mr119405ugg; Fri, 27 Jan 2006 07:55:42 -0800 (PST) Received: by 10.66.249.15 with HTTP; Fri, 27 Jan 2006 07:55:42 -0800 (PST) Message-ID: Date: Fri, 27 Jan 2006 08:55:42 -0700 From: Jon Kuster To: "Morten A. Middelthon" In-Reply-To: <20060127141626.GA38042@freenix.no> MIME-Version: 1.0 References: <20060127141626.GA38042@freenix.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-amd64@freebsd.org Subject: Re: CPUTYPE in /etc/make.conf X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 16:25:21 -0000 nocona is what you want. On 1/27/06, Morten A. Middelthon wrote: > > Hi list, > > I'm currently setting up a Dell PowerEdge 1855 server using Intel's EM64T= . > I > am therefore installing the FreeBSD 6.0 amd64 port. What should I set > CPUTYPE > to in /etc/make.conf? If I try with pentium4 I get an error during 'make > buildworld' telling me that the cpu selected does not support 64 bit > instructions, which I guess is correct. But what should I set it to then? > Does > it actually make any big difference anyway? > > The server has 2 x Intel Xeon 3.2 GHz CPU with EM64T. I have attached the > dmesg output, if that's of any interest > > with regards, > > -- > Morten A. Middelthon > > A system admin's life is a sorry one. The only advantage he has > over Emergency Room doctors is that malpractice suits are rare. > On the other hand, ER doctors never have to deal with patients > installing new versions of their own innards! (Michael O'Brien) > > > From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 16:27:45 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 343CB16A420 for ; Fri, 27 Jan 2006 16:27:45 +0000 (GMT) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (gw.zefyris.com [213.41.131.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81BAF43F19 for ; Fri, 27 Jan 2006 16:27:23 +0000 (GMT) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (localhost [127.0.0.1]) by aoi.wolfpond.org (8.13.4/8.13.4) with ESMTP id k0RGROdo029493; Fri, 27 Jan 2006 17:27:24 +0100 (CET) (envelope-from ftigeot@aoi.wolfpond.org) Received: (from ftigeot@localhost) by aoi.wolfpond.org (8.13.4/8.13.1/Submit) id k0RGRLd4029492; Fri, 27 Jan 2006 17:27:21 +0100 (CET) (envelope-from ftigeot) Date: Fri, 27 Jan 2006 17:27:21 +0100 From: Francois Tigeot To: Ken Gunderson Message-ID: <20060127162721.GB27084@aoi.wolfpond.org> References: <20060127020350.02abf989.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060127020350.02abf989.kgunders@teamcool.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 16:27:45 -0000 On Fri, Jan 27, 2006 at 02:03:50AM -0700, Ken Gunderson wrote: > > I've only run fbsd-amd64 on servers. My favorite server ports all > work great but not sure about status of desktop related stuff. For > example, I know OpenOffice has issues. Any other gotchas I should know > about? This will depend on your application mix. I have been running a 64-bit desktop for about two years without too much trouble apart from some Windowmaker bugs. For OpenOffice, there is no native version and the FreeBSD/i386 package doesn't run. The Linux/i386 version works like a charm, howewer. > Also that there were some thread a while back that i386 was better > performer if you don't need the extra ram capability. But that was > also in reference to 5.x. I believe it was mainly due to assembly optimized routines in the i386 version versus straight C for amd64. FreeBSD/amd64 should become relatively faster as these are rewritten in assembly again. > What would y'all recommend for a desktop machine? Why don't you try both ? You can partition the machine with a big home directory shared between two different FreeBSD installations... -- Francois Tigeot From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 16:56:55 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org 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 39E9F16A420; Fri, 27 Jan 2006 16:56:55 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id D810843D49; Fri, 27 Jan 2006 16:56:54 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id 9EF2C5E48E5; Fri, 27 Jan 2006 08:56:54 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 1ACFD5E4884; Fri, 27 Jan 2006 08:56:50 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Fri, 27 Jan 2006 08:56:47 -0800 To: Danny Braniss X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Tom Rhodes , freebsd-amd64@FreeBSD.org, Kris Kennaway Subject: Re: amd64/92410: calloc.c missing from Makefile.inc X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 16:56:55 -0000 On Jan 27, 2006, at 2:13 AM, Danny Braniss wrote: >> The following reply was made to PR amd64/92410; it has been noted >> by GNATS. >> >> From: Kris Kennaway >> To: Bruce Becker >> Cc: freebsd-gnats-submit@FreeBSD.org >> Subject: Re: amd64/92410: calloc.c missing from Makefile.inc >> Date: Fri, 27 Jan 2006 04:57:56 -0500 >> >> --ZGiS0Q5IWpPtfppv >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On Fri, Jan 27, 2006 at 09:21:44AM +0000, Bruce Becker wrote: >>> =20 >>>> Number: 92410 >>>> Category: amd64 >>>> Synopsis: calloc.c missing from Makefile.inc >>>> Confidential: no >>>> Severity: critical >>>> Priority: high >>>> Responsible: freebsd-amd64 >>>> State: open >>>> Quarter: =20 >>>> Keywords: =20 >>>> Date-Required: >>>> Class: sw-bug >>>> Submitter-Id: current-users >>>> Arrival-Date: Fri Jan 27 09:30:08 GMT 2006 >>>> Closed-Date: >>>> Last-Modified: >>>> Originator: Bruce Becker >>>> Release: 6.0 >>>> Organization: >>> G.T.S. >>>> Environment: >>> FreeBSD vhcst.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 >>> 23:25:4= >> 9 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 >>> =20 >>>> Description: >>> =20 >>> Make buildworld failed with missing reference to calloc at link >>> of atrun >> >> You omitted the error. It's probably caused by something on your >> end, >> since 6.0-STABLE in fact builds just fine. > > it's happening to me too: (cvs'ed about one hour ago) This is due to a bad MFC by trhodes, when he added th a64l(), l64a(), and l64a_r() functions. calloc.c was inadvertently removed from MISRCS. Jason From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 17:45:45 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 EFB9C16A420 for ; Fri, 27 Jan 2006 17:45:45 +0000 (GMT) (envelope-from satyam@sklinks.com) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by mx1.FreeBSD.org (Postfix) with SMTP id 86B8E4437C for ; Fri, 27 Jan 2006 17:45:45 +0000 (GMT) (envelope-from satyam@sklinks.com) Received: (qmail 40804 invoked from network); 27 Jan 2006 17:45:36 -0000 Received: from unknown (HELO prajipati-freebsd.prajipati-freebsd) (varuna@sbcglobal.net@69.106.241.223 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 27 Jan 2006 17:45:36 -0000 From: Joseph Vella To: freebsd-amd64@freebsd.org Date: Fri, 27 Jan 2006 09:49:57 -0800 User-Agent: KMail/1.8.2 References: <20060127141626.GA38042@freenix.no> In-Reply-To: <20060127141626.GA38042@freenix.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601270949.57992.satyam@sklinks.com> Subject: Is SMP included in i386? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 17:45:46 -0000 I'm getting a new AMD 64 X2 for use as a desktop machine. I want to have flash and w32codecs, etc..., so I'm planning on using a 32 bit kernel. Can I start with the i386 iso cd set? I assume I would have to compile it from there? Anyone have any tips or suggestions for what I want to do? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 17:46:02 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 2317816A420 for ; Fri, 27 Jan 2006 17:46:02 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC54D4437C for ; Fri, 27 Jan 2006 17:46:01 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 5C9F8F80F for ; Fri, 27 Jan 2006 10:46:01 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 11415F805 for ; Fri, 27 Jan 2006 10:46:01 -0700 (MST) Date: Fri, 27 Jan 2006 10:46:00 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060127104600.1ffa38c9.kgunders@teamcool.net> In-Reply-To: <84dead720601270812vbfab477i27e6def1aed324f6@mail.gmail.com> References: <20060127141626.GA38042@freenix.no> <84dead720601270812vbfab477i27e6def1aed324f6@mail.gmail.com> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: CPUTYPE in /etc/make.conf X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 17:46:02 -0000 On Fri, 27 Jan 2006 21:42:33 +0530 Joseph Koshy wrote: > > What should I set CPUTYPE to in /etc/make.conf? > > You can leave it blank or set it to 'nocona'. ALong similar vein- is there a difference is between "k8" and "opteron" when running an opteron on i386 arch?? -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 17:47:48 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 476FE16A5E3 for ; Fri, 27 Jan 2006 17:47:35 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E23643F76 for ; Fri, 27 Jan 2006 17:14:47 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 4A2B3F80F for ; Fri, 27 Jan 2006 10:14:47 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 273A8F805 for ; Fri, 27 Jan 2006 10:14:47 -0700 (MST) Date: Fri, 27 Jan 2006 10:14:45 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060127101445.535dcaa8.kgunders@teamcool.net> In-Reply-To: <20060127162721.GB27084@aoi.wolfpond.org> References: <20060127020350.02abf989.kgunders@teamcool.net> <20060127162721.GB27084@aoi.wolfpond.org> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 17:47:49 -0000 On Fri, 27 Jan 2006 17:27:21 +0100 Francois Tigeot wrote: > On Fri, Jan 27, 2006 at 02:03:50AM -0700, Ken Gunderson wrote: > > > > I've only run fbsd-amd64 on servers. My favorite server ports all > > work great but not sure about status of desktop related stuff. For > > example, I know OpenOffice has issues. Any other gotchas I should know > > about? > > This will depend on your application mix. > > I have been running a 64-bit desktop for about two years without too > much trouble apart from some Windowmaker bugs. > > For OpenOffice, there is no native version and the FreeBSD/i386 package > doesn't run. The Linux/i386 version works like a charm, howewer. > > > Also that there were some thread a while back that i386 was better > > performer if you don't need the extra ram capability. But that was > > also in reference to 5.x. > > I believe it was mainly due to assembly optimized routines in the i386 > version versus straight C for amd64. > FreeBSD/amd64 should become relatively faster as these are rewritten in > assembly again. > > > What would y'all recommend for a desktop machine? > > Why don't you try both ? You can partition the machine with a big home > directory shared between two different FreeBSD installations... Good idea;-) But mainly because I don't have much spare time at the moment...;-( Need things to "just work". So that's why I inquired. Thanks to all for their comments. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 17:55:05 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 D9F9C16A420 for ; Fri, 27 Jan 2006 17:55:05 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A68143D6A for ; Fri, 27 Jan 2006 17:55:05 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id A6710F80F for ; Fri, 27 Jan 2006 10:55:04 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 5A102F805 for ; Fri, 27 Jan 2006 10:55:04 -0700 (MST) Date: Fri, 27 Jan 2006 10:55:03 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060127105503.0f6cabae.kgunders@teamcool.net> In-Reply-To: <200601270949.57992.satyam@sklinks.com> References: <20060127141626.GA38042@freenix.no> <200601270949.57992.satyam@sklinks.com> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Is SMP included in i386? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 17:55:06 -0000 On Fri, 27 Jan 2006 09:49:57 -0800 Joseph Vella wrote: > I'm getting a new AMD 64 X2 for use as a desktop machine. I want to have > flash and w32codecs, etc..., so I'm planning on using a 32 bit kernel. Can I > start with the i386 iso cd set? I assume I would have to compile it from > there? Anyone have any tips or suggestions for what I want to do? Set KERNCONF=SMP in your /etc/make.conf and buildworld/kernel (don't really need to buidlworld but you might as well cvsup your src tree while you're at it). See FBSD Handbook or / usr/ src/ Makefile for more detail. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 18:00:24 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B00D916A420 for ; Fri, 27 Jan 2006 18:00:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19BC243D8B for ; Fri, 27 Jan 2006 18:00:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RI0KEK031546 for ; Fri, 27 Jan 2006 18:00:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RI0KeB031545; Fri, 27 Jan 2006 18:00:20 GMT (envelope-from gnats) Date: Fri, 27 Jan 2006 18:00:20 GMT Message-Id: <200601271800.k0RI0KeB031545@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 18:00:24 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: hotlips Internet admin To: kris@obsecurity.org (Kris Kennaway) Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Fri, 27 Jan 2006 11:59:15 -0500 (EST) Thus saith Kris Kennaway: | | | --nmemrqcdn5VTmUEE | Content-Type: text/plain; charset=us-ascii | Content-Disposition: inline | Content-Transfer-Encoding: quoted-printable | | On Fri, Jan 27, 2006 at 09:32:39AM +0000, Bruce Becker wrote: | | > FreeBSD tarantula.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:= | 25:49 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 | >=20 | > >Description: | > packets/second value reported by rpc.rstatd to remote monitor hovers arou= | nd | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at = | all related to actual interface traffic) | >=20 | > >How-To-Repeat: | > keep displaying rpc.rstatd data from 6.0 system | | How are you using rpc.rstatd and rup? I don't see a way to make rup | display "packets/second", it only gives uptime and load average: | | # rup | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 Solaris perfmeter, actually. -- Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 18:00:31 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1152F16A420 for ; Fri, 27 Jan 2006 18:00:31 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B029643D8F for ; Fri, 27 Jan 2006 18:00:30 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RI0UDn031568 for ; Fri, 27 Jan 2006 18:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RI0Ux6031567; Fri, 27 Jan 2006 18:00:30 GMT (envelope-from gnats) Date: Fri, 27 Jan 2006 18:00:30 GMT Message-Id: <200601271800.k0RI0Ux6031567@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92410: calloc.c missing from Makefile.inc X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 18:00:31 -0000 The following reply was made to PR amd64/92410; it has been noted by GNATS. From: hotlips Internet admin To: kris@obsecurity.org (Kris Kennaway) Cc: Subject: Re: amd64/92410: calloc.c missing from Makefile.inc Date: Fri, 27 Jan 2006 12:15:23 -0500 (EST) Thus saith Kris Kennaway: | | | --ZGiS0Q5IWpPtfppv | Content-Type: text/plain; charset=us-ascii | Content-Disposition: inline | Content-Transfer-Encoding: quoted-printable | | On Fri, Jan 27, 2006 at 09:21:44AM +0000, Bruce Becker wrote: | >=20 | > >Number: 92410 | > >Category: amd64 | > >Synopsis: calloc.c missing from Makefile.inc | > >Confidential: no | > >Severity: critical | > >Priority: high | > >Responsible: freebsd-amd64 | > >State: open | > >Quarter: =20 | > >Keywords: =20 | > >Date-Required: | > >Class: sw-bug | > >Submitter-Id: current-users | > >Arrival-Date: Fri Jan 27 09:30:08 GMT 2006 | > >Closed-Date: | > >Last-Modified: | > >Originator: Bruce Becker | > >Release: 6.0 | > >Organization: | > G.T.S. | > >Environment: | > FreeBSD vhcst.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:25:4= | 9 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 | >=20 | > >Description: | > =20 | > Make buildworld failed with missing reference to calloc at link of atrun | | You omitted the error. It's probably caused by something on your end, | since 6.0-STABLE in fact builds just fine. It *definitely* was caused by a bad submission. Maybe it's already been fixed? Check the CVS history please - I have been building 6.0 amd64 versions from cvsup for days now - the version of /usr/src/lib/libc/stdlib/Makefile.inc checked in yesterday definitely broke things! (go look in the repository). PLEASE DO NOT SHOOT THE MESSENGER | > >How-To-Repeat: | > make buildworld | > >Fix: | > add "calloc.c" to MISRCS+=3D declaration in /usr/src/lib/libc/stdlib/Make= | file.inc | > (# $FreeBSD: src/lib/libc/stdlib/Makefile.inc,v 1.48.8.1 2006/01/27 05:17= | :25 trhodes Exp $) | >=20 | > -STABLE shouldn't ever have untested code in it :| | | If you say so :) That was a very unpleasant problem to have to deal with at 4:30 AN when there's a deadline to meet... -- Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 18:00:37 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C615316A423 for ; Fri, 27 Jan 2006 18:00:37 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44C7243D49 for ; Fri, 27 Jan 2006 18:00:34 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RI0YBv031575 for ; Fri, 27 Jan 2006 18:00:34 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RI0Y9J031574; Fri, 27 Jan 2006 18:00:34 GMT (envelope-from gnats) Date: Fri, 27 Jan 2006 18:00:34 GMT Message-Id: <200601271800.k0RI0Y9J031574@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92410: calloc.c missing from Makefile.inc (fwd) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 18:00:38 -0000 The following reply was made to PR amd64/92410; it has been noted by GNATS. From: hotlips Internet admin To: trhodes@FreeBSD.org Cc: followup@FreeBSD.org, kris@obsecurity.org Subject: Re: amd64/92410: calloc.c missing from Makefile.inc (fwd) Date: Fri, 27 Jan 2006 12:29:56 -0500 (EST) Forwarded message: | From hostmaster Fri Jan 27 12:15:23 2006 | Subject: Re: amd64/92410: calloc.c missing from Makefile.inc | To: kris@obsecurity.org (Kris Kennaway) | Date: Fri, 27 Jan 2006 12:15:23 -0500 (EST) | Thus saith Kris Kennaway: | | On Fri, Jan 27, 2006 at 09:21:44AM +0000, Bruce Becker wrote: | | > | | > >Number: 92410 | | > >Category: amd64 | | > >Synopsis: calloc.c missing from Makefile.inc | | > >Confidential: no | | > >Severity: critical | | > >Priority: high | | > >Responsible: freebsd-amd64 | | > >State: open | | > >Quarter: | | > >Keywords: | | > >Date-Required: | | > >Class: sw-bug | | > >Submitter-Id: current-users | | > >Arrival-Date: Fri Jan 27 09:30:08 GMT 2006 | | > >Closed-Date: | | > >Last-Modified: | | > >Originator: Bruce Becker | | > >Release: 6.0 | | > >Organization: G.T.S. | | > >Environment: | | > FreeBSD vhcst.web.ca 6.0-STABLE FreeBSD 6.0-STABLE #0: Sun Jan 22 23:25:4= | | 9 EST 2006 root@tarantula:/usr/obj/usr/src/sys/TARANTULA amd64 | | >=20 | | > >Description: | | > =20 | | > Make buildworld failed with missing reference to calloc at link of atrun | | | | You omitted the error. It's probably caused by something on your end, | | since 6.0-STABLE in fact builds just fine. | | It *definitely* was caused by a bad submission. Maybe it's | already been fixed? Check the CVS history please - I have | been building 6.0 amd64 versions from cvsup for days now - | the version of /usr/src/lib/libc/stdlib/Makefile.inc checked in | yesterday definitely broke things! (go look in the repository). | | PLEASE DO NOT SHOOT THE MESSENGER | | | > >How-To-Repeat: | | > make buildworld | | > >Fix: | | > add "calloc.c" to MISRCS+=3D declaration in /usr/src/lib/libc/stdlib/Make= | | file.inc | | > (# $FreeBSD: src/lib/libc/stdlib/Makefile.inc,v 1.48.8.1 2006/01/27 05:17= | | :25 trhodes Exp $) | | >=20 | | > -STABLE shouldn't ever have untested code in it :| | | | | If you say so :) | | | That was a very unpleasant problem to have to deal with | at 4:30 AN when there's a deadline to meet... FYI - please see PR 94210 - I just looked in the CVS to see that this issue was related to PR 51209 (thanks for adding the functionality in any case) Thanks, Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 18:39:58 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 E1FAC16A420 for ; Fri, 27 Jan 2006 18:39:58 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from deadcafe.de (deadcafe.de [81.169.162.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 134C543D53 for ; Fri, 27 Jan 2006 18:39:57 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from dialin.t-online.de (p54A5D028.dip.t-dialin.net [84.165.208.40]) by deadcafe.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id k0RIdsB6016472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jan 2006 19:39:55 +0100 (CET) Received: from [172.23.7.254] (doom.rock.net [172.23.7.254]) by dialin.t-online.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id k0RIdn3G000388; Fri, 27 Jan 2006 19:39:49 +0100 (CET) Message-ID: <43DA6906.9030508@deadcafe.de> Date: Fri, 27 Jan 2006 19:40:06 +0100 From: Daniel Rock User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: kono@kth.se References: <200601270957.44032.kono@kth.se> In-Reply-To: <200601270957.44032.kono@kth.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deadcafe.de Cc: mumag@nist.gov, freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 18:39:59 -0000 Alexander Konovalenko schrieb: > I have upgraded my AMD64 Athlon 3000+ to dual core X2 4400+. Now I can run > two oommf tasks at the same time, and performance (I measure total execution > time of the task) is around 186% comparing with 100% when only one task is > running. This 7% degrade in performance per task is probably due to > concurrent data transferring CPU<->RAM. I am very satisfied with X2 but just > wonder if dual core Opteron gives better performance? Does anybody run OOMMF > on Opteron? Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core Opteron 1xx are exactly the same. Daniel From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 19:23:07 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 12CF316A420 for ; Fri, 27 Jan 2006 19:23:07 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A87BE43D46 for ; Fri, 27 Jan 2006 19:23:06 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 68811F80F for ; Fri, 27 Jan 2006 12:23:05 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 33095F805 for ; Fri, 27 Jan 2006 12:23:05 -0700 (MST) Date: Fri, 27 Jan 2006 12:23:04 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060127122304.6f6614cd.kgunders@teamcool.net> In-Reply-To: <43DA6906.9030508@deadcafe.de> References: <200601270957.44032.kono@kth.se> <43DA6906.9030508@deadcafe.de> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 19:23:07 -0000 On Fri, 27 Jan 2006 19:40:06 +0100 Daniel Rock wrote: > Alexander Konovalenko schrieb: > > I have upgraded my AMD64 Athlon 3000+ to dual core X2 4400+. Now I can run > > two oommf tasks at the same time, and performance (I measure total execution > > time of the task) is around 186% comparing with 100% when only one task is > > running. This 7% degrade in performance per task is probably due to > > concurrent data transferring CPU<->RAM. I am very satisfied with X2 but just > > wonder if dual core Opteron gives better performance? Does anybody run OOMMF > > on Opteron? > > Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core > Opteron 1xx are exactly the same. Are you sure about this? For example, Opteron 1xx use ECC RAM but I'm not sure if the Athalons do. Also the Opteron's are reportedly held to a higher qa standard. Opteron 1xx are backed by metal whereas Athalons are just the die (not used x2 Athalons yet though). Not an AMD guru but my $0.02... -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 21:05:18 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 570FE16A420 for ; Fri, 27 Jan 2006 21:05:18 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from deadcafe.de (deadcafe.de [81.169.162.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC61043D46 for ; Fri, 27 Jan 2006 21:05:15 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from dialin.t-online.de (p54A5FEAE.dip.t-dialin.net [84.165.254.174]) by deadcafe.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id k0RL5ChU016712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jan 2006 22:05:13 +0100 (CET) Received: from [172.23.7.254] (doom.rock.net [172.23.7.254]) by dialin.t-online.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id k0RL4tZH004543; Fri, 27 Jan 2006 22:04:55 +0100 (CET) Message-ID: <43DA8AF7.9040902@deadcafe.de> Date: Fri, 27 Jan 2006 22:04:55 +0100 From: Daniel Rock User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ken Gunderson References: <200601270957.44032.kono@kth.se> <43DA6906.9030508@deadcafe.de> <20060127122304.6f6614cd.kgunders@teamcool.net> In-Reply-To: <20060127122304.6f6614cd.kgunders@teamcool.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deadcafe.de Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 21:05:18 -0000 Ken Gunderson schrieb: > On Fri, 27 Jan 2006 19:40:06 +0100 > Daniel Rock wrote: >> Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core >> Opteron 1xx are exactly the same. > > Are you sure about this? For example, Opteron 1xx use ECC RAM So does the Athlon64 (even the single core and socket 754 ones) > Also the Opteron's are reportedly held > to a higher qa standard. Opteron 1xx are backed by metal whereas > Athalons are just the die (not used x2 Athalons yet though). Not an AMD > guru but my $0.02... That also isn't true for Athlon64 any more. Every Athlon64 CPU comes with a heat spreader installed. I don't think Opteron 1xx are of a higher standard than their Athlon64 counterpart. Some Opteron models are even cheaper than the Athlon64 equivalent. Daniel From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 21:12:43 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 D429116A420 for ; Fri, 27 Jan 2006 21:12:43 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6262043D55 for ; Fri, 27 Jan 2006 21:12:43 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 6ABCDF80F for ; Fri, 27 Jan 2006 14:12:42 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 35451F805 for ; Fri, 27 Jan 2006 14:12:42 -0700 (MST) Date: Fri, 27 Jan 2006 14:12:41 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060127141241.2084b661.kgunders@teamcool.net> In-Reply-To: <43DA8AF7.9040902@deadcafe.de> References: <200601270957.44032.kono@kth.se> <43DA6906.9030508@deadcafe.de> <20060127122304.6f6614cd.kgunders@teamcool.net> <43DA8AF7.9040902@deadcafe.de> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 21:12:43 -0000 On Fri, 27 Jan 2006 22:04:55 +0100 Daniel Rock wrote: > Ken Gunderson schrieb: > > On Fri, 27 Jan 2006 19:40:06 +0100 > > Daniel Rock wrote: > >> Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core > >> Opteron 1xx are exactly the same. > > > > Are you sure about this? For example, Opteron 1xx use ECC RAM > > So does the Athlon64 (even the single core and socket 754 ones) > > > > Also the Opteron's are reportedly held > > to a higher qa standard. Opteron 1xx are backed by metal whereas > > Athalons are just the die (not used x2 Athalons yet though). Not an AMD > > guru but my $0.02... > > That also isn't true for Athlon64 any more. Every Athlon64 CPU comes with a > heat spreader installed. I don't think Opteron 1xx are of a higher standard > than their Athlon64 counterpart. Some Opteron models are even cheaper than the > Athlon64 equivalent. Perhaps you're correct but this is not congruent with posts I've read at AMD forums. I think I even saw on AMD's main site somewhere that Opteron's were "server/workstation class" and underwent more rigorous testing. I'm paraphasing here. You're info may also be more current... -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 22:03:13 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 351A816A420 for ; Fri, 27 Jan 2006 22:03:13 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E12643D4C for ; Fri, 27 Jan 2006 22:03:11 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from mxfep02 ([195.54.107.73] [195.54.107.73]) by mxfep02.bredband.com with SMTP id <20060127220310.JWHG2008.mxfep02.bredband.com@mxfep02>; Fri, 27 Jan 2006 23:03:10 +0100 X-Mailer: Openwave WebEngine, version 2.8.18 (webedge20-101-1108-20050216) From: To: Ken Gunderson , Date: Fri, 27 Jan 2006 23:03:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060127220310.JWHG2008.mxfep02.bredband.com@mxfep02> Cc: Subject: Re: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 22:03:13 -0000 > > From: Ken Gunderson > > Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core > > Opteron 1xx are exactly the same. NO. > > Are you sure about this? For example, Opteron 1xx use ECC RAM but I'm > not sure if the Athlons do. Correct, Opteron uses socket 940 to be able to use registred ECC Ram. Whilst modern Athlon 64 uses socket 939 to cut the cost of the motherboard components and to use unregistred non-ECC RAM. Its actually becomming difficult now to find new Consumer PC's with Intel P4 CPUS. So I Guess that the Socket 939 is paying off nicely for AMD. The other difference is that Athlon 64 can be overclocked. You dont want to live on the edge in a server , you want it to be reliable. So Opterons have fixed frequency. //Lars From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 22:06:20 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 41E9416A420 for ; Fri, 27 Jan 2006 22:06:20 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6A7543D46 for ; Fri, 27 Jan 2006 22:06:19 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id F367EAD; Fri, 27 Jan 2006 16:06:18 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 322E961C38; Fri, 27 Jan 2006 16:06:18 -0600 (CST) Date: Fri, 27 Jan 2006 16:06:18 -0600 From: "Matthew D. Fuller" To: lars.tunkrans@bredband.net Message-ID: <20060127220618.GE1388@over-yonder.net> References: <20060127220310.JWHG2008.mxfep02.bredband.com@mxfep02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060127220310.JWHG2008.mxfep02.bredband.com@mxfep02> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: freebsd-amd64@freebsd.org Subject: Re: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 22:06:20 -0000 On Fri, Jan 27, 2006 at 11:03:10PM +0100 I heard the voice of lars.tunkrans@bredband.net, and lo! it spake thus: > > Correct, Opteron uses socket 940 to be able to use registred ECC > Ram. Whilst modern Athlon 64 uses socket 939 to cut the cost of > the motherboard components and to use unregistred non-ECC RAM. Opteron 1xx uses Socket 939, and A64 supports ECC RAM. As far as I've been able to tell, the primary difference is that the 940 motherboards tend to support registered memory while the 939's generally dont, and the 2xx and up Opterons have the extra HT links for multi-package systems. And perhaps some of the Opterons have more cache, I'm not sure. The difference became awful awful blurry when Socket 939 and dual-core A64's came around. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 22:10:09 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81C2516A420 for ; Fri, 27 Jan 2006 22:10:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 060F843D45 for ; Fri, 27 Jan 2006 22:10:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0RMA8cU044755 for ; Fri, 27 Jan 2006 22:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0RMA8Jc044754; Fri, 27 Jan 2006 22:10:08 GMT (envelope-from gnats) Date: Fri, 27 Jan 2006 22:10:08 GMT Message-Id: <200601272210.k0RMA8Jc044754@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 22:10:09 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: hotlips Internet admin To: kris@obsecurity.org (Kris Kennaway) Cc: bug-followup@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Fri, 27 Jan 2006 17:02:33 -0500 (EST) Thus saith Kris Kennaway: | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: | > | > > | > | > >Description: | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at all related to actual interface traffic) | > | > | > | > >How-To-Repeat: | > | > keep displaying rpc.rstatd data from 6.0 system | > | | > | How are you using rpc.rstatd and rup? I don't see a way to make rup | > | display "packets/second", it only gives uptime and load average: | > | | > | # rup | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 | > | > Solaris perfmeter, actually. | | Do you know how I can query this on FreeBSD? It's easy to do on any BSD system - in /usr/src/usr.bin/rup, make a copy rupx.c with this diff: *** rup.c Sat May 21 05:55:07 2005 --- rupx.c Fri Jan 27 16:17:25 2006 *************** *** 153,158 **** --- 153,159 ---- (double)host_stat->avenrun[0]/FSCALE, (double)host_stat->avenrun[1]/FSCALE, (double)host_stat->avenrun[2]/FSCALE); + printf("ipackets: %d opackets %d\n", host_stat->if_ipackets, host_stat->if_opackets); remember_host(raddrp->sin_addr); return(0); All other FreeBSD systems seem to return 0 for if_opackets (which is wrong), whereas 6.0 returns junk. NetBSD, Solaris, SunOS 4.x, & Irix 6.x all seem to do the right thing. I also note that the RPC/XDR code seems to be quite ancient - even SunOS 4.1.1 1990 code has declarations for an additional version 4 of the rstats protocol: RSTATVERS_VAR, with variable args for RSTAT_CPUSTATES & RSTAT_DK_NDRIVE. All the code appears to have version 3 (RSTATVERS_TIME), which rup uses. Cheers, Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 22:27:33 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 EA48816A420 for ; Fri, 27 Jan 2006 22:27:33 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from deadcafe.de (deadcafe.de [81.169.162.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E6D43D45 for ; Fri, 27 Jan 2006 22:27:29 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from dialin.t-online.de (p54A5FEAE.dip.t-dialin.net [84.165.254.174]) by deadcafe.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id k0RMRPPv016801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jan 2006 23:27:27 +0100 (CET) Received: from [172.23.7.254] (doom.rock.net [172.23.7.254]) by dialin.t-online.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id k0RMRKb4006760; Fri, 27 Jan 2006 23:27:20 +0100 (CET) Message-ID: <43DA9E48.7010101@deadcafe.de> Date: Fri, 27 Jan 2006 23:27:20 +0100 From: Daniel Rock User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: lars.tunkrans@bredband.net References: <20060127220310.JWHG2008.mxfep02.bredband.com@mxfep02> In-Reply-To: <20060127220310.JWHG2008.mxfep02.bredband.com@mxfep02> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deadcafe.de Cc: kellyl@sysrq.ca, freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 22:27:34 -0000 lars.tunkrans@bredband.net schrieb: >> From: Ken Gunderson > >>> Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core >>> Opteron 1xx are exactly the same. > > NO. Sure! >> Are you sure about this? For example, Opteron 1xx use ECC RAM but I'm >> not sure if the Athlons do. > > Correct, Opteron uses socket 940 to be able to use registred > ECC Ram. Whilst modern Athlon 64 uses socket 939 to cut > the cost of the motherboard components and to use unregistred > non-ECC RAM. We are talking about Dual-Core Opteron 1xx. Current Opteron 1xx (beginning with E-Stepping) use Socket 939 - just like Athlon64: http://www.amdcompare.com/us-en/opteron/ http://www.amdcompare.com/us-en/desktop/ Athlon64 and current Opteron 1xx are the same. They even share the number of HTT links: 1 (non coherent) - only Socket 940 Opterons provide 3 HTT links. Because of the integrated memory controller supporting or not supporting ECC isn't a function of the chipset, but of the CPU itself (and the BIOS initializing ECC right). Every Athlon64 (Socket 754, 939, 940) does support ECC. The only difference is, that Socket 940 requires registered DIMMS while the other ones work with unbuffered DIMMs. Conclusion: Apart from different CPUID the following CPUs are *exactly the same*: Athlon64 FX-55 Opteron 152 Athlon64 FX-57 Opteron 154 Athlon64 X2 4400+ Opteron 175 Athlon64 X2 4800+ Opteron 180 the following CPUs exist in different flavours. The E4-stepping are the same: Athlon64 4000+ Opteron 150 Athlon64 3700+ Opteron 148 Daniel From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 27 23:25:11 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 D5A1716A422 for ; Fri, 27 Jan 2006 23:25:11 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (www.cursosvirtuales.com.ar [200.59.46.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9363443D55 for ; Fri, 27 Jan 2006 23:25:09 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (localhost [127.0.0.1]) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11) with ESMTP id k0RNOw6b006433; Fri, 27 Jan 2006 20:24:59 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from schapachnik.com.ar (uucp@localhost) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11/Submit) with UUCP id k0RNOwoK006432; Fri, 27 Jan 2006 20:24:58 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from funes.schapachnik.com.ar (localhost [127.0.0.1]) by funes.schapachnik.com.ar (8.13.4/8.13.4) with ESMTP id k0RNNx6W002323; Fri, 27 Jan 2006 20:23:59 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: (from fpscha@localhost) by funes.schapachnik.com.ar (8.13.4/8.13.4/Submit) id k0RNNx6n002322; Fri, 27 Jan 2006 20:23:59 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) X-Authentication-Warning: funes.schapachnik.com.ar: fpscha set sender to fernando@schapachnik.com.ar using -f Date: Fri, 27 Jan 2006 20:23:59 -0300 From: Fernando Schapachnik To: Lennart Sorth Message-ID: <20060127232359.GI930@funes.schapachnik.com.ar> References: <20060127020350.02abf989.kgunders@teamcool.net> <200601271228.02675.groot@kde.org> <43DA1A5A.3000409@uni-c.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43DA1A5A.3000409@uni-c.dk> User-Agent: Mutt/1.4.2.1i X-OS: FreeBSD 6.0 - http://www.freebsd.org Cc: freebsd-amd64@freebsd.org Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 23:25:12 -0000 En un mensaje anterior, Lennart Sorth escribió: > Adriaan de Groot wrote: > >and surfing dubious websites (webbrowser + mplayer), amd64 > >desktops are fine. > > ... as long as you don't need win32-codecs Or vmware, or wine... Appart from that, using KDE, works really nice. Fernando P. Schapachnik fernando@schapachnik.com.ar From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 08:30:55 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 72E7F16A420 for ; Sat, 28 Jan 2006 08:30:55 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id E539243D45 for ; Sat, 28 Jan 2006 08:30:54 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so768230nzo for ; Sat, 28 Jan 2006 00:30:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bx+NrY4GZ37xn5NUza+8ngH5q6oZmPNyIfb/S1EF2vcl7MG6M1ekIqais2h4bk5MCHd7HKRassasQApOdiiCrJ88KDtHn8a1uFdxXtf0qER6yn6PCzNpiWkGdgAYOt9TIQF+jK4JidfwROdqBvzIgnc3TPbNydkoWGwy0Mj0Yok= Received: by 10.36.154.20 with SMTP id b20mr3214010nze; Sat, 28 Jan 2006 00:30:53 -0800 (PST) Received: by 10.37.20.67 with HTTP; Sat, 28 Jan 2006 00:30:53 -0800 (PST) Message-ID: Date: Sat, 28 Jan 2006 11:30:53 +0300 From: Andrew Pantyukhin To: Ken Gunderson In-Reply-To: <20060127104600.1ffa38c9.kgunders@teamcool.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060127141626.GA38042@freenix.no> <84dead720601270812vbfab477i27e6def1aed324f6@mail.gmail.com> <20060127104600.1ffa38c9.kgunders@teamcool.net> Cc: freebsd-amd64@freebsd.org Subject: Re: CPUTYPE in /etc/make.conf X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 08:30:55 -0000 On 1/27/06, Ken Gunderson wrote: > On Fri, 27 Jan 2006 21:42:33 +0530 > Joseph Koshy wrote: > > > > What should I set CPUTYPE to in /etc/make.conf? > > > > You can leave it blank or set it to 'nocona'. > > ALong similar vein- is there a difference is between "k8" and > "opteron" when running an opteron on i386 arch?? > > -- > Best regards, > > Ken Gunderson > > Q: Because it reverses the logical flow of conversation. > A: Why is putting a reply at the top of the message frowned upon? > > _______________________________________________ > 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" > This section is your friend: http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.htm= l Opteron and K8 are on the same line, which means they are just aliases to each other. From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 10:12:24 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 8388316A420 for ; Sat, 28 Jan 2006 10:12:24 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from mxfep04.bredband.com (mxfep04.bredband.com [195.54.107.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C8D343D46 for ; Sat, 28 Jan 2006 10:12:22 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from mxfep04 ([195.54.107.79] [195.54.107.79]) by mxfep04.bredband.com with SMTP id <20060128101221.ZTBV8741.mxfep04.bredband.com@mxfep04>; Sat, 28 Jan 2006 11:12:21 +0100 X-Mailer: Openwave WebEngine, version 2.8.18 (webedge20-101-1108-20050216) From: To: Daniel Rock Date: Sat, 28 Jan 2006 11:12:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060128101221.ZTBV8741.mxfep04.bredband.com@mxfep04> Cc: freebsd-amd64@freebsd.org Subject: Re: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 10:12:24 -0000 > > From: Daniel Rock > We are talking about Dual-Core Opteron 1xx. Current Opteron 1xx (beginning > with E-Stepping) use Socket 939 - just like Athlon64: > > http://www.amdcompare.com/us-en/opteron/ > http://www.amdcompare.com/us-en/desktop/ > > Athlon64 and current Opteron 1xx are the same. They even share the number of > HTT links: 1 (non coherent) - only Socket 940 Opterons provide 3 HTT links. > > Because of the integrated memory controller supporting or not supporting ECC > isn't a function of the chipset, but of the CPU itself (and the BIOS > initializing ECC right). Every Athlon64 (Socket 754, 939, 940) does support > ECC. The only difference is, that Socket 940 requires registered DIMMS while > the other ones work with unbuffered DIMMs. > > Conclusion: Apart from different CPUID the following CPUs are *exactly the same*: > > Athlon64 FX-55 Opteron 152 > Athlon64 FX-57 Opteron 154 > Athlon64 X2 4400+ Opteron 175 > Athlon64 X2 4800+ Opteron 180 O.K. Seems to defeat the purpose , If you want to build a reliable Server you want Registred ECC RAM. ( socket 940 ) If you want to build a cheap desktop machine you want un-registred non-ECC RAM. ( socket 939 ) Only other reason I can think of to have two brand names for the same product is to sell it at different price levels, but AMD generally seems to have the same price for the same clockrate on these chips. Only application I can think of for using non-reliable servers built with socket 939 is compute clusters where you have several hundred compute servers, and you are not dependent on whether an individual server runs all the time. //Lars From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 11:13:08 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 82A7716A420 for ; Sat, 28 Jan 2006 11:13:08 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E81743D46 for ; Sat, 28 Jan 2006 11:13:07 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k0SBCtZh093125; Sat, 28 Jan 2006 09:12:56 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-amd64@freebsd.org Date: Sat, 28 Jan 2006 09:12:51 -0200 User-Agent: KMail/1.9.1 References: <200601270957.44032.kono@kth.se> <43DA6906.9030508@deadcafe.de> In-Reply-To: <43DA6906.9030508@deadcafe.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200601280912.52907.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Cc: kono@kth.se, Daniel Rock , mumag@nist.gov Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 11:13:08 -0000 On Friday 27 January 2006 16:40, Daniel Rock wrote: > Alexander Konovalenko schrieb: > > I have upgraded my AMD64 Athlon 3000+ to dual core X2 4400+. Now I can > > run two oommf tasks at the same time, and performance (I measure total > > execution time of the task) is around 186% comparing with 100% when only > > one task is running. This 7% degrade in performance per task is probably > > due to concurrent data transferring CPU<->RAM. I am very satisfied with > > X2 but just wonder if dual core Opteron gives better performance? Does > > anybody run OOMMF on Opteron? > > Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core > Opteron 1xx are exactly the same. > Hi I believe this is not exactly correct If I am not wrong there is actual only the X2-4800 and 4400 with 2x1MB cach= e,=20 all others are having max 512K=20 The Opterons are having 2MB of cache, not 2x1=20 the manufacture technology of opterons and athlons-X2 are quiet different a= nd=20 there other tiny "server" related points (for me doubtless) a server-MB for dual opteron is also faster then a US100= =20 939 socket MB and probably much more stable IMO the opterons are faster when talking server, nevertheless the athlons a= re=20 much cheaper, not the processors but I can run real cheap MBs=20 when I do not need more than 3.5GB of RAM the performance difference is not= =20 that much so the athlon-X2 are an attractive alternative for US500-1000+ le= ss I have lot's of cache/gw servers and I am changing all to X2, the disk r/w= =20 performance advantage with good memory chips is very big in comparism to= =20 i386 P4 machines. I run also expensive perl tasks on this servers which gave my a bottleneck = on=20 UP a machines, the X2 SMPs are managing this as perfect as my dual-otperon= =20 server and for me the X2 is a very very good and cheap solution. I can not say anything for workstations but as long as you do not pass more= =20 than 6-8MB/s traffic through the machine a X2 Athlon may do it as good as a= n=20 Opteron system but probably depends also on what you do particulary with th= is=20 machine. Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 13:40:50 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 6B67016A420 for ; Sat, 28 Jan 2006 13:40:50 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.178.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C71643D49 for ; Sat, 28 Jan 2006 13:40:49 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [217.185.80.92] (manz-d9b9505c.pool.mediaWays.net [217.185.80.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate2.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 78A4B3000931; Sat, 28 Jan 2006 14:40:45 +0100 (CET) Message-ID: <43DB7457.6050605@mail.uni-mainz.de> Date: Sat, 28 Jan 2006 14:40:39 +0100 From: "O. Hartmann" User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: JoaoBR References: <200601270957.44032.kono@kth.se> <43DA6906.9030508@deadcafe.de> <200601280912.52907.joao@matik.com.br> In-Reply-To: <200601280912.52907.joao@matik.com.br> Content-Type: multipart/mixed; boundary="------------060904080806080005020605" X-Virus-Scanned: by amavisd-new at uni-mainz.de X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kono@kth.se, Daniel Rock , mumag@nist.gov, freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 13:40:50 -0000 This is a multi-part message in MIME format. --------------060904080806080005020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit JoaoBR wrote: > On Friday 27 January 2006 16:40, Daniel Rock wrote: > >> Alexander Konovalenko schrieb: >> >>> I have upgraded my AMD64 Athlon 3000+ to dual core X2 4400+. Now I can >>> run two oommf tasks at the same time, and performance (I measure total >>> execution time of the task) is around 186% comparing with 100% when only >>> one task is running. This 7% degrade in performance per task is probably >>> due to concurrent data transferring CPU<->RAM. I am very satisfied with >>> X2 but just wonder if dual core Opteron gives better performance? Does >>> anybody run OOMMF on Opteron? >>> >> Besides the different CPUID, Athlon64 X2 (with 2x1MB Cache) and Dual-Core >> Opteron 1xx are exactly the same. >> >> > > Hi > I believe this is not exactly correct > > If I am not wrong there is actual only the X2-4800 and 4400 with 2x1MB cache, > all others are having max 512K We were talking about comparable Athlon64/Opterons for socket 939. > > > The Opterons are having 2MB of cache, not 2x1 > No, that's wrong. Dual-core 1XX Opterons do have two times 1MB 2nd level cache for each core, not a unified 2MB cache! > the manufacture technology of opterons and athlons-X2 are quiet different and > there other tiny "server" related points > As you can read in many technical reports and newsgroups, Opteron 1xx for s939 and Athlon64 of comparable cache size use identical core logic. The only difference in between is the Athlon64 has a unlocked clock multiplicator. > (for me doubtless) a server-MB for dual opteron is also faster then a US100 > 939 socket MB and probably much more stable > > IMO the opterons are faster when talking server, nevertheless the athlons are > much cheaper, not the processors but I can run real cheap MBs Whether a socket 939-MB built for hosting 1xx Opterons will accept a Athlon64 chip depends on BIOS - a simple recognition of the CPUID! Tests revealed that dual core Opteron 1xx for socket 939 and Athlon64-X1 are at same performance at the same speed (assuming the same cache size). There is no performance difference if both chips have the same technical specs. > > > when I do not need more than 3.5GB of RAM the performance difference is not > that much so the athlon-X2 are an attractive alternative for US500-1000+ less > > I have lot's of cache/gw servers and I am changing all to X2, the disk r/w > performance advantage with good memory chips is very big in comparism to > i386 P4 machines. > > I run also expensive perl tasks on this servers which gave my a bottleneck on > UP a machines, the X2 SMPs are managing this as perfect as my dual-otperon > server and for me the X2 is a very very good and cheap solution. > > I can not say anything for workstations but as long as you do not pass more > than 6-8MB/s traffic through the machine a X2 Athlon may do it as good as an > Opteron system but probably depends also on what you do particulary with this > machine. > > João > > All right, talking about scientific calculations, I would prefer a real dual chip plus dual core Opteron 2xx system due to the fact, memory bandwith is much more efficient when using NUMA architecture. But in my opinion, comparin dual chip and dual core Opterons (and their Athlon64 counterparts) is comparing cherries and pineapples ... > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > 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" > --------------060904080806080005020605-- From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 14:07:30 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 6BF4016A420 for ; Sat, 28 Jan 2006 14:07:30 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 839DE43D58 for ; Sat, 28 Jan 2006 14:07:29 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail15.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0SE7O9I004973 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 29 Jan 2006 01:07:25 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k0SE7OL1002506; Sun, 29 Jan 2006 01:07:24 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k0SE7Ong002505; Sun, 29 Jan 2006 01:07:24 +1100 (EST) (envelope-from peter) Date: Sun, 29 Jan 2006 01:07:24 +1100 From: Peter Jeremy To: lars.tunkrans@bredband.net Message-ID: <20060128140724.GB2341@turion.vk2pj.dyndns.org> References: <20060128101221.ZTBV8741.mxfep04.bredband.com@mxfep04> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060128101221.ZTBV8741.mxfep04.bredband.com@mxfep04> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-amd64@freebsd.org Subject: Re: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 14:07:30 -0000 On Sat, 2006-Jan-28 11:12:21 +0100, lars.tunkrans@bredband.net wrote: > Seems to defeat the purpose , If you want to build a reliable > Server you want Registred ECC RAM. ( socket 940 ) > If you want to build a cheap desktop machine you want un-registred > non-ECC RAM. ( socket 939 ) According to the posting you quoted, you can have non-registered ECC RAM on a socket-939 so that provides a third alternative: A low-end server with limited RAM capacity using socket-939 and unregistered ECC RAM. > Only application I can think of for using non-reliable servers > built with socket 939 is compute clusters where you have several > hundred compute servers, and you are not dependent on whether an > individual server runs all the time. You probably still want ECC RAM so that you can rely on the answers that your compute server is providing. -- Peter Jeremy From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 14:20:06 2006 Return-Path: X-Original-To: amd64@freebsd.org 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 18D2616A420; Sat, 28 Jan 2006 14:20:06 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5E3843D45; Sat, 28 Jan 2006 14:20:05 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id k0SEK4MK051118; Sat, 28 Jan 2006 09:20:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k0SEJuPq009792; Sat, 28 Jan 2006 09:19:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 26B127302F; Sat, 28 Jan 2006 09:20:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060128142003.26B127302F@freebsd-current.sentex.ca> Date: Sat, 28 Jan 2006 09:20:03 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 14:20:06 -0000 TB --- 2006-01-28 12:38:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-01-28 12:38:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-01-28 12:38:01 - cleaning the object tree TB --- 2006-01-28 12:38:38 - checking out the source tree TB --- 2006-01-28 12:38:38 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-01-28 12:38:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-01-28 12:45:33 - building world (CFLAGS=-O2 -pipe) TB --- 2006-01-28 12:45:33 - cd /src TB --- 2006-01-28 12:45: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 >>> stage 5.1: building 32 bit shim libraries TB --- 2006-01-28 14:18:01 - generating LINT kernel config TB --- 2006-01-28 14:18:01 - cd /src/sys/amd64/conf TB --- 2006-01-28 14:18:01 - /usr/bin/make -B LINT TB --- 2006-01-28 14:18:01 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-01-28 14:18:01 - cd /src TB --- 2006-01-28 14:18:01 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 28 14:18:01 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -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 In file included from /src/sys/kern/kern_rwlock.c:44: /src/sys/sys/rwlock.h:36:25: sys/_rwlock.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-01-28 14:20:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-01-28 14:20:02 - ERROR: failed to build lint kernel TB --- 2006-01-28 14:20:02 - tinderbox aborted TB --- 1.24 user 6.79 system 6121.16 real From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 16:40:04 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D55D816A420 for ; Sat, 28 Jan 2006 16:40:04 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BEF143D48 for ; Sat, 28 Jan 2006 16:40:04 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0SGe4dP015378 for ; Sat, 28 Jan 2006 16:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0SGe3RR015377; Sat, 28 Jan 2006 16:40:03 GMT (envelope-from gnats) Resent-Date: Sat, 28 Jan 2006 16:40:03 GMT Resent-Message-Id: <200601281640.k0SGe3RR015377@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Armin Mohirng Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7883B16A420 for ; Sat, 28 Jan 2006 16:36:23 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ED1A43D46 for ; Sat, 28 Jan 2006 16:36:23 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k0SGaK6Y005560 for ; Sat, 28 Jan 2006 16:36:20 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k0SGaK8k005559; Sat, 28 Jan 2006 16:36:20 GMT (envelope-from nobody) Message-Id: <200601281636.k0SGaK8k005559@www.freebsd.org> Date: Sat, 28 Jan 2006 16:36:20 GMT From: Armin Mohirng To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/92463: Buttons of USB mouse do no work under KDE 3.4.2 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 16:40:04 -0000 >Number: 92463 >Category: amd64 >Synopsis: Buttons of USB mouse do no work under KDE 3.4.2 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jan 28 16:40:03 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Armin Mohirng >Release: 6.0 >Organization: >Environment: AMD 64 Generic >Description: USB mouse: MS Intelli explorer 4.0 Mainboard: MSI K8Neo Platinum (Nvidia nForce 250GB) Installation: OK xorgconfig: OK startx works startkde works integrated Gbit LAN works But the mouse buttons do react slowly or not upon user input. >How-To-Repeat: Install freebsd xorgconfig startx startkde desktop does react slowly or not upon user input, if mouse buttons are used. >Fix: ? >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 17:04:25 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 CA16016A420 for ; Sat, 28 Jan 2006 17:04:25 +0000 (GMT) (envelope-from freebsd-amd64@club-internet.fr) Received: from relay-av.club-internet.fr (relay-av.club-internet.fr [194.158.96.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 549CB43D53 for ; Sat, 28 Jan 2006 17:04:25 +0000 (GMT) (envelope-from freebsd-amd64@club-internet.fr) Received: from [192.168.0.5] (l06m-213-44-74-57.d4.club-internet.fr [213.44.74.57]) by relay-av.club-internet.fr (Postfix) with ESMTP id 3A67B25608; Sat, 28 Jan 2006 18:04:24 +0100 (CET) In-Reply-To: <200512271020.58471.groot@kde.org> References: <562e6673484764a98de5ffb5241d1b76@prodigy.net> <200512271020.58471.groot@kde.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <50F4B7E9-BA1B-4F61-97B5-E81449F33B6B@club-internet.fr> Content-Transfer-Encoding: quoted-printable From: Mathieu Prevot Date: Sat, 28 Jan 2006 18:05:36 +0100 To: Adriaan de Groot X-Mailer: Apple Mail (2.746.2) Cc: freebsd-amd64@freebsd.org Subject: Re: version 6.0 and AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 17:04:25 -0000 Le 27 d=E9c. 05 =E0 10:20, Adriaan de Groot a =E9crit : > On Monday 26 December 2005 21:35, je killen wrote: >> I purchased Version 6.0 from FreeBSD Mall and am now concerned =20 >> that the >> packaged system will work on AMD64 which I have, The processor I have >> and want to use is socket 754, if it makes a difference. > > Socket 754 is an amd64 socket, so that'll be fine (unless there are =20= > socket 754 > Semprons without 64-bit? The AMD website doesn't say in so many =20 > words "this > is not a 64-bit processor", but neither does it tout 64-bitness. In =20= > that > case, it's not the socket type that's most interesting, but the CPU =20= > family > (Athlon64 vs. Sempron) that is.). Until summer 2005 semprons were 32bit only. I have 2 sempron 64bit =20 working with freebsd 6 amd64. On 754 there is no dual channel, cache L2 is lower (256 on most =20 recent semprons, 128 on olders vs 512 and 1024 on 939 amd64) etc... cheers Mathieu= From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 18:07:19 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 EFF8416A422 for ; Sat, 28 Jan 2006 18:07:19 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C451E43D8D for ; Sat, 28 Jan 2006 18:06:56 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id C6138F80F for ; Sat, 28 Jan 2006 11:06:53 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 8FD39F805 for ; Sat, 28 Jan 2006 11:06:53 -0700 (MST) Date: Sat, 28 Jan 2006 11:06:52 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060128110652.38519dc6.kgunders@teamcool.net> In-Reply-To: References: <20060127141626.GA38042@freenix.no> <84dead720601270812vbfab477i27e6def1aed324f6@mail.gmail.com> <20060127104600.1ffa38c9.kgunders@teamcool.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: CPUTYPE in /etc/make.conf X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 18:07:20 -0000 On Sat, 28 Jan 2006 11:30:53 +0300 Andrew Pantyukhin wrote: > On 1/27/06, Ken Gunderson wrote: > > On Fri, 27 Jan 2006 21:42:33 +0530 > > Joseph Koshy wrote: > > > > > > What should I set CPUTYPE to in /etc/make.conf? > > > > > > You can leave it blank or set it to 'nocona'. > > > > ALong similar vein- is there a difference is between "k8" and > > "opteron" when running an opteron on i386 arch?? > > > > -- > > Best regards, > > > > Ken Gunderson > > > > Q: Because it reverses the logical flow of conversation. > > A: Why is putting a reply at the top of the message frowned upon? > > > > _______________________________________________ > > 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" > > > > This section is your friend: > http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html Thank you. Never thought to look it up that way since I'm not a developer. Valuable info that I've now bookmarked;-) > Opteron and K8 are on the same line, which means they > are just aliases to each other. I suspected as much. Thanks for the confirmation. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 28 20:50:20 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org 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 967AE16A420 for ; Sat, 28 Jan 2006 20:50:20 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D700543D45 for ; Sat, 28 Jan 2006 20:50:19 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k0SKoCRD020647; Sat, 28 Jan 2006 18:50:12 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR To: "O. Hartmann" Date: Sat, 28 Jan 2006 18:50:05 -0200 User-Agent: KMail/1.9.1 References: <200601270957.44032.kono@kth.se> <200601280912.52907.joao@matik.com.br> <43DB7457.6050605@mail.uni-mainz.de> In-Reply-To: <43DB7457.6050605@mail.uni-mainz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200601281850.07422.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Cc: kono@kth.se, Daniel Rock , mumag@nist.gov, freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2006 20:50:20 -0000 On Saturday 28 January 2006 11:40, O. Hartmann wrote: > > > > If I am not wrong there is actual only the X2-4800 and 4400 with 2x1MB > > cache, all others are having max 512K > > We were talking about comparable Athlon64/Opterons for socket 939. > > > The Opterons are having 2MB of cache, not 2x1 > > No, that's wrong. Dual-core 1XX Opterons do have two times 1MB 2nd level > cache for each core, not a unified 2MB cache! > right, well, I didn't read with attention ... sincerly I was not even aware= of=20 existing socket 939 opterons so all my opteron opinions were not related wi= th=20 this ones I just reread the processor comparism query on amd's site where the dual=20 opterons are returned with 2MB cache=20 http://www.amdcompare.com/us-en/opteron/Default.aspx#grid but on the data sheet they are as 1MB per core, so 2x1Mb http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_9240,= 00.html I guess you are right here, make sense and I do not care so much either ;) anyway, amd should be able to give exact info on all papers the publish > All right, talking about scientific calculations, I would prefer a real > dual chip plus dual core Opteron 2xx system due to the fact, memory > bandwith is much more efficient when using NUMA architecture. But in my > opinion, comparin dual chip and dual core Opterons (and their Athlon64 > counterparts) is comparing cherries and pineapples ... > sure, absolutly, but often on smaller or low bandwidth server the differenc= e=20 is not even appearing, for the client I mean, I have no idea how this is on= =20 PCs or Workstations but money is a strong point when you get the same quantity of "cherries" at= =20 the end, so the comparism is it worth to talk about and find out the limits Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br