From owner-freebsd-amd64@FreeBSD.ORG Sun Mar 12 23:23:39 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 677BB16A400 for ; Sun, 12 Mar 2006 23:23:37 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from mail.migtel.ru (mail.migtel.ru [80.240.208.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02E9143D46 for ; Sun, 12 Mar 2006 23:23:36 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from mail.migtel.ru (unknown [194.154.84.11]) by mail.migtel.ru (Postfix) with ESMTP id 7990A4C1064 for ; Mon, 13 Mar 2006 02:23:35 +0300 (MSK) Received: from [10.20.5.22] (unknown [10.20.5.22]) by mail.migtel.ru (Postfix) with ESMTP for ; Mon, 13 Mar 2006 02:23:35 +0300 (MSK) Date: Mon, 13 Mar 2006 02:17:03 +0300 From: Oleg Rusanov X-Mailer: The Bat! (v3.65.03) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <1267011631.20060313021703@molecon.ru> To: freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on Free.migtel.ru Subject: grep -R 'zlib' /usr/ports/ crashed server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2006 23:23:39 -0000 amd64# uname -prs FreeBSD 6.0-RELEASE-p5 amd64 -- Regards, Oleg mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 00:44:00 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 6DDF516A400 for ; Mon, 13 Mar 2006 00:43:59 +0000 (GMT) (envelope-from erlester@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0409643D48 for ; Mon, 13 Mar 2006 00:43:57 +0000 (GMT) (envelope-from erlester@gmail.com) Received: by zproxy.gmail.com with SMTP id x7so1126986nzc for ; Sun, 12 Mar 2006 16:43:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jpmvgaUui77qNLXkcFhBcoA3rSirsvLoNz36QIe6ekhkHI0w0PybEnAqdv/0OLHqd5bmVuB3rgY0ivdgciuBCLTWCzI3u2r9aFWVp+SAqb7S1240SWJ62WIuOBrN+vxo8NXAUQqZOLZ9yjrm0eSDByV2DSi30eZREbrSAPlm54U= Received: by 10.65.150.16 with SMTP id c16mr1841864qbo; Sun, 12 Mar 2006 16:43:57 -0800 (PST) Received: by 10.65.200.16 with HTTP; Sun, 12 Mar 2006 16:43:57 -0800 (PST) Message-ID: Date: Mon, 13 Mar 2006 11:43:57 +1100 From: "Erle Pereira" To: freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: boot problem: turion '64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 00:44:00 -0000 been trying to install freebsd 6.0 release Config is as follows: model: acer aspire 5002nwlmi Chip : AMD Turion 64 (ML-30) SIS chipset ( i know.. but.. was the only one in budget!) -- OS: Dual Boot with debian sarge (amd 64 port) booting freebsd thru` grub from debian partition -- with -- title FreeBSD 6.0 root (hd0,3,a) kernel /boot/loader -- Installs fine. Without errors. But then when trying to boot, the system freezes. I am unable to get even the loader prompt. Console is garbled with random colors... Been through this twice. Same exact outcome in both. Im out of ideas. Any suggestions as to what do i do next? -Erle From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 00:47:53 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 0FA9216A401 for ; Mon, 13 Mar 2006 00:47:52 +0000 (GMT) (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 C842343D46 for ; Mon, 13 Mar 2006 00:47:51 +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 AEE0F1A4DA8; Sun, 12 Mar 2006 16:47:51 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7F2BA51CF4; Sun, 12 Mar 2006 19:47:50 -0500 (EST) Date: Sun, 12 Mar 2006 19:47:50 -0500 From: Kris Kennaway To: Oleg Rusanov Message-ID: <20060313004749.GA46647@xor.obsecurity.org> References: <1267011631.20060313021703@molecon.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <1267011631.20060313021703@molecon.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: grep -R 'zlib' /usr/ports/ crashed server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 00:47:53 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 13, 2006 at 02:17:03AM +0300, Oleg Rusanov wrote: >=20 > amd64# uname -prs > FreeBSD 6.0-RELEASE-p5 amd64 Please explain Kris --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEFME1Wry0BWjoQKURAks6AJ9V4rL6oz2hGYxW+4b2jHenzs/XXQCgnYKF eB60711MhW3N2qPUpT9i0D4= =NWUr -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 03:40:30 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 7D76E16A400 for ; Mon, 13 Mar 2006 03:40:30 +0000 (UTC) (envelope-from Robin.Liu@amd.com) Received: from amdext4.amd.com (amdext4.amd.com [163.181.251.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6CC943D48 for ; Mon, 13 Mar 2006 03:40:29 +0000 (GMT) (envelope-from Robin.Liu@amd.com) Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k2D3eTif025948 for ; Sun, 12 Mar 2006 21:40:29 -0600 Received: from 163.181.22.101 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Sun, 12 Mar 2006 21:40:20 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from sausexmb1.amd.com ([163.181.3.156]) by sausexbh1.amd.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Mar 2006 19:40:20 -0800 Received: from ssuzexmb3.amd.com ([165.204.233.99]) by sausexmb1.amd.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Mar 2006 21:40:20 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 13 Mar 2006 11:40:17 +0800 Message-ID: <60F1B0FC76F1504A91839905DA7EBDB603903C@ssuzexmb3.amd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NUMA and Dual-Core Support Thread-Index: AcZGT9hFhq/A8A4RTNC9roaO67dgjQ== From: "Liu, Robin" To: freebsd-amd64@freebsd.org X-OriginalArrivalTime: 13 Mar 2006 03:40:20.0344 (UTC) FILETIME=[DA2DE780:01C6464F] X-WSS-ID: 680A362E1VK7584209-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NUMA and Dual-Core Support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 03:40:30 -0000 SGksDQoNCkFzIHdlIGtub3cgRnJlZUJTRCBzdXBwb3J0IFNNUCBidXQgZG8gbm90IHN1cHBvcnQg TlVNQSB0ZWNobm9sb2d5IG5vdywgaXMgdGhlcmUgYW55IHBsYW4gdG8gbWFrZSBGcmVlQlNEIHN1 cHBvcnQgTlVNQT8gQW5kIGZyb20gd2hpY2ggdmVyc2lvbiBvbj8NCg0KQlRXLCBjb3VsZCBhbnli b2R5IHRlbGwgbWUgd2hpY2ggaXMgdGhlIG9sZGVzdCB2ZXJzaW9uIG9mIEZyZWVCU0QgdG8gc3Vw cG9ydCB0aGUgZHVhbC1jb3JlIHByb2Nlc3Nvcj8NCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KUm9i aW4NCg0K From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 07:06:08 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 6211316A400 for ; Mon, 13 Mar 2006 07:06:08 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from efacilitas.de (smtp.efacilitas.de [85.10.196.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id F22FB43D46 for ; Mon, 13 Mar 2006 07:06:07 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-169-72.dynamic.qsc.de [212.202.169.72]) by efacilitas.de (Postfix) with ESMTP id A343B4AE46; Mon, 13 Mar 2006 08:16:41 +0100 (CET) Received: from [192.168.1.2] (muhkuh.local [192.168.1.2]) by eurystheus.local (Postfix) with ESMTP id 5D3055285B; Mon, 13 Mar 2006 08:05:59 +0100 (CET) Message-ID: <441519DD.1010301@cs.tu-berlin.de> Date: Mon, 13 Mar 2006 08:06:05 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Oleg Rusanov References: <1267011631.20060313021703@molecon.ru> In-Reply-To: <1267011631.20060313021703@molecon.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-amd64@freebsd.org Subject: Re: grep -R 'zlib' /usr/ports/ crashed server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 07:06:08 -0000 An unclean filesystem could be the reason for this problem. I had this several times. I suggest to run fsck *not* using background fsck in this case. Björn From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 08:18:01 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 E0FE916A41F for ; Mon, 13 Mar 2006 08:18:01 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from fri.itea.ntnu.no (fri.itea.ntnu.no [129.241.7.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A97143D53 for ; Mon, 13 Mar 2006 08:18:00 +0000 (GMT) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by fri.itea.ntnu.no (Postfix) with ESMTP id 51D7E80E6 for ; Mon, 13 Mar 2006 09:17:59 +0100 (CET) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by fri.itea.ntnu.no (Postfix) with ESMTP for ; Mon, 13 Mar 2006 09:17:59 +0100 (CET) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id 0B9D0CFF14; Mon, 13 Mar 2006 09:17:59 +0100 (CET) Date: Mon, 13 Mar 2006 09:17:59 +0100 From: Ulf Lilleengen To: freebsd-amd64@freebsd.org Message-ID: <20060313081758.GA29260@stud.ntnu.no> References: <60F1B0FC76F1504A91839905DA7EBDB603903C@ssuzexmb3.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60F1B0FC76F1504A91839905DA7EBDB603903C@ssuzexmb3.amd.com> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Subject: Re: NUMA and Dual-Core Support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 08:18:02 -0000 On man, mar 13, 2006 at 11:40:17 +0800, Liu, Robin wrote: > BTW, could anybody tell me which is the oldest version of FreeBSD to support the dual-core processor? The oldest version of FreeBSD to take use of SMPng would be 5.0, but you wouldn't want to run anything below 5.5/6.0 for this right now anywaw. Other than that, the dual-core processors should be visible as two processors to the OS, so it should work on older versions such as 4.x as well. -- Mvh Ulf Lilleengen From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 11:00:08 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 A430416A400 for ; Mon, 13 Mar 2006 11:00:08 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF14143D46 for ; Mon, 13 Mar 2006 11:00:07 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by uproxy.gmail.com with SMTP id q2so631798uge for ; Mon, 13 Mar 2006 03:00:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=obQjpxA0Jkuuajo1J28ONKPoyTEZTnzC6Yv32Hmd2OaOONcck5eQV+HfbmBt+611PvbTCOlbYGjcJecblr0NPm7hX8LoFbniwRBdCRqw7tXV3MKt8tsELByva8EHx5CzZn6cHR3hH+Gw9qLtG0WX/kfLCae8w4DWo9QXw5EGetM= Received: by 10.66.254.4 with SMTP id b4mr352177ugi; Mon, 13 Mar 2006 03:00:06 -0800 (PST) Received: by 10.66.236.1 with HTTP; Mon, 13 Mar 2006 03:00:06 -0800 (PST) Message-ID: <2fd864e0603130300m12a02932tb82c3c5fa4ac1973@mail.gmail.com> Date: Mon, 13 Mar 2006 20:00:06 +0900 From: Astrodog To: freebsd-amd64@freebsd.org In-Reply-To: <2fd864e0603130256l52f5b0aoa5e2a4c720aa3e10@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <60F1B0FC76F1504A91839905DA7EBDB603903C@ssuzexmb3.amd.com> <2fd864e0603130256l52f5b0aoa5e2a4c720aa3e10@mail.gmail.com> Subject: Fwd: NUMA and Dual-Core Support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 11:00:08 -0000 ---------- Forwarded message ---------- From: Astrodog Date: Mar 13, 2006 7:56 PM Subject: Re: NUMA and Dual-Core Support To: "Liu, Robin" On 3/13/06, Liu, Robin wrote: > Hi, > > As we know FreeBSD support SMP but do not support NUMA technology now, is= there any plan to make FreeBSD support NUMA? And from which version on? > > BTW, could anybody tell me which is the oldest version of FreeBSD to supp= ort the dual-core processor? > I am (As I get time) working on adding some NUMA awareness to ULE. Mostly, this effort isn`t focused on real NUMA installations, but on optimizing FreeBSD for use with Opterons where there is a penalty for accessing remote memory (Attached to another socket). After discussing it with some people though.... it appears to be the same project, just different weighting in memory allocation and scheduling --- Harrison Grundy From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 11:02:27 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 AC22116A435 for ; Mon, 13 Mar 2006 11:02:27 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E376943D5E for ; Mon, 13 Mar 2006 11:02:23 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2DB2Np2097560 for ; Mon, 13 Mar 2006 11:02:23 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2DB2Mwh097554 for freebsd-amd64@freebsd.org; Mon, 13 Mar 2006 11:02:22 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Mar 2006 11:02:22 GMT Message-Id: <200603131102.k2DB2Mwh097554@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 11:02:27 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/08/09] amd64/84693 amd64 Keyboard not recognized during first step o [2005/11/17] amd64/89202 amd64 [ufs] [panic] Kernel crash when accessing o [2006/03/01] amd64/93961 amd64 Problem in bounce buffer handling in sys/ 3 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/07/28] amd64/69704 amd64 ext2/ext3 unstable in amd64 o [2004/07/28] amd64/69707 amd64 IPC32 dont work OK in amd64 FreeBSD o [2004/09/07] amd64/71471 amd64 Can not install 5.3beta3/amd64 on IBM eSe o [2004/09/12] amd64/71644 amd64 [panic] amd64 5.3-BETA4 crash when heavy o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see o [2004/10/30] amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdo o [2004/11/07] amd64/73650 amd64 5.3-release panics on boot o [2004/11/10] amd64/73775 amd64 Kernel panic (trap 12) when booting with o [2004/11/16] amd64/74014 amd64 5.3-RELEASE-AMD64 freezes on boot during o [2004/12/05] amd64/74747 amd64 System panic on shutdown when process wil o [2004/12/18] amd64/75209 amd64 5.3-Release panics on attempted boot from o [2004/12/23] amd64/75417 amd64 ACPI: SATA Hard-disk o [2005/01/12] amd64/76136 amd64 system halts before reboot o [2005/01/17] amd64/76336 amd64 racoon/setkey -D cases instant "Fatal Tra o [2005/02/02] amd64/77011 amd64 consisten 5.3-p5 make crash on installwor o [2005/02/23] amd64/77949 amd64 Pb boot FreeBSD 64 o [2005/03/04] amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/p o [2005/03/07] amd64/78558 amd64 installation o [2005/03/14] amd64/78848 amd64 [sis] sis driver on FreeBSD 5.x does not o [2005/04/12] amd64/79813 amd64 Will not install/run on amd64 nForce 4 pl o [2005/04/19] amd64/80114 amd64 kldload snd_ich causes interrupt storm wh o [2005/05/06] amd64/80691 amd64 amd64 kernel hangs on load o [2005/05/14] amd64/81037 amd64 SATA problem o [2005/05/28] amd64/81602 amd64 SATA crashes with parallel pcm access o [2005/06/09] amd64/82071 amd64 incorrect -march's parameter to build 32b o [2005/06/19] amd64/82425 amd64 [fxp] fxp0: device timeout, fxp interface o [2005/06/23] amd64/82555 amd64 Kernel Panic - after i connect to my "amd o [2005/07/05] amd64/83005 amd64 Memory Occupied during installation of th o [2005/08/12] amd64/84832 amd64 Installation crashes just at boot AMD64/ o [2005/08/14] amd64/84930 amd64 [msdosfs] something wrong with msdosfs on o [2005/08/29] amd64/85431 amd64 AMD64 has short but temporary freezes (ha o [2005/08/29] amd64/85451 amd64 [hang] 6.0-BETA3 lockups on AMD64 (PREEMP o [2005/09/13] amd64/86080 amd64 [radeon] [hang] radeon DRI causes system o [2005/09/23] amd64/86503 amd64 [atapicam] [panic] k3b crash the system l o [2005/10/09] amd64/87156 amd64 First Installation: Kernel crashes o [2005/10/11] amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Are o [2005/10/12] amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powe o [2005/10/12] amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD a [2005/10/12] amd64/87328 amd64 [boot] BTX halted error o [2005/10/12] amd64/87348 amd64 amd64+smp+startkde always crashing o [2005/10/15] amd64/87472 amd64 I downloaded 5.4 and went to install it, o [2005/10/16] amd64/87514 amd64 6.0-CURRENT freezes machine using >4GB on o [2005/10/19] amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron o [2005/10/25] amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock c o [2005/10/31] amd64/88299 amd64 swapcontext fails with errno 0 o [2005/11/06] amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not b f [2005/11/09] amd64/88746 amd64 Buffer problem with SSH2 under amd64 arch o [2005/11/10] amd64/88790 amd64 kernel panic on first boot (after the Fre o [2005/11/24] amd64/89501 amd64 System crashes on install using ftp on lo o [2005/11/24] amd64/89503 amd64 Cant Boot Installation Disk o [2005/11/25] amd64/89546 amd64 [geom] GEOM error o [2005/11/25] amd64/89549 amd64 [amd64] nve timeouts on 6.0-release o [2005/11/25] amd64/89550 amd64 [amd64] sym0: VTOBUS failed (6.0 Release) o [2005/12/05] amd64/89968 amd64 [ata] Asus A8N-E MediaShield RAID problem o [2005/12/22] amd64/90798 amd64 asking if motherboard is compatible o [2006/01/06] amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr o [2006/01/08] amd64/91492 amd64 BTX halted o [2006/01/26] amd64/92337 amd64 FreeBsd 6.0 Release Intel Pro 1000 MT em1 o [2006/02/06] amd64/92889 amd64 xdr double buffer overflow o [2006/02/07] amd64/92991 amd64 FreeBSD(amd64) freezes when primary disk o [2006/02/08] amd64/93065 amd64 Running make depend on GENERIC kernel fai o [2006/02/14] amd64/93325 amd64 mount_ufs fails mounting Nero UFS DVD+RW o [2006/02/16] amd64/93413 amd64 lpd does not remove lock file from /var/s o [2006/02/17] amd64/93469 amd64 uninitialised struct stat in lpd prevents 65 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/01/11] amd64/61209 amd64 ppc0: cannot reserve I/O port range o [2004/02/21] amd64/63188 amd64 [ti] ti(4) broken on amd64 o [2004/07/28] amd64/69705 amd64 IPC problem (msq_queues) o [2004/12/02] amd64/74608 amd64 [mpt] [hang] mpt hangs 5 minutes when boo o [2004/12/07] amd64/74811 amd64 [nfs] df, nfs mount, negative Avail -> 32 o [2004/12/13] ports/75015 amd64 cvsup on amd64 coredumps with either runs o [2005/03/17] amd64/78954 amd64 kerberos 5 failed to build o [2005/06/18] amd64/82399 amd64 MSI K8N Neo4 Platinium is not supported o [2005/08/07] amd64/84652 amd64 kbdmap -r dumps core o [2005/08/20] amd64/85144 amd64 Asus K8S-MX mobo, integ LAN not recognize o [2005/09/06] amd64/85812 amd64 "Rebooting..." on serial console appears o [2005/09/07] amd64/85820 amd64 1.5 times slower performance with SCHED_U o [2005/10/23] amd64/87882 amd64 emu10k1 and APCI on amd64 is just noisy o [2005/11/09] amd64/88730 amd64 kernel panics during booting from the ins o [2006/01/02] amd64/91195 amd64 FreeBSD 6.0(amd64) and Asus A8R-MVP o [2006/01/30] amd64/92527 amd64 no driver for "CICADA VSC 8201 Gigabit LA o [2006/02/07] amd64/93002 amd64 amd64 (6.0) coredumps at unpredictable ti o [2006/02/09] amd64/93090 amd64 NIC on GA-K8NF-9 motherboard is recognize o [2006/02/28] amd64/93930 amd64 Page fault on `kldunload snd_driver` o [2006/03/10] amd64/94295 amd64 DVD instead of CDs 20 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 11:23:55 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 1C70E16A486 for ; Mon, 13 Mar 2006 11:23:55 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 487FA43D4C for ; Mon, 13 Mar 2006 11:23:53 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2DBNpba081552; Mon, 13 Mar 2006 08:23:51 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-amd64@freebsd.org Date: Mon, 13 Mar 2006 08:23:35 -0300 User-Agent: KMail/1.9.1 References: <60F1B0FC76F1504A91839905DA7EBDB603903C@ssuzexmb3.amd.com> <2fd864e0603130256l52f5b0aoa5e2a4c720aa3e10@mail.gmail.com> <2fd864e0603130300m12a02932tb82c3c5fa4ac1973@mail.gmail.com> In-Reply-To: <2fd864e0603130300m12a02932tb82c3c5fa4ac1973@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603130823.35433.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Fwd: NUMA and Dual-Core Support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 11:23:56 -0000 On Monday 13 March 2006 08:00, Astrodog wrote: > > I am (As I get time) working on adding some NUMA awareness to ULE. > Mostly, this effort isn`t focused on real NUMA installations, but on > optimizing FreeBSD for use with Opterons where there is a penalty for > accessing remote memory (Attached to another socket). After discussing > it with some people though.... it appears to be the same project, just > different weighting in memory allocation and scheduling > Is the memory access with dual-core (not HT) the the same as with=20 dual-processores? Would NUMA have any impact on dual-cores? Since you touched ULE, do you think using ULE on dual-core would have some= =20 benefit? Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 12:00:30 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 AE91216A424 for ; Mon, 13 Mar 2006 12:00:29 +0000 (UTC) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (tourist.net8.nerim.net [213.41.176.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DEBE43D45 for ; Mon, 13 Mar 2006 12:00:28 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (localhost [127.0.0.1]) by sockar.homeip.net (8.13.3/8.13.3) with ESMTP id k2DBq50E027632; Mon, 13 Mar 2006 12:52:05 +0100 (CET) (envelope-from amon@sockar.homeip.net) Received: (from amon@localhost) by sockar.homeip.net (8.13.3/8.13.3/Submit) id k2DBq5xV027631; Mon, 13 Mar 2006 12:52:05 +0100 (CET) (envelope-from amon) Date: Mon, 13 Mar 2006 12:52:05 +0100 From: Herve Boulouis To: JoaoBR Message-ID: <20060313115205.GA17399@ra.aabs> References: <60F1B0FC76F1504A91839905DA7EBDB603903C@ssuzexmb3.amd.com> <2fd864e0603130256l52f5b0aoa5e2a4c720aa3e10@mail.gmail.com> <2fd864e0603130300m12a02932tb82c3c5fa4ac1973@mail.gmail.com> <200603130823.35433.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200603130823.35433.joao@matik.com.br> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: Fwd: NUMA and Dual-Core Support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 12:00:30 -0000 Le 13/03/2006 08:23, JoaoBR a écrit: > > Is the memory access with dual-core (not HT) the the same as with > dual-processores? Would NUMA have any impact on dual-cores? Since the memory controller is shared between the 2 cores on dual core opterons, I doubt you'll see any benefits on memory accesses with a NUMA aware scheduler. -- Herve Boulouis From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 13:54:36 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 9F80316A41F for ; Mon, 13 Mar 2006 13:54:36 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCAB543D70 for ; Mon, 13 Mar 2006 13:54:31 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Mon, 13 Mar 2006 08:54:31 -0500 id 0005644F.44157997.000080A2 Date: Mon, 13 Mar 2006 08:54:31 -0500 From: Bill Moran To: freebsd-amd64@freebsd.org Message-Id: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bseklecki@collaborativefusion.com Subject: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 13:54:36 -0000 We've got some dell servers (Poweredge 2850 is specifically what the following tests were run on). Some of the behaviour we're seeing was unexpected. In particular, I'm rather fuzzy as to how an amd64 kernel handles hyperthreading. (Personally, I'm also a little fuzzy on whether this really is hyperthreading under amd64 at all) After building a kernel with SMP, I do see 2 logical processors, and top(1) shows both of them doing their thing. However, machdep.hypterthreading_allowed is set to 0. Is the amd64 kernel ignoring this value, or is top(1) reporting incorrectly? Additionally, I'm not seeing the performance I'm accustomed to on hypterthreaded machines. Usually, throughput scales when hyperthreading is enabled and more than one process are fighting for CPU. In my tests, it seems as if there is no scaling whatsoever. i.e.: On a standard hyperthreaded machine, running 1 ubench might yield a CPU value of 100,000. Running two ubench simultaneously will usually result in each of them returning ~90,000 or so. With the amd64, I end up with each one around 50,000 - as if there were no second logical CPU (despite the fact that top(1) shows both in use). dmesg attached. I can provide more information on request. -- Bill Moran Collaborative Fusion Inc. Mar 10 15:08:51 kernel: Copyright (c) 1992-2005 The FreeBSD Project. Mar 10 15:08:51 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 10 15:08:51 kernel: The Regents of the University of California. All rights reserved. Mar 10 15:08:51 kernel: FreeBSD 6.0-RELEASE #0: Wed Nov 2 19:07:38 UTC 2005 Mar 10 15:08:51 kernel: root@rat.samsco.home:/usr/obj/usr/src/sys/GENERIC Mar 10 15:08:51 kernel: ACPI APIC Table: Mar 10 15:08:51 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 10 15:08:51 kernel: CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) Mar 10 15:08:51 kernel: Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Mar 10 15:08:51 kernel: Features=0xbfebfbff Mar 10 15:08:51 kernel: Features2=0x641d> Mar 10 15:08:51 kernel: AMD Features=0x20000800 Mar 10 15:08:51 kernel: Hyperthreading: 2 logical CPUs Mar 10 15:08:51 kernel: real memory = 2147221504 (2047 MB) Mar 10 15:08:51 kernel: avail memory = 2063126528 (1967 MB) Mar 10 15:08:51 kernel: ioapic0: Changing APIC ID to 2 Mar 10 15:08:51 kernel: ioapic1: Changing APIC ID to 3 Mar 10 15:08:51 kernel: ioapic1: WARNING: intbase 32 != expected base 24 Mar 10 15:08:51 kernel: ioapic2: Changing APIC ID to 4 Mar 10 15:08:51 kernel: ioapic2: WARNING: intbase 64 != expected base 56 Mar 10 15:08:51 kernel: ioapic3: Changing APIC ID to 5 Mar 10 15:08:51 kernel: ioapic3: WARNING: intbase 96 != expected base 88 Mar 10 15:08:51 kernel: ioapic0 irqs 0-23 on motherboard Mar 10 15:08:51 kernel: ioapic1 irqs 32-55 on motherboard Mar 10 15:08:51 kernel: ioapic2 irqs 64-87 on motherboard Mar 10 15:08:51 kernel: ioapic3 irqs 96-119 on motherboard Mar 10 15:08:51 kernel: acpi0: on motherboard Mar 10 15:08:51 kernel: acpi0: Power Button (fixed) Mar 10 15:08:51 kernel: pci_link0: irq 11 on acpi0 Mar 10 15:08:51 kernel: pci_link1: irq 3 on acpi0 Mar 10 15:08:51 kernel: pci_link2: irq 7 on acpi0 Mar 10 15:08:51 kernel: pci_link3: irq 10 on acpi0 Mar 10 15:08:51 kernel: pci_link4: on acpi0 Mar 10 15:08:51 kernel: pci_link5: on acpi0 Mar 10 15:08:51 kernel: pci_link6: on acpi0 Mar 10 15:08:51 kernel: pci_link7: irq 5 on acpi0 Mar 10 15:08:51 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 10 15:08:51 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Mar 10 15:08:51 kernel: cpu0: on acpi0 Mar 10 15:08:51 kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 10 15:08:51 kernel: pci0: on pcib0 Mar 10 15:08:51 kernel: pcib1: at device 2.0 on pci0 Mar 10 15:08:51 kernel: pci1: on pcib1 Mar 10 15:08:51 kernel: pcib2: at device 0.0 on pci1 Mar 10 15:08:51 kernel: pci2: on pcib2 Mar 10 15:08:51 kernel: amr0: mem 0xd80f0000-0xd80fffff,0xdfdc0000-0xdfdfffff irq 46 at device 14.0 on pci2 Mar 10 15:08:51 kernel: amr0: Firmware 513O, BIOS H418, 256MB RAM Mar 10 15:08:51 kernel: pcib3: at device 0.2 on pci1 Mar 10 15:08:51 kernel: pci3: on pcib3 Mar 10 15:08:51 kernel: pcib4: at device 4.0 on pci0 Mar 10 15:08:51 kernel: pci4: on pcib4 Mar 10 15:08:51 kernel: pcib5: at device 5.0 on pci0 Mar 10 15:08:51 kernel: pci5: on pcib5 Mar 10 15:08:51 kernel: pcib6: at device 0.0 on pci5 Mar 10 15:08:51 kernel: pci6: on pcib6 Mar 10 15:08:51 kernel: em0: port 0xecc0-0xecff mem 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6 Mar 10 15:08:51 kernel: em0: Ethernet address: 00:11:43:d5:a4:1a Mar 10 15:08:51 kernel: em0: Speed:N/A Duplex:N/A Mar 10 15:08:51 kernel: pcib7: at device 0.2 on pci5 Mar 10 15:08:51 kernel: pci7: on pcib7 Mar 10 15:08:51 kernel: em1: port 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 65 at device 8.0 on pci7 Mar 10 15:08:51 kernel: em1: Ethernet address: 00:11:43:d5:a4:1b Mar 10 15:08:51 kernel: em1: Speed:N/A Duplex:N/A Mar 10 15:08:51 kernel: pcib8: at device 6.0 on pci0 Mar 10 15:08:51 kernel: pci8: on pcib8 Mar 10 15:08:51 kernel: pcib9: at device 0.0 on pci8 Mar 10 15:08:51 kernel: pci9: on pcib9 Mar 10 15:08:51 kernel: pcib10: at device 0.2 on pci8 Mar 10 15:08:51 kernel: pci10: on pcib10 Mar 10 15:08:51 kernel: uhci0: port 0xbce0-0xbcff irq 16 at device 29.0 on pci0 Mar 10 15:08:51 kernel: uhci0: [GIANT-LOCKED] Mar 10 15:08:51 kernel: usb0: on uhci0 Mar 10 15:08:51 kernel: usb0: USB revision 1.0 Mar 10 15:08:51 kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 10 15:08:51 kernel: uhub0: 2 ports with 2 removable, self powered Mar 10 15:08:51 kernel: uhci1: port 0xbcc0-0xbcdf irq 19 at device 29.1 on pci0 Mar 10 15:08:51 kernel: uhci1: [GIANT-LOCKED] Mar 10 15:08:51 kernel: usb1: on uhci1 Mar 10 15:08:51 kernel: usb1: USB revision 1.0 Mar 10 15:08:51 kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 10 15:08:51 kernel: uhub1: 2 ports with 2 removable, self powered Mar 10 15:08:51 kernel: uhci2: port 0xbca0-0xbcbf irq 18 at device 29.2 on pci0 Mar 10 15:08:51 kernel: uhci2: [GIANT-LOCKED] Mar 10 15:08:51 kernel: usb2: on uhci2 Mar 10 15:08:51 kernel: usb2: USB revision 1.0 Mar 10 15:08:51 kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 10 15:08:51 kernel: uhub2: 2 ports with 2 removable, self powered Mar 10 15:08:51 kernel: ehci0: mem 0xdff00000-0xdff003ff irq 23 at device 29.7 on pci0 Mar 10 15:08:51 kernel: ehci0: [GIANT-LOCKED] Mar 10 15:08:51 kernel: usb3: EHCI version 1.0 Mar 10 15:08:51 kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 Mar 10 15:08:51 kernel: usb3: on ehci0 Mar 10 15:08:51 kernel: usb3: USB revision 2.0 Mar 10 15:08:51 kernel: uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 Mar 10 15:08:51 kernel: uhub3: 6 ports with 6 removable, self powered Mar 10 15:08:51 kernel: uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 Mar 10 15:08:51 kernel: uhub4: multiple transaction translators Mar 10 15:08:51 kernel: uhub4: 2 ports with 2 removable, self powered Mar 10 15:08:51 kernel: ukbd0: DELL DELL USB Keyboard, rev 1.10/1.04, addr 3, iclass 3/1 Mar 10 15:08:51 kernel: kbd0 at ukbd0 Mar 10 15:08:51 kernel: pcib11: at device 30.0 on pci0 Mar 10 15:08:51 kernel: pci11: on pcib11 Mar 10 15:08:51 kernel: pci11: at device 13.0 (no driver attached) Mar 10 15:08:51 kernel: isab0: at device 31.0 on pci0 Mar 10 15:08:51 kernel: isa0: on isab0 Mar 10 15:08:51 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 Mar 10 15:08:51 kernel: ata0: on atapci0 Mar 10 15:08:51 kernel: ata1: on atapci0 Mar 10 15:08:51 kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Mar 10 15:08:51 kernel: fdc0: [FAST] Mar 10 15:08:51 kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 10 15:08:51 kernel: sio0: type 16550A Mar 10 15:08:51 kernel: orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 Mar 10 15:08:51 kernel: atkbdc0: at port 0x60,0x64 on isa0 Mar 10 15:08:51 kernel: ppc0: cannot reserve I/O port range Mar 10 15:08:51 kernel: sc0: at flags 0x100 on isa0 Mar 10 15:08:51 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 10 15:08:51 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Mar 10 15:08:51 kernel: sio1: port may not be enabled Mar 10 15:08:51 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 10 15:08:51 kernel: Timecounter "TSC" frequency 2992705635 Hz quality 800 Mar 10 15:08:51 kernel: Timecounters tick every 1.000 msec Mar 10 15:08:51 kernel: acd0: CDROM at ata0-master UDMA33 Mar 10 15:08:51 kernel: amrd0: on amr0 Mar 10 15:08:51 kernel: amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) Mar 10 15:08:51 kernel: amrd1: on amr0 Mar 10 15:08:51 kernel: amrd1: 209640MB (429342720 sectors) RAID 5 (optimal) Mar 10 15:08:51 kernel: ses0 at amr0 bus 0 target 6 lun 0 Mar 10 15:08:51 kernel: ses0: Fixed Processor SCSI-2 device Mar 10 15:08:51 kernel: ses0: SAF-TE Compliant Device Mar 10 15:08:51 kernel: ses1 at amr0 bus 1 target 6 lun 0 Mar 10 15:08:51 kernel: ses1: Fixed Processor SCSI-2 device Mar 10 15:08:51 kernel: ses1: SAF-TE Compliant Device From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 14:38:12 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 212FB16A431 for ; Mon, 13 Mar 2006 14:38:02 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8DEE43D79 for ; Mon, 13 Mar 2006 14:37:52 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.52 (FreeBSD)) id 1FIoBB-000Ls3-Sg; Mon, 13 Mar 2006 14:37:49 +0000 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.52 (FreeBSD)) id 1FIoBB-00011G-P4; Mon, 13 Mar 2006 14:37:49 +0000 To: freebsd-amd64@freebsd.org, wmoran@collaborativefusion.com In-Reply-To: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> Message-Id: From: Pete French Date: Mon, 13 Mar 2006 14:37:49 +0000 Cc: bseklecki@collaborativefusion.com Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 14:38:12 -0000 > After building a kernel with SMP, I do see 2 logical processors, > and top(1) shows both of them doing their thing. However, > machdep.hypterthreading_allowed is set to 0. Is the amd64 kernel > ignoring this value, or is top(1) reporting incorrectly? It seems to be a bug - if you have an SMP kernel you cant turn off hyperthreading, no matter which knobs you twiddle. Not amd64 specific either. Even with all the hyperthreading variables off and with the masks showing that processes should not be scheduled on the second CPU's I still see stuff on 0, 1, 2 and 3. -pcf. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 14:43:58 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 5602016A423 for ; Mon, 13 Mar 2006 14:43:58 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id C552743D49 for ; Mon, 13 Mar 2006 14:43:57 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Mon, 13 Mar 2006 09:43:56 -0500 id 00056417.4415852C.00008456 Date: Mon, 13 Mar 2006 09:43:56 -0500 From: Bill Moran To: Pete French Message-Id: <20060313094356.d7f0988a.wmoran@collaborativefusion.com> In-Reply-To: References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bseklecki@collaborativefusion.com, freebsd-amd64@freebsd.org Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 14:43:58 -0000 On Mon, 13 Mar 2006 14:37:49 +0000 Pete French wrote: > > After building a kernel with SMP, I do see 2 logical processors, > > and top(1) shows both of them doing their thing. However, > > machdep.hypterthreading_allowed is set to 0. Is the amd64 kernel > > ignoring this value, or is top(1) reporting incorrectly? > > It seems to be a bug - if you have an SMP kernel you cant turn off > hyperthreading, no matter which knobs you twiddle. Not amd64 specific > either. Even with all the hyperthreading variables off and with the > masks showing that processes should not be scheduled on the second CPU's > I still see stuff on 0, 1, 2 and 3. I don't see this behaviour on i386 - my desktop, for example uses only CPU 0 if the sysctl is 0, and switches between 0 and 1 when the sysctl is 1. Also doesn't explain the lack of any performance improvement with ht enabled. I'm aware of the argument that HT is really multiprocessers, thus the performance increase isn't all one would expect. However, in i386 systems, enabling HT results in a _noticeable_ performance improvement under most loads. -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 14:48:18 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 2662616A41F for ; Mon, 13 Mar 2006 14:48:16 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7146743D67 for ; Mon, 13 Mar 2006 14:48:07 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Mon, 13 Mar 2006 09:48:06 -0500 id 00056417.44158626.00008491 Date: Mon, 13 Mar 2006 09:48:06 -0500 From: Bill Moran To: freebsd-amd64@freebsd.org Message-Id: <20060313094806.26d70c99.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bseklecki@collaborativefusion.com Subject: Incorrect memory probing? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 14:48:18 -0000 Complete dmesg is attached, but notice the memory probing: Mar 10 14:56:40 kernel: real memory = 5100273664 (4864 MB) Mar 10 14:56:40 kernel: avail memory = 4124049408 (3933 MB) The machine in question (a Dell Poweredge 2850) has 4G of RAM installed. It looks to me as if the "avail memory" number is correct (after booting, other systems tools seem to show the correct amount) Is the "real memory" number expected? If so, can someone explain why it appears to see almost a G more RAM than is actually in the machine? (As a side note, I get the same numbers if I boot a i386 kernel with PAE on this machine). Mar 10 14:56:40 kernel: Copyright (c) 1992-2005 The FreeBSD Project. Mar 10 14:56:40 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 10 14:56:40 kernel: The Regents of the University of California. All rights reserved. Mar 10 14:56:40 kernel: FreeBSD 6.0-RELEASE #0: Wed Nov 2 19:07:38 UTC 2005 Mar 10 14:56:40 kernel: root@rat.samsco.home:/usr/obj/usr/src/sys/GENERIC Mar 10 14:56:40 kernel: ACPI APIC Table: Mar 10 14:56:40 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 10 14:56:40 kernel: CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) Mar 10 14:56:40 kernel: Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Mar 10 14:56:40 kernel: Features=0xbfebfbff Mar 10 14:56:40 kernel: Features2=0x641d> Mar 10 14:56:40 kernel: AMD Features=0x20000800 Mar 10 14:56:40 kernel: Hyperthreading: 2 logical CPUs Mar 10 14:56:40 kernel: real memory = 5100273664 (4864 MB) Mar 10 14:56:40 kernel: avail memory = 4124049408 (3933 MB) Mar 10 14:56:40 kernel: ioapic0: Changing APIC ID to 2 Mar 10 14:56:40 kernel: ioapic1: Changing APIC ID to 3 Mar 10 14:56:40 kernel: ioapic1: WARNING: intbase 32 != expected base 24 Mar 10 14:56:40 kernel: ioapic2: Changing APIC ID to 4 Mar 10 14:56:40 kernel: ioapic2: WARNING: intbase 64 != expected base 56 Mar 10 14:56:40 kernel: ioapic3: Changing APIC ID to 5 Mar 10 14:56:40 kernel: ioapic3: WARNING: intbase 96 != expected base 88 Mar 10 14:56:40 kernel: ioapic0 irqs 0-23 on motherboard Mar 10 14:56:40 kernel: ioapic1 irqs 32-55 on motherboard Mar 10 14:56:40 kernel: ioapic2 irqs 64-87 on motherboard Mar 10 14:56:40 kernel: ioapic3 irqs 96-119 on motherboard Mar 10 14:56:40 kernel: acpi0: on motherboard Mar 10 14:56:40 kernel: acpi0: Power Button (fixed) Mar 10 14:56:40 kernel: pci_link0: irq 11 on acpi0 Mar 10 14:56:40 kernel: pci_link1: irq 3 on acpi0 Mar 10 14:56:40 kernel: pci_link2: irq 7 on acpi0 Mar 10 14:56:40 kernel: pci_link3: irq 10 on acpi0 Mar 10 14:56:40 kernel: pci_link4: on acpi0 Mar 10 14:56:40 kernel: pci_link5: on acpi0 Mar 10 14:56:40 kernel: pci_link6: on acpi0 Mar 10 14:56:40 kernel: pci_link7: irq 5 on acpi0 Mar 10 14:56:40 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 10 14:56:40 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Mar 10 14:56:40 kernel: cpu0: on acpi0 Mar 10 14:56:40 kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 10 14:56:40 kernel: pci0: on pcib0 Mar 10 14:56:40 kernel: pcib1: at device 2.0 on pci0 Mar 10 14:56:40 kernel: pci1: on pcib1 Mar 10 14:56:40 kernel: pcib2: at device 0.0 on pci1 Mar 10 14:56:40 kernel: pci2: on pcib2 Mar 10 14:56:40 kernel: amr0: mem 0xd80f0000-0xd80fffff,0xdfdc0000-0xdfdfffff irq 46 at device 14.0 on pci2 Mar 10 14:56:40 kernel: amr0: Firmware 513O, BIOS H418, 256MB RAM Mar 10 14:56:40 kernel: pcib3: at device 0.2 on pci1 Mar 10 14:56:40 kernel: pci3: on pcib3 Mar 10 14:56:40 kernel: pcib4: at device 4.0 on pci0 Mar 10 14:56:40 kernel: pci4: on pcib4 Mar 10 14:56:40 kernel: pcib5: at device 5.0 on pci0 Mar 10 14:56:40 kernel: pci5: on pcib5 Mar 10 14:56:40 kernel: pcib6: at device 0.0 on pci5 Mar 10 14:56:40 kernel: pci6: on pcib6 Mar 10 14:56:40 kernel: em0: port 0xecc0-0xecff mem 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6 Mar 10 14:56:40 kernel: em0: Ethernet address: 00:11:43:d5:a4:1a Mar 10 14:56:40 kernel: em0: Speed:N/A Duplex:N/A Mar 10 14:56:40 kernel: pcib7: at device 0.2 on pci5 Mar 10 14:56:40 kernel: pci7: on pcib7 Mar 10 14:56:40 kernel: em1: port 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 65 at device 8.0 on pci7 Mar 10 14:56:40 kernel: em1: Ethernet address: 00:11:43:d5:a4:1b Mar 10 14:56:40 kernel: em1: Speed:N/A Duplex:N/A Mar 10 14:56:40 kernel: pcib8: at device 6.0 on pci0 Mar 10 14:56:40 kernel: pci8: on pcib8 Mar 10 14:56:40 kernel: pcib9: at device 0.0 on pci8 Mar 10 14:56:40 kernel: pci9: on pcib9 Mar 10 14:56:40 kernel: pcib10: at device 0.2 on pci8 Mar 10 14:56:40 kernel: pci10: on pcib10 Mar 10 14:56:40 kernel: uhci0: port 0xbce0-0xbcff irq 16 at device 29.0 on pci0 Mar 10 14:56:40 kernel: uhci0: [GIANT-LOCKED] Mar 10 14:56:40 kernel: usb0: on uhci0 Mar 10 14:56:40 kernel: usb0: USB revision 1.0 Mar 10 14:56:40 kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 10 14:56:40 kernel: uhub0: 2 ports with 2 removable, self powered Mar 10 14:56:40 kernel: uhci1: port 0xbcc0-0xbcdf irq 19 at device 29.1 on pci0 Mar 10 14:56:40 kernel: uhci1: [GIANT-LOCKED] Mar 10 14:56:40 kernel: usb1: on uhci1 Mar 10 14:56:40 kernel: usb1: USB revision 1.0 Mar 10 14:56:40 kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 10 14:56:40 kernel: uhub1: 2 ports with 2 removable, self powered Mar 10 14:56:40 kernel: uhci2: port 0xbca0-0xbcbf irq 18 at device 29.2 on pci0 Mar 10 14:56:40 kernel: uhci2: [GIANT-LOCKED] Mar 10 14:56:40 kernel: usb2: on uhci2 Mar 10 14:56:40 kernel: usb2: USB revision 1.0 Mar 10 14:56:40 kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 10 14:56:40 kernel: uhub2: 2 ports with 2 removable, self powered Mar 10 14:56:40 kernel: ehci0: mem 0xdff00000-0xdff003ff irq 23 at device 29.7 on pci0 Mar 10 14:56:40 kernel: ehci0: [GIANT-LOCKED] Mar 10 14:56:40 kernel: usb3: EHCI version 1.0 Mar 10 14:56:40 kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 Mar 10 14:56:40 kernel: usb3: on ehci0 Mar 10 14:56:40 kernel: usb3: USB revision 2.0 Mar 10 14:56:40 kernel: uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 Mar 10 14:56:40 kernel: uhub3: 6 ports with 6 removable, self powered Mar 10 14:56:40 kernel: uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 Mar 10 14:56:40 kernel: uhub4: multiple transaction translators Mar 10 14:56:40 kernel: uhub4: 2 ports with 2 removable, self powered Mar 10 14:56:40 kernel: ukbd0: DELL DELL USB Keyboard, rev 1.10/1.04, addr 3, iclass 3/1 Mar 10 14:56:40 kernel: kbd0 at ukbd0 Mar 10 14:56:40 kernel: pcib11: at device 30.0 on pci0 Mar 10 14:56:40 kernel: pci11: on pcib11 Mar 10 14:56:40 kernel: pci11: at device 13.0 (no driver attached) Mar 10 14:56:40 kernel: isab0: at device 31.0 on pci0 Mar 10 14:56:40 kernel: isa0: on isab0 Mar 10 14:56:40 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 Mar 10 14:56:40 kernel: ata0: on atapci0 Mar 10 14:56:40 kernel: ata1: on atapci0 Mar 10 14:56:40 kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Mar 10 14:56:40 kernel: fdc0: [FAST] Mar 10 14:56:40 kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 10 14:56:40 kernel: sio0: type 16550A Mar 10 14:56:40 kernel: orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 Mar 10 14:56:40 kernel: atkbdc0: at port 0x60,0x64 on isa0 Mar 10 14:56:40 kernel: ppc0: cannot reserve I/O port range Mar 10 14:56:40 kernel: sc0: at flags 0x100 on isa0 Mar 10 14:56:40 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 10 14:56:40 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Mar 10 14:56:40 kernel: sio1: port may not be enabled Mar 10 14:56:40 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 10 14:56:40 kernel: Timecounter "TSC" frequency 2992709985 Hz quality 800 Mar 10 14:56:40 kernel: Timecounters tick every 1.000 msec Mar 10 14:56:40 kernel: acd0: CDROM at ata0-master UDMA33 Mar 10 14:56:40 kernel: amrd0: on amr0 Mar 10 14:56:40 kernel: amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) Mar 10 14:56:40 kernel: amrd1: on amr0 Mar 10 14:56:40 kernel: amrd1: 209640MB (429342720 sectors) RAID 5 (optimal) Mar 10 14:56:40 kernel: ses0 at amr0 bus 0 target 6 lun 0 Mar 10 14:56:40 kernel: ses0: Fixed Processor SCSI-2 device Mar 10 14:56:40 kernel: ses0: SAF-TE Compliant Device Mar 10 14:56:40 kernel: ses1 at amr0 bus 1 target 6 lun 0 Mar 10 14:56:40 kernel: ses1: Fixed Processor SCSI-2 device Mar 10 14:56:40 kernel: ses1: SAF-TE Compliant Device From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 15:11:32 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADB3416A401; Mon, 13 Mar 2006 15:11:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 439E743D53; Mon, 13 Mar 2006 15:11:31 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k2DFBTp7074413; Mon, 13 Mar 2006 10:11:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k2DFBk2R027350; Mon, 13 Mar 2006 10:11:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 514337304D; Mon, 13 Mar 2006 10:11:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060313151129.514337304D@freebsd-current.sentex.ca> Date: Mon, 13 Mar 2006 10:11:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 15:11:32 -0000 TB --- 2006-03-13 13:23:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-03-13 13:23:34 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-03-13 13:23:34 - cleaning the object tree TB --- 2006-03-13 13:24:11 - checking out the source tree TB --- 2006-03-13 13:24:11 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-03-13 13:24:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-03-13 13:30:47 - building world (CFLAGS=-O2 -pipe) TB --- 2006-03-13 13:30:47 - cd /src TB --- 2006-03-13 13:30:47 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2006-03-13 15:02:42 - generating LINT kernel config TB --- 2006-03-13 15:02:42 - cd /src/sys/amd64/conf TB --- 2006-03-13 15:02:42 - /usr/bin/make -B LINT TB --- 2006-03-13 15:02:42 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-03-13 15:02:42 - cd /src TB --- 2006-03-13 15:02:42 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 13 15:02:42 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/geom/label/g_label_ntfs.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/geom/label/g_label_reiserfs.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/geom/label/g_label_ufs.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/geom/mirror/g_mirror.c /src/sys/geom/mirror/g_mirror.c: In function `g_mirror_sync_request': /src/sys/geom/mirror/g_mirror.c:1286: warning: cast from pointer to integer of different size /src/sys/geom/mirror/g_mirror.c: In function `g_mirror_sync_start': /src/sys/geom/mirror/g_mirror.c:1900: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-03-13 15:11:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-03-13 15:11:29 - ERROR: failed to build lint kernel TB --- 2006-03-13 15:11:29 - tinderbox aborted TB --- 1.41 user 6.66 system 6474.80 real From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 15:16:16 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 5F1BC16A41F for ; Mon, 13 Mar 2006 15:16:16 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id F080543D45 for ; Mon, 13 Mar 2006 15:16:15 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.52 (FreeBSD)) id 1FIomN-000Mh2-AI; Mon, 13 Mar 2006 15:16:15 +0000 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.52 (FreeBSD)) id 1FIomN-00015b-4x; Mon, 13 Mar 2006 15:16:15 +0000 To: wmoran@collaborativefusion.com In-Reply-To: <20060313094356.d7f0988a.wmoran@collaborativefusion.com> Message-Id: From: Pete French Date: Mon, 13 Mar 2006 15:16:15 +0000 Cc: bseklecki@collaborativefusion.com, freebsd-amd64@freebsd.org Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 15:16:17 -0000 > I don't see this behaviour on i386 - my desktop, for example uses only > CPU 0 if the sysctl is 0, and switches between 0 and 1 when the sysctl > is 1. Uh, a typo on my part - substitute *machine* for *kernel*. Sorry! A machine with one physical processor works fine - ccan enable and disable hyperthreading as pper the manual. A machine with two physical processors always gets hyperthreading enabled though. All of these machines are running 6.0 currently - though I will verify that the bug is still there on 6.1 when I get a moment to do an update on them. -pete. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 15:41:58 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 4C39116A48F for ; Mon, 13 Mar 2006 15:41:54 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD31A43DD4 for ; Mon, 13 Mar 2006 15:41:38 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Mon, 13 Mar 2006 10:41:37 -0500 id 0005641F.441592B1.000087AF Date: Mon, 13 Mar 2006 10:41:37 -0500 From: Bill Moran To: Pete French Message-Id: <20060313104137.5fcc80ea.wmoran@collaborativefusion.com> In-Reply-To: References: <20060313094356.d7f0988a.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bseklecki@collaborativefusion.com, freebsd-amd64@freebsd.org Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 15:41:58 -0000 On Mon, 13 Mar 2006 15:16:15 +0000 Pete French wrote: > > I don't see this behaviour on i386 - my desktop, for example uses only > > CPU 0 if the sysctl is 0, and switches between 0 and 1 when the sysctl > > is 1. > > Uh, a typo on my part - substitute *machine* for *kernel*. Sorry! > > A machine with one physical processor works fine - can enable and disable > hyperthreading as per the manual. A machine with two physical processors > always gets hyperthreading enabled though. All of these machines are > running 6.0 currently - though I will verify that the bug is still there > on 6.1 when I get a moment to do an update on them. Again, not what I'm seeing here. It appears as if the machine behaves identically no matter what machdep.hyperthreading_allowed is set to. The machine I'm testing on only has a single physical processor. I've been running ubench multiple times to test this, and I see processes on CPUs 1 and 0 no matter what I set the above sysctl to. I also don't see any difference in ubench's performance numbers. -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 15:52:08 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 4EC8316A420 for ; Mon, 13 Mar 2006 15:52:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBCCE43D5E for ; Mon, 13 Mar 2006 15:51:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2DFpObN097316; Mon, 13 Mar 2006 10:51:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Mon, 13 Mar 2006 10:52:28 -0500 User-Agent: KMail/1.9.1 References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> In-Reply-To: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603131052.29655.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1326/Sat Mar 11 15:33:54 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.2 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: bseklecki@collaborativefusion.com Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 15:52:08 -0000 On Monday 13 March 2006 08:54, Bill Moran wrote: > > We've got some dell servers (Poweredge 2850 is specifically what > the following tests were run on). Some of the behaviour we're > seeing was unexpected. In particular, I'm rather fuzzy as to > how an amd64 kernel handles hyperthreading. (Personally, I'm also > a little fuzzy on whether this really is hyperthreading under amd64 > at all) > > After building a kernel with SMP, I do see 2 logical processors, > and top(1) shows both of them doing their thing. However, > machdep.hypterthreading_allowed is set to 0. Is the amd64 kernel > ignoring this value, or is top(1) reporting incorrectly? > > Additionally, I'm not seeing the performance I'm accustomed to on > hypterthreaded machines. Usually, throughput scales when hyperthreading > is enabled and more than one process are fighting for CPU. In my > tests, it seems as if there is no scaling whatsoever. i.e.: On > a standard hyperthreaded machine, running 1 ubench might yield a > CPU value of 100,000. Running two ubench simultaneously will usually > result in each of them returning ~90,000 or so. With the amd64, I > end up with each one around 50,000 - as if there were no second > logical CPU (despite the fact that top(1) shows both in use). > > dmesg attached. I can provide more information on request. Your dmesg is from a kernel that doesn't include 'options SMP' and is thus only using 1 CPU. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 15:59:55 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 7700D16A427 for ; Mon, 13 Mar 2006 15:59:54 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71D8243D9E for ; Mon, 13 Mar 2006 15:59:38 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.52 (FreeBSD)) id 1FIpSM-000NV9-5t; Mon, 13 Mar 2006 15:59:38 +0000 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.52 (FreeBSD)) id 1FIpSK-0000Cs-UP; Mon, 13 Mar 2006 15:59:36 +0000 To: wmoran@collaborativefusion.com In-Reply-To: <20060313104137.5fcc80ea.wmoran@collaborativefusion.com> Message-Id: From: Pete French Date: Mon, 13 Mar 2006 15:59:36 +0000 Cc: bseklecki@collaborativefusion.com, freebsd-amd64@freebsd.org Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 15:59:55 -0000 > Again, not what I'm seeing here. It appears as if the machine behaves > identically no matter what machdep.hyperthreading_allowed is set to. > The machine I'm testing on only has a single physical processor. > > I've been running ubench multiple times to test this, and I see processes > on CPUs 1 and 0 no matter what I set the above sysctl to. I also don't > see any difference in ubench's performance numbers. Actually, I just upgraded this machine to 6.1 and now I am seeing much the same thing - no matter what I set machdep.hyperthreading_allowed and machdep.hlt_logical_cpu to I still see stuff on both CPUs. I havent doe any performance measurements though. -pete. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 16:16: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 00D5516A400; Mon, 13 Mar 2006 16:16:23 +0000 (UTC) (envelope-from root@scienceclue.ath.cx) Received: from scienceclue.ath.cx (mic92-1-87-90-12-116.dsl.club-internet.fr [87.90.12.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E37C43D46; Mon, 13 Mar 2006 16:16:20 +0000 (GMT) (envelope-from root@scienceclue.ath.cx) Received: from scienceclue.ath.cx (localhost [127.0.0.1]) by scienceclue.ath.cx (8.13.4/8.13.4) with ESMTP id k2DGHk0r057133; Mon, 13 Mar 2006 17:17:46 +0100 (CET) (envelope-from root@scienceclue.ath.cx) Received: (from root@localhost) by scienceclue.ath.cx (8.13.4/8.13.4/Submit) id k2DGHe7n057132; Mon, 13 Mar 2006 17:17:40 +0100 (CET) (envelope-from root) Date: Mon, 13 Mar 2006 17:17:40 +0100 From: Mathieu Prevot To: freebsd-hackers@freebsd.org Message-ID: <20060313161740.GA56875@scienceclue.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD-AMD64 6.1-PRERELEASE X-URL: http://scienceclue.ath.cx Cc: freebsd-amd64@freebsd.org Subject: Creating real bool type for simulation in physics X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mathieu Prevot List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 16:16:23 -0000 Hello, I use freebsd/amd64 (RELENG_6) for simulation in physics. I am working on the Ising model: an assembly of spins (micromagnets) which interact and which are in one of two states (up or down). Until now I use char to define the state of each spin (-1 or 1), however, I remarked that most time is spent on memory I/O. Most of bits are unused. I think that if I can use just one bit per spin, I can have something much faster. I need advices on how to use it. I guess I can't define a new type with a 1/8 byte height (or one bit), yes ? What variable (int, char...) do you recommend to use for a sempron 64 bits. I think I'll need to define new operators (opaque operators, built with bit operators) to switch my spins or use directly the following: & | ^ ~ ... May I gain speed using MMX registers or something like this ? How can I do this ? Here is my basic and multithreaded program: http://scienceclue.ath.cx/download/ising_lps_0.2.tar.bz2 Thanks Mathieu P. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 17:13:33 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DDA016A400 for ; Mon, 13 Mar 2006 17:13:28 +0000 (UTC) (envelope-from apple@justken.net) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E315043D45 for ; Mon, 13 Mar 2006 17:13:26 +0000 (GMT) (envelope-from apple@justken.net) Received: from ip02.eastlink.ca ([24.222.10.10]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IW20093ST4A8K90@mta01.eastlink.ca> for amd64@freebsd.org; Mon, 13 Mar 2006 13:12:11 -0400 (AST) Received: from server4.justken.net (HELO [192.168.0.57]) ([24.222.15.13]) by ip02.eastlink.ca with ESMTP; Mon, 13 Mar 2006 13:13:12 -0400 Date: Mon, 13 Mar 2006 13:00:57 -0400 From: Ken Easson To: amd64@freebsd.org Message-id: <8B10B63B-7777-4B0F-B9BD-DB30918D5B24@justken.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= Cc: Subject: nvnet on MSI K8NGM2 motherboard & FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 17:13:33 -0000 Hello, I've recently purchased a new AMD64 bases system with an all in one motherboard. K8NGM2 on board is the nVidia 10/100 MCP51 ethernet controller. running freebsd 6.0-RELEASE-p5 the system doesn't detect the ethernet card. When i boot using acip the system reboots, so i'm booting without ACIP enabled. I've been able to install Mandrake and after downloading the drivers from nvidia's site, the card works. Also i have an Intel Pro 1000 installed - which is what i'm connecting to the internet with now. I tried to install the port net/nvnet driver, however, i get a stop: lot's of ../src/if_nv.c:XXXX: error: structure has no member named 'ac_if' *** Error code 1 Stop in /usr/ports/net/nvnet/work/nvnet/module. *** Error code 1 any help would be greatly appreciated. ken From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 17:13:52 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 7686316A401; Mon, 13 Mar 2006 17:13:51 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D636643D45; Mon, 13 Mar 2006 17:13:50 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.4) id k2DHDfdS074363; Mon, 13 Mar 2006 11:13:42 -0600 (CST) (envelope-from dan) Date: Mon, 13 Mar 2006 11:13:41 -0600 From: Dan Nelson To: Mathieu Prevot Message-ID: <20060313171341.GA7636@dan.emsphone.com> References: <20060313161740.GA56875@scienceclue.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060313161740.GA56875@scienceclue.ath.cx> X-OS: FreeBSD 5.5-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Creating real bool type for simulation in physics X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 17:13:52 -0000 In the last episode (Mar 13), Mathieu Prevot said: > I use freebsd/amd64 (RELENG_6) for simulation in physics. I am > working on the Ising model: an assembly of spins (micromagnets) which > interact and which are in one of two states (up or down). Until now I > use char to define the state of each spin (-1 or 1), however, I > remarked that most time is spent on memory I/O. Most of bits are > unused. > > I think that if I can use just one bit per spin, I can have something > much faster. I need advices on how to use it. I guess I can't define > a new type with a 1/8 byte height (or one bit), yes ? What variable > (int, char...) do you recommend to use for a sempron 64 bits. I think > I'll need to define new operators (opaque operators, built with bit > operators) to switch my spins or use directly the following: & | ^ ~ > ... Take a look at the "bitstring" functions, which let you allocate an array of "bits" and manipulate them individually. They're documented in the bitstring manpage. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 18:25:25 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 131C316A401 for ; Mon, 13 Mar 2006 18:25:25 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AFCA43D45 for ; Mon, 13 Mar 2006 18:25:23 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2DIPMq2093699 for ; Mon, 13 Mar 2006 15:25:22 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-amd64@freebsd.org Date: Mon, 13 Mar 2006 15:25:06 -0300 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603131525.06540.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Subject: 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: Mon, 13 Mar 2006 18:25:25 -0000 Hi Since some time (>6.0R) I have the impression that amd64 runs slower than=20 i386. Now I run some tests on identical hardware and using ubench confirmes= =20 this. Somebody has comments on this? Jo=E3o ##################################### Athlon64 3200+ (i386) Ubench Single CPU: 97255 (0.48s) Ubench Single MEM: 146557 (0.40s) =2D---------------------------------- Ubench Single AVG: 121906 ##################################### Athlon64 3200+ (amd64) Ubench Single CPU: 86200 (0.39s) Ubench Single MEM: 106488 (0.41s) =2D---------------------------------- Ubench Single AVG: 96344 ##################################### an athlon 3500 marks as an athlon 4000 ##################################### Athlon 64 3500+ (i386) Ubench Single CPU: 94013 (0.38s) Ubench Single MEM: 128801 (0.39s) =2D---------------------------------- Ubench Single AVG: 111407 ##################################### Athlon64 4000+ (amd64) Ubench Single CPU: 111604 (0.44s) Ubench Single MEM: 113530 (0.39s) =2D---------------------------------- Ubench Single AVG: 112567 ##################################### A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 18:45:45 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 CFFD616A41F; Mon, 13 Mar 2006 18:45:45 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D88F43D6A; Mon, 13 Mar 2006 18:45:41 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Mon, 13 Mar 2006 13:45:40 -0500 id 00056422.4415BDD4.00008FD7 Date: Mon, 13 Mar 2006 13:45:40 -0500 From: Bill Moran To: John Baldwin Message-Id: <20060313134540.506b6b46.wmoran@collaborativefusion.com> In-Reply-To: <200603131052.29655.jhb@freebsd.org> References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> <200603131052.29655.jhb@freebsd.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bseklecki@collaborativefusion.com, freebsd-amd64@freebsd.org Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 18:45:45 -0000 On Mon, 13 Mar 2006 10:52:28 -0500 John Baldwin wrote: > On Monday 13 March 2006 08:54, Bill Moran wrote: > > > > We've got some dell servers (Poweredge 2850 is specifically what > > the following tests were run on). Some of the behaviour we're > > seeing was unexpected. In particular, I'm rather fuzzy as to > > how an amd64 kernel handles hyperthreading. (Personally, I'm also > > a little fuzzy on whether this really is hyperthreading under amd64 > > at all) > > > > After building a kernel with SMP, I do see 2 logical processors, > > and top(1) shows both of them doing their thing. However, > > machdep.hypterthreading_allowed is set to 0. Is the amd64 kernel > > ignoring this value, or is top(1) reporting incorrectly? > > > > Additionally, I'm not seeing the performance I'm accustomed to on > > hypterthreaded machines. Usually, throughput scales when hyperthreading > > is enabled and more than one process are fighting for CPU. In my > > tests, it seems as if there is no scaling whatsoever. i.e.: On > > a standard hyperthreaded machine, running 1 ubench might yield a > > CPU value of 100,000. Running two ubench simultaneously will usually > > result in each of them returning ~90,000 or so. With the amd64, I > > end up with each one around 50,000 - as if there were no second > > logical CPU (despite the fact that top(1) shows both in use). > > > > dmesg attached. I can provide more information on request. > > Your dmesg is from a kernel that doesn't include 'options SMP' and is > thus only using 1 CPU. Really? I've triple-checked at this point and: 1) The kernel config file has "options SMP" 2) The running kernel was made from #1 3) top(1) shows cpus 0 and 1 I can't argue that the boot messages don't seem to show anything to indicate that a second logical CPU was found. -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 19:05:42 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 A023A16A41F for ; Mon, 13 Mar 2006 19:05:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE14943D46 for ; Mon, 13 Mar 2006 19:05:41 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2DJ5Y9w098347; Mon, 13 Mar 2006 14:05:35 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bill Moran Date: Mon, 13 Mar 2006 14:06:34 -0500 User-Agent: KMail/1.9.1 References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> <200603131052.29655.jhb@freebsd.org> <20060313134540.506b6b46.wmoran@collaborativefusion.com> In-Reply-To: <20060313134540.506b6b46.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603131406.36636.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1328/Mon Mar 13 12:13:39 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.2 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: bseklecki@collaborativefusion.com, freebsd-amd64@freebsd.org Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 19:05:42 -0000 On Monday 13 March 2006 13:45, Bill Moran wrote: > On Mon, 13 Mar 2006 10:52:28 -0500 > John Baldwin wrote: > > > On Monday 13 March 2006 08:54, Bill Moran wrote: > > > > > > We've got some dell servers (Poweredge 2850 is specifically what > > > the following tests were run on). Some of the behaviour we're > > > seeing was unexpected. In particular, I'm rather fuzzy as to > > > how an amd64 kernel handles hyperthreading. (Personally, I'm also > > > a little fuzzy on whether this really is hyperthreading under amd64 > > > at all) > > > > > > After building a kernel with SMP, I do see 2 logical processors, > > > and top(1) shows both of them doing their thing. However, > > > machdep.hypterthreading_allowed is set to 0. Is the amd64 kernel > > > ignoring this value, or is top(1) reporting incorrectly? > > > > > > Additionally, I'm not seeing the performance I'm accustomed to on > > > hypterthreaded machines. Usually, throughput scales when hyperthreading > > > is enabled and more than one process are fighting for CPU. In my > > > tests, it seems as if there is no scaling whatsoever. i.e.: On > > > a standard hyperthreaded machine, running 1 ubench might yield a > > > CPU value of 100,000. Running two ubench simultaneously will usually > > > result in each of them returning ~90,000 or so. With the amd64, I > > > end up with each one around 50,000 - as if there were no second > > > logical CPU (despite the fact that top(1) shows both in use). > > > > > > dmesg attached. I can provide more information on request. > > > > Your dmesg is from a kernel that doesn't include 'options SMP' and is > > thus only using 1 CPU. > > Really? I've triple-checked at this point and: > 1) The kernel config file has "options SMP" > 2) The running kernel was made from #1 > 3) top(1) shows cpus 0 and 1 > > I can't argue that the boot messages don't seem to show anything to > indicate that a second logical CPU was found. Grab the dmesg from /var/run/dmesg.boot rather than /var/log/messages please. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 19:41:09 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6539316A426 for ; Mon, 13 Mar 2006 19:41:09 +0000 (UTC) (envelope-from root@mail.bitdefender.com) Received: from mail.bitdefender.com (ns.bitdefender.com [217.156.83.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0FFA43D6B for ; Mon, 13 Mar 2006 19:40:50 +0000 (GMT) (envelope-from root@mail.bitdefender.com) Received: (qmail 25318 invoked by uid 0); 13 Mar 2006 21:40:47 +0200 Received: (qmail 25204 invoked by uid 1010); 11 Mar 2006 04:43:04 +0200 Received: from mx2.freebsd.org (216.136.204.119) by mail.bitdefender.com with SMTP; 11 Mar 2006 04:43:03 +0200 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 70DD014B5C4; Sat, 11 Mar 2006 02:19:46 +0000 (GMT) (envelope-from owner-freebsd-questions@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BDA2916AE34; Sat, 11 Mar 2006 02:14:53 +0000 (GMT) (envelope-from owner-freebsd-questions@freebsd.org) X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E347A16A440; Sat, 11 Mar 2006 01:38:30 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DAD543DAC; Sat, 11 Mar 2006 01:37:56 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k2B1btET052122; Fri, 10 Mar 2006 17:37:55 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k2B1btVa052121; Fri, 10 Mar 2006 17:37:55 -0800 (PST) (envelope-from sgk) Date: Fri, 10 Mar 2006 17:37:55 -0800 From: Steve Kargl To: Nathan Vidican Message-ID: <20060311013755.GA52109@troutmask.apl.washington.edu> References: <4411D6D8.5030101@wmptl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4411D6D8.5030101@wmptl.com> User-Agent: Mutt/1.4.2.1i X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org X-BitDefender-SpamStamp: 1.1.4 049000040111AAAAAAEAAAAAAgAAAAAAAAAAAAAAAAAAQ X-BitDefender-Scanner: Clean, Agent: BitDefender Qmail 1.6.2 on mail.bitdefender.com X-BitDefender-Spam: No (0) Cc: amd64@freebsd.org, questions@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 19:41:09 -0000 On Fri, Mar 10, 2006 at 02:43:20PM -0500, Nathan Vidican wrote: > I seem to recall various threads relating to problems with machines running > at or above 4GB ram... what if any issues still exist? > I've been running with 12 GB for the last 18 months. -- Steve _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://www.bitdefender.com/ From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:04:25 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 6F8D216A41F for ; Mon, 13 Mar 2006 20:04:25 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A3ED43D45 for ; Mon, 13 Mar 2006 20:04:24 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Mon, 13 Mar 2006 15:04:24 -0500 id 0005643A.4415D048.000092A4 Date: Mon, 13 Mar 2006 15:04:23 -0500 From: Bill Moran To: freebsd-amd64@freebsd.org Message-Id: <20060313150423.2b475fd4.wmoran@collaborativefusion.com> In-Reply-To: <200603131406.36636.jhb@freebsd.org> References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> <200603131052.29655.jhb@freebsd.org> <20060313134540.506b6b46.wmoran@collaborativefusion.com> <200603131406.36636.jhb@freebsd.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bseklecki@collaborativefusion.com Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:04:25 -0000 On Mon, 13 Mar 2006 14:06:34 -0500 John Baldwin wrote: [...] > > I can't argue that the boot messages don't seem to show anything to > > indicate that a second logical CPU was found. > > Grab the dmesg from /var/run/dmesg.boot rather than /var/log/messages > please. Copyright (c) 1992-2005 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 6.0-RELEASE-p5 #1: Fri Mar 10 16:57:56 EST 2006 root@:/usr/obj/usr/src/sys/DB64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20000800 Hyperthreading: 2 logical CPUs real memory = 2147221504 (2047 MB) avail memory = 2066378752 (1970 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 4 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 5 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 3 on acpi0 pci_link2: irq 7 on acpi0 pci_link3: irq 10 on acpi0 pci_link4: irq 11 on acpi0 pci_link5: irq 10 on acpi0 pci_link6: on acpi0 pci_link7: irq 5 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xd80f0000-0xd80fffff,0xdfdc0000-0xdfdfffff irq 46 at device 14.0 on pci2 amr0: Firmware 513O, BIOS H418, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xecc0-0xecff mem 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:11:43:d5:a4:1a em0: Speed:N/A Duplex:N/A pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:11:43:d5:a4:1b em1: Speed:N/A Duplex:N/A pcib8: at device 6.0 on pci0 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 pcib10: at device 0.2 on pci8 pci10: on pcib10 uhci0: port 0xbce0-0xbcff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] 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 uhci1: port 0xbcc0-0xbcdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbca0-0xbcbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xdff00000-0xdff003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered ukbd0: DELL DELL USB Keyboard, rev 1.10/1.04, addr 3, iclass 3/1 kbd0 at ukbd0 pcib11: at device 30.0 on pci0 pci11: on pcib11 pci11: at device 5.0 (no driver attached) pci11: at device 5.1 (no driver attached) pci11: at device 5.2 (no driver attached) atapci0: port 0xccf0-0xccf7,0xcce4-0xcce7,0xccd8-0xccdf,0xccd0-0xccd3,0xcc70-0xcc7f mem 0xdf4fec00-0xdf4fecff irq 23 at device 6.0 on pci11 ata2: on atapci0 ata3: on atapci0 pci11: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci1 ata1: on atapci1 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd1: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 kbd1 at ukbd1 ums0: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 acd1: CDROM at ata2-slave PIO3 amrd0: on amr0 amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) amrd1: on amr0 amrd1: 139760MB (286228480 sectors) RAID 1 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device ses1 at amr0 bus 1 target 6 lun 0 ses1: Fixed Processor SCSI-2 device ses1: SAF-TE Compliant Device SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/amrd0s1a From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:11:26 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1545216A437; Mon, 13 Mar 2006 20:11:21 +0000 (UTC) (envelope-from rand@meridian-enviro.com) Received: from newman.meridian-enviro.com (newman.meridian-enviro.com [207.109.235.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id D543643D60; Mon, 13 Mar 2006 20:11:08 +0000 (GMT) (envelope-from rand@meridian-enviro.com) X-Envelope-To: questions@freebsd.org Received: from delta.meridian-enviro.com (delta.meridian-enviro.com [10.10.10.43]) by newman.meridian-enviro.com (8.13.1/8.13.1) with ESMTP id k2DKB7cm009256; Mon, 13 Mar 2006 14:11:07 -0600 (CST) (envelope-from rand@meridian-enviro.com) Received: (from rand@localhost) by delta.meridian-enviro.com (8.13.3/8.13.3/Submit) id k2DKB7au015660; Mon, 13 Mar 2006 14:11:07 -0600 (CST) (envelope-from rand@delta.meridian-enviro.com) To: Kris Kennaway References: <4411D6D8.5030101@wmptl.com> <20060311024412.GA26254@xor.obsecurity.org> From: rand@meridian-enviro.com (Douglas K. Rand) Date: 13 Mar 2006 14:11:04 -0600 In-Reply-To: <20060311024412.GA26254@xor.obsecurity.org> Message-ID: <87r7562jhj.fsf@delta.meridian-enviro.com> Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.88/1328/Mon Mar 13 11:13:39 2006 on newman.meridian-enviro.com X-Virus-Status: Clean Cc: amd64@freebsd.org, questions@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:11:26 -0000 Nathan> I seem to recall various threads relating to problems with Nathan> machines running at or above 4GB ram... what if any issues Nathan> still exist? Kris> Some specific drivers do not work on such systems. FreeBSD Kris> itself has no problems. Is there a means of telling (or even better, a list) which drivers handle (or those that don't) more than 4 GB of RAM? From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:27:08 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD3FD16A400; Mon, 13 Mar 2006 20:27:08 +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 9475243D46; Mon, 13 Mar 2006 20:27:08 +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 751E31A4DBD; Mon, 13 Mar 2006 12:27:08 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CDD1451954; Mon, 13 Mar 2006 15:27:07 -0500 (EST) Date: Mon, 13 Mar 2006 15:27:07 -0500 From: Kris Kennaway To: Nathan Vidican Message-ID: <20060313202707.GA99442@xor.obsecurity.org> References: <4411D6D8.5030101@wmptl.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <4411D6D8.5030101@wmptl.com> User-Agent: Mutt/1.4.2.1i Cc: amd64@freebsd.org, questions@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:27:08 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 10, 2006 at 02:43:20PM -0500, Nathan Vidican wrote: > I seem to recall various threads relating to problems with machines runni= ng=20 > at or above 4GB ram... what if any issues still exist? The only potential issues are with specific drivers (e.g. ata). Search the amd64 mailing list archives for more discussion. Kris --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEFdWbWry0BWjoQKURAgoAAKDNqe8kKVNPr5B0BE2KQTj2HoouVACguygE 0XEEFrcUTG8sHi51LPxwpWE= =hVKC -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:32:24 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 9C5A516A428 for ; Mon, 13 Mar 2006 20:32:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E84B743D45 for ; Mon, 13 Mar 2006 20:32:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2DKWHOu098798; Mon, 13 Mar 2006 15:32:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Mon, 13 Mar 2006 15:32:51 -0500 User-Agent: KMail/1.9.1 References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> <200603131406.36636.jhb@freebsd.org> <20060313150423.2b475fd4.wmoran@collaborativefusion.com> In-Reply-To: <20060313150423.2b475fd4.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603131532.53869.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1328/Mon Mar 13 12:13:39 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.2 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, UPPERCASE_25_50 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: bseklecki@collaborativefusion.com Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:32:24 -0000 On Monday 13 March 2006 15:04, Bill Moran wrote: > On Mon, 13 Mar 2006 14:06:34 -0500 > John Baldwin wrote: > > [...] > > > I can't argue that the boot messages don't seem to show anything to > > > indicate that a second logical CPU was found. > > > > Grab the dmesg from /var/run/dmesg.boot rather than /var/log/messages > > please. > > Copyright (c) 1992-2005 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 6.0-RELEASE-p5 #1: Fri Mar 10 16:57:56 EST 2006 > root@:/usr/obj/usr/src/sys/DB64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > Features=0xbfebfbff > Features2=0x641d> > AMD Features=0x20000800 > Hyperthreading: 2 logical CPUs > real memory = 2147221504 (2047 MB) > avail memory = 2066378752 (1970 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 This is a dmesg from an SMP kernel this time. :) Can you provide the output from 'sysctl machdep'? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:41:48 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 E70FA16A400 for ; Mon, 13 Mar 2006 20:41:48 +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 46D0943D7F for ; Mon, 13 Mar 2006 20:41:48 +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 2A3951A4DC0; Mon, 13 Mar 2006 12:41:48 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8FDA15186D; Mon, 13 Mar 2006 15:41:47 -0500 (EST) Date: Mon, 13 Mar 2006 15:41:47 -0500 From: Kris Kennaway To: Bill Moran Message-ID: <20060313204147.GA99753@xor.obsecurity.org> References: <20060313094806.26d70c99.wmoran@collaborativefusion.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <20060313094806.26d70c99.wmoran@collaborativefusion.com> User-Agent: Mutt/1.4.2.1i Cc: bseklecki@collaborativefusion.com, freebsd-amd64@freebsd.org Subject: Re: Incorrect memory probing? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:41:49 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 13, 2006 at 09:48:06AM -0500, Bill Moran wrote: >=20 > Complete dmesg is attached, but notice the memory probing: > Mar 10 14:56:40 kernel: real memory =3D 5100273664 (4864 MB) > Mar 10 14:56:40 kernel: avail memory =3D 4124049408 (3933 MB) > The machine in question (a Dell Poweredge 2850) has 4G of RAM > installed. It looks to me as if the "avail memory" number is > correct (after booting, other systems tools seem to show the > correct amount) >=20 > Is the "real memory" number expected? If so, can someone explain > why it appears to see almost a G more RAM than is actually in the > machine? This is a FAQ, please consult the archives. Kris --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEFdkLWry0BWjoQKURAmXTAJ9QUwhxPFbvpRI+8RsrxifcEl2qhQCgxQbZ GEDRqr9JWiAhE/Y4pa/izAw= =Zy71 -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:49:05 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D01B16A420 for ; Mon, 13 Mar 2006 20:49:05 +0000 (UTC) (envelope-from root@mail.bitdefender.com) Received: from mail.bitdefender.com (ns.bitdefender.com [217.156.83.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1194043D79 for ; Mon, 13 Mar 2006 20:48:34 +0000 (GMT) (envelope-from root@mail.bitdefender.com) Received: (qmail 15573 invoked by uid 0); 13 Mar 2006 22:48:31 +0200 Received: (qmail 10664 invoked by uid 1010); 11 Mar 2006 09:00:03 +0200 Received: from mailx.softwin.ro (194.102.234.6) by mail.bitdefender.com with AES256-SHA encrypted SMTP; 11 Mar 2006 09:00:02 +0200 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by mailx.softwin.ro (8.13.4/8.13.4) with ESMTP id k2B5Qk6i023915 for ; Sat, 11 Mar 2006 07:26:47 +0200 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id CA5ABD03AB; Sat, 11 Mar 2006 05:08:57 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6293516A44C; Sat, 11 Mar 2006 05:08:56 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) X-Original-To: current@freebsd.org 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 B23D816A41F; Sat, 11 Mar 2006 03:48:52 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 942B643D67; Sat, 11 Mar 2006 03:48:49 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k2B3mmZE008068; Fri, 10 Mar 2006 22:48:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id k2B3mmDA040555; Fri, 10 Mar 2006 22:48:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 33D237304D; Fri, 10 Mar 2006 22:48:48 -0500 (EST) From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060311034848.33D237304D@freebsd-current.sentex.ca> Date: Fri, 10 Mar 2006 22:48:48 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-BitDefender-SpamStamp: 1.1.4 049000040111AAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAQ X-BitDefender-Scanner: Clean, Agent: BitDefender Qmail 1.6.2 on mail.bitdefender.com X-BitDefender-Spam: No (0) Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:49:05 -0000 TB --- 2006-03-11 01:52:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-03-11 01:52:33 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-03-11 01:52:33 - cleaning the object tree TB --- 2006-03-11 01:53:10 - checking out the source tree TB --- 2006-03-11 01:53:10 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-03-11 01:53:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-03-11 01:59:36 - building world (CFLAGS=-O2 -pipe) TB --- 2006-03-11 01:59:36 - cd /src TB --- 2006-03-11 01:59:36 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2006-03-11 03:31:31 - generating LINT kernel config TB --- 2006-03-11 03:31:31 - cd /src/sys/amd64/conf TB --- 2006-03-11 03:31:31 - /usr/bin/make -B LINT TB --- 2006-03-11 03:31:31 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-03-11 03:31:31 - cd /src TB --- 2006-03-11 03:31:31 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 11 03:31:31 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] touch export_syms awk -f /src/sys/modules/ispfw/../../conf/kmod_syms.awk ispfw.ko export_syms | xargs -J% objcopy % ispfw.ko objcopy --strip-debug ispfw.ko ===> iwi (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/iwi/../../dev/iwi/if_iwi.c /src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_init': /src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2450: warning: int format, different type arg (arg 3) /src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2459: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /src/sys/modules/iwi. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-03-11 03:48:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-03-11 03:48:47 - ERROR: failed to build lint kernel TB --- 2006-03-11 03:48:47 - tinderbox aborted TB --- 1.32 user 6.80 system 6974.31 real _______________________________________________ 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" -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://www.bitdefender.com/ From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:49:09 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 61E6B16A429 for ; Mon, 13 Mar 2006 20:49:09 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD38F43D69 for ; Mon, 13 Mar 2006 20:49:02 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IW3007MQ35ML420@osl1smout1.broadpark.no> for freebsd-amd64@freebsd.org; Mon, 13 Mar 2006 21:48:58 +0100 (CET) Received: from kg-work.kg4.no ([80.202.172.162]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0IW3000R935MJJ60@osl1sminn1.broadpark.no> for freebsd-amd64@freebsd.org; Mon, 13 Mar 2006 21:48:58 +0100 (CET) Date: Mon, 13 Mar 2006 21:48:57 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <8B10B63B-7777-4B0F-B9BD-DB30918D5B24@justken.net> To: freebsd-amd64@freebsd.org Message-id: <20060313214857.3d0db65a.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <8B10B63B-7777-4B0F-B9BD-DB30918D5B24@justken.net> Subject: Re: nvnet on MSI K8NGM2 motherboard & FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:49:09 -0000 On Mon, 13 Mar 2006 13:00:57 -0400 Ken Easson wrote: > I've recently purchased a new AMD64 bases system with an all in one > motherboard. K8NGM2 on board is the nVidia 10/100 MCP51 ethernet > controller. > running freebsd 6.0-RELEASE-p5 the system doesn't detect the ethernet > card. When i boot using acip the system reboots, so i'm booting FWIW, I used this patch on 6.0-RELEASE to get nve ethernet working: http://sources.zabbadoz.net/freebsd/patchset/nve-20051211-01.diff after that I cvsup'en to -stable and rebuilt world, and nve has been working since. I get theses messages occasionally, but they don't seem to indicate any real trouble: Mar 12 17:22:52 kg-fil kernel: nve0: device timeout (1) Mar 12 17:22:52 kg-fil kernel: nve0: link state changed to DOWN Mar 12 17:22:53 kg-fil kernel: nve0: link state changed to UP This on a K8-NF-9 motherboard. YMMV. -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:57:18 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 59A8916A422 for ; Mon, 13 Mar 2006 20:57:18 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35AF243D66 for ; Mon, 13 Mar 2006 20:57:15 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2DKvCVx000877; Mon, 13 Mar 2006 17:57:12 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-amd64@freebsd.org Date: Mon, 13 Mar 2006 17:56:56 -0300 User-Agent: KMail/1.9.1 References: <8B10B63B-7777-4B0F-B9BD-DB30918D5B24@justken.net> <20060313214857.3d0db65a.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20060313214857.3d0db65a.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603131756.56458.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: nvnet on MSI K8NGM2 motherboard & FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:57:18 -0000 On Monday 13 March 2006 17:48, Torfinn Ingolfsen wrote: > On Mon, 13 Mar 2006 13:00:57 -0400 > > Ken Easson wrote: > > I've recently purchased a new AMD64 bases system with an all in one > > motherboard. K8NGM2 on board is the nVidia 10/100 MCP51 ethernet > > controller. > > running freebsd 6.0-RELEASE-p5 the system doesn't detect the ethernet > > card. When i boot using acip the system reboots, so i'm booting > > FWIW, I used this patch on 6.0-RELEASE to get nve ethernet working: > http://sources.zabbadoz.net/freebsd/patchset/nve-20051211-01.diff > > after that I cvsup'en to -stable and rebuilt world, and nve has been > working since. > I get theses messages occasionally, but they don't seem to indicate > any real trouble: > Mar 12 17:22:52 kg-fil kernel: nve0: device timeout (1) > Mar 12 17:22:52 kg-fil kernel: nve0: link state changed to DOWN > Mar 12 17:22:53 kg-fil kernel: nve0: link state changed to UP > > This on a K8-NF-9 motherboard. YMMV. on older 6.0-stable it worked fine for me and since releng_6 went to 6.1-Pr= e I=20 get this timeouts but my connection really stops working and no chance to g= et=20 it back until shutdown -p and power on again, I installed another NIC Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 20:58:10 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C1AE16A44A; Mon, 13 Mar 2006 20:58:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59AF743D4C; Mon, 13 Mar 2006 20:58:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k2DKw15a063597; Mon, 13 Mar 2006 13:58:02 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4415DCD1.20603@samsco.org> Date: Mon, 13 Mar 2006 13:57:53 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <4411D6D8.5030101@wmptl.com> <20060313202707.GA99442@xor.obsecurity.org> In-Reply-To: <20060313202707.GA99442@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: amd64@freebsd.org, questions@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 20:58:10 -0000 Kris Kennaway wrote: > On Fri, Mar 10, 2006 at 02:43:20PM -0500, Nathan Vidican wrote: > >>I seem to recall various threads relating to problems with machines running >>at or above 4GB ram... what if any issues still exist? > > > The only potential issues are with specific drivers (e.g. ata). > Search the amd64 mailing list archives for more discussion. > > Kris Ok, off the top of my head: Storage drivers that are known to work with amd64 and 4GB of RAM or more: aac amr iir (6.1 and above only) ips ahc ahd ciss arcmsr mpt isp Storage drivers that should work, but might need more testing and validation: twa twe mlx mly amd trm Storage drivers that are known to have problems under load: ata hptmv Storage drivers that simply will not work:: asr asr asr asr asr pst ida sym This list isn't definitive, and I've purposely excluded ISA controllers and controllers that are significantly out of date, but it's close enough to give you a good idea of what to shop for. Personally, I feel a bit bad that ata and sym aren't in the first group, but there are only so many hours in the day. Both present interesting challenges. Scott From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 21:17:16 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0629C16A423; Mon, 13 Mar 2006 21:17:16 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D73043D5F; Mon, 13 Mar 2006 21:17:15 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.colo.erols.net with local (Exim 4.52 (FreeBSD)) id 1FIuPa-000IVj-DK; Mon, 13 Mar 2006 16:17:06 -0500 Date: Mon, 13 Mar 2006 16:17:06 -0500 From: Gary Palmer To: Scott Long Message-ID: <20060313211706.GA72123@in-addr.com> References: <4411D6D8.5030101@wmptl.com> <20060313202707.GA99442@xor.obsecurity.org> <4415DCD1.20603@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4415DCD1.20603@samsco.org> Cc: amd64@freebsd.org, questions@freebsd.org, Kris Kennaway Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 21:17:16 -0000 On Mon, Mar 13, 2006 at 01:57:53PM -0700, Scott Long wrote: > > Storage drivers that simply will not work:: > > asr > asr > asr > asr > asr > pst > ida > sym Any particular reason "asr" is listed 5 times? Did you mean to replace some of them with other drivers, or are you emphatically sure that asr is broken? :-) From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 21:22:09 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9969916A425; Mon, 13 Mar 2006 21:22:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE9843DA2; Mon, 13 Mar 2006 21:21:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k2DLLi2g063791; Mon, 13 Mar 2006 14:21:46 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4415E262.5010908@samsco.org> Date: Mon, 13 Mar 2006 14:21:38 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Palmer References: <4411D6D8.5030101@wmptl.com> <20060313202707.GA99442@xor.obsecurity.org> <4415DCD1.20603@samsco.org> <20060313211706.GA72123@in-addr.com> In-Reply-To: <20060313211706.GA72123@in-addr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: amd64@freebsd.org, questions@freebsd.org, Kris Kennaway Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 21:22:09 -0000 Gary Palmer wrote: > On Mon, Mar 13, 2006 at 01:57:53PM -0700, Scott Long wrote: > >>Storage drivers that simply will not work:: >> >>asr >>asr >>asr >>asr >>asr >>pst >>ida >>sym > > > Any particular reason "asr" is listed 5 times? Did you mean to replace > some of them with other drivers, or are you emphatically sure that asr > is broken? :-) It's there to make a point. Do not buy asr hardware and expect it to work on amd64. The driver comes from the vendor, and the vendor hasn't had any interest in supporting it since 2001. There are many other vendors who make much higher quality cards and who are actively interested in supporting FreeBSD, so I recommend doing business with them. Scott From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 22:18:28 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 331B016A423 for ; Mon, 13 Mar 2006 22:18:28 +0000 (UTC) (envelope-from sangwoos@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 880D743D48 for ; Mon, 13 Mar 2006 22:18:27 +0000 (GMT) (envelope-from sangwoos@gmail.com) Received: by nproxy.gmail.com with SMTP id g2so952013nfe for ; Mon, 13 Mar 2006 14:18:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gb5xRut51ePuboieDEq01IGxaJZEaDN8ZOdKpnCZSQRKUIivyRJCuLrK4IFUy48pEaA2yG9wr35CoZDub9nO94gIPKRBYqtHx3u5+qMsqcn1MvYe8MBBD2gK6+IUFV+qdnQIoUhkpiyTOn7z/wUIDYb24R9sxggwMtv0OxobHgk= Received: by 10.49.69.16 with SMTP id w16mr2008276nfk; Mon, 13 Mar 2006 14:18:25 -0800 (PST) Received: by 10.48.207.11 with HTTP; Mon, 13 Mar 2006 14:18:25 -0800 (PST) Message-ID: <4cbd01f40603131418k56b63741t@mail.gmail.com> Date: Tue, 14 Mar 2006 07:18:25 +0900 From: "Sangwoo Shim" To: "Herve Boulouis" In-Reply-To: <20060313115205.GA17399@ra.aabs> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <60F1B0FC76F1504A91839905DA7EBDB603903C@ssuzexmb3.amd.com> <2fd864e0603130256l52f5b0aoa5e2a4c720aa3e10@mail.gmail.com> <2fd864e0603130300m12a02932tb82c3c5fa4ac1973@mail.gmail.com> <200603130823.35433.joao@matik.com.br> <20060313115205.GA17399@ra.aabs> Cc: freebsd-amd64@freebsd.org Subject: Re: Fwd: NUMA and Dual-Core Support X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 22:18:28 -0000 2006/3/13, Herve Boulouis : > Le 13/03/2006 08:23, JoaoBR a =E9crit: > > > > Is the memory access with dual-core (not HT) the the same as with > > dual-processores? Would NUMA have any impact on dual-cores? > > Since the memory controller is shared between the 2 cores on dual core > opterons, I doubt you'll see any benefits on memory accesses with a NUMA > aware scheduler. > There are multi-processor opteron systems (e.g., 2 of dual-core processors)= :-) > -- > Herve Boulouis > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > -- Regards, Sangwoo Shim From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 22:38:47 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CD7816A400; Mon, 13 Mar 2006 22:38:47 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6988243D45; Mon, 13 Mar 2006 22:38:46 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (t8snclf38se5pl9o@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id k2DMchcG036600; Mon, 13 Mar 2006 14:38:43 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id k2DMcgdS036598; Mon, 13 Mar 2006 14:38:42 -0800 (PST) (envelope-from jmg) Date: Mon, 13 Mar 2006 14:38:42 -0800 From: John-Mark Gurney To: "Douglas K. Rand" Message-ID: <20060313223842.GN840@funkthat.com> Mail-Followup-To: "Douglas K. Rand" , Kris Kennaway , amd64@freebsd.org, questions@freebsd.org References: <4411D6D8.5030101@wmptl.com> <20060311024412.GA26254@xor.obsecurity.org> <87r7562jhj.fsf@delta.meridian-enviro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r7562jhj.fsf@delta.meridian-enviro.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: amd64@freebsd.org, questions@freebsd.org, Kris Kennaway Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 22:38:47 -0000 Douglas K. Rand wrote this message on Mon, Mar 13, 2006 at 14:11 -0600: > Nathan> I seem to recall various threads relating to problems with > Nathan> machines running at or above 4GB ram... what if any issues > Nathan> still exist? > > Kris> Some specific drivers do not work on such systems. FreeBSD > Kris> itself has no problems. > > Is there a means of telling (or even better, a list) which drivers > handle (or those that don't) more than 4 GB of RAM? http://www.freebsd.org/projects/busdma/ -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 13 23:15:12 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E64516A427; Mon, 13 Mar 2006 23:15:12 +0000 (UTC) (envelope-from igor@hybrid-lab.co.uk) Received: from mra04.ch.as12513.net (mra04.ch.as12513.net [82.153.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id D828A43D45; Mon, 13 Mar 2006 23:15:11 +0000 (GMT) (envelope-from igor@hybrid-lab.co.uk) Received: from localhost (localhost [127.0.0.1]) by mra04.ch.as12513.net (Postfix) with ESMTP id 1EBF7C05F7; Mon, 13 Mar 2006 23:15:12 +0000 (GMT) Received: from mra04.ch.as12513.net ([127.0.0.1]) by localhost (mra04.ch.as12513.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25455-01-30; Mon, 13 Mar 2006 23:15:11 +0000 (GMT) Received: from [81.168.65.150] (unknown [81.168.65.150]) by mra04.ch.as12513.net (Postfix) with ESMTP id 66310C05D7; Mon, 13 Mar 2006 23:15:11 +0000 (GMT) In-Reply-To: <20060313223842.GN840@funkthat.com> References: <4411D6D8.5030101@wmptl.com> <20060311024412.GA26254@xor.obsecurity.org> <87r7562jhj.fsf@delta.meridian-enviro.com> <20060313223842.GN840@funkthat.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Igor Mozolevsky Date: Mon, 13 Mar 2006 23:16:07 +0000 To: John-Mark Gurney X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk Cc: amd64@freebsd.org, questions@freebsd.org Subject: busdma/ata & sysinstall [Was: Re: 6.0-RELEASE/AMD64 Ram Capacity?] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 23:15:12 -0000 I've spent a considerable amount of time looking through ata/busdma drivers, they need a lot of tidying up, lack of comments doesn't help either... i'd like to grab the handle on busdma & ata projects, with the aim of having them in production state for 6.5-STABLE. I was also looking at systinstall, which requires a major rework, and we have some ideas for that too, I'd say also aim for 6.5. I also am going to talk to Scott L. about it in the near future. If you have any ideas/suggestions for the above drop me an email. Cheers, Igor :-) On 13 Mar 2006, at 22:38, John-Mark Gurney wrote: > Douglas K. Rand wrote this message on Mon, Mar 13, 2006 at 14:11 > -0600: >> Nathan> I seem to recall various threads relating to problems with >> Nathan> machines running at or above 4GB ram... what if any issues >> Nathan> still exist? >> >> Kris> Some specific drivers do not work on such systems. FreeBSD >> Kris> itself has no problems. >> >> Is there a means of telling (or even better, a list) which drivers >> handle (or those that don't) more than 4 GB of RAM? > > http://www.freebsd.org/projects/busdma/ > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64- > unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 07:34:42 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 E152A16A401 for ; Tue, 14 Mar 2006 07:34:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CD3A43D45 for ; Tue, 14 Mar 2006 07:34:42 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1FJ43F-0004jj-Bs for freebsd-amd64@freebsd.org; Tue, 14 Mar 2006 09:34:41 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-amd64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Mar 2006 09:34:41 +0200 From: Danny Braniss Message-ID: Subject: acpi problems with IBM/Lenovo/ThinkCentre X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 07:34:43 -0000 this is an intel/xeon dual core, booting with a 32bit kernel: FreeBSD 6.1-PRERELEASE #4: Mon Mar 13 09:52:47 IST 2006 danny@bsd:/r+d/obj/bsd/i386/r+d/6.1/src/sys/HUJI ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf44 Stepping = 4 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20000000 Hyperthreading: 2 logical CPUs ... acpi0: on motherboard ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB1._PRW] (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB1._PRW] (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB2._PRW] (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB2._PRW] (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB3._PRW] (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB3._PRW] (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB4._PRW] (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB4._PRW] (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USBE._PRW] (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USBE._PRW] (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE ... which probably break the usb stuff, but with a 64kernel: ... ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), AE_AML_ALIGNMENT ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), AE_AML_ALIGNMENT ... but then: ... Mar 14 09:09:10 ibm kernel: ACPI-0501: *** Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT Mar 14 09:09:10 ibm kernel: ACPI-1304: *** Error: Method execution failed [\_TZ_.THM0._TMP] (Node 0xffffff0000b77b40), AE_AML_ALIGNMENT Mar 14 09:09:20 ibm kernel: ACPI-0501: *** Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT Mar 14 09:09:20 ibm kernel: ACPI-1304: *** Error: Method execution failed [\_TZ_.THM0._TMP] (Node 0xffffff0000b77b40), AE_AML_ALIGNMENT Mar 14 09:09:30 ibm kernel: ACPI-0501: *** Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT Mar 14 09:09:30 ibm kernel: ACPI-1304: *** Error: Method execution failed [\_TZ_.THM0._TMP] (Node 0xffffff0000b77b40), AE_AML_ALIGNMENT ... for ever, and ever... anything to fix this? (not interested in turning off acpi :-) danny From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 08:15:11 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 C84CE16A400 for ; Tue, 14 Mar 2006 08:15:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C5C143D49 for ; Tue, 14 Mar 2006 08:15:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id EC7BE2000B4; Tue, 14 Mar 2006 09:15:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 089A62000BA; Tue, 14 Mar 2006 09:15:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AF50344487E; Tue, 14 Mar 2006 08:13:57 +0000 (UTC) Date: Tue, 14 Mar 2006 08:13:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: JoaoBR In-Reply-To: <200603131756.56458.joao@matik.com.br> Message-ID: <20060314081213.B73618@maildrop.int.zabbadoz.net> References: <8B10B63B-7777-4B0F-B9BD-DB30918D5B24@justken.net> <20060313214857.3d0db65a.torfinn.ingolfsen@broadpark.no> <200603131756.56458.joao@matik.com.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-amd64@freebsd.org Subject: Re: nvnet on MSI K8NGM2 motherboard & FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 08:15:11 -0000 On Mon, 13 Mar 2006, JoaoBR wrote: [nve(4)] > on older 6.0-stable it worked fine for me and since releng_6 went to 6.1-Pre I > get this timeouts but my connection really stops working and no chance to get > it back until shutdown -p and power on again, I installed another NIC could you tell me which board and the output of pciconf -lv and if you are running i386 or amd64 (though I guess the latter if posting to this list, just to confirm). -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 08:15:17 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 6FE1616A41F; Tue, 14 Mar 2006 08:15:17 +0000 (UTC) (envelope-from root@scienceclue.ath.cx) Received: from scienceclue.ath.cx (mic92-1-87-90-12-116.dsl.club-internet.fr [87.90.12.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id C268443D49; Tue, 14 Mar 2006 08:15:14 +0000 (GMT) (envelope-from root@scienceclue.ath.cx) Received: from scienceclue.ath.cx (localhost [127.0.0.1]) by scienceclue.ath.cx (8.13.4/8.13.4) with ESMTP id k2E8GKVe055705; Tue, 14 Mar 2006 09:16:20 +0100 (CET) (envelope-from root@scienceclue.ath.cx) Received: (from root@localhost) by scienceclue.ath.cx (8.13.4/8.13.4/Submit) id k2E8GCPF055704; Tue, 14 Mar 2006 09:16:12 +0100 (CET) (envelope-from root) Date: Tue, 14 Mar 2006 09:16:12 +0100 From: Mathieu Prevot To: Dan Nelson Message-ID: <20060314081612.GA55608@scienceclue.ath.cx> References: <20060313161740.GA56875@scienceclue.ath.cx> <20060313171341.GA7636@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20060313171341.GA7636@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD-AMD64 6.1-PRERELEASE X-URL: http://scienceclue.ath.cx Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Creating real bool type for simulation in physics X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mathieu Prevot List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 08:15:17 -0000 On Mon, Mar 13, 2006 at 11:13:41AM -0600, Dan Nelson wrote: > In the last episode (Mar 13), Mathieu Prevot said: > > I use freebsd/amd64 (RELENG_6) for simulation in physics. I am > > working on the Ising model: an assembly of spins (micromagnets) which > > interact and which are in one of two states (up or down). Until now I > > use char to define the state of each spin (-1 or 1), however, I > > remarked that most time is spent on memory I/O. Most of bits are > > unused. > > > > I think that if I can use just one bit per spin, I can have something > > much faster. I need advices on how to use it. I guess I can't define > > a new type with a 1/8 byte height (or one bit), yes ? What variable > > (int, char...) do you recommend to use for a sempron 64 bits. I think > > I'll need to define new operators (opaque operators, built with bit > > operators) to switch my spins or use directly the following: & | ^ ~ > > ... > > Take a look at the "bitstring" functions, which let you allocate an > array of "bits" and manipulate them individually. They're documented > in the bitstring manpage. Thank you. bitstring functions (macros) are based on char (8bits) type. This is not ANSI or POSIX, I will include /usr/src/sys/sys/bitstring.h in my program for portability. vi (nvi), and bind9 also use these macros, but are a bit different. -- Mathieu P http://scienceclue.ath.cx From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 10:06:09 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 0C62116A41F for ; Tue, 14 Mar 2006 10:06:09 +0000 (UTC) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (daemon.nanophys.kth.se [130.237.35.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A05C43D46 for ; Tue, 14 Mar 2006 10:06:07 +0000 (GMT) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (localhost [127.0.0.1]) by omega.nanophys.kth.se (8.13.4/8.13.1) with ESMTP id k2EA6EL7011676; Tue, 14 Mar 2006 11:06:14 +0100 (CET) (envelope-from kono@kth.se) Received: from localhost (localhost [[UNIX: localhost]]) by omega.nanophys.kth.se (8.13.4/8.13.1/Submit) id k2EA6EaJ011675; Tue, 14 Mar 2006 11:06:14 +0100 (CET) (envelope-from kono@kth.se) X-Authentication-Warning: omega.nanophys.kth.se: kono set sender to kono@kth.se using -f From: Alexander Konovalenko Organization: KTH To: freebsd-amd64@freebsd.org Date: Tue, 14 Mar 2006 11:06:12 +0100 User-Agent: KMail/1.9.1 References: <20060313221836.5491916A420@hub.freebsd.org> In-Reply-To: <20060313221836.5491916A420@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603141106.13693.kono@kth.se> Cc: Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kono@kth.se List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 10:06:09 -0000 > Hi > Since some time (>6.0R) I have the impression that amd64 runs slower than > i386. Now I run some tests on identical hardware and using ubench confirmes > this. Somebody has comments on this? I have Dual core AMD64 4400+ and FreeBSD RELENG_5. I don't have FreeBSD i386 installed but you can just compare benchmarks. ubench uses all CPU/cores by default, when one ubench is running, top shows: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 11528 XXXX 111 0 3572K 880K RUN 1 0:12 93.64% 42.29% ubench 11529 XXXX 111 0 3572K 880K CPU0 1 0:11 97.21% 41.16% ubench 11526 XXXX -8 0 3572K 880K piperd 0 0:17 41.76% 31.98% ubench one ubench executed (with no -s flag = use all CPU, default): Unix Benchmark Utility v.0.3 Copyright (C) July, 1999 PhysTech, Inc. Author: Sergei Viznyuk http://www.phystech.com/download/ubench.html FreeBSD 5.5-PRERELEASE FreeBSD 5.5-PRERELEASE #12: Sun Mar 5 17:34:07 CET 2006 XXXX@XXXX:/usr/obj/usr/src/sys/DAEMON64SMP amd64 Ubench CPU: 238149 Ubench MEM: 255459 -------------------- Ubench AVG: 246804 two ubench executed with -s flag (use single CPU only): Ubench Single CPU: 120184 (0.40s) Ubench Single MEM: 126787 (0.39s) ----------------------------------- Ubench Single AVG: 123485 Ubench Single CPU: 121000 (0.41s) Ubench Single MEM: 128762 (0.40s) ----------------------------------- Ubench Single AVG: 124881 one ubench executed with -s flag (use single CPU only): Ubench Single CPU: 123251 (0.40s) Ubench Single MEM: 161494 (0.40s) ----------------------------------- Ubench Single AVG: 142372 /Alexander Konovalenko +46-8-5537-8142 (office) +46-7-3752-2116 http://daemon.nanophys.kth.se/~kono Royal Institute of Technology (KTH) Nanostructure Physics Department, Albanova Roslagstullsbacken 21 10691 Stockholm Sweden From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 10:41:03 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 5DB2716A400 for ; Tue, 14 Mar 2006 10:41:03 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 884A043D46 for ; Tue, 14 Mar 2006 10:41:02 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2EAetN9033171; Tue, 14 Mar 2006 07:40:56 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: kono@kth.se Date: Tue, 14 Mar 2006 07:40:37 -0300 User-Agent: KMail/1.9.1 References: <20060313221836.5491916A420@hub.freebsd.org> <200603141106.13693.kono@kth.se> In-Reply-To: <200603141106.13693.kono@kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603140740.38388.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 10:41:03 -0000 On Tuesday 14 March 2006 07:06, Alexander Konovalenko wrote: > > Hi > > Since some time (>6.0R) I have the impression that amd64 runs slower th= an > > i386. Now I run some tests on identical hardware and using ubench > > confirmes this. Somebody has comments on this? > > I have Dual core AMD64 4400+ and FreeBSD RELENG_5. I don't have FreeBSD > i386 installed but you can just compare benchmarks. > > ubench uses all CPU/cores by default, when one ubench is running, top > shows: > so where is your comparism? My point was that the same hardware is faster=20 running i386 I experience this also on X2 machines but do not have two machines to compa= re I have a X2-4400-SMP running amd64 and a X2-4200-SMP running i386 and it gi= ves=20 me the same numbers running ubench Jo=E3o > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU > COMMAND 11528 XXXX 111 0 3572K 880K RUN 1 0:12 93.64% > 42.29% ubench 11529 XXXX 111 0 3572K 880K CPU0 1 0:11 > 97.21% 41.16% ubench 11526 XXXX -8 0 3572K 880K piperd 0 =20 > 0:17 41.76% 31.98% ubench > > > one ubench executed (with no -s flag =3D use all CPU, default): > > Unix Benchmark Utility v.0.3 > Copyright (C) July, 1999 PhysTech, Inc. > Author: Sergei Viznyuk > http://www.phystech.com/download/ubench.html > FreeBSD 5.5-PRERELEASE FreeBSD 5.5-PRERELEASE #12: Sun Mar 5 17:34:07 CET > 2006 XXXX@XXXX:/usr/obj/usr/src/sys/DAEMON64SMP amd64 > Ubench CPU: 238149 > Ubench MEM: 255459 > -------------------- > Ubench AVG: 246804 > > > two ubench executed with -s flag (use single CPU only): > > Ubench Single CPU: 120184 (0.40s) > Ubench Single MEM: 126787 (0.39s) > ----------------------------------- > Ubench Single AVG: 123485 > > Ubench Single CPU: 121000 (0.41s) > Ubench Single MEM: 128762 (0.40s) > ----------------------------------- > Ubench Single AVG: 124881 > > > one ubench executed with -s flag (use single CPU only): > > Ubench Single CPU: 123251 (0.40s) > Ubench Single MEM: 161494 (0.40s) > ----------------------------------- > Ubench Single AVG: 142372 > > > /Alexander Konovalenko > > +46-8-5537-8142 (office) > +46-7-3752-2116 > http://daemon.nanophys.kth.se/~kono > > Royal Institute of Technology (KTH) > Nanostructure Physics Department, Albanova > Roslagstullsbacken 21 > 10691 Stockholm > Sweden > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 11:38:13 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 A9A0416A420 for ; Tue, 14 Mar 2006 11:38:13 +0000 (UTC) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (daemon.nanophys.kth.se [130.237.35.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id E368143D53 for ; Tue, 14 Mar 2006 11:38:12 +0000 (GMT) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (localhost [127.0.0.1]) by omega.nanophys.kth.se (8.13.4/8.13.1) with ESMTP id k2EBcQDP091567; Tue, 14 Mar 2006 12:38:26 +0100 (CET) (envelope-from kono@kth.se) Received: from localhost (localhost [[UNIX: localhost]]) by omega.nanophys.kth.se (8.13.4/8.13.1/Submit) id k2EBcQkE091566; Tue, 14 Mar 2006 12:38:26 +0100 (CET) (envelope-from kono@kth.se) X-Authentication-Warning: omega.nanophys.kth.se: kono set sender to kono@kth.se using -f From: Alexander Konovalenko Organization: KTH To: JoaoBR Date: Tue, 14 Mar 2006 12:38:25 +0100 User-Agent: KMail/1.9.1 References: <20060313221836.5491916A420@hub.freebsd.org> <200603141106.13693.kono@kth.se> <200603140740.38388.joao@matik.com.br> In-Reply-To: <200603140740.38388.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603141238.26235.kono@kth.se> Cc: freebsd-amd64@freebsd.org 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 Reply-To: kono@kth.se List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 11:38:13 -0000 On Tuesday 14 March 2006 11:40, JoaoBR wrote: > > so where is your comparism? My point was that the same hardware is faster > running i386 > > I experience this also on X2 machines but do not have two machines to > compare I have a X2-4400-SMP running amd64 and a X2-4200-SMP running i386 > and it gives me the same numbers running ubench > I have experienced that -O3 and -ffast-math optimizations flags on AMD64 might cause degrade in performance, meaning that -O2 is the fastest. When you compile your ports what opt. flags do you use? Try to reinstall ubench with different flags. Also code produced with gcc4.x is faster then system compiler and has no degrade effect. Some time ago I was interested in fast scientific computations and did some primitive benchmark tests (http://daemon.nanophys.kth.se/~kono/testfcpu) I just wonder what will happen if you run ubench (compiled for i386) on AMD64, will performance overcome amd64 ubench? /Alexander Konovalenko From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 11:49:32 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 8E33616A422 for ; Tue, 14 Mar 2006 11:49:32 +0000 (UTC) (envelope-from ray@redshift.com) Received: from mail-fs2.redshift.com (mail5.redshift.com [216.228.2.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64E8E43D70 for ; Tue, 14 Mar 2006 11:49:27 +0000 (GMT) (envelope-from ray@redshift.com) Received: (qmail 16571 invoked by uid 89); 14 Mar 2006 11:49:25 -0000 Received: by simscan 1.2.0 ppid: 16566, pid: 16567, t: 0.0863s scanners: attach: 1.2.0 clamav: 0.88/m:36/d:1318 Received: from unknown (HELO workstation) (216.228.19.21) by mail-fs2.redshift.com with SMTP; 14 Mar 2006 11:49:25 -0000 Message-Id: <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Tue, 14 Mar 2006 03:49:32 -0800 To: kono@kth.se,JoaoBR From: ray@redshift.com In-Reply-To: <200603141238.26235.kono@kth.se> References: <200603140740.38388.joao@matik.com.br> <20060313221836.5491916A420@hub.freebsd.org> <200603141106.13693.kono@kth.se> <200603140740.38388.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@freebsd.org 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: Tue, 14 Mar 2006 11:49:32 -0000 At 12:38 PM 3/14/2006 +0100, Alexander Konovalenko wrote: | On Tuesday 14 March 2006 11:40, JoaoBR wrote: | > | > so where is your comparism? My point was that the same hardware is faster | > running i386 | > | > I experience this also on X2 machines but do not have two machines to | > compare I have a X2-4400-SMP running amd64 and a X2-4200-SMP running i386 | > and it gives me the same numbers running ubench | > | | I have experienced that -O3 and -ffast-math optimizations flags on AMD64 might | cause degrade in performance, meaning that -O2 is the fastest. When you | compile your ports what opt. flags do you use? Try to reinstall ubench with | different flags. Also code produced with gcc4.x is faster then system | compiler and has no degrade effect. Some time ago I was interested in fast | scientific computations and did some primitive benchmark tests | (http://daemon.nanophys.kth.se/~kono/testfcpu) | | I just wonder what will happen if you run ubench (compiled for i386) on AMD64, | will performance overcome amd64 ubench? | | | | /Alexander Konovalenko +2 cents mode on... :) I'm just coming in on the tail end of the message (missed the previous stuff). I recently did some benchmarks between AMD64 and i386 (version 5.4) on the same hardware. I initially saw that the i386 ran faster also. However, after searching a bit further, I discovered that I had made an error: the i386 kernel has the SMP stuff compiled into the generic kernel by default, while the AMD64 (at least on 5.4) does not. It has a separate kernel file called SMP (as I recall), which adds the SMP line and then does an include for the rest of the generic kernel config file (or something to that effect). Anyway, if you are testing back and forth, it's easy to forget that and end up accidently testing an i386 with SMP against an AMD64 without SMP. Like I say, I'm coming in on the tail end of the thread, so I might be off base, but it might be something worth double checking - just to be 100% sure. :-) Ray From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 12:08:49 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 F310C16A422 for ; Tue, 14 Mar 2006 12:08:49 +0000 (UTC) (envelope-from freebsd-amd64@molecon.ru) Received: from mail.migtel.ru (mail.migtel.ru [80.240.208.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E90843D45 for ; Tue, 14 Mar 2006 12:08:49 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from mail.migtel.ru (unknown [80.240.208.45]) by mail.migtel.ru (Postfix) with ESMTP id E30B74BEFE0 for ; Tue, 14 Mar 2006 15:08:47 +0300 (MSK) Received: from [10.20.5.22] (unknown [10.20.5.22]) by mail.migtel.ru (Postfix) with ESMTP for ; Tue, 14 Mar 2006 15:08:47 +0300 (MSK) Date: Tue, 14 Mar 2006 15:02:34 +0300 From: Oleg Rusanov X-Mailer: The Bat! (v3.65.03) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <455581941.20060314150234@molecon.ru> To: freebsd-amd64@freebsd.org In-Reply-To: <441519DD.1010301@cs.tu-berlin.de> References: <1267011631.20060313021703@molecon.ru> <441519DD.1010301@cs.tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP on Free.migtel.ru Subject: Re[2]: grep -R 'zlib' /usr/ports/ crashed server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 12:08:50 -0000 Çäðàâñòâóéòå, Björn. Âû ïèñàëè 13 ????? 2006 ?., 10:06:05: > An unclean filesystem could be the reason for this problem. I had this > several times. I suggest to run fsck *not* using background fsck in this > case. > Björn How can i do this on remote production server without rebooting? -- Regards, Oleg mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 12:27:22 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 2061E16A401 for ; Tue, 14 Mar 2006 12:27:22 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 566BB43D45 for ; Tue, 14 Mar 2006 12:27:21 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2ECR0Lr001132; Tue, 14 Mar 2006 09:27:01 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: ray@redshift.com Date: Tue, 14 Mar 2006 09:27:00 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> In-Reply-To: <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603140927.00320.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: kono@kth.se, freebsd-amd64@freebsd.org 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: Tue, 14 Mar 2006 12:27:22 -0000 On Tuesday 14 March 2006 08:49, ray@redshift.com wrote: > At 12:38 PM 3/14/2006 +0100, Alexander Konovalenko wrote: > | On Tuesday 14 March 2006 11:40, JoaoBR wrote: > | > so where is your comparism? My point was that the same hardware is > | > faster running i386 > | > > | I have experienced that -O3 and -ffast-math optimizations flags on AMD64 > | might cause degrade in performance, meaning that -O2 is the fastest. Wh= en > | you compile your ports what opt. flags do you use? Try to reinstall > | ubench with different flags. Also code produced with gcc4.x is faster > | then system compiler and has no degrade effect. Some time ago I was > | interested in fast scientific computations and did some primitive > | benchmark tests > | (http://daemon.nanophys.kth.se/~kono/testfcpu) > | > | I just wonder what will happen if you run ubench (compiled for i386) on > | AMD64, will performance overcome amd64 ubench? > | and what would be the point here?=20 the amd64 systems I checked are running amd64 the i386 systems I checked are running i386 and entirely I mean > > I'm just coming in on the tail end of the message (missed the previous > stuff). I recently did some benchmarks between AMD64 and i386 (version 5.= 4) > on the same hardware. I initially saw that the i386 ran faster also.=20 > However, after searching a bit further, I discovered that I had made an > error: the i386 kernel has the SMP stuff compiled into the generic kernel > by default, while the AMD64 (at least on 5.4) does not. It has a separate > kernel file called SMP (as I recall), which adds the SMP line and then do= es > an include for the rest of the generic kernel config file (or something to > that effect). > > Anyway, if you are testing back and forth, it's easy to forget that and e= nd > up accidently testing an i386 with SMP against an AMD64 without SMP. > obviously I checked UP kernels against UP and SMP against SMP but anyway running SMP kernel on single processor systems should not affect= =20 this tests Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 12:44:12 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 CD1E016A400 for ; Tue, 14 Mar 2006 12:44:12 +0000 (UTC) (envelope-from ray@redshift.com) Received: from mail-fs2.redshift.com (mail-smtp.redshift.com [216.228.2.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2817543D45 for ; Tue, 14 Mar 2006 12:44:12 +0000 (GMT) (envelope-from ray@redshift.com) Received: (qmail 7318 invoked by uid 89); 14 Mar 2006 12:44:11 -0000 Received: by simscan 1.2.0 ppid: 7314, pid: 7315, t: 0.0894s scanners: attach: 1.2.0 clamav: 0.88/m:36/d:1318 Received: from unknown (HELO workstation) (216.228.19.21) by mail-fs2.redshift.com with SMTP; 14 Mar 2006 12:44:11 -0000 Message-Id: <3.0.1.32.20060314044416.00af7f30@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Tue, 14 Mar 2006 04:44:16 -0800 To: JoaoBR From: ray@redshift.com In-Reply-To: <200603140927.00320.joao@matik.com.br> References: <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> <200603140740.38388.joao@matik.com.br> <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: kono@kth.se, freebsd-amd64@freebsd.org 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: Tue, 14 Mar 2006 12:44:12 -0000 At 09:27 AM 3/14/2006 -0300, JoaoBR wrote: | On Tuesday 14 March 2006 08:49, ray@redshift.com wrote: | > At 12:38 PM 3/14/2006 +0100, Alexander Konovalenko wrote: | > | On Tuesday 14 March 2006 11:40, JoaoBR wrote: | > | > so where is your comparism? My point was that the same hardware is | > | > faster running i386 | > | > | > | I have experienced that -O3 and -ffast-math optimizations flags on AMD64 | > | might cause degrade in performance, meaning that -O2 is the fastest. When | > | you compile your ports what opt. flags do you use? Try to reinstall | > | ubench with different flags. Also code produced with gcc4.x is faster | > | then system compiler and has no degrade effect. Some time ago I was | > | interested in fast scientific computations and did some primitive | > | benchmark tests | > | (http://daemon.nanophys.kth.se/~kono/testfcpu) | > | | > | I just wonder what will happen if you run ubench (compiled for i386) on | > | AMD64, will performance overcome amd64 ubench? | > | | | and what would be the point here? | | the amd64 systems I checked are running amd64 | the i386 systems I checked are running i386 | | and entirely I mean | | > | > I'm just coming in on the tail end of the message (missed the previous | > stuff). I recently did some benchmarks between AMD64 and i386 (version 5.4) | > on the same hardware. I initially saw that the i386 ran faster also. | > However, after searching a bit further, I discovered that I had made an | > error: the i386 kernel has the SMP stuff compiled into the generic kernel | > by default, while the AMD64 (at least on 5.4) does not. It has a separate | > kernel file called SMP (as I recall), which adds the SMP line and then does | > an include for the rest of the generic kernel config file (or something to | > that effect). | > | > Anyway, if you are testing back and forth, it's easy to forget that and end | > up accidently testing an i386 with SMP against an AMD64 without SMP. | > | | obviously I checked UP kernels against UP and SMP against SMP | but anyway running SMP kernel on single processor systems should not affect | this tests | | João Perhaps it's the fact that AMD64 has to deal with larger pointers? In speaking with AMD on this subject some months ago, I believe they mentioned there was a compiler switch/flag you could use to force 32 bit pointers. I never bothered to try it and don't know the specifics of it, but perhaps it's something to check into further. Ray From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 13:41:17 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 7A44E16A43B; Tue, 14 Mar 2006 13:41:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 312ED43E8B; Tue, 14 Mar 2006 13:40:19 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2EDcnSH007148; Tue, 14 Mar 2006 08:38:49 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Tue, 14 Mar 2006 08:31:15 -0500 User-Agent: KMail/1.8.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603140831.16988.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1329/Mon Mar 13 19:22:03 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, UPPERCASE_25_50 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: njl@freebsd.org Subject: Re: acpi problems with IBM/Lenovo/ThinkCentre X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 13:41:17 -0000 On Tuesday 14 March 2006 02:34 am, Danny Braniss wrote: > this is an intel/xeon dual core, booting with a 32bit kernel: > > FreeBSD 6.1-PRERELEASE #4: Mon Mar 13 09:52:47 IST 2006 > danny@bsd:/r+d/obj/bsd/i386/r+d/6.1/src/sys/HUJI > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.01-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf44 Stepping =3D 4 > =20 > Features=3D0xbfebfbffA, C > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=3D0x641d> > AMD Features=3D0x20000000 > Hyperthreading: 2 logical CPUs > ... > acpi0: on motherboard > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB1._PRW] > (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB1._PRW] > (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB2._PRW] > (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB2._PRW] > (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB3._PRW] > (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB3._PRW] > (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB4._PRW] > (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB4._PRW] > (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USBE._PRW] > (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USBE._PRW] > (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE > ... > which probably break the usb stuff, > but with a 64kernel: > ... > ACPI-1304: *** Error: Method execution failed > [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), > AE_AML_ALIGNMENT > ACPI-0239: *** Error: Method execution failed > [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), > AE_AML_ALIGNMENT > ... =46ixing these requires a MFC of changes to ACPI-CA to not require strict alignment for amd64. The ACPI-CA in 6.x requires strict alignment for all 64-bit archs because ia64 requires it, but that has since been fixed in current, just not MFC'd apparently. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 14:11:35 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 37E8516A401; Tue, 14 Mar 2006 14:11:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC5FF43D49; Tue, 14 Mar 2006 14:11:34 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1FJAFJ-000JOd-8q; Tue, 14 Mar 2006 16:11:33 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: John Baldwin In-Reply-To: Message from John Baldwin of "Tue, 14 Mar 2006 08:31:15 EST." <200603140831.16988.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Mar 2006 16:11:33 +0200 From: Danny Braniss Message-ID: Cc: njl@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: acpi problems with IBM/Lenovo/ThinkCentre X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 14:11:35 -0000 > On Tuesday 14 March 2006 02:34 am, Danny Braniss wrote: > > this is an intel/xeon dual core, booting with a 32bit kernel: > > > > FreeBSD 6.1-PRERELEASE #4: Mon Mar 13 09:52:47 IST 2006 > > danny@bsd:/r+d/obj/bsd/i386/r+d/6.1/src/sys/HUJI > > ACPI APIC Table: > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.01-MHz 686-class CPU) > > Origin =3D "GenuineIntel" Id =3D 0xf44 Stepping =3D 4 > > = > > Features=3D0xbfebfbff >A, C > > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=3D0x641d> > > AMD Features=3D0x20000000 > > Hyperthreading: 2 logical CPUs > > ... > > acpi0: on motherboard > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB1._= PRW] > > (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB1._= PRW] > > (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB2._= PRW] > > (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB2._= PRW] > > (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB3._= PRW] > > (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB3._= PRW] > > (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB4._= PRW] > > (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB4._= PRW] > > (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USBE._= PRW] > > (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USBE._= PRW] > > (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE > > ... > > which probably break the usb stuff, > > but with a 64kernel: > > ... > > ACPI-1304: *** Error: Method execution failed > > [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), > > AE_AML_ALIGNMENT > > ACPI-0239: *** Error: Method execution failed > > [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), > > AE_AML_ALIGNMENT > > ... > = > Fixing these requires a MFC of changes to ACPI-CA to not require strict= > alignment for amd64. The ACPI-CA in 6.x requires strict alignment for > all 64-bit archs because ia64 requires it, but that has since been fixe= d > in current, just not MFC'd apparently. assuming that there will be more amd64 than ia64, can the = ACPI_MISALIGNED_TRANSFERS be defined by default, and only undefed for ia64? danny From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 14:36:16 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 1272816A41F for ; Tue, 14 Mar 2006 14:36:16 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 997F743D49 for ; Tue, 14 Mar 2006 14:36:15 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Tue, 14 Mar 2006 09:36:14 -0500 id 00056410.4416D4DE.0000AD22 Date: Tue, 14 Mar 2006 09:36:14 -0500 From: Bill Moran To: freebsd-amd64@freebsd.org Message-Id: <20060314093614.e5247e95.wmoran@collaborativefusion.com> In-Reply-To: <200603131532.53869.jhb@freebsd.org> References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> <200603131406.36636.jhb@freebsd.org> <20060313150423.2b475fd4.wmoran@collaborativefusion.com> <200603131532.53869.jhb@freebsd.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 14:36:16 -0000 On Mon, 13 Mar 2006 15:32:51 -0500 John Baldwin wrote: > On Monday 13 March 2006 15:04, Bill Moran wrote: > > On Mon, 13 Mar 2006 14:06:34 -0500 > > John Baldwin wrote: > > > > [...] > > > > I can't argue that the boot messages don't seem to show anything to > > > > indicate that a second logical CPU was found. > > > > > > Grab the dmesg from /var/run/dmesg.boot rather than /var/log/messages > > > please. > > > > Copyright (c) 1992-2005 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 6.0-RELEASE-p5 #1: Fri Mar 10 16:57:56 EST 2006 > > root@:/usr/obj/usr/src/sys/DB64 > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) > > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > Features=0xbfebfbff > > Features2=0x641d> > > AMD Features=0x20000800 > > Hyperthreading: 2 logical CPUs > > real memory = 2147221504 (2047 MB) > > avail memory = 2066378752 (1970 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > This is a dmesg from an SMP kernel this time. :) > > Can you provide the output from 'sysctl machdep'? machdep.adjkerntz: 18000 machdep.disable_rtc_set: 0 machdep.wall_cmos_clock: 1 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1038016 machdep.disable_mtrrs: 0 machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 2 machdep.panic_on_nmi: 1 machdep.tsc_freq: 2992705365 machdep.i8254_freq: 1193182 machdep.conspeed: 9600 machdep.gdbspeed: 9600 machdep.conrclk: 1843200 machdep.enable_panic_key: 0 machdep.hlt_logical_cpus: 0 machdep.logical_cpus_mask: 2 machdep.hyperthreading_allowed: 0 -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 15:35:40 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 8282D16A400; Tue, 14 Mar 2006 15:35:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFCCB43D45; Tue, 14 Mar 2006 15:35:39 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2EFZUHe007829; Tue, 14 Mar 2006 10:35:30 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Danny Braniss Date: Tue, 14 Mar 2006 10:34:36 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603141034.39801.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1329/Mon Mar 13 19:22:03 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, UPPERCASE_25_50 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: njl@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: acpi problems with IBM/Lenovo/ThinkCentre X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 15:35:40 -0000 On Tuesday 14 March 2006 09:11, Danny Braniss wrote: > > On Tuesday 14 March 2006 02:34 am, Danny Braniss wrote: > > > this is an intel/xeon dual core, booting with a 32bit kernel: > > > > > > FreeBSD 6.1-PRERELEASE #4: Mon Mar 13 09:52:47 IST 2006 > > > danny@bsd:/r+d/obj/bsd/i386/r+d/6.1/src/sys/HUJI > > > ACPI APIC Table: > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.01-MHz 686-class CPU) > > > Origin = "GenuineIntel" Id = 0xf44 Stepping = 4 > > > > > > Features=0xbfebfbff > >A, C > > > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > Features2=0x641d> > > > AMD Features=0x20000000 > > > Hyperthreading: 2 logical CPUs > > > ... > > > acpi0: on motherboard > > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB1._PRW] > > > (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE > > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB1._PRW] > > > (Node 0xc32861c0), AE_AML_NO_RETURN_VALUE > > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB2._PRW] > > > (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE > > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB2._PRW] > > > (Node 0xc32860a0), AE_AML_NO_RETURN_VALUE > > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB3._PRW] > > > (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE > > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB3._PRW] > > > (Node 0xc3247da0), AE_AML_NO_RETURN_VALUE > > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USB4._PRW] > > > (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE > > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USB4._PRW] > > > (Node 0xc3247c80), AE_AML_NO_RETURN_VALUE > > > ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.USBE._PRW] > > > (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE > > > ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.USBE._PRW] > > > (Node 0xc3247be0), AE_AML_NO_RETURN_VALUE > > > ... > > > which probably break the usb stuff, > > > but with a 64kernel: > > > ... > > > ACPI-1304: *** Error: Method execution failed > > > [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), > > > AE_AML_ALIGNMENT > > > ACPI-0239: *** Error: Method execution failed > > > [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), > > > AE_AML_ALIGNMENT > > > ... > > > > Fixing these requires a MFC of changes to ACPI-CA to not require strict > > alignment for amd64. The ACPI-CA in 6.x requires strict alignment for > > all 64-bit archs because ia64 requires it, but that has since been fixed > > in current, just not MFC'd apparently. > > assuming that there will be more amd64 than ia64, can the > ACPI_MISALIGNED_TRANSFERS > be defined by default, and only undefed for ia64? As I mentioned, it's already fixed in current and in the vendor ACPI-CA sources. We just need to backport that change to RELENG_6. Hmm, Intel actually changed the whole flag around (changed it to a different one with an inverted sense). Probably best to just sync up ACPI-CA in RELENG_6 with ACPI-CA in head. Nate, what do you think? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 15:40:27 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 2944316A423 for ; Tue, 14 Mar 2006 15:40:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ED8943D45 for ; Tue, 14 Mar 2006 15:40:26 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k2EFeJv1007853; Tue, 14 Mar 2006 10:40:22 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Tue, 14 Mar 2006 10:41:17 -0500 User-Agent: KMail/1.9.1 References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> <200603131532.53869.jhb@freebsd.org> <20060314093614.e5247e95.wmoran@collaborativefusion.com> In-Reply-To: <20060314093614.e5247e95.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603141041.19069.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1329/Mon Mar 13 19:22:03 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 15:40:27 -0000 On Tuesday 14 March 2006 09:36, Bill Moran wrote: > On Mon, 13 Mar 2006 15:32:51 -0500 > John Baldwin wrote: > > > On Monday 13 March 2006 15:04, Bill Moran wrote: > > > On Mon, 13 Mar 2006 14:06:34 -0500 > > > John Baldwin wrote: > > > > > > [...] > > > > > I can't argue that the boot messages don't seem to show anything to > > > > > indicate that a second logical CPU was found. > > > > > > > > Grab the dmesg from /var/run/dmesg.boot rather than /var/log/messages > > > > please. > > > > > > Copyright (c) 1992-2005 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 6.0-RELEASE-p5 #1: Fri Mar 10 16:57:56 EST 2006 > > > root@:/usr/obj/usr/src/sys/DB64 > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) > > > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > > Features=0xbfebfbff > > > Features2=0x641d> > > > AMD Features=0x20000800 > > > Hyperthreading: 2 logical CPUs > > > real memory = 2147221504 (2047 MB) > > > avail memory = 2066378752 (1970 MB) > > > ACPI APIC Table: > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > cpu0 (BSP): APIC ID: 0 > > > cpu1 (AP): APIC ID: 1 > > > > This is a dmesg from an SMP kernel this time. :) > > > > Can you provide the output from 'sysctl machdep'? > > machdep.hlt_cpus: 2 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 2 > machdep.hyperthreading_allowed: 0 Ok, the mask is right (CPU 1 is marked as a hyperthread), and it's marked as disabled in hlt_cpus. I think I know what is happening. Can you update to the latest RELENG_6 and see if the issue still occurs. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 16:10:03 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 69A3216A422 for ; Tue, 14 Mar 2006 16:10:03 +0000 (UTC) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (daemon.nanophys.kth.se [130.237.35.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3847E43D4C for ; Tue, 14 Mar 2006 16:09:59 +0000 (GMT) (envelope-from kono@kth.se) Received: from omega.nanophys.kth.se (localhost [127.0.0.1]) by omega.nanophys.kth.se (8.13.4/8.13.1) with ESMTP id k2EGADaX079836; Tue, 14 Mar 2006 17:10:13 +0100 (CET) (envelope-from kono@kth.se) Received: from localhost (localhost [[UNIX: localhost]]) by omega.nanophys.kth.se (8.13.4/8.13.1/Submit) id k2EGACOh079835; Tue, 14 Mar 2006 17:10:12 +0100 (CET) (envelope-from kono@kth.se) X-Authentication-Warning: omega.nanophys.kth.se: kono set sender to kono@kth.se using -f From: Alexander Konovalenko Organization: KTH To: ray@redshift.com Date: Tue, 14 Mar 2006 17:10:12 +0100 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> In-Reply-To: <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603141710.12822.kono@kth.se> Cc: freebsd-amd64@freebsd.org 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 Reply-To: kono@kth.se List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 16:10:03 -0000 On Tuesday 14 March 2006 12:49, ray@redshift.com wrote: > > +2 cents mode on... :) what do you mean? > > I'm just coming in on the tail end of the message (missed the previous > stuff). I recently did some benchmarks between AMD64 and i386 (version 5.4) > on the same hardware. I initially saw that the i386 ran faster also. > However, after searching a bit further, I discovered that I had made an > error: the i386 kernel has the SMP stuff compiled into the generic kernel > by default, while the AMD64 (at least on 5.4) does not. It has a separate > kernel file called SMP (as I recall), which adds the SMP line and then does > an include for the rest of the generic kernel config file (or something to > that effect). > > Anyway, if you are testing back and forth, it's easy to forget that and end > up accidently testing an i386 with SMP against an AMD64 without SMP. > > Like I say, I'm coming in on the tail end of the thread, so I might be off > base, but it might be something worth double checking - just to be 100% > sure. > > :-) > > Ray I am just trying to understand, the conclusion is that all people who got i386 benchmark better than amd64 one, on the same X2 hardware, were running not SMP kernel on amd64 and never bothered them self to build and use a proper kernel for their platform? Naively I thought that problem is much serious... :-P /Alexander From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 16:26:26 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 7305F16A420 for ; Tue, 14 Mar 2006 16:26:26 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id E85F743D45 for ; Tue, 14 Mar 2006 16:26:25 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Tue, 14 Mar 2006 11:26:25 -0500 id 00056422.4416EEB1.0000B04D Date: Tue, 14 Mar 2006 11:26:25 -0500 From: Bill Moran To: freebsd-amd64@freebsd.org Message-Id: <20060314112625.09a3ac2c.wmoran@collaborativefusion.com> In-Reply-To: <200603141710.12822.kono@kth.se> References: <200603140740.38388.joao@matik.com.br> <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> <200603141710.12822.kono@kth.se> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 14 Mar 2006 16:26:26 -0000 On Tue, 14 Mar 2006 17:10:12 +0100 Alexander Konovalenko wrote: > > I am just trying to understand, the conclusion is that all people who got i386 > benchmark better than amd64 one, on the same X2 hardware, were running not > SMP kernel on amd64 and never bothered them self to build and use a proper > kernel for their platform? Naively I thought that problem is much > serious... :-P We've been doing some tests here (on Dell Poweredge 2850) and haven't done extensive tweaking (have tried different -O or any other compile flags) So far, our conclusion is that running amd64 binaries on an amd64 kernel is slower than ia32 binaries on an ia32 kernel. We're comparing identical 2850 hardware, both kernels built with SMP (although there seem to be some issues related to running SMP on amd64) We've been using ubench and pgbench (since these will be PostgreSQL servers) to test. We're seeing that the 64b stuff runs just a bit slower. We're also seeing that the amd64 doesn't seem to scale up to using more than one processor, but that's an issue under investigation (see other thread on this list) These are not conclusive tests at this point, but it's more data for you. -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 17:19:10 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 8D2A316A424 for ; Tue, 14 Mar 2006 17:19:10 +0000 (UTC) (envelope-from freebsd-amd64@molecon.ru) Received: from mail.migtel.ru (mail.migtel.ru [80.240.208.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79EE743D4C for ; Tue, 14 Mar 2006 17:19:09 +0000 (GMT) (envelope-from freebsd-amd64@molecon.ru) Received: from mail.migtel.ru (unknown [80.240.208.45]) by mail.migtel.ru (Postfix) with ESMTP id A26334BF2B5 for ; Tue, 14 Mar 2006 20:19:08 +0300 (MSK) Received: from [10.20.5.22] (unknown [10.20.5.22]) by mail.migtel.ru (Postfix) with ESMTP for ; Tue, 14 Mar 2006 20:19:08 +0300 (MSK) Date: Tue, 14 Mar 2006 20:12:53 +0300 From: Oleg Rusanov X-Mailer: The Bat! (v3.65.03) Professional Organization: Molecon X-Priority: 3 (Normal) Message-ID: <668930424.20060314201253@molecon.ru> To: freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on Free.migtel.ru Subject: kernel: fff X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Rusanov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 17:19:10 -0000 Hi. This is from my messages log: Mar 14 13:43:45 amd64 kernel: WARNING pid 9855 (cpanel): ioctl sign-extension ioctl fffff Mar 14 13:43:45 amd64 kernel: fff Mar 14 13:43:45 amd64 kernel: c02 Mar 14 13:43:45 amd64 kernel: 06 Mar 14 13:43:45 amd64 kernel: 92 Mar 14 13:43:45 amd64 kernel: 1 Mar 14 13:43:45 amd64 kernel: Mar 14 13:43:45 amd64 stunnel[949]: Connection closed: 4545 bytes sent to SSL, 400 bytes sent to socket M what is this? -- Regards, Oleg mailto:freebsd-amd64@molecon.ru From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 18:21:09 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 C6ADD16A41F for ; Tue, 14 Mar 2006 18:21:08 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3836443D49 for ; Tue, 14 Mar 2006 18:21:08 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (Postfix) with ESMTP id AF24775C71; Wed, 15 Mar 2006 05:21:06 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k2EIL4aN009133; Wed, 15 Mar 2006 05:21:05 +1100 Date: Wed, 15 Mar 2006 05:21:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: JoaoBR In-Reply-To: <200603131525.06540.joao@matik.com.br> Message-ID: <20060315045807.F41988@delplex.bde.org> References: <200603131525.06540.joao@matik.com.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org 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: Tue, 14 Mar 2006 18:21:09 -0000 On Mon, 13 Mar 2006, JoaoBR wrote: > Since some time (>6.0R) I have the impression that amd64 runs slower than > i386. Now I run some tests on identical hardware and using ubench confirmes > this. Somebody has comments on this? Of course 64-bit mode is slower. Many (data) objects are twice as large, so there are more cache misses. 64-bit integer registers make relatively little difference except in code that does lots of 64-bit integer operations. Other features that are only available in 64-bit mode make relatively little difference except in even more specialized code. Bruce From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 19:12:16 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 9450E16A41F; Tue, 14 Mar 2006 19:12:16 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A43343D49; Tue, 14 Mar 2006 19:12:16 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout6-ext.prodigy.net (pimout6-int.prodigy.net [207.115.4.22]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k2EJC7bN025922; Tue, 14 Mar 2006 14:12:12 -0500 X-ORBL: [67.119.74.222] Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by pimout6-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k2EJC69Q196756; Tue, 14 Mar 2006 14:12:07 -0500 Message-ID: <44171570.8070901@root.org> Date: Tue, 14 Mar 2006 11:11:44 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Baldwin References: <200603141034.39801.jhb@freebsd.org> In-Reply-To: <200603141034.39801.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jung-uk Kim , freebsd-amd64@freebsd.org Subject: Re: acpi problems with IBM/Lenovo/ThinkCentre X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 19:12:16 -0000 John Baldwin wrote: > On Tuesday 14 March 2006 09:11, Danny Braniss wrote: >>> On Tuesday 14 March 2006 02:34 am, Danny Braniss wrote: >>>> ACPI-1304: *** Error: Method execution failed >>>> [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), >>>> AE_AML_ALIGNMENT >>>> ACPI-0239: *** Error: Method execution failed >>>> [\\_SB_.PCI0.LPC0.SIO_.COMA._ STA] (Node 0xffffff0000b8fc40), >>>> AE_AML_ALIGNMENT >>>> ... >>> Fixing these requires a MFC of changes to ACPI-CA to not require strict >>> alignment for amd64. The ACPI-CA in 6.x requires strict alignment for >>> all 64-bit archs because ia64 requires it, but that has since been fixed >>> in current, just not MFC'd apparently. >> assuming that there will be more amd64 than ia64, can the >> ACPI_MISALIGNED_TRANSFERS >> be defined by default, and only undefed for ia64? > > As I mentioned, it's already fixed in current and in the vendor ACPI-CA > sources. We just need to backport that change to RELENG_6. Hmm, Intel > actually changed the whole flag around (changed it to a different one > with an inverted sense). Probably best to just sync up ACPI-CA in > RELENG_6 with ACPI-CA in head. Nate, what do you think? Unfortunately, the ACPI-CA in -current (and the latest from the vendor) have a small memory leak so we can't MFC until that is found and fixed. -- Nate From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 20:05:45 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 049B816A422 for ; Tue, 14 Mar 2006 20:05:45 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F40D43D48 for ; Tue, 14 Mar 2006 20:05:44 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IW400LL1VTJDZE0@osl1smout1.broadpark.no> for freebsd-amd64@freebsd.org; Tue, 14 Mar 2006 21:05:43 +0100 (CET) Received: from kg-work.kg4.no ([80.202.172.162]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0IW400K1UVTJ4Q90@osl1sminn1.broadpark.no> for freebsd-amd64@freebsd.org; Tue, 14 Mar 2006 21:05:43 +0100 (CET) Date: Tue, 14 Mar 2006 21:05:42 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <200603131756.56458.joao@matik.com.br> To: freebsd-amd64@freebsd.org Message-id: <20060314210542.32228081.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <8B10B63B-7777-4B0F-B9BD-DB30918D5B24@justken.net> <20060313214857.3d0db65a.torfinn.ingolfsen@broadpark.no> <200603131756.56458.joao@matik.com.br> Subject: Re: nvnet on MSI K8NGM2 motherboard & FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 20:05:45 -0000 On Mon, 13 Mar 2006 17:56:56 -0300 JoaoBR wrote: > on older 6.0-stable it worked fine for me and since releng_6 went to > 6.1-Pre I get this timeouts but my connection really stops working > and no chance to get it back until shutdown -p and power on again, I > installed another NIC FWIW, it still works here (Gigabyte K8-NF-9 motherboard): root@kg-fil# uname -a FreeBSD kg-fil.kg4.no 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #5: Sat Mar 11 15:05:47 CET 2006 root@kg-fil.kg4.no:/usr/obj/usr/src/sys/FIL60 amd64 nve-related messages in /var/log/messages since last reboot: Mar 11 18:10:41 kg-fil kernel: nve0: device timeout (1) Mar 11 18:10:41 kg-fil kernel: nve0: link state changed to DOWN Mar 11 18:10:42 kg-fil kernel: nve0: link state changed to UP Mar 11 23:45:25 kg-fil kernel: nve0: device timeout (1) Mar 11 23:45:25 kg-fil kernel: nve0: link state changed to DOWN Mar 11 23:45:27 kg-fil kernel: nve0: link state changed to UP Mar 12 17:22:52 kg-fil kernel: nve0: device timeout (1) Mar 12 17:22:52 kg-fil kernel: nve0: link state changed to DOWN Mar 12 17:22:53 kg-fil kernel: nve0: link state changed to UP Mar 13 21:46:58 kg-fil kernel: nve0: device timeout (1) Mar 13 21:46:58 kg-fil kernel: nve0: link state changed to DOWN Mar 13 21:46:59 kg-fil kernel: nve0: link state changed to UP HTH -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 20:27:16 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 96B9016A401 for ; Tue, 14 Mar 2006 20:27:16 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1450B43D46 for ; Tue, 14 Mar 2006 20:27:15 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Tue, 14 Mar 2006 15:27:15 -0500 id 00056410.44172723.0000B6B4 Date: Tue, 14 Mar 2006 15:27:15 -0500 From: Bill Moran To: freebsd-amd64@freebsd.org Message-Id: <20060314152715.a22b31fa.wmoran@collaborativefusion.com> In-Reply-To: <200603141041.19069.jhb@freebsd.org> References: <20060313085431.0eb059d9.wmoran@collaborativefusion.com> <200603131532.53869.jhb@freebsd.org> <20060314093614.e5247e95.wmoran@collaborativefusion.com> <200603141041.19069.jhb@freebsd.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 20:27:16 -0000 On Tue, 14 Mar 2006 10:41:17 -0500 John Baldwin wrote: [snip] > > > This is a dmesg from an SMP kernel this time. :) > > > > > > Can you provide the output from 'sysctl machdep'? > > > > machdep.hlt_cpus: 2 > > machdep.hlt_logical_cpus: 0 > > machdep.logical_cpus_mask: 2 > > machdep.hyperthreading_allowed: 0 > > Ok, the mask is right (CPU 1 is marked as a hyperthread), and > it's marked as disabled in hlt_cpus. I think I know what is > happening. Can you update to the latest RELENG_6 and see if the > issue still occurs. Just finished. The newly built kernel seems to be acting the same as the 6.0-RELEASE kernel was. (i.e. the problem is still there) Are there any specific tests you'd like me to perform, or any other information you'd like me to gather? -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 21:49:12 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 020D816A400 for ; Tue, 14 Mar 2006 21:49:12 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79F0743D46 for ; Tue, 14 Mar 2006 21:49:11 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Tue, 14 Mar 2006 16:49:10 -0500 id 00056422.44173A56.0000B948 Date: Tue, 14 Mar 2006 16:49:10 -0500 From: Bill Moran To: freebsd-amd64@freebsd.org Message-Id: <20060314164910.735a7a9d.wmoran@collaborativefusion.com> In-Reply-To: <20060313204147.GA99753@xor.obsecurity.org> References: <20060313094806.26d70c99.wmoran@collaborativefusion.com> <20060313204147.GA99753@xor.obsecurity.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Incorrect memory probing? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 21:49:12 -0000 On Mon, 13 Mar 2006 15:41:47 -0500 Kris Kennaway wrote: > On Mon, Mar 13, 2006 at 09:48:06AM -0500, Bill Moran wrote: > > > > Complete dmesg is attached, but notice the memory probing: > > Mar 10 14:56:40 kernel: real memory = 5100273664 (4864 MB) > > Mar 10 14:56:40 kernel: avail memory = 4124049408 (3933 MB) > > The machine in question (a Dell Poweredge 2850) has 4G of RAM > > installed. It looks to me as if the "avail memory" number is > > correct (after booting, other systems tools seem to show the > > correct amount) > > > > Is the "real memory" number expected? If so, can someone explain > > why it appears to see almost a G more RAM than is actually in the > > machine? > > This is a FAQ, please consult the archives. http://www.freebsd.org/cgi/query-pr.cgi?pr=94454 -- Bill Moran Collaborative Fusion Inc. From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 22:15:20 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 47A1116A422 for ; Tue, 14 Mar 2006 22:15:20 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE53643D46 for ; Tue, 14 Mar 2006 22:15:17 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2EMEspq022560; Tue, 14 Mar 2006 19:14:54 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-amd64@freebsd.org Date: Tue, 14 Mar 2006 19:14:54 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603141710.12822.kono@kth.se> <20060314112625.09a3ac2c.wmoran@collaborativefusion.com> In-Reply-To: <20060314112625.09a3ac2c.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603141914.54442.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: 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: Tue, 14 Mar 2006 22:15:20 -0000 On Tuesday 14 March 2006 13:26, Bill Moran wrote: > We've been doing some tests here (on Dell Poweredge 2850) and haven't > done extensive tweaking (have tried different -O or any other compile > flags) > that is good I think because even if it could give certain benefit in certa= in=20 cases the base system should run as is. Special configs can be necessary fo= r=20 special application but should not be necessary to get a standard setup=20 suitable for what it was designed > So far, our conclusion is that running amd64 binaries on an amd64 > kernel is slower than ia32 binaries on an ia32 kernel. We're > comparing identical 2850 hardware, both kernels built with SMP > (although there seem to be some issues related to running SMP on > amd64) > I can confirm this too SMP amd64s are having constant crashes when running >2GB and <4GB of RAM. In order not getting anything wrong I am talking about X2-SMP mono-chip-MBs this is not happening on dual-chip-MB with two separate processors. I run the same hardware as UP-amd64 and it never crashes Since this crashes are more frequent with IPI_PREEMPTION I have now some=20 servers under test running without PREEMPTION at all and appearently the=20 crashes are gone Overall the amd64-SMP kernels running on X2 processors are extermly sensiti= ve=20 to non polling NICs and are crashing often. The overall performance also is= =20 bad.=20 Soon I change this cards into polling ones, seems XL is best, I do not have= =20 crashes anymore.=20 =46unny that single 64bit AMDs are running fine with non polling NICs even = when=20 running a SMP enabled kernel. Soon I put back the X2 ... boom. > We've been using ubench and pgbench (since these will be PostgreSQL > servers) to test. We're seeing that the 64b stuff runs just a bit > slower. We're also seeing that the amd64 doesn't seem to scale up > to using more than one processor, but that's an issue under investigation > (see other thread on this list) this I can not confirm, I get SMP X2-amds with ULE and 4BSD running on both= =20 cpus, same for dual-chip-MBs But I can not say anything about PGSQL at all My servers are cache servers in first place and I have some web and mail=20 server running amd64 and the cpu scheduling seems to work well. Overall I=20 have the impression that the ULE scheduler is giving better performance on = a=20 machine with more than 2MB/s going through Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 23:20:41 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 9B27716A400 for ; Tue, 14 Mar 2006 23:20:41 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C320043D45 for ; Tue, 14 Mar 2006 23:20:40 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by nproxy.gmail.com with SMTP id x4so1198040nfb for ; Tue, 14 Mar 2006 15:20:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ODi1apVVNk7t/9F052LJ6C5jKt1aa18/NNuEB4as/Z2NePF2iSnPntbByvnKEEjgBzksG3x+6TwFwCCBSpK4taW/q/AhTtvome8ardkAyHbU9YlBdTVpmajrNyyCpZuLGRFZYvjq6p4MP8AEnE/40SoKyEproHBfQtgLxtC7mHU= Received: by 10.49.20.15 with SMTP id x15mr1625511nfi; Tue, 14 Mar 2006 15:20:35 -0800 (PST) Received: by 10.48.220.1 with HTTP; Tue, 14 Mar 2006 15:20:35 -0800 (PST) Message-ID: <346a80220603141520i2ac1a4br66cbfb213453dcd6@mail.gmail.com> Date: Tue, 14 Mar 2006 18:20:35 -0500 From: "Coleman Kane" To: JoaoBR In-Reply-To: <200603140740.38388.joao@matik.com.br> MIME-Version: 1.0 References: <20060313221836.5491916A420@hub.freebsd.org> <200603141106.13693.kono@kth.se> <200603140740.38388.joao@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kono@kth.se, freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@cokane.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 23:20:41 -0000 On 3/14/06, JoaoBR wrote: > > On Tuesday 14 March 2006 07:06, Alexander Konovalenko wrote: > > > Hi > > > Since some time (>6.0R) I have the impression that amd64 runs slower > than > > > i386. Now I run some tests on identical hardware and using ubench > > > confirmes this. Somebody has comments on this? > > > > I have Dual core AMD64 4400+ and FreeBSD RELENG_5. I don't have FreeBSD > > i386 installed but you can just compare benchmarks. > > > > ubench uses all CPU/cores by default, when one ubench is running, top > > shows: > > > > so where is your comparism? My point was that the same hardware is faster > running i386 > > I experience this also on X2 machines but do not have two machines to > compare > I have a X2-4400-SMP running amd64 and a X2-4200-SMP running i386 and it > gives > me the same numbers running ubench > > > > Jo=E3o > > > > > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU > > COMMAND 11528 XXXX 111 0 3572K 880K RUN 1 0:12 93.64% > > 42.29% ubench 11529 XXXX 111 0 3572K 880K CPU0 1 0:11 > > 97.21% 41.16% ubench 11526 XXXX -8 0 3572K 880K piperd 0 > > 0:17 41.76% 31.98% ubench > > > > > > one ubench executed (with no -s flag =3D use all CPU, default): > > > > Unix Benchmark Utility v.0.3 > > Copyright (C) July, 1999 PhysTech, Inc. > > Author: Sergei Viznyuk > > http://www.phystech.com/download/ubench.html > > FreeBSD 5.5-PRERELEASE FreeBSD 5.5-PRERELEASE #12: Sun Mar 5 17:34:07 > CET > > 2006 XXXX@XXXX:/usr/obj/usr/src/sys/DAEMON64SMP amd64 > > Ubench CPU: 238149 > > Ubench MEM: 255459 > > -------------------- > > Ubench AVG: 246804 > > > > > > two ubench executed with -s flag (use single CPU only): > > > > Ubench Single CPU: 120184 (0.40s) > > Ubench Single MEM: 126787 (0.39s) > > ----------------------------------- > > Ubench Single AVG: 123485 > > > > Ubench Single CPU: 121000 (0.41s) > > Ubench Single MEM: 128762 (0.40s) > > ----------------------------------- > > Ubench Single AVG: 124881 > > > > > > one ubench executed with -s flag (use single CPU only): > > > > Ubench Single CPU: 123251 (0.40s) > > Ubench Single MEM: 161494 (0.40s) > > ----------------------------------- > > Ubench Single AVG: 142372 > > > > > > /Alexander Konovalenko > > > > +46-8-5537-8142 (office) > > +46-7-3752-2116 > > http://daemon.nanophys.kth.se/~kono > > > > Royal Institute of Technology (KTH) > > Nanostructure Physics Department, Albanova > > Roslagstullsbacken 21 > > 10691 Stockholm > > Sweden > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > I think that the nature of the ubench benchmark should be investigated to reveal the reasons behind your dismay. It seems to me that your assumption that 64-bit should be faster than 32-bit in all cases is wrong. The nature of the processor design, the OS implementation, and how ubench does its measurement needs to be addressed. First of all, when comparing a 64-bit amd64 to a 32-bit IA-32 system it is important to know that this *does not* in fact mean that if you tested a loop of: long x, y, z; x =3D 1; y =3D 1; z =3D x + y; That the 64-bit machine would do 2X that above calculation. In fact, on the 64-bit machine, the memory taken up by the x, y, z would be double that on the i386, the add/load instruction would also double in size, and as far as execution goes, the time *should* be about the same for both units. This is all looking like 64-bit would, by its nature, have a slower average than your 32-bit system. In addition, amd64 64-bit mode doubles your register set, increasing the amount of memory that needs to be moved around on a context switch, and everything is pointing towards.....probably slower. The benefit to a 64-bit architecture is the wider word length that opens up your options. If I want to compute a 64-bit calculation on my 64-bit box, I no longer nee= d to fumble around with EAX:EDX registere concatentations, etc... Also, when taking into account things like "BigInteger" code (that builds unlimited size integers by creating datastrings), that type of code should be bigger as well. Anyhow the Ubench pkg-descr says that it spawns a bunch of processes to do "senseless mathematical integer and floating-point calculations". The same is stated for the memory operations that it executes. In fact, the CPU bench part of it uses doubles and unsigned int types to do its work. Guess what?: sizeof(unsigned int) =3D=3D sizeof(unsigned int) on amd64 vs. i386 sizeof(double) =3D=3D sizeof(double) on amd64 vs. i386 Being 64-bit does not make the system be able to necessarily do two more unsigned int operations than it would in i386 mode. That's just not how its designed. So.... I still fail to see your point with this thread. Its not faster, because the way that ubench wants to do stuff is not expected to be faster. In fact it is slower, because it is doing more work, and you are seeing the results of that. -- Coleman Kane From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 02:28:02 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 43AD416A41F for ; Wed, 15 Mar 2006 02:28:02 +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 A058443D49 for ; Wed, 15 Mar 2006 02:28:01 +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 806F31A4E10; Tue, 14 Mar 2006 18:28:01 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D4A8D51A83; Tue, 14 Mar 2006 21:28:00 -0500 (EST) Date: Tue, 14 Mar 2006 21:28:00 -0500 From: Kris Kennaway To: JoaoBR Message-ID: <20060315022800.GA47353@xor.obsecurity.org> References: <200603140740.38388.joao@matik.com.br> <200603141710.12822.kono@kth.se> <20060314112625.09a3ac2c.wmoran@collaborativefusion.com> <200603141914.54442.joao@matik.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <200603141914.54442.joao@matik.com.br> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org 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 02:28:02 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 14, 2006 at 07:14:54PM -0300, JoaoBR wrote: > I can confirm this too > SMP amd64s are having constant crashes when running >2GB and <4GB of RAM. > In order not getting anything wrong I am talking about X2-SMP mono-chip-M= Bs > this is not happening on dual-chip-MB with two separate processors. > I run the same hardware as UP-amd64 and it never crashes > Since this crashes are more frequent with IPI_PREEMPTION I have now some= =20 > servers under test running without PREEMPTION at all and appearently the= =20 > crashes are gone Right, IPI_PREEMPTION is not stable (nor is it enabled by default). Why did you decide to use it? > Overall the amd64-SMP kernels running on X2 processors are extermly sensi= tive=20 > to non polling NICs and are crashing often. The overall performance also = is=20 > bad.=20 > Soon I change this cards into polling ones, seems XL is best, I do not ha= ve=20 > crashes anymore.=20 > Funny that single 64bit AMDs are running fine with non polling NICs even = when=20 > running a SMP enabled kernel. Soon I put back the X2 ... boom. Crashing with or without the use of broken kernel options? > > We've been using ubench and pgbench (since these will be PostgreSQL > > servers) to test. We're seeing that the 64b stuff runs just a bit > > slower. We're also seeing that the amd64 doesn't seem to scale up > > to using more than one processor, but that's an issue under investigati= on > > (see other thread on this list) >=20 > this I can not confirm, I get SMP X2-amds with ULE and 4BSD running on bo= th=20 > cpus, same for dual-chip-MBs > But I can not say anything about PGSQL at all > My servers are cache servers in first place and I have some web and mail= =20 > server running amd64 and the cpu scheduling seems to work well. Overall I= =20 > have the impression that the ULE scheduler is giving better performance o= n a=20 > machine with more than 2MB/s going through You need to be very careful when claiming bad performance: ULE is well-known to perform badly on many workloads. In summary, you need to rule out whether your issues are resulting from a poor choice of non-standard kernel options, or are actually bugs in FreeBSD. Kris --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEF3uwWry0BWjoQKURAo7SAJ93qYBCzo0vdKLIVgbXL2Ol3W+EAgCfRO3C Vl8qyEFpSUl/Ke+qpX5Q1nI= =WHpO -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 09:01:49 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 0E86016A401 for ; Wed, 15 Mar 2006 09:01:49 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75E7A43D46 for ; Wed, 15 Mar 2006 09:01:48 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2F91jv8051806; Wed, 15 Mar 2006 06:01:45 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Kris Kennaway Date: Wed, 15 Mar 2006 06:01:25 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> In-Reply-To: <20060315022800.GA47353@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603150601.26135.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org 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 09:01:49 -0000 On Tuesday 14 March 2006 23:28, Kris Kennaway wrote: > On Tue, Mar 14, 2006 at 07:14:54PM -0300, JoaoBR wrote: > > I can confirm this too > > SMP amd64s are having constant crashes when running >2GB and <4GB of RA= M. > > In order not getting anything wrong I am talking about X2-SMP > > mono-chip-MBs this is not happening on dual-chip-MB with two separate > > processors. I run the same hardware as UP-amd64 and it never crashes > > Since this crashes are more frequent with IPI_PREEMPTION I have now some > > servers under test running without PREEMPTION at all and appearently the > > crashes are gone > > Right, IPI_PREEMPTION is not stable (nor is it enabled by default). > Why did you decide to use it? > for the obvious ... the never-ending-search for better performance BTW this option is very bad documented and no hint in NOTES that it may not= =20 work > > Overall the amd64-SMP kernels running on X2 processors are extermly > > sensitive to non polling NICs and are crashing often. The overall > > performance also is bad. > > Soon I change this cards into polling ones, seems XL is best, I do not > > have crashes anymore. > > Funny that single 64bit AMDs are running fine with non polling NICs even > > when running a SMP enabled kernel. Soon I put back the X2 ... boom. > > Crashing with or without the use of broken kernel options? without, SMP kernel but POLLING enabled > > My servers are cache servers in first place and I have some web and mail > > server running amd64 and the cpu scheduling seems to work well. Overall= I > > have the impression that the ULE scheduler is giving better performance > > on a machine with more than 2MB/s going through > > You need to be very careful when claiming bad performance: ULE is > well-known to perform badly on many workloads. > well, read again I said here that ULE is giving me BETTER performance > In summary, you need to rule out whether your issues are resulting > from a poor choice of non-standard kernel options, or are actually > bugs in FreeBSD. > obvious, but we often do not know all for sure so it's good talking about=20 resuming my experience: SMP with single dual-core processors on standard MBs are sensitive (crashi= ng=20 easily or time-outs) with non polling NICs SMP with single dual-core processors are randomly crashing when >2GB and <4= GB=20 on standard MBs Both issues are not appearing at all when changing the X2 for a standard=20 athlon 64 processor, means same hardware, same OS version and kernel Both issues are also not appearing when using the dual-core running same=20 hardware, same os version but UP kernel (only cutting options SMP). I understand here that amd64 is still not dealing well with dual-cores and= =20 more than 2GB of RAM Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 09:32:12 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 AFCBA16A420 for ; Wed, 15 Mar 2006 09:32:12 +0000 (UTC) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EBD143D46 for ; Wed, 15 Mar 2006 09:32:11 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 112C9F815 for ; Wed, 15 Mar 2006 02:34:53 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id CB89FF814 for ; Wed, 15 Mar 2006 02:34:52 -0700 (MST) Date: Wed, 15 Mar 2006 02:32:09 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060315023209.55db2b1e.kgunders@teamcool.net> In-Reply-To: <200603150601.26135.joao@matik.com.br> References: <200603140740.38388.joao@matik.com.br> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> <200603150601.26135.joao@matik.com.br> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: 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 09:32:12 -0000 On Wed, 15 Mar 2006 06:01:25 -0300 JoaoBR wrote: > On Tuesday 14 March 2006 23:28, Kris Kennaway wrote: > > On Tue, Mar 14, 2006 at 07:14:54PM -0300, JoaoBR wrote: > > > I can confirm this too > > > SMP amd64s are having constant crashes when running >2GB and <4GB of RAM. > > > In order not getting anything wrong I am talking about X2-SMP > > > mono-chip-MBs this is not happening on dual-chip-MB with two separate > > > processors. I run the same hardware as UP-amd64 and it never crashes > > > Since this crashes are more frequent with IPI_PREEMPTION I have now some > > > servers under test running without PREEMPTION at all and appearently the > > > crashes are gone > > > > Right, IPI_PREEMPTION is not stable (nor is it enabled by default). > > Why did you decide to use it? > > > > for the obvious ... the never-ending-search for better performance > BTW this option is very bad documented and no hint in NOTES that it may not > work > > > > Overall the amd64-SMP kernels running on X2 processors are extermly > > > sensitive to non polling NICs and are crashing often. The overall > > > performance also is bad. > > > Soon I change this cards into polling ones, seems XL is best, I do not > > > have crashes anymore. > > > Funny that single 64bit AMDs are running fine with non polling NICs even > > > when running a SMP enabled kernel. Soon I put back the X2 ... boom. > > > > Crashing with or without the use of broken kernel options? > > without, SMP kernel but POLLING enabled > > > > My servers are cache servers in first place and I have some web and mail > > > server running amd64 and the cpu scheduling seems to work well. Overall I > > > have the impression that the ULE scheduler is giving better performance > > > on a machine with more than 2MB/s going through > > > > You need to be very careful when claiming bad performance: ULE is > > well-known to perform badly on many workloads. > > > > well, read again > I said here that ULE is giving me BETTER performance > > > In summary, you need to rule out whether your issues are resulting > > from a poor choice of non-standard kernel options, or are actually > > bugs in FreeBSD. > > > > obvious, but we often do not know all for sure so it's good talking about > > resuming my experience: > > SMP with single dual-core processors on standard MBs are sensitive (crashing > easily or time-outs) with non polling NICs > > SMP with single dual-core processors are randomly crashing when >2GB and <4GB > on standard MBs > > Both issues are not appearing at all when changing the X2 for a standard > athlon 64 processor, means same hardware, same OS version and kernel > > Both issues are also not appearing when using the dual-core running same > hardware, same os version but UP kernel (only cutting options SMP). > > I understand here that amd64 is still not dealing well with dual-cores and > more than 2GB of RAM fwiw-- I have some dual cores (Opteron 165's and Opteron180). All on Tyan K8E updated to latest BIOS rev. All have 2GB Crucial DDR400 ECC. Running FBSD-6.0- RELEASE w/o issues. Stock kernel w/SMP enabled. After testing under FBSD one of them transitioned to XP Pro (sigh...). Then saw 7K250 Nvidia4 issues under RAID1 when using supplied drivers. Updated drivers fixed that (at least last I'd heard). The other FBSD machines are using WD Raptors and gmirror. I haven't seriously stress tested these machines but did run Memtest86+ for a couple days followed by a few rounds of Ubench. Didn't keep the results but seem to recall slightly better scores under amd64 than i386. Or maybe the other way around. In any case, to the best of my recollection it was pretty close (substantial diff under ab though). Subsequent use hasn't result in much load. No issues during buildworld, etc. though, wh/is about as "stressed" as they get. Ya wanna send me a couple hundred bucks and I'll be happy to do some testing w/4 gigs of Ram...>;-P Speaking of ram-- just out of couriosity, are you setting your timings to 1T or 2T in BIOS?? -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 10:16:35 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 3C08716A422 for ; Wed, 15 Mar 2006 10:16:35 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B789E43D46 for ; Wed, 15 Mar 2006 10:16:34 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by zproxy.gmail.com with SMTP id r28so84688nza for ; Wed, 15 Mar 2006 02:16:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q+qF1k88MClxxsbASpxbAJjataEiPcq2gaRi0Vk4nsAU4GzL68wwGSRNDIm4W2SOS5mUkvutyRAfh919HN0TBi6YlXTbONLmf1YbD/gDeD61J8vuQnQteQ3HLL6+RyxrTcpc2v27SWJ74J3PbYI+8BYT+M1AVPFFo2J4Foa4dsU= Received: by 10.65.218.8 with SMTP id v8mr226151qbq; Wed, 15 Mar 2006 02:16:33 -0800 (PST) Received: by 10.65.216.18 with HTTP; Wed, 15 Mar 2006 02:16:33 -0800 (PST) Message-ID: Date: Wed, 15 Mar 2006 11:16:33 +0100 From: "Claus Guttesen" To: JoaoBR In-Reply-To: <200603150601.26135.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200603140740.38388.joao@matik.com.br> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> <200603150601.26135.joao@matik.com.br> 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 10:16:35 -0000 > SMP with single dual-core processors are randomly crashing when >2GB and = <4GB > on standard MBs > ... > I understand here that amd64 is still not dealing well with dual-cores an= d > more than 2GB of RAM I have two web-servers with 4 GB RAM, one with 4 single-core opterons, the other with 2 dual-core. I have one db-server with 8 GB RAM with 2 dual-core, all working flawlessly. I have two web-servers with 4 GB RAM and 2 single-core opterons. I had problems related to RAM becoming corrupt with the server having 8 GB, swapping 4 GB of the exact same type of RAM-modules from another server cured the server. The server that got the RAM-modules did not excibit abnormal behaviour, ran it for hours with memtest (www.memtest.org) without problems. So it very much depends on your motherboard and type of ram etc. Other than I don't recall I had any serious issues in that area except for ata-drivers not being 4 GB clean. I even have some Dell dual xeon's running amd64 and 4 GB RAM :-) regards Claus From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 11:14:39 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 D42D616A41F for ; Wed, 15 Mar 2006 11:14:39 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EEF743D48 for ; Wed, 15 Mar 2006 11:14:38 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2FBEa36057331; Wed, 15 Mar 2006 08:14:37 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: "Claus Guttesen" Date: Wed, 15 Mar 2006 08:14:16 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603150601.26135.joao@matik.com.br> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603150814.17039.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean 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 11:14:39 -0000 On Wednesday 15 March 2006 07:16, Claus Guttesen wrote: > > SMP with single dual-core processors are randomly crashing when >2GB and > > <4GB on standard MBs > > ... > > I understand here that amd64 is still not dealing well with dual-cores > > and more than 2GB of RAM > > I have two web-servers with 4 GB RAM, one with 4 single-core opterons, > the other with 2 dual-core. I have one db-server with 8 GB RAM with 2 > dual-core, all working flawlessly. I have two web-servers with 4 GB > RAM and 2 single-core opterons. > mine either the problems I have only on standard MBs with athlon64 X2 processors, as sa= id=20 before I do not have them on server boards using opterons, but I still do n= ot=20 have dual-core opterons to check this out Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 12:36:28 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 C5BB316A401 for ; Wed, 15 Mar 2006 12:36:28 +0000 (UTC) (envelope-from cstdenis@voicio.com) Received: from swordfish.dnsvelocity.com (swordfish.dnsvelocity.com [216.67.224.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 395CB43D46 for ; Wed, 15 Mar 2006 12:36:28 +0000 (GMT) (envelope-from cstdenis@voicio.com) Received: from s0106000f660223be.vc.shawcable.net ([24.83.99.55]:4179 helo=chris) by swordfish.dnsvelocity.com with esmtpa (Exim 4.52) id 1FJVEo-0005jL-UF for freebsd-amd64@freebsd.org; Wed, 15 Mar 2006 12:36:27 +0000 Message-ID: <00a401c6482d$11548dc0$6401a8c0@chris> From: "Cstdenis" To: Date: Wed, 15 Mar 2006 04:36:19 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - swordfish.dnsvelocity.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - voicio.com X-Source: X-Source-Args: X-Source-Dir: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: net/ser segfaults on amd64 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 12:36:28 -0000 Any ideas? Anyone having success with this program on this platform? Minimal ser.cfg =3D> http://pastebin.ca/45075 gdb ser /ser.core =3D> http://pastebin.ca/45076 (excert below) #0 0x00000008006c5cc3 in __error () from /usr/lib/libpthread.so.2 #1 0x00000008006b8ec6 in _pthread_mutex_trylock () from /usr/lib/libpthread.so.2 #2 0x00000008006ba3e9 in pthread_mutex_lock () from /usr/lib/libpthread.so.2 #3 0x0000000800bfec73 in reply_received () from /usr/local/lib/ser/modules/tm.so #4 0x00000000004115b1 in forward_reply () ser1# uname -mrs FreeBSD 6.0-RELEASE-p4 amd64 ser1# ser -V version: ser 0.9.3 (amd64/freebsd) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, = DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, USE_PTHREAD_MUTEX MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.197 2004/12/03 19:09:31 andrei Exp $ main.c compiled on 15:22:58 Mar 9 2006 with gcc 3.4 partial debug output from log_stderror=3Dyes 4(66703) After parse_msg... 4(66703) forward_reply: found module tm, passing reply to it 4(66703) DEBUG: t_check: msg id=3D1 global id=3D0 T = start=3D0xffffffffffffffff 4(66703) parse_headers: flags=3D17 4(66703) parse_headers: flags=3D4 4(66703) DEBUG: t_reply_matching: hash 11892 label 200433279 branch 0 4(66703) DEBUG: t_reply_matching: reply matched (T=3D0x801241cb0)! 4(66703) DEBUG: t_check: msg id=3D1 global id=3D1 T end=3D0x801241cb0 4(66703) DEBUG: reply_received: org. status uas=3D100, uac[0]=3D0 = local=3D0 is_invite=3D1) 23(66722) DBG: tcp_main_loop: dead child 4 (shutting down?) 0(66699) child process 66703 exited by a signal 11 0(66699) core was generated 0(66699) INFO: terminating due to SIGCHLD 17(66716) INFO: signal 15 received 17(66716) Memory status (pkg): 17(66716) qm_status (0x5bdf60): 17(66716) heap size=3D 1005488 17(66716) used=3D 14064, used+overhead=3D61312, free=3D944176 17(66716) max used (+overhead)=3D 61760 17(66716) dumping all alloc'ed. fragments: From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 15:05:36 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 9A02216A401 for ; Wed, 15 Mar 2006 15:05:36 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CFB243D69 for ; Wed, 15 Mar 2006 15:05:33 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 3F779B81F for ; Wed, 15 Mar 2006 10:05:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060315022800.GA47353@xor.obsecurity.org> References: <200603140740.38388.joao@matik.com.br> <200603141710.12822.kono@kth.se> <20060314112625.09a3ac2c.wmoran@collaborativefusion.com> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AABAA8B-3146-4EA0-8D23-8A2BCB24E09D@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Wed, 15 Mar 2006 10:05:31 -0500 To: FreeBSD AMD list X-Mailer: Apple Mail (2.746.3) 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 15:05:36 -0000 On Mar 14, 2006, at 9:28 PM, Kris Kennaway wrote: > > In summary, you need to rule out whether your issues are resulting > from a poor choice of non-standard kernel options, or are actually > bugs in FreeBSD. Or are hardware faults. I had no end of trouble with a certain motherboard (1 of 5 was stable), but have had zero problems with the one SunFire X4100 I have. The quality control is a big issue. From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 18:46:13 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 31C8216A400 for ; Wed, 15 Mar 2006 18:46:13 +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 4467A43D70 for ; Wed, 15 Mar 2006 18:46:08 +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 14B161A4E46; Wed, 15 Mar 2006 10:46:08 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1212A51954; Wed, 15 Mar 2006 13:46:07 -0500 (EST) Date: Wed, 15 Mar 2006 13:46:06 -0500 From: Kris Kennaway To: JoaoBR Message-ID: <20060315184606.GA85629@xor.obsecurity.org> References: <200603140740.38388.joao@matik.com.br> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> <200603150601.26135.joao@matik.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <200603150601.26135.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 18:46:13 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2006 at 06:01:25AM -0300, JoaoBR wrote: > On Tuesday 14 March 2006 23:28, Kris Kennaway wrote: > > On Tue, Mar 14, 2006 at 07:14:54PM -0300, JoaoBR wrote: > > > I can confirm this too > > > SMP amd64s are having constant crashes when running >2GB and <4GB of = RAM. > > > In order not getting anything wrong I am talking about X2-SMP > > > mono-chip-MBs this is not happening on dual-chip-MB with two separate > > > processors. I run the same hardware as UP-amd64 and it never crashes > > > Since this crashes are more frequent with IPI_PREEMPTION I have now s= ome > > > servers under test running without PREEMPTION at all and appearently = the > > > crashes are gone > > > > Right, IPI_PREEMPTION is not stable (nor is it enabled by default). > > Why did you decide to use it? > > >=20 > for the obvious ... the never-ending-search for better performance > BTW this option is very bad documented and no hint in NOTES that it may n= ot=20 > work 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. > > > Overall the amd64-SMP kernels running on X2 processors are extermly > > > sensitive to non polling NICs and are crashing often. The overall > > > performance also is bad. > > > Soon I change this cards into polling ones, seems XL is best, I do not > > > have crashes anymore. > > > Funny that single 64bit AMDs are running fine with non polling NICs e= ven > > > when running a SMP enabled kernel. Soon I put back the X2 ... boom. > > > > Crashing with or without the use of broken kernel options? >=20 > without, SMP kernel but POLLING enabled OK, please file a bug report including panic traces, etc. This is necessary for someone to analyze and (if appropriate) fix your problem. > > > My servers are cache servers in first place and I have some web and m= ail > > > server running amd64 and the cpu scheduling seems to work well. Overa= ll I > > > have the impression that the ULE scheduler is giving better performan= ce > > > on a machine with more than 2MB/s going through > > > > You need to be very careful when claiming bad performance: ULE is > > well-known to perform badly on many workloads. > > >=20 > well, read again > I said here that ULE is giving me BETTER performance And above in the quoted text you said bad performance, so who knows what settings you had then :-) Maybe you're blaming something on polling that is really the fault of ULE. > > In summary, you need to rule out whether your issues are resulting > > from a poor choice of non-standard kernel options, or are actually > > bugs in FreeBSD. > > >=20 > obvious, but we often do not know all for sure so it's good talking about= =20 >=20 > resuming my experience: >=20 > SMP with single dual-core processors on standard MBs are sensitive (cras= hing=20 > easily or time-outs) with non polling NICs >=20 > SMP with single dual-core processors are randomly crashing when >2GB and = <4GB=20 > on standard MBs >=20 > Both issues are not appearing at all when changing the X2 for a standard= =20 > athlon 64 processor, means same hardware, same OS version and kernel >=20 > Both issues are also not appearing when using the dual-core running same= =20 > hardware, same os version but UP kernel (only cutting options SMP). >=20 > I understand here that amd64 is still not dealing well with dual-cores an= d=20 > more than 2GB of RAM 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. Kris --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEGGDuWry0BWjoQKURAvQ0AKDmeIUxRQOIYrQvCPq5sWd+sjZ6xgCg3jBN ylcqmedSgCo0uzY1K2WEW4o= =Cedt -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 20:29:01 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 4CC0C16A401 for ; Wed, 15 Mar 2006 20:29:01 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E984A43D6B for ; Wed, 15 Mar 2006 20:28:58 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2FKStIn082717; Wed, 15 Mar 2006 17:28:56 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Kris Kennaway Date: Wed, 15 Mar 2006 17:28:35 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603150601.26135.joao@matik.com.br> <20060315184606.GA85629@xor.obsecurity.org> In-Reply-To: <20060315184606.GA85629@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603151728.35620.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org 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:29:01 -0000 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. > as well may exist good reason to check them out, if nobody checks this thin= gs=20 we never know about, right? preemption and ipi_preemption are good theories (seems to me) and things li= ke=20 that are worth to be tried even knowing that they are in early stage anyway I am not blaming somebody nor the OS for anything instead I tried to= =20 exchange experiences in first place. > > And above in the quoted text you said bad performance, so who knows > what settings you had then :-) Maybe you're blaming something on > polling that is really the fault of ULE. > ok but I am not that stupid to try a prototype scheduler and then blaming i= t=20 for my mess > > 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. > well, that was my first thought too but makes no sense if the same happens = on=20 several different brands, anyway I checked and tested different bios versio= ns=20 on any board because the thing is important to me, I can not migrate 500=20 servers having this problem=20 also it is clearly X2 processor related since it doesn't appear when using = a=20 normal athlon64, then you may say ACPI is to blame what could be the case o= f=20 Asus or Abit but the EPOX ACPI is very clean and appearently error free My guess here is the shared memory access when running X2-SMP=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br 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-- From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 20:54:50 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 C388F16A420 for ; Wed, 15 Mar 2006 20:54:50 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38D1943D88 for ; Wed, 15 Mar 2006 20:54:49 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2FKsl9D083781; Wed, 15 Mar 2006 17:54:47 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Kris Kennaway Date: Wed, 15 Mar 2006 17:54:27 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603151728.35620.joao@matik.com.br> <20060315203922.GA87806@xor.obsecurity.org> In-Reply-To: <20060315203922.GA87806@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603151754.27250.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org 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:54:50 -0000 On Wednesday 15 March 2006 17:39, Kris Kennaway wrote: > > 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. > whats that now? absolutly not true read the thread again and show me where I said that but to help you out: I= =20 said that I (I!) have problems with X2 processor with very specific memory= =20 amount installed on certain hardware when SMP is enabled don't turn my words around > > > > well, that was my first thought too but makes no sense if the same > > happens on several different brands, > > Why not? It is well-documented that many motherboards need BIOS > updates to work correctly with dual-core CPUs. > you are more clever than that aren't you? Or do you try to get clever with = me? means: makes no sense that the bios is broken on all MBs I tried overall you cut the important thing where I said that I did tried other bio= s=20 versions and what you say here has nothing to do with all of this because the bios=20 updates you're talking about are necessary on certain MBs in order to=20 recognize the X2 - so we are beyond this point ... Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 21:13:16 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 9581F16A425 for ; Wed, 15 Mar 2006 21:13:16 +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 7EEBC43D70 for ; Wed, 15 Mar 2006 21:13:12 +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 0A1841A4E4D; Wed, 15 Mar 2006 13:13:11 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0DE4151FEB; Wed, 15 Mar 2006 16:13:10 -0500 (EST) Date: Wed, 15 Mar 2006 16:13:07 -0500 From: Kris Kennaway To: JoaoBR Message-ID: <20060315211307.GA88339@xor.obsecurity.org> References: <200603140740.38388.joao@matik.com.br> <200603151728.35620.joao@matik.com.br> <20060315203922.GA87806@xor.obsecurity.org> <200603151754.27250.joao@matik.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <200603151754.27250.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 21:13:16 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2006 at 05:54:27PM -0300, JoaoBR wrote: > On Wednesday 15 March 2006 17:39, Kris Kennaway wrote: > > > > 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. > > >=20 > whats that now? absolutly not true >=20 > read the thread again and show me where I said that but to help you out: = I=20 > said that I (I!) have problems with X2 processor with very specific memor= y=20 > amount installed on certain hardware when SMP is enabled >=20 > don't turn my words around You said: > I can confirm this too > SMP amd64s are having constant crashes when running >2GB and <4GB of RAM. > In order not getting anything wrong I am talking about X2-SMP mono-chip-M= Bs > this is not happening on dual-chip-MB with two separate processors. > I run the same hardware as UP-amd64 and it never crashes > Since this crashes are more frequent with IPI_PREEMPTION I have now some > servers under test running without PREEMPTION at all and appearently the > crashes are gone The claim in this paragraph is that it is necessary to disable the (default) PREEMPTION option in order for FreeBSD not to crash on these systems, i.e. FreeBSD is unstable by default. But what you actually did was enable the non-default IPI_PREEMPTION option, which may cause crashes, and then instead of just turning it off again you turned off both this and PREEMPTION. Anyway, maybe there is just a language issue and you didn't manage to express yourself well. > > > well, that was my first thought too but makes no sense if the same > > > happens on several different brands, > > > > Why not? It is well-documented that many motherboards need BIOS > > updates to work correctly with dual-core CPUs. > > >=20 > you are more clever than that aren't you? Or do you try to get clever wit= h me? >=20 > means: makes no sense that the bios is broken on all MBs I tried >=20 > overall you cut the important thing where I said that I did tried other b= ios=20 > versions >=20 > and what you say here has nothing to do with all of this because the bios= =20 > updates you're talking about are necessary on certain MBs in order to=20 > recognize the X2 - so we are beyond this point ... No, you haven't ruled it out, only that none of the versions you tried fix your issue. Note what I said earlier: other people use dual core CPUs on FreeBSD/amd64 without stability problems, so it is not a general problem with FreeBSD. Kris --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEGINhWry0BWjoQKURAqgYAKDCIMimdOuX3ZZfUSBDlqIBJjpAgQCbBnJ+ LiOKwDgfdLwziKCX2oG577M= =sqBZ -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 21:46:04 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 5288216A420 for ; Wed, 15 Mar 2006 21:46:04 +0000 (UTC) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7596843D5D for ; Wed, 15 Mar 2006 21:46:00 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id B5DF7F815 for ; Wed, 15 Mar 2006 14:45:59 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 779A3F814 for ; Wed, 15 Mar 2006 14:45:59 -0700 (MST) Date: Wed, 15 Mar 2006 14:45:58 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060315144558.118c584b.kgunders@teamcool.net> In-Reply-To: <200603151754.27250.joao@matik.com.br> References: <200603140740.38388.joao@matik.com.br> <200603151728.35620.joao@matik.com.br> <20060315203922.GA87806@xor.obsecurity.org> <200603151754.27250.joao@matik.com.br> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: 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 21:46:04 -0000 On Wed, 15 Mar 2006 17:54:27 -0300 JoaoBR wrote: > On Wednesday 15 March 2006 17:39, Kris Kennaway wrote: > > > > 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. > > > > whats that now? absolutly not true > > read the thread again and show me where I said that but to help you out: I > said that I (I!) have problems with X2 processor with very specific memory > amount installed on certain hardware when SMP is enabled > > don't turn my words around > > > > > > > well, that was my first thought too but makes no sense if the same > > > happens on several different brands, > > > > Why not? It is well-documented that many motherboards need BIOS > > updates to work correctly with dual-core CPUs. > > > > you are more clever than that aren't you? Or do you try to get clever with me? > > means: makes no sense that the bios is broken on all MBs I tried > > overall you cut the important thing where I said that I did tried other bios > versions > > and what you say here has nothing to do with all of this because the bios > updates you're talking about are necessary on certain MBs in order to > recognize the X2 - so we are beyond this point ... The systems I referenced came w/default BIOS that supported dual core cpu's out of the gate. They were also defective. Which illustrates why MB vendors have proceedures to investigate complaints and release updated BIOS where warranted. Step 1 of any such proceedures is to confirm that you're using the latest firmware (and drivers where appropriate). If you're not they pretty much stop conversation until you update and are able to report that the problem still exists. Also, you reported you were having memory related issues but I missed any reply to my query regarding memory timings in BIOS. I've seen some MB's ship w/1T and other aggressive timings enabled. I assume so that they can get out of the box perf boost for those MS gaming site reviews where stability takes a back seat to bleeding edge performance. But these more aggressive timings can also cause stability issues. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 21:57:45 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 5C5E716A434 for ; Wed, 15 Mar 2006 21:57:45 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B05243D68 for ; Wed, 15 Mar 2006 21:56:25 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 54775 invoked from network); 15 Mar 2006 21:56:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aMCHf31h6J/YRb6GEqI6QApkPu1dYoTn1r3bsQM9xFHOAOATJFx0Mu7ZJ/128+ujLbNhPEY/9lqLf4tR8V2l9PiPLl+JUVn3sBcvvt+VexEPwanaDzp4aGtL2/RAZScTgqScYH7iTF3Hec7TwEDRJxJkt2NxDXWkKIfiJ6Z8RUY= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp100.rog.mail.re2.yahoo.com with SMTP; 15 Mar 2006 21:56:11 -0000 Message-ID: <44188D9D.8010801@rogers.com> Date: Wed, 15 Mar 2006 16:56:45 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kris Kennaway References: <200603140740.38388.joao@matik.com.br> <200603151728.35620.joao@matik.com.br> <20060315203922.GA87806@xor.obsecurity.org> <200603151754.27250.joao@matik.com.br> <20060315211307.GA88339@xor.obsecurity.org> In-Reply-To: <20060315211307.GA88339@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org 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 21:57:45 -0000 Kris Kennaway wrote: > No, you haven't ruled it out, only that none of the versions you tried > fix your issue. Note what I said earlier: other people use dual core > CPUs on FreeBSD/amd64 without stability problems, so it is not a > general problem with FreeBSD. > Indeed, they are. The system below is working just fine for me, and the performance is quite good too (for a pentium4). It's a Supermicro PDSMi board: 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Tue Mar 7 12:24:51 EST 2006 amd64 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf62 Stepping = 2 Features=0xbfebfbff Features2=0xe43d,> AMD Features=0x20100800 Hyperthreading: 2 logical CPUs real memory = 535691264 (510 MB) avail memory = 510017536 (486 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 21:57:48 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 A087D16A423 for ; Wed, 15 Mar 2006 21:57:48 +0000 (UTC) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id E47D543DA3 for ; Wed, 15 Mar 2006 21:56:41 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 857E919773; Wed, 15 Mar 2006 13:56:28 -0800 (PST) From: Peter Wemm To: freebsd-amd64@freebsd.org, cokane@cokane.org Date: Wed, 15 Mar 2006 13:56:27 -0800 User-Agent: KMail/1.8.3 References: <20060313221836.5491916A420@hub.freebsd.org> <200603140740.38388.joao@matik.com.br> <346a80220603141520i2ac1a4br66cbfb213453dcd6@mail.gmail.com> In-Reply-To: <346a80220603141520i2ac1a4br66cbfb213453dcd6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603151356.27972.peter@wemm.org> Cc: kono@kth.se Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? 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 21:57:48 -0000 On Tuesday 14 March 2006 03:20 pm, Coleman Kane wrote: > On 3/14/06, JoaoBR wrote: > > On Tuesday 14 March 2006 07:06, Alexander Konovalenko wrote: > > > > Hi > > > > Since some time (>6.0R) I have the impression that amd64 runs > > > > slower > > > > than > > > > > > i386. Now I run some tests on identical hardware and using > > > > ubench confirmes this. Somebody has comments on this? > > > > > > I have Dual core AMD64 4400+ and FreeBSD RELENG_5. I don't have > > > FreeBSD i386 installed but you can just compare benchmarks. > > > > > > ubench uses all CPU/cores by default, when one ubench is running, > > > top shows: > > > > so where is your comparism? My point was that the same hardware is > > faster running i386 > > > > I experience this also on X2 machines but do not have two machines > > to compare > > I have a X2-4400-SMP running amd64 and a X2-4200-SMP running i386 > > and it gives > > me the same numbers running ubench > > > > > > > > Jo=E3o > > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU =20 > > > CPU COMMAND 11528 XXXX 111 0 3572K 880K RUN 1 =20 > > > 0:12 93.64% 42.29% ubench 11529 XXXX 111 0 3572K 880K > > > CPU0 1 0:11 97.21% 41.16% ubench 11526 XXXX -8 0=20 > > > 3572K 880K piperd 0 0:17 41.76% 31.98% ubench > > > > > > > > > one ubench executed (with no -s flag =3D use all CPU, default): > > > > > > Unix Benchmark Utility v.0.3 > > > Copyright (C) July, 1999 PhysTech, Inc. > > > Author: Sergei Viznyuk > > > http://www.phystech.com/download/ubench.html > > > FreeBSD 5.5-PRERELEASE FreeBSD 5.5-PRERELEASE #12: Sun Mar 5 > > > 17:34:07 > > > > CET > > > > > 2006 XXXX@XXXX:/usr/obj/usr/src/sys/DAEMON64SMP amd64 > > > Ubench CPU: 238149 > > > Ubench MEM: 255459 > > > -------------------- > > > Ubench AVG: 246804 > > > > > > > > > two ubench executed with -s flag (use single CPU only): > > > > > > Ubench Single CPU: 120184 (0.40s) > > > Ubench Single MEM: 126787 (0.39s) > > > ----------------------------------- > > > Ubench Single AVG: 123485 > > > > > > Ubench Single CPU: 121000 (0.41s) > > > Ubench Single MEM: 128762 (0.40s) > > > ----------------------------------- > > > Ubench Single AVG: 124881 > > > > > > > > > one ubench executed with -s flag (use single CPU only): > > > > > > Ubench Single CPU: 123251 (0.40s) > > > Ubench Single MEM: 161494 (0.40s) > > > ----------------------------------- > > > Ubench Single AVG: 142372 > > > > > > > > > /Alexander Konovalenko > > > > > > +46-8-5537-8142 (office) > > > +46-7-3752-2116 > > > http://daemon.nanophys.kth.se/~kono > > > > > > Royal Institute of Technology (KTH) > > > Nanostructure Physics Department, Albanova > > > Roslagstullsbacken 21 > > > 10691 Stockholm > > > Sweden > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser > > considerada segura. > > Service fornecido pelo Datacenter Matik=20 > > https://datacenter.matik.com.br > > _______________________________________________ > > freebsd-amd64@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > > To unsubscribe, send any mail to > > "freebsd-amd64-unsubscribe@freebsd.org" > > I think that the nature of the ubench benchmark should be > investigated to reveal the reasons behind your dismay. It seems to me > that your assumption that 64-bit should be faster than 32-bit in all > cases is wrong. The nature of the processor design, the OS > implementation, and how ubench does its measurement needs to be > addressed. > > First of all, when comparing a 64-bit amd64 to a 32-bit IA-32 system > it is important to know that this *does not* in fact mean that if you > tested a loop of: > long x, y, z; > x =3D 1; > y =3D 1; > z =3D x + y; > > That the 64-bit machine would do 2X that above calculation. In fact, > on the 64-bit machine, the memory taken up by the x, y, z would be > double that on the i386, the add/load instruction would also double > in size, and as far as execution goes, the time *should* be about the > same for both units. This is all looking like 64-bit would, by its > nature, have a slower average than your 32-bit system. > > In addition, amd64 64-bit mode doubles your register set, increasing > the amount of memory that needs to be moved around on a context > switch, and everything is pointing towards.....probably slower. I tend to agree with this. ubench is not a useful benchmark for=20 comparing 32 bit vs 64 bit systems. However, what might be interesting is to compile a 32 bit binary (and=20 statically link it) on the i386 system, and compare the runtime on the=20 64 bit kernel, using the same identical binary. That way you are=20 measuring the same math operations on both platforms. Comparing 64 bit=20 operations vs 32 bit operations is apples vs oranges. Of course, it may still be slower, but at least the results would be=20 more meaningful. Don't assume the OS is slower because the compiler=20 makes the application do twice the work. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 22:34:51 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 B252516A400 for ; Wed, 15 Mar 2006 22:34:51 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta01ps.mx.bigpond.com (omta01ps.mx.bigpond.com [144.140.82.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1216143D6E for ; Wed, 15 Mar 2006 22:34:48 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.4.160]) by omta01ps.mx.bigpond.com with ESMTP id <20060315223446.KYBK19070.omta01ps.mx.bigpond.com@areilly.bpc-users.org> for ; Wed, 15 Mar 2006 22:34:46 +0000 Received: (qmail 40999 invoked by uid 501); 15 Mar 2006 22:35:28 -0000 Date: Thu, 16 Mar 2006 09:35:28 +1100 From: Andrew Reilly To: JoaoBR Message-ID: <20060315223528.GA40682@gurney.reilly.home> References: <200603140740.38388.joao@matik.com.br> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> <200603150601.26135.joao@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603150601.26135.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 22:34:51 -0000 On Wed, Mar 15, 2006 at 06:01:25AM -0300, JoaoBR wrote: > SMP with single dual-core processors on standard MBs are sensitive (crashing > easily or time-outs) with non polling NICs Just to add another data point: My 1G RAM, AMD64-X2 box is running a mostly-SMP kernel, but with kernel.smp.disabled="1" in boot/loader.conf (because that's the only way to get the 4front-tech sound card driver to load; otherwise it is unable to allocate a necessary contiguous chunk of memory). The on-board nForce MCP9 network adaptor has never worked properly (time-outs and failure to detect carrier, rather than crashes), but I was having good success with a dc (Intel 21143) up until last weekend's cvsup/rebuild, when that stopped working too: unable to detect carrier, which I guess is an interrupt-related activity. The dc0 driver is working happily, now, with DEVICE_POLLING enabled, and configured on the interface. -- Andrew From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 23:50:30 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 5911D16A479 for ; Wed, 15 Mar 2006 23:50:30 +0000 (UTC) (envelope-from apenner@malaysia.net) Received: from 1Cust32.VR1.DEN4.broadband.uu.net (1Cust32.VR1.DEN4.broadband.uu.net [63.13.205.32]) by mx1.FreeBSD.org (Postfix) with SMTP id C16D343D45 for ; Wed, 15 Mar 2006 23:50:26 +0000 (GMT) (envelope-from apenner@malaysia.net) Received: from malaysia.net (malaysia-net.mr.outblaze.com [205.158.62.181]) by 1Cust32.VR1.DEN4.broadband.uu.net (Postfix) with ESMTP id 8EAC392224 for ; Wed, 15 Mar 2006 18:47:09 -0500 Message-ID: <110001c6488a$912afcbc$987e8635@malaysia.net> From: Yakovlev A.G. To: freebsd-amd64 Date: Wed, 15 Mar 2006 18:47:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. Subject: =?windows-1251?b?4iDu8uTl6yDv8O7k4OYsIPLl9e3u6+7j6P8gQ1JNIA==?= 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 23:50:30 -0000 =cf =d0 =c0 =ca =d2 =c8 =d7 =c5 =d1 =ca =c8 =c9 =d1 =c5 =cc =c8 =cd =c0= =d0 "CRM=2e =d3=d1=d2=c0=cd=ce=c2=cb=c5=cd=c8=c5 =c4=ce=cb=c3=ce=d1=d0=ce=d7=cd= =db=d5 =ce=d2=cd=ce=d8=c5=cd=c8=c9 =d1 =ca=cb=c8=c5=cd=d2=c0=cc=c8" 28-29 =ec=e0=f0=f2=e0 2006=a0=e3=ee=e4=e0 (=f1 10=2e00 =e4=ee 18=2e00) -=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-= =3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d-=3d= -=3d- =c0=f3=e4=e8=f2=ee=f0=e8=ff: =f0=f3=ea=ee=e2=ee=e4=e8=f2=e5=eb=e8 =ee=f2=e4= =e5=eb=ee=e2 =ef=f0=ee=e4=e0=e6, =ee=f2=e4=e5=eb=ee=e2 =ef=ee =f0=e0=e1=ee= =f2=e5 =f1 =ea=eb=e8=e5=ed=f2=e0=ec=e8, =ec=e5=ed=e5=e4=e6=e5=f0=fb =ef=ee= =ef=f0=ee=e4=e0=e6=e0=ec=2e =ce=d1=cd=ce=c2=db =d2=c5=ce=d0=c8=c8 =c8 =cf=d0=c0=ca=d2=c8=ca=c8=a0 CRM= (=f2=e5=f5=ed=ee=eb=ee=e3=e8=ff =ee=e4=ed=e8=ec =e2=e7=e3=eb=ff=e4=ee=ec= ) 1=2e =ce=f0=e3=e0=ed=e8=e7=e0=f6=e8=ff =ef=f0=ee=e4=e0=e6, =fd=f2=e0=ef=fb= =ef=f0=ee=e4=e0=e6 - =e1=eb=ee=ea-=f1=f5=e5=ec=e0 (=e0=ed=e0=eb=e8=f2=e8= =f7=e5=f1=ea=e8=e9 =fd=f2=e0=ef - =ee=f0=e3=e0=ed=e8=e7=e0=f6=e8=ff =ea=eb= =e8=e5=ed=f2=f1=ea=ee=e9 =e1=e0=e7=fb =e8 =ef=f0=ee=e4=f3=ea=f2=e0; =fd=f4= =f4=e5=ea=f2=e8=e2=ed=e0=ff =ef=f0=e5=e7=e5=ed=f2=e0=f6=e8=ff; =e7=e0=ea=eb= =fe=f7=e5=ed=e8=e5 =f1=e4=e5=eb=ea=e8; =e1=e5=f1=ea=ee=ed=e5=f7=ed=e0=ff = =f1=e4=e5=eb=ea=e0, =e2=e5=e4=e5=ed=e8=e5 =e8 =ef=e5=f0=e5=e4=e0=f7=e0 =ea= =eb=e8=e5=ed=f2=e0)=2e 2=2e =d1=f2=f0=f3=ea=f2=f3=f0=e0 =e8 =f2=e5=f5=ed=e8=ea=e0 =ef=ee=f1=f2=f0= =ee=e5=ed=e8=ff =c1=e0=e7=fb =c4=e0=ed=ed=fb=f5 (=c1=c4) (=f1=f2=f0=f3=ea= =f2=f3=f0=e0 =c1=c4, =ea=e0=f0=f2=ee=f7=ea=e0 =ea=eb=e8=e5=ed=f2=e0, =e7=e0= =ef=e8=f1=e8 =e8 =ef=ee=eb=ff, =ef=e5=f0=e5=f7=e5=ed=fc =ef=ee=eb=e5=e9; = =f2=e5=f5=ed=e8=ea=e0 =f4=ee=f0=ec=e8=f0=ee=e2=e0=ed=e8=ff =c1=c4, =e0=ea= =f2=f3=e0=eb=e8=e7=e0=f6=e8=ff =c1=c4; =e2=f5=ee=e4=ed=e0=ff =e0=ed=ea=e5= =f2=e0 =e4=eb=ff =f4=ee=f0=ec=e8=f0=ee=e2=e0=ed=e8=ff =c1=c4)=2e 3=2e =c8=f1=ef=ee=eb=fc=e7=ee=e2=e0=ed=e8=e5 =ca=eb=e8=e5=ed=f2=f1=ea=ee=e9= =e1=e0=e7=fb =e2 =f2=e5=f5=ed=ee=eb=ee=e3=e8=e8 CRM (=f2=e5=f5=ed=ee=eb=ee= =e3=e8=ff =ea=ee=ed=f2=e0=ea=f2=ee=e2 - =d2=c7 =e4=eb=ff =f1=ee=e7=e4=e0=ed= =e8=ff =c1=c4; =f6=e5=eb=e8 =ea=ee=ed=f2=e0=ea=f2=ee=e2; =f3=f7=e5=f2, =e0= =ed=e0=eb=e8=e7, =fd=f4=f4=e5=ea=f2=e8=e2=ed=ee=f1=f2=fc =ea=ee=ed=f2=e0=ea= =f2=ee=e2; =f1=f2=f0=e0=f2=e5=e3=e8=e8 =ea=ee=ec=ec=f3=ed=e8=ea=e0=f6=e8=e9= )=2e =cf=d0=df=cc=db=c5 =cf=d0=ce=c4=c0=c6=c8: =ce=d0=c3=c0=cd=c8=c7=c0=d6=c8=df= =c8 =ca=ce=cd=d2=d0=ce=cb=dc 1=2e =d0=e0=e1=ee=f2=e0 =ea=ee=ed=f2=e0=ea=f2=ed=fb=f5 =ec=e5=ed=e5=e4=e6= =e5=f0=ee=e2=2e 2=2e =cf=eb=e0=ed=e8=f0=ee=e2=e0=ed=e8=e5, =ee=f0=e3=e0=ed=e8=e7=e0=f6=e8= =ff =e8 =ea=ee=ed=f2=f0=ee=eb=fc =ef=f0=ee=e4=e0=e6=2e 3=2e =ce=f0=e3=e0=ed=e8=e7=e0=f6=e8=ff =ea=ee=ec=e0=ed=e4=ed=ee=e3=ee =e8= =f1=ef=ee=eb=fc=e7=ee=e2=e0=ed=e8=ff =c1=c4 =e2 =e4=e5=ff=f2=e5=eb=fc=ed=ee= =f1=f2=e8 =ec=e5=ed=e5=e4=e6=e5=f0=ee=e2 =ef=ee =ef=f0=ee=e4=e0=e6=e0=ec=2e= 4=2e =ce=f6=e5=ed=ea=e0 =f1=f2=ee=e8=ec=ee=f1=f2=e8 =ea=ee=ec=ec=f3=ed=e8= =ea=e0=f6=e8=e9=2e 5=2e =c8=ed=f1=f2=f0=f3=ec=e5=ed=f2=e0=f0=e8=e8 =ee=f0=e3=e0=ed=e8=e7=e0=f6= =e8=e8 =e8 =ea=ee=ed=f2=f0=ee=eb=ff =ec=e5=ed=e5=e4=e6=e5=f0=ee=e2=2e =cf=d0=c0=ca=d2=c8=ca=c0 =ca=ce=cd=d2=c0=ca=d2=ce=c2: =eb=e8=f7=ed=e0=ff = =ef=f0=e5=e7=e5=ed=f2=e0=f6=e8=ff, =f2=e5=eb=e5=f4=ee=ed=ed=fb=e9 =e8 =fd= =ef=e8=f1=f2=ee=eb=ff=f0=ed=fb=e9 =ea=ee=ed=f2=e0=ea=f2=2e =ce=ef=f2=e8=ec= =e0=eb=fc=ed=fb=e5 =f1=f6=e5=ed=e0=f0=e8=e8 =ea=ee=ed=f2=e0=ea=f2=ee=e2=2e= =cf=d0=ce=c3=d0=c0=cc=cc=db =d3=c2=c5=cb=c8=d7=c5=cd=c8=df =cb=ce=df=cb=dc= =cd=ce=d1=d2=c8 =cf=ce=d2=d0=c5=c1=c8=d2=c5=cb=c5=c9 =c8 CRM 1=2e =cc=ee=e4=e5=eb=e8 =f1=e5=f0=e2=e8=f1=ed=ee=e3=ee =f6=e8=ea=eb=e0, =e4= =ee=e2=ee=eb=fc=ed=fb=e5 =e8 =ed=e5=e4=ee=e2=ee=eb=fc=ed=fb=e5 =ea=eb=e8=e5= =ed=f2=fb=2e 2=2e =dd=ea=ee=ed=ee=ec=e8=f7=e5=f1=ea=e0=ff =fd=f4=f4=e5=ea=f2=e8=e2=ed=ee= =f1=f2=fc =f3=e2=e5=eb=e8=f7=e5=ed=e8=ff =eb=ee=ff=eb=fc=ed=ee=f1=f2=e8=2e= 3=2e =cc=e5=f2=ee=e4=e8=ea=e0 CRM, =ef=ee=f1=f2=f0=ee=e5=ed=e8=e5 =f3=f1=f2= =ee=e9=f7=e8=e2=fb=f5 =ee=f2=ed=ee=f8=e5=ed=e8=e9 =f1 =ea=eb=e8=e5=ed=f2=e0= =ec=e8=2e =dd=d2=c0=cf=db =c8=d1=cf=ce=cb=dc=c7=ce=c2=c0=cd=c8=df =d2=c5=d5=cd=ce=cb= =ce=c3=c8=c8 CRM 1=2e =ce=f1=ee=e1=e5=ed=ed=ee=f1=f2=e8 CRM-=ef=f0=ee=e3=f0=e0=ec=ec=2e 2=2e =ce=f1=ee=e1=e5=ed=ed=ee=f1=f2=e8 =e8=f1=ef=ee=eb=fc=e7=ee=e2=e0=ed=e8= =ff =e4=e8=f1=ea=ee=ed=f2=ed=fb=f5 =ef=f0=ee=e3=f0=e0=ec=ec=2e 3=2e =d0=e0=e7=eb=e8=f7=e8=ff =e4=e8=f1=ea=ee=ed=f2=ed=fb=f5 =ef=f0=ee=e3= =f0=e0=ec=ec =e8 =f2=e5=f5=ed=ee=eb=ee=e3=e8=e9 CRM=2e =cf=d0=c8=cc=c5=d0=db =d0=c5=c0=cb=dc=cd=ce=c9 =ce=d0=c3=c0=cd=c8=c7=c0=d6= =c8=c8 =cf=d0=ce=c3=d0=c0=cc=cc CRM=2e =d2=c5=d5=cd=c8=ca=c0 =cf=ce=d1=d2= =d0=ce=c5=cd=c8=df =ce=d2=cd=ce=d8=c5=cd=c8=c9 =d1 =ca=cb=c8=c5=cd=d2=c0=cc= =c8 1=2e =ca=ee=f0=ef=ee=f0=e0=f2=e8=e2=ed=e0=ff =ea=f3=eb=fc=f2=f3=f0=e0 (=ee= =f1=ed=ee=e2=fb =e0=ed=e0=eb=e8=e7=e0)=2e 2=2e =d3=f1=f2=e0=ed=ee=e2=eb=e5=ed=e8=e5 =ea=ee=ed=f2=e0=ea=f2=ee=e2 (=ea= =ee=ed=f2=e0=ea=f2=ed=fb=e5 =ef=ee=e2=ee=e4=fb)=2e 3=2e =d1=ef=ee=f1=ee=e1=fb =ef=ee=f1=f2=f0=ee=e5=ed=e8=ff =ee=f2=ed=ee=f8= =e5=ed=e8=e9=2e =ce=f0=e3=e0=ed=e8=e7=e0=f6=e8=ff =e8 =f3=ef=f0=e0=e2=eb=e5= =ed=e8=e5 =ef=ee=f1=f2=f0=ee=e5=ed=e8=e5=ec =ee=f2=ed=ee=f8=e5=ed=e8=e9=2e= =c2 =f0=e5=e7=f3=eb=fc=f2=e0=f2=e5 =f1=e5=ec=e8=ed=e0=f0=e0 =f3=f7=e0=f1=f2= =ed=e8=ea=e8: 1=2e =cf=ee=eb=f3=f7=e0=f2 =e8=ed=f1=f2=f0=f3=ec=e5=ed=f2=fb =f0=e0=e1=ee= =f2=fb =f1 =ea=eb=e8=e5=ed=f2=f1=ea=ee=e9 =e1=e0=e7=ee=e9; 2=2e =cf=ee=eb=f3=f7=e0=f2 =ef=f0=e5=e4=f1=f2=e0=e2=eb=e5=ed=e8=e5 =ee =ef= =f0=e0=e2=e8=eb=fc=ed=ee=e9 =f0=e0=e1=ee=f2=e5 =f1 =ea=eb=e8=e5=ed=f2=e0=ec= =e8 =e8 =f1=ef=ee=f1=ee=e1=e0=f5 =ef=ee=e2=fb=f8=e5=ed=e8=ff =eb=ee=ff=eb= =fc=ed=ee=f1=f2=e8 =ea=eb=e8=e5=ed=f2=ee=e2 =ea=ee=ec=ef=e0=ed=e8=e8; 3=2e =d3=e7=ed=e0=fe=f2 =ee =e3=eb=e0=e2=ed=fb=f5 =ef=f0=e8=ed=f6=e8=ef=e0= =f5 =ef=ee=f1=f2=f0=ee=e5=ed=e8=ff =fd=f4=f4=e5=ea=f2=e8=e2=ed=ee=e9 =c1=e0= =e7=fb =c4=e0=ed=ed=fb=f5 =e8 =f1=ec=ee=e3=f3=f2 =f0=e5=e0=eb=e8=e7=ee=e2= =e0=f2=fc =fd=f2=e8 =e7=ed=e0=ed=e8=ff =ed=e0 =f1=e2=ee=e8=f5 =f0=e0=e1=ee= =f7=e8=f5 =ec=e5=f1=f2=e0=f5=2e =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d= =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d= =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d =c0=e2=f2=ee=f0 =f1=e5=ec=e8=ed=e0=f0=e0: =d1=e0=ec=ee=f5=e8=ed =cc=2e=de= =2e - =ef=f0=ee=f4=e5=f1=f1=e8=ee=ed=e0=eb=fc=ed=fb=e9 =e1=e8=e7=ed=e5=f1= -=f2=f0=e5=ed=e5=f0, =ea=ee=ed=f1=f3=eb=fc=f2=e0=ed=f2, =ec=e0=f0=ea=e5=f2= =ee=eb=ee=e3, =e0=e2=f2=ee=f0 =f0=e0=e7=f0=e0=e1=ee=f2=ee=ea =e2 =ee=e1=eb= =e0=f1=f2=e8 =e0=ea=f2=e8=e2=ed=fb=f5 =ec=e5=f2=ee=e4=ee=e2 =ee=e1=f3=f7=e5= =ed=e8=ff, =ef=f0=e5=ef=ee=e4=e0=e2=e0=f2=e5=eb=fc =c0=cd=d5, =d1=e8=ed=e5= =f0=e3=e8=ff (=cc=c2=c0), =cc=c8=d0=c1=c8=d1 (=cc=c2=c0), =c2=ca=d8, =cd=ee= =f0=e2=e5=e6=f1=ea=ee-=d0=ee=f1=f1=e8=e9=f1=ea=ee=e3=ee =ee=e1=f0=e0=e7=ee= =e2=e0=f2=e5=eb=fc=ed=ee=e3=ee =ef=f0=ee=e5=ea=f2=e0 Skedsmo=2e =d0=f3=ea= =ee=e2=ee=e4=e8=f2=e5=eb=fc =e0=ed=e0=eb=e8=f2=e8=f7=e5=f1=ea=ee=e9 =e3=f0= =f3=ef=ef=fb (=ec=e0=f0=ea=e5=f2=e8=ed=e3=ee=e2=fb=e5 =e8=f1=f1=eb=e5=e4=ee= =e2=e0=ed=e8=ff), =e0=e2=f2=ee=f0 =ef=f3=e1=eb=e8=ea=e0=f6=e8=e9 =e2 =ee=e1= =eb=e0=f1=f2=e8 =f3=ef=f0=e0=e2=eb=e5=ed=e8=ff =ef=f0=ee=e5=ea=f2=e0=ec=e8= , =e1=f0=e5=ed=e4=e8=ed=e3=e0 =e8 CRM=2e =cd=e5=ea=ee=f2=ee=f0=fb=e5 =ea=ee= =f0=ef=ee=f0=e0=f2=e8=e2=ed=fb=e5 =ea=eb=e8=e5=ed=f2=fb: =d2=e8=ed=fc=ea=ee= =f4=f4, =cc=e8=eb=e0=e3=f0=ee, Le Cafe, =c5=e2=f0=ee=ee=e9=eb, =c4=e8=e0=f1= =ee=f4=f2, =c0=f0=ec=ee-=e3=f0=f3=ef, Asstra (=c1=e5=eb=e0=f0=f3=f1=fc), = =c1=e5=eb=fd=eb=e5=ea=f2=f0=ee=ed=ea=ee=ec=ef=eb=e5=ea=f2 (=c1=e5=eb=e0=f0= =f3=f1=fc), =d1=e0=f5=e0=eb=e8=ed =dd=ed=e5=f0=e4=e6=e8 (=ea=ee=ed=f1=ee=f0= =f6=e8=f3=ec Shell, Mitsui, Mitsubisi), =cc=e8=f0=f0=e0 =cb=fe=ea=f1, =c3= =e0=f0=e0=ed=f2, =d1=e5=f2=fc =f1=e0=eb=ee=ed=ee=e2 =d4=e0=e1=f0=e8=ea=e0= =c3=f0=e5=e7", =ca=e0=ec=ef=ee=ec=ee=f1, =d7=e5=f0=ea=e8=e7=ee=e2=ee, =cc= =ee=f1=ea=ee=e2=f1=ea=e8=e9 =d8=e8=ed=ed=fb=e9 =c7=e0=e2=ee=e4, =cc=e0=ea= =f1=e8=f2 (=c2=e5=f2=ee=ed=e8=f2), =c4=ff=f2=fc=ea=ee=e2=ee-=ec=e5=e1=e5=eb= =fc, =e8=e7=e4=e0=f2=e5=eb=fc=f1=f2=e2=ee MacMillan (=f0=ee=f1=f1=e8=e9=f1= =ea=e8=e9 =ee=f4=e8=f1), =cc=c8=dd=cb=dc-=ed=e5=e4=e2=e8=e6=e8=ec=ee=f1=f2= =fc, =d2=ee=f0=e3=ee=e2=fb=e9 =e4=ee=ec =cb=e0=e2=e5=f0=ed=e0, =d1=e8=e1=f3= =f0 =e8 =e4=f0=f3=e3=e8=e5 =ea=ee=ec=ef=e0=ed=e8=e8=2e =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d= =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d= =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d =d1=f2=ee=e8=ec=ee=f1=f2=fc =f3=f7=e0=f1=f2=e8=ff: 8260 =f0=f3=e1=2e (=f1= =f3=f7=e5=f2=ee=ec =cd=c4=d1) =c2 =f1=f2=ee=e8=ec=ee=f1=f2=fc =e2=ea=eb=fe=f7=e5=ed=fb =e0=e2=f2=ee=f0=f1= =ea=e8=e5 =f0=e0=e7=e4=e0=f2=ee=f7=ed=fb=e5 =ec=e0=f2=e5=f0=e8=e0=eb=fb, = =ea=ee=f4=e5-=e1=f0=e5=e9=ea=e8, =ee=e1=e5=e4=2e =d1=ea=e8=e4=ea=e8: =e1=ee=eb=e5=e5 =ee=e4=ed=ee=e3=ee =f3=f7=e0=f1=f2=ed= =e8=ea=e0 =ee=f2 =ea=ee=ec=ef=e0=ed=e8=e8 - =f1=ea=e8=e4=ea=e0 10%, =ef=ee= =f1=f2=ee=ff=ed=ed=fb=ec =ea=eb=e8=e5=ed=f2=e0=ec - 20%=2e =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d= =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d= =3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d=3d =d1=cf=d0=c0=c2=ca=c8=a0 =c8=a0 =d0=c5=c3=c8=d1=d2=d0=c0=d6=c8=df =ef=ee = =f2=e5=eb=2e: [495]980-67-00 hDEBB From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 03:33:51 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95D2F16A426 for ; Thu, 16 Mar 2006 03:33:51 +0000 (UTC) (envelope-from lists@stringsutils.com) Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A5C243D45 for ; Thu, 16 Mar 2006 03:33:51 +0000 (GMT) (envelope-from lists@stringsutils.com) Received: from zoraida.natserv.net (zoraida.natserv.net [66.114.65.147]) by zoraida.natserv.net (Postfix) with ESMTP id 67BA6B84B; Wed, 15 Mar 2006 22:33:50 -0500 (EST) References: <4411D6D8.5030101@wmptl.com> <44122C1C.6030301@samsco.org> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Francisco Reyes To: Scott Long Date: Wed, 15 Mar 2006 22:33:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Cc: amd64@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 03:33:51 -0000 Scott Long writes: > The ATA driver is still a bit flakey with more than 4GB of RAM, so make > sure that you are using either a modern SCSI controller or a RAID > controller. How about 3Ware controller? Is the same applicable to the i386? (ie ATA driver problems with more than 4GB?) From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 10:35:01 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 9260416A423 for ; Thu, 16 Mar 2006 10:35:01 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAED043D53 for ; Thu, 16 Mar 2006 10:35:00 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2GAYuQN016817; Thu, 16 Mar 2006 07:34:57 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Kris Kennaway Date: Thu, 16 Mar 2006 07:34:35 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603151754.27250.joao@matik.com.br> <20060315211307.GA88339@xor.obsecurity.org> In-Reply-To: <20060315211307.GA88339@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603160734.36006.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org 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: Thu, 16 Mar 2006 10:35:01 -0000 On Wednesday 15 March 2006 18:13, Kris Kennaway wrote: > > > Since this crashes are more frequent with IPI_PREEMPTION I have now some > > servers under test running without PREEMPTION at all and appearently the > > crashes are gone > > The claim in this paragraph is that it is necessary to disable the > (default) PREEMPTION option in order for FreeBSD not to crash on these > systems, i.e. FreeBSD is unstable by default. > well, like you said somewhere it must be our understandings of expressions,= =20 anyway in my opinion I just shared my experiences and did not expressed any= =20 "necessary" steps nor I said generally the system is unstable > > No, you haven't ruled it out, only that none of the versions you tried > fix your issue. Note what I said earlier: other people use dual core > CPUs on FreeBSD/amd64 without stability problems, so it is not a > general problem with FreeBSD. > I didn't said that either I said that I have difficulties when certain conditions are met and I said = too=20 that I do have stable systems which do NOT met this conditions You'll find a clear description of this conditions in the thread so it is n= ot=20 to understand as a general problem but a restricted problem what up to this= =20 moment I have nobody confirmed to have the same problem exactly BUT nobody confirmed NOT having the same problem under same conditions what= =20 are: =2D athlon 64 X2 processor (4200|4400|4800) =2D standard MBs as ASUS A8V[deluxe] and EPOX 9DAN3, Abit AV8 and some othe= rs =2D 4GB of RAM (means not 3 and not 3 or less ) =2D SMP enabled =2D amd64 releng_6 up to date what perhaps was not said clearly, the problem do NOT appear withamd 64=20 releng_5 and NOT with i386 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 10:41:32 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 A2E6D16A423 for ; Thu, 16 Mar 2006 10:41:32 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F71243D62 for ; Thu, 16 Mar 2006 10:41:27 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2GAfP9G017160; Thu, 16 Mar 2006 07:41:25 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-amd64@freebsd.org Date: Thu, 16 Mar 2006 07:41:05 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603151754.27250.joao@matik.com.br> <20060315144558.118c584b.kgunders@teamcool.net> In-Reply-To: <20060315144558.118c584b.kgunders@teamcool.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603160741.05493.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: 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: Thu, 16 Mar 2006 10:41:32 -0000 On Wednesday 15 March 2006 18:45, Ken Gunderson wrote: > > Also, you reported you were having memory related issues but I missed > any reply to my query regarding memory timings in BIOS. I've seen some > MB's ship w/1T and other aggressive timings enabled. I assume so > that they can get out of the box perf boost for those MS gaming > site reviews where stability takes a back seat to bleeding edge > performance. But these more aggressive timings can also cause stability > issues. I know and I remember that and did not answered because I wanted to check t= his=20 first than I forgot to answer, but the problem I have is certainly not memo= ry=20 related, it simply happened when having 4GB on the MB. Of course I do not use any kind of overclocking and the memory settings are= =20 default settings, On the MBs which support ECC I use it and otherwise I use= =20 correct dual-channel 1GB chips. The voltages detected seems to be correct = =20 and the powersuplies I used are good ones. Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 10:43:50 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 ECF7F16A52F for ; Thu, 16 Mar 2006 10:43:50 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4817B43D48 for ; Thu, 16 Mar 2006 10:43:50 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2GAhlGF017181; Thu, 16 Mar 2006 07:43:48 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Mike Jakubik Date: Thu, 16 Mar 2006 07:43:27 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <20060315211307.GA88339@xor.obsecurity.org> <44188D9D.8010801@rogers.com> In-Reply-To: <44188D9D.8010801@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603160743.27519.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean 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: Thu, 16 Mar 2006 10:43:51 -0000 On Wednesday 15 March 2006 18:56, Mike Jakubik wrote: > Kris Kennaway wrote: > > No, you haven't ruled it out, only that none of the versions you tried > > fix your issue. Note what I said earlier: other people use dual core > > CPUs on FreeBSD/amd64 without stability problems, so it is not a > > general problem with FreeBSD. > > Indeed, they are. The system below is working just fine for me, and the > performance is quite good too (for a pentium4). It's a Supermicro PDSMi > board: > > 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Tue Mar 7 12:24:51 EST > 2006 amd64 > > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.02-MHz K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf62 Stepping =3D 2 > > Features=3D0xbfebfbffA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=3D0xe43d,> AMD > Features=3D0x20100800 > Hyperthreading: 2 logical CPUs > real memory =3D 535691264 (510 MB) > avail memory =3D 510017536 (486 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > I never had any kind of problem with any system with <=3D 2Gb of Ram Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 10:47:24 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 34DC316A423 for ; Thu, 16 Mar 2006 10:47:24 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8300943D49 for ; Thu, 16 Mar 2006 10:47:23 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2GAlLiP017374; Thu, 16 Mar 2006 07:47:22 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Peter Wemm Date: Thu, 16 Mar 2006 07:46:59 -0300 User-Agent: KMail/1.9.1 References: <20060313221836.5491916A420@hub.freebsd.org> <346a80220603141520i2ac1a4br66cbfb213453dcd6@mail.gmail.com> <200603151356.27972.peter@wemm.org> In-Reply-To: <200603151356.27972.peter@wemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603160747.00051.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 10:47:24 -0000 On Wednesday 15 March 2006 18:56, Peter Wemm wrote: > I tend to agree with this. ubench is not a useful benchmark for > comparing 32 bit vs 64 bit systems. > > However, what might be interesting is to compile a 32 bit binary (and > statically link it) on the i386 system, and compare the runtime on the > 64 bit kernel, using the same identical binary. That way you are > measuring the same math operations on both platforms. Comparing 64 bit > operations vs 32 bit operations is apples vs oranges. > > Of course, it may still be slower, but at least the results would be > more meaningful. Don't assume the OS is slower because the compiler > makes the application do twice the work. good point=20 what do you think of unixbench since it does some real-life tasks? Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 11:06:22 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 487FF16A401 for ; Thu, 16 Mar 2006 11:06:22 +0000 (UTC) (envelope-from freebsd@rtl.fmailbox.com) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B934143D62 for ; Thu, 16 Mar 2006 11:06:21 +0000 (GMT) (envelope-from freebsd@rtl.fmailbox.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id C1014D4091D; Thu, 16 Mar 2006 06:06:20 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Thu, 16 Mar 2006 06:06:20 -0500 X-Sasl-enc: 2CXpgxqq4KOStpH1tIi4dzX+ah3sJz1nLntmp+lPkDBj 1142507175 Received: from [192.168.1.51] (unknown [144.138.29.114]) by frontend3.messagingengine.com (Postfix) with ESMTP id 0BE1569D; Thu, 16 Mar 2006 06:06:13 -0500 (EST) Message-ID: <441946A7.7090302@rtl.fmailbox.com> Date: Thu, 16 Mar 2006 22:06:15 +1100 From: Robert Leftwich User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <4411D6D8.5030101@wmptl.com> <44122C1C.6030301@samsco.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: amd64@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 11:06:22 -0000 > Scott Long writes: > >> The ATA driver is still a bit flakey with more than 4GB of RAM, so >> make sure that you are using either a modern SCSI controller or a RAID >> controller. > Would you mind clarifying if this applies to *only* > 4GB of ram or if it includes exactly 4GB? Also does PAE impact this flakey-ness? Are there any particular chipsets that are flaky/non-flaky? Are all FreeBSD 6.x versions affected? I guess what it boils down to is that I'm running an asus a8n-sli premium with 4GB ram and 4*160GB SATA2 drives in raid 0+1 (via the onboard nVidia (pseudo) raid) and currently using 6.1beta3 (as 6.0x does not recognise all 4GB of ram) - should I be worried that the drives are going to be flaky? Robert From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 16:52:18 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 E4D1916A422 for ; Thu, 16 Mar 2006 16:52:17 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26AF943D48 for ; Thu, 16 Mar 2006 16:52:16 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by nproxy.gmail.com with SMTP id l37so284731nfc for ; Thu, 16 Mar 2006 08:52:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=c1RCfdF+HG/SoYXUrh5Av2bzW2P90Sk1XXYcLv/4wvMClU9IZdfsAR7Oa9U+CfHduRGxum9mfYFLGSzMfO2E4Rym0PyQ4UUOpMYcZH6SE4qFVmcFlEBFHCgCEhKRSnxK6JgdGVfaIAKqa9sQpNJthhrGMPUduAErYoLN3jw9Hu0= Received: by 10.48.202.18 with SMTP id z18mr6684nff; Thu, 16 Mar 2006 08:52:14 -0800 (PST) Received: by 10.49.43.10 with HTTP; Thu, 16 Mar 2006 08:52:14 -0800 (PST) Message-ID: <346a80220603160852u591a2d47p7031409c1d93bfc0@mail.gmail.com> Date: Thu, 16 Mar 2006 11:52:14 -0500 From: "Coleman Kane" To: JoaoBR In-Reply-To: <200603160747.00051.joao@matik.com.br> MIME-Version: 1.0 References: <20060313221836.5491916A420@hub.freebsd.org> <346a80220603141520i2ac1a4br66cbfb213453dcd6@mail.gmail.com> <200603151356.27972.peter@wemm.org> <200603160747.00051.joao@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@cokane.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 16:52:18 -0000 On 3/16/06, JoaoBR wrote: > > On Wednesday 15 March 2006 18:56, Peter Wemm wrote: > > I tend to agree with this. ubench is not a useful benchmark for > > comparing 32 bit vs 64 bit systems. > > > > However, what might be interesting is to compile a 32 bit binary (and > > statically link it) on the i386 system, and compare the runtime on the > > 64 bit kernel, using the same identical binary. That way you are > > measuring the same math operations on both platforms. Comparing 64 bit > > operations vs 32 bit operations is apples vs oranges. > > > > Of course, it may still be slower, but at least the results would be > > more meaningful. Don't assume the OS is slower because the compiler > > makes the application do twice the work. > > good point > what do you think of unixbench since it does some real-life tasks? > > Jo=E3o I think that you need to determine what comparison is being made. What aspect of the CPUs are you trying to benchmark? Then, do some investigation into what benchmarks will demonstrate your performance comparison. ubench may show that my amd64 mode OS is slower on its tests, but when I run make buildworld with a common TARGET_ARCH, my amd64 setup wins out....and I know that's less scientific... but there must exist scientific benchmarks that demonstrate this. I do a lot of development, A LOT. This involves not only lots of gcc, lex, yacc, make, perl, java, etc... it generally involves lots of operations on large sets of data, building large data trees, and all hordes of other algorithmic fun. Earlier you stated: "Since some time (>6.0R) I have the impression that amd64 runs slower than i386. Now I run some tests on identical hardware and using ubench confirmes this. Somebody has comments on this?" I suppose a good place to start is "What were you expecting?", "Why were yo= u expecting that?", and "What is problematic about the results that you collected?". IMO, I don't expect many of the normal day to day operations on my amd64 machine to be significantly faster than if it were running an i386 kernel. Due to the differences between the two (amd64 and ia32) architectures, it i= s quite likely that certain operations will be faster on one than on the othe= r (and not broadly assume that amd64 will always at least be as well performing as ia32 mode). One good point is that, for instance, in ia32 mode you can fit twice as man= y possible 'values' in your cache than in amd64 mode. Also, types of long are the same length as pointers and "int"s in ia32, while only long and pointer= s are the same length in amd64. So you're amd64 vs. ia32 code in many cases can be longer and less cache-nice. These considerations need to be taken into account when analyzing performance benchmarks. I agree with Peter though, regarding the i386 static build. Try that and se= e how it fares. My expectation is that the numbers will still be slightly under for the amd64 case, but I could be wrong. From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 17:17:32 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 B8FCE16A424 for ; Thu, 16 Mar 2006 17:17:32 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2881A43D45 for ; Thu, 16 Mar 2006 17:17:32 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id EB8722A8F9 for ; Thu, 16 Mar 2006 09:17:31 -0800 (PST) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id A35C6E2B3 for ; Thu, 16 Mar 2006 09:17:31 -0800 (PST) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.4) with ESMTP id k2GHHUT3058493; Thu, 16 Mar 2006 09:17:30 -0800 (PST) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id k2GHHUxF058492; Thu, 16 Mar 2006 09:17:30 -0800 (PST) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: JoaoBR Date: Thu, 16 Mar 2006 09:17:29 -0800 User-Agent: KMail/1.8.1 References: <20060313221836.5491916A420@hub.freebsd.org> <200603151356.27972.peter@wemm.org> <200603160747.00051.joao@matik.com.br> In-Reply-To: <200603160747.00051.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603160917.30225.peter@wemm.org> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 17:17:32 -0000 On Thursday 16 March 2006 02:46 am, JoaoBR wrote: > On Wednesday 15 March 2006 18:56, Peter Wemm wrote: > > I tend to agree with this. ubench is not a useful benchmark for > > comparing 32 bit vs 64 bit systems. > > > > However, what might be interesting is to compile a 32 bit binary > > (and statically link it) on the i386 system, and compare the > > runtime on the 64 bit kernel, using the same identical binary. > > That way you are measuring the same math operations on both > > platforms. Comparing 64 bit operations vs 32 bit operations is > > apples vs oranges. > > > > Of course, it may still be slower, but at least the results would > > be more meaningful. Don't assume the OS is slower because the > > compiler makes the application do twice the work. > > good point > what do you think of unixbench since it does some real-life tasks? In general, I don't like synthetic benchmarks at all. What we do at work is put them under real workloads alongside a comparison system, and measure idle cpu trends over a day or so. A comparison where one machine has a 30% idle cpu and the other has a 40% idle cpu under the same *real* workload tells us the most. Unfortunately, we have some folks here that like to push the machines to the wall. The problem is that FreeBSD 5 and later tend to not "hit the wall gracefully" and the results of those are more often a test of how badly the kernel suffers from lock contention than how it runs under real load. Still, the max workload numbers are useful because it tells you what the worst case is. BTW: don't compare 'make buildworld' of i386 vs amd64, because amd64 not only builds things differently, but builds all the libraries twice. amd64 has 5 stages, i386 has 4. Even a 'make TARGET_ARCH=i386' isn't entirely a fair comparison because one has to build a 64 bit host compiler in one stage, the other has to build a 32 bit host compiler. gcc even turns off some optimizations when operating as a cross compiler. An actual 32 bit buildworld in a 32 bit chroot on both machines is a fair comparison of buildworld times from an OS perspective because they are building exactly the same thing. But that doesn't make it meaningful if you're interested in 'buildworld' times as a FreeBSD developer who does a buildworld umpteen times per day as part of compile testing. Anyway, one has to keep in mind whether a given test is of the operating system port, or the cpu architecture, or application performance. ubench in particular is stronly affected by 32 vs 64 bit because it generates a very different workload for itself depending on the size of the machine. There are a number of weaknesses in the amd64 port too. In particular, the math library does not yet use the generally superior SSE2 instructions. This is a real setback because the ABI uses SSE2 floating point parameter passing. The effect is that some random libm function is given a SSE2 register, which we convert to and x87 fp stack register, do the x87 operation, then convert the x87 stack register back to a SSE2 register then return the SSE2 result. This is especially unfortunate when the native SSE2 instruction that would operate on the SSE2 registers directly is faster. But, I don't know SSE2 nor x87 fpu assembler code very well, so I've done "just enough" to get things to work. It is worth reiterating that I do NOT expect the amd64 port to be better than i386 across the board. Nor even in most tests. But the difference should be minimal, except in some specific cases where the 64 bit nature really helps. eg: if you want to mmap a 3GB file. You can't do that on an i386 kernel machine. I think of the advantages of using the amd64 port in terms of functionality rather than performance. You definately have to consider functionality if you want a desktop though. flash plugins for browsers are right out, for example, unless you use the linux browser builds. Most of the time though, no flash is usually good because you get less annoying ads. :-) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 17:25:02 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 42A0C16A4C5 for ; Thu, 16 Mar 2006 17:25:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD76543D45 for ; Thu, 16 Mar 2006 17:25:01 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id AA3982A8F3 for ; Thu, 16 Mar 2006 09:25:01 -0800 (PST) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 34594E2B3 for ; Thu, 16 Mar 2006 09:25:01 -0800 (PST) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.4/8.13.4) with ESMTP id k2GHP0jT058677; Thu, 16 Mar 2006 09:25:00 -0800 (PST) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.4/8.13.1/Submit) id k2GHP0vm058676; Thu, 16 Mar 2006 09:25:00 -0800 (PST) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Thu, 16 Mar 2006 09:24:59 -0800 User-Agent: KMail/1.8.1 References: <200603140740.38388.joao@matik.com.br> <20060315144558.118c584b.kgunders@teamcool.net> <200603160741.05493.joao@matik.com.br> In-Reply-To: <200603160741.05493.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603160925.00090.peter@wemm.org> Cc: 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: Thu, 16 Mar 2006 17:25:02 -0000 On Thursday 16 March 2006 02:41 am, JoaoBR wrote: > On Wednesday 15 March 2006 18:45, Ken Gunderson wrote: > > Also, you reported you were having memory related issues but I > > missed any reply to my query regarding memory timings in BIOS. > > I've seen some MB's ship w/1T and other aggressive timings enabled. > > I assume so that they can get out of the box perf boost for those > > MS gaming site reviews where stability takes a back seat to > > bleeding edge performance. But these more aggressive timings can > > also cause stability issues. > > I know and I remember that and did not answered because I wanted to > check this first than I forgot to answer, but the problem I have is > certainly not memory related, it simply happened when having 4GB on > the MB. > > Of course I do not use any kind of overclocking and the memory > settings are default settings, On the MBs which support ECC I use it > and otherwise I use correct dual-channel 1GB chips. The voltages > detected seems to be correct and the powersuplies I used are good > ones. I have had very bad experiences using non-ECC memory on amd64 systems, especially early motherboards. As a result, I will not use a machine without ECC. The memory controller on all Athlon64 and Opteron cpus works in ECC mode, it isn't a motherboard issue (unless they forget to wire up bits 65 through 72, or forget to put the bios options in). You can use pciconf to read the memory controller settings to see if ECC is enabled from inside freebsd. But I don't remember what the magic values are though. I will go look them up if anybody particularly cares though. Unregistered ECC ram is rare, but worth it IMHO. I get mine from crucial.com (aka Micron). That's probably not a help for .br, but it might be for the other list readers. And don't forget to turn ECC mode on! :-) And yes, ECC does slightly slow down the memory system because it can no longer just write random byte values to ram. If there is a byte write, it has to read all 64 bits from the dimm, merge the new byte in, calculate ECC for the whole 64 bit chunk and write it back again. A byte write becomes a read/modify/write operation. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 18:20:34 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 B95EA16A401 for ; Thu, 16 Mar 2006 18:20:34 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 2010143D45 for ; Thu, 16 Mar 2006 18:20:34 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 34864 invoked from network); 16 Mar 2006 18:20:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=u+CLxZQwKla9u7ilvG9EHipTuQM+5fGQDdDo2wfOFzaDgBP1H1lLtXFzYgeokdrVrWj4a8vrZMIdRrq3hLcAS2BQpSpxEl41u7rbjl9ZRQ841pgXNYPEfGhUgo+KDpeMPEWIo9u0PaIhWl5rTwehR28QKf9bu/UIYYZmIFTGGJA= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 16 Mar 2006 18:20:33 -0000 Message-ID: <4419AC9B.6000804@rogers.com> Date: Thu, 16 Mar 2006 13:21:15 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: JoaoBR References: <200603140740.38388.joao@matik.com.br> <20060315211307.GA88339@xor.obsecurity.org> <44188D9D.8010801@rogers.com> <200603160743.27519.joao@matik.com.br> In-Reply-To: <200603160743.27519.joao@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 16 Mar 2006 18:20:34 -0000 JoaoBR wrote: > I never had any kind of problem with any system with <= 2Gb of Ram > Ok then, how abut this puppy? It's a dual dual-core opteron server, with 2 GB ram, and it's running perfectly. The most likely cause of your problem is hw, if you have problems with 2GB of ram on a normal kernel. --- CPU: Dual Core AMD Opteron(tm) Processor 265 (1808.34-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 Features=0x178bfbff Hyperthreading: 2 logical CPUs AMD Features=0xe0500000 real memory = 2146500608 (2047 MB) avail memory = 2099249152 (2002 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 19:11:22 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 F0C2816A484 for ; Thu, 16 Mar 2006 19:11:22 +0000 (UTC) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CC2843D78 for ; Thu, 16 Mar 2006 19:11:22 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 35A83F2611; Thu, 16 Mar 2006 11:11:20 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76254-10; Thu, 16 Mar 2006 11:11:19 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 9E029F233C; Thu, 16 Mar 2006 11:11:19 -0800 (PST) From: Sean McNeil To: Mike Jakubik In-Reply-To: <4419AC9B.6000804@rogers.com> References: <200603140740.38388.joao@matik.com.br> <20060315211307.GA88339@xor.obsecurity.org> <44188D9D.8010801@rogers.com> <200603160743.27519.joao@matik.com.br> <4419AC9B.6000804@rogers.com> Content-Type: text/plain Date: Thu, 16 Mar 2006 11:11:19 -0800 Message-Id: <1142536279.77351.5.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com 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: Thu, 16 Mar 2006 19:11:23 -0000 On Thu, 2006-03-16 at 13:21 -0500, Mike Jakubik wrote: > JoaoBR wrote: > > I never had any kind of problem with any system with <= 2Gb of Ram > > > > Ok then, how abut this puppy? It's a dual dual-core opteron server, with > 2 GB ram, and it's running perfectly. The most likely cause of your > problem is hw, if you have problems with 2GB of ram on a normal kernel. > > --- > CPU: Dual Core AMD Opteron(tm) Processor 265 (1808.34-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > > Features=0x178bfbff > Hyperthreading: 2 logical CPUs > AMD Features=0xe0500000 > real memory = 2146500608 (2047 MB) > avail memory = 2099249152 (2002 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 This is not on his list either. I have an Athlon 64 X2 3800 with 2GB of RAM that works perfectly, but it doesn't fall into his failure category. Wonder if there is some sort of memory pairing issue. To get >2GB and <4GB I'd think you have to have 2 1GB sticks and 2 512MB sticks or something like that. Anytime I've had issues, someone has told me it is my memory - and they were right. Running SMP vs. UP vs. amd64 vs. x86 all use memory differently. From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 19:43:44 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 A938716A401 for ; Thu, 16 Mar 2006 19:43:44 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31FE943D53 for ; Thu, 16 Mar 2006 19:43:44 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (Postfix) with ESMTP id 6FE3726DEE3; Fri, 17 Mar 2006 06:43:42 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k2GJhcDf016592; Fri, 17 Mar 2006 06:43:39 +1100 Date: Fri, 17 Mar 2006 06:43:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: cokane@cokane.org In-Reply-To: <346a80220603160852u591a2d47p7031409c1d93bfc0@mail.gmail.com> Message-ID: <20060317062056.R48622@delplex.bde.org> References: <20060313221836.5491916A420@hub.freebsd.org> <346a80220603141520i2ac1a4br66cbfb213453dcd6@mail.gmail.com> <200603151356.27972.peter@wemm.org> <200603160747.00051.joao@matik.com.br> <346a80220603160852u591a2d47p7031409c1d93bfc0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 19:43:44 -0000 On Thu, 16 Mar 2006, Coleman Kane wrote: > IMO, I don't expect many of the normal day to day operations on my amd64 > machine to be significantly faster than if it were running an i386 kernel. You should expect almost of of them to be slower. > Due to the differences between the two (amd64 and ia32) architectures, it is > quite likely that certain operations will be faster on one than on the other > (and not broadly assume that amd64 will always at least be as well > performing as ia32 mode). There are considerable differences at the FreeBSD arch level but none at lower levels since the CPU is identical with itself. Everything gets converted to a micro-op and the same instruction schedulers and pipeline resources etc. apply to the micro-ops. Higher levels generate a different mixture of micro-ops, and the difference mostly favors 32-bit mode since 64-bit ops are wider. > One good point is that, for instance, in ia32 mode you can fit twice as many > possible 'values' in your cache than in amd64 mode. Also, types of long are > the same length as pointers and "int"s in ia32, while only long and pointers > are the same length in amd64. So you're amd64 vs. ia32 code in many cases > can be longer and less cache-nice. These considerations need to be taken > into account when analyzing performance benchmarks. Yes, the wider ops generally take the same time unless they access memory. Then they mostly take the same time if they hit the L1 cache, but they put a heavier load on the L1 cache and eventually cause more accesses to real memory which is _slow_. Bruce From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 20:05:42 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 9F36F16A401 for ; Thu, 16 Mar 2006 20:05:42 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC93243D64 for ; Thu, 16 Mar 2006 20:05:41 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2GK5cPJ046817; Thu, 16 Mar 2006 17:05:38 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Sean McNeil Date: Thu, 16 Mar 2006 17:05:16 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <4419AC9B.6000804@rogers.com> <1142536279.77351.5.camel@triton.mcneil.com> In-Reply-To: <1142536279.77351.5.camel@triton.mcneil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603161705.17351.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean 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: Thu, 16 Mar 2006 20:05:42 -0000 On Thursday 16 March 2006 16:11, Sean McNeil wrote: > On Thu, 2006-03-16 at 13:21 -0500, Mike Jakubik wrote: > > JoaoBR wrote: > > > I never had any kind of problem with any system with <=3D 2Gb of Ram > > > > Ok then, how abut this puppy? It's a dual dual-core opteron server, with > > 2 GB ram, and it's running perfectly. The most likely cause of your > > problem is hw, if you have problems with 2GB of ram on a normal kernel. > > > > This is not on his list either. I have an Athlon 64 X2 3800 with 2GB of > RAM that works perfectly, but it doesn't fall into his failure category. > right with 2GB no problem,=20 3GB I do not know but 4GB is when the problem appears here for me > Wonder if there is some sort of memory pairing issue. To get >2GB and > <4GB I'd think you have to have 2 1GB sticks and 2 512MB sticks or > something like that. no it isn't in my case, I use real good dual-channel 2x (2x1GB) suggested= =20 memory listed in the MB manual > > Anytime I've had issues, someone has told me it is my memory - and they > were right. Running SMP vs. UP vs. amd64 vs. x86 all use memory > differently. Indeed some standard MBs with X2 are very picky with correct dual-channel=20 memory Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 16 21:30:28 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 F26C316A500 for ; Thu, 16 Mar 2006 21:30:28 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F1A243D45 for ; Thu, 16 Mar 2006 21:30:28 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (Postfix) with ESMTP id 0239E6E198; Fri, 17 Mar 2006 08:30:27 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k2GLUOng012996; Fri, 17 Mar 2006 08:30:25 +1100 Date: Fri, 17 Mar 2006 08:30:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Peter Wemm In-Reply-To: <200603160917.30225.peter@wemm.org> Message-ID: <20060317064348.C48622@delplex.bde.org> References: <20060313221836.5491916A420@hub.freebsd.org> <200603151356.27972.peter@wemm.org> <200603160747.00051.joao@matik.com.br> <200603160917.30225.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 21:30:29 -0000 On Thu, 16 Mar 2006, Peter Wemm wrote: > There are a number of weaknesses in the amd64 port too. In particular, > the math library does not yet use the generally superior SSE2 > instructions. This is a real setback because the ABI uses SSE2 > floating point parameter passing. The effect is that some random libm > function is given a SSE2 register, which we convert to and x87 fp stack > register, do the x87 operation, then convert the x87 stack register > back to a SSE2 register then return the SSE2 result. This is > especially unfortunate when the native SSE2 instruction that would > operate on the SSE2 registers directly is faster. But, I don't know > SSE2 nor x87 fpu assembler code very well, so I've done "just enough" > to get things to work. Actually, the math library just uses SSE2 (except for long doubles, when SSE2 can't be used), and anyway SSE2 is only slightly faster than the FPU for code with scalar interfaces like the math library. The "just uses" part is due to gcc. It just uses SSE2 instructions by default on amd64. SSE2 is only slightly faster because most scalar floating point operations have the same execution latency and throughput as for the FPU. SSE2's advantage on scalar code comes mainly from having more directly accessible registers (16 xmm registers instead of 8 (or sometimes only 1 at the top of the stack directly accessible) FPU registers on amd64). This advantage is often small because the extra moves to access registers can be done in parallel with other operations. Note that this parallelism often occurs automatically due to (out of order instruction) scheduling in the CPU. Execution latency is very large (e.g., 4 cycles for each of add and mul) compared with execution throughput (e.g., 1 cycle for an add and a mul) so there are usually plenty of spare pipeline slots for executing the moves in parallel. My benchmarks in libm indicate that 64-bitness + SSE2 end up being a tiny improvment for single precision and a signifcant improvement for double and long double precision (even for long double where SSE2 cannot be used!), but this is only for versions that doesn't use the FPU for transcendental functions, and I think it is mainly from foot shooting in the 32-bit versions. The improvment in double precision is needed to be competitive with the hardware transcendental functions, and the foot shooting is from heavy use of the GET/SET macros -- these macros force things to memory and thus tend to cause pipeline stalls. Bruce From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 05:46:48 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 C0AA916A42B for ; Fri, 17 Mar 2006 05:46:48 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9650243D58 for ; Fri, 17 Mar 2006 05:46:47 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 862C94A; Thu, 16 Mar 2006 23:46:46 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id B3A8761C38; Thu, 16 Mar 2006 23:46:45 -0600 (CST) Date: Thu, 16 Mar 2006 23:46:45 -0600 From: "Matthew D. Fuller" To: Peter Wemm Message-ID: <20060317054645.GF2473@over-yonder.net> References: <200603140740.38388.joao@matik.com.br> <20060315144558.118c584b.kgunders@teamcool.net> <200603160741.05493.joao@matik.com.br> <200603160925.00090.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603160925.00090.peter@wemm.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: freebsd-amd64@freebsd.org 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: Fri, 17 Mar 2006 05:46:48 -0000 On Thu, Mar 16, 2006 at 09:24:59AM -0800 I heard the voice of Peter Wemm, and lo! it spake thus: > > As a result, I will not use a machine without ECC. The memory > controller on all Athlon64 and Opteron cpus works in ECC mode, it > isn't a motherboard issue (unless they forget to wire up bits 65 > through 72, or forget to put the bios options in). I've heard statements, though, that there ARE a non-trivial number of motherboards that [fail to] do those sort of things (it probably saves almost a deci-penny a board, after all). Me, I just stick with ECC 'cuz I like my data. I wonder, though, if anybody has run across specific makes of boards that get in the way of running ECC; would be nice to mention it on the motherboards page if so. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 05:48:39 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 2B1B616A400 for ; Fri, 17 Mar 2006 05:48:39 +0000 (UTC) (envelope-from martin@gneto.com) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3143B43D46 for ; Fri, 17 Mar 2006 05:48:37 +0000 (GMT) (envelope-from martin@gneto.com) Received: from ua-83-227-181-30.cust.bredbandsbolaget.se ([83.227.181.30] [83.227.181.30]) by mxfep01.bredband.com with ESMTP id <20060317054836.ZKQI16061.mxfep01.bredband.com@ua-83-227-181-30.cust.bredbandsbolaget.se>; Fri, 17 Mar 2006 06:48:36 +0100 Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by ua-83-227-181-30.cust.bredbandsbolaget.se (Postfix) with ESMTP id 8814967922; Fri, 17 Mar 2006 06:48:29 +0100 (CET) Message-ID: <441A4DAB.4030800@gneto.com> Date: Fri, 17 Mar 2006 06:48:27 +0100 From: Martin Nilsson User-Agent: Thunderbird 1.5 (X11/20060203) MIME-Version: 1.0 To: JoaoBR References: <200603140740.38388.joao@matik.com.br> <4419AC9B.6000804@rogers.com> <1142536279.77351.5.camel@triton.mcneil.com> <200603161705.17351.joao@matik.com.br> In-Reply-To: <200603161705.17351.joao@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 17 Mar 2006 05:48:39 -0000 JoaoBR wrote: > with 2GB no problem, > 3GB I do not know but 4GB is when the problem appears here for me > > >> Wonder if there is some sort of memory pairing issue. To get >2GB and >> <4GB I'd think you have to have 2 1GB sticks and 2 512MB sticks or >> something like that. > > no it isn't in my case, I use real good dual-channel 2x (2x1GB) suggested > memory listed in the MB manual With 4GB memory you will likely get some memory remapped above 4GB, could your problems be caused by a buggy driver that doesn't support memory over the 4GB barrier correctly? (The ata driver comes to mind) /Martin From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 10:52:10 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 34A4316A400; Fri, 17 Mar 2006 10:52:10 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F17C243D46; Fri, 17 Mar 2006 10:52:09 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from misaki64 (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with SMTP id k2HAq7GF056824; Fri, 17 Mar 2006 10:52:08 GMT (envelope-from ariff@FreeBSD.org) Date: Fri, 17 Mar 2006 18:51:42 +0800 From: Ariff Abdullah To: freebsd-amd64@FreeBSD.org, freebsd-stable@FreeBSD.org Message-Id: <20060317185142.56e5042d.ariff@FreeBSD.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__17_Mar_2006_18_51_42_+0800_Dulf/MgmnPtRCns7" Cc: Subject: acquiring duplicate lock of same type: "vnode interlock" X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 10:52:10 -0000 --Signature=_Fri__17_Mar_2006_18_51_42_+0800_Dulf/MgmnPtRCns7 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think I've read somewhere about panic during early root mount, fsck etc.. Perhaps this might be related: Full dmesg: http://people.freebsd.org/~ariff/misc/dmesg.boot.amd64 [....] acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ kern/vfs_vnops.c:791 2nd vnode interlock @ kern/vfs_subr.c:2018 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x4da _mtx_lock_flags() at _mtx_lock_flags+0x4a vrefcnt() at vrefcnt+0x31 null_checkvp() at null_checkvp+0x65 null_lock() at null_lock+0x5b VOP_LOCK_APV() at VOP_LOCK_APV+0x81 vn_lock() at vn_lock+0x6b nullfs_root() at nullfs_root+0x4c vfs_donmount() at vfs_donmount+0x1096 nmount() at nmount+0x82 syscall() at syscall+0x21b Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x800679e8c, rsp =3D 0x7fffffffe558, rbp =3D 0x7fffffffee40 --- -- Ariff Abdullah FreeBSD --Signature=_Fri__17_Mar_2006_18_51_42_+0800_Dulf/MgmnPtRCns7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEGpTPlr+deMUwTNoRAiFkAJ4hjYBB1VGcmIAfPWEEh7OKDh7oKwCfXfBz xPwFzpBhFU9lSfd+We/WhxM= =AaHR -----END PGP SIGNATURE----- --Signature=_Fri__17_Mar_2006_18_51_42_+0800_Dulf/MgmnPtRCns7-- From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 12:10:11 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 8C31416A420 for ; Fri, 17 Mar 2006 12:10:11 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A402E43D45 for ; Fri, 17 Mar 2006 12:10:10 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2HCA6kG084616; Fri, 17 Mar 2006 09:10:08 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Martin Nilsson Date: Fri, 17 Mar 2006 09:09:42 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603161705.17351.joao@matik.com.br> <441A4DAB.4030800@gneto.com> In-Reply-To: <441A4DAB.4030800@gneto.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603170909.42622.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean 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: Fri, 17 Mar 2006 12:10:11 -0000 On Friday 17 March 2006 02:48, Martin Nilsson wrote: > JoaoBR wrote: > > with 2GB no problem, > > 3GB I do not know but 4GB is when the problem appears here for me > > > >> Wonder if there is some sort of memory pairing issue. To get >2GB and > >> <4GB I'd think you have to have 2 1GB sticks and 2 512MB sticks or > >> something like that. > > > > no it isn't in my case, I use real good dual-channel 2x (2x1GB)=20 > > suggested memory listed in the MB manual > > With 4GB memory you will likely get some memory remapped above 4GB, > could your problems be caused by a buggy driver that doesn't support > memory over the 4GB barrier correctly? (The ata driver comes to mind) > I thought this at the beginning, I got an answer from Asus and Epox support= =20 that the never Bios versions prevent this since the southbridge on Asus as= =20 example cuts some 300Mb already so I have this when using 4GB real memory =3D 3992649728 (3807 MB) avail memory =3D 3858542592 (3679 MB) there are also some rumors on some mailling lists that when using 4 double= =20 density DDR400 ram modules that the MB only recognizes them as DDR333 what = I=20 did not get confirmed anywhere, neither Asus nor Epox, that appearently has= =20 to do when people use not full qualified modules only there may be an issue using double density modules regarding dualchannel bu= t=20 the worse case that the memory module is not working as dual channel and th= e=20 board should work normally.=20 well, I do not use IDEs or SATAs and it seems the ahd driver is not affected I have a very small kernel and I do not even compile sio/lpt or any other=20 unecessary stuff I use xl|sk|nve and the scsi driver only I just compiled a releng_6 i386 and will check this weekend one of this X2= =20 machines to see what happens Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 12:15:52 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 EA1C116A425; Fri, 17 Mar 2006 12:15:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 703A143D45; Fri, 17 Mar 2006 12:15:50 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.3/8.13.3) with ESMTP id k2HCFixf007492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 14:15:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k2HCFhWx067601; Fri, 17 Mar 2006 14:15:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.4/8.13.4/Submit) id k2HCFhBW067600; Fri, 17 Mar 2006 14:15:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Mar 2006 14:15:43 +0200 From: Kostik Belousov To: Ariff Abdullah Message-ID: <20060317121543.GE1203@deviant.kiev.zoral.com.ua> References: <20060317185142.56e5042d.ariff@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WBsA/oQW3eTA3LlM" Content-Disposition: inline In-Reply-To: <20060317185142.56e5042d.ariff@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on fw.zoral.com.ua Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: acquiring duplicate lock of same type: "vnode interlock" X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 12:15:52 -0000 --WBsA/oQW3eTA3LlM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 17, 2006 at 06:51:42PM +0800, Ariff Abdullah wrote: > I think I've read somewhere about panic during early root mount, fsck > etc.. Perhaps this might be related: >=20 > Full dmesg: http://people.freebsd.org/~ariff/misc/dmesg.boot.amd64 >=20 > [....] > acquiring duplicate lock of same type: "vnode interlock" > 1st vnode interlock @ kern/vfs_vnops.c:791 > 2nd vnode interlock @ kern/vfs_subr.c:2018 > KDB: stack backtrace: > witness_checkorder() at witness_checkorder+0x4da > _mtx_lock_flags() at _mtx_lock_flags+0x4a > vrefcnt() at vrefcnt+0x31 > null_checkvp() at null_checkvp+0x65 > null_lock() at null_lock+0x5b > VOP_LOCK_APV() at VOP_LOCK_APV+0x81 > vn_lock() at vn_lock+0x6b > nullfs_root() at nullfs_root+0x4c > vfs_donmount() at vfs_donmount+0x1096 > nmount() at nmount+0x82 > syscall() at syscall+0x21b > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x800679e8c, rsp =3D > 0x7fffffffe558, rbp =3D 0x7fffffffee40 --- It does not seem to be the moment of mounting root. Do you have nullfs mounts in fstab ? If yes, then, probably, some user-mode output is absent in your trace. Anyway, issue looks like cosmetic and manifests itself only under both WITNESS and DIAGNOSTIC options, living itself in diagonstic code. The patch shuts the witness in dirty manner: Index: sys/fs/nullfs/null_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/fs/nullfs/null_subr.c,v retrieving revision 1.50 diff -u -r1.50 null_subr.c --- sys/fs/nullfs/null_subr.c 22 Feb 2006 06:15:12 -0000 1.50 +++ sys/fs/nullfs/null_subr.c 17 Mar 2006 12:13:46 -0000 @@ -306,7 +306,7 @@ while (null_checkvp_barrier) /*WAIT*/ ; panic("null_checkvp"); } - if (vrefcnt(a->null_lowervp) < 1) { + if (a->null_lowervp->v_usecount < 1) { int i; u_long *p; printf("vp =3D %p, unref'ed lowervp\n", (void *)vp); for (p =3D (u_long *) a, i =3D 0; i < 8; i++) I do not think that it worthy to reorg code to allow to use vrefcnt. --WBsA/oQW3eTA3LlM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEGqhuC3+MBN1Mb4gRAqnmAKCB6mxoGGLfJk0TEbP1tMPirERBAgCgp7FG hn2pmPvu+yi8ejjUkreJ1JU= =PltH -----END PGP SIGNATURE----- --WBsA/oQW3eTA3LlM-- From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 12:17:18 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 E65DB16A596 for ; Fri, 17 Mar 2006 12:17:18 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53CF843D58 for ; Fri, 17 Mar 2006 12:17:13 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2HCH9XB084852; Fri, 17 Mar 2006 09:17:11 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Bruce Evans Date: Fri, 17 Mar 2006 09:16:47 -0300 User-Agent: KMail/1.9.1 References: <20060313221836.5491916A420@hub.freebsd.org> <200603160917.30225.peter@wemm.org> <20060317064348.C48622@delplex.bde.org> In-Reply-To: <20060317064348.C48622@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603170916.48004.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 12:17:19 -0000 On Thursday 16 March 2006 18:30, Bruce Evans wrote: > On Thu, 16 Mar 2006, Peter Wemm wrote: > > There are a number of weaknesses in the amd64 port too. In particular, > > the math library does not yet use the generally superior SSE2 > > instructions. This is a real setback because the ABI uses SSE2 > > floating point parameter passing. The effect is that some random libm > > function is given a SSE2 register, which we convert to and x87 fp stack > > register, do the x87 operation, then convert the x87 stack register > > back to a SSE2 register then return the SSE2 result. This is > > especially unfortunate when the native SSE2 instruction that would > > operate on the SSE2 registers directly is faster. But, I don't know > > SSE2 nor x87 fpu assembler code very well, so I've done "just enough" > > to get things to work. > do SSE influence "normal" operations as disk-io, memory access and network ? > My benchmarks in libm indicate that 64-bitness + SSE2 end up being a > tiny improvment for single precision and a signifcant improvement for > double and long double precision (even for long double where SSE2 > cannot be used!), but this is only for versions that doesn't use the > FPU for transcendental functions, and I think it is mainly from foot > shooting in the 32-bit versions. The improvment in double precision > is needed to be competitive with the hardware transcendental functions, > and the foot shooting is from heavy use of the GET/SET macros -- these > macros force things to memory and thus tend to cause pipeline stalls. > sorry, would you mind to say what do you mean with "foot shooting" here?=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 13:00:32 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDFE116A401 for ; Fri, 17 Mar 2006 13:00:32 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43D9543D45 for ; Fri, 17 Mar 2006 13:00:32 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2HD0Wx8065388 for ; Fri, 17 Mar 2006 13:00:32 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2HD0VqA065387; Fri, 17 Mar 2006 13:00:32 GMT (envelope-from gnats) Resent-Date: Fri, 17 Mar 2006 13:00:32 GMT Resent-Message-Id: <200603171300.k2HD0VqA065387@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Armin Mohring Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 913BE16A420 for ; Fri, 17 Mar 2006 12:52:30 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48CEB43D6D for ; Fri, 17 Mar 2006 12:52:30 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k2HCqTXD054408 for ; Fri, 17 Mar 2006 12:52:29 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k2HCqTtY054407; Fri, 17 Mar 2006 12:52:29 GMT (envelope-from nobody) Message-Id: <200603171252.k2HCqTtY054407@www.freebsd.org> Date: Fri, 17 Mar 2006 12:52:29 GMT From: Armin Mohring To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/94604: Installation not only into a primary partition X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 13:00:32 -0000 >Number: 94604 >Category: amd64 >Synopsis: Installation not only into a primary partition >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Mar 17 13:00:31 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Armin Mohring >Release: 6.0 >Organization: >Environment: x86_64 >Description: Like with any other Linux distribution, it should be possible to install Freebsd into a logical partition. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 13:04:45 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5644216A401 for ; Fri, 17 Mar 2006 13:04:45 +0000 (UTC) (envelope-from jc@oxado.com) Received: from mars.interactivemediafactory.net (ci-77.custnet-1.n-3.pari1.eu.psigh.com [62.50.134.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id D345B43D45 for ; Fri, 17 Mar 2006 13:04:44 +0000 (GMT) (envelope-from jc@oxado.com) Received: from JC-8600.oxado.com (localhost [127.0.0.1]) by mars.interactivemediafactory.net (8.12.11/8.12.11) with ESMTP id k2HD4a2o051735; Fri, 17 Mar 2006 14:04:41 +0100 (CET) (envelope-from jc@oxado.com) Message-Id: <7.0.0.16.0.20060317133742.03ceb0c8@imfeurope.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 17 Mar 2006 14:02:53 +0100 To: Robert Leftwich From: Jacques Caron In-Reply-To: <441946A7.7090302@rtl.fmailbox.com> References: <4411D6D8.5030101@wmptl.com> <44122C1C.6030301@samsco.org> <441946A7.7090302@rtl.fmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: amd64@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 13:04:45 -0000 Hi, At 12:06 16/03/2006, Robert Leftwich wrote: >>Scott Long writes: >> >>>The ATA driver is still a bit flakey with more than 4GB of RAM, so >>>make sure that you are using either a modern SCSI controller or a >>>RAID controller. > >Would you mind clarifying if this applies to *only* > 4GB of ram or >if it includes exactly 4GB? Also does PAE impact this flakey-ness? >Are there any particular chipsets that are flaky/non-flaky? Are all >FreeBSD 6.x versions affected? > >I guess what it boils down to is that I'm running an asus a8n-sli >premium with 4GB ram and 4*160GB SATA2 drives in raid 0+1 (via the >onboard nVidia (pseudo) raid) and currently using 6.1beta3 (as 6.0x >does not recognise all 4GB of ram) - should I be worried that the >drives are going to be flaky? It will affect any machine with more than 2 (S)ATA drives where some of the memory is above the 32-bit limit, since it requires the busdma code to allocate bounce buffers under the 32-bit limit, and the busdma code has a hard limit on the amount of bounce buffers it allocates for a given type in some conditions (in 5.4 at least, haven't checked what the status is in 6.0 and later), and the ATA driver wants more. To check if things work, simply do (on a box that you're ready to see panic): dd if=/dev/adX of=/dev/null bs=512k & dd if=/dev/adY of=/dev/null bs=512k & dd if=/dev/adZ of=/dev/null bs=512k & dd if=/dev/adT of=/dev/null bs=512k & where X,Y,Z,T are the device numbers of your different drives. If your box is still alive after your have entered the 4th line you should be safe (on 5.4 you actually won't even get to the 4th line, a panic will interfere with your day). You may also want to check sysctl -a | grep busdma before/while you run the test: hw.busdma.zone1.total_bpages: 320 hw.busdma.zone1.free_bpages: 320 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 763930088 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 On a stock 5.4 total_bpages will be much lower than 320, and active_bpages will reach the limit pretty soon (once the 2nd dd is running) and kaboom (once your launch the 3rd dd) since the driver expects the pages to be there (busdma tells it they are). I run my 5.4 boxes with the following patch: diff -c sys/dev/ata/ata-dma.c.orig sys/dev/ata/ata-dma.c *** sys/dev/ata/ata-dma.c.orig Fri Sep 2 16:14:19 2005 --- sys/dev/ata/ata-dma.c Thu Oct 27 12:40:12 2005 *************** *** 111,117 **** BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, 256 * DEV_BSIZE, ATA_DMA_ENTRIES, ch->dma->max_iosize, ! BUS_DMA_ALLOCNOW, NULL, NULL, &ch->dma->ddmatag)) goto error; if (bus_dmamem_alloc(ch->dma->cdmatag, (void **)&ch->dma->dmatab, 0, --- 111,117 ---- BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, 256 * DEV_BSIZE, ATA_DMA_ENTRIES, ch->dma->max_iosize, ! 0, NULL, NULL, &ch->dma->ddmatag)) goto error; if (bus_dmamem_alloc(ch->dma->cdmatag, (void **)&ch->dma->dmatab, 0, It is not the "right" fix (the problem is in busdma, not ata, or at least it used to be in 5.4), but it's a workaround that works pretty well: busdma will gladly allocate the bounce buffers and ata will happily use them. Note again that I really haven't checked if things have changed in post-5.4 versions, so maybe it works now. I believe Scott made at least one change somewhere in there, but I haven't had the opportunity to look at it or test it. And obviously I can't tell you if the above patch works with anything other than 5.4. Final note: bounce buffer allocation is *very* slow, so with the above patch it takes a few seconds for each ata driver to initialize. Hope that helps, Jacques. From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 17 19:32:49 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 DE95616A41F for ; Fri, 17 Mar 2006 19:32:49 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4694B43D4C for ; Fri, 17 Mar 2006 19:32:49 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail09.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k2HJWlEo007106 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 18 Mar 2006 06:32:47 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k2HJWkOx040143 for ; Sat, 18 Mar 2006 06:32:46 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k2HJWkJ0040142 for freebsd-amd64@freebsd.org; Sat, 18 Mar 2006 06:32:46 +1100 (EST) (envelope-from peter) Date: Sat, 18 Mar 2006 06:32:46 +1100 From: Peter Jeremy To: freebsd-amd64@freebsd.org Message-ID: <20060317193246.GA688@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Subject: Bootstrapping Java from i386 version X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 19:32:49 -0000 Has anyone managed to get the i386 jdk1.4.2 running on amd64? (If this even possible)? I've tried writing a wrapper that sets LD_LIBRARY_PATH to point onto my i386 filesystem and running java but it just generates lots (377K/sec) of traps. Running ktrace shows that it starts ok (mapping the correct .so's), checks the password file, creates a /tmp/hsperfdata_peter directory and then goes off into the wide blue yonder. Does anyone have any suggestions? -- Peter Jeremy From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 00:58:06 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 2C95B16A400 for ; Sat, 18 Mar 2006 00:58:06 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 776FC43D45 for ; Sat, 18 Mar 2006 00:58:05 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (Postfix) with ESMTP id ECEBD7DDCD; Sat, 18 Mar 2006 11:58:03 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k2I0w0FC005197; Sat, 18 Mar 2006 11:58:01 +1100 Date: Sat, 18 Mar 2006 11:57:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: JoaoBR In-Reply-To: <200603170916.48004.joao@matik.com.br> Message-ID: <20060318113545.R52723@delplex.bde.org> References: <20060313221836.5491916A420@hub.freebsd.org> <200603160917.30225.peter@wemm.org> <20060317064348.C48622@delplex.bde.org> <200603170916.48004.joao@matik.com.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? / How is hyperthreading handled on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 00:58:06 -0000 On Fri, 17 Mar 2006, JoaoBR wrote: > On Thursday 16 March 2006 18:30, Bruce Evans wrote: >> On Thu, 16 Mar 2006, Peter Wemm wrote: >>> There are a number of weaknesses in the amd64 port too. In particular, >>> the math library does not yet use the generally superior SSE2 >>> instructions. This is a real setback because the ABI uses SSE2 >>> floating point parameter passing. The effect is that some random libm >>> function is given a SSE2 register, which we convert to and x87 fp stack >>> register, do the x87 operation, then convert the x87 stack register >>> back to a SSE2 register then return the SSE2 result. This is >>> especially unfortunate when the native SSE2 instruction that would >>> operate on the SSE2 registers directly is faster. But, I don't know >>> SSE2 nor x87 fpu assembler code very well, so I've done "just enough" >>> to get things to work. >> [The part that I wrote saying that this is not true was clipped.] > do SSE influence "normal" operations as disk-io, memory access and network ? Not at all on amd64 systems. Nontemporal memory accesses can be faster (or slower), but can and should be done, if at all, without using SSE on amd64 systems. (On 32-bit i386 systems with SSE1, they are only available using MMX registers; on 32-bit i386 systems with SSE2, they are available using MMX, XMM and 32-bit integer registers but the integer registers aren't wide enough the the accesses to be as efficient as possible.) >> My benchmarks in libm indicate that 64-bitness + SSE2 end up being a >> tiny improvment for single precision and a signifcant improvement for >> double and long double precision (even for long double where SSE2 >> cannot be used!), but this is only for versions that doesn't use the >> FPU for transcendental functions, and I think it is mainly from foot >> shooting in the 32-bit versions. The improvment in double precision >> is needed to be competitive with the hardware transcendental functions, >> and the foot shooting is from heavy use of the GET/SET macros -- these >> macros force things to memory and thus tend to cause pipeline stalls. >> > > sorry, would you mind to say what do you mean with "foot shooting" here? "Foot shooting" here means using a method that would be hard to unimprove on by intentionally choosing the worst method from a range of not obviously wrong methods. Bruce From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 02:49:06 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7F3E16A401 for ; Sat, 18 Mar 2006 02:49:06 +0000 (UTC) (envelope-from freebsd@rtl.fmailbox.com) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57BF943D45 for ; Sat, 18 Mar 2006 02:49:06 +0000 (GMT) (envelope-from freebsd@rtl.fmailbox.com) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 87273D40ECE; Fri, 17 Mar 2006 21:49:04 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Fri, 17 Mar 2006 21:49:04 -0500 X-Sasl-enc: A1woU1iHrmyJ7998Iwk6H1Fm/KI0mX9PXw7hq/GZ8RwU 1142650138 Received: from [192.168.1.51] (CWPP-p-144-134-229-104.prem.tmns.net.au [144.134.229.104]) by frontend3.messagingengine.com (Postfix) with ESMTP id 088E2716; Fri, 17 Mar 2006 21:48:52 -0500 (EST) Message-ID: <441B751E.1010600@rtl.fmailbox.com> Date: Sat, 18 Mar 2006 13:49:02 +1100 From: Robert Leftwich User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Caron References: <4411D6D8.5030101@wmptl.com> <44122C1C.6030301@samsco.org> <441946A7.7090302@rtl.fmailbox.com> <7.0.0.16.0.20060317133742.03ceb0c8@imfeurope.com> In-Reply-To: <7.0.0.16.0.20060317133742.03ceb0c8@imfeurope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: amd64@freebsd.org Subject: Re: 6.0-RELEASE/AMD64 Ram Capacity? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 02:49:06 -0000 Jacques Caron wrote: > At 12:06 16/03/2006, Robert Leftwich wrote: > >> should I be worried that the drives are going to be flaky? > > To check if things work, simply do (on a box that you're ready to see > panic): > dd if=/dev/adX of=/dev/null bs=512k & > dd if=/dev/adY of=/dev/null bs=512k & > dd if=/dev/adZ of=/dev/null bs=512k & > dd if=/dev/adT of=/dev/null bs=512k & I ran this on a freshly installed amd64 6.1beta4 (after trying the i386 6.1b4 and discovering the PAE kernel still has a problem with 4gb of ram on my m/b). All 4 ran fine and although my total_bpages for zone2 is 96, the most active_bpages I actually saw was 19 in zone2. (Although I don't know what the difference is between the zones 0,1 & 2 - but the zone0 and 1 figures didn't change). > > Hope that helps, > It does - I'm feeling a lot more comfortable about this 4GB flakey-ness. Thanks! Robert From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 04:08:18 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 4C7C616A422 for ; Sat, 18 Mar 2006 04:08:18 +0000 (UTC) (envelope-from reed@pilchuck.reedmedia.net) Received: from pilchuck.reedmedia.net (pilchuck.reedmedia.net [209.166.74.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCAB043D46 for ; Sat, 18 Mar 2006 04:08:17 +0000 (GMT) (envelope-from reed@pilchuck.reedmedia.net) Received: from reed by pilchuck.reedmedia.net with local (Exim 4.44) id 1FKSjh-0004x0-GK for freebsd-amd64@FreeBSD.org; Fri, 17 Mar 2006 20:08:17 -0800 Date: Fri, 17 Mar 2006 20:08:17 -0800 (PST) From: "Jeremy C. Reed" To: freebsd-amd64@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: "Jeremy C. Reed" Cc: Subject: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 04:08:18 -0000 The amd64 webpage http://www.freebsd.org/platforms/amd64.html is not easily found via front homepage. Searching for "amd64" does not get there. And "platforms" link is not easily seen on front pages. I may have overlooked though. Please make this easier to find. The amd64 webpage is missing either links to the amd64 Hardware Notes and release notes or the information provided in them. (For example, the Hardware Notes mentions Intel Xeon, but amd64 webpage only mentions Opteron and Athlon.) (Should I email the above two comments to freebsd-www@?) I was told a remote system is a 64-bit, dual processor with 12 GB memory. How can I tell if a 2.80Ghz Xeon is a 32-bit Xeon or a 64-bit Xeon? What do I look for in the 6.0-RELEASE GENERIC i386 dmesg output? I do see: ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100000 Hyperthreading: 2 logical CPUs real memory = 3489071104 (3327 MB) avail memory = 3414630400 (3256 MB) How can I tell if it can take advantage of "options SMP" (from looking at 6.0-RELEASE i386 GENERIC output)? (I do see "Hyperthreading: 2 logical CPUs".) I was told it has 12 GB of memory. The Hardware Notes also says "The largest tested memory configuration to date is 8GB." But I only see "real memory = 3489071104 (3327 MB)". (I also looked at NYCBUG's dmesg database but didn't seem to find any same Xeon.) Also maybe answers or advice for above can be listed on the amd64 webpage. Thanks, Jeremy C. Reed echo '9,J8HD,fDGG8B@?:536FC5=8@I;C5?@H5B0D@5GBIELD54DL>@8L?:5GDEJ8LDG1' |\ sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP' From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 04:41:12 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 7FB5F16A400 for ; Sat, 18 Mar 2006 04:41:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CF1443D46 for ; Sat, 18 Mar 2006 04:41:11 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k2I4fATE009014; Fri, 17 Mar 2006 20:41:10 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k2I4fA6n009013; Fri, 17 Mar 2006 20:41:10 -0800 (PST) (envelope-from sgk) Date: Fri, 17 Mar 2006 20:41:10 -0800 From: Steve Kargl To: "Jeremy C. Reed" Message-ID: <20060318044110.GA8986@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 04:41:12 -0000 On Fri, Mar 17, 2006 at 08:08:17PM -0800, Jeremy C. Reed wrote: > > How can I tell if a 2.80Ghz Xeon is a 32-bit Xeon or a 64-bit Xeon? What > do I look for in the 6.0-RELEASE GENERIC i386 dmesg output? I do see: > > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) ^^^^^^^^^^^^^ You're running a i386 kernel, which is 32-bit. > Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x641d> > AMD Features=0x20100000 > Hyperthreading: 2 logical CPUs > real memory = 3489071104 (3327 MB) > avail memory = 3414630400 (3256 MB) > > How can I tell if it can take advantage of "options SMP" (from looking at > 6.0-RELEASE i386 GENERIC output)? (I do see "Hyperthreading: 2 logical > CPUs".) You're using a GENERIC kernel. IIRC, "options SMP" isn't included in GENERIC, so you're running a UP kernel. You need to rebuild the kernel > I was told it has 12 GB of memory. The Hardware Notes also says "The > largest tested memory configuration to date is 8GB." But I only see "real > memory = 3489071104 (3327 MB)". The i386 is limited to 4 GB address space without options PAE. You need to rebuild your kernel. -- Steve From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 06:02:32 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 9A04E16A420 for ; Sat, 18 Mar 2006 06:02:32 +0000 (UTC) (envelope-from reed@pilchuck.reedmedia.net) Received: from pilchuck.reedmedia.net (pilchuck.reedmedia.net [209.166.74.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB9D43D45 for ; Sat, 18 Mar 2006 06:02:31 +0000 (GMT) (envelope-from reed@pilchuck.reedmedia.net) Received: from reed by pilchuck.reedmedia.net with local (Exim 4.44) id 1FKUWF-0004UK-H5; Fri, 17 Mar 2006 22:02:31 -0800 Date: Fri, 17 Mar 2006 22:02:31 -0800 (PST) From: "Jeremy C. Reed" To: Steve Kargl In-Reply-To: <20060318044110.GA8986@troutmask.apl.washington.edu> Message-ID: References: <20060318044110.GA8986@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: "Jeremy C. Reed" Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 06:02:32 -0000 On Fri, 17 Mar 2006, Steve Kargl wrote: > > How can I tell if a 2.80Ghz Xeon is a 32-bit Xeon or a 64-bit Xeon? What > > do I look for in the 6.0-RELEASE GENERIC i386 dmesg output? I do see: > > > > ACPI APIC Table: > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) > ^^^^^^^^^^^^^ > You're running a i386 kernel, which is 32-bit. I already know what it is currently running. In my email, I tried to indicate that it is running 6.0-RELEASE GENERIC i386 (twice in the parts you included in your reply). I am unclear if you are answering my question: How can I tell if a 2.80Ghz Xeon is a 32-bit Xeon or a 64-bit Xeon? > > Features=0xbfebfbff > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x641d> > > AMD Features=0x20100000 > > Hyperthreading: 2 logical CPUs > > real memory = 3489071104 (3327 MB) > > avail memory = 3414630400 (3256 MB) > > > > How can I tell if it can take advantage of "options SMP" (from looking at > > 6.0-RELEASE i386 GENERIC output)? (I do see "Hyperthreading: 2 logical > > CPUs".) > > You're using a GENERIC kernel. IIRC, "options SMP" isn't included > in GENERIC, so you're running a UP kernel. You need to rebuild > the kernel I understand. I know it is running GENERIC as I mentioned. My question is: How can I tell if it can take advantage of "options SMP" (from looking at 6.0-RELEASE i386 GENERIC output)? > > I was told it has 12 GB of memory. The Hardware Notes also says "The > > largest tested memory configuration to date is 8GB." But I only see "real > > memory = 3489071104 (3327 MB)". > > The i386 is limited to 4 GB address space without options PAE. You > need to rebuild your kernel. Only i386 supports "options PAE". How can I tell if this system can support an amd64 (without physical access)? I am still unsure. Sorry if I misunderstood your reply. I know I am currently running a 6.0-RELEASE i386 GENERIC kernel. (And I know SMP is not in GENERIC). I want to know how I can find out if I should be running an amd64 kernel instead. I was under the impression that some (all?) 64 bit Athlons, Opterons, Xeons can also run the 32-bit i386 kernel. (I was sure I have seen this too.) I have been looking at src/sys/i386/i386/identcpu.c. But I am not sure how an 64-bit Intel Xeon would behave. (I am guessing it would be CPUCLASS_686.) I do see that my dmesg output has AMD featuress with "LM" which means 64-bit long mode. But I don't know if that means this is a 64-bit system. I see the dmesg says "Id = 0xf43" (this is the cpu_id). Doing some google searches show one "K8-class" and several "686-class" CPUs. Also NYCBUG's dmesg database has that same "K8-class" "Id = 0xf43" system. A "K8-class" is definitely from an amd64 kernel (as it is printed from the src/sys/amd64/amd64/identcpu.c). I am hoping the system I am looking at can run the amd64 kernel. Thanks for your reply. You got me searching into the kernel source now. Jeremy C. Reed echo '9,J8HD,fDGG8B@?:536FC5=8@I;C5?@H5B0D@5GBIELD54DL>@8L?:5GDEJ8LDG1' |\ sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP' From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 08:01:31 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 D949B16A400 for ; Sat, 18 Mar 2006 08:01:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D03E43D46 for ; Sat, 18 Mar 2006 08:01:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k2I81TWP099654; Sat, 18 Mar 2006 01:01:29 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <441BBE52.8000204@samsco.org> Date: Sat, 18 Mar 2006 01:01:22 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jeremy C. Reed" References: <20060318044110.GA8986@troutmask.apl.washington.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 08:01:32 -0000 Jeremy C. Reed wrote: > On Fri, 17 Mar 2006, Steve Kargl wrote: > > >>>How can I tell if a 2.80Ghz Xeon is a 32-bit Xeon or a 64-bit Xeon? What >>>do I look for in the 6.0-RELEASE GENERIC i386 dmesg output? I do see: >>> >>>ACPI APIC Table: >>>Timecounter "i8254" frequency 1193182 Hz quality 0 >>>CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) >> >> ^^^^^^^^^^^^^ >>You're running a i386 kernel, which is 32-bit. > > > I already know what it is currently running. In my email, I tried to > indicate that it is running 6.0-RELEASE GENERIC i386 (twice in the parts > you included in your reply). > > I am unclear if you are answering my question: How can I tell if a 2.80Ghz > Xeon is a 32-bit Xeon or a 64-bit Xeon? > The 'LM' string in the AMD Features lines tells you that it can go into long mode, which means that it can operate in 64 bit mode. > >>>Features=0xbfebfbff>>MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >>> Features2=0x641d> >>> AMD Features=0x20100000 >>> Hyperthreading: 2 logical CPUs >>>real memory = 3489071104 (3327 MB) >>>avail memory = 3414630400 (3256 MB) >>> >>>How can I tell if it can take advantage of "options SMP" (from looking at >>>6.0-RELEASE i386 GENERIC output)? (I do see "Hyperthreading: 2 logical >>>CPUs".) >> >>You're using a GENERIC kernel. IIRC, "options SMP" isn't included >>in GENERIC, so you're running a UP kernel. You need to rebuild >>the kernel > > > I understand. I know it is running GENERIC as I mentioned. My question is: > How can I tell if it can take advantage of "options SMP" (from looking at > 6.0-RELEASE i386 GENERIC output)? > How can I tell if my car takes diesel or unleaded? I'm sorry, but this questioning sounds a bit hysterical. But, if you truly have no other way of knowing, compile and run the tool in /usr/src/tools/tools/ncpus. > >>>I was told it has 12 GB of memory. The Hardware Notes also says "The >>>largest tested memory configuration to date is 8GB." But I only see "real >>>memory = 3489071104 (3327 MB)". >> >>The i386 is limited to 4 GB address space without options PAE. You >>need to rebuild your kernel. > > > Only i386 supports "options PAE". How can I tell if this system can > support an amd64 (without physical access)? See above. > > I am still unsure. Sorry if I misunderstood your reply. I know I am > currently running a 6.0-RELEASE i386 GENERIC kernel. (And I know SMP is > not in GENERIC). I want to know how I can find out if I should be running > an amd64 kernel instead. > > I was under the impression that some (all?) 64 bit Athlons, Opterons, > Xeons can also run the 32-bit i386 kernel. (I was sure I have seen this > too.) > > I have been looking at src/sys/i386/i386/identcpu.c. But I am not sure how > an 64-bit Intel Xeon would behave. (I am guessing it would be > CPUCLASS_686.) CPUCLASS_686 refers to Pentium Pro and above CPUs, and significantly predates the 64-bit x86 architecture. But fwiw, the i386 sources files are not a good place to find 64-bit code. > > I do see that my dmesg output has AMD featuress with "LM" which means > 64-bit long mode. But I don't know if that means this is a 64-bit system. YES! > > I see the dmesg says "Id = 0xf43" (this is the cpu_id). Doing some google > searches show one "K8-class" and several "686-class" CPUs. Also NYCBUG's > dmesg database has that same "K8-class" "Id = 0xf43" system. A "K8-class" > is definitely from an amd64 kernel (as it is printed from the > src/sys/amd64/amd64/identcpu.c). > > I am hoping the system I am looking at can run the amd64 kernel. Yes, it sure can. Scott From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 08:43:38 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 D13FA16A401 for ; Sat, 18 Mar 2006 08:43:38 +0000 (UTC) (envelope-from satyam@sklinks.com) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by mx1.FreeBSD.org (Postfix) with SMTP id 7AFA643D45 for ; Sat, 18 Mar 2006 08:43:38 +0000 (GMT) (envelope-from satyam@sklinks.com) Received: (qmail 36852 invoked from network); 18 Mar 2006 08:43:37 -0000 Received: from unknown (HELO akasha.akasha) (varuna@sbcglobal.net@69.106.233.173 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 18 Mar 2006 08:43:37 -0000 From: Joseph Vella To: freebsd-amd64@freebsd.org Date: Sat, 18 Mar 2006 00:42:47 -0800 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603180042.47458.satyam@sklinks.com> Cc: "Jeremy C. Reed" Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 08:43:39 -0000 On Friday 17 March 2006 20:08, Jeremy C. Reed wrote: > The amd64 webpage http://www.freebsd.org/platforms/amd64.html is not > easily found via front homepage. Searching for "amd64" does not get there. > And "platforms" link is not easily seen on front pages. I may have > overlooked though. Please make this easier to find. In the upper left part of the website homepage, there's a single paragraph. The last sentence of that paragraph has a direct link to the page you refer. > > The amd64 webpage is missing either links to the amd64 Hardware Notes > and release notes or the information provided in them. (For example, the > Hardware Notes mentions Intel Xeon, but amd64 webpage only mentions > Opteron and Athlon.) > > (Should I email the above two comments to freebsd-www@?) > > I was told a remote system is a 64-bit, dual processor with 12 GB memory. > > How can I tell if a 2.80Ghz Xeon is a 32-bit Xeon or a 64-bit Xeon? What > do I look for in the 6.0-RELEASE GENERIC i386 dmesg output? I do see: > > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 > > Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x641d> > AMD Features=0x20100000 > Hyperthreading: 2 logical CPUs > real memory = 3489071104 (3327 MB) > avail memory = 3414630400 (3256 MB) > > How can I tell if it can take advantage of "options SMP" (from looking at > 6.0-RELEASE i386 GENERIC output)? (I do see "Hyperthreading: 2 logical > CPUs".) Right after the lines you posted I have "Multiprocessor System Detected: 2 CPUs": Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> Hyperthreading: 2 logical CPUs real memory = 2147155968 (2047 MB) avail memory = 2091982848 (1995 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 I had to recompile my kernel to get that. I found it pretty easy to do, the Handbook tells you how. I'm not sure if this was in there but I had to add "Options SMP" to my kernel config file. Under the section "II. Common Tasks" you'll find Configuring the FreeBSD Kernel: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html The handbook is the main official source of documentation. I find it to be amazingly complete and accurate. I usually start there for anything I need. > > I was told it has 12 GB of memory. The Hardware Notes also says "The > largest tested memory configuration to date is 8GB." But I only see "real > memory = 3489071104 (3327 MB)". > > (I also looked at NYCBUG's dmesg database but didn't seem to find any same > Xeon.) > > Also maybe answers or advice for above can be listed on the amd64 webpage. > > Thanks, > > Jeremy C. Reed > > echo '9,J8HD,fDGG8B@?:536FC5=8@I;C5?@H5B0D@5GBIELD54DL>@8L?:5GDEJ8LDG1' |\ > sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP' > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 16:34:55 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 CDE7216A41F for ; Sat, 18 Mar 2006 16:34:55 +0000 (UTC) (envelope-from reed@pilchuck.reedmedia.net) Received: from pilchuck.reedmedia.net (pilchuck.reedmedia.net [209.166.74.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 374DE43D48 for ; Sat, 18 Mar 2006 16:34:55 +0000 (GMT) (envelope-from reed@pilchuck.reedmedia.net) Received: from reed by pilchuck.reedmedia.net with local (Exim 4.44) id 1FKeOE-0006wD-Lc for freebsd-amd64@freebsd.org; Sat, 18 Mar 2006 08:34:54 -0800 Date: Sat, 18 Mar 2006 08:34:54 -0800 (PST) From: "Jeremy C. Reed" To: freebsd-amd64@freebsd.org In-Reply-To: <200603180042.47458.satyam@sklinks.com> Message-ID: References: <200603180042.47458.satyam@sklinks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: "Jeremy C. Reed" Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 16:34:55 -0000 Thank you, Joseph and Scott. I am replying to both Joseph's and Scott's emails below. (Plus I have new questions below :) On Sat, 18 Mar 2006, Joseph Vella wrote: > In the upper left part of the website homepage, there's a single paragraph. > The last sentence of that paragraph has a direct link to the page you refer. Thanks. I overlooked that. I was looking in the various lists of hyperlinks. Maybe the "amd64" could be hyperlinked above? (But then again maybe hyperlinking everything becomes too cluttered.) But I feel it should be hyperlinked for sure direct from the "Get FreeBSD" webpage. > Right after the lines you posted I have "Multiprocessor System Detected: 2 > CPUs": ... > I had to recompile my kernel to get that. I found it pretty easy to do, the > Handbook tells you how. I'm not sure if this was in there but I had to add > "Options SMP" to my kernel config file. That is my point. I do not want to compile and reboot with new kernel to know this. I am not asking how to get SMP enabled. I just want to know if this system even supports it. (Thanks for links to kernconfig.html and handbook. I have had the opportunity to read most of the handbook -- plus several other BSD books in addition to my own *BSD courseware -- already. And I have configured and built FreeBSD kernels hundreds of times, including many with SMP support.) I am looking for something like: "This machine appears to have support for multiprocessors; enabling 'options SMP' may take advantage of this." > The 'LM' string in the AMD Features lines tells you that it can go into long > mode, which means that it can operate in 64 bit mode. Awesome! That was what I was hoping. It would be great if this was listed somewhere, maybe on a FAQ or amd64 or i386 webpage. (If I overlooked this I am sorry, but please point me to it.) (I did find brief note of this in identcpu.c code, but that seems like the wrong way to find out and is not clear.) > > I understand. I know it is running GENERIC as I mentioned. My question is: > > How can I tell if it can take advantage of "options SMP" (from looking at > > 6.0-RELEASE i386 GENERIC output)? > > > > How can I tell if my car takes diesel or unleaded? I'm sorry, but this > questioning sounds a bit hysterical. But, if you truly have no other > way of knowing, compile and run the tool in /usr/src/tools/tools/ncpus. I don't know why it is funny. (Anyways with most cars, even without access to engine, you can look on dash board and on fuel cap and see.) Imagine someone giving you remote access to a system and you don't know what hardware it has (since you can not physically inspect). Rebooting with an SMP kernel seems like the slow way to find out. I am just curious if there is some way without rebooting, maybe the non-SMP kernel could detect and printf at boot time (for dmesg) something like: "It appears this system is multiprocessor; using 'options SMP' may be useful." I have used the ncpu's tool before (ported from FreeBSD to DragonFly). I didn't realize that it could tell a non-SMP kernel user about their multiprocessors. I didn't have a chance to run it yet on FreeBSD 6.0-RELEASE, as it does not compile: In file included from biosmptable.c:37: /usr/include/machine/mptable.h:143: error: syntax error before "pcib" Maybe because device_t is not defined yet. It is defined in sys/bus.h but only if _KERNEL. I will look at that later. It would be useful for a user to know if system is multiprocessor without building and running an outside tool (in this case not even included with FreeBSD 6.0-RELEASE). > > I have been looking at src/sys/i386/i386/identcpu.c. But I am not sure how > > an 64-bit Intel Xeon would behave. (I am guessing it would be CPUCLASS_686.) > > CPUCLASS_686 refers to Pentium Pro and above CPUs, and significantly > predates the 64-bit x86 architecture. But fwiw, the i386 sources files > are not a good place to find 64-bit code. Understood. The system is running FreeBSD-6.0-RELEASE i386 GENERIC. It would be interesting to add to the dmesg output: "Consider using the 'amd64' kernel" if that is appropriate. > > I do see that my dmesg output has AMD featuress with "LM" which means 64-bit > > long mode. But I don't know if that means this is a 64-bit system. > > YES! ... > > I am hoping the system I am looking at can run the amd64 kernel. > > Yes, it sure can. That was the answer I am looking for! Thank you! I will now reboot with an amd64 kernel. (Hopefully with reboot all my 12 GB of memory will be seen; I do understand there are some issues with big memory.) Can you please point me to the webpage that says it is okay to boot an amd64 kernel using a i386 (6.0-RELEASE in this case) userland? (I will update userland after reboot.) Also can you point me to the documentation for cross-compiling amd64 kernel and userland (on i386 host). The point of my email: it would be nice if there was some documentation or webpage or kernel boot output that can suggest to an i386 user that they should consider using an amd64 kernel instead -- and it would be nice if there was some documentation or webpage or kernel boot output that can suggest to a user that an "options SMP" kernel could be beneficial. Booting an amd64 kernel on a (possibly) non-amd64 system seems like the wrong way to find out. Booting an "options SMP" kernel to find out if multiprocessor seems like a slow way to find out. I will submit a patch for the amd64 webpage and maybe the FAQ and maybe the i386 webpage. Please review the following: "If you boot with an i386 kernel and it shows an "AMD Features" line containing an "LM" string, then you are operating in 64-bit long mode and can use an amd64 kernel." (I don't have text for my SMP question since I still do not know the answer.) Thanks again for the replies. Jeremy C. Reed From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 17:14:50 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 8BD6116A400 for ; Sat, 18 Mar 2006 17:14:50 +0000 (UTC) (envelope-from smeagle@hell.nonstopviolence.de) Received: from hell.nonstopviolence.de (www.nonstopviolence.de [213.95.21.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0242B43D49 for ; Sat, 18 Mar 2006 17:14:49 +0000 (GMT) (envelope-from smeagle@hell.nonstopviolence.de) Received: from hell.nonstopviolence.de (smeagle@localhost [127.0.0.1]) by hell.nonstopviolence.de (8.13.4/8.12.10) with ESMTP id k2IHFft2014693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Mar 2006 18:15:41 +0100 (CET) (envelope-from smeagle@hell.nonstopviolence.de) Received: (from smeagle@localhost) by hell.nonstopviolence.de (8.13.1/8.12.2/Submit) id k2IHFeEJ014692 for freebsd-amd64@freebsd.org; Sat, 18 Mar 2006 18:15:40 +0100 (CET) (envelope-from smeagle) Date: Sat, 18 Mar 2006 18:15:40 +0100 (CET) From: smeagle Message-Id: <200603181715.k2IHFeEJ014692@hell.nonstopviolence.de> To: freebsd-amd64@freebsd.org Subject: Plextor SATA DVD writer not recognized X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 17:14:50 -0000 Hi, last week I got a Plextor 712SA DVD writer. After installing it, it was not recognized by my installed 6.1 PRERELEASE. I searched the web for some hints but the only things I found where about problems with 5.3 RELEASE. I tried FreeSBIE 1.1 which is based on a 5.3 and could verify thoose problems. But at least it was found during bootup, something about a interupt storm was displayed on the screen and bootup hang. So I installed a Windooze to upgrade the Firmware of the Drive to version 1.07 downloaded a FreeBSD 6.1 beta4 and tried this one. Same problem, the device simply doesn't show up during bootup. Mainboard is a GigaByte GA-K8NF-9 Ultra and the drive should be atached to ata5, at least this is the port where FreeSBIE detected the device. I'm currently not able to post a dmesg output as I have not yet figured out how to get this under windooze ;( regards Florian From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 18:14:06 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 D1DE316A400 for ; Sat, 18 Mar 2006 18:14:06 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C15743D45 for ; Sat, 18 Mar 2006 18:14:06 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so743465nzf for ; Sat, 18 Mar 2006 10:14:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ar/GdhO/tivNsM0+qQtOFkOS3Lg+urXO1PFTYyxObr5TalCzezwBm6W6ItRtHxIImMXyE99P49oTyWKUKNKVjvzM+QviE0hpuHuyhKMsq2GEpFJ7PJSNiGAw0kRVw0QjBJ0POiy+nTzfRBirKIACE2fTsqVGUgr19Lo770ST9Xw= Received: by 10.36.148.14 with SMTP id v14mr5168290nzd; Sat, 18 Mar 2006 10:14:05 -0800 (PST) Received: by 10.36.220.56 with HTTP; Sat, 18 Mar 2006 10:14:05 -0800 (PST) Message-ID: <2fd864e0603181014i35ea5e07i4547ae0167706afe@mail.gmail.com> Date: Sun, 19 Mar 2006 02:14:05 +0800 From: Astrodog To: "Jeremy C. Reed" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200603180042.47458.satyam@sklinks.com> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 18:14:07 -0000 Processor feature flags are well documented. No need to duplicate work ther= e. As far as your system goes... it support Hyperthreading (Feature flag HTT), so there's no good answer to your question. HTT doesn't seem to have muc h effect one way or another on FreeBSD... though your system does support it. As far as taking ADVANTAGE of "options SMP", in your case, we can't tell, its app by app. If you don't know if your system has 2 physical cores or not, though, frankly, you have no business administrating it. Well, that, and dmesg, and the bios will tell you. I'm not sure I see the exact problem here. --- Harrison Grundy On 3/19/06, Jeremy C. Reed wrote: > Thank you, Joseph and Scott. I am replying to both Joseph's and Scott's > emails below. (Plus I have new questions below :) > > On Sat, 18 Mar 2006, Joseph Vella wrote: > > > In the upper left part of the website homepage, there's a single > paragraph. > > The last sentence of that paragraph has a direct link to the page you > refer. > > Thanks. I overlooked that. I was looking in the various lists of > hyperlinks. Maybe the "amd64" could be hyperlinked above? (But then again > maybe hyperlinking everything becomes too cluttered.) But I feel it shoul= d > be hyperlinked for sure direct from the "Get FreeBSD" webpage. > > > Right after the lines you posted I have "Multiprocessor System Detected= : 2 > > CPUs": > ... > > > I had to recompile my kernel to get that. I found it pretty easy to do= , > the > > Handbook tells you how. I'm not sure if this was in there but I had to > add > > "Options SMP" to my kernel config file. > > That is my point. I do not want to compile and reboot with new kernel > to know this. I am not asking how to get SMP enabled. I just want to know > if this system even supports it. > > (Thanks for links to kernconfig.html and handbook. I have had the > opportunity to read most of the handbook -- plus several other BSD books > in addition to my own *BSD courseware -- already. And I have configured > and built FreeBSD kernels hundreds of times, including many with SMP > support.) > > I am looking for something like: "This machine appears to have support fo= r > multiprocessors; enabling 'options SMP' may take advantage of this." > > > The 'LM' string in the AMD Features lines tells you that it can go into > long > > mode, which means that it can operate in 64 bit mode. > > Awesome! That was what I was hoping. It would be great if this was listed > somewhere, maybe on a FAQ or amd64 or i386 webpage. (If I overlooked this > I am sorry, but please point me to it.) (I did find brief note of this in > identcpu.c code, but that seems like the wrong way to find out and is > not clear.) > > > > I understand. I know it is running GENERIC as I mentioned. My questio= n > is: > > > How can I tell if it can take advantage of "options SMP" (from lookin= g > at > > > 6.0-RELEASE i386 GENERIC output)? > > > > > > > How can I tell if my car takes diesel or unleaded? I'm sorry, but this > > questioning sounds a bit hysterical. But, if you truly have no other > > way of knowing, compile and run the tool in /usr/src/tools/tools/ncpus. > > I don't know why it is funny. (Anyways with most cars, even without acces= s > to engine, you can look on dash board and on fuel cap and see.) > > Imagine someone giving you remote access to a system and you don't know > what hardware it has (since you can not physically inspect). Rebooting > with an SMP kernel seems like the slow way to find out. I am just curious > if there is some way without rebooting, maybe the non-SMP kernel could > detect and printf at boot time (for dmesg) something like: "It appears > this system is multiprocessor; using 'options SMP' may be useful." > > I have used the ncpu's tool before (ported from FreeBSD to DragonFly). I > didn't realize that it could tell a non-SMP kernel user about their > multiprocessors. > > I didn't have a chance to run it yet on FreeBSD 6.0-RELEASE, as it does > not compile: > > In file included from biosmptable.c:37: > /usr/include/machine/mptable.h:143: error: syntax error before "pcib" > > Maybe because device_t is not defined yet. It is defined in sys/bus.h but > only if _KERNEL. > > I will look at that later. > > It would be useful for a user to know if system is multiprocessor without > building and running an outside tool (in this case not even included with > FreeBSD 6.0-RELEASE). > > > > I have been looking at src/sys/i386/i386/identcpu.c. But I am not sur= e > how > > > an 64-bit Intel Xeon would behave. (I am guessing it would be > CPUCLASS_686.) > > > > CPUCLASS_686 refers to Pentium Pro and above CPUs, and significantly > > predates the 64-bit x86 architecture. But fwiw, the i386 sources files > > are not a good place to find 64-bit code. > > Understood. The system is running FreeBSD-6.0-RELEASE i386 GENERIC. It > would be interesting to add to the dmesg output: "Consider using the > 'amd64' kernel" if that is appropriate. > > > > I do see that my dmesg output has AMD featuress with "LM" which means > 64-bit > > > long mode. But I don't know if that means this is a 64-bit system. > > > > YES! > ... > > > I am hoping the system I am looking at can run the amd64 kernel. > > > > Yes, it sure can. > > That was the answer I am looking for! Thank you! > > I will now reboot with an amd64 kernel. (Hopefully with reboot all my 12 > GB of memory will be seen; I do understand there are some issues with big > memory.) > > Can you please point me to the webpage that says it is okay to boot an > amd64 kernel using a i386 (6.0-RELEASE in this case) userland? (I will > update userland after reboot.) > > Also can you point me to the documentation for cross-compiling amd64 > kernel and userland (on i386 host). > > The point of my email: it would be nice if there was some documentation o= r > webpage or kernel boot output that can suggest to an i386 user that they > should consider using an amd64 kernel instead -- and it would be nice if > there was some documentation or webpage or kernel boot output that can > suggest to a user that an "options SMP" kernel could be beneficial. > > Booting an amd64 kernel on a (possibly) non-amd64 system seems like the > wrong way to find out. > > Booting an "options SMP" kernel to find out if multiprocessor seems like = a > slow way to find out. > > I will submit a patch for the amd64 webpage and maybe the FAQ and maybe > the i386 webpage. Please review the following: > "If you boot with an i386 kernel and it shows an "AMD Features" line > containing an "LM" string, then you are operating in 64-bit long mode > and can use an amd64 kernel." > > (I don't have text for my SMP question since I still do not know the > answer.) > > Thanks again for the replies. > > Jeremy C. Reed > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 18:41:35 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 5084016A422 for ; Sat, 18 Mar 2006 18:41:35 +0000 (UTC) (envelope-from reed@pilchuck.reedmedia.net) Received: from pilchuck.reedmedia.net (pilchuck.reedmedia.net [209.166.74.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ADA943D72 for ; Sat, 18 Mar 2006 18:41:30 +0000 (GMT) (envelope-from reed@pilchuck.reedmedia.net) Received: from reed by pilchuck.reedmedia.net with local (Exim 4.44) id 1FKgMj-0005po-GI; Sat, 18 Mar 2006 10:41:29 -0800 Date: Sat, 18 Mar 2006 10:41:29 -0800 (PST) From: "Jeremy C. Reed" To: Astrodog In-Reply-To: <2fd864e0603181014i35ea5e07i4547ae0167706afe@mail.gmail.com> Message-ID: References: <200603180042.47458.satyam@sklinks.com> <2fd864e0603181014i35ea5e07i4547ae0167706afe@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: "Jeremy C. Reed" Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 18:41:35 -0000 On Sun, 19 Mar 2006, Astrodog wrote: > If you don't know if your system has 2 physical cores or not, though, > frankly, you have no business administrating it. Please tell me how. Imagine you are givin remote login access to an unknown machine. What would you do to find out? Is there any software tool in the default installation of FreeBSD 6.0-RELEASE for i386 that will tell you? > Well, that, and dmesg, and the bios will tell you. Please teach me. That was the whole point of my email. How do you know without physical access (and hopefully without rebooting)? Jeremy C. Reed echo '9,J8HD,fDGG8B@?:536FC5=8@I;C5?@H5B0D@5GBIELD54DL>@8L?:5GDEJ8LDG1' |\ sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP' From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 18:48:46 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 DF03D16A401 for ; Sat, 18 Mar 2006 18:48:46 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (hood.oook.cz [195.250.137.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8775F43D46 for ; Sat, 18 Mar 2006 18:48:45 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from ikaros.oook.cz (localhost [127.0.0.1]) by hood.oook.cz (8.13.4/8.13.4) with ESMTP id k2IImdrP085670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Mar 2006 19:48:40 +0100 (CET) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by ikaros.oook.cz (8.13.4/8.13.4/Submit) id k2IImcph085669; Sat, 18 Mar 2006 19:48:38 +0100 (CET) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: ikaros.oook.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: "Jeremy C. Reed" In-Reply-To: References: <200603180042.47458.satyam@sklinks.com> <2fd864e0603181014i35ea5e07i4547ae0167706afe@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dxMVdErQQlJF4ZLENzrJ" Date: Sat, 18 Mar 2006 19:48:37 +0100 Message-Id: <1142707717.919.47.camel@ikaros.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 18:48:47 -0000 --=-dxMVdErQQlJF4ZLENzrJ Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Jeremy C. Reed p=ED=B9e v so 18. 03. 2006 v 10:41 -0800: > On Sun, 19 Mar 2006, Astrodog wrote: >=20 > > If you don't know if your system has 2 physical cores or not, though,=20 > > frankly, you have no business administrating it. >=20 > Please tell me how. Run dmidecode (sysutils/dmidecode port), it will tell you all about the hardware, from motherboard model, BIOS version, over the processor details, what's in memory slots and how many are empty, what PCI slots are there, etc... You need root permissions for that. --=20 Pav Lucistnik > With a 10 MHz 386 the downloading speed would most likely drop to a crawl > or stop with the decoding process etc. I think most 10MHz 386 users are quite accustomed to things dropping to a crawl. --=-dxMVdErQQlJF4ZLENzrJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEHFYFntdYP8FOsoIRAp1KAKC+TGIvcpz1Ol6/6ti1wpIf2p1XlgCfSWW4 FuLh1ENXhF41/9cpa+fjYcg= =CaIy -----END PGP SIGNATURE----- --=-dxMVdErQQlJF4ZLENzrJ-- From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 19:03:14 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 67EE816A424 for ; Sat, 18 Mar 2006 19:03:14 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0374E43D72 for ; Sat, 18 Mar 2006 19:03:07 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id A12BC4A; Sat, 18 Mar 2006 13:03:06 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id D3D7361C38; Sat, 18 Mar 2006 13:03:05 -0600 (CST) Date: Sat, 18 Mar 2006 13:03:05 -0600 From: "Matthew D. Fuller" To: "Jeremy C. Reed" Message-ID: <20060318190305.GC37096@over-yonder.net> References: <200603180042.47458.satyam@sklinks.com> <2fd864e0603181014i35ea5e07i4547ae0167706afe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 19:03:14 -0000 On Sat, Mar 18, 2006 at 10:41:29AM -0800 I heard the voice of Jeremy C. Reed, and lo! it spake thus: > > Is there any software tool in the default installation of FreeBSD > 6.0-RELEASE for i386 that will tell you? mptable? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-amd64@FreeBSD.ORG Sat Mar 18 21:19:31 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 E1B9F16A422 for ; Sat, 18 Mar 2006 21:19:31 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FDCF43D6A for ; Sat, 18 Mar 2006 21:19:23 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by zproxy.gmail.com with SMTP id o37so931018nzf for ; Sat, 18 Mar 2006 13:19:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Sp/4lmP+/4mGaJIJNNmuMgIrsTXx13AZuyhtbI88uZZc/a/01s2gVWS18peHhnfVpiBBeFRpnmPAdOIQKPvNcupG+ZY06DkI6bDcJSz+QUjqQfOtXSdSlvecDpud2kqC/6uyTaHuFpHArse6LKn44rODFHG0Ejxq6IvsLnPTVPk= Received: by 10.36.251.41 with SMTP id y41mr23439nzh; Sat, 18 Mar 2006 13:19:23 -0800 (PST) Received: by 10.36.220.56 with HTTP; Sat, 18 Mar 2006 13:19:23 -0800 (PST) Message-ID: <2fd864e0603181319ka6eafa2j3b8fc80df8989459@mail.gmail.com> Date: Sun, 19 Mar 2006 05:19:23 +0800 From: Astrodog To: "Matthew D. Fuller" In-Reply-To: <20060318190305.GC37096@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200603180042.47458.satyam@sklinks.com> <2fd864e0603181014i35ea5e07i4547ae0167706afe@mail.gmail.com> <20060318190305.GC37096@over-yonder.net> Cc: "Jeremy C. Reed" , freebsd-amd64@freebsd.org Subject: Re: amd64 webpage, 12GB memory? 64-bit or not? SMP or not? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 21:19:32 -0000 The first big clue would be contacting the system's owner. I don't=20 make a habit of logging into systems where I cannot contact whoever is paying for it. That being said, mptable, the motherboard, or simply "boot SMP", will all provide the information you seek. I would be very hesitant to do anything on a system where I did not know its owner, and I cannot reboot it, however. If you're finding yourself in that situation.... run far, far away. On 3/19/06, Matthew D. Fuller wrote: > On Sat, Mar 18, 2006 at 10:41:29AM -0800 I heard the voice of > Jeremy C. Reed, and lo! it spake thus: > > > > Is there any software tool in the default installation of FreeBSD > > 6.0-RELEASE for i386 that will tell you? > > mptable? > > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. >