From owner-freebsd-amd64@FreeBSD.ORG Sun Nov 23 04:47:53 2003 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 9550C16A4CE for ; Sun, 23 Nov 2003 04:47:53 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id F385643FCB for ; Sun, 23 Nov 2003 04:47:51 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from localhost by pandora.cs.kun.nl via odin.cs.kun.nl [131.174.33.33] with ESMTP for id hANClnmU003937 (8.12.10/3.58); Sun, 23 Nov 2003 13:47:50 +0100 (MET) From: Adriaan de Groot To: amd64@freebsd.org Date: Sun, 23 Nov 2003 13:47:38 +0100 User-Agent: KMail/1.5.93 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200311231347.38353.adridg@cs.kun.nl> Subject: Ports mixing libc and libc_r 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, 23 Nov 2003 12:47:53 -0000 ogg123 bus errors on me all the time, in code that looks perfectly innocuous sprintf(data,"%05li:%05.2f",min,sec); and i suspect it's because ogg123 links against both libc_r and libc: beans.ebn.kun.nl$ldd `which ogg123` /usr/local/bin/ogg123: libvorbisfile.so.3 => /usr/local/lib/libvorbisfile.so.3 (0x20063d000) libvorbis.so.2 => /usr/local/lib/libvorbis.so.2 (0x200744000) libm.so.2 => /lib/libm.so.2 (0x200875000) libogg.so.4 => /usr/local/lib/libogg.so.4 (0x20099d000) libao.so.3 => /usr/local/lib/libao.so.3 (0x200aa2000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x200ba8000) libcurl.so.2 => /usr/local/lib/libcurl.so.2 (0x200d98000) libintl.so.5 => /usr/local/lib/libintl.so.5 (0x200ec6000) libc_r.so.5 => /usr/lib/libc_r.so.5 (0x200fcf000) libc.so.5 => /lib/libc.so.5 (0x2010ff000) libssl.so.3 => /usr/lib/libssl.so.3 (0x201330000) libcrypto.so.3 => /lib/libcrypto.so.3 (0x201475000) libz.so.2 => /lib/libz.so.2 (0x201708000) this is after a straightforward ports make && make install. Now, before I go chasing phantoms, (1) is this bad? (2) the final link of ogg123 explicitly links with -lc_r, is that bad? Thanks, [ade] -- pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot If the door is ajar, can we fill it with door-jamb? From owner-freebsd-amd64@FreeBSD.ORG Sun Nov 23 06:04:41 2003 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 49A4C16A4CE for ; Sun, 23 Nov 2003 06:04:41 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1329A43F93 for ; Sun, 23 Nov 2003 06:04:40 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from localhost by pandora.cs.kun.nl via odin.cs.kun.nl [131.174.33.33] with ESMTP for id hANE4bmU009936 (8.12.10/3.58); Sun, 23 Nov 2003 15:04:38 +0100 (MET) From: Adriaan de Groot To: amd64@freebsd.org Date: Sun, 23 Nov 2003 15:04:34 +0100 User-Agent: KMail/1.5.93 References: <200311231347.38353.adridg@cs.kun.nl> In-Reply-To: <200311231347.38353.adridg@cs.kun.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_z5Lw/2I7qZkRQQX" Message-Id: <200311231504.35012.adridg@cs.kun.nl> X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: Ports mixing libc and libc_r 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, 23 Nov 2003 14:04:41 -0000 --Boundary-00=_z5Lw/2I7qZkRQQX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sunday 23 November 2003 13:47, Adriaan de Groot wrote: > ogg123 bus errors on me all the time, in code that looks perfectly > innocuous sprintf(data,"%05li:%05.2f",min,sec); > and i suspect it's because ogg123 links against both libc_r and libc: Duh, that's not a problem at all. However, sprintf() and fprintf() both have trouble printing double arguments from a thread that is not the main thread of control on amd64, as the attached little test program shows. I compile it on 5-CURRENT (well, from last week) with: beans.ebn.kun.nl$gcc -o threadtest t.c -pthread -- pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot If the door is ajar, can we fill it with door-jamb? --Boundary-00=_z5Lw/2I7qZkRQQX-- From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 01:29:07 2003 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 D7D1316A4CE for ; Mon, 24 Nov 2003 01:29:06 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id C381343FE0 for ; Mon, 24 Nov 2003 01:29:05 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5E7CF66C55; Mon, 24 Nov 2003 01:29:00 -0800 (PST) Date: Mon, 24 Nov 2003 01:29:00 -0800 From: Kris Kennaway To: Akinori MUSHA Message-ID: <20031124092900.GA12109@xor.obsecurity.org> References: <20031124002433.GB6264@xor.obsecurity.org> <86znemcf0m.knu@iDaemons.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <86znemcf0m.knu@iDaemons.org> User-Agent: Mutt/1.4.1i cc: amd64@FreeBSD.org cc: Kris Kennaway Subject: Re: ruby-1.8.1.p2 broken on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 09:29:08 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 24, 2003 at 06:06:01PM +0900, Akinori MUSHA wrote: > Hi, >=20 > At Sun, 23 Nov 2003 16:24:33 -0800, > kkenn wrote: > > http://bento.freebsd.org/errorlogs/amd64-5-latest/ruby-1.8.1.p2.log > >=20 > > Can you please investigate ASAP? >=20 > Hmm, I'm a bit confused. The substitute config.guess/sub (in > ports/Template/, which came with a newer autoconf) seem to recognoze > "amd64" and replace it with "x86_64", and as we don't have such a > thing as "x86_64" available from a port, there is no other way than > hardcoding s/amd64/x86_64/ blah blah blah to make packaging > (pkg-plist) work. >=20 > Now, do you know what is the canonical architecture name for the amd64 > platform? Did we diverge from GNU by adopting amd64, or is GNU just > behind us? I checked the just released autoconf 2.58, but the > situation did not seem to have changed. I don't remember..someone on the amd64 list (peter or David) should know. Kris --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/wc9bWry0BWjoQKURAoQ6AJ4p8Vjs10SAK4J/y/cUR3EPxiAyoQCglbq6 d7yOgRq4q/PEKgLlE1omjDE= =E0vI -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 03:04:25 2003 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 3BAF016A4CE for ; Mon, 24 Nov 2003 03:04:25 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E59D43FAF for ; Mon, 24 Nov 2003 03:04:24 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id hAOB4MvX051640; Mon, 24 Nov 2003 03:04:22 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id hAOB4Koh051639; Mon, 24 Nov 2003 03:04:20 -0800 (PST) (envelope-from obrien) Date: Mon, 24 Nov 2003 03:04:20 -0800 From: "David O'Brien" To: Kris Kennaway Message-ID: <20031124110420.GA51510@dragon.nuxi.com> References: <20031124002433.GB6264@xor.obsecurity.org> <86znemcf0m.knu@iDaemons.org> <20031124092900.GA12109@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031124092900.GA12109@xor.obsecurity.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-BETA Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Akinori MUSHA cc: amd64@FreeBSD.org Subject: Re: ruby-1.8.1.p2 broken on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 11:04:25 -0000 > > Now, do you know what is the canonical architecture name for the amd64 > > platform? Did we diverge from GNU by adopting amd64, or is GNU just > > behind us? I checked the just released autoconf 2.58, but the > > situation did not seem to have changed. AMD marketing refused to pick a name for a long time -- so "x86-64" was adopted by those doing the open source work. Right before Opteron launch, AMD marketing woke up and choose "AMD64" as the architecture name to follow Microsoft[1] and to make it clear who invented the technology when Intel follows AMD in the [near] future. I personally led the charge to get the misspelled "x86_64" changed to "amd64" in the open source world. Some followed (Debian and NetBSD), others were stubborn and said it too hard to change the few hundred users that existed at time -- SuSE and RedHat. So we're stuck with multiple names for the entire future of AMD64 due to those two players. Thus GNU autoconf accepts amd64-*-freebsd* as a configure target, but too many of the software packages don't know what to do with "amd64" so GNU autoconf silently changes it so "x86_64" at the moment. [1] then Microsoft turns face and calls the platform "64-bit Extended Systems" From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 03:47:54 2003 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 4260E16A4CE for ; Mon, 24 Nov 2003 03:47:54 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42C2E43F85 for ; Mon, 24 Nov 2003 03:47:53 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id hAOBlpvX060953; Mon, 24 Nov 2003 03:47:51 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id hAOBloTA060952; Mon, 24 Nov 2003 03:47:50 -0800 (PST) (envelope-from obrien) Date: Mon, 24 Nov 2003 03:47:50 -0800 From: "David O'Brien" To: Akinori MUSHA Message-ID: <20031124114750.GA60860@dragon.nuxi.com> References: <20031124002433.GB6264@xor.obsecurity.org> <86znemcf0m.knu@iDaemons.org> <20031124092900.GA12109@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031124092900.GA12109@xor.obsecurity.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-BETA Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org cc: Kris Kennaway Subject: Re: ruby-1.8.1.p2 broken on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 11:47:54 -0000 On Mon, Nov 24, 2003 at 01:29:00AM -0800, Kris Kennaway wrote: > On Mon, Nov 24, 2003 at 06:06:01PM +0900, Akinori MUSHA wrote: > > > http://bento.freebsd.org/errorlogs/amd64-5-latest/ruby-1.8.1.p2.log > > > Can you please investigate ASAP? > > > > Hmm, I'm a bit confused. The substitute config.guess/sub (in > > ports/Template/, which came with a newer autoconf) seem to recognoze > > "amd64" and replace it with "x86_64", and as we don't have such a > > thing as "x86_64" available from a port, there is no other way than > > hardcoding s/amd64/x86_64/ blah blah blah to make packaging > > (pkg-plist) work. The bug is in Mk/bsd.ruby.mk. It is bogusly clearing CONFIGURE_TARGET. At least for passing the --target GNU tuple to GNU autoconf. GNU software has always used a 3-TUPPLE: cpu, vender, OS. While - might be the proper tuple for Ruby itself, it isn't for GNU autoconf. Modern versions of GNU autoconf are a lot more strict about demanding a 3-tuple vs. 2-tuple than older versions. Setting RUBY_ARCH?=${ARCH}-portbld-freebsd${OSREL:C/\..*//}${RUBY_R} gets GNU autoconf to configure properly. The "-pc-" in "x86_64-pc-freebsd5" is a big warning GNU configure isn't being run correctly. From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 04:46:38 2003 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 BD5A616A4CE; Mon, 24 Nov 2003 04:46:38 -0800 (PST) Received: from mail.musha.org (daemon.musha.org [210.189.104.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7069543F93; Mon, 24 Nov 2003 04:46:35 -0800 (PST) (envelope-from knu@iDaemons.org) Received: from archon.local.idaemons.org (archon.local.idaemons.org [192.168.1.32]) by mail.musha.org (Postfix) with ESMTP id 67182ACD4; Mon, 24 Nov 2003 21:46:34 +0900 (JST) Date: Mon, 24 Nov 2003 21:46:34 +0900 Message-ID: <86wu9qc4t1.knu@iDaemons.org> From: "Akinori MUSHA" To: "David O'Brien" In-Reply-To: <20031124114750.GA60860@dragon.nuxi.com> References: <20031124002433.GB6264@xor.obsecurity.org> <86znemcf0m.knu@iDaemons.org> <20031124092900.GA12109@xor.obsecurity.org> <20031124114750.GA60860@dragon.nuxi.com> Organization: Associated I. Daemons X-PGP-Public-Key: finger knu@FreeBSD.org X-PGP-Fingerprint: 081D 099C 1705 861D 4B70 B04A 920B EFC7 9FD9 E1EE MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: Kris Kennaway Subject: Re: ruby-1.8.1.p2 broken on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 12:46:38 -0000 At Mon, 24 Nov 2003 03:47:50 -0800, o`brien wrote: > The bug is in Mk/bsd.ruby.mk. It is bogusly clearing CONFIGURE_TARGET. > At least for passing the --target GNU tuple to GNU autoconf. GNU > software has always used a 3-TUPPLE: cpu, vender, OS. While - > might be the proper tuple for Ruby itself, it isn't for GNU autoconf. > Modern versions of GNU autoconf are a lot more strict about demanding a > 3-tuple vs. 2-tuple than older versions. > > Setting RUBY_ARCH?=${ARCH}-portbld-freebsd${OSREL:C/\..*//}${RUBY_R} gets > GNU autoconf to configure properly. The "-pc-" in "x86_64-pc-freebsd5" is > a big warning GNU configure isn't being run correctly. Thanks for the hint. I remembered why I cleared CONFIGURE_TARGET and just fixed the problem. -- / /__ __ Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "It seems to me as we make our own few circles 'round the sun We get it backwards and our seven years go by like one" From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 04:50:44 2003 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 6EE6016A4CE; Mon, 24 Nov 2003 04:50:44 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-234.dsl.lsan03.pacbell.net [63.207.60.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E4BB43F93; Mon, 24 Nov 2003 04:50:43 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3DB9E66D1F; Mon, 24 Nov 2003 04:50:43 -0800 (PST) Date: Mon, 24 Nov 2003 04:50:43 -0800 From: Kris Kennaway To: Akinori MUSHA Message-ID: <20031124125043.GA16016@xor.obsecurity.org> References: <20031124002433.GB6264@xor.obsecurity.org> <86znemcf0m.knu@iDaemons.org> <20031124092900.GA12109@xor.obsecurity.org> <20031124114750.GA60860@dragon.nuxi.com> <86wu9qc4t1.knu@iDaemons.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <86wu9qc4t1.knu@iDaemons.org> User-Agent: Mutt/1.4.1i cc: freebsd-amd64@FreeBSD.org cc: David O'Brien cc: Kris Kennaway Subject: Re: ruby-1.8.1.p2 broken on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 12:50:44 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 24, 2003 at 09:46:34PM +0900, Akinori MUSHA wrote: > At Mon, 24 Nov 2003 03:47:50 -0800, > o`brien wrote: > > The bug is in Mk/bsd.ruby.mk. It is bogusly clearing CONFIGURE_TARGET. > > At least for passing the --target GNU tuple to GNU autoconf. GNU > > software has always used a 3-TUPPLE: cpu, vender, OS. While - > > might be the proper tuple for Ruby itself, it isn't for GNU autoconf. > > Modern versions of GNU autoconf are a lot more strict about demanding a > > 3-tuple vs. 2-tuple than older versions. > >=20 > > Setting RUBY_ARCH?=3D${ARCH}-portbld-freebsd${OSREL:C/\..*//}${RUBY_R} = gets > > GNU autoconf to configure properly. The "-pc-" in "x86_64-pc-freebsd5" = is > > a big warning GNU configure isn't being run correctly. >=20 > Thanks for the hint. I remembered why I cleared CONFIGURE_TARGET and > just fixed the problem. Thanks! Kris --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/wf6iWry0BWjoQKURAmskAJ9U3yaqQHlV8diVy/zREj+cl6jekgCbB/nf 0pImS0SOIM0IwF/qC6uXRzY= =5bdZ -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 09:27:50 2003 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 51F7316A4CF for ; Mon, 24 Nov 2003 09:27:50 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C620743F3F for ; Mon, 24 Nov 2003 09:27:48 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id hAOHRlvX064009; Mon, 24 Nov 2003 09:27:47 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id hAOHRjqw064008; Mon, 24 Nov 2003 09:27:45 -0800 (PST) (envelope-from obrien) Date: Mon, 24 Nov 2003 09:27:44 -0800 From: "David O'Brien" To: Akinori MUSHA Message-ID: <20031124172744.GA63983@dragon.nuxi.com> References: <20031124002433.GB6264@xor.obsecurity.org> <86znemcf0m.knu@iDaemons.org> <20031124092900.GA12109@xor.obsecurity.org> <20031124114750.GA60860@dragon.nuxi.com> <86wu9qc4t1.knu@iDaemons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86wu9qc4t1.knu@iDaemons.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-BETA Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org cc: Kris Kennaway Subject: Re: ruby-1.8.1.p2 broken on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 17:27:50 -0000 On Mon, Nov 24, 2003 at 09:46:34PM +0900, Akinori MUSHA wrote: > > Setting RUBY_ARCH?=${ARCH}-portbld-freebsd${OSREL:C/\..*//}${RUBY_R} gets > > GNU autoconf to configure properly. The "-pc-" in "x86_64-pc-freebsd5" is > > a big warning GNU configure isn't being run correctly. > > Thanks for the hint. I remembered why I cleared CONFIGURE_TARGET and > just fixed the problem. Cool! From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 11:10:20 2003 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 1456516A4CE for ; Mon, 24 Nov 2003 11:10:20 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C429043FE9 for ; Mon, 24 Nov 2003 11:10:17 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAOJAHFY062144 for ; Mon, 24 Nov 2003 11:10:17 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAOJAHZg062143; Mon, 24 Nov 2003 11:10:17 -0800 (PST) (envelope-from gnats) Resent-Date: Mon, 24 Nov 2003 11:10:17 -0800 (PST) Resent-Message-Id: <200311241910.hAOJAHZg062143@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, adriaan de groot Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5601216A4CE for ; Mon, 24 Nov 2003 11:09:07 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEF4C43F93 for ; Mon, 24 Nov 2003 11:09:03 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from localhost by pandora.cs.kun.nl id hAOJ8xd5013384 (8.12.10/3.58); Mon, 24 Nov 2003 20:09:01 +0100 (MET) Message-Id: <200311242008.55699.adridg@cs.kun.nl> Date: Mon, 24 Nov 2003 20:08:55 +0100 From: adriaan de groot To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: amd64/59650: sprintf() bus errors in non-main thread with %f X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: adriaan de groot List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 19:10:20 -0000 >Number: 59650 >Category: amd64 >Synopsis: sprintf() bus errors in non-main thread with %f >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 24 11:10:17 PST 2003 >Closed-Date: >Last-Modified: >Originator: adridg@cs.kun.nl >Release: FreeBSD 5.1-CURRENT amd64 >Organization: KDE-FreeBSD >Environment: System: FreeBSD beans.ebn.kun.nl 5.1-CURRENT FreeBSD 5.1-CURRENT #4: Wed Nov 19 14:11:35 CET 2003 root@beans.ebn.kun.nl:/mnt/sys/CURRENT/src/sys/amd64/compile/BEANS amd64 >Description: The ogg123 port bus errors on an amd64 machine. This is because sprintf() and fprintf() do "something weird" with %f arguments in threads that are not the main thread of control. >How-To-Repeat: This program demonstrates the problem: /* Demonstration program that shows that sprintf() doesn't work with double args from threads that aren't the main thread of control. */ #include #include #include void slipper(void *p) { fprintf(stderr,"[%lx] d=%d t=%d\n",(long)pthread_self(),3,time(NULL)); sleep(3); fprintf(stderr,"%f\n",22/7); fprintf(stderr,"%06.3f\n",0.002462390263402); } int main(int argc, char **argv) { pthread_t tid; slipper(NULL); pthread_create(&tid,NULL,slipper,NULL); sleep(6); slipper(NULL); return 0; } } Expected output is something like [lofi@lofi]:0:~ > ./threadtest [804c000] d=3 t=1069603991 0.000000 00.002 [804c400] d=3 t=1069603994 0.000000 00.002 [804c000] d=3 t=1069604000 0.000000 00.002 and on 4-STABLE i386, 5-CURRENT i386, and 5-CURRENT alpha, that is exactly what it does. On amd64, however, beans.ebn.kun.nl$./threadtest [504000] d=3 t=1069604372 0.000000 00.002 [504800] d=3 t=1069604375 0.000000 Bus error (core dumped) Note that the "plain" %f when printing a 0 value works, but that sprintf() bus errors in the second call. Replacing 22/7 by the constant 0.002462390263402 in the code causes a bus error in the first call to sprintf(). (gdb) bt #0 0x0000000200841189 in fprintf () from /lib/libc.so.5 #1 0x000000000040086f in slipper () #2 0x000000020063c670 in _thread_start () from /usr/lib/libc_r.so.5 Error accessing memory address 0x7fffffeff000: Bad address. Possibly relevant disassembly: 0x0000000200841181 : movaps %xmm2,0xffffffffffffffa1(%rax) 0x0000000200841185 : movaps %xmm1,0xffffffffffffff91(%rax) 0x0000000200841189 : movaps %xmm0,0xffffffffffffff81(%rax) 0x000000020084118d : mov %rsi,0xffffffffffffff40(%rbp) 0x0000000200841194 : movl $0x10,0xffffffffffffff10(%rbp) 0x000000020084119e : movl $0x30,0xffffffffffffff14(%rbp) (If it's gonna bus error, I'll suspect those odd constants in the three movaps instructions.) >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 12:10:28 2003 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 CCA8516A4CE; Mon, 24 Nov 2003 12:10:28 -0800 (PST) Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3113E43F75; Mon, 24 Nov 2003 12:10:27 -0800 (PST) (envelope-from adridg@cs.kun.nl) Received: from localhost by pandora.cs.kun.nl via odin.cs.kun.nl [131.174.33.33] with ESMTP id hAOKALd5023464 (8.12.10/3.58); Mon, 24 Nov 2003 21:10:22 +0100 (MET) From: Adriaan de Groot To: kde@freebsd.org, amd64@freebsd.org Date: Mon, 24 Nov 2003 20:59:19 +0100 User-Agent: KMail/1.5.93 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_XMmw/50/6/LrePe" Message-Id: <200311242059.19644.adridg@cs.kun.nl> cc: Kris Kennaway Subject: Re: [kde-freebsd] arts-1.1.4,1 broken on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 20:10:28 -0000 --Boundary-00=_XMmw/50/6/LrePe Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 24 November 2003 09:46, Adriaan de Groot wrote: > On Mon, 24 Nov 2003, Lauri Watts wrote: > > On Monday 24 November 2003 01.36, Kris Kennaway wrote: > > > http://bento.freebsd.org/errorlogs/amd64-5-latest/arts-1.1.4,1.log > > > > > > Can you please investigate ASAP? > Someone complained vaguely about this already on the amd64 list, but > didn't provide any specifics, also not after being prompted. > > > There's a patch added, orginally to make it build on amd64: > > patch-flow-gsl-gslglib.c > > FWIW, arts builds straight from CVS with no tweaks of any kind for me on > amd64. I'll try to grab the port today and see what it does when I get > home. My bad, it _didn't_ build from CVS without tweaks, I needed to define the correct form of G_VA_COPY for the amd64 (which uses the standard va_copy macro .. count on glib to suffer from NIH). I've attached two patches: 1) va.diff adds # define G_VA_COPY(ap1, ap2) va_copy(ap1,ap2) in relevant places. 2) stringcat.diff removes a bunch of G_STRLOCs from the code, since those expand to __FUNCTION__, and concatenating __FUNCTION__ with constant strings is deprecated. Kris, as usual I haven't the slightest idea as to how to get this into FBSD in a sensible fashion. Bug a committer about it. I'll push it into upstream CVS, though. I called them files/patch-flow-gsl-VA_COPY and files/patch-flow-gsl-gslglib.c-2 and it both configures and builds. -- pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot If the door is ajar, can we fill it with door-jamb? --Boundary-00=_XMmw/50/6/LrePe Content-Type: text/x-diff; charset="iso-8859-1"; name="stringcat.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="stringcat.diff" Index: flow/gsl/gslglib.c =================================================================== RCS file: /home/kde/arts/flow/gsl/gslglib.c,v retrieving revision 1.15.2.1 diff -u -3 -p -r1.15.2.1 gslglib.c --- flow/gsl/gslglib.c 12 Dec 2002 16:14:49 -0000 1.15.2.1 +++ flow/gsl/gslglib.c 24 Nov 2003 19:42:08 -0000 @@ -2057,7 +2057,7 @@ printf_string_upper_bound (const gchar * */ case '$': if (may_warn) - g_warning (G_STRLOC ": unable to handle positional parameters (%%n$)"); + g_warning (": unable to handle positional parameters (%%n$)"); len += 1024; /* try adding some safety padding */ break; @@ -2222,7 +2222,7 @@ printf_string_upper_bound (const gchar * /* n . dddddddddddddddddddddddd E +- eeee */ conv_len += 1 + 1 + MAX (24, spec.precision) + 1 + 1 + 4; if (may_warn && spec.mod_extra_long) - g_warning (G_STRLOC ": unable to handle long double, collecting double only"); + g_warning (": unable to handle long double, collecting double only"); #ifdef HAVE_LONG_DOUBLE #error need to implement special handling for long double #endif @@ -2265,7 +2265,7 @@ printf_string_upper_bound (const gchar * if (spec.mod_long) { if (may_warn) - g_warning (G_STRLOC": unable to handle wide char strings"); + g_warning (": unable to handle wide char strings"); len += 1024; /* try adding some safety padding */ } break; @@ -2296,7 +2296,7 @@ printf_string_upper_bound (const gchar * break; default: if (may_warn) - g_warning (G_STRLOC": unable to handle `%c' while parsing format", + g_warning (": unable to handle `%c' while parsing format", c); break; } --Boundary-00=_XMmw/50/6/LrePe Content-Type: text/x-diff; charset="iso-8859-1"; name="va.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="va.diff" Index: flow/gsl/gslglib.h =================================================================== RCS file: /home/kde/arts/flow/gsl/gslglib.h,v retrieving revision 1.20 diff -u -3 -p -r1.20 gslglib.h --- flow/gsl/gslglib.h 24 Sep 2002 18:55:16 -0000 1.20 +++ flow/gsl/gslglib.h 24 Nov 2003 19:41:45 -0000 @@ -513,6 +513,8 @@ gboolean g_path_is_absolute (const gchar # define G_VA_COPY(ap1, ap2) (*(ap1) = *(ap2)) # elif defined (G_VA_COPY_AS_ARRAY) # define G_VA_COPY(ap1, ap2) g_memmove ((ap1), (ap2), sizeof (va_list)) +# elif defined (va_copy) +# define G_VA_COPY(ap1, ap2) va_copy(ap1,ap2) # else /* va_list is a pointer */ # define G_VA_COPY(ap1, ap2) ((ap1) = (ap2)) # endif /* va_list is a pointer */ Index: mcop/debug.cc =================================================================== RCS file: /home/kde/arts/mcop/debug.cc,v retrieving revision 1.7.2.3 diff -u -3 -p -r1.7.2.3 debug.cc --- mcop/debug.cc 12 Dec 2002 16:17:37 -0000 1.7.2.3 +++ mcop/debug.cc 24 Nov 2003 19:41:46 -0000 @@ -385,6 +385,8 @@ typedef struct _GString GString; # define G_VA_COPY(ap1, ap2) (*(ap1) = *(ap2)) # elif defined (G_VA_COPY_AS_ARRAY) # define G_VA_COPY(ap1, ap2) g_memmove ((ap1), (ap2), sizeof (va_list)) +# elif defined (va_copy) +# define G_VA_COPY(ap1, ap2) va_copy(ap1,ap2) # else /* va_list is a pointer */ # define G_VA_COPY(ap1, ap2) ((ap1) = (ap2)) # endif /* va_list is a pointer */ --Boundary-00=_XMmw/50/6/LrePe-- From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 24 19:29:00 2003 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 EA9C116A4CE for ; Mon, 24 Nov 2003 19:29:00 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E831043F85 for ; Mon, 24 Nov 2003 19:28:59 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id hAP3Swo8023813 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 24 Nov 2003 21:28:58 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id hAP3Swg4023810; Mon, 24 Nov 2003 21:28:58 -0600 (CST) Date: Mon, 24 Nov 2003 21:28:58 -0600 (CST) Message-Id: <200311250328.hAP3Swg4023810@bigtex.jrv.org> From: James Van Artsdalen To: freebsd-amd64@freebsd.org Subject: disk controollers 2/ 64-bit addressing? 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, 25 Nov 2003 03:29:01 -0000 Are there any ATA or serial-ATA controllers that can address memory above 4 GB? In other words I'm hoping to avoid bounce-buffers with large memory configurations. I believe there are SCSI controllers that can do this but I'd rather stick to ATA or sATA for cost reasons. HighPoint has released the RocketRAID 1820, which is a serial-ATA PCI-X 64-bit 66/100/133 MHz controller with eight sATA ports. I have no idea if it can address memory above 4 GB not. From owner-freebsd-amd64@FreeBSD.ORG Tue Nov 25 23:33:46 2003 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 1B34F16A4CE for ; Tue, 25 Nov 2003 23:33:46 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C32A43FDD for ; Tue, 25 Nov 2003 23:33:45 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id hAQ7Xio8012679 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 26 Nov 2003 01:33:44 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id hAQ7XheT012676; Wed, 26 Nov 2003 01:33:43 -0600 (CST) Date: Wed, 26 Nov 2003 01:33:43 -0600 (CST) Message-Id: <200311260733.hAQ7XheT012676@bigtex.jrv.org> From: James Van Artsdalen To: freebsd-amd64@freebsd.org Subject: Re: disk controllers w/ 64-bit addressing? 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, 26 Nov 2003 07:33:46 -0000 This is not exactly an authoritative or complete answer from HighPoint, but it does suggest there's hope for an (relative to SCSI) economic means of a disk system that doesn't need bounce buffers. Does anyone in FreeBSD already have a contact at HighPoint or should I nag them to cough up a datasheet for whatever IC is used? The pictures show eight SATA ports and one control IC with no ATA-to-SATA adapter chips in sight, so this probably isn't one of the chips listed on their site but rather something new. Date: Wed, 26 Nov 2003 14:48:43 +0800 To: James Van Artsdalen From: "HighPoint Technologies Inc." Subject: Re: RocketRaid 1820 Dear Sir / Madam, Thanks for your contacting us! The current driver for RR1820 only can work on the 32-bit OS. If you use the 32bit OS on Opteron, RR1820 can work properly, for Memory Addressing, it is determined by the operating system directly. The 64bit-driver(Support 64bit OS) will support 64bit addressing, but it hasn't released yet. Regards, HighPoint Technologies Inc. At 04:13 2003-11-26, you wrote: >Is the datasheet on the controller for the 1820 available? > >Can the 1820 address memory above 4 GB (i.e., Opteron)? > >I can see that the 1820 does 64-bit data: the question is if it does >64-bit addresses too. From owner-freebsd-amd64@FreeBSD.ORG Wed Nov 26 05:30:25 2003 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 D76EA16A4CF for ; Wed, 26 Nov 2003 05:30:25 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3595643FDD for ; Wed, 26 Nov 2003 05:30:24 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAQDUNFY061787 for ; Wed, 26 Nov 2003 05:30:23 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAQDUNbg061786; Wed, 26 Nov 2003 05:30:23 -0800 (PST) (envelope-from gnats) Date: Wed, 26 Nov 2003 05:30:23 -0800 (PST) Message-Id: <200311261330.hAQDUNbg061786@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Adriaan de Groot Subject: Re: amd64/59650: passing float parameters in non-main threads bus errors X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Adriaan de Groot List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 13:30:26 -0000 The following reply was made to PR amd64/59650; it has been noted by GNATS. From: Adriaan de Groot To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: amd64/59650: passing float parameters in non-main threads bus errors Date: Wed, 26 Nov 2003 14:23:10 +0100 Some further debugging shows that it's not even sprintf() of va_start() specific, but just passing float / double arguments to a varargs function in a non-main thread of control triggers bus errors already: /* ** Demonstration program that float parameters to ** varargs functions in non-main threads of ** control on amd64 does not work properly. */ #include #include #include /* ** This is a varargs function to which we will attempt to pass ** a float value in the ... . */ int PrintF(int fd, const char *fmt, int i, ...) { int ret = 2; fprintf(stderr,"[%lx]B %d\n",(long)pthread_self(),fd); return ret; } /* ** Demonstration function. Expected output is something like ** ** [504000]B 0 ** [504000]B 1 ** [504000]B 2 ** [504000]B 3 ** ** From the 4 calls to PrintF(). This bus errors in the third ** call when not in the main thread of control. */ void *threadfunc(void *p) { PrintF(0,"hello",0,0); PrintF(1,"hello",0,6); PrintF(2,"hello",1,0.00028376223); /* arg4 is a float */ PrintF(3,"hello",0.00028376223,6); /* arg3 converts to int here */ return p; } int main(int argc, char **argv) { pthread_t tid; threadfunc(NULL); pthread_create(&tid,NULL,threadfunc,NULL); sleep(4); threadfunc(NULL); return 0; } Now, either I'm doing something totally moronic with threads (and the ogg123 port is too) or the argument passing is seriously broken. I might be compiling it wrong, though: beans.ebn.kun.nl$gcc -o threadtest -g v.c -lc_r && ./threadtest [504000]B 0 [504000]B 1 [504000]B 2 [504000]B 3 [504800]B 0 [504800]B 1 Bus error (core dumped) The machine has been updated in -CURRENT since the original bug report: FreeBSD beans.ebn.kun.nl 5.2-BETA FreeBSD 5.2-BETA #2: Sun Nov 23 19:48:43 CET 2003 root@beans.ebn.kun.nl:/usr/obj/mnt/sys/CURRENT/src/sys/BEANS amd64 -- pub 1024D/FEA2A3FE 2002-06-18 Adriaan de Groot If the door is ajar, can we fill it with door-jamb? From owner-freebsd-amd64@FreeBSD.ORG Wed Nov 26 07:40:22 2003 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 7EC0616A4CE for ; Wed, 26 Nov 2003 07:40:22 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D6343FE9 for ; Wed, 26 Nov 2003 07:40:17 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAQFeHFY082212 for ; Wed, 26 Nov 2003 07:40:17 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAQFeHGj082211; Wed, 26 Nov 2003 07:40:17 -0800 (PST) (envelope-from gnats) Resent-Date: Wed, 26 Nov 2003 07:40:17 -0800 (PST) Resent-Message-Id: <200311261540.hAQFeHGj082211@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 833BD16A4CF for ; Wed, 26 Nov 2003 07:38:21 -0800 (PST) Received: from da.mailomat.net (mailomat.net [212.185.46.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A83243FBD for ; Wed, 26 Nov 2003 07:38:17 -0800 (PST) (envelope-from roemer@wetteronline.de) Received: This line has been intentionally left blank. Received: from prozess-8.wetteronline.weblan (terminix.wetteronline.de [131.220.99.21])hAQFabA7061518 for ; Wed, 26 Nov 2003 16:36:38 +0100 (CET) (envelope-from roemer@wetteronline.de) Received: from prozess-8.wetteronline.weblan (localhost [127.0.0.1]) hAQAvwiZ000849 for ; Wed, 26 Nov 2003 11:57:58 +0100 (CET) (envelope-from roemer@prozess-8.wetteronline.weblan) Received: (from roemer@localhost)hAQAvwlD000848; Wed, 26 Nov 2003 11:57:58 +0100 (CET) (envelope-from roemer) Message-Id: <200311261057.hAQAvwlD000848@prozess-8.wetteronline.weblan> Date: Wed, 26 Nov 2003 11:57:58 +0100 (CET) From: To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: amd64/59713: X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: roemer.ulrich@gmx.de List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 15:40:22 -0000 >Number: 59713 >Category: amd64 >Synopsis: >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Nov 26 07:40:16 PST 2003 >Closed-Date: >Last-Modified: >Originator: Ulrich Roemer >Release: FreeBSD 5.2-BETA amd64 >Organization: >Environment: System: FreeBSD prozess-8.wetteronline.weblan 5.2-BETA FreeBSD 5.2-BETA #12: Wed Nov 26 11:29:21 CET 2003 root@prozess-8.wetteronline.weblan:/space/obj/space/src/sys/WASWEISSICH.cfg amd64 >Description: amd64 Hello, I have a problem since 1-2 week with the new kernel 5.1 and now 5.2 This is the info in the message file: kernel: ad0: WARNING - WRITE_DMA recovered from missing interrupt su: roemer to root on /dev/ttyp2 kernel: fxp0: device timeout kernel: fxp0: device timeout kernel: arp: unknown hardware address format (0x4500) kernel: arp: unknown hardware address format (0x4500) This is the dmesg.boot Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-BETA #12: Wed Nov 26 11:29:21 CET 2003 root@prozess-8.wetteronline.weblan:/space/obj/space/src/sys/WASWEISSICH.cfg Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff805fd000. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) 64 Processor 240 (1400.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf51 Stepping = 1 Features=0x78bfbff AMD Features=0xe0500000 real memory = 1072955392 (1023 MB) avail memory = 1012191232 (965 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 ACPI-0226: *** Error: Return object type is incorrect [\\_SB_.LATA._CRS] (Node 0xffffff00008cc780), AE_TYPE can't fetch resources for \\_SB_.LATA - AE_TYPE acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 2 INTA is routed to irq 7 pcib0: slot 2 INTB is routed to irq 5 pcib0: slot 2 INTC is routed to irq 10 pcib0: slot 5 INTA is routed to irq 11 pcib0: slot 6 INTA is routed to irq 11 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pci0: at device 5.0 (no driver attached) pcm0: port 0xec00-0xec7f,0xe800-0xe8ff mem 0xfebfb000-0xfebfbfff irq 11 at device 6.0 on pci0 pcm0: atapci0: port 0xffa0-0xffaf at device 8.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pcib1: at device 10.0 on pci0 pci1: on pcib1 pcib1: slot 4 INTA is routed to irq 5 pcib1: slot 5 INTA is routed to irq 11 pcib1: slot 8 INTA is routed to irq 11 pcib1: slot 9 INTA is routed to irq 11 rl0: port 0xd800-0xd8ff mem 0xfc9ffc00-0xfc9ffcff irq 5 at device 4.0 on pci1 rl0: Ethernet address: 00:50:bf:90:fd:b0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: port 0xdf00-0xdf3f mem 0xfc9c0000-0xfc9dffff,0xfc9fe000-0xfc9fefff irq 11 at device 5.0 on pci1 fxp0: Ethernet address 00:02:b3:8d:e5:5d miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0xdc00-0xdc7f,0xdfa0-0xdfaf,0xde80-0xdebf mem 0xfc980000-0xfc99ffff,0xfc9fd000-0xfc9fdfff irq 11 at device 8.0 on pci1 atapci1: [MPSAFE] ata2: at 0xfc9fd000 on atapci1 ata2: [MPSAFE] ata3: at 0xfc9fd000 on atapci1 ata3: [MPSAFE] ata4: at 0xfc9fd000 on atapci1 ata4: [MPSAFE] pci1: at device 9.0 (no driver attached) pcib2: at device 11.0 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND pci2: on pcib2 pci2: at device 0.0 (no driver attached) acpi_button0: on acpi0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 ACPI-0226: *** Error: Return object type is incorrect [\\_SB_.LATA._CRS] (Node 0xffffff00008cc780), AE_TYPE can't fetch resources for \\_SB_.LATA - AE_TYPE acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 2 INTA is routed to irq 7 pcib0: slot 2 INTB is routed to irq 5 pcib0: slot 2 INTC is routed to irq 10 pcib0: slot 5 INTA is routed to irq 11 pcib0: slot 6 INTA is routed to irq 11 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pci0: at device 5.0 (no driver attached) pcm0: port 0xec00-0xec7f,0xe800-0xe8ff mem 0xfebfb000-0xfebfbfff irq 11 at device 6.0 on pci0 pcm0: atapci0: port 0xffa0-0xffaf at device 8.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pcib1: at device 10.0 on pci0 pci1: on pcib1 pcib1: slot 4 INTA is routed to irq 5 pcib1: slot 5 INTA is routed to irq 11 pcib1: slot 8 INTA is routed to irq 11 pcib1: slot 9 INTA is routed to irq 11 rl0: port 0xd800-0xd8ff mem 0xfc9ffc00-0xfc9ffcff irq 5 at device 4.0 on pci1 rl0: Ethernet address: 00:50:bf:90:fd:b0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: port 0xdf00-0xdf3f mem 0xfc9c0000-0xfc9dffff,0xfc9fe000-0xfc9fefff irq 11 at device 5.0 on pci1 fxp0: Ethernet address 00:02:b3:8d:e5:5d miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0xdc00-0xdc7f,0xdfa0-0xdfaf,0xde80-0xdebf mem 0xfc980000-0xfc99ffff,0xfc9fd000-0xfc9fdfff irq 11 at device 8.0 on pci1 atapci1: [MPSAFE] ata2: at 0xfc9fd000 on atapci1 ata2: [MPSAFE] ata3: at 0xfc9fd000 on atapci1 ata3: [MPSAFE] ata4: at 0xfc9fd000 on atapci1 ata4: [MPSAFE] pci1: at device 9.0 (no driver attached) pcib2: at device 11.0 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND pci2: on pcib2 pci2: at device 0.0 (no driver attached) acpi_button0: on acpi0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: