From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 20:39:23 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBDED16A400 for ; Wed, 15 Mar 2006 20:39:23 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D8343D66 for ; Wed, 15 Mar 2006 20:39:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 687BD1A4E4B; Wed, 15 Mar 2006 12:39:23 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D1B92515BE; Wed, 15 Mar 2006 15:39:22 -0500 (EST) Date: Wed, 15 Mar 2006 15:39:22 -0500 From: Kris Kennaway To: JoaoBR Message-ID: <20060315203922.GA87806@xor.obsecurity.org> References: <200603140740.38388.joao@matik.com.br> <200603150601.26135.joao@matik.com.br> <20060315184606.GA85629@xor.obsecurity.org> <200603151728.35620.joao@matik.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <200603151728.35620.joao@matik.com.br> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: amd64 slower than i386 on identical AMD 64 system? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2006 20:39:23 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2006 at 05:28:35PM -0300, JoaoBR wrote: > On Wednesday 15 March 2006 15:46, Kris Kennaway wrote: > > > > OK. Just as a general point of common sense: when you find things > > that aren't enabled by default, there's almost always a good reason > > for this. > > > > Sometimes the reason is clear (driver conflicts with another driver, > > etc), but for secret poorly-documented options that change kernel > > behaviour it should ring warning bells that it might not be a good > > idea to just set and forget. > > >=20 > as well may exist good reason to check them out, if nobody checks this th= ings=20 > we never know about, right? Yes, but the problem is that you didn't stop and file a bug report when you learned of the problems (and then turn off the broken option), but instead wrote an email in which you made the broad claim that FreeBSD's SMP support was unstable. > > polling that is really the fault of ULE. > > >=20 > ok but I am not that stupid to try a prototype scheduler and then blaming= it=20 > for my mess >=20 > > > > It really sounds like it could be a broken BIOS on your system (check > > for upgrades). AFAIK, dual-core systems are not known to have these > > problems in general. > > >=20 > well, that was my first thought too but makes no sense if the same happen= s on=20 > several different brands, Why not? It is well-documented that many motherboards need BIOS updates to work correctly with dual-core CPUs. Kris --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEGHt6Wry0BWjoQKURAr76AKDOZCr7x+nv40X4LpvrHnHHGywxzACg7JXT z0CHu9W3aYn4TNq8YOckpnY= =c5ab -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW--