From owner-freebsd-current@FreeBSD.ORG Sun May 25 00:48:27 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF6AE37B401; Sun, 25 May 2003 00:48:27 -0700 (PDT) Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D8F43FA3; Sun, 25 May 2003 00:48:25 -0700 (PDT) (envelope-from joshua@shallow.net) Received: by yello.shallow.net (Postfix, from userid 1001) id C770A2A99; Sun, 25 May 2003 17:48:23 +1000 (EST) Date: Sun, 25 May 2003 17:48:23 +1000 From: Joshua Goodall To: Ruslan Ermilov Message-ID: <20030525074823.GK91207@roughtrade.net> References: <20030523203517.GA93787@attbi.com> <20030524034419.GA63643@sunbay.com> <20030524084432.GA509@roughtrade.net> <20030524174817.GA42456@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030524174817.GA42456@sunbay.com> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org Subject: Re: Updating -CURRENT, what about outdated files? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 07:48:28 -0000 On Sat, May 24, 2003 at 08:48:17PM +0300, Ruslan Ermilov wrote: > On Sat, May 24, 2003 at 06:44:32PM +1000, Joshua Goodall wrote: > > On Sat, May 24, 2003 at 06:44:19AM +0300, Ruslan Ermilov wrote: > > > I do this a lot too. And I use "find . -mtime +1 ! -type d" to > > > seek for the stale stuff. This of course requires that you're > > > not running with ``INSTALL="install -C"'' in /etc/make.conf. > > > > Is there any part of installworld that uses tools other than > > rm, mtree, install and ln? > > > Sure, a lot of. We use all tools that are copied into the > ${INSTALLTMP} as the first step of installworld. I must correct myself. I should have written "Is there any part of installworld where files/dirs/links are installed using tools other than ..." Actually the total list seems really short to me; [ awk cat chflags chmod chown date echo egrep find grep ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl test true uname wc zic I can think of three methods; i) a simple wrapper that attempts to parse the subset of invocations used by installworld, and maintain a log, ii) an LD_PRELOAD-based wrapper, taking advantage of recent dynamic linkage changes, iii) building installation editions of those tools, so that they maintain a log of activity. Obviously not all are attractive. > Some files are only installed if the destination does not yet > exist, and there you are going to have a problem with this > approarch. Either way, the file exists. I wasn't looking for anything more sophisticated than that in a first pass at this. Other than the general case of using install -C, can you point out any specific examples? I thought that was the point of mergemaster; to manage elements of the distribution where simply overwriting would be inappropriate. J -- Joshua Goodall "tea makes itself" joshua@roughtrade.net - Ana Susanj From owner-freebsd-current@FreeBSD.ORG Sun May 25 01:43:57 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F56737B401 for ; Sun, 25 May 2003 01:43:57 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B72143F3F for ; Sun, 25 May 2003 01:43:54 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h4P8hiEd027241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 May 2003 11:43:44 +0300 (EEST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h4P8hiA9027236; Sun, 25 May 2003 11:43:44 +0300 (EEST) (envelope-from ru) Date: Sun, 25 May 2003 11:43:44 +0300 From: Ruslan Ermilov To: Joshua Goodall Message-ID: <20030525084344.GA26791@sunbay.com> References: <20030523203517.GA93787@attbi.com> <20030524034419.GA63643@sunbay.com> <20030524084432.GA509@roughtrade.net> <20030524174817.GA42456@sunbay.com> <20030525074823.GK91207@roughtrade.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <20030525074823.GK91207@roughtrade.net> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org Subject: Re: Updating -CURRENT, what about outdated files? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 08:43:57 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 25, 2003 at 05:48:23PM +1000, Joshua Goodall wrote: > On Sat, May 24, 2003 at 08:48:17PM +0300, Ruslan Ermilov wrote: > > On Sat, May 24, 2003 at 06:44:32PM +1000, Joshua Goodall wrote: > > > On Sat, May 24, 2003 at 06:44:19AM +0300, Ruslan Ermilov wrote: > > > > I do this a lot too. And I use "find . -mtime +1 ! -type d" to > > > > seek for the stale stuff. This of course requires that you're > > > > not running with ``INSTALL=3D"install -C"'' in /etc/make.conf. > > >=20 > > > Is there any part of installworld that uses tools other than > > > rm, mtree, install and ln? > > >=20 > > Sure, a lot of. We use all tools that are copied into the > > ${INSTALLTMP} as the first step of installworld. >=20 > I must correct myself. >=20 > I should have written "Is there any part of installworld where > files/dirs/links are installed using tools other than ..." >=20 > Actually the total list seems really short to me; >=20 > [ awk cat chflags chmod chown date echo egrep find grep > ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl > test true uname wc zic >=20 Bear in mind the conditionals of make(1) and sh(1)? > I can think of three methods; >=20 > i) a simple wrapper that attempts to parse the subset of > invocations used by installworld, and maintain a log, > ii) an LD_PRELOAD-based wrapper, taking advantage of recent > dynamic linkage changes, > iii) building installation editions of those tools, so that they=20 > maintain a log of activity. >=20 > Obviously not all are attractive. >=20 > > Some files are only installed if the destination does not yet > > exist, and there you are going to have a problem with this > > approarch. >=20 > Either way, the file exists. I wasn't looking for anything more > sophisticated than that in a first pass at this. >=20 But you don't often know if installworld attemps to install it or not, if it wasn't here: src/sys/boot/i386/loader/Makefile: beforeinstall: =2E.. =2Eif !exists(${DESTDIR}/boot/loader.rc) ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ ${.CURDIR}/../../forth/loader.rc ${DESTDIR}/boot =2Eendif > Other than the general case of using install -C, can you > point out any specific examples? I thought that was the point > of mergemaster; to manage elements of the distribution where > simply overwriting would be inappropriate. >=20 Nope, mergemaster(8) deals with updating of /etc only, unless I'm horribly mistaken (I don't use it personally, but pretty much do what it does manually). Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+0IJAUkv4P6juNwoRAkOpAJ4xofx5b7T2dq6yp/12Q/X0fViEhQCcDS3x g7PJor9YaOm1pDzzAjlX/Cs= =3Egf -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Sun May 25 03:06:04 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42F0B37B401; Sun, 25 May 2003 03:06:02 -0700 (PDT) Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4147D43FA3; Sun, 25 May 2003 03:06:01 -0700 (PDT) (envelope-from joshua@shallow.net) Received: by yello.shallow.net (Postfix, from userid 1001) id C740A29BA; Sun, 25 May 2003 20:05:59 +1000 (EST) Date: Sun, 25 May 2003 20:05:59 +1000 From: Joshua Goodall To: Ruslan Ermilov Message-ID: <20030525100559.GL91207@roughtrade.net> References: <20030523203517.GA93787@attbi.com> <20030524034419.GA63643@sunbay.com> <20030524084432.GA509@roughtrade.net> <20030524174817.GA42456@sunbay.com> <20030525074823.GK91207@roughtrade.net> <20030525084344.GA26791@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030525084344.GA26791@sunbay.com> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org Subject: Re: Updating -CURRENT, what about outdated files? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 10:06:05 -0000 On Sun, May 25, 2003 at 11:43:44AM +0300, Ruslan Ermilov wrote: > Bear in mind the conditionals of make(1) and sh(1)? Neither of which install files. I hope ;) > But you don't often know if installworld attemps to install it > or not, if it wasn't here: > > src/sys/boot/i386/loader/Makefile: > > beforeinstall: > ... > .if !exists(${DESTDIR}/boot/loader.rc) > ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ > ${.CURDIR}/../../forth/loader.rc ${DESTDIR}/boot > .endif > > > Other than the general case of using install -C, can you > > point out any specific examples? I thought that was the point > > of mergemaster; to manage elements of the distribution where > > simply overwriting would be inappropriate. > Nope, mergemaster(8) deals with updating of /etc only, unless > I'm horribly mistaken (I don't use it personally, but pretty > much do what it does manually). What you just said implies that installing world+kernel, then running mergemaster, does not update every part of a FreeBSD base system installation, modulo ports and make.conf knobs. I knew that already about /stand. I didn't realise it extended elsewhere. Perhaps because I lack install-fu. I confess that my Astonishment meter just twitched a little. Any reason why /boot/loader.rc *shouldn't* be under mergemaster control? At any rate, I'd expect to catch-and-document special cases, if only through a find-and-diff. I might just have a crack at this during the week. I have a deep sense of it being needed. Joshua -- Joshua Goodall "tea makes itself" joshua@roughtrade.net - Ana Susanj From owner-freebsd-current@FreeBSD.ORG Sun May 25 03:32:39 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4E1E37B408 for ; Sun, 25 May 2003 03:32:39 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD2F43FAF for ; Sun, 25 May 2003 03:32:39 -0700 (PDT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h4PAWc3q081263; Sun, 25 May 2003 06:32:38 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sun, 25 May 2003 06:32:38 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: current@FreeBSD.ORG Message-ID: <20030525061524.H30007@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Bang Jun-Young Subject: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 10:32:40 -0000 I've implemented per-executable ELF prebinding: ftp://ftp.jurai.net/users/winter/patches/prebind.patch Initial performance measurements are very encouraging. I originally ported the work that Bang Jun-Young (junyoung@netbsd.org) did for NetBSD (RelCache. See ftp://ftp.netbsd.org/pub/NetBSD/misc/junyoung) but found that there were too many problems to work around and that the cache file size made it impractical. This patch requires toolchain changes (included) to allow the linker to add a 'BUILDID' section to each library and executable. This section allows the prebinding file to be validated. There are only two assumptions this implementation makes: 1. The number of libraries does not change. 2. The order of libraries does not change. (This means that the prebinding file will be invalidated if LD_PRELOAD is used or if a new dependency is introduced via a shared library etc.) Solving these will require further kernel support (similar to OS X in some respects). There are a few more changes I need to make, and documentation to write, as well some testing and performance measurements. I should also note that these changes are x86 only at this point. Comments welcome. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | From owner-freebsd-current@FreeBSD.ORG Sun May 25 05:45:04 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CF5337B401; Sun, 25 May 2003 05:45:04 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725CA43FE0; Sun, 25 May 2003 05:45:02 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 7F28B530E; Sun, 25 May 2003 14:44:59 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Matthew N. Dodd" References: <20030525061524.H30007@sasami.jurai.net> From: Dag-Erling Smorgrav Date: Sun, 25 May 2003 14:44:59 +0200 In-Reply-To: <20030525061524.H30007@sasami.jurai.net> (Matthew N. Dodd's message of "Sun, 25 May 2003 06:32:38 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Bang Jun-Young cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 12:45:04 -0000 "Matthew N. Dodd" writes: > I've implemented per-executable ELF prebinding: Could you explain briefly what prebinding does? DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-current@FreeBSD.ORG Sun May 25 06:00:49 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20F7E37B401 for ; Sun, 25 May 2003 06:00:49 -0700 (PDT) Received: from staszic.eu.org (hood.1lo.lublin.pl [212.182.71.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B50743F75 for ; Sun, 25 May 2003 06:00:48 -0700 (PDT) (envelope-from koper@staszic.eu.org) Received: by staszic.eu.org (Postfix, from userid 1001) id DB7311A5A; Sun, 25 May 2003 15:00:51 +0200 (CEST) Date: Sun, 25 May 2003 15:00:50 +0200 From: Piotr Koper To: freebsd-current@freebsd.org Message-ID: <20030525130050.GM51404@staszic.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Broken Boot Manager instalator ?! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 13:00:49 -0000 Hi, I've just recovered from .. FreeBSD-Current installation on my computer. I used to have Win98 on the first partition and FreeBSD on the second. After successful installation FBSD-5.1-BETA everything was OK but booting Windows from the first partition. Boot sector on this partition was overwritten. Piotr Koper From owner-freebsd-current@FreeBSD.ORG Sun May 25 06:00:56 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54FA137B401; Sun, 25 May 2003 06:00:56 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3924C43F75; Sun, 25 May 2003 06:00:55 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4PD0EOn056706; Sun, 25 May 2003 09:00:14 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: (from robert@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) id h4PD0EuN056705; Sun, 25 May 2003 09:00:14 -0400 (EDT) (envelope-from robert) Date: Sun, 25 May 2003 09:00:14 -0400 (EDT) Message-Id: <200305251300.h4PD0EuN056705@fledge.watson.org> From: Robert Watson To: current@FreeBSD.org Subject: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: re@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 13:00:56 -0000 This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail re@FreeBSD.org. Must Resolve Issues for 5.1-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-------------------+-------------+---------------+----------------------| | | | | There are reports of | | | | | alignment problems | | ipfw/ipfw2 | | | with ipfw and/or | | alignment issues | In progress | Luigi Rizzo | ipfw2 on 64-bit | | on alpha/sparc64 | | | platforms | | | | | (specifically alpha | | | | | and sparc64). | |-------------------+-------------+---------------+----------------------| | | | | Kris Kennaway | | | | | reports high | | | | | instability of | | | | | 5.0-CURRENT on ia64 | | ia64 stability | -- | -- | machines, such as | | | | | the pluto* machines. | | | | | These problems need | | | | | to be fixed in order | | | | | to get a successful | | | | | package build. | |-------------------+-------------+---------------+----------------------| | | | | Brian Feldman has | | | | | submitted patches to | | | | | improve the | | | | | consistency of the | | | | | pathnames passed | | MAC Framework | | | into the MAC | | devfs path fixes | In progress | Robert Watson | Framework devfs | | | | | labeling entry | | | | | points. These | | | | | patches need to be | | | | | thoroughly reviewed | | | | | and tested, then | | | | | merged. | |-------------------+-------------+---------------+----------------------| | | | | If a network device | | | | | driver, possibly any | | Panic on | | | driver, is linked | | load/unload a | | | into the kernel and | | kernel module for | Patch | Maxime | then loaded and | | a driver already | submitted | Henrion | unloaded as a | | statically linked | | | module, the kernel | | into the kernel. | | | will panic. This has | | | | | been observed with | | | | | both if_dc and | | | | | if_fxp. | |-------------------+-------------+---------------+----------------------| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for the | | | | | i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake | make KSE available | | sparc64, alpha, | -- | Burkholder, | on non-i386 | | ia64 | | --, -- | platforms for | | | | | 5.1-RELEASE so that | | | | | KSE can see more | | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-------------------+-------------+---------------+----------------------| | | | | Update the run-time | | rtld-elf | -- | Alexander | link editor (rtld) | | thread-safety | | Kabaev | thread-safe with | | | | | libpthread. | |-------------------+-------------+---------------+----------------------| | | | | rpc.lockd(8) | | | | | client-side and | | | | | server-side NFS | | | | | locking appears to | | | | | have a number of | | | | | serious bugs which | | rpc.lockd(8) | | | prevent NFS locking | | stability | In progress | Robert Watson | from working | | | | | properly in a number | | | | | of common scenarios. | | | | | These bugs must be | | | | | resolved to ship | | | | | 5.1-RELEASE. Work is | | | | | underway to classify | | | | | and track the bugs. | |-------------------+-------------+---------------+----------------------| | | | | There have been | | | | | reports of | | | | | memory/data | | | | | corruption on some | | | | | systems; one working | | | | | hypothesis is that | | | | | this corresponds to | | | | | an undocumented bug | | | | | in a particular line | | | | | of Intel and AMD | | data corruption | | Peter Wemm, | processors, but it's | | reports | In progress | Bosko Milekic | unclear whether | | | | | current work-arounds | | | | | are correcting or | | | | | masking the problem. | | | | | Patches are being | | | | | circulated to test | | | | | this hypothesis, but | | | | | developers are | | | | | encouraged to be on | | | | | the lookout for | | | | | possible data | | | | | corruption bugs. | +------------------------------------------------------------------------+ Desired Features for 5.1-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |---------------+-------------+----------------+-------------------------| | | | | ia64 serial console | | | | | support is reported to | | | | | not be functional on HP | | ia64 sio | | Marcel | Itanium2 platforms. A | | support | In progress | Moolenaar, | reworking of the sio | | | | Warner Losh | driver to improve | | | | | platform independence | | | | | and bus handling is | | | | | likely needed. | |---------------+-------------+----------------+-------------------------| | | | | A.out support in the | | a.out | | | base system was | | toolchain | -- | -- | reduced; the removed | | port | | | build chain components | | | | | should be made into a | | | | | port. | |---------------+-------------+----------------+-------------------------| | | | | Truss appears to | | | | | contain a race | | | | | condition during the | | | | | start-up of debugging, | | | | | which can result in | | | | | truss failing to attach | | | | | to the process before | | | | | it exits. The symptom | | | | | is that truss reports | | | | | that it cannot open the | | | | | procfs node supporting | | | | | the process being | | Race | | | debugged. A bug also | | conditions in | Errata | Robert Drehmel | appears to exist where | | truss | candidate | | in truss will hang if | | | | | execve() returns | | | | | ENOENT. A further race | | | | | appears to exist in | | | | | which truss will return | | | | | "PIOCWAIT: Input/output | | | | | error" occasionally on | | | | | startup. The fix for | | | | | this sufficiently | | | | | changes process | | | | | execution handling that | | | | | we will defer the fix | | | | | to post-5.0 and | | | | | consider this errata. | |---------------+-------------+----------------+-------------------------| | | | | Kris Kennaway reports | | | | | deadlocks involving the | | | | | use of nullfs in the | | | | | bento environment: | | | | | buildworld -j4 with src | | | | | and obj mounted via | | nullfs | -- | -- | nullfs; the gcc | | deadlocks | | | processes eventually | | | | | deadlocked in the ufs | | | | | state. DDB traceback | | | | | showed two different | | | | | codepaths. I've just | | | | | repeated this, so the | | | | | bug still exists. | |---------------+-------------+----------------+-------------------------| | | | | If amd(8) does mount | | | | | more than one fs from a | | | | | host, the second call | | | | | to mountd on the server | | | | | gets aborted even if | | | | | the read does return | | | | | EAGAIN. This is | | | | | definitly a bug in the | | | | | nonblocking rpc code. | | amd/mountd | In progress | Martin Blapp | If truss or ktrace is | | bugs | | | attached on mountd, the | | | | | bug happens almost all | | | | | times, else 3-10 times | | | | | of 10 trys. Since there | | | | | have been several | | | | | reports of amd | | | | | irregularity on | | | | | 5.1-BETA, it's | | | | | important to get this | | | | | fixed for the release. | |---------------+-------------+----------------+-------------------------| | gdb -k | | | gdb -k doesn't work on | | doesn't work | -- | Mark Peek | alpha | | on alpha | | | | +------------------------------------------------------------------------+ Documentation items that must be resolved for 5.1 +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-----------------+-------------+--------------+-------------------------| | | | | As BUSDMA is now the | | | | | required driver API for | | | | | DMA access in hardware | | | | | device drivers as of | | | | | 5.1-RELEASE, we need to | | busdma man page | In progress | Hiten Pandya | make sure it's properly | | | | | documented. A man page | | | | | is in progress and | | | | | needs to be | | | | | appropriately reviewed | | | | | and committed prior to | | | | | the release. | |-----------------+-------------+--------------+-------------------------| | | | | rcNG is now the | | | | | supported (and only) | | | | | boot scripting | | rcNG | | | mechanism in 5.x, but | | documentation | In progress | Tom Rhodes | it's not currently | | | | | documented in the | | | | | handbook. We need this | | | | | documentation for | | | | | 5.1-RELEASE. | +------------------------------------------------------------------------+ Areas requiring immediate testing +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-------------------+--------+---------------+---------------------------| | | | | The 20030228 vendor | | Fresh ACPI-CA | -- | -- | sources have been | | import | | | imported. Further testing | | | | | is appreciated. | |-------------------+--------+---------------+---------------------------| | | | | PAE support allows the | | | | | use of up to 64GB of RAM | | PAE support for | -- | -- | on Pentium Pro and above | | i386 | | | systems. Virtual | | | | | addresses are still | | | | | constrained to 32-bits. | |-------------------+--------+---------------+---------------------------| | | | | The recently upgraded | | | | | if_wi driver is more | | | | | tuned to Prism hardware | | | | | than to Lucent hardware, | | if_wi problems on | | | resulting in system | | Lucent hardware | -- | -- | lockups and poor | | | | | performance when using | | | | | Lucent hardware. These | | | | | problems are believed to | | | | | be fixed but more testing | | | | | is welcome. | |-------------------+--------+---------------+---------------------------| | | | | For 5.1-RELEASE, the | | | | | default file system type | | | | | for newly created file | | | | | systems is UFS2 rather | | UFS2 as | | | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default | | | updated to use this new | | | | | default. Testing to make | | | | | sure all goes well after | | | | | the change (committed on | | | | | April 20, 2003) is vital. | |-------------------+--------+---------------+---------------------------| | | | | Support for pluggable | | | | | directory services using | | | | | NSS, including | | | | | adaptations of current | | | | Jacques | directory services (local | | NSSwitch support | -- | Vidrine | databases, NIS), and | | | | | support for new services | | | | | (LDAP, Active Directory, | | | | | etc). This change has | | | | | been committed, and | | | | | requires broader testing. | |-------------------+--------+---------------+---------------------------| | | | | Kris Kennaway reports | | | | | that he has seen several | | | | | unique panics on the | | Spurious alpha | | | alpha machines, but since | | panics | -- | -- | gdb -k doesn't work on | | | | | alpha I haven't been able | | | | | to get more than a DDB | | | | | traceback. No-one has | | | | | looked into them. | +------------------------------------------------------------------------+ ---------------------------------------------------------------------- freebsd-qa@FreeBSD.ORG Copyright (c) 1995-2003 The FreeBSD Project. All rights reserved. Last modified: 2003/05/23 22:39:47 From owner-freebsd-current@FreeBSD.ORG Sun May 25 06:03:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7F5A37B401 for ; Sun, 25 May 2003 06:03:25 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 060FC43F93 for ; Sun, 25 May 2003 06:03:25 -0700 (PDT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h4PD3O3q085047; Sun, 25 May 2003 09:03:24 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sun, 25 May 2003 09:03:24 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Dag-Erling Smorgrav In-Reply-To: Message-ID: <20030525084629.R30007@sasami.jurai.net> References: <20030525061524.H30007@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Bang Jun-Young cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 13:03:26 -0000 On Sun, 25 May 2003, Dag-Erling Smorgrav wrote: > "Matthew N. Dodd" writes: > > I've implemented per-executable ELF prebinding: > > Could you explain briefly what prebinding does? (This isn't as brief as you or I hoped I suspect.) Relocatable objects (executables and libraries) contain elements that require relocation before the are usable. In some cases this relocation requires symbols to be located and resolved. Resolving these symbols and performing the lookups imposes some execution overhead. By 'prebinding' we can do as much of this work beforehand and speed up the actual relocation process. The short answer is that things like KDE and other library happy executables take a little less time to load. Consider this program: # cat test.c int main (int argc, char *argv[]) { return (0); } # cc -o test test.c # ldd test test: libc.so.5 => /usr/lib/libc.so.5 (0x28076000) ... Using a simple execloop (1000 iterations) and time(1): normal: 0.734u 4.395s 0:07.55 67.8% 13+163k 0+0io 0pf+0w prebind: 0.396u 3.777s 0:05.26 79.0% 16+173k 0+0io 0pf+0w static: 0.000u 0.663s 0:01.06 62.2% 56+186k 0+0io 0pf+0w Now lets link test.c with lots of useless libraries: # cc -Wall -o test test.c -lalias -lasn1 -latm -lbsdxml -lbz2 -lc -lc_r -lcalendar -lcam -lcom_err -lcrypt -lcrypto -ldevinfo -ldevstat -ldialog -ledit -lfetch -lform -lftpio -lg2c -lgeom -lgnuregex -lhistory -lipsec -lipx -lisc -lm -lmd -lmenu -lmilter -lmp -lncp -lncurses -lnetgraph -lopie -lpam -lpanel -lpcap -lradius -lreadline -lroken -lrpcsvc -lsbuf -lsmb -lssh -lssl -lstdc++ -ltacplus -lufs -lugidfw -lusbhid -lutil -lvgl -lwrap -lxpg4 -lypclnt -lz -lkvm (We'll run execloop with only 100 iterations) normal: 14.003u 4.263s 0:23.14 78.9% 5+174k 0+0io 0pf+0w prebind: 1.108u 3.231s 0:05.46 79.3% 6+182k 0+0io 0pf+0w static: 0.000u 0.062s 0:00.15 40.0% 66+229k 0+0io 0pf+0w This is just a quick and dirty example mind you; I should really run things with 10000 iterations and make execloop do its own timing statistics etc. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | From owner-freebsd-current@FreeBSD.ORG Sun May 25 07:32:27 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AA9737B401 for ; Sun, 25 May 2003 07:32:27 -0700 (PDT) Received: from hotmail.com (bay8-f86.bay8.hotmail.com [64.4.27.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC7ED43F3F for ; Sun, 25 May 2003 07:32:26 -0700 (PDT) (envelope-from freebsd_stable@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 25 May 2003 07:32:26 -0700 Received: from 218.102.185.139 by by8fd.bay8.hotmail.msn.com with HTTP; Sun, 25 May 2003 14:32:26 GMT X-Originating-IP: [218.102.185.139] X-Originating-Email: [freebsd_stable@hotmail.com] From: "nobody nobody" To: mykroft@explosive.mail.net, david@catwhisker.org Date: Sun, 25 May 2003 22:32:26 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 May 2003 14:32:26.0880 (UTC) FILETIME=[76D34000:01C322CA] cc: freebsd-current@freebsd.org cc: freebsd_stable@hotmail.com Subject: Re: Radeon VE won't work with XFree4.3.0.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 14:32:27 -0000 >From: "Adam Maas" >To: "nobody nobody" , >CC: , >Subject: Re: Radeon VE won't work with XFree4.3.0.1 >Date: Sat, 24 May 2003 13:03:02 -0400 > > >Your problem's not the Radeon, but the display, from the config that's been >generated. The Radeon's configured OK, the display has no modes. > >Any chance on getting the error that X gives you when you start? > >Adam > Ok. I would like to clarify some points for my case. The video card of my system is Radeon VE with TV-out. First of all I would like to know if it is supported under 5.1 beta2. I don't need the tv-out option at the moment. Secondly, I didn't have any chance to specify anything (such as modes ...) since I run xf86cfg and then was kicked by the system. That is what I did so far. Any idea to get off the problem. Thanks. Clarence _________________________________________________________________ Get 10Mb extra storage for MSN Hotmail. Subscribe Now! http://join.msn.com/?pgmarket=en-hk From owner-freebsd-current@FreeBSD.ORG Sun May 25 08:45:29 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F96D37B401 for ; Sun, 25 May 2003 08:45:29 -0700 (PDT) Received: from xmxpita.excite.com (nn1.excitenetwork.com [207.159.120.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8DD043F85 for ; Sun, 25 May 2003 08:45:28 -0700 (PDT) (envelope-from testing12351@excite.com) Received: by xmxpita.excite.com (Postfix, from userid 110) id 6F0D6B700; Sun, 25 May 2003 11:45:25 -0400 (EDT) To: freebsd-current@freebsd.org Received: from [66.171.42.29] by xprdmailfe20.nwk.excite.com via HTTP; Sun, 25 May 2003 11:45:25 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 900b1b1d357e5d9a11deb402afe3e6a5 From: "hgjsdfkhfjkl" MIME-Version: 1.0 X-Sender: testing12351@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Message-Id: <20030525154525.6F0D6B700@xmxpita.excite.com> Date: Sun, 25 May 2003 11:45:25 -0400 (EDT) Subject: FreeBSD 5.1 BETA 2 installer disk geometry X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: testing12351@excite.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 15:45:29 -0000 x86 P3 whitebox Hard disk: Seagate IDE Model Number:ST380011A Capacity:80 GB Speed:7200 rpm Interface:Ultra ATA/100 The FreeBSD 5.1 BETA 2 installer ( custom "partition" ) has trouble determining my hard disk geometry. The installer reads the disk as 155061/16/63 then reports this as unlikely and guesses 9729/255/63 but the BIOS states that the geometry is 1024/255/63 once the geometry is set correctly, the install works ( with the often mentioned krb5 problem ). _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-freebsd-current@FreeBSD.ORG Sun May 25 09:03:49 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC54F37B401 for ; Sun, 25 May 2003 09:03:49 -0700 (PDT) Received: from empire.explosive.mail.net (empire.explosive.mail.net [205.205.25.120]) by mx1.FreeBSD.org (Postfix) with SMTP id 08D0C43FA3 for ; Sun, 25 May 2003 09:03:49 -0700 (PDT) (envelope-from mykroft@explosive.mail.net) Received: (qmail 3571 invoked from network); 25 May 2003 16:03:17 -0000 Received: from ticking.explosive.mail.net (HELO ticking) (205.205.25.116) by empire.explosive.mail.net with SMTP; 25 May 2003 16:03:17 -0000 Message-ID: <0f7e01c322d7$4f93dfb0$7419cdcd@ticking> From: "Adam Maas" To: "nobody nobody" , References: Date: Sun, 25 May 2003 12:04:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 cc: freebsd-current@freebsd.org cc: freebsd_stable@hotmail.com Subject: Re: Radeon VE won't work with XFree4.3.0.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 16:03:50 -0000 ----- Original Message ----- From: "nobody nobody" To: ; Cc: ; Sent: Sunday, May 25, 2003 10:32 AM Subject: Re: Radeon VE won't work with XFree4.3.0.1 > > > > >From: "Adam Maas" > >To: "nobody nobody" , > >CC: , > >Subject: Re: Radeon VE won't work with XFree4.3.0.1 > >Date: Sat, 24 May 2003 13:03:02 -0400 > > > > > >Your problem's not the Radeon, but the display, from the config that's been > >generated. The Radeon's configured OK, the display has no modes. > > > >Any chance on getting the error that X gives you when you start? > > > >Adam > > > > Ok. I would like to clarify some points for my case. The video card of my > system is Radeon VE with TV-out. First of all I would like to know if it is > supported under 5.1 beta2. I don't need the tv-out option at the moment. > Secondly, I didn't have any chance to specify anything (such as modes ...) > since I run xf86cfg and then was kicked by the system. That is what I did > so far. Any idea to get off the problem. > Thanks. > > Clarence > Support for Video Cards is from X, rather than from FreeBSD, and the Radeon VE is certainly supported, since I used to run a Radeon VE Dual Display Edition 32MB (VGA+DVI+TV out) under XFree86 4.1 before I got my 8500. What kind of Monitor do you have plugged in, and what port are you using? Adam From owner-freebsd-current@FreeBSD.ORG Sun May 25 09:13:12 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EBAB37B401 for ; Sun, 25 May 2003 09:13:12 -0700 (PDT) Received: from xmxpita.excite.com (nn1.excitenetwork.com [207.159.120.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B1F43F75 for ; Sun, 25 May 2003 09:13:11 -0700 (PDT) (envelope-from testing12351@excite.com) Received: by xmxpita.excite.com (Postfix, from userid 110) id 41B4BB703; Sun, 25 May 2003 12:13:07 -0400 (EDT) To: freebsd-current@freebsd.org Received: from [66.171.42.29] by xprdmailfe20.nwk.excite.com via HTTP; Sun, 25 May 2003 12:13:07 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 900b1b1d357e5d9a11deb402afe3e6a5 From: "hgjsdfkhfjkl" MIME-Version: 1.0 X-Sender: testing12351@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Message-Id: <20030525161307.41B4BB703@xmxpita.excite.com> Date: Sun, 25 May 2003 12:13:07 -0400 (EDT) Subject: FreeBSD 5.1 BETA 2 make cvsup-without-gui fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: testing12351@excite.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 16:13:12 -0000 after a fresh "kernel developer" install from the x86 5.1 beta 2 ISO, i successfully configured the network and ping a domain name. Then I attempted to install /usr/ports/net/cvsup-without-gui. This fails and repeated attempts provide differing failures. output follows ===> Extracting for cvsup-without-gui-16.1h >> Checksum OK for cvsup-snap-16.1h.tar.gz. ===> Patching for cvsup-without-gui-16.1h ===> cvsup-without-gui-16.1h depends on file: /usr/local/lib/m3/pkg/tcp/FreeBSD4/libm3tcp.a - not found ===> Verifying install for /usr/local/lib/m3/pkg/tcp/FreeBSD4/libm3tcp.a in /usr/ports/lang/ezm3 ===> Extracting for ezm3-1.1 >> Checksum OK for ezm3/ezm3-1.1-FreeBSD4-boot.tar.bz2. >> Checksum OK for ezm3/ezm3-1.1-src.tar.bz2. ===> Patching for ezm3-1.1 ===> Applying FreeBSD patches for ezm3-1.1 ===> ezm3-1.1 depends on executable: gmake - not found ===> Verifying install for gmake in /usr/ports/devel/gmake ===> Extracting for gmake-3.80 >> Checksum OK for make-3.80.tar.bz2. ===> Patching for gmake-3.80 ===> Applying FreeBSD patches for gmake-3.80 /bin/rm /usr/ports/devel/gmake/work/make-3.80/doc/make.info* ===> gmake-3.80 depends on shared library: intl.4 - not found ===> Verifying install for intl.4 in /usr/ports/devel/gettext ===> Extracting for gettext-0.11.5_1 >> Checksum OK for gettext-0.11.5.tar.gz. ===> Patching for gettext-0.11.5_1 ===> Applying FreeBSD patches for gettext-0.11.5_1 ===> gettext-0.11.5_1 depends on executable: libtool - not found ===> Verifying install for libtool in /usr/ports/devel/libtool >> libtool-1.3.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://ftp.gnu.org/gnu/libtool/. 535519 bytes transferred in 4.1 seconds (127.88 kBps) ===> Extracting for libtool-1.3.4_4 >> Checksum OK for libtool-1.3.4.tar.gz. ===> Patching for libtool-1.3.4_4 ===> Applying FreeBSD patches for libtool-1.3.4_4 ===> Configuring for libtool-1.3.4_4 creating cache ./config.cache checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking whether make sets ${MAKE}... yes checking for working aclocal... missing checking for working autoconf... missing checking for working automake... missing checking for working autoheader... missing checking for working makeinfo... found checking for gcc... cc checking whether the C compiler (cc -O -pipe -mcpu=pentiumpro ) works... yes checking whether the C compiler (cc -O -pipe -mcpu=pentiumpro ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether cc accepts -g... yes checking for ranlib... ranlib checking host system type... i386-portbld-freebsd5.1 checking build system type... i386-portbld-freebsd5.1 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking for mawk... no checking for gawk... no checking for nawk... nawk updating cache ./config.cache creating ./config.status creating Makefile creating doc/Makefile creating tests/Makefile configuring in libltdl running /bin/sh ./configure --prefix=/usr/local i386-portbld-freebsd5.1 --enable-ltdl-install --cache-file=.././config.cache --srcdir=. loading cache .././config.cache checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... missing checking for working autoconf... missing checking for working automake... missing checking for working autoheader... missing checking for working makeinfo... found checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... (cached) cc checking whether the C compiler (cc -O -pipe -mcpu=pentiumpro ) works... yes checking whether the C compiler (cc -O -pipe -mcpu=pentiumpro ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether cc accepts -g... (cached) yes checking for working const... yes checking for inline... inline checking host system type... i386-portbld-freebsd5.1 checking build system type... i386-portbld-freebsd5.1 checking for ranlib... (cached) ranlib checking for ld used by GCC... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes checking for BSD-compatible nm... (cached) /usr/bin/nm -B checking whether ln -s works... (cached) yes updating cache .././config.cache loading cache .././config.cache within ltconfig checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions ... yes checking if cc static flag -static works... -static checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... freebsd5.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool updating cache .././config.cache loading cache .././config.cache checking which extension is used for shared libraries... .so checking which variable specifies run-time library path... LD_LIBRARY_PATH checking for objdir... .libs checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for malloc.h... no checking for memory.h... yes checking for stdlib.h... yes checking for stdio.h... yes checking for ctype.h... yes checking for dlfcn.h... yes checking for dl.h... no checking for dld.h... no checking for string.h... yes checking for strchr... yes checking for strrchr... yes checking whether libtool supports -dlopen/-dlpreopen... yes checking for dlopen in -ldl... no checking for dlopen... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dld_link in -ldld... no checking for dlerror... yes checking command to parse /usr/bin/nm -B output... yes checking for _ prefix in compiled symbols... (cached) no updating cache .././config.cache creating ./config.status creating Makefile creating config.h ===> Building for libtool-1.3.4_4 Making all in . CC="cc" CFLAGS="-O -pipe -mcpu=pentiumpro" CPPFLAGS="" LD="/usr/bin/ld" LDFLAGS="" LIBS="" LN_S="ln -s" NM="/usr/bin/nm -B" RANLIB="ranlib" DLLTOOL="" OBJDUMP="" AS="" /bin/sh ./ltconfig --cache-file=./config.cache --with-gcc --with-gnu-ld --enable-dlopen --srcdir=. --output=libtool ./ltmain.sh loading cache ./config.cache within ltconfig checking host system type... i386-unknown-freebsdelf5.1 checking for object suffix... o checking for executable suffix... (cached) no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions ... yes checking if cc static flag -static works... -static checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... freebsdelf5.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs checking for dlopen in -ldl... (cached) no checking for dlopen... (cached) yes checking for dlfcn.h... (cached) yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... no creating libtool updating cache ./config.cache CONFIG_FILES=libtoolize CONFIG_HEADERS= ./config.status creating libtoolize chmod +x libtoolize Making all in libltdl /bin/sh ./libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -O -pipe -mcpu=pentiumpro -c ltdl.c mkdir .libs cc -DHAVE_CONFIG_H -I. -I. -I. -O -pipe -mcpu=pentiumpro -c ltdl.c -fPIC -DPIC -o .libs/ltdl.lo cc -DHAVE_CONFIG_H -I. -I. -I. -O -pipe -mcpu=pentiumpro -c ltdl.c -o ltdl.o >/dev/null 2>&1 mv -f .libs/ltdl.lo ltdl.lo /bin/sh ./libtool --mode=link cc -O -pipe -mcpu=pentiumpro -o libltdl.la -rpath /usr/local/lib -version-info 1:2:1 ltdl.lo rm -fr .libs/libltdl.la .libs/libltdl.* .libs/libltdl.* cc -shared -Wl,--rpath -Wl,/usr/local/lib ltdl.lo -Wl,-soname -Wl,libltdl.so.1 -o .libs/libltdl.so.1 (cd .libs && rm -f libltdl.so && ln -s libltdl.so.1 libltdl.so) ar cru .libs/libltdl.a ltdl.o ranlib .libs/libltdl.a creating libltdl.la (cd .libs && rm -f libltdl.la && ln -s ../libltdl.la libltdl.la) Making all in doc cd . && makeinfo --no-split `echo libtool.texi | sed 's,.*/,,'` libtool.texi:2906: warning: `(' follows defined name `LTDL_SET_PRELOADED_SYMBOLS' instead of whitespace. Making all in tests ===> Installing for libtool-1.3.4_4 Making install in . /bin/sh ./mkinstalldirs /usr/local/bin /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: Undefined symbol "_nsyylen" install -o root -g wheel -m 555 libtool /usr/local/bin/libtool install -o root -g wheel -m 555 libtoolize /usr/local/bin/libtoolize /bin/sh ./mkinstalldirs /usr/local/share/libtool mkdir /usr/local/share/libtool install -o root -g wheel -m 555 config.guess /usr/local/share/libtool/config.guess install -o root -g wheel -m 555 config.sub /usr/local/share/libtool/config.sub install -o root -g wheel -m 555 ltconfig /usr/local/share/libtool/ltconfig /bin/sh ./mkinstalldirs /usr/local/share/aclocal install -o root -g wheel -m 444 ./libtool.m4 /usr/local/share/aclocal/libtool.m4 /bin/sh ./mkinstalldirs /usr/local/share/libtool install -o root -g wheel -m 444 ./ltmain.sh /usr/local/share/libtool/ltmain.sh make install-data-hook cd libltdl && make local-install-files rm -rf /usr/local/share/libtool/libltdl /bin/sh ./../mkinstalldirs /usr/local/share/libtool/libltdl mkdir /usr/local/share/libtool/libltdl Making install in libltdl /bin/sh ./../mkinstalldirs /usr/local/lib /bin/sh ./libtool --mode=install /usr/bin/install -c -o root -g wheel libltdl.la /usr/local/lib/libltdl.la /usr/bin/install -c -o root -g wheel .libs/libltdl.so.1 /usr/local/lib/libltdl.so.1 (cd /usr/local/lib && rm -f libltdl.so && ln -s libltdl.so.1 libltdl.so) /usr/bin/install -c -o root -g wheel .libs/libltdl.a /usr/local/lib/libltdl.a ranlib /usr/local/lib/libltdl.a chmod 644 /usr/local/lib/libltdl.a /usr/bin/env OBJFORMAT="elf" /sbin/ldconfig -m /usr/local/lib ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /bin/sh ./../mkinstalldirs /usr/local/include install -o root -g wheel -m 444 ltdl.h /usr/local/include/ltdl.h Making install in doc /bin/sh ../mkinstalldirs /usr/local/info install -o root -g wheel -m 444 ./libtool.info /usr/local/info/libtool.info install-info --info-dir=/usr/local/info /usr/local/info/libtool.info Making install in tests ===> Generating temporary packing list ===> Running ldconfig /sbin/ldconfig -m /usr/local/lib ===> Registering installation for libtool-1.3.4_4 ===> Returning to build of gettext-0.11.5_1 ===> gettext-0.11.5_1 depends on shared library: iconv.3 - not found ===> Verifying install for iconv.3 in /usr/ports/converters/libiconv >> libiconv-1.8.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://ftp.gnu.org/gnu/libiconv/. 3514117 bytes transferred in 36.3 seconds (94.64 kBps) ===> Extracting for libiconv-1.8_2 >> Checksum OK for libiconv-1.8.tar.gz. ===> Patching for libiconv-1.8_2 ===> Applying FreeBSD patches for libiconv-1.8_2 ===> libiconv-1.8_2 depends on executable: libtool - found ===> Configuring for libiconv-1.8_2 configure: WARNING: you should use --build, --host, --target checking whether make sets ${MAKE}... yes checking for i386-portbld-freebsd5.1-gcc... cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking how to run the C preprocessor... cc -E checking whether cc needs -traditional... no checking for ranlib... ranlib checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel checking how to copy files... cp -p checking how to make hard links... ln checking whether ln -s works... yes checking build system type... i386-portbld-freebsd5.1 checking host system type... i386-portbld-freebsd5.1 checking for AIX... no checking for minix/config.h... no checking for strerror in -lcposix... no checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... nm checking how to recognise dependant libraries... pass_all checking command to parse nm output... ok checking for dlfcn.h... yes checking for i386-portbld-freebsd5.1-ranlib... (cached) ranlib checking for i386-portbld-freebsd5.1-strip... no checking for strip... strip checking for objdir... .libs checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc static flag -static works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... freebsd5.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... yes creating libtool checking host system type... i386-unknown-freebsdelf5.1 checking for ranlib... ranlib checking whether we are using GNU C... yes checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions ... yes checking if cc static flag -static works... -static checking whether ln -s works... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking for BSD-compatible nm... /usr/bin/nm -B checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... freebsdelf5.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking for iconv... no, consider installing GNU libiconv checking for msgfmt... no checking for gmsgfmt... : checking for xgettext... no checking for msgmerge... no checking whether NLS is requested... yes checking for GNU gettext in libc... no checking for iconv... (cached) no, consider installing GNU libiconv checking for GNU gettext in libintl... no checking for locale.h... yes checking for stdlib.h... yes checking for mbstate_t... yes checking for mbrtowc... yes checking for wcrtomb... yes checking for mbsinit... yes checking for setlocale... yes checking for wchar.h... yes checking for EILSEQ... yes checking byte ordering... little endian configure: creating ./config.status config.status: creating Makefile config.status: creating lib/Makefile config.status: creating src/Makefile config.status: creating po/Makefile.in config.status: creating man/Makefile config.status: creating tests/Makefile config.status: creating include/iconv.h config.status: creating lib/config.h config.status: creating src/config.h config.status: creating po/POTFILES config.status: creating po/Makefile configure: configuring in libcharset configure: running /bin/sh './configure' --enable-static --without-libintl-prefix --prefix=/usr/local i386-portbld-freebsd5.1 'CFLAGS=-O -pipe -mcpu=pentiumpro' host_alias=i386-portbld-freebsd5.1 build_alias=i386-portbld-freebsd5.1 target_alias=i386-portbld-freebsd5.1 CC=cc --cache-file=/dev/null --srcdir=. configure: WARNING: you should use --build, --host, --target checking whether make sets ${MAKE}... yes checking for i386-portbld-freebsd5.1-gcc... cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking how to run the C preprocessor... cc -E checking whether cc needs -traditional... no checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel checking build system type... i386-portbld-freebsd5.1 checking host system type... i386-portbld-freebsd5.1 checking for AIX... no checking for minix/config.h... no checking for POSIXized ISC... no checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... nm checking whether ln -s works... yes checking how to recognise dependant libraries... pass_all checking command to parse nm output... ok checking for dlfcn.h... yes checking for i386-portbld-freebsd5.1-ranlib... no checking for ranlib... ranlib checking for i386-portbld-freebsd5.1-strip... no checking for strip... strip checking for objdir... .libs checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc static flag -static works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... freebsd5.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... yes creating libtool checking host system type... i386-unknown-freebsdelf5.1 checking for ranlib... ranlib checking whether we are using GNU C... yes checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions ... yes checking if cc static flag -static works... -static checking whether ln -s works... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking for BSD-compatible nm... /usr/bin/nm -B checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... freebsdelf5.1 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool checking for langinfo.h... yes checking for nl_langinfo... yes checking for nl_langinfo and CODESET... yes checking whether we are using the GNU C Library 2.1 or newer... no checking for stddef.h... yes checking for stdlib.h... yes checking for string.h... yes checking for setlocale... yes configure: creating ./config.status config.status: creating Makefile config.status: creating lib/Makefile config.status: creating config.h ===> Building for libiconv-1.8_2 builddir="`pwd`"; cd libcharset && make all && make install-lib libdir="$builddir/lib" includedir="$builddir/lib" sysconfdir="$builddir/lib" if [ ! -d include ] ; then mkdir include ; fi cp ./include/libcharset.h.in include/libcharset.h cd lib && make all /bin/sh ../libtool --mode=compile cc -I. -I. -I.. -I./.. -O -pipe -mcpu=pentiumpro -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/libdata\" -c ./localcharset.c mkdir .libs cc -I. -I. -I.. -I./.. -O -pipe -mcpu=pentiumpro -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/libdata\" -c ./localcharset.c -fPIC -DPIC -o .libs/localcharset.lo cc -I. -I. -I.. -I./.. -O -pipe -mcpu=pentiumpro -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/libdata\" -c ./localcharset.c -o localcharset.o >/dev/null 2>&1 mv -f .libs/localcharset.lo localcharset.lo /bin/sh ../libtool --mode=link cc -o libcharset.la -rpath /usr/local/lib -version-info 1 -no-undefined localcharset.lo rm -fr .libs/libcharset.la .libs/libcharset.* .libs/libcharset.* cc -shared -Wl,--rpath -Wl,/usr/local/lib localcharset.lo -Wl,-soname -Wl,libcharset.so.1 -o .libs/libcharset.so.1 (cd .libs && rm -f libcharset.so && ln -sf libcharset.so.1 libcharset.so) ar cru .libs/libcharset.a localcharset.o ranlib .libs/libcharset.a creating libcharset.la (cd .libs && rm -f libcharset.la && ln -sf ../libcharset.la libcharset.la) /bin/sh ./config.charset 'i386-portbld-freebsd5.1' > t-charset.alias mv t-charset.alias charset.alias sed -e '/^#/d' -e 's/@''PACKAGE''@//g' ./ref-add.sin > t-ref-add.sed mv t-ref-add.sed ref-add.sed sed -e '/^#/d' -e 's/@''PACKAGE''@//g' ./ref-del.sin > t-ref-del.sed mv t-ref-del.sed ref-del.sed cd lib && make all cd lib && make install-lib libdir='/usr/ports/converters/libiconv/work/libiconv-1.8/lib' includedir='/usr/ports/converters/libiconv/work/libiconv-1.8/lib' sysconfdir='/usr/ports/converters/libiconv/work/libiconv-1.8/lib' /bin/sh ./../autoconf/mkinstalldirs /usr/ports/converters/libiconv/work/libiconv-1.8/lib /bin/sh ../libtool --mode=install install -o root -g wheel -m 444 libcharset.la /usr/ports/converters/libiconv/work/libiconv-1.8/lib/libcharset.la install -o root -g wheel -m 444 .libs/libcharset.so.1 /usr/ports/converters/libiconv/work/libiconv-1.8/lib/libcharset.so.1 (cd /usr/ports/converters/libiconv/work/libiconv-1.8/lib && rm -f libcharset.so && ln -sf libcharset.so.1 libcharset.so) install -o root -g wheel -m 444 .libs/libcharset.a /usr/ports/converters/libiconv/work/libiconv-1.8/lib/libcharset.a ranlib /usr/ports/converters/libiconv/work/libiconv-1.8/lib/libcharset.a chmod 644 /usr/ports/converters/libiconv/work/libiconv-1.8/lib/libcharset.a libtool: install: warning: remember to run `libtool --finish /usr/local/lib' /bin/sh ./../autoconf/mkinstalldirs /usr/ports/converters/libiconv/work/libiconv-1.8/lib test -f /usr/ports/converters/libiconv/work/libiconv-1.8/lib/charset.alias && orig=/usr/ports/converters/libiconv/work/libiconv-1.8/lib/charset.alias || orig=charset.alias; sed -f ref-add.sed $orig > /usr/ports/converters/libiconv/work/libiconv-1.8/lib/t-charset.alias; install -o root -g wheel -m 444 /usr/ports/converters/libiconv/work/libiconv-1.8/lib/t-charset.alias /usr/ports/converters/libiconv/work/libiconv-1.8/lib/charset.alias; rm -f /usr/ports/converters/libiconv/work/libiconv-1.8/lib/t-charset.alias /bin/sh ./autoconf/mkinstalldirs /usr/ports/converters/libiconv/work/libiconv-1.8/lib install -o root -g wheel -m 444 include/libcharset.h /usr/ports/converters/libiconv/work/libiconv-1.8/lib/libcharset.h cd lib && make all /bin/sh ../libtool --mode=compile cc -I. -I. -I../include -I./../include -O -pipe -mcpu=pentiumpro -c ./iconv.c ../libtool: 1048: Syntax error: ";" unexpected *** Error code 2 Stop in /usr/ports/converters/libiconv/work/libiconv-1.8/lib. *** Error code 1 Stop in /usr/ports/converters/libiconv/work/libiconv-1.8. *** Error code 1 Stop in /usr/ports/converters/libiconv. *** Error code 1 Stop in /usr/ports/devel/gettext. *** Error code 1 Stop in /usr/ports/devel/gmake. *** Error code 1 Stop in /usr/ports/lang/ezm3. *** Error code 1 Stop in /usr/ports/net/cvsup-without-gui. _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-freebsd-current@FreeBSD.ORG Sun May 25 09:59:26 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3602E37B401 for ; Sun, 25 May 2003 09:59:26 -0700 (PDT) Received: from thuis.piwebs.com (t-indiv5-84.athome.tue.nl [131.155.241.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 17DE243FAF for ; Sun, 25 May 2003 09:59:23 -0700 (PDT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 8327 invoked by uid 85); 25 May 2003 17:01:18 -0000 Received: from avleeuwen@piwebs.com by thuis.piwebs.com by uid 82 with qmail-scanner-1.15 (uvscan: v4.1.60/v4210. spamassassin: 2.x. Clear:SA:0(-5.0/5.0):. Processed in 11.283167 secs); 25 May 2003 17:01:18 -0000 X-Spam-Status: No, hits=-5.0 required=5.0 Received: from unknown (HELO 192.168.0.109) (192.168.0.109) by 0 with SMTP; 25 May 2003 17:01:06 -0000 From: Arjan van Leeuwen To: "Matthew N. Dodd" Date: Sun, 25 May 2003 18:59:09 +0200 User-Agent: KMail/1.5.2 References: <20030525061524.H30007@sasami.jurai.net> <20030525084629.R30007@sasami.jurai.net> In-Reply-To: <20030525084629.R30007@sasami.jurai.net> MIME-Version: 1.0 Content-Disposition: inline X-UID: 379 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200305251859.09670.avleeuwen@piwebs.com> cc: current@freebsd.org Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 16:59:26 -0000 Do I need to recompile applications to use prebinding? Arjan On Sunday 25 May 2003 15:03, Matthew N. Dodd wrote: > On Sun, 25 May 2003, Dag-Erling Smorgrav wrote: > > "Matthew N. Dodd" writes: > > > I've implemented per-executable ELF prebinding: > > > > Could you explain briefly what prebinding does? > > (This isn't as brief as you or I hoped I suspect.) > > Relocatable objects (executables and libraries) contain elements that > require relocation before the are usable. In some cases this relocation > requires symbols to be located and resolved. Resolving these symbols and > performing the lookups imposes some execution overhead. By 'prebinding' > we can do as much of this work beforehand and speed up the actual > relocation process. > > The short answer is that things like KDE and other library happy > executables take a little less time to load. > > Consider this program: > > # cat test.c > int main (int argc, char *argv[]) { return (0); } > # cc -o test test.c > # ldd test > test: > libc.so.5 => /usr/lib/libc.so.5 (0x28076000) > ... > > Using a simple execloop (1000 iterations) and time(1): > > normal: 0.734u 4.395s 0:07.55 67.8% 13+163k 0+0io 0pf+0w > prebind: 0.396u 3.777s 0:05.26 79.0% 16+173k 0+0io 0pf+0w > static: 0.000u 0.663s 0:01.06 62.2% 56+186k 0+0io 0pf+0w > > Now lets link test.c with lots of useless libraries: > > # cc -Wall -o test test.c -lalias -lasn1 -latm -lbsdxml -lbz2 -lc -lc_r > -lcalendar -lcam -lcom_err -lcrypt -lcrypto -ldevinfo -ldevstat -ldialog > -ledit -lfetch -lform -lftpio -lg2c -lgeom -lgnuregex -lhistory -lipsec > -lipx -lisc -lm -lmd -lmenu -lmilter -lmp -lncp -lncurses -lnetgraph > -lopie -lpam -lpanel -lpcap -lradius -lreadline -lroken -lrpcsvc -lsbuf > -lsmb -lssh -lssl -lstdc++ -ltacplus -lufs -lugidfw -lusbhid -lutil -lvgl > -lwrap -lxpg4 -lypclnt -lz -lkvm > > (We'll run execloop with only 100 iterations) > > normal: 14.003u 4.263s 0:23.14 78.9% 5+174k 0+0io 0pf+0w > prebind: 1.108u 3.231s 0:05.46 79.3% 6+182k 0+0io 0pf+0w > static: 0.000u 0.062s 0:00.15 40.0% 66+229k 0+0io 0pf+0w > > This is just a quick and dirty example mind you; I should really run > things with 10000 iterations and make execloop do its own timing > statistics etc. From owner-freebsd-current@FreeBSD.ORG Sun May 25 10:02:00 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DA9537B401 for ; Sun, 25 May 2003 10:02:00 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFBD243F3F for ; Sun, 25 May 2003 10:01:59 -0700 (PDT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h4PH1w3q091305; Sun, 25 May 2003 13:01:59 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sun, 25 May 2003 13:01:58 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Arjan van Leeuwen In-Reply-To: <200305251859.09670.avleeuwen@piwebs.com> Message-ID: <20030525130038.L86964@sasami.jurai.net> References: <20030525061524.H30007@sasami.jurai.net> <200305251859.09670.avleeuwen@piwebs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 17:02:00 -0000 On Sun, 25 May 2003, Arjan van Leeuwen wrote: > Do I need to recompile applications to use prebinding? Relinking with the new binutils is all thats required, so in most cases the answer is "yes" (most people don't keep all the .o files around...) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | From owner-freebsd-current@FreeBSD.ORG Sun May 25 10:04:13 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E0A737B401 for ; Sun, 25 May 2003 10:04:13 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1218C43F85 for ; Sun, 25 May 2003 10:04:00 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h4PH2eEd076378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 May 2003 20:02:47 +0300 (EEST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h4PH2U9U076348; Sun, 25 May 2003 20:02:30 +0300 (EEST) (envelope-from ru) Date: Sun, 25 May 2003 20:02:30 +0300 From: Ruslan Ermilov To: Joshua Goodall Message-ID: <20030525170230.GA74239@sunbay.com> References: <20030523203517.GA93787@attbi.com> <20030524034419.GA63643@sunbay.com> <20030524084432.GA509@roughtrade.net> <20030524174817.GA42456@sunbay.com> <20030525074823.GK91207@roughtrade.net> <20030525084344.GA26791@sunbay.com> <20030525100559.GL91207@roughtrade.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <20030525100559.GL91207@roughtrade.net> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org Subject: Re: Updating -CURRENT, what about outdated files? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 17:04:13 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 25, 2003 at 08:05:59PM +1000, Joshua Goodall wrote: > On Sun, May 25, 2003 at 11:43:44AM +0300, Ruslan Ermilov wrote: > > But you don't often know if installworld attemps to install it > > or not, if it wasn't here: > >=20 > > src/sys/boot/i386/loader/Makefile: > >=20 > > beforeinstall: > > ... > > .if !exists(${DESTDIR}/boot/loader.rc) > > ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ > > ${.CURDIR}/../../forth/loader.rc ${DESTDIR}/boot > > .endif > >=20 > > > Other than the general case of using install -C, can you > > > point out any specific examples? I thought that was the point > > > of mergemaster; to manage elements of the distribution where > > > simply overwriting would be inappropriate. >=20 > > Nope, mergemaster(8) deals with updating of /etc only, unless > > I'm horribly mistaken (I don't use it personally, but pretty > > much do what it does manually). >=20 > What you just said implies that installing world+kernel, then running > mergemaster, does not update every part of a FreeBSD base system > installation, modulo ports and make.conf knobs. >=20 It doesn't, mergemaster(8) only covers the set of files produced by "make distribution" from src/etc/Makefile. These are /dev, /etc, /root, and /var/log files, with a few minor exceptions like /COPYRIGHT, /.cshrc, /.profile, and /var/run. > I knew that already about /stand. I didn't realise it extended elsewhere. > Perhaps because I lack install-fu. >=20 I remove /stand as soon as I install the system. It will soon be replaced in 5.x with some very useful stuff (/rescue). > I confess that my Astonishment meter just twitched a little. Any > reason why /boot/loader.rc *shouldn't* be under mergemaster control? >=20 It cannot be, because it's installed by "installworld" and not the "distribution" from src/etc/Makefile. To install a fresh system, one needs to "installworld" first, then run "make distribution" from src/etc/. That gives a fresh system, pretty much like after the initial installation, with an empty root password in /etc/master.passwd, etc. (Never ever run this on a running system without also specifying DESTDIR=3D/somewhere, like mergemaster(8) does for you!) > At any rate, I'd expect to catch-and-document special cases, if > only through a find-and-diff. >=20 To summarize, mergemaster(8) only adds/updates/removes files from the "make distribution" set. The files from "installworld" are unaffected. I use find(1) to clean the "installworld" leftovers, and I use the procedure similar to what is done by mergemaster(8) to clean the "make distribution" set of files: my /var/tmp on each machine has two directories, e.g., 20021204/ and 20030415/, that are populated by the "make distribution" outputs from their respective dates. If I'd be about to upgrade this system today, as the last step, I would create the 20030525 directory, populate it with "make distribution", and then diff(1) compare it against 20030415/ (and remove 20021204/). You can always have a fresh system by using this sequence: rm -rf /somewhere && mkdir -p /somewhere cd /usr/src && make DESTDIR=3D/somewhere installworld cd /usr/src/etc && make DESTDIR=3D/somewhere distribution diff(1) compare "/" and "/somewhere" Hint: the -q option to diff(1) is very handy here, as it optimizes the case where two files differ in size. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+0PclUkv4P6juNwoRAuS/AJ4yxixWnmY9RgYub6J9n1xlsHN3DwCeLZsw k1QNHPKd132shmE9A2/fnZU= =nbBC -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From owner-freebsd-current@FreeBSD.ORG Sun May 25 10:06:14 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EFFC37B401 for ; Sun, 25 May 2003 10:06:14 -0700 (PDT) Received: from philemon.caltech.edu (philemon.caltech.edu [131.215.90.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE38D43F93 for ; Sun, 25 May 2003 10:06:13 -0700 (PDT) (envelope-from jd@philemon.caltech.edu) Received: from philemon.caltech.edu (localhost [127.0.0.1]) h4PH6Hsn003614 for ; Sun, 25 May 2003 10:06:17 -0700 (PDT) (envelope-from jd@philemon.caltech.edu) Received: (from jd@localhost) by philemon.caltech.edu (8.12.6p2/8.12.6/Submit) id h4PH6HVu003613 for freebsd-current@freebsd.org; Sun, 25 May 2003 10:06:17 -0700 (PDT) Date: Sun, 25 May 2003 10:06:17 -0700 From: eng@donut.ugcs.caltech.edu To: freebsd-current@freebsd.org Message-ID: <20030525170617.GA3588@philemon.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: sysinstall hangs while attempting ftp install X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 17:06:14 -0000 I experience a hard lock within sysinstall (5.0-R) while attempting an ftp install over a pc card ethernet device (ep driver). This problem is reprducable with the emergancy shell simply by running ifconfig ep0 . Are pccard installations not supported? Thanks. From owner-freebsd-current@FreeBSD.ORG Sun May 25 11:43:14 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5E5637B401 for ; Sun, 25 May 2003 11:43:14 -0700 (PDT) Received: from mail.dubium.com (h24-82-130-8.vn.shawcable.net [24.82.130.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDF5A43F3F for ; Sun, 25 May 2003 11:43:13 -0700 (PDT) (envelope-from joe@dubium.com) Received: (qmail 87956 invoked by uid 0); 25 May 2003 18:44:05 -0000 Received: from joe@dubium.com by fafner.dubium.com by uid 7791 with qmail-scanner-1.14 (spamassassin: 2.50. Clear:. Processed in 0.034693 secs); 25 May 2003 18:44:05 -0000 Received: from sigfried.dubium.com (HELO mail.dubium.com) ([192.168.0.201]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 25 May 2003 18:44:05 -0000 Received: from 192.168.0.1 (SquirrelMail authenticated user joe@dubium.com) by mail.dubium.com with HTTP; Sun, 25 May 2003 11:44:05 -0700 (PDT) Message-ID: <65460.192.168.0.1.1053888245.squirrel@mail.dubium.com> Date: Sun, 25 May 2003 11:44:05 -0700 (PDT) From: "Joe Sotham" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: MODE_SENSE_BIG "Error" during install 5.1-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 18:43:15 -0000 The error acd1 MODE_SENSE_BIG command timeout - resetting occured repeatedly (12 times) until I cancelled the install (using the 5.0 and 5.1-BETA2 install CDs.) acd1 is a Plextor CD-RW PXW1210A. As I really don't need to install 5 on my workstation yet, it was a boring Saturday night, I will drop this unless someone is interesting in following up with me on this issue, in which case I would be happy to help out. -- Joe Sotham ------------ If the only prayer you say in your entire life is "Thank You", that will suffice. - Meister Eckhart From owner-freebsd-current@FreeBSD.ORG Sun May 25 12:18:37 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD87B37B404 for ; Sun, 25 May 2003 12:18:37 -0700 (PDT) Received: from mailhost2.dircon.co.uk (mailhost2.dircon.co.uk [194.112.32.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3928E43FAF for ; Sun, 25 May 2003 12:18:36 -0700 (PDT) (envelope-from mark@blackmans.org) Received: from mail.blackmans.org (unknown [195.157.223.200]) by mailhost2.dircon.co.uk (Postfix) with ESMTP id A180B645D9; Sun, 25 May 2003 20:18:34 +0100 (BST) Received: by mail.blackmans.org (Postfix, from userid 1010) id 3EF526FA9; Sun, 25 May 2003 20:12:33 +0100 (BST) Date: Sun, 25 May 2003 20:12:32 +0100 From: Mark Blackman To: ticso@cicely.de Message-ID: <20030525191232.GA76628@maddog.blackmans.org> References: <200305070308.42781.jay@evilrealms.net> <20030507095531.GJ84364@cicely9.cicely.de> <200305072315.33643.jay@evilrealms.net> <200305101126.20312.jay@evilrealms.net> <20030511000432.GP94201@cicely9.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030511000432.GP94201@cicely9.cicely.de> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org cc: Jay Cornwall Subject: Re: USB ugen_set_interface issue (+ possible patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 19:18:38 -0000 Hi, Thanks for the effort here, but using a -current from May 24, (patch committed on May 18), I'm still getting device panics of the same type when using modem_run (from pppoa). However, the modem_run gets a bit further and most of the upload/download operations succeed. The panic now occurs at BLOCK4 instead of immediately. I can arrange to provide more detail for anyone who is interested. cheers, Mark On Sun, May 11, 2003 at 02:04:33AM +0200, Bernd Walter wrote: > On Sat, May 10, 2003 at 11:26:16AM +0100, Jay Cornwall wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Wednesday 07 May 2003 23:15 pm, Jay Cornwall wrote: > > > > > With these issues I can't do a full upgrade to -current, but I've done some > > > blind testing with the GENERIC kernel. Without the patch, the kernel still > > > panics when attempting to run the Speedtouch software. With the patch in > > > place, the panic is averted and the modem goes on to establish a > > > connection. > > > > Any further comments on this patch, or am I perhaps asking in the wrong place > > (maybe I should be asking in freebsd-hackers)? > > I will take care for your patch in a few days. > > -- > B.Walter BWCT http://www.bwct.de > ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Sun May 25 14:12:52 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C17A437B401 for ; Sun, 25 May 2003 14:12:52 -0700 (PDT) Received: from gunjin.wccnet.org (gunjin.wccnet.org [198.111.176.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC86243F3F for ; Sun, 25 May 2003 14:12:51 -0700 (PDT) (envelope-from anthony@gunjin.wccnet.org) Received: from gunjin.wccnet.org (localhost.rexroof.com [127.0.0.1]) by gunjin.wccnet.org (8.12.3/8.12.2) with ESMTP id h4PLHVsn005413 for ; Sun, 25 May 2003 17:17:31 -0400 (EDT) Received: (from anthony@localhost) by gunjin.wccnet.org (8.12.3/8.12.3/Submit) id h4PLHVkg005412 for freebsd-current@freebsd.org; Sun, 25 May 2003 17:17:31 -0400 (EDT) Date: Sun, 25 May 2003 17:17:30 -0400 From: Anthony Schneider To: freebsd-current@freebsd.org Message-ID: <20030525211730.GA5226@x-anthony.com> References: <20030525064929.GA96588@x-anthony.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20030525064929.GA96588@x-anthony.com> User-Agent: Mutt/1.4i Subject: Re: mpi + shmem issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 21:12:53 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable additional information: when recompiling mpich for debugging symbols, configure fails on: checking that usable shared memory locks were found... no so, does this mean that mpich somehow exhausted all shmem locks? after running the program only 10 times, i see this as infeasible, considering a) mpich (presumably in MPI_Init()) would only want 1 or 2 locks on init and b) any shared memory locks mpich grabs should be freed upon process completion (whether clean or not) by the operating system, no? well, configure with --with-device=3Dch_shmem:-usesysv succeeds (checking that usable shared memory locks were found... yes), so I will try this out. But for reference, can anyone make a guess as to why/how a shared memory application can exhaust locks like this? thank you. -Anthony. On Sun, May 25, 2003 at 02:49:30AM -0400, Anthony Schneider wrote: > Hello, > My machine is a dual athlon: > FreeBSD pickle. 5.1-BETA FreeBSD 5.1-BETA #6: Sun May 25 02:16:15 EDT 2003 > anthony@pickle.:/usr/src/sys/i386/compile/PICKLE i386 >=20 > I started having this issue, which may or may not exist on uniprocessor > systems or 4.x systems. I built mpi with ch_shmem device for shared memo= ry > programs (instead of the more common rsh/ssh), and something strange > happens. For even the most basic little program, the program will launch > fine (usually) the first time i run it after the system boots, but after a > few executions, execution starts failing consistently until after i reboo= t. >=20 > as an example, here is a small acknowledgment program: >=20 > #include > #include >=20 > int main (int argc, char *argv[]) { > int mpiRank, mpiSize; >=20 > MPI_Init (&argc, &argv); > MPI_Comm_rank (MPI_COMM_WORLD, &mpiRank); >=20 > printf ("#%d here\n", mpiRank); >=20 > return 0; >=20 > } >=20 > and here is the history of executing it: >=20 > pickle:anthony:/home/anthony/src/mpi:6% mpirun -np 2 ./foo > #0 here > #1 here > Child process exited unexpectedly 0 > Abort trap (core dumped) > pickle:anthony:/home/anthony/src/mpi:7% mpirun -np 2 ./foo > #0 here > pickle:anthony:/home/anthony/src/mpi:8% #1 here >=20 > pickle:anthony:/home/anthony/src/mpi:8% mpirun -np 2 ./foo > #0 here > #1 here > pickle:anthony:/home/anthony/src/mpi:9% mpirun -np 2 ./foo > #0 here > #1 here > pickle:anthony:/home/anthony/src/mpi:10% mpirun -np 2 ./foo > #1 here > #0 here > Child process exited unexpectedly 0 > Abort trap (core dumped) > pickle:anthony:/home/anthony/src/mpi:11% mpirun -np 2 ./foo > #0 here > #1 here > Child process exited unexpectedly 0 > Abort trap (core dumped) > pickle:anthony:/home/anthony/src/mpi:12% mpirun -np 2 ./foo > #0 here > #1 here > pickle:anthony:/home/anthony/src/mpi:13% mpirun -np 2 ./foo > #1 here > #0 here > Child process exited unexpectedly 0 > Abort trap (core dumped) > pickle:anthony:/home/anthony/src/mpi:14% mpirun -np 2 ./foo > #0 here > #1 here > pickle:anthony:/home/anthony/src/mpi:15% mpirun -np 2 ./foo > #0 here > #1 here > pickle:anthony:/home/anthony/src/mpi:16% mpirun -np 2 ./foo > semget failed for setnum =3D 0 > Abort trap (core dumped) > pickle:anthony:/home/anthony/src/mpi:17% mpirun -np 2 ./foo > semget failed for setnum =3D 0 > Abort trap (core dumped) > pickle:anthony:/home/anthony/src/mpi:18% mpirun -np 2 ./foo > semget failed for setnum =3D 0 > Abort trap (core dumped) >=20 > ... (continues until i reboot) >=20 > the first run that aborts is strange, but since it is not something > i've witnessed previously, i'd like to forget that and focus on > the repeated semget failures. i would normally be looking into > the mpi implementation (mpich 1.2.5), but since after semget fails > once it never seems to succeed again with other mpi programs, i > think this to be a freebsd problem. >=20 > i'm runing a (barely) custom kernel, with nothing added to it. > i just cvsup'd and rebuilt less than an hour ago, and the problem > has persisted from beta #5 through beta #6. >=20 > any suggestions? >=20 > thank you for your help. >=20 > -Anthony. --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+0TLpKUeW47UGY2kRAssxAKCZs5We5Q/IWgdxdQTRxzLD4tT+xQCfe6+5 sePLca9mYSn9wqa6t/c6868= =qRIN -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-current@FreeBSD.ORG Sun May 25 14:16:28 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BBE637B401 for ; Sun, 25 May 2003 14:16:28 -0700 (PDT) Received: from herbelot.dyndns.org (herbelot.net1.nerim.net [62.212.117.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4989043F85 for ; Sun, 25 May 2003 14:16:27 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.12.6/8.12.6) with ESMTP id h4PKvPV8025423 for ; Sun, 25 May 2003 22:57:25 +0200 (CEST) From: Thierry Herbelot To: current ML Date: Sun, 25 May 2003 23:16:19 +0200 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305252316.19358.thierry@herbelot.com> Subject: Lock Order Reversal report X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 21:16:28 -0000 Hello, with a quite recent SMP -Current machine, I've seen a message reporting a LOR (the sources have been cvsup'ed around 07h00 GMT yesterday). in /var/log/messages : May 25 18:09:38 machine kernel: lock order reversal May 25 18:09:38 machine kernel: 1st 0xc409aa80 pcm0 (sound softc) @ /files3/src/sys/dev/sound/isa/mss.c:179 May 25 18:09:38 machine kernel: 2nd 0xc40aa200 pcm0:play:0 (pcm channel) @ /files3/src/sys/dev/sound/pcm/channel.c:440 idents of the incriminated files : machine% ident /files3/src/sys/dev/sound/isa/mss.c /files3/src/sys/dev/sound/isa/mss.c: $FreeBSD: src/sys/dev/sound/isa/mss.c,v 1.84 2003/02/07 14:05:33 nyan Exp $ machine% ident /files3/src/sys/dev/sound/pcm/channel.c /files3/src/sys/dev/sound/pcm/channel.c: $FreeBSD: src/sys/dev/sound/pcm/channel.c,v 1.88 2003/02/26 14:38:19 orion Exp $ machine% uname -a FreeBSD machine 5.1-BETA FreeBSD 5.1-BETA #21: Sat May 24 16:28:28 CEST 2003 rot@machine:/files3/obj/files3/src/sys/SMP i386 The machine is a BP6, with no ACPI (the BIOS seems to be broken in this regard) and the straight SMP kernel config file. Happy hacking TfH From owner-freebsd-current@FreeBSD.ORG Sun May 25 15:05:54 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3834037B401 for ; Sun, 25 May 2003 15:05:54 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C03A43F3F for ; Sun, 25 May 2003 15:05:53 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h4PM5pBA013567 for ; Mon, 26 May 2003 01:05:51 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h4PM5oUo013564 for ; Mon, 26 May 2003 01:05:51 +0300 (EEST) Date: Mon, 26 May 2003 01:05:50 +0300 (EEST) From: Narvi To: current@freebsd.org Message-ID: <20030526010359.D40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: 5.1 beta2 based freebsie ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 22:05:54 -0000 Anybody - esp the freebsie people of course - know if there are plans for a 5.1 beta2 based freebsie iso? or will it have to wait until 5.1 is released? From owner-freebsd-current@FreeBSD.ORG Sun May 25 15:29:58 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07D8337B401; Sun, 25 May 2003 15:29:58 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36C1D43F85; Sun, 25 May 2003 15:29:56 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4PMTtwk045387; Sun, 25 May 2003 15:29:55 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4PMTtrv001000; Sun, 25 May 2003 15:29:55 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h4PMTtF1000999; Sun, 25 May 2003 15:29:55 -0700 (PDT) Date: Sun, 25 May 2003 15:29:55 -0700 From: Marcel Moolenaar To: "Matthew N. Dodd" Message-ID: <20030525222955.GA826@athlon.pn.xcllnt.net> References: <20030525061524.H30007@sasami.jurai.net> <20030525084629.R30007@sasami.jurai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030525084629.R30007@sasami.jurai.net> User-Agent: Mutt/1.5.4i cc: Bang Jun-Young cc: current@freebsd.org Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 22:29:58 -0000 On Sun, May 25, 2003 at 09:03:24AM -0400, Matthew N. Dodd wrote: > > Relocatable objects (executables and libraries) contain elements that > require relocation before the are usable. In some cases this relocation > requires symbols to be located and resolved. Resolving these symbols and > performing the lookups imposes some execution overhead. By 'prebinding' > we can do as much of this work beforehand and speed up the actual > relocation process. How does prebinding and lazy binding interact? Lazy binding was introduced to solve the performance issue introduced with dynamic linking. Where lazy binding (or bind on reference) minimizes the runtime overhead by binding only those symbols that are actually used, prebinding seems to go the opposite direction (towards static linking) by avoiding the binding at runtime. > Now lets link test.c with lots of useless libraries: *snip* > normal: 14.003u 4.263s 0:23.14 78.9% 5+174k 0+0io 0pf+0w > prebind: 1.108u 3.231s 0:05.46 79.3% 6+182k 0+0io 0pf+0w > static: 0.000u 0.062s 0:00.15 40.0% 66+229k 0+0io 0pf+0w > > This is just a quick and dirty example mind you; I should really run > things with 10000 iterations and make execloop do its own timing > statistics etc. Interesting. However, it seems to me that prebinding is solving a problem it should not be solving. I would expect that the toolchain sanitizes the dependency list. Put differently, if I add a library to a link but none of the exported symbols are actually being referenced, then there's no dependency and the final shared object should not have that library recorded at all. The runtime overhead between a minimal link and a bloated link would then be minimal (there's always the chance of false positives). To explicitly state my standing on prebinding: I'm mostly un- convinced that it's something we need at this time. Patching the toolchain is considered a sin by me. Also, the footnote that it "only works for i386 for now" is getting annoying and to me only means that the testing results are too colored or biased to be useful. Some specific comments on the patch: o An OS specific segment type/name is expected to be prefixed by the os name to avoid collition. Thus: (type)PT_FREEBSD_BUILDID and (name)".freebsd.buildid". o The use of time and some random key is too adhoc and does not really provide the uniqueness one wants. Given that UUIDs have showed up in a lot of places not originally intended for UUIDs to show up, one might as well use UUIDs here. Make sure you nail down the byte order if you want to use UUIDs. o Of course the i386 specifics in the non-i386 specific file libexec/rtld-elf/prebind.c is something that clearly needs to be fixed. o The prebind cache file format is not sufficiently multi-platform nor does it handle collisions well enough (ie when different executables end up using the same cache file name). Have you thought about updating the executable itself? o The prebinding stuff will probably not work as-is ia64 (this is of course if we ignore the i386 specifics for a moment and look at the framework). If my cursory glance over the patch isn't deceiving me, we don't have the right information yet to deal with the function descriptors, which means that some of the runtime overhead is not properly resolved, and thus devaluating the usefulness of prebinding. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun May 25 15:39:11 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 631A537B401 for ; Sun, 25 May 2003 15:39:11 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A014143F85 for ; Sun, 25 May 2003 15:39:05 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h4PMcsQa086972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 25 May 2003 15:38:54 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h4PMcs9V063923; Sun, 25 May 2003 15:38:54 -0700 (PDT) (envelope-from jdp) Date: Sun, 25 May 2003 15:38:54 -0700 (PDT) Message-Id: <200305252238.h4PMcs9V063923@strings.polstra.com> To: current@freebsd.org From: John Polstra In-Reply-To: <20030525161307.41B4BB703@xmxpita.excite.com> References: <20030525161307.41B4BB703@xmxpita.excite.com> Organization: Polstra & Co., Seattle, WA X-Bogosity: No, tests=bogofilter, spamicity=0.460155, version=0.11.2 Subject: Re: FreeBSD 5.1 BETA 2 make cvsup-without-gui fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 22:39:11 -0000 In article <20030525161307.41B4BB703@xmxpita.excite.com>, hgjsdfkhfjkl wrote: > > after a fresh "kernel developer" install from the x86 5.1 beta 2 ISO, i > successfully configured the network and ping a domain name. Then I > attempted to install /usr/ports/net/cvsup-without-gui. This fails and > repeated attempts provide differing failures. output follows [...] > install -o root -g wheel -m 444 include/libcharset.h > /usr/ports/converters/libiconv/work/libiconv-1.8/lib/libcharset.h > cd lib && make all > /bin/sh ../libtool --mode=compile cc -I. -I. -I../include -I./../include > -O -pipe -mcpu=pentiumpro -c ./iconv.c > ../libtool: 1048: Syntax error: ";" unexpected > *** Error code 2 > > Stop in /usr/ports/converters/libiconv/work/libiconv-1.8/lib. > *** Error code 1 > > Stop in /usr/ports/converters/libiconv/work/libiconv-1.8. > *** Error code 1 > > Stop in /usr/ports/converters/libiconv. > *** Error code 1 > > Stop in /usr/ports/devel/gettext. > *** Error code 1 > > Stop in /usr/ports/devel/gmake. > *** Error code 1 > > Stop in /usr/ports/lang/ezm3. > *** Error code 1 > > Stop in /usr/ports/net/cvsup-without-gui. It's not the cvsup-without-gui port that's failing. It's the libiconv port, which is apparently required directly or indirectly by gmake. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying From owner-freebsd-current@FreeBSD.ORG Sun May 25 15:41:11 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 770BC37B401 for ; Sun, 25 May 2003 15:41:11 -0700 (PDT) Received: from cecov.masternet.it (cecov.masternet.it [194.184.65.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C7AD43F75 for ; Sun, 25 May 2003 15:41:10 -0700 (PDT) (envelope-from gmarco@scotty.masternet.it) Received: from usul.scotty.masternet.it (freebsd.giovannelli.com [194.184.65.139]) by cecov.masternet.it (8.12.9/8.12.9) with ESMTP id h4PMi42L004254; Mon, 26 May 2003 00:44:08 +0200 (CEST) (envelope-from gmarco@scotty.masternet.it) Message-Id: <5.2.1.1.2.20030526003728.023a6228@194.184.65.7> X-Sender: gmarco@194.184.65.7 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 26 May 2003 00:43:13 +0200 To: Narvi , current@freebsd.org From: Gianmarco Giovannelli In-Reply-To: <20030526010359.D40030-100000@haldjas.folklore.ee> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freesbie@gufi.org Subject: Re: 5.1 beta2 based freebsie ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 22:41:11 -0000 At 26/05/2003, Narvi wrote: >Anybody - esp the freebsie people of course - know if there are plans for >a 5.1 beta2 based freebsie iso? or will it have to wait until 5.1 is >released? I think you should ask in the right ml :-) You can reach the authors here: dave@gufi.org or saturnero@gufi.org. We have also a ml: freesbie@gufi.org please feel free to join (msg to: minimalist@gufi.org with subj: subscribe freesbie) ... it is in english and very quite ... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.gufi.org/~gmarco From owner-freebsd-current@FreeBSD.ORG Sun May 25 16:34:39 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82DBA37B40D for ; Sun, 25 May 2003 16:34:39 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF7D43F3F for ; Sun, 25 May 2003 16:34:38 -0700 (PDT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h4PNYb3q002471; Sun, 25 May 2003 19:34:37 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sun, 25 May 2003 19:34:37 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Marcel Moolenaar In-Reply-To: <20030525222955.GA826@athlon.pn.xcllnt.net> Message-ID: <20030525190744.A86964@sasami.jurai.net> References: <20030525061524.H30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 23:34:40 -0000 On Sun, 25 May 2003, Marcel Moolenaar wrote: > How does prebinding and lazy binding interact? If you look at rtld.c:relocate_objects() you'll see that the bind_now conditional controls the behavior that would affect lazy binding. The rtld.c:_rtld() entry function calls relocate_objects() to setup the initial objects; regardless of setting of the bind_now variable the work in relocate_objects() -must- be done. I have not yet performed testing to determine how much time the 'bind_now' behavior of prebinding takes. > Interesting. However, it seems to me that prebinding is solving a > problem it should not be solving. I would expect that the toolchain > sanitizes the dependency list. Put differently, if I add a library to a > link but none of the exported symbols are actually being referenced, > then there's no dependency and the final shared object should not have > that library recorded at all. The runtime overhead between a minimal > link and a bloated link would then be minimal (there's always the chance > of false positives). This doesn't seem to be the case, or if it is our rtld isn't taking advantage of any toolchain hints. All relocations in a shared libraries must be handled on the off chance that the program will dlopen() a shared object. > To explicitly state my standing on prebinding: I'm mostly un- convinced > that it's something we need at this time. Patching the toolchain is > considered a sin by me. Also, the footnote that it "only works for i386 > for now" is getting annoying and to me only means that the testing > results are too colored or biased to be useful. I'm not happy with having to patch the toolchain either. With respect to your complaints that the code is x86 centric; my plans are to continue working on the code and split it out into MI/MD bits. > o An OS specific segment type/name is expected to be prefixed by > the os name to avoid collition. Thus: (type)PT_FREEBSD_BUILDID > and (name)".freebsd.buildid". Maybe PT_BSD_BUILDID since it should be fairly easy to get this code running on the other BSD systems. > o The use of time and some random key is too adhoc and does not > really provide the uniqueness one wants. Given that UUIDs have > showed up in a lot of places not originally intended for UUIDs > to show up, one might as well use UUIDs here. Make sure you > nail down the byte order if you want to use UUIDs. I was more concerned with simplicity; the method I use solves the problem with minimal effort and complexity. The combination of time() + random() + filename will not collide on a single box. > o Of course the i386 specifics in the non-i386 specific file > libexec/rtld-elf/prebind.c is something that clearly needs to > be fixed. Of course. > o The prebind cache file format is not sufficiently multi-platform I'll be adding a platform identifier to the file header. All I'm concerned with is being able to reject a file if its not for the current platform. I have no expectation of cross-generating prebinding files. > nor does it handle collisions well enough (ie when different > executables end up using the same cache file name). This is actually handled. I'll likely change the format of the filenames as well. > Have you thought about updating the executable itself? Of course. I eliminated all the wrong/impossible methods of implementing prebinding. Having the prebinding cache file added as an ELF section was one of the first things I tried. :) > o The prebinding stuff will probably not work as-is ia64 (this is > of course if we ignore the i386 specifics for a moment and look > at the framework). If my cursory glance over the patch isn't > deceiving me, we don't have the right information yet to deal > with the function descriptors, which means that some of the > runtime overhead is not properly resolved, and thus devaluating > the usefulness of prebinding. My read of the ia64 code didn't reveal any major difficulties. Its possible that I'm missing something though. I'm most concerned about the sparc64 code. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | From owner-freebsd-current@FreeBSD.ORG Sun May 25 16:46:19 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65EC037B401 for ; Sun, 25 May 2003 16:46:19 -0700 (PDT) Received: from hotmail.com (bay8-f39.bay8.hotmail.com [64.4.27.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07F6B43F3F for ; Sun, 25 May 2003 16:46:19 -0700 (PDT) (envelope-from freebsd_stable@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 25 May 2003 16:46:19 -0700 Received: from 218.102.39.130 by by8fd.bay8.hotmail.msn.com with HTTP; Sun, 25 May 2003 23:46:18 GMT X-Originating-IP: [218.102.39.130] X-Originating-Email: [freebsd_stable@hotmail.com] From: "nobody nobody" To: mykroft@explosive.mail.net, david@catwhisker.org Date: Mon, 26 May 2003 07:46:18 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 May 2003 23:46:19.0016 (UTC) FILETIME=[D6B8C880:01C32317] cc: freebsd-current@freebsd.org Subject: Re: Radeon VE won't work with XFree4.3.0.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2003 23:46:19 -0000 >From: "Adam Maas" >To: "nobody nobody" , >CC: , >Subject: Re: Radeon VE won't work with XFree4.3.0.1 >Date: Sun, 25 May 2003 12:04:24 -0400 > > >Support for Video Cards is from X, rather than from FreeBSD, and the Radeon >VE is certainly supported, since I used to run a Radeon VE Dual Display >Edition 32MB (VGA+DVI+TV out) under XFree86 4.1 before I got my 8500. > >What kind of Monitor do you have plugged in, and what port are you using? > >Adam I am glad to know that Radeon VE is supported from X. Thanks. My monitor is a LCD. Sorry what is 'what port are you using?', I don't understand. Clarence _________________________________________________________________ No masks required! Use MSN Messenger to chat with friends and family. http://go.msnserver.com/HK/25382.asp From owner-freebsd-current@FreeBSD.ORG Sun May 25 17:17:36 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98D0937B401 for ; Sun, 25 May 2003 17:17:36 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [64.105.95.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id F03BC43F3F for ; Sun, 25 May 2003 17:17:35 -0700 (PDT) (envelope-from gshapiro@gshapiro.net) Received: from horsey.gshapiro.net (localhost [127.0.0.1]) h4Q0HZ47032560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 May 2003 17:17:35 -0700 (PDT) Received: (from gshapiro@localhost)h4Q0HYAf032559; Sun, 25 May 2003 17:17:34 -0700 (PDT) Date: Sun, 25 May 2003 17:17:34 -0700 From: Gregory Neil Shapiro To: Garrett Wollman Message-ID: <20030526001734.GB75037@horsey.gshapiro.net> References: <200305222116.h4MLGqK4097076@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305222116.h4MLGqK4097076@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.5.4i cc: current@FreeBSD.org Subject: Re: Would it be useful to ship an alternate submit.cf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 00:17:36 -0000 > It might be useful to include an alternate submit.cf that operates > more like nullclient.mc did in the pre-privsep world. Personally, I'd rather not offer yet another .mc/.cf file, especially given that we are only talking about changing one line from the existing .mc/.cf file. However, I am willing to document this alternative in etc/mail/README if that is desirable. From owner-freebsd-current@FreeBSD.ORG Sun May 25 17:19:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7AEC37B401; Sun, 25 May 2003 17:19:25 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9083E43F3F; Sun, 25 May 2003 17:19:24 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4Q0JOwk045838; Sun, 25 May 2003 17:19:24 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4Q0JOrv001357; Sun, 25 May 2003 17:19:24 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h4Q0JOcG001356; Sun, 25 May 2003 17:19:24 -0700 (PDT) Date: Sun, 25 May 2003 17:19:24 -0700 From: Marcel Moolenaar To: "Matthew N. Dodd" Message-ID: <20030526001924.GA1272@athlon.pn.xcllnt.net> References: <20030525061524.H30007@sasami.jurai.net> <20030525084629.R30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> <20030525190744.A86964@sasami.jurai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030525190744.A86964@sasami.jurai.net> User-Agent: Mutt/1.5.4i cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 00:19:26 -0000 On Sun, May 25, 2003 at 07:34:37PM -0400, Matthew N. Dodd wrote: > > > Interesting. However, it seems to me that prebinding is solving a > > problem it should not be solving. I would expect that the toolchain > > sanitizes the dependency list. Put differently, if I add a library to a > > link but none of the exported symbols are actually being referenced, > > then there's no dependency and the final shared object should not have > > that library recorded at all. The runtime overhead between a minimal > > link and a bloated link would then be minimal (there's always the chance > > of false positives). > > This doesn't seem to be the case, or if it is our rtld isn't taking > advantage of any toolchain hints. All relocations in a shared libraries > must be handled on the off chance that the program will dlopen() a shared > object. I'm not sure I understand what you mean. AFAICT, you only have to record dependencies if the shared objects are in the initial set of loadable objects (ie those that must be loaded at initial program load). It doesn't matter if the program itself loads additional shared objects. Also, I don't think dlopen() has any consequences for static linking. One does not have to provide libraries on the link line if they are only dlopen()'d. > > To explicitly state my standing on prebinding: I'm mostly un- convinced > > that it's something we need at this time. Patching the toolchain is > > considered a sin by me. Also, the footnote that it "only works for i386 > > for now" is getting annoying and to me only means that the testing > > results are too colored or biased to be useful. > > I'm not happy with having to patch the toolchain either. Do you know if the toolchain developers are working on this? > > o An OS specific segment type/name is expected to be prefixed by > > the os name to avoid collition. Thus: (type)PT_FREEBSD_BUILDID > > and (name)".freebsd.buildid". > > Maybe PT_BSD_BUILDID since it should be fairly easy to get this code > running on the other BSD systems. The EI_OSABI field in the ELF header (e_ident[]) defines the meaning of the OS specific extensions (in the same way the e_machine defines the CPU specific extension). Since ELFOSABI_NETBSD != ELFOSABI_FREEBSD != ELFOSABI_OPENBSD, we need to ensure that the segment type for prebinding is identical across the OSABIs if we want to share the name. It can be done, but I would not assume a priori that we'll succeed. I probably would stick to a FreeBSD specific name until there's complete buy-in. > > o The use of time and some random key is too adhoc and does not > > really provide the uniqueness one wants. Given that UUIDs have > > showed up in a lot of places not originally intended for UUIDs > > to show up, one might as well use UUIDs here. Make sure you > > nail down the byte order if you want to use UUIDs. > > I was more concerned with simplicity; the method I use solves the problem > with minimal effort and complexity. The combination of time() + random() > + filename will not collide on a single box. But it can across NFS, right? > > o The prebind cache file format is not sufficiently multi-platform > > I'll be adding a platform identifier to the file header. All I'm > concerned with is being able to reject a file if its not for the current > platform. I have no expectation of cross-generating prebinding files. Please keep that option open. Not only do we have to deal with byte- order on a single platform, we also have to keep an eye on emulation layers (ia32 on ia64 and ia32 on amd64). Decoupling the program from its prebinding information can create all sorts of nasty (ie unexpected) complexities. > > Have you thought about updating the executable itself? > > Of course. I eliminated all the wrong/impossible methods of implementing > prebinding. Having the prebinding cache file added as an ELF section was > one of the first things I tried. :) What are the major reasons for not editing the executable in your opinion? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun May 25 17:33:33 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F81637B401 for ; Sun, 25 May 2003 17:33:33 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31F0643F3F for ; Sun, 25 May 2003 17:33:32 -0700 (PDT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h4Q0XV3q004109; Sun, 25 May 2003 20:33:31 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sun, 25 May 2003 20:33:31 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Marcel Moolenaar In-Reply-To: <20030526001924.GA1272@athlon.pn.xcllnt.net> Message-ID: <20030525202140.Y86964@sasami.jurai.net> References: <20030525061524.H30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> <20030526001924.GA1272@athlon.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 00:33:33 -0000 On Sun, 25 May 2003, Marcel Moolenaar wrote: > > I was more concerned with simplicity; the method I use solves the problem > > with minimal effort and complexity. The combination of time() + random() > > + filename will not collide on a single box. > > But it can across NFS, right? Uh... If you want to share /var/db/prebind via NFS I suppose you can. I'm not sure how a practical NFS environment would result in a greater chance of collisions. Regardless, there is no real penalty for collisions (other than prebinding not being available for that executable.) > > I'll be adding a platform identifier to the file header. All I'm > > concerned with is being able to reject a file if its not for the current > > platform. I have no expectation of cross-generating prebinding files. > > Please keep that option open. Not only do we have to deal with byte- > order on a single platform, we also have to keep an eye on emulation > layers (ia32 on ia64 and ia32 on amd64). Its simply not possible to cross-generate prebinding files. Period. (You're of course welcome to implement a totally standalone utility that duplicates much of the functionality that rtld-elf provides.) > Decoupling the program from its prebinding information can create all > sorts of nasty (ie unexpected) complexities. Uh, what? I'm not parsing this. > What are the major reasons for not editing the executable in your > opinion? Besides it not working? It is not possible for rtld-elf to access the section header, let alone additional section data in a clean manner. Furthermore, rtld-elf is not provided with a valid file handle for the main executable so hacks to access section data of libraries won't actually work for the main executable. I ran around in circles until I'd figured all this out. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | From owner-freebsd-current@FreeBSD.ORG Sun May 25 18:37:37 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C61BC37B401 for ; Sun, 25 May 2003 18:37:37 -0700 (PDT) Received: from empire.explosive.mail.net (empire.explosive.mail.net [205.205.25.120]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A7F543F3F for ; Sun, 25 May 2003 18:37:36 -0700 (PDT) (envelope-from mykroft@explosive.mail.net) Received: (qmail 16495 invoked from network); 26 May 2003 01:37:03 -0000 Received: from ticking.explosive.mail.net (HELO ticking) (205.205.25.116) by empire.explosive.mail.net with SMTP; 26 May 2003 01:37:03 -0000 Message-ID: <12d201c32327$77a2a3b0$7419cdcd@ticking> From: "Adam Maas" To: "nobody nobody" , References: Date: Sun, 25 May 2003 21:38:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 cc: freebsd-current@freebsd.org Subject: Re: Radeon VE won't work with XFree4.3.0.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 01:37:38 -0000 ----- Original Message ----- From: "nobody nobody" To: ; Cc: Sent: Sunday, May 25, 2003 7:46 PM Subject: Re: Radeon VE won't work with XFree4.3.0.1 > > > > >From: "Adam Maas" > >To: "nobody nobody" , > >CC: , > >Subject: Re: Radeon VE won't work with XFree4.3.0.1 > >Date: Sun, 25 May 2003 12:04:24 -0400 > > > > > >Support for Video Cards is from X, rather than from FreeBSD, and the Radeon > >VE is certainly supported, since I used to run a Radeon VE Dual Display > >Edition 32MB (VGA+DVI+TV out) under XFree86 4.1 before I got my 8500. > > > >What kind of Monitor do you have plugged in, and what port are you using? > > > >Adam > > I am glad to know that Radeon VE is supported from X. Thanks. My monitor > is a LCD. Sorry what is 'what port are you using?', I don't understand. > > Clarence > DVI or VGA port. The DVI port is the larger, VGA is a 15pin port. I'd bet what's happening is X can't detect your LCD's specs properly. Adam Adam From owner-freebsd-current@FreeBSD.ORG Sun May 25 19:37:44 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E0FF37B401 for ; Sun, 25 May 2003 19:37:44 -0700 (PDT) Received: from hyperreal.net (marduk.tessellated.net [64.46.156.14]) by mx1.FreeBSD.org (Postfix) with SMTP id 88A2543F75 for ; Sun, 25 May 2003 19:37:43 -0700 (PDT) (envelope-from dkl@hyperreal.net) Received: (qmail 27498 invoked by uid 1009); 26 May 2003 02:37:42 -0000 Date: Sun, 25 May 2003 22:37:42 -0400 (EDT) From: John Dhmioyrgos X-X-Sender: John Dhmioyrgos To: mark tinguely In-Reply-To: <200305231520.h4NFKG2e030159@web.cs.ndsu.nodak.edu> Message-ID: <0305252222050.0.pimpmail@mailhub> References: <200305231520.h4NFKG2e030159@web.cs.ndsu.nodak.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: BCM5703 GigE ifs on Supermicro X5DL8-GG m/b not detected on5.1-BETA2 or 4.8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 02:37:44 -0000 http://www.teq.org/jd/pciwalk.out.clean.bz2 11M compressed. I'd suspect the bridge chips are being found, since each PCI-X slot is basically one bus and all of the addon cards in there come up. regards, John On Fri, 23 May 2003, mark tinguely wrote: > If FreeBSD 4.8 does not know about the ServerWorks PCI bridge chips, then > devices on the higher buses are not found. I am surprised that the ACPI > in FreeBSD 5.x did not find them though. > > If the PCI bridge chips are not being discovered, I know in FreeBSD 4.8 > we can add the entry. I am not a real expert in the ACPI code though in > FreeBSD 5.x. > > If you would do an extensive PCI bus search (with pciwalk script below), > it will tell us what the the PCI bridge chips, and which bus holds the > missing GigE card. > > ---pciwalk script--- > from() { > usage="usage: from to [by ]" > let i=${1?$usage} > let j=${3?$usage} > let k=${5-1} > > if (( i <=j )) ; then > while (( i<=j )) ; do > echo $i > let i=i+k > done > else > while (( i>=j )) ; do > echo $i > let i=i+k > done > fi > } > > > for pci in $(from 0 to 255); do > for slot in $(from 0 to 31); do > for func in $(from 0 to 15); do > zero=$(pciconf -r pci$pci:$slot:$func 0 | sed 's/ //g') > > [[ $zero = 0xffffffff ]] && { continue; } > [[ $zero = 0x00000000 ]] && { continue; } > > echo "$pci:$slot:$func 0 " :$zero: > > for addr in $(from 4 to 255 by 4); do > echo -n "$pci:$slot:$func $addr " > pciconf -r pci$pci:$slot:$func $addr > done | grep -v -e 0xffffffff -e 0x00000000 > done > done > done > --end pciwalk script-- > > --Mark Tinguely > From owner-freebsd-current@FreeBSD.ORG Sun May 25 19:40:03 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D54B837B401 for ; Sun, 25 May 2003 19:40:02 -0700 (PDT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id E530643F75 for ; Sun, 25 May 2003 19:40:01 -0700 (PDT) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au (210.50.252.147) by smtp01.syd.iprimus.net.au (7.0.015) id 3ECDA4450005D74E; Mon, 26 May 2003 12:39:58 +1000 Received: by dilbert.robbins.dropbear.id.au (Postfix, from userid 1000) id 39208C90F; Mon, 26 May 2003 12:39:54 +1000 (EST) Date: Mon, 26 May 2003 12:39:53 +1000 From: Tim Robbins To: Anthony Schneider Message-ID: <20030526123953.A91078@dilbert.robbins.dropbear.id.au> References: <20030525064929.GA96588@x-anthony.com> <20030525211730.GA5226@x-anthony.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030525211730.GA5226@x-anthony.com>; from anthony@x-anthony.com on Sun, May 25, 2003 at 05:17:30PM -0400 cc: freebsd-current@freebsd.org Subject: Re: mpi + shmem issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 02:40:03 -0000 On Sun, May 25, 2003 at 05:17:30PM -0400, Anthony Schneider wrote: > so, does this mean that mpich somehow exhausted all shmem locks? > after running the program only 10 times, i see this as infeasible, > considering > a) mpich (presumably in MPI_Init()) would only want 1 or > 2 locks on init > and > b) any shared memory locks mpich grabs should be freed > upon process completion (whether clean or not) by the > operating system, no? No, semaphores stay around until they are removed. Perhaps there's an MPI_Xyz function you should be calling before your program exits. In any case, you can use "ipcs -s" to list semaphores, and "ipcrm -s semid" to remove semaphores. It looks like the program is leaking semaphores -- notice how your program fails when you run it for the 11th time, and the default maximum number of semaphores in the GENERIC kernel is 10 (sysctl kern.ipc.semmni). Tim From owner-freebsd-current@FreeBSD.ORG Sun May 25 20:37:40 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 264F437B401 for ; Sun, 25 May 2003 20:37:40 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70CAE43FAF for ; Sun, 25 May 2003 20:37:39 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP id MUA74016; Sun, 25 May 2003 20:37:38 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D2F455D04; Sun, 25 May 2003 20:37:37 -0700 (PDT) To: "Jesse D. Guardiani" In-Reply-To: Message from "Jesse D. Guardiani" of "Sat, 24 May 2003 02:12:32 EDT." Date: Sun, 25 May 2003 20:37:37 -0700 From: "Kevin Oberman" Message-Id: <20030526033737.D2F455D04@ptavv.es.net> cc: freebsd-current@freebsd.org Subject: Re: 5.1-BETA2 FAILURE on IBM A30p Thinkpad X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 03:37:40 -0000 > From: "Jesse D. Guardiani" > Date: Sat, 24 May 2003 02:12:32 -0400 > Sender: owner-freebsd-current@freebsd.org > > > "Andre Guibert de Bruet" wrote in message > news:20030523145802.U75651@alpha.siliconlandmark.com... > > Jesse, > > > > IBM just released (As of 5/20/2003) a new version (1EET70WW (1.16)) of > > your laptop's BIOS. Could you update it and see if it helps any? > > These kernel panics still occur with the 1.16 BIOS. > > As an update, I have successfully installed 5.0-RELEASE on this laptop > without any kernel panics. However, neither ACPI or APM works. If I disable > ACPI then the kernel locks up right before it detects my keyboard > controller. > > I'm beginning to get discouraged. Does you r kernel configuration have: options DISABLE_PSE options DISABLE_PG_G I just discovered that a kernel built with these options will not boot on my ThinkPad T30 unless I remove APM. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Sun May 25 20:50:21 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14C2937B401 for ; Sun, 25 May 2003 20:50:21 -0700 (PDT) Received: from mx1.au.itouchnet.net (nat2.au.itouchnet.net [144.135.23.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9624043FB1 for ; Sun, 25 May 2003 20:50:19 -0700 (PDT) (envelope-from ajthomson@optushome.com.au) Received: from nobody by mx1.au.itouchnet.net with scanned_ok (Exim 3.36 #1) id 19K905-000GXo-00 for freebsd-current@freebsd.org; Mon, 26 May 2003 13:50:17 +1000 X-TLS: TLSv1:DES-CBC3-SHA:168 athomson.prv.au.itouchnet.net -> mx1.au.itouchnet.net Received: from athomson.prv.au.itouchnet.net ([192.168.13.55]) by mx1.au.itouchnet.net with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19K904-000GXh-00 for freebsd-current@freebsd.org; Mon, 26 May 2003 13:50:16 +1000 Received: from localhost ([127.0.0.1] helo=athomson.prv.au.itouchnet.net) by athomson.prv.au.itouchnet.net with esmtp (Exim 4.20) id 19K904-000Piq-Iu for freebsd-current@freebsd.org; Mon, 26 May 2003 13:50:16 +1000 Received: (from ajt@localhost)h4Q3oFjS098879 for freebsd-current@freebsd.org; Mon, 26 May 2003 13:50:15 +1000 (EST) X-Authentication-Warning: athomson.prv.au.itouchnet.net: ajt set sender to ajthomson@optushome.com.au using -f Date: Mon, 26 May 2003 13:50:15 +1000 From: Andrew Thomson To: freebsd-current@freebsd.org Message-ID: <20030526035015.GB98359@athomson.prv.au.itouchnet.net> References: <20030526033737.D2F455D04@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030526033737.D2F455D04@ptavv.es.net> User-Agent: Mutt/1.4.1i X-Checked: Scanned for any viruses and unauthorized attachments at mx1.au.itouchnet.net X-iScan-ID: 63596-1053921017-72905@mx1.au.itouchnet.net version $Name: REL_2_0_2 $ Subject: Re: 5.1-BETA2 FAILURE on IBM A30p Thinkpad X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 03:50:21 -0000 hmm, a common thread!! my ibm x24 is having serious issues with 5.1b2 as well!! ajt. On Sun, May 25, 2003 at 08:37:37PM -0700, Kevin Oberman wrote: > > From: "Jesse D. Guardiani" > > Date: Sat, 24 May 2003 02:12:32 -0400 > > Sender: owner-freebsd-current@freebsd.org > > > > > > "Andre Guibert de Bruet" wrote in message > > news:20030523145802.U75651@alpha.siliconlandmark.com... > > > Jesse, > > > > > > IBM just released (As of 5/20/2003) a new version (1EET70WW (1.16)) of > > > your laptop's BIOS. Could you update it and see if it helps any? > > > > These kernel panics still occur with the 1.16 BIOS. > > > > As an update, I have successfully installed 5.0-RELEASE on this laptop > > without any kernel panics. However, neither ACPI or APM works. If I disable > > ACPI then the kernel locks up right before it detects my keyboard > > controller. > > > > I'm beginning to get discouraged. > > Does you r kernel configuration have: > options DISABLE_PSE > options DISABLE_PG_G > > I just discovered that a kernel built with these options will not boot > on my ThinkPad T30 unless I remove APM. > > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun May 25 21:53:50 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6414537B401; Sun, 25 May 2003 21:53:50 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5A5C43F3F; Sun, 25 May 2003 21:53:49 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h4Q4rVM7086104; Sun, 25 May 2003 21:53:36 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200305260453.h4Q4rVM7086104@gw.catspoiler.org> Date: Sun, 25 May 2003 21:53:31 -0700 (PDT) From: Don Lewis To: drs@rucus.ru.ac.za, hrs@eos.ocn.ne.jp In-Reply-To: <20030523071506.GA546@rucus.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT cc: wpaul@FreeBSD.org cc: current@FreeBSD.org cc: matt@hasta.se Subject: Re: possible bug fix for 82550-based fxp packet truncation problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 04:53:50 -0000 On 23 May, Hiroki Sato wrote: > Don Lewis wrote > in <200305220823.h4M8N9M7075271@gw.catspoiler.org>: > > truckman> If you are using one of my previous patches which worked around the > truckman> problem by disabling the IPCB mode, you may want to try the patch below. > > This works fine in my environment. My fxp has the following id: > > fxp0@pci7:2:0: class=0x020000 card=0x10508086 chip=0x12298086 rev=0x0d hdr=0x00 > > Without any patches, packets whose size is 216+(N*1480) are dropped > as I reported on -stable before. Similarly I tried "ping -s X" with > various payload size from X=1 to X=6000 in the system using the > patched kernel, but no error is reported. > On 23 May, David Siebörger wrote: > At 10:23 AM on Thursday 22 May 2003, Don Lewis wrote: >> If you are using one of my previous patches which worked around the >> problem by disabling the IPCB mode, you may want to try the patch below. > > This patch seems to work just as well as the previous patch did on my > fxp's (card=0x00408086 chip=0x12298086 rev=0x0c). Thanks for testing my patch. I committed it with re approval on Sat, 24 May 2003 22:04:26 -0700 (PDT), in time for 5.1-RELEASE. From owner-freebsd-current@FreeBSD.ORG Sun May 25 22:24:39 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CFB437B401 for ; Sun, 25 May 2003 22:24:39 -0700 (PDT) Received: from hotmail.com (bay8-f7.bay8.hotmail.com [64.4.27.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBA2A43FCB for ; Sun, 25 May 2003 22:24:38 -0700 (PDT) (envelope-from freebsd_stable@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 25 May 2003 22:24:38 -0700 Received: from 218.102.39.130 by by8fd.bay8.hotmail.msn.com with HTTP; Mon, 26 May 2003 05:24:38 GMT X-Originating-IP: [218.102.39.130] X-Originating-Email: [freebsd_stable@hotmail.com] From: "nobody nobody" To: mykroft@explosive.mail.net, david@catwhisker.org Date: Mon, 26 May 2003 13:24:38 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 May 2003 05:24:38.0936 (UTC) FILETIME=[1A6AC180:01C32347] cc: freebsd-current@freebsd.org cc: freebsd_stable@hotmail.com Subject: Re: Radeon VE won't work with XFree4.3.0.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 05:24:39 -0000 >From: "Adam Maas" >To: "nobody nobody" , >CC: >Subject: Re: Radeon VE won't work with XFree4.3.0.1 >Date: Sun, 25 May 2003 21:38:11 -0400 > >----- Original Message ----- >From: "nobody nobody" >To: ; >Cc: >Sent: Sunday, May 25, 2003 7:46 PM >Subject: Re: Radeon VE won't work with XFree4.3.0.1 > > > > > > > > > > >From: "Adam Maas" > > >To: "nobody nobody" , > > >CC: , > > >Subject: Re: Radeon VE won't work with XFree4.3.0.1 > > >Date: Sun, 25 May 2003 12:04:24 -0400 > > > > > > > > >Support for Video Cards is from X, rather than from FreeBSD, and the >Radeon > > >VE is certainly supported, since I used to run a Radeon VE Dual Display > > >Edition 32MB (VGA+DVI+TV out) under XFree86 4.1 before I got my 8500. > > > > > >What kind of Monitor do you have plugged in, and what port are you >using? > > > > > >Adam > > > > I am glad to know that Radeon VE is supported from X. Thanks. My >monitor > > is a LCD. Sorry what is 'what port are you using?', I don't understand. > > > > Clarence > > > >DVI or VGA port. The DVI port is the larger, VGA is a 15pin port. I'd bet >what's happening is X can't detect your LCD's specs properly. > >Adam > >Adam > It is VGA port. From the /var/log/XFree86.0.log, I can find the monitor0 hsync 28 - 33 Hz vsync 43-72 Hz and the "600x480" mode with some figures for horizontal and verical frequency. I also tried to include this information into the XF86Config without any success. Any idea ? Clarence _________________________________________________________________ Get 10Mb extra storage for MSN Hotmail. Subscribe Now! http://join.msn.com/?pgmarket=en-hk From owner-freebsd-current@FreeBSD.ORG Sun May 25 22:31:22 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C08A37B401; Sun, 25 May 2003 22:31:22 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE9B143F3F; Sun, 25 May 2003 22:31:20 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4Q5VKwk046954; Sun, 25 May 2003 22:31:20 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4Q5VKrv002101; Sun, 25 May 2003 22:31:20 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h4Q5VKh5002100; Sun, 25 May 2003 22:31:20 -0700 (PDT) Date: Sun, 25 May 2003 22:31:20 -0700 From: Marcel Moolenaar To: "Matthew N. Dodd" Message-ID: <20030526053120.GB1941@athlon.pn.xcllnt.net> References: <20030525061524.H30007@sasami.jurai.net> <20030525084629.R30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> <20030525190744.A86964@sasami.jurai.net> <20030526001924.GA1272@athlon.pn.xcllnt.net> <20030525202140.Y86964@sasami.jurai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030525202140.Y86964@sasami.jurai.net> User-Agent: Mutt/1.5.4i cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 05:31:22 -0000 On Sun, May 25, 2003 at 08:33:31PM -0400, Matthew N. Dodd wrote: > On Sun, 25 May 2003, Marcel Moolenaar wrote: > > > I was more concerned with simplicity; the method I use solves the problem > > > with minimal effort and complexity. The combination of time() + random() > > > + filename will not collide on a single box. > > > > But it can across NFS, right? > > Uh... If you want to share /var/db/prebind via NFS I suppose you can. I was more thinking about having executables shared across machines, but it's not unthinkable to share prebind information. > I'm not sure how a practical NFS environment would result in a greater > chance of collisions. Regardless, there is no real penalty for collisions > (other than prebinding not being available for that executable.) Precisely. This links us back to my observation that collisions didn't appear to be handled well enough. Not being able to have prebinding for some executable because there's a name collision is what I call "not well enough". > > > I'll be adding a platform identifier to the file header. All I'm > > > concerned with is being able to reject a file if its not for the current > > > platform. I have no expectation of cross-generating prebinding files. > > > > Please keep that option open. Not only do we have to deal with byte- > > order on a single platform, we also have to keep an eye on emulation > > layers (ia32 on ia64 and ia32 on amd64). > > Its simply not possible to cross-generate prebinding files. Period. If you can cross-generate executables (by means of a cross-compiler, cross-assembler and cross-linker), then I don't see why you cannot cross-generate binding information (by means of a cross-prebinder). But before we miss the point: leaving the option open does not mean that you have to do it, just that you avoid making it impossible by not defining file layouts carefully enough. It also doesn't mean that you have to have the possibility against all odds. > (You're of course welcome to implement a totally standalone utility that > duplicates much of the functionality that rtld-elf provides.) Aren't we all welcome in that respect? :-) > > Decoupling the program from its prebinding information can create all > > sorts of nasty (ie unexpected) complexities. > > Uh, what? I'm not parsing this. The prebinding information lives under /var/db/prebind, right? I don't think we normally put our executables there as well and if we do, we don't have the prebind information *in* the executable. Hence, prebind information is decoupled from the executable. One of the more obvious complexities is the fact that the naming scheme is such that multiple binaries can have the same prebind cache file. The collision is currently not handled, other than making sure that the prebind information for binary A1 is not used by binary A2. But other complexities exist. What if by some unlucky draw of faith you have two totally independent executables that both resolve to the same prebind file *and* happen to have the same build ID? You have an undetectable collision. Before this point starts a whole argument of it's own: you already said that you wanted something simple to implement, so let it be noted that if you're at a point where you can productize this, you have to make sure that you have a good way to deal with it or otherwise clearly state somewhere why not. > > What are the major reasons for not editing the executable in your > > opinion? > > Besides it not working? I don't see why it cannot work. You have to explain to me why you cannot edit an executable. It may not be common, but it's done (HP-UX has chatr of example). > It is not possible for rtld-elf to access > the section header, let alone additional section data in a clean manner. It cannot be any more unclean than the ELF headers, segments and other data like the symbol table or relocation information are being accessed now, can't it? > Furthermore, rtld-elf is not provided with a valid file handle for the > main executable so hacks to access section data of libraries won't > actually work for the main executable. This is something the OS can provide by means of the AUXARGS. We already tell rtld where the base of the executable is (AFAICT), so we have a valid ELF header right at our fingertips. You don't need more. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun May 25 22:52:27 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CC3F37B401 for ; Sun, 25 May 2003 22:52:27 -0700 (PDT) Received: from onion.ish.org (onion.ish.org [219.118.161.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7112343F75 for ; Sun, 25 May 2003 22:52:26 -0700 (PDT) (envelope-from ishizuka@ish.org) Received: from localhost (ishizuka@localhost [IPv6:::1]) h4Q5qNaO013454; Mon, 26 May 2003 14:52:23 +0900 (JST) (envelope-from ishizuka@ish.org) Date: Mon, 26 May 2003 14:52:22 +0900 (JST) Message-Id: <20030526.145222.41631808.ishizuka@ish.org> To: scott_long@btc.adaptec.com From: Masachika ISHIZUKA In-Reply-To: <3ECDA2B5.2030106@btc.adaptec.com> References: <20030523.101245.74734696.ishizuka@ish.org> <3ECDA2B5.2030106@btc.adaptec.com> X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ X-Mailer: Mew version 3.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: 5.1-beta2 failed upgrade install X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 05:52:27 -0000 >> I want to upgrade from 5.1-BETA-20030522-JPSNAP to 5.1-BETA2 >> with CD-ROM (5.1-BETA2-i386-disc1.iso). > > Can you retry the test and type 'trace' at the db> prompt, then post > the results in an email? Hi, Scott-san. I upgraded from 5.1-BETA2 to 5.1-BETA2 for testing. The following message is displayed. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03046d3 stack pointer = 0x10:0xe16afaf0 frame pointer = 0x10:0xe16afb10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 34 (syncer) kernel: type 12 trap, code=0 Stopped at _mtx_lock_flags+0x43: cmpl $0xc05541ac,0(%ebx) db> trace _mtx_lock_flags(0,0,c05041bd,8eb,c05c40c8) at _mtx_lock_flags+0x43 vfs_setdirty(d4642588,c05041bd,e16afb70,c03047f0,c84725b4) at vfs_setdirty+0x79 vfs_busy_pages(d4642588,1,c05041bd,35e,c05c21c0) at vfs_busy_pages+0x59 bwrite(d4642588,e16afc14,c043b580,d4642588,d4d98000) at bwrite+0x305 bawrite(d4642588,d4d98000,800,800,0) at bawrite+0x1c ffs_sbupdate(c8453900,3,c05122d6,4b4,0) at ffs_sbupdate+0x110 ffs_sync(c82d5c00,3,c3ee7f00,c3f06ab0,c82d5c00) at ffs_sync+0x3c7 sync_fsync(e16afcd0,20002,c3f06ab0,6c6,0) at sync_fsync+0x16a sched_sync(0,e16afd48,c04fc5b7,2f8,0) at sched_sync+0x17e fork_exit(c0363c10,0,e16afd48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xe16afd7c, ebp = 0 --- db> ------------- dmesg is shown below ---------- 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.1-BETA2 #0: Tue May 20 16:08:27 GMT 2003 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b09000. Preloaded mfs_root "/boot/mfsroot" at 0xc0b09200. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2399326424 Hz CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2147483648 (2048 MB) avail memory = 2078687232 (1982 MB) Pentium Pro MTRR support enabled md0: Preloaded image 4423680 bytes at 0xc06cf3bc npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f2fb0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 2.0 on pci0 pci2: on pcib1 pci2: at device 28.0 (no driver attached) pcib2: at device 29.0 on pci2 pci4: on pcib2 em0: port 0xd800-0xd83f mem 0xfe9e0000-0xfe9fffff irq 9 at device 1.0 on pci4 em0: Speed:N/A Duplex:N/A pci2: at device 30.0 (no driver attached) pcib3: at device 31.0 on pci2 pci3: on pcib3 uhci0: port 0xe800-0xe81f irq 9 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib4: at device 30.0 on pci0 pci1: on pcib4 fxp0: port 0xc400-0xc43f mem 0xfe7a0000-0xfe7bffff,0xfe7fe000-0xfe7fefff irq 5 at device 1.0 on pci1 fxp0: Ethernet address 00:e0:81:25:ef:f6 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: at device 2.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) orm0: