From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 22 04:04:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0859116A4CF; Sun, 22 Aug 2004 04:04:59 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA94343D2F; Sun, 22 Aug 2004 04:04:58 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (203.134.132.68) by smtp01.syd.iprimus.net.au (7.0.028) id 412634F300072396; Sun, 22 Aug 2004 14:04:55 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 26B37420D; Sun, 22 Aug 2004 14:04:53 +1000 (EST) Date: Sun, 22 Aug 2004 14:04:53 +1000 From: Tim Robbins To: "Conrad J. Sabatier" Message-ID: <20040822040453.GA11878@cat.robbins.dropbear.id.au> References: <1093108393.4202.8.camel@funshine.carebears.net> <20040821133701.6ecf9f04@dolphin.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040821133701.6ecf9f04@dolphin.local.net> User-Agent: Mutt/1.4.1i cc: freebsd-multimedia@freebsd.org cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: [Fwd: sound in CURRENT] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 04:04:59 -0000 On Sat, Aug 21, 2004 at 01:37:01PM -0500, Conrad J. Sabatier wrote: > On Sat, 21 Aug 2004 19:13:13 +0200 > Christer Solskogen wrote: > > > -----Forwarded Message----- > > > From: Christer Solskogen > > > To: freebsd-current@freebsd.org > > > Subject: sound in CURRENT > > > Date: Sat, 21 Aug 2004 16:26:03 +0200 > > > > > > FreeBSD funshine.carebears.net 5.3-BETA1 FreeBSD 5.3-BETA1 #1: Sat > > > Aug 21 15:51:04 CEST 2004 > > > root@funshine.carebears.net:/usr/obj/usr/src/sys/FUNSHINE amd64 > > > > > > I cant get sound working on my SB Live. > > > I have the following in kernel config: > > > device sound > > > device "snd_emu10k1" > > > > > > It seems like I dont have any sound modules either in /boot/kernel > > > (yeah, i know the modules are named snd_*) > > > > > > (no need to CC: back to me. I`m subscribed) > > > > Could this only be on amd64? [long rant snipped] It's unreasonable to claim that the whole sound system is broken on the basis of one driver not working with your hardware -- I've had no problems whatsoever with sound on my system, using both the onboard sound (VIA 8237/ Analog Devices AD1980 with the snd_via8233 driver) and an old Sound Blaster Live! Value card (with the snd_emu10k1 driver). Tim From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 22 04:24:12 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD77F16A4D0; Sun, 22 Aug 2004 04:24:12 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B8C543D68; Sun, 22 Aug 2004 04:24:12 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 27ACAFD06B; Sat, 21 Aug 2004 21:24:12 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45466-09; Sat, 21 Aug 2004 21:24:11 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 9D420FD029; Sat, 21 Aug 2004 21:24:11 -0700 (PDT) From: Sean McNeil To: Tim Robbins In-Reply-To: <20040822040453.GA11878@cat.robbins.dropbear.id.au> References: <1093108393.4202.8.camel@funshine.carebears.net> <20040821133701.6ecf9f04@dolphin.local.net> <20040822040453.GA11878@cat.robbins.dropbear.id.au> Content-Type: text/plain Message-Id: <1093148651.47618.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 21 Aug 2004 21:24:11 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-multimedia@freebsd.org cc: "Conrad J. Sabatier" cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: [Fwd: sound in CURRENT] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 04:24:12 -0000 On Sat, 2004-08-21 at 21:04, Tim Robbins wrote: > On Sat, Aug 21, 2004 at 01:37:01PM -0500, Conrad J. Sabatier wrote: > > On Sat, 21 Aug 2004 19:13:13 +0200 > > Christer Solskogen wrote: > > > > > -----Forwarded Message----- > > > > From: Christer Solskogen > > > > To: freebsd-current@freebsd.org > > > > Subject: sound in CURRENT > > > > Date: Sat, 21 Aug 2004 16:26:03 +0200 > > > > > > > > FreeBSD funshine.carebears.net 5.3-BETA1 FreeBSD 5.3-BETA1 #1: Sat > > > > Aug 21 15:51:04 CEST 2004 > > > > root@funshine.carebears.net:/usr/obj/usr/src/sys/FUNSHINE amd64 > > > > > > > > I cant get sound working on my SB Live. > > > > I have the following in kernel config: > > > > device sound > > > > device "snd_emu10k1" > > > > > > > > It seems like I dont have any sound modules either in /boot/kernel > > > > (yeah, i know the modules are named snd_*) > > > > > > > > (no need to CC: back to me. I`m subscribed) > > > > > > Could this only be on amd64? > > [long rant snipped] > > It's unreasonable to claim that the whole sound system is broken on the > basis of one driver not working with your hardware -- I've had no problems > whatsoever with sound on my system, using both the onboard sound (VIA 8237/ > Analog Devices AD1980 with the snd_via8233 driver) and an old Sound Blaster > Live! Value card (with the snd_emu10k1 driver). Well he mentioned actually 2 different chip sets. I do not know if they are the same driver, though. I'm using the snd_via8233 as well and have terrible sound quality. Have you played back mp3 files on that machine? Do they sound good completely through? Mine sounds hurried at times. Like it is getting interrupts too soon. Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 22 05:01:52 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F95116A4CE; Sun, 22 Aug 2004 05:01:52 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D04DF43D1D; Sun, 22 Aug 2004 05:01:51 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (203.134.132.68) by smtp01.syd.iprimus.net.au (7.0.028) id 412634F300075FE0; Sun, 22 Aug 2004 15:01:48 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 8274E420D; Sun, 22 Aug 2004 15:01:46 +1000 (EST) Date: Sun, 22 Aug 2004 15:01:46 +1000 From: Tim Robbins To: Sean McNeil Message-ID: <20040822050146.GC11878@cat.robbins.dropbear.id.au> References: <1093108393.4202.8.camel@funshine.carebears.net> <20040821133701.6ecf9f04@dolphin.local.net> <20040822040453.GA11878@cat.robbins.dropbear.id.au> <1093148651.47618.3.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093148651.47618.3.camel@server.mcneil.com> User-Agent: Mutt/1.4.1i cc: freebsd-multimedia@freebsd.org cc: "Conrad J. Sabatier" cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: [Fwd: sound in CURRENT] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 05:01:52 -0000 On Sat, Aug 21, 2004 at 09:24:11PM -0700, Sean McNeil wrote: > On Sat, 2004-08-21 at 21:04, Tim Robbins wrote: > > On Sat, Aug 21, 2004 at 01:37:01PM -0500, Conrad J. Sabatier wrote: > > > On Sat, 21 Aug 2004 19:13:13 +0200 > > > Christer Solskogen wrote: > > > > > > > -----Forwarded Message----- > > > > > From: Christer Solskogen > > > > > To: freebsd-current@freebsd.org > > > > > Subject: sound in CURRENT > > > > > Date: Sat, 21 Aug 2004 16:26:03 +0200 > > > > > > > > > > FreeBSD funshine.carebears.net 5.3-BETA1 FreeBSD 5.3-BETA1 #1: Sat > > > > > Aug 21 15:51:04 CEST 2004 > > > > > root@funshine.carebears.net:/usr/obj/usr/src/sys/FUNSHINE amd64 > > > > > > > > > > I cant get sound working on my SB Live. > > > > > I have the following in kernel config: > > > > > device sound > > > > > device "snd_emu10k1" > > > > > > > > > > It seems like I dont have any sound modules either in /boot/kernel > > > > > (yeah, i know the modules are named snd_*) > > > > > > > > > > (no need to CC: back to me. I`m subscribed) > > > > > > > > Could this only be on amd64? > > > > [long rant snipped] > > > > It's unreasonable to claim that the whole sound system is broken on the > > basis of one driver not working with your hardware -- I've had no problems > > whatsoever with sound on my system, using both the onboard sound (VIA 8237/ > > Analog Devices AD1980 with the snd_via8233 driver) and an old Sound Blaster > > Live! Value card (with the snd_emu10k1 driver). > > Well he mentioned actually 2 different chip sets. I do not know if they > are the same driver, though. I'm using the snd_via8233 as well and have > terrible sound quality. Have you played back mp3 files on that > machine? Do they sound good completely through? Mine sounds hurried at > times. Like it is getting interrupts too soon. MP3 files play back fine with XMMS, mpg123, and everything else I've tried. The only time they don't is when WITNESS and INVARIANTS are both turned on and the box is under heavy load (buildworld, portupgrade, etc.). Tim From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 22 09:44:37 2004 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2AE616A4CE; Sun, 22 Aug 2004 09:44:37 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C237543D1D; Sun, 22 Aug 2004 09:44:37 +0000 (GMT) (envelope-from tjr@FreeBSD.org) Received: from freefall.freebsd.org (tjr@localhost [127.0.0.1]) i7M9iblX015142; Sun, 22 Aug 2004 09:44:37 GMT (envelope-from tjr@freefall.freebsd.org) Received: (from tjr@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7M9ibHJ015138; Sun, 22 Aug 2004 09:44:37 GMT (envelope-from tjr) Date: Sun, 22 Aug 2004 09:44:37 GMT From: "Tim J. Robbins" Message-Id: <200408220944.i7M9ibHJ015138@freefall.freebsd.org> To: morgothdbma@o2.pl, tjr@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: amd64/69713: just quite unstable (panic when burncd fails, or when checking ufs1/ufs2, heavy load panics) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 09:44:38 -0000 Synopsis: just quite unstable (panic when burncd fails, or when checking ufs1/ufs2, heavy load panics) State-Changed-From-To: open->closed State-Changed-By: tjr State-Changed-When: Sun Aug 22 09:43:18 GMT 2004 State-Changed-Why: Please try the upcoming 5.3-BETA releases and submit detailed problem reports if you can reproduce these problems. http://www.freebsd.org/cgi/query-pr.cgi?pr=69713 From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 22 16:31:35 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBA3E16A4CE for ; Sun, 22 Aug 2004 16:31:35 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D9143D31 for ; Sun, 22 Aug 2004 16:31:35 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i7MGVZJg031571 for ; Sun, 22 Aug 2004 09:31:35 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i7MGVZxE031570 for freebsd-amd64@freebsd.org; Sun, 22 Aug 2004 09:31:35 -0700 (PDT) (envelope-from sgk) Date: Sun, 22 Aug 2004 09:31:35 -0700 From: Steve Kargl To: freebsd-amd64@freebsd.org Message-ID: <20040822163135.GA31549@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [PATCH] "fix" make(1) problems in build32.sh script X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 16:31:35 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The attached patch appears to "fix" the damage caused by the recent changes to make(1). I have been able to build (some of?) the libraries and the loader. However, all dynamic i386 binaries that I have tried to run have exited with a seg fault. This may be a gcc 3.4.2 issue. I have a 1.7 MB log of the build32.sh execution if anyone wants to take a peek. -- Steve --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="build32.sh.diff" --- build32.sh.orig Fri Aug 13 11:33:59 2004 +++ build32.sh Sat Aug 21 10:22:31 2004 @@ -11,41 +11,63 @@ # XXX installation of includes. ie: it will re-install some files in # XXX /usr/include for you. -mkdir /lib32 -mkdir /usr/lib32 -mkdir /usr/local/lib32 -mkdir /usr/X11R6/lib32 +mkdir -p /lib32 +mkdir -p /usr/lib32 +mkdir -p /usr/local/lib32 +mkdir -p /usr/X11R6/lib32 + +export MAKEOBJDIRPREFIX=/tmp/i386 +mkdir -p $MAKEOBJDIRPREFIX # Set up an obj tree -chflags -R noschg /tmp/i386 -rm -rf /tmp/i386 +chflags -R noschg $MAKEOBJDIRPREFIX +rm -rf $MAKEOBJDIRPREFIX +mkdir -p $MAKEOBJDIRPREFIX CCARGS="-m32 -march=athlon-xp -msse2 -mfancy-math-387 -I/tmp/i386/root/usr/include -L/usr/lib32 -B/usr/lib32" CXXARGS="-m32 -march=athlon-xp -msse2 -mfancy-math-387 -I/tmp/i386/root/usr/include/c++/3.3 -I/tmp/i386/root/usr/include -L/usr/lib32 -B/usr/lib32" # and a place to put the alternate include tree into. -mkdir -p /tmp/i386/root -make -s MAKEOBJDIRPREFIX=/tmp/i386 DESTDIR=/tmp/i386/root MACHINE_ARCH=i386 hierarchy +mkdir -p $MAKEOBJDIRPREFIX/root + +export MACHINE_ARCH=i386 +export DESTDIR=$MAKEOBJDIRPREFIX/root + +make -s hierarchy # Now build includes -make -s MAKEOBJDIRPREFIX=/tmp/i386 DESTDIR=/tmp/i386/root MACHINE_ARCH=i386 obj -make -s MAKEOBJDIRPREFIX=/tmp/i386 DESTDIR=/tmp/i386/root MACHINE_ARCH=i386 includes +make -s obj +make -s includes + +unset MACHINE_ARCH +unset DESTDIR # libncurses needs a build-tools pass first. I wish build-tools was a recursive target. -(cd lib/libncurses; make -s MAKEOBJDIRPREFIX=/tmp/i386 build-tools) +(cd lib/libncurses; make -s build-tools) # Now the libraries. This doesn't work for gnuregex yet. hence -k. # libbind is just an internal target, ignore it. -make -s -DNO_BIND -DNOMAN -DNODOC -DNOINFO MAKEOBJDIRPREFIX=/tmp/i386 LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 MACHINE_ARCH=i386 CC="cc $CCARGS" CXX="c++ $CXXARGS" LD="ld -m elf_i386_fbsd -Y P,/usr/lib32" -k libraries +export LIBDIR=/usr/lib32 +export SHLIBDIR=/usr/lib32 +export MACHINE_ARCH=i386 +export CC="cc $CCARGS" +export CXX="c++ $CXXARGS" +export LD="ld -m elf_i386_fbsd -Y P,/usr/lib32" +make -s -DNO_BIND -DNOMAN -DNODOC -DNOINFO -k libraries # Hack to fix gnuregex which does hacks to the -I path based on $DESTDIR. But, we cannot # use DESTDIR during the libraries target, because we're just using alternate includes, not # an alternate install directory. -(cd gnu/lib/libregex; make -s -DNOMAN -DNODOC -DNOINFO MAKEOBJDIRPREFIX=/tmp/i386 LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 MACHINE_ARCH=i386 CC="cc -I/tmp/i386/root/usr/include/gnu $CCARGS" CXX="c++ $CXXARGS" LD="ld -m elf_i386_fbsd -Y P,/usr/lib32" all install) +unset CC +export CC="cc -I/tmp/i386/root/usr/include/gnu $CCARGS" +(cd gnu/lib/libregex; make -k -DNOMAN -DNODOC -DNOINFOall install) # and now that we have enough libraries, build ld-elf32.so.1 cd libexec/rtld-elf -make -s -DNOMAN -DNODOC -DNOINFO PROG=ld-elf32.so.1 MAKEOBJDIRPREFIX=/tmp/i386 LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 MACHINE_ARCH=i386 CC="cc $CCARGS -DCOMPAT_32BIT" LD="ld -m elf_i386_fbsd -Y P,/usr/lib32" obj -make -s -DNOMAN -DNODOC -DNOINFO PROG=ld-elf32.so.1 MAKEOBJDIRPREFIX=/tmp/i386 LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 MACHINE_ARCH=i386 CC="cc $CCARGS -DCOMPAT_32BIT" LD="ld -m elf_i386_fbsd -Y P,/usr/lib32" depend -make -s -DNOMAN -DNODOC -DNOINFO PROG=ld-elf32.so.1 MAKEOBJDIRPREFIX=/tmp/i386 LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 MACHINE_ARCH=i386 CC="cc $CCARGS -DCOMPAT_32BIT" LD="ld -m elf_i386_fbsd -Y P,/usr/lib32" -make -s -DNOMAN -DNODOC -DNOINFO PROG=ld-elf32.so.1 MAKEOBJDIRPREFIX=/tmp/i386 LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 MACHINE_ARCH=i386 CC="cc $CCARGS -DCOMPAT_32BIT" LD="ld -m elf_i386_fbsd -Y P,/usr/lib32" install +export PROG=ld-elf32.so.1 +unset CC +export CC="cc $CCARGS -DCOMPAT_32BIT" +make -s -DNOMAN -DNODOC -DNOINFO -k obj +make -s -DNOMAN -DNODOC -DNOINFO -k depend +make -s -DNOMAN -DNODOC -DNOINFO -k +make -s -DNOMAN -DNODOC -DNOINFO -k install --DocE+STaALJfprDB-- From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 22 19:38:16 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AAFD16A4CE for ; Sun, 22 Aug 2004 19:38:16 +0000 (GMT) Received: from host142.ipowerweb.com (host142.ipowerweb.com [66.235.193.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 62B5A43D3F for ; Sun, 22 Aug 2004 19:38:16 +0000 (GMT) (envelope-from valour@thejemreport.com) Received: (qmail 61736 invoked from network); 22 Aug 2004 19:38:06 -0000 Received: from unknown (HELO ?192.168.0.163?) (66.67.130.234) by host142.ipowerweb.com with SMTP; 22 Aug 2004 19:38:06 -0000 From: Jem Matzan To: FreeBSD/AMD64 list Content-Type: text/plain Message-Id: <1093203489.43321.25.camel@valour.network> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 22 Aug 2004 15:38:09 -0400 Content-Transfer-Encoding: 7bit Subject: Microsoft Wireless Intellimouse Explorer 2.0 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 19:38:16 -0000 I had no trouble using this mouse with the i386 edition, but when I switched to the AMD64 release the mouse became choppy and slow. It's a USB mouse with a PS/2 adapter, and it only works as PS/2 in either 32-bit or 64-bit builds. Even though it's recognized properly in the terminal, moused can't use it. Anyway, I'm using the same hardware, the same xorg.conf and the same kernel config (adjusted for the change in architecture). Here's the system: Asus K8V Deluxe motherboard Athlon 64 3200+ (OEM) Corsair TwinX LL 1024MB DDR400 (2x512) Microsoft Wireless Optical Desktop (the above-mentioned mouse plus the wireless natural keyboard -- these both go through their respective PS/2 ports) Maxtor ATA133 120GB hard drive Pioneer DVDRW Albatron GeForce FX 5700 Ultra3 video card (AGP) And that's all. Trying to load the mouse through a USB connection results in moused claiming that the /dev/ums0 port is busy. moused detects the mouse in PS/2 mode as IntelliMouse Explorer, but will only accept the Auto, PS/2 and SysMouse protocols. Other mice by Microsoft and Logitech work just fine as USB or PS/2. Anyone have any ideas, or any ways I can further test the system to narrow down the problem? I've tried Google and the archive and have not seen anything at all on this, other than the note about it in my review some months back. I checked CVS to see if there were any changes to the moused source, but there didn't appear to be anything significant done since 5.2.1-RELEASE. -- Jem Matzan From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 23 11:01:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6E8016A4ED for ; Mon, 23 Aug 2004 11:01:59 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA2643D46 for ; Mon, 23 Aug 2004 11:01:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i7NB1x5a029756 for ; Mon, 23 Aug 2004 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7NB1xkf029750 for freebsd-amd64@freebsd.org; Mon, 23 Aug 2004 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 Aug 2004 11:01:59 GMT Message-Id: <200408231101.i7NB1xkf029750@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 11:02:00 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/06/09] amd64/67745 amd64 boot fails on compaq presario r3000z 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 3 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/07/28] amd64/69712 amd64 no DRI (hardware OpenGL) for ATI Radeon 9 o [2004/08/15] amd64/70500 amd64 bge driver for 3Com 3C996B on amd64 preve 6 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 23 09:07:18 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 152D116A4CE for ; Mon, 23 Aug 2004 09:07:18 +0000 (GMT) Received: from huawei.com (mta2.huawei.com [61.144.161.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2CA443D45 for ; Mon, 23 Aug 2004 09:07:16 +0000 (GMT) (envelope-from divakin@huawei.com) Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2W002NN59FEP@mta2.huawei.com> for freebsd-amd64@FreeBSD.org; Mon, 23 Aug 2004 16:36:51 +0800 (CST) Received: from mailru (mailru.huawei.com [172.18.6.2])Sep 8 2003)) with ESMTP id <0I2W00H0759DSM@mta2.huawei.com> for freebsd-amd64@FreeBSD.org; Mon, 23 Aug 2004 16:36:50 +0800 (CST) Received: from i83432 ([10.127.14.222])Jul 12 2002)) with ESMTPA id <0I2W0024V533OZ@mailru.huawei.com> for freebsd-amd64@FreeBSD.org; Mon, 23 Aug 2004 05:33:04 -0300 (GMT) Date: Mon, 23 Aug 2004 12:37:31 +0400 From: "Ivakin E. Dmitry" To: freebsd-amd64@FreeBSD.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-index: AcSI6p20gYeFeoJiS7+OD49qt3lVmg== X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-Id: <20040823090716.F2CA443D45@mx1.FreeBSD.org> X-Mailman-Approved-At: Mon, 23 Aug 2004 11:54:03 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: freebsd for AMD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 09:07:18 -0000 Hello, Is FreeBSD supported on AMD Athlon XP processor (not 64 bits)? Best regards, Ivakin Dmitry From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 23 15:52:35 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A5AB16A4CE for ; Mon, 23 Aug 2004 15:52:35 +0000 (GMT) Received: from gldis.ca (constans.gldis.ca [66.11.169.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C40043D67 for ; Mon, 23 Aug 2004 15:52:34 +0000 (GMT) (envelope-from gldisater@gldis.ca) Received: from [IPv6:::1] (localhost [127.0.0.1]) by gldis.ca (8.12.11/8.12.11) with ESMTP id i7NG470o077435; Mon, 23 Aug 2004 12:04:09 -0400 (EDT) (envelope-from gldisater@gldis.ca) Message-ID: <412A13B0.4030208@gldis.ca> Date: Mon, 23 Aug 2004 11:56:32 -0400 From: Jeremy Faulkner User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040728) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ivakin E. Dmitry" References: <20040823090716.F2CA443D45@mx1.FreeBSD.org> In-Reply-To: <20040823090716.F2CA443D45@mx1.FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-amd64@freebsd.org Subject: Re: freebsd for AMD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 15:52:35 -0000 Ivakin E. Dmitry wrote: > Hello, > > Is FreeBSD supported on AMD Athlon XP processor (not 64 bits)? > > Best regards, > Ivakin Dmitry FreeBSD supports all i386 processors. Including AMD's 32 bit processors. And this list is not meant for AMD's 32 bit processors. -- Jeremy Faulkner From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 24 06:20:37 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA19B16A4CE for ; Tue, 24 Aug 2004 06:20:37 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id A29E243D1D for ; Tue, 24 Aug 2004 06:20:35 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 45B31FD0B9 for ; Mon, 23 Aug 2004 23:20:35 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00593-03 for ; Mon, 23 Aug 2004 23:20:34 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id A7A64FD06B for ; Mon, 23 Aug 2004 23:20:34 -0700 (PDT) From: Sean McNeil To: amd64@freebsd.org Content-Type: text/plain Message-Id: <1093328434.6603.21.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 23 Aug 2004 23:20:34 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: va_list structure passing as argument X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 06:20:37 -0000 I'm looking at a problem I have on the amd64 with bsdtar. Essentially, you get a core dump if you try to run the following: tar zxvvf nonexistent.tar.gz I've tracked it down to an issue where the ap is getting changed as a side-effect of calling __vfprintf. It looks like this is happening because the va_list structure is being passed by reference. The va_list structure on amd64 is 24 bytes. I'm guessing that it is 16 bytes or less for i386. It has been a while since I've looked at the macro that determines when a structure is passed by reference or value. Does anyone know what that is? I'm guessing that 24 passes that cutoff but 16 does not and that is why I see this bug on amd64 and not i386. Sean From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 24 09:20:47 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5ECA16A4CE; Tue, 24 Aug 2004 09:20:47 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B524543D48; Tue, 24 Aug 2004 09:20:47 +0000 (GMT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 5A4152A8FB; Tue, 24 Aug 2004 02:20:47 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 9C0EDE2B3; Tue, 24 Aug 2004 02:20:46 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i7O9KjPP003792; Tue, 24 Aug 2004 02:20:45 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i7O9Kj8E003791; Tue, 24 Aug 2004 02:20:45 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Tue, 24 Aug 2004 02:20:45 -0700 User-Agent: KMail/1.6.1 References: <1093328434.6603.21.camel@server.mcneil.com> In-Reply-To: <1093328434.6603.21.camel@server.mcneil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408240220.45554.peter@wemm.org> cc: amd64@freebsd.org Subject: Re: va_list structure passing as argument X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 09:20:47 -0000 On Monday 23 August 2004 11:20 pm, Sean McNeil wrote: > I'm looking at a problem I have on the amd64 with bsdtar. > Essentially, you get a core dump if you try to run the following: > > tar zxvvf nonexistent.tar.gz > > I've tracked it down to an issue where the ap is getting changed as a > side-effect of calling __vfprintf. It looks like this is happening > because the va_list structure is being passed by reference. The > va_list structure on amd64 is 24 bytes. I'm guessing that it is 16 > bytes or less for i386. It has been a while since I've looked at the > macro that determines when a structure is passed by reference or > value. Does anyone know what that is? I'm guessing that 24 passes > that cutoff but 16 does not and that is why I see this bug on amd64 > and not i386. Yes, its an external value. Consider it a pointer. It is the same on both ppc and amd64. The problem is that vfprintf "consumes" the values and advances the counters in the structure. (The argument passing ABI is very complex) What you need to do is this: myfunc(va_list ap) { va_list apcopy; va_copy(apcopy, ap); vprintf(stuff, ap1); va_copy(apcopy, ap); do_stuff_with(ap1); } etc. Using va_copy is "correct" for all our platforms, but neglecting to use it is only fatal for amd64 and ppc. Does that make sense? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 24 09:20:47 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5ECA16A4CE; Tue, 24 Aug 2004 09:20:47 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B524543D48; Tue, 24 Aug 2004 09:20:47 +0000 (GMT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 5A4152A8FB; Tue, 24 Aug 2004 02:20:47 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 9C0EDE2B3; Tue, 24 Aug 2004 02:20:46 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i7O9KjPP003792; Tue, 24 Aug 2004 02:20:45 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i7O9Kj8E003791; Tue, 24 Aug 2004 02:20:45 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Tue, 24 Aug 2004 02:20:45 -0700 User-Agent: KMail/1.6.1 References: <1093328434.6603.21.camel@server.mcneil.com> In-Reply-To: <1093328434.6603.21.camel@server.mcneil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408240220.45554.peter@wemm.org> cc: amd64@freebsd.org Subject: Re: va_list structure passing as argument X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 09:20:47 -0000 On Monday 23 August 2004 11:20 pm, Sean McNeil wrote: > I'm looking at a problem I have on the amd64 with bsdtar. > Essentially, you get a core dump if you try to run the following: > > tar zxvvf nonexistent.tar.gz > > I've tracked it down to an issue where the ap is getting changed as a > side-effect of calling __vfprintf. It looks like this is happening > because the va_list structure is being passed by reference. The > va_list structure on amd64 is 24 bytes. I'm guessing that it is 16 > bytes or less for i386. It has been a while since I've looked at the > macro that determines when a structure is passed by reference or > value. Does anyone know what that is? I'm guessing that 24 passes > that cutoff but 16 does not and that is why I see this bug on amd64 > and not i386. Yes, its an external value. Consider it a pointer. It is the same on both ppc and amd64. The problem is that vfprintf "consumes" the values and advances the counters in the structure. (The argument passing ABI is very complex) What you need to do is this: myfunc(va_list ap) { va_list apcopy; va_copy(apcopy, ap); vprintf(stuff, ap1); va_copy(apcopy, ap); do_stuff_with(ap1); } etc. Using va_copy is "correct" for all our platforms, but neglecting to use it is only fatal for amd64 and ppc. Does that make sense? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 24 17:29:21 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1389916A4CE; Tue, 24 Aug 2004 17:29:21 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCE9B43D53; Tue, 24 Aug 2004 17:29:20 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 748FDFD0B6; Tue, 24 Aug 2004 10:29:20 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10001-01; Tue, 24 Aug 2004 10:29:20 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id E628CFD02A; Tue, 24 Aug 2004 10:29:19 -0700 (PDT) From: Sean McNeil To: Peter Wemm In-Reply-To: <200408240220.45554.peter@wemm.org> References: <1093328434.6603.21.camel@server.mcneil.com> <200408240220.45554.peter@wemm.org> Content-Type: text/plain Message-Id: <1093368559.9914.15.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 10:29:19 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: amd64@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: va_list structure passing as argument X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 17:29:21 -0000 On Tue, 2004-08-24 at 02:20, Peter Wemm wrote: > On Monday 23 August 2004 11:20 pm, Sean McNeil wrote: > > I'm looking at a problem I have on the amd64 with bsdtar. > > Essentially, you get a core dump if you try to run the following: > > > > tar zxvvf nonexistent.tar.gz > > > > I've tracked it down to an issue where the ap is getting changed as a > > side-effect of calling __vfprintf. It looks like this is happening > > because the va_list structure is being passed by reference. The > > va_list structure on amd64 is 24 bytes. I'm guessing that it is 16 > > bytes or less for i386. It has been a while since I've looked at the > > macro that determines when a structure is passed by reference or > > value. Does anyone know what that is? I'm guessing that 24 passes > > that cutoff but 16 does not and that is why I see this bug on amd64 > > and not i386. > > Yes, its an external value. Consider it a pointer. It is the same on > both ppc and amd64. > > The problem is that vfprintf "consumes" the values and advances the > counters in the structure. (The argument passing ABI is very complex) > > What you need to do is this: > myfunc(va_list ap) > { > va_list apcopy; > > va_copy(apcopy, ap); > vprintf(stuff, ap1); > va_copy(apcopy, ap); > do_stuff_with(ap1); > } > etc. Using va_copy is "correct" for all our platforms, but neglecting > to use it is only fatal for amd64 and ppc. > > Does that make sense? Makes sense and is what I tried originally. I figured this wasn't correct, however, as it means that a side-effect of the call is allowable. What you are indicating is that it is allowable and expected. The problem is, the side-effect will only happen on ppc and amd64 since i386 will pass the va_list by value. Thanks, Sean From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 24 17:29:21 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1389916A4CE; Tue, 24 Aug 2004 17:29:21 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCE9B43D53; Tue, 24 Aug 2004 17:29:20 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 748FDFD0B6; Tue, 24 Aug 2004 10:29:20 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10001-01; Tue, 24 Aug 2004 10:29:20 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id E628CFD02A; Tue, 24 Aug 2004 10:29:19 -0700 (PDT) From: Sean McNeil To: Peter Wemm In-Reply-To: <200408240220.45554.peter@wemm.org> References: <1093328434.6603.21.camel@server.mcneil.com> <200408240220.45554.peter@wemm.org> Content-Type: text/plain Message-Id: <1093368559.9914.15.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 24 Aug 2004 10:29:19 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: amd64@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: va_list structure passing as argument X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 17:29:21 -0000 On Tue, 2004-08-24 at 02:20, Peter Wemm wrote: > On Monday 23 August 2004 11:20 pm, Sean McNeil wrote: > > I'm looking at a problem I have on the amd64 with bsdtar. > > Essentially, you get a core dump if you try to run the following: > > > > tar zxvvf nonexistent.tar.gz > > > > I've tracked it down to an issue where the ap is getting changed as a > > side-effect of calling __vfprintf. It looks like this is happening > > because the va_list structure is being passed by reference. The > > va_list structure on amd64 is 24 bytes. I'm guessing that it is 16 > > bytes or less for i386. It has been a while since I've looked at the > > macro that determines when a structure is passed by reference or > > value. Does anyone know what that is? I'm guessing that 24 passes > > that cutoff but 16 does not and that is why I see this bug on amd64 > > and not i386. > > Yes, its an external value. Consider it a pointer. It is the same on > both ppc and amd64. > > The problem is that vfprintf "consumes" the values and advances the > counters in the structure. (The argument passing ABI is very complex) > > What you need to do is this: > myfunc(va_list ap) > { > va_list apcopy; > > va_copy(apcopy, ap); > vprintf(stuff, ap1); > va_copy(apcopy, ap); > do_stuff_with(ap1); > } > etc. Using va_copy is "correct" for all our platforms, but neglecting > to use it is only fatal for amd64 and ppc. > > Does that make sense? Makes sense and is what I tried originally. I figured this wasn't correct, however, as it means that a side-effect of the call is allowable. What you are indicating is that it is allowable and expected. The problem is, the side-effect will only happen on ppc and amd64 since i386 will pass the va_list by value. Thanks, Sean From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 24 18:55:30 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 536CE16A4CE; Tue, 24 Aug 2004 18:55:30 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 417C043D4C; Tue, 24 Aug 2004 18:55:30 +0000 (GMT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 110052A8DA; Tue, 24 Aug 2004 11:55:30 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 8CC14E2B3; Tue, 24 Aug 2004 11:55:29 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i7OItTHx009699; Tue, 24 Aug 2004 11:55:29 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i7OItPvX009698; Tue, 24 Aug 2004 11:55:25 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: Sean McNeil Date: Tue, 24 Aug 2004 11:55:25 -0700 User-Agent: KMail/1.6.1 References: <1093328434.6603.21.camel@server.mcneil.com> <200408240220.45554.peter@wemm.org> <1093368559.9914.15.camel@server.mcneil.com> In-Reply-To: <1093368559.9914.15.camel@server.mcneil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408241155.25406.peter@wemm.org> cc: amd64@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: va_list structure passing as argument X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 18:55:30 -0000 On Tuesday 24 August 2004 10:29 am, Sean McNeil wrote: > On Tue, 2004-08-24 at 02:20, Peter Wemm wrote: > > On Monday 23 August 2004 11:20 pm, Sean McNeil wrote: > > > I'm looking at a problem I have on the amd64 with bsdtar. > > > Essentially, you get a core dump if you try to run the following: > > > > > > tar zxvvf nonexistent.tar.gz > > > > > > I've tracked it down to an issue where the ap is getting changed > > > as a side-effect of calling __vfprintf. It looks like this is > > > happening because the va_list structure is being passed by > > > reference. The va_list structure on amd64 is 24 bytes. I'm > > > guessing that it is 16 bytes or less for i386. It has been a > > > while since I've looked at the macro that determines when a > > > structure is passed by reference or value. Does anyone know what > > > that is? I'm guessing that 24 passes that cutoff but 16 does not > > > and that is why I see this bug on amd64 and not i386. > > > > Yes, its an external value. Consider it a pointer. It is the same > > on both ppc and amd64. > > > > The problem is that vfprintf "consumes" the values and advances > > the counters in the structure. (The argument passing ABI is very > > complex) > > > > What you need to do is this: > > myfunc(va_list ap) > > { > > va_list apcopy; > > > > va_copy(apcopy, ap); > > vprintf(stuff, ap1); > > va_copy(apcopy, ap); > > do_stuff_with(ap1); > > } > > etc. Using va_copy is "correct" for all our platforms, but > > neglecting to use it is only fatal for amd64 and ppc. > > > > Does that make sense? > > Makes sense and is what I tried originally. I figured this wasn't > correct, however, as it means that a side-effect of the call is > allowable. What you are indicating is that it is allowable and > expected. The problem is, the side-effect will only happen on ppc > and amd64 since i386 will pass the va_list by value. Just because you can get away with it on i386, that doesn't mean it is allowed. With C99, you're supposed to use va_copy, even if you can get away with not using it on some platforms. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Tue Aug 24 18:55:30 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 536CE16A4CE; Tue, 24 Aug 2004 18:55:30 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 417C043D4C; Tue, 24 Aug 2004 18:55:30 +0000 (GMT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 110052A8DA; Tue, 24 Aug 2004 11:55:30 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 8CC14E2B3; Tue, 24 Aug 2004 11:55:29 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i7OItTHx009699; Tue, 24 Aug 2004 11:55:29 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i7OItPvX009698; Tue, 24 Aug 2004 11:55:25 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: Sean McNeil Date: Tue, 24 Aug 2004 11:55:25 -0700 User-Agent: KMail/1.6.1 References: <1093328434.6603.21.camel@server.mcneil.com> <200408240220.45554.peter@wemm.org> <1093368559.9914.15.camel@server.mcneil.com> In-Reply-To: <1093368559.9914.15.camel@server.mcneil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408241155.25406.peter@wemm.org> cc: amd64@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: va_list structure passing as argument X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 18:55:30 -0000 On Tuesday 24 August 2004 10:29 am, Sean McNeil wrote: > On Tue, 2004-08-24 at 02:20, Peter Wemm wrote: > > On Monday 23 August 2004 11:20 pm, Sean McNeil wrote: > > > I'm looking at a problem I have on the amd64 with bsdtar. > > > Essentially, you get a core dump if you try to run the following: > > > > > > tar zxvvf nonexistent.tar.gz > > > > > > I've tracked it down to an issue where the ap is getting changed > > > as a side-effect of calling __vfprintf. It looks like this is > > > happening because the va_list structure is being passed by > > > reference. The va_list structure on amd64 is 24 bytes. I'm > > > guessing that it is 16 bytes or less for i386. It has been a > > > while since I've looked at the macro that determines when a > > > structure is passed by reference or value. Does anyone know what > > > that is? I'm guessing that 24 passes that cutoff but 16 does not > > > and that is why I see this bug on amd64 and not i386. > > > > Yes, its an external value. Consider it a pointer. It is the same > > on both ppc and amd64. > > > > The problem is that vfprintf "consumes" the values and advances > > the counters in the structure. (The argument passing ABI is very > > complex) > > > > What you need to do is this: > > myfunc(va_list ap) > > { > > va_list apcopy; > > > > va_copy(apcopy, ap); > > vprintf(stuff, ap1); > > va_copy(apcopy, ap); > > do_stuff_with(ap1); > > } > > etc. Using va_copy is "correct" for all our platforms, but > > neglecting to use it is only fatal for amd64 and ppc. > > > > Does that make sense? > > Makes sense and is what I tried originally. I figured this wasn't > correct, however, as it means that a side-effect of the call is > allowable. What you are indicating is that it is allowable and > expected. The problem is, the side-effect will only happen on ppc > and amd64 since i386 will pass the va_list by value. Just because you can get away with it on i386, that doesn't mean it is allowed. With C99, you're supposed to use va_copy, even if you can get away with not using it on some platforms. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Wed Aug 25 19:02:26 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 645FF16A4D2; Wed, 25 Aug 2004 19:02:26 +0000 (GMT) Received: from duchess.twilley.org (alpha.twilley.org [66.92.188.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E5243D1D; Wed, 25 Aug 2004 19:02:25 +0000 (GMT) (envelope-from jmt@twilley.org) Received: by duchess.twilley.org (Postfix, from userid 1001) id DA2B53FBCB; Wed, 25 Aug 2004 12:02:24 -0700 (PDT) To: obrien@freebsd.org References: <86r7q1e46f.fsf@duchess.twilley.org> <20040821173933.GA14967@dragon.nuxi.com> From: Jack Twilley X-PGP-Key: 0x007F7B38 X-PGP-Fingerprint: 5315 7434 6095 DF36 995B 3407 18F1 527C 007F 7B38 X-Face: .NHAX*9Wpk.L>*/dOY%Tx85BIb; aN`:H*I7y}qDK{(&Q(zjfnli]\}|xh+mpp22}~9u.T[[ zaK{BFgnXg'rBY+GiwLccR(O/iXq"_Fhrx0+%!1N}?D(mT{T$n_q}f`!f\(,@dR~*x&{_Zn^Qm)6rV ]E,6z3JLm6k<9>^9kg:#TU-S'a3{@c,rcT7YF`M*cCg_S0e1=C?!^kg-Wy]f+Xjpe#gB]>#xi= sa4'F#mX[QH^5}1B$0.s"6Y0R["ypG0mIe; 8R6H_W]*_c:1|0Z^FgjUA?dCr`b[TX (David O'Brien's message of "Sat, 21 Aug 2004 10:39:33 -0700") Message-ID: <86r7pvoxc8.fsf@duchess.twilley.org> User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (celery, berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" cc: freebsd-amd64@freebsd.org Subject: Re: -CURRENT doesn't make world lately X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 19:02:26 -0000 --=-=-= Content-Type: text/plain >>>>> "David" == David O'Brien writes: Jack> Am I the only one who's tried to build -CURRENT recently and Jack> failed? Jack> One of the GCC info files isn't being makeinfo'ed properly, and Jack> that breaks the build. I'd love to try some possible fixes for Jack> the SMP problems I'm having but that requires a functional world Jack> build. Jack> It breaks at gnu/usr.bin/cc/doc -- anyone else notice this? David> Error log please. A penguin stole my x-ray glasses that let me David> see screens from miles away. Here you go. Hope it helps. ===> gnu/usr.bin/cc/doc makeinfo -I /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc -I /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/include --no-split -I /usr/src/gnu/usr.bin/cc/doc -I /usr/src/gnu/usr.bin/cc/doc /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/gcc.texi -o gcc.info gzip -cn gcc.info > gcc.info.gz makeinfo -I /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc -I /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/include --no-split -I /usr/src/gnu/usr.bin/cc/doc -I /usr/src/gnu/usr.bin/cc/doc /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/cpp.texi -o cpp.info gzip -cn cpp.info > cpp.info.gz makeinfo -I /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc -I /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/include --no-split -I /usr/src/gnu/usr.bin/cc/doc -I /usr/src/gnu/usr.bin/cc/doc /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/gccint.texi -o gccint.info /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:4542: @code missing close brace. /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:4538: No matching `@end deftypefn'. /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:4387: Next reference to nonexistent node `Trampolines' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/fragments.texi:85: Cross reference to nonexistent node `Initialization' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/fragments.texi:78: Cross reference to nonexistent node `Initialization' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:54: Menu reference to nonexistent node `Misc' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:53: Menu reference to nonexistent node `PCH Target' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:52: Menu reference to nonexistent node `MIPS Coprocessors' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:51: Menu reference to nonexistent node `Target Attributes' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:50: Menu reference to nonexistent node `Mode Switching' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:49: Menu reference to nonexistent node `Floating Point' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:48: Menu reference to nonexistent node `Debugging Info' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:47: Menu reference to nonexistent node `Assembler Format' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:46: Menu reference to nonexistent node `PIC' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:45: Menu reference to nonexistent node `Sections' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:44: Menu reference to nonexistent node `Scheduling' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:43: Menu reference to nonexistent node `Costs' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:42: Menu reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:41: Menu reference to nonexistent node `Addressing Modes' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:40: Menu reference to nonexistent node `Library Calls' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/tm.texi:39: Menu reference to nonexistent node `Trampolines' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/md.texi:5790: Cross reference to nonexistent node `Scheduling' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/md.texi:3717: Cross reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/md.texi:3703: Cross reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/md.texi:2999: Cross reference to nonexistent node `Misc' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/md.texi:599: Cross reference to nonexistent node `Instruction Output' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:2032: Cross reference to nonexistent node `Misc' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:2029: Cross reference to nonexistent node `Misc' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:1815: Cross reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:1682: Cross reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:1373: Cross reference to nonexistent node `Data Output' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:1369: Cross reference to nonexistent node `Floating Point' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:1212: Cross reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/rtl.texi:1113: Cross reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/sourcebuild.texi:742: Cross reference to nonexistent node `Target Attributes' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/sourcebuild.texi:729: Cross reference to nonexistent node `Condition Code' (perhaps incorrect sectioning?). /usr/src/gnu/usr.bin/cc/doc/../../../../contrib/gcc/doc/libgcc.texi:228: Cross reference to nonexistent node `Library Calls' (perhaps incorrect sectioning?). makeinfo: Removing output file `gccint.info' due to errors; use --force to preserve. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/doc. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Jack. -- Jack Twilley jmt at twilley dot org http colon slash slash www dot twilley dot org slash tilde jmt slash --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBLOJAGPFSfAB/ezgRApnSAJ9eZrvZGhFMs7TjGBfEaEtvNy5aKgCg3kSt +dGSmOOaj38/Ad7TeGWn3vM= =M6eZ -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-amd64@FreeBSD.ORG Thu Aug 26 07:56:49 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FAF616A4CE for ; Thu, 26 Aug 2004 07:56:49 +0000 (GMT) Received: from mail-relay-4.tiscali.it (mail-relay-4.tiscali.it [213.205.33.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF19243D3F for ; Thu, 26 Aug 2004 07:56:48 +0000 (GMT) (envelope-from vw393@fatcat.homeunix.net) Received: from qmailsvr (217.133.34.161) by mail-relay-4.tiscali.it (7.1.021.3) id 40F3EBEA009646BA for freebsd-amd64@freebsd.org; Thu, 26 Aug 2004 09:56:47 +0200 Received: (qmail 22123 invoked from network); 26 Aug 2004 07:57:32 -0000 Received: from unknown (HELO www.pizzinato.it) (192.168.1.12) by 192.168.1.11 with SMTP; 26 Aug 2004 07:57:32 -0000 Received: from 213.156.52.112 (SquirrelMail authenticated user vw393@fatcat.homeunix.net) by www.pizzinato.it with HTTP; Thu, 26 Aug 2004 07:57:32 -0000 (GMT) Message-ID: <7526.213.156.52.112.1093507052.squirrel@www.pizzinato.it> Date: Thu, 26 Aug 2004 07:57:32 -0000 (GMT) From: "vw393" To: freebsd-amd64@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: newbie question X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vw393@fatcat.homeunix.net List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 07:56:49 -0000 Hi All. I wonder what has changed in the kernel compilation procedure. The way I know doesn't work anylonger, and I couldn't find any hint to solve this. I just installed this amd64 machine, cvsup'd the RELENG_5 branch and buildworld/buildkernel etc., no errors. However, I can't manage to recompile the kernel: bash-2.05b# uname -a FreeBSD ludo 5.3-BETA1 FreeBSD 5.3-BETA1 #2: Thu Aug 26 00:35:46 UTC 2004 root@ludo:/usr/obj/usr/src/sys/GENERIC amd64 bash-2.05b# bash-2.05b# bash-2.05b# cd /usr/src/sys/i386/conf bash-2.05b# bash-2.05b# cp GENERIC NEWKERNEL bash-2.05b# bash-2.05b# config NEWKERNEL Kernel build directory is ../compile/NEWKERNEL Don't forget to do a ``make depend'' bash-2.05b# bash-2.05b# cd ../compile/NEWKERNEL bash-2.05b# bash-2.05b# make depend 2>&1 | tee /tmp/log And this fails straight away with the following: rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Win line -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilte r -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -finline-limit= 8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msof t-float -fno-asynchronous-unwind-tables -ffreestanding ../../../amd64/amd64/genassym.c In file included from ../../../sys/systm.h:41, from ../../../amd64/amd64/genassym.c:42: ./machine/atomic.h: In function `atomic_cmpset_ptr': ./machine/atomic.h:367: warning: cast from pointer to integer of different size ./machine/atomic.h:368: warning: cast from pointer to integer of different size ./machine/atomic.h: In function `atomic_load_acq_ptr': ./machine/atomic.h:378: warning: cast to pointer from integer of different size ./machine/atomic.h: In function `atomic_store_rel_ptr': ./machine/atomic.h:384: warning: cast from pointer to integer of different size In file included from ../../../sys/systm.h:42, from ../../../amd64/amd64/genassym.c:42: ./machine/cpufunc.h: In function `invlpg': ./machine/cpufunc.h:436: warning: cast to pointer from integer of different size In file included from ../../../sys/proc.h:53, from ../../../sys/buf.h:263, from ../../../amd64/amd64/genassym.c:45: ../../../sys/signal.h: At top level: ../../../sys/signal.h:303: error: redefinition of `struct osigcontext' In file included from ../../../amd64/amd64/genassym.c:70: ./machine/sigframe.h:86: error: field `sf_uc' has incomplete type ../../../amd64/amd64/genassym.c:96: error: `addr_PTmap' undeclared here (not in a function) ../../../amd64/amd64/genassym.c:97: error: `addr_PDmap' undeclared here (not in a function) ../../../amd64/amd64/genassym.c:98: error: `addr_PDPmap' undeclared here (not in a function) ../../../amd64/amd64/genassym.c:99: error: `addr_PML4map' undeclared here (not in a function) ... ... ## many of these lines ## ... ../../../amd64/amd64/genassym.c:211: error: storage size of `SEL_RPL_MASKw2' isn't known ../../../amd64/amd64/genassym.c:211: error: storage size of `SEL_RPL_MASKw3' isn't known *** Error code 1 Stop in /usr/src/sys/i386/compile/NEWKERNEL. *** Error code 1 Stop in /usr/src/sys/i386/compile/NEWKERNEL. bash-2.05b# Any idea? Thanks From owner-freebsd-amd64@FreeBSD.ORG Thu Aug 26 12:18:53 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F69816A4CF for ; Thu, 26 Aug 2004 12:18:53 +0000 (GMT) Received: from toijalantilitoimisto.fi (toijalantilitoimisto.fi [194.29.194.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB3ED43D48 for ; Thu, 26 Aug 2004 12:18:52 +0000 (GMT) (envelope-from Kari.Pietarinen@saunalahti.fi) Received: from localhost (localhost.yang.fi [127.0.0.1]) by toijalantilitoimisto.fi (Postfix) with ESMTP id 99E49E6053 for ; Thu, 26 Aug 2004 15:18:52 +0300 (EEST) Received: from toijalantilitoimisto.fi ([127.0.0.1]) by localhost (ying.yang.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81955-07 for ; Thu, 26 Aug 2004 15:18:51 +0300 (EEST) Received: from [10.0.0.81] (ziggurati.net [62.142.249.77]) by toijalantilitoimisto.fi (Postfix) with ESMTP id 88BFAE603E for ; Thu, 26 Aug 2004 15:18:51 +0300 (EEST) Message-ID: <412DD47E.8020302@saunalahti.fi> Date: Thu, 26 Aug 2004 15:15:58 +0300 From: Kari Pietarinen User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Freebsd-amd64 nforce3 serial-ata problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 12:18:53 -0000 Hi all. I have FreeBSD-Amd64 5.2.1 with athlon64 3000+ system with (EP-8KDA3J)* *nForce3-250 chipset under configuration. In some boot i noticed that serial-ata is used only in UDA33 mode and is only disk that this system to have, so the system would be quite inuseful to original purpose because of slow filesystem I/O. This far I have made some minor investigation conserning the proplem and here is some outputs dmesg: _Mao# dmesg|grep 'ad4' GEOM: create disk ad4 dp=0xffffff0000ecfca0 ad4: 35304MB [71730/16/63] at ata2-master UDMA33 _ and dmesg for atacontrollers: _Mao# dmesg|grep 'atapci' atapci0: port 0xf000-0xf00f at device 8.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: port 0xc800-0xc87f,0xc400-0xc40f,0xb70-0xb73,0x970-0x977,0xbf0-0xbf3,0x9f0-0x9f7 irq 11 at device 10.0 on pci0 atapci1: [MPSAFE] ata2: at 0x9f0 on atapci1 ata3: at 0x970 on atapci1 _ atacontrol outputs: _Mao# atacontrol list|grep 'ad4' Master: ad4 ATA/ATAPI rev 6 _ ATA/ATAPI rev 6 is "alias" for UDMA100 or visa versa, BUT if i try to set UDMA133 or UDMA100 on manually with atacontrol it gives me following output: _Mao# atacontrol mode 2 UDMA100 BIOSPIO Master = UDMA33 Slave = BIOSPIO _ benchmarking with bonnie/bonnie++ or timed dd indicates that _buffered_ disk I/O is approximately 50Mb/sec, so that leads to conclusion that this atapci controller uses disk really as UDMA33. Output of pciconf: _Mao# pciconf -lv|grep 'atapci' atapci0@pci0:8:0: class=0x01018a card=0x100c1695 chip=0x00e510de rev=0xa2 hdr=0x00 atapci1@pci0:10:0: class=0x010185 card=0x100c1695 chip=0x00e310de rev=0xa2 hdr=0x00 _ I have searched posts and groups for this problem and there seems to been some similar issues conserning Serial-ATA/ATA: http://lists.freebsd.org/pipermail/freebsd-amd64/2004-January/000415.html <- Same issue with non-SATA controller http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-11/0024.html <- Same issue with exeption that this system doesn't complain about /DMA limited to UDMA33 /AND sees SATA controller as GENERIC ATA As I am NOT expert on SATA issues so I'm bit of confused here, but pointing to information beneath I would think that system sees this SATA controller as an generic ATA controller and so can I assume that it is driver problem with nforce3? Also integrated nvGigabit ethernet chip doesn't work, nForce3-150 have patch but i didn't have any success with that (pciconf does not see ethernet chip at all). Can anyone point me solution or any other knowledge to these problems? Also, I have another motherboard (8KDA3+) with execption that it have silicons sata chip (SIL 3114) integrated on it, any experiences with SIL 3114 and FreeBSD-amd64? Gratefully, Kari Pietarinen From owner-freebsd-amd64@FreeBSD.ORG Thu Aug 26 17:41:08 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 930E116A4CE for ; Thu, 26 Aug 2004 17:41:08 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 352A043D53 for ; Thu, 26 Aug 2004 17:41:08 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1C0OFD-0002w1-00; Thu, 26 Aug 2004 19:41:03 +0200 Date: Thu, 26 Aug 2004 19:41:03 +0200 To: vw393 Message-ID: <20040826174103.GQ29560@poupinou.org> References: <7526.213.156.52.112.1093507052.squirrel@www.pizzinato.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7526.213.156.52.112.1093507052.squirrel@www.pizzinato.it> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Bruno Ducrot cc: freebsd-amd64@freebsd.org Subject: Re: newbie question X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 17:41:08 -0000 On Thu, Aug 26, 2004 at 07:57:32AM -0000, vw393 wrote: > Hi All. > > I wonder what has changed in the kernel compilation procedure. The way I > know doesn't work anylonger, and I couldn't find any hint to solve this. > > I just installed this amd64 machine, cvsup'd the RELENG_5 branch and > buildworld/buildkernel etc., no errors. > However, I can't manage to recompile the kernel: > I guess you should go to '/usr/src/sys/amd64/conf' instead of '/usr/src/sys/i386/conf'... -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 27 03:45:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5163716A4CF; Fri, 27 Aug 2004 03:45:42 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5D9343D2F; Fri, 27 Aug 2004 03:45:41 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7R3jfcu038985; Thu, 26 Aug 2004 23:45:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7R3jfbr075055; Thu, 26 Aug 2004 23:45:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 505557303F; Thu, 26 Aug 2004 23:45:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040827034541.505557303F@freebsd-current.sentex.ca> Date: Thu, 26 Aug 2004 23:45:41 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 03:45:42 -0000 TB --- 2004-08-27 02:39:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-27 02:39:41 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-08-27 02:39:41 - checking out the source tree TB --- 2004-08-27 02:39:41 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-08-27 02:39:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-27 02:44:52 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-27 02:44:52 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-27 02:44:52 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -o kgmon kgmon.o -lkvm gzip -cn /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/kgmon/kgmon.8 > kgmon.8.gz ===> usr.sbin/kldxref cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/kldxref/kldxref.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/kldxref/ef.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/kldxref/ef_obj.c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/kldxref/ef_obj.c: In function `ef_obj_open': /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/kldxref/ef_obj.c:377: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/kldxref. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-08-27 03:45:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-27 03:45:41 - ERROR: failed to build world TB --- 2004-08-27 03:45:41 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 27 18:13:18 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B5FD16A4CE for ; Fri, 27 Aug 2004 18:13:18 +0000 (GMT) Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C1F43D1D for ; Fri, 27 Aug 2004 18:13:17 +0000 (GMT) (envelope-from tilman@arved.at) Received: from huckfinn-wi0.arved.de (localhost [127.0.0.1]) i7RIDI4k073367 for ; Fri, 27 Aug 2004 20:13:18 +0200 (CEST) (envelope-from tilman@arved.at) Received: (from tilman@localhost) by huckfinn-wi0.arved.de (8.13.1/8.12.6/Submit) id i7RIDHrE073366 for amd64@FreeBSD.org; Fri, 27 Aug 2004 20:13:17 +0200 (CEST) X-Authentication-Warning: huckfinn-wi0.arved.de: tilman set sender to tilman@arved.at using -f Date: Fri, 27 Aug 2004 20:13:17 +0200 From: Tilman Linneweh To: amd64@FreeBSD.org Message-ID: <20040827181317.GA24054@arved.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Adjust comment after IA32->COMPAT->IA32 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 18:13:18 -0000 Hello, just noticed a leftover Comment after IA32->COMPAT_IA32 renaming Please commit or approve: http://people.freebsd.org/~arved/stuff/NOTES.diff From owner-freebsd-amd64@FreeBSD.ORG Fri Aug 27 18:42:48 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C85C16A4CE; Fri, 27 Aug 2004 18:42:48 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13FE143D75; Fri, 27 Aug 2004 18:42:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp53.pn.xcllnt.net (dhcp53.pn.xcllnt.net [192.168.4.253]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7RIglc0021658; Fri, 27 Aug 2004 11:42:47 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp53.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp53.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7RIgliX076588; Fri, 27 Aug 2004 11:42:47 -0700 (PDT) (envelope-from marcel@dhcp53.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp53.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7RIglRN076587; Fri, 27 Aug 2004 11:42:47 -0700 (PDT) (envelope-from marcel) Date: Fri, 27 Aug 2004 11:42:47 -0700 From: Marcel Moolenaar To: Tilman Linneweh Message-ID: <20040827184247.GB76550@dhcp53.pn.xcllnt.net> References: <20040827181317.GA24054@arved.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040827181317.GA24054@arved.at> User-Agent: Mutt/1.4.2.1i cc: amd64@freebsd.org Subject: Re: Adjust comment after IA32->COMPAT->IA32 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 18:42:48 -0000 On Fri, Aug 27, 2004 at 08:13:17PM +0200, Tilman Linneweh wrote: > > just noticed a leftover Comment after IA32->COMPAT_IA32 renaming > > Please commit or approve: > http://people.freebsd.org/~arved/stuff/NOTES.diff I approve it and take responsibility. Go for it. :-) (if someone didn't beat you to it) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net