From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 31 11:14:39 2005 Return-Path: X-Original-To: freebsd-amd64@www.freebsd.org Delivered-To: freebsd-amd64@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 414A816A41F for ; Sun, 31 Jul 2005 11:14:39 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id D99B643D46 for ; Sun, 31 Jul 2005 11:14:38 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [134.93.180.218] (edda.Physik.Uni-Mainz.DE [134.93.180.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 3892A3000686 for ; Sun, 31 Jul 2005 13:14:37 +0200 (CEST) Message-ID: <42ECB269.4030206@mail.uni-mainz.de> Date: Sun, 31 Jul 2005 13:13:45 +0200 From: "O. Hartmann" Organization: Institut =?ISO-8859-15?Q?f=FCr_Geophysik?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@www.freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: Subject: OpenOffice2.0 64Bit ready? 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, 31 Jul 2005 11:14:39 -0000 Dear Sirs. I do not follow up everything written herein, so my question may sound stupid. On my FreeBSD 6.0 AMD64 box I run a 'clean' 64 Bit FreeBSD 6.0 (no 32Bit compatibility). I want to use OpenOffice from time to time reading Word or Excel documents. Can we compile and run OO 2.0 without 32 Bit compatibility enabled? I know this implies 64Bit clean code, so the major question would be whether OO 2 is 64 Bit clean or not. Thanks for your answers, Oliver From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 31 12:56: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 393BD16A41F for ; Sun, 31 Jul 2005 12:56:58 +0000 (GMT) (envelope-from dystopianrebel@yahoo.com) Received: from web52310.mail.yahoo.com (web52310.mail.yahoo.com [206.190.48.153]) by mx1.FreeBSD.org (Postfix) with SMTP id AB51443D46 for ; Sun, 31 Jul 2005 12:56:57 +0000 (GMT) (envelope-from dystopianrebel@yahoo.com) Received: (qmail 85925 invoked by uid 60001); 31 Jul 2005 12:56:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bXNoTRCr0bFwu5WuByp0rEz2gk016Iv5ZDK9p68wbaGhW95nNqQAxnGZEPhTsvKltQpypjzBrwOrXjq2i0Gn+dp7G+Lg4gQz5nkgUQTXrSOzPkcV8vS3hE3gaydXA3glbOpN+uXL+4ZefTgiLkIPS3deupRiMbroqpsplA2zdME= ; Message-ID: <20050731125657.85923.qmail@web52310.mail.yahoo.com> Received: from [64.26.160.170] by web52310.mail.yahoo.com via HTTP; Sun, 31 Jul 2005 05:56:57 PDT Date: Sun, 31 Jul 2005 05:56:57 -0700 (PDT) From: dR To: freebsd-amd64@freebsd.org In-Reply-To: <20050731120013.9D6D316A421@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: OpenOffice2.0 64Bit ready? 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, 31 Jul 2005 12:56:58 -0000 Oliver, OO is not 64-bit clean, according to the responses that I received when I've asked about OO here. I am using FreeBSD 5.4 Release. In 6.0, where you able to compile Java without any problems? Particularly, the "long-command error"? Marko Ottawa - - - From: "O. Hartmann" Subject: OpenOffice2.0 64Bit ready? Dear Sirs. I do not follow up everything written herein, so my question may sound stupid. On my FreeBSD 6.0 AMD64 box I run a 'clean' 64 Bit FreeBSD 6.0 (no 32Bit compatibility). I want to use OpenOffice from time to time reading Word or Excel documents. Can we compile and run OO 2.0 without 32 Bit compatibility enabled? I know this implies 64Bit clean code, so the major question would be whether OO 2 is 64 Bit clean or not. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 31 17:37:18 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 59ED216A41F for ; Sun, 31 Jul 2005 17:37:18 +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 0471743D4C for ; Sun, 31 Jul 2005 17:37: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 CB22711EA4 for ; Sun, 31 Jul 2005 11:37:12 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 94CD911EA3 for ; Sun, 31 Jul 2005 11:37:12 -0600 (MDT) Date: Sun, 31 Jul 2005 11:37:09 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050731113709.73cead31.kgunders@teamcool.net> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: TYAN Transport TA26 (B2882) BIOS V3.03 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, 31 Jul 2005 17:37:18 -0000 Greetings Fellow TA26 People: Just noticed this at Tyan's website dated 07/08/05: TYAN Transport TA26 (B2882) BIOS V3.03: New features and Fixes : * Fixed the Peepercon's USB KVM hang issue * Implemented AMD recommend for if 4 or more DDR400 DIMM's are used, then the DDR speed is forced to DDR333 by default * Auto detect and added support for SMDC M3289 and * M3290 cards. * Implemented AMD erratum 123. * Fixed DualCore CPU H/W Mem Remap issue * Added IPMI Over Lan selectable itmes * [82551]/[BCM5704] * Fixed a Bank Interleaving function issue * Fixed AMD PowerNow! implementation issues * Fixed the reporting of CPU1 Vcore & CPU2 Vcore values Okay, it's the 4 or more DIMMS that caught my eye. Especially since on a previous occassion they had specifically recommended Opteron 246 or faster for use with DDR400. So now if I ugrade to the latest BIOS my 4x1GB sticks of DDR400 will be forced to run at DDR333 speeds. Fantastic!! Just what I always wanted. AMD ROCKS!! Market CPU's as supporting DDR400 then force us to run at DDR333 when you realize you screwed up! And then there's the bank interleaving issue.... I am curious what other TA26 owners seeing/ doing? My systems are still at v3.01 and running single core 246's w/4x1GB sticks of DDR400 ECC Reg. I've seen a KVM hang or two (but then I'm using PS2 not USB KVM....). Other than staying away from the know issues w/ the flakey built in Broadcom's I've not been having any problems. However, these systems have yet to be really stressed. TIA- -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 1 11:01: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 9EC4F16A42C for ; Mon, 1 Aug 2005 11:01:53 +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 6114A43D48 for ; Mon, 1 Aug 2005 11:01:53 +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 j71B1rLf017107 for ; Mon, 1 Aug 2005 11:01:53 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j71B1q0i017100 for freebsd-amd64@freebsd.org; Mon, 1 Aug 2005 11:01:52 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Aug 2005 11:01:52 GMT Message-Id: <200508011101.j71B1q0i017100@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, 01 Aug 2005 11:01:53 -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 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 34 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 Aug 1 18:25: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 D50E716A41F; Mon, 1 Aug 2005 18:25:45 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id C139243D46; Mon, 1 Aug 2005 18:25:44 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 6FB1DEB4A2C; Tue, 2 Aug 2005 02:25:40 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 119601379BC; Tue, 2 Aug 2005 02:25:36 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85075-20; Tue, 2 Aug 2005 02:25:23 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id EA36913762A; Tue, 2 Aug 2005 02:25:18 +0800 (CST) Date: Tue, 2 Aug 2005 02:25:18 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050801182518.GA85423@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: obrien@FreeBSD.org Subject: [RFC] Port of NetBSD's optimized amd64 string code 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, 01 Aug 2005 18:25:46 -0000 --EuxKj2iCbKjpUGkD Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Guys, Here is a patchset that I have produced to make our libc aware of the NetBSD assembly implementation of the string related operations. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-libc::amd64-string" Content-Transfer-Encoding: quoted-printable Index: Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libc/amd64/string/Makefile.inc,v retrieving revision 1.5 diff -u -r1.5 Makefile.inc --- Makefile.inc 10 Apr 2005 18:58:49 -0000 1.5 +++ Makefile.inc 1 Aug 2005 18:18:29 -0000 @@ -1,4 +1,5 @@ # $FreeBSD: src/lib/libc/amd64/string/Makefile.inc,v 1.5 2005/04/10 18:58:= 49 alc Exp $ =20 -MDSRCS+=3D bcmp.S bcopy.S bzero.S memcmp.S memcpy.S memmove.S memset.S \ - strcat.S strcmp.S strcpy.S +MDSRCS+=3D bcmp.S bcopy.S bzero.S ffs.S index.S memchr.S memcmp.S memcpy.S= \ + memmove.S memset.S rindex.S strcat.S strchr.S strcmp.S strcpy.S \ + strlen.S strncmp.S strrchr.S swab.S Index: ffs.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: ffs.S diff -N ffs.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ ffs.S 1 Aug 2005 17:54:04 -0000 @@ -0,0 +1,22 @@ +/* + * Written by J.T. Conklin . + * Public domain. + * Adapted for NetBSD/x86_64 by Frank van der Linden + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: ffs.S,v 1.2 2003/07/26 19:24:38 salo Exp $") +#endif + +ENTRY(ffs) + bsfl %edi,%eax + jz L1 /* ZF is set if all bits are 0 */ + incl %eax /* bits numbered from 1, not 0 */ + ret + + .align 4 +L1: xorl %eax,%eax /* clear result */ + ret Index: index.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: index.S diff -N index.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ index.S 1 Aug 2005 18:08:21 -0000 @@ -0,0 +1,5 @@ +/* $NetBSD: index.S,v 1.3 2004/07/19 20:04:41 drochner Exp $ */ +/* $FreeBSD$ */ + +#define INDEX +#include "strchr.S" Index: memchr.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: memchr.S diff -N memchr.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ memchr.S 1 Aug 2005 18:09:44 -0000 @@ -0,0 +1,112 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: memchr.S,v 1.3 2004/07/19 20:04:41 drochner Exp $") +#endif + +ENTRY(memchr) + movzbq %sil,%rcx + + /* + * Align to word boundry + * Consider unrolling loop? + */ + testq %rdx,%rdx /* nbytes =3D=3D 0? */ + je .Lzero +.Lalign: + testb $7,%dil + je .Lword_aligned + movq %rdi,%rax + cmpb (%rdi),%cl + je .Ldone + incq %rdi + decq %rdx + jnz .Lalign + jmp .Lzero + +.Lword_aligned: + /* copy char to all bytes in word */ + movb %cl,%ch + movq %rcx,%rsi + salq $16,%rcx + orq %rsi,%rcx + movq %rcx,%rsi + salq $32,%rcx + orq %rsi,%rcx + + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 + + .align 4 +.Lloop: + cmpq $7,%rdx /* nbytes > 8 */ + jbe .Lbyte + movq (%rdi),%rsi + addq $8,%rdi + xorq %rcx,%rsi + subq $8,%rdx + subq %r8,%rsi + testq %r9,%rsi + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word are + * equal to ch. + */ + + leaq -8(%rdi),%rax + cmpb -8(%rdi),%cl /* 1st byte =3D=3D ch? */ + je .Ldone + + leaq -7(%rdi),%rax + cmpb -7(%rdi),%cl /* 2nd byte =3D=3D ch? */ + je .Ldone + + leaq -6(%rdi),%rax + cmpb -6(%rdi),%cl /* 3rd byte =3D=3D ch? */ + je .Ldone + + leaq -5(%rdi),%rax + cmpb -5(%rdi),%cl /* 4th byte =3D=3D ch? */ + je .Ldone + + leaq -4(%rdi),%rax + cmpb -4(%rdi),%cl /* 5th byte =3D=3D ch? */ + je .Ldone + + leaq -3(%rdi),%rax + cmpb -3(%rdi),%cl /* 6th byte =3D=3D ch? */ + je .Ldone + + leaq -2(%rdi),%rax + cmpb -2(%rdi),%cl /* 7th byte =3D=3D ch? */ + je .Ldone + + leaq -1(%rdi),%rax + cmpb -1(%rdi),%cl /* 7th byte =3D=3D ch? */ + jne .Lloop + ret + +.Lbyte: + testq %rdx,%rdx + je .Lzero +.Lbyte_loop: + movq %rdi,%rax + cmpb (%rdi),%cl + je .Ldone + incq %rdi + decq %rdx + jnz .Lbyte_loop + +.Lzero: + xorq %rax,%rax + +.Ldone: + ret Index: rindex.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: rindex.S diff -N rindex.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ rindex.S 1 Aug 2005 18:10:36 -0000 @@ -0,0 +1,5 @@ +/* $NetBSD: rindex.S,v 1.3 2004/07/19 20:04:41 drochner Exp $ */ +/* $FreeBSD$ */ + +#define RINDEX +#include "strrchr.S" Index: strchr.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strchr.S diff -N strchr.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strchr.S 1 Aug 2005 18:11:51 -0000 @@ -0,0 +1,137 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strchr.S,v 1.2 2004/07/19 20:04:41 drochner Exp $") +#endif + +#ifdef INDEX +ENTRY(index) +#else +ENTRY(strchr) +#endif + movzbq %sil,%rcx + + /* + * Align to word boundary. + * Consider unrolling loop? + */ +.Lalign: + testb $7,%dil + je .Lword_aligned + movb (%rdi),%dl + cmpb %cl,%dl + je .Ldone + incq %rdi + testb %dl,%dl + jne .Lalign + jmp .Lzero + +.Lword_aligned: + /* copy char to all bytes in word */ + movb %cl,%ch + movq %rcx,%rdx + salq $16,%rcx + orq %rdx,%rcx + movq %rcx,%rdx + salq $32,%rcx + orq %rdx,%rcx + + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 + + /* Check whether any byte in the word is equal to ch or 0. */ + .align 4 +.Lloop: + movq (%rdi),%rdx + addq $8,%rdi + movq %rdx,%rsi + subq %r8,%rdx + xorq %rcx,%rsi + subq %r8,%rsi + orq %rsi,%rdx + testq %r9,%rdx + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word match + * ch or are equal to 0. + */ + + movb -8(%rdi),%dl + cmpb %cl,%dl /* 1st byte =3D=3D ch? */ + jne 1f + subq $8,%rdi + jmp .Ldone +1: testb %dl,%dl /* 1st byte =3D=3D 0? */ + je .Lzero + + movb -7(%rdi),%dl + cmpb %cl,%dl /* 2nd byte =3D=3D ch? */ + jne 1f + subq $7,%rdi + jmp .Ldone +1: testb %dl,%dl /* 2nd byte =3D=3D 0? */ + je .Lzero + + movb -6(%rdi),%dl + cmpb %cl,%dl /* 3rd byte =3D=3D ch? */ + jne 1f + subq $6,%rdi + jmp .Ldone +1: testb %dl,%dl /* 3rd byte =3D=3D 0? */ + je .Lzero + + movb -5(%rdi),%dl + cmpb %cl,%dl /* 4th byte =3D=3D ch? */ + jne 1f + subq $5,%rdi + jmp .Ldone +1: testb %dl,%dl /* 4th byte =3D=3D 0? */ + je .Lzero + + movb -4(%rdi),%dl + cmpb %cl,%dl /* 5th byte =3D=3D ch? */ + jne 1f + subq $4,%rdi + jmp .Ldone +1: testb %dl,%dl /* 5th byte =3D=3D 0? */ + je .Lzero + + movb -3(%rdi),%dl + cmpb %cl,%dl /* 6th byte =3D=3D ch? */ + jne 1f + subq $3,%rdi + jmp .Ldone +1: testb %dl,%dl /* 6th byte =3D=3D 0? */ + je .Lzero + + movb -2(%rdi),%dl + cmpb %cl,%dl /* 7th byte =3D=3D ch? */ + jne 1f + subq $2,%rdi + jmp .Ldone +1: testb %dl,%dl /* 7th byte =3D=3D 0? */ + je .Lzero + + movb -1(%rdi),%dl + cmpb %cl,%dl /* 8th byte =3D=3D ch? */ + jne 1f + subq $1,%rdi + jmp .Ldone +1: testb %dl,%dl /* 8th byte =3D=3D 0? */ + jne .Lloop + +.Lzero: + /* If a ch wasn't found, return 0. */ + xorq %rdi,%rdi + +.Ldone: + movq %rdi,%rax + ret Index: strlen.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strlen.S diff -N strlen.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strlen.S 1 Aug 2005 18:12:48 -0000 @@ -0,0 +1,157 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strlen.S,v 1.3 2004/07/19 20:04:41 drochner Exp $") +#endif + +ENTRY(strlen) + movq %rdi,%rax + negq %rdi + +.Lalign: + /* Consider unrolling loop? */ + testb $7,%al + je .Lword_aligned + cmpb $0,(%rax) + jne 1f + leaq (%rdi,%rax),%rax + ret +1: incq %rax + jmp .Lalign + + /* + * There are many well known branch-free sequences which are used + * for determining whether a zero-byte is contained within a word. + * These sequences are generally much more efficent than loading + * and comparing each byte individually. + * + * The expression [1,2]: + * + * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) + * + * evaluates to a non-zero value if any of the bytes in the + * original word is zero. + * + * It also has the useful property that bytes in the result word + * that coorespond to non-zero bytes in the original word have + * the value 0x00, while bytes cooresponding to zero bytes have + * the value 0x80. This allows calculation of the first (and + * last) occurance of a zero byte within the word (useful for C's + * str* primitives) by counting the number of leading (or + * trailing) zeros and dividing the result by 8. On machines + * without (or with slow) clz() / ctz() instructions, testing + * each byte in the result word for zero is necessary. + * + * This typically takes 4 instructions (5 on machines without + * "not-or") not including those needed to load the constant. + * + * + * The expression: + * + * (2) ((x - 0x01....01) & ~x & 0x80....80) + * + * evaluates to a non-zero value if any of the bytes in the + * original word is zero. + * + * On little endian machines, the first byte in the result word + * that cooresponds to a zero byte in the original byte is 0x80, + * so clz() can be used as above. On big endian machines, and + * little endian machines without (or with a slow) clz() insn, + * testing each byte in the original for zero is necessary + * + * This typically takes 3 instructions (4 on machines without + * "and with complement") not including those needed to load + * constants. + * + * + * The expression: + * + * (3) ((x - 0x01....01) & 0x80....80) + * + * always evaluates to a non-zero value if any of the bytes in + * the original word is zero. However, in rare cases, it also + * evaluates to a non-zero value when none of the bytes in the + * original word is zero. + * + * To account for possible false positives, each byte of the + * original word must be checked when the expression evaluates to + * a non-zero value. However, because it is simpler than those + * presented above, code that uses it will be faster as long as + * the rate of false positives is low. + * + * This is likely, because the the false positive can only occur + * if the most siginificant bit of a byte within the word is set. + * The expression will never fail for typical 7-bit ASCII strings. + * + * This typically takes 2 instructions not including those needed + * to load constants. + * + * + * [1] Henry S. Warren Jr., "Hacker's Delight", Addison-Westley 2003 + * + * [2] International Business Machines, "The PowerPC Compiler Writer's + * Guide", Warthman Associates, 1996 + */ + + .align 4 +.Lword_aligned: + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 +.Lloop: + movq (%rax),%rdx + addq $8,%rax + subq %r8,%rdx + testq %r9,%rdx + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word equal 0. + */ + cmpb $0,-8(%rax) /* 1st byte =3D=3D 0? */ + je .Lsub8 + cmpb $0,-7(%rax) /* 2nd byte =3D=3D 0? */ + je .Lsub7 + cmpb $0,-6(%rax) /* 3rd byte =3D=3D 0? */ + je .Lsub6 + cmpb $0,-5(%rax) /* 4th byte =3D=3D 0? */ + je .Lsub5 + cmpb $0,-4(%rax) /* 5th byte =3D=3D 0? */ + je .Lsub4 + cmpb $0,-3(%rax) /* 6th byte =3D=3D 0? */ + je .Lsub3 + cmpb $0,-2(%rax) /* 7th byte =3D=3D 0? */ + je .Lsub2 + cmpb $0,-1(%rax) /* 8th byte =3D=3D 0? */ + jne .Lloop + +.Lsub1: + leaq -1(%rdi,%rax),%rax + ret +.Lsub2: + leaq -2(%rdi,%rax),%rax + ret +.Lsub3: + leaq -3(%rdi,%rax),%rax + ret +.Lsub4: + leaq -4(%rdi,%rax),%rax + ret +.Lsub5: + leaq -5(%rdi,%rax),%rax + ret +.Lsub6: + leaq -6(%rdi,%rax),%rax + ret +.Lsub7: + leaq -7(%rdi,%rax),%rax + ret +.Lsub8: + leaq -8(%rdi,%rax),%rax + ret Index: strncmp.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strncmp.S diff -N strncmp.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strncmp.S 1 Aug 2005 18:13:51 -0000 @@ -0,0 +1,108 @@ +/* + * Written by J.T. Conklin . + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strncmp.S,v 1.2 2003/07/26 19:24:40 salo Exp $") +#endif + +/* + * NOTE: I've unrolled the loop eight times: large enough to make a + * significant difference, and small enough not to totally trash the + * cache. + */ + +ENTRY(strncmp) + testq %rdx,%rdx + jmp L2 /* Jump into the loop! */ + +L1: incq %rdi + incq %rsi + decq %rdx +L2: jz L4 /* strings are equal */ + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + jne L3 + + incq %rdi + incq %rsi + decq %rdx + jz L4 + movb (%rdi),%al + testb %al,%al + jz L3 + cmpb %al,(%rsi) + je L1 + +L3: movzbl (%rdi),%eax /* unsigned comparision */ + movzbl (%rsi),%ecx + subl %ecx,%eax + ret +L4: xorl %eax,%eax + ret Index: strrchr.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: strrchr.S diff -N strrchr.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ strrchr.S 1 Aug 2005 18:15:07 -0000 @@ -0,0 +1,127 @@ +/* + * Written by J.T. Conklin + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: strrchr.S,v 1.2 2004/07/19 20:04:41 drochner Exp $") +#endif + +#ifdef RINDEX +ENTRY(rindex) +#else +ENTRY(strrchr) +#endif + movzbq %sil,%rcx + + /* zero return value */ + xorq %rax,%rax + + /* + * Align to word boundary. + * Consider unrolling loop? + */ +.Lalign: + testb $7,%dil + je .Lword_aligned + movb (%rdi),%dl + cmpb %cl,%dl + cmoveq %rdi,%rax + incq %rdi + testb %dl,%dl + jne .Lalign + jmp .Ldone + +.Lword_aligned: + /* copy char to all bytes in word */ + movb %cl,%ch + movq %rcx,%rdx + salq $16,%rcx + orq %rdx,%rcx + movq %rcx,%rdx + salq $32,%rcx + orq %rdx,%rcx + + movabsq $0x0101010101010101,%r8 + movabsq $0x8080808080808080,%r9 + + /* Check whether any byte in the word is equal to ch or 0. */ + .align 4 +.Lloop: + movq (%rdi),%rdx + addq $8,%rdi + movq %rdx,%rsi + subq %r8,%rdx + xorq %rcx,%rsi + subq %r8,%rsi + orq %rsi,%rdx + testq %r9,%rdx + je .Lloop + + /* + * In rare cases, the above loop may exit prematurely. We must + * return to the loop if none of the bytes in the word match + * ch or are equal to 0. + */ + + movb -8(%rdi),%dl + cmpb %cl,%dl /* 1st byte =3D=3D ch? */ + jne 1f + leaq -8(%rdi),%rax +1: testb %dl,%dl /* 1st byte =3D=3D 0? */ + je .Ldone + + movb -7(%rdi),%dl + cmpb %cl,%dl /* 2nd byte =3D=3D ch? */ + jne 1f + leaq -7(%rdi),%rax +1: testb %dl,%dl /* 2nd byte =3D=3D 0? */ + je .Ldone + + movb -6(%rdi),%dl + cmpb %cl,%dl /* 3rd byte =3D=3D ch? */ + jne 1f + leaq -6(%rdi),%rax +1: testb %dl,%dl /* 3rd byte =3D=3D 0? */ + je .Ldone + + movb -5(%rdi),%dl + cmpb %cl,%dl /* 4th byte =3D=3D ch? */ + jne 1f + leaq -5(%rdi),%rax +1: testb %dl,%dl /* 4th byte =3D=3D 0? */ + je .Ldone + + movb -4(%rdi),%dl + cmpb %cl,%dl /* 5th byte =3D=3D ch? */ + jne 1f + leaq -4(%rdi),%rax +1: testb %dl,%dl /* 5th byte =3D=3D 0? */ + je .Ldone + + movb -3(%rdi),%dl + cmpb %cl,%dl /* 6th byte =3D=3D ch? */ + jne 1f + leaq -3(%rdi),%rax +1: testb %dl,%dl /* 6th byte =3D=3D 0? */ + je .Ldone + + movb -2(%rdi),%dl + cmpb %cl,%dl /* 7th byte =3D=3D ch? */ + jne 1f + leaq -2(%rdi),%rax +1: testb %dl,%dl /* 7th byte =3D=3D 0? */ + je .Ldone + + movb -1(%rdi),%dl + cmpb %cl,%dl /* 8th byte =3D=3D ch? */ + jne 1f + leaq -1(%rdi),%rax +1: testb %dl,%dl /* 8th byte =3D=3D 0? */ + jne .Lloop + +.Ldone: + ret Index: swab.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: swab.S diff -N swab.S --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ swab.S 1 Aug 2005 18:18:17 -0000 @@ -0,0 +1,47 @@ +/* + * Written by J.T. Conklin . + * Public domain. + */ + +#include +__FBSDID("$FreeBSD$"); + +#if 0 + RCSID("$NetBSD: swab.S,v 1.2 2003/07/26 19:24:40 salo Exp $") +#endif + +#define LOAD_SWAP_STORE_WORD \ + lodsw ; \ + xchgb %al,%ah ; \ + stosw + +ENTRY(swab) + xchgq %rdi,%rsi + cld # set direction forward + + shrq $1,%rdx + testq $7,%rdx # copy first group of 1 to 7 words + jz L2 # while swaping alternate bytes. +L1: lodsw + rorw $8,%ax + stosw + decq %rdx + testq $7,%rdx + jnz L1 + +L2: shrq $3,%rdx # copy remainder 8 words at a time + jz L4 # while swapping alternate bytes. +L3: + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + LOAD_SWAP_STORE_WORD + + decq %rdx + jnz L3 +L4: + ret --vtzGhvizbBRQ85DL-- --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7mkO/cVsHxFZiIoRArcuAJ9AF9F0+YFYsQpLVPvnd3hGmKNXBgCdFAIS mrMJ3TeaXKrzkBqS3vxeQGI= =TJe9 -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 1 19:55:44 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 DBFBD16A41F; Mon, 1 Aug 2005 19:55:44 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F18D43D45; Mon, 1 Aug 2005 19:55:43 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j71JteVE020293; Mon, 1 Aug 2005 22:55:41 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j71Jte7q001422; Mon, 1 Aug 2005 22:55:40 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j71JtdwJ001421; Mon, 1 Aug 2005 22:55:39 +0300 (EEST) Date: Mon, 1 Aug 2005 22:55:39 +0300 From: Giorgos Keramidas To: Xin LI Message-ID: <20050801195539.GB1406@beatrix.daedalusnetworks.priv> References: <20050801182518.GA85423@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801182518.GA85423@frontfree.net> Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 01 Aug 2005 19:55:45 -0000 On 2005-08-02 02:25, Xin LI wrote: > Hi, Guys, > > Here is a patchset that I have produced to make our libc aware of the > NetBSD assembly implementation of the string related operations. I can't speak for the asm code, since I know barely enough amd64 things to read it, but there are a few typos you might want to fix before this gets committed. > + /* > + * Align to word boundry > + * Consider unrolling loop? s/boundry/boundary/ > + * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) > + * > + * evaluates to a non-zero value if any of the bytes in the > + * original word is zero. > + * > + * It also has the useful property that bytes in the result word > + * that coorespond to non-zero bytes in the original word have > + * the value 0x00, while bytes cooresponding to zero bytes have s/coorespond/correspond/ in the 2 last lines. > + * On little endian machines, the first byte in the result word > + * that cooresponds to a zero byte in the original byte is 0x80, Ditto. > + * so clz() can be used as above. On big endian machines, and > + * little endian machines without (or with a slow) clz() insn, > + * testing each byte in the original for zero is necessary Missing final period. > + testq $7,%rdx # copy first group of 1 to 7 words > + jz L2 # while swaping alternate bytes. s/swaping/swapping/ That's all I could spot. From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 1 20:05: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 99C1516A41F; Mon, 1 Aug 2005 20:05:56 +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 51A0A43D48; Mon, 1 Aug 2005 20:05:55 +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 j71K5q1X013169; Mon, 1 Aug 2005 13:05:52 -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 j71K5quH013168; Mon, 1 Aug 2005 13:05:52 -0700 (PDT) (envelope-from sgk) Date: Mon, 1 Aug 2005 13:05:52 -0700 From: Steve Kargl To: Giorgos Keramidas Message-ID: <20050801200552.GA13041@troutmask.apl.washington.edu> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801195539.GB1406@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 01 Aug 2005 20:05:56 -0000 On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 02:25, Xin LI wrote: > > Hi, Guys, > > > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. > > I can't speak for the asm code, since I know barely enough amd64 things > to read it, but there are a few typos you might want to fix before this > gets committed. > Ditto. > > That's all I could spot. > There is an occurrence of "occurance", which should be "occurrence". :-) -- Steve From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 1 20:33: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 13C5416A41F; Mon, 1 Aug 2005 20:33:06 +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 C307B43D45; Mon, 1 Aug 2005 20:33:05 +0000 (GMT) (envelope-from pete@users.altadena.net) Received: from pete by users.altadena.net with local (Exim 4.51) id 1Dzgy9-00019t-J7; Mon, 01 Aug 2005 13:33:05 -0700 Date: Mon, 1 Aug 2005 13:33:05 -0700 From: Pete Carah To: amd64@freebsd.org, current@freebsd.org, x11@freebsd.org Message-ID: <20050801203305.GA3612@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: Compaq v2310 revisited in 32-bit mode 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, 01 Aug 2005 20:33:06 -0000 I gave up on keeping my new amd64 compaq in 64-bit mode due mostly to the lack of 64-bit drivers even from HP. Even the PCcard driver only kind-of worked... The pc-card works in 32bit mode; in fbsd/amd64 it hung the system whenever a card (Dlink ath card) was plugged in, then resumed whenever it was unplugged. This works fine in 32-bit (I'm typing through it now). There is no 64-bit Broadcom driver out there that I could find that handled the 4318. Linuxant.com had a 64bit driver that, when the .inf was patched to recognize the 4318, did so, but fbsd never attached the ndis driver due to a timeout. The 32bit driver is better but doesn't handle WPA. (in fact nothing shows up in "list scan" so something fundamental is wrong. I got the driver out of my own /windows/system32/drivers directory so I know it works in windoze (WPA works fine in windows on the same access point). I get reboots whenever trying X11 on the ATI chipset in this machine, using the .12 or .16 snapshot at xorg. Eric and JKim: This happens also in 32-bit mode (I was wishing :-) So, the TI cardbus driver lacks something in 64-bit mode and the ndisulator is better (but might be OK if Broadcom released a 64-bit driver for the 4318...) (and even better if they did something like atheros and released a layered driver to handle the nda stuff, but I'm not holding my breath...) Also, I couldn't get the CD boot to work (in fact, the generic kernel in general) without disabling a bunch of stuff in hints. I still haven't quite figured out what it is but it partly seems to be atapi_dma. Still progress needed. If anyone involved in the hardware effort (especially X11) lives in Southern Calif, I can help with some access to the hardware. I do have the TI datasheet (all 300 pages) for the chip that handles the pccard (also fw and the built-in flash-card reader/writer). I never tried fw in 64-bit mode to see if that part of the driver worked. Once I get some time I can look into the relevant drivers to see what is going on there. It may be that some address masking/bounce-buffer stuff needs to be done... (or does the amd64 port always assign addresses that fit into 32 bits if there is less than 4g ram present?) Again, all this works fine in windoze (32-bit mode again; HP isn't (yet) participating in the MS 64-bit XP exchange program, maybe thanks to Broadcom?). (though I also don't know about ATI...) USB and ATA do work in 64-bit; those are in the main ATI chipset. I think that atapi_dma doesn't but don't know for sure since the only symptom I see is a hang before the geom printouts during boot. (and that could be the drive and not the chipset anyhow?) I've kept verbose dmesg and several xorg logs from the 64-bit phase in case. (http://www.altadena.net/~pete/amd64/) -- Pete From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 1 23:45: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 CB08B16A41F for ; Mon, 1 Aug 2005 23:45:04 +0000 (GMT) (envelope-from Matthew.Sullivan@canberra.edu.au) Received: from mail.canberra.edu.au (mail.canberra.edu.au [137.92.97.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DF2543D46 for ; Mon, 1 Aug 2005 23:45:04 +0000 (GMT) (envelope-from Matthew.Sullivan@canberra.edu.au) Received: from [137.92.9.213] by mail.canberra.edu.au (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPSA id <0IKK00538HYQNK@mail.canberra.edu.au> for freebsd-amd64@freebsd.org; Tue, 02 Aug 2005 09:44:59 +1000 (EST) Date: Tue, 02 Aug 2005 09:44:49 +1000 From: Matthew Sullivan In-reply-to: <42EA0CA7.8080605@bsdhacker.org> To: uidzero Message-id: <42EEB3F1.9050005@canberra.edu.au> Organization: The University of Canberra MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <42EA0CA7.8080605@bsdhacker.org> 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: Mon, 01 Aug 2005 23:45:04 -0000 uidzero wrote: > 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. :) This echos my experiences... Further to that I have seen some amazing feats of sheer processing power - processing out Postfix queues of >5k messages (with inline virus checking) on a single AMD64 processor in under 5 minutes (most messages being delivered through a perl script). Mailing lists of 500+ people getting getting processed _and_ delivered in under 20 seconds from first accept to last delivery (450+ users on the list were remote Internet users). As a mail server with inline virus scanning I have no qualms with it receiving 50 messages per second - infact there is a 22M Uplink to the net, so far it has kept up with everything to the point of the 22M being full. Hardware: AMD64 2.0GHz Asus K8S M/B 1G Ram Dual 160G SATA (RAID1 config). Regards, -- Matthew Sullivan IT Security Manager The University of Canberra A member of the Australian Association for the Abolition of Acronym Abuse, Regional Group Headquarters, Strategic and Tactical Operations Planning (AAAAARGHSTOP). From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 00:36: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 2B06F16A41F for ; Tue, 2 Aug 2005 00:36:14 +0000 (GMT) (envelope-from akbeech@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9E9A43D49 for ; Tue, 2 Aug 2005 00:36:13 +0000 (GMT) (envelope-from akbeech@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so723821nzd for ; Mon, 01 Aug 2005 17:36:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=t+TZtg/x34rX8TafZS8fQc510MvIYu+cePgIu4U/Tlp3rQaRscP+iNRKyp8q6O13L+yaOljOHZpbe7TwrEUhESDmbv5OLTN8VvvSa02bvPfDds1ylBieGjprQ9pwEkZ97YqfJxkMU1e5XD6haovzVC7Ycbrg3WwkLoI5+IIBm2U= Received: by 10.36.224.6 with SMTP id w6mr5024316nzg; Mon, 01 Aug 2005 17:36:13 -0700 (PDT) Received: by 10.36.86.11 with HTTP; Mon, 1 Aug 2005 17:36:13 -0700 (PDT) Message-ID: Date: Mon, 1 Aug 2005 16:36:13 -0800 From: Beecher Rintoul To: freebsd-amd64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Boot Error X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Beecher Rintoul List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 00:36:14 -0000 I'm getting the following error while trying to boot: int=3D0000000d=09err=3D00000000=09efl=3D0010006=09eip=3D00027995 eax=3D00000100=09ebx=3D00000000=09ecx=3Dc000000=09edx=3D00000000 esi=3D00000200=09edi=3D0006d5f0=09ebp=3D0093630=09esp=3D0009d600 cs=3D0008=09ds=3D0010=09es=3D0010=09fs=3D0010=09gs=3D0010=09ss=3D0010 cs:eip=3D0f 30 0f 20 e0 83 c8 30-0f 22 e0 b8 00 f0 03 00 of 22 d8 0f 20 c0 0d 00-00 00 80 0f 22 c0 b8 00 ss:esp=3D69 95 00 00 00 40 dd 00-00 50 dd 00 00 10 04 00 00 00 00 00 00 00 04 00-00 00 00 00 00 40 dd 00 BTX halted I have tried both 5.4-release and 6.0-beta with the same results. The machine works fine with i386 5.4. The box is an MSI K8t Neo Mobo, running a 2800+ Sempron. Anyone have a suggestion? Tnx, Beech From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 01:39: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 4CEC616A41F; Tue, 2 Aug 2005 01:39:23 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02C4143D48; Tue, 2 Aug 2005 01:39:22 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j721dIRR038004; Mon, 1 Aug 2005 18:39:18 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j721dGEX038003; Mon, 1 Aug 2005 18:39:16 -0700 (PDT) (envelope-from obrien) Date: Mon, 1 Aug 2005 18:39:16 -0700 From: "David O'Brien" To: Xin LI Message-ID: <20050802013916.GA37135@dragon.NUXI.org> Mail-Followup-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org, Xin LI References: <20050801182518.GA85423@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801182518.GA85423@frontfree.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 01:39:23 -0000 On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > Here is a patchset that I have produced to make our libc aware of the > NetBSD assembly implementation of the string related operations. What performance benchmarks have these been thru? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 03:17:03 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 E578F16A41F; Tue, 2 Aug 2005 03:17:03 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E7C143D48; Tue, 2 Aug 2005 03:17:03 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 5F8CCEB4ABA; Tue, 2 Aug 2005 11:17:01 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id BF87C136E0F; Tue, 2 Aug 2005 11:16:58 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03769-04; Tue, 2 Aug 2005 11:16:51 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 9F57B1366D5; Tue, 2 Aug 2005 11:16:50 +0800 (CST) Date: Tue, 2 Aug 2005 11:16:50 +0800 From: Xin LI To: Giorgos Keramidas Message-ID: <20050802031650.GA3799@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <20050801195539.GB1406@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 02 Aug 2005 03:17:04 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Giorgos, On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 02:25, Xin LI wrote: > > Hi, Guys, > > > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. >=20 > I can't speak for the asm code, since I know barely enough amd64 things > to read it, but there are a few typos you might want to fix before this > gets committed. [good stuff snipped] > That's all I could spot. Thanks very much, will do more proof reading before considering to commit it :-) Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7uWi/cVsHxFZiIoRArPPAJ9zPkW434Tg9Ygr83p1RDzthJThdwCdFngr T0trij/cWiEOyjpy8di4WUY= =bA1+ -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 04:03:00 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 C1F2B16A41F; Tue, 2 Aug 2005 04:03:00 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C2ED43D49; Tue, 2 Aug 2005 04:03:00 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id DD30FEB1E9F; Tue, 2 Aug 2005 12:02:56 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id B0BE4138359; Tue, 2 Aug 2005 12:02:54 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03769-18; Tue, 2 Aug 2005 12:02:47 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 66BBA138352; Tue, 2 Aug 2005 12:02:46 +0800 (CST) Date: Tue, 2 Aug 2005 12:02:46 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050802040246.GB3799@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <20050802013916.GA37135@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 02 Aug 2005 04:03:00 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. >=20 > What performance benchmarks have these been thru? I'm stilling reading The "Software Optimization Guide for AMD Athlon64 and Opteron" and the disassembly output of latest GCC snapshot to see if we are on the right way. No benchmarks has been done yet, but I will at least test it on Athlon64 tonight to get some numbers, and if I can arrange a test on our Opteron box at company, I will do some benchmarks there, too. BTW. Would you please give me some hints on the benchmarking? I am not sure whether just looping the test cases on some determine dataset would be enough? Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7vBm/cVsHxFZiIoRAjM2AJ9looDj9eeNKvMm4flnRzJ5eEPeIQCffe1T 2MWnE3syKiMLIla7S6UEENo= =2/BP -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 14:29: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 3434216A438 for ; Tue, 2 Aug 2005 14:29:07 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: from pluricanal.net (mail.pluricanal.net [83.144.129.196]) by mx1.FreeBSD.org (Postfix) with SMTP id DE23A43D4C for ; Tue, 2 Aug 2005 14:29:05 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: (qmail 26436 invoked from network); 2 Aug 2005 16:22:00 -0000 Received: from unknown (HELO proton.internal.fnop.net) (83.144.140.19) by mail.pluricanal.net with SMTP; 2 Aug 2005 16:22:00 -0000 Received: by proton.internal.fnop.net (Postfix, from userid 1000) id 2AD013307; Tue, 2 Aug 2005 15:27:22 +0100 (WEST) Date: Tue, 2 Aug 2005 15:27:22 +0100 From: Rui Paulo To: Steve Kargl Message-ID: <20050802142722.GA2583@proton.internal.fnop.net> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> <20050801200552.GA13041@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801200552.GA13041@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org, Giorgos Keramidas , freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 02 Aug 2005 14:29:07 -0000 On 2005.08.01 13:05:52 +0000, Steve Kargl wrote: | On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: | > On 2005-08-02 02:25, Xin LI wrote: | > > Hi, Guys, | > > | > > Here is a patchset that I have produced to make our libc aware of the | > > NetBSD assembly implementation of the string related operations. | > | > I can't speak for the asm code, since I know barely enough amd64 things | > to read it, but there are a few typos you might want to fix before this | > gets committed. | > | | Ditto. | | > | > That's all I could spot. | > | | There is an occurrence of "occurance", which should be "occurrence". :-) Thank you Steve Kargl and Giorgos Keramidas, I fixed those typos on NetBSD. http://mail-index.netbsd.org/source-changes/2005/08/02/0009.html http://mail-index.netbsd.org/source-changes/2005/08/02/0010.html -- Rui Paulo From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 15:16: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 2CFD616A41F for ; Tue, 2 Aug 2005 15:16:16 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (167-49.nyc.dsl.access.net [166.84.167.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B4B743D46 for ; Tue, 2 Aug 2005 15:16:15 +0000 (GMT) (envelope-from rob@hudson-trading.com) Received: from daemon.mistermishap.net (localhost.mistermishap.net [127.0.0.1]) by daemon.mistermishap.net (8.12.9/8.12.9) with ESMTP id j72FGEmU059997; Tue, 2 Aug 2005 11:16:14 -0400 (EDT) (envelope-from rob@hudson-trading.com) Received: from localhost (rob@localhost) by daemon.mistermishap.net (8.12.9/8.12.9/Submit) with ESMTP id j72FGDj7059994; Tue, 2 Aug 2005 11:16:14 -0400 (EDT) X-Authentication-Warning: daemon.mistermishap.net: rob owned process doing -bs Date: Tue, 2 Aug 2005 11:16:13 -0400 (EDT) From: Rob Watt X-X-Sender: rob@daemon.mistermishap.net To: freebsd-amd64@freebsd.org In-Reply-To: <42D06471.6080105@mWare.ca> Message-ID: <20050726135103.V18252@daemon.mistermishap.net> References: <20050630160225.D38285@daemon.mistermishap.net> <42D06471.6080105@mWare.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: rob work Subject: Re: fatal trap 12 in pagedaemon on dual-core opteron machine 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, 02 Aug 2005 15:16:16 -0000 Gary, Thanks for the debug.mpsafenet reccomendation. It did solve our stability problem with our mulitcast application. I ran over 100 replays of the data that caused the panic, and we no longer panic when debug.mpsafenet=0. Unfortunately, our tcp applications now utilize a much higher percentage of cpu. We now regularly get a load of 3, and the interactive response of the machine is much worse. It takes up to 30 seconds to log in to the machine when our tcp applications are running, and the lag while working on the machine makes it feel like we're using a 1200 baud modem rather than gigabit ethernet. Our tcp apps function similarly to our multicast apps, they simultaneously listen to tcp data, record the data, and re-broadcast the data using multicast. The load while listening to the same data with debug.mpsafenet=1 is 0.2, and on an i386 fbsd 4.11 machine the load is comparable at 0.25, and there is no noticeable lag while working on the machine. At our average data load I was not able to measure a big drop off in tcp performance, but I am concerned by the increased cpu load and interactivity performance. We are not willing to use debug.mpsafenet=0 if this performance drop is the price to pay. After reading some of Robert Watson's notes on fine tuning the multi-threaded network stack it seems that many fixes are being applied to current, but not all of them are applied to stable. We are not willing to run CURRENT on our productions machines. Does anyone know if patches are planned for STABLE (either for increasing performance with GIANT on, or for making the multi-threaded network stack more stable)? Thanks - Rob Watt On Mon, 11 Jul 2005, Gary wrote: >All, > >I can confirm that I've had numerous crashes that seem to be network >related using 5.4R AMD64 on a dual AMD Tyan S2882 Thunder K8S PRO. > >Removing the Berkley Packet Filter and IPFilter from the kernel reduced >the frequency of the crashes. Moving from the onboard bge to the onboard >fxp interface didn't seem to make much difference. Running the GENERIC >uniprocessor kernel seemed to eliminate the problems. > >I got conformation that there seems to be locking issues with the multi >threaded implementation of the network stack from Gleb Smirnoff >(glebius at freebsd.org). Gleb suggested setting "debug.mpsafenet=0" to >turn off multi-threaded networking (as far as I understand): > >http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035253.html > >This initially looked like it fixed the problem, but my system crashed >again a day later. > >Gary - Rob Watt From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 16:41: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 6875416A41F; Tue, 2 Aug 2005 16:41:37 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id B855243D45; Tue, 2 Aug 2005 16:41:36 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 14CA8EB4B16; Wed, 3 Aug 2005 00:41:33 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 1CD2C1384F6; Wed, 3 Aug 2005 00:41:30 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16558-08; Wed, 3 Aug 2005 00:41:21 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 6AD8F1384E5; Wed, 3 Aug 2005 00:41:20 +0800 (CST) Date: Wed, 3 Aug 2005 00:41:20 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050802164120.GA16775@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <20050802013916.GA37135@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 02 Aug 2005 16:41:37 -0000 --XF85m9dhOBO43t/C Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > Here is a patchset that I have produced to make our libc aware of the > > NetBSD assembly implementation of the string related operations. >=20 > What performance benchmarks have these been thru? In summary: index, rindex, memchr, strchr, strlen, strlen, strrchr are faster than their C counterparts; ffs, strncmp are about the same, and swab is worse. Note that these tests are done within loops that first copy a string to a new place, then perform the operation, then free the string, to defeat cache effects. The attachement has provided some details. If anyone wants the (ugly) test code, please let me know. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=result-x86_64vsC BETTER CASES [delphij@warrior7] ~/test/index> /usr/bin/time ./index 5.81 real 5.79 user 0.00 sys ASSEMBLY 1.84 real 1.82 user 0.00 sys [delphij@warrior7] ~/test/rindex> /usr/bin/time ./rindex 6.25 real 6.24 user 0.00 sys ASSEMBLY 2.17 real 1.84 user 0.01 sys [delphij@warrior7] ~/test/memchr> /usr/bin/time ./memchr 5.93 real 5.91 user 0.00 sys ASSEMBLY 1.91 real 1.84 user 0.00 sys [delphij@warrior7] ~/test/strchr> /usr/bin/time ./strchr 5.93 real 5.91 user 0.00 sys ASSEMBLY 1.84 real 1.83 user 0.00 sys [delphij@warrior7] ~/test/strlen> /usr/bin/time ./strlen 7.13 real 7.12 user 0.00 sys ASSEMBLY 1.44 real 1.43 user 0.00 sys [delphij@warrior7] ~/test/strrchr> /usr/bin/time ./strrchr 9.12 real 9.08 user 0.00 sys ASSEMBLY 4.71 real 4.69 user 0.00 sys WORSE/NO EFFECTS [delphij@warrior7] ~/test/ffs> /usr/bin/time ./ffs 0.33 real 0.33 user 0.00 sys ASSEMBLY 0.33 real 0.33 user 0.00 sys [delphij@warrior7] ~/test/strncmp> /usr/bin/time ./strncmp 3.90 real 3.88 user 0.00 sys 3.88 real 3.87 user 0.00 sys ASSEMBLY 3.88 real 3.87 user 0.00 sys [delphij@warrior7] ~/test/swab> /usr/bin/time ./swab 6.59 real 6.53 user 0.01 sys ASSEMBLY 8.06 real 8.05 user 0.00 sys --CE+1k2dSO48ffgeK-- --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC76Iw/cVsHxFZiIoRAm7dAJ9c9OXtEXP50o7LGwQu4LeehGzK2QCfa41T kNaVpPLdVEsHuZwlXoufgjY= =no2E -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:20:44 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 B1E1516A41F; Tue, 2 Aug 2005 17:20:44 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4472343D45; Tue, 2 Aug 2005 17:20:44 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72HKgdZ085112; Tue, 2 Aug 2005 10:20:42 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72HKgmu085111; Tue, 2 Aug 2005 10:20:42 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 10:20:42 -0700 From: "David O'Brien" To: Xin LI Message-ID: <20050802172042.GA71672@dragon.NUXI.org> Mail-Followup-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org, Xin LI References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> <20050802040246.GB3799@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802040246.GB3799@frontfree.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:20:44 -0000 On Tue, Aug 02, 2005 at 12:02:46PM +0800, Xin LI wrote: > On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > > Here is a patchset that I have produced to make our libc aware of the > > > NetBSD assembly implementation of the string related operations. > > > > What performance benchmarks have these been thru? .. > BTW. Would you please give me some hints on the benchmarking? I am > not sure whether just looping the test cases on some determine dataset > would be enough? Try some real world tests such as 'make buildworld'. Looking in src/usr.bin the following utils make good use of these libc functions and would be good real world tests: uuencode catman compress last makewhatis * uuencode a large kernel * run /etc/periodic/weekly/320.whatis * compress a large kernel * last delphij on a large /var/log/wtmp * cp /usr/src/share/man/man[1-9] to a ram disk and then run catman over it Just a few suggestions. It is easy to "optimize" for the simple input case and miss the larger case. I've also seen people "optimize" for all cases but then wind up with so much overhead that small inputs are slower. I have some very fancy routines from AMD that take into account cache size, alignment, and uses the prefetch instructions. The problem is they are a huge win for large input sizes, but I'm concerned about their performance on small input sizes. If these NetBSD routines perform better in the tests I listed above, we should commit them. We can continue to refine these libc routines over time. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:28:45 2005 Return-Path: X-Original-To: freebsd-amd64@www.freebsd.org Delivered-To: freebsd-amd64@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC40C16A41F for ; Tue, 2 Aug 2005 17:28:45 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77BD843D45 for ; Tue, 2 Aug 2005 17:28:45 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72HSeqr085386; Tue, 2 Aug 2005 10:28:40 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72HSeuu085385; Tue, 2 Aug 2005 10:28:40 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 10:28:40 -0700 From: "David O'Brien" To: "O. Hartmann" Message-ID: <20050802172840.GE71672@dragon.NUXI.org> References: <42ECB269.4030206@mail.uni-mainz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ECB269.4030206@mail.uni-mainz.de> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@www.freebsd.org Subject: Re: OpenOffice2.0 64Bit ready? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:28:45 -0000 On Sun, Jul 31, 2005 at 01:13:45PM +0200, O. Hartmann wrote: > Dear Sirs. > I do not follow up everything written herein, so my question may sound > stupid. > On my FreeBSD 6.0 AMD64 box I run a 'clean' 64 Bit FreeBSD 6.0 (no 32Bit > compatibility). I want to use OpenOffice from time to time reading Word > or Excel documents. Can we compile and run OO 2.0 without 32 Bit > compatibility enabled? I know this implies 64Bit clean code, so the > major question would be whether OO 2 is 64 Bit clean or not. No OOo isn't 64-bit clean. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:34: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 CAC4A16A41F for ; Tue, 2 Aug 2005 17:34:55 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8223843D45 for ; Tue, 2 Aug 2005 17:34:55 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72HYtS1085467; Tue, 2 Aug 2005 10:34:55 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72HYsrR085466; Tue, 2 Aug 2005 10:34:54 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 10:34:54 -0700 From: "David O'Brien" To: Ken Gunderson Message-ID: <20050802173454.GF71672@dragon.NUXI.org> References: <20050731113709.73cead31.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050731113709.73cead31.kgunders@teamcool.net> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: TYAN Transport TA26 (B2882) BIOS V3.03 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:34:55 -0000 On Sun, Jul 31, 2005 at 11:37:09AM -0600, Ken Gunderson wrote: > Just noticed this at Tyan's website dated 07/08/05: > TYAN Transport TA26 (B2882) BIOS V3.03: > New features and Fixes : .. > * Implemented AMD recommend for if 4 or more DDR400 DIMM's are used, > then the DDR speed is forced to DDR333 by default ... > Okay, it's the 4 or more DIMMS that caught my eye. Especially since on > a previous occassion they had specifically recommended Opteron 246 or > faster for use with DDR400. So now if I ugrade to the latest BIOS my > 4x1GB sticks of DDR400 will be forced to run at DDR333 speeds. > > > Fantastic!! Just what I always wanted. AMD ROCKS!! Market CPU's as > supporting DDR400 then force us to run at DDR333 when you realize you > screwed up! > I suspect these docs are overly terse and this applies to double-sided, double-stacked DIMM's, which put twice the load on the memory data bus and thus load the memory data bus beyond AMD's specification for pre-revision E Opteron CPU's. > And then there's the bank interleaving issue.... What is wrong with bank interleaving? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:36: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 B271716A429; Tue, 2 Aug 2005 17:36:07 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D53B043D48; Tue, 2 Aug 2005 17:36:06 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A7F73EB3FCC; Wed, 3 Aug 2005 01:36:04 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 65EF113435F; Wed, 3 Aug 2005 01:36:01 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17150-14; Wed, 3 Aug 2005 01:35:53 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 63E31133D09; Wed, 3 Aug 2005 01:35:52 +0800 (CST) Date: Wed, 3 Aug 2005 01:35:52 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <20050802173552.GB17471@frontfree.net> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> <20050802040246.GB3799@frontfree.net> <20050802172042.GA71672@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: <20050802172042.GA71672@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #4: Thu Jul 28 10:59:26 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 02 Aug 2005 17:36:07 -0000 --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 10:20:42AM -0700, David O'Brien wrote: > On Tue, Aug 02, 2005 at 12:02:46PM +0800, Xin LI wrote: > > On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: > > > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: > > > > Here is a patchset that I have produced to make our libc aware of t= he > > > > NetBSD assembly implementation of the string related operations. > > >=20 > > > What performance benchmarks have these been thru? > .. > > BTW. Would you please give me some hints on the benchmarking? I am > > not sure whether just looping the test cases on some determine dataset > > would be enough? >=20 > Try some real world tests such as 'make buildworld'. Looking in > src/usr.bin the following utils make good use of these libc functions and > would be good real world tests: uuencode catman compress last makewhatis >=20 > * uuencode a large kernel > * run /etc/periodic/weekly/320.whatis > * compress a large kernel > * last delphij on a large /var/log/wtmp > * cp /usr/src/share/man/man[1-9] to a ram disk and then run catman over it Thanks, I will try these tomorrow. > Just a few suggestions. It is easy to "optimize" for the simple input ca= se > and miss the larger case. I've also seen people "optimize" for all cases > but then wind up with so much overhead that small inputs are slower. >=20 > I have some very fancy routines from AMD that take into account cache > size, alignment, and uses the prefetch instructions. The problem is they > are a huge win for large input sizes, but I'm concerned about their > performance on small input sizes. >=20 > If these NetBSD routines perform better in the tests I listed above, we > should commit them. We can continue to refine these libc routines over > time. Agreed. I will do more careful benchmarks that can reflect more real world= =20 better, to figure out whether these "optimizations" are really necessary for us. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7674/cVsHxFZiIoRAu/4AJ9w62vonIN+p9sfcdZZNJcuOkSsHgCcDpci 5psIn9+yVcxR0DVnB248410= =beKZ -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:49: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 6E12716A41F for ; Tue, 2 Aug 2005 17:49:37 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF3943D46 for ; Tue, 2 Aug 2005 17:49:34 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72HnNK2085921; Tue, 2 Aug 2005 10:49:23 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72HnMxa085913; Tue, 2 Aug 2005 10:49:22 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 10:49:22 -0700 From: "David O'Brien" To: ray@redshift.com Message-ID: <20050802174922.GI71672@dragon.NUXI.org> References: <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i 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 Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:49:37 -0000 On Fri, Jul 29, 2005 at 02:06:09AM -0700, ray@redshift.com wrote: > 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? Totally false! A kernel w/o 'options SMP' is a UP kernel and only uses a single CPU. I suspect is what you are mis-remembering is that an AMD64 SMP kernel will boot and work just fine on a UP AMD64 machine. (which hasn't been the case on i386 in the past) -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:54:19 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 BDC7D16A41F for ; Tue, 2 Aug 2005 17:54:19 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 798BD43D45 for ; Tue, 2 Aug 2005 17:54:19 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72HsIfv086040; Tue, 2 Aug 2005 10:54:18 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72HsIbQ086039; Tue, 2 Aug 2005 10:54:18 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 10:54:17 -0700 From: "David O'Brien" To: Phil Allsopp Message-ID: <20050802175417.GL71672@dragon.NUXI.org> References: <5.1.1.6.0.20050727120543.054c5c08@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.6.0.20050727120543.054c5c08@127.0.0.1> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: MultiCPU opteron Kernel configuration. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-alpha@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:54:19 -0000 On Wed, Jul 27, 2005 at 12:11:10PM +0100, 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 There is no "Tiger" K8S Pro. What "S" model motherboard do you have? > options SMP > > and rebuild everything and see no errors, however I see no multiple CPU > usage after rebuilding, installing and rebooting the machine. What does your /var/run/dmesg.boot say? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:55:41 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 35F8F16A41F for ; Tue, 2 Aug 2005 17:55:41 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B589543D46 for ; Tue, 2 Aug 2005 17:55:40 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72Hteri086107; Tue, 2 Aug 2005 10:55:40 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72HtdZj086106; Tue, 2 Aug 2005 10:55:39 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 10:55:39 -0700 From: "David O'Brien" To: Phil Allsopp Message-ID: <20050802175539.GM71672@dragon.NUXI.org> References: <5.1.1.6.0.20050727120543.054c5c08@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.6.0.20050727120543.054c5c08@127.0.0.1> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: MultiCPU opteron Kernel configuration. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:55:41 -0000 [ Please ignore the previous response - It has an erroneous reply-to: ] On Wed, Jul 27, 2005 at 12:11:10PM +0100, 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 There is no "Tiger" K8S Pro. What "S" model motherboard do you have? > options SMP > > and rebuild everything and see no errors, however I see no multiple CPU > usage after rebuilding, installing and rebooting the machine. What does your /var/run/dmesg.boot say? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 17:59: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 8290316A41F for ; Tue, 2 Aug 2005 17:59:39 +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 A80D343D46 for ; Tue, 2 Aug 2005 17:59:38 +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 57E1E9791D; Tue, 2 Aug 2005 10:59:38 -0700 (PDT) Message-Id: <3.0.1.32.20050802105941.00a547c8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Tue, 02 Aug 2005 10:59:41 -0700 To: freebsd-amd64@freebsd.org From: ray@redshift.com In-Reply-To: <20050802174922.GI71672@dragon.NUXI.org> References: <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050729020609.00a6a240@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: Tue, 02 Aug 2005 17:59:39 -0000 At 10:49 AM 8/2/2005 -0700, David O'Brien wrote: | On Fri, Jul 29, 2005 at 02:06:09AM -0700, ray@redshift.com wrote: | > 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? | | Totally false! A kernel w/o 'options SMP' is a UP kernel and only uses a | single CPU. I suspect is what you are mis-remembering is that an AMD64 | SMP kernel will boot and work just fine on a UP AMD64 machine. (which | hasn't been the case on i386 in the past) | | -- | -- David (obrien@FreeBSD.org) Thanks David - needless to say, I'm going to be re-running all my benchmarks :-D I can't remember if I left out the SMP line on the AMD kernel config or if I was thinking about the "device apic" line that is not needed. I was operating on about 2 hours of sleep and rushing to finish my benchmarks before the evaluation server had to be picked up by UPS. I'll post my results when I have another machine in here and re-run the exact same benchmarks. This time I will be certain to confirm the situation on the SMP kernel with regard to the AMD64 branch. Ray From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 18:00:24 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 1FC7F16A41F for ; Tue, 2 Aug 2005 18:00:24 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE0DD43D45 for ; Tue, 2 Aug 2005 18:00:23 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72I0Mv9086290; Tue, 2 Aug 2005 11:00:22 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72I0M9U086289; Tue, 2 Aug 2005 11:00:22 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 11:00:22 -0700 From: "David O'Brien" To: NAKATA Maho Message-ID: <20050802180022.GO71672@dragon.NUXI.org> References: <20050727.154329.71086249.chat95@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050727.154329.71086249.chat95@mac.com> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i 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 Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 18:00:24 -0000 On Wed, Jul 27, 2005 at 03:43:29PM +0900, NAKATA Maho wrote: > Hello > sometimes my opteron box locks up recently, > it seems that there are some discussion about this issue > on the list. .. > * set hw.physmem="4G" doesn't help Try something like "3G" instead. > workaround: > on board GbE (bge0) and SATA disabled. I've found that the Silicon Images SATA driver isn't >4GB clean. I can easily panic my Iwill DK8X with 8GB of RAM when I try to use a Silicon Images based SATA mirror. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 18:04: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 54D7216A41F for ; Tue, 2 Aug 2005 18:04:39 +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 EE27843D45 for ; Tue, 2 Aug 2005 18:04:38 +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 ADDED11EB1 for ; Tue, 2 Aug 2005 12:04:35 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 5F9A911EA4 for ; Tue, 2 Aug 2005 12:04:35 -0600 (MDT) Date: Tue, 2 Aug 2005 12:07:01 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050802120701.47ca52c9.kgunders@teamcool.net> In-Reply-To: <20050802173454.GF71672@dragon.NUXI.org> References: <20050731113709.73cead31.kgunders@teamcool.net> <20050802173454.GF71672@dragon.NUXI.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: TYAN Transport TA26 (B2882) BIOS V3.03 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, 02 Aug 2005 18:04:39 -0000 On Tue, 2 Aug 2005 10:34:54 -0700 "David O'Brien" wrote: > On Sun, Jul 31, 2005 at 11:37:09AM -0600, Ken Gunderson wrote: > > Just noticed this at Tyan's website dated 07/08/05: > > TYAN Transport TA26 (B2882) BIOS V3.03: > > New features and Fixes : > .. > > * Implemented AMD recommend for if 4 or more DDR400 DIMM's are used, > > then the DDR speed is forced to DDR333 by default > ... > > Okay, it's the 4 or more DIMMS that caught my eye. Especially since on > > a previous occassion they had specifically recommended Opteron 246 or > > faster for use with DDR400. So now if I ugrade to the latest BIOS my > > 4x1GB sticks of DDR400 will be forced to run at DDR333 speeds. > > > > > > Fantastic!! Just what I always wanted. AMD ROCKS!! Market CPU's as > > supporting DDR400 then force us to run at DDR333 when you realize you > > screwed up! > > > > I suspect these docs are overly terse and this applies to double-sided, > double-stacked DIMM's, which put twice the load on the memory data bus > and thus load the memory data bus beyond AMD's specification for > pre-revision E Opteron CPU's. > > > And then there's the bank interleaving issue.... > > What is wrong with bank interleaving? No clues. I was getting ready to order a couple more of these puppies and happened to run across this whilst on Tyan's site: Just a terse listing of the issues the BIOS update addresses. There wern't any links to the referenced "AMD recommend". Alas, my current cpu's are pre rev. E (CG). I'm using Corsair 4 x 1GB ECC Reg. sticks of DDR400 ram. I've not seen any issues. Noticed a BIOS upgrade and since I usually keep my systems current on BIOS.... Didn't want to do this upgrade w/o further investigation though since I am not keen on forcing DDR333. Perhaps the "by default" means you can still change it in the BIOS. So I was just curious about what those more guru than I in the freebsd-amd64 camp might think. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 18:13: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 D607116A41F for ; Tue, 2 Aug 2005 18:13:56 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ACAD43D58 for ; Tue, 2 Aug 2005 18:13:55 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72IDtxa086609; Tue, 2 Aug 2005 11:13:55 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72IDtrl086608; Tue, 2 Aug 2005 11:13:55 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 11:13:55 -0700 From: "David O'Brien" To: ray@redshift.com Message-ID: <20050802181355.GP71672@dragon.NUXI.org> References: <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> <3.0.1.32.20050802105941.00a547c8@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.1.32.20050802105941.00a547c8@pop.redshift.com> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i 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: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 18:13:57 -0000 On Tue, Aug 02, 2005 at 10:59:41AM -0700, ray@redshift.com wrote: > Thanks David - needless to say, I'm going to be re-running all my benchmarks ... > I'll post my results when I have another machine in here and re-run the exact > same benchmarks. This time I will be certain to confirm the situation on the > SMP kernel with regard to the AMD64 branch. You need to be careful about what you are testing. If you dual-boot 64-bit and 32-bit from the same disk, don't forget one of them will be on a faster area of the disk. So you need a 2nd data disk that is newfs'ed between each run to do your benchmarks on. At a minium, you should build a set of 32-bit binaries on FreeBSD/i386 with CPUTYPE=k8. Run benchmarks under the 32-bit OS. Then run the same benchmarks with the 32-bit binaries on the 64-bit OS. (ie, you're just changing the kernel). Then build 64-bit binaries and benchmark them. You should use RELENG_6, not 5.x to make sure you're getting the best K8 GCC we support along with the optimizations we've added since 5.x was released. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 18:36:40 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 07EE216A423 for ; Tue, 2 Aug 2005 18:36:39 +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 0CB2643D55 for ; Tue, 2 Aug 2005 18:36:37 +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 ; Tue, 02 Aug 2005 14:51:10 -0400 From: John Baldwin To: freebsd-amd64@freebsd.org, Beecher Rintoul Date: Tue, 2 Aug 2005 14:06:08 -0400 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508021406.09670.jhb@FreeBSD.org> Cc: Subject: Re: Boot Error 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, 02 Aug 2005 18:36:40 -0000 On Monday 01 August 2005 08:36 pm, Beecher Rintoul wrote: > I'm getting the following error while trying to boot: > > int=0000000d err=00000000 efl=0010006 eip=00027995 > eax=00000100 ebx=00000000 ecx=c000000 edx=00000000 > esi=00000200 edi=0006d5f0 ebp=0093630 esp=0009d600 > cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 > cs:eip=0f 30 0f 20 e0 83 c8 30-0f 22 e0 b8 00 f0 03 00 of 22 d8 0f 20 > c0 0d 00-00 00 80 0f 22 c0 b8 00 > ss:esp=69 95 00 00 00 40 dd 00-00 50 dd 00 00 10 04 00 00 00 00 00 00 > 00 04 00-00 00 00 00 00 40 dd 00 > > BTX halted > > I have tried both 5.4-release and 6.0-beta with the same results. The > machine works fine with i386 5.4. The box is an MSI K8t Neo Mobo, > running a 2800+ Sempron. > Anyone have a suggestion? Looks like your BIOS is trying to enter long mode or something: 00000000 0F30 wrmsr 00000002 0F20E0 mov eax,cr4 00000005 83C830 or ax,byte +0x30 00000008 0F22E0 mov cr4,eax 0000000B B800F0 mov ax,0xf000 0000000E 0300 add ax,[bx+si] 00000010 00 db 0x00 Actually, this isn't your BIOS, this might be in the kernel startup. The code after the wrmsr is trying to turn on PSE and PAE. %ecx is 0xc0000000, and I don't think that is a valid MSR. The eip is still in the loader. Hmm, looks like it is the code in the amd64 trampoline: amd64_tramp: /* Be sure that interrupts are disabled */ cli /* Turn on EFER.LME */ movl $MSR_EFER, %ecx rdmsr orl $EFER_LME, %eax wrmsr /* Turn on PAE */ movl %cr4, %eax orl $(CR4_PAE | CR4_PSE), %eax movl %eax, %cr4 /* Set %cr3 for PT4 */ movl $VTOP(PT4), %eax movl %eax, %cr3 Hmm, looks like MSR_EFER is supposed to be 0xc0000080. Are you sure the value is 0xc0000000? If so, perhaps your loader is corrupted and/or you have some bad memory perhaps? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 18:37:11 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 B142916A430; Tue, 2 Aug 2005 18:37:11 +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 2250643D5C; Tue, 2 Aug 2005 18:37:11 +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 j72IjGQO046484; Tue, 2 Aug 2005 12:45:16 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42EFBD4A.1020001@samsco.org> Date: Tue, 02 Aug 2005 12:36:58 -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: obrien@freebsd.org References: <20050727.154329.71086249.chat95@mac.com> <20050802180022.GO71672@dragon.NUXI.org> In-Reply-To: <20050802180022.GO71672@dragon.NUXI.org> 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: 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: Tue, 02 Aug 2005 18:37:14 -0000 David O'Brien wrote: > On Wed, Jul 27, 2005 at 03:43:29PM +0900, NAKATA Maho wrote: > >>Hello >>sometimes my opteron box locks up recently, >>it seems that there are some discussion about this issue >>on the list. > > .. > >>* set hw.physmem="4G" doesn't help > > > Try something like "3G" instead. > > >>workaround: >>on board GbE (bge0) and SATA disabled. > > > I've found that the Silicon Images SATA driver isn't >4GB clean. > I can easily panic my Iwill DK8X with 8GB of RAM when I try to use a > Silicon Images based SATA mirror. > Is it not 64-bit clean, or is that it doesn't handle more than 32 bits of data address space correctly? There's a sharp difference. Take the asr driver for example; it isn't 64 bit clean because it tries to store kernel data pointers into 32-bit quantities. It also doesn't work with more than 32bits worth of data memory because, well, it sucks. Anyways, I know that the SiL311x parts do not do 64-bit data addressing, so it's up to the driver to use busdma correctly. Since it works on AMD64 with less than 4GB of RAM, I suspect that it's 64-bit clean, but it doesn't use busdma correctly. Scott From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 18:43: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 70CF416A41F for ; Tue, 2 Aug 2005 18:43: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 E54EA43D4C for ; Tue, 2 Aug 2005 18: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 92B2597924; Tue, 2 Aug 2005 11:43:35 -0700 (PDT) Message-Id: <3.0.1.32.20050802114339.00a547c8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Tue, 02 Aug 2005 11:43:39 -0700 To: freebsd-amd64@freebsd.org From: ray@redshift.com Cc: freebsd-amd64@freebsd.org In-Reply-To: <20050802181355.GP71672@dragon.NUXI.org> References: <3.0.1.32.20050802105941.00a547c8@pop.redshift.com> <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050728013152.00a4d188@pop.redshift.com> <3.0.1.32.20050729020609.00a6a240@pop.redshift.com> <3.0.1.32.20050802105941.00a547c8@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: Tue, 02 Aug 2005 18:43:36 -0000 At 11:13 AM 8/2/2005 -0700, David O'Brien wrote: | On Tue, Aug 02, 2005 at 10:59:41AM -0700, ray@redshift.com wrote: | > Thanks David - needless to say, I'm going to be re-running all my benchmarks | ... | > I'll post my results when I have another machine in here and re-run the exact | > same benchmarks. This time I will be certain to confirm the situation on the | > SMP kernel with regard to the AMD64 branch. | | You need to be careful about what you are testing. | If you dual-boot 64-bit and 32-bit from the same disk, don't forget one | of them will be on a faster area of the disk. So you need a 2nd data | disk that is newfs'ed between each run to do your benchmarks on. | | At a minium, you should build a set of 32-bit binaries on FreeBSD/i386 | with CPUTYPE=k8. Run benchmarks under the 32-bit OS. | Then run the same benchmarks with the 32-bit binaries on the 64-bit OS. | (ie, you're just changing the kernel). | Then build 64-bit binaries and benchmark them. | You should use RELENG_6, not 5.x to make sure you're getting the best K8 | GCC we support along with the optimizations we've added since 5.x was | released. | | -- | -- David (obrien@FreeBSD.org) okay, thanks for the info. I'll keep that handy for when I have another machine to test. Ray From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 18:44:57 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 44BF416A41F for ; Tue, 2 Aug 2005 18:44:57 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DA243D46 for ; Tue, 2 Aug 2005 18:44:56 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j72IiuRA087466; Tue, 2 Aug 2005 11:44:56 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j72IisLs087465; Tue, 2 Aug 2005 11:44:54 -0700 (PDT) (envelope-from obrien) Date: Tue, 2 Aug 2005 11:44:54 -0700 From: "David O'Brien" To: Scott Long Message-ID: <20050802184454.GA87421@dragon.NUXI.org> References: <20050727.154329.71086249.chat95@mac.com> <20050802180022.GO71672@dragon.NUXI.org> <42EFBD4A.1020001@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42EFBD4A.1020001@samsco.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i 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 Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 18:44:57 -0000 On Tue, Aug 02, 2005 at 12:36:58PM -0600, Scott Long wrote: > Is it not 64-bit clean, or is that it doesn't handle more than 32 bits > of data address space correctly? There's a sharp difference. ENOCLUE - I've posted the panic stack trace, but haven't heard anything from the maintainer. Diving into this issue isn't something I had much time for -- I needed to add storage to that machine ASAP and took another path. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 2 22:39: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 144BF16A41F for ; Tue, 2 Aug 2005 22:39:14 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A443243D78 for ; Tue, 2 Aug 2005 22:39:12 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j72MfjNq050671; Tue, 2 Aug 2005 18:41:45 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: NIKSUN, Inc. To: freebsd-amd64@freebsd.org Date: Tue, 2 Aug 2005 18:38:43 -0400 User-Agent: KMail/1.6.2 References: <20050801203305.GA3612@users.altadena.net> In-Reply-To: <20050801203305.GA3612@users.altadena.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200508021838.45622.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.85.1/1001/Tue Aug 2 04:22:39 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Pete Carah Subject: Re: Compaq v2310 revisited in 32-bit mode X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jkim@niksun.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 22:39:14 -0000 On Monday 01 August 2005 04:33 pm, Pete Carah wrote: > There is no 64-bit Broadcom driver out there that I could find that > handled the 4318. Linuxant.com had a 64bit driver that, when the > .inf was patched to recognize the 4318, did so, but fbsd never > attached the ndis driver due to a timeout. Try this: http://csd.acer.com.tw/SI/Download2.nsf/1815c7c6f8aff65d48256bdd0035cffd/3258e9e4bc7d2e584825702f00124f32/$FILE/80211g.rar One Linux user told it didn't work with their ndiswrapper but you may have better luck with NDISulator. Who knows? ;-) > The 32bit driver is better but doesn't handle WPA. (in fact nothing > shows up in "list scan" so something fundamental is wrong. I got > the driver out of my own /windows/system32/drivers directory so I > know it works in windoze (WPA works fine in windows on the same > access point). AFAIK, NDISulator doesn't (or can't?) do WPA yet. Jung-uk Kim From owner-freebsd-amd64@FreeBSD.ORG Wed Aug 3 12:48: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 8DAB616A41F for ; Wed, 3 Aug 2005 12:48:15 +0000 (GMT) (envelope-from dystopianrebel@yahoo.com) Received: from web52306.mail.yahoo.com (web52306.mail.yahoo.com [206.190.48.149]) by mx1.FreeBSD.org (Postfix) with SMTP id DFED443D48 for ; Wed, 3 Aug 2005 12:48:14 +0000 (GMT) (envelope-from dystopianrebel@yahoo.com) Received: (qmail 17892 invoked by uid 60001); 3 Aug 2005 12:48:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fewmdNpfdai9kBvemEQrbbhx6qFsoIXZQhrm0jx5Th2j0shP8u4Js43gNEQCxmShgO5AYfD3NXQ/m3D0PQI4QzemzauWtPvw4aXSQ92TofcEqEMbJZJ+RcA60kwhozdItUmvuUkccEGU+e2zXlDogXUhiiuu6MXr5VQxD8KAVQo= ; Message-ID: <20050803124814.17890.qmail@web52306.mail.yahoo.com> Received: from [64.26.160.170] by web52306.mail.yahoo.com via HTTP; Wed, 03 Aug 2005 05:48:14 PDT Date: Wed, 3 Aug 2005 05:48:14 -0700 (PDT) From: dR To: freebsd-amd64@freebsd.org, freebsd-java@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Building JDK15 for AMD64 -- status of the "long-command" error? 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, 03 Aug 2005 12:48:15 -0000 A few weeks ago, someone on the AMD64 list was going to try to find a solution to the "long-command" error that one sees when trying to build JDK15 for AMD64. One theory is that this problem is caused by a bug in the Linux Java binary that is needed to seed the FreeBSD build. While sifting through the mail archive yesterday, I saw a comment by someone saying that the JDK15 problem does not exist in 5.4 CURRENT. (I am using 5.4 STABLE.) Would someone please confirm whether the bug exists in 5.4 CURRENT or 6.0? Marko Ottawa, Canada __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-amd64@FreeBSD.ORG Wed Aug 3 15:31: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 F2EF416A420 for ; Wed, 3 Aug 2005 15:31:52 +0000 (GMT) (envelope-from rnsanchez@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5E7143D53 for ; Wed, 3 Aug 2005 15:31:51 +0000 (GMT) (envelope-from rnsanchez@gmail.com) Received: by wproxy.gmail.com with SMTP id i22so168564wra for ; Wed, 03 Aug 2005 08:31:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q1gTbT+7gYinFRUf2OI12Iebf8aD9ke1NDGFxDyrDPyJ32zV+wTIaneiRPSxdnkTp844Z9Zxf4T16AHTuktGrs1vUce3PCqicpdMd+y34ejKRTtlTir0HqA8mOvFwiPugic6kcDtl0B3CGB9jiygMAA+HRsl3bWpQ0JdlUo+Zt8= Received: by 10.54.13.77 with SMTP id 77mr689353wrm; Wed, 03 Aug 2005 08:31:51 -0700 (PDT) Received: by 10.54.38.8 with HTTP; Wed, 3 Aug 2005 08:31:50 -0700 (PDT) Message-ID: <52b3de6f0508030831f2995ba@mail.gmail.com> Date: Wed, 3 Aug 2005 12:31:50 -0300 From: Ricardo Nabinger Sanchez To: Rui Paulo In-Reply-To: <20050802142722.GA2583@proton.internal.fnop.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> <20050801200552.GA13041@troutmask.apl.washington.edu> <20050802142722.GA2583@proton.internal.fnop.net> Cc: Giorgos Keramidas , freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 03 Aug 2005 15:31:53 -0000 Hello, On 8/2/05, Rui Paulo wrote: > On 2005.08.01 13:05:52 +0000, Steve Kargl wrote: > | On Mon, Aug 01, 2005 at 10:55:39PM +0300, Giorgos Keramidas wrote: > | > On 2005-08-02 02:25, Xin LI wrote: > | > > Hi, Guys, > | > > > | > > Here is a patchset that I have produced to make our libc aware of t= he > | > > NetBSD assembly implementation of the string related operations. > | > > | > I can't speak for the asm code, since I know barely enough amd64 thin= gs > | > to read it, but there are a few typos you might want to fix before th= is > | > gets committed. > | > > | > | Ditto. > | > | > > | > That's all I could spot. > | > > | > | There is an occurrence of "occurance", which should be "occurrence". :-= ) >=20 > Thank you Steve Kargl and Giorgos Keramidas, I fixed those typos on NetBS= D. >=20 > http://mail-index.netbsd.org/source-changes/2005/08/02/0009.html > http://mail-index.netbsd.org/source-changes/2005/08/02/0010.html There's also this one: +L3:=09movzbl=09(%rdi),%eax=09=09/* unsigned comparision */ s/comparision/comparison --=20 Ricardo Nabinger Sanchez GNU/Linux #140696 [http://counter.li.org] Slackware Linux + FreeBSD From owner-freebsd-amd64@FreeBSD.ORG Wed Aug 3 23:02: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 457B416A41F for ; Wed, 3 Aug 2005 23:02:34 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: from pluricanal.net (mail.pluricanal.net [83.144.129.196]) by mx1.FreeBSD.org (Postfix) with SMTP id 1A49543D53 for ; Wed, 3 Aug 2005 23:02:32 +0000 (GMT) (envelope-from rpaulo@NetBSD.org) Received: (qmail 5358 invoked from network); 4 Aug 2005 00:53:50 -0000 Received: from unknown (HELO proton.internal.fnop.net) (83.144.140.19) by mail.pluricanal.net with SMTP; 4 Aug 2005 00:53:50 -0000 Received: by proton.internal.fnop.net (Postfix, from userid 1000) id C9982330F; Wed, 3 Aug 2005 23:58:58 +0100 (WEST) Date: Wed, 3 Aug 2005 23:58:58 +0100 From: Rui Paulo To: Ricardo Nabinger Sanchez Message-ID: <20050803225858.GA1180@proton.internal.fnop.net> References: <20050801182518.GA85423@frontfree.net> <20050801195539.GB1406@beatrix.daedalusnetworks.priv> <20050801200552.GA13041@troutmask.apl.washington.edu> <20050802142722.GA2583@proton.internal.fnop.net> <52b3de6f0508030831f2995ba@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52b3de6f0508030831f2995ba@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Giorgos Keramidas , freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 03 Aug 2005 23:02:34 -0000 On 2005.08.03 12:31:50 +0000, Ricardo Nabinger Sanchez wrote: | There's also this one: | | +L3: movzbl (%rdi),%eax /* unsigned comparision */ | | s/comparision/comparison Fixed, thanks. -- Rui Paulo From owner-freebsd-amd64@FreeBSD.ORG Thu Aug 4 22:33: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 11FDC16A41F; Thu, 4 Aug 2005 22:33:47 +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 91F7043D69; Thu, 4 Aug 2005 22:33:35 +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 j74MXYwB005491; Fri, 5 Aug 2005 00:33: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 j74MXY2S005489; Fri, 5 Aug 2005 00:33:34 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j74MVFWk021621; Fri, 5 Aug 2005 00:31:15 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j74MVEqW021620; Fri, 5 Aug 2005 00:31:14 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 5 Aug 2005 00:31:14 +0200 To: freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org, qemu-devel@nongnu.org Message-ID: <20050804223114.GA21296@saturn.kn-bremen.de> Mail-Followup-To: freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org, qemu-devel@nongnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: freebsd qemu port update - kqemu wrapper merge, need testing 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, 04 Aug 2005 22:33:47 -0000 Okay, I finally got around looking at this a little longer and came up with the port update below. Specifically, I tried to merge the good parts of the old kqemu wrapper: - device cloning support on 5.x (multiple vms can use kqemu, tested and seems to work) - 4.x support (untested, I'm not sure if vm_map_user_pageable can be used as a 1-to-1 replacement for vm_map_{un,}wire on 4.x, can anyone here definitely say?) - max_locked_pages calculation Also: - moved debug messages under debug.kqemu_debug sysctl (do `sysctl debug.kqemu_debug=1' to enable) - fixed a small bug - added the amd64 ata irq mapping fix Also untested on amd64. Removed files: files/BSDmakefile files/kmod_bsd.c New files: files/kqemu-freebsd-patch files/patch-libmath2 files/patch-vl.c patch-hw::ide.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 4 Aug 2005 19:28:21 -0000 @@ -6,12 +6,12 @@ # PORTNAME= qemu -PORTVERSION= 0.7.0s.20050717 +PORTVERSION= 0.7.1s.20050803 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 +DISTNAME= ${PORTNAME}-snapshot-2005-08-03_23 EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} MAINTAINER= nox@jelal.kn-bremen.de @@ -23,8 +23,9 @@ .endif .if defined(WITH_KQEMU) -DISTKQEMU= kqemu-0.6.2-1.tar.gz +DISTKQEMU= kqemu-0.7.1-1.tar.gz DISTFILES= ${EXTRACT_ONLY} ${DISTKQEMU} +EXTRA_PATCHES= ${FILESDIR}/kqemu-freebsd-patch .endif HAS_CONFIGURE= yes @@ -40,9 +41,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 +55,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 +66,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 +84,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 4 Aug 2005 19:29:01 -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-snapshot-2005-08-03_23.tar.bz2) = 69f7547ef97e02860677dcf926f57e35 +SIZE (qemu-snapshot-2005-08-03_23.tar.bz2) = 1120642 +MD5 (kqemu-0.7.1-1.tar.gz) = 012498dac620eb8c212bf5f622414dd0 +SIZE (kqemu-0.7.1-1.tar.gz) = 76427 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,489 @@ +Index: qemu/kqemu/Makefile.freebsd +@@ -1,9 +1,13 @@ ++# $Id: Makefile.freebsd,v 1.1 2005/04/17 17:21:31 bellard Exp $ + KMOD= kqemu + 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= + +Index: qemu/kqemu/kqemu-freebsd.c +@@ -3,20 +3,33 @@ + #include + #include + #include ++#include ++#include + #include + #include + #include + #include + #include ++#include ++#if __FreeBSD_version > 500000 + #include ++#endif + #include + #include ++#include ++#include ++#if __FreeBSD_version < 500000 ++#include ++#endif ++ + #include + #include + #include + #include + #include + #include ++#include ++ + #include + #include + +@@ -27,10 +40,14 @@ + MALLOC_DECLARE(M_KQEMU); + MALLOC_DEFINE(M_KQEMU, "kqemu", "kqemu buffers"); + ++int kqemu_debug; ++SYSCTL_INT(_debug, OID_AUTO, kqemu_debug, CTLFLAG_RW, &kqemu_debug, 0, ++ "kqemu debug flag"); ++ + #define USER_BASE 0x1000 + + /* lock the page at virtual address 'user_addr' and return its +- physical page index. Return -1 if error */ ++ physical page index. Return NULL if error */ + struct kqemu_user_page *CDECL kqemu_lock_user_page(unsigned long *ppage_index, + unsigned long user_addr) + { +@@ -39,14 +56,18 @@ + vm_paddr_t pa = 0; + int ret; + pmap_t pmap; ++#if __FreeBSD_version > 500000 + ret = vm_map_wire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); ++#else ++ ret = vm_map_user_pageable(&vm->vm_map, va, va+PAGE_SIZE, FALSE); ++#endif + if (ret != KERN_SUCCESS) { +- printf("kqemu_lock_user_page(%08lx) failed, ret=%d\n", user_addr, ret); ++ kqemu_log("kqemu_lock_user_page(%08lx) failed, ret=%d\n", user_addr, ret); + return NULL; + } + pmap = vm_map_pmap(&vm->vm_map); + pa = pmap_extract(pmap, va); +- // printf("kqemu_lock_user_page(%08lx) va=%08x pa=%08x\n", user_addr, va, pa); ++ // kqemu_log("kqemu_lock_user_page(%08lx) va=%08x pa=%08x\n", user_addr, va, pa); + *ppage_index = pa >> PAGE_SHIFT; + return (struct kqemu_user_page *)va; + } +@@ -56,12 +77,16 @@ + struct vmspace *vm = curproc->p_vmspace; + vm_offset_t va; + int ret; +- // printf("kqemu_unlock_user_page(%08lx)\n", page_index); ++ // kqemu_log("kqemu_unlock_user_page(%08lx)\n", page_index); + va = (vm_offset_t)page; ++#if __FreeBSD_version > 500000 + ret = vm_map_unwire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); ++#else ++ ret = vm_map_user_pageable(&vm->vm_map, va, va+PAGE_SIZE, TRUE); ++#endif + #if 0 + if (ret != KERN_SUCCESS) { +- printf("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); ++ kqemu_log("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); + } + #endif + } +@@ -78,19 +103,20 @@ + + va = kmem_alloc(kernel_map, PAGE_SIZE); + if (va == 0) { +- printf("kqemu_alloc_zeroed_page: NULL\n"); +- return -1; ++ kqemu_log("kqemu_alloc_zeroed_page: NULL\n"); ++ return NULL; + } + pmap = vm_map_pmap(kernel_map); + pa = pmap_extract(pmap, va); +- // printf("kqemu_alloc_zeroed_page: %08x\n", pa); ++ // kqemu_log("kqemu_alloc_zeroed_page: %08x\n", pa); + *ppage_index = pa >> PAGE_SHIFT; + return (struct kqemu_page *)va; + } + + void CDECL kqemu_free_page(struct kqemu_page *page) + { +- // printf("kqemu_free_page(%08lx)\n", page_index); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_free_page(%p)\n", page); + /* XXX: do it */ + } + +@@ -109,22 +135,25 @@ + vm_offset_t va = USER_BASE; + int rv; + if (size % PAGE_SIZE != 0) { +- printf("kqemu_vmalloc(%d) not a multiple of page size\n", size); ++ kqemu_log("kqemu_vmalloc(%d) not a multiple of page size\n", size); + return NULL; + } + rv = vm_map_find(&vm->vm_map, NULL, 0, &va, size, 1, + VM_PROT_ALL, VM_PROT_ALL, 0); + if (rv != KERN_SUCCESS) { +- printf("kqemu_vmalloc(%d) failed rv=%d\n", size, rv); ++ kqemu_log("kqemu_vmalloc(%d) failed rv=%d\n", size, rv); + return NULL; + } +- printf("kqemu_vmalloc(%d): %08x\n", size, va); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vmalloc(%d): %08x\n", size, va); + return (void *)va; + } + + void CDECL kqemu_vfree(void *ptr) + { +- printf("kqemu_vfree(%p)\n", ptr); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vfree(%p)\n", ptr); ++ /* XXX: do it */ + } + + /* return the physical page index for a given virtual page */ +@@ -137,10 +166,11 @@ + pmap = vm_map_pmap(&vm->vm_map); + pa = pmap_extract(pmap, (vm_offset_t)vaddr); + if (pa == 0) { +- printf("kqemu_vmalloc_to_phys(%p)->error\n", vaddr); ++ kqemu_log("kqemu_vmalloc_to_phys(%p)->error\n", vaddr); + return -1; + } +- printf("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa); + return pa >> PAGE_SHIFT; + } + +@@ -156,16 +186,48 @@ + { + } + ++#if __FreeBSD_version < 500000 ++static int ++curpriority_cmp(struct proc *p) ++{ ++ int c_class, p_class; ++ ++ c_class = RTP_PRIO_BASE(curproc->p_rtprio.type); ++ p_class = RTP_PRIO_BASE(p->p_rtprio.type); ++ if (p_class != c_class) ++ return (p_class - c_class); ++ if (p_class == RTP_PRIO_NORMAL) ++ return (((int)p->p_priority - (int)curpriority) / PPQ); ++ return ((int)p->p_rtprio.prio - (int)curproc->p_rtprio.prio); ++} ++ ++/* return TRUE if a signal is pending (i.e. the guest must stop ++ execution) */ ++int CDECL kqemu_schedule(void) ++{ ++ struct proc *p = curproc; ++ if (curpriority_cmp(p) > 0) { ++ int s = splhigh(); ++ p->p_priority = MAXPRI; ++ setrunqueue(p); ++ p->p_stats->p_ru.ru_nvcsw++; ++ mi_switch(); ++ splx(s); ++ } ++ return issignal(curproc) != 0; ++} ++#else + /* return TRUE if a signal is pending (i.e. the guest must stop + execution) */ + int CDECL kqemu_schedule(void) + { +- // printf("kqemu_schedule\n"); ++ // kqemu_log("kqemu_schedule\n"); + mtx_lock_spin(&sched_lock); + mi_switch(SW_VOL, NULL); + mtx_unlock_spin(&sched_lock); + return SIGPENDING(curthread); + } ++#endif + + static char log_buf[4096]; + +@@ -178,47 +240,149 @@ + va_end(ap); + } + ++#define KQEMU_MAX_INSTANCES 4 ++ + struct kqemu_instance { ++#if __FreeBSD_version > 500000 ++ TAILQ_ENTRY(kqemu_instance) kqemu_ent; ++ struct cdev *kqemu_dev; ++#endif + // struct semaphore sem; + struct kqemu_state *state; + }; + ++static int kqemu_ref_count = 0; ++static int max_locked_pages; ++ ++#if __FreeBSD_version < 500000 ++static dev_t kqemu_dev; ++#else ++static struct clonedevs *kqemuclones; ++static TAILQ_HEAD(,kqemu_instance) kqemuhead = TAILQ_HEAD_INITIALIZER(kqemuhead); ++static eventhandler_tag clonetag; ++#endif ++ + static d_close_t kqemu_close; + static d_open_t kqemu_open; + static d_ioctl_t kqemu_ioctl; + + static struct cdevsw kqemu_cdevsw = { ++#if __FreeBSD_version < 500000 ++ /* open */ kqemu_open, ++ /* close */ kqemu_close, ++ /* read */ noread, ++ /* write */ nowrite, ++ /* ioctl */ kqemu_ioctl, ++ /* poll */ nopoll, ++ /* mmap */ nommap, ++ /* strategy */ nostrategy, ++ /* name */ "kqemu", ++ /* maj */ KQEMU_MAJOR, ++ /* dump */ nodump, ++ /* psize */ nopsize, ++ /* flags */ 0, ++ /* bmaj */ -1 ++#else + .d_version = D_VERSION, + .d_flags = D_NEEDGIANT, + .d_open = kqemu_open, + .d_ioctl = kqemu_ioctl, + .d_close = kqemu_close, + .d_name = "kqemu" ++#endif + }; + +-/* For use with make_dev(9)/destroy_dev(9). */ +-static struct cdev *kqemu_dev; ++#if __FreeBSD_version > 500000 ++static void ++kqemu_clone(void *arg, char *name, int namelen, struct cdev **dev) ++{ ++ int unit, r; ++ if (*dev != NULL) ++ return; ++ ++ if (strcmp(name, "kqemu") == 0) ++ unit = -1; ++ else if (dev_stdclone(name, NULL, "kqemu", &unit) != 1) ++ return; /* Bad name */ ++ if (unit != -1 && unit > KQEMU_MAX_INSTANCES) ++ return; ++ ++ r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0); ++ if (r) { ++ *dev = make_dev(&kqemu_cdevsw, unit2minor(unit), ++ UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit); ++ if (*dev != NULL) { ++ dev_ref(*dev); ++ (*dev)->si_flags |= SI_CHEAPCLONE; ++ } ++ } ++} ++#endif ++ ++static void kqemu_destroy(struct kqemu_instance *ks) ++{ ++ struct cdev *dev = ks->kqemu_dev; ++ ++ if (ks->state) { ++ kqemu_delete(ks->state); ++ ks->state = NULL; ++ } ++ ++ free(ks, M_KQEMU); ++ dev->si_drv1 = NULL; ++#if __FreeBSD_version > 500000 ++ TAILQ_REMOVE(&kqemuhead, ks, kqemu_ent); ++ destroy_dev(dev); ++#endif ++ --kqemu_ref_count; ++} + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_open(dev_t dev, int flags, int fmt __unused, struct proc *p) ++{ ++#else + kqemu_open(struct cdev *dev, int flags, int fmt __unused, + struct thread *td) + { ++ struct proc *p = td->td_proc; ++#endif + struct kqemu_instance *ks; ++ ++ if (dev->si_drv1 || kqemu_ref_count >= KQEMU_MAX_INSTANCES) ++ return(EBUSY); ++ ++ if ((flags & (FREAD|FWRITE)) == FREAD) ++ return(EPERM); ++ + ks = malloc(sizeof(struct kqemu_instance), M_KQEMU, M_WAITOK); + if (ks == NULL) { +- printf("malloc failed\n"); ++ kqemu_log("malloc failed\n"); + return ENOMEM; + } +- ks->state = NULL; ++ memset(ks, 0, sizeof *ks); ++#if __FreeBSD_version > 500000 ++ ks->kqemu_dev = dev; ++ TAILQ_INSERT_TAIL(&kqemuhead, ks, kqemu_ent); ++#endif ++ kqemu_ref_count++; ++ + dev->si_drv1 = ks; ++ if (kqemu_debug > 0) ++ kqemu_log("opened by pid=%d\n", p->p_pid); + return 0; + } + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_ioctl(dev_t dev, u_long cmd, caddr_t addr, ++ int flags __unused, struct proc *p) ++#else + kqemu_ioctl(struct cdev *dev, u_long cmd, caddr_t addr, + int flags __unused, struct thread *td) ++#endif + { + int error = 0; + int ret; +@@ -233,8 +397,9 @@ + break; + } + d1 = *(struct kqemu_init *)addr; +- printf("ram_base=%p ram_size=%ld\n", d1.ram_base, d1.ram_size); +- s = kqemu_init(d, 16000); ++ if (kqemu_debug > 0) ++ kqemu_log("ram_base=%p ram_size=%ld\n", d1.ram_base, d1.ram_size); ++ s = kqemu_init(d, max_locked_pages); + if (s == NULL) { + error = ENOMEM; + break; +@@ -250,9 +415,16 @@ + } + ctx = kqemu_get_cpu_state(s); + *ctx = *(struct kqemu_cpu_state *)addr; ++#if __FreeBSD_version > 500000 + DROP_GIANT(); ++#endif + ret = kqemu_exec(s); ++#if __FreeBSD_version > 500000 + PICKUP_GIANT(); ++ td->td_retval[0] = ret; ++#else ++ p->p_retval[0] = ret; ++#endif + *(struct kqemu_cpu_state *)addr = *ctx; + break; + } +@@ -267,10 +439,22 @@ + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_close(dev_t dev, int flags, int fmt __unused, struct proc *p) ++{ ++#else + kqemu_close(struct cdev *dev __unused, int flags, int fmt __unused, + struct thread *td) + { +- return 0; ++ struct proc *p = td->td_proc; ++#endif ++ struct kqemu_instance *ks = (struct kqemu_instance *) dev->si_drv1; ++ ++ kqemu_destroy(ks); ++ ++ if (kqemu_debug > 0) ++ kqemu_log("closed by pid=%d\n", p->p_pid); ++ return 0; + } + + /* ARGSUSED */ +@@ -278,15 +462,55 @@ + kqemu_modevent(module_t mod __unused, int type, void *data __unused) + { + int error = 0; ++#if __FreeBSD_version < 500000 ++ int rc; ++#else ++ struct kqemu_instance *ks; ++#endif + + switch (type) { + case MOD_LOAD: + printf("kqemu version 0x%08x\n", KQEMU_VERSION); ++ max_locked_pages = physmem / (2 * KQEMU_MAX_INSTANCES); ++ if (max_locked_pages > 32768) ++ max_locked_pages = 32768; ++#if __FreeBSD_version < 500000 ++ if ((rc = cdevsw_add(&kqemu_cdevsw))) { ++ kqemu_log("error registering cdevsw, rc=%d\n", rc); ++ error = ENOENT; ++ break; ++ } + kqemu_dev = make_dev(&kqemu_cdevsw, 0, +- UID_ROOT, GID_WHEEL, 0666, "kqemu"); ++ UID_ROOT, GID_WHEEL, 0660, "kqemu"); ++#else ++ clone_setup(&kqemuclones); ++ clonetag = EVENTHANDLER_REGISTER(dev_clone, kqemu_clone, 0, 1000); ++ if (!clonetag) { ++ error = ENOMEM; ++ break; ++ } ++#endif ++ kqemu_log("KQEMU installed, max_instances=%d max_locked_mem=%dkB.\n", ++ KQEMU_MAX_INSTANCES, max_locked_pages * 4); ++ ++ kqemu_ref_count = 0; + break; + case MOD_UNLOAD: ++ if (kqemu_ref_count > 0) { ++ error = EBUSY; ++ break; ++ } ++#if __FreeBSD_version < 500000 + destroy_dev(kqemu_dev); ++ if ((rc = cdevsw_remove(&kqemu_cdevsw))) ++ kqemu_log("error unregistering, rc=%d\n", rc); ++#else ++ EVENTHANDLER_DEREGISTER(dev_clone, clonetag); ++ while ((ks = TAILQ_FIRST(&kqemuhead)) != NULL) { ++ kqemu_destroy(ks); ++ } ++ clone_cleanup(&kqemuclones); ++#endif + break; + case MOD_SHUTDOWN: + break; 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]; Index: files/patch-hw::ide.c @@ -0,0 +1,9 @@ +Index: qemu/hw/ide.c +@@ -2330,6 +2330,7 @@ + pci_conf[0x01] = 0x80; + pci_conf[0x02] = 0x10; + pci_conf[0x03] = 0x70; ++ pci_conf[0x09] = 0x80; // legacy ATA mode + pci_conf[0x0a] = 0x01; // class_sub = PCI_IDE + pci_conf[0x0b] = 0x01; // class_base = PCI_mass_storage + pci_conf[0x0e] = 0x00; // header_type From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 00:53: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 BBADD16A41F for ; Fri, 5 Aug 2005 00:53:43 +0000 (GMT) (envelope-from rk@wrpkap.net) Received: from mail.telnix.com (66-224-227-82.atgi.net [66.224.227.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 693C643D45 for ; Fri, 5 Aug 2005 00:53:43 +0000 (GMT) (envelope-from rk@wrpkap.net) Received: (qmail 11270 invoked from network); 5 Aug 2005 00:53:42 -0000 Received: from 69-29-32-178.dyn.centurytel.net (HELO ?192.168.1.46?) (rk@wrpkap.net@69.29.32.178) by 66-224-227-82.atgi.net with SMTP; 5 Aug 2005 00:53:42 -0000 Message-ID: <42F2B889.2010106@wrpkap.net> Date: Thu, 04 Aug 2005 19:53:29 -0500 From: Randy Powell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050724 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: 66-224-227-82.atgi.net 0/1/N Cc: Subject: AMD 64 & 5.4 i386 intalls 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, 05 Aug 2005 00:53:43 -0000 I am in the process of up-dating my motherboard, cpu, and memory. I have three Maxter 60GB ATA 133 HDs with Windblows xp on one and two Freebsd5.4 installs on the other two. Since my current system is i386, my fear is that I will have to reload BSD5.4 amd64 program. What say you :) Randy rk@wrpkap.net From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 07:57:28 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 49CAC16A41F for ; Fri, 5 Aug 2005 07:57:28 +0000 (GMT) (envelope-from groot@kde.org) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9ED443D46 for ; Fri, 5 Aug 2005 07:57:27 +0000 (GMT) (envelope-from groot@kde.org) Received: from odin.cs.kun.nl [131.174.33.33] (helo=localhost.englishbreakfastnetwork.org) by pandora.cs.kun.nl (8.12.10/5.2) with ESMTP id j757vOJZ005113; Fri, 5 Aug 2005 09:57:24 +0200 (MEST) From: Adriaan de Groot To: freebsd-amd64@freebsd.org Date: Fri, 5 Aug 2005 09:57:08 +0200 User-Agent: KMail/1.8.50 References: <42F2B889.2010106@wrpkap.net> In-Reply-To: <42F2B889.2010106@wrpkap.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508050957.09193.groot@kde.org> X-Spam-Score: -1.399 () BAYES_00,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 131.174.33.4 Cc: Randy Powell Subject: Re: AMD 64 & 5.4 i386 intalls 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, 05 Aug 2005 07:57:28 -0000 On Friday 05 August 2005 02:53, Randy Powell wrote: > Freebsd5.4 installs on the other two. Since my current system is i386, > my fear is that I will have to reload BSD5.4 amd64 program. It's not really clear what you're asking here. In any case, FreeBSD i386 runs just fine on amd64 hardware, you just won't have the amd64 specific things turned on -- only really relevant if you have lots of memory, do scientific computing, or run big databases (in which case recent threads suggest that it's faster to run i386 anyway). -- These are your friends - Adem GPG: FEA2 A3FE Adriaan de Groot From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 19:48: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 724F616A41F for ; Fri, 5 Aug 2005 19:48:20 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76D4243D48 for ; Fri, 5 Aug 2005 19:48:18 +0000 (GMT) (envelope-from lars.tunkrans@bredband.net) Received: from [192.168.245.40] ([213.112.167.85] [213.112.167.85]) by mxfep01.bredband.com with ESMTP id <20050805194817.MNOA11632.mxfep01.bredband.com@[192.168.245.40]>; Fri, 5 Aug 2005 21:48:17 +0200 Message-ID: <42F3C27F.7000103@bredband.net> Date: Fri, 05 Aug 2005 21:48:15 +0200 From: Lars Tunkrans User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Powell References: <42F2B889.2010106@wrpkap.net> In-Reply-To: <42F2B889.2010106@wrpkap.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@FreeBSD.org Subject: Re: AMD 64 & 5.4 i386 intalls 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, 05 Aug 2005 19:48:20 -0000 Randy Powell wrote: > I am in the process of up-dating my motherboard, cpu, and memory. I > have three Maxter 60GB ATA 133 HDs with Windblows xp on one and two > Freebsd5.4 installs on the other two. Since my current system is i386, > my fear is that I will have to reload BSD5.4 amd64 program. > > What say you :) Unless you manage to buy a motherboard that has serious problems ( like those with Nforce3 150 chipset ) you should be able to run the GENERIC i386 kernel on the new system and then customise for any additional bits. I am running the MSI K8T Neo2 FIR ( Via K8T800-Pro chipset ) with FreeBSD 5.4 i386. //Lars From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 21:40: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 5972A16A41F; Fri, 5 Aug 2005 21:40:15 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CBC843D45; Fri, 5 Aug 2005 21:40:13 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h122.241.159.dialup.iptcom.net ([213.159.241.122]:41168 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1219359AbVHEVkL (ORCPT + 1 other); Sat, 6 Aug 2005 00:40:11 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [10.0.0.1]) by kushnir1.kiev.ua (8.13.4/8.13.3) with ESMTP id j75Le6M4001612; Sat, 6 Aug 2005 00:40:06 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Sat, 6 Aug 2005 00:40:06 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: Juergen Lock In-Reply-To: <20050804223114.GA21296@saturn.kn-bremen.de> Message-ID: <20050806002532.N902@kushnir1.kiev.ua> References: <20050804223114.GA21296@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-emulation@freebsd.org, qemu-devel@nongnu.org, freebsd-amd64@freebsd.org Subject: Re: freebsd qemu port update - kqemu wrapper merge, need testing 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, 05 Aug 2005 21:40:15 -0000 Hi Thanks for your work, but... (see below) On Fri, 5 Aug 2005, Juergen Lock wrote: > Okay, I finally got around looking at this a little longer and > came up with the port update below. Specifically, I tried to merge > the good parts of the old kqemu wrapper: > > - device cloning support on 5.x (multiple vms can use kqemu, tested > and seems to work) > - 4.x support (untested, I'm not sure if vm_map_user_pageable can > be used as a 1-to-1 replacement for vm_map_{un,}wire on 4.x, can > anyone here definitely say?) > - max_locked_pages calculation > > Also: > > - moved debug messages under debug.kqemu_debug sysctl > (do `sysctl debug.kqemu_debug=1' to enable) > - fixed a small bug > - added the amd64 ata irq mapping fix > > Also untested on amd64. > Here it goes: ~> uname -a FreeBSD kushnir1.kiev.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #10: Thu Aug 4 04:17:5 4 EEST 2005 root@kushnir1.kiev.ua:/usr/obj/usr/src/sys/KUSHNIR amd64 This is Athlon64 3000+ -based box, Asus A8N SLI MB. qemu itself builds and works like a charm ('sept the sound doesn't work), but as far as kqemu is concerned - it loads perfectly all right but no /dev/kqemu... is created. No warnings, no panics... and no kqemu's speed boost (obviously). Is there anything I could do? Regards, Vladimir From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 22:24: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 BFA0716A41F; Fri, 5 Aug 2005 22:24:50 +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 50A6A43D48; Fri, 5 Aug 2005 22:24:47 +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 j75MObZA002871; Sat, 6 Aug 2005 00:24:37 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j75MObLa002868; Sat, 6 Aug 2005 00:24:37 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j75MEf60016833; Sat, 6 Aug 2005 00:14:41 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j75MEbJT016832; Sat, 6 Aug 2005 00:14:37 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 6 Aug 2005 00:14:37 +0200 To: Vladimir Kushnir Message-ID: <20050805221437.GA16804@saturn.kn-bremen.de> Mail-Followup-To: Vladimir Kushnir , freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org, qemu-devel@nongnu.org References: <20050804223114.GA21296@saturn.kn-bremen.de> <20050806002532.N902@kushnir1.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050806002532.N902@kushnir1.kiev.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-emulation@freebsd.org, qemu-devel@nongnu.org, freebsd-amd64@freebsd.org Subject: Re: freebsd qemu port update - kqemu wrapper merge, need testing 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, 05 Aug 2005 22:24:50 -0000 On Sat, Aug 06, 2005 at 12:40:06AM +0300, Vladimir Kushnir wrote: > Hi > Thanks for your work, but... (see below) > > On Fri, 5 Aug 2005, Juergen Lock wrote: > > >Okay, I finally got around looking at this a little longer and > >came up with the port update below. Specifically, I tried to merge > >the good parts of the old kqemu wrapper: > > > >- device cloning support on 5.x (multiple vms can use kqemu, tested > >and seems to work) > >- 4.x support (untested, I'm not sure if vm_map_user_pageable can > >be used as a 1-to-1 replacement for vm_map_{un,}wire on 4.x, can > >anyone here definitely say?) > >- max_locked_pages calculation > > > >Also: > > > >- moved debug messages under debug.kqemu_debug sysctl > >(do `sysctl debug.kqemu_debug=1' to enable) > >- fixed a small bug > >- added the amd64 ata irq mapping fix > > > >Also untested on amd64. > > > > Here it goes: > > ~> uname -a > FreeBSD kushnir1.kiev.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #10: Thu Aug 4 > 04:17:5 > 4 EEST 2005 root@kushnir1.kiev.ua:/usr/obj/usr/src/sys/KUSHNIR amd64 > > This is Athlon64 3000+ -based box, Asus A8N SLI MB. > qemu itself builds and works like a charm ('sept the sound doesn't work), > but as far as kqemu is concerned - it loads perfectly all right but no > /dev/kqemu... is created. That's alright, it will appear when open()ed by qemu. (thats device cloning for ya...) > No warnings, no panics... qemu would print a warning when it cannot open kqemu. > and no kqemu's speed > boost (obviously). > Hmm. You do use qemu-system-x86_64, since you're on amd64? Juergen From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 22:46: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 2FFE416A420; Fri, 5 Aug 2005 22:46:34 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18AE343D49; Fri, 5 Aug 2005 22:46:32 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h66.241.159.dialup.iptcom.net ([213.159.241.66]:55753 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1219352AbVHEWqa (ORCPT + 1 other); Sat, 6 Aug 2005 01:46:30 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [10.0.0.1]) by kushnir1.kiev.ua (8.13.4/8.13.3) with ESMTP id j75MkRO9005976; Sat, 6 Aug 2005 01:46:27 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Sat, 6 Aug 2005 01:46:27 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: Juergen Lock In-Reply-To: <20050805221437.GA16804@saturn.kn-bremen.de> Message-ID: <20050806013400.O1629@kushnir1.kiev.ua> References: <20050804223114.GA21296@saturn.kn-bremen.de> <20050806002532.N902@kushnir1.kiev.ua> <20050805221437.GA16804@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-emulation@freebsd.org, qemu-devel@nongnu.org, freebsd-amd64@freebsd.org Subject: Re: freebsd qemu port update - kqemu wrapper merge, need testing 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, 05 Aug 2005 22:46:34 -0000 On Sat, 6 Aug 2005, Juergen Lock wrote: >> > Hmm. You do use qemu-system-x86_64, since you're on amd64? > > Juergen > Silly me. Now I did. And it falls with: EAX=00000000 EBX=00000001 ECX=00000002 EDX=00000003 ESI=00000004 EDI=00000005 EBP=00000000 ESP=0015fd1c EIP=77fb4d83 EFL=00000202 [-------] CPL=3 II=0 A20=1 ES =0023 00000000 ffffffff 00cff300 CS =001b 00000000 ffffffff 00cffa00 SS =0023 00000000 ffffffff 00cff300 DS =0023 00000000 ffffffff 00cff300 FS =0023 7ffde000 00000fff 7f40f3fd GS =0023 00000000 00000000 00000000 LDT=0000 00000000 00000000 00008000 TR =0028 80042000 000020ab 80008904 GDT= 8003f000 000003ff IDT= 8003f400 000007ff CR0=e001003b CR2=805ba6fd CR3=04631000 CR4=000006d8 Unsupported return value: 0xffffffff And from dmesg output: kqemu version 0x00010100 kqemu: KQEMU installed, max_instances=4 max_locked_mem=64536kB. kqemu: aborting: Unexpected exception 0x0d in monitor space CS:EIP=f180:ffff900000001729 This was with (already made) winxp installation. Almost the same on an attempt to install it. Regards, Vladimir From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 22:53:22 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 9E1CD16A41F for ; Fri, 5 Aug 2005 22:53:22 +0000 (GMT) (envelope-from bob@immure.com) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id D35A243D46 for ; Fri, 5 Aug 2005 22:53:21 +0000 (GMT) (envelope-from bob@immure.com) Received: from pimout4-ext.prodigy.net (pimout4-int.prodigy.net [207.115.4.203]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j75Mqlsx025373 for ; Fri, 5 Aug 2005 18:52:47 -0400 X-ORBL: [66.136.206.1] Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by pimout4-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j75MrFpZ071598; Fri, 5 Aug 2005 18:53:15 -0400 Received: from luke.immure.com (luke.immure.com [10.1.132.3]) by maul.immure.com (8.13.3/8.12.11) with ESMTP id j75MrAFp088197; Fri, 5 Aug 2005 17:53:10 -0500 (CDT) (envelope-from bob@immure.com) Received: from luke.immure.com (localhost [127.0.0.1]) by luke.immure.com (8.13.1/8.13.1) with ESMTP id j75Mr9UB003887; Fri, 5 Aug 2005 17:53:09 -0500 (CDT) (envelope-from bob@luke.immure.com) Received: (from bob@localhost) by luke.immure.com (8.13.1/8.12.11/Submit) id j75Mr9qH003886; Fri, 5 Aug 2005 17:53:09 -0500 (CDT) (envelope-from bob) Date: Fri, 5 Aug 2005 17:53:09 -0500 From: Bob Willcox To: freebsd-amd64@freebsd.org Message-ID: <20050805225309.GA99941@luke.immure.com> References: <42ECB269.4030206@mail.uni-mainz.de> <20050802172840.GE71672@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802172840.GE71672@dragon.NUXI.org> User-Agent: Mutt/1.5.9i X-immure-MailScanner-Information: Please contact the ISP for more information X-immure-MailScanner: Found to be clean X-MailScanner-From: bob@immure.com Cc: freebsd-amd64@www.freebsd.org, "O. Hartmann" Subject: Re: OpenOffice2.0 64Bit ready? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Willcox List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 22:53:22 -0000 On Tue, Aug 02, 2005 at 10:28:40AM -0700, David O'Brien wrote: > On Sun, Jul 31, 2005 at 01:13:45PM +0200, O. Hartmann wrote: > > Dear Sirs. > > I do not follow up everything written herein, so my question may sound > > stupid. > > On my FreeBSD 6.0 AMD64 box I run a 'clean' 64 Bit FreeBSD 6.0 (no 32Bit > > compatibility). I want to use OpenOffice from time to time reading Word > > or Excel documents. Can we compile and run OO 2.0 without 32 Bit > > compatibility enabled? I know this implies 64Bit clean code, so the > > major question would be whether OO 2 is 64 Bit clean or not. > > No OOo isn't 64-bit clean. Is it possible to build and run a 32-bit version of OOo on AMD64? -- Bob Willcox The early bird who catches the worm works for someone bob@immure.com who comes in late and owns the worm farm. Austin, TX -- Travis McGee From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 22:53:22 2005 Return-Path: X-Original-To: freebsd-amd64@www.freebsd.org Delivered-To: freebsd-amd64@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8E9916A41F for ; Fri, 5 Aug 2005 22:53:22 +0000 (GMT) (envelope-from bob@immure.com) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2024D43D48 for ; Fri, 5 Aug 2005 22:53:21 +0000 (GMT) (envelope-from bob@immure.com) Received: from pimout4-ext.prodigy.net (pimout4-int.prodigy.net [207.115.4.203]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j75Mqlt3025373 for ; Fri, 5 Aug 2005 18:52:48 -0400 X-ORBL: [66.136.206.1] Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by pimout4-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j75MrFpZ071598; Fri, 5 Aug 2005 18:53:15 -0400 Received: from luke.immure.com (luke.immure.com [10.1.132.3]) by maul.immure.com (8.13.3/8.12.11) with ESMTP id j75MrAFp088197; Fri, 5 Aug 2005 17:53:10 -0500 (CDT) (envelope-from bob@immure.com) Received: from luke.immure.com (localhost [127.0.0.1]) by luke.immure.com (8.13.1/8.13.1) with ESMTP id j75Mr9UB003887; Fri, 5 Aug 2005 17:53:09 -0500 (CDT) (envelope-from bob@luke.immure.com) Received: (from bob@localhost) by luke.immure.com (8.13.1/8.12.11/Submit) id j75Mr9qH003886; Fri, 5 Aug 2005 17:53:09 -0500 (CDT) (envelope-from bob) Date: Fri, 5 Aug 2005 17:53:09 -0500 From: Bob Willcox To: freebsd-amd64@freebsd.org Message-ID: <20050805225309.GA99941@luke.immure.com> References: <42ECB269.4030206@mail.uni-mainz.de> <20050802172840.GE71672@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802172840.GE71672@dragon.NUXI.org> User-Agent: Mutt/1.5.9i X-immure-MailScanner-Information: Please contact the ISP for more information X-immure-MailScanner: Found to be clean X-MailScanner-From: bob@immure.com Cc: freebsd-amd64@www.freebsd.org, "O. Hartmann" Subject: Re: OpenOffice2.0 64Bit ready? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Willcox List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 22:53:23 -0000 On Tue, Aug 02, 2005 at 10:28:40AM -0700, David O'Brien wrote: > On Sun, Jul 31, 2005 at 01:13:45PM +0200, O. Hartmann wrote: > > Dear Sirs. > > I do not follow up everything written herein, so my question may sound > > stupid. > > On my FreeBSD 6.0 AMD64 box I run a 'clean' 64 Bit FreeBSD 6.0 (no 32Bit > > compatibility). I want to use OpenOffice from time to time reading Word > > or Excel documents. Can we compile and run OO 2.0 without 32 Bit > > compatibility enabled? I know this implies 64Bit clean code, so the > > major question would be whether OO 2 is 64 Bit clean or not. > > No OOo isn't 64-bit clean. Is it possible to build and run a 32-bit version of OOo on AMD64? -- Bob Willcox The early bird who catches the worm works for someone bob@immure.com who comes in late and owns the worm farm. Austin, TX -- Travis McGee From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 22:59:28 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 2731716A41F for ; Fri, 5 Aug 2005 22:59:28 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62F4843D49 for ; Fri, 5 Aug 2005 22:59:27 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so384777nzo for ; Fri, 05 Aug 2005 15:59:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=CjutYk2bLdq/GETH7TnAxNgWVhzuFVkSAbZdRjXwP5nstBcT1HYUmkJxaQrphOSxHe0BTAQkXQX7nDFknsdMIkiDUqr3kxoCeqW5mJlsFugT8vKCluqz7yI6QLwLYBT/PMopeTL+atiZSvGUvpNq6duHOQ1kpTWiuJRFc3OeueE= Received: by 10.37.15.37 with SMTP id s37mr1387936nzi; Fri, 05 Aug 2005 15:59:26 -0700 (PDT) Received: from ?192.168.15.122? ([68.190.230.198]) by mx.gmail.com with ESMTP id 36sm1898179nzk.2005.08.05.15.59.26; Fri, 05 Aug 2005 15:59:26 -0700 (PDT) From: Pascal Hofstee To: current@freebsd.org In-Reply-To: <1123260641.69686.4.camel@synergy.charterpipeline.net.lan> References: <1123260641.69686.4.camel@synergy.charterpipeline.net.lan> Content-Type: text/plain Date: Fri, 05 Aug 2005 15:59:24 -0700 Message-Id: <1123282764.53733.3.camel@synergy.charterpipeline.net.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.3.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 buildworld broken ... 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, 05 Aug 2005 22:59:28 -0000 On Fri, 2005-08-05 at 09:50 -0700, Pascal Hofstee wrote: > I had some strange network problems yesterday so i am not sure if my > mail actually made it out to the list (since i have seen no responses at > all yet .. i assume it did not ... so i retry). > > I have tried a buildworld for 7.0-CURRENT/amd64 for three days straight > now .. and it keeps bailing out with the following error. [snip] > I have tried make cleanworld, rm -Rf /usr/src, using different cvsup > mirrors yet the problem persists. if below's snippet of output log is > insufficient i can provide a full buildworld log if required. Well .. it looks like make cleanworld doesn't clean up /usr/obj/lib32 so after manually issuing an "rm -Rf /usr/obj/lib32" buildworld still breaks .. but in a different location now. ===> lib/csu/i386-elf (depend,all,install) rm -f .depend mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S cc -O -g -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/lib/csu/i386-elf/crt1.c {standard input}: Assembler messages: {standard input}:74: Error: suffix or operands invalid for `mov' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Can somebody on amd64 HEAD .. please confirm this breakage or give me suggestions on what else i can possibly try to resolve this buildworld problem ? -- Pascal Hofstee From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 23:30:52 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 72F8C16A420 for ; Fri, 5 Aug 2005 23:30:52 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by mx1.FreeBSD.org (Postfix) with SMTP id 736E943D46 for ; Fri, 5 Aug 2005 23:30:51 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: (qmail 76918 invoked from network); 5 Aug 2005 23:30:50 -0000 Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.210.29 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2005 23:30:50 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 2ACFC60E8; Fri, 5 Aug 2005 18:30:50 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16640-02; Fri, 5 Aug 2005 18:30:46 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 61E9760D2; Fri, 5 Aug 2005 18:30:46 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.4/8.13.4) with ESMTP id j75NUj2l007966; Fri, 5 Aug 2005 18:30:46 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <42F3F6A1.7040608@alumni.rice.edu> Date: Fri, 05 Aug 2005 18:30:41 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pascal Hofstee References: <1123260641.69686.4.camel@synergy.charterpipeline.net.lan> <1123282764.53733.3.camel@synergy.charterpipeline.net.lan> In-Reply-To: <1123282764.53733.3.camel@synergy.charterpipeline.net.lan> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=991D8195; url=http://www.noacks.org/cert/noackjr.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C07B443BA1F0390587C81BB" X-Virus-Scanned: amavisd-new at noacks.org Cc: current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64 buildworld broken ... X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 23:30:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C07B443BA1F0390587C81BB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/05/05 17:59, Pascal Hofstee wrote: > On Fri, 2005-08-05 at 09:50 -0700, Pascal Hofstee wrote: >>I have tried make cleanworld, rm -Rf /usr/src, using different cvsup >>mirrors yet the problem persists. if below's snippet of output log is >>insufficient i can provide a full buildworld log if required. > > Well .. it looks like make cleanworld doesn't clean up /usr/obj/lib32 so > after manually issuing an "rm -Rf /usr/obj/lib32" buildworld still > breaks .. but in a different location now. I haven't seen any tinderbox failures recently so I think amd64 HEAD builds. Try "rm -rf /usr/obj/*". Coupled with a new /usr/src (which you already have), that should get you a clean build environment. -- Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 --------------enig1C07B443BA1F0390587C81BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFC8/alUFz01pkdgZURAnlKAJ9eBfVUWSh4ET6XALKA2/KQ2hrnVACfXcoY WJrp+2rH40uy37gDmN56OPU= =AmqE -----END PGP SIGNATURE----- --------------enig1C07B443BA1F0390587C81BB-- From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 5 23:51: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 183EF16A41F; Fri, 5 Aug 2005 23:51:10 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C76143D45; Fri, 5 Aug 2005 23:51:07 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j75Np0b9046007; Sat, 6 Aug 2005 02:51:00 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 22539-15; Sat, 6 Aug 2005 02:51:00 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j75Np0oU046004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Aug 2005 02:51:00 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j75Noxme072892; Sat, 6 Aug 2005 02:50:59 +0300 (EEST) (envelope-from ru) Date: Sat, 6 Aug 2005 02:50:59 +0300 From: Ruslan Ermilov To: Jonathan Noack Message-ID: <20050805235059.GE48504@ip.net.ua> References: <1123260641.69686.4.camel@synergy.charterpipeline.net.lan> <1123282764.53733.3.camel@synergy.charterpipeline.net.lan> <42F3F6A1.7040608@alumni.rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n2Pv11Ogg/Ox8ay5" Content-Disposition: inline In-Reply-To: <42F3F6A1.7040608@alumni.rice.edu> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: current@freebsd.org, freebsd-amd64@freebsd.org, Pascal Hofstee Subject: Re: amd64 buildworld broken ... 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, 05 Aug 2005 23:51:10 -0000 --n2Pv11Ogg/Ox8ay5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 05, 2005 at 06:30:41PM -0500, Jonathan Noack wrote: > On 08/05/05 17:59, Pascal Hofstee wrote: > >On Fri, 2005-08-05 at 09:50 -0700, Pascal Hofstee wrote: > >>I have tried make cleanworld, rm -Rf /usr/src, using different cvsup > >>mirrors yet the problem persists. if below's snippet of output log is > >>insufficient i can provide a full buildworld log if required. > > > >Well .. it looks like make cleanworld doesn't clean up /usr/obj/lib32 so > >after manually issuing an "rm -Rf /usr/obj/lib32" buildworld still > >breaks .. but in a different location now. >=20 > I haven't seen any tinderbox failures recently so I think amd64 HEAD=20 > builds. Try "rm -rf /usr/obj/*". Coupled with a new /usr/src (which=20 > you already have), that should get you a clean build environment. >=20 I'd also suggest running "env -i /usr/bin/make buildworld __MAKE_CONF=3D/dev/null", for the best known cleanness. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --n2Pv11Ogg/Ox8ay5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC8/tjqRfpzJluFF4RAgAJAJ0QojEKLp6mteCTQMJevy9EvlcWuACgmL/Z W3fyrrkk3IQJYfZgbH+EsDg= =RyMx -----END PGP SIGNATURE----- --n2Pv11Ogg/Ox8ay5-- From owner-freebsd-amd64@FreeBSD.ORG Sat Aug 6 00:00:48 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 1121B16A41F for ; Sat, 6 Aug 2005 00:00:48 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D993343D49 for ; Sat, 6 Aug 2005 00:00:46 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so610974rne for ; Fri, 05 Aug 2005 17:00:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=nKqpvqNvmtTK5RV/i7yYtn+IEByuRIc27Mp45P2TSMqDJbinv8ek480qxB4LFSFlM2+WaB2dk2rZpH+Zg8VxvU+qCJJCOYF6Gdc6Ci0rEL40ZvCukxbuUoXrNPip+kb42r23JM023zx/F+iL+gxXZByhWML9j3FR/uujrQf6EzA= Received: by 10.39.2.26 with SMTP id e26mr1570054rni; Fri, 05 Aug 2005 17:00:46 -0700 (PDT) Received: from ?192.168.15.122? ([68.190.230.198]) by mx.gmail.com with ESMTP id j20sm1871100rnf.2005.08.05.17.00.45; Fri, 05 Aug 2005 17:00:45 -0700 (PDT) From: Pascal Hofstee To: Ruslan Ermilov In-Reply-To: <20050805235059.GE48504@ip.net.ua> References: <1123260641.69686.4.camel@synergy.charterpipeline.net.lan> <1123282764.53733.3.camel@synergy.charterpipeline.net.lan> <42F3F6A1.7040608@alumni.rice.edu> <20050805235059.GE48504@ip.net.ua> Content-Type: text/plain Date: Fri, 05 Aug 2005 17:00:27 -0700 Message-Id: <1123286427.47742.6.camel@synergy.charterpipeline.net.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.3.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org, current@freebsd.org, Jonathan Noack Subject: Re: amd64 buildworld broken ... 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, 06 Aug 2005 00:00:48 -0000 On Sat, 2005-08-06 at 02:50 +0300, Ruslan Ermilov wrote: > On Fri, Aug 05, 2005 at 06:30:41PM -0500, Jonathan Noack wrote: > > >Well .. it looks like make cleanworld doesn't clean up /usr/obj/lib32 so > > >after manually issuing an "rm -Rf /usr/obj/lib32" buildworld still > > >breaks .. but in a different location now. > > > > I haven't seen any tinderbox failures recently so I think amd64 HEAD > > builds. Try "rm -rf /usr/obj/*". Coupled with a new /usr/src (which > > you already have), that should get you a clean build environment. > > > I'd also suggest running "env -i /usr/bin/make buildworld > __MAKE_CONF=/dev/null", for the best known cleanness. I had another close look at my /etc/make.conf when it suddenly hit me. I have not yet been able to confirm buildworld indeed no longer breaks ... but i think i found the source of my problem. I have been trying to use ccache for buildworlds a little while back ... but never could get it to pass building libcrypto.so.4 (iirc) .. but it worked perfectly for my ports tree. So i thought i had properly disabled ccache for /usr/src based builds by removing the /usr/src/ check that normally enables the usage of ccache as follows: .if !defined(NOCCACHE) #.if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/ports*} .if ${.CURDIR:M/usr/ports*} CC=/usr/local/libexec/ccache/cc CXX=/usr/local/libexec/ccache/c++ .else CC=cc CXX=c++ .endif .else CC=/usr/bin/cc CXX=/usr/bin/c++ .endif it just hit me that this makes /usr/src use the bottom CC=/usr/bin/cc section ... instead of the supposed CC=cc section. I am almost positive this indeed is what broke my buildworld. I apologize for the linenoise. I am currently running a new buildworld with the ccache bits completely removed from my make.conf to confirm this was the source of my buildworld breakage but i am about 99.99% sure. With kind regards, Pascal Hofstee From owner-freebsd-amd64@FreeBSD.ORG Sat Aug 6 09:18: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 2E33416A41F for ; Sat, 6 Aug 2005 09:18:56 +0000 (GMT) (envelope-from Sergio.Bezerra@iecn.u-nancy.fr) Received: from antares.iecn.u-nancy.fr (iecn.u-nancy.fr [193.50.42.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7AE243D53 for ; Sat, 6 Aug 2005 09:18:55 +0000 (GMT) (envelope-from Sergio.Bezerra@iecn.u-nancy.fr) Received: by antares.iecn.u-nancy.fr (Postfix, from userid 15) id 2200F1CF249; Sat, 6 Aug 2005 11:18:54 +0200 (CEST) Received: from stx1.iecn.u-nancy.fr (stx1.iecn.u-nancy.fr [193.50.42.40]) by antares.iecn.u-nancy.fr (Postfix) with ESMTP id 010AE1CF242 for ; Sat, 6 Aug 2005 11:18:52 +0200 (CEST) Received: by stx1.iecn.u-nancy.fr (Postfix, from userid 32503) id CCB493565A2; Sat, 6 Aug 2005 11:18:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by stx1.iecn.u-nancy.fr (Postfix) with ESMTP id BCBBC2A3140 for ; Sat, 6 Aug 2005 11:18:36 +0200 (CEST) Date: Sat, 6 Aug 2005 11:18:36 +0200 (CEST) From: Sergio Bezerra To: freebsd-amd64@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on antares.iecn.u-nancy.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: Cc: Subject: Athlon 850 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, 06 Aug 2005 09:18:56 -0000 Hello, I have a AMD Athlon 850. Does FreeBSD have any version for this processor? I have installed Windows and Linux but I would like to change the linux partition by a FreeBSD one. yours truly Sergio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D S=E9rgio BEZERRA t=E9l (33)-383684555 Probabilit=E9 Institut Elie Cartan (IECN) Universit=E9 Henri Poincar=E9 Nancy 1 B.P. 239, F-54506 Vandoeuvre-l=E8s-Nancy Cedex, France =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D From owner-freebsd-amd64@FreeBSD.ORG Sat Aug 6 09:35:28 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 357A116A41F for ; Sat, 6 Aug 2005 09:35:28 +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 0D1BF43D46 for ; Sat, 6 Aug 2005 09:35:26 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 14650 invoked from network); 6 Aug 2005 09:35:24 -0000 Received: from maxwell2.pacific.net.sg (203.120.90.192) by smtpgate2.pacific.net.sg with SMTP; 6 Aug 2005 09:35:24 -0000 Received: from [192.168.0.107] ([210.24.246.166]) by maxwell2.pacific.net.sg with ESMTP id <20050806093524.ZGCS28012.maxwell2.pacific.net.sg@[192.168.0.107]>; Sat, 6 Aug 2005 17:35:24 +0800 Message-ID: <42F4844A.6090205@pacific.net.sg> Date: Sat, 06 Aug 2005 17:35:06 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sergio Bezerra , freebsd-amd64@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Athlon 850 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, 06 Aug 2005 09:35:28 -0000 Hi, I have serious problems answering your mail direcltly as it switches to an unknown characterset if I hit 'reply'. To your question. You do not need a special version. Just take the i386 release install it and configure a custom kernel for the i686. You cannot use the AMD64 release. I am writing this e-mail on an Athlon machine. Erich From owner-freebsd-amd64@FreeBSD.ORG Sat Aug 6 15:42:57 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 15B4416A41F for ; Sat, 6 Aug 2005 15:42:57 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FDA443D8F for ; Sat, 6 Aug 2005 15:42:56 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so685850rne for ; Sat, 06 Aug 2005 08:42:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=Ry9smOCHUt7EF752kpscNDJAPWow4HSxcjXRdVX1Gq53BBIPcmyFH3kk7iIBJZ2N6WU8qLtc1flw/D4+xPZeuveVoUWRle5RcQjlCIzctqzOR8EEfPCkyapPPWxS0kfmGhbiZB/5TNxxbfgPbKqdwSAxQditiq4d1RgoKvqMD/A= Received: by 10.38.101.1 with SMTP id y1mr1836584rnb; Sat, 06 Aug 2005 08:42:56 -0700 (PDT) Received: from kan.dnsalias.net ([24.34.99.65]) by mx.gmail.com with ESMTP id i1sm4655105rne.2005.08.06.08.42.55; Sat, 06 Aug 2005 08:42:56 -0700 (PDT) Date: Sat, 6 Aug 2005 11:42:49 -0400 From: Alexander Kabaev To: freebsd-amd64@freebsd.org Message-ID: <20050806114249.4908ab1e@kan.dnsalias.net> In-Reply-To: References: X-Mailer: Sylpheed-Claws 1.9.12 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Signature_Sat__6_Aug_2005_11_42_49_-0400_nDnXqmTg23vUu2pa; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: Athlon 850 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, 06 Aug 2005 15:42:57 -0000 --Signature_Sat__6_Aug_2005_11_42_49_-0400_nDnXqmTg23vUu2pa Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 6 Aug 2005 11:18:36 +0200 (CEST) Sergio Bezerra wrote: >=20 > Hello, >=20 > I have a AMD Athlon 850. Does FreeBSD have any version for this > processor? I have installed Windows and Linux but I would like to > change the linux partition by a FreeBSD one. >=20 >=20 > yours truly >=20 > Sergio >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Institut Elie Cartan (IECN) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > _______________________________________________ > 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" If you want to run FreeBSD in 64bit mode, then try FreeBSD/amd64, otherwise normal i386 distribution will work just fine.=20 --=20 Alexander Kabaev --Signature_Sat__6_Aug_2005_11_42_49_-0400_nDnXqmTg23vUu2pa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC9Np9Q6z1jMm+XZYRAmKUAJ9B4SeYYceAb5RT4VGieNYDb9zboQCfX9e7 QkLwhYDoL3gpkwgJqinlJqI= =iV8f -----END PGP SIGNATURE----- --Signature_Sat__6_Aug_2005_11_42_49_-0400_nDnXqmTg23vUu2pa-- From owner-freebsd-amd64@FreeBSD.ORG Sat Aug 6 22:13: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 11EC116A41F; Sat, 6 Aug 2005 22:13:38 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5159143D46; Sat, 6 Aug 2005 22:13:37 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j76MDWPP016628; Sun, 7 Aug 2005 08:13:32 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j76MDSrU018738; Sun, 7 Aug 2005 08:13:29 +1000 Date: Sun, 7 Aug 2005 08:13:27 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Xin LI In-Reply-To: <20050802164120.GA16775@frontfree.net> Message-ID: <20050807050237.H3151@epsplex.bde.org> References: <20050801182518.GA85423@frontfree.net> <20050802013916.GA37135@dragon.NUXI.org> <20050802164120.GA16775@frontfree.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Port of NetBSD's optimized amd64 string code 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, 06 Aug 2005 22:13:38 -0000 On Wed, 3 Aug 2005, Xin LI wrote: > On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote: >> On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote: >>> Here is a patchset that I have produced to make our libc aware of the >>> NetBSD assembly implementation of the string related operations. >> >> What performance benchmarks have these been thru? I would expect insignificant ones. alc already optimized most of the amd64 string functions that are worth optimizing. > In summary: index, rindex, memchr, strchr, strlen, strlen, strrchr are > faster than their C counterparts; ffs, strncmp are about the same, and > swab is worse. This is not surprising, since the faster ones mostly use better algorithms so their fastness has very little to do with them being written in asm, ffs.S has slightly worse code than the gcc builtin, strncmp.S doesn't do anything special, and swab.S does almost everything pessimally. > Note that these tests are done within loops that first copy a string to > a new place, then perform the operation, then free the string, to defeat > cache effects. I usually test like this since it is hard to do better, but this tests for precisely things that shouldn't happen in real applications. > BETTER CASES > > [delphij@warrior7] ~/test/index> /usr/bin/time ./index > 5.81 real 5.79 user 0.00 sys > ASSEMBLY > 1.84 real 1.82 user 0.00 sys > > [delphij@warrior7] ~/test/rindex> /usr/bin/time ./rindex > 6.25 real 6.24 user 0.00 sys > ASSEMBLY > 2.17 real 1.84 user 0.01 sys > > [delphij@warrior7] ~/test/memchr> /usr/bin/time ./memchr > 5.93 real 5.91 user 0.00 sys > ASSEMBLY > 1.91 real 1.84 user 0.00 sys > > [delphij@warrior7] ~/test/strchr> /usr/bin/time ./strchr > 5.93 real 5.91 user 0.00 sys > ASSEMBLY > 1.84 real 1.83 user 0.00 sys memchr.S, strchr.S (and thus index.S), strchchr.S (strchr timings below) (and thus rindex.S) all use the well known method of comparing with the magic byte sequences \x80\x80... and \x01\0x01... It's not surprising that this is several times faster since it accesses the data 4-8 bytes at a time (8 bytes for amd64), but IMO this optimization belongs only in C code (if anywhere) so that it optimizes all arches (if it is an optimization). glibc has it in C code. NetBSD also has it in the i386 string library but not in the generic string library. > [delphij@warrior7] ~/test/strlen> /usr/bin/time ./strlen > 7.13 real 7.12 user 0.00 sys > ASSEMBLY > 1.44 real 1.43 user 0.00 sys strlen.S uses the magic byte sequence method in the same way (NetBSD also does this in the i386 strlen.S...). The method works even better for strlen(), giving closer to an 8-fold speedup, since there is less overhead. Other benchmarks for strlen() show strange behaviour. (Note that neither the generic library version nor the MD i386/amd64 version of it is normally used, since the gcc builtin is normally used.) - the builtin is slightly faster than the MD i386 version, since they use the same algorithm (a scasb loop) and the builtin doesn't have function call overhead. - the simple generic C version is often faster than the "optimized" builtin! IIRC, alc noticed this for amd64 and didn't implement an amd64 strlen.S using the same simple algorithm as the i386 one because it would be a pessimization even if it were actually used. It seems to be pessimal on Athlon XP's too. For 10^8 strlen()s, with other CFLAGS -O2 -static: on an AXP2600 overclocked: %%% string length 0: algorithm -fbuiltin: 0.30 real 0.29 user 0.00 sys algorithm -fno-builtin: 0.33 real 0.32 user 0.00 sys algorithm -DMISTRLEN: 0.25 real 0.24 user 0.00 sys string length 1: algorithm -fbuiltin: 0.31 real 0.30 user 0.00 sys algorithm -fno-builtin: 0.34 real 0.33 user 0.00 sys algorithm -DMISTRLEN: 0.26 real 0.25 user 0.00 sys string length 10: algorithm -fbuiltin: 0.40 real 0.39 user 0.00 sys algorithm -fno-builtin: 0.43 real 0.42 user 0.00 sys algorithm -DMISTRLEN: 0.40 real 0.39 user 0.00 sys string length 100: algorithm -fbuiltin: 1.32 real 1.30 user 0.00 sys algorithm -fno-builtin: 1.35 real 1.33 user 0.00 sys algorithm -DMISTRLEN: 1.21 real 1.20 user 0.00 sys string length 1000: algorithm -fbuiltin: 10.46 real 10.42 user 0.00 sys algorithm -fno-builtin: 10.50 real 10.46 user 0.00 sys algorithm -DMISTRLEN: 9.35 real 9.31 user 0.00 sys %%% Note that the MI version is fastest for all string lengths. The C version was sometimes (in results with -O1 and/or not shown above) 30% slower than it usually is; this turned out to be due to the loop in strlen() not fitting in a cache line due to the start of the loop accidentally beginning near a cache line boundary. On an A64 3400: %%% string length 0: algorithm -fbuiltin: 0.34 real 0.32 user 0.00 sys algorithm -fno-builtin: 0.24 real 0.23 user 0.00 sys algorithm -fno-builtin zq.S: 0.27 real 0.26 user 0.00 sys string length 1: algorithm -fbuiltin: 0.35 real 0.33 user 0.00 sys algorithm -fno-builtin: 0.25 real 0.24 user 0.00 sys algorithm -fno-builtin zq.S: 0.29 real 0.28 user 0.00 sys string length 10: algorithm -fbuiltin: 0.44 real 0.42 user 0.00 sys algorithm -fno-builtin: 0.42 real 0.40 user 0.00 sys algorithm -fno-builtin zq.S: 0.30 real 0.29 user 0.00 sys string length 100: algorithm -fbuiltin: 1.34 real 1.32 user 0.00 sys algorithm -fno-builtin: 1.32 real 1.30 user 0.00 sys algorithm -fno-builtin zq.S: 0.55 real 0.54 user 0.00 sys string length 1000: algorithm -fbuiltin: 10.39 real 10.37 user 0.00 sys algorithm -fno-builtin: 10.37 real 10.34 user 0.00 sys algorithm -fno-builtin zq.S: 2.25 real 2.23 user 0.00 sys %%% zq.S is your proposed strlen.S. > > [delphij@warrior7] ~/test/strrchr> /usr/bin/time ./strrchr > 9.12 real 9.08 user 0.00 sys > ASSEMBLY > 4.71 real 4.69 user 0.00 sys > > WORSE/NO EFFECTS > > [delphij@warrior7] ~/test/ffs> /usr/bin/time ./ffs > 0.33 real 0.33 user 0.00 sys > ASSEMBLY > 0.33 real 0.33 user 0.00 sys The MI library version is poor for ffs, but the builtin is good. It is easy to improve the MI version, at least in benchmarks, using a lookup table, but efficiency of ffs() is unimportant in most applications so no one has done it. From an old benchmark of various methods on an A64: %%% UNIFORM/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys UNIFORM/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys UNIFORM/LIBMET0_FFS: 0.70 real 0.70 user 0.00 sys UNIFORM/LIBMETH_FFS: 0.72 real 0.72 user 0.00 sys UNIFORM/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys UNIFORM/CPUFUNC_FLS: 0.33 real 0.33 user 0.00 sys UNIFORM/ILOGMET_FLS: 0.18 real 0.18 user 0.00 sys UNIFORM/ILOGBME_FLS: 0.37 real 0.36 user 0.00 sys UNIFORM/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys UNIFORM/LIBMET0_FLS: 1.67 real 1.67 user 0.00 sys UNIFORM/LIBMETH_FLS: 1.71 real 1.71 user 0.00 sys RANDBIT/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys RANDBIT/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys RANDBIT/LIBMET0_FFS: 1.43 real 1.43 user 0.00 sys RANDBIT/LIBMETH_FFS: 1.44 real 1.43 user 0.00 sys RANDBIT/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys RANDBIT/CPUFUNC_FLS: 0.33 real 0.33 user 0.00 sys RANDBIT/ILOGMET_FLS: 0.17 real 0.17 user 0.00 sys RANDBIT/ILOGBME_FLS: 0.41 real 0.41 user 0.00 sys RANDBIT/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys RANDBIT/LIBMET0_FLS: 1.16 real 1.16 user 0.00 sys RANDBIT/LIBMETH_FLS: 1.16 real 1.16 user 0.00 sys ALLZERO/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys ALLZERO/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys ALLZERO/LIBMET0_FFS: 0.53 real 0.53 user 0.00 sys ALLZERO/LIBMETH_FFS: 0.55 real 0.55 user 0.00 sys ALLZERO/LUTMETH_FFS: 0.12 real 0.12 user 0.00 sys ALLZERO/CPUFUNC_FLS: 0.10 real 0.10 user 0.00 sys ALLZERO/ILOGMET_FLS: 0.12 real 0.12 user 0.00 sys ALLZERO/ILOGBME_FLS: 0.12 real 0.12 user 0.00 sys ALLZERO/ILOGBM0_FLS: 0.10 real 0.10 user 0.00 sys ALLZERO/LIBMET0_FLS: 0.24 real 0.24 user 0.00 sys ALLZERO/LIBMETH_FLS: 0.29 real 0.28 user 0.00 sys ALLONE_/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys ALLONE_/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys ALLONE_/LIBMET0_FFS: 0.58 real 0.57 user 0.00 sys ALLONE_/LIBMETH_FFS: 0.60 real 0.59 user 0.00 sys ALLONE_/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys ALLONE_/CPUFUNC_FLS: 0.37 real 0.37 user 0.00 sys ALLONE_/ILOGMET_FLS: 0.16 real 0.16 user 0.00 sys ALLONE_/ILOGBME_FLS: 0.37 real 0.37 user 0.00 sys ALLONE_/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys ALLONE_/LIBMET0_FLS: 0.25 real 0.24 user 0.00 sys ALLONE_/LIBMETH_FLS: 0.29 real 0.28 user 0.00 sys ALLLAST/BUILTIN_FFS: 0.27 real 0.26 user 0.00 sys ALLLAST/CPUFUNC_FFS: 0.27 real 0.26 user 0.00 sys ALLLAST/LIBMET0_FFS: 2.37 real 2.36 user 0.00 sys ALLLAST/LIBMETH_FFS: 2.39 real 2.38 user 0.00 sys ALLLAST/LUTMETH_FFS: 0.25 real 0.24 user 0.00 sys ALLLAST/CPUFUNC_FLS: 0.37 real 0.37 user 0.00 sys ALLLAST/ILOGMET_FLS: 0.12 real 0.12 user 0.00 sys ALLLAST/ILOGBME_FLS: 0.37 real 0.37 user 0.00 sys ALLLAST/ILOGBM0_FLS: 0.39 real 0.39 user 0.00 sys ALLLAST/LIBMET0_FLS: 1.77 real 1.76 user 0.00 sys ALLLAST/LIBMETH_FLS: 1.81 real 1.81 user 0.00 sys %%% Here various distributions of the bits are tested, with various algorithms: BUILTIN_FFS: whatever gcc gives CPUFUNC_FFS: as in (this uses the builtin for amd64) LIBMET0_FFS: LIBMETH_FFS compiled with benchmark's CFLAGS LIBMETH_FFS: MI library method LUTMETH_FFS: a lookup table method, orignally by cperciva CPUFUNC_FLS: whatever gcc gives ILOGMET_FLS: convert to floating point and extract the exponent directly ILOGBME_FLS: convert to floating point and use ilogb(3) to extract... ILOGBM0_FLS: ILOGBM0_FLS compiled with benchmark's CFLAGS LIBMET0_FLS: MI library method compiled with benchmark's CFLAGS LIBMETH_FLS: MI library method > [delphij@warrior7] ~/test/strncmp> /usr/bin/time ./strncmp > 3.90 real 3.88 user 0.00 sys > 3.88 real 3.87 user 0.00 sys > ASSEMBLY > 3.88 real 3.87 user 0.00 sys > > [delphij@warrior7] ~/test/swab> /usr/bin/time ./swab > 6.59 real 6.53 user 0.01 sys > ASSEMBLY > 8.06 real 8.05 user 0.00 sys > Some comments on the patch. % Index: ffs.S % =================================================================== % RCS file: ffs.S % diff -N ffs.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ ffs.S 1 Aug 2005 17:54:04 -0000 % @@ -0,0 +1,22 @@ % +/* % + * Written by J.T. Conklin . % + * Public domain. % + * Adapted for NetBSD/x86_64 by Frank van der Linden % + */ % + % +#include % +__FBSDID("$FreeBSD$"); % + % +#if 0 % + RCSID("$NetBSD: ffs.S,v 1.2 2003/07/26 19:24:38 salo Exp $") % +#endif % + % +ENTRY(ffs) % + bsfl %edi,%eax % + jz L1 /* ZF is set if all bits are 0 */ % + incl %eax /* bits numbered from 1, not 0 */ % + ret % + % + .align 4 % +L1: xorl %eax,%eax /* clear result */ % + ret The amd64 builtin uses cmove to avoid the branch. This is always better, but is only a small optimization (see above benchmark). The i386 ffs() does the test and branch before the bsfl so as to avoid the bsfl if the arg is 0. This sigificantly optimimizes the case of a zero arg at no cost for nonzero args. The gcc builtin ffs() has evolved in many stages: - very old versions depended on undefined behaviour. The i386 kernel ffs() was written to avoid this bug and it was easy to optimize it while doing this. - not old versions generated essentially the above code. - not so old versions (3.3.3) generate "sete; negl; orl" to avoid the branch. This is a less efficient variant of the cmove. % Index: memchr.S % =================================================================== % RCS file: memchr.S % diff -N memchr.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ memchr.S 1 Aug 2005 18:09:44 -0000 % @@ -0,0 +1,112 @@ This is good code (algorithm and style). I don't mind using this micro-optimization if someone else writes and maintains it :-). % ... % +.Lzero: % + xorq %rax,%rax Some of the other functions only return %eax, which is sufficient for an int but is a different style. % Index: strchr.S % =================================================================== % RCS file: strchr.S % diff -N strchr.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strchr.S 1 Aug 2005 18:11:51 -0000 % @@ -0,0 +1,137 @@ Similarly to memchr.S.... % ... % + subq $7,%rdi % + jmp .Ldone % +1: testb %dl,%dl /* 2nd byte == 0? */ ... but not so good style near the end of it: - nameless labels are fairly easy to write but hard to read - no blank line before separate blocks of code - labels on the same line as statements % Index: strlen.S % =================================================================== % RCS file: strlen.S % diff -N strlen.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strlen.S 1 Aug 2005 18:12:48 -0000 % @@ -0,0 +1,157 @@ Not as good style as memchr.S. % + /* % + * There are many well known branch-free sequences which are used % + * for determining whether a zero-byte is contained within a word. % + * These sequences are generally much more efficent than loading % + * and comparing each byte individually. % + * % + * The expression [1,2]: % + * % + * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) % + * % + * evaluates to a non-zero value if any of the bytes in the % + * original word is zero. % ... This comment has some spelling errors and doesn't belong here. The algorithm is mostly general and should be described centrally. A more complicated variant of It is used without comment in memchr.S and strchr.S. Describing things in terms of PowerPC (?) clz instructions belongs even less in the i386 asm version than it does in a general comment. % Index: strncmp.S % =================================================================== % RCS file: strncmp.S % diff -N strncmp.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strncmp.S 1 Aug 2005 18:13:51 -0000 % @@ -0,0 +1,108 @@ Note as good as memchr.S. It uses an algorithm that apparently gives no better results than the generic C one, and uses meaningless though named labels throughout. % Index: strrchr.S % =================================================================== % RCS file: strrchr.S % diff -N strrchr.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ strrchr.S 1 Aug 2005 18:15:07 -0000 % @@ -0,0 +1,127 @@ Similarly to strchr.S. but less worth optimizing. % Index: swab.S % =================================================================== % RCS file: swab.S % diff -N swab.S % --- /dev/null 1 Jan 1970 00:00:00 -0000 % +++ swab.S 1 Aug 2005 18:18:17 -0000 % @@ -0,0 +1,47 @@ Shows how not to optimize things. % +#define LOAD_SWAP_STORE_WORD \ % + lodsw ; \ The lods instruction should never be used, since it is very slow. % + xchgb %al,%ah ; \ Partial register operations should be avoided. I don't know if this is important on amd64's. On Athlons xchgb of 2 registers is on the VectorPath and takes 2 cycles, so is probably possible to do 2 byte loads to the right places (%al and %ah) in the same time that it takes to fix up the bytes after slowly loading them as a word, provided there is no penalty for the partial register operations. I think the C code wins by doing something similar. % + stosw stosw Is OK. % +L2: shrq $3,%rdx # copy remainder 8 words at a time % + jz L4 # while swapping alternate bytes. % +L3: % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + LOAD_SWAP_STORE_WORD % + % + decq %rdx % + jnz L3 To optimize the amd64 version, I would first try loading 8 bytes at a time and swap them using a minimal combination of bswaps and rotates. Bruce From owner-freebsd-amd64@FreeBSD.ORG Sat Aug 6 23:41:04 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CF4FA16A41F; Sat, 6 Aug 2005 23:41:03 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <42F54A8E.8080704@freebsd.org> Date: Sun, 07 Aug 2005 07:41:02 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm 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> <200507281057.43655.peter@wemm.org> In-Reply-To: <200507281057.43655.peter@wemm.org> 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: Sat, 06 Aug 2005 23:41:04 -0000 Peter Wemm wrote: >Mysql could also easily be affected by inefficiencies in the amd64 >pthread libraries too. > > > libthr on -CURRENT is very similar with Linux NPTL, think of NPTL's throughput, the inefficiencies might be in our kernel. Also the bottleneck in userland might be malloc which does belongs to thread library, Linux has ptmalloc which is thread friendly. David Xu From owner-freebsd-amd64@FreeBSD.ORG Sat Aug 6 23:53:05 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id DB0D816A41F; Sat, 6 Aug 2005 23:53:04 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <42F54D60.1090102@freebsd.org> Date: Sun, 07 Aug 2005 07:53:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu 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> <200507281057.43655.peter@wemm.org> <42F54A8E.8080704@freebsd.org> In-Reply-To: <42F54A8E.8080704@freebsd.org> 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: Sat, 06 Aug 2005 23:53:05 -0000 David Xu wrote: > Peter Wemm wrote: > >> Mysql could also easily be affected by inefficiencies in the amd64 >> pthread libraries too. >> >> >> > libthr on -CURRENT is very similar with Linux NPTL, think of NPTL's > throughput, the inefficiencies might be in our kernel. Also the > bottleneck in > userland might be malloc which does belongs to thread library, sorry for typo, malloc is in libc. > Linux has > ptmalloc which is thread friendly.