From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 24 03:50:19 2005 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 CF1BC16A41F for ; Sun, 24 Jul 2005 03:50:19 +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 93C4143D45 for ; Sun, 24 Jul 2005 03:50:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j6O3oJFj015802 for ; Sun, 24 Jul 2005 03:50:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j6O3oJuG015801; Sun, 24 Jul 2005 03:50:19 GMT (envelope-from gnats) Date: Sun, 24 Jul 2005 03:50:19 GMT Message-Id: <200507240350.j6O3oJuG015801@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: KOBAYASHI Hidenobu Cc: Subject: Re: amd64/83806: Can not comple /usr/src/lib/msun/amd64/fenv.c at make buildworld. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KOBAYASHI Hidenobu List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 03:50:19 -0000 The following reply was made to PR amd64/83806; it has been noted by GNATS. From: KOBAYASHI Hidenobu To: bug-followup@FreeBSD.org Cc: KOBAYASHI Hidenobu Subject: Re: amd64/83806: Can not comple /usr/src/lib/msun/amd64/fenv.c at make buildworld. Date: Sun, 24 Jul 2005 12:43:37 +0900 I correct Fix parts. >Fix: The 1st my report is invalid. The fact that compiling the fenv.c fails is because the /usr/src/lib/msun/i387/fenv.h is included. It is correct for the /usr/src/lib/msun/amd64/fenv.h to be included. When I install the lib32 with the make installworld, the /usr/include/fenv.h is superscribed with the /usr/src/lib/msun/i387/fenv.h. --- START: make installworld log--- ... ===> lib/msun (install) install -C -o root -g wheel -m 444 libm.a /usr/lib install -C -o root -g wheel -m 444 libm_p.a /usr/lib install -s -o root -g wheel -m 444 libm.so.4 /lib ln -fs /lib/libm.so.4 /usr/lib/libm.so install -C -o root -g wheel -m 444 /usr/src/lib/msun/amd64/fenv.h /usr/src/lib/msun/src/math.h /usr/include ... ===> msun (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libm.a /usr/lib32 sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libm_p.a /usr/lib32 sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libm.so.4 /usr/lib32 ln -fs libm.so.4 /usr/lib32/libm.so sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/msun/i387/fenv.h /usr/src/ lib/msun/src/math.h /usr/include --- END: make installworld log --- Workaround is as follows, 1. echo "NO_LIB32=yes" >> /etc/make.conf 2. re-compile and install world. 3. re-compile and install world. once more. Best Regards, -- KOBAYASHI Hidenobu kobayasi@pp.iij4u.or.jp From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 24 07:08:25 2005 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 CBF6A16A41F for ; Sun, 24 Jul 2005 07:08:25 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from rms06.rommon.net (rms06.rommon.net [212.54.5.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72EE743D46 for ; Sun, 24 Jul 2005 07:08:24 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.236] (dyn236.helenius.fi [193.64.42.236]) by rms06.rommon.net (Postfix) with ESMTP id EC2C333C65 for ; Sun, 24 Jul 2005 10:08:22 +0300 (EEST) Message-ID: <42E33E67.7040205@he.iki.fi> Date: Sun, 24 Jul 2005 10:08:23 +0300 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <42DFDCCA.8050207@he.iki.fi> <200507210137.29816.peter@wemm.org> <42DFF043.3090203@he.iki.fi> In-Reply-To: <42DFF043.3090203@he.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kernel memory 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, 24 Jul 2005 07:08:25 -0000 BTW, I remember seeing a freebsd memory map somewhere but I'm unable to locate it again. Is there one that has been updated to be valid for the 64 bit platforms? Pete Petri Helenius wrote: > Peter Wemm wrote: > >> >> 2GB for paged kernel memory. But in addition we access memory via >> the direct map area to avoid the need for temporary mappings in many >> cases. uma (malloc, mbufs) etc use this, as does the sfbuf temporary >> mapping system. >> >> >> > So there is no limitation for malloced memory? Say if my driver would > like to have 4 or 8 gig lookup cache that would work? > > Pete > > > From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 24 08:16:25 2005 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 6DCFB16A41F for ; Sun, 24 Jul 2005 08:16:25 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from rms06.rommon.net (rms06.rommon.net [212.54.5.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13C9E43D46 for ; Sun, 24 Jul 2005 08:16:24 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.236] (dyn236.helenius.fi [193.64.42.236]) by rms06.rommon.net (Postfix) with ESMTP id 9EDE333C1B; Sun, 24 Jul 2005 11:16:22 +0300 (EEST) Message-ID: <42E34E56.8060108@he.iki.fi> Date: Sun, 24 Jul 2005 11:16:22 +0300 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <42DFDCCA.8050207@he.iki.fi> <200507210137.29816.peter@wemm.org> <42DFF043.3090203@he.iki.fi> <200507231212.24708.peter@wemm.org> In-Reply-To: <200507231212.24708.peter@wemm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: kernel memory 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, 24 Jul 2005 08:16:25 -0000 Peter Wemm wrote: > >AARGH. I've just found a bug/feature in the memory allocator. > >There are two code paths, one for small (uses the direct map allocations instead of kvm allocations, and the >other large chunk allocator that simply allocates pages at a time from >kvm. :-( > >I suspect this is because malloc's semantics depend on objects being >contiguous. The direct map method would allocate physically >discontiguous pages. > >So, if you allocated your lookup cache in <4K chunks, you could have as >much as you like. :-/ > > Is there an overhead I should be aware of if I say allocate 10 million 400 byte entries? (other than I obviously suffer the overhead of keeping an array of pointers) Pete From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 24 17:47:55 2005 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 6D52316A41F for ; Sun, 24 Jul 2005 17:47:55 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1124543D48 for ; Sun, 24 Jul 2005 17:47:54 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id BBC112A8F3 for ; Sun, 24 Jul 2005 10:47:53 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 71516E2B3 for ; Sun, 24 Jul 2005 10:47:53 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.1) with ESMTP id j6OHlrrI007033; Sun, 24 Jul 2005 10:47:53 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id j6OHlqW3007032; Sun, 24 Jul 2005 10:47:52 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Sun, 24 Jul 2005 10:47:52 -0700 User-Agent: KMail/1.8.1 References: <42DFDCCA.8050207@he.iki.fi> <42DFF043.3090203@he.iki.fi> <42E33E67.7040205@he.iki.fi> In-Reply-To: <42E33E67.7040205@he.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507241047.52669.peter@wemm.org> Cc: Petri Helenius Subject: Re: kernel memory 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, 24 Jul 2005 17:47:55 -0000 On Sunday 24 July 2005 12:08 am, Petri Helenius wrote: > BTW, I remember seeing a freebsd memory map somewhere but I'm unable > to locate it again. Is there one that has been updated to be valid > for the 64 bit platforms? 0000000000000000 - 00007fffffffffff userland 0000800000000000 - ffff7fffffffffff does not exist (hole) ffff800000000000 - ffff804020100fff recursive page table (512GB slot) .. unused .. ffffff0000000000 - ffffff7fffffffff 512GB direct map mappings ffffff8000000000 - ffffffff7fffffff 510GB future kva (todo) ffffffff80000000 - ffffffffffffffff 2GB kva This is specific to the FreeBSD/amd64 kernel as it currently stands. The "hole" does not exist, you can't generate addresses in that region because it doesn't map onto the page table tree and causes a GPF. This layout is arranged around the 512 entry 4th level page table page. Each slot corresponds to 512GB of virtual address space. Slots 0 - 255 are userland, 256 - 511 are kernel. kvm is using 2GB out of the topmost slot. When we extend KVM, it'll have all 512GB available. The direct map region uses the next slot from the top, using 2MB pages. It only has enough entries in there to cover max(physicalram, 4GB); because it is still a page table tree and it would consume physical pages to implement it. If there is nothing actually there, there isn't much point wasting page table pages for them. There is a huge "unused" block in the kernel half of address space. Only 3 of the 256 kernel slots are used. > Pete > > Petri Helenius wrote: > > Peter Wemm wrote: > >> 2GB for paged kernel memory. But in addition we access memory via > >> the direct map area to avoid the need for temporary mappings in > >> many cases. uma (malloc, mbufs) etc use this, as does the sfbuf > >> temporary mapping system. > > > > So there is no limitation for malloced memory? Say if my driver > > would like to have 4 or 8 gig lookup cache that would work? > > > > Pete > > _______________________________________________ > 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" -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 01:10:20 2005 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 C571316A41F for ; Mon, 25 Jul 2005 01:10:20 +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 5493243D45 for ; Mon, 25 Jul 2005 01:10: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.3/8.13.3) with ESMTP id j6P1AKvs015716 for ; Mon, 25 Jul 2005 01:10:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j6P1AKO9015715; Mon, 25 Jul 2005 01:10:20 GMT (envelope-from gnats) Resent-Date: Mon, 25 Jul 2005 01:10:20 GMT Resent-Message-Id: <200507250110.j6P1AKO9015715@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, meka Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EA8B16A41F for ; Mon, 25 Jul 2005 01:04:06 +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 6514D43D45 for ; Mon, 25 Jul 2005 01:04:06 +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 j6P146xg002738 for ; Mon, 25 Jul 2005 01:04:06 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j6P146Aw002737; Mon, 25 Jul 2005 01:04:06 GMT (envelope-from nobody) Message-Id: <200507250104.j6P146Aw002737@www.freebsd.org> Date: Mon, 25 Jul 2005 01:04:06 GMT From: meka To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/84027: if_nve gets stuck 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, 25 Jul 2005 01:10:20 -0000 >Number: 84027 >Category: amd64 >Synopsis: if_nve gets stuck >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jul 25 01:10:19 GMT 2005 >Closed-Date: >Last-Modified: >Originator: meka >Release: 6.0-BETA1 >Organization: >Environment: FreeBSD hal9000 6.0-BETA1 FreeBSD 6.0-BETA1 #0: Sun Jul 24 04:00:43 CEST 2005 root@hal9000:/usr/src/sys/amd64/compile/HAL9000 amd64 >Description: Some kind of if_nve buffer is geting full. I keep getting messages: nve0: device timeout (2). When I get the "final" message nve0: device timeout (64), I can not do anything on the LAN. I've noticed that this buffer is fulled faster when I'm accessing NET (through gateway). I've marked this bug as serious with medium priority because of FreeBSD's policy "made to serve". Simple kldunload/kldload makes this buffer empty, but this is not what one wants to do every 15 minutes. >How-To-Repeat: Use it on MSI nforce3 board. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 11:02:07 2005 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 E923716A421 for ; Mon, 25 Jul 2005 11:02:06 +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 AC9FE43D45 for ; Mon, 25 Jul 2005 11:02:06 +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.3/8.13.3) with ESMTP id j6PB26qa018317 for ; Mon, 25 Jul 2005 11:02:06 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j6PB25A4018311 for freebsd-amd64@freebsd.org; Mon, 25 Jul 2005 11:02:05 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 25 Jul 2005 11:02:05 GMT Message-Id: <200507251102.j6PB25A4018311@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, 25 Jul 2005 11:02:07 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/27] amd64/73211 amd64 FAST_IPSEC broken on amd64 1 problem 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/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see o [2004/10/30] amd64/73322 amd64 unarchiving /etc to msdos fs locks up amd o [2004/11/01] amd64/73369 amd64 on-board firewire unreliable with Asus K8 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/04] amd64/77101 amd64 Please include ULi M1689 LAN, SATA, and A o [2005/02/17] amd64/77629 amd64 aMule hardlocks AMD64 system 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 driver on FreeBSD 5.x does not work o 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/19] amd64/81272 amd64 JDK 1.5 port doesn't build. o [2005/05/20] amd64/81325 amd64 KLD if_ath.ko: depends on ath_hal - not a 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 f [2005/06/12] amd64/82176 amd64 ehci causes crash on amd64 o [2005/06/19] amd64/82425 amd64 fxp0: device timeout, fxp interface dies 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/07/25] amd64/84027 amd64 if_nve gets stuck 35 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(4) broken on amd64 o [2004/07/28] amd64/69705 amd64 IPC problem (msq_queues) o [2004/07/28] amd64/69709 amd64 ACPI enabled then floppy don't work (5.2. o [2004/08/15] amd64/70500 amd64 bge driver for 3Com 3C996B on amd64 preve o [2004/12/02] amd64/74608 amd64 mpt hangs 5 minutes when booting o [2004/12/07] amd64/74811 amd64 df, nfs mount, negative Avail -> 32/64-bi o [2004/12/13] ports/75015 amd64 cvsup on amd64 with runsocks (socks5) cor o [2005/03/17] amd64/78954 amd64 kerberos 5 failed to build o [2005/05/16] amd64/81089 amd64 FreeBSD 5.4 released version can not use o [2005/06/12] amd64/82178 amd64 missing 32bit subsystem o [2005/06/18] amd64/82380 amd64 buildworld error in libc o [2005/06/18] amd64/82399 amd64 MSI K8N Neo4 Platinium is not supported o [2005/06/24] amd64/82599 amd64 ports/misc/mtx wont compile on amd64 o [2005/07/20] amd64/83806 amd64 Can not comple /usr/src/lib/msun/amd64/fe 15 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 19:06:46 2005 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 C4D9D16A41F for ; Mon, 25 Jul 2005 19:06:46 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 398F543D46 for ; Mon, 25 Jul 2005 19:06:46 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 150FB2A909 for ; Mon, 25 Jul 2005 12:06:46 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id C1C39E2B3 for ; Mon, 25 Jul 2005 12:06:45 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.1) with ESMTP id j6PJ6j0v056565; Mon, 25 Jul 2005 12:06:45 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id j6PJ6d0c056564; Mon, 25 Jul 2005 12:06:39 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Mon, 25 Jul 2005 12:06:38 -0700 User-Agent: KMail/1.8.1 References: <20050411033957.GA21170@xor.obsecurity.org> In-Reply-To: <20050411033957.GA21170@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507251206.39454.peter@wemm.org> Cc: Kris Kennaway Subject: Re: fpudna: fpcurthread == curthread 2 times 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, 25 Jul 2005 19:06:46 -0000 On Sunday 10 April 2005 08:39 pm, Kris Kennaway wrote: > Got this on an SMP package machine running 5.4-RC2: > > fpudna: fpcurthread == curthread 1 times > fpudna: fpcurthread == curthread 2 times > > int > fpudna() > { > struct pcb *pcb; > register_t s; > > if (PCPU_GET(fpcurthread) == curthread) { > printf("fpudna: fpcurthread == curthread %d times\n", > ++err_count); > stop_emulating(); > return (1); > } > > Debugging message accidentally left in, or bug? > > Kris If any folks are reliably seeing these messages, please try a tweak to amd64/amd64/fpu.c. The lines near the top that are "__asm()"... please change them all to "__asm __volatile()" This is the code that I'd like changed: #define fldcw(addr) __asm("fldcw %0" : : "m" (*(addr))) #define fnclex() __asm("fnclex") #define fninit() __asm("fninit") #define fnstcw(addr) __asm __volatile("fnstcw %0" : "=m" (*(addr))) #define fnstsw(addr) __asm __volatile("fnstsw %0" : "=m" (*(addr))) #define fxrstor(addr) __asm("fxrstor %0" : : "m" (*(addr))) #define fxsave(addr) __asm __volatile("fxsave %0" : "=m" (*(addr))) #define ldmxcsr(r) __asm __volatile("ldmxcsr %0" : : "m" (r)) #define start_emulating() __asm("smsw %%ax; orb %0,%%al; lmsw %%ax" \ : : "n" (CR0_TS) : "ax") #define stop_emulating() __asm("clts") If this tweak has any effect (either better or worse), please let me know. I'm wondering if there are some reordering effects going on here. It is just a wild shot in the dark. It won't hurt anything though and is safe to try. Most likely it is a wild goose chase, but it could be worth a try. What would be worth knowing is: 1) if the patch stops messages for people who see them regularly or repeatably, and/or 2) if the messages keep happening even with the patch applied. The latter case indicates that it is a wild goose chase. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 20:26:43 2005 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 2AFB016A41F; Mon, 25 Jul 2005 20:26:43 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6235F43D45; Mon, 25 Jul 2005 20:26:38 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j6PKQYF8007638; Mon, 25 Jul 2005 22:26:34 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j6PKQYIf007636; Mon, 25 Jul 2005 22:26:34 +0200 Received: (from nox@localhost) by saturn.kn-bremen.de (8.11.4/8.8.5) id j6PKQBr43809; Mon, 25 Jul 2005 22:26:11 +0200 (CEST) From: Juergen Lock Date: Mon, 25 Jul 2005 22:26:09 +0200 To: freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20050725222608.A42815@saturn.kn-bremen.de> Mail-Followup-To: freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org, ports@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Cc: ports@FreeBSD.org Subject: need help with kqemu 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, 25 Jul 2005 20:26:43 -0000 Hi! Fabrice has released a new version of kqemu that now also supports amd64 hosts, but as he doesnt know FreeBSD (and my kernel foo is far from being good enough, neither do i have an amd64 box) we need someone to port the wrapper to amd64. Actually the i386 wrapper he has now added to the release (kqemu-0.7.1.tar.gz) doesnt work either (not sure what happened there, it doesnt even build), so we need someone to fix/update that as well. I have made an update for the port that can be used as a template (only non-kqemu build works), I'll append it below: Removed files: files/BSDmakefile files/kmod_bsd.c New files: files/kqemu-Makefile-patch files/patch-libmath2 files/patch-vl.c (btw patch-vl.c is from Andrey V. Elsukov, it enables kernel debugging via virtual serial console, as posted on -ports: # qemu -hda disk.img -cdrom 6.0-BETA1.iso -serial pty # gdb (gdb) target remote /dev/ptyp0 ....) Index: Makefile =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- Makefile 19 Jul 2005 06:06:56 -0000 1.27 +++ Makefile 25 Jul 2005 16:52:49 -0000 @@ -6,12 +6,9 @@ # PORTNAME= qemu -PORTVERSION= 0.7.0s.20050717 +PORTVERSION= 0.7.1 CATEGORIES= emulators -MASTER_SITES= http://www.qemu.org/ \ - http://people.fruitsalad.org/nox/qemu/ \ - http://dad-answers.com/qemu/ -DISTNAME= ${PORTNAME}-snapshot-2005-07-17_23 +MASTER_SITES= http://www.qemu.org/ EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} MAINTAINER= nox@jelal.kn-bremen.de @@ -23,12 +20,12 @@ .endif .if defined(WITH_KQEMU) -DISTKQEMU= kqemu-0.6.2-1.tar.gz +DISTKQEMU= kqemu-0.7.1.tar.gz DISTFILES= ${EXTRACT_ONLY} ${DISTKQEMU} +EXTRA_PATCHES= ${FILESDIR}/kqemu-Makefile-patch .endif HAS_CONFIGURE= yes -USE_BZIP2= yes USE_GMAKE= yes USE_GETOPT_LONG= yes USE_SDL= sdl @@ -85,7 +82,7 @@ .if defined(WITH_KQEMU) post-extract: @cd ${WRKSRC} && ${TAR} xfz ${_DISTDIR}/${DISTKQEMU} - @${CP} ${FILESDIR}/BSDmakefile ${FILESDIR}/kmod_bsd.c ${WRKSRC}/kqemu + @${LN} -s Makefile.freebsd ${WRKSRC}/kqemu/BSDmakefile .endif pre-patch: Index: distinfo =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v retrieving revision 1.20 diff -u -r1.20 distinfo --- distinfo 19 Jul 2005 06:06:56 -0000 1.20 +++ distinfo 25 Jul 2005 16:40:12 -0000 @@ -1,4 +1,4 @@ -MD5 (qemu-snapshot-2005-07-17_23.tar.bz2) = 5d21295c1f328ea00de19a54715ee7c3 -SIZE (qemu-snapshot-2005-07-17_23.tar.bz2) = 1114748 -MD5 (kqemu-0.6.2-1.tar.gz) = c6bb3b40fb3d526d731eb0f1f9dee7ee -SIZE (kqemu-0.6.2-1.tar.gz) = 21002 +MD5 (qemu-0.7.1.tar.gz) = b0c80d2c082049a5b8ccbc7f55fe165b +SIZE (qemu-0.7.1.tar.gz) = 1338521 +MD5 (kqemu-0.7.1.tar.gz) = 8fc7967492b2157521198f6639218420 +SIZE (kqemu-0.7.1.tar.gz) = 76135 Index: files/kqemu-Makefile-patch @@ -0,0 +1,13 @@ +Index: qemu/kqemu/Makefile.freebsd +@@ -1,6 +1,10 @@ + # $Id: Makefile.freebsd,v 1.1 2005/04/17 17:21:31 bellard Exp $ + KMOD= kqemu +-SRCS= kmod-freebsd.c ++SRCS= kqemu-freebsd.c + OBJS= kqemu-mod-i386.o ++.if ${OSVERSION} >= 500000 ++CC= cc ++.endif ++WERROR= + + .include Index: files/patch-libmath2 @@ -0,0 +1,67 @@ +Index: qemu/bsd/Makefile +@@ -16,7 +16,8 @@ + ${MACHINE_ARCH}/s_rintl.c \ + ${MACHINE_ARCH}/s_round.c \ + ${MACHINE_ARCH}/s_sinl.S \ +- ${MACHINE_ARCH}/s_tanl.S ++ ${MACHINE_ARCH}/s_tanl.S \ ++ ${MACHINE_ARCH}/s_ldexpl.c + + OBJS= ${SRCS:R:S/$/.o/} + +Index: qemu/bsd/i386/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/bsd/amd64/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/target-i386/helper.c +@@ -2886,6 +2886,8 @@ + ST0 = floatx_round_to_int(ST0, &env->fp_status); + } + ++long double ldexpl(long double, int); ++ + void helper_fscale(void) + { + ST0 = ldexp (ST0, (int)(ST1)); Index: files/patch-vl.c @@ -0,0 +1,21 @@ +Index: qemu/vl.c +@@ -40,6 +40,10 @@ + #include + #include + #include ++#ifdef __FreeBSD__ ++#include ++#include ++#endif + #ifdef _BSD + #include + #ifndef __APPLE__ +@@ -1280,7 +1284,7 @@ + return chr; + } + +-#if defined(__linux__) ++#if defined(__linux__) || defined(__FreeBSD__) + CharDriverState *qemu_chr_open_pty(void) + { + char slave_name[1024]; From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 22:09:50 2005 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 F35A616A41F; Mon, 25 Jul 2005 22:09:49 +0000 (GMT) (envelope-from pete@users.altadena.net) Received: from users.altadena.net (users.altadena.net [207.151.161.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAEDB43D45; Mon, 25 Jul 2005 22:09:49 +0000 (GMT) (envelope-from pete@users.altadena.net) Received: from pete by users.altadena.net with local (Exim 4.51) id 1DxB8v-000NSa-DD; Mon, 25 Jul 2005 15:09:49 -0700 Date: Mon, 25 Jul 2005 15:09:49 -0700 From: Pete Carah To: mobile@freebsd.org, amd64@freebsd.org Message-ID: <20050725220949.GA90080@users.altadena.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Sender: Pete Carah Cc: Subject: Disgusting wireless with Compaq v2310 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, 25 Jul 2005 22:09:50 -0000 I attempted to change my wireless card from the provided Broadcom to a more usable Atheros one and to my disgust, apparently Compaq detects this in the bios and won't even give me the banner screen. Instead it just blinks the caps and num lock lights quick-on long-off and refuses to boot. Is there a bypass to this? I've tried various F keys and other such... and control-alt combinations, and fn-alt etc. It *will* boot with the wireless card totally removed. Does anyone know how to do this right and/or does ndis work on the amd64 now? (I am using WPA (with 1x) several places and the atheros is a nice card for this purpose...) (i.e. does ndis handle wpa on the broadcom anyhow, especially on the AMD64?) Waiting for X11 too... (that is already in process with several folks.) -- Pete From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 22:26:13 2005 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 BD52416A420; Mon, 25 Jul 2005 22:26:13 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 680F543D58; Mon, 25 Jul 2005 22:26:09 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j6PMSLHG036444; Mon, 25 Jul 2005 18:28:21 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-amd64@FreeBSD.org Date: Mon, 25 Jul 2005 18:25:50 -0400 User-Agent: KMail/1.6.2 References: <20050725222608.A42815@saturn.kn-bremen.de> In-Reply-To: <20050725222608.A42815@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_vbW5CTfX8oQ8HhB" Message-Id: <200507251825.51540.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/992/Mon Jul 25 17:48:49 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, Juergen Lock Subject: Re: need help with kqemu 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, 25 Jul 2005 22:26:13 -0000 --Boundary-00=_vbW5CTfX8oQ8HhB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 25 July 2005 04:26 pm, Juergen Lock wrote: > Hi! > > Fabrice has released a new version of kqemu that now also > supports amd64 hosts, but as he doesnt know FreeBSD (and my > kernel foo is far from being good enough, neither do i have > an amd64 box) we need someone to port the wrapper to amd64. > Actually the i386 wrapper he has now added to the release > (kqemu-0.7.1.tar.gz) doesnt work either (not sure what happened > there, it doesnt even build), so we need someone to fix/update > that as well. I have made an update for the port that can be > used as a template (only non-kqemu build works), I'll append it > below: > > Removed files: files/BSDmakefile files/kmod_bsd.c > New files: files/kqemu-Makefile-patch files/patch-libmath2 > files/patch-vl.c > > (btw patch-vl.c is from Andrey V. Elsukov, it enables kernel > debugging via virtual serial console, as posted on -ports: > > # qemu -hda disk.img -cdrom 6.0-BETA1.iso -serial pty > # gdb > (gdb) target remote /dev/ptyp0 > ....) Try the attachment. It seems to build and work on amd64 now, including kqemu. Thanks! Jung-uk Kim --Boundary-00=_vbW5CTfX8oQ8HhB Content-Type: text/x-diff; charset="iso-8859-1"; name="qemu.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu.diff" Index: Makefile =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- Makefile 19 Jul 2005 06:06:56 -0000 1.27 +++ Makefile 25 Jul 2005 22:16:33 -0000 @@ -6,12 +6,9 @@ # PORTNAME= qemu -PORTVERSION= 0.7.0s.20050717 +PORTVERSION= 0.7.1 CATEGORIES= emulators -MASTER_SITES= http://www.qemu.org/ \ - http://people.fruitsalad.org/nox/qemu/ \ - http://dad-answers.com/qemu/ -DISTNAME= ${PORTNAME}-snapshot-2005-07-17_23 +MASTER_SITES= http://www.qemu.org/ EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} MAINTAINER= nox@jelal.kn-bremen.de @@ -23,12 +20,12 @@ .endif .if defined(WITH_KQEMU) -DISTKQEMU= kqemu-0.6.2-1.tar.gz +DISTKQEMU= kqemu-0.7.1.tar.gz DISTFILES= ${EXTRACT_ONLY} ${DISTKQEMU} +EXTRA_PATCHES= ${FILESDIR}/kqemu-freebsd-patch .endif HAS_CONFIGURE= yes -USE_BZIP2= yes USE_GMAKE= yes USE_GETOPT_LONG= yes USE_SDL= sdl @@ -40,9 +37,11 @@ ONLY_FOR_ARCHS= amd64 i386 .if defined(WITH_KQEMU) NO_PACKAGE= Depends on kernel, and module not redistributable +CONFIGURE_ARGS+= --enable-kqemu PLIST_SUB= WITH_KQEMU="" PLIST_SUB+= KMODDIR=${KMODDIR} .else +CONFIGURE_ARGS+= --disable-kqemu PLIST_SUB= WITH_KQEMU="@comment " .endif @@ -52,7 +51,7 @@ .if ${ARCH} == "amd64" ARCH= x86_64 -.if ${OSVERSION} >= 502126 +.if ${OSVERSION} >= 502126 && ${OSVERSION} <= 600029 BUILD_DEPENDS+= gcc34:${PORTSDIR}/lang/gcc34 GCCVERSION= 030402 CC= gcc34 @@ -63,16 +62,12 @@ USE_GCC= 3.4 .endif -.if defined(WITH_KQEMU) && ${ARCH} != "i386" -IGNORE= kqemu only supported on i386 -.endif - .if defined(WITH_KQEMU) && !exists(${SRC_BASE}/sys/Makefile) IGNORE= kqemu requires kernel source to be installed .endif pre-everything:: -.if !defined(WITH_KQEMU) && ${ARCH} == "i386" +.if !defined(WITH_KQEMU) @${ECHO_MSG} "Notice: you can build qemu with the (alpha!) kqemu accelerator kernel module" @${ECHO_MSG} "by defining WITH_KQEMU." .endif @@ -85,7 +80,7 @@ .if defined(WITH_KQEMU) post-extract: @cd ${WRKSRC} && ${TAR} xfz ${_DISTDIR}/${DISTKQEMU} - @${CP} ${FILESDIR}/BSDmakefile ${FILESDIR}/kmod_bsd.c ${WRKSRC}/kqemu + @${LN} -s Makefile.freebsd ${WRKSRC}/kqemu/BSDmakefile .endif pre-patch: Index: distinfo =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v retrieving revision 1.20 diff -u -r1.20 distinfo --- distinfo 19 Jul 2005 06:06:56 -0000 1.20 +++ distinfo 25 Jul 2005 22:16:33 -0000 @@ -1,4 +1,4 @@ -MD5 (qemu-snapshot-2005-07-17_23.tar.bz2) = 5d21295c1f328ea00de19a54715ee7c3 -SIZE (qemu-snapshot-2005-07-17_23.tar.bz2) = 1114748 -MD5 (kqemu-0.6.2-1.tar.gz) = c6bb3b40fb3d526d731eb0f1f9dee7ee -SIZE (kqemu-0.6.2-1.tar.gz) = 21002 +MD5 (qemu-0.7.1.tar.gz) = b0c80d2c082049a5b8ccbc7f55fe165b +SIZE (qemu-0.7.1.tar.gz) = 1338521 +MD5 (kqemu-0.7.1.tar.gz) = 8fc7967492b2157521198f6639218420 +SIZE (kqemu-0.7.1.tar.gz) = 76135 Index: files/patch-fbsd =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/files/patch-fbsd,v retrieving revision 1.2 diff -u -r1.2 patch-fbsd --- files/patch-fbsd 5 May 2005 12:41:10 -0000 1.2 +++ files/patch-fbsd 25 Jul 2005 22:16:33 -0000 @@ -13,7 +13,7 @@ $(MAKE) -C kqemu -f Makefile.winnt else - $(MAKE) -C kqemu -+ cd kqemu && $(BSD_MAKE) ++ ( cd kqemu && $(BSD_MAKE) ) endif endif --- files/kqemu-freebsd-patch Mon Jul 25 18:11:00 2005 +++ files/kqemu-freebsd-patch Mon Jul 25 18:04:37 2005 @@ -0,0 +1,50 @@ +--- qemu/configure.orig Mon Jul 25 17:58:33 2005 ++++ qemu/configure Mon Jul 25 17:59:55 2005 +@@ -99,7 +99,7 @@ + FreeBSD) + bsd="yes" + oss="yes" +-if [ "$cpu" = "i386" ] ; then ++if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then + kqemu="yes" + fi + ;; +--- qemu/kqemu/Makefile.freebsd.orig Sun Apr 17 13:21:31 2005 ++++ qemu/kqemu/Makefile.freebsd Mon Jul 25 17:32:48 2005 +@@ -1,6 +1,11 @@ + # $Id: Makefile.freebsd,v 1.1 2005/04/17 17:21:31 bellard Exp $ + KMOD= kqemu +-SRCS= kmod-freebsd.c ++SRCS= kqemu-freebsd.c ++.if ${MACHINE_ARCH} == "i386" + OBJS= kqemu-mod-i386.o ++.elif ${MACHINE_ARCH} == "amd64" ++OBJS= kqemu-mod-x86_64.o ++.endif ++WERROR= + + .include +--- qemu/kqemu/kqemu-freebsd.c.orig Mon Apr 25 18:14:40 2005 ++++ qemu/kqemu/kqemu-freebsd.c Mon Jul 25 17:40:17 2005 +@@ -59,9 +59,9 @@ + // printf("kqemu_unlock_user_page(%08lx)\n", page_index); + va = (vm_offset_t)page; + ret = vm_map_unwire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); +- if (ret != KERN_SUCCESS) { +- printf("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); +- } ++ // if (ret != KERN_SUCCESS) { ++ // printf("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); ++ // } + } + + /* +@@ -88,7 +88,7 @@ + + void CDECL kqemu_free_page(struct kqemu_page *page) + { +- printf("kqemu_free_page(%08lx)\n", page_index); ++ // printf("kqemu_free_page(%08lx)\n", page_index); + /* XXX: do it */ + } + --- files/patch-libmath2 Mon Jul 25 18:11:00 2005 +++ files/patch-libmath2 Mon Jul 25 16:54:12 2005 @@ -0,0 +1,67 @@ +Index: qemu/bsd/Makefile +@@ -16,7 +16,8 @@ + ${MACHINE_ARCH}/s_rintl.c \ + ${MACHINE_ARCH}/s_round.c \ + ${MACHINE_ARCH}/s_sinl.S \ +- ${MACHINE_ARCH}/s_tanl.S ++ ${MACHINE_ARCH}/s_tanl.S \ ++ ${MACHINE_ARCH}/s_ldexpl.c + + OBJS= ${SRCS:R:S/$/.o/} + +Index: qemu/bsd/i386/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/bsd/amd64/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/target-i386/helper.c +@@ -2886,6 +2886,8 @@ + ST0 = floatx_round_to_int(ST0, &env->fp_status); + } + ++long double ldexpl(long double, int); ++ + void helper_fscale(void) + { + ST0 = ldexp (ST0, (int)(ST1)); --- files/patch-vl.c Mon Jul 25 18:11:00 2005 +++ files/patch-vl.c Mon Jul 25 16:54:12 2005 @@ -0,0 +1,21 @@ +Index: qemu/vl.c +@@ -40,6 +40,10 @@ + #include + #include + #include ++#ifdef __FreeBSD__ ++#include ++#include ++#endif + #ifdef _BSD + #include + #ifndef __APPLE__ +@@ -1280,7 +1284,7 @@ + return chr; + } + +-#if defined(__linux__) ++#if defined(__linux__) || defined(__FreeBSD__) + CharDriverState *qemu_chr_open_pty(void) + { + char slave_name[1024]; --Boundary-00=_vbW5CTfX8oQ8HhB-- From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 22:28:08 2005 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 222AB16A41F; Mon, 25 Jul 2005 22:28:08 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B255C43D46; Mon, 25 Jul 2005 22:28:07 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j6PMUCgc036505; Mon, 25 Jul 2005 18:30:12 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-amd64@FreeBSD.org Date: Mon, 25 Jul 2005 18:27:41 -0400 User-Agent: KMail/1.6.2 References: <20050725222608.A42815@saturn.kn-bremen.de> <200507251825.51540.jkim@FreeBSD.org> In-Reply-To: <200507251825.51540.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200507251827.42671.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/992/Mon Jul 25 17:48:49 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, Juergen Lock Subject: Re: need help with kqemu 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, 25 Jul 2005 22:28:08 -0000 On Monday 25 July 2005 06:25 pm, Jung-uk Kim wrote: > On Monday 25 July 2005 04:26 pm, Juergen Lock wrote: > > Hi! > > > > Fabrice has released a new version of kqemu that now also > > supports amd64 hosts, but as he doesnt know FreeBSD (and my > > kernel foo is far from being good enough, neither do i have > > an amd64 box) we need someone to port the wrapper to amd64. > > Actually the i386 wrapper he has now added to the release > > (kqemu-0.7.1.tar.gz) doesnt work either (not sure what happened > > there, it doesnt even build), so we need someone to fix/update > > that as well. I have made an update for the port that can be > > used as a template (only non-kqemu build works), I'll append it > > below: > > > > Removed files: files/BSDmakefile files/kmod_bsd.c > > New files: files/kqemu-Makefile-patch files/patch-libmath2 > > files/patch-vl.c > > > > (btw patch-vl.c is from Andrey V. Elsukov, it enables kernel > > debugging via virtual serial console, as posted on -ports: > > > > # qemu -hda disk.img -cdrom 6.0-BETA1.iso -serial pty > > # gdb > > (gdb) target remote /dev/ptyp0 > > ....) > > Try the attachment. It seems to build and work on amd64 now, > including kqemu. Oops, I forgot to tell you that I renamed files/kqemu-Makefile-patch to files/kqemu-freebsd-patch because it has more than Makefile.freebsd patch now. Sorry, Jung-uk Kim > Thanks! > > Jung-uk Kim From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 25 23:41:45 2005 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 0ED4C16A41F; Mon, 25 Jul 2005 23:41:45 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EFE743D45; Mon, 25 Jul 2005 23:41:42 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j6PNfeFC023396; Tue, 26 Jul 2005 01:41:40 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j6PNfe3e023394; Tue, 26 Jul 2005 01:41:40 +0200 Received: (from nox@localhost) by saturn.kn-bremen.de (8.11.4/8.8.5) id j6PNg8l49455; Tue, 26 Jul 2005 01:42:08 +0200 (CEST) From: Juergen Lock Date: Tue, 26 Jul 2005 01:42:08 +0200 To: Jung-uk Kim Message-ID: <20050726014207.A48961@saturn.kn-bremen.de> Mail-Followup-To: Jung-uk Kim , freebsd-amd64@FreeBSD.org, freebsd-emulation@FreeBSD.org, ports@FreeBSD.org References: <20050725222608.A42815@saturn.kn-bremen.de> <200507251825.51540.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200507251825.51540.jkim@FreeBSD.org> Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: need help with kqemu 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, 25 Jul 2005 23:41:45 -0000 On Mon, Jul 25, 2005 at 06:25:50PM -0400, Jung-uk Kim wrote: > On Monday 25 July 2005 04:26 pm, Juergen Lock wrote: > > Hi! > > > > Fabrice has released a new version of kqemu that now also > > supports amd64 hosts, but as he doesnt know FreeBSD (and my > > kernel foo is far from being good enough, neither do i have > > an amd64 box) we need someone to port the wrapper to amd64. > > Actually the i386 wrapper he has now added to the release > > (kqemu-0.7.1.tar.gz) doesnt work either (not sure what happened > > there, it doesnt even build), so we need someone to fix/update > > that as well. I have made an update for the port that can be > > used as a template (only non-kqemu build works), I'll append it > > below: > > > > Removed files: files/BSDmakefile files/kmod_bsd.c > > New files: files/kqemu-Makefile-patch files/patch-libmath2 > > files/patch-vl.c > > > > (btw patch-vl.c is from Andrey V. Elsukov, it enables kernel > > debugging via virtual serial console, as posted on -ports: > > > > # qemu -hda disk.img -cdrom 6.0-BETA1.iso -serial pty > > # gdb > > (gdb) target remote /dev/ptyp0 > > ....) > > Try the attachment. It seems to build and work on amd64 now, > including kqemu. Hey, nice! So there wasnt actually that much wrong... One question: Does this also work on 4.x? Here's my version: (I disabled a kqemu_vmalloc_to_phys(%p) printf and added back use of the system cc for kqemu) Removed files: files/BSDmakefile, files/kmod_bsd.c New files: files/kqemu-freebsd-patch files/patch-libmath2 files/patch-vl.c Index: Makefile =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- Makefile 19 Jul 2005 06:06:56 -0000 1.27 +++ Makefile 25 Jul 2005 23:00:43 -0000 @@ -6,12 +6,9 @@ # PORTNAME= qemu -PORTVERSION= 0.7.0s.20050717 +PORTVERSION= 0.7.1 CATEGORIES= emulators -MASTER_SITES= http://www.qemu.org/ \ - http://people.fruitsalad.org/nox/qemu/ \ - http://dad-answers.com/qemu/ -DISTNAME= ${PORTNAME}-snapshot-2005-07-17_23 +MASTER_SITES= http://www.qemu.org/ EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} MAINTAINER= nox@jelal.kn-bremen.de @@ -23,12 +20,12 @@ .endif .if defined(WITH_KQEMU) -DISTKQEMU= kqemu-0.6.2-1.tar.gz +DISTKQEMU= kqemu-0.7.1.tar.gz DISTFILES= ${EXTRACT_ONLY} ${DISTKQEMU} +EXTRA_PATCHES= ${FILESDIR}/kqemu-freebsd-patch .endif HAS_CONFIGURE= yes -USE_BZIP2= yes USE_GMAKE= yes USE_GETOPT_LONG= yes USE_SDL= sdl @@ -40,9 +37,11 @@ ONLY_FOR_ARCHS= amd64 i386 .if defined(WITH_KQEMU) NO_PACKAGE= Depends on kernel, and module not redistributable +CONFIGURE_ARGS+= --enable-kqemu PLIST_SUB= WITH_KQEMU="" PLIST_SUB+= KMODDIR=${KMODDIR} .else +CONFIGURE_ARGS+= --disable-kqemu PLIST_SUB= WITH_KQEMU="@comment " .endif @@ -52,7 +51,7 @@ .if ${ARCH} == "amd64" ARCH= x86_64 -.if ${OSVERSION} >= 502126 +.if ${OSVERSION} >= 502126 && ${OSVERSION} <= 600029 BUILD_DEPENDS+= gcc34:${PORTSDIR}/lang/gcc34 GCCVERSION= 030402 CC= gcc34 @@ -63,16 +62,12 @@ USE_GCC= 3.4 .endif -.if defined(WITH_KQEMU) && ${ARCH} != "i386" -IGNORE= kqemu only supported on i386 -.endif - .if defined(WITH_KQEMU) && !exists(${SRC_BASE}/sys/Makefile) IGNORE= kqemu requires kernel source to be installed .endif pre-everything:: -.if !defined(WITH_KQEMU) && ${ARCH} == "i386" +.if !defined(WITH_KQEMU) @${ECHO_MSG} "Notice: you can build qemu with the (alpha!) kqemu accelerator kernel module" @${ECHO_MSG} "by defining WITH_KQEMU." .endif @@ -85,7 +80,7 @@ .if defined(WITH_KQEMU) post-extract: @cd ${WRKSRC} && ${TAR} xfz ${_DISTDIR}/${DISTKQEMU} - @${CP} ${FILESDIR}/BSDmakefile ${FILESDIR}/kmod_bsd.c ${WRKSRC}/kqemu + @${LN} -s Makefile.freebsd ${WRKSRC}/kqemu/BSDmakefile .endif pre-patch: Index: distinfo =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v retrieving revision 1.20 diff -u -r1.20 distinfo --- distinfo 19 Jul 2005 06:06:56 -0000 1.20 +++ distinfo 25 Jul 2005 23:00:43 -0000 @@ -1,4 +1,4 @@ -MD5 (qemu-snapshot-2005-07-17_23.tar.bz2) = 5d21295c1f328ea00de19a54715ee7c3 -SIZE (qemu-snapshot-2005-07-17_23.tar.bz2) = 1114748 -MD5 (kqemu-0.6.2-1.tar.gz) = c6bb3b40fb3d526d731eb0f1f9dee7ee -SIZE (kqemu-0.6.2-1.tar.gz) = 21002 +MD5 (qemu-0.7.1.tar.gz) = b0c80d2c082049a5b8ccbc7f55fe165b +SIZE (qemu-0.7.1.tar.gz) = 1338521 +MD5 (kqemu-0.7.1.tar.gz) = 8fc7967492b2157521198f6639218420 +SIZE (kqemu-0.7.1.tar.gz) = 76135 Index: files/patch-fbsd =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/files/patch-fbsd,v retrieving revision 1.2 diff -u -r1.2 patch-fbsd --- files/patch-fbsd 5 May 2005 12:41:10 -0000 1.2 +++ files/patch-fbsd 25 Jul 2005 23:00:43 -0000 @@ -13,7 +13,7 @@ $(MAKE) -C kqemu -f Makefile.winnt else - $(MAKE) -C kqemu -+ cd kqemu && $(BSD_MAKE) ++ ( cd kqemu && $(BSD_MAKE) ) endif endif Index: files/kqemu-freebsd-patch @@ -0,0 +1,62 @@ +--- qemu/configure.orig Mon Jul 25 17:58:33 2005 ++++ qemu/configure Mon Jul 25 17:59:55 2005 +@@ -99,7 +99,7 @@ + FreeBSD) + bsd="yes" + oss="yes" +-if [ "$cpu" = "i386" ] ; then ++if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then + kqemu="yes" + fi + ;; +--- qemu/kqemu/Makefile.freebsd.orig Sun Apr 17 13:21:31 2005 ++++ qemu/kqemu/Makefile.freebsd Mon Jul 25 17:32:48 2005 +@@ -1,6 +1,14 @@ + # $Id: Makefile.freebsd,v 1.1 2005/04/17 17:21:31 bellard Exp $ + KMOD= kqemu +-SRCS= kmod-freebsd.c ++SRCS= kqemu-freebsd.c ++.if ${MACHINE_ARCH} == "i386" + OBJS= kqemu-mod-i386.o ++.elif ${MACHINE_ARCH} == "amd64" ++OBJS= kqemu-mod-x86_64.o ++.endif ++.if ${OSVERSION} >= 500000 ++CC= cc ++.endif ++WERROR= + + .include +--- qemu/kqemu/kqemu-freebsd.c.orig Mon Apr 25 18:14:40 2005 ++++ qemu/kqemu/kqemu-freebsd.c Mon Jul 25 17:40:17 2005 +@@ -59,9 +59,9 @@ + // printf("kqemu_unlock_user_page(%08lx)\n", page_index); + va = (vm_offset_t)page; + ret = vm_map_unwire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); +- if (ret != KERN_SUCCESS) { +- printf("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); +- } ++ // if (ret != KERN_SUCCESS) { ++ // printf("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); ++ // } + } + + /* +@@ -88,7 +88,7 @@ + + void CDECL kqemu_free_page(struct kqemu_page *page) + { +- printf("kqemu_free_page(%08lx)\n", page_index); ++ // printf("kqemu_free_page(%08lx)\n", page_index); + /* XXX: do it */ + } + +@@ -138,7 +138,7 @@ + printf("kqemu_vmalloc_to_phys(%p)->error\n", vaddr); + return -1; + } +- printf("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa); ++ /*printf("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa);*/ + return pa >> PAGE_SHIFT; + } + Index: files/patch-libmath2 @@ -0,0 +1,67 @@ +Index: qemu/bsd/Makefile +@@ -16,7 +16,8 @@ + ${MACHINE_ARCH}/s_rintl.c \ + ${MACHINE_ARCH}/s_round.c \ + ${MACHINE_ARCH}/s_sinl.S \ +- ${MACHINE_ARCH}/s_tanl.S ++ ${MACHINE_ARCH}/s_tanl.S \ ++ ${MACHINE_ARCH}/s_ldexpl.c + + OBJS= ${SRCS:R:S/$/.o/} + +Index: qemu/bsd/i386/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/bsd/amd64/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/target-i386/helper.c +@@ -2886,6 +2886,8 @@ + ST0 = floatx_round_to_int(ST0, &env->fp_status); + } + ++long double ldexpl(long double, int); ++ + void helper_fscale(void) + { + ST0 = ldexp (ST0, (int)(ST1)); Index: files/patch-vl.c @@ -0,0 +1,21 @@ +Index: qemu/vl.c +@@ -40,6 +40,10 @@ + #include + #include + #include ++#ifdef __FreeBSD__ ++#include ++#include ++#endif + #ifdef _BSD + #include + #ifndef __APPLE__ +@@ -1280,7 +1284,7 @@ + return chr; + } + +-#if defined(__linux__) ++#if defined(__linux__) || defined(__FreeBSD__) + CharDriverState *qemu_chr_open_pty(void) + { + char slave_name[1024]; From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 26 01:16:57 2005 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 948EC16A41F; Tue, 26 Jul 2005 01:16:57 +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 EF1C643D46; Tue, 26 Jul 2005 01:16:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6Q1GK5H040176; Mon, 25 Jul 2005 21:16:20 -0400 (EDT) (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 j6Q1GtfU088241; Mon, 25 Jul 2005 21:16:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 54C477304D; Mon, 25 Jul 2005 21:16:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050726011655.54C477304D@freebsd-current.sentex.ca> Date: Mon, 25 Jul 2005 21:16:55 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 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: Tue, 26 Jul 2005 01:16:57 -0000 TB --- 2005-07-25 23:16:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-25 23:16:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-07-25 23:16:01 - cleaning the object tree TB --- 2005-07-25 23:16:25 - checking out the source tree TB --- 2005-07-25 23:16:25 - cd /home/tinderbox/HEAD/amd64/amd64 TB --- 2005-07-25 23:16:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-25 23:22:01 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-25 23:22:01 - cd /home/tinderbox/HEAD/amd64/amd64/src TB --- 2005-07-25 23:22:01 - /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 --- 2005-07-26 00:52:09 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-26 00:52:09 - cd /home/tinderbox/HEAD/amd64/amd64/src TB --- 2005-07-26 00:52:09 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Jul 26 00:52:10 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Jul 26 01:07:23 UTC 2005 TB --- 2005-07-26 01:07:23 - generating LINT kernel config TB --- 2005-07-26 01:07:23 - cd /home/tinderbox/HEAD/amd64/amd64/src/sys/amd64/conf TB --- 2005-07-26 01:07:23 - /usr/bin/make -B LINT TB --- 2005-07-26 01:07:23 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-07-26 01:07:23 - cd /home/tinderbox/HEAD/amd64/amd64/src TB --- 2005-07-26 01:07:23 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 26 01:07:23 UTC 2005 >>> 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/tinderbox/HEAD/amd64/amd64/src/sys -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/altq -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/pf -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/HEAD/amd64/amd64/src/sys/dev/twa -D_KERNEL -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-as ynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_dummynet.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/tinderbox/HEAD/amd64/amd64/src/sys -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/altq -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/pf -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/HEAD/amd64/amd64/src/sys/dev/twa -D_KERNEL -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-as ynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_ecn.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/tinderbox/HEAD/amd64/amd64/src/sys -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/altq -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/pf -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/HEAD/amd64/amd64/src/sys/dev/twa -D_KERNEL -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-as ynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_encap.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/tinderbox/HEAD/amd64/amd64/src/sys -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/altq -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/pf -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/HEAD/amd64/amd64/src/sys/dev/twa -D_KERNEL -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-as ynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_fastfwd.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/tinderbox/HEAD/amd64/amd64/src/sys -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/altq -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/pf -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/HEAD/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/HEAD/amd64/amd64/src/sys/dev/twa -D_KERNEL -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-as ynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_fw2.c /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_fw2.c: In function `search_ip6_addr_net': /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_fw2.c:602: warning: implicit declaration of function `in6_clearscope' /tinderbox/HEAD/amd64/amd64/src/sys/netinet/ip_fw2.c:602: warning: nested extern declaration of `in6_clearscope' *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/obj/amd64/tinderbox/HEAD/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/src. TB --- 2005-07-26 01:16:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-26 01:16:55 - ERROR: failed to build lint kernel TB --- 2005-07-26 01:16:55 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 26 07:56:04 2005 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 BA7DC16A41F for ; Tue, 26 Jul 2005 07:56:04 +0000 (GMT) (envelope-from shadow@netherite.student.utwente.nl) Received: from netlx050.vf.utwente.nl (netlx050.vf.utwente.nl [192.87.17.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E8F43D45 for ; Tue, 26 Jul 2005 07:56:03 +0000 (GMT) (envelope-from shadow@netherite.student.utwente.nl) Received: from arcanite.student.utwente.nl (arcanite.student.utwente.nl [130.89.166.68]) by netlx050.vf.utwente.nl (8.11.7/HKD) with ESMTP id j6Q7u0PU019264 for ; Tue, 26 Jul 2005 09:56:00 +0200 From: Wouter Hummelink To: freebsd-amd64@freebsd.org Content-Type: text/plain Date: Tue, 26 Jul 2005 09:54:15 +0200 Message-Id: <1122364455.59736.12.camel@arcanite.student.utwente.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-MailScanner-From: shadow@delenn.student.utwente.nl Subject: Kernel build fails on -current/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wouter.hummelink@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2005 07:56:05 -0000 I'm having trouble building a kernel after updating my sources to either RELENG_6 or HEAD cvs trees, in both instances my kernel build fails on the same thing, after building the world without a hitch. I removed all IEEE 802.11 drivers from my kernel config, including the ural driver that the build seems to fail on. If anyone has a clue what I'm doing wrong, any help would be appreciated. last bits of output from make buildkernel: linking kernel.debug if_ural.o(.text+0x97): In function `ural_free_tx_list': /usr/src/sys/dev/usb/if_ural.c:596: undefined reference to `ieee80211_free_node'if_ural.o(.text+0x18a): In function `ural_detach': /usr/src/sys/dev/usb/if_ural.c:536: undefined reference to `ieee80211_ifdetach' if_ural.o(.text+0x3b0): In function `ural_rxeof': /usr/src/sys/dev/usb/if_ural.c:878: undefined reference to `ieee80211_find_rxnode' if_ural.o(.text+0x3ca):/usr/src/sys/dev/usb/if_ural.c:881: undefined reference to `ieee80211_input' if_ural.o(.text+0x3d2):/usr/src/sys/dev/usb/if_ural.c:884: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x96c): In function `ural_start': /usr/src/sys/dev/usb/if_ural.c:1309: undefined reference to `ieee80211_find_txnode' if_ural.o(.text+0x9ac):/usr/src/sys/dev/usb/if_ural.c:1316: undefined reference to `ieee80211_encap' if_ural.o(.text+0xb01):/usr/src/sys/dev/usb/if_ural.c:1326: undefined reference to `ieee80211_free_node' if_ural.o(.text+0xb2b):/usr/src/sys/dev/usb/if_ural.c:1206: undefined reference to `ieee80211_crypto_encap' if_ural.o(.text+0xdb4):/usr/src/sys/dev/usb/if_ural.c:1318: undefined reference to `ieee80211_free_node' if_ural.o(.text+0xeda): In function `ural_txeof': /usr/src/sys/dev/usb/if_ural.c:814: undefined reference to `ieee80211_free_node'if_ural.o(.text+0xff8): In function `ural_watchdog': /usr/src/sys/dev/usb/if_ural.c:1358: undefined reference to `ieee80211_watchdog'if_ural.o(.text+0x175f): In function `ural_attach': /usr/src/sys/dev/usb/if_ural.c:481: undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x1781):/usr/src/sys/dev/usb/if_ural.c:488: undefined reference to `ieee80211_ifattach' if_ural.o(.text+0x179a):/usr/src/sys/dev/usb/if_ural.c:494: undefined reference to `ieee80211_media_status' if_ural.o(.text+0x17bb):/usr/src/sys/dev/usb/if_ural.c:494: undefined reference to `ieee80211_media_init' if_ural.o(.text+0x18a0):/usr/src/sys/dev/usb/if_ural.c:459: undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x18d4):/usr/src/sys/dev/usb/if_ural.c:464: undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x190b):/usr/src/sys/dev/usb/if_ural.c:469: undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x1950):/usr/src/sys/dev/usb/if_ural.c:508: undefined reference to `ieee80211_announce' if_ural.o(.text+0x1c2a): In function `ural_set_chan': /usr/src/sys/dev/usb/if_ural.c:1593: undefined reference to `ieee80211_chan2ieee' if_ural.o(.text+0x21e4): In function `ural_task': /usr/src/sys/dev/usb/if_ural.c:744: undefined reference to `ieee80211_beacon_alloc' if_ural.o(.text+0x2c18): In function `ural_media_change': /usr/src/sys/dev/usb/if_ural.c:674: undefined reference to `ieee80211_media_change' if_ural.o(.text+0x2d02): In function `ural_ioctl': /usr/src/sys/dev/usb/if_ural.c:1405: undefined reference to `ieee80211_ioctl' if_ural.o(.text+0x205): In function `ural_next_scan': /usr/src/sys/dev/usb/if_ural.c:699: undefined reference to `ieee80211_next_scan'*** Error code 1 Stop in /usr/obj/usr/src/sys/ARCANITE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. make.conf looks like this: CPUTYPE ?= athlon64 CFLAGS = -O -pipe NOPROFILE = true KERNCONF = ARCANITE CONFIGARGS = -g COPT_FLAGS = -O -pipe USA_RESIDENT = NO # added by use.perl 2005-07-26 09:52:18 PERL_VER=5.6.2 PERL_VERSION=5.6.2 From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 26 21:38:38 2005 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 7723016A41F for ; Tue, 26 Jul 2005 21:38:38 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from anya.eboundary.com (anya.eboundary.com [69.90.127.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ADBB43D49 for ; Tue, 26 Jul 2005 21:38:37 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from epicofti by anya.eboundary.com with local (Exim 4.51 (FreeBSD)) id 1DxXCP-0001HJ-Pw for freebsd-amd64@freebsd.org; Tue, 26 Jul 2005 17:42:53 -0400 Received: from 127.0.0.1 ([127.0.0.1]) (SquirrelMail authenticated user freebsd@epicoftimewasted.com) by www.epicoftimewasted.com with HTTP; Tue, 26 Jul 2005 17:42:53 -0400 (EDT) Message-ID: <2225.127.0.0.1.1122414173.squirrel@www.epicoftimewasted.com> Date: Tue, 26 Jul 2005 17:42:53 -0400 (EDT) From: "Ryan R." To: freebsd-amd64@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - anya.eboundary.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [1018 1019] / [26 6] X-AntiAbuse: Sender Address Domain - epicoftimewasted.com X-Source: X-Source-Args: X-Source-Dir: Subject: "Page fault while in kernel mode" without debugging options 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, 26 Jul 2005 21:38:38 -0000 I'm running 6.0-BETA1, cvsup'd and rebuilt last night. I decided to build a kernel without debugging options (KDB, DDB, GDB, INVARIANTS, INVARIANT_SUPPORT, WITNESS, and WITNESS_SKIPSPIN), but keeping "makeoptions= DEBUG=-g". As soon as I put a little load on the system (make buildworld), I received this panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x678bf5e8b00 fault code = supervisor write, page not present instruction pointer = 0x8:0xffffffff803a2f7a stack pointer = 0x10:0xffffffffa7da1780 frame pointer = 0x10:0x0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 799 (sh) trap number = 12 panic: page fault Here's a chunk of the back trace: This GDB was configured as "amd64-marcel-freebsd". #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:172 #1 0x0000000000000000 in ?? () #2 0xffffffff8025e157 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #3 0xffffffff8025e7d6 in panic (fmt=0xffffff002daefbe0 "@\203-") at /usr/src/sys/kern/kern_shutdown.c:553 #4 0xffffffff803a75ef in trap_fatal (frame=0xffffff002daefbe0, eva=18446742974967546688) at /usr/src/sys/amd64/amd64/trap.c:664 #5 0xffffffff803a790c in trap_pfault (frame=0xffffffffa7da16d0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:580 #6 0xffffffff803a7bc3 in trap (frame= {tf_rdi = -140737488355328, tf_rsi = -140737421235584, tf_rdx = 0, tf_rcx = -1098740149840, tf_r8 = -1098740149840, tf_r9 = -1098469670912, tf_rax = 1, tf_rbx = -1608022720, tf_rbp = 0, tf_r10 = 1026768269655, tf_r11 = 68451217977, tf_r12 = -1098740149920, tf_r13 = 7115676486328, tf_r14 = 140737488355328, tf_r15 = 0, tf_trapno = 12, tf_addr = 7115676486400, tf_flags = -1608010096, tf_err = 2, tf_rip = -2143670406, tf_cs = 8, tf_rflags = 66118, tf_rsp = -1478879344, tf_ss = 0}) at /usr/src/sys/amd64/amd64/trap.c:359 #7 0xffffffff803979cb in calltrap () at /usr/src/sys/amd64/amd64/exception.S:170 #8 0xffff800000000000 in ?? () #9 0xffff800004002a80 in ?? () #10 0x0000000000000000 in ?? () #11 0xffffff002dfbd1b0 in ?? () #12 0xffffff002dfbd1b0 in ?? () #13 0xffffff003e1b0000 in ?? () #14 0x0000000000000001 in ?? () #15 0xffffffffa0278540 in ?? () #16 0x0000000000000000 in ?? () #17 0x000000ef10287157 in ?? () #18 0x0000000ff002b239 in ?? () #19 0xffffff002dfbd160 in ?? () #20 0x00000678bf5e8ab8 in ?? () #21 0x0000800000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x000000000000000c in ?? () #24 0x00000678bf5e8b00 in ?? () #25 0xffffffffa027b690 in ?? () #26 0x0000000000000002 in ?? () #27 0xffffffff803a2f7a in pmap_remove_pages (pmap=0xffffff002dfbd160, sva=0, eva=140737488355328) at /usr/src/sys/amd64/amd64/pmap.c:2529 #28 0xffffff002ddf8340 in ?? () #29 0x0000000000000004 in ?? () #30 0x0000000000000002 in ?? () #31 0xffffff002daefbe0 in ?? () #32 0xffffffff80244ca2 in exit1 (td=0xffffff0000a1a100, rv=771477504) at vm_map.h:252 #33 0xffffffff80262f68 in sigexit (td=0xffffff002daefbe0, sig=2) at /usr/src/sys/kern/kern_sig.c:2439 #34 0xffffffff80263b5c in postsig (sig=2) at /usr/src/sys/kern/kern_sig.c:2320 #35 0xffffffff80285597 in ast (framep=0xffffffffa7da1c40) at /usr/src/sys/kern/subr_trap.c:266 #36 0xffffffff80398159 in doreti_ast () at /usr/src/sys/amd64/amd64/exception.S:391 (kgdb) list *0x00000678bf5e8b00 No source file for address 0x678bf5e8b00. Running the same kernel with the debugging options enabled runs flawlessly. If it's needed, I'll post my kernel config, or a diff between it and GENERIC. Also, no fancy CFLAGS or anything of the sort were used. For reference, the CPU is an Athlon 64 socket 939 rev. E4. The motherboard is a DFI LanParty UT SLI-DR nForce4 (I know... but I game on it from time to time too). Any suggestions? Ryan From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 26 22:35:49 2005 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 9FBFD16A420; Tue, 26 Jul 2005 22:35:49 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C9A743D49; Tue, 26 Jul 2005 22:35:48 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j6QMc4T4065413; Tue, 26 Jul 2005 18:38:05 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Juergen Lock Date: Tue, 26 Jul 2005 18:35:29 -0400 User-Agent: KMail/1.6.2 References: <20050725222608.A42815@saturn.kn-bremen.de> <200507251825.51540.jkim@FreeBSD.org> <20050726014207.A48961@saturn.kn-bremen.de> In-Reply-To: <20050726014207.A48961@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200507261835.32168.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/993/Tue Jul 26 03:28:36 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: need help with kqemu 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, 26 Jul 2005 22:35:49 -0000 On Monday 25 July 2005 07:42 pm, Juergen Lock wrote: > On Mon, Jul 25, 2005 at 06:25:50PM -0400, Jung-uk Kim wrote: > > Try the attachment. It seems to build and work on amd64 now, > > including kqemu. > > Hey, nice! So there wasnt actually that much wrong... One > question: Does this also work on 4.x? > > Here's my version: (I disabled a kqemu_vmalloc_to_phys(%p) printf > and added back use of the system cc for kqemu) BTW, I think KQEMU for amd64 is still unstable. VM crashes with error message like this: kqemu: aborting: Unexpected exception 0x0d in monitor space CS:EIP=f180:ffff900000001729 With `-no-kqemu' option, everything's fine. Actually somebody in Linux world also reported somthing similar. In his case, it was just hanging VM, though. Thanks, Jung-uk Kim From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 01:41:43 2005 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 4735E16A41F; Wed, 27 Jul 2005 01:41:43 +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 5FD1B43D46; Wed, 27 Jul 2005 01:41:42 +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.3/8.13.3) with ESMTP id j6R1f4D5017480; Tue, 26 Jul 2005 21:41:04 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6R1ffoU050220; Tue, 26 Jul 2005 21:41:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EECD47304D; Tue, 26 Jul 2005 21:41:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050727014140.EECD47304D@freebsd-current.sentex.ca> Date: Tue, 26 Jul 2005 21:41:40 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_6 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, 27 Jul 2005 01:41:43 -0000 TB --- 2005-07-27 00:48:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-27 00:48:57 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2005-07-27 00:48:57 - cleaning the object tree TB --- 2005-07-27 00:49:31 - checking out the source tree TB --- 2005-07-27 00:49:31 - cd /home/tinderbox/RELENG_6/amd64/amd64 TB --- 2005-07-27 00:49:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2005-07-27 00:57:51 - building world (CFLAGS=-O -pipe) TB --- 2005-07-27 00:57:51 - cd /home/tinderbox/RELENG_6/amd64/amd64/src TB --- 2005-07-27 00:57:51 - /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 [...] gzip -cn /tinderbox/RELENG_6/amd64/amd64/src/share/man/man9/VFS_MOUNT.9 > VFS_MOUNT.9.gz gzip -cn /tinderbox/RELENG_6/amd64/amd64/src/share/man/man9/vfs_mount.9 > vfs_mount.9.gz gzip -cn /tinderbox/RELENG_6/amd64/amd64/src/share/man/man9/vfs_mountedon.9 > vfs_mountedon.9.gz gzip -cn /tinderbox/RELENG_6/amd64/amd64/src/share/man/man9/VFS_QUOTACTL.9 > VFS_QUOTACTL.9.gz gzip -cn /tinderbox/RELENG_6/amd64/amd64/src/share/man/man9/VFS_ROOT.9 > VFS_ROOT.9.gz gzip -cn /tinderbox/RELENG_6/amd64/amd64/src/share/man/man9/vfs_rootmountalloc.9 > vfs_rootmountalloc.9.gz gzip -cn /tinderbox/RELENG_6/amd64/amd64/src/share/man/man9/VFS_SET.9 > VFS_SET.9.gz make: don't know how to make VFS_START.9. Stop *** Error code 2 Stop in /tinderbox/RELENG_6/amd64/amd64/src/share/man. *** Error code 1 Stop in /tinderbox/RELENG_6/amd64/amd64/src/share. *** Error code 1 Stop in /tinderbox/RELENG_6/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/RELENG_6/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/RELENG_6/amd64/amd64/src. TB --- 2005-07-27 01:41:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-27 01:41:40 - ERROR: failed to build world TB --- 2005-07-27 01:41:40 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 04:33:30 2005 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 4AB5F16A41F for ; Wed, 27 Jul 2005 04:33:30 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A0E543D46 for ; Wed, 27 Jul 2005 04:33:30 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id A01C5F1986; Tue, 26 Jul 2005 21:33:29 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18780-01; Tue, 26 Jul 2005 21:33:28 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 7B408F1897; Tue, 26 Jul 2005 21:33:28 -0700 (PDT) From: Sean McNeil To: wouter.hummelink@gmail.com In-Reply-To: <1122364455.59736.12.camel@arcanite.student.utwente.nl> References: <1122364455.59736.12.camel@arcanite.student.utwente.nl> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Tue, 26 Jul 2005 21:33:28 -0700 Message-Id: <1122438808.18783.0.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Cc: freebsd-amd64@freebsd.org Subject: Re: Kernel build fails on -current/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 04:33:30 -0000 On Tue, 2005-07-26 at 09:54 +0200, Wouter Hummelink wrote: > I'm having trouble building a kernel after updating my sources to either > RELENG_6 or HEAD cvs trees, in both instances my kernel build fails on > the same thing, after building the world without a hitch. > I removed all IEEE 802.11 drivers from my kernel config, including the > ural driver that the build seems to fail on. > > If anyone has a clue what I'm doing wrong, any help would be > appreciated. I ran into this same problem. I added the "device wlan" to my kernel config and that was cleared up. Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 05:36:50 2005 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 C608816A41F for ; Wed, 27 Jul 2005 05:36:50 +0000 (GMT) (envelope-from shadow@netherite.student.utwente.nl) Received: from netlx050.vf.utwente.nl (netlx050.vf.utwente.nl [192.87.17.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 371DF43D46 for ; Wed, 27 Jul 2005 05:36:50 +0000 (GMT) (envelope-from shadow@netherite.student.utwente.nl) Received: from arcanite.student.utwente.nl (arcanite.student.utwente.nl [130.89.166.68]) by netlx050.vf.utwente.nl (8.11.7/HKD) with ESMTP id j6R5ahOC008110; Wed, 27 Jul 2005 07:36:48 +0200 From: Wouter Hummelink To: sean@mcneil.com In-Reply-To: <1122438808.18783.0.camel@server.mcneil.com> References: <1122364455.59736.12.camel@arcanite.student.utwente.nl> <1122438808.18783.0.camel@server.mcneil.com> Content-Type: text/plain Date: Wed, 27 Jul 2005 07:34:53 +0200 Message-Id: <1122442493.22808.1.camel@arcanite.student.utwente.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-MailScanner-From: shadow@delenn.student.utwente.nl Cc: freebsd-amd64@freebsd.org Subject: Re: Kernel build fails on -current/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wouter.hummelink@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2005 05:36:50 -0000 On Tue, 2005-07-26 at 21:33 -0700, Sean McNeil wrote: > On Tue, 2005-07-26 at 09:54 +0200, Wouter Hummelink wrote: > > I'm having trouble building a kernel after updating my sources to either > > RELENG_6 or HEAD cvs trees, in both instances my kernel build fails on > > the same thing, after building the world without a hitch. > > I removed all IEEE 802.11 drivers from my kernel config, including the > > ural driver that the build seems to fail on. > > > > If anyone has a clue what I'm doing wrong, any help would be > > appreciated. > > I ran into this same problem. I added the "device wlan" to my kernel > config and that was cleared up. > > Cheers, > Sean > > That worked thanks. > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 06:43:37 2005 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 A020B16A41F for ; Wed, 27 Jul 2005 06:43:37 +0000 (GMT) (envelope-from chat95@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1508243D58 for ; Wed, 27 Jul 2005 06:43:36 +0000 (GMT) (envelope-from chat95@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout06/MantshX 4.0) with ESMTP id j6R6ha7O002285 for ; Tue, 26 Jul 2005 23:43:36 -0700 (PDT) Received: from localhost ([133.11.172.102]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j6R6hWGr027815 for ; Tue, 26 Jul 2005 23:43:35 -0700 (PDT) Date: Wed, 27 Jul 2005 15:43:29 +0900 (JST) Message-Id: <20050727.154329.71086249.chat95@mac.com> To: freebsd-amd64@freebsd.org From: NAKATA Maho Organization: private X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Tyan S2885 Thunder K8W lockups 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, 27 Jul 2005 06:43:37 -0000 Hello sometimes my opteron box locks up recently, it seems that there are some discussion about this issue on the list. o Opteron 250x2 o Tyan S2885 K8W on board SATA/IEEE1394/USB2/GbE/AC97 o Total 10G of ram (512Mx4+2Gx4) : tested with memtest+ 1.6 o BIOS 06/10/05 TYAN Thunder K8W (S2885) V2.05 o FreeBSD 5.4-RELEASE How to lockup: # dd if=/dev/mem of=/dev/null bs=1024k about 50 seconds later it lockups. 100% reproducible. * Both Optimal/Failsafe setting in BIOS * Both MTRR Mapping Continuous/Disabled * set hw.physmem="4G" doesn't help workaround: on board GbE (bge0) and SATA disabled. any hints or comments? -- NAKATA, Maho (maho@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 08:13:09 2005 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 F2CD216A41F for ; Wed, 27 Jul 2005 08:13:08 +0000 (GMT) (envelope-from chat95@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id A983F43D45 for ; Wed, 27 Jul 2005 08:13:08 +0000 (GMT) (envelope-from chat95@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout01/MantshX 4.0) with ESMTP id j6R8D86P002204 for ; Wed, 27 Jul 2005 01:13:08 -0700 (PDT) Received: from localhost ([133.11.172.102]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j6R8D4er026160 for ; Wed, 27 Jul 2005 01:13:07 -0700 (PDT) Date: Wed, 27 Jul 2005 17:13:03 +0900 (JST) Message-Id: <20050727.171303.78703474.chat95@mac.com> To: freebsd-amd64@freebsd.org From: NAKATA Maho In-Reply-To: <20050727.154329.71086249.chat95@mac.com> References: <20050727.154329.71086249.chat95@mac.com> Organization: private X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Tyan S2885 Thunder K8W lockups 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, 27 Jul 2005 08:13:09 -0000 In Message-ID: <20050727.154329.71086249.chat95@mac.com> NAKATA Maho wrote: > Hello > sometimes my opteron box locks up recently, > it seems that there are some discussion about this issue > on the list. > > o Opteron 250x2 > o Tyan S2885 K8W > on board SATA/IEEE1394/USB2/GbE/AC97 > o Total 10G of ram (512Mx4+2Gx4) : tested with memtest+ 1.6 > o BIOS 06/10/05 TYAN Thunder K8W (S2885) V2.05 > o FreeBSD 5.4-RELEASE > > How to lockup: > # dd if=/dev/mem of=/dev/null bs=1024k > about 50 seconds later it lockups. 100% reproducible. > * Both Optimal/Failsafe setting in BIOS > * Both MTRR Mapping Continuous/Disabled > * set hw.physmem="4G" doesn't help > > workaround: > on board GbE (bge0) and SATA disabled. dmseg is following: 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 5.4-RELEASE-p5 #0: Wed Jul 27 16:56:23 JST 2005 maho@ligeti.private.org:/usr/src/sys/amd64/compile/MAHO Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 250 (2390.29-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 10737418240 (10240 MB) avail memory = 10014359552 (9550 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 6.0 on pci0 pci1: on pcib1 ohci0: mem 0xfd7fe000-0xfd7fefff irq 19 at device 0.0 on pci1 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfd7ff000-0xfd7fffff irq 19 at device 0.1 on pci1 usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pci1: at device 12.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pci0: at device 7.5 (no driver attached) pcib2: at device 10.0 on pci0 pci2: on pcib2 bge0: mem 0xfd8f0000-0xfd8fffff irq 24 at device 9.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:e0:81:27:a0:33 pci0: at device 10.1 (no driver attached) pcib3: at device 11.0 on pci0 pci3: on pcib3 pci0: at device 11.1 (no driver attached) pcib4: on acpi0 pci4: on pcib4 pcib5: at device 1.0 on pci4 pci5: on pcib5 pci5: at device 0.0 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xc8fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad0: 117800MB [239340/16/63] at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 SMP: AP CPU #1 Launched! cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/ad0s1a From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 08:14:05 2005 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 DCE4616A41F for ; Wed, 27 Jul 2005 08:14:05 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from peedub.jennejohn.org (J91ad.j.pppool.de [85.74.145.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F2A843D48 for ; Wed, 27 Jul 2005 08:14:04 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.4/8.11.6) with ESMTP id j6R8E2Mc006780; Wed, 27 Jul 2005 10:14:03 +0200 (CEST) (envelope-from garyj@jennejohn.org) Message-Id: <200507270814.j6R8E2Mc006780@peedub.jennejohn.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: NAKATA Maho In-Reply-To: Message from NAKATA Maho of "Wed, 27 Jul 2005 15:43:29 +0900." <20050727.154329.71086249.chat95@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jul 2005 10:14:02 +0200 From: Gary Jennejohn Cc: freebsd-amd64@freebsd.org Subject: Re: Tyan S2885 Thunder K8W lockups 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, 27 Jul 2005 08:14:06 -0000 NAKATA Maho writes: > How to lockup: > # dd if=/dev/mem of=/dev/null bs=1024k > about 50 seconds later it lockups. 100% reproducible. > * Both Optimal/Failsafe setting in BIOS > * Both MTRR Mapping Continuous/Disabled > * set hw.physmem="4G" doesn't help > > workaround: > on board GbE (bge0) and SATA disabled. > > any hints or comments? > I could be wrong, but it seems to me that you might be accessing HW address space with resulting undesirable side effects since you're trying to read the entire range which /dev/mem maps. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 08:22:58 2005 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 885F316A41F for ; Wed, 27 Jul 2005 08:22:58 +0000 (GMT) (envelope-from chat95@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ADFD43D49 for ; Wed, 27 Jul 2005 08:22:58 +0000 (GMT) (envelope-from chat95@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout16/MantshX 4.0) with ESMTP id j6R8Mv8Y015041 for ; Wed, 27 Jul 2005 01:22:57 -0700 (PDT) Received: from localhost ([133.11.172.102]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j6R8MsAD028078 for ; Wed, 27 Jul 2005 01:22:57 -0700 (PDT) Date: Wed, 27 Jul 2005 17:22:53 +0900 (JST) Message-Id: <20050727.172253.112627901.chat95@mac.com> To: freebsd-amd64@freebsd.org From: NAKATA Maho In-Reply-To: <20050727.171303.78703474.chat95@mac.com> References: <20050727.154329.71086249.chat95@mac.com> <20050727.171303.78703474.chat95@mac.com> Organization: private X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: iommu flushing problem? (Re: Tyan S2885 Thunder K8W lockups) 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, 27 Jul 2005 08:22:58 -0000 I found a simular issue http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/0937.html iommu flushing problem? -- NAKATA, Maho (maho@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 10:55:10 2005 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 28EEE16A41F for ; Wed, 27 Jul 2005 10:55:10 +0000 (GMT) (envelope-from phil@virtek.com) Received: from newmail.allsopp.com (82-70-95-149.dsl.in-addr.zen.co.uk [82.70.95.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F40A43D48 for ; Wed, 27 Jul 2005 10:55:08 +0000 (GMT) (envelope-from phil@virtek.com) Received: from [82.70.95.157] by newmail.allsopp.com (GMS 8.00.3078/NT0935.01.cb74d8fe) with ESMTP id pggxgaaa for freebsd-amd64@freebsd.org; Wed, 2 Apr 2003 11:50:37 +0100 Message-Id: <5.1.1.6.0.20050727120543.054c5c08@127.0.0.1> X-Sender: mail.allsopp.com&phil@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 27 Jul 2005 12:11:10 +0100 To: freebsd-amd64@freebsd.org From: Phil Allsopp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: Evaluation version of GMS at newmail.allsopp.com Subject: MultiCPU opteron Kernel configuration. 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, 27 Jul 2005 10:55:10 -0000 Hi all, I have a Tyan Tiger K8S PRO twin opteron board and want to run FreeBSD 5.4 in twin CPU mode. However, when I re-configure the kernel, I add options SMP and rebuild everything and see no errors, however I see no multiple CPU usage after rebuilding, installing and rebooting the machine. On older versions of FreeBSD, I used to add options APIC_IO to the kernel conf file to get a multiple CPU system running, but 5.4 AMD version of FreeBSD doesn't seem to recognise this. Information seems to be thin on the ground about dual CPU's under FreeBSD 5.4 AMD 64 and wondered if anyone could point me the right direction. Thanks in advance. Phil. From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 13:44:04 2005 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 CC02416A41F for ; Wed, 27 Jul 2005 13:44:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FBE343D48 for ; Wed, 27 Jul 2005 13:44:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 27 Jul 2005 09:58:30 -0400 From: John Baldwin To: freebsd-amd64@freebsd.org Date: Wed, 27 Jul 2005 09:44:16 -0400 User-Agent: KMail/1.8 References: <5.1.1.6.0.20050727120543.054c5c08@127.0.0.1> In-Reply-To: <5.1.1.6.0.20050727120543.054c5c08@127.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507270944.18052.jhb@FreeBSD.org> Cc: Phil Allsopp Subject: Re: MultiCPU opteron Kernel configuration. 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, 27 Jul 2005 13:44:04 -0000 On Wednesday 27 July 2005 07:11 am, Phil Allsopp wrote: > Hi all, > > I have a Tyan Tiger K8S PRO twin opteron board and want to run FreeBSD 5.4 > in twin CPU mode. However, when I re-configure the kernel, I add > > options SMP > > and rebuild everything and see no errors, however I see no multiple CPU > usage after rebuilding, installing and rebooting the machine. > > On older versions of FreeBSD, I used to add > > options APIC_IO > > to the kernel conf file to get a multiple CPU system running, but 5.4 AMD > version of FreeBSD doesn't seem to recognise this. > > Information seems to be thin on the ground about dual CPU's under > FreeBSD 5.4 AMD 64 and wondered if anyone could point me the right > direction. > > Thanks in advance. Use 'device apic' rather than 'options APIC_IO' -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Wed Jul 27 17:27:31 2005 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 D5FCD16A41F for ; Wed, 27 Jul 2005 17:27:31 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from pigeon.infotechfl.com (mailrelay.infotechfl.com [209.251.147.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F84A43D88 for ; Wed, 27 Jul 2005 17:27:30 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from [172.20.0.75] (gmulder.infotechfl.com [172.20.0.75]) by pigeon.infotechfl.com (8.11.6/8.11.6) with ESMTP id j6RHRT327949; Wed, 27 Jul 2005 13:27:30 -0400 Message-ID: <42E7C454.8080404@infotechfl.com> Date: Wed, 27 Jul 2005 13:28:52 -0400 From: Gary Mu1der User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <200507270814.j6R8E2Mc006780@peedub.jennejohn.org> In-Reply-To: <200507270814.j6R8E2Mc006780@peedub.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Tyan S2885 Thunder K8W lockups 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, 27 Jul 2005 17:27:31 -0000 Gary Jennejohn wrote: > NAKATA Maho writes: > >>How to lockup: >># dd if=/dev/mem of=/dev/null bs=1024k >>about 50 seconds later it lockups. 100% reproducible. >>* Both Optimal/Failsafe setting in BIOS >>* Both MTRR Mapping Continuous/Disabled >>* set hw.physmem="4G" doesn't help >> >>workaround: >>on board GbE (bge0) and SATA disabled. >> >>any hints or comments? >> > > > I could be wrong, but it seems to me that you might be accessing HW > address space with resulting undesirable side effects since you're > trying to read the entire range which /dev/mem maps. I can confirm I tried the same thing and got the same result with similar hardware. It was also pointed out to me that reading indiscriminately from /dev/mem may screw up memory mapped I/O and likely cause a crash. Gary From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 00:22:19 2005 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 2639F16A420; Thu, 28 Jul 2005 00:22:19 +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 5EAD743D46; Thu, 28 Jul 2005 00:22:18 +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.3/8.13.3) with ESMTP id j6S0Ldl0093787; Wed, 27 Jul 2005 20:21:39 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6S0MHQ4014805; Wed, 27 Jul 2005 20:22:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 48B517304D; Wed, 27 Jul 2005 20:22:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728002216.48B517304D@freebsd-current.sentex.ca> Date: Wed, 27 Jul 2005 20:22:16 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 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: Thu, 28 Jul 2005 00:22:19 -0000 TB --- 2005-07-27 23:11:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-27 23:11:45 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-07-27 23:11:45 - cleaning the object tree TB --- 2005-07-27 23:12:17 - checking out the source tree TB --- 2005-07-27 23:12:17 - cd /home/tinderbox/HEAD/amd64/amd64 TB --- 2005-07-27 23:12:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-07-27 23:18:02 - building world (CFLAGS=-O2 -pipe) TB --- 2005-07-27 23:18:02 - cd /home/tinderbox/HEAD/amd64/amd64/src TB --- 2005-07-27 23:18:02 - /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 [...] cd /tinderbox/HEAD/amd64/amd64/src/include/../sys; sh /tinderbox/HEAD/amd64/amd64/src/tools/install.sh -C -o root -g wheel -m 444 geom/concat/*.h /home/tinderbox/HEAD/amd64/amd64/obj/amd64/tinderbox/HEAD/amd64/amd64/src/lib32/usr/include/geom/concat cd /tinderbox/HEAD/amd64/amd64/src/include/../sys; sh /tinderbox/HEAD/amd64/amd64/src/tools/install.sh -C -o root -g wheel -m 444 geom/eli/*.h /home/tinderbox/HEAD/amd64/amd64/obj/amd64/tinderbox/HEAD/amd64/amd64/src/lib32/usr/include/geom/eli install: wrong number or types of arguments usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-v] [-g group] [-m mode] [-o owner] directory ... *** Error code 64 Stop in /tinderbox/HEAD/amd64/amd64/src/include. *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/src/include. *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/HEAD/amd64/amd64/src. TB --- 2005-07-28 00:22:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-28 00:22:15 - ERROR: failed to build world TB --- 2005-07-28 00:22:15 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 00:51:34 2005 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 7ADFF16A41F for ; Thu, 28 Jul 2005 00:51:34 +0000 (GMT) (envelope-from chat95@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 431BD43D49 for ; Thu, 28 Jul 2005 00:51:34 +0000 (GMT) (envelope-from chat95@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout06/MantshX 4.0) with ESMTP id j6S0pXWL017597; Wed, 27 Jul 2005 17:51:33 -0700 (PDT) Received: from localhost ([133.11.172.102]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j6S0pTaI002639; Wed, 27 Jul 2005 17:51:32 -0700 (PDT) Date: Thu, 28 Jul 2005 09:51:28 +0900 (JST) Message-Id: <20050728.095128.59652907.chat95@mac.com> To: gmulder@infotechfl.com From: NAKATA Maho In-Reply-To: <42E7C454.8080404@infotechfl.com> References: <200507270814.j6R8E2Mc006780@peedub.jennejohn.org> <42E7C454.8080404@infotechfl.com> Organization: private X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: Tyan S2885 Thunder K8W lockups 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, 28 Jul 2005 00:51:34 -0000 In Message-ID: <42E7C454.8080404@infotechfl.com> Gary Mu1der wrote: > >>How to lockup: > >># dd if=/dev/mem of=/dev/null bs=1024k > >>about 50 seconds later it lockups. 100% reproducible. > >>* Both Optimal/Failsafe setting in BIOS > >>* Both MTRR Mapping Continuous/Disabled > >>* set hw.physmem="4G" doesn't help > >> > >>workaround: > >>on board GbE (bge0) and SATA disabled. > >>any hints or comments? > > address space with resulting undesirable side effects since you're > > trying to read the entire range which /dev/mem maps. > > I can confirm I tried the same thing and got the same result with > similar hardware. > > It was also pointed out to me that reading indiscriminately from > /dev/mem may screw up memory mapped I/O and likely cause a crash. this is a reproducible form of my problem. if I run some program which I use for my research, after 1 or 2 days(it took 60 or 40hours to complete), my opteron box locks up. Two jobs are running using mpich, and one process eats 1G of memory and the other process eats 3G of memory. so I currently disable both (GbE and SATA) of them and running to see the stablity of this box. thanks! -- NAKATA, Maho (maho@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 08:31:55 2005 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 B19F116A41F for ; Thu, 28 Jul 2005 08:31:55 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B2CE43D46 for ; Thu, 28 Jul 2005 08:31:55 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 69E799789A; Thu, 28 Jul 2005 01:31:51 -0700 (PDT) Message-Id: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 28 Jul 2005 01:31:52 -0700 To: freebsd-amd64@freebsd.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1122564712==_" Subject: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 08:31:55 -0000 --=====================_1122564712==_ Content-Type: text/plain; charset="us-ascii" Freebsd-AMD64 list: I recently completed benchmarking an evaluation server provided to us by our hardware vendor in order to see if switching our cluster from Xeon based machines to AMD based machines was worth while/cost effective The machine provided was a Dual Opteron 246 using the Tyan S2881 motherboard. It had 4GB or ram and included a single SATA hard drive. I initially loaded FreeBSD 5.4 AMD64 on the machine, recompiled the kernel, etc. and applied all the normal tweaks to apache, PHP, etc. The machine, while faster than our single 2.4 Ghz Xeon's, wasn't all that much faster (maybe only 10 to 15 percent). After speaking with AMD and doing further benchmarks, I was about to give up on AMD and return the machine. However, at the last minute, an engineer from AMD suggested that perhaps loading the 32 bit version of FreeBSD (aka i386) might improve performance, since it was possible that the overhead from 64 bit pointers was causing the machine to run slower than expected. He also explained that the AMD should be running about 3 to 4 times faster than the single Xeon. While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine and after applying the exact same configuration to the OS, Apache, PHP and MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 bit to 32 bit caused the machine to double in speed. The results are attached in an Excel spreadsheet. So the exact same machine, running the identical configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) In speaking with one person off the list here, I was told that the FreeBSD AMD64 branch has actually been cleaned up substantially over the i386 code. So naturally I was expecting much better performance from a 64 bit machine running the AMD64 code than the "older" i386 code. I had also originally expected that since this branch [the AMD64 branch] was specifically built around the AMD CPU's, that it should run the best (and thus the fastest) on the AMD opteron CPU's. However, just the contrary turned out to be the case in benchmarking. I'm wondering if anyone has any comments or thoughts on this? The attached benchmarks show transactions per second across localhost using Apache AB on the same machine. The first tests are with plain text files from 64 bytes to 50K in size. The next group is using a small and medium size PHP program. The final set relate to MySQL inserts, selects and updates. As you can see from the data, the exact same machine runs about twice as fast just by switching the OS from AMD64 to i386. But why? The only answer I have so far as to why this may be the case is that perhaps i386 uses 32 bit pointers which the CPU(s) can handle faster (thus less overhead for the CPU). But it still seems odd to me that if FreeBSD AMD64 is written specifically for the 64 bit CPU, why doesn't the machine perform better when running it? I'm also wondering if there is a compiler switch on AMD64 that could be used (perhaps in /etc/make.conf or something) that would force the AMD64 version to run in 32 bit mode only - since that would be an interesting comparison as well. I welcome any/all comments, suggestions, insight. Thanks. Ray --=====================_1122564712==_ Content-Type: application/octet-stream; name="bench1.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bench1.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGQAAAAAAAAAA EAAA/v///wAAAAD+////AAAAABgAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAK8YzQfBQAAABgEAAOEAAgCwBMEAAgAAAOIAAABcAHAAAwAAUmF5ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQYA AQACAAMAnAACAA4AGQACAAAAEgACAAAAEwACAAAArwECAAAAvAECAAAAPQASAAYYdQM0REQ0OAAA AAAAAQBYAkAAAgAAAI0AAgAAACIAAgAAAA4AAgABALcBAgAAANoAAgAAADEAGgDIAAAA/3+QAQAA AAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+QAQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+Q AQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+QAQAAAAAAAAUBQQByAGkAYQBsAB4EHAAFABcA ACIkIiMsIyMwXyk7XCgiJCIjLCMjMFwpHgQhAAYAHAAAIiQiIywjIzBfKTtbUmVkXVwoIiQiIywj IzBcKR4EIgAHAB0AACIkIiMsIyMwLjAwXyk7XCgiJCIjLCMjMC4wMFwpHgQnAAgAIgAAIiQiIywj IzAuMDBfKTtbUmVkXVwoIiQiIywjIzAuMDBcKR4ENwAqADIAAF8oIiQiKiAjLCMjMF8pO18oIiQi KiBcKCMsIyMwXCk7XygiJCIqICItIl8pO18oQF8pHgQuACkAKQAAXygqICMsIyMwXyk7XygqIFwo IywjIzBcKTtfKCogIi0iXyk7XyhAXykeBD8ALAA6AABfKCIkIiogIywjIzAuMDBfKTtfKCIkIiog XCgjLCMjMC4wMFwpO18oIiQiKiAiLSI/P18pO18oQF8pHgQ2ACsAMQAAXygqICMsIyMwLjAwXyk7 XygqIFwoIywjIzAuMDBcKTtfKCogIi0iPz9fKTtfKEBfKeAAFAAAAAAA9f8gAAAAAAAAAAAAAADA IOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAACAAAA 9f8gAAD0AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAA AAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAA FAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8g AAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAA AADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAA AAAAAQAgAAAAAAAAAAAAAADAIOAAFAABACsA9f8gAAD4AAAAAAAAAADAIOAAFAABACkA9f8gAAD4 AAAAAAAAAADAIOAAFAABACwA9f8gAAD4AAAAAAAAAADAIOAAFAABACoA9f8gAAD4AAAAAAAAAADA IOAAFAABAAkA9f8gAAD4AAAAAAAAAADAIOAAFAAAAAAAAQAiAAAQAAAAAAAAAADAIOAAFAAAAAMA AQAiAAAUAAAAAAAAAADAIJMCBAAQgAP/kwIEABGABv+TAgQAEoAE/5MCBAATgAf/kwIEAACAAP+T AgQAFIAF/2ABAgAAAIUADgCPBwAAAAAGAFNoZWV0MYUADgBgCwAAAAAGAFNoZWV0MoUADgBnDAAA AAAGAFNoZWV0M4wABAABAAEAwQEIAMEBAABgaQEA/AC5ARkAAAAYAAAABwAANjQgYnl0ZQIAADFL AgAANUsDAAA1MEsFAABTbWFsbAYAAE1lZGl1bQMAAFBIUCEAAER1YWwgT3B0ZXJvbiB3LyBGcmVl QlNEIDUuNCBBTUQ2NCAAAER1YWwgT3B0ZXJvbiB3LyBGcmVlQlNEIDUuNCBpMzg2CQAAMTAwSyBy b3dzDAAATXlTUUwgSW5zZXJ0DQAAUmFuZG9tIFNlbGVjdAwAADEwMEsgcmVjb3Jkcw0AAFJhbmRv bSBVcGRhdGULAAAxODAgc2Vjb25kcwsAADE0MyBzZWNvbmRzCgAAMjkgc2Vjb25kcwoAADIwIHNl Y29uZHMLAAAxMEsgcmVjb3JkcwoAADEzIHNlY29uZHMJAAA3IHNlY29uZHM0AABJZGVudGljYWwg bWFjaGluZSBydW5uaW5nIEZyZWVCU0QgNS40IEFNRDY0IHZzLiBpMzg2HgAAQmVuY2htYXJrcyBy dW4gdXNpbmcgQXBhY2hlIEFCNwAARGF0YSBpbiB0cmFuc2FjdGlvbnMgcGVyIHNlY29uZHMgdW5s ZXNzIG90aGVyd2lzZSBub3RlZP8AGgAIALwFAAAMAAAAEQYAAGEAAACaBgAA6gAAAAoAAAAJCBAA AAYQAK8YzQfBQAAABgEAAAsCFAAAAAAAAQAAAA8AAABLCAAAEQsAAA0AAgABAAwAAgBkAA8AAgAB ABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUC BAAAAP8AgQACAMEEFAAAABUAAACDAAIAAACEAAIAAAChACIAAAD/AAEAAQABAAQAAAAAAAAAAAAA AOA/AAAAAAAA4D8AAFUAAgAIAH0ADAAEAAkAJAkVAAAABAB9AAwACgAMALYPFQACAAQAfQAMAA0A DQC2DRUAAgAEAH0ADAAOAA8AJAkVAAAABAAAAg4AAQAAAA8AAAAAABAAAAAIAhAAAQAAAA0A/wAA AAAAAAEPAAgCEAACAAAADQD/AAAAAAAAAQ8ACAIQAAMAAAANAP8AAAAAAAABDwAIAhAABAAAAA0A /wAAAAAAAAEPAAgCEAAGAAAADQD/AAAAAAAAAQ8ACAIQAAoAAAANAP8AAAAAAAABDwAIAhAADAAA AA0A/wAAAAAAAAEPAAgCEAAOAAAADQD/AAAAAAAAAQ8A/QAKAAEABAAVAAAAAAD9AAoAAQAFABUA AQAAAP0ACgABAAYAFQACAAAA/QAKAAEABwAVAAMAAAD9AAoAAQAIABUABAAAAP0ACgABAAkAFQAF AAAA/QAKAAEACgAVAAoAAAD9AAoAAQALABUACwAAAP0ACgABAAwAFQANAAAAAQIGAAIABwAWAP0A CgACAAgAFQAGAAAA/QAKAAIACQAVAAYAAAD9AAoAAgAKABUACQAAAP0ACgACAAsAFQAMAAAA/QAK AAIADAAVABIAAAABAgYAAwAHABYA/QAKAAQAAAAPAAcAAAC9ACoABAAEABUAAPCkQBUAANijQBUA AMahQBUAAHCMQBUAAECfQBUAAAyXQAkA/QAKAAQACgAVAA4AAAD9AAoABAALABUAEAAAAP0ACgAE AAwAFQATAAAA/QAKAAYAAAAPAAgAAAC9ACoABgAEABUAAOi8QBUAAO67QBUAAO23QBUAAOyjQBUA AP6wQBUAACyqQAkA/QAKAAYACgAVAA8AAAD9AAoABgALABUAEQAAAP0ACgAGAAwAFQAUAAAA/QAK AAoAAAAPABUAAAD9AAoADAAAAA8AFgAAAP0ACgAOAAAADwAXAAAA1wAUAG4CAACMAH4AUAAKAGYA ZgAOAA4APgISALYGAAAAAEAAAAAAAAAAAAAAAB0ADwADDgAAAAAAAQAOAA4AAADvAAYAAAA3AAAA CgAAAAkIEAAABhAArxjNB8FAAAAGAQAACwIQAAAAAAAAAAAAAAAAABgMAAANAAIAAQAMAAIAZAAP AAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAA AAAlAgQAAAD/AIEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAA/wABAAEAAQAEAAAAAAAA AAAAAADgPwAAAAAAAOA/FQBVAAIACAAAAg4AAAAAAAAAAAAAAAAAAAA+AhIAtgAAAAAAQAAAAAAA AAAAAAAAHQAPAAMAAAAAAAABAAAAAAAAAO8ABgAAADcAAAAKAAAACQgQAAAGEACvGM0HwUAAAAYB AAALAhAAAAAAAAAAAAAAAAAAHw0AAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQ P18AAgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEEFAAAABUA AACDAAIAAACEAAIAAAChACIAAAD/AAEAAQABAAQAAAAAAAAAAAAAAOA/AAAAAAAA4D8VAFUAAgAI AAACDgAAAAAAAAAAAAAAAAAAAD4CEgC2AAAAAABAAAAAAAAAAAAAAAAdAA8AAwAAAAAAAAEAAAAA AAAA7wAGAAAANwAAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAA AAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAmAAAAAcAAAABAAAAQAAAAAQA AABIAAAACAAAAFQAAAASAAAAYAAAAAwAAAB4AAAADQAAAIQAAAATAAAAkAAAAAIAAADkBAAAHgAA AAQAAABSYXkAHgAAAAQAAABSYXkAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAABeIChKk8UB QAAAAADIDbtLk8UBAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAA AAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAANgAAAAJAAAAAQAAAFAAAAAPAAAAWAAAABcA AABkAAAACwAAAGwAAAAQAAAAdAAAABMAAAB8AAAAFgAAAIQAAAANAAAAjAAAAAwAAAC1AAAAAgAA AOQEAAAeAAAAAQAAAAAAMwADAAAAoAoJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAAAMAAAAHAAAAU2hlZXQxAAcAAABTaGVldDIABwAAAFNoZWV0MwAMEAAAAgAAAB4AAAALAAAA V29ya3NoZWV0cwADAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH AAAA/v///wkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAAP7////9/////v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8CAAAAIAgC AAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAFAcUzpMk8UB/v///wAAAAAAAAAAVwBvAHIAawBiAG8A bwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAA AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKAACAQEAAAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAgAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAQAAAAAAAA --=====================_1122564712==_-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 09:07:23 2005 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 91EB216A41F for ; Thu, 28 Jul 2005 09:07:23 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate2.pacific.net.sg (smtpgate2.pacific.net.sg [203.120.90.28]) by mx1.FreeBSD.org (Postfix) with SMTP id 85FD843D46 for ; Thu, 28 Jul 2005 09:07:20 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 20129 invoked from network); 28 Jul 2005 09:07:17 -0000 Received: from maxwell6.pacific.net.sg (203.120.90.212) by smtpgate2 with SMTP; 28 Jul 2005 09:07:17 -0000 Received: from [192.168.0.107] ([210.24.246.110]) by maxwell6.pacific.net.sg with ESMTP id <20050728090717.KNIS1233.maxwell6.pacific.net.sg@[192.168.0.107]>; Thu, 28 Jul 2005 17:07:17 +0800 Message-ID: <42E89FCF.5070307@pacific.net.sg> Date: Thu, 28 Jul 2005 17:05:19 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050514) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ray@redshift.com References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> In-Reply-To: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 09:07:23 -0000 Hi, ray@redshift.com wrote: > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 > bit to 32 bit caused the machine to double in speed. The results are attached I do not wonder at all. I did some software development for PA-RISC and SPARC machines. Naiv as I am, I started with the perfect 64 bit program which resulted in bad performance. I then collected hints of how to mix 8, 16, 32 and 64 bit data to make the program much faster. The TCP/IP based application run then five times faster on the same machine compared to the plain 64 bit program. 64 bit programs copy to many unused information around. It will be very difficult to tune a huge source base to maximum performance and keep it compatible between 32 and 64 bit. The pointers mentioned by you are only a small part of the problem. The main problem is - at least in my program, and as far as what I saw in the sources here - the data handling. Erich From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 09:13:15 2005 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 79C4716A41F for ; Thu, 28 Jul 2005 09:13:15 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 351E243D45 for ; Thu, 28 Jul 2005 09:13:15 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 7020897898; Thu, 28 Jul 2005 02:13:14 -0700 (PDT) Message-Id: <3.0.1.32.20050728021315.00a4d188@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 28 Jul 2005 02:13:15 -0700 To: Erich Dollansky From: ray@redshift.com In-Reply-To: <42E89FCF.5070307@pacific.net.sg> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 09:13:15 -0000 At 05:05 PM 7/28/2005 +0800, Erich Dollansky wrote: | Hi, | | ray@redshift.com wrote: | | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 | > bit to 32 bit caused the machine to double in speed. The results are attached | | I do not wonder at all. | | I did some software development for PA-RISC and SPARC machines. Naiv as | I am, I started with the perfect 64 bit program which resulted in bad | performance. | | I then collected hints of how to mix 8, 16, 32 and 64 bit data to make | the program much faster. The TCP/IP based application run then five | times faster on the same machine compared to the plain 64 bit program. | | 64 bit programs copy to many unused information around. | | It will be very difficult to tune a huge source base to maximum | performance and keep it compatible between 32 and 64 bit. | | The pointers mentioned by you are only a small part of the problem. The | main problem is - at least in my program, and as far as what I saw in | the sources here - the data handling. | | Erich Thank you for the info - that makes sense and certainly backs up what I was seeing as well. Ray From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 12:13:55 2005 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 7B60816A41F for ; Thu, 28 Jul 2005 12:13:55 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06D3743D48 for ; Thu, 28 Jul 2005 12:13:54 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C06486145; Thu, 28 Jul 2005 14:13:49 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 4FD1360F8; Thu, 28 Jul 2005 14:13:49 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 2B15D33D48; Thu, 28 Jul 2005 14:13:49 +0200 (CEST) To: ray@redshift.com References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 28 Jul 2005 14:13:49 +0200 In-Reply-To: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> (ray@redshift.com's message of "Thu, 28 Jul 2005 01:31:52 -0700") Message-ID: <86mzo7yvpe.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.3/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 12:13:55 -0000 ray@redshift.com writes: > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on > the machine and after applying the exact same configuration to the > OS, Apache, PHP and MySQL, re-ran the benchmarks. Much to my > surprise, just changing the OS from 64 bit to 32 bit caused the > machine to double in speed. The results are attached in an Excel > spreadsheet. So the exact same machine, running the identical > configuration, performed roughly twice as fast when running FreeBSD > 5.4 i386 vs FreeBSD 5.4 AMD64. Something about this seems so wrong > to me :-) 64-bit code uses up to twice as much CPU cache and twice as many memory accesses to do the same work as the equivalent 32-bit code. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 15:01:10 2005 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 9227C16A41F for ; Thu, 28 Jul 2005 15:01:10 +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 3A3DE43D48 for ; Thu, 28 Jul 2005 15:01:09 +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 2089811EA4 for ; Thu, 28 Jul 2005 09:01:07 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id DE10B11EA3 for ; Thu, 28 Jul 2005 09:01:06 -0600 (MDT) Date: Thu, 28 Jul 2005 09:01:05 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050728090105.4c917e70.kgunders@teamcool.net> In-Reply-To: <86mzo7yvpe.fsf@xps.des.no> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> 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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 15:01:10 -0000 On Thu, 28 Jul 2005 14:13:49 +0200 des@des.no (Dag-Erling Sm=F8rgrav) wrote: > ray@redshift.com writes: > > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on > > the machine and after applying the exact same configuration to the > > OS, Apache, PHP and MySQL, re-ran the benchmarks. Much to my > > surprise, just changing the OS from 64 bit to 32 bit caused the > > machine to double in speed. The results are attached in an Excel > > spreadsheet. So the exact same machine, running the identical > > configuration, performed roughly twice as fast when running FreeBSD > > 5.4 i386 vs FreeBSD 5.4 AMD64. Something about this seems so wrong > > to me :-) >=20 > 64-bit code uses up to twice as much CPU cache and twice as many > memory accesses to do the same work as the equivalent 32-bit code. Makes a lot of sense once you think about it but counter intuitive to most people's expectations from their "shinny new 64bit powerhouse"... Looking at the other side of the coin perhaps we should mention some situations where 64bit os's outperform 32 bit ones, e.g. analysis of larger, complex datasets...?? I've talked with a few folks from the SAP crowd and they're absolutely in love with the Opterons, reporting far superior performance over Xeons, and are rolling out quads and 8x in lieu of much, much, much more costly heavy iron counter parts. They are, however, running on Linux. Ubench scores, for what they're worth, appear to be comparable between Opterons and Xeon64T's , so I guess the answer depends on your application.;-) -- 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 Thu Jul 28 15:05:25 2005 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 77F4716A41F for ; Thu, 28 Jul 2005 15:05:25 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1790943D45 for ; Thu, 28 Jul 2005 15:05:25 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id D4C6A978FD; Thu, 28 Jul 2005 08:05:24 -0700 (PDT) Message-Id: <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 28 Jul 2005 08:05:26 -0700 To: Ken Gunderson ,freebsd-amd64@freebsd.org From: ray@redshift.com In-Reply-To: <20050728090105.4c917e70.kgunders@teamcool.net> References: <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 15:05:25 -0000 At 09:01 AM 7/28/2005 -0600, Ken Gunderson wrote: | On Thu, 28 Jul 2005 14:13:49 +0200 | des@des.no (Dag-Erling Smrgrav) wrote: | | > ray@redshift.com writes: | > > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on | > > the machine and after applying the exact same configuration to the | > > OS, Apache, PHP and MySQL, re-ran the benchmarks. Much to my | > > surprise, just changing the OS from 64 bit to 32 bit caused the | > > machine to double in speed. The results are attached in an Excel | > > spreadsheet. So the exact same machine, running the identical | > > configuration, performed roughly twice as fast when running FreeBSD | > > 5.4 i386 vs FreeBSD 5.4 AMD64. Something about this seems so wrong | > > to me :-) | > | > 64-bit code uses up to twice as much CPU cache and twice as many | > memory accesses to do the same work as the equivalent 32-bit code. | | Makes a lot of sense once you think about it but counter intuitive to | most people's expectations from their "shinny new 64bit powerhouse"... | | Looking at the other side of the coin perhaps we should mention some | situations where 64bit os's outperform 32 bit ones, e.g. | analysis of larger, complex datasets...?? | | I've talked with a few folks from the SAP crowd and they're absolutely | in love with the Opterons, reporting far superior performance over | Xeons, and are rolling out quads and 8x in lieu of much, much, much more | costly heavy iron counter parts. They are, however, running on Linux. | | Ubench scores, for what they're worth, appear to be comparable between | Opterons and Xeon64T's , so I guess the answer depends on your | application.;-) I've also heard the AMD's perform well under heavy database load - although I have not put any machine into production yet. As you say, you get a new shinney AMD and run to put a 64 bit OS on it thinking it will smoke the tires. But once you test it and start thinking about it, the 32 bit running faster makes sense. Maybe there needs to be a 20 bit OS :-) Anyway, thanks for the run down. Ray From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 15:34:47 2005 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 25E7F16A425 for ; Thu, 28 Jul 2005 15:34:47 +0000 (GMT) (envelope-from erich.boleyn@amd.com) Received: from amdext3.amd.com (amdext3.amd.com [139.95.251.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A03A143D45 for ; Thu, 28 Jul 2005 15:34:46 +0000 (GMT) (envelope-from erich.boleyn@amd.com) Received: from SSVLGW02.amd.com (ssvlgw02.amd.com [139.95.250.170]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id j6SFVwi7008593 for ; Thu, 28 Jul 2005 08:34:47 -0700 Received: from 139.95.250.1 by SSVLGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Thu, 28 Jul 2005 08:34:38 -0700 X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF Received: from SSVLEXBH2.amd.com (SSVLEXBH2.amd.com [139.95.53.183]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id j6SFYcVo012233; Thu, 28 Jul 2005 08:34:38 -0700 (PDT) Received: from SSVLEXMB1.amd.com ([139.95.53.181]) by SSVLEXBH2.amd.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Jul 2005 08:34:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jul 2005 08:34:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Benchmarks: AMD64 vs i386 on Dual 246 Opteron thread-index: AcWTTuDspPqLmYrlSdaRhVNplZaNrwAOINMV From: "Boleyn, Erich" To: ray@redshift.com, freebsd-amd64@freebsd.org X-OriginalArrivalTime: 28 Jul 2005 15:34:38.0583 (UTC) FILETIME=[DD7F3070:01C59389] X-WSS-ID: 6EF624842Q49623068-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 15:34:47 -0000 [NOTE: I am not subscribed to the list, but got this sent to me by the = author of the message. Please copy me on any responses that are relevant] Include std disclaimer here: I work for AMD on this stuff, but am = answering generally as myself. ray@redshift.com [mailto:ray@redshift.com] wrote: > Freebsd-AMD64 list: ... > The machine provided was a Dual Opteron 246 using the Tyan S2881 = motherboard. > It had 4GB or ram and included a single SATA hard drive. >=20 > I initially loaded FreeBSD 5.4 AMD64 on the machine, recompiled the = kernel, etc. > and applied all the normal tweaks to apache, PHP, etc. The machine, = while > faster than our single 2.4 Ghz Xeon's, wasn't all that much faster = (maybe only > 10 to 15 percent). =20 >=20 > After speaking with AMD and doing further benchmarks, I was about to = give up on > AMD and return the machine. However, at the last minute, an engineer = from AMD > suggested that perhaps loading the 32 bit version of FreeBSD (aka = i386) might > improve performance, since it was possible that the overhead from 64 = bit > pointers was causing the machine to run slower than expected. He also = explained > that the AMD should be running about 3 to 4 times faster than the = single Xeon. >=20 > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the = machine > and after applying the exact same configuration to the OS, Apache, PHP = and > MySQL, re-ran the benchmarks. Much to my surprise, just changing the = OS from 64 > bit to 32 bit caused the machine to double in speed. The results are = attached > in an Excel spreadsheet. So the exact same machine, running the = identical > configuration, performed roughly twice as fast when running FreeBSD = 5.4 i386 vs > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) ...[shorted for brevity]... > The only answer I have so far as to why this may be the case is that = perhaps > i386 uses 32 bit pointers which the CPU(s) can handle faster (thus = less overhead > for the CPU). But it still seems odd to me that if FreeBSD AMD64 is = written > specifically for the 64 bit CPU, why doesn't the machine perform = better when > running it? This question isn't as simple as saying "64-bit pointers vs. 32-bit = pointers". Opterons really do run code much the same clock-per-clock in 64-bit and = 32-bit mode, given it's the same instruction sequence, which is almost always = NOT the case. Typically, for well-optimized code, you see: -- 32-bit x86 code has a smaller data footprint since pointers are = only 4 bytes. -- 64-bit x86 code has fewer spills/reloads of registers (i.e. = shorter code paths in most routines). The result is that, for most reasonably well-optimized or identical code = I've run, the 64-bit version is faster. Large-data-footprint/cache-busting cases = seem the exception, of which there are plenty of course. Linux webservers we've = tested do seem to perform much better on 64-bit. Having said that, it's well known that FreeBSD i386 is very highly = optimized. I'd bet that the considerably less mature FreeBSD AMD64 codebase, or the = PHP/Apache software stack is to blame here. There are almost certainly i386 = assembly or just i386-code-path-specific C/C++ code involved which is distinct = from the version compiled for AMD64. The i386 version of FreeBSD (and PHP/Apache), and in specific, the = i386-specific codepaths, have been beaten to death by a very large number of people = opimizing the heck out of it. I sincerely doubt the same can be said of the AMD64 = code path. > I'm also wondering if there is a compiler switch on AMD64 that could = be used > (perhaps in /etc/make.conf or something) that would force the AMD64 = version to > run in 32 bit mode only - since that would be an interesting = comparison as well. Yes, for building 32-bit code: for GCC, use "-m32", for LD, use = "-melf_i386". Erich Boleyn CPG Architecture AMD From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 15:53:51 2005 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 D1AD016A41F for ; Thu, 28 Jul 2005 15:53:51 +0000 (GMT) (envelope-from erich.boleyn@amd.com) Received: from amdext3.amd.com (amdext3.amd.com [139.95.251.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B9743D53 for ; Thu, 28 Jul 2005 15:53:50 +0000 (GMT) (envelope-from erich.boleyn@amd.com) Received: from SSVLGW02.amd.com (ssvlgw02.amd.com [139.95.250.170]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id j6SFrThl016620 for ; Thu, 28 Jul 2005 08:53:52 -0700 Received: from 139.95.250.1 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Thu, 28 Jul 2005 08:53:39 -0700 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from SSVLEXBH2.amd.com (SSVLEXBH2.amd.com [139.95.53.183]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id j6SFrcVo015778; Thu, 28 Jul 2005 08:53:39 -0700 (PDT) Received: from SSVLEXMB1.amd.com ([139.95.53.181]) by SSVLEXBH2.amd.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Jul 2005 08:53:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jul 2005 08:50:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Benchmarks: AMD64 vs i386 on Dual 246 Opteron thread-index: AcWTTuDspPqLmYrlSdaRhVNplZaNrwAOINMVAAEpiKQ= From: "Boleyn, Erich" To: ray@redshift.com, freebsd-amd64@freebsd.org X-OriginalArrivalTime: 28 Jul 2005 15:53:38.0925 (UTC) FILETIME=[853191D0:01C5938C] X-WSS-ID: 6EF620091CO9645719-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Boleyn, Erich" Subject: RE: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 15:53:52 -0000 Sorry for the extra note here, but I thought I'd make sure to point out = that the performance issue here could also very likely be an i386-specific path = through PHP (which was actually my first suspicion), and not FreeBSD-specific at = all. I'd bet that has a "generic" path and also machine-specific optimized = paths (given the number of targets PHP supports), and the i386-path has = probably been highly optimized given how many x86 machines run PHP. Erich Boleyn CPG Architecture AMD -----Original Message----- From: Boleyn, Erich Sent: Thu 7/28/2005 8:34 AM To: ray@redshift.com; freebsd-amd64@freebsd.org Subject: RE: Benchmarks: AMD64 vs i386 on Dual 246 Opteron =20 [NOTE: I am not subscribed to the list, but got this sent to me by the = author of the message. Please copy me on any responses that are relevant] Include std disclaimer here: I work for AMD on this stuff, but am = answering generally as myself. ray@redshift.com [mailto:ray@redshift.com] wrote: > Freebsd-AMD64 list: ... > The machine provided was a Dual Opteron 246 using the Tyan S2881 = motherboard. > It had 4GB or ram and included a single SATA hard drive. >=20 > I initially loaded FreeBSD 5.4 AMD64 on the machine, recompiled the = kernel, etc. > and applied all the normal tweaks to apache, PHP, etc. The machine, = while > faster than our single 2.4 Ghz Xeon's, wasn't all that much faster = (maybe only > 10 to 15 percent). =20 >=20 > After speaking with AMD and doing further benchmarks, I was about to = give up on > AMD and return the machine. However, at the last minute, an engineer = from AMD > suggested that perhaps loading the 32 bit version of FreeBSD (aka = i386) might > improve performance, since it was possible that the overhead from 64 = bit > pointers was causing the machine to run slower than expected. He also = explained > that the AMD should be running about 3 to 4 times faster than the = single Xeon. >=20 > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the = machine > and after applying the exact same configuration to the OS, Apache, PHP = and > MySQL, re-ran the benchmarks. Much to my surprise, just changing the = OS from 64 > bit to 32 bit caused the machine to double in speed. The results are = attached > in an Excel spreadsheet. So the exact same machine, running the = identical > configuration, performed roughly twice as fast when running FreeBSD = 5.4 i386 vs > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) ...[shorted for brevity]... > The only answer I have so far as to why this may be the case is that = perhaps > i386 uses 32 bit pointers which the CPU(s) can handle faster (thus = less overhead > for the CPU). But it still seems odd to me that if FreeBSD AMD64 is = written > specifically for the 64 bit CPU, why doesn't the machine perform = better when > running it? This question isn't as simple as saying "64-bit pointers vs. 32-bit = pointers". Opterons really do run code much the same clock-per-clock in 64-bit and = 32-bit mode, given it's the same instruction sequence, which is almost always = NOT the case. Typically, for well-optimized code, you see: -- 32-bit x86 code has a smaller data footprint since pointers are = only 4 bytes. -- 64-bit x86 code has fewer spills/reloads of registers (i.e. = shorter code paths in most routines). The result is that, for most reasonably well-optimized or identical code = I've run, the 64-bit version is faster. Large-data-footprint/cache-busting cases = seem the exception, of which there are plenty of course. Linux webservers we've = tested do seem to perform much better on 64-bit. Having said that, it's well known that FreeBSD i386 is very highly = optimized. I'd bet that the considerably less mature FreeBSD AMD64 codebase, or the = PHP/Apache software stack is to blame here. There are almost certainly i386 = assembly or just i386-code-path-specific C/C++ code involved which is distinct = from the version compiled for AMD64. The i386 version of FreeBSD (and PHP/Apache), and in specific, the = i386-specific codepaths, have been beaten to death by a very large number of people = opimizing the heck out of it. I sincerely doubt the same can be said of the AMD64 = code path. > I'm also wondering if there is a compiler switch on AMD64 that could = be used > (perhaps in /etc/make.conf or something) that would force the AMD64 = version to > run in 32 bit mode only - since that would be an interesting = comparison as well. Yes, for building 32-bit code: for GCC, use "-m32", for LD, use = "-melf_i386". Erich Boleyn CPG Architecture AMD From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 16:19:08 2005 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 E5AF616A41F for ; Thu, 28 Jul 2005 16:19:08 +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 7C64143D4C for ; Thu, 28 Jul 2005 16:19:08 +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 j6SGJ8Yg064217; Thu, 28 Jul 2005 09:19:08 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j6SGJ8Q9064216; Thu, 28 Jul 2005 09:19:08 -0700 (PDT) (envelope-from sgk) Date: Thu, 28 Jul 2005 09:19:08 -0700 From: Steve Kargl To: ray@redshift.com Message-ID: <20050728161908.GB64153@troutmask.apl.washington.edu> References: <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 16:19:09 -0000 On Thu, Jul 28, 2005 at 08:05:26AM -0700, ray@redshift.com wrote: > > I've also heard the AMD's perform well under heavy database > load - although I have not put any machine into production yet. > > As you say, you get a new shinney AMD and run to put a 64 bit > OS on it thinking it will smoke the tires. But once you test > it and start thinking about it, the 32 bit running faster makes > sense. Maybe there needs to be a 20 bit OS :-) > Drop 8 GB of memory into the box and see how the 32-bit FreeBSD performs in comparison to the 64-bit FreeBSD when your process consumes greater than 4GB of memory. -- Steve From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 16:23:36 2005 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 AD96116A41F for ; Thu, 28 Jul 2005 16:23:36 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 661BD43D45 for ; Thu, 28 Jul 2005 16:23:36 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 2B83597915; Thu, 28 Jul 2005 09:23:36 -0700 (PDT) Message-Id: <3.0.1.32.20050728092338.01207628@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 28 Jul 2005 09:23:38 -0700 To: Steve Kargl From: ray@redshift.com In-Reply-To: <20050728161908.GB64153@troutmask.apl.washington.edu> References: <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 16:23:36 -0000 True, once you go over the 4GB limit it's a different ball of wax. However, until that time, it would be nice to get to the bottom of why 64 bit code is running half the speed of 32 bit code on the exact same machine - don't you think? Ray At 09:19 AM 7/28/2005 -0700, Steve Kargl wrote: | On Thu, Jul 28, 2005 at 08:05:26AM -0700, ray@redshift.com wrote: | > | > I've also heard the AMD's perform well under heavy database | > load - although I have not put any machine into production yet. | > | > As you say, you get a new shinney AMD and run to put a 64 bit | > OS on it thinking it will smoke the tires. But once you test | > it and start thinking about it, the 32 bit running faster makes | > sense. Maybe there needs to be a 20 bit OS :-) | > | | Drop 8 GB of memory into the box and see how the 32-bit | FreeBSD performs in comparison to the 64-bit FreeBSD | when your process consumes greater than 4GB of memory. | | -- | Steve | | From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 16:36:02 2005 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 EB44116A420 for ; Thu, 28 Jul 2005 16:36:02 +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 5631A43D4C for ; Thu, 28 Jul 2005 16:36:02 +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 j6SGa2cN064330; Thu, 28 Jul 2005 09:36:02 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j6SGa2Rn064329; Thu, 28 Jul 2005 09:36:02 -0700 (PDT) (envelope-from sgk) Date: Thu, 28 Jul 2005 09:36:02 -0700 From: Steve Kargl To: ray@redshift.com Message-ID: <20050728163602.GC64153@troutmask.apl.washington.edu> References: <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> <3.0.1.32.20050728092338.01207628@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.1.32.20050728092338.01207628@pop.redshift.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 16:36:03 -0000 On Thu, Jul 28, 2005 at 09:23:38AM -0700, ray@redshift.com wrote: > | > | Drop 8 GB of memory into the box and see how the 32-bit > | FreeBSD performs in comparison to the 64-bit FreeBSD > | when your process consumes greater than 4GB of memory. > > True, once you go over the 4GB limit it's a different ball of wax. > However, until that time, it would be nice to get to the bottom of > why 64 bit code is running half the speed of 32 bit code on the exact > same machine - don't you think? Well, I have 12 GB of memory and run numerical intensive codes that easily can grab 4+ GB, so I've never explored i386 FreeBSD on an amd64 system. As mentioned elsewhere, I would look for optimizations within the software packages that target i386. Additionally, the instruction schedulers in gcc/gas have had many more years of development in comparison to the amd64 schedulers. An interesting test would be to build math/atlas on 32-bit and 64-bit FreeBSD and then run some linpack benchmarks. -- Steve From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 16:46:31 2005 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 097AE16A41F for ; Thu, 28 Jul 2005 16:46:31 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94FE843D45 for ; Thu, 28 Jul 2005 16:46:30 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 597D89791F; Thu, 28 Jul 2005 09:46:27 -0700 (PDT) Message-Id: <3.0.1.32.20050728094629.00a50b10@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 28 Jul 2005 09:46:29 -0700 To: Steve Kargl From: ray@redshift.com In-Reply-To: <20050728163602.GC64153@troutmask.apl.washington.edu> References: <3.0.1.32.20050728092338.01207628@pop.redshift.com> <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <86mzo7yvpe.fsf@xps.des.no> <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> <3.0.1.32.20050728092338.01207628@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 16:46:31 -0000 At 09:36 AM 7/28/2005 -0700, Steve Kargl wrote: | On Thu, Jul 28, 2005 at 09:23:38AM -0700, ray@redshift.com wrote: | > | | > | Drop 8 GB of memory into the box and see how the 32-bit | > | FreeBSD performs in comparison to the 64-bit FreeBSD | > | when your process consumes greater than 4GB of memory. | > | > True, once you go over the 4GB limit it's a different ball of wax. | > However, until that time, it would be nice to get to the bottom of | > why 64 bit code is running half the speed of 32 bit code on the exact | > same machine - don't you think? | | Well, I have 12 GB of memory and run numerical intensive codes | that easily can grab 4+ GB, so I've never explored i386 FreeBSD on | an amd64 system. | | As mentioned elsewhere, I would look for optimizations within | the software packages that target i386. Additionally, the | instruction schedulers in gcc/gas have had many more years | of development in comparison to the amd64 schedulers. | | An interesting test would be to build math/atlas on 32-bit | and 64-bit FreeBSD and then run some linpack benchmarks. All good points. Maybe part of it does boil down to the fact that AMD64 is new and hasn't had the mileage and hammering that i386 has had all right - that makes a lot of sense certainly. My main question relating to all of this is whether the 64 bit code should run as fast as the 32 bit code. If not, that's fine. But if it should, then - at least in my testing - there is something resulting in quite a delay when it comes to the AMD64 branch vs. the i386 branch, at least in relation to something like Apache and MySQL. Let me put it this way... I know if I was in your shoes, running apps that could only run on the 64 bit version of FreeBSD, I would want to know for sure that I wasn't giving up half my potential speed just in order to gain access to system memory above 4GB's. That's really what my concerns are - even though currently I do not have any servers that need require more than a couple of GB's of RAM. Ray From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 17:49:51 2005 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 C97C516A41F for ; Thu, 28 Jul 2005 17:49:51 +0000 (GMT) (envelope-from erich.boleyn@amd.com) Received: from amdext3.amd.com (amdext3.amd.com [139.95.251.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2113E43D45 for ; Thu, 28 Jul 2005 17:49:45 +0000 (GMT) (envelope-from erich.boleyn@amd.com) Received: from SSVLGW02.amd.com (ssvlgw02.amd.com [139.95.250.170]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id j6SHnln1030112 for ; Thu, 28 Jul 2005 10:49:47 -0700 Received: from 139.95.250.1 by SSVLGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Thu, 28 Jul 2005 10:49:33 -0700 X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF Received: from SSVLEXBH2.amd.com (SSVLEXBH2.amd.com [139.95.53.183]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id j6SHnVVo008827; Thu, 28 Jul 2005 10:49:31 -0700 (PDT) Received: from SSVLEXMB1.amd.com ([139.95.53.181]) by SSVLEXBH2.amd.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Jul 2005 10:49:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jul 2005 10:45:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Benchmarks: AMD64 vs i386 on Dual 246 Opteron thread-index: AcWTkXG4O4pHUoEQSui+OodD6BPVMQACrpLa From: "Boleyn, Erich" To: ray@redshift.com, freebsd-amd64@freebsd.org X-OriginalArrivalTime: 28 Jul 2005 17:49:31.0373 (UTC) FILETIME=[B52CF1D0:01C5939C] X-WSS-ID: 6EF7C5272Q49658944-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Boleyn, Erich" Subject: RE: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 17:49:52 -0000 ray at redshift.com wrote: > In the benchmarking I did, even .gif and .jpg files being loaded via = Apache were > negatively impacted under AMD64 vs. i386. I don't think PHP would be = involved > at that stage - even though I do have PHP statically compiled into = Apache.=20 >=20 > The speed difference between i386 and AMD64 was pretty consistent = between .php, > .gif/jpg loads as well as when handling MySQL stuff (even though it is = PHP > making the MySQL calls, the bottle neck in the MySQL tests appeared to = be MySQL, > not the API language as it were. And in those cases, the MySQL tests = went up by > around the same factor as the .php and .gif/jpg page loads, so I think = it was > something not directly tied to PHP. I could be mistaken, but that's = the > impression I got since even non .php stuff went up/down as I changed = the OS > branch during the benchmarking.=20 Agreed, that would indicate it's likely the base FreeBSD OS or libraries = heavily used by the above applications (assuming you didn't serve static pages = from MySQL as well and it was not a common factor as it seems from your statement). Erich Boleyn CPG Architecture AMD From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 17:57:45 2005 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 C8BD916A41F for ; Thu, 28 Jul 2005 17:57:45 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7113A43D46 for ; Thu, 28 Jul 2005 17:57:45 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 1CC862A8F8 for ; Thu, 28 Jul 2005 10:57:45 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id C8CB5E2B3 for ; Thu, 28 Jul 2005 10:57:44 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.4) with ESMTP id j6SHviKx061117; Thu, 28 Jul 2005 10:57:44 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id j6SHvhjq061116; Thu, 28 Jul 2005 10:57:43 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Thu, 28 Jul 2005 10:57:42 -0700 User-Agent: KMail/1.8.1 References: <3.0.1.32.20050728080526.00aa4098@pop.redshift.com> <3.0.1.32.20050728092338.01207628@pop.redshift.com> <20050728163602.GC64153@troutmask.apl.washington.edu> In-Reply-To: <20050728163602.GC64153@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507281057.43655.peter@wemm.org> Cc: Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 17:57:46 -0000 On Thursday 28 July 2005 09:36 am, Steve Kargl wrote: > As mentioned elsewhere, I would look for optimizations within > the software packages that target i386. Additionally, the > instruction schedulers in gcc/gas have had many more years > of development in comparison to the amd64 schedulers. Take libc and libm for example... libc: peter@overcee[10:50am]~/fbp4/hammer/lib/libc-112> ls i386/string/ Makefile.inc index.S memset.S strcpy.S wcschr.S bcmp.S memchr.S rindex.S strlen.S wcscmp.S bcopy.S memcmp.S strcat.S strncmp.S wcslen.S bzero.S memcpy.S strchr.S strrchr.S wmemchr.S ffs.S memmove.S strcmp.S swab.S peter@overcee[10:50am]~/fbp4/hammer/lib/libc-113> ls amd64/string/ Makefile.inc bzero.S memmove.S strcmp.S bcmp.S memcmp.S memset.S strcpy.S bcopy.S memcpy.S strcat.S peter@overcee[10:50am]~/fbp4/hammer/lib/libc-114> libm: peter@overcee[10:51am]~/fbp4/hammer/lib/msun-117> ls i387 Makefile.inc s_ceilf.S s_remquo.S e_exp.S s_ceill.S s_remquof.S e_fmod.S s_copysign.S s_rint.S e_log.S s_copysignf.S s_rintf.S e_log10.S s_copysignl.S s_scalbn.S e_log10f.S s_cos.S s_scalbnf.S e_logf.S s_finite.S s_scalbnl.S e_remainder.S s_floor.S s_significand.S e_remainderf.S s_floorf.S s_significandf.S e_scalb.S s_floorl.S s_sin.S e_scalbf.S s_llrint.S s_tan.S e_sqrt.S s_llrintf.S s_trunc.S e_sqrtf.S s_logb.S s_truncf.S fenv.c s_logbf.S s_truncl.S fenv.h s_lrint.S s_ceil.S s_lrintf.S peter@overcee[10:51am]~/fbp4/hammer/lib/msun-118> ls amd64/ Makefile.inc fenv.c s_llrintf.S s_remquo.S s_scalbnf.S e_sqrt.S fenv.h s_lrint.S s_remquof.S s_scalbnl.S e_sqrtf.S s_llrint.S s_lrintf.S s_scalbn.S peter@overcee[10:51am]~/fbp4/hammer/lib/msun-119> Now granted gcc has many of these as builtins.. but it illustrates the point I'm trying to make. Lots of code has hand-tuned i386 assembler optimization and falls back to generic C code for 64 bit mode. Mysql could also easily be affected by inefficiencies in the amd64 pthread libraries too. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 22:45:04 2005 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 D821E16A421; Thu, 28 Jul 2005 22:45:04 +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 3EE0543D49; Thu, 28 Jul 2005 22:45:02 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SMiLRs060916; Thu, 28 Jul 2005 18:44:21 -0400 (EDT) (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 j6SMj1t2039545; Thu, 28 Jul 2005 18:45:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4B4FE7305C; Thu, 28 Jul 2005 18:45:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728224501.4B4FE7305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 18:45:01 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 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: Thu, 28 Jul 2005 22:45:05 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 22:45:05 2005 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 7115016A423; Thu, 28 Jul 2005 22:45:05 +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 3ED1A43D48; Thu, 28 Jul 2005 22:45:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SMiLYt060914; Thu, 28 Jul 2005 18:44:21 -0400 (EDT) (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 j6SMj1MD039539; Thu, 28 Jul 2005 18:45:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 242DA73052; Thu, 28 Jul 2005 18:45:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728224501.242DA73052@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 18:45:01 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_6 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: Thu, 28 Jul 2005 22:45:06 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:00:04 2005 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 851E516A421; Thu, 28 Jul 2005 23:00:04 +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 B43B843D5E; Thu, 28 Jul 2005 23:00:02 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SN006P031477; Thu, 28 Jul 2005 19:00:01 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6SN00GM070194; Thu, 28 Jul 2005 19:00:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D8AF97305C; Thu, 28 Jul 2005 19:00:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728230000.D8AF97305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:00:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner5 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: Thu, 28 Jul 2005 23:00:05 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:00:05 2005 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 9BF8516A422; Thu, 28 Jul 2005 23:00:04 +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 8688C43D49; Thu, 28 Jul 2005 23:00:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SN00rq031474; Thu, 28 Jul 2005 19:00:00 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6SN00tJ070187; Thu, 28 Jul 2005 19:00:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A91147304F; Thu, 28 Jul 2005 19:00:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728230000.A91147304F@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:00:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [releng_6 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: Thu, 28 Jul 2005 23:00:05 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:15:02 2005 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 847D116A421; Thu, 28 Jul 2005 23:15:02 +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 327A243D5C; Thu, 28 Jul 2005 23:15:01 +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.3/8.13.3) with ESMTP id j6SNF02X032256; Thu, 28 Jul 2005 19:15:00 -0400 (EDT) (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 j6SNF0ku010270; Thu, 28 Jul 2005 19:15:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 36B817304F; Thu, 28 Jul 2005 19:15:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728231500.36B817304F@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:15:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner5 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [releng_6 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: Thu, 28 Jul 2005 23:15:02 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:15:04 2005 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 23F8F16A423; Thu, 28 Jul 2005 23:15:04 +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 0CBD443D5C; Thu, 28 Jul 2005 23:15:02 +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.3/8.13.3) with ESMTP id j6SNF0pn032259; Thu, 28 Jul 2005 19:15:00 -0400 (EDT) (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 j6SNF0Am010278; Thu, 28 Jul 2005 19:15:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 66D3C7305C; Thu, 28 Jul 2005 19:15:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728231500.66D3C7305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:15:00 -0400 (EDT) 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: Thu, 28 Jul 2005 23:15:04 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:30:03 2005 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 D96F016A420; Thu, 28 Jul 2005 23:30:03 +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 883EC43D53; Thu, 28 Jul 2005 23:30:01 +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.3/8.13.3) with ESMTP id j6SNTLSB062538; Thu, 28 Jul 2005 19:29:21 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6SNU0U9082604; Thu, 28 Jul 2005 19:30:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B410F7304F; Thu, 28 Jul 2005 19:30:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728233000.B410F7304F@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:30:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_6 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: Thu, 28 Jul 2005 23:30:04 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:30:06 2005 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 2205B16A420; Thu, 28 Jul 2005 23:30: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 C910C43D5E; Thu, 28 Jul 2005 23:30:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SNTLiY062541; Thu, 28 Jul 2005 19:29:21 -0400 (EDT) (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 j6SNU1Od045433; Thu, 28 Jul 2005 19:30:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DFC917305C; Thu, 28 Jul 2005 19:30:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728233000.DFC917305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:30:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner5 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: Thu, 28 Jul 2005 23:30:06 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:35:31 2005 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 B0FB416A41F for ; Thu, 28 Jul 2005 23:35:31 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ED8643D7B for ; Thu, 28 Jul 2005 23:35:20 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j6SNZJNq066372; Fri, 29 Jul 2005 01:35:19 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j6SNZJcH066368; Thu, 28 Jul 2005 19:35:19 -0400 (EDT) (envelope-from cracauer) Date: Thu, 28 Jul 2005 19:35:19 -0400 From: Martin Cracauer To: ray@redshift.com Message-ID: <20050728193519.A66123@cons.org> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com>; from ray@redshift.com on Thu, Jul 28, 2005 at 01:31:52AM -0700 Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 28 Jul 2005 23:35:31 -0000 > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine > and after applying the exact same configuration to the OS, Apache, PHP and > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 > bit to 32 bit caused the machine to double in speed. The results are attached > in an Excel spreadsheet. So the exact same machine, running the identical > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) I'm sorry but I cannot support these findings. I don't have cut'n'paste numbers handy, but generally 64 bits speed up things quite a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but generally there is a speedup. Data is not generally doubled in size. Plain int stays the same in C. Floating point stays the same. String stays the same. Arrays of ints stay the same. But e.g. lists do not. The additonal registers are a huge deal. While you "only" double from 8 to 16 you have to understand that not all of the 8 registers are general-purpose. In practice you go from 3 or 4 registers to 11 or 12 for run-of-the-mill C-compiled code. Databases like mysql should see a speedup from having native 64 bit integer arithmetic, which they use heavily for e.g. statistics and general addressing other than pointers. Php on the other hand, along with most other scripting languages, makes heavy use of linked lists which are pointer-intensive. Benchmarks of 64 bits Linux versus 32 bit Linux has been published on sites such as the Linux section of anandtech.com and linuxhardware.com and they all verify what I write above. I am currently setting up a quad-boot Opteron and will be able to get cut'n'pasteable numbers soon. I never kept my earlier ones. %% I highly suspect that the 64 bit version of FreeBSD in this comparision was somehow doomed before it started. Opportunities are leaving in kernel safety code in one of the kernels, a driver that just doesn't work right on AMD64. Or the same for any of the software, maybe php is hosed in its 64 bit build. > I'm also wondering if there is a compiler switch on AMD64 that could be used > (perhaps in /etc/make.conf or something) that would force the AMD64 version to > run in 32 bit mode only - since that would be an interesting comparison as well. -m32 You can also just copy a 32 bit installation of your benchmark suite, if required a whole OS installation and changeroot into it. That way you don't have to compile. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:45:02 2005 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 D04DA16A41F; Thu, 28 Jul 2005 23:45:02 +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 5D11543D5C; Thu, 28 Jul 2005 23:45:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SNiKok062985; Thu, 28 Jul 2005 19:44:20 -0400 (EDT) (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 j6SNj1eh080489; Thu, 28 Jul 2005 19:45:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8C4F87304F; Thu, 28 Jul 2005 19:45:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728234500.8C4F87304F@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:45:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_6 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: Thu, 28 Jul 2005 23:45:03 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:45:11 2005 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 93A8016A41F; Thu, 28 Jul 2005 23:45:11 +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 535A743D7B; Thu, 28 Jul 2005 23:45:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SNj0L7033180; Thu, 28 Jul 2005 19:45:00 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6SNj0rU087846; Thu, 28 Jul 2005 19:45:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B9EED7305C; Thu, 28 Jul 2005 19:45:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050728234500.B9EED7305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 19:45:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 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: Thu, 28 Jul 2005 23:45:11 -0000 From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 28 23:50:58 2005 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 305C616A41F for ; Thu, 28 Jul 2005 23:50:58 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF04843D45 for ; Thu, 28 Jul 2005 23:50:57 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 7A069F20C6; Thu, 28 Jul 2005 16:50:57 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45888-02; Thu, 28 Jul 2005 16:50:48 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 865E0F18CC; Thu, 28 Jul 2005 16:50:48 -0700 (PDT) From: Sean McNeil To: Martin Cracauer In-Reply-To: <20050728193519.A66123@cons.org> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <20050728193519.A66123@cons.org> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Thu, 28 Jul 2005 16:50:48 -0700 Message-Id: <1122594648.45827.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 23:50:58 -0000 On Thu, 2005-07-28 at 19:35 -0400, Martin Cracauer wrote: > I highly suspect that the 64 bit version of FreeBSD in this > comparision was somehow doomed before it started. Opportunities are > leaving in kernel safety code in one of the kernels, a driver that > just doesn't work right on AMD64. Or the same for any of the > software, maybe php is hosed in its 64 bit build. If network throughput can effect the testing, I would suspect network drivers. I've found the re0 driver performs horrible on amd64. Especially with gigE. Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 00:00:09 2005 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 6DB9716A41F; Fri, 29 Jul 2005 00:00:09 +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 3277C43D75; Fri, 29 Jul 2005 00:00:02 +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.3/8.13.3) with ESMTP id j6T00199033661; Thu, 28 Jul 2005 20:00:01 -0400 (EDT) (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 j6T0017b015786; Thu, 28 Jul 2005 20:00:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5CB9B7305C; Thu, 28 Jul 2005 20:00:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050729000001.5CB9B7305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 20:00:01 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 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: Fri, 29 Jul 2005 00:00:10 -0000 From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 00:00:10 2005 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 A081316A424; Fri, 29 Jul 2005 00:00:09 +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 2D3CA43D73; Fri, 29 Jul 2005 00:00:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6SNxL6t063421; Thu, 28 Jul 2005 19:59:21 -0400 (EDT) (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 j6T001ql015780; Thu, 28 Jul 2005 20:00:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1EB027304F; Thu, 28 Jul 2005 20:00:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050729000001.1EB027304F@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 20:00:01 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_6 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: Fri, 29 Jul 2005 00:00:10 -0000 From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 00:15:03 2005 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 2CDC116A41F; Fri, 29 Jul 2005 00:15:03 +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 A9E0E43D48; Fri, 29 Jul 2005 00:15:01 +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.3/8.13.3) with ESMTP id j6T0ELjM064093; Thu, 28 Jul 2005 20:14:21 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6T0F0Op098216; Thu, 28 Jul 2005 20:15:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D66297305C; Thu, 28 Jul 2005 20:15:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050729001500.D66297305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 20:15:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 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: Fri, 29 Jul 2005 00:15:03 -0000 From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 00:15:16 2005 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 3667316A42D; Fri, 29 Jul 2005 00:15:16 +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 C05DD43D53; Fri, 29 Jul 2005 00:15:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6T0F04X034248; Thu, 28 Jul 2005 20:15:00 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6T0F0ul098213; Thu, 28 Jul 2005 20:15:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A8C337304F; Thu, 28 Jul 2005 20:15:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050729001500.A8C337304F@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 20:15:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [releng_6 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: Fri, 29 Jul 2005 00:15:16 -0000 From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 00:30:04 2005 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 6A67716A41F; Fri, 29 Jul 2005 00:30:04 +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 54BE143D49; Fri, 29 Jul 2005 00:30:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j6T0U0m4034714; Thu, 28 Jul 2005 20:30:00 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6T0U0SA003294; Thu, 28 Jul 2005 20:30:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5B1697304F; Thu, 28 Jul 2005 20:30:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050729003000.5B1697304F@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 20:30:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [releng_6 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: Fri, 29 Jul 2005 00:30:04 -0000 From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 00:30:06 2005 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 0ED3716A425; Fri, 29 Jul 2005 00:30:06 +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 346D243D5F; Fri, 29 Jul 2005 00:30:01 +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.3/8.13.3) with ESMTP id j6T0U0oG034721; Thu, 28 Jul 2005 20:30:00 -0400 (EDT) (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 j6T0U0xR086888; Thu, 28 Jul 2005 20:30:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8798A7305C; Thu, 28 Jul 2005 20:30:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050729003000.8798A7305C@freebsd-current.sentex.ca> Date: Thu, 28 Jul 2005 20:30:00 -0400 (EDT) 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: Fri, 29 Jul 2005 00:30:06 -0000 From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 03:08:33 2005 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 1094E16A41F for ; Fri, 29 Jul 2005 03:08:33 +0000 (GMT) (envelope-from peter@larkowski.net) Received: from pm6500.larkowski.net (pcp08839268pcs.nanarb01.mi.comcast.net [68.43.120.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D2B643D45 for ; Fri, 29 Jul 2005 03:08:32 +0000 (GMT) (envelope-from peter@larkowski.net) Received: from [192.168.1.100] (powerbook [192.168.1.100]) by pm6500.larkowski.net (8.12.11/8.12.11) with ESMTP id j6T38Pl7001648 for ; Thu, 28 Jul 2005 23:08:31 -0400 (EDT) Message-ID: <42E99DA9.10306@larkowski.net> Date: Thu, 28 Jul 2005 23:08:25 -0400 From: Peter Larkowski User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: sym problems in 6.0-beta1 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, 29 Jul 2005 03:08:33 -0000 Hello: I've been using 5.X/i386 on my athlon64 due to the PAGE_SIZE problem with the sym driver in freebsd/AMD64. I noticed that the driver in -CURRENT had been updated and that specific problem fixed, so I tried 6.0-Beta1. Now I get panic: sym: VTOBUS FAILED! right after detection of the card. Any ideas? I only own scsi disks and I have 2 different symbios cards (an LSI Logic and a Tekram DC-390F), and they behave identically. Any ideas? Other system info: Amd Athlon64 3000, Asus A8V Deluxe motherboard. Let me know what else I can post to help. Thanks, Peter From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 04:40:20 2005 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 33EB616A41F for ; Fri, 29 Jul 2005 04:40:20 +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 D9C1B43D45 for ; Fri, 29 Jul 2005 04:40:19 +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 j6T4eJgf023245; Thu, 28 Jul 2005 21:40:19 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j6T4eJl3023244; Thu, 28 Jul 2005 21:40:19 -0700 Date: Thu, 28 Jul 2005 21:40:19 -0700 From: Brooks Davis To: Peter Larkowski Message-ID: <20050729044019.GA14121@odin.ac.hmc.edu> References: <42E99DA9.10306@larkowski.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <42E99DA9.10306@larkowski.net> 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: sym problems in 6.0-beta1 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, 29 Jul 2005 04:40:20 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 28, 2005 at 11:08:25PM -0400, Peter Larkowski wrote: > Hello: >=20 > I've been using 5.X/i386 on my athlon64 due to the PAGE_SIZE problem=20 > with the sym driver in freebsd/AMD64. I noticed that the driver in=20 > -CURRENT had been updated and that specific problem fixed, so I tried=20 > 6.0-Beta1. Now I get panic: sym: VTOBUS FAILED! right after detection=20 > of the card. Any ideas? I only own scsi disks and I have 2 different=20 > symbios cards (an LSI Logic and a Tekram DC-390F), and they behave=20 > identically. Any ideas? >=20 > Other system info: Amd Athlon64 3000, Asus A8V Deluxe motherboard. Let= =20 > me know what else I can post to help. I'm seeing the same issue with two different cards on one of my servers. I ended up using a spare machine, but eventually I'd like this to work so I can only have on non-work machine on. -- 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 --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC6bMyXY6L6fI4GtQRAuyTAJsFNkw0TjVEuqHBGLVCMUNWFFldiACgsE12 KZ3bBJGOUbuYMi1mDfzaKc4= =FPSt -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 05:17:02 2005 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 3CE7E16A41F for ; Fri, 29 Jul 2005 05:17: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 990F343D48 for ; Fri, 29 Jul 2005 05:17: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 D36F611EA4 for ; Thu, 28 Jul 2005 23:17:00 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 8779A11EA3 for ; Thu, 28 Jul 2005 23:17:00 -0600 (MDT) Date: Thu, 28 Jul 2005 23:16:59 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050728231659.36bdfcd5.kgunders@teamcool.net> In-Reply-To: <20050728193519.A66123@cons.org> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <20050728193519.A66123@cons.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: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 05:17:02 -0000 On Thu, 28 Jul 2005 19:35:19 -0400 Martin Cracauer wrote: > > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine > > and after applying the exact same configuration to the OS, Apache, PHP and > > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 > > bit to 32 bit caused the machine to double in speed. The results are attached > > in an Excel spreadsheet. So the exact same machine, running the identical > > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs > > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) > > I'm sorry but I cannot support these findings. I don't have > cut'n'paste numbers handy, but generally 64 bits speed up things quite > a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but > generally there is a speedup. > > Data is not generally doubled in size. Plain int stays the same in C. > Floating point stays the same. String stays the same. Arrays of ints > stay the same. But e.g. lists do not. In another context I just happened to be running some Apache Bench tests on a couple systems earlier today; 1) Dual opteron 246 w/4GB DDR400 ECC Registered Memory: Server Software: lighttpd/1.3.15 Server Hostname: typo.mydom.tld Server Port: 80 Document Path: / Document Length: 2846 bytes Concurrency Level: 1000 Time taken for tests: 13.998918 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 3065062 bytes HTML transferred: 2848846 bytes Requests per second: 71.43 [#/sec] (mean) Time per request: 13998.918 [ms] (mean) Time per request: 13.999 [ms] (mean, across all concurrent requests) Transfer rate: 213.80 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 2 1644 3065.3 2 9414 Processing: 330 2270 654.8 2181 4046 Waiting: 323 2267 654.9 2179 4042 Total: 477 3914 3442.4 2465 13445 2) And w/legacy 700 MHz PIII w/1GB PC100 Memory (or maybe its PC133, I don't exactly recall): $ ab -n 1000 -c 1000 http://typo.mydom.tld/ Server Software: lighttpd/1.3.15 Server Hostname: typo.mydom.tld Server Port: 80 Document Path: / Document Length: 7951 bytes Concurrency Level: 1000 Time taken for tests: 7.122140 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 8750272 bytes HTML transferred: 8493032 bytes Requests per second: 140.41 [#/sec] (mean) Time per request: 7122.140 [ms] (mean) Time per request: 7.122 [ms] (mean, across all concurrent requests) Transfer rate: 1199.78 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 2 434 1091.0 2 6205 Processing: 133 1036 295.6 1034 2152 Waiting: 130 788 209.6 805 1381 Total: 287 1471 1126.9 1108 7076 No efforts were made to optimize or tune anything. This is an ROR app running under FastCGI via Lighttpd proxied by Apache2. Lighttpd.conf spec'd max-procs=4. Both machines running FBSD-5.4-p5. Opteron box running amd64. Results are same w/wo the Apache proxy so it's not the bottleneck. FWIW we see that the lowly PIII serves up roughly 2x the requests/ second (w/larger requests even) than the "64 bit AMD Goliath". Of course the Opteron totally spanks the 700MHz on Ubench scores. Not trying to start any wars, just throwing this out for what it's worth since my quick tests just happened to concur with the timing of this thead.... -- 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 Jul 29 05:37:39 2005 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 A986116A41F for ; Fri, 29 Jul 2005 05:37:39 +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 47E9643D45 for ; Fri, 29 Jul 2005 05:37:36 +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.3/8.13.3) with ESMTP id j6T5kQTO018270; Thu, 28 Jul 2005 23:46:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E9C089.8030902@samsco.org> Date: Thu, 28 Jul 2005 23:37:13 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <42E99DA9.10306@larkowski.net> <20050729044019.GA14121@odin.ac.hmc.edu> In-Reply-To: <20050729044019.GA14121@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-amd64@freebsd.org Subject: Re: sym problems in 6.0-beta1 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, 29 Jul 2005 05:37:39 -0000 Brooks Davis wrote: > On Thu, Jul 28, 2005 at 11:08:25PM -0400, Peter Larkowski wrote: > >>Hello: >> >>I've been using 5.X/i386 on my athlon64 due to the PAGE_SIZE problem >>with the sym driver in freebsd/AMD64. I noticed that the driver in >>-CURRENT had been updated and that specific problem fixed, so I tried >>6.0-Beta1. Now I get panic: sym: VTOBUS FAILED! right after detection >>of the card. Any ideas? I only own scsi disks and I have 2 different >>symbios cards (an LSI Logic and a Tekram DC-390F), and they behave >>identically. Any ideas? >> >>Other system info: Amd Athlon64 3000, Asus A8V Deluxe motherboard. Let >>me know what else I can post to help. > > > I'm seeing the same issue with two different cards on one of my servers. > I ended up using a spare machine, but eventually I'd like this to work > so I can only have on non-work machine on. > Send some SYM cards my way and I'll make it work. Scott From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 07:24:14 2005 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 3939416A41F for ; Fri, 29 Jul 2005 07:24:14 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from e0-a11.b1.lan.prg.vol.cz (e0-a11.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8677A43D45 for ; Fri, 29 Jul 2005 07:24:13 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from pav.hide.vol.cz (localhost [127.0.0.1]) by e0-a11.b1.lan.prg.vol.cz (8.13.4/8.13.4) with ESMTP id j6T7OJX9066338; Fri, 29 Jul 2005 09:24:19 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by pav.hide.vol.cz (8.13.4/8.13.4/Submit) id j6T7OET2066337; Fri, 29 Jul 2005 09:24:14 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Ken Gunderson In-Reply-To: <20050728231659.36bdfcd5.kgunders@teamcool.net> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <20050728193519.A66123@cons.org> <20050728231659.36bdfcd5.kgunders@teamcool.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1bZ6ZCzkCcWddX7z51ek" Date: Fri, 29 Jul 2005 09:24:14 +0200 Message-Id: <1122621854.66245.0.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-amd64@FreeBSD.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2005 07:24:14 -0000 --=-1bZ6ZCzkCcWddX7z51ek Content-Type: text/plain; charset=ISO8859-2 Content-Transfer-Encoding: quoted-printable Ken Gunderson p=ED=B9e v =E8t 28. 07. 2005 v 23:16 -0600: > Document Path: / > Document Length: 2846 bytes > Document Path: / > Document Length: 7951 bytes Is it just my impression that you served two completely different websites in the test? Doesn't make it much trusty. --=20 Pav Lucistnik --=-1bZ6ZCzkCcWddX7z51ek Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC6dmentdYP8FOsoIRAvrlAJ497OY+48DY/LPkaCueuVAu94twkACgiM7p wzxSaFWODfE+kzHPWc+MZpQ= =0Vb6 -----END PGP SIGNATURE----- --=-1bZ6ZCzkCcWddX7z51ek-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 08:15:30 2005 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 95CEF16A41F for ; Fri, 29 Jul 2005 08:15:30 +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 3AF5143D45 for ; Fri, 29 Jul 2005 08:15:29 +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 54DC911EDB for ; Fri, 29 Jul 2005 02:15:29 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 3170B11EA3 for ; Fri, 29 Jul 2005 02:15:29 -0600 (MDT) Date: Fri, 29 Jul 2005 02:15:28 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050729021528.35d1a3e4.kgunders@teamcool.net> In-Reply-To: <1122621854.66245.0.camel@pav.hide.vol.cz> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <20050728193519.A66123@cons.org> <20050728231659.36bdfcd5.kgunders@teamcool.net> <1122621854.66245.0.camel@pav.hide.vol.cz> 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=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 08:15:30 -0000 On Fri, 29 Jul 2005 09:24:14 +0200 Pav Lucistnik wrote: > Ken Gunderson píše v čt 28. 07. 2005 v 23:16 -0600: > > > Document Path: / > > Document Length: 2846 bytes > > > Document Path: / > > Document Length: 7951 bytes > > Is it just my impression that you served two completely different > websites in the test? Doesn't make it much trusty. Not completely different. Same ROR app w/Identicle configuration on both machines. Same db backend. As I pointed out initially, the size of the requests on the i386 machine were larger (because that site actually has a bit of content), wh/ I doubt is responsible for the legacy hardware serving up approx. double the requests/sec. as the dual opteron. The ROR app is Typo. i386 front page (My 70 yr. father's 1st blog, please be merciful). The amd64 was just default front door w/ o any content. This wasn't intended as a scientific study. Like I said, it was just something I happened to be doing in another context and posted here since it fit the general profile of 2x that the op was reporting. I'm sure BOTH machines could do better but I was curoius about a +/- oob scenario. -- 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 Jul 29 08:32:42 2005 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 37B0816A41F for ; Fri, 29 Jul 2005 08:32:42 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E784643D46 for ; Fri, 29 Jul 2005 08:32:41 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 373B997D5D; Fri, 29 Jul 2005 01:32:36 -0700 (PDT) Message-Id: <3.0.1.32.20050729013240.00a8afb8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 29 Jul 2005 01:32:40 -0700 To: sean@mcneil.com,Martin Cracauer From: ray@redshift.com In-Reply-To: <1122594648.45827.11.camel@server.mcneil.com> References: <20050728193519.A66123@cons.org> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <20050728193519.A66123@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 08:32:42 -0000 At 04:50 PM 7/28/2005 -0700, Sean McNeil wrote: | On Thu, 2005-07-28 at 19:35 -0400, Martin Cracauer wrote: | > I highly suspect that the 64 bit version of FreeBSD in this | > comparision was somehow doomed before it started. Opportunities are | > leaving in kernel safety code in one of the kernels, a driver that | > just doesn't work right on AMD64. Or the same for any of the | > software, maybe php is hosed in its 64 bit build. | | If network throughput can effect the testing, I would suspect network | drivers. I've found the re0 driver performs horrible on amd64. | Especially with gigE. | | Cheers, | Sean Hi Sean, Testing was done via localhost. That should let out the broadcam gigabit card. Ray From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 09:06:07 2005 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 0EB1C16A41F for ; Fri, 29 Jul 2005 09:06:06 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F7B43D49 for ; Fri, 29 Jul 2005 09:06:06 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 5B62B979E0; Fri, 29 Jul 2005 02:06:05 -0700 (PDT) Message-Id: <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 29 Jul 2005 02:06:09 -0700 To: Martin Cracauer From: ray@redshift.com In-Reply-To: <20050728193519.A66123@cons.org> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 09:06:07 -0000 At 07:35 PM 7/28/2005 -0400, Martin Cracauer wrote: | > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine | > and after applying the exact same configuration to the OS, Apache, PHP and | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 | > bit to 32 bit caused the machine to double in speed. The results are attached | > in an Excel spreadsheet. So the exact same machine, running the identical | > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs | > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) | | I'm sorry but I cannot support these findings. I don't have | cut'n'paste numbers handy, but generally 64 bits speed up things quite | a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but | generally there is a speedup. Hi Martin - do you have any data to back up these statements? If so, I'd like to see it. I will have another AMD Dual Opteron in here in a month or so and will do some further benchmarks. In going over my notes, the only thing I can see that might have been a mistake was if I left out 'options SMP' from the AMD64 kernel config file. But I seem to recall you do not have to include that on AMD64 like you do with i386 - can anyone confirm this? I had to return the evaluation server, so I can't test it this second. As far as I call, the CPU's were launching properly under both installations however. When I have our next AMD Dual Opteron machine in here, I will re-run the tests. Ray From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 09:32:31 2005 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 8955916A41F for ; Fri, 29 Jul 2005 09:32:31 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3460143D45 for ; Fri, 29 Jul 2005 09:32:31 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 2CEC0979B6; Fri, 29 Jul 2005 02:32:30 -0700 (PDT) Message-Id: <3.0.1.32.20050729023234.00a8afb8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 29 Jul 2005 02:32:34 -0700 To: Martin Cracauer From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 09:32:31 -0000 At 07:35 PM 7/28/2005 -0400, Martin Cracauer wrote: | > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine | > and after applying the exact same configuration to the OS, Apache, PHP and | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 | > bit to 32 bit caused the machine to double in speed. The results are attached | > in an Excel spreadsheet. So the exact same machine, running the identical | > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs | > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) | | I'm sorry but I cannot support these findings. I don't have | cut'n'paste numbers handy, but generally 64 bits speed up things quite | a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but | generally there is a speedup. On the AMD64, I am pretty sure that I did *not* include the following lines like I normally do on the i386: options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC I seem to remember on one of the first AMD64 installs I did, the apic line produced some sort of compiler error. However, in looking over the AMD64 branch on another machine (with 5.3 on it), I do see there is a SMP config file that includes the GENERIC conf file and then tags on options SMP. So this may be a problem in my benchmarks and I will have to repeat the tests when I have another Dual Opteron server down here. For whatever reason, I was under the impression the AMD64 kernel config file supported SMP by default, but now I'm wondering. Ray From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 11:02:06 2005 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 504AA16A41F for ; Fri, 29 Jul 2005 11:02:06 +0000 (GMT) (envelope-from uidzero@bsdhacker.org) Received: from smtp2.suscom.net (smtp2.suscom.net [64.78.83.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8229B43D46 for ; Fri, 29 Jul 2005 11:02:05 +0000 (GMT) (envelope-from uidzero@bsdhacker.org) Received: from localhost (smtp2.suscom.net [127.0.0.1]) by smtp2.suscom.net (Postfix) with ESMTP id D99FB1CDCF0; Fri, 29 Jul 2005 06:53:46 -0400 (EDT) Received: from smtp2.suscom.net ([127.0.0.1]) by localhost (smtp2 [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 15954-02; Fri, 29 Jul 2005 06:53:43 -0400 (EDT) Received: from [216.45.135.174] (ip174.135.45.216.susc.suscom.net [216.45.135.174]) by smtp2.suscom.net (Postfix) with SMTP id A4CE91CD853; Fri, 29 Jul 2005 06:53:42 -0400 (EDT) Message-ID: <42EA0CA7.8080605@bsdhacker.org> Date: Fri, 29 Jul 2005 06:01:59 -0500 From: uidzero User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ray@redshift.com References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> In-Reply-To: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at suscom.net Cc: freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 11:02:06 -0000 ray@redshift.com wrote: >Freebsd-AMD64 list: > >I recently completed benchmarking an evaluation server provided to us by our >hardware vendor in order to see if switching our cluster from Xeon based >machines to AMD based machines was worth while/cost effective > >The machine provided was a Dual Opteron 246 using the Tyan S2881 motherboard. >It had 4GB or ram and included a single SATA hard drive. > >I initially loaded FreeBSD 5.4 AMD64 on the machine, recompiled the kernel, etc. >and applied all the normal tweaks to apache, PHP, etc. The machine, while >faster than our single 2.4 Ghz Xeon's, wasn't all that much faster (maybe only >10 to 15 percent). > >After speaking with AMD and doing further benchmarks, I was about to give up on >AMD and return the machine. However, at the last minute, an engineer from AMD >suggested that perhaps loading the 32 bit version of FreeBSD (aka i386) might >improve performance, since it was possible that the overhead from 64 bit >pointers was causing the machine to run slower than expected. He also explained >that the AMD should be running about 3 to 4 times faster than the single Xeon. > >While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine >and after applying the exact same configuration to the OS, Apache, PHP and >MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS from 64 >bit to 32 bit caused the machine to double in speed. The results are attached >in an Excel spreadsheet. So the exact same machine, running the identical >configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs >FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) > >In speaking with one person off the list here, I was told that the FreeBSD AMD64 >branch has actually been cleaned up substantially over the i386 code. So >naturally I was expecting much better performance from a 64 bit machine running >the AMD64 code than the "older" i386 code. I had also originally expected that >since this branch [the AMD64 branch] was specifically built around the AMD >CPU's, that it should run the best (and thus the fastest) on the AMD opteron >CPU's. However, just the contrary turned out to be the case in benchmarking. > >I'm wondering if anyone has any comments or thoughts on this? The attached >benchmarks show transactions per second across localhost using Apache AB on the >same machine. The first tests are with plain text files from 64 bytes to 50K in >size. The next group is using a small and medium size PHP program. The final >set relate to MySQL inserts, selects and updates. As you can see from the data, >the exact same machine runs about twice as fast just by switching the OS from >AMD64 to i386. But why? > >The only answer I have so far as to why this may be the case is that perhaps >i386 uses 32 bit pointers which the CPU(s) can handle faster (thus less overhead >for the CPU). But it still seems odd to me that if FreeBSD AMD64 is written >specifically for the 64 bit CPU, why doesn't the machine perform better when >running it? > >I'm also wondering if there is a compiler switch on AMD64 that could be used >(perhaps in /etc/make.conf or something) that would force the AMD64 version to >run in 32 bit mode only - since that would be an interesting comparison as well. > >I welcome any/all comments, suggestions, insight. > >Thanks. > >Ray > > Good morning. I'm very NEW to the list and NEW to 64bit systems. I installed 5.4-R (i386) on my dual AMD64 Opteron 2.0g (1mb cache) with 1g ram and 4 X 160 (raid10) sata drives server. I was blazing fast, I think the first kernel recompile was 10 minutes or so "time make buildkernel KERNCONF=KERNEL" I was shocked to see how fast it was. (I know you tested with php/etc...) Well, like an idiot, I was thinking I could use the i386 install disc to get the 64bit. Eh.. no go. I then grabbed the boot only 64bit from FreeBSD's ftp site and loaded it. Base install of course. When I did the "first compile" I yet again. was surprised. 6:29:xx!!! Fastest I've ever seen a kernel compile and that was with ONE cpu. (Had to compile in SMP.) Man, never had a system that was this fast. Needless to say, I think the 64bit out performs the 32bit OSes. Then again, I'm not as technical as most of you all are, I'm just chimming in from a "different" side. Please, put me in my place if need be. :) Michael From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 12:38:47 2005 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 1725F16A41F for ; Fri, 29 Jul 2005 12:38:47 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4112A43D45 for ; Fri, 29 Jul 2005 12:38:46 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j6TCcinG078507; Fri, 29 Jul 2005 14:38:44 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j6TCcicR078506; Fri, 29 Jul 2005 08:38:44 -0400 (EDT) (envelope-from cracauer) Date: Fri, 29 Jul 2005 08:38:44 -0400 From: Martin Cracauer To: ray@redshift.com Message-ID: <20050729083844.A78480@cons.org> References: <3.0.1.32.20050729023234.00a8afb8@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3.0.1.32.20050729023234.00a8afb8@pop.redshift.com>; from ray@redshift.com on Fri, Jul 29, 2005 at 02:32:34AM -0700 Cc: Martin Cracauer , freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 12:38:47 -0000 ray@redshift.com wrote on Fri, Jul 29, 2005 at 02:32:34AM -0700: > At 07:35 PM 7/28/2005 -0400, Martin Cracauer wrote: > | > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine > | > and after applying the exact same configuration to the OS, Apache, PHP and > | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS > from 64 > | > bit to 32 bit caused the machine to double in speed. The results are attached > | > in an Excel spreadsheet. So the exact same machine, running the identical > | > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs > | > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) > | > | I'm sorry but I cannot support these findings. I don't have > | cut'n'paste numbers handy, but generally 64 bits speed up things quite > | a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but > | generally there is a speedup. > > On the AMD64, I am pretty sure that I did *not* include the following lines like > I normally do on the i386: > > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC I occurse to me that not using one of the two CPUs might have something to do with a performance drop of approximately 50% :-) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 12:43:30 2005 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 6797116A425 for ; Fri, 29 Jul 2005 12:43:30 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6EF243D49 for ; Fri, 29 Jul 2005 12:43:29 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j6TChShb078617; Fri, 29 Jul 2005 14:43:28 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j6TChSHv078616; Fri, 29 Jul 2005 08:43:28 -0400 (EDT) (envelope-from cracauer) Date: Fri, 29 Jul 2005 08:43:28 -0400 From: Martin Cracauer To: ray@redshift.com Message-ID: <20050729084328.B78480@cons.org> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <20050728193519.A66123@cons.org> <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3.0.1.32.20050729020609.00a6a240@pop.redshift.com>; from ray@redshift.com on Fri, Jul 29, 2005 at 02:06:09AM -0700 Cc: Martin Cracauer , freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 12:43:30 -0000 ray@redshift.com wrote on Fri, Jul 29, 2005 at 02:06:09AM -0700: > At 07:35 PM 7/28/2005 -0400, Martin Cracauer wrote: > | > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine > | > and after applying the exact same configuration to the OS, Apache, PHP and > | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS > from 64 > | > bit to 32 bit caused the machine to double in speed. The results are attached > | > in an Excel spreadsheet. So the exact same machine, running the identical > | > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs > | > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) > | > | I'm sorry but I cannot support these findings. I don't have > | cut'n'paste numbers handy, but generally 64 bits speed up things quite > | a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but > | generally there is a speedup. > > Hi Martin - do you have any data to back up these statements? If so, I'd like > to see it. I didn't keep my own benchmarks. However, the Linux section on anandtech has a good deal of such benchmarks: http://www.anandtech.com/linux/ http://www.anandtech.com/linux/showdoc.aspx?i=2158 http://www.anandtech.com/linux/showdoc.aspx?i=2127 http://www.anandtech.com/linux/showdoc.aspx?i=2114 linuxhardware.com also has at least one article comparing 32 and 64 bit applications on the same box. If you could kindly fix the NILs I get for numbers out of the new CMUCL or at least the string lookup in SBCL I could go set up my quad-boot opteron and get all the benchmarks we want :-) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 12:43:35 2005 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 AB56F16A433 for ; Fri, 29 Jul 2005 12:43:35 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FF8F43D4C for ; Fri, 29 Jul 2005 12:43:35 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id CB4FE97A03; Fri, 29 Jul 2005 05:43:34 -0700 (PDT) Message-Id: <3.0.1.32.20050729054336.00a67578@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 29 Jul 2005 05:43:36 -0700 To: Martin Cracauer From: ray@redshift.com In-Reply-To: <20050729083844.A78480@cons.org> References: <3.0.1.32.20050729023234.00a8afb8@pop.redshift.com> <3.0.1.32.20050729023234.00a8afb8@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Martin Cracauer , freebsd-amd64@freebsd.org Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 12:43:35 -0000 At 08:38 AM 7/29/2005 -0400, Martin Cracauer wrote: | ray@redshift.com wrote on Fri, Jul 29, 2005 at 02:32:34AM -0700: | > At 07:35 PM 7/28/2005 -0400, Martin Cracauer wrote: | > | > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine | > | > and after applying the exact same configuration to the OS, Apache, PHP and | > | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS | > from 64 | > | > bit to 32 bit caused the machine to double in speed. The results are attached | > | > in an Excel spreadsheet. So the exact same machine, running the identical | > | > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs | > | > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) | > | | > | I'm sorry but I cannot support these findings. I don't have | > | cut'n'paste numbers handy, but generally 64 bits speed up things quite | > | a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but | > | generally there is a speedup. | > | > On the AMD64, I am pretty sure that I did *not* include the following lines like | > I normally do on the i386: | > | > options SMP # Symmetric MultiProcessor Kernel | > device apic # I/O APIC | | I occurse to me that not using one of the two CPUs might have | something to do with a performance drop of approximately 50% :-) | | Martin :-) Stay tuned for "son of benchmarks" when I get our next Dual Opteron 246 in here! This may be operator, not "opteron" error after all - hehe :) Ray From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 17:35:46 2005 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 4249116A41F for ; Fri, 29 Jul 2005 17:35:46 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E75A243D48 for ; Fri, 29 Jul 2005 17:35:45 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id C800D2A8F3 for ; Fri, 29 Jul 2005 10:35:45 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 56577E2B3 for ; Fri, 29 Jul 2005 10:35:45 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.4) with ESMTP id j6THZffx058062; Fri, 29 Jul 2005 10:35:41 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id j6THZWIC058055; Fri, 29 Jul 2005 10:35:32 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Fri, 29 Jul 2005 10:35:31 -0700 User-Agent: KMail/1.8.1 References: <20050727.154329.71086249.chat95@mac.com> <20050727.171303.78703474.chat95@mac.com> <20050727.172253.112627901.chat95@mac.com> In-Reply-To: <20050727.172253.112627901.chat95@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507291035.31851.peter@wemm.org> Cc: Subject: Re: iommu flushing problem? (Re: Tyan S2885 Thunder K8W lockups) 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, 29 Jul 2005 17:35:46 -0000 On Wednesday 27 July 2005 01:22 am, NAKATA Maho wrote: > I found a simular issue > http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/0937.html > iommu flushing problem? FreeBSD doesn't use any of the iommu stuff. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 19:10:56 2005 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 C822016A420 for ; Fri, 29 Jul 2005 19:10:56 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9990F43D4C for ; Fri, 29 Jul 2005 19:10:53 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 8A049B869 for ; Fri, 29 Jul 2005 15:10:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <1122594648.45827.11.camel@server.mcneil.com> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <20050728193519.A66123@cons.org> <1122594648.45827.11.camel@server.mcneil.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-475646239; protocol="application/pkcs7-signature" Message-Id: From: Vivek Khera Date: Fri, 29 Jul 2005 15:10:50 -0400 To: freebsd-amd64 List X-Mailer: Apple Mail (2.733) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 19:10:56 -0000 --Apple-Mail-8-475646239 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 28, 2005, at 7:50 PM, Sean McNeil wrote: > On Thu, 2005-07-28 at 19:35 -0400, Martin Cracauer wrote: > >> I highly suspect that the 64 bit version of FreeBSD in this >> comparision was somehow doomed before it started. Opportunities are >> leaving in kernel safety code in one of the kernels, a driver that >> just doesn't work right on AMD64. Or the same for any of the >> software, maybe php is hosed in its 64 bit build. >> > > If network throughput can effect the testing, I would suspect network > drivers. I've found the re0 driver performs horrible on amd64. > Especially with gigE. The OP used a S2881 mobo, which has a bge ethernet. I've had nothing but bad luck with that in FreeBSD/amd64. I put in some intel NICs and everything got better and more stable. Vivek Khera, Ph.D. +1-301-869-4449 x806 --Apple-Mail-8-475646239-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 29 21:47:16 2005 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 3BE9016A41F for ; Fri, 29 Jul 2005 21:47:16 +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 D5C9943D45 for ; Fri, 29 Jul 2005 21:47:15 +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 86C9011EA4 for ; Fri, 29 Jul 2005 15:47:14 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 4F24311EA3 for ; Fri, 29 Jul 2005 15:47:14 -0600 (MDT) Date: Fri, 29 Jul 2005 15:47:13 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050729154713.48b3fe08.kgunders@teamcool.net> In-Reply-To: <20050729083844.A78480@cons.org> References: <3.0.1.32.20050729023234.00a8afb8@pop.redshift.com> <20050729083844.A78480@cons.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: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 29 Jul 2005 21:47:16 -0000 On Fri, 29 Jul 2005 08:38:44 -0400 Martin Cracauer wrote: > ray@redshift.com wrote on Fri, Jul 29, 2005 at 02:32:34AM -0700: > > At 07:35 PM 7/28/2005 -0400, Martin Cracauer wrote: > > | > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine > > | > and after applying the exact same configuration to the OS, Apache, PHP and > > | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS > > from 64 > > | > bit to 32 bit caused the machine to double in speed. The results are attached > > | > in an Excel spreadsheet. So the exact same machine, running the identical > > | > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs > > | > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) > > | > > | I'm sorry but I cannot support these findings. I don't have > > | cut'n'paste numbers handy, but generally 64 bits speed up things quite > > | a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but > > | generally there is a speedup. > > > > On the AMD64, I am pretty sure that I did *not* include the following lines like > > I normally do on the i386: > > > > options SMP # Symmetric MultiProcessor Kernel > > device apic # I/O APIC > > I occurse to me that not using one of the two CPUs might have > something to do with a performance drop of approximately 50% :-) Not to beat a dead horse here, but for the record, the numbers I reported were definitely for a SMP kernel. -- 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 Jul 30 01:06:42 2005 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 1C49016A41F; Sat, 30 Jul 2005 01:06:42 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0C9E43D46; Sat, 30 Jul 2005 01:06:41 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j6U16flh099650; Sat, 30 Jul 2005 01:06:41 GMT (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j6U16dc9099646; Sat, 30 Jul 2005 01:06:39 GMT (envelope-from kris) Date: Sat, 30 Jul 2005 01:06:39 GMT From: Kris Kennaway Message-Id: <200507300106.j6U16dc9099646@freefall.freebsd.org> To: morgothdbma@o2.pl, kris@FreeBSD.org, freebsd-amd64@FreeBSD.org Cc: Subject: Re: amd64/82176: ehci causes crash on 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, 30 Jul 2005 01:06:42 -0000 Synopsis: ehci causes crash on amd64 State-Changed-From-To: feedback->closed State-Changed-By: kris State-Changed-When: Sat Jul 30 01:06:28 GMT 2005 State-Changed-Why: Feedback timeout http://www.freebsd.org/cgi/query-pr.cgi?pr=82176 From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 30 05:19:18 2005 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 5561A16A41F; Sat, 30 Jul 2005 05:19:18 +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 EBCC343D49; Sat, 30 Jul 2005 05:19:17 +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.3/8.13.3) with ESMTP id j6U5IZso040232; Sat, 30 Jul 2005 01:18:35 -0400 (EDT) (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.3/8.13.3) with ESMTP id j6U5JGhZ084852; Sat, 30 Jul 2005 01:19:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B89717304D; Sat, 30 Jul 2005 01:19:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050730051916.B89717304D@freebsd-current.sentex.ca> Date: Sat, 30 Jul 2005 01:19:16 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner5 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [releng_6 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, 30 Jul 2005 05:19:18 -0000 TB --- 2005-07-30 03:32:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-07-30 03:32:12 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2005-07-30 03:32:12 - cleaning the object tree TB --- 2005-07-30 03:32:46 - checking out the source tree TB --- 2005-07-30 03:32:46 - cd /tinderbox/RELENG_6/amd64/amd64 TB --- 2005-07-30 03:32:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2005-07-30 03:41:06 - building world (CFLAGS=-O -pipe) TB --- 2005-07-30 03:41:06 - cd /src TB --- 2005-07-30 03:41:06 - /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 --- 2005-07-30 05:06:53 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-07-30 05:06:53 - cd /src TB --- 2005-07-30 05:06:53 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jul 30 05:06:54 UTC 2005 >>> 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 [...] touch export_syms awk -f /src/sys/modules/ips/../../conf/kmod_syms.awk ips.ko.debug export_syms | xargs -J% objcopy % ips.ko.debug objcopy --strip-debug ips.ko.debug ips.ko ===> ipw (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /obj/amd64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -fno-omit-frame-pointer -I/obj/amd64/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/ipw/../../dev/ipw/if_ipw.c /src/sys/modules/ipw/../../dev/ipw/if_ipw.c: In function `ipw_newstate': /src/sys/modules/ipw/../../dev/ipw/if_ipw.c:845: warning: passing arg 1 of `ieee80211_node_authorize' from incompatible pointer type /src/sys/modules/ipw/../../dev/ipw/if_ipw.c:845: error: too many arguments to function `ieee80211_node_authorize' *** Error code 1 Stop in /src/sys/modules/ipw. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-07-30 05:19:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-07-30 05:19:16 - ERROR: failed to build generic kernel TB --- 2005-07-30 05:19:16 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 30 07:22:20 2005 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 0D2B716A41F for ; Sat, 30 Jul 2005 07:22:20 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F23443D4C for ; Sat, 30 Jul 2005 07:22:19 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 89E3897B1A; Sat, 30 Jul 2005 00:22:18 -0700 (PDT) Message-Id: <3.0.1.32.20050730002225.00a718a0@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Sat, 30 Jul 2005 00:22:25 -0700 To: Ken Gunderson ,freebsd-amd64@freebsd.org From: ray@redshift.com In-Reply-To: <20050729154713.48b3fe08.kgunders@teamcool.net> References: <20050729083844.A78480@cons.org> <3.0.1.32.20050729023234.00a8afb8@pop.redshift.com> <20050729083844.A78480@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Benchmarks: AMD64 vs i386 on Dual 246 Opteron 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, 30 Jul 2005 07:22:20 -0000 At 03:47 PM 7/29/2005 -0600, Ken Gunderson wrote: | On Fri, 29 Jul 2005 08:38:44 -0400 | Martin Cracauer wrote: | | > ray@redshift.com wrote on Fri, Jul 29, 2005 at 02:32:34AM -0700: | > > At 07:35 PM 7/28/2005 -0400, Martin Cracauer wrote: | > > | > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine | > > | > and after applying the exact same configuration to the OS, Apache, PHP and | > > | > MySQL, re-ran the benchmarks. Much to my surprise, just changing the OS | > > from 64 | > > | > bit to 32 bit caused the machine to double in speed. The results are attached | > > | > in an Excel spreadsheet. So the exact same machine, running the identical | > > | > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs | > > | > FreeBSD 5.4 AMD64. Something about this seems so wrong to me :-) | > > | | > > | I'm sorry but I cannot support these findings. I don't have | > > | cut'n'paste numbers handy, but generally 64 bits speed up things quite | > > | a bit for me. I have seen slowdown in 64 bit mode in e.g. bzip2 but | > > | generally there is a speedup. | > > | > > On the AMD64, I am pretty sure that I did *not* include the following lines like | > > I normally do on the i386: | > > | > > options SMP # Symmetric MultiProcessor Kernel | > > device apic # I/O APIC | > | > I occurse to me that not using one of the two CPUs might have | > something to do with a performance drop of approximately 50% :-) | | Not to beat a dead horse here, but for the record, the numbers I | reported were definitely for a SMP kernel. | | -- | Best regards, | | Ken Gunderson | I'm going to have to repeat my benchmarks again on the AMD when our actual machine shows up (I was testing on an evaluation machine that had to be sent back). I'll post the info again and this time will make absolutely sure the AMD kernel is configured specifically with SMP - even though I seem to remember adding that line, I can't be sure now because the machine is gone and I erased the configuration. Ray From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 30 07:39:56 2005 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 71E8316A41F for ; Sat, 30 Jul 2005 07:39:56 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from amd64.molecon.ru (amd64.molecon.ru [213.219.245.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id F03E143D45 for ; Sat, 30 Jul 2005 07:39:53 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from [194.154.84.49] (helo=[10.20.5.22]) by amd64.molecon.ru with esmtp (Exim 4.51 (FreeBSD)) id 1Dylwi-000ChB-7T for freebsd-amd64@freebsd.org; Sat, 30 Jul 2005 11:39:48 +0400 Date: Sat, 30 Jul 2005 11:39:27 +0400 From: Oleg Rusanov X-Mailer: The Bat! (v3.0) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <1812296880.20050730113927@molecon.ru> To: freebsd-amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: freebsd-amd64@molecon.ru, freebsd-opennet@molecon.ru, freebsd-security@molecon.ru, info@molecon.ru, mysql@molecon.ru, oleg@molecon.ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - amd64.molecon.ru X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - molecon.ru X-Source: X-Source-Args: X-Source-Dir: Subject: Mysql 4.1. my-large.cnf or my-medium.cnf? Dual Opteron web server 2gb memory X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2005 07:39:56 -0000 Hello. my-large.cnf is twice quicklier, but the description from my-medium.cnf is approaches (such as a web server). It is necessary that Mysql worked twice more slowly on a web server? amd64# uname -r 5.4-STABLE make WITH_XCHARSET=all BUILD_OPTIMIZED=yes BUILD_STATIC=yes install --------------------------my-medium.cnf-------------------------------------- description: # This is for a system with little memory (32M - 64M) where MySQL plays # an important part, or systems up to 128M where MySQL is used together with # other programs (such as a web server) test: Query Barrel Report for client smacker1 connect: max=4ms min=2ms avg= 2ms from 10 clients Query_type num_queries max_time min_time q_per_s select_index 20000 0 0 11858.11 --------------------------/my-medium.cnf-------------------------------------- --------------------------my-large.cnf-------------------------------------- description: # This is for a large system with memory = 512M where the system runs mainly # MySQL. test: Query Barrel Report for client smacker1 connect: max=4ms min=2ms avg= 2ms from 10 clients Query_type num_queries max_time min_time q_per_s select_index 20000 0 0 21777.24 --------------------------/my-large.cnf-------------------------------------- -- Regards, Oleg Rusanov Molecon mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 30 16:26:53 2005 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 4B88516A41F for ; Sat, 30 Jul 2005 16:26: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 E82BF43D45 for ; Sat, 30 Jul 2005 16:26: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 2A99411EA4 for ; Sat, 30 Jul 2005 10:26:52 -0600 (MDT) Received: from [192.168.1.112] (unknown [192.168.1.112]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id E543611EA3 for ; Sat, 30 Jul 2005 10:26:51 -0600 (MDT) Message-ID: <42EBAA45.6020400@teamcool.net> Date: Sat, 30 Jul 2005 10:26:45 -0600 From: Ken Gunderson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <1812296880.20050730113927@molecon.ru> In-Reply-To: <1812296880.20050730113927@molecon.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Mysql 4.1. my-large.cnf or my-medium.cnf? Dual Opteron web server 2gb memory 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, 30 Jul 2005 16:26:53 -0000 Oleg Rusanov wrote: > Hello. > my-large.cnf is twice quicklier, but the description from > my-medium.cnf is approaches (such as a web server). > It is necessary that Mysql worked twice more slowly on a web server? > > amd64# uname -r > 5.4-STABLE > make WITH_XCHARSET=all BUILD_OPTIMIZED=yes BUILD_STATIC=yes install > > --------------------------my-medium.cnf-------------------------------------- > description: > # This is for a system with little memory (32M - 64M) where MySQL plays > # an important part, or systems up to 128M where MySQL is used together with > # other programs (such as a web server) > > test: > Query Barrel Report for client smacker1 > connect: max=4ms min=2ms avg= 2ms from 10 clients > Query_type num_queries max_time min_time q_per_s > select_index 20000 0 0 11858.11 > > --------------------------/my-medium.cnf-------------------------------------- > > --------------------------my-large.cnf-------------------------------------- > description: > # This is for a large system with memory = 512M where the system runs mainly > # MySQL. > > test: > Query Barrel Report for client smacker1 > connect: max=4ms min=2ms avg= 2ms from 10 clients > Query_type num_queries max_time min_time q_per_s > select_index 20000 0 0 21777.24 > --------------------------/my-large.cnf-------------------------------------- > These are just some example suggestions that have been included since forever w/the MySQL distribution. There is certainly nothing about them that is written in stone. If you have the RAM, and you probably most certainly do on any modern system, use start off with my-large.cnf Regards-- kvg